こんにちはかめねこです。
先日お話させていただきました、「インフラエンジニアBooks」での質問や所管などをまとめてみました。
はじめに
インフラエンジニアBooks 30分でわかる「Prometheus実践ガイド」
というタイトルで、1月23日に開催しました。インフラに関する各種書籍の著者を呼び、さまざまな話をしてもらうイベントだそうです。ちょうどPrometheus要素が不足していたようで、ちょうど需要にマッチしたらしく、お声をかけていただきました🙏
動画はこちらから
イベント後記
当日のありがたいことに、160人を超える方に登録していただき、当日のYouTubeの同時接続数も91人と多くの方に観ていただきました。
また、参加後アンケートについても、非常に好評な評価をいただきまして、改めてお話して良かったと思います。
満足度が非常に満足・やや満足だけ…ありがたい🙏
ちなみに、イベントを迎えるにあたって、どんな話をしようかと考えていました。最初は単純にPrometheusの話をするかと思っていたのですが、せっかくインフラエンジニア「Books」と名がつくイベントです。単に技術トークをするだけではもったいない。
せっかくさまざまな書籍を集めたシリーズでお話をさせいただくので、書籍を書いた経緯や、各章での著者としての思いや伝えたいことを話そうと思いました。
ぜひ詳細は動画をご覧いただきたいのですが、自分でもビビるくらいひたすら語っていますｗ もう少し技術によればよかったかもしれませんが、実際トーク時間は30分しかないのでしょうがないですね。
質問への回答大全
ここからは、事前もしくはTwitter上でいただいていた質問にお答えしようと思います。基本的には当日お話したことと重複しますが、その時お話できなかったことも含めてできるだけ詳細に書こうかと思います。
AWSではマネージドなPrometheusがありますが、OSS版を自前で構築する場合とパブリッククラウド提供のマネージドサービスを利用する場合の違いなどがありましたらご教授頂きたいです。
端的に、マネージドサービスを利用する最大の理由は「ストレージ管理からの開放」
Prometheusにおいて、そのメトリクスを保存するためのストレージの運用が大きな課題になります。Prometheusそれ自体は、TSDBというファイルシステムベースのデータベースを持っています。ただ、これはあくまでも一時的な利用に留めるもので、長期的な利用には不向きです。（なぜ不向きなのか詳細は書籍で紹介しているのでそちらをご参照ください）
そのため、Prometheusは「リモートストレージ」と呼ばれる外部データベースにメトリクスを転送する仕組みを用意しています。このリモートストレージは、InfluxDBやElasticsearchのような汎用的なデータベースに加えて、VictoriaMetricsなどのようなリモートストレージ専用のOSSが存在します。このようにPrometheusの運用では、Prometheusに加えてリモートストレージの運用が必要になるのです。そう、追加でデータベースを運用しなければなりません。
実際に商用サービスのインフラを運用したことがある方であればわかるかと思いますが、データベースを自前で運用するのは、さまざまな面でコストがかかります。なので、これをマネージドにしたものが、「マネージドPrometheus」ということです。
ここからはデータベースの運用と同じ話で、ある程度大規模・マネージドではコスパが悪い場合には、自社でOSSを運用したほうが結果的にコストなどの面で最適な可能性があります。そのため、マネージドPrometheusかセルフホストかどうかは、自社においてどの程度コストをかけられるかなどを天秤にかけて検討する必要があります。また、結局実際にスクレイプを行うPrometheusは自前で管理が必要なので、実際にはPrometheus自体がマネージドになるわけではないことに注意が必要です。ちなみに、余談ですがGoogle CloudのGoogle Cloud Managed Service for Prometheusでは、マネージドなコレクタを用意しているため、Google Cloud環境でサービス展開しているなら、コレクタもマネージドになりますね。素晴らしい。
いくつか監視サービスがあるとき、Prometheusを導入する決め手となるもの
1つはエクスポーターの恩恵を受けること。そしてもう1つはその設計がマッチするかどうか
まず、Prometheusの最大のメリットは、非常に多くのエクスポーターが存在することでしょう。大抵のOSSは公式または有志のExporterが公開されており、これらを利用することで非常に簡単にメトリクスを収集できます。また、Kubernetesを始めとした比較的最近のOSSなどは、それ自体がPrometheusに対応したメトリクスを出力することができるため、Exporterすら不要ですぐに利用開始できます。
そのため、これから監視システムを構築するような状況であれば、Prometheusは非常に有用になるでしょう。
対し、すでにZabbixなどのOSSやDatadogなどのSaaSを利用している場合はその効果は薄い可能性があります。基本的に監視システムが乱立すると、各サービスを横断して見づらくなるため、統一すべきと考えています。よって、大きな理由がなければ既存の仕組みと同じものを使ったほうが結果的に幸せになる可能性はあります。
次に設計思想についてです。Prometheusは、Observabilityの考えのもと、基本的にシステム全体のさまざまなメトリクスを収集して、さまざまな問題に対応できるような思想です。そのため、Kubernetesのような大量のコンポーネントが存在するようなシステムにおいては、インフラだけでかなりのメトリクスを保存する必要があります。
対し、Zabbixなどのシステムにおいては、「どの仕組みの何を知りたいのか」が明確で、取得するメトリクスは限定的です。そのため、Prometheusに比べたらストレージ使用量は少ないです。
そのため、ストレージコストよりもObservabilityを優先するならPrometheusがマッチする可能性が高いです。
このような違いがあるため、組織やシステムとしてどちらがマッチするのかそれぞれの点で検討が必要です。
prometheusは今後SREにおいて必須のスキルだと思いますか？
必須ではないがあるとよい。
まず、Prometheus自体はただのツールなので、スキルというよりは単にツールを覚えるかどうかという違いだと思います。ただ、現在は多くのOSSなどがPrometheusに対応したメトリクスを出力するようになっているため、これらを簡単に取得して監視するためにも、Prometheusに慣れておくのは良いと思います。
特にインフラをやっている人以外に、実際にサービス開発をしているソフトウェアエンジニアについては、Prometheusを理解してもらえると大変うれしいです。
というのも、単にメトリクスを取得するだけではなく、自身のアプリケーションから簡単にメトリクスを出力する事ができます。これをすることで、サービスの健全性を手軽かつ詳細に監視できます。そのハードルを下げるためにも、ぜひPrometheusを触っていただき、ご自身が開発しているアプリケーションのメトリクスを出力してもらえるとインフラエンジニアとしても嬉しいです。
他にも、Prometheusで取得したメトリクスをZabbixに転送するような仕組みなどもあり、既存の環境でZabbixが動いていても導入しやすいという話もあります。また、これによりZabbixでは取得できなかった・難しかったシステムのメトリクスを簡単にZabbixで収集できるので、そういった理由からも、多くの方にPrometheusを経験していただきたいと思います。
どうやって習得されましたか
公式ドキュメントと「入門Prometheus」
執筆当時はPrometheusに関するブログ記事はまだ少なく、特にチュートリアルを超えた、実践的な記事が非常に少なかったです。そのため、基本的には公式ドキュメントやIssueなどを参考に学習を進めました。
併せて、特に有用だったのがオライリーの「入門Prometheus」です。この書籍は、Prometheusに関して非常に詳しく書いており、日本語で書かれているため、公式ドキュメントではよくわからなかった点に関して理解が捗りました。まじで「入門Prometheus」良いです。今でもクタクタになるくらい愛用しています。
あとは最後は実際に運用したことが大きいです。私は実際に業務でPrometheusを運用しているため、なんだかんだでこれが一番勉強になっています。多くの失敗もしましたが、それらから得られた経験によって「Prometheus実践ガイド」が出来上がっています。
Zabbixとの比較、UIの整理方法
ソフトウェアとしての堅牢性と、Grafanaによる統合
まずZabbixとの比較については、ソフトウェアとしての堅牢性や成熟度が段違いです。Zabbixは2004年にバージョン1.0が公開されており、本記事執筆時点で19年も経過しています。対しPrometheusは、2016年にバージョン1.0が公開されています。実に12年も差があるわけです。
そのため、Zabbixは多くの機能を持ちながらも、非常に堅牢で高い信頼性を持ちます。また、多くの企業で採用されているため、ナレッジやユーザも大変多いです。Prometheusは、CNCFのGradueted Project（1人前のソフトウェアとして）に認められたとはいえ、この差を埋めることはできません。
また、PrometheusはPrometheusサーバー以外にも、AlertmanagerやGrafana、Pushgateway、Exporterなどさまざまなコンポーネントを扱います。これらをすべて運用するのは中々パワーが必要なため、All in Oneで利用可能なZabbixのほうが楽ということもあります。
さらに、Prometheusはメトリクスの値が100%の制度であることを保証していません。そのため、課金システムなどでPrometheusを利用するのは避けたほうが良いでしょう。
さらにUIの整理方法についてですが、これはGrafanaを使うのが良いでしょう。
Grafanaはダッシュボード作成や管理を専門とするツールです。Grafanaでは、外部の監視システムなどのデータを参照してダッシュボードを作成しますが、このデータソースとしてPrometheusもZabbixも利用可能です。
こうすることで、それぞれのシステムのダッシュボードを1つのGrafana上で管理できますし、何ならPrometheusとZabbixのデータを混合させたダッシュボードも作成可能です。こうすることで、大量に存在するさまざまなダッシュボードや管理画面を行ったり来たりしなくて良いわけです。
oss限定でのmetricsやlogのDBはどれが一番良いんでしょうか？
イチオシはVictoriaMetrics
リモートストレージ向けのOSSとしてはいくつかありますが、個人的にはVictoriaMetricsがめちゃイチオシです。最小構成のでは1つのコンポーネントで簡単に起動でき、仕組みとしても比較的シンプル。本番環境や大規模な環境ではよりスケールする”クラスタバージョン”を使って高い可用性で運用可能です。
もちろん、Prometheusを公式でサポートしているため、PromQL準拠でクエリが実行できます。
次に「Log」と質問にあるので、こちらはGrafana Lokiのことと推測します。
Lokiでは、ストレージには以下の2種類があり、それぞれサポートするストレージが異なります。
- インデックス
- チャンク
基本的にはマネージドサービスが並んでいますが、この内どちらにも共通するOSSが”Apache Cassandra”です。これについては、正直私が運用したこと無いので詳しいことは言えませんが、中々大変そうという印象です。
対応ストレージの詳細は以下をご確認ください。
エクスポーターは監視対象サーバにインストールするエージェントのようなものなのか
半分Yes、半分No
エクスポーターは、Node exporterのように監視対象それ自体にインストールするタイプのものや、Blackbox exporterなどのように監視対象から離れて設置するものもあります。
とはいえ、基本的にはエージェント的に扱うという理解で問題ないかと思います。
最小構成として、Alertmanager, Grafanaと監視対象用のサーバーで学習するために3台サーバーが必要？
サーバ（Linux）という意味であればNo。1台でOK。
コンポーネントとしては、最低限↓があると色々遊べます。
- Prometheus Server
- Alertmanager
- Grafana
- 監視対象サーバ
なので、4つのサーバが必要かと思いきや、基本的にそれぞれ同居可能なので、学習目的であれば1個のLinuxサーバがあればOKです。書籍の方でも、このあたりのチュートリアルを用意しているのでぜひご活用ください。
イベントを振り返って
ここからは、主に私のお気持ち表現になりますので、技術ネタは以上となる点についてご注意ください。
謝辞
まず、今回このようなお話をさせて頂く場を用意していただきました、株式会社エーピーコミュニケーションズ様、本当にありがとうございます。
今回お話して、改めて「Prometheus実践ガイド」に皆さん興味があるということがわかりました。Prometheusというキーワードは、クラウドネイティブ界隈では比較的人気なカテゴリの1つですが、ITインフラ全体で見た場合はまだまだ小さいと感じていました。ただ、今回お話させていただき、「Prometheusを知らなかったがぜひ触ってみたい」というお声を多数いただき、そういった方にPrometheusや書籍を知ってもらえたということが何より大きいです。
改めて、このような機会をいただき誠にありがとうございます。
また、当日ご参加してくださった皆様、本当にありがとうございます。どうなるか不安でしたが、大変好評なお声をいただき、イベント終了後に安堵しました。
登壇内容について
Twitterを見ていると、「Prometheusについて何も得られなかった…」というお声をチラホラ見ました。今回は、書籍のイベントということで、書籍に関しての思いを熱く語らせていただきましたが、逆に技術情報を期待していた方には、その期待にはお答えできなかったことが悔しいです。
30分というお時間の中で、書籍についての思いと、技術情報の両方を提供するのは中々難しいのでご理解をいただきつつ、今後似たような機会があった場合は、技術情報を織り交ぜて、より楽しんでいけるようなお話をさせていただければと思います。
書籍への思い
実は「Prometheus実践ガイド」は、単に私のPrometheusに関する知識を共有することが目的ではありませんでした。本書を通して、「Prometheusに関する情報の選択肢が増える」ことが最大の目的であり、そのために本書を執筆しました。このような目的には、私の個人的な経緯があります。
オライリーの入門Prometheusが発売された当時、当然発売日にすぐ手に入れたのですが、1点だけとても残念に感じたことがありました。それは、「ストレージについての記述が非常に少ない」ということでした。ちょうど業務でリモートストレージの運用について悩んでいたところで、これについて知りたかったのですが、入門Prometheusではあまり詳細に取り上げられていませんでした。また、それ以外に日本語の書籍はなく、インターネット上のさまざまな情報を調べなければならず、非常に苦労したのを覚えています。
その後、本書執筆のお声を頂いた際には、ぜひストレージについては詳細に書こうと、そして同じように「この情報が欲しかった…！」と思えるような書籍にしようと考えました。
そのため、実は本書のストレージは単一の章として取り上げられ、特に私の中でもおすすめの章の1つです。ぜひお持ちの方、これから手に入れられる方はお読みいただければと思います。
他にも、本書の1章はPrometheusではなく、システム監視について書かれています。これは、Prometheusを単にツールとして扱うだけでなく、それぞれの機能が存在する背景を知ってもらうためにも、Observabilityの考えなどを先に持ってきました。
このように、実は本書は私の暑苦しい思いともに書かれた書籍だったわけです。
終わりに
ぜひPrometheusが気になる方、これから業務で利用する方、本書を手にとって見てください。そんな私の熱い想いがマッチする方には、有用になるかもしれません。
