7章 アプリケーション監視

メトリクスでアプリケーションを計測

監視が非常に効果的にも関わらず、見逃されがちなことがアプリケーション自体の監視
アプリケーションはそれ自体のパフォーマンスに関する価値のある情報をたくさん持っているので、活用することによって、受動的ではなく能動的にアプリケーションのパフォーマンスを維持できるようになる

まずは、データベースクエリにかかった時間、外部ベンダのAPIが応答するのにかかった時間、1日に発生したログイン数などシンプルなものから計測する

アプリケーションを計測するのにStatsDが紹介されている
モダンな監視スタックには不可欠な存在らしい

ビルドとリリースパイプラインの監視

ビルドからリリースまでの監視は、アプリケーションやインフラのメトリクスと一緒にメタ情報(デプロイがいつ始まったか・終わったか・どのビルドがデプロイされたか・誰がデプロイしたのか)を利用することにより役に立つ
例えば、APIのエラー率にデプロイしたタイミングを重ねることにより、デプロイの影響とAPIのエラー率の関係性を明確に表せる

healthエンドポイントパターン

アプリケーションの健全性を伝えるアプリケーション内のHTTPエンドポイント
アプリケーションについての基本的な情報(デプロイされたバージョンや、依存性のステータスなど)も含む場合もある
エンドポイントの裏側には、アプリケーションの健全性と状態について、取得する独立したコードが存在している

githubのステータスページみたいなもの？

アプリケーションロギング

ちゃんとしたログ解析システムなら、ログエントリからメトリクスに変換することは簡単
1行のログエントリは、1つのメトリクスより多くの情報を保持できる
しかし、ツールが高価・成熟していないという理由で、メトリクスのほうが現在は一般的

メトリクスかログにすべきかには以下の観点で判断すると良い

ログはネットワーク越しに送るのではなく、ディスクに書くべき
そして定期的(あるはリアルタイム)に外部にデータを送るサービスと組み合わせる

サーバレスまたはFunction-as-a-Service

総実行時間が1秒以下などの処理の関しにはStatsDを使えば良い

マイクロサービスアーキテクチャ

分散トレーシングで監視する
分散トレーシングとはマイクロサービスアーキテクチャにつきものの複雑なサービス間のやり取りを監視するための方法論とツールチェーンのこと

仕組みはシステムに入ってくるリクエストに一意なリクエストIDをタグつけする
リクエストIDはリクエストについて回り、どのサービスにアクセスしたか、各サービスでどのぐらい過ごしたのかがわかる

分散トレーシングは非常に難しく、時間のかかる監視の仕組みのため、業界内の一部だけで役に立つ