Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Prometheus on AWS
自己紹介
• 反田 光洋
• グリー株式会社 インフラストラクチャ部
• AWSでPrometheusを運用 (約1年)
• Grafana committer
• @mtanda
Prometheusの特徴
• multi-dimensional data model
• flexible query language
• pull model over HTTP
• service discovery
• Promet...
AWSモニタリングの課題
• インスタンスのライフサイクルが短い
• Auto Scalingでインスタンスが増減する
• AZの違いなどにより負荷傾向が異なる
AWSに適している点
• multi-dimensional data model & flexible query
language
– RoleやAZごとにメトリクスを集計して比較
– 負荷傾向が異なるインスタンスを検出
• pull mo...
multi-dimensional data model
• インスタンスのメタデータをlabelに記録
key value
instance_id i-1234abcd
instance_type ec2, rds, elasticache,...
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:DescribeInstancesAPIでインスタンスを検知
• AZやタグなどから柔軟にモニタリング対象を設定
• web Roleのみをモニタリング対象とする例
- job_name: 'job_name'
ec2...
Prometheusの設定方法
Prometheus
(for web)
Prometheus
(for db)
Role=web Role=db
pack
upload
deploy
edit
このロゴはJenkins project (ht...
CloudWatch対応
• CloudWatchのメトリクスもPrometheusに取り込んでいる
• cloudwatch_exporterはJavaに依存しているので使わない
• aws-sdk-goを使ってexporterを作成
• メ...
運用時の構成
• インスタンスはt2.micro – t2.medium
• EBSはgp2で50-100GB
• 50-100台程度の規模なら、t2.mediumで十分
• t2.small以上が推奨
– t2.microではメモリ不足
– ...
ディスク書き込み負荷
ディスク使用量
• モニタリング対象1台あたりで計算
• 1台あたり150 – 300メトリクス
• メトリクスのscrape間隔は15秒
• 1ヶ月のディスク消費は約200MB
メトリクスの長期保存
• rrdtoolのようにデータをサマライズする機能はない
• メトリクスの保持期間に応じてデータサイズは増加
• デフォルトでは15日経過時点で削除される
• メトリクスの長期保存は想定されていない
• 長期保存する場合...
1年間運用して
• 運用について
– 負荷は安定している
– 運用の手間はほとんどない
• バージョンアップ時の対応
– 新しい書式に対応する必要が何度かあった
– 1.0までは非互換な変更がある
• 新規要件への対応
– 必要に応じてexpo...
参考URL
• http://www.robustperception.io/automatically-monitoring-ec2-instances/
• http://www.robustperception.io/how-to-hav...
Upcoming SlideShare
Loading in …5
×

Prometheus on AWS

10,941 views

Published on

Prometheus on AWS

Published in: Technology
  • Be the first to comment

Prometheus on AWS

  1. 1. Prometheus on AWS
  2. 2. 自己紹介 • 反田 光洋 • グリー株式会社 インフラストラクチャ部 • AWSでPrometheusを運用 (約1年) • Grafana committer • @mtanda
  3. 3. Prometheusの特徴 • multi-dimensional data model • flexible query language • pull model over HTTP • service discovery • Prometheus values reliability
  4. 4. AWSモニタリングの課題 • インスタンスのライフサイクルが短い • Auto Scalingでインスタンスが増減する • AZの違いなどにより負荷傾向が異なる
  5. 5. AWSに適している点 • multi-dimensional data model & flexible query language – RoleやAZごとにメトリクスを集計して比較 – 負荷傾向が異なるインスタンスを検出 • pull model over HTTP & service discovery – Roleなどを条件にモニタリング対象を設定 – モニタリング対象増加への対応が容易
  6. 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. 7. avg(cpu) by (availability_zone)
  8. 8. cpu{role="web"}
  9. 9. avg(cpu) by (role)
  10. 10. Service Discovery • モニタリング対象を自動検知する機能 • 環境にあわせて使用するSDを選択する – ec2_sd, consul_sd, kubernetes_sd, file_sd • (Pullだからこそ必要な機能)
  11. 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. 12. Prometheusの設定方法 Prometheus (for web) Prometheus (for db) Role=web Role=db pack upload deploy edit このロゴはJenkins project (https://jenkins.io/)に帰属します。
  13. 13. CloudWatch対応 • CloudWatchのメトリクスもPrometheusに取り込んでいる • cloudwatch_exporterはJavaに依存しているので使わない • aws-sdk-goを使ってexporterを作成 • メトリクスのtimestamp記録が問題 – CloudWatchのメトリクス送出は数分単位で遅れる – timestampを記録しようとすると、古いメトリクスとして扱われ、 Prometheusに取り込めないことがある – 現状は妥協して、一部メトリクスはtimestampを記録していない
  14. 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. 15. ディスク書き込み負荷
  16. 16. ディスク使用量 • モニタリング対象1台あたりで計算 • 1台あたり150 – 300メトリクス • メトリクスのscrape間隔は15秒 • 1ヶ月のディスク消費は約200MB
  17. 17. メトリクスの長期保存 • rrdtoolのようにデータをサマライズする機能はない • メトリクスの保持期間に応じてデータサイズは増加 • デフォルトでは15日経過時点で削除される • メトリクスの長期保存は想定されていない • 長期保存する場合 – Remote Storage (Graphiteなど)を利用する – 長期保存用のPrometheusに、サマライズして保存する
  18. 18. 1年間運用して • 運用について – 負荷は安定している – 運用の手間はほとんどない • バージョンアップ時の対応 – 新しい書式に対応する必要が何度かあった – 1.0までは非互換な変更がある • 新規要件への対応 – 必要に応じてexporterを作成 – 強力なクエリのおかげで、exporter自体はシンプルに作れた
  19. 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

×