{"slug": "the-oom-that-was-not-your-agent", "title": "The OOM that was not your agent", "summary": "Pydantic released a new Hosts view for its Logfire observability platform that correlates host-level metrics (CPU, memory, disk I/O) with trace data in a single interface, enabling developers to diagnose infrastructure-related failures like OOM kills caused by background processes such as Postgres vacuuming. The feature uses standard OpenTelemetry hostmetricsreceiver data and is available immediately.", "body_md": "Your overnight document classifier, built on the Anthropic SDK and run on a self-hosted box, is dying every night around 2am.\n\nLogs say OOM. The agent code is unchanged. The model is unchanged. The traffic shape is identical to last week, when the job ran fine. The instinct is to bump memory and move on.\n\nWhat's new\n\n- See every host shipping metrics to your project: which are live, which are stale, which are down, and what the fleet looks like in CPU and memory.\n- Drill into any host for CPU, memory, load, and disk and network charts split by direction (read vs. write, in vs. out).\n- Click from any host straight to the traces from the workloads it ran in the live view.\n\nWhy this matters\n\nOpen the host running the batch job. Memory tells the story. It climbs steadily from midnight, hits 95% just before 2am, and your agent dies. But the climb does not start when the batch job starts. The climb is already in progress when the agent kicks in. Something else is eating the box.\n\nThe 1-minute load chart confirms it. Load is high while CPU is moderate, which means processes are waiting on something other than CPU. Disk I/O on the same host is spiking from midnight to 2am. There is a Postgres on this box, and Postgres runs a nightly vacuum.\n\nSpans tell you what the agent did. Host metrics tell you whether the machine running it had any resources left to give. Plenty of tools show you both, in different products. What was missing for us was putting them in the same product, on the same trace ID, so the question \"was it the box?\" gets answered in the same browser tab as the trace that hit the wall.\n\nAll of this data is available to you and your closest friends: Claude, Codex, Gemini, Pydantic AI, and more via MCP and our RESTful query endpoints.\n\nHow it works\n\nThe data comes from the standard OpenTelemetry [ hostmetricsreceiver](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/hostmetricsreceiver). There is no proprietary agent and no lock-in. The same OTel collector you already use for traces can collect host metrics with a few extra lines in its config.\n\nHosts are keyed in the inventory on the `host.id`\n\nand `host.name`\n\nresource attributes, populated by the collector's `resourcedetection`\n\nprocessor (the `system`\n\ndetector on Linux, plus `ec2`\n\n, `gcp`\n\n, or `azure`\n\non the matching clouds). Without those, a single host can appear duplicated or N replicas of a containerized collector can collapse into one fake host. Hosts inside a Kubernetes cluster are recognized as nodes (the dedup hinges on `host.name`\n\nmatching `k8s.node.name`\n\n) and appear on the Kubernetes view as well.\n\nEach host is marked live, stale, or down based on how recently its metrics arrived. Empty states deep-link straight to the *Everything Else* tab of the add-data wizard, with copy-pasteable hostmetrics config for the OTel collector.\n\nGetting started\n\nIf your OpenTelemetry collector already has the hostmetrics receiver enabled, the Hosts page populates within about thirty seconds of the next collection cycle. If not, the empty state on the page links to the setup steps.\n\nIn our scenario, you schedule the Postgres vacuum to run an hour earlier and add a memory cap. The agent runs through the night. The trace from the previous failure is in the live view, with the host memory chart from the night of the failure open alongside it.\n\nFull reference, including the minimum collector config and the Kubernetes-node dedup story: the [Hosts view docs](https://pydantic.dev/docs/logfire/observe/hosts/).\n\nNot using Logfire yet? [Get started](https://pydantic.dev/logfire). The free tier includes usage up to 10 million spans, our AI Gateway, and so much more.", "url": "https://wpnews.pro/news/the-oom-that-was-not-your-agent", "canonical_source": "https://pydantic.dev/articles/logfire-hosts-view", "published_at": "2026-06-18 09:00:00+00:00", "updated_at": "2026-07-16 14:31:23.890372+00:00", "lang": "en", "topics": ["developer-tools", "ai-infrastructure"], "entities": ["Pydantic", "Logfire", "Anthropic", "Claude", "Codex", "Gemini", "OpenTelemetry"], "alternates": {"html": "https://wpnews.pro/news/the-oom-that-was-not-your-agent", "markdown": "https://wpnews.pro/news/the-oom-that-was-not-your-agent.md", "text": "https://wpnews.pro/news/the-oom-that-was-not-your-agent.txt", "jsonld": "https://wpnews.pro/news/the-oom-that-was-not-your-agent.jsonld"}}