Maxim Brown
Technical Content Writer
NGINX、Apache、AWS Elastic Load Balancing (ELB) などの技術による Web サーバーログや他のアクセスログは、アプリケーションの健全性とパフォーマンスの監視やユーザー体験を理解するのに役立つ豊富な重要業績評価指標（KPI）を提供します。これらのログから、ページを読み込むのにかかる時間、エラーの発生箇所、最もリクエストの多いアプリケーションの部分などが分かります。
詳細かつデータが豊富なログイベントを検索、分析、使用できることは、特定の問題をトラブルシュートしたり、より深い履歴分析を行う際に役立ちます。しかしたとえ小さめの環境であっても、日々大量のログイベントを生成する可能性があり、それを検索や分析ができるような方法で保存するにはコスト面でも管理面でも容易なことではありません。コストに加え、1 週間分の大量のログイベントを検索する手間も相当なものです。結果、ログを使った全体的な傾向の把握や長期間の履歴分析が難しくなります。代わりに、大量のログを取り込み、重要なものだけインデックス化し、そこに含まれる情報を使用して、長期間の傾向を追跡するため効果的な保存と使用が可能なメトリクスを生成することが理想的です。
ノイズからトレンドを見出す
高度な傾向をモニターするためにログイベントの一部（遅延や URL パスなど）のみを使うだけの場合でも、大量の Web アクセスログの保存や分析という課題が付いてまわります。代わりに、ログからメトリクスを生成すれば、使用中の環境で起きていること可視化でき問題を特定できるため、大量のログのインデックス化やそれに伴うコストという悪夢を軽減することができます。ログベースのメトリクスにより、大量のログからの不要な情報に煩わされることなく、アプリケーションのアクティビティの全体的な傾向を把握できます。
ここでは、ログを使用してアプリケーションの可視性を高めるために、ログベースのメトリクスを生成させる効率的な手法を取り上げます。具体的には、大量のログの中でモニターする情報を特定することで適切なメトリクスを作成する方法を説明します。その情報に基づき生成されるメトリクスを調べ、必要なインサイトを提供します。
モニターの対象を把握する
重要な情報をログからログベースのメトリクスに抽出する最初のステップは、追跡する KPI を決定することです。
たとえば次のような 1 つの NGINX アクセスログ（JSON 形式）から、最もモニターする価値のある属性を判断できます。
追跡する情報には次のようなものがあります。
クライアント IP
要求された URL パスとメソッド
応答ステータスコード
リクエスト処理時間
クライアントのブラウザ情報
上記の情報から、アプリケーションのパフォーマンスに関する一般的な傾向が分かります。これらログ属性からメトリクスを生成すれば、リクエストトレースおよびインフラストラクチャーメトリクスで可視化、アラート表示、関連付けすることができます。傾向をモニターするためにメトリクスを生成することで、費用がかさむログのインデックス化を回避できます。
メトリクスの生成
モニターする KPI が決めたら、ログの属性を使い必要な情報を照会できます。また他の属性をタグに変換できるため、ディメンション全体でログベースのメトリクスをフィルタリングし集計することができます。
ログからメトリクスを作成する方法は複数あり、特定のクエリと一致するログイベントの数を追跡する方法はその 1 つです。たとえば、ログのステータスコード属性を使用し、NGINX サーバー側のエラーログ（500 番台の応答コードを含む NGINX アクセスログ）の頻度をモニターするメトリクスを作成します。このメトリクスに他のログ属性（URL パスや地理的な場所など）をタグ付けすることで、大量のエラーを発生させる Web アプリケーションのエンドポイントや地域を判断することができます。
また、プレーンテキスト検索用語を使用して、特定のメッセージやフレーズを含むログを検索できます。たとえば、 login failed というフレーズを含むログを探し、失敗したログインを追跡できます。
特定の種類のログの頻度を追跡するメトリクスを作成するだけではなく、特定のログ属性の値の変化を追跡するメトリクスを生成することもできます。この例として、応答時間のモニタリングや、リクエストで送受信されたデータ量などがあります。これらのメトリクスをさまざまな方法でグループ化することで、たとえばどの URL パスまたはクライアントで最大の遅延が発生しているかを明らかにできます。
大量のログを生成する技術に対し、ログベースのメトリクスはユーザーが最も必要とするログ情報のサマリーを提供します。Datadog のような統合監視プラットフォームでは、他のメトリクスと同じ方法でそれを使用することができます。
Datadog のログベースのメトリクス
Datadog のログ処理および分析は、属性をタグとして自動的にパースすることで、ログの補完を簡単にしています。そのタグは使用中の環境で全てのソースからログをクエリするのに使えます。同じクエリを使いログベースのメトリクスを作成できるので、他のインフラストラクチャーメトリクスやトレースでダッシュボード、アラート表示、関連付けすることができます。
Datadog でログベースのメトリクスを作成
ログ分析クエリからログベースのメトリクスを作成するには、グラフから新しいメトリクスの生成オプションを選択します。
Datadog アプリの場合は、ログコンフィギュレーションセクションのメトリクスを生成タブに移動して、新しいクエリを作成します。ログから生成したメトリクスはすべて、Datadog のアカウントにカスタムメトリクスとして表示されます。
他のメトリクスと同様に、Datadog はログベースのメトリクスを完全な粒度で 15 か月間保存します。つまり、通常数日から長くても数週間しか保存されないログイベントとは異なり、情報を履歴分析のために保持できるため、長期的な傾向を追跡し、異常の検出や予測に利用できます。また、メトリクスは SLI としても使用できるので、重要な組織の SLOs をモニターすることができます。
メトリクス形式のデータに長期間簡単にアクセスできるため、インデックス化するログの数を限定でき、ログの保管コストを削減しながら傾向に関する可視性を保つことができます。
選択的にインデックス化
ここまでで、収集した全てのログにインデックス付けすることなく、ログベースのメトリクスによりシステム内の傾向をモニターできることをお分かりいただけたと思います。ただし、ログからメトリクスを生成している場合でも、ログの一部をインデックス化する必要はあります。それにより、たとえばリクエストトレースとログを関連付けるなどの方法で問題の背景を把握することができるからです。
Datadog の除外フィルターは、収集したログの内どれをインデックス化するか制限します。Log Patterns ビューでログをグループ化し、どのログソースが最も多くのイベントを発生させるかを追跡できます。これにより、除外フィルターを適用するログの種類を特定できます。
上記の例では、大量の NGINX ログが収集され、その多くでリクエストは正常に記録されています。フィルターを作成すれば、Datadog はその 1% のみをインデックス化します。
Datadog はフィルターが適用される前にメトリクスを生成するため、すべてのログイベントをインデックス化するかにかかわらず、完全なデータポイントを追跡できます。
Datadog の Logging without Limits™ は、インデックス化しなかったものを含むすべてのログをアーカイブします。後になって根本原因の分析やトラブルシューティングする必要が出てきた場合、Datadog の Log Rehydration™ によりコールドストレージから簡単にログを取得できるため、ダッシュボードに照会、検索、追加することができます。
はじめましょう
NGINX、ELB、Apache からのような大量のログの場合、ログベースのメトリクスは保存や保持に関する問題を解決しながらも貴重な情報を取り出すのに最適な方法です。ログベースのメトリクスがあれば、毎日作成される大量かつ不要なログイベントをインデックス化するコストに煩わされることなく、一般的な傾向を可視化することでインフラストラクチャーのインサイトを得ることができます。
ログコンフィギュレーションのメトリクスの生成 タブにアクセスして、Datadog でログからメトリクスを作成しましょう。詳細は、ドキュメントをご覧ください。 Datadog を初めてご利用になるお客様は、14 日間の無料トライアルをご利用いただけます。
