Skip to content

Instantly share code, notes, and snippets.

@rrreeeyyy
Last active September 12, 2019 10:01
Show Gist options
  • Star 20 You must be signed in to star a gist
  • Fork 1 You must be signed in to fork a gist
  • Save rrreeeyyy/39aa9bea53f5235d02b26fb0d8a86077 to your computer and use it in GitHub Desktop.
Save rrreeeyyy/39aa9bea53f5235d02b26fb0d8a86077 to your computer and use it in GitHub Desktop.
Prometheus 2018 の近況と基礎

https://prometheus.io/ 2.3.2 (2018-07-12)

exporter 周りは大分充実してきたし、retention period に応じたメモリがある程度あればI/Oがひどいことになることはないので運用はまあまあ簡単だと思う。 時系列データも圧縮されるので、300000 メトリクス・解像度 15 秒・14 日間保存で 50GB ぐらいで済んでる。 PromQL を投げたときに CPU を結構食うので、ルールをたくさん書きたいとかめっちゃ PromQL を眺めたいって時は CPU を積んであげるのがオススメ。

long-term storage 周りはそんなにシュッとはしてないので、基本的には 14d ぐらいの短い周期のデータを解像度高く見たいとか、 そんな真剣に長期のメトリクスを眺めなくていいような時とかに使うのが良いと思う。 (まあ本気を出せば long-term storage もできなくないが、運用コストはまあまあ高まると思う。)


基本的にはバイナリ置いて使うだけ。設定が必要そうなオプションは ↓ の感じ。

/usr/bin/prometheus \
  --config.file=<%= node[:prometheus][:config_file] %> \
  --storage.tsdb.path=<%= node[:prometheus][:storage_local_path] %> \
  --storage.tsdb.retention=<%= node[:prometheus][:storage_tsdb_retention] %> \
  --web.console.libraries=<%= node[:prometheus][:console_libraries] %> \
  --web.console.templates=<%= node[:prometheus][:console_templates] %>

LimitNOFILE とか引っかかりがちなので設定しておくと良さそう。 冗長化させたいときは 2 台同時に動かして前段の LB とかで切り替えるようにする。 (時系列データは最大 scrape_interval * 2 だけズレるけど許容する他ない)

設定はまあここに書いてあるとおりやる。 https://prometheus.io/docs/prometheus/latest/configuration/configuration/

自分の好きな方法で service discovery したい時は、file_sd_config を使う。 ファイルの変更が検知されて勝手に reload されるので、適当なフォーマットの JSON とか YAML を定期的に吐くデーモンを動かしておくだけで reload 無しで sd できる。 適当な HTTP Endpoint を定期的にスクレイプして file に吐いてくれるデーモンはこれ https://github.com/rrreeeyyy/prometheus-http-sd

exporter はサードパーティ製なら https://prometheus.io/docs/instrumenting/exporters/ この辺にまとまってる。 https://github.com/prometheus/prometheus/wiki/Default-port-allocations 使用ポート管理台帳もある(つらい) 手前味噌だけど exporter_proxy とかを間に挟むとまあちょっとマシになると思う(ホストのポートはたくさん使っちゃうけど対外的には一つだけ開いとけばいい)。 exporter_proxy: https://github.com/rrreeeyyy/exporter_proxy

Linux のメトリクスを取りたい時は node_exporter を使う。 普通に起動すると要らなそうなメトリクスも結構たくさん取られたりする。EC2 みたいなクラウド上のインスタンスとかで使うなら次のオプションが個人的にはいいと思う。

-collectors.enabled conntrack,diskstats,entropy,filefd,filesystem,loadavg,mdadm,meminfo,netdev,netstat,sockstat,stat,textfile,time,uname,vmstat 

あとは便利として text_collector というのがある。 指定したディレクトリに .prom で終わる Prometheus のメトリクス形式のファイルがあれば勝手に node_exporter を scrape されたときにそれも含まれるようになる。 起動時に textfile.directory の引数を有効にしてあげる。

-collector.textfile.directory /var/lib/node_exporter/textfile_collector

https://github.com/prometheus/node_exporter/tree/master/text_collector_examples こんな感じのスクリプトを書いて適当にやればよい。 雑なメトリクスなら exporter 自作するまでもなく text_collector で十分。

あとはミドルウェア毎に必要なやつがあればその exporter を使ったり作ったりする。

外形監視的なやつは Prometheus サーバとかの外形監視用のサーバに blackbox_exporter ってやつを入れるといい感じになる。


アラート出すためには alertmanager を使う。 Prometheus のルールで指定したアラートが鳴ったときにいい感じにまとめたりしてくれて Slack とか Pagerduty に飛ばせる、というのが alertmanager の役目。

Alertmanager の config とか Prometheus のルールを Jsonnet で管理するいい感じの example はこれ https://github.com/rrreeeyyy/docker-prometheus-mixin/tree/master/example

これもバイナリ置いて使うだけ。

起動時に -mesh.peer のオプションのあとに別の alertmanager のホストを書くとホスト間でアラート情報をいい感じに共有してくれて冗長化される。

alert の定義は alerting rule ってやつを prometheus に食わせて定義する。 https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/

PromQL は頑張って勉強する。

https://www.digitalocean.com/community/tutorials/how-to-query-prometheus-on-ubuntu-14-04-part-1 このシリーズ(part1,2)が勉強になる。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment