概要

初めてサービスを公開するにあたって、障害対策のために監視を強化することになり、入門　監視を読むことで監視に関して知見をつけることにしました。この本の内容についてまとめます。対象として後半の「何を監視すべきか、なぜ監視すべきなのか、どうやっって監視するのかといった監視の戦略」についての内容をまとめます。

フロントエンド監視

監視ののゴール

フロントエンドのパフォーマンス監視のゴールは動き続けることではなく、素早くロードされること

フロントエンド監視には、リアルユーザー監視(RUM)とシンセティック監視の２つの方法がある。

リアルユーザー監視：監視のデータとして実際のおユーザトラフィックを使うもの
ex)下の Navigation Timing APIや　Speed Indexでメトリクスを取得
シンセティック監視：Webサイトがうご行っているかどうかをリクエストしてstatus code 200のレスポンスが返ってくることで確かめる方法
ex) Datadog synthetics

フロントエンドパフォーマンスのメトリクス

Navigation Timing API

ブラウザは、W3Cによって推奨されいている Navigation Timing APIという仕様に基づいたAPIを通じて、ページパフォーマンスのメトリクスを公開している。

特に有益なメトリクス

メトリクス項目	内容
navigationStart	ブラウザによってページリクエストが開始されたタイミング
domLoading	DOMがコンパイルされロードが始まったタイミング
domInteractive	ページが使用可能になったと考えられるタイミング(ページのロードが終わっているとは限らない
domCoontentLoaded	全てのスクリプトが実行されたタイミング
domComplete	ページが全て(HTML,CSS,JS)のロードを終えたがイミング

他にも、 Speed Indexなどのフロントエンドパフォーマンステストツール。
Speed Indexは視覚的な点でページがいつロードされ終わったのかを判断する。

アプリケーション監視

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

まずシンプルにはじめる。
ex)

データベースのクエリの実行にかかった時間
外部ベンダのAPIが応答するのにかかった時間
あるいは一日に発生したログインの数

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

デプロイイベントとAPIエラー率のそれぞれのグラフを重ねた表を作ることで、どこのデプロイから挙動おがおかしくなったのかを一目で分かるようにする。

healthエンドポイントによるレスポンスの確認

監視方法
healthエンドポイントに対してhealth()関数を呼び、レスポンスを返してそのステータスコードで成功しているかどうかを判断する

sqlデータベースに接続してqueryが実行できるかどうか
Redisに依存性がある場合はRedisに接続してデータを取得できるか否か。場合に応じて書き込みの確認も

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

監視方法
分散トレーシングにより、1つのリクエストに一意なリクエストIDを「タグ付け」することで、そのリクエストがどのサービスにアクセスしたか、各サービスでどのくらい時間を過ごしたかが分かる。ただ、分散トレーシングを始めるには時間と労力がかかる。

ex) Zipkin

サーバ監視

OSの標準的なメトリクス

OSの標準的なメトリクスは世の中の監視ツールではデフォルトで収集対象になっているため、どうやって取得するかよりも、その意味と使い方について説明。
CPU、メモリ、ネットワーク、ディスク、ロードアベレージなどについて説明されています。今回は省略。

Webサーバ

パフォーマンスとトラフィックのレベルを測る決定版のメトリクスは秒間リクエスト数。
基本的には秒間リクエスト数はスループットの指標。
パフォーマンスにはそこまで致命的ではないが全体の見通しで重要なのがHTTPステータスコードの監視。
もう1つ便利なメトリクスが、リクエスト時間。

DBサーバ

監視項目

まず監視するのはコネクション数(MySQLではスレッドと表現している)
どれくらい忙しいのかをみるのには秒間クエリ数をみる。
スロークエリー(クエリの実行時間、実行回数、そのクエリ自体をあわせてログに出力される)
レリプリケーションの遅延
IOPS

参考資料：実践ハイパフォーマンスMySQL Database Reliability Engineering

ロードバランサー

ロードバランサはヘルスチェックを通じてバックエンドサーバの状態を判断する。