서버와 데이터베이스를 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종류의 모니터링이 구분되지 않음

   생사 확인 모니터링(프로세스나 엔드포인트가 응답하는지), 성능 모니터링(응답은 하지만 느려지지 않았는지), 로그 모니터링(오류가 발생하지 않았는지)은 목적도 감지할 수 있는 사건도 다릅니다. 어느 하나만으로는 다른 두 가지가 감지하는 장애를 놓치게 됩니다.

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

   에스컬레이션 경로 작성하기

   参照のみ

   1차 대응자, 2차 대응자, 연락이 닿지 않을 경우의 대체, 판단이 필요한 경우의 책임자를 문서화합니다.

7. 7

   알람 추가하기

   低

   부족한 항목에 대해 `put-metric-alarm`으로 알람을 생성합니다. 생성 전에 통지 대상과 런북을 준비합니다.

対応方法

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

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

• 통지가 실제로 도착하는지 시험하기

  테스트 통지를 보내 심야 시간대를 포함해 수신자에게 도착하는지 확인합니다. 설정상은 올바르더라도 수신 측의 필터로 걸러지는 경우가 있습니다.

• 모니터링 대상에서 빠진 리소스가 없는지 확인하기

  새로 생성된 인스턴스가 모니터링 설정에 포함되어 있는지 정기적으로 확인합니다. 생성 시 알람을 붙이는 자동화가 유효합니다.

• 과거 장애를 모니터링 항목에 반영하기

  발생한 장애 각각에 대해 "이 모니터링 항목이 있었다면 먼저 알아챌 수 있었을지"를 검증하고 부족했던 항목을 추가합니다.

• 알림 발생 건수를 정기적으로 되돌아보기

  대응 불필요한 알림이 많다면 임계값이나 모니터링 항목 자체를 재검토합니다. 건수의 추이 자체를 지표로 삼습니다.

• 런북의 내용이 현재 상황과 맞는지 확인하기

  구성 변경 후에도 런북이 갱신되지 않으면 대응 절차가 실제와 맞지 않게 됩니다. 정기적인 갱신 담당을 정하십시오.

この文書の根拠と限界

よくある質問

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

• 고객이 먼저 장애를 발견하는 상황을 막는 방법
• 데이터베이스 모니터링에서 봐야 할 지표를 알고 싶다
• 알림이 너무 많아 대응할 수 없음
• 야간·휴일 장애 대응 체계를 어떻게 만드는가

リスク表示の意味

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

GIIPの対応範囲

모니터링 항목 목록을 만드는 것 자체는 설계 작업으로 끝납니다. 24시간 모니터링이 어려운 것은 심야와 휴일에 사람이 깨어 있는 것, 그리고 도착한 알림에 대해 판단할 수 있는 것이라는 두 가지입니다. GIIP에서는 AWS와 Azure 상의 여러 데이터베이스 및 약 30개의 웹 서비스에 대해 1차 분리(메트릭 대조, 최근 변경 이력 확인, 영향 범위 특정)를 AI 에이전트가 담당하고, 재시작이나 장애 조치처럼 되돌릴 수 없는 판단은 사람인 전문가가 수행하는 분담으로 운영하고 있습니다. 사람이 24시간 붙어 있다는 전제를 두지 않고 대응의 초동만은 항상 동작하는 상태를 만든다는 사고방식입니다.

関連サービス

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