プロダクト誕生の背景から学ぶ PrometheusとGrafana Loki July Tech Festa 2021 winter

● 吉村 翔太 ● ゼットラボ株式会社 ソフトウェアエンジニア ● 経歴 年、通信事業者の 年 ● 、 　 ● 登壇 入門 ● コミュニティ活動 自己紹介

本日のゴール • 発表を聴き終えた聴講者の状態 – どうしてPrometheusやGrafana Lokiが誕生したかちょっと分かるようになる – PrometheusやGrafana Lokiのことが好きになってちょっと試してみたくなる • 想定する聴講者のスキルレベル – 雰囲気でPrometheusを使ってる方 – 使ったことないけどPrometheusが気になってる方

Prometheus

What is Prometheus?（1/2） 参考 prometheus.io https://prometheus.io/docs/introduction/overview SoundCloud で2012年に作られたオープンソースのソフトウェア

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/

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/

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/

まずは、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/

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/

Borgmon, Prometheusが誕生した背景 参考 The Site Reliability Engineering Workbook https://sre.google/books/ • SLOを下回ることなく継続した変更(開発)を 行うことを目的としている • SLIの測定のためにモニタリングが必要 (Borgmon, Prometheus が必要) • システムのエラーを検知してアラートを出すことが 目的ではない 必ずエラーを検知したいのではなく、 SLOを守りたいというのがプロダクト作成の背景にある

Prometheusのアーキテクチャ（1/3） 参考 prometheus.io https://prometheus.io/docs/introduction/overview/

Prometheusのアーキテクチャ（2/3） データ蓄積 データ収集 アラート 可視化

Prometheusのアーキテクチャ（3/3） 参考 prometheus.io https://prometheus.io/docs/introduction/overview/ データ収集 データ収集 アラート 可視化 データ蓄積

データ収集：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

データ収集：Exporter （1/2） • 代表的なサードパーティ – Node exporter：ノードのCPU, メモリ, ディスクI/Oなどをメトリクスとして出力 – Blackbox exporter：ICMP, HTTP 等の結果をメトリクスとして出力 • Exporter – HTTPリクエストにメトリクスの取得が可能 – 10〜60秒程度の間隔で定期的にスクレイプしてデータを取得する – 自作することも可能だが、様々なThird-party exportersが公開されている • アプリ自身でのメトリクスの出力 – KubernetesやCoreDNSなどはアプリ自身がメトリクスを出力する – Exporterを自作することや、アプリ自身がメトリクスを出力するようにも可能

データ収集：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

なぜ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で取り込む形にシフトしている

Prometheusのアーキテクチャ データ蓄積 データ収集 アラート 可視化

データ蓄積：時系列DB + PromQL • 時系列DB – 蓄積したデータの利用シーンを考えた場合に、アラートや分できでは特定の時間単位で データを評価することが多いため、時系列DBに蓄積する形となっている – 保管期間が定められており、それ以降のデータは自動で削除される(2週間程度が多い) • PromQL – Prometheus独自のクエリ言語 – 平均や偏差などの統計を用いた分析が容易になる

Prometheusのアーキテクチャ データ蓄積 データ収集 アラート 可視化

アラート：通知の待機とグルーピング 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：類似のアラートを都度通知せずに、まとめて１つにして通知する – Inhibition：特定のアラートが出ているときに、他のアラートを通知しない – silences：特定の時間、特定のアラートを通知しない。作業時などによく使う • 通知先 – Slak, Email, Pagerduty などに通知することができる

アラート：チケット管理や、 ポストモーテム • チケット管理 – 通知されたアラートのその後の管理は、Prometheusのスコープ外 – Githubのissueや、pagerdutyなどを用意して管理する必要がある • ポストモーテム – SRE本で記載されている失敗のナレッジの共有 – ポストモーテムの形式にこだわる必要はないが、Prometheusではスコープ外なので 別途検討の必要あり 参考 Site Reliability Engineering https://sre.google/books/

アラート：ポストモーテムの例 参考 The Site Reliability Engineering Workbook https://sre.google/books/

アラートの書き方に悩んだら 参考 Awesome Prometheus alerts https://awesome-prometheus-alerts.grep.to/ このサイトをサンプルが多数あるので 真似して動かしてみると勉強になります

Prometheusのアーキテクチャ データ蓄積 データ収集 アラート 可視化

可視化：Grafana • Grafanaを使用する

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を可視化できることを目指した

可視化：Grafana • GrafanaLabの公式サイトのたくさんサンプルがあるので活用してください 参考 grafana.com https://grafana.com/grafana/dashboards

PromQLの書き方に悩んだら 参考 PromQL Cheat Sheet https://promlabs.com/promql-cheat-sheet/ このサイトにサンプルが多数載っているので、 実際に真似して書いてみると参考になると思います

Prometheusの特徴（1/2） 参考 Prometheus Introduction - Julius Volz, Prometheus https://sched.co/Zex4

Prometheusの特徴（2/2） 参考 Prometheus Introduction - Julius Volz, Prometheus https://sched.co/Zex4

Prometheusの可用性について 参考 prometheus.io https://prometheus.io/docs/introduction/overview/

可用性：Exporter 参考 prometheus.io https://prometheus.io/docs/introduction/overview/ • Exporterを複数立てることで可能 • App自体にメトリクスを出力する機能を作ることを想定してるので Appのプロセスが消えると、メトリクスも出力されない想定が多い • Kubernetesとかを使用するときは、Auto healing と組み合わせたり

可用性：Prometheus • Prometheus自体にクラスタ化の仕組みはない • 必要な場合は、同じTarget(スクレイプ対象)の設定を持つPrometheusを 複数台用意する でヘルスチェック

可用性：Alertmanager • 冗長構成が可能 alerting: alertmanagers: - static_configs: - targets: - alertmanager1:9093 - alertmanager2:9093 - alertmanager3:9093 参考 alertmanager#high-availability https://github.com/prometheus/alertmanager#high-availability 側でも以下のように設定 のクラスタ

Prometheusのスケール • Targetが増えて1台のPrometheusで処理できなくなったら • 複数のPrometheusを立てて、Targetを分割する

メトリクスの長期保管（1/3） • メトリクスを長期保管したい場合は、remote write 機能で 他のプロダクトへ出力する 参考 prometheus.io https://prometheus.io/docs/prometheus/latest/storage/#overview

メトリクスの長期保管（2/3） • 以下のようなプロダクトに対して、remote write 機能で出力する

メトリクスの長期保管（3/3） • Cortex を使用した時の例 で 書き込む に対応しているプロダクトは で見れるものが多い

どのくらいの期間メトリクスを保管する？ 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/ 私個人の意見としては 内に保管するメトリクスは 週間分に留めておいて、 それ以上を保管したい場合は、 機能を使うのがおすすめです

グローバルビュー（1/2） 「Site Reliability Engineering」より 参考 Site Reliability Engineering https://sre.google/books/ • Borgmonではtarget(メトリクスの収集対象)とスクレイプするBorgmonが 同じDC内にあるように設計されてます • そのため、複数のBorgmonのデータを横断してみたいというニーズがあります • Prometheusを含め監視システムの設計では同様のニーズがあります

グローバルビュー（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間でメトリクスデータを渡せる機能を使って実現する の設定例

監視システムの監視 • 監視システムの設計において、監視システム自身の監視の設計が必要になります • 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 監視専用 一番シンプルな例 毎日誰かが定刻に画面を見てチェックするなどの人力ではなく システムとして設計した方が良いです のメトリクスの例

監視システムのテスト（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. メトリクスの正常性 の構成 期待したアラートが 出力されるか 監視システムに当然ながらテストが 必要になります

監視システムのテスト（2/2） 参考 Unit Testing for Prometheus Rules • promtoolというPrometheus専用のテストツールがあります • promtoolの詳細については、「unit-testing-for-prometheus-rules」の資料が詳しいので そちらをご参照ください

Grafana Loki

What is Grafana Loki? 参考 grafana.com https://grafana.com/oss/loki/ Grafana Labで 2018年に作られたオープンソースのソフトウェア

監視で収集する情報 参考 Metrics, Logs & Traces https://static.sched.com/hosted_files/kccnceu19/b7/Tom%20Wilkie%20and%20Frederic%20Branczyk%20-%20May%2023.pdf

Metrics, Logs & Traces 例 参考 Metrics, Logs & Traces https://static.sched.com/hosted_files/kccnceu19/b7/Tom%20Wilkie%20and%20Frederic%20Branczyk%20-%20May%2023.pdf

アラートの通知から原因解析までの流れ（1/2） 参考 Metrics, Logs & Traces https://static.sched.com/hosted_files/kccnceu19/b7/Tom%20Wilkie%20and%20Frederic%20Branczyk%20-%20May%2023.pdf

アラートの通知から原因解析までの流れ（2/2） 参考 Metrics, Logs & Traces https://static.sched.com/hosted_files/kccnceu19/b7/Tom%20Wilkie%20and%20Frederic%20Branczyk%20-%20May%2023.pdf はメトリクスだけで測定できるが 故障の解析にはログが必要であり、強いニーズがあった

公開直後の反応 • KubeCon 2018 NA で発表 – 反響：あまりない – 出来栄え：α版、商用で絶対に使わないで • そもそも当時のGrafanaで使えない – 所感：無理矢理出した感あるけど期待したい – 参考：https://sched.co/GrXC • KubeCon 2019 EU で発表 – 反響：Keynoteで騒がれる – 出来栄え：β版 • でも機能がまだ足りない – 所感：いい感じに進化してる – 参考：https://sched.co/MPbj βでロゴが変わった

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 – みたいな統計情報 長期間のログに対しての統計情報の取得はターゲットにしてない

Loki と Prometheus, Cortexの関係 のログ版 を 水平スケール 水平スケールの アーキテクチャを踏襲

Cortex のアーキテクチャ

Loki のアーキテクチャ（1/2） 入力が とほとんど同じ 参考 Grafana Loki: Like Prometheus, but for Logs - Tom Wilkie, Grafana Labs https://sched.co/MPbj

Loki のアーキテクチャ（2/2） • “Promtail”をdeamonsetで各ノードに配置してログを収集 を に置き換えることも可 参考 https://grafana.com/blog/2018/12/12/loki-prometheus-inspired-open-source-logging-for-cloud-natives/ 上のコンテナのメタデータも が集めて ログに付与してくれる

Prometheusのアーキテクチャ データ蓄積 データ収集 アラート 可視化 も同じ構成をとっている

Loki によるアラート • Alertmanagerと組み合わせることによりログを用いてアラートを出すことができま す

Loki のアーキテクチャ の が でも実装されてる 参考 Grafana Loki: Like Prometheus, but for Logs - Tom Wilkie, Grafana Labs https://sched.co/MPbj

Loki のGrafanaでの操作画面

Loki 自身の監視とテスト • Prometheusでの考え方をLokiでも同じように実践する • テストツールについては、Cortexのツールを使用する 参考 Cortex Tools https://github.com/grafana/cortex-tools#cortex-tools 前述の もそうですが、 監視システムの継続的な変更を想定して の中でこのテストを実施するのが良いとされています

Grafana Tempo

Grafana Tempo • Trace 用の Grafana Tempo のリリース

アラートの通知から原因解析までの流れ 参考 Metrics, Logs & Traces https://static.sched.com/hosted_files/kccnceu19/b7/Tom%20Wilkie%20and%20Frederic%20Branczyk%20-%20May%2023.pdf ログの次には、やはりトレースの情報が欲しいという ニーズがあった

Grafana Tempo • Grafana Tempo の Grafana の画面 と の情報を組み合わせて ログとトレースの情報を関連づけてみることが想定されている

今後の話

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/ まだプレビューですが今後が楽しみです

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/ をベースに実現しているので、 同じアーキテクチャを使用している にも 進展がないか期待しています

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 それぞれの開発者同士で話し合いが行われているようですが、 統合するというよりは、スコープとして重なる部分があるので その辺りの境界を定めていく方向になるのかなと思っています

OpenObservability 参考 OpenObservability https://github.com/OpenObservability 年 月 を作成しているRichard Hartmannが 新たなレポジトリを公開したので今後何かあるかもしれません

OpenMetricsのIETFへの提出 参考 tweet https://twitter.com/EGMC/status/1353206119049515009?s=20 登壇中に して頂いたので、知りましたが が 提出されたようです しかし、 に提出されて、 にブログに書かれてるのはすごいですね 時差も考えると提出のほぼ翌日にはブログが公開されたのではないでしょうか 参考 Prometheusが利用するOpenMetricsの仕様がIETFに提出された https://asnokaze.hatenablog.com/entry/2020/11/27/011732

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 の の設定方法の例

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 データの収集はクラスタ化された データの蓄積は 機能で別のプロダクト そのものを使わない構成も考えられる

参考資料

参考資料（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/ >

参考資料（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/ >

参考資料（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/ >

参考資料（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　>

参考資料（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 >

参考資料（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>

参考資料（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/ >