ブログトップ 記事一覧 ログイン 無料ブログ開設

wyukawa’s blog

2016-08-23

Prometheus London meetupでLTしてきました。

Prometheus Core Developer Björn Rabenstein Open Q&A - Prometheus London User Group (London, England)- Meetup

最初にビザとビールで腹と喉を潤した後に僕がトップバッターでLTしました。

僕のLTスライドはこちら

英語につっかえながらもなんとか5分間のLTをやりとげました。

初の英語プレゼンです。

ありがたいことに質問も2つありました。

一つはnginxモニタリングの話で、例えばnginx-lua-prometheusなどを使ってレスポンスタイムを取得することは考えなかったのか?というもの。

僕の答えとしては、それも少し考えたがnginx-lua-prometheusを使うと独立性を保てない、例えばnginx-lua-prometheusにバグがあったらnginxにもろに影響してしまうので、nginx_exporterのように疎結合というか独立性を保てる方法の方がいいと思っている。ただレスポンスタイムは欲しいのでアクセスログから集計する方法を考えている。

二つ目はGrafanaのダッシュボードを公開して共有する計画はないのか?

無い。というのもGrafana Templatingに社内依存のものが少し含まれているため。


僕のLT後にもう一人LTがあってその後のメインがPrometheus開発者の一人であるBjörnさんを招いていろいろ質問するというもの。

どうやらBjörnさんはGolang UK Conferenceで発表していた模様。

Golang UK Conference

活発な議論がありましたが、残念ながら僕の英語力ではあまり理解できず。。。

ただせっかくなので僕からも一つ質問しました。1台のPrometheusサーバーで何台までさばけるの?と。まあサーバースペックとかPrometheusの設定とかexporterの数とかいろいろ条件によるだろうけど3000台くらいまではいけるんじゃねって言ってました。

BjörnさんはPromCon 2016ではTime Series Databaseの話をするらしく、この日はスライドをチラ見できました。

PrometheusのストレージはFacebookのGorillaにインスパイアされて値の差分の差分を取ってええ感じに保存するということをやっていてその分CPUは使うけど圧縮率は高いみたいな感じなんですが、その辺の話をPromCon 2016でするらしいです。

この辺の話ですね。

no title

Prometheus Storage

その後パブに移動してビール飲みながら話してました。といってもあんまり英語理解できてないのでもっと頑張らないとなあと思っております。

ちなみにこの日の発表や質疑応答の様子は録画しており、そのうち公開されると思います。

2016-07-29

Alertmanagerについて書いてみる

Prometehus, Grafanaでモニタリングできるのはもうわかったので監視をどうするかというとAlertmanagerを使うことになります。

Prometehus本体に比べればAlertmanagerはまだ成熟してないと思うけど、使う価値は十分にあると個人的にあると思ってます。

その理由は2つあって、Prometehusで収集したメトリクスに対してアラートを設定できることと、アラート通知をまとめることができるということ。


1番目はまあわかりますよね。GangliaでモニタリングしてNagiosで監視とかだとツールが分かれているのでやりづらい。Gangliaでモニタリング結果に対してNagiosでアラート通知できないからね。


2番目が今日最も書きたかったこと。


監視はナイーブにやると、いったんアラートがなったときに対処しない限り延々とアラートがなり続けることになります。

例えばあるプロセスが落ちてたら通知することを考えてみましょう。


そうですね。例えばpresto workerが10台起動しているものとして、10台じゃなくなったらアラート通知するとします。

こんな感じのスクリプトをcronで5分間隔で実行するとします。send_notify関数で監視ツールにpostしていると思ってください。

presto_nodes=`java -jar ...`

if [ ${presto_nodes} -ne 10 ]; then
  message="some presto node is down! now presto has ${presto_nodes} nodes..."
  send_notify(message)
fi

夜中3時に9台になって誰も気づかなかったら延々と通知が来ますね。

他のアラートが来ても埋もれそうですよね。

それじゃあ辛いのでスクリプト側をこんな感じにしたとします。

if [ -e /tmp/presto.down ]; then
  exit
fi

presto_nodes=`java -jar ...`

if [ ${presto_nodes} -ne 10 ]; then
  message="some presto node is down! now presto has ${presto_nodes} nodes..."
  send_notify(message)
  echo ${message} > /tmp/presto.down
fi

これならアラートは1回しか来ない!素晴らしい!

でも復旧作業が終わったら/tmp/presto.down消す必要ありますけど、まあ忘れますよね。

それにそもそもこの手の処理を監視スクリプト側に毎回入れないといけないのは辛い。

ここではcronでチェックする例を入れましたけど、標準で用意されてそうなHDD使用率のチェックとかでもアラート通知洪水は起きがちですよね。


ツールによってはerror levelで通知間隔を制御するものもあります。

例えば、HDD使用率が90%を超えてたらlevelがerrorということで10分間隔で通知する、

HDD使用率が95%を超えてたらlevelがfatalということで1分間隔で通知する。

エラーが本当に深刻なものなら通知が来続けて欲しいという人も中にはいますが、僕の経験上、精神を疲弊させると思います。

それに他のアラートが来ても埋もれそうになる問題は避けられない。メール通知ならメーラーのフィルタリングで頑張るという手もあるかもしれませんが。


前置きが長くなりましたが、そこでAlertmanagerですよ。

Alertmanagerはこんな感じでルールを書きます。IFのところがアラートの条件ですね。この例だとupが0の状態が5分超えたらアラート。

FORの部分のおかげで突発的なものはフィルタリングできます。LABELSとANNOTATIONSは補足情報ですね。

# Alert for any instance that is unreachable for >5 minutes.
ALERT InstanceDown
  IF up == 0
  FOR 5m
  LABELS { severity = "page" }
  ANNOTATIONS {
    summary = "Instance {{ $labels.instance }} down",
    description = "{{ $labels.instance }} of job {{ $labels.job }} has been down for more than 5 minutes.",
  }

Prometheusの世界ではアラートもメトリクスです。アラートがなると下記メトリクスが1になります。

ALERTS{alertname="InstanceDown", alertstate="firing", ...}

alertnameでグルーピングされるので、同じアラートが延々きつづけることはありません。

最初のアラートが来て何も対処しない状態だと4時間後に再度アラートが来ます。素晴らしい。

この設定はrepeat_intervalです。


モニタリング対象ホストにexporterをsetupしてメトリクスをPrometheusサーバーからpullしてそれに対してアラートを設定するのが一般的です。

ただ上記の例みたいにcronでチェックしたい場合もあるでしょう。

その場合はAlertmanagerに直接POSTすることもできます。

https://prometheus.io/docs/alerting/clients/

presto workerの例だとこんな感じ。

presto_nodes=`...`

if [ ${presto_nodes} -eq 10 ]; then
  exit 0
fi

curl --data-binary @- http://alertmanager.../api/v1/alerts << EOS
[
  {
    "labels": {
      "alertname": "presto_down",
      "severity": "major"
    },
    "annotations": {
      "summary": "some presto node is down! now presto has ${presto_nodes} nodes.."
    }
  }
]
EOS

これでアラート通知洪水に悩まされることも無くなります。

復旧したかどうかをどう判断するかというと、resolve_timeout(default: 5m)の時間が経ってもアラートがPOSTされてこなかったら解決したとAlertmanagerが判断してます。

Alertmanagerの通知方法として僕はwebhookを使っているんですが、デフォルト設定だとアラート発火と解決の両方のタイミングで通知があります。

send_resolvedをfalseにすればおそらくアラート解決の通知は来ないと思います。

そんなわけで、Alertmanagerには通知を工夫している部分が感じられるので将来有望なソフトだと思ってます。素晴らしい。

2016-07-20

Presto Meetupで発表してきました

Presto Meetup - dots. [ドッツ]で発表してきました。

主催のrepeatedlyさん、および発表者、スタッフ、参加者のみなさまお疲れ様でした。ありがとうございました。

参加者が30人ほどと小規模で、かつ発表後すぐには質問もなかったので、聞いていた方がどういう感じだったのかつかみづらい感じだったのですがいかがでしたでしょうか。

前回から1年半ぶりですね。

Presto Meetupで発表してきました - wyukawa’s blog

togetterはこちら

Presto Meetup #2 - Togetterまとめ

発表者のスライドはこちらです。

この1年半におけるPrestoの変化を追った発表です。

node-scheduler.network-topologyとかresource groupsはうちではいじってないですね。

僕の発表です。前回と同じ事例紹介でそれ以外にはprestoのバージョンアップをする際に踏んだバグの話をしました。

redshiftとmysqlを対象にprestoを使っている話でした。

僕はhadoopの延長にprestoが来るもんだと思ってたのでhadoopを使わないでprestoを使う話は新鮮でした。teradataがJDBC周りを頑張ってくれるみたいなのでそこに期待ですね。

connector自作の話。あんまりはまらずに実装できたって言ってた。すげー。


その後、ツムビアホフにて懇親会やりました。各社それぞれの苦労話を聞けて面白かったです。毎回repeatedlyさんにAzkabanはオワコンってdisられますが、特に困ってないのでめげずに使っております。

2016-06-15

Prometheus Casual Talks #1を開催しました

Prometheus Casual Talks #1 - connpass

発表者、参加者の皆様おつかれさまでした。ありがとうございました。

Prometheusは日本ではあんまり使われていないと思うのでそんなに人集まらないと思ってたんですが、connpassに公開したその日にすぐ定員はうまるぐらい人気でした。

ただ97人の申し込みに対して実際に来たのは66人で、入退室の面倒くささを考えると今後はdotsを使うのが正しい気がしてきました。

参加者がどういうモニタリング、監視ソフトを使っているのか興味があったので、

事前に任意で「現在業務で使っているモニタリング、監視ソフトは何ですか?」という複数回答可のアンケートを実施したのですがその結果が下記です。

Zabbix66
Nagios48
Cloudwatch34
Kibana33
Elasticsearch28
Cacti26
NewRelic26
Mackerel22
Munin18
Grafana17
Ganglia14
Pagerduty14
Sensu14
その他14
Growthforecast13
内製のなにか13
Datadog10
InfluxDB10
Cloudforecast7
Prometehus5
Graphite4
Kurado2

ZabbixとNagiosという昔ながらのものがワンツーフィニッシュでした。

MackerelやDatadogといった新興のクラウドモニタリングサービスがもっと浸透しているかと思いきや意外とそうでも無かったです。

そしてPrometehusは5人でした。まあそんなもんだよね。


僕の発表資料はこちら

サンプリングしたアクセスログデータに対してHTTPステータスごとに集計する場合4xx, 5xxのエラーが実際はあるのにサンプリングの結果0になる可能性があるのでfluentdやnorikraを使うよりもFlinkやStormのような分散システム前提のものを使う必要があるのではという僕の主張に対していくつかツッコミがありました。

や、ありがたいことです。だいたい以下のようなコメントだったと思います。

  • 200を除けばいいのでは
  • HTTPサーバー側にagent的なものを置いてそこで集計すればいいのでは
  • statsdを使えば良いのでは

1番目は言われてみればそうかもだけど、そうすると割合が求めらるのが難しくなるのとfluentdの設定を複雑にしたくないという思いがあります。

2番目は例えばGitHub - knyar/nginx-lua-prometheus: Prometheus metric library for Nginx written in Luaを使うことなのかなと理解しました。それはアリだと思いますが、現状のアクセスログをtailして集計するやり方に比べるとHTTPサーバー側に仕込みが必要なので若干独立性が落ちるのかなと思いました。

で、statsdはよく知らないんですがこれもHTTPサーバー側のマシンにagent仕込む必要があるかなと。

今のところうちにはHadoopクラスタがあるのでそこをうまく活用できないかなと思ってます。そうすれば既存のモニタリング対象サーバー側の仕組みを変えずに済むので。

他の発表者の資料はこちらです。




https://gist.github.com/moznion/20ad8797af22df6b1365c2fd6f5a8a74


togetterはこちら

Prometheus Casual Talks #1 まとめ - Togetterまとめ

他の方のブログレポートはこちら

#PrometheusCasual #1 に行ってきた - weblog of key_amb



各プレゼンそれぞれ多様性があってなかなか面白かったです。

簡単にまとめてしまうとPrometheusのクエリは強力で、exporterは簡単に書けるし、exporter側で無理に頑張らなくてrawに近いデータを渡せばあとでクエリで好きなようにできるというのは大きな強みかなと。

たとえばなんか障害があってTIME_WAITとかSlabとかそういうちょっとニッチなメトリクスをモニタリングする必要ができた場合普通はその時点からモニタリングスクリプト作成するしかないけど、

Prometheusの場合はnode_exporterを最初にセットアップしておけば後で大抵のマシン固有のメトリクスは取れるのでなんとかなります。

弱みはあまり長期間メトリクスを保持するのは向いていないのではということ。RRDはその逆ですね。resolutionとretentionのトレードオフになると思います。

以上です。Prometheusに関する情報がもっと出てくると嬉しいので何かありましたら是非シェアお願いします。

2016-06-12

南魚沼グルメマラソン

一昨年、去年に引き続いて3年連続で行ってきました。

南魚沼グルメマラソンで走ってきた - wyukawa’s blog

南魚沼グルメマラソンにいってきた - wyukawa’s blog

結果はネットタイムが2時間1分6秒でした。去年に比べるとだいぶ遅い。。。練習不足だな。

3年連続でとても天気が良くて暑かったのでビールがうまかったです。ていうかここで飲んだビールが人生で一番うまかったです。3年連続でそう思ってます。

f:id:wyukawa:20160612171028j:image