logとは何か? オブザーバビリティにおけるイベント記録の解説

logは、システムで起きた離散的なイベントのtimestamp付き記録で、人間または機械が後で何が起きたかを再構成できるように書かれます。

logは、最も古く最も直感的なオブザーバビリティのシグナルです。プログラムが何をしたかの継続的な物語です。metricが集約し、traceがリクエストを追う一方で、logは個々の瞬間を完全な詳細で捕捉します。その詳細が、調査にとって計り知れない価値を持たせる一方で、スケールでの保存を高価にします。

logエントリが含むもの

logの行は通常、timestamp、info、warn、errorといったseverityレベル、そしてメッセージを運び、しばしばrequest IDやコンポーネント名のようなコンテキストを与える追加のフィールドを伴います。合わせて、logの行のストリームは、システムがある瞬間に何をしていたかの物語を語ります。

severityレベル

レベルによって、シグナルをノイズから絞り込めます。debugとinfoは通常の動作を記述し、warnは疑わしい何かを示し、errorとfatalは本当の問題を示します。環境ごとに正しいレベルを設定すること、開発では詳細に、本番では静かに、が、ストレージを溢れさせずにlogを有用に保ちます。

structured logとunstructured log

unstructured logは自由形式のテキストで、書くのは簡単ですがクエリが困難です。structured logはキーと値のデータ、通常はJSONとして発行されるため、フィールドを機械でフィルタし集約できます。structured loggingが現代の既定なのは、まさにlogを、単に読むだけでなく検索し分析できるものに変えるからです。

CI/CDにおけるlog

build logは、jobが失敗したとき誰もが最初に読むものであり、pipelineのオブザーバビリティの最も生の形です。CIのステップがstructured logを発行し、それを中央のストアに送ると、実行をまたいで検索し、エラーのパターンを数え、jobを一つずつ読み返す代わりに、多くのbuildにわたって再発する失敗を見つけられます。

コストと保持

logは詳細であり、そのため大量になり保持が高価です。チームはこれを、sampling、価値の低いlogのより短い保持、そして頻繁にクエリされるフィールドのmetricへの昇格によって管理します。目標は、すべてを永久に保存する費用を払わずに、調査に十分な詳細を保つことです。

重要なポイント

logは、単一のイベントのtimestamp付きで詳細な記録です。
severityレベルが、日常的な活動を本当の問題から分けます。
structured logはクエリ可能で、unstructured logは単なるテキストです。
build logは、pipelineのオブザーバビリティの最も生の形です。