Grok パーサー
Grok パーサーとは、名前付きのパターンを並べた規則でログの本文を読み、日時やレベル、処理時間などを属性として切り出す Datadog のログプロセッサーのこと。純粋な正規表現より短く読みやすい構文で、切り出した属性はそのまま検索と集計に使える。
概要
Grok パーサーは、ログパイプラインの中で平文のログ本文から属性を切り出すプロセッサーです。JSON 形式のログは Datadog が自動で解析するため、対象になるのはアプリケーションの平文ログや Web サーバーのアクセスログのような半構造化テキストです。規則は %{マッチャー:属性名:フィルター} という 3 要素の組み合わせで書き、マッチャーが「何が来るか」を、属性名が「どこへ入れるか」を、フィルターが「どう整えるか」を表します。気にするのは、切り出したはずの属性で検索できない、数値のはずの値が文字列として扱われる、日時が取れないといった場面で、規則の評価順と型の決まり方を知っていれば原因を絞れます。
正規表現に名前を付けて読みやすくした切り出しの規則
Grok パーサーは、ログパイプラインを構成するプロセッサーの一つで、ログ本文から属性を取り出す役目を持ちます。公式ドキュメントは、JSON 形式のログは自動で解析され、それ以外の形式には Grok パーサーで属性を付け足すと説明し、その構文は正規表現より容易だと位置づけています (2026 年 9 月時点・出典: Parsing)。規則は %{MATCHER:EXTRACT:FILTER} の形で書きます。たとえば john connected on 11/08/2017 という 1 行を考えます。%{word:user} connected on %{date("MM/dd/yyyy"):date} を当てると、user に john が、date に Unix タイムスタンプになった日時が入ります。正規表現の \b\w+\b を word の一語で済ませているわけです。プロセッサーの並べ方はログパイプラインの項に任せます。
マッチャー - 何が来るかを名前で言う
規則の中心はマッチャーです。切り出したい場所に「ここには単語が来る」「ここには数が来る」と宣言し、その部分を属性名へ送ります。公式ドキュメントに載っている主なものを挙げます。
| マッチャー | 一致するもの | 補足 |
|---|---|---|
word | 英数字と _ からなる 1 語 | 正規表現の \b\w+\b に相当 |
notSpace | 次の空白までの文字列 | 記号を含む値を取るときに使う |
integer / number | 整数 / 小数 | 数値型として解析される |
data | 空白や改行を含む任意の文字列 | .* に相当。他が合わないときに使う |
date("pattern") | 指定した書式の日時 | Unix タイムスタンプに変換される |
regex("pattern") | 任意の正規表現 | 名前付きパターンで表せないときの逃げ道 |
読み分けの要点は word と notSpace と data の 3 つです。word は英数字と下線しか受けないので、ハイフンや記号を含むサービス名は notSpace で取ります。data は空白も改行も飲み込むため、行末のメッセージ本文のように「残り全部」を受ける場所に限って使うと、他の属性を巻き込みません。ほかに IP アドレスやホスト名、ポート番号、UUID を受ける専用のマッチャーも用意されています (2026 年 9 月時点)。
フィルターで型と形を整える
3 つ目の要素であるフィルターは、一致した文字列を後処理する部品です。integer と number は値を数値型に変え、boolean は真偽値に、nullIf("value") は指定した値を null に変えます。lowercase / uppercase は大文字小文字を揃え、scale(factor) は数値に係数を掛けます。ほかに json や keyvalue、csv のように形式ごと構造化するものもあります (2026 年 9 月時点・出典: Parsing)。実務で効くのは型の決まり方です。処理時間を %{notSpace:duration} で取ると文字列になり、大小の比較や平均が計算できません。%{integer:duration} か %{number:duration} で数値にしてからファセットのメジャーとして登録すると、範囲検索と集計が使えます。
複数の規則を並べたとき、どれが効くか
1 つの Grok パーサーには規則を複数書けますが、1 件のログに一致するのは 1 つだけで、上から順に最初に一致した規則が解析を行います。各規則は自分より上に定義した規則を参照でき、規則名は同じパーサー内で一意にし、英数字と _ と . だけで英数字から始めます (2026 年 9 月時点・出典: Parsing)。見落としやすいのは、規則がログ全体に一致しなければならない点です。行の先頭から末尾まで説明し切る必要があるので、前半だけ書いた規則は一致しません。空白の大きな隙間や改行は \s+ と \n で受けます。共通部分が多いときは、ヘルパー規則として user や server のような部品を先に定義し、本体の規則から %{user} の形で呼び出せます。既定では message 属性を解析しますが、Extract from の設定で command.line のような別の属性を対象にすることもできます。
検索画面の Grok は取り込み時の Grok の一部だけ
Grok は取り込み時のプロセッサーとしてだけでなく、Log Explorer の計算フィールドとしてクエリ時にも使えます。ただしクエリ時に使えるマッチャーは data / integer / notSpace / number / word の 5 種だけです。フィルターも number と integer の 2 種に限られると公式ドキュメントが明記しています (2026 年 9 月時点・出典: Parsing)。日時の解釈や JSON の展開、キーバリューの分解は取り込み時にしかできないということです。調査の最中に「この値で絞りたい」と思い立ったとき、単純な切り出しなら検索画面で済み、型や形の変換が要るならパイプラインの Grok パーサーに規則を足してから届くログを待つ、という判断になります。ログ管理を導入したら、日時とレベルと処理時間の 3 つだけでも先に規則を書いておくと、障害のときに検索画面で困りません。