Observability

OpenTelemetry実践導入ガイド：ログ・メトリクス・トレース統合を90日で定着させる 「監視は入れているのに障害原因の特定が遅い」。この状態は、たいていデータが足りないのではなく、データが分断されていることが原因です。メトリクスは見える、ログは別画面、トレースは導入途中、という構成だと、オンコールは毎回同じ調査を手作業で繰り返すことになります。 OpenTelemetry（OTel）はこの分断を減らすための共通規格です。ただし、導入に失敗するチームも少なくありません。理由は単純で、「計測の追加」だけやって「運用設計」を後回しにするからです。 本記事では、OpenTelemetry を 90 日で現場定着させるための、実務寄りの導入手順を紹介します。 1. まず決めるべき運用目標 OTel を入れる前に、次の問いに答えます。 どの障害をどれだけ早く見つけたいか どのサービスの MTTR をどれだけ下げたいか どのチームがトリアージ責任を持つか たとえば「API 5xx の原因調査を 60 分 → 15 分に短縮する」と明文化すると、必要な計測が決まります。逆に目標がないと、span を増やす作業が目的化して終わります。 2. 参照アーキテクチャ 本番で扱いやすい最小構成は次です。 アプリケーションに OTel SDK を導入 エージェント/サイドカー経由で OTel Collector に送信 Collector で加工・サンプリング・ルーティング Prometheus / Loki / Tempo（または商用基盤）へ出力 Collector を中継に置く理由は、アプリ側の再デプロイなしでルール変更できるからです。運用現場ではここが非常に効きます。 3. サービス命名規則を最初に固定する 命名規則を後で直すと、ダッシュボードとアラートが壊れます。以下は最低限のルール例です。 service.name: domain-service-env（例: billing-api-prod） deployment.environment: prod|stg|dev service.version: Git SHA または semver cloud.region: 実リージョン名 この 4 つが揃うと、障害時に「どの環境・どのバージョン」が悪いか一気に絞れます。 4. Pythonサービス計測の実装例 FastAPI を例に、最小導入手順を示します。 1 2 3 4 pip install opentelemetry-distro \ opentelemetry-exporter-otlp \ opentelemetry-instrumentation-fastapi \ opentelemetry-instrumentation-requests 起動時に auto-instrumentation を有効化します。 ...

LLM運用の可観測性を実装する：OpenTelemetryでつくるPrompt/Token/Latency監視の実践 LLMアプリは「動く」だけでは本番品質になりません。運用を始めると、次のような問題が必ず発生します。 昨日まで 1.2 秒だった応答が突然 4 秒台になる コストが月末に急増したが、どの機能が原因かわからない 回答品質が落ちたと言われるが、どのプロンプト変更が影響したか追えない リトライ回数や外部API待ちの偏りが可視化されていない この課題を解く鍵が「可観測性（Observability）」です。本記事では OpenTelemetry を軸に、LLM アプリの監視をゼロから構築する実装を、実際に運用で使える粒度で説明します。 なぜ APM だけでは LLM を見切れないのか 従来の Web アプリ監視（CPU、HTTP レイテンシ、エラーレート）だけでは、LLM 特有の故障点が見えません。理由は、LLM の品質とコストが「入力テキスト」と「推論設定」に強く依存するためです。 少なくとも次の軸が必要です。 Prompt 可視化: システム/ユーザー/ツール呼び出しの構成 Token 可視化: input/output token、モデル別単価、キャッシュヒット率 推論経路可視化: retrieval → rerank → generation の各ステップ時間 品質シグナル: hallucination 率、参照文書一致率、ユーザー評価 つまり、HTTP 1 本のログでは不十分で、トレース単位で LLM 実行を分解する必要があります。 アーキテクチャの全体像 最初に、実装対象を次の構成とします。 API: FastAPI LLM: OpenAI / Azure OpenAI（抽象化） RAG: pgvector + reranker Observability: OpenTelemetry SDK + OTLP Exporter + Grafana Tempo/Loki/Prometheus 処理フローは次の通りです。 ...