Slide 1

Slide 1 text

Prometheus on AWS

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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, …

Slide 7

Slide 7 text

avg(cpu) by (availability_zone)

Slide 8

Slide 8 text

cpu{role="web"}

Slide 9

Slide 9 text

avg(cpu) by (role)

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

ディスク書き込み負荷

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

参考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