Upgrade to Pro — share decks privately, control downloads, hide ads and more …

【NRUG : New Relic User Group@20210915】Prometheus を捨てない NewRelic の活用方法 / nrug_lt_20210915

86f4267ce6c7ee2c48347f30b1da3df8?s=47 ta-dadadada
September 15, 2021

【NRUG : New Relic User Group@20210915】Prometheus を捨てない NewRelic の活用方法 / nrug_lt_20210915

86f4267ce6c7ee2c48347f30b1da3df8?s=128

ta-dadadada

September 15, 2021
Tweet

Transcript

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

    1
  2. 自己紹介 多田 吉克(Tada Yoshikatsu ) 所属:(株)いい生活 物件流通プラットフォーム本部 on EKS でサーバAPI

    の開発〜インフラ運用まで全般を担当 プロダクトローンチからしばらくは Prometheus + Grafana & NewRelic を手運用 していたが、しばらくして NewRelic を導入した 2
  3. (株)いい生活 不動産業向けに統合型業務支援 クラウド・SaaS を中心に提供 (BtoB ) HP 作成サービス(CMS )など一 部のプロダクトでは(間接的

    に) toC も提供 3
  4. Talk Theme APM + Infra/Middleware Metrics をいい感じに NewRelic で統合するためのアイデア 自前構築から

    NewRelic 中心 の監視系に変えてきた 特にメトリクスの取り扱い方について 今 の考えをお話します 4
  5. 前提 監視の中心は APM に任せる サービスの品質をリッチに書き出すのに非常に役立つツール APM だけでは不足する情報をどうやって付け足していくか 5

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

    (CPU 、 Mem など) 6
  7. 案1 :NewRelic に全てお任せする NewRelic Infrastructure Agent with On-host integrations NewRelic

    で全て完結 クラウド含めた多くのインフラメトリクスやミドルウェアについてはカバーでき る 7
  8. 案2 :Prometheus (Exporter) を利用する Prometheus + Prometheus Integrations / Prometheus

    OpenMetrics integration メトリクスの収集は Prometheus で行い、データは NewRelic に蓄積する 8
  9. Prometheus 的メトリクスを NewRelic に送信する Prometheus remote write integration Prometheus の

    remote write 機能の送信先として NewRelic を指定できる Prometheus を自前でホストする必要あり Prometheus OpenMetrics integration(nri-prometheus) Agent 自身がメトリクスを収集して NewRelic に送信する Prometheus をホストする必要はない 9
  10. メトリクス収集を Prometheus に寄せるメリット 大抵のミドルウェアでは Prometheus Metrics 形式(OpenMetrics 形式)での metrics-exporter が

    OSS として公開されており流用できる NewRelic On-host integrations でも基本的なところは抑えられているのでそ の意味では十分かも 監視以外の用途に Prometheus を使う メトリクスストアとして活用して、オートスケールに利用する 保管場所に応じたメトリクスの解像度を調節できる <= 今日の趣旨 10
  11. メトリクスの解像度問題 「モダンなシステム」にするほどメトリクスは増える 多種多様なクラウドリソース マイクロサービス化によるアプリケーションの絶対数の増加 サービスメッシュによる proxy サーバ の増加 さらに exporter

    は「要るのかわからない」大量のメトリクスを出力する 自前運用の監視系でこれを捌き切るにはチームの体力が相当必要 外部(NewRelic )に任せるにしてもそれなりにコストはかかる とはいえ、取捨選択は「やってみないとわからない」 11
  12. 全てのメトリクスが半永久的に必要か? TPO によって求められるメトリクスの解像度は変わる トラブルシュートなどでは、5s 毎の詳細なメトリクスで瞬間を捉えたい 普段の監視やトレンド確認では、ある程度サマリされた結果でも良いので中長期 的にふりかえりたい 例)SLI として1 分ごとのエラーレートを計測する

    12
  13. 一旦 Prometheus を介す or Prometheus でも収集す る Prometheus では全てのメトリクスを高解像度で取得する Grafana

    で可視化して必要なときに見る data retention は短めに取って運用負荷を抑える NewRelic には選択的に、あるいはサマリを送信して中長期的に保持してもらう 13
  14. NewRelic への送信 NewRelic への送信メトリクスを調整する 種類を絞る スクレイプ頻度を調整する 必要となったものは逆に足す 副次的な効果 使わないデータに対して余計な費用をかけずに済む NewRelic

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

    15
  16. Join us! 16