Prometheusで アプリケーション モニタリング 宍戸展志

今日の内容 ● 監視とは ● Prometheus ○ ruby_client ● アプリケーションのメトリクスを見てみる ● まとめ

監視（モニタリング） ● サービスを提供しつづけられるかをチェック ○ ある機能が正しく動いているか？（現在） ○ 動いているシステムのリソース状況は？（過去 /未来予測）

監視（モニタリング） ● 死活監視 ○ ある機能が正しく動いているか？ ○ 例）https://medley.life に外部からアクセスし正常な応答が返ってくるか ● リソース監視 ○ アプリケーションの稼働環境の資源の使用状況に問題が無いか？ ○ 例）cpu、memory、disk、network使用率 ● アプリケーション監視 ○ アプリケーション固有の情報の監視 ○ 例）レスポンスタイム、エラー率、機能の利用比率、内部リソースの使用状況 ○ New Relic APM、Datadog

監視（モニタリング） ● どんなツールを使っていますか？ ● 最近はOSSやサービスとして多種多様なツール群が存在 ● 目的に応じて選んでいく

Prometheus

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で書かれた構成コンポーネント

Prometheus ● 特徴 ○ 多次元のデータモデル ○ クエリ言語 ○ データの保存を分散ストレージに依存しないシンプルさ ○ pull型のデータ収集モデル ○ Pushgateway ○ Service Discoveryによる監視対象の動的な検知

Prometheus - 特徴 ● データモデル ○ 形式 ■ {=, ...} ○ metric nameは例えば http_request_total のような測定される項目の一般名称？が良い ○ label name, label valueは次元モデルを生成する項目 ■ この項目を使って後述するクエリの条件を記述できる

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)

再掲：監視（モニタリング） ● 死活監視 ○ ある機能が正しく動いているか？ ○ 例）https://medley.life に外部からアクセスし正常な応答が返ってくるか ● リソース監視 ○ アプリケーションの稼働環境の資源の使用状況に問題が無いか？ ○ 例）cpu、memory、disk、network使用率 ● アプリケーション監視 ○ アプリケーション固有の情報の監視 ○ 例）レスポンスタイム、エラー率、機能の利用比率、内部リソースの使用状況 ○ New Relic APM、Datadog

アプリケーションメトリクス ● アプリケーションの稼働状況 ○ APIごとのレスポンスタイム ○ APIごとのエラーレート（数） ○ 内部リソースの使用率 ● CloudWatch Logsでもエラーレートなどは取得可能らしい ● Prometheusでは投入しておいたデータに対してクエリを発行できる ○ モニタリングする内容をカスタマイズできる ○ 設計大事 ● 注意）ノイズに本当に見たいものが埋もれないかどうか ○ たまに遅いとかたまにコケるとか ○ ◯◯毎に、ではなく特定のエンドポイントに監視対象を絞ったりなど ○ 傾向だけわかれば良い場合はサンプリングで良い（全データを扱わない）

アプリケーションメトリクス ● 導入 ○ 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 ○ 必要に応じて特定の処理のタイミングで自分で定義したメトリクスを取ることも可能

アプリケーションメトリクス ● 直近5分のAPIエンドポイントごとのレイテンシ ○ rate(http_server_request_duration_seconds_sum{path=~"/api.*"}[5m]) / rate(http_server_request_duration_seconds_count{path=~"/api.*"}[5m]) ● リリース直後にパフォーマンスが・・・！とかはこれ見ると一目でわかる ○ そもそもテストしとけとかそういうのはあると思います、はい

アプリケーションメトリクス ● APIエンドポイント毎のエラー数 ○ sum(http_server_requests_total{job="rack-example", code!~"^2..$", path=~"/api.*"} offset 10m ) by (path) ○ 外部からの不正な（リクエストパラメータ間違ってるとかも含めて）アクセスがあることなどに気づけ る ■ 経験）死んだaccess tokenでめっちゃAPI叩いてるやつが居るっぽい、とか

アプリケーションメトリクス ● APIエンドポイントの様子を可視化しておくと異常に気づける ● 必要に応じて通知するようにすればなお良い ● プロダクトの初期から必要かというと...？

まとめ ● 監視大事 ○ 何を見るべきかはアプリケーションによる ● Prometheusを使ってアプリケーションのパフォーマンス情報を可視化 ● アプリケーション自身の情報を日頃見ておくの大事だと思う ○ 問題を早期にみつけることができる（かもしれない） ○ 実装するときに気をつけるポイントがわかる（かもしれない） ○ 放ったらかしておいても大丈夫ならそれに越したことはないけど！

ありがとうございました