Logfire Infrastructure

Monitor Infrastructure with Logfire

Do not use this skill for application-level traces, logs, or AI/agent spans — that's logfire-instrumentation. The two compose: a full setup often runs both.

How This Works

The OpenTelemetry Collector ships host, container, cluster, and infrastructure-service metrics to Logfire with no application code changes — Logfire is a fully compliant OTel backend and ingests standard OTLP traces, logs, and metrics from it (one narrow exception noted in the collector reference), so the Collector is the entire mechanism. This is optional and is an advanced tool: if the user only wants their app's own traces, logfire-instrumentation's language SDKs are enough on their own.

Step 1: Authenticate and Select the Exact Project

Do not open, read, or run any infrastructure config file (docker-compose.yml, a Kubernetes manifest, or similar) until whoami confirms you're authenticated to the right project — nothing about this step requires knowing what's being monitored. Auth is also the one step that can block on a human (browser sign-in), so starting it first means that wait begins on turn one, not after Step 2's detection work.

Use Authenticate and Select the Exact Project to derive the CLI target from the supplied Logfire URL and run its target-aware whoami check with a verified CLI path — for JS/TS projects without uv, use the external-prefix npm fallback instead of plain npx, which can execute a repository-local binary. Skip to Step 2 if that already reports the right project and resolved --region or --base-url target; otherwise, continue through the full authentication and project-selection sequence there, including its safe handoff for the write credential created by projects use.

Step 2: Identify What to Monitor

Detect the infrastructure actually in play, don't assume:

• Host/VM: monitoring the machine itself (CPU, memory, disk, network, load).
• Docker: read docker-compose.yml / Dockerfiles for running containers.
• Kubernetes: look for manifests, a kubeconfig, or kubectl context.
• Database/queue/cache servers: read docker-compose.yml / pyproject.toml / package.json for Postgres, MySQL, Redis, MongoDB, Kafka, RabbitMQ, Nginx, Apache, Elasticsearch, or Memcached.
• Cloud provider: GCP or AWS metrics (Cloud Monitoring, CloudWatch, ECS), when the user names the provider or the app clearly runs there.

More than one can apply at once — a single Collector can run multiple receivers in parallel pipelines.

Step 3: Configure the Collector

Follow the collector reference for the receiver(s) identified in Step 2 — it covers the shared exporter setup, then a dedicated section per source: host metrics, Docker, Kubernetes, database/queue/cache servers, and cloud-provider metrics, each with the exact receiver name, a working config, and the caveats that actually bite (Docker socket permissions, API version pinning, host.docker.internal vs localhost, IAM permissions, ADOT vs. Contrib collector images).

Set the same service & resource metadata conventions the collector reference describes — host.name, service.name, service.instance.id — so data groups correctly across the Hosts, Kubernetes, and Metrics pages.

Before starting or restarting the Collector, validate the config file — a receiver typo or bad indentation should surface as a validation error, not a Collector that starts, logs nothing useful, and silently drops the pipeline:

otelcol-contrib validate --config=collector-config.yaml
# or, for the core (non-Contrib) distribution: otelcol validate --config=...

If neither binary is on PATH, inspect the running Collector container (for example with kubectl exec) or use the deployment-specific validation command from the image entrypoint, systemd unit, or Helm chart. docker compose config or kubectl get pod <name> -o yaml can show the command when it is explicitly configured.