Prometheus: Go言語で書かれたモニタリングシステム

https://developers.soundcloud.com/blog/prometheus-monitoring-at-soundcloud

1 comment | 0 points | by WazanovaNews 2年弱前 edited


Jshiike 2年弱前 edited | ▲upvoteする | link

Prometheusは、SoundCloudが中心となって開発を進めているオープンソースのプロジェクト。Dockerの社内でもメインのモニタリングシステムとして利用されているようです。

各社のブログのエントリーから、その特徴をまとめると。

  • 多元データモデルとそれを活かす柔軟なクエリ言語
    • 全てのデータにタイムスタンプのある、OpenTSDBに準じたデータモデル。
    • http_response_500_totalhttp_response_403_totalなどHTTPレスポンスのステータスごとに用意しなくても、ラベルで分類できる。api_http_requests_total{method="GET", endpoint="/api/tracks", status="200"}
    • コンテナの分析の例として、「同じ名称のコンテナのデータをまとめたいが、特定のイメージだけを選別する。」「本番マシンのデプロイと本番内の一部ユーザだけに露出するカナリア版を比較する。」「時間軸 / 正規表現でのフィルタリング、ホスト / 環境 / ゾーン別の分析」など、柔軟な切り口での分析をサポート。データをまとめることに関してはGraphiteよりも良い。
    • インスタンスごとにメモリ消費 / メモリ上限 / CPU消費 / アウトオブメモリエラー / インスタンスの再起動などを確認する際に、さらにアプリごと / プロセスタイプ / Gitの修正履歴 / 環境 / インスタンスIDなどで分類できる。直近5分のCPU利用上位をアプリごと、プロセスタイプごとに集計したり。デバッグや、設定ミスの発見がたやすくなる。また、分析に時間がかかるものは、バックグランドで事前に計算もできる。
  • ダッシュボード
    • 柔軟なクエリ言語が活きる。
    • GUIベースのダッシュボードビルダー + SQLバックエンド。設定が容易。HTTP API経由で複数のPrometeusサーバとやりとりが可能。Graphiteのグラフの組み込みも可能。
    • コンソールテンプレでシンプルにつくることもできる。
    • 複数モードでのビジュアル化やダッシュボードをサポート。
  • アラート通知
    • クエリ言語を活かし粒度を柔軟に設定。
    • Alertmanagerを介して通知とその取りまとめを行う。Prometheusの他の機能と比較すると、完成度という意味でまだ改善の余地あり。
    • Nagiosのプラグインあり。
  • システム関連情報
    • Prometheusスタイルのモニタリングはコードをダイレクトに操作する。これは、「モニタリングされるアプリは、プラグインか、独自の言語でやりとりするエージェントを介しているので、モニタリングシステムのことを知らない。」というアプローチとは異なる。
    • Go / Java / Ruby向けのクライアントライブラリが用意されている。HTTPを介するプルモデルで、フォーマットは基本はprotocol bufferだが、シンプルなテキストフォーマットも利用でき、ライブラリいらず、つまりシェルスクリプトからも対応できる。
    • 従来のモニタリングのアプローチにも対応できるように、HAProxyやNodeのエクスポーターも用意している。AWS Cloudwatch連携あり。
    • 中間のゲートウェイを利用してタイムシリーズのプッシュもサポート。cronjobのような短命でスクレイプに間に合わないものには、データをプッシュするPushgateway機能がある。
    • 分散ストレージへの依存なし。単一のサーバnodeが自立している。
    • 何でも分散化という流れがあるが、実際問題はメンテは大変。毎秒、数百万のタイムシリーズと数万のサンプルを一つのサーバのローカルディスクで処理できるようにしている。機能ごとにサーバをシャードして、シャードを複数レプリしたものを実行することにより冗長性を担保。サーバ間のクエリはできないが、階層的なスキームをつくり、上位のPrometheusサーバが下位のサーバから特定のデータを集める仕組みができる。ローカルのタイムシリーズDBは、インデックスと実際のサンプル値とタイムスタンプの保管にはLevelDBを採用。PrometheusのエコシステムをOpenTSDBのコレクションマシーナリーに変えることで、永続的なストレージとして集めたサンプルをOpenTSDBにストリーミングする仕組みを実験的につくっている。将来的にはPrometheusからのクエリでOpenTSDBからデータを読み込めるようにして、ラウンドトリップを実現したい。他のタイムシリーズDBのサポートの可能性もあるが、データモデルの違いがけっこうチャレンジである。
    • サービスディスカバリもしくは静的な設定でターゲットを見つけられる。
    • 分散ストレージバックエンドや再設定の手間なし、モニタリングサーバを必要なところ(ローカルのワークステーションでも)で立ち上げられる簡単さ。
    • スケーラブルで分散アーキテクチャ、別のチームが独自のモニタリングシステムを立ち上げることも可能。
  • パフォーマンス
  • ランニングコストの低さ
    • Boxever社のケースでは、タイムシリーズのスクレイプは、Amazon m1.largeは毎分50万件程度までスケールでき、6ヶ月保管するとして、タイムシリーズあたりのコストは月間$0.001程度。

[参考]

http://www.boxever.com/tag/monitoring

http://5pi.de/2015/01/26/monitor-docker-containers-with-prometheus/


2014 Topアクセスランキング


Back