ちょっと話題の記事

クラウド世代の OSS 監視システム「Prometheus」 Meetup でがっつり話を聞いてきた #prometheustokyo

6/3 渋谷で行われた Prometheus Tokyo Meetup #2 をレポートします。クックパッド社やヤフー社の事例など、 Prometheus ヘビーユーザの方々によるセッション・LTが非常に興味深いミートアップでした
特集

渡辺聖剛

2019.06.10

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

6/3 渋谷で行われた Prometheus Tokyo Meetup #2 をレポートします。 Prometheus といえば「クラウドネイティブ」というキーワードの中で語られることの多いインフラ監視・モニタリングソリューションですが、本ミートアップではクックパッド社やヤフー社の事例など、 Prometheus ヘビーユーザの方々により特徴や活用事例が語られる、非常に興味深いものでした。

Prometheus Tokyo Meetup #2 - connpass

なお、本ミートアップはサイバーエージェント殿協力の下、渋谷の Abema Towers にて行われました。

動画

入門 Prometheus

  • スピーカー : Kazuki Suda (@superbrothers)

Prometheus は、メトリクスベースのモニタリングシステムです。もし本番環境の CPU 全体におけるアイドルではない時間の割合やアプリケーションの秒間リクエスト数が時間の経過とともにどのように変化しているといったインフラからアプリケーションのパフォーマンスを計測したければ Prometheus が利用できます。このセッションでは、Prometheus の概要からアーキテクチャ、主な exporter の紹介やメトリクスの集計、ダッシュボードの作成方法、アラーティングといった Prometheus を今日から始めるための一通りをお話します。

  • 入門 Prometheus / Introduction to Prometheus - Speaker Deck

  • Prometheus

    • 動的な環境での監視が得意 -> コンテナ、クラウドに最適
  • 「モニタリング」とは
    • 本番環境でアプリやツール、データベース、ネットワークの問題を知り、それに対処するための情報を得て、問題に対処すること
    • アラートと問題の特定
    • デバッグ情報の提供
    • トレンド調査
    • キャパシティプランニング
    • 他のシステムへの情報提供
    • AutoScaling など自動化のため
  • モニタリングのカテゴリ
    • logging
    • tracing
    • metrics -> Prometheus が扱う領域
  • アーキテクチャ
    • prometheus サーバ
    • バイナリひとつ
    • Go
    • コンテナで動かしたり
    • prometheusはステートフルアプリケーション
      • TSDBはHDD/SSDに吐き出す
      • ブロックストレージをマウントするなど
    • Prometheusの開発方針 = データの永続化をPrometheusで持つよりは、他の得意なものに任せる
  • スクレイピング
    • Prometheusがメトリクスをpullすることをこう呼ぶ
  • メトリクス
  • exporter
    • 定義「他の形式のメトリクスデータをprometheusで処理できる形式に変換するもの」
    • 数百のexporterがOSSで公開されておりすぐ使える
    • 独自exporterも簡単
    • 公式・非公式クライアントライブラリ
  • pushgateway
    • 本の中に書いてある
  • サービスディスカバリ
    • 監視対象（ターゲット）をPrometheusが認識する方法
    • fileだったりDNSだったりAWS APIだったり
    • もちろんk8sだったり
  • ダッシュボード
    • Grafanaが本番
  • PromQL
    • 集めたメトリクスを検索して表現
    • レコーディングルール、アラートルール
    • ダッシュボードもアラートも同じ言語で書ける
  • アラート
    • 定期的にPromQL式を実行し、結果がそのままアラートとなる
    • アラートの通知は責任外（作るところまで）
    • あとはalertmanagerの仕事
  • 長期ストレージ

＊　＊　＊

Prometheus の特徴をそのアーキテクチャから丁寧に説明した、まさに「入門」と呼ぶにふさわしいセッションでした。それもそのはず、スピーカーの須田氏は書籍「入門 Prometheus」の監訳者に名を連ねています。

ただ時間の都合で駆け足（終盤は特に）となってしまったのが、個人的には少々残念でした。なお「より詳しく知るためには本を読んで下さい」とのことで、正論だと思いましたｗ

Prometheus and Cookpad

  • スピーカー : Ryota Yoshikawa (@rrreeeyyy), クックパッド株式会社

クックパッドでの Prometheus の使われ方について紹介します。特に、マイクロサービスやコンテナ環境のモニタリングと、Prometheus の Rule や Alertmanager の設定ファイルを Jsonnet で管理しているということについて紹介します。

  • Cookpad and Prometheus - Speaker Deck

  • CoockpadとPrometheus

    • 2017年くらいから徐々に
    • リージョンごと（TokyoとUS）に2台ずつ
    • IoT機器の監視にも使われ始めている
  • 対象 - 1k〜2k、だいたい 1.8kくらい
    • ASGで勝手に上下する
  • 使われ方
    • Prometheusルール、Alertmanagerはプルリク
    • 開発者が勝手に定義を変更したり独自exporterを作ったりする
    • GitOps
    • Vizceral でマイクロサービスのトラフィックを可視化
    • Netflix/vizceral: WebGL visualization for displaying animated traffic graphs
    • envoyのメトリクスからサービスグラフを自動作成
    • envoyは一部のメトリクスをうまく取得できない問題があった > statsd_exporterを使っている

運用の工夫

  • サービスディスカバリ
    • ec2_sd_configを普通に使っている
    • ECSのコンテナ等の監視ではサービスカタログを自作してsd(サービスディスカバリ)している
    • AWS APIのレートリミット対策
  • exporter_proxy
    • EC2インスタンスなどの監視ではexporter_proxyを通す
    • 使わない場合 : exporterの数だけLISTENポートが増える > 都度SGの修正が発生してしまう
    • 自作
    • 機能的にはNginxなどでもよかった
    • サービス(Nginx)とモニタリング(exporter_proxy)を分けたかった
  • Prometheus のルール = Jsonnetで
  • labels / annotationの活用
    • アノテーションにrunbookのリンク書いておく（そういう習慣を付けておく
  • アラートマネージャーのルーティング
  • Long-term storageなどはまだ（ちゃんとしたい機能がいろいろ…）

QAより

  • どう冗長化しているか
    • 複数たてたPrometheusそれぞれがスクレイピングしている(Act/Act)
    • そんなにコストもかかってない（各々300GB?くらい）

＊　＊　＊

とても実践的なセッションでした。exporter_proxyの工夫やVizcerelなど刺激を受ける話も多かったと思います。以後のセッションでも Jsonnet を活用しているという話は多く、（やっぱり JSON はどこのインフラ業界でも人類にははやかったんやな…）って少し思いました。

Prometheus at PFN

  • スピーカー : 荒井 良太 (@ryot_a_rai ), 株式会社Preferred Networks

Preferred Networks (PFN)ではオンプレミスのKubernetesクラスタで機械学習基盤を構築しており、そのモニタリングにPrometheusを利用しています。このセッションではPFNでのPrometheusの利用事例、Thanosを利用したスケーラブルなPrometheusのデプロイなどをご紹介します。

thanos.io

  • Thanos - Highly available Prometheus setup with long term storage capabilities
  • Cortexと近い
  • HA
    • 複数のPrometheusインスタンスから集められたメトリックを重複排除する
  • 複数のPrometheusにまたがったメトリックをクエリ出来る
    • 以前はFederationを使用し集約していた > 入門Prometheusではバッドプラクティスと言われた
  • Unlimited Retention
    • データストアとしてS3やGCSなどを使える
    • ただしメモリ使用量の増加には気をつけること
    • Remote Writeは使用していない（uploadするだけ
  • Downsamplingなど
    • PFNでは使っていない
    • 単純な間引きでは無く平均などの統計値になるから
  • Thanos Store, Query はステートを持たない
    • かつメモリ食う
    • EC2スポットインスタンスで
  • メモリをすごくくう問題
    • OOM Killerに殺される
    • 事前に見積もるのはほぼ不可能

その他

＊　＊　＊

一昔前から主流の「HPC + Ganglia」 という構成が、そのまま「ML + Prometheus」に置き換わったような印象をうけました。コンピュートリソースが増減する環境とは相性がいいのかもしれません。また監視対象に GPU が含まれているのも興味深かったです。ただ ML 環境に限らず、 Thanos や Trickster 、 Query Recorder など、Prometheus が不得意とするところをサードパーティ製あるいは内製のソフトウェアをうまく活用しているところなど、ひろく参考になるセッションだったと思いました。

（まったく関係ない話ですが、Thanos ってやっぱり彼のことなんでしょうか…？）

データセンターネットワークでのPrometheus活用事例

  • スピーカー : 安藤 格也 (Twitter: @akakuya, GitHub: servak), ヤフー株式会社

ヤフーのデータセンターネットワークの監視としてPrometheusを活用しているため、そちらの活用事例について発表させていただきます。

データセンターネットワークでのPrometheus活用事例

  • DCごとに集約用のPrometheusを立てている
    • 多いから
    • あるデータセンタでもっているサンプル数 = 4400,000
    • I/Fが多い、各I/Fごとに多数のメトリクス
    • 物理、論理I/F
    • シャーシ型のスイッチだと 300I/F x 1I/Fあたり70メトリックなど
    • Global Prometheus
    • Federationで集約
    • クエリに時間がかかってしまう問題
      • Thanosを検証中
  • 死活監視
    • blackbox_exporter
    • ICMP
    • DNS
    • HTTP(S)
  • ネットワークの種類
    • Data plane = サービス用のデータが流れるネットワーク
    • Control plane = スイッチ・機器をコントロールするネットワーク
    • ToR = Top of Rack = 集約スイッチ
  • Inhibit rule
    • 重要度の高いアラートのみを通知
    • groupとseverityによりアラートの抑止が可能に

リソース監視

  • exporter
    • snmp_exporter
    • node_exporter = Whitebox Switchに入れている
    • custom_exporter
    • 独自
    • switch, lb
  • 監視項目
    • トラフィック
    • CPU、メモリ、OS情報、uptime、モジュール、リンク(L2)情報
    • バッファーあふれ
    • 破損パケット数上昇検知
    • 電源故障・温度監視
  • I/F数が多く選択が困難 = Tagを活用
    • metric_relabel_configs
  • イベント情報表示
    • GrafanaのAnnotationを活用

その他

  • サービスディスカバリ
    • 社内構成管理データベース(CMDB)からFileSDに
    • CMDB内でIPAM情報なども保持
    • Data plane、Control plane情報を付与
  • ChatOps
    • ChatBot (hubot) からAlertmanagerのAPI

まとめ

＊　＊　＊

多数のデータセンターを抱えるヤフーのネットワーク機器監視ノウハウ（の一端）が垣間見られたセッションでした。SNMPによるスイッチ監視は、MRTGの時代から「大量のスイッチや各々のI/F向けの設定をいかに手軽に生成するか」というところが要になっている印象ですが、（詳細はセッション内で語られなかったものの）構成管理DBに丸投げできるPrometheusはある意味向いているのだろうなと感じました。一方でスイッチ内でnode_exporterを動かしたり、blackbox_exporterによる外形監視を活用されていたりと、個人的に非常に興味深い内容が語られました。

LT大会x5

Grafana Dashboards-as-Code - TakuhiroYoshida

Rancher's Mluti-Tenant Prometheus Support - cyberblack28

KubernetesベースなFaaSにおけるPrometheus の使い方 - nwiizo

and_Severless_Platform_Prometheus - Speaker Deck

  • サーバレスとは
  • OpenFaaSの概要
  • Knativeとは
  • 入門Prometheus Chapter 9
    • k8sでPrometheusを使う話
  • OpenFaaSにおけるPrometheusの使い方

  • API Gateway経由
    • 各関数コンテナのメトリックを取得・可視化

どうして我々はKubernetes上のPrometheusを破壊したのか - whywaita

Prometheus monitoring from outside of Kubernetes 〜どうして我々はKubernetes上のPrometheusを破壊したのか〜 #prometheustokyo

  • 緊急アンケート : どこにPrometheusをおいているか？
    • k8s上のPod
    • VM上
    • タンスの上（実話）

  • 以前はk8s上で運用していた
    • 永続ストレージはCephを使用
  • Prometheusをk8s上に置くと嬉しい
  • が…
  • 免責事項 開発環境での話
  • メンテナンス
    • -> 5つあるコンテナのうち2つ
  • -> メンテ中に一つで障害発生
    • -> 生きているのは2つ（正常時の半数以下）
    • -> etcdクラスタ崩壊
    • -> k8sクラスタ崩壊
    • -> Cephが死ぬ
    • -> PVC提供も
    • -> Prometheusも
    • -> アラート発報できず
  • 復旧は淡々と…
  • Prometheusをk8sの外に置く
    • 嬉しかったところを自前で

（とても勢いのあるLTでした。2:40:00頃からですので動画も是非ご覧くださいｗ）

Prometheusのrelabeling - yteraoka

  • Prometheus relabel __address__ - Speaker Deck

  • 2017年頭からPrometheus

    • Zabbix、Cactiから乗り換え
  • 多数のexporterを使っていた
  • 2018年7月より前の話
    • 入門Prometheusの原著がリリースされる前の話
    • (旧)Docker Swamでregistratorを使ってConsulにサービス登録していた
    • Swam外からアクセスしたい
    • consul_sd_configを使えば良いと思っていた
    • -> Consulから取得されたtargetには、クラスタ内からしか接続できないIPアドレスがセットされていた
  • -> Githubで問い合わせて解決
    • You can use relabeling
    • 当時の自分は、翌日には「ありがとう」と返していた（ので、これで解決した模様）
  • 入門Prometheus読もう

所感

Webサービス提供、機械学習、データセンタ運用、などなど、様々な環境で Prometheus がどう活用されているか、非常に興味深いセッションの数々でした。僕自身は過去データセンタやWebサービスの監視運用で Cacti や Nagios、Zabbix などを（その前身も含めて）利用し、ちょうど転換先としてPrometheusを検討しようとしていたころに転職、いまは監視SaaSを主に扱う身です。そのためPrometheusには興味はあったものの長く触れることのないソリューションでした。今回本 meetup に参加し本当に良かったと思います。

なおそういった外野からみた素人の感想ですが、各セッションをおしなべて語られていたものは下記かなと感じました。Prometheusそのものを機能拡張するというよりそれ自身はシンプルにしておいて、拡張が必要な部分はサードパーティ製や開発ができるようにしておく、というPrometheusの特徴が現れているのかな、と思います。

  • ダッシュボードがGrafanaなのは常識（言うまでもない）
  • Prometheus の設定を Jsonnet で管理・運用（GitOps）
  • Prometheus の冗長化やストレージ永続化は Thanos を使う
  • 入門Prometheusは良い本、読もう

強力なサービスディスカバリと軽量・シンプルさ、exporterの仕組みで外形監視まで対応可能など、他の監視ソリューションにはない特色・補完的な使い方ができそうなPrometheus。今回のミートアップで個人的なPrometheusへの興味が再燃してきたので、隙を見て触ってみたいと思います。

なお当日は最後に「入門 Prometheus」 プレゼント（5冊）の抽選が行われたのですが、僕は惜しくも選から漏れてしまったので素直に購入しました。これから読みます！

O'Reilly Japan - 入門 Prometheus

*

関連記事

【レポート】チームビルディング合宿 ~琥珀の回想録(メモワール)~

稲葉奏人

2024.04.22

Security-JAWS 第32回レポート #secjaws #secjaws32 #jawsug #サイバーセキュリティは全員参加

臼田佳祐

2024.02.14

Security-JAWS 第31回レポート #secjaws #secjaws31 #jawsug

臼田佳祐

2023.11.15

【iOSDC Japan 2023 レポート】「SwiftUIに適した新アーキテクチャの導入に挑む」を聞いてきた。

リルオッサ

2023.09.05