はじめに
この記事は何を説明するのか
別記事にも書きましたが、Prometheus が登場してから月日も経ちました。
監視対象となる環境の種類も増え、伴い、利便性や可用性を向上させる新しいアイデアも登場してきました。
本稿では、2023年秋に、新規に Kubernetes (k8s)環境へ Prometheus を用いた監視を導入することを想定し、その際に導入検討をお勧めしておきたいオープンソースソフトウェア (OSS) をいくつか取り上げてみます。
紹介するソフトウェアの特徴を際立たせるために、シェアのある他の OSS と比較する場合がありますが、それらの存在を否定するものではありません。監視システムは安定稼働することが最も大事なことであり「古いからダメ」という考え方は必ずしも正しくはありません。
なお、本稿での「Prometheus」は、教義の OSS 製品名に留まらず、下記のような広い範囲のソフトウェア・スイートを指す場合があります。
- Prometheus と互換性のある類似のソフトウェア…たとえば Mimir など。
- Prometheus と併用される機会が多い監視用ソフトウェア…たとえば Grafana や Loki など。
事前に知っておいたほうが良い K8s 知識
「知ってるよ」という方はスキップしてください。
Operator pattern
K8s の優れた点の一つに「宣言的記述から結果整合でリソースがデプロイされる」という思想があります。
入門者でも判り易そうな例として、StatefulSet があります。StatefulSet リソースは「こんな感じで Pod がデプロイされてほしい」という "宣言" です。
K8s 利用者が StatefulSet をクラスタに登録した結果として、StatefulSet での要求を満たす形で Pod がデプロイされます。しかし StatefulSet には「具体的にどうデプロイするか」という手順は含まれていません。手順を考えるのは、 k8s が標準的に提供する "controller" の役目です。
この "controller" による運用の考え方を拡張したのが "Operator pattern" です。
Operator pattern に則ったソリューションでは、下記の構成要素が提供されます。
- operator と呼ばれる、特定の挙動を示す Pod。
- カスタムリソース (CR : Custom Resource) と呼ばれるリソース。また、それを定義するカスタムリソース定義 (CRD : Custom Resource Definition)
先に例示した StatefulSet リソースは、K8s の世界では天与のものです。一方、CR は operator の実装者が CRD を用いて自由に定義できます。
operator は、ユーザが登録した(CR を含む)リソースを監視し、必要に応じて自らリソースを追加削除変更などを行っていきます。実装レベルの高い operator の場合、何らかの理由でクラスタ内にリソースの不整合が発生した場合には、自己修復を試みたりもします。
Operator patten は、現在の K8s を実運用する上で、欠かせないものとなっています。
細かい手順を operator に任せることで、保守工数は圧倒的に軽減されます。
押さえておきたい OSS 製品
さて本題です。紹介しだしたらキリがありませんが、絶対に眺めていただきたい OSS は下記 2 点です。
- grafana-operator
- grafana-agent-operator
それぞれ概説していきます。いずれも公式サイトのドキュメントは整備されているので、深掘りはそちらで行ってください。
grafana-operator
システム監視に興味のある方に Grafana の説明は不要でしょう。
grafana-operator は、"Grafana" というその名の通りの CRD を提供します。それに沿った CR を K8s へ登録すると、grafana 入りの Pod や外部公開用の Ingress など必要なリソースをデプロイしてくれます。
また、"DataSource" "Dashboard" という名前の CRD も提供しています。Grafana を使った方ならピンと来るかもしれませんが、Grafana の UI 上でポチポチ手作業でやっていた登録作業を、operator に代行させられます。
ある程度の自己修復能力があり、誰かが誤って DataSource や Dashboard を UI 上から削除しても、operator が再度生成してくれたりもします。
以前の grafana-operator は、同一クラスタ上に登録できる Grafana CR は 1 つのみでした。
複数チームが K8s クラスタを共用する(いわゆるマルチテナント)環境では、正直なところ使い勝手が微妙だったのです。
…が、2023 年春のアップグレードである v5 からは、同一クラスタに複数の Grafana CR をデプロイできるようになりました。
最近のアップデートなので、web 上には過去バージョンである v4 に関する情報も多く残っており、しばらく混乱が続くかもしれませんが、じきに収束するものと思います。
grafana-operator の開発主体は Grafana の開発主体である GrafanaLab ではなく、GitHub でのコントリビュータを見ても特定の企業が推しているというわけでもないようです。
しかし、採用企業を見ている限り、Red Hat など大手が含まれますので、短期で打ち捨てられるような可能性は低いと見て良いと思います。
Grafana は Helm chart 経由でのデプロイも可能です。しかし、operator による自己修復能力を考えると、grafana-operator の導入には、一考の余地があります。
Grafana Agent Operaor
Grafana Agent is 何?
Grafana Agent Operator の解説の前に、「Grafana Agent って、何?」を説明する必要があるかもしれません。(ご存知の方は読み飛ばしてください)
Grafana Agent については、以前の記事にも書きました。(引用)
Grafana といえば可視化ツールが有名だが grafana-agent は可視化ツールとは直接の関係は無い。Grafana の開発元である GrafanaLabs 社が提供しているから grafana-agent。紛らわしい。
Grafana Agent が提供する機能は、概ね下記のとおりです。
- remote write 機能を有効にした Prometheus と同等機能
- Loki へのログ記録を目的とした場合の Promtail と同等機能
- (その他機能ありますが、本稿では割愛します)
grafana-agent 登場前は、複数のコンポーネントを使って Prometheus 向けのデータスクレイピングを行う必要がありました。
それらを一つのコンポーネントに集約できるのが、従来行われていた手法に対する、 Grafana Agent の強みです。
管理対象のコンポーネントは、少ないほうが楽ですし。
加えて、これは実測を伴ってから言及すべきですが、 従来手法よりも grafana-agent を用いたほうがリソース消費量が少なくなる傾向があるように思います。
なお、Grafana Agent 自身は、K8s への依存性はありません。
オンプレでも、他のコンテナ実行環境(docker等)でも使えます。
Grafana Agent Operator の強み
Grafana Agent Operator の強みは、他の operator と同様です。
-
GrafanaAgentという CR で Grafana Agent を K8s クラスタ内にデプロイできます。 -
MetricsInstanceLogInstance等々の CR で、Grafana Agent へ与える設定を指定できます。
むすび、および余談
以上、2023年秋から K8s クラスタへ Prometheus 監視を新規導入するという前提で、最近注目の OSS を紹介しました。
既に組み上がった Prometheus 監視環境に対し、これらと入れ替えるべきか…? 冒頭に書いた通り、これは難しいところだと思います。
grafana-operator に関しては、追加導入することで、既存の環境を壊すこと無く利便性を高められる可能性はあるかもしれません。
grafana-agent-operator に関しては、必要とする CRD が、既存環境のそれと衝突する可能性があります。仮に移行を検討するにしても、慎重に進める必要がありそうです。
監視関係は、その重要性から、慎重にならざるを得ない部分はあり、過去の成功事例の "コピペ" でリスクを担保しようという傾向が割とあるかもしれません。
一方で、ソフトウェアは "後出しジャンケン" が圧倒的に有利なので、後発のソリューションのほうが(大抵は)優れています。
過去と現在、両利きで見定める必要がありそうです。