Datadog Logsをざっくりキャッチアップ

はじめに

この記事は OPENLOGI Advent Calendar 2022 21日目の記事です。

弊社ではDevopsにDatadogを導入しておりまして、日々SREチームの方々が様々な可視化・アラートなどの導入を進めてくださっています。

Datadogは非常に多機能でドキュメントもボリュームがあり、それ故に中々使いこなせないとか、どこから始めたらいいのか・・という感じでキャッチアップが大変な印象があります（個人の感想です）。本記事ではまずはログ監視からということでDatadog Logsの概要をキャッチアップしていきたいと思います。

なお、弊社が活用しているDatadogの機能の事例については、弊社のさださん・・もとい @moaikids さんが先日記事を公開されているのでそちらをご覧いただければと思います。

Datadog Learning Centerについて

Datadogでは公式ドキュメントの他に、テーマ毎にハンズオン形式で学習できるLearning Centerというコンテンツが用意されています。
コース中はテスト用のDatadogアカウントが発行され、仮想コンソールから架空のアプリにDatadogを導入したり、実際にDatadogが稼働している状態で画面を操作するなど、実践に近い形で学習することができます。

まずは Introduction to Log Managementというコースの内容を元に、Log Explorer 画面を使ったログ確認の概要を見ていきたいと思います。

Log Explorer

Overview

こちらが Log Explolerの画面です。よく見るやつ。大体こんなことができます（雑）。
いくつか具体的に見ていきます。（なお、画像はLearning Centerの架空のアプリのものです）

ログの検索

画面上部の検索バー（Search Query）から検索します。

基本的な使い方としては、

• 普通に文字列を入力すると、CONTENTをその文字列で検索できます。複数の単語をダブルクォートで囲むこともできます。
• 属性とその値を指定することもできます。例えば @host:65202b3d17f2 のような記法で指定します。ワイルドカードとして*なども使えます。
  • また、画面左側のFacets から指定しても同様の指定ができます。
• 上記のようにこれらを組み合わせることもできます。

詳しい記法は公式をご覧ください。 https://docs.datadoghq.com/ja/logs/explorer/search_syntax/

Facets

検索条件に関連してFacetsという概念があります。ログのパラメータに対して作成することで、そのパラメータをフィルタや検索に利用できるようになるものです。
画面左側の一覧からポチポチ押して検索条件に指定することができます。

HostやServiceなど基本的にパラメータはデフォルトでありますが、アプリの要件に応じた任意のパラメータ（userId、各種リソースのIDとか）に対してFacetを作成することもできます。

ログ詳細（Log Side Panel）

ログをクリックするとその詳細が確認できます。メッセージの内容や、パラメータがビジュアライズされて表示されています。
Event Attributesとして見えているパラメータはログからパイプラインという機能によってパース・加工された属性が表示されています。

そのログに関連付けられているAPMの情報がある場合、Traces タブを選択すると処理時間の内訳などを細かく確認することができます。

グルーピング

様々な情報でログをグループして、傾向を掴んだりすることができます。
大まかな種類として Field、 Pattern、 Transaction によるグルーピングを行うことができます。

Fieldによるグルーピング

ログのField（属性）によるグルーピングです。SQLの GROUP BY句のようなものと考えると分かりやすいと思います。
簡単な例では、 Service フィールドによってグルーピングしたログの数を円グラフとして表示したりできます。

Patternによるグルーピング

対象のログをメッセージのパターン別に集計することができます。
ドキュメントによるとノイズとなるパターンの検出、フィルタリングに役立つ、とのことです。
パターン化は自動的にやってくれるので、サクッとパターン毎の数など傾向を知りたいときに便利そうです。

リストのパターンをクリックすると条件となったパターンの内容や、実際のログの一覧や件数などが確認できます。
また右上のShow Parsing Rule をクリックすると、ログパイプラインの機能でこのログをフィルタするためのルールが確認できます。

Transactionによるグルーピング

複数のログを横断した、一連のログの集合（トランザクション）の分析を行うことができます。
例えば複数のサービスから投げられた各種ログについて、リクエストの単位でグルーピングする、といったことができます。
Group Byの条件に例えばRequestIdのような、トランザクション毎に一意な値を指定することで利用できます。

この画面では各Transactionの内訳、最大SEVERITYや全体の実行時間などが確認できます。

Log Explorer については以上です。

ログがDatadog Logsに積まれるまで

Log Explorerの見方が何となく分かったところで、そもそもDatadogに送信された各サービスのログがどのように処理されてここで確認できる状態になるのか、というのも簡単に見ていきたいと思います。

Logs > Configulation の画面では、Datadogに送信されたログがどのように加工されているかの確認・設定を行うことができます。

この画面中から、加工処理である下記の2つを見ていきます。

• Preprocessing for JSON logs
• PIPELINES

Preprocessing for JSON logs

ログがJSON形式の場合は、JSONログのフィールド名と、Datadog Logsがあらかじめ定義している主要な属性(attribute)とのマッピングを自動的に行います。

マッピングは下記のように定義されていて、クリックすると確認・変更することが可能です。

PIPELINES

ここではパラメータの抽出や加工処理により、例えばJSONでないログからパラメータをkey-valueの形で抽出したり、そのパラメータを正規化したりすることで、Log Explorerで各パラメータが表示できるようにしていきます。

PIPELINEの定義は各サービス（nginxとか、elbとか）のログ毎に必要です。ただ、Datadogが提供するSDKを利用して収集したログなどについてはインテグレーションパイプラインといって既製のパイプラインが設定されています。これはパイプラインの右側にジグソーパズルのマークがついていることで確認できます。

自前で定義する場合は、まずPipelineを定義し、その中に具体的な処理を行うProcesserを複数定義していくという流れになります。

Processorは色々と種類があります。

大まかに分類すると下記になります。

• Parser
  • メッセージからパラメータを抽出する処理
• Remapper
  • パラメータ名を変換する処理。特にログステータスや日付、サービスなど重要なパラメータには専用のリマッパーが用意されています
• Processer
  • 特定の条件に応じてパラメータを追加するような処理

nginxのパイプラインの例で、下記のProcessorをピックアップして見ていきます。

Grok Parser

JSON形式でないログに対して、Grokという所定の書式でルールを定義することでログのフィルタやパラメータの抽出を行うパーサです。

公式ドキュメントのシンプルな例で見ていきます。ログのサンプルとルールを記述していきます。
抽出したいパラメータは %{データ型:キー名} のように記述します。

そうすると画面の下のほうでサンプルに対するパース結果が確認できます。

またHelper Rules という機能があって、ルール定義を切り出して再利用したりすることもできます。先程のルールにてconnected on 11/08/2017 の部分を connected_date というHelper Rule に切り出すと下記のように書くことができます。

NginxのGrok Parserは下記のようになっています。
まずは対象となるログサンプルです。

上記のログからパラメータを抽出するルール定義（難しい）と、その結果抽出できたパラメータが表示されています。

Category Processor / Status Remapper

次に、下記のようなログステータスがどのように定義されるかを見ていきます。

Nginxのパイプラインでは、最後に定義されている2つのProcessor(Category Processor / Status Remapper)が関連する処理をしています。

まず、Category Processor では、 http.status_code の値に対して、対応した http.status_category を定義します。
status_codeが200 ~ 299だったらOK、といった具合です。
ここでhttp.status_code は上述のGrok Parserにて生ログから抽出されているパラメータです。

次にStatus Remapper により、http.status_category の値が、ステータス表示にマッピングされます。
これは専用のログステータスリマッパー が用意されていて、WARNだったら黄色で表示してくれるといった動作になります。

という感じで一例ではありますが、Log Explorer上の表示はこのようにごにょごにょ加工された結果なんだな〜というイメージがわけばいいかなと思います。

感想

ざっくり見ていきましたが、やはりこの手のツールのキャッチアップは実際に触ってみることが一番良いと思います。Learning Centerはかなり実践に近い形での学習方法を提供してくれているので今後積極的に活用していきたいところです。

また、実践でもたまに触りたいと思いつつ、必要がないと触らない、ということになりがちなので、運用業務や実装の改善などで意識的に活用していきたいと思っています。参考になるところがあれば嬉しいです。