ども。
Datadogでログを取ってると「このログ、ぶっちゃけWARNINGでいいんだけど」みたいなのがある。
Datadogは自分でparseルールをカスタムできるので、それを利用してremapしてやるのだがそのやり方を毎回忘れる。
そして例によってわかりにくい公式ドキュメントとにらめっこしたくないので、備忘録。
- Grok Parserでremapしたい値をparseさせる
- facetを作成
- Category Processorで紐付ける
- Status Remapperで書き換える
- Piplineの順番に注意
- おわりに
- 参考
Grok Parserでremapしたい値をparseさせる
例えばこのようなサンプルログ([xxxx-xxxxx-xxxx]
は本来uuidで、文字列ではないのでルール設定時注意)
E, [2020-02-25T16:00:31.843110 #644] ERROR -- : [HogeJob] [FugaJob] [xxxx-xxxxx-xxxx] xxxxxxxxx (api connection failed):
はっきりERRORと記録されるため、賢いDatadogは自動的にERRORログ判定してくれる↓
受信したステータス値は、次のようにマップされます。
- 整数値 (0 から 7) は、Syslog の重大度標準にマップされます
- emerg または f で始まる文字列 (大文字と小文字の区別なし) は、emerg (0) にマップされます
- a で始まる文字列 (大文字と小文字の区別なし) は、alert (1) にマップされます
- c で始まる文字列 (大文字と小文字の区別なし) は、critical (2) にマップされます
- err で始まる文字列 (大文字と小文字の区別なし) は、error (3) にマップされます
- w で始まる文字列 (大文字と小文字の区別なし) は、warning (4) にマップされます
- n で始まる文字列 (大文字と小文字の区別なし) は、notice (5) にマップされます
- i で始まる文字列 (大文字と小文字の区別なし) は、info (6) にマップされます
- d、trace、または verbose で始まる文字列 (大文字と小文字の区別なし) は、debug (7) にマップされます
- o で始まる文字列または OK か Successに一致する文字列 (大文字と小文字の区別なし) は、OK にマップされます
- 他はすべて、info (6) にマップされます
今回はこれをWARN判定させたいとしよう。
まずはparseルールを書いていく。
なお公式はこちら
CommonRule %{_short_log_level}, \[%{_date}T%{_datetime}.%{_microsec} #%{_process}\] %{_log_level} -- : \[%{_job}\] \[%{_job}\] \[%{_uuid}\] %{_message} %{_statusRemap}
Advanced Settingにもルールを設置(入れ子のルールは任意。↑と矛盾しなければOK)。
_short_log_level %{word:level.short_log_level} _log_level %{data:level.log_level} _date %{date("yyyy-MM-dd"):message.date.date} _datetime %{date("HH:mm:ss"):message.date.time} _microsec %{integer:message.date.micro_sec} _process %{integer:message.date.process_id} _uuid %{uuid:message.uuid} _job %{data:message.job} _message %{data: message.message} _statusRemap %{data:statusRemap}
New Processorの画面でリアルタイムに確認できるので、設定があっていればMATCH
判定になる。
statusRemap
の値に(api connection failed):
が入っているのを確認して次へ行く。
facetを作成
Category Processorで検索できるようにここで作っておく。
Create
を押下して次へ行く。
Category Processorで紐付ける
ここはhogehoge
がきたらfugahuga
と表示して〜と紐付けるプロセッサー。
例えばstatus:200
が来たらOK
と表示させてといった感じ。
これをさっきつくったfacetで設定する。
set target category attributeのpathは、_statusRemap %{data:statusRemap}
のpath。もしdata:hogehuga.statusRemap
にしているなら、pathはhogehuga.statusRemap
になる。
Addを押下してSaveしたら終わり。
Status Remapperで書き換える
Category Processorで「(api connection failed):
というログが来たらstatusRemapにはWARNを入れてね」と設定したので、このstatusRemapというattributeをログレベルとして扱ってもらう設定をする。
Status Remapperには、statusRemap
のpathを入れるだけでOK
実際にparseしてremapされた図↓
Piplineの順番に注意
もし別のparseルールが複数ある場合、優先順位は上からになることを忘れてはいけない(これに気づかずに時間を溶かした)。
WARN判定がうまくされないぞ?と思ったら、まずはこの順序が他のparseルールより下になってないかを確認しよう。
おわりに
地味にハマって時間を溶かした案件だった。
このルールを理解していれば、それ以外のログも自由自在と言ったところか。