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: