「実務で役立つ ログの教科書」を読み終えたので、印象に残ったところを読書メモとして残しておきます。ログというと障害が起きたときに見るもの、というイメージが強かったのですが、この本を読んでログはもっと広い目的に使えるものだと考え方が変わりました。
トラブル以外のログの目的
ログは問題が発生したときだけに出力されるものではありません。正常に動いているときにも「問題なく動作していること」を示すログを残しておかないと、そもそもどの状態が正常なのかを判断できなくなります。異常時のログだけを見ても、正常時の記録がなければ、それが本当に異常なのかどうかは判断できないからです。
「問題なく動作していること」を示すログは、障害調査以外の目的にも使えます。たとえば利用者のアクセスログや閲覧履歴からは、利用者がどう行動したのかを把握でき、それをデータ分析してマーケティングに活かせます。Webサイトであれば、どのページから流入してどのページで離脱したのか、どの地域からどれくらいアクセスがあったのか、といったことを分析できます。
本書ではログの目的を大きく3つに整理していました。
- システム管理: システムの利用状況を調べる / トラブルの原因を調べる
- セキュリティ: 攻撃の予兆を調べる / 不正を抑止する
- ビジネス: 利用状況を調べる
普段は「エラーが出たら困るからログを仕込む」という発想になりがちでしたが、正常時のログこそが基準線になり、その基準線があるからこそ異常に気づけるという順序で考えると腑に落ちました。
ログに何を出力するか(5W1H)
何をログに残すべきかを整理するときは、5W1Hの観点が役立つと紹介されていました。
- When: いつ。基本は秒単位で記録し、処理の順序を厳密に追いたい場合はミリ秒・マイクロ秒まで記録する
- Where: どこから出力されたログか
- Who: ログ出力が必要な操作をした人や端末
- What: どんなデータを操作したのか、リクエストの内容
- Why: ログの種類(警告・エラー・正常など)
- How: どうやってその操作がされたのか(どのボタンを押したか、どのリンクをクリックしたか)
漠然と「ログを出す」ではなく、この6つの観点が埋まっているかを確認すると、あとから見返したときに役立つログを書けそうです。
アクセスログ
Webサーバーが受け取ったリクエストを記録するアクセスログには、次のような項目が含まれます。
| 項目 | 内容 |
|---|---|
| タイムスタンプ | リクエストの日時 |
| アクセス元のIPアドレス | 利用者のIPアドレス |
| リクエストの種類 | GET、POSTなど |
| URL | パスとクエリ文字列 |
| ステータスコード | 正常、エラーなど |
| 転送量 | ファイルのサイズなど |
| リファラー | リンク元のURL |
| ユーザーエージェント | 利用者のOS、Webブラウザなど |
こうした項目を並べる形式としては、NCSA combined形式やW3C拡張ログ形式などがよく使われます。フォーマットが標準化されているおかげで、解析ツールに素直に取り込めるのは大きな利点だと感じました。
クエリログ
クエリログは、DBMSが受け取ったSQLクエリの実行履歴を記録するログです。どんなクエリがどれくらい実行されているかがわかるので、インデックスの最適化やSQL文の改善などに役立ちます。
パフォーマンスの問題を調べるときは、アプリケーション側のログだけでなく、データベースがどんなクエリを受け取っていたのかを合わせて見られると原因にたどり着きやすくなります。
ログの収集方式(エージェント型とエージェントレス型)
ログを集める方式には、大きくエージェント型とエージェントレス型があります。
エージェント型は、監視対象のサーバーにエージェントと呼ばれるソフトウェアを常駐させ、そこからログを収集する方式です。一方のエージェントレス型は、管理サーバーからSNMPやICMP、WMIといったプロトコルを使って監視対象と通信し、外部からデータを収集します。監視対象に専用のソフトウェアを入れずに済むのが特徴です。
- SNMP(Simple Network Management Protocol): ネットワーク経由で監視するときに使われる簡易的なプロトコル
- ICMP(Internet Control Message Protocol): 問題なく通信できているかを確認するときに使われるプロトコル
- WMI(Windows Management Instrumentation): Windowsコンピュータの管理情報へアクセスするために使われるプロトコル
エージェントレス型の代表的なログ収集ツールには、syslogからログを収集するGraylogがあります。GraylogはMongoDBやOpenSearchと組み合わせて動作します。
ログの検索
集めたログは、テキストエディタの検索機能で探すこともできますが、量が増えてくると全文検索エンジンを使うのが現実的です。よく使われるのがElastic StackやGrafana、Splunkです。
- Elastic Stack: Elastic社が開発する、データの収集・検索・分析・可視化のためのプラットフォーム
- Grafana: さまざまなデータソースから取得したメトリクスやログを、ひとつの画面でグラフやダッシュボードとして可視化・監視できるオープンソースソフトウェア
- Splunk: サーバーやネットワーク機器、アプリケーションが出力する膨大なマシンデータ(ログ)を、リアルタイムに収集・検索・分析・可視化するデータ分析プラットフォーム
ログの通知と、通知した後の課題
異常を見つけたら担当者に通知します。ただ、通知を出すこと自体よりも、そのあと確実に対応まで至るかどうかのほうが難しい、というのが印象的でした。起こりがちな課題は、次のように整理されていました。
| 課題 | 背景 |
|---|---|
| 担当者と連絡が取れない | アラート発生時に担当者が不在 |
| 担当者が連絡を受けたが放置した | アラートは認識しているが対応を後回しにしてしまう |
| 複数の担当者がおり、誰も担当しない | 責任の所在が曖昧になり、対応が遅れる |
| 対応したが結果が報告されない | 対応後の報告がなく、情報共有や次の対応に支障が出る |
| アラートの誤検知やノイズが多い | 実際には問題ないのにアラートが頻発し、対応が煩雑になる |
| アラート内容が不明瞭で情報が足りない | 原因や影響範囲がわからず、対応が遅れる |
| 対応履歴やログの管理が不十分 | 過去の対応履歴が残っておらず、対応に時間がかかる |
| 担当者のスキルや知識が不足している | 対応方法がわからず、対応に時間がかかる |
| 対応の優先順位が不明瞭 | どのアラートから対応すべきか判断できず、重要なものが後回しになる |
| システム間の連携が不足している | 複数のシステムが連携しておらず、情報が断片的にしか得られない |
通知の仕組みを作るだけでは足りず、誰がどの順番で対応し、その結果をどう記録するかまで含めて設計しておく必要があるのだと感じました。
改ざんの検出と証拠の保全
ログはシステムの動作履歴や操作記録を示す証拠でもあります。もしログが改ざんされてしまうと、不正行為の証拠が失われたり、調査の信憑性が損なわれたり、法的な証拠として使えなくなったりします。そのため、改ざんを防ぐだけでなく、早期に検出できる仕組みを整えておくことが求められます。
検出方法のひとつとして、ローテーション済みのログを対象にするTripwireが紹介されていました。ファイルのハッシュ値をあらかじめ記録しておき、定期的に比較することで変更を検知する仕組みです。
ログを使ったパフォーマンス改善
ログはパフォーマンスの改善にも使えます。応答にかかった時間をより細かく計測したい場合は、APM(アプリケーションパフォーマンス管理)ツールを導入する方法があります。本書ではPrometheusやGrafana、New Relic、Datadog、Elastic APMが挙げられていました。
- Prometheus: システムやサーバーの数値を集めて監視するオープンソース
- Grafana: さまざまなデータソースのメトリクスやログを、ひとつの画面で可視化・監視できるオープンソースソフトウェア
- New Relic: システムやアプリケーションの状態を一体的に監視・分析するクラウド型のオブザーバビリティプラットフォーム
- Datadog: ブラウザやモバイルアプリからバックエンドサービス、データベースまで、コードレベルの分散トレーシングを提供
- Elastic APM: アプリケーションの性能や動作をリアルタイムに監視するツール
おわりに
この本を読んで、ログは「困ったときに眺めるもの」から「正常な状態を記録し続けておくもの」へと位置づけが変わりました。何を残すかを5W1Hで設計し、アクセスログやクエリログのように目的ごとに整った形式を選ぶ。そのうえで、収集や検索、通知、改ざんの検出、パフォーマンス改善といった使い道まで見渡せると、システム管理・セキュリティ・ビジネスのどの目的にも応用が効きそうです。
