Prometheusでアプリーケーションモニタリング /prometheus

D879794ea42768ea417f970914430d56?s=47 Medley Inc.
December 08, 2017

Prometheusでアプリーケーションモニタリング /prometheus

メドレー開発本部の社内勉強会「TechLunch」で発表した内容を掲載しました。
Prometheusを使ったアプリケーションのモニタリングについて発表する機会がありましたので、その内容を紹介したものです。

発表者:宍戸 展志

D879794ea42768ea417f970914430d56?s=128

Medley Inc.

December 08, 2017
Tweet

Transcript

  1. 4.

    監視(モニタリング) • 死活監視 ◦ ある機能が正しく動いているか? ◦ 例)https://medley.life に外部からアクセスし正常な応答が返ってくるか • リソース監視

    ◦ アプリケーションの稼働環境の資源の使用状況に問題が無いか? ◦ 例)cpu、memory、disk、network使用率 • アプリケーション監視 ◦ アプリケーション固有の情報の監視 ◦ 例)レスポンスタイム、エラー率、機能の利用比率、内部リソースの使用状況 ◦ New Relic APM、Datadog
  2. 7.

    Prometheus • 監視対象に関する時系列データを収集・保存・可視化 ◦ 通知機能などをはじめ機能が盛り沢山 ◦ 幅広い監視対象 • SoundCloudが当初開発 ◦

    2012年ごろからossとして ◦ 2016年からCloud Native Computing Foundationで運営 • 現在のバージョン 1.7.1 ◦ 2系の開発も進んでいる ◦ 先日2.0リリースされました ◦ https://prometheus.io/blog/2017/11/08/announcing-prometheus-2-0/ • Goで書かれた構成コンポーネント
  3. 8.

    Prometheus • 特徴 ◦ 多次元のデータモデル ◦ クエリ言語 ◦ データの保存を分散ストレージに依存しないシンプルさ ◦

    pull型のデータ収集モデル ◦ Pushgateway ◦ Service Discoveryによる監視対象の動的な検知
  4. 9.

    Prometheus - 特徴 • データモデル ◦ 形式 ▪ <metric name>{<label

    name>=<label value>, ...} ◦ metric nameは例えば http_request_total のような測定される項目の一般名称?が良い ◦ label name, label valueは次元モデルを生成する項目 ▪ この項目を使って後述するクエリの条件を記述できる
  5. 10.

    Prometheus - 特徴 • クエリ言語 ◦ 一番シンプルには、前述の「 metrics name」のみを指定するだけでも OK

    ◦ 例) ▪ http_requests_total{job="prometheus",group="canary"} ▪ sum(http_requests_total{method="GET"} offset 5m) ▪ rate(http_requests_total[5m] offset 1w)
  6. 11.

    再掲:監視(モニタリング) • 死活監視 ◦ ある機能が正しく動いているか? ◦ 例)https://medley.life に外部からアクセスし正常な応答が返ってくるか • リソース監視

    ◦ アプリケーションの稼働環境の資源の使用状況に問題が無いか? ◦ 例)cpu、memory、disk、network使用率 • アプリケーション監視 ◦ アプリケーション固有の情報の監視 ◦ 例)レスポンスタイム、エラー率、機能の利用比率、内部リソースの使用状況 ◦ New Relic APM、Datadog
  7. 12.

    アプリケーションメトリクス • アプリケーションの稼働状況 ◦ APIごとのレスポンスタイム ◦ APIごとのエラーレート(数) ◦ 内部リソースの使用率 •

    CloudWatch Logsでもエラーレートなどは取得可能らしい • Prometheusでは投入しておいたデータに対してクエリを発行できる ◦ モニタリングする内容をカスタマイズできる ◦ 設計大事 • 注意)ノイズに本当に見たいものが埋もれないかどうか ◦ たまに遅いとかたまにコケるとか ◦ ◯◯毎に、ではなく特定のエンドポイントに監視対象を絞ったりなど ◦ 傾向だけわかれば良い場合はサンプリングで良い(全データを扱わない)
  8. 13.

    アプリケーションメトリクス • 導入 ◦ gem ‘prometheus-client’ ◦ Prometheus::Middleware::Exporter, Prometheus::Middleware::Collectorの利用設定 ▪

    application.rbに書くだけ ◦ 幾つかのメトリクスはこれだけで取得できる ▪ http_server_requests_total ▪ http_server_request_duration_seconds_bucket ▪ http_server_request_duration_seconds_sum ▪ http_server_request_duration_seconds_count ▪ http_server_exceptions_total ◦ 必要に応じて特定の処理のタイミングで自分で定義したメトリクスを取ることも可能
  9. 15.

    アプリケーションメトリクス • APIエンドポイント毎のエラー数 ◦ sum(http_server_requests_total{job="rack-example", code!~"^2..$", path=~"/api.*"} offset 10m )

    by (path) ◦ 外部からの不正な(リクエストパラメータ間違ってるとかも含めて)アクセスがあることなどに気づけ る ▪ 経験)死んだaccess tokenでめっちゃAPI叩いてるやつが居るっぽい、とか
  10. 17.

    まとめ • 監視大事 ◦ 何を見るべきかはアプリケーションによる • Prometheusを使ってアプリケーションのパフォーマンス情報を可視化 • アプリケーション自身の情報を日頃見ておくの大事だと思う ◦

    問題を早期にみつけることができる(かもしれない) ◦ 実装するときに気をつけるポイントがわかる(かもしれない) ◦ 放ったらかしておいても大丈夫ならそれに越したことはないけど!