Prometheus on AWS

Prometheus on AWS

自己紹介• 反田 光洋• グリー株式会社 インフラストラクチャ部• AWS で Prometheus を運用 ( 約 1 年 )• Grafana committer• @mtanda

Prometheus の特徴• multi-dimensional data model• flexible query language• pull model over HTTP• service discovery• Prometheus values reliability

AWS モニタリングの課題• インスタンスのライフサイクルが短い• Auto Scaling でインスタンスが増減する• AZ の違いなどにより負荷傾向が異なる

AWS に適している点• multi-dimensional data model & flexible

query language– Role や AZ ごとにメトリクスを集計して比較– 負荷傾向が異なるインスタンスを検出

• pull model over HTTP & service discovery– Role などを条件にモニタリング対象を設定– モニタリング対象増加への対応が容易

multi-dimensional data model

• インスタンスのメタデータを label に記録key valueinstance_id i-1234abcdinstance_type ec2, rds, elasticache, elb, …instance_model t2.large, m4.large, c4.large,

r3.large, …region ap-northeast-1, us-east-1, …availability_zone ap-northeast-1a, ap-northeast-1c,

…role (instance tag) web, db, …environment (instance tag) production, staging, …

avg(cpu) by (availability_zone)

cpu{role="web"}

avg(cpu) by (role)

Service Discovery

• モニタリング対象を自動検知する機能• 環境にあわせて使用する SD を選択する– ec2_sd, consul_sd, kubernetes_sd,

file_sd

• (Pull だからこそ必要な機能 )

ec2_sd• ec2:DescribeInstances API でインスタンスを検知• AZ やタグなどから柔軟にモニタリング対象を設定• web Role のみをモニタリング対象とする例- job_name: 'job_name' ec2_sd_configs: - region: ap-northeast-1 port: 9100 relabel_configs: - source_labels: [__meta_ec2_tag_Role] regex: web.* action: keep

Prometheus の設定方法

Prometheus(for web)

Prometheus(for db)

Role=web Role=db

pack

upload

deploy

edit

このロゴは Jenkins project (https://jenkins.io/) に帰属します。

CloudWatch 対応• CloudWatch のメトリクスも Prometheus に取り込んでいる• cloudwatch_exporter は Java に依存しているので使わない• aws-sdk-go を使って exporter を作成• メトリクスの timestamp 記録が問題

– CloudWatch のメトリクス送出は数分単位で遅れる– timestamp を記録しようとすると、古いメトリクスとして扱われ、

Prometheus に取り込めないことがある– 現状は妥協して、一部メトリクスは timestamp を記録していない

運用時の構成• インスタンスは t2.micro – t2.medium• EBS は gp2 で 50-100GB• 50-100 台程度の規模なら、 t2.medium で十分• t2.small 以上が推奨

– t2.micro ではメモリ不足– storage.local.memory-chunks を調整する必要あり

• 突発的な負荷はバーストで対応– T2 インスタンスのバースト– EBS(gp2) のバースト

ディスク書き込み負荷

ディスク使用量• モニタリング対象 1 台あたりで計算• 1 台あたり 150 – 300 メトリクス• メトリクスの scrape 間隔は 15 秒• 1 ヶ月のディスク消費は約 200MB

メトリクスの長期保存• rrdtool のようにデータをサマライズする機能はない• メトリクスの保持期間に応じてデータサイズは増加• デフォルトでは 15 日経過時点で削除される• メトリクスの長期保存は想定されていない• 長期保存する場合

– Remote Storage (Graphite など ) を利用する– 長期保存用の Prometheus に、サマライズして保存する

1 年間運用して• 運用について

– 負荷は安定している– 運用の手間はほとんどない

• バージョンアップ時の対応– 新しい書式に対応する必要が何度かあった– 1.0 までは非互換な変更がある

• 新規要件への対応– 必要に応じて exporter を作成– 強力なクエリのおかげで、 exporter 自体はシンプルに作れた

参考 URL

• http://www.robustperception.io/automatically-monitoring-ec2-instances/

• http://www.robustperception.io/how-to-have-labels-for-machine-roles/

• http://www.robustperception.io/life-of-a-label/• http://www.slideshare.net/FabianReinartz/prometheus-stora

ge-57557499