レガシー監視基盤から
可観測性基盤への刷新
個別に監視する仕組みから、システム全体を観測し続ける基盤へ。長期間運用されてきたシステム監視基盤を、Kubernetesを中心としたモダンな可観測性基盤へ段階的に刷新しました。
従来はMunin、Nagios、Cacti、syslog-ngなどを組み合わせ、ホストや個別サービスごとに監視項目とアラート条件を設定する構成でした。CoRISEは既存の監視基盤を一度に置き換えるのではなく、その役割を整理しながら、Prometheus、Thanos、Grafana、Vector、Loki、OpenTelemetry、Alertmanagerを中心とする構成へ段階的に移行しました。
- Kubernetes
- Prometheus
- Thanos
- Grafana
- Vector
- Loki
- OpenTelemetry
- Alertmanager
- Nix / NixOS
01 / MIGRATION
レガシー監視基盤からの段階的な移行
一度に置き換えるのではなく、既存の役割を整理しながら移行。
02 / PLATFORM
Kubernetes上で宣言的に管理する可観測性基盤
Prometheus、Thanos、Grafana、Vector、Loki、OpenTelemetryを中核に構成。
03 / OPERATIONS
監視基盤自身の更新・保守まで継続運用
Nixを利用したコンポーネント管理と、監視基盤自身の監視。
Background
「サーバが動いているか」から、「サービスがどう動いているか」へ。
従来の監視基盤は、サーバ、プロセス、ネットワーク、個別メトリクスなどを監視し、定められた条件を超えた場合に通知する、実績のある構成でした。しかし、コンテナやKubernetesを利用した動的な環境では、監視対象そのものが継続的に変化します。
重要になるのは、個々のホストを監視することだけではなく、次を継続的に把握できることです。
- サービス全体がどのような状態にあるか
- どのコンポーネントで異常が発生しているか
- その兆候がいつから現れているか
- メトリクス、ログ、トレースをどのように関連づけるか
- 障害が利用者にどのような影響を与えているか
そこで、監視対象を個別に登録するモデルから、システム自身が観測データを公開し、それを共通基盤で収集・評価するモデルへ移行しました。
Before
ホスト中心・個別設定型の監視。
旧環境ではMunin、Nagios、Cacti、syslog-ngを利用。それぞれが重要な役割を担っていましたが、運用モデルとしては比較的静的でした。
↔ 横にスクロールして図全体をご覧いただけます。
図を文章で読む
ホストからMunin，Cacti，Nagios，syslog-ngへ分岐します。それぞれMetrics，Metricsとグラフ，ChecksとAlerts，Logsを扱います。この環境での個別管理を表す概念図であり，各ツールの連携能力の制限を示すものではありません。
安定して動作していた一方で、システム規模や構成の変化に伴い、次の課題が顕在化していました。
- 監視対象や設定の追加に手作業が必要になる
- メトリクスとログが分断される
- ホスト単位の監視ではサービス全体の状態を捉えにくい
- 長期間のメトリクス保持と横断的な分析が難しい
- 監視基盤そのものの構成変更や更新にも運用負荷がかかる
After
Kubernetes上で宣言的に管理する可観測性基盤。
新しい基盤では、観測データの役割ごとにコンポーネントを整理しました。
METRICS
Prometheus
サービス、インフラストラクチャ、Kubernetesからメトリクスを収集し、PromQLによって状態を評価します。
監視対象を静的に列挙するのではなく、Kubernetesのサービスディスカバリーなどを利用し、環境の変化に追従できる構成へ移行しました。
LONG-TERM METRICS
Thanos
Prometheusのメトリクスを長期間保持し、複数のPrometheus環境を横断して検索できる構成を採用しました。短期的な異常検知だけでなく、次の分析にも利用できる基盤です。
- 長期的な傾向
- 処理能力・容量の計画
- 過去障害との比較
- 季節性
- リソース利用の変化
VISUALIZATION
Grafana
メトリクスやログを横断して参照する共通の可視化層として利用。単なるグラフ表示ではなく、運用者がシステム状態を理解するための共通インターフェースとして位置づけています。
LOGS
Vector + Loki
コンテナやシステムから発生するログをVectorで収集・変換し、Lokiへ送信する構成を採用。Vectorでは収集だけでなく、解析・選別・情報の付加・振り分けを担わせ、アプリケーションや環境による差を吸収します。
LokiはGrafanaとの統合を前提としたログ検索基盤として利用し、メトリクスから異常を発見した後、その時間帯のログへ自然に移動できる運用を目指しました。
TELEMETRY STANDARDIZATION
OpenTelemetry
新しいアプリケーションや分散システムでは、OpenTelemetryを観測データの標準的な入口として採用。メトリクス、ログ、トレースを個別の監視製品へ直接依存させるのではなく、計装とバックエンドを分離できる構造にしています。
ALERTING
アラートルール + Alertmanager
アラート条件をメトリクスと同じ宣言的な仕組みで管理し、Alertmanagerで通知のグループ化、振り分け、通知の抑制などを扱います。単純に「閾値を超えたら通知する」のではなく、次を運用ルールとしてコード化しました。
- どの状態を異常とみなすか
- どの程度継続した場合に通知するか
- 関連するアラートをどうまとめるか
- 誰に通知するか
Architecture
観測データの経路を、一つの系として設計する。
↔ 横にスクロールして図全体をご覧いただけます。
図を文章で読む
アプリケーション・インフラのMetricsをPrometheusが収集し，Thanosが長期保持と横断検索を支えます。LogsはVectorからLokiへ送られます。GrafanaはMetricsとLogsを参照します。OpenTelemetryによるInstrumentationからCollectorへ送られたTelemetryはBackendへ転送されます。Collector自体はトレース保存・検索基盤ではありません。アラートはPrometheusで評価し，Grafanaを経由せずAlertmanagerから運用者へ通知します。構成要素とデータの関係を示す概念図です。
Declarative Operations
監視設定そのものを、運用可能なソフトウェアへ。
刷新の重要な目的の一つは、ツールを新しくすることではなく、監視基盤そのものを再現・変更・レビュー可能にすることでした。監視対象、アラートルール、ダッシュボード、KubernetesリソースなどをYAMLや構成ファイルとして管理し、変更履歴をGit上に残せる形へ移行しました。
- 誰が何を変更したか分かる
- レビューできる
- 同じ構成を再現できる
- 更新を自動化できる
- ロールバックしやすい
↔ 横にスクロールして図全体をご覧いただけます。
図を文章で読む
監視対象・ルール・Dashboardなどの構成をGitで管理し，レビューと変更を経て宣言的な構成としてKubernetesへ反映します。
From Monitoring to Observability
異常を知らせるだけでなく、原因を調べられる基盤へ。
旧来の監視では「何かがおかしい」ことを検出することが中心でした。新しい可観測性基盤では、検知 → 状況把握 → 調査 → 診断 → 改善までを一続きの運用体験として考えました。
↔ 横にスクロールして図全体をご覧いただけます。
図を文章で読む
Detection（検知），Context（状況把握），Investigation（調査），Diagnosis（診断），Improvement（改善）が順に進みます。改善から検知へ戻る矢印は，知見を監視ルールへ反映する関係を示します。
たとえば障害対応は、次の流れをたどります。
- 01Prometheusのメトリクスから異常を検知する
- 02Grafanaで関連メトリクスを確認する
- 03同じ時間帯のLokiのログを確認する
- 04必要に応じてトレースを確認する
- 05Kubernetesの状態を確認する
- 06原因を修正する
- 07新たなメトリクスやアラートへ知見を反映する
障害対応で得られた知識を、次の監視ルールやダッシュボードへ戻すことで、監視基盤自体を継続的に改善できるようにしました。
Monitoring the Monitoring System
監視基盤そのものも、本番システムとして扱う。
可観測性基盤が停止すれば、障害時に最も必要な情報が失われます。そのため、監視対象のシステムだけでなく、監視基盤自身の状態も監視対象としました。
監視システムを「補助ツール」ではなく、本番基盤の一部として扱っています。
- Prometheus
- Thanos
- Grafana
- Loki
- Vector
- OTel Collector
- Alertmanager
- Kubernetes
- etcd
Kubernetes Lifecycle
動かすだけでなく、更新し続けられること。
可観測性基盤は自社運用のKubernetes上で運用されています。CoRISEは監視アプリケーションだけでなく、Kubernetesのコンポーネント、etcd、ミドルウェア、コンテナイメージ、構成、依存関係のライフサイクル管理にも関与しました。Nixを利用してKubernetesや関連ツールのバージョンを管理し、環境差異を減らしながら継続的な更新を行える構成としました。
- Kubernetesのコンポーネント
- etcd
- ミドルウェア
- コンテナイメージ
- 構成
- 依存関係
What Changed
刷新によって変わったのは、監視ツールの名前だけではありません。
Before
- ホスト中心の監視
- 静的な設定
- ツールごとの個別管理
- メトリクスとログの分断
- 閾値を中心としたアラート
- 手作業での設定変更
- 短期的な監視が中心
After
- サービス・基盤全体の可観測性
- Kubernetesの状態に追従する監視対象の検出
- 宣言的な構成管理
- メトリクス・ログ・トレースの関連付け
- Prometheusによるアラート評価
- Gitで管理する運用設定
- Thanosによるメトリクスの長期保持
- Lokiによるログの集約・分析
- OpenTelemetryによる計装
- 基盤の継続的な更新・保守
Outcome
変化に追従できる運用基盤へ。
この刷新によって目指したのは、単に新しい監視製品へ置き換えることではありませんでした。システム構成が変化しても監視基盤が追従できること。問題が起きたときに、通知だけでなく原因調査に必要な情報へ到達できること。運用で得られた知見を、監視設定やシステム設計へ戻せること。そして、監視基盤そのものを継続的に更新・改善できること。
監視を、変更可能で継続的に改善される技術基盤へ変えること — それが、この取り組みの中心でした。
CoRISEが担当したこと
この可観測性基盤の設計・構築・移行・継続運用に関わり、特に以下を担当しました。
- 01レガシー監視基盤からの段階的な移行
- 02Prometheusを中心としたメトリクス基盤
- 03Thanosによる長期メトリクス基盤
- 04Grafanaによる可視化
- 05Vectorによるログ収集パイプライン
- 06Lokiによるログ集約
- 07OpenTelemetryを利用した観測データの収集・参照構成
- 08アラートルール / Alertmanagerによる通知基盤
- 09Kubernetes上への可観測性基盤構築
- 10宣言的構成管理
- 11Nixを利用したコンポーネントのライフサイクル管理
- 12Kubernetes / etcdの継続運用
- 13可観測性基盤自身の監視
- 14ミドルウェアの更新
- 15継続的な運用改善
Technologies
- Kubernetes
- Nix / NixOS
- Prometheus
- Thanos
- Grafana
- Vector
- Loki
- OpenTelemetry
- Alertmanager
- etcd
- Git
- YAML