クラウドの監視は何を見るのか。死活・リソース・アプリ

クラウドの監視は、外から見てシステムが動いているか（死活）、サーバーやデータベースの資源に余裕があるか（リソース）、利用者から見て正しく動いているか（アプリケーション）の3つの層で見ます。3つの層に分けると、「サーバーは動いているのに、利用者は画面を開けない」といった見落としに気づきやすくなります。

監視は、仕組みを入れること自体より、何を見て、異常のときに誰が何をするかを決めることのほうが大切です。この記事では、見るものの決め方と、24時間の監視を仕組みと人の対応に分ける考え方を説明します。

3つの層で見る

監視で見るものを、3つの層に分けて整理します。

死活の監視は、止まったことに気づくための最低限の監視です。リソースの監視は、止まる前の兆しに気づくために使います。アプリケーションの監視は、サーバーは動いていても、利用者から見ると使えない状態に気づくために使います。

3つのうち、死活とリソースは、クラウドの事業者の仕組みで比較的すぐに始められます。アプリケーションの層は、何を「正しく動いている」とするかを業務に合わせて決める必要があるため、後回しにされがちですが、利用者への影響を直接映す層です。応答の時間やエラーの割合の目標を決める考え方は、SLO の用語の説明もあわせてご覧ください。

各クラウドの監視の仕組み

3つのクラウドは、それぞれ監視の仕組みを用意しています。

外からの死活の確認

Google Cloud の Cloud Monitoring の稼働時間チェック（uptime check）は、公開している URL などに、世界の複数の場所から定期的に HTTP・HTTPS・TCP の要求を送り、応答を確かめます。失敗したときに通知する設定もでき、既定では、少なくとも2つの地域から1分以上失敗が報告されたときに通知されます。1か所だけの失敗では、既定の設定では通知されません。

出典：Manage public uptime checks（Google Cloud）

複数の場所からの失敗を条件にするのは、確かめる側の一時的な通信の不調で、不要な通知が出るのを防ぐためです。

AWS の CloudWatch Synthetics のカナリアは、決まった間隔で動くスクリプトで、利用者と同じ経路をたどり同じ操作をすることで、利用者がいない時間でも、利用者から見た動きを確かめ続けられます。応答の有無と時間を確かめ、画面の写しを残すこともでき、最短で1分ごとに動かせます。

出典：Synthetic monitoring (canaries)（AWS）

カナリアのように手続きの流れまで確かめる仕組みは、アプリケーションの層の監視にもなります。

リソースとアプリケーション

AWS の CloudWatch のアラームは、指標（メトリクス）を見張り、しきい値を上回ったときなどに通知を送ったり、資源を自動で変えたりします。アラームは状態が変わったときに動作を起こし、通知の先として Amazon SNS（通知のサービス）などを指定できます。指標のデータが届かないときは「データ不足」の状態になり、資源が動いていないだけで、問題があるとは限らない、とされています。

出典：Using Amazon CloudWatch alarms（AWS）

Microsoft の Azure Monitor は、Azure のさまざまな資源から指標とログを集め、仮想マシンや Kubernetes のクラスターからは、指標に加えてイベントのログも集めます。Application Insights は、動いている Web アプリケーションの性能を監視する機能です。アラートは、集めたデータから問題を見つけて、利用者に影響が出る前に知らせるためのものと説明されています。

出典：Azure Monitor overview（Microsoft Learn）

監視の仕組みが集めた指標とログを、原因の調べやすさまで含めて使う考え方は、オブザーバビリティとは。監視と何が違うのかで説明しています。ログの残し方は、ログの取り方と見方。何を、どのくらい残すかをご覧ください。

通知は、人が動くものだけに絞る

監視で見るものと、人に知らせるものは分けて考えます。見る指標をすべて通知にすると、通知が多すぎて、本当に対応が要る通知が埋もれます。

通知の設定を決めるときは、次の点を決めます。

1. 知らせる条件：その状態が続くと、利用者に影響が出るか
2. 知らせる相手：誰が受けるか（時間帯ごとに違う場合も含めて）
3. 受けた人がすること：最初に確かめること、切り分けの手順、誰に連絡するか
4. 急ぎの度合い：すぐに動くもの、翌営業日でよいもの、記録だけでよいもの

3つ目の「受けた人がすること」は、手順書（ランブック）として書いておきます。通知を受けた人が手順書を見て動ける状態にしておくと、担当者が替わっても、夜間でも、同じように対応できます。手順書の作り方と、障害のときの連絡の流れは、障害が起きたときの一次対応。連絡の流れと手順書で説明しています。

通知の条件は、一度決めて終わりではありません。不要な通知が多いもの、通知が出なかったのに障害が起きたものを、月に一度などの機会に見直します。

24時間の監視は、仕組みと人の対応を分ける

「24時間監視」と聞くと、人が画面を見続ける姿を思い浮かべるかもしれませんが、見張ること自体は監視の仕組みが24時間自動で行えます。人の対応は、通知を受けて切り分ける役割と、原因を直して再発を防ぐ役割に分けて考えます。

1つ目の「見張る」は、監視の仕組みが24時間365日、自動で回します。人が決めるのは、何を見て、どの条件で知らせるかの設計と設定です。

2つ目の「受けて切り分ける」は、通知を受けて、影響の範囲を確かめ、手順書にある一次対応（再起動など）を行い、必要な人へ連絡する役割です。夜間・休日もこの役割を担う必要がある場合は、社内の当番か、手順書にもとづいて動く外部の専門の会社に任せる方法があります。

3つ目の「直して再発を防ぐ」は、原因を調べ、設定や構成を直し、同じ障害が起きないようにする役割です。急ぎの切り分けとは違い、落ち着いて調べる時間が要るため、営業時間内に行う形でも回せる場合があります。

3つを分けると、「夜間に誰が起きているか」と「誰が原因を直すか」を別々に決められるため、少ない人数の会社でも無理のない体制を作りやすくなります。担当者が少ない会社の体制の考え方は、インフラの担当が1人しかいない会社のクラウド運用で説明しています。

当社のご支援

当社は、死活・リソース・アプリケーションの3つの層での監視の設計と設定、通知の条件と手順書づくりを、クラウドの構築と運用管理でお手伝いしています。監視の仕組みは24時間自動で回し、夜間・休日の通知の受け付けと一次対応は、当社の手順書にもとづいて外部の専門の会社が担い、原因の調査と再発の防止、月次の報告は当社が営業時間内に行う形でお受けしています。料金の目安は料金のページに載せています。