監視と可観測性: APM、ロギングとアラートのベスト プラクティス

Splunk の State of Observability レポートによると、成熟した可観測性を実践している企業は、インシデントを 69% 早く解決します。 監視すると、何かが壊れていることがわかります。可観測性により、壊れた理由とどこを見るべきかがわかります。すべての運用上の問題を何時間もかけて対処するか、数分で解決するかの違いは、システムをどのように装備し、ログを構造化し、アラートを設計するかによって決まります。

重要なポイント

• 可観測性の 3 つの柱であるメトリクス、ログ、トレースは、それぞれ異なる質問に答え、連携してシステムを完全に理解します。
• 症状（ユーザー側への影響）に関するアラートは、アラート疲労を軽減し、新たな障害モードを検出する原因（内部指標）ではない
• 相関 ID を使用した構造化された JSON ログにより、サービス全体の検索とリクエスト フローの再構築が可能になります
• SLO (サービス レベル目標) により、監視が「何か壊れていないか」から「ユーザーへの約束を果たしているか」に変わります。

---

可観測性の 3 つの柱

可観測性は 3 つの相補的なデータ型に基づいて構築されています。各柱は、システムの動作に関するさまざまな質問に答えます。

メトリクス

メトリクスは、一定の間隔で収集される数値測定値です。彼らは「何が起こっているのか」という質問に答えます: 1 秒あたりのリクエストの数は何ですか?平均応答時間はどれくらいですか?使用されているメモリの量はどれくらいですか?

特徴:

• 集約されコンパクト -- 数百万のイベントが時系列カウンターに圧縮されます
• 保存コストが安い -- トラフィック量に関係なく固定サイズのデータ
• ダッシュボードやアラートに最適
• 限定されたコンテキスト -- 応答時間が増加したことはわかっていますが、どのリクエストが遅いかはわかりません。

主要な指標タイプ:

• カウンタ -- 単調増加する値 (リクエストの合計、エラーの合計)
• ゲージ -- 上下する値 (現在の CPU 使用率、アクティブな接続)
• ヒストグラム -- 値の分布 (応答時間のパーセンタイル、ペイロード サイズ)
• 概要 -- クライアント側で事前に計算されたパーセンタイル

ログ

ログは、個別のイベントのタイムスタンプ付きテキスト記録です。 「何が起こったのか」という質問に答えます。ユーザーにはどのようなエラー メッセージが表示されましたか?失敗した関数にはどのようなパラメータが渡されましたか?問題が発生したとき、システムはどのような状態でしたか?

特徴:

• 豊富なコンテキスト -- 個々のイベントに関する任意の詳細
• 大規模化すると高価 -- 高トラフィック システムでは 1 時間あたりギガバイトのログが生成されます
• 検索可能 -- 全文検索で特定のイベントを検索します
• 構造が必要 -- 構造化されていないログ行は解析や関連付けが困難です

トレース

トレースは、複数のサービスにわたる単一のリクエストに従います。彼らは、「どこに時間がかかっているのか」という質問に答えます。どのサービス呼び出しが遅いですか?リクエストのパスはどこで分岐しますか?どのデータベース クエリがボトルネックになっていますか?

特徴:

• 因果関係の表示 -- 操作間の親子関係
• 分散システムの動作を明らかにします -- サービス境界を越えた遅延
• 大規模なサンプリングが必要 -- すべてのリクエストをトレースするとコストがかかる
• マイクロサービスに不可欠 -- トレースがなければ、マルチサービス フローのデバッグは推測に頼ることになります。

---

可観測性ツールのエコシステム

スタックの選択

成長中のほとんどのビジネスでは、次のことから始めることをお勧めします。

1. エラー追跡用の Sentry -- フルスタック トレース、ソース マップ、リリース追跡で例外をキャッチします。
2. メトリクス用の Prometheus + Grafana -- オープンソース、実戦テスト済み、広範な統合エコシステム
3. マネージド サービスへの構造化ログ -- クラウド プロバイダーに応じて、Datadog Logs、AWS CloudWatch、または Grafana Loki
4. インストルメンテーション用の OpenTelemetry -- あらゆるバックエンドで動作するベンダー中立の標準

単一ベンダーを必要とするチームにとって、Datadog は最高のオールインワン エクスペリエンスを提供しますが、大規模化すると大幅なコストがかかります。 Grafana のオープンソース スタック (Prometheus、Loki、Tempo) は、より低いライセンス コストで同等の機能を提供しますが、運用上の負担は大きくなります。

---

構造化ログのベスト プラクティス

Error processing order 12345 for user [email protected] のような非構造化ログ行は、人間には判読可能ですが、マシンには敵対的です。構造化された JSON ログにより、特定のフィールドでの検索、フィルタリング、集計、アラートが可能になります。

ログ構造

すべてのログ エントリには次のものが含まれている必要があります。

相関 ID

相関 ID は、各リクエストの開始時に生成される一意の識別子で、すべてのダウンストリーム サービス呼び出し、データベース クエリ、およびバックグラウンド ジョブに渡されます。問題を調査する場合、相関 ID で検索すると、すべてのサービスにわたるその特定のリクエストに関連するすべてのログ エントリが表示されます。

実装: API ゲートウェイまたはロード バランサーで UUID を生成し、それを X-Request-ID ヘッダーに渡し、すべてのログ エントリに含めます。 NestJS では、相関 ID を抽出または生成し、それを非同期ローカル ストレージ コンテキストに保存するミドルウェアを使用します。

ログレベル

ログ レベルを一貫して使用します。

• DEBUG -- 詳細な診断情報。アクティブにデバッグしない限り実稼働環境では無効になっています。
• 情報 -- 重要なビジネス イベント (注文、ユーザー登録、支払い処理)
• 警告 -- システムが処理したが調査が必要な予期せぬ状況 (再試行の成功、キャッシュミス、非推奨の API 呼び出し)
• エラー -- ユーザー エクスペリエンスに影響を及ぼした障害 (リクエストの失敗、支払いの拒否、外部サービスの利用不可)
• 致命的 -- アプリケーションは続行できません (データベースに到達できない、必要な構成がありません)

ログの保存とコスト管理

ログは、保存するのに最もコストがかかる可観測性データです。段階的な保持を実装します。

• ホット ストレージ (30 日間) -- 全文検索可能、高速クエリ、高コスト
• ウォーム ストレージ (90 日) -- 圧縮され、クエリは遅くなり、コストは中程度です
• コールド ストレージ (1 年以上) -- アーカイブ、クエリオンデマンド、低コスト
• デバッグ ログ -- 積極的にトラブルシューティングを行う場合を除き、本番環境には保存しないでください。

---

アラートのデザイン

不適切なアラートはアラート疲労を引き起こします。ほとんどが誤検知または優先度の低いノイズであるため、チームはアラートに応答しなくなります。適切なアラートは、人間の介入が必要な真の問題を明らかにします。

原因ではなく症状について警告する

症状ベースのアラート (良好): 「/api/orders のエラー率が 5 分間で 1% を超えました」 -- これは、根本的な原因に関係なく、ユーザーへの影響を直接示しています。

原因ベースのアラート (悪い): 「データベース CPU が 90% を超えました」 -- これはユーザーに影響を与える場合もあれば、影響しない場合もあります。データベースは 95% の CPU を問題なく処理する場合もあれば、50% の CPU を使用しても完全にデッドロック状態になる場合もあります。

原因ベースのメトリクスは、アラート ルールではなく、調査用のダッシュボードに属します。

アラート重大度レベル

アラートノイズの低減

1. グループ関連のアラート -- データベースがダウンした場合、それに依存するすべてのサービスから 50 件のアラートではなく、「データベースが使用不可」というアラートを 1 件受け取ります。
2. 持続的な違反が必要 -- 一時的なスパイクを避けるため、「1 秒間 CPU 90% 以上」ではなく、「CPU 90% 以上 5 分間」
3. 自動解決 -- 状態が解決されると、アラートは自動的にクリアされます。
4. 毎週のアラートの確認 -- 発生したすべてのアラートを確認し、人間のアクションを必要としないアラートを特定して修正または沈黙させます。
5. オンコール フィードバック ループ -- オンコール ローテーションごとに、エンジニアはどのアラートが実用的で、どのアラートが調整が必要かを文書化します。

---

SLO: サービス レベル目標

SLO は、監視を事後対応 (「何かが壊れた、修正する」) から予防的 (「エラー バジェットを使い果たしている、ユーザーが気づく前に調査しましょう」) に変換します。

SLO の定義

SLO は、サービスの目標信頼性を定義します。内容は以下のとおりです。

• SLI (サービス レベル インジケーター) -- 測定されるメトリック (リクエストの成功率、レイテンシのパーセンタイル)
• ターゲット -- 許容可能なパフォーマンスを定義するしきい値 (99.9% の成功率、200 ミリ秒未満の P95)
• ウィンドウ -- ターゲットが評価される期間 (ローリング 30 日)

eコマース プラットフォームの SLO の例

エラーバジェット

エラー バジェットは、SLO 目標の逆数です。 99.9% の SLO では、0.1% のエラーが許容されます。つまり、1 か月あたり約 43 分のダウンタイムになります。エラー バジェットが使い果たされると、チームは機能から信頼性の作業に焦点を移します。

エラー バジェットは、エンジニアリング チームと製品チームの間で共通の言語を提供します。サービスが「十分に信頼できる」かどうかを議論する代わりに、両チームはエラー バジェットがどのくらい残っているかを正確に確認し、新機能のリリースと安定性への投資についてデータに基づいた決定を下すことができます。

---

よくある質問

可観測性を大規模に実現するにはどれくらいのコストがかかりますか?

可観測性のコストは、オープンソース スタック (Prometheus、Grafana、Loki) の場合はホストあたり月額 10 ～ 50 ドル、商用ソリューション (Datadog、New Relic) の場合はホストあたり 30 ～ 100 ドル以上となります。最大のコスト要因はログ量です。デバッグ ログのサンプリング、保存されたログの圧縮、適切な保存期間の設定によって最適化します。サーバーが 50 台未満のほとんどの企業の場合、コストは月額 500 ～ 2,000 ドルです。

OpenTelemetry またはベンダー固有のエージェントを使用する必要がありますか?

OpenTelemetry を使用します。これはインスツルメンテーションの業界標準であり、すべての主要な可観測性ベンダーによってサポートされており、ベンダー ロックインを防ぎます。コードを再インスツルメントすることなく、バックエンドを (たとえば、Datadog から Grafana に) 切り替えることができます。ベンダー固有のエージェントは、より深い統合を提供する場合がありますが、移植性とのトレードオフを考慮する価値はありません。

NestJS アプリケーションのモニタリングを設定するにはどうすればよいですか?

NestJS では、リクエストのタイミングにインターセプターを使用し、エラー追跡に例外フィルターを使用し、相関 ID の伝播にミドルウェアを使用します。エラー追跡のために Sentry を @sentry/nestjs と統合します。 /metrics エンドポイントで公開されている prom-client ライブラリを使用して Prometheus メトリクスをエクスポートします。 JSON 出力用に構成された nestjs-pino または winston で構造化ログを使用します。

モニタリングとオブザーバビリティの違いは何ですか?

監視により、事前に定義された問題が発生した場合 (CPU 高、エラー率の上昇、ディスクがいっぱい) が通知されます。可観測性により、新しいインスツルメンテーションを導入しなくても、システムの動作について新しい質問をすることができます。システムの内部状態を外部出力 (メトリクス、ログ、トレース) から理解できる場合、システムは観察可能です。実際には、適切なモニタリングは可観測性の一部です。

可観測性への投資をチームに説得するにはどうすればよいですか?

可観測性の向上の前後で、実稼働インシデントの平均解決時間 (MTTR) を追跡します。可観測性が優れているチームは、通常、MTTR を 60 ～ 70% 削減します。 ROI を示すには、節約された時間にエンジニアリング コストを掛けます。また、モニタリングによって検出されたインシデントの数とユーザー レポートによって検出されたインシデントの数も追跡します。プロアクティブな検出により、顧客の信頼が構築されます。

---

次は何ですか

何もない場合は、エラー追跡 (Sentry) から始めてください。運用エラーを捕捉して警告することで、最も即時の価値が得られます。次に、相関 ID を使用した構造化ログを追加します。次に、Prometheus および Grafana ダッシュボードを使用してメトリクス収集を実装します。最後に、複数のサービスがある場合は分散トレースを追加します。

パフォーマンス エンジニアリングの完全なコンテキストについては、[ビジネス プラットフォームのスケーリング] (/blog/scaling-business-platform-performance) に関する柱ガイドを参照してください。監視対象のインフラストラクチャを最適化するには、インフラストラクチャ スケーリング ガイド をお読みください。

ECOSIRE は、Odoo ERP およびカスタム アーキテクチャ上で実行されるビジネス プラットフォーム用の可観測性スタックを実装します。モニタリングと可観測性の評価については、DevOps チームにお問い合わせください。

---

ECOSIRE によって発行 — Odoo ERP、Shopify eCommerce、OpenClaw AI にわたる AI を活用したソリューションで企業のスケールアップを支援します。