第8章 監視
複数ホスト、サービスでどう監視設計を行うか。という話し。
多分、「監視」を行っている人達は用いているツールは違うけれども似たようなことはすでにやっているんじゃないかな。
ポイントは
- サービスが多くなると収集するメトリクス、ログの頻度やサイズが負担になってくるよね
- 新しくビルドされたサービスはどうメトリクスにJoinするの？
- 複数サービスを利用するリクエスト時のログの追跡。例えば、決済 - メール送信の2つのサービスを利用するリクエストがあった場合、どのリクエストからの処理であったかを関連付けたい。
とかになると思う。
監視の課題
障害が発生した時、すべてのサービスを監視して、ログをウォッチし、時にはサービス間でのネットワークの遅延などが発生している可能性もある。
監視の考え方
基本は小さいものを監視していき、集約すればよい。
知りたい情報はホスト全体 and 個々のメトリクスなので、Nagiosのようにメトリクスをグループ可視できればわかりやすい。
複数のホスト、サービスをどう監視するか？
アプリケーションの動作を監視するにはやっぱり「ログ」の監視。マイクロサービスすべてのアプリケーションが吐いたログをDWHに記録する手法が有効。
サービスごとにログの形式が違ったりするので、本書では解析と送信にLogstash、DWHにKibanaについて名前だけ紹介している。僕の前職はFluentd、Redshftで運用していた。
メトリクスの集約
単に集約するだけではなく、頻度やサイズ、新しくビルドされたサービスに対しても考慮する必要がある。
本書ではGraphiteについて紹介されている。知らなかったんだけど便利そう。
メトリクスというとホストの状態やサーバソフトウェアにも目がいきがちだけど、自身のアプリケーションについても考慮しよう。例えば、エラー率や応答速度なんかは有益な情報になり得る。
プロセスごとのログの追跡
複数のサービスから一連の処理を行うプロセスの場合、その一連の処理プロセスを示す処理IDを各サービス間で共有しよう。本書では「相関ID」と記述。
言わずもがな、相関IDをログに記述することにより、プロセス、イベントごとの流れに応じた各サービスのログを追うことができる。
これは重要。
その他
サービス結合部分の監視も忘れずに。ネットワークとか。
対象のサービスが接続する下流システムを監視すれば、そのサービスの結合部分は監視できているはず。
