監視

前回の記事で「サーバー監視の王道スタック」として Prometheus + Loki + Grafana + Alloy を整理しました。アラート設計のセクションで触れた Grafana OnCall について、改めて単独で深掘りします。 ただし重要な注意点があります — Grafana OnCall OSS（grafana/oncall リポジトリ）は 2026 年 3 月 24 日にアーカイブされました。後継は **Grafana Cloud IRM（Incident Response Management）**で、OnCall と Incident の両アプリが 1 つに統合されています。 「Grafana OnCall を新規導入したい」「既存環境を移行すべきか」という人に向けて、何が終わって、何が始まったのかを整理します。 Grafana OnCall とは何だったのか Grafana OnCall は 「アラートが鳴った後の対応フロー」を管理するツールでした。 Prometheus / Loki / Grafana が「異常を検知する」までを担当 Grafana OnCall は「鳴ったアラートを誰に・どうやって届け、どう対応するか」を管理 PagerDuty や Opsgenie の OSS 互換ツールとして、Grafana エコシステムの中で重要なポジションを占めていました。 主な機能（当時） アラートの集約とルーティング — 複数の監視システムからのアラートを統合、内容に応じてチームへ振り分け オンコールシフト管理 — 担当者のカレンダー（シフト表）に従って当番者にだけ通知 エスカレーションポリシー — 一定時間応答がなければ次の担当者へ自動エスカレーション ChatOps 連携 — Slack / Telegram 上でアラート確認・対応開始（Acknowledge）・解決（Resolve）が完結 柔軟な通知手段 — Slack / Microsoft Teams / SMS / 自動音声通話（電話）/ モバイルプッシュ IaC 対応 — Terraform プロバイダで設定をコード管理可能 連携先（インテグレーション） カテゴリ 代表的な連携先 監視・アラート検知 Grafana, Prometheus (Alertmanager), Datadog, Zabbix, AWS CloudWatch, New Relic 通知・コミュニケーション Slack, Microsoft Teams, Telegram, SMS, 自動音声通話 OSS 版で自社サーバーに構築することも、Grafana Cloud のマネージドサービスとして利用することも可能でした。 ...

サーバー監視は「死活監視 + リソース監視」の時代から、「メトリクス + ログ + トレース」を 1 つの画面で相関分析するオブザーバビリティの時代に移りました。クラウドネイティブ環境では、Grafana Labs の OSS スタック（Prometheus + Loki + Grafana + Alloy）が、コスト・自由度・運用ノウハウの蓄積において事実上の王道になっています。 この記事では、なぜこの組み合わせが現代の標準なのか、各コンポーネントがどう役割分担しているのか、そして最小構成から本番運用までの全体像を整理します。 なぜこの構成が「王道」なのか サーバー監視の選択肢は大きく分けて 3 系統あります。 カテゴリ 代表例 特徴 OSS スタック（Grafana Labs） Prometheus + Loki + Grafana + Alloy 無料、自由度高、運用責任は自分で OSS スタック（Elastic） Elasticsearch + Logstash + Kibana + Beats 全文検索が強力、コストとリソース消費が大 SaaS Datadog、New Relic、Grafana Cloud 楽だが高価、データ主権がない このうち Prometheus + Loki + Grafana + Alloy が王道とされる理由: ...

概要 時系列メトリクスの可視化とダッシュボード作成の標準ツール。CloudWatch・Prometheus・Graphite など複数データソースに対応。AWS コスト可視化では IAM ユーザー + CloudWatch データソースで実現。

AWS DMS Serverless Replication（CDC モード）が OOM（Out of Memory）で failed 状態になり、自動再起動の仕組みが検知できずに長期間停止していた問題について、根本原因と対策をまとめます。 構成 RDS (MySQL) → DMS Serverless (CDC) → S3 (Parquet) DMS Serverless Replication で全テーブルの CDC（Change Data Capture）を実行 S3 に Parquet 形式で日付パーティション付きで出力 EventBridge + Lambda で DMS 停止を検知し自動再起動する仕組みを構築済み 発生した事象 症状 prod 環境の DMS Serverless Replication が failed 状態で停止 エラーメッセージ: Replication out of memory. Stop Reason FATAL_ERROR Error Level FATAL CDC が完全に停止し、S3 へのデータ同期が止まっていた 発覚の経緯 手動確認で発見。自動再起動 Lambda の最終実行は約2ヶ月前で、それ以降は検知されていなかった。 根本原因 原因 1: EventBridge ルールのイベントパターンが不完全 自動再起動用の EventBridge ルールが REPLICATION_TASK_STOPPED のみを監視していた。 ...