kakudooo docs


小規模から中規模へ
構造化ログからはじめる信頼性の担保

Kaigi on Rails 2025
PLEX / 種井覚道


自己紹介


そのログ活用できていますか?


今日話すこと


ログについて整理


ログについて整理

ログとは? その①

“基本的には連続した文字列のことで、(可能なら)いつイベントが発生したのかを示すタイムスタンプが関連づけられたものです。”

引用: 入門監視

alt text


ログについて整理

ログとは? その②


ログについて整理

構造化ログと非構造化ログ

構造化ログ


非構造化ログ

alt text alt text


ログについて整理

ログの用途についての分類

参考: Webアプリケーションのログに関するいくつかの考察


背景


背景

Plex JobというHRプラットフォームを作っています


背景

アプリケーションの構成

alt text


背景

立ち上げから4年ほど経過し成長フェーズに


背景

信頼性がより求められるフェーズに

👉 ある時点でのアプリケーションの状態について迅速に、また詳細を知る必要がある

alt text


背景

監視・調査&復旧業務の効率化

監視ツールにより、アプリケーション監視や調査を効率的に行うことができる


背景

監視ツールと構造化ログ

👉 Datadogをはじめとした監視ツールは「構造化ログ」を取り込むことで、上記のようなログベースの機能に応用することが可能


背景

当時のアプリケーション監視

👉 収集しているログを活かしきれていない状態


背景

ここまでの話しを整理


背景

👉 構造化ロギングを行うだけでも
信頼性の担保を見据えたログの活用ができる


背景

「監視」と「調査」のためのログ収集

  1. アプリケーションを構成する各サーバープロセス構造化ログが出力されている状態にする
  2. 監視ツールのログベースの機能に合わせてログをフォーマットする

背景

「監視」と「調査」用途のログ収集と活用

alt text


Railsアプリケーションのログを
構造化する


Railsアプリケーションのログを構造化する

構造化手法の選定と導入

大きく分けて2つ


Railsアプリケーションのログを構造化する

Semantic Logger Rails を採用


Railsアプリケーションのログを構造化する

構造化手法のデファクトスタンダードがない問題


Railsアプリケーションのログを構造化する

Railsアプリケーションのログを構造化ロギングに対応させることができた!!

Railsアプリケーションのログを構造化することができた

→ ただし、運用をはじめてみると一部の要素が漏れていたことがわかった


Railsアプリケーションのログを構造化する

Rakeタスクで発生した例外が構造化されていない

alt text

alt text


Railsアプリケーションのログを構造化する

Rakeタスクで発生した例外が構造化されていない

alt text


Railsアプリケーションのログを構造化する

検討: 3つの方法


Railsアプリケーションのログを構造化する

どの方法で実装するか?

今回は保守性を考慮して、Rake にパッチをあてる方法が落とし所としてはよさそうだという判断となりました。

Rake にパッチをあてる

alt text


Railsアプリケーションのログを構造化する

begin … rescue … end で処理を囲う

alt text


Railsアプリケーションのログを構造化する

at_exit を使用する

alt text


Railsアプリケーションのログを構造化する

Rakeにパッチをあてる

https://github.com/ruby/rake/blob/79bf96f9aa3219ce87a4979e78fb206a29d18dac/lib/rake/application.rb#L235を参考にdisplay_error_messageメソッドにモンキーパッチを当てることで実装を行いました。


Railsアプリケーションのログを構造化する

パッチの例

alt text


Railsアプリケーションのログを構造化する

結果

{"host":"004c21fd7993","application":"Semantic Logger","timestamp":"2025-07-24T06:23:03.354088Z","level":"fatal","level_index":5,"pid":6481,"thread":"1816","file":"/workspaces/sample/rakefile","line":17,"name":"Rails","message":"bin/rails aborted! Tasks: TOP =\u003e hoge:fuga","exception":{"name":"RuntimeError","message":"","stack_trace":["/workspaces/sample/lib/tasks/hoge.rake:3:in 'block (2 levels) in ..."]}}

ログのフォーマット


ログのフォーマット

ツールの仕様に合わせてログをフォーマットする

→ 監視ツールで定められた要件を満たす形に構造化ログをフォーマットする必要がある

{
  ...
  "level": "ERROR",
  "error": {
    "kind": "...",
    "message": "...",
    "stack": "...",
  }
  ...
}

どこでフォーマットするか?

→ ログのフォーマットに関する設定がアプリケーションと監視ツールにまたがってしまうことや、SWEを中心としたチームであることから、前者を選択 → 社内に専門性のあるメンバーやチームがある場合は、監視ツールでフォーマットするのもあり


ログ活用の現在


監視


調査


おまけ | Rails8.1と構造化ログ

Railsでの構造化ログ標準化やエコシステム進化の期待

課題に対して取り組んできた内容と、Railsへの期待が対応している形にしたい


まとめ