監視＠可観測性¶
はじめに¶
本サイトにつきまして、以下をご認識のほど宜しくお願いいたします。
01. 監視の要素¶
監視とは¶
既知のメトリクスとログを基に、システムにおける想定内の不具合の発生を未然に防ぐこと。
想定内という点で、可観測性と区別できる。
アラート通知までのアクション¶
▼ データの作成¶
監視対象が、データ (ログ、メトリクス) を作成する。
ここでは、ログ (アプリケーションログ、ブラウザのコンソールログ、ユーザーエンゲージメント、検索クローラーのサイト評価、など) とメトリクス (メトリクスのデータポイント、、ユーザートラフィック、など) のみを取り上げる。
ただし、可観測性を実現するためには、スパンの作成も必要である。
▼ データの収集¶
監視バックエンドが、対象からデータを収集する。
プル型の場合、監視バックエンド自体がデータを収集する。
一方でプル型の場合、監視バックエンドがエージェントを提供しており、これがデータを監視バックエンドに送信する。
メトリクスはプル型またはプッシュ型の収集ツールからなり、ログと分散トレースはプッシュ型の収集ツールのみからなる。
▼ データの保管¶
収集したデータ (ログ、メトリクス) をストレージに保管する。
保管期間は、90日が個人的には推奨である。
| 要件 | 説明 |
|---|---|
| ストレージ容量 | ログファイルのメトリクスのストレージのサイズを決める。メトリクスの場合、データポイント数を抑えて (例：収集間隔の拡大、ダウンサンプリング、重複排除) 、データサイズを小さくすると良い。 |
| バックアップしないログ | 全てのログを保管するとストレージ容量を圧迫してしまうため、一部のログ (例：ヘルスチェックのアクセスログ) は捨てるように決めておくと良い。 |
| バックアップの保管期間 (リテンション) | ログファイルのメトリクスのバックアップを実施し、また保管期間ポリシー (例：3ヶ月) を決めておくと良い。 |
| ローテーション | ログファイルやメトリクスのローテーション期間 (例：7日) をポリシーとして決めておくと良い。ローテションされた過去のログやメトリクスのファイルでは、ファイル名の末尾に最終日付 (例：-20220101) をつけておく。 |
| 世代数 | ローテションの結果作成されるファイルの世代数 (例：5) をポリシーとして決めておくと良い。ただ、これは設定できないツールがある。 |
▼ データの可視化¶
分析したデータを監視バックエンドとして収集し、目視できるように可視化する。
▼ データの分析¶
保管したデータ (ログ、メトリクス) を再集計し、新しいデータ (例：意味付けされた新しいメトリクス、ビジネス指標) として扱う。
注意点として、アラートのための再集計は、これに含まれない。
▼ レポートの作成¶
算出値をグラフ化として、レポートを作成する。
▼ アラートの発火と通知¶
分析による集計値に異常がある場合、これをエラーイベントとして一次オンコール担当の開発者にアラートを通知する。
全ての異常値をアラートする必要はなく、異常値とみなすための重要度レベルを決めておく。
また、エラーイベントの場所を特定できるようにすると良い。
アラートの通知後のアクション¶
▼ オンコール¶
アラートを通知された一次オンコール担当は、エラーイベントがインシデントか否かを判断する。
▼ インシデント管理¶
一次オンコール担当は、エラーを解決するためのタスクを作成し、完了させる。
エラーがインシデントの場合、担当者はこれを迅速に解決する必要がある。
また、二次担当者にアラートの通知をエスカレーションさせる。
▼ サービスレベルとの照合¶
インシデントによって、サービス利用者に提供できたサービスがサービスレベルに満たなかった場合、サービス利用者に利用料を返金する。
02. フロントエンドの監視¶
フロントエンドの監視とは¶
アプリケーションのフロントエンド領域 (特にブラウザ) を対象として、監視を実施する。
メトリクスの場合¶
▼ メトリクスの種類¶
| メトリクスの種類 | 説明 |
|---|---|
| パーセンテージ系 | 割合を単位とするアプリケーションのフロントエンド領域のメトリクス |
| 時分秒系 | 時間を単位とするアプリケーションのフロントエンド領域のメトリクス |
| カウント系 | 数を単位とするアプリケーションのフロントエンド領域のメトリクス |
▼ リアルユーザー監視 (RUM)¶
特にページ性能に関するメトリクスのデータポイントを収集し、監視する。
Webページのローディング時に、Navigation-timing-APIに対してリクエストを送信すると、Webページ性能に関するメトリクスのデータポイントを収集できる。
JavaScriptにNavigation-timing-APIにリクエストを送信する処理を組み込むと、ページ性能に関するメトリクスのデータポイントを収集できる。
ページローディング時間は特に重要である。
Amazonの自社調査では、ローディング時間が100ms短くなるごとに、売り上げが1%増加することが明らかになった。
4秒以下を目指すと良い。
▼ Googleアナリティクスによる監視¶
特にサイト訪問後のユーザーエンゲージメントのデータポイントを収集し、監視する。
リアルユーザー監視の一種ともみなせるが、性能の監視が主目的ではなく、リアルユーザー監視と補完し合う監視方法である。
▼ Googleサーチコンソールによる監視¶
検索エンジン上 (サイト訪問前) のユーザーエンゲージメントのデータポイントを収集し、監視する。
▼ 合成監視 (外部監視、外形監視)¶
『外部監視、外形監視』ともいう。
実際のユーザーの一連の操作を模したリクエストをアプリケーションに送信し、またレスポンスに関するメトリクスのデータポイントを収集し、監視する。
ユーザーを模したリクエストを作成するという意味合いで、『合成』という。
ユーザー視点で監視できる。
特に、クリティカルユーザージャーニーの一連の操作を監視すると良い。
ログの場合¶
ブラウザのコンソールログを収集し、監視する。
| ログの種類 | 説明 |
|---|---|
コンソールログ (Chromeの場合はconsole.logファイル) |
ブラウザのコンソールログを出力する。 |
03. バックエンドの監視¶
バックエンドの監視とは¶
アプリケーションのバックエンド領域を対象として、監視を実施する。
メトリクスの場合¶
▼ メトリクスの種類¶
アプリケーションのメトリクスのデータポイントを収集し、監視する。
| メトリクスの種類 | データポイントの内容 | 説明 |
|---|---|---|
| カウント系 | データポイントのタイムスタンプ、数 | 数を単位とするアプリケーションのバックエンド領域のメトリクス (例：リクエストの受信数、ログイン数) |
| パーセンテージ系 | データポイントのタイムスタンプ、パーセンテージ | 割合を単位とするアプリケーションのバックエンド領域のメトリクス |
| 時分秒系 | データポイントのタイムスタンプ、処理時間 | 時間を単位とするアプリケーションのバックエンド領域のメトリクス (例：SQLにかかる時間、ビルドまたはデプロイの開始/完了時間、外部APIコールにかかる時間) |
▼ 性能 (APM)¶
『APM (アプリケーション性能監視) 』ともいう。
特に性能に関わるメトリクス (例：CPU使用率、レスポンスタイム、分散トレースにおけるマイクロサービス間のスループット、エラー率、リクエスト数、連続稼働時間) のデータポイントを収集し、監視する。
▼ カスタムメトリクス¶
サーバー内にStatsDエージェントをデーモンとして常駐させ、アプリケーションでstatsdパッケージを使用すると、ユーザーの定義したカスタムメトリクスのデータポイントを収集できる。
CloudWatchでは、StatsDからのメトリクスの送信をサポートしている。
ログの場合¶
▼ ログの種類¶
アプリケーションのログを収集し、監視する。
| ログの種類 | 説明 |
|---|---|
システムログ (/var/log/messageファイル) |
基本的にはOSやミドルウェアの処理のログの出力先ではあるが、場合よってはアプリケーション処理のログも出力する。 ・https://thinkit.co.jp/article/724/1 |
| アプリケーションログ (ログファイルはフレームワークによる) | アプリケーションの任意の重要な処理 (アクセスログ、ログイン、ログアウト、など) のログを出力する。 |
クエリログ (/var/log/<ベンダー名>/general-query.logファイル) |
アプリケーションからDBへのクエリ処理の内容をログとして出力する。 |
分散トレースの場合¶
記入中...
セキュリティの場合¶
記入中...
04. サーバー/コンテナの監視¶
サーバー/コンテナの監視とは¶
インフラ領域のうちで、サーバー/コンテナを対象として、監視を実施する。
メトリクスの場合¶
| メトリクスの種類 | 説明 |
|---|---|
| パーセンテージ系 | 割合を単位とするサーバー/コンテナのメトリクス (例：CPU使用率、メモリ使用率、ディスク使用率) |
| 時分秒系 | 時間を単位とするサーバー/コンテナのメトリクス |
| カウント系 | 数を単位とするサーバー/コンテナのメトリクス |
ログの場合¶
▼ ログの種類¶
| ログの種類 | 説明 |
|---|---|
システムログ (/var/log/messageファイル) |
OSやミドルウェアの処理ログを出力する。 ・https://thinkit.co.jp/article/724/1 |
セキュリティログ (/var/log/secureファイル) |
OSのセキュリティ処理のログを出力する。 |
cronログ (/var/log/cronファイル) |
OSのジョブ処理 (例：Unixであればcron) のログを出力する。 |
メールログ (/var/log/maillogファイル) |
OSのメール処理のログを出力する。 |
印刷ログ (/var/log/spoolerファイル) |
OSの印刷処理のログを出力する。 |
OSブートログ (/var/log/boot.logファイル) |
OSの起動処理のログを出力する。 |
セキュリティの場合¶
記入中...
05. ネットワークの監視¶
ネットワークの監視とは¶
インフラ領域のうちで、ネットワークを対象として、監視を実施する。
メトリクスの場合¶
記入中...
セキュリティの場合¶
記入中...
06. アクティブ型ヘルスチェック¶
アクティブ型ヘルスチェックとは¶
ヘルスチェックで監視したい対象に対して、定期的にリクエストを送信する。
アプリケーション、サーバー/コンテナ、ネットワークの場合¶
▼ ヘルスチェックの方法¶
ロードバランサーからヘルスチェックエンドポイントに専用のリクエストを送信し、ターゲットが正しく動作しているか否かを確認する。
OSI参照モデルのいずれのレイヤーまでの動作を確認するかによって、ヘルスチェックに種類がある。
| ヘルスチェックの種類 | ヘルスチェックの範囲 | 方法 |
|---|---|---|
L3チェック |
L1からL3 (ネットワーク層) まで |
サーバー/コンテナのIPアドレスにPINGリクエスト (ICMP echo) を送信し、レスポンスを検証する。正しいPINGレスポンスが返信されれば、サーバー/コンテナまでのネットワークが正しく動作していると判断できる。 ・https://milestone-of-se.nesuke.com/nw-basic/ip/icmp/ |
L4チェック |
L1からL4 (トランスポート層) まで |
サーバー/コンテナのポートにTCPスリーウェイハンドシェイクを実行し、TCPコネクションを確立できるかを検証する。TCPコネクションの確立が成功すれば、サーバー/コンテナの開放ポートまでのネットワークが正しく動作していると判断できる。 |
L7チェック |
L1からL7 (アプリケーション層) まで |
サーバー/コンテナ上のアプリケーションのエンドポイントにHTTPリクエストを送信し、HTTPレスポンスを検証する。正しいHTTPレスポンスが返信されれば、アプリケーション自体とその開放ポートが正しく動作していると判断できる。 |
ジョブの場合¶
▼ ヘルスチェックの方法¶
ジョブ (定期的なバッチ処理) が正常に動作しているか否かを監視する。
ジョブの実装方法としては、例えばUnixのCronがある。
▼ Healthchecks.io¶
Cronの処理結果を監視する。
ジョブの最後に、ジョブの標準出力/標準エラー出力の内容をHealthchecks.ioに送信する。
これにより、ジョブの開始から最後のリクエストまでが、一定の時間内に完了するか否かを確認する。
# Cronの実行結果をHealthchecks.ioに直接的に送信する場合
8 6 * * * /foo-cron.sh && curl -fsS --retry 5 -o /dev/null https://hc-ping.com/ping/<healthchecksのID>
▼ Healthchecks.io と Runitor¶
curlコマンドの代わりとしてRunitorを使用すると、標準出力/標準エラー出力の内容を人間がわかりやすいように整形してくれる。
Runitorを使わない場合、Cronの標準出力/標準エラー出力の内容をそのままhealthchecks.ioに送信することになる。
# Runitorを介して、Cronの実行結果をHealthchecks.
# -api-url：healthchecks.ioのエンドポイント
# -uuid：healthchecks.ioのID
# --：ジョブの実行
8 6 * * * /usr/local/bin/runitor -api-url https://hc-ping.com/ping -uuid <healthchecksのID> -- /foo-cron.sh
クラウドプロバイダーの場合¶
▼ ヘルスチェックの方法¶
クラウドプロバイダーが正常に動作しているか否かを監視する。
クラウドプロバイダーの多くがステータスページを公開しているため、これを監視する。
06-02. パッシブ型ヘルスチェック¶
パッシブ型ヘルスチェックとは¶
実際のユーザーのリクエストを借りて、ターゲットが正しく動作しているか否かを確認する。
アクティブ型とは異なり、ユーザーを犠牲することになるため、Webサイトの信頼性が低下する可能性がある。
07. ビジネス成果の監視¶
ビジネス成果の監視とは¶
ビジネス成果の指標を対象として、監視を実施する。
ビジネス成果の指標 (例：KPI、業務プロセスに関する現在のステータス) の監視に特化したメトリクス監視バックエンドを、特に『BIツール (例：Redash、Metabase、Google Cloud Looker、など) 』ともいう。
なお、BIツールはDBからビジネスに関するデータを収集し、監視できるようにする。