Pydantic Logfireを使用して、ホスト、Dockerコンテナ、Kubernetesクラスタ、データベース・キュー・キャッシュサーバー、クラウドプロバイダのメトリクス（測定データ）を監視できます。アプリケーションコードの変更は不要です。 **次のような場合に使用:** - ホスト・サーバー・仮想マシンの監視をしたい - Dockerコンテナの監視をしたい - Kubernetesクラスタの監視をしたい - インフラストラクチャメトリクスをLogfireに送信したい - データベース（Postgres、Redis、MongoDB、Kafkaなど）の監視をしたい - クラウドメトリクス（AWS、GCPなど）を収集したい - Logfireの文脈でOpenTelemetry Collectorについて述べている **注意:** このスキルはインフラストラクチャの監視専用です。アプリケーションコードのトレース・ログ・AI/エージェントスパンの計測が必要な場合は、logfire-instrumentationスキルを使用してください。
Monitor hosts, Docker containers, Kubernetes clusters, database/queue/cache servers, and cloud-provider metrics with Pydantic Logfire — no application code required. Use this skill whenever the user asks to "monitor my host/server/VM", "monitor my Docker containers", "monitor my Kubernetes cluster", "send infrastructure metrics to Logfire", "watch my database/Postgres/Redis/MongoDB/Kafka", "collect cloud metrics" (AWS/GCP), or mentions the OpenTelemetry Collector in the context of Logfire. This is infrastructure only — for instrumenting APPLICATION CODE (traces, logs, AI/agent spans) use the logfire-instrumentation skill instead.
このスキルをアプリケーション層のトレース（追跡データ）、ログ、AI/エージェント スパン（処理単位）に使用しないでください。それは logfire-instrumentation の役割です。2つは組み合わせて使う設計になっており、完全なセットアップでは通常両方を実行します。
OpenTelemetry Collector（標準的な監視ツール）は、ホスト、コンテナ、クラスタ、インフラサービスのメトリクス（測定値）を、アプリケーションコードの変更なしに Logfireに送信します。Logfireは完全に対応した OTel バックエンド（受信側システム）であり、標準的な OTLP トレース、ログ、メトリクスを受け取るため、Collector がすべての仕組みです。これはオプション機能で高度なツールです。ユーザーがアプリケーション自体のトレースだけを必要とする場合は、logfire-instrumentation の言語 SDK だけで十分です。
whoami コマンドで正しいプロジェクトへの認証を確認するまで、インフラストラクチャの設定ファイル（docker-compose.yml、Kubernetes マニフェスト、その他）を開いたり読んだり実行したりしないでください。このステップでは何を監視するかを知る必要はありません。認証は人間の操作（ブラウザでのサインイン）がボトルネックになる唯一のステップなので、これを最初に開始することで、ステップ2の検出作業の後ではなく、1ターン目から待機が始まります。
まず確認してください — uvx logfire --non-interactive whoami（JavaScript の場合: npx logfire whoami）— すでに正しいプロジェクトとリージョンが表示されていればステップ2へ進んでください。そうでない場合、完全なコマンド手順、フラグ、注意点（--non-interactive 要件、auth がなぜブラウザを開かないのか、LOGFIRE_TOKEN と認証情報ファイルの競合）、および Collector 独自の書き込みトークンの入手先については、認証とプロジェクト確認 を参照してください。
実際に使用中のインフラを検出してください。推測しないでください。
docker-compose.yml / Dockerfile を読む。kubeconfig、または kubectl コンテキストを探す。docker-compose.yml / pyproject.toml / package.json を読む。複数が同時に当てはまることもあります。単一の Collector は複数のレシーバー（受信設定）を並列パイプラインで実行できます。
ステップ2で特定されたレシーバーについて、Collector リファレンス に従ってください。共有エクスポーター（送信）設定、その後ソースごとの専用セクション（ホストメトリクス、Docker、Kubernetes、データベース/キュー/キャッシュサーバー、クラウドプロバイダーメトリクス）があり、各セクションに正確なレシーバー名、動作する設定、実際に問題になる注意点（Docker ソケットのアクセス権限、API バージョン固定、host.docker.internal vs localhost、IAM 権限、ADOT vs. Contrib Collector イメージ）が含まれます。
Collector リファレンス が説明する同じサービスおよびリソースメタデータ規約を設定してください — host.name、service.name、service.instance.id — これでデータがホスト、Kubernetes、メトリクスページ全体で正しくグループ化されます。
Collector を開始または再開始する前に、設定ファイルを検証してください。レシーバー名の誤字またはインデント不正は、検証エラーとして表面化する必要があり、Collector が開始され、有用なログが出力されず、パイプラインが静かにドロップされるべきではありません。
otelcol-contrib validate --config=collector-config.yaml
# または、コア（非Contrib）配布の場合: otelcol validate --config=...
どちらのバイナリも PATH にない場合は、実行中の Collector コンテナを検査するか（例: kubectl exec）、イメージエントリポイント、systemd ユニット、または Helm チャートのデプロイメント固有の検証コマンドを使用してください。docker compose config または kubectl get pod <name> -o yaml は、明示的に設定されている場合、コマンドを表示できます。
レシーバーの接続は、Collector がクリーンに起動したときに完了しません。単に何かが到着したことではなく、データが実際に正しいページの正しいホスト/コンテナ/クラスタに到着したことを確認してください。同じセッション内で照会せずにメトリクスが「到着した」と報告しないでください — 検証されていないもっともらしい要約は、検証できないと言うより悪いです。
host.name / コンテナ / クラスタを過去数分以内に照会してください。その正確な識別子でゼロ行を返すクエリは、ページが他の何かからデータを表示していても、それが到着しなかったことを意味します。それ以外の場合は、特定のプロダクトページ — ホスト、Docker、または Kubernetes — または データベース/キュー/キャッシュ/クラウドソース用の メトリクス エクスプローラを開き、その同じ正確な識別子を探してください。service.pipelines 下で参照されていない）、リソース属性（host.name、service.name）が設定されているか。リファレンス独自の確認セクションに完全なトラブルシューティング経路があります。先ほど確認したことから最終レポートを作成して閉じてください — whoami から org/プロジェクト/リージョン、どのレシーバーがアクティブか、検証した正確なホスト/コンテナ/クラスタ識別子。テンプレートではなく。関連ビューへの直接リンクを含めます（ソースに基づいて /hosts、/docker、/kubernetes、または /metrics）、whoami のプロジェクト URL を使用すれば、ユーザーは自分のソースが到着するのを見ることができます。どこを見ればよいかを尋ねる必要はありません。プレースホルダーを含むレポートは、上記のステップが完了していなく、スキップされたことを意味します。
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.
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.
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.
Check first — uvx logfire --non-interactive whoami (JS: npx logfire whoami) — and skip to Step 2 if it already reports the right project and region. Otherwise, full command sequence, flags, and gotchas (the --non-interactive requirement, why auth won't open a browser for you, the LOGFIRE_TOKEN-vs-credentials-file conflict) plus where the Collector's own write token comes from: Authenticate and Select the Exact Project.
Detect the infrastructure actually in play, don't assume:
docker-compose.yml / Dockerfiles for running containers.kubeconfig, or kubectl context.docker-compose.yml / pyproject.toml / package.json for Postgres, MySQL, Redis, MongoDB, Kafka, RabbitMQ, Nginx, Apache, Elasticsearch, or Memcached.More than one can apply at once — a single Collector can run multiple receivers in parallel pipelines.
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.
Wiring a receiver isn't done when the Collector starts cleanly — confirm the data actually reached the right page for the right host/container/cluster, not just that something arrived. Never report a metric as "arrived" without having queried for it in this same session — a plausible-sounding summary that wasn't checked is worse than saying you couldn't verify.
host.name / container / cluster you set in Step 3 within the last few minutes — a query that returns zero rows for that exact identifier means it didn't land, even if the page shows data from something else. Otherwise, open the specific product page — Hosts, Docker, or Kubernetes — or the Metrics explorer for database/queue/cache/cloud sources, and look for that same exact identifier.service.pipelines), and that resource attributes (host.name, service.name) are set — the reference's own Verify section has the full troubleshooting path.Close with a final report built from what you just confirmed — org/project/region from whoami, which receiver(s) are active, and the exact host/container/cluster identifier you verified — not a template. Include a direct link to the relevant view (/hosts, /docker, /kubernetes, or /metrics, based on the source) using the project's URL from whoami, so the user can see their own source arrive without having to ask where to look. A report with a placeholder in it means a step above was skipped, not finished.
原文・著作権は Anthropic および各プラグイン作者に帰属します。日本語訳は Claude API による自動翻訳です。