Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
Prometheus on AWS
Search
gree_tech
PRO
June 14, 2016
Technology
450
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
34
AI駆動で挑むプロダクト刷新 ── アーキテクチャ設計とワークフロー最適化の実践事例 ──
gree_tech
PRO
0
33
『ヘブンバーンズレッド』のリグレッションテストにおけるストーリーの自動プレイ
gree_tech
PRO
0
38
REALITYにTAチームができるまでの軌跡〜ミッション:ガチャ本数5倍に対応せよ!〜
gree_tech
PRO
0
23
イベント続きでもミスらないライブサービスゲーム公式サイト運用システム開発
gree_tech
PRO
0
28
20年間 SNS サービス「GREE」 を支えた技術の刷新と、長期運用サービスの Kubernetes へのリアーキテクト
gree_tech
PRO
0
75
グラフ基盤ワークフローで実現するLLMによる自動ゲームプレイ
gree_tech
PRO
0
47
AIエージェントに脆弱性診断の仕事を奪われかけた ークローリングからコード全診断までの限界突破ー
gree_tech
PRO
0
36
アバター使っておもろいものを作り続けたい
gree_tech
PRO
0
30
Other Decks in Technology
See All in Technology
AIカンパニーへの転換を支えた、エンジニアの仕事の再定義
kworkdev
PRO
2
1.3k
Webの常識が通じないHTMLメールのダークモード
teamlab
PRO
0
130
Persisting Massive Data with Rails ~Designing for 60 billion rows, and fighting the bottlenecks~ Railsで挑む大量データ永続化 〜600億件を永続化するための設計とボトルネックとの戦い〜
occhi
0
730
Metadata - Section 1: HTML Basics
mohab1
0
120
エンタメ企業のM&Aを支えるデータ基盤 ― 統合から店舗のリアルタイム分析まで / Data Engineering Summit 2026
genda
0
190
How to Design Configuration for Rails Applications
willnet
1
820
S3 Filesで挑む! 八戸せんべい汁の食べ頃問題
usanchuu
0
100
[JAWS-UG彩の国埼玉#12]そろそろ準備する?re:Invent2026をやさしく解説 / reinvent2026-sainokuni
sh_fk2
1
350
Refining Active Record
shugo
0
160
JAWSUG TOHOKU 青森支部 「LoGoチャット」のAWS移行で 乗り越えたこと
taketakekaho
0
340
Gemini Intelligence 入門 ― AppFunctions と Gemini Nano
takuroabe
0
280
Code for Security プロジェクト紹介 2026年10月
yu23ki14
0
110
Featured
See All Featured
Thoughts on Productivity
jonyablonski
76
5.4k
The #1 spot is gone: here's how to win anyway
tamaranovitovic
4
1.2k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
AI Search: Where Are We & What Can We Do About It?
aleyda
0
8.1k
Git: the NoSQL Database
bkeepers
PRO
433
67k
DevOps and Value Stream Thinking: Enabling flow, efficiency and business value
helenjbeal
2
410
Effective software design: The role of men in debugging patriarchy in IT @ Voxxed Days AMS
baasie
1
570
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
37
6.6k
16th Malabo Montpellier Forum Presentation
akademiya2063
PRO
0
410
4 Signs Your Business is Dying
shpigford
187
23k
Stewardship and Sustainability of Urban and Community Forests
pwiseman
0
560
How Fast Is Fast Enough? [PerfNow 2025]
tammyeverts
3
940
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