はじめに 以前のblog postで予告したように、OSSのモニタリングツールとして最近注目を集めているPrometheusの初のカンファレンスPromCon 2016に参加して発表してきました。 発表資料や動画はこちらから見ることができるので各セッションの詳細はそちらをご覧ください。 このblog postでは当日の様子をお伝えしたいと思います。本家でもレポートが出ているので興味ある方はそちらもチェックしてみると良いと思います。 https://prometheus.io/blog/2016/09/04/promcon-2016-its-a-wrap/ 当日のイベントの様子 参加者の雰囲気 PromCon 2016は8/25(木), 26(金)の2日間にわたってドイツのベルリンで開催されたイベントです。会場はGoogle Berlinで、LINEはシルバースポンサーとして協賛しました。 カンファレンスの規模は参加者約80名でシングルトラックで進行しました。東京でのPrometheusイベントでさえ約100名のエンジニアが参加したぐらいなので、本家のカンファレンスで80名というキャパシティは少ないのではと最初は思っていたのですが、実際その通りだったようでチケットは一瞬にして売り切れたそうです。参加者はクラウドサービスを活用したインフラエンジニア、SREといったポジションの方が多かったようです。 会話した限りではやはりヨーロッパからの参加者が多く、ドイツ以外ではイギリス、アイルランド、スペイン、フランス、スウェーデンといった国から、アジアでは日本を除くとタイ、インドネシアから参加している方がいました。主催者の方も遠いアジアまでPrometheusが広まっていることに驚きと喜びを感じているようでした。私は4月末にCFP(Call for Papers)を出し、それがacceptされたのでspeakerとして参加できました。 私の発表 私の発表資料は以下を参考にしてください。 発表時の写真と名札はこちらです。 私はFluentdでログ収集してHadoopに蓄積するということをやっているので、そのシステムのモニタリングにPrometheus, Grafanaを使っている話と、OSSとして公開したpromgenを紹介しました。 promgenはRubyで実装されたWebアプリケーションで下記２つの機能を持っています。 Prometheusの設定ファイルの自動生成およびPrometheusのreload アラート通知先の制御 私の発表に限らず参加者はアットホームというかハートウォーミングに発表を聞いてくれ、とてもやりやすい雰囲気でした。発表後に「Nice Talk!」と言ってくれる人もいて、とても嬉しかったです。 印象深かったやりとりと私の経験 私以外のセッションでは、Prometheus開発者によるストレージやアラート周りの発表やPrometheus誕生秘話、kubernatesのモニタリングなどPrometheusのユースケース紹介、Grafanaの話、Prometheusを活用してモニタリングサービスを展開する話、などバラエティに富んだセッションが沢山ありました。 セッションのなかで個人的に気になったのは、地味だけど重要なアラート周りの話です。機械学習の異常検知によるアラートの話題も出て個人的には面白いと思いますが、運用が少し難しそうです。 PromQLを使った例は出てきましたが、クエリが少し複雑で僕の環境で取り入れるのは先になりそうです。 アラートのunit testってどうするの？という話題も出て、現状だとドッグフーディングしかないかもしれないと聞いてやはりまだそうなのかと思った次第です。アラートがちゃんと動いているか確認するのは実践でやるしかない部分もありますが、障害がそんなに頻繁に起きるわけでもないので、アラートが来ないバグというのは気付きづらい傾向にあります。実際に私自身も最近それを経験しました。 PrometheusのAlertmanagerのご紹介 Prometheusの世界ではアラートはAlertmanagerが担当します。アラートが発生するとAlertmanagerがmailなりhipchatなりslackなりにそれを通知しますが、私の環境ではまずpromgenがアラートを受け取って処理をするという流れです。Prometheus → Alertmanager → promgen → hipcaht/mail という経路です。こうすることによってAlertmanagerのreloadをしなくてもアラート通知先を柔軟に変更することができます。promgenは当初CSRFの問題があったためRack::Protectionを用いてリファラーが無いリクエストははじくように変更を入れたところ、Alertmanagerからのアラート通知を拒否してしまい結果的にアラートが来ないという状況になってしまいました。 そのような経緯があり、現在では下記のようにアラート通知に失敗した場合は障害になるようにアラートルールを追加しました。 ALERT AlertDeliveryError IF rate(alertmanager_notifications_failed_total[5m]) > 0 FOR 5m LABELS {severity="critical"} ANNOTATIONS {summary="notification through promgen failed."} このアラートルールに引っかかってもpromgenに問題があって通知できないのでは困るので、Alertmanagerに関するものはpromgen以外の経路で下記のようにmail通知するようにしています。 global: smtp_smarthost: '... smtp_from: '... route: receiver: 'promgen-webhook' routes: - receiver: 'promgen-mail' match: job: alertmanager receivers: - name: "promgen-webhook" webhook_configs: - url: 'http://promgen:password@localhost:9092/alert' - name: "promgen-mail" email_configs: - to: '...' require_tls: false AlertmanagerのHAのLightning Talks アラート周りの他の発表ではAlertmanagerのHA(High Availability)のLightning Talkがありました。Lightning Talkは参加者が会場で下記のようにホワイトボードに書いてsign upする方式でした。 Prometheusはpull型のアーキテクチャなのでHAは簡単に組めます。同じ設定ファイルで2つのPrometheusを動かすだけです。しかしAlertmanagerは現状SPOF(Single Point of Failure)なので、HAは必要だと思います。私のようなHadoopエンジニアだとHAと聞くとZooKeeperが必要なのかな？と思ってしまいますが、AlertmanagerのHAはZooKeeperのような外部のミドルウェアを必要としません。これならセットアップも楽そうですね。 内部的にはCassandraのようにGossipプロトコルでノード間通信を行いCAP定理のAP型システムのようです。またAlertmanagerが複数あっても同じアラートを複数受け取ることになっては意味がないのでそこについての説明もありました。 Alertmanager HAの実装は終わっているもののテストが足りないようでまだリリースされていません。リリースされたら私もチェックしようと思っています。 会場で提供された食べ物、飲み物、Tシャツ、バッグ イベント当日は食べ物も非常に充実していました。朝食と昼飯としてはヨーロッパとアジアを区分せず様々な料理がでました。ドリンクもコーヒーを含め様々な種類が提供されていて、デザートにPrometheusケーキもありました。カップケーキの上にPrometheusのマークが乗っているのが印象的です。 さらにお土産にPrometheusバッグとTシャツももらいました。 さらにイベント初日の夜には懇親会も開催され活発な議論が展開されました。 (…)
↧