Hosts, Docker containers, Kubernetes and databases, collected by the same OpenTelemetry Collector that ships your traces. No proprietary agent, and a pod you can drill from straight into the requests it served.
receivers:
hostmetrics:
scrapers:
cpu: {}
memory: {}
disk: {}
exporters:
otlphttp:
endpoint: https://logfire-us.pydantic.dev
headers:
Authorization: Bearer ${env:LOGFIRE_TOKEN}
service:
pipelines:
metrics:
receivers: [hostmetrics]
exporters: [otlphttp]Infrastructure monitoring is collecting metrics from the machines and services your application runs on: CPU, memory, disk and network per host, resource usage per container and pod, and the health of the databases, caches and queues around them.
It answers whether the platform is healthy, which is a different question from whether a given request was slow. Explaining an incident almost always needs both, which is the argument for not keeping them in separate products.
The usual shape of this problem is one proprietary agent per vendor, each with its own configuration, its own release cadence and its own opinion about what it will send you. Adding a backend means adding an agent; removing one means a migration.
hostmetrics, containers from docker_stats, Kubernetes from the upstream
opentelemetry-kube-stack Helm chart. All of it is standard OpenTelemetry, so the day you point that last arrow somewhere else, everything
to the left of it keeps running unchanged.
The config in the hero is complete and will ship CPU, memory and disk from the machine it runs on. Two things about it are worth saying out
loud: the endpoint has to match the region your project lives in (logfire-us or logfire-eu), and a receiver only sends
anything once it is named in a pipeline.
Coverage grows a receiver at a time. Here it is again with a database attached and Kubernetes attributes wired on:
receivers:
hostmetrics:
collection_interval: 30s
scrapers:
cpu: {}
memory: {}
load: {}
disk: {}
network: {}
postgresql:
endpoint: localhost:5432
databases: [checkout]
username: ${env:POSTGRES_USER}
password: ${env:POSTGRES_PASSWORD}
processors:
k8sattributes:
extract:
metadata:
- k8s.pod.name
- k8s.namespace.name
- k8s.deployment.name
exporters:
otlphttp:
endpoint: https://logfire-us.pydantic.dev
headers:
Authorization: Bearer ${env:LOGFIRE_TOKEN}
service:
pipelines:
metrics:
receivers: [hostmetrics, postgresql]
processors: [k8sattributes]
exporters: [otlphttp]Every receiver in the collector guides works the same way, and none of it is Logfire-specific until the exporter block.
A fleet inventory with live, stale and down status, OS and architecture, a CPU sparkline, memory, load average and process count, and detail charts for CPU, memory, load, disk and network on any host you open. Collected with the standard hostmetrics receiver, so there is nothing Logfire-specific about how the numbers are produced.
Clusters, nodes, namespaces, workloads, pods and images, with restart counts rolling up at every level so a crash-looping pod is visible from the cluster view rather than only from the pod. Installed with the upstream opentelemetry-kube-stack Helm chart, which is also what wires pod, namespace and deployment names onto your spans.
Docker containers, images and Compose projects through the docker_stats receiver, with CPU, memory, block IO and network per container. Useful on its own for a single-box deployment, and the same data whether you run one container on a VM or a fleet under an orchestrator.
Container stdout, systemd journal entries and Kubernetes events land as log records in the same store as your spans and metrics. Correlating a restart with the requests that failed around it is a query rather than an export, because there is nothing to correlate across.
An alert is a query on a schedule, so anything you can ask about your infrastructure you can also be told about. Disk above 85 percent on any host, a pod restarting more than three times an hour, replication lag over a threshold, all written the same way as the query you used to find the problem the first time.
Ten of the things most likely to be running underneath your application arrive as curated packs: a dashboard, alert templates, and the collector configuration that produces the metrics they read. These are not empty tiles with a logo on them: they are dashboards somebody sat down and built, and they know what matters about each technology.
56 panels 7 alerts
Buffer pool pages, index I/O wait time, connection errors
53 panels 6 alerts
Global lock time, cache operations, index access
53 panels 7 alerts
Cluster health, unassigned shards, circuit breakers tripped
43 panels 6 alerts
Commits and rollbacks, checkpoint duration, index scans
40 panels 6 alerts
Keyspace hit ratio, evictions per second, memory fragmentation
33 panels 8 alerts
Queue depth ready vs unacknowledged, publish and deliver rates
32 panels 3 alerts
Consumer lag, under-replicated partitions, production rate by topic
26 panels 3 alerts
Hit ratio by operation, evictions per second, current items
23 panels 2 alerts
Workers by state, scoreboard, requests per second
17 panels 2 alerts
Connections by state, accepted vs handled, keep-alive idle
Detect and install reads what you are already sending and installs the packs that match, so the "which of these apply to me" step is a button rather than an afternoon.
That is 50 alerts you did not have to write, with thresholds chosen by someone who knows what the number means: Redis at 90% of maxmemory is about to start evicting, a RabbitMQ queue with no consumer is a deploy that half-finished. Getting those right is the part that takes a week.
Ten packs is ten. The catalogue that matters is the OpenTelemetry Collector's receiver list, which covers far more than we will ever hand-build dashboards for — and anything that speaks OTLP can reach us whether or not a receiver exists for it.
For all of that, the dashboard is a conversation. Logfire is an MCP server, so the coding agent you already use can read your actual telemetry, work out which attributes you are sending, and create the dashboards and alerts against them. Ask for "a dashboard for our queue workers and an alert when the backlog outlives its SLO" and it writes the queries, because the queries are SQL over the same table everything else lands in.
This is the honest answer to integration counts. A competitor with a thousand packs has a thousand things someone chose to build; anything outside that list is a support ticket. Here the pre-built packs are a convenience for the ten most common cases, and the general case is a sentence.
This is the part that is hard to do with two products. The Helm chart wires the k8sattributes processor into the trace pipeline,
not just the metrics one, so your spans carry k8s.pod.name, k8s.namespace.name and k8s.deployment.name as resource
attributes.
A pod that looks unhealthy and the requests it degraded stop being two dashboards and a hypothesis. They become one query:
select
otel_resource_attributes->>'k8s.pod.name' as pod,
count(*) as errors
from records
where otel_resource_attributes->>'k8s.pod.name' is not null
and is_exception
and start_timestamp > now() - interval '1 hour'
group by pod
order by errors desc;Group by the deployment name instead and you are asking about the rollout. Join to the host metrics and you are asking whether the node was saturated. It is the same table either way, which is the whole point of collecting it into one place.
"No proprietary agent" gets said a lot on pages like this one, so here is the honest version. The Collector is a process on your hosts and a DaemonSet in your clusters. You own its configuration, its resource limits and its upgrades. There is no arrangement in which nothing runs next to your workloads.
The difference is what that thing is. It is upstream OpenTelemetry, configured with receivers anyone can read, doing work you can inspect, and it keeps running unchanged if you point the exporter at somebody else tomorrow. That is a different proposition from a vendor binary whose behavior you take on trust and whose removal is a migration.
You can tell that Pydantic Logfire was built by people who use it.
Infrastructure is one layer. Application performance monitoring covers the requests running on top of it, and the language pages carry the framework and driver specifics for instrumenting them. All three land in the same store, and answer to the same queries.
Infrastructure monitoring is collecting metrics from the machines and services your application runs on: CPU, memory, disk and network on each host, container and pod resource usage, and the health of the databases, caches and queues around them. It answers whether the platform is healthy, which is a different question from whether a given request was slow, and you usually need both to explain an incident.
No. Infrastructure data reaches Logfire through the OpenTelemetry Collector, which is the same collector that ships your traces. Hosts use the standard hostmetrics receiver, containers use docker_stats, Kubernetes uses the upstream opentelemetry-kube-stack Helm chart. There is no proprietary agent, so the configuration you write is portable to any other OTLP backend.
Yes, and this is the main reason to have infrastructure and application telemetry in one place. The Helm chart wires the k8sattributes processor into the trace pipeline, so spans carry pod, namespace and deployment names as ordinary attributes. A pod that looks unhealthy and the requests it actually served are then the same query rather than two products and a guess.
Apache, Elasticsearch, Kafka, Memcached, MongoDB, MySQL, NGINX, PostgreSQL, RabbitMQ and Redis, each bundling a curated dashboard, alert templates and the collector configuration to produce the metrics they read. These are substantial: the PostgreSQL dashboard is 43 panels and the MySQL one is 56. Detect and install will find the ones matching what you already send and install them for you. They are built on standard OpenTelemetry receivers, so anything else with a receiver works too, it just does not come with the dashboard pre-made.
Kubernetes events arrive as log records rather than as a separate events view. That means they are queryable and correlatable with everything else in the same table, and you can alert on them with the same SQL, but if you are expecting a dedicated Events tab in the UI, there is not one.
Yes. The collector produces host, container, Kubernetes and service metrics with no application changes at all, so you can start there and add tracing later. The two get more useful together, because that is what turns 'this node is saturated' into 'and here are the requests it degraded', but neither requires the other.
Metrics count as records like spans and logs do. Personal includes 10 million records a month and pauses ingestion at the limit; Team and Growth include the same allowance, then charge $2 per million additional records. Collection interval is the main lever: scraping every 30 seconds instead of every 10 cuts volume by two thirds, and for most host metrics changes nothing you would have acted on.
Get started with 10 million free spans, logs, and metrics per month. No credit card required.