Datadog Logsでparseして任意のログレベルに変えたいときのremap方法 - VTRyo Blog

VTRyo Blog

一歩ずつ前に進むブログ

Datadog Logsでparseして任意のログレベルに変えたいときのremap方法

ども。

Datadogでログを取ってると「このログ、ぶっちゃけWARNINGでいいんだけど」みたいなのがある。

Datadogは自分でparseルールをカスタムできるので、それを利用してremapしてやるのだがそのやり方を毎回忘れる。

そして例によってわかりにくい公式ドキュメントとにらめっこしたくないので、備忘録。

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) にマップされます

docs.datadoghq.com

今回はこれをWARN判定させたいとしよう。

まずはparseルールを書いていく。
なお公式はこちら

docs.datadoghq.com

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}

f:id:vtryo:20200227173121p:plain

New Processorの画面でリアルタイムに確認できるので、設定があっていればMATCH判定になる。

f:id:vtryo:20200227172927p:plain
設定したルールでparseできてるか確認

statusRemapの値に(api connection failed):が入っているのを確認して次へ行く。

facetを作成

Category Processorで検索できるようにここで作っておく。

f:id:vtryo:20200227174123p:plain
facetを追加する

f:id:vtryo:20200227174150p:plain

Create を押下して次へ行く。

Category Processorで紐付ける

ここはhogehogeがきたらfugahugaと表示して〜と紐付けるプロセッサー。 例えばstatus:200が来たらOKと表示させてといった感じ。

これをさっきつくったfacetで設定する。

set target category attributeのpathは、_statusRemap %{data:statusRemap} のpath。もしdata:hogehuga.statusRemapにしているなら、pathはhogehuga.statusRemapになる。

f:id:vtryo:20200227174655p:plain
statusRemapを任意のログレベルと紐付ける

Addを押下してSaveしたら終わり。

Status Remapperで書き換える

Category Processorで「(api connection failed):というログが来たらstatusRemapにはWARNを入れてね」と設定したので、このstatusRemapというattributeをログレベルとして扱ってもらう設定をする。

Status Remapperには、statusRemapのpathを入れるだけでOK

f:id:vtryo:20200227175341p:plain
pathを書く

実際にparseしてremapされた図↓

f:id:vtryo:20200227175631p:plain
WARNになってる

Piplineの順番に注意

もし別のparseルールが複数ある場合、優先順位は上からになることを忘れてはいけない(これに気づかずに時間を溶かした)。

f:id:vtryo:20200227180650p:plain
Piplineは上から処理される

WARN判定がうまくされないぞ?と思ったら、まずはこの順序が他のparseルールより下になってないかを確認しよう。

おわりに

地味にハマって時間を溶かした案件だった。

このルールを理解していれば、それ以外のログも自由自在と言ったところか。

参考