サーバーとデータベースを24時間監視するときに設定する項目

この文書の適用条件

そのまま実行できるコマンド

# 対象: Amazon CloudWatch（AWS CLI v2）
# 権限: cloudwatch:PutMetricAlarm
# 変更作業: あり（同名アラームが存在する場合は上書きされる）
# Production 実行: 可能。通知先とランブックを用意してから作成すること
#
# 通知先の SNS トピック ARN は環境変数で渡す（この文書には実 ARN を記載しない）
# export SNS_TOPIC_ARN="<自環境の SNS トピック ARN>"

aws cloudwatch put-metric-alarm \
  --alarm-name "rds-db-sample-instance-cpu-sustained" \
  --alarm-description "CPU使用率が継続して高い状態を検知する" \
  --namespace AWS/RDS \
  --metric-name CPUUtilization \
  --dimensions Name=DBInstanceIdentifier,Value=db-sample-instance \
  --statistic Average \
  --period 300 \
  --evaluation-periods 3 \
  --datapoints-to-alarm 3 \
  --threshold 80 \
  --comparison-operator GreaterThanThreshold \
  --treat-missing-data missing \
  --alarm-actions "$SNS_TOPIC_ARN" \
  --ok-actions "$SNS_TOPIC_ARN"

-- 対象: MySQL 5.7 以降 / Amazon Aurora MySQL
-- 権限: グローバル状態変数の参照権限（PROCESS 権限相当）
-- 変更作業: なし（参照のみ）
-- Production 実行: 可能

-- 現在の接続数
SHOW STATUS LIKE 'Threads_connected';

-- 起動以降の最大同時接続数（ピークの把握に使う）
SHOW STATUS LIKE 'Max_used_connections';

-- 接続上限
SHOW VARIABLES LIKE 'max_connections';

-- 上限に達して拒否された接続の累計
SHOW STATUS LIKE 'Aborted_connects';

-- 対象: SQL Server 2012 以降 / Amazon RDS for SQL Server
-- 権限: VIEW SERVER STATE
-- 変更作業: なし（参照のみ）
-- Production 実行: 可能
SELECT
    (SELECT COUNT(*) FROM sys.dm_exec_sessions
      WHERE is_user_process = 1)                 AS user_sessions,
    (SELECT COUNT(*) FROM sys.dm_exec_requests
      WHERE session_id > 50)                     AS active_requests,
    (SELECT COUNT(*) FROM sys.dm_exec_requests
      WHERE blocking_session_id <> 0)            AS blocked_requests,
    @@MAX_CONNECTIONS                            AS max_connections_configured;

# 対象: Amazon CloudWatch（AWS CLI v2）
# 権限: cloudwatch:DescribeAlarms
# 変更作業: なし（参照のみ）
# Production 実行: 可能
aws cloudwatch describe-alarms \
  --query "MetricAlarms[].{Name:AlarmName,Metric:MetricName,\
Threshold:Threshold,Periods:EvaluationPeriods,Missing:TreatMissingData,\
State:StateValue,Actions:AlarmActions[0],Enabled:ActionsEnabled}" \
  --output table

結果の読み方

こういう状況で使います

• 障害を顧客からの連絡で知ることがある
• アラートが多すぎて、重要なものが埋もれている
• 夜間と休日に誰が対応するかが決まっていない
• アラートは届くが、受け取った人が何をすればよいか分からない
• 監視は入れているが、何を監視しているのか一覧がない
• CPU使用率のような分かりやすい指標だけを見ていて、ロック待ちやレプリケーション遅延を見ていない

考えられる原因（可能性の高い順）

1. 01

   3種類の監視が区別されていない

   死活監視（プロセスやエンドポイントが応答するか）、性能監視（応答はするが遅くなっていないか）、ログ監視（エラーが出ていないか）は目的も検知できる事象も違います。どれか1つだけでは、他の2種類が検知する障害を見逃します。

2. 02

   内部指標しか見ていない

   CPU・メモリ・接続数がすべて正常でも、DNS、ロードバランサ、証明書、アプリケーションの例外、外部連携先の障害によって利用者からは使えない状態になり得ます。内部指標をいくら増やしてもこの経路は監視できません。

3. 03

   しきい値が単一の固定値で設計されている

   「CPU 80%を超えたら通知」のような単発条件は、平常時の山でも鳴ります。鳴りすぎるアラートは無視されるようになり、結果として本物のアラートも見逃されます。継続時間（何回連続で超えたか）と変化率（普段との差）を条件に組み込む必要があります。

4. 04

   アラートに対応手順が紐づいていない

   通知を受け取った人が何を確認し、どこまでを自分で対応し、どの条件でエスカレーションするかが決まっていないと、通知は「気づき」で止まり対応につながりません。

5. 05

   夜間・休日の体制が設計されていない

   24時間監視は「監視ツールが24時間動いている」ことではなく「24時間、対応できる人に届く」ことです。オンコールの当番、連絡がつかない場合の次の連絡先、対応者の負荷分散が決まっていないと、深夜の通知は翌朝まで放置されます。

6. 06

   監視設定が棚卸しされていない

   通知先が退職者のアドレスのまま、アクションが無効のまま、対象リソースが削除済みのまま、といった設定は「あるのに機能しない監視」になります。設定した時点では正しくても、時間とともに劣化します。

確認手順

1. 1

   監視対象の一覧を作る

   参照のみ

   ホスト・データベース・アプリケーションの各層で、現在何を監視しているかを一覧化します。抜けを議論する前に現状を可視化します。

2. 2

   外形監視の有無を確認する

   参照のみ

   利用者が実際に通る経路（DNS→LB→アプリ→DB）を外部から確認する監視があるかを確認します。無ければ最優先の追加項目です。

3. 3

   アラームの棚卸しを行う

   参照のみ

   `describe-alarms` で、無効化されているもの、通知先が空のもの、長期間 INSUFFICIENT_DATA のものを洗い出します。

4. 4

   過去のアラート発報数を数える

   参照のみ

   直近1か月に何件鳴り、そのうち何件が対応を要したかを数えます。対応不要の比率が高いなら、しきい値設計が原因です。

5. 5

   過去の障害が何で検知されたかを振り返る

   参照のみ

   直近の障害について、監視が先に検知したか、利用者からの連絡が先だったかを確認します。後者があれば監視の穴が特定できます。

6. 6

   エスカレーション経路を書き出す

   参照のみ

   一次対応者、二次対応者、連絡がつかない場合の代替、判断が必要な場合の責任者を明文化します。

7. 7

   アラームを追加する

   低

   不足している項目について `put-metric-alarm` でアラームを作成します。作成前に通知先とランブックを用意します。

対応方法

バージョン・環境による違い

これで解決しない場合に確認すること

• 通知が実際に届くかを試験する

  テスト通知を送り、深夜帯を含めて受信者に届くかを確認します。設定上は正しくても、受信側のフィルタで落ちていることがあります。

• 監視対象から漏れたリソースがないか確認する

  新規に作成されたインスタンスが監視設定に含まれているかを定期的に確認します。作成時にアラームを付ける自動化が有効です。

• 過去の障害を監視項目に反映する

  発生した障害それぞれについて「この監視項目があれば先に気づけたか」を検証し、不足していた項目を追加します。

• アラートの発報件数を定期的に振り返る

  対応不要のアラートが多いなら、しきい値か監視項目そのものを見直します。件数の推移自体を指標にします。

• ランブックの内容が現状と合っているか確認する

  構成変更後もランブックが更新されていないと、対応手順が実態と食い違います。定期的な更新の担当を決めてください。

この文書の根拠と限界

よくある質問

この文書がカバーする質問

• 顧客が先に障害を発見する状況を防ぐ方法
• データベース監視で見るべき指標が知りたい
• アラートが多すぎて対応できない
• 夜間・休日の障害対応体制をどう作るか

リスク表示の意味

• 参照のみデータと設定を変更しません。
• 低影響は限定的ですが、権限と負荷の確認が必要です。
• 中性能・ロック・コストに影響する可能性があります。
• 高障害・データ損失・復旧作業が発生する可能性があります。
• 専門家レビュー必須本番適用前に別途レビューが必須です。

GIIPの対応範囲

監視項目の一覧を作ること自体は設計作業で終わります。24時間監視が難しいのは、深夜と休日に人が起きていること、そして届いたアラートに対して判断ができることの2点です。GIIPではAWSとAzure上の複数データベースおよび約30のWebサービスについて、一次切り分け（メトリクスの突き合わせ、直近の変更履歴の確認、影響範囲の特定）をAIエージェントが担当し、再起動やフェイルオーバーのように取り返しのつかない判断は人間の専門家が行う分担で運用しています。人が24時間張り付く前提を置かずに、対応の初動だけは常時動く状態を作るという考え方です。

関連サービス

• 24時間監視の対象を確認する
• 障害対応の初動を任せる
• AIインフラ運用