Conversation
監視の持つ4つの性質に対して、Prometheusなどの具体的なツールとの1対1対応の例を記載することで、より理解しやすいとのアドバイスを受けたため
mkgrei
left a comment
There was a problem hiding this comment.
ツールの具体例ということで、それぞれの性質に対してツールを一つピックアップした形に今はなっています。一方で一つのツールが一つの性質しか満たしていないわけではないため、少しわかりにくくなっています
例えばPrometheusを利用する監視システムのスタックの一例として
- 各種exporter
- Prometheus
- Alertmanager
- Grafana
という構成を挙げてから、
- exporterでは特定性に寄与して
- Prometheusは通知性、特定性、分析性があり、通知性として集められたデータからアラートルールを発火してAlertmanagerに転送、特定性では時系列データベースが役に立ち、分析性としてPromQLというクエリ言語があり
- Alertmanagerは通知性を担っていて
- Grafanaでは可視性、分析性を実現できる
とするとわかりやすいかもしれません
| Tables | exporter | Prometheus | Alertmanager | Grafana |
|---|---|---|---|---|
| 可視性 | - | - | - | ◎ |
| 通知性 | - | ○ | ◎ | △ |
| 特定性 | ○ | ◎ | - | - |
| 分析性 | - | ○ | - | ◎ |
△: 機能としてある、○: 寄与している、◎: 中心的な機能である
| > | ||
| > 1. 可視性 | ||
| > | ||
| > Prometheusにおいて、可視性はGrafanaで実現します。GrafanaはPrometheusが集積した時系列データをグラフ化することに特化しており、ユーザライクな可視化を柔軟に実現することができます。 |
There was a problem hiding this comment.
PrometheusもGrafanaもツールであるため、少し違和感があります。Prometheusのいち機能としてGrafanaがあるように読めるためかと思います
具体的な言い回しはおまかせしますが、一例として、
「Prometheusを利用する際にはGrafanaというプロダクトを用いて可視化を行うことが多いです。Prometheusでもシンプルなグラフを描画できますが、Grafanaはより高度な可視化や複数のグラフを組み合わせてダッシュボードとして表示することで可視性を実現することに特化しています。」
また、さっと検索する限り「ユーザライク」という言葉はあまり一般的ではないかもしれません。「ユーザフレンドリー」や「ユーザに優しい」といった意味合いかと捉えましたが、「〜ライクな」には「〜的な」という用法があるため文書が多義的になるかもしれません
|
|
||
| > 【4つの性質の具体例】 | ||
| > | ||
| > 世の中に出回っている殆どの監視ツールは、上記4つの性質を何らかの機能で実現できるようになっています。ここでは代表的な監視ツールであるPrometheusを利用した際にどのようにして実現できるかを紹介します。 |
There was a problem hiding this comment.
「監視ツール」が初出です。以後の文脈で言葉の揺れがあるように感じます。「監視システム」という言葉がexporter, prometheus, alertmanager, grafanaといったスタック全体をさすのに対して、特にpull型においてスクレイピングを行う部分を狭義の「監視ツール」として定義しているのでしょうか。どちらかというと「監視システム」の任意の構成要素の一つ一つが広義の「監視ツール」であるように定義するほうが見通しがよいです。そうすると、Prometheusは監視ツール、Grafanaも監視ツールとなります
また、監視の4つの性質があるゆえに、監視ツールと呼べるものはそれらの性質の何かしらの部分を機能で実現するために作成されていると考えるほうが自然です。そのようにも書かれていますが、情報は 既出→新規 の順番に提示すると文書がわかりやすくなります。今回の場合直前に性質の話をしているので、性質を満たすためにツールがある、のほうが誤解がないかと思います。あえて逆に、ツールがあり性質を実現する、の順序の場合あたかもツールが先にあって、あとになって監視の性質について体系的にまとめられて、実はこれらのツールは性質の満たしていたのだ、という発見的なニュアンスを与えます
ここでわかりにくい理由はおそらく、Prometheusだけが出ていることにあります。Prometheusの他にどのようなものを想像しているのかについて並列に並べると言いたいことが伝わるかもしれません。多分ですがZabbixやDatadogなどではなく、Prometheusを選択した際に、監視システムとして監視に求められる性質を満たすには他にどのようなプロダクト(監視ツール)と組み合わせるのかについて話したいのかと思いました
| > | ||
| > 2. 通知性 | ||
| > | ||
| > Prometheusにおいて、通知性はAlertmanagerで実現します。AlertmanagerはPrometheusから発火されたアラートに対して、メール、チャット、電話など柔軟な方法で管理者に通知することができます。 |
There was a problem hiding this comment.
前のコメントと同様「Prometheusにおいて」という日本語の意味が広く読めることが文書をわかりにくくしています。「Prometheusと連携して」のようにするほうが、Prometheusのいち機能ではなく、別のツールとしてAlertmanagerがあることがわかりやすくなります
Alertmanagerの特徴として多様の通知方法を提供している他に、アラートをグルーピングすることも挙げられたりしますが、話がややこしくなるのであれば無理に盛り込まなくても大丈夫です
ちなみに設定を見ると電話がなさそうに見えます。通知先として架電してくれるようなサービス(PagerDuty)もあるということでしょうか
| > Prometheusにおいて、通知性はAlertmanagerで実現します。AlertmanagerはPrometheusから発火されたアラートに対して、メール、チャット、電話など柔軟な方法で管理者に通知することができます。 | ||
| > | ||
| > 3. 特定性 | ||
| > Prometheusにおいて、特定性はPrometheus内のアーキテクチャTSDBなどによって実現されます。Prometheusは時系列データの解析に特化したツールであり、主にメトリクス情報を集積、解析することに強みを有しています。これにより過去と現在のデータの比較を容易に行うことができます。 |
There was a problem hiding this comment.
「Prometheusは内部に時系列データベースを抱えており、スクレイピングによって集められたデータが保管されています。過去のデータを蓄えて必要なときに高速に引き出せるため特定性を実現できます」が言いたいことかと思います
また、実は長期間のデータ保存においてはPrometheusよりも特化したプロダクトがあり、VictoriaMetricsやcortexが挙げられます。いずれもPrometheusよりもデータ圧縮などの側面で優れています
時系列データベースが監視に向いているのは、監視が一般的に時系列データであり、時系列データ特有の集計作業(移動平均など)を高速に算出することができるためです。そのため比較には他の時系列データベースが挙げることになります。Prometheusは時系列データベースの一つの実装であり、そこにスクレイピング機能や多種のサービスディスカバリを追加してCNCFに初期から受け入れられたことが今の地位を築いているのではないかと思います
| > | ||
| > 4. 分析性 | ||
| > | ||
| > Prometheusにおいて、PromQL(時系列データを取得・集約するクエリ言語)を用いたクエリに対する関数の適用などによって実現することが出来ます。たとえば、クエリに線形回帰モデルなどを適用することで、将来の傾向を分析することができます。 |
There was a problem hiding this comment.
「PrometheusではPromQLと呼ばれるクエリ言語を用いて時系列データを取得・集約して分析することができます」
後半は「傾向を予測」「将来を予測」「傾向を分析」が組み合わさっているように思います。将来の傾向であれば予測が適切ではないかと思います。過去・現在の傾向を分析するかと思います
またPromQLというのが分析をするためのベースとなっていて、ここで挙げられてると思います。実際は分析をするのであればGrafanaのようなものを用いて、複数のデータを並べて実施されるかと思います
監視の持つ4つの性質に対して、Prometheusなどの具体的なツールとの1対1対応の例を記載することで、より理解しやすいとのアドバイスを受けたため