Slide 1

Slide 1 text

Prometheus を捨てない NewRelic の活用方法 (株)いい生活 多田 吉克@ta_dadada NRUG LT 2021.09.15 1

Slide 2

Slide 2 text

自己紹介 多田 吉克(Tada Yoshikatsu ) 所属:(株)いい生活 物件流通プラットフォーム本部 on EKS でサーバAPI の開発〜インフラ運用まで全般を担当 プロダクトローンチからしばらくは Prometheus + Grafana & NewRelic を手運用 していたが、しばらくして NewRelic を導入した 2

Slide 3

Slide 3 text

(株)いい生活 不動産業向けに統合型業務支援 クラウド・SaaS を中心に提供 (BtoB ) HP 作成サービス(CMS )など一 部のプロダクトでは(間接的 に) toC も提供 3

Slide 4

Slide 4 text

Talk Theme APM + Infra/Middleware Metrics をいい感じに NewRelic で統合するためのアイデア 自前構築から NewRelic 中心 の監視系に変えてきた 特にメトリクスの取り扱い方について 今 の考えをお話します 4

Slide 5

Slide 5 text

前提 監視の中心は APM に任せる サービスの品質をリッチに書き出すのに非常に役立つツール APM だけでは不足する情報をどうやって付け足していくか 5

Slide 6

Slide 6 text

APM に足りないもの アプリケーションの外側のメトリクス インフラメトリクス CPU 、Mem 、ネットワーク転送量 ミドルウェアメトリクス ロードバランサー(リクエスト成功数など) DB (CPU 、 Mem など) 6

Slide 7

Slide 7 text

案1 :NewRelic に全てお任せする NewRelic Infrastructure Agent with On-host integrations NewRelic で全て完結 クラウド含めた多くのインフラメトリクスやミドルウェアについてはカバーでき る 7

Slide 8

Slide 8 text

案2 :Prometheus (Exporter) を利用する Prometheus + Prometheus Integrations / Prometheus OpenMetrics integration メトリクスの収集は Prometheus で行い、データは NewRelic に蓄積する 8

Slide 9

Slide 9 text

Prometheus 的メトリクスを NewRelic に送信する Prometheus remote write integration Prometheus の remote write 機能の送信先として NewRelic を指定できる Prometheus を自前でホストする必要あり Prometheus OpenMetrics integration(nri-prometheus) Agent 自身がメトリクスを収集して NewRelic に送信する Prometheus をホストする必要はない 9

Slide 10

Slide 10 text

メトリクス収集を Prometheus に寄せるメリット 大抵のミドルウェアでは Prometheus Metrics 形式(OpenMetrics 形式)での metrics-exporter が OSS として公開されており流用できる NewRelic On-host integrations でも基本的なところは抑えられているのでそ の意味では十分かも 監視以外の用途に Prometheus を使う メトリクスストアとして活用して、オートスケールに利用する 保管場所に応じたメトリクスの解像度を調節できる <= 今日の趣旨 10

Slide 11

Slide 11 text

メトリクスの解像度問題 「モダンなシステム」にするほどメトリクスは増える 多種多様なクラウドリソース マイクロサービス化によるアプリケーションの絶対数の増加 サービスメッシュによる proxy サーバ の増加 さらに exporter は「要るのかわからない」大量のメトリクスを出力する 自前運用の監視系でこれを捌き切るにはチームの体力が相当必要 外部(NewRelic )に任せるにしてもそれなりにコストはかかる とはいえ、取捨選択は「やってみないとわからない」 11

Slide 12

Slide 12 text

全てのメトリクスが半永久的に必要か? TPO によって求められるメトリクスの解像度は変わる トラブルシュートなどでは、5s 毎の詳細なメトリクスで瞬間を捉えたい 普段の監視やトレンド確認では、ある程度サマリされた結果でも良いので中長期 的にふりかえりたい 例)SLI として1 分ごとのエラーレートを計測する 12

Slide 13

Slide 13 text

一旦 Prometheus を介す or Prometheus でも収集す る Prometheus では全てのメトリクスを高解像度で取得する Grafana で可視化して必要なときに見る data retention は短めに取って運用負荷を抑える NewRelic には選択的に、あるいはサマリを送信して中長期的に保持してもらう 13

Slide 14

Slide 14 text

NewRelic への送信 NewRelic への送信メトリクスを調整する 種類を絞る スクレイプ頻度を調整する 必要となったものは逆に足す 副次的な効果 使わないデータに対して余計な費用をかけずに済む NewRelic API の rate-limit を回避 14

Slide 15

Slide 15 text

まとめ APM と Prometheus を組み合わせて使う方法についてお話しました Prometheus は便利だが、それだけで完結するには努力が必要 NewRelic をうまく活用していいとこ取りをする 必要なデータを必要な場所に送ると効率が良い 15

Slide 16

Slide 16 text

Join us! 16