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

プロダクト誕生の背景から学ぶ PrometheusとGrafana Loki

yosshi_
January 24, 2021

プロダクト誕生の背景から学ぶ PrometheusとGrafana Loki

July Tech Festa 2021 winter での登壇資料
ref : https://techfesta.connpass.com/event/193966/

yosshi_

January 24, 2021
Tweet

More Decks by yosshi_

Other Decks in Technology

Transcript

  1. What is Prometheus?(2/2) 参考 Prometheus and OpenMetrics, with Richard Hartmann

    https://kubernetespodcast.com/episode/037-prometheus-and-openmetrics/ Kubernetes Podcast「Prometheus and OpenMetrics, with Richard Hartmann」より Prometheus came into being because a few ex-Googlers were quite unhappy with what they found in the open-source and also in the paid software world. So they basically reimplemented large parts of Borgmon into Prometheus. In recent years, monitoring has undergone a Cambrian Explosion: Riemann, Heka, Bosun, and Prometheus have emerged as open source tools that are very similar to Borgmon’s time-series–based alerting. In particular, Prometheus shares many similarities with Borgmon, especially when you compare the two rule languages. The principles of variable collection and rule evaluation remain the same across all these tools and provide an environment with which you can experiment, and hopefully launch into production 「Site Reliability Engineering」より Prometheus は Borg を参考に作られた時系列ベースのアラートシステム 参考 Site Reliability Engineering https://sre.google/books/
  2. What is Borgmon? Shortly after the job scheduling infrastructure Borg

    was created in 2003, a new monitoring system—Borgmon—was built to complement it. 「Site Reliability Engineering」より Borgmon は Borg のために作られた監視システム 参考 Site Reliability Engineering https://sre.google/books/
  3. What is Borg? Borg is a distributed cluster operating system,

    similar to Apache Mesos. Borg manages its jobs at the cluster level. 「Site Reliability Engineering」より Borg は分散のクラスタ管理システム Kubernetes はこの Borg を参考に作られている 参考 Site Reliability Engineering https://sre.google/books/
  4. まずは、SREについて知ろう Every implementation guide needs to start with a common

    base from which to build. In this case, the basic foundations of SRE include SLOs, monitoring, alerting, toil reduction, and simplicity. Getting these basics right will set you up well to succeed on your SRE journey. 「The Site Reliability Workbook」より SLO, monitoring, alerting の順番になっているので、まずは SLOが何か知ろう 参考 The Site Reliability Engineering Workbook https://sre.google/books/
  5. SLI と SLO • サービスレベル指標:SLI (Service Level Indicator) – サービスの状態を測定するための指標

    ( “成功したイベント数 / イベントの総数” がよく用いられている) • 成功したHTTPリクエストの数/ HTTPリクエストの総数(成功率) • 100ミリ秒未満で正常に完了したgRPC呼び出しの数/ gRPCリクエストの合計 • サービスレベル目標:SLO (Service Level Objective) – SLIを用いて定められるサービスの目標値 参考 The Site Reliability Engineering Workbook https://sre.google/books/ Even if you could achieve 100% reliability within your system, your customers would not experience 100% reliability. The chain of systems between you and your customers is often long and complex, and any of these components can fail. 「The Site Reliability Workbook」より 100% is the wrong reliability target for basically everything 「Site Reliability Engineering」より 参考 Site Reliability Engineering https://sre.google/books/
  6. Borgmon, Prometheusが誕生した背景 参考 The Site Reliability Engineering Workbook https://sre.google/books/ •

    SLOを下回ることなく継続した変更(開発)を 行うことを目的としている • SLIの測定のためにモニタリングが必要 (Borgmon, Prometheus が必要) • システムのエラーを検知してアラートを出すことが 目的ではない 必ずエラーを検知したいのではなく、 SLOを守りたいというのがプロダクト作成の背景にある
  7. データ収集:Pull型 + Service discovery • Pull型 – Prometheusからターゲットに対して定期的にメトリクスを スクレイプするアーキテクチャを採用している •

    Service discovery – Pull型の欠点として,ターゲットが追加されるたびに Configの変更が必要なことが上げられるがこの機能により 自動化することができる • OpenMetrics – 対象の名前、値に加えてラベルもつ形式のデータ # HELP http_requests_total The total number of HTTP requests. # TYPE http_requests_total counter http_requests_total{method="post",code="200"} 1027 1395066363000 http_requests_total{method="post",code="400"} 3 1395066363000
  8. データ収集:Exporter (1/2) • 代表的なサードパーティ – Node exporter:ノードのCPU, メモリ, ディスクI/Oなどをメトリクスとして出力 –

    Blackbox exporter:ICMP, HTTP 等の結果をメトリクスとして出力 • Exporter – HTTPリクエストにメトリクスの取得が可能 – 10〜60秒程度の間隔で定期的にスクレイプしてデータを取得する – 自作することも可能だが、様々なThird-party exportersが公開されている • アプリ自身でのメトリクスの出力 – KubernetesやCoreDNSなどはアプリ自身がメトリクスを出力する – Exporterを自作することや、アプリ自身がメトリクスを出力するようにも可能
  9. データ収集:Exporter (2/2) • app自体がメトリクスを出力 # HELP http_requests_total The total number

    of HTTP requests. # TYPE http_requests_total counter http_requests_total{method="post",code="200"} 1027 1395066363000 http_requests_total{method="post",code="400"} 3 1395066363000 • exporterがメトリクスを出力 参考 Prometheus Introduction - Julius Volz, Prometheus https://sched.co/Zex4
  10. なぜOpenMetricsが必要なの? 参考 Prometheus and OpenMetrics, with Richard Hartmann https://kubernetespodcast.com/episode/037-prometheus-and-openmetrics/ OpenMetrics

    に対応しておけば どの監視ツールでも対応できるようになることが 期待される ADAM GLICK: Given all the work that you're doing with Prometheus, how did that lead you into creating the OpenMetrics Project? RICHARD HARTMANN: Politics. It's really hard for other projects, and especially for other companies, to support something with a different name on it. Even though Prometheus itself doesn't have a profit motive, so we don't have to have sales or anything, it was hard for others to accept stuff which is named after Prometheus in their own product. And this is basically why I decided to do that. • 他の企業が採用しやすいようにわざと切り出している • Prometheusのメトリクスのフォーマットを切り出したものがOpenMetiricsだが 今では、OpenMetiricsで定義してそれをPrometheusで取り込む形にシフトしている
  11. アラート:通知の待機とグルーピング groups: - name: example rules: - alert: HighRequestLatency expr:

    job:request_latency_seconds:mean5m{job="myjob"} > 0.5 for: 10m labels: severity: page annotations: summary: High request latency • 通知の抑制 – for:異常を検知してから一定時間待機して、回復しないことを確認してから通知する – grouping:類似のアラートを都度通知せずに、まとめて1つにして通知する – Inhibition:特定のアラートが出ているときに、他のアラートを通知しない – silences:特定の時間、特定のアラートを通知しない。作業時などによく使う • 通知先 – Slak, Email, Pagerduty などに通知することができる
  12. アラート:チケット管理や、 ポストモーテム • チケット管理 – 通知されたアラートのその後の管理は、Prometheusのスコープ外 – Githubのissueや、pagerdutyなどを用意して管理する必要がある • ポストモーテム

    – SRE本で記載されている失敗のナレッジの共有 – ポストモーテムの形式にこだわる必要はないが、Prometheusではスコープ外なので 別途検討の必要あり 参考 Site Reliability Engineering https://sre.google/books/
  13. What is Grafana? 参考 Grafana, with Torkel Ödegaard https://kubernetespodcast.com/episode/122-grafana/ So

    I took Kibana as a starting point when I started working on Grafana. And I really wanted that easy to use dashboard experience, combined with an easy query builder experience. Because that's where many of my teammates struggling, editing, and understanding the graphic queries. Because it's a small text box. It's a long query nested structure. Kubernetes Podcast「Grafana, with Torkel Ödegaard」より • 2014年にGithubにOSSとして公開 • Kibana v3 を参考に作られてる • 簡単にqueryを可視化できることを目指した
  14. 可用性:Alertmanager • 冗長構成が可能 alerting: alertmanagers: - static_configs: - targets: -

    alertmanager1:9093 - alertmanager2:9093 - alertmanager3:9093 参考 alertmanager#high-availability https://github.com/prometheus/alertmanager#high-availability 側でも以下のように設定 のクラスタ
  15. どのくらいの期間メトリクスを保管する? This is a highly contentious point even within Prometheus

    team. The common wisdom used to be, you retain your data for two weeks, and you drop everything which is older. Personally, I kept all data since late 2015. So data which we collected back then is still available today. The truth is probably somewhere in the middle for most users. If you really care about persisting your data long time, you would probably be looking at something like Cortex or Thanos or Influx Data. Or one of those other tools where we have our remote read/write API, where you can just push data to those other systems and persist data over there. Kubernetes Podcast「Prometheus and OpenMetrics, with Richard Hartmann」より 参考 Prometheus and OpenMetrics, with Richard Hartmann https://kubernetespodcast.com/episode/037-prometheus-and-openmetrics/ 私個人の意見としては 内に保管するメトリクスは 週間分に留めておいて、 それ以上を保管したい場合は、 機能を使うのがおすすめです
  16. グローバルビュー(1/2) 「Site Reliability Engineering」より 参考 Site Reliability Engineering https://sre.google/books/ •

    Borgmonではtarget(メトリクスの収集対象)とスクレイプするBorgmonが 同じDC内にあるように設計されてます • そのため、複数のBorgmonのデータを横断してみたいというニーズがあります • Prometheusを含め監視システムの設計では同様のニーズがあります
  17. グローバルビュー(2/2) 参考 prometheus.io https://prometheus.io/docs/prometheus/latest/federation/ gscrape_configs: - job_name: 'federate' scrape_interval: 15s

    honor_labels: true metrics_path: '/federate' params: 'match[]': - '{job="prometheus"}' - '{__name__=~"job:.*"}' static_configs: - targets: - 'source-prometheus-1:9090' - 'source-prometheus-2:9090' - 'source-prometheus-3:9090' • Prometheusでは以下の2つの方法のいずれかで実現が可能です – remote write機能:Third-party Storage で実現する – federation機能:Prometheus自身を大きなexporterとして、別のPrometheusのtargetに設定することで Prometheus間でメトリクスデータを渡せる機能を使って実現する の設定例
  18. 監視システムの監視 • 監視システムの設計において、監視システム自身の監視の設計が必要になります • Prometheusでは、Prometheus自身もメトリクスを出力するため それを監視する形になります • 一番シンプルな構成は、Prometheus自身のメトリクスを監視する別のPrometheusを立てることで すが、他にもそのメトリクスだけを社内全体の監視基盤で監視したり、SaaSを使ったりするケースが あります

    # HELP go_goroutines Number of goroutines that currently exist. # TYPE go_goroutines gauge go_goroutines 289 # HELP go_info Information about the Go environment. # TYPE go_info gauge go_info{version="go1.15.2"} 1 # HELP go_memstats_alloc_bytes Number of bytes allocated and still in use. # TYPE go_memstats_alloc_bytes gauge go_memstats_alloc_bytes 3.63520904e+08 監視専用 一番シンプルな例 毎日誰かが定刻に画面を見てチェックするなどの人力ではなく システムとして設計した方が良いです のメトリクスの例
  19. 監視システムのテスト(1/2) 参考 The Site Reliability Engineering Workbook 「The Site Reliability

    Workbook」より 1. Binary reporting: Check that the exported metric variables change in value under certain conditions as expected. 2. Monitoring configurations: Make sure that rule evaluation produces expected results, and that specific conditions produce the expected alerts. 3. Alerting configurations: Test that generated alerts are routed to a predetermined destination, based on alert label values. メトリクスの正常性 の構成 期待したアラートが 出力されるか 監視システムに当然ながらテストが 必要になります
  20. 監視システムのテスト(2/2) 参考 Unit Testing for Prometheus Rules • promtoolというPrometheus専用のテストツールがあります •

    promtoolの詳細については、「unit-testing-for-prometheus-rules」の資料が詳しいので そちらをご参照ください
  21. Metrics, Logs & Traces 例 参考 Metrics, Logs & Traces

    https://static.sched.com/hosted_files/kccnceu19/b7/Tom%20Wilkie%20and%20Frederic%20Branczyk%20-%20May%2023.pdf
  22. 公開直後の反応 • KubeCon 2018 NA で発表 – 反響:あまりない – 出来栄え:α版、商用で絶対に使わないで

    • そもそも当時のGrafanaで使えない – 所感:無理矢理出した感あるけど期待したい – 参考:https://sched.co/GrXC • KubeCon 2019 EU で発表 – 反響:Keynoteで騒がれる – 出来栄え:β版 • でも機能がまだ足りない – 所感:いい感じに進化してる – 参考:https://sched.co/MPbj βでロゴが変わった
  23. What is Grafana Loki ? 参考 Prometheus and OpenMetrics, with

    Richard Hartmann https://kubernetespodcast.com/episode/037-prometheus-and-openmetrics/ • 概要 – ログの収集と可視化ツール • 開発の背景 – Metricsだけではインシデントの全容の半分しか分からない – MetricsとLogsの参照時の切替コストを最小限にしたい(Grafanaで完結したい) • アプローチ – Prometheusと同様にラベルがあって、時系列にデータを格納 – Cortexを参考に水平スケールを意識 • Non-Goal – みたいな統計情報 長期間のログに対しての統計情報の取得はターゲットにしてない
  24. Grafana Tempo • Grafana Tempo の Grafana の画面 と の情報を組み合わせて

    ログとトレースの情報を関連づけてみることが想定されている
  25. Amazon Managed Service for Prometheus • Amazon Web Services 側のブログ

    参考 プレビュー開始 – Amazon Managed Service for Prometheus (AMP) https://aws.amazon.com/jp/blogs/news/join-the-preview-amazon-managed-service-for-prometheus-amp/ まだプレビューですが今後が楽しみです
  26. Amazon Managed Service for Prometheus • Grafana Labs 側のブログ 参考

    Our new partnership with AWS gives Grafana users more options https://grafana.com/blog/2020/12/15/announcing-amazon-managed-service-for-grafana/ をベースに実現しているので、 同じアーキテクチャを使用している にも 進展がないか期待しています
  27. Openmetrics と OpenTelemetry の関係 参考 dd a README entry on

    how OM relates to the wider CNCF ecosystem https://github.com/OpenObservability/OpenMetrics/issues/137 参考 https://docs.google.com/document/d/17r3BW7-DBtdNNJ_PRvAlrnbj_RsMDkSv_lljOhI03HI/edit#heading=h.k8l30yl2bec4 それぞれの開発者同士で話し合いが行われているようですが、 統合するというよりは、スコープとして重なる部分があるので その辺りの境界を定めていく方向になるのかなと思っています
  28. OpenMetricsのIETFへの提出 参考 tweet https://twitter.com/EGMC/status/1353206119049515009?s=20 登壇中に して頂いたので、知りましたが が 提出されたようです しかし、 に提出されて、

    にブログに書かれてるのはすごいですね 時差も考えると提出のほぼ翌日にはブログが公開されたのではないでしょうか 参考 Prometheusが利用するOpenMetricsの仕様がIETFに提出された https://asnokaze.hatenablog.com/entry/2020/11/27/011732
  29. Grafana Cloud Agent 参考 Grafana Cloud Agent https://github.com/grafana/agent のメトリクスや のログを

    に送る になります 年 月 に が登場し、 時点で へのデータの送信方法は 機能を使用してるので色々の使い方できそうです prometheus: wal_directory: /tmp/wal integrations: agent: enabled: true prometheus_remote_write: - url: http://localhost:9009/api/prom/push の の設定方法の例
  30. Grafana Cloud Agent:Scraping Service Mode 参考 Grafana Cloud Agent Scraping

    Service Mode ttps://github.com/grafana/agent/blob/master/docs/scraping-service.md#scraping-service-mode クラスタリングする時の設定例 • Scraping Service Mode – Agent をクラスタリングして、スクレイピングの負荷分散ができます – クラスタリングせずに、スクレイプだけして remo write機能で書き出すだけを行うこともできます prometheus: global: scrape_interval: 5s scraping_service: enabled: true kvstore: store: etcd etcd: endpoints: - etcd:2379 lifecycler: ring: replication_factor: 1 kvstore: store: etcd etcd: endpoints: - etcd:2379 データの収集はクラスタ化された データの蓄積は 機能で別のプロダクト そのものを使わない構成も考えられる
  31. 参考資料(1/7) • 書籍 – The Site Reliability Workbook < https://sre.google/books/

    > – Site Reliability Engineering < https://sre.google/books/> – 入門 監視 ――モダンなモニタリングのためのデザインパターン < https://www.oreilly.co.jp/books/9784873118642/ > – 入門 Prometheus ――インフラとアプリケーションのパフォーマンスモニタリング < https://www.oreilly.co.jp/books/9784873118772/ > • サイト – Awesome Prometheus alerts < https://awesome-prometheus-alerts.grep.to/ > – PromQL Cheat Sheet < https://promlabs.com/promql-cheat-sheet/ >
  32. 参考資料(2/7) • ブログ (1/2) – Borgmon 現代芸術美術館で空想にふける < https://cloud.google.com/blog/ja/products/gcp/welcome-to-the-museum-of-modern-borgmon-art >

    – プレビュー開始 – Amazon Managed Service for Prometheus (AMP) < https://aws.amazon.com/jp/blogs/news/join-the-preview-amazon-managed-service-for-prometheus-amp/ > – A Comprehensive Analysis of Open-Source Time Series Databases < https://www.alibabacloud.com/blog/a-comprehensive-analysis-of-open-source-time-series-databases-4_594733?spm=a2c41.12826437.0.0 > – Loki: Prometheus-inspired, open source logging for cloud natives < https://grafana.com/blog/2018/12/12/loki-prometheus-inspired-open-source-logging-for-cloud-natives/ > – An (only slightly technical) introduction to Loki, the Prometheus-inspired open source logging system < https://grafana.com/blog/2020/05/12/an-only-slightly-technical-introduction-to-loki-the-prometheus-inspired-open-source-logging-system/> – Prometheus vs. Graphite: Which Should You Choose for Time Series or Monitoring? < https://logz.io/blog/prometheus-vs-graphite > – Announcing Grafana Tempo, a massively scalable distributed tracing system < https://grafana.com/blog/2020/10/27/announcing-grafana-tempo-a-massively-scalable-distributed-tracing-system/ >
  33. 参考資料(3/7) • ブログ (2/2) – Loki 2.0 released: Transform logs

    as you’re querying them, and set up alerts within Loki < https://cloud.google.com/blog/ja/products/gcp/welcome-to-the-museum-of-modern-borgmon-art > – ObservabilityCON 2020: Your guide to the newest announcements from Grafana Lab < https://grafana.com/blog/2020/10/26/observabilitycon-2020-your-guide-to-the-newest-announcements-from-grafana-labs/ > – Our new partnership with AWS gives Grafana users more options < https://grafana.com/blog/2020/12/15/announcing-amazon-managed-service-for-grafana/> – Prometheusが利用するOpenMetricsの仕様がIETFに提出された < https://asnokaze.hatenablog.com/entry/2020/11/27/011732 > – An (only slightly technical) introduction to Loki, the Prometheus-inspired open source logging system < https://grafana.com/blog/2020/05/12/an-only-slightly-technical-introduction-to-loki-the-prometheus-inspired-open-source-logging-system/> – Prometheus vs. Graphite: Which Should You Choose for Time Series or Monitoring? < https://logz.io/blog/prometheus-vs-graphite > – Announcing Grafana Tempo, a massively scalable distributed tracing system < https://grafana.com/blog/2020/10/27/announcing-grafana-tempo-a-massively-scalable-distributed-tracing-system/ >
  34. 参考資料(4/7) • KubeCon + CloudNativeCon Europe 2019 – Grafana Loki:

    Like Prometheus, but for Logs - Tom Wilkie, Grafana Labs < https://sched.co/MPbj > • KubeCon + CloudNativeCon Europe 2020 Virtual – Prometheus Introduction - Julius Volz, Prometheus < https://sched.co/Zex4> – Scaling Prometheus: How We Got Some Thanos Into Cortex - Thor Hansen, HashiCorp & Marco Pracucci, Grafana Labs < https://sched.co/Zeuw > – Review and define compatibility or incompatibility between OpenMetrics and OpenTelemetry < https://sched.co/ekFx > – What You Need to Know About OpenMetrics - Brian Brazil, Robust Perception & Richard Hartmann, Grafana Labs < https://sched.co/ZevQ >
  35. 参考資料(5/7) • KubeCon + CloudNativeCon North America 2020 Virtual –

    Evolution of Metric Monitoring and Alerting: Upgrade Your Prometheus Today - Bartlomiej Płotka, Red Hat, Björn Rabenstein & Richard Hartmann, Grafana Labs, & Julius Volz, PromLabs < https://sched.co/ekHn > – Intro to Scaling Prometheus with Cortex - Tom Wilkie, Grafana Labs & Ken Haines, Microsoft < https://sched.co/ekHh > – Observing Cloud Native Observables with the New SIG Observability - Bartlomiej Płotka, Red Hat & Richard Hartmann, Grafana Labs < https://sched.co/ekFx > • ObservabilityCON – Observability with logs & Grafana < https://sched.co/ekHn >
  36. 参考資料(6/7) – Cortex < https://github.com/cortexproject/cortex > – Thanos < https://github.com/thanos-io/thanos

    > – VictoriaMetrics < https://github.com/VictoriaMetrics/VictoriaMetrics > – M3 < https://github.com/m3db/m3 > • Github – Prometheus < https://github.com/prometheus/prometheus > – Grafana Loki < https://github.com/grafana/loki > – Grafana Tempo < https://github.com/grafana/tempo > – OpenMetrics < https://github.com/OpenObservability/OpenMetrics > – OpenObservability < https://github.com/OpenObservability > – Grafana Cloud Agent < https://github.com/grafana/agent>
  37. 参考資料(7/7) • Kubernetes Podcast – Prometheus and OpenMetrics, with Richard

    Hartmann < https://kubernetespodcast.com/episode/037-prometheus-and-openmetrics/ > – Grafana, with Torkel Ödegaard < https://kubernetespodcast.com/episode/122-grafana/ > – Monitoring, Metrics and M3, with Martin Mao and Rob Skillington < https://kubernetespodcast.com/episode/084-monitoring-metrics-m3/ >