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

# はじめに
この記事は [OPENLOGI Advent Calendar 2022](https://qiita.com/advent-calendar/2022/openlogi) 21日目の記事です。

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

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

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

https://qiita.com/moaikids/items/fbd727566bca68a475cc

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

![Introduction_to_Log_Management_-_The_Datadog_Learning_Center.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/180075/d28b9703-55df-26d8-ad6d-dfb79a6961b5.jpeg)

まずは [Introduction to Log Management](https://learn.datadoghq.com/courses/take/intro-to-log-management/texts/35664916-lab-setting-up-logging-and-log-collection)というコースの内容を元に、`Log Explorer` 画面を使ったログ確認の概要を見ていきたいと思います。

# Log Explorer

## Overview

こちらが `Log Exploler`の画面です。よく見るやつ。大体こんなことができます（雑）。
いくつか具体的に見ていきます。（なお、画像はLearning Centerの架空のアプリのものです）
![Log_Explorer___Datadog.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/180075/85f3900b-7ef4-4dc0-f4d8-d013826b88c1.jpeg)

## ログの検索
画面上部の検索バー（Search Query）から検索します。
![Log_Explorer___Datadog.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/180075/4ddb3627-f14f-8d6d-0e96-b37c0dc9e323.jpeg)

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

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

### Facets
https://docs.datadoghq.com/ja/logs/explorer/facets/

検索条件に関連してFacetsという概念があります。ログのパラメータに対して作成することで、そのパラメータをフィルタや検索に利用できるようになるものです。
画面左側の一覧からポチポチ押して検索条件に指定することができます。
![Log_Explorer___Datadog.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/180075/cf916f34-b00d-c0a2-5440-36b8cb471a80.jpeg)

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

## ログ詳細（Log Side Panel）
ログをクリックするとその詳細が確認できます。メッセージの内容や、パラメータがビジュアライズされて表示されています。
`Event Attributes`として見えているパラメータはログからパイプラインという機能によってパース・加工された属性が表示されています。
![Log_Explorer___Datadog.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/180075/f2515a4e-e2f7-b40a-88ab-1c4f31640129.jpeg)

そのログに関連付けられているAPMの情報がある場合、`Traces` タブを選択すると処理時間の内訳などを細かく確認することができます。
![Log_Explorer___Datadog.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/180075/8d0e1651-e091-e0ef-000a-138f851a7c96.jpeg)

## グルーピング
様々な情報でログをグループして、傾向を掴んだりすることができます。
大まかな種類として `Field`、 `Pattern`、 `Transaction` によるグルーピングを行うことができます。
![Log_Explorer___Datadog.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/180075/47020fda-98b0-5c57-15cf-20b20f35e356.jpeg)

### Fieldによるグルーピング
ログのField（属性）によるグルーピングです。SQLの `GROUP BY`句のようなものと考えると分かりやすいと思います。
簡単な例では、 `Service` フィールドによってグルーピングしたログの数を円グラフとして表示したりできます。
![Log_Explorer___Datadog.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/180075/6a46c4b1-f7c0-9b38-f325-780c6826e78d.jpeg)

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

![Log_Explorer___Datadog.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/180075/d163ac74-a1d7-2903-7465-95902ad0d288.jpeg)

リストのパターンをクリックすると条件となったパターンの内容や、実際のログの一覧や件数などが確認できます。
また右上の`Show Parsing Rule` をクリックすると、ログパイプラインの機能でこのログをフィルタするためのルールが確認できます。
![Log_Explorer___Datadog.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/180075/0bad8693-4832-3541-5a04-f43e8c12274e.jpeg)

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

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

![Log_Explorer___Datadog.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/180075/ce01593e-1054-13c7-d318-7c4019b94acc.jpeg)

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

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

`Logs > Configulation` の画面では、Datadogに送信されたログがどのように加工されているかの確認・設定を行うことができます。
![スクリーンショット_2022-12-16_16_33_18.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/180075/9561ae66-4880-a517-5ef2-90beaf689912.jpeg)

この画面中から、加工処理である下記の2つを見ていきます。
- `Preprocessing for JSON logs`
- `PIPELINES`

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

マッピングは下記のように定義されていて、クリックすると確認・変更することが可能です。
![Log_Pipelines___Datadog.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/180075/5d878eda-0020-f8c4-e3f9-a40a4b9d1fa3.jpeg)

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

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

自前で定義する場合は、まず`Pipeline`を定義し、その中に具体的な処理を行う`Processer`を複数定義していくという流れになります。
![Log_Pipelines___Datadog.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/180075/37c22e7c-bd95-e4ed-9e8a-e6e1e8c519f9.jpeg)
`Processor`は色々と種類があります。

https://docs.datadoghq.com/ja/logs/log_configuration/processors/

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

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

![Cursor_と_Log_Pipelines___Datadog.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/180075/e790e324-26dc-3ca5-6450-b3e62a90da2a.jpeg)

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

[公式ドキュメント](https://docs.datadoghq.com/ja/logs/log_configuration/parsing/)のシンプルな例で見ていきます。ログのサンプルとルールを記述していきます。
抽出したいパラメータは `%{データ型:キー名}` のように記述します。

![Log_Pipelines___Datadog.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/180075/b7c93cdb-8fff-7961-6ec4-bbe2da815819.jpeg)

そうすると画面の下のほうでサンプルに対するパース結果が確認できます。
![Log_Pipelines___Datadog.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/180075/525b7b3a-3855-e090-33c0-5bef5bad5524.jpeg)

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

![Log_Pipelines___Datadog.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/180075/0c278e54-3430-c010-f4f7-969373352eaa.jpeg)

NginxのGrok Parserは下記のようになっています。
まずは対象となるログサンプルです。
![Log_Pipelines___Datadog.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/180075/9deac49d-ebe2-fa91-f4a7-43d04e69ca97.jpeg)
上記のログからパラメータを抽出するルール定義（難しい）と、その結果抽出できたパラメータが表示されています。
![Log_Pipelines___Datadog.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/180075/e3391735-b215-80a5-dba1-e17a265c4c48.jpeg)

### Category Processor / Status Remapper
次に、下記のようなログステータスがどのように定義されるかを見ていきます。
![Cursor_と_Log_Explorer___Datadog.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/180075/8f4e97e1-8356-6483-45fd-ed696aaa5364.jpeg)
Nginxのパイプラインでは、最後に定義されている2つのProcessor(`Category Processor` / `Status Remapper`)が関連する処理をしています。
![Cursor_と_Log_Pipelines___Datadog.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/180075/6f7d872f-a216-58a6-d17b-a788b270d831.jpeg)


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

![Cursor_と_Log_Pipelines___Datadog.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/180075/4bcfd45e-548e-d28d-7c9b-e25534d9af6e.jpeg)

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

![Cursor_と_Log_Pipelines___Datadog.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/180075/2df54309-70bd-cf2a-b08c-f3b8cf77a55e.jpeg)

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

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

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