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
430
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
AI画像認識を活用したゲーム内決済処理検証の自動化
gree_tech
PRO
0
800
長期運営で肥大化したExcelマスターデータの解消に向けた移行事例
gree_tech
PRO
0
820
ゲームにおけるメディアミックス展開との向き合い方 -ヘブンバーンズレッドのメディアミックス企画の立て方-
gree_tech
PRO
0
840
課題発見から始めるプロダクト密着型TA組織立ち上げ 〜小規模TAチームが3Dアセットの生産性を倍にした方法〜
gree_tech
PRO
0
850
属人化を叩き割れ!「制作加速」と「安定化」の矛盾を打破する:8年目プロダクトが辿り着いた「ミスが起こり得ない」アセット制作フローの全貌
gree_tech
PRO
0
800
20年続く長寿タイトルが、15年目にして売上を伸ばせた理由
gree_tech
PRO
0
1.3k
我々はどう生きるか
gree_tech
PRO
2
1k
変わるもの、変わらないもの :OSSアーキテクチャで実現する持続可能なシステム
gree_tech
PRO
0
5.4k
マネジメントに役立つ Google Cloud
gree_tech
PRO
0
110
Other Decks in Technology
See All in Technology
Bet AI Day 2026丨AIを「使う」から、AIが「働く」へ ― LayerXが進める「組織AI」の社会実装
layerx
PRO
3
2.8k
プロダクト思考 × 基盤思考を AIで実現する Compound Engineering
tkc66buzz
1
280
omasushiというライブラリを作った
polidog
PRO
0
130
Where Is JetBrains AI Heading- — Central CLI, Air Alpha, and the Agentic Development Stack
x5gtrn
PRO
0
140
AI時代に、プロダクトの数だけ積み上がる所有コストをどうエンジニアリングするか / Engineering the Cost of Ownership
kzkmaeda
1
1.1k
AIで開発は速くなったのに、なぜ現場は楽にならないのか 〜あなたの組織のボトルネックを突き止めるワークショップ〜
jacopen
1
270
AI時代におけるプロダクト横断勉強会の設計
zozotech
PRO
0
170
Sony-DroidKaigi2026
sony
1
400
Oracle Cloud Infrastructure IaaS 新機能アップデート 2026/6 - 2026/8
oracle4engineer
PRO
0
120
Backstageでつくるセルフサービスな社内開発基盤
kikunosuke75
1
360
全員がプロダクトへ向き合う組織を持続成長させるために——組織づくりのフライホイールと4象限 / The Flywheel Model and Four Quadrants for Organizational Design
hiro_torii
4
900
Benchmarking Vector Databases: pgvector vs. LanceDB
tsho
0
150
Featured
See All Featured
KATA
mclloyd
PRO
35
15k
Reflections from 52 weeks, 52 projects
jeffersonlam
356
21k
My Coaching Mixtape
mlcsv
0
310
Test your architecture with Archunit
thirion
2
2.4k
[SF Ruby Conf 2025] Rails X
palkan
2
1.3k
Balancing Empowerment & Direction
lara
6
1.3k
Odyssey Design
rkendrick25
PRO
2
800
Building the Perfect Custom Keyboard
takai
2
860
The State of eCommerce SEO: How to Win in Today's Products SERPs - #SEOweek
aleyda
2
11k
GraphQLの誤解/rethinking-graphql
sonatard
75
12k
エンジニアに許された特別な時間の終わり
watany
108
250k
Marketing to machines
jonoalderson
1
5.7k
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