1. Prometheus on AWS

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

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

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

5. AWSに適している点
• multi-dimensional data model & flexible query
language
– RoleやAZごとにメトリクスを集計して比較
– 負荷傾向が異なるインスタンスを検出
• pull model over HTTP & service discovery
– Roleなどを条件にモニタリング対象を設定
– モニタリング対象増加への対応が容易

6. multi-dimensional data model
• インスタンスのメタデータをlabelに記録
key value
instance_id i-1234abcd
instance_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, …

7. avg(cpu) by (availability_zone)

8. cpu{role="web"}

9. avg(cpu) by (role)

10. Service Discovery
• モニタリング対象を自動検知する機能
• 環境にあわせて使用するSDを選択する
– ec2_sd, consul_sd, kubernetes_sd, file_sd
• (Pullだからこそ必要な機能)

11. ec2_sd
• ec2:DescribeInstancesAPIでインスタンスを検知
• 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

12. Prometheusの設定方法
Prometheus
(for web)
Prometheus
(for db)
Role=web Role=db
pack
upload
deploy
edit
このロゴはJenkins project (https://jenkins.io/)に帰属します。

13. CloudWatch対応
• CloudWatchのメトリクスもPrometheusに取り込んでいる
• cloudwatch_exporterはJavaに依存しているので使わない
• aws-sdk-goを使ってexporterを作成
• メトリクスのtimestamp記録が問題
– CloudWatchのメトリクス送出は数分単位で遅れる
– timestampを記録しようとすると、古いメトリクスとして扱われ、
Prometheusに取り込めないことがある
– 現状は妥協して、一部メトリクスはtimestampを記録していない

14. 運用時の構成
• インスタンスはt2.micro – t2.medium
• EBSはgp2で50-100GB
• 50-100台程度の規模なら、t2.mediumで十分
• t2.small以上が推奨
– t2.microではメモリ不足
– storage.local.memory-chunksを調整する必要あり
• 突発的な負荷はバーストで対応
– T2インスタンスのバースト
– EBS(gp2)のバースト

15. ディスク書き込み負荷

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

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

18. 1年間運用して
• 運用について
– 負荷は安定している
– 運用の手間はほとんどない
• バージョンアップ時の対応
– 新しい書式に対応する必要が何度かあった
– 1.0までは非互換な変更がある
• 新規要件への対応
– 必要に応じてexporterを作成
– 強力なクエリのおかげで、exporter自体はシンプルに作れた

19. 参考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-storage-57557499