Ougai

構造化ログ 構造化ログ とは、機械的に処理しやすいログのことであり、その機構（ロギング）である。 英語圏では、 Structured Logging と表記される。たとえば Google Cloud の Stackdriver のドキュメントには下記の説明ページがあります。（残念ながら執筆時点で、これの日本語ページがまだできてないので、Google がどう訳すか興味深い） Structured Logging | Stackdriver Logging | Google Cloud 普通のログと構造化ログの比較 普通のログは、基本的に タイムスタンプ 、レベル 、そして メッセージ の文字列だけである。ログとして残す事象（イベント）のコンテキストになる情報はメッセージに適当に埋め込む。コンソール等で人が読みやすいものである。 構造化ログは、メッセージに埋め込んでいたコンテキストになる情報をそれぞれログ構造のフィールドに独立して持たせる。そのため後から解析がしやすい。そして出力するログはテキストベースで JSON にすることが多い。 では、見比べてみましょう。通常のRubyのLoggerと自作のOugaiでのログは次のようになります。『ユーザが記事を作成した』というログです（冠詞、削ってます）。 logger.info "User created article (user_id=#{user.id} article_id=#{article.id}" I, [2018-05-13T17:51:08.772542 #6253] INFO -- : User created article (user_id=123 article_id=45) logger.info "User created article", user_id: user.id, article_id: article.id 1 {"pid":6253,"level":20,"time":"2018-05-13T17:52:25.147+09:00","msg":"User created article","user_id":123,"article_id":45} ※デフォルトフォーマットとは異なります 見てわかる通り、普通のログは埋め込んで付帯情報を文字列化しつつ書かなくてはなりません。一方、構造化ログの方が JSON にした影響で長くなるのでコンソールでは読みづらいです。しかし読みづらいことはフォーマッタの動作環境での切替やparse機構を持つログビューワを使えば問題になりません。 構造化ログの方が解析しやすいというのは、例えば普通のログでは「あるユーザのログだけ抽出したいとき」に単に grep "user_id=10" とすると user_id が 101 など他のものまで引っかけてしまいます。構造化ログでは（主に JSONPath を使って）フィルタが $.user_id = 10 のように簡単に確実に絞り込めます。 ...