'Prometheus Meetup Tokyo #3 に参加してきました'
1/15に 行われた Prometheus Meetup Tokyo #3 にブログ枠で参加してきました。
https://prometheus.connpass.com/event/157721/
Prometheusと私
昔ちょっとだけ触った
はじめに私の Prometheus 歴ですが、3年ほど前に前職で同僚が試していたのをちょっと横目にみた程度で、雰囲気は知っていますが実運用は行ったことがありません。 当時触れていたシステムではZabbixが主流で、その置き換えとして Prometheus ってどうなの？という検証をやっていた記憶があります。その時はPrometheusやGrafanaへの割り当てリソースの問題もあったとは思いますが、Grafanaからのクエリ応答が非常に重くて「まあ、Zabbixで良いんじゃない」という感想で終わっていました。
今は全然触ってない…
現在は全く触っていません。自前運用しているGitLabCEで動いていることは知っていますが、内部で動いているので意識する必要はありません。システムの監視は基本的にSaaSを利用していて、Mackerel・Datadog・NewRelicをシステムや適材適所を考えながら利用しています。
参加のモチベーション
現状触っていないのになぜ参加したかというと、知識のアップデートが主な目的です。 3年前にちょっと検証しただけの「何か重くって微妙…」の感想を払拭したいと思ったのと、Kubernetesの上で動作するコンテナの運用が増えていく中で、改めてPrometheusという監視の選択肢を見つめ直したいなと考えました。
Prometheus Meetup Tokyo #3の感想
会場
会場は以下で行われました。田町駅から5分程度と立地も良く、内装も素敵で良い会場でした。事前にメール配布されたQRコードでの入室ができるのもスマートで良かったです。 今考えると34Fの高所から夜景を眺めておけば良かったと少し後悔しています。1
日本電信電話株式会社 ソフトウェアイノベーションセンタ
1 - Remote Write API と Thanos を活用したメトリクス永続化 (仮)
1本目から大規模な環境の話で興味深く拝聴しました。 500以上のK8sクラスタを運用する中でPrometheusを運用しており、課題として “短時間のメトリクスしか参照できない” 問題があり、それをThanosを用いて解決した、という話でした。
Using Thanos as a long-term storage for your Prometheus metrics - Speaker Deck
冒頭で「Prometheusについては入門Prometheusにお任せします」でさらっと始まり、課題解決のために模索した3案について説明を頂きました。
- Cortex案は仕組みが複雑で運用負荷も高そうだから見送った
- 独自Adapterを開発して運用していたが、Write APIが負荷分散できない＆Write APIのダウンがクリティカルな問題になるので課題があった(現在の2.8以降は改善されてるかも)
- 最終的にはThanosを採用し、独自Adapterを置き換えた。Thanos Receiveは冗長化もできるし2、Thanos Queryを利用してユーザはメトリクスを長期間に対して検索ができる
Thanosについてはコンポーネントについて丁寧に説明があり、おかげで概要について学ぶことができました。
Thanosのコンポーネントの説明、後で復習しなきゃ#prometheustokyo
まとめとして、まだまだワークアラウンド的な不具合回避が必要だったり、500以上の複数クラスタ全てのメトリクスをThanosで受けるには超えていく課題があるよ、という締めでした。
2 - Victoria Metricsで作りあげる大規模・超負荷システムモニタリング基盤
こちらも大規模な事例で、コロプラ社のゲーム基盤のモニタリングで Prometheusを利用しており、超有名タイトルの負荷試験時にPrometheus自体が高負荷でOOMで死に、運用に耐えない問題を受けてVitoria Metricsを選択したという話でした。
負荷の原因としてはGrafanaが直接QueryをPrometheusに実行しているため、3rd party storageとして以下の検討を行ったが、どれも問題があり
- Cortex -> 構成が複雑…
- Thanos -> Remote APIでメモリが2倍になる不具合
- M3DB -> ちょっと複雑…
コミュニティ3からの助言でVictoria Metricsを導入して安定動作するようになったとのこと。Victoria Metricsについても丁寧に説明がありました。
- シンプルな構成(コンポーネントがレイヤ毎にありわかりやすい)
- Scale-Outが可能(ただしScale-Inはできない)
- 安定してる
個人的に面白く感じたのは、Scale-Outが可能な理由の説明の中で「毎回全てのVMStorage4にクエリを実行するので、データがどこに分散されようが問題がない」という仕様でした。
面白い「複数のストレージ全てに同時にクエリを投げて、戻りをマージする。よってどのストレージに分散されても問題ない」#prometheustokyo
Victoria Metoricsのチューニングについても解説や
- 公式ドキュメントの通り
- エラーメッセージに推奨値が出るのでそれに従う
それ以外の工夫なども面白く拝聴しました。5
内容も学びが多かったのはもちろんですが、発表全体を通してスピーカーの入江さんのキリッとした語り口調が素晴らしくて、ある種アカデミックな空気感があって良かったです。
また、このブログを書くためにアップいただいた資料を見直しましたが、Appendixとして付録が付与されていて、発表時より読み応えが増えてました。粋な試みですね。
3 - 次世代のログ基盤 Grafana Lokiを始めよう！
前半は @uesyn さんから Grafana Loki の概要について、 後半は @kameneko1004 さんからLokiへLabel付けしながらログを送信する promtail についての解説でした。
次世代のログ基盤 Grafana Lokiを始めよう! / prometheus-meetup-tokyo-3-lets-start-the-loki - Speaker Deck
Grafana Loki については名前くらいしか知らなかったのですが、ログ収集＆検索をGrafanaで実現するプロダクトということがわかる良いセッションでした。
特に印象深かったのは、Grafana LokiのアーキテクチャはCortexとほぼ同じだということで、そのCortexは前の2セッションとも複雑というコメントがされていたこと。
lokiのアーキテクチャはほぼCortexのそれで、今日は何度も複雑といわれた構成#prometheustokyo
promqlについては「正規表現でログパースするの辛いからアプリ側に頼んでJSONでやっとけ」というのがかなり真理なんだろうなぁってしみじみした感想です。発表に勢いとユーモアさがあって楽しく聞くことができました。
LT
懇親会で新しい出会いもありつつ、お酒とまい泉のミニコロバーガーをいただきながらLTも楽しく聞きましたので一言感想を。
イベントネットワークのlog監視をlokiでやってみた - gen16k
ICPCという国際大学対抗イベントでネットワーク機器の監視をPrometehusでやってみたという話で、Zabbixを讃えつつ時にディスりつつPrometheusでどう頑張ったか、頑張りきれなかったかが面白く伝わってきました。落ちが「Zabbixでよさそう」なのも笑えました。6
Grafana Lokiでイベントネットワーク監視をやって見た話 - Speaker Deck
レガシー環境でも Prometheus はイケるんです - Kazuhito_Omachi
LT2本目は一番勢いがあってLTらしかったと感じました。レガシー環境にPrometheusがどう効果的なのかがシンプルに伝わってきましたし、金の力でスケールアップ！みたいな良い割り切りノリは好感が持てました。
レガシー環境でもPrometheus はイケるんです | PDF
Prometheus でデータの水平分割を試みる - watawuwu
LT3本目はまず資料のデザインが良かったのが記憶に残りました。内容としても面白くて、ラベルハッシュ、メトリクス、ルールそれぞれの単位でデータを分割する方法が提示されてました。スケールアウトはできるがリバランスやリシャーディングができないというのは、Victoria Metricsでも同様の制約があって、ある種の割り切りなんだろうなと感じました。
Prometheusでデータの水平分割を試みる/Let’s split prometheus data - Speaker Deck
Lokiでjurnal logを可視化する方法 - yosshi_
LT4本目は飛び込みで Victoria Metrics をコロプラさんに紹介したという@yosshi_ さんでした。 3本目のセッションの中でpromtailについて「障害起きると辛い」的なQAがあり、それへの一つの回答としての記事紹介でした。結局のところ諦めない心とプロダクトへの理解が大事なんだな（大変そう…)ということが良く伝わってきました。
Grafana Lokiを使ったKubelet Logging入門 #kubernetes - Qiita
Grafana/Lokiの開発元にfluent-bitのプラグインを作成してフィードバックした話- Hiroshi Hatake
最終LTはクリアコードの方で、私はGroonga7の会社という認識を持っていましたが、fluentdと聞いてなるほどとなりました。全体的にPrometheusの運用の話が多かった中で、最後に開発な話でインパクトがありました。トークも切れ味あって素敵でした。
Prometheus meetup tokyo#3 slide | PDF
まとめ
総括して学びの多い素晴らしいイベントでした。目的だったPrometheusについて自分の古い知識のアップデートも十分達成できましたし、3rd party storageを利用した長期間データの保存の実現や、Grafana lokiのようなエコシステムが今後成熟していく中で、今後もdatadogなどのSaaSとの選択に迷っていくのだろうなと感じました。8