この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
はじめに
1/15、今回で 3 回目となる Prometheus Meetup Tokyo が開催されたため参加してきました。
今回のテーマは「Prometheus を取り巻くエコシステム達」ということで、Thanos や Victoria Metrics、Grafana Loki など、Prometheus の機能を拡張するソリューションやその事例について熱いプレゼンテーションが行われました。
会場は東京・田町駅から徒歩圏内にある、 NTT ソフトウェアイノベーションセンタさまのイベントスペースでした。こちらの会場は OSS に関する非営利イベントであれば貸し出せるとのことです。
「Prometheus Meetup Tokyo」の会場準備完了！あとはみなさんが来るのを待つだけ！今日は、Prometheus のエコシステム回なので楽しみ?https://t.co/M8WOgemcRO
#prometheustokyo pic.twitter.com/7SEKYURZNV— yosshi_(Shota Yoshimura) (@yosshi_) 2020 年 1 月 15 日
また会場には軽食と飲み物が用意されており、そちらは Z Lab さまのご提供とのこと。ありがとうございました！
それでは順にレポートして行きたいと思います！
既に当日のセッション録画動画が公開されていますので、お時間があれば是非そちらもご覧頂きたいと思います。
目次
- Remote Write API と Thanos を活用したメトリクス永続化
- Victoria Metrics で作りあげる大規模・超負荷システムモニタリング基盤
- 次世代のログ基盤 Grafana Loki を始めよう！
- LT: Grafana Loki でイベントネットワーク監視をやってみた
- LT: レガシー環境でも Prometheus はイケるんです / 全然モダンじゃない Prometheus の運用ください
- LT: Prometheus でデータ分割を試みる
- LT: Grafana Loki を使った Kubelet Logging 入門
- LT: Grafana/Loki の開発元に fluent-bit のプラグインを作成してフィードバックした話
Using Thanos as a long-term storage for your Prometheus metrics （Remote Write API と Thanos を活用したメトリクス永続化）
- スピーカー : Moto Ishizawa (@summerwind)
- Z Lab Corporation
- 500 以上の k8s クラスタが稼働中
- 各クラスタ専用の Prometheus
- 各クラスタのノードは数週間で作り直されてしまう
- 各 Prometheus のメトリクスを永続化したい
- オンプレで運用している
- 課題に対するゴール (どうしたいか)
- 180 日以上のメトリクスを参照できるようにしたい
- Prometheus の割り当て RAM は最小限にしたい
- Cortex はどうか？
- SaaS （Weave Cloud など）の裏側で使われており実績がある
- でも複雑
- データストア（DynamoDB など）が必要なので運用がきつそう
- オブジェクトストレージが使いたかった
- 独自アダプタを開発するのはどうか
- Prometheus の Remote Read/Write API を使う
- ユーザからは、単にストレージが大きくなっただけに見える
- メトリクス参照のために RAM は必要
- Remote Read/Write API の注意点
- 負荷分散はエンドポイント側で行う必要あり
- ダウンしたときに未転送のメトリックが lost する -> v2.8 以上で解決
- ドキュメントによると「今後プロトコルが変わる可能性がある」
- Thanos
- Prometheus 互換システム
- 必要なコンポーネントだけ選んで使うことができる
- Receive コンポーネントを使ってみた
- まだ実験的な扱いのもの
- メトリクスの参照は Thanos Query から行うように
- Thanos Receive の冗長化
- メトリクスの担当の Receive が決まる
- 送られてきたメトリクスのラベルセットの HASH などから算出
- 担当でない Receive が受け取っても勝手に担当に転送する
- メトリクスのレプリケーションも出来る
- 話者は使ってはいない
- エラーになったとしても Prometheus 側の WAL (Write Ahead Log) に残りリトライされる
- 複数保存してもクエリ側で重複排除される
- メトリクスの担当の Receive が決まる
- Thanos Receive 利用時の注意点
- 実験的なコンポーネント
- ドキュメントがない
- 細かい挙動はコードを追いかけないとだめ
- Label まわりに不具合っぽい挙動あり
- まとめ
- シンプルな環境ではほぼゴール達成
- より多くの Prometheus からメトリクスを受信するには以下のような対策が必要
- 複数メトリクスの混在を防ぐ仕組みの実装
- Thanos Receive のパフォーマンス検証
- Thanos Receive の冗長化機能の利用
Q&A
- 1 クラスタあたりの規模感は？
- 大小さまざま、5〜10 ノードくらいが一般的
Victoria Metrics で作りあげる大規模・超負荷システムモニタリング基盤
- スピーカー : 入江 順也 (GitHub: inletorder)
- 株式会社コロプラ
- 新卒入社５年目
- GKE タイトル運用、運用効率化担当
- 最近の発表 : GKE と Cloud Spanner が躍動するドラゴンクエストウォーク
株式会社コロプラ『GKE と Cloud Spanner が躍動するドラゴンクエストウォーク』第 9 回 Google Cloud INSIDE Game & Apps from Google Cloud Platform - Japan
- 150Billion（1,500 億）
- DQ Walk の累計データポイント（10k+ の Pods より）
- これまで
- Single Tenant 構成
- ゲームタイトル毎に k8s クラスタ、それぞれに 1:1 で Prometheus
- リリース前の負荷試験時、想定負荷の 1/4 で問題が顕在化
- 負荷試験開始数分で Prometheus が落ちる
- Prometheus のスケールアップは効果無し、ハングしてしまう
- 問題：Grafana が直接 TSDB にアクセスしているところ
- Cortex は試そうとした
- 複雑、管理コンポーネントが多い
- Cortex は最終手段としてあとまわし
- Thanos
- 直近データのクエリは Prometheus にも行く
- やっぱりメモリがひっ迫
- 今では解消しているかも？
- M3DB
- etcd を別途立てる必要あり
- 扱うコンポーネントの数は極力減らしたい
- 学習コストが高そう
- Twitter で VictoriaMetrics を教えてもらう
- これで解決した
- VictoriaMetrics とは
- Cortex や Thanos と同じ立ち位置
- 信頼性高い
- VMStorage
- TSDB
- スケールアウト可能（スケールインは出来ない）
- VMSelect は全てのストレージに同じクエリを投げる
- VMSelect
- ステート持たない、スケール簡単
- VMInsert
- 同じくスケール簡単
- pod 数が 8,000 を超えた辺りで k8s のコントローラがあやしくなったのでマルチクラスタにした
- 安定した理由：役割分担
- Prometheus に Grafana が見に行かないようになったことが大きい？
- Prometheus はスクレイピング専門にしたほうが良い
- 課題
- クリティカルなところはスケールイン不可なところのみ
- Performance Tuning
- 基本的なところのみ
max_samples_per_send:一度に送る最大 sample 数maxConcurrentRequests:同時リクエスト数maxUniqueTimeseries:上限に達したとログに出たので増やした
- 負荷試験中にブラウザが落ちた
- Grafana 上で表示するパネル、描画点が多すぎた
- 表示するメトリクスや時間を絞る
- 最終的にはよい PC を用意した -> 金で解決！
- 恒久的な対応ではない
Q&A
- データの冗長化について
- VM は冗長化できない、ローリングアップデートできない
- 永続化、ダウンサンプリングも可能、リテンションは 2y
- スクレイピングの間隔は 1 分間
- Prometheus も冗長化していない
次世代のログ基盤 Grafana Loki を始めよう！
- スピーカー :
- 仲亀 拓馬 (@kameneko1004, さくらインターネット 株式会社)
- 上村 真也 (@uesyn, Z Lab Corporation)
- Grafana Loki - Log aggregation system
- 「Prometheus のように」ログを扱う
- ログをシンプルに扱う
- ラベルを付与して保存、フィルタリング
- 形態素解析のようなことはしない
- Grafana Loki
- ほとんど Cortex のアーキテクチャと同じ
- Loki 自体は DB ではない
- 2 種類の DB がある
- index : インデクス
- chunk : 実際のログを保存
- ハッシュ値は Consul や etcd に保存（そのうち依存しなくなる？
- 様々なコンポーネントがあるが、全て同じバイナリ
- シングルプロセスで全てのコンポーネント機能を動かすことも可能
- マルチテナント可能
- Grafana 連携
- Grafana からログ検索
- ログパネルが利用可能
- Automatic Annotation
- How to Do Automatic Annotations with Grafana and Loki | Grafana Labs
- メトリクスの変化ポイントに自動的にログを紐付ける
- Promtail
- 各 Node 上で Pod 等のログを収集するエージェント
- k8s と上位 Nginx のログをまとめて見るようなこともできる
- Prometheus ライクにディスカバリする
- ログストリームにラベルを付けることで検索高速化している
- ログからアラートを生成する <- たのしい
- カスタムメトリクスを生やして Prometheus 側でアラート設定する
- ドキュメント
Q&A
- ログは pod がいるノードだけ対象
- 正規表現がんばれ
- Promtail の WebUI があって、デバッグはそこで頑張れる
- 過去のログに対するリラベリングは難しそう
- Prometheus 全体として、ラベルの管理はちゃんとしないとつらい
- file 以外の target（journal, systemd）の指定の仕方
- 方法はある、基本的にはだいたい file なので今後はわからない
LT: Grafana Loki でイベントネットワーク監視をやってみた - gen16k
- イベント
- ICPC 国際大学対抗プログラミングコンテスト
- 66 チーム 300 名が参加
- ping やメトリクスは Prometheus で
- スイッチの syslog 監視を Loki で
- I/F の down/up など
- Loki だけでは実現できなかったところがあった > mtail,同僚作ツールで回避
- 問題点
- snmp-trap を受信できない
- 監視用プロダクトの数が多くなりがち
- 一元化できていない（どの画面をみればいい？）
- 良かった点
- (zabbix より) 画面が見やすい！
- (zabbix より) 画面がかっこいい！
- 構築が簡単（コンテナ化したので）
- Loki を実運用で検証できた
- まとめ
- イベントネットワーク監視ならZABBIX でよさそう
- 持つべきものは優秀な同僚
LT: レガシー環境でも Prometheus はイケるんです / 全然モダンじゃない Prometheus の運用ください - Kazuhito_Omachi
- Prometheus はレガシー環境に最適
- 1 台のサーバで実行ファイルを動かすだけ
- 数万台監視できる（スケールする）
- 構成はシンプルに 2 台で冗長化
- Active/Stand-by 構成に
- 監視対象が増えても、メモリを足せばスケールする
- -> 金で解決！
- 現状で CPU/メモリともに 60%程度
- データ欠損は「仕方ない」と割り切る
- DB リカバリーに 20 分くらいかかる
- 欠損症状の緩和
- 設定のリロードは
kill -HUP - DB リカバリ中はヘルスチェックを失敗させる
- Management API
- 設定のリロードは
- システム管理構成がレガシー環境で独自進化したことによる闇
- 監視対象サーバの追加削除 = サーバリストを CRON で流し込む
- 以下の方法でもいい：
- 結論：レガシーでも Prometheus はイケます
LT: Prometheus でデータ分割を試みる - watawuwu
- Prometheus だけで分散できる方法
- 高可用性も長期間保存もここではふれません
- メモリとストレージの使用量増加にどう対応するか、を検討した
- ↑の解のひとつ「スケールアウト」
- リモートストレージナシでのスケールアウト
- Prometheus の設定変更だけで実現可能（pull 型の利点）
- A. scrape ルールごと
- 一般的
- B. メトリックごと（時分割ではない）
- metrics name
- 管理大変、実運用ではナイ
- C. ラベル HASH ごと
- 本題
action: hashmodmodules: ${shard_total}regex: ${shard_num}を使うと良い
- ブラウズとアラートはどうする？
- A. Remote read API を使って Aggregate する
- （試したことはない）
- B. Thanos を使って Aggregate する
- Querier, Ruler, Sidecar
- A. Remote read API を使って Aggregate する
- 課題
- 自動スケーリングはしない
- 冗長構成は難しい
- リシャーディング・リバランシングは出来ない
LT: Grafana Loki を使った Kubelet Logging 入門
- Loki でジャーナルログを見る方法について（既存のブログを使って補足説明）
- Loki で journal log を見るための変更ポイント
grafana/promtailの image は-amd64とついているものを使うこと（そうでないと動かない）- ホストのログを見たいときにはちゃんと
hostPath:指定しておく
- 実際にやろうとしたとき、ドキュメントがなくてつらかった
- CHANGELOG やコメントを根気よく追っていくと解決できたりする
- そうやると Loki と仲良く出来る
- 結構動く
- ドキュメントがなくてつらいだけ
LT: Grafana/Loki の開発元に fluent-bit のプラグインを作成してフィードバックした話- Hiroshi Hatake
- fluent-bit : アウトプットのみなら Golang でプラグインが書ける
- 詳しい解説↓
- fluent-bit -> Loki にログを転送
- Golang
- gRPC（API は非同期・バッチ的に送信される）
- 作ってみた
- 作った理由
- ログコレクターの中のひととして Loki に触れておきたい
- Promtail よりも慣れ親しんだプロトコルで Loki にログを入れてみたい
Promtail がちょっと使いづらいそこに Issue があったから
- ある日
- Grafana/Loki の中のひとから打診があった
- 「Grafana/Loki にマージしてみるのはどうよ？（するよね？）」
- 圧を感じた
- フィードバックしてみた
- 一般に OSS の作法に準じればちゃんと見て貰える
- 1 はっきりとした同期を書く
- 2 関連する Issue 番号
- 3 チェックリストがあれば埋める
- フィードバックすると良いこと
- 独力ではすぐに対応できないプラットフォームに対応できた
- ちょっとした不便さや、新しく作った便利さを正しく開発元に伝えて昨日よりも便利にしていきましょう！
まとめ
19:00 開始で 22:00 近くまで行われた、非常に中身の濃い Meetup でした！
システムモニタリングの界隈ではいま、メトリクスとログを一元的に監視しようという動きが盛んで、例えば商用 SaaS の Datadog や New Relic も同様の機能を拡充しています。それらと比べると Loki はまだまだこれから（ドキュメントの整備も含め）といった感触がありますが、「Prometheus（メトリクス・イベント）と同じやりかたでログも扱う」という熱い設計思想と、何はともあれ「いま動いている Prometheus に追加で整備できる」環境としてはメリットも大きいのではないでしょうか。Automatic Annotation とかしびれますね！
個人的にも、たまたま隣に座られた初見の方と、監視・モニタリングや AWS の活用について意見交換ができたりと、有意義な Meetup でした。
主催・運営の方々に感謝しつつ、次回以降もできる限り参加していきたいと思います。
7
