小規模なチームでPrometheus（メトリクス収集・監視の代表的OSS）とGrafana（ダッシュボード可視化ツール）を中心にした自前監視基盤を運用しているなら、この記事は判断材料になるかもしれません。監視をSaaSから自前運用（セルフホスト）に切り替えたあと、「気づけば監視自体が止まっていた」という状態に陥る構造を整理し、確認方法と対策までまとめます。
自前監視への移行理由は大きく2つに分かれます。データを社外に出せないコンプライアンス要件か、SaaS型監視サービスの従量課金がホスト数増加とともに膨らみすぎた場合です。どちらも合理的な判断ですが、落とし穴は「自前監視」が実質1個のサービスではなく5個のサービス群になる点にあります。
何が起きるか：気づかぬうちに監視が監視されなくなる
典型的な自前監視スタックは、ホストメトリクス用のPrometheus + node_exporter、可視化とアラート用のGrafana + Alertmanager、ログ収集用のLoki + Promtail、死活監視とステータスページ用のUptime Kuma、分散トレーシング用のTempoかJaegerという5系統に分かれます。
それぞれは単体では優秀なOSSです。しかし5つを組み合わせると、初期構築だけで丸1日、月次のパッチ適用に半日、四半期に1回はディスク逼迫や設定フォーマット変更絡みの障害対応が発生する計算になります。
プラットフォームチームがいる組織ならこの負荷は許容範囲です。問題は、開発と兼務でインフラ運用をしている少人数チームです。監視基盤のメンテナンスが後回しになり、いつの間にかアラートが飛ばなくなっていた、ダッシュボードのデータが数週間前で止まっていた、という状態に陥りやすくなります。
なぜ起きるか：5つのコンポーネントに潜む個別の運用コスト
原因を分解すると、コンポーネントごとに固有の「維持タスク」が存在することが見えてきます。
- Prometheus：保持期間（retention）のサイズ設計、カーディナリティ（メトリクスのラベル組み合わせ数）増加への対応、データ量が増えた際のリモートストレージ移行
- Grafana + Alertmanager：ダッシュボードのプロビジョニング、Infrastructure as Code的な構成管理、アラートのルーティング設計
- Loki + Promtail：チャンクストレージの管理、ラベル設計の規律維持、クエリ制限のチューニング
- Uptime Kuma：バックアップ対象のSQLiteデータベースがもう1個増える
- Tempo/Jaeger：オブジェクトストレージの運用とサンプリング率の調整
これらは個別に見れば小さなタスクですが、積み重なると「誰も専任で見ていない設定ファイルとバージョン差分」が各所に生まれます。特にPrometheusのカーディナリティ問題は厄介です。ラベルの組み合わせが増えるとメモリ使用量が指数関数的に膨らみ、ある日突然OOM（メモリ不足）でPrometheus自体が落ちるという事故につながります。
さらに構成管理の観点でも見落としが起きやすいポイントがあります。TerraformやPulumiでインフラをコード化していても、監視スタック側の設定（Grafanaのダッシュボード定義やAlertmanagerのルーティングルール）はコード管理の対象から漏れがちです。結果として「本番環境でしか動いているアラート設定」が生まれ、障害対応の再現性が失われます。
自分のプロジェクトが該当するか確認する方法
以下の観点で、現在の監視基盤が「気づかぬ形骸化」に近づいていないか確認できます。
# Prometheusのカーディナリティ状況を確認
curl -s http://localhost:9090/api/v1/status/tsdb | jq '.data.headStats'
# ディスク使用量とretentionの実態を確認
df -h /prometheus-data
cat /etc/prometheus/prometheus.yml | grep -A2 retentionチェックすべき項目は次の通りです。
- Alertmanagerの通知履歴を直近30日で確認し、意図せず通知が止まっている期間がないか
- Grafanaのダッシュボード設定がGitリポジトリで管理されているか、それとも管理画面上の手動編集のみか
- Loki/Promtailの設定ファイルが最後にいつ更新されたか（
git logでコミット履歴を確認） - 各コンポーネントのバージョンが公式最新版からどれだけ乖離しているか（
docker imagesやhelm listで確認） - 監視基盤自体を監視する仕組み（メタ監視）があるか。Prometheus自体が落ちたことを検知する別経路の有無
この最後の「メタ監視」の有無が、実は一番見落とされがちです。監視ツールが監視対象と同じ基盤上で動いていると、その基盤全体の障害時に監視もろとも沈黙します。
対策の手順
個別コンポーネント運用の負荷を下げる方向性は主に2つあります。
1つ目は、統合型の自前監視ソフトウェアへの切り替えです。ホストメトリクス・ログ・APM（アプリケーション性能監視）・ステータスページを1つのエージェントと1つのインストールにまとめる製品が存在します。設定不要のエージェントでホスト・プロセス・コンテナのメトリクスとログを同時収集し、HTTPトラフィックのパッシブキャプチャでコード変更なしにエンドポイント単位のエラー率とp95レイテンシを取得する、という設計思想です。
導入判断の基準としては、ステートフルな部分（データベース）を1つに集約できるかを見ると分かりやすいです。ある実装例では、20台規模のサーバーが30秒間隔でメトリクスとログを送信する構成で、月あたりのデータベース増加量は約2GBという実測値が示されています。これはPostgres1系統のみで完結する規模感です。
2つ目は、既存の5系統構成を維持しつつ、運用を仕組み化する方向です。具体的には以下を最低限セットで整備します。
- 全設定ファイル（Prometheusルール、Grafanaダッシュボード、Alertmanagerルーティング）をGitで管理し、CI/CDパイプラインで適用する
- SLO（サービスレベル目標）を明文化し、アラート条件をSLOのエラーバジェット消費速度に紐づける
- バックアップの自動化と復元テストを四半期ごとに実施する（Uptime KumaのSQLiteも対象に含める）
- 監視基盤自体の死活監視を、別ネットワークまたは外部サービスから独立して行う
統合型ソフトウェアを検討する際は、アップデートの安全性も確認ポイントです。たとえば2レプリカ構成でヘルスチェック通過を確認しながら1台ずつ切り替える方式なら、更新中に監視が完全停止する瞬間がありません。逆に単一インスタンス構成の製品であれば、更新作業自体がダウンタイムを伴う前提で計画する必要があります。
ライセンス方式を採用する製品を検討する場合は、ライセンス切れ時の挙動も必ず確認してください。切れた瞬間に監視が完全停止する設計だと、障害検知そのものが止まるリスクがあります。猶予期間を設けて読み取り専用モードに落とすような設計であれば、少なくとも「監視が止まったことに気づけない」事態は避けられます。
まとめ
自前監視基盤は、単一ツールの導入ではなく5系統のソフトウェア運用だという前提を持つことが出発点になります。
次に取れる行動としては、まずgit logで監視関連の設定ファイルが最後にいつ更新されたかを確認してみてください。数ヶ月以上更新がなければ、形骸化の兆候として扱う価値があります。
そのうえで、統合型ツールへの移行でコンポーネント数を減らすか、既存構成をIaCとSLO運用で仕組み化するか、自分のチームの体制に合わせて選ぶことになります。どちらを選んでも、監視基盤自体を監視するメタ監視の有無だけは、早めに確認しておく価値があります。