Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Prometheus on AWS
Search
gree_tech
PRO
June 14, 2016
Technology
420
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
Prometheus on AWS
Prometheus on AWS
gree_tech
PRO
June 14, 2016
More Decks by gree_tech
See All by gree_tech
我々はどう生きるか
gree_tech
PRO
0
4
変わるもの、変わらないもの :OSSアーキテクチャで実現する持続可能なシステム
gree_tech
PRO
0
5.1k
マネジメントに役立つ Google Cloud
gree_tech
PRO
0
72
今この時代に技術とどう向き合うべきか
gree_tech
PRO
3
2.8k
生成AIを開発組織にインストールするために: REALITYにおけるガバナンス・技術・文化へのアプローチ
gree_tech
PRO
0
470
安く・手軽に・現場発 既存資産を生かすSlack×AI検索Botの作り方
gree_tech
PRO
0
470
生成AIを安心して活用するために──「情報セキュリティガイドライン」策定とポイント
gree_tech
PRO
1
2.4k
あうもんと学ぶGenAIOps
gree_tech
PRO
0
590
MVP開発における生成AIの活用と導入事例
gree_tech
PRO
0
620
Other Decks in Technology
See All in Technology
AI工学特論: MLOps・継続的評価
asei
11
3.1k
GMOフィナンシャルゲートが挑む、「止まらない」決済インフラ構築の裏側【SORACOM Discovery 2026】
soracom
PRO
0
110
AI Agent を本番環境へ―― Microsoft Foundry × Azure Serverless で作る Enterprise-Ready な基盤
shibayan
PRO
1
910
データ組織の転換期 一足飛びしない段階的戦略
leveragestech
PRO
0
120
信頼できるテスティングAIをどう育てるか?
odan611
0
170
Retriever と Reranker、結局どうする?
kazuaki
1
520
VPCセキュリティ対応の最新事情
nagisa53
2
350
1台から試せる!Edge IoTを使った位置情報の活用設計【SORACOM Discovery 2026】
soracom
PRO
0
110
BigQuery を検索ソースとした AI Agent の作り方って 〇〇 通りあんねん
satohjohn
0
140
もう一度考える SRE チームの作り方・育て方 / Rethinking SRE #1: Building and Growing SRE Teams
rrreeeyyy
1
160
最高のシステムプロンプトを作るためにフィードバック機能を導入した話
alchemy1115
1
240
PLaMoを毎日の開発で使い育てていく
pfn
PRO
0
150
Featured
See All Featured
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
27k
Are puppies a ranking factor?
jonoalderson
1
3.7k
How to Think Like a Performance Engineer
csswizardry
28
2.7k
Everyday Curiosity
cassininazir
0
270
The SEO identity crisis: Don't let AI make you average
varn
0
520
Efficient Content Optimization with Google Search Console & Apps Script
katarinadahlin
PRO
1
750
Making the Leap to Tech Lead
cromwellryan
135
10k
How GitHub (no longer) Works
holman
316
150k
svc-hook: hooking system calls on ARM64 by binary rewriting
retrage
2
410
Utilizing Notion as your number one productivity tool
mfonobong
4
490
Docker and Python
trallard
47
4k
Pawsitive SEO: Lessons from My Dog (and Many Mistakes) on Thriving as a Consultant in the Age of AI
davidcarrasco
0
200
Transcript
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 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, …
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-storage-57557499