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
Monitoringについてあれこれ語ろう - A Feedback from Cloud N...
Search
Kazuto Kusama
March 19, 2019
Technology
9
3.4k
Monitoringについてあれこれ語ろう - A Feedback from Cloud Native Deep Dive
Rancher Meetup #18で発表した資料です。
Monitoring、Logging、Alertingについてディスカッションした結果をまとめて共有しました。
Kazuto Kusama
March 19, 2019
Tweet
Share
More Decks by Kazuto Kusama
See All by Kazuto Kusama
Platform Engineeringで クラウドの「楽しくない」を解消しよう
jacopen
7
460
トラシューアニマルになろう ~開発者だからこそできる、安定したサービス作りの秘訣~
jacopen
3
3.3k
あなたの興味は信頼性?それとも生産性? SREとしてのキャリアに悩むみなさまに伝えたい選択肢
jacopen
7
6.8k
PaaSの歴史と、 アプリケーションプラットフォームのこれから
jacopen
7
2.2k
AI x インシデント管理で拡げるサービスオーナーシップ
jacopen
0
180
間違いだらけのポストモーテム - ホントに役立つレビューはこうだ!
jacopen
7
1.6k
2024/10 PagerDuty機能アップデート
jacopen
1
66
ゲームから学ぶ、いちばん速いインシデント対応
jacopen
1
130
PEK2024 Recap
jacopen
2
180
Other Decks in Technology
See All in Technology
PostgreSQL Unconference #52 pg_tde
nori_shinoda
0
180
[CATS]Amazon Bedrock GenUハンズオン座学資料 #2 GenU環境でRAGを体験してみよう
tsukuboshi
0
130
SaaSプロダクト開発におけるバグの早期検出のためのAcceptance testの取り組み
kworkdev
PRO
0
370
「エンジニアマネージャー」の役割を担っている / 担ってみたい方へのキャリアパスガイド
coconala_engineer
1
240
チームの性質によって変わる ADR との向き合い方と、生成 AI 時代のこれから / How to deal with ADR depends on the characteristics of the team
mh4gf
4
320
IAMのマニアックな話 2025 ~40分バージョン ~
nrinetcom
PRO
7
860
スケールアップ企業のQA組織のバリューを最大限に引き出すための取り組み
tarappo
4
870
Cline、めっちゃ便利、お金が飛ぶ💸
iwamot
19
18k
SLI/SLO・ラプソディあるいは組織への適用の旅
nwiizo
4
1.2k
移行できそうでやりきれなかった 10年超えのシステムを葬るための戦略
ryu955
2
200
移行できそうでやりきれなかった 10年超えのシステムを葬るための戦略 / phper-kaigi-2025-ryu
carta_engineering
0
680
空が堕ち、大地が割れ、海が涸れた日~もしも愛用しているフレームワークが開発停止したら?~ #phperkaigi 2025
77web
2
980
Featured
See All Featured
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
45
9.5k
Building Applications with DynamoDB
mza
94
6.3k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
129
19k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
34
2.9k
A Tale of Four Properties
chriscoyier
158
23k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.2k
Writing Fast Ruby
sferik
628
61k
Why You Should Never Use an ORM
jnunemaker
PRO
55
9.3k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
31
4.7k
Embracing the Ebb and Flow
colly
84
4.6k
Intergalactic Javascript Robots from Outer Space
tanoku
270
27k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.8k
Transcript
A Feedback from Cloud Native Deep Dive Monitoringについてあれこれ語ろう
Pivotal Japan - Solutions Architect Kazuto Kusama @jacopen
None
None
Cloud Native Deep Dive • 従来ながらの講義形式は取らない • あらかじめ決められたテーマについて、全員参加で ディスカッションを行う •
ディスカッションを通じて、実戦で使える知識と経験を深め ていく • 参加登録時にはアンケート回答が必須。 アンケート未回答者は参加不可。
テーマ #1 Manifest管理 #2 Service Mesh #3 Release Engineering #JKD
総集編 #4 Monitoring
今回は、#4の内容を 共有します
- Monitoring - Logging - Alerting
Monitoring
- Blackbox Monitoring - Whitebox Monitoring 分けて考えるべき
ツール • Datadog • Mackerel • Wavefront • Stackdriver •
CloudWatch • Prometheus • Elasticsearch • Zabbix • Sysdig SaaS IaaS Provided Self Hosted
監視する対象 • Baremetal • VM • Container • Security •
Networking • Backend • Frontend • Business KPI ・・・他にもいろいろ • Pod • Node • Cluster
みんなの課題 • どんなメトリクスを監視すればいいのか ◦ Kubernetesだけでも膨大な種類のメトリクスが • Kubernetesのクラスタ管理者とアプリ開発者への 通知切り分け • ロングタームのメトリクス管理方法・
ダウンサンプリング方法
みんなの課題 • 外れ値出たときどうするか? ◦ ここのハンドリング重要 ◦ DatadogやElasticsearchには検出する機能があるが・・・
みんなの課題 • Prometheusのメモリ使用量多い • モニタリングのモニタリング • そもそもPrometheus難しい ◦ relabel_configs ◦
PromQL ▪ Prometheusおじさんの発生!
みんなの課題 • Dashboardの作り方 ◦ JSONのレビュー大変 ▪ GrafanaならDashboard Shopあるが・・・ ◦ できる限りコード管理したい
▪ Grafanaでexportするたびに形が変わっててキツい • Jsonnetで生成⇒Grafanaに反映 を試そう • (Prometheusの場合) Prometheus Operator良い ◦ 最初からいい感じに作り込まれている ◦ 必要ならば自分で拡張することも出来る
みんなの課題 • そもそもDashboardいつ見る? ◦ 常に見る? ◦ デプロイ時に見る ◦ 週次でみる ◦
朝会時に見る ◦ 常に廊下に表示させる
みんなの課題 • Monitoring 101は読んでおくべき ◦ https://www.datadoghq.com/blog/tag/monitoring-101/
Logging
よくある構成 対象 対象 対象 Collector Collector Collector Aggregator Log Platform
ログ収集 集約 パース タギング フィルタリング 保存 インデックス化 検索 可視化
ツール • Fluentd • Fluentbit • LogStash • Splunk •
Elasticsearch • CloudWatch Logging • Stackdriver • S3 • GCS • DWH Collector Log Platform
Logging =
Logging = 課金
みんなの課題 • ロギングはカネがかかる!! ◦ SaaS高い ▪ ログ量に比例してガンガン金がかかる ◦ Self Hostedにしてもかなりの運用・インフラコストかかる
▪ 最終的には監視対象と同じくらいのインフラリソースがログ基 盤だけで必要になることも ◦ 結局は金
みんなの課題 • Aggregatorの運用辛すぎ ◦ とにかくここが死ぬ ◦ ログの保存量を制御することは出来るが、 ログの流量を制御するのは難しい ▪ アプリ側が大量のログ吐くとすぐ死ぬ
▪ Collector側で工夫する?⇒収集すべきものとしないものの判 断難しい ◦ パースやフィルタリングなどをやりやすい場所 ▪ でも処理に比例して負荷が増す • 死
みんなの課題 • ログの形式バラバラ問題 ◦ ミドルウェアによって吐く形式が違う ◦ チーム間でもログ形式は往々にして異なる ▪ チーム間で形式統一を試みた⇒無理だった ◦
パースせずに生データで保存 ▪ 正規表現地獄 ◦ ログ基盤側でなんとかする ▪ 負荷で激重になる
みんなの課題 • ログとメトリクスの横断検索が難しい問題 ◦ 何か問題が発生したとき、特定の時刻・特定のコンポーネントにおい て、ログとメトリクスを突き合わせて見たい ▪ ログ基盤とメトリクスが分断していると、 横断して調べるのが辛い ▪
SaaSや商用ソフトウェアだと、この機能を 備えているものもある
Alerting
みんなの課題 • 閾値の根拠は? • 通知先 ◦ Slack ◦ Chatwork ◦
Pagerduty ◦ メール • オンコール担当は誰か ◦ アプリのログはアプリ開発者に ◦ 基盤のログは基盤運用チームに
みんなの課題 • 突発的なアラート対応による生産性低下 ◦ Scrum開発しているのに、アラート対応によってスプリント計画が めちゃくちゃに ◦ 不安定な生活リズムによる生産性の低下 ◦ ベロシティバラバラ
みんなの課題 • オンコール先任者・部門を作るか? ◦ 対象アプリや基盤の知識が無い人がオンコール対応しても、 結局そのままエスカレーションされる ⇒ コミュニケーションロス • オンコールローテーション
◦ オンコール対応後の休暇など、制度の確立も必要 ◦ 少人数のチームだとどうする?
みんなの課題 • 誤検知・過剰なアラーティングへの対応 ◦ アラートのレベル分け大事 • 閾値やアラートレベルの見直しはいつやるか ◦ 定期的に見直す ◦
アドホックに対応 • アラートルールのコード化はどうやるか
みんなの課題 • 通知すべきメトリクスのベストプラクティスはあるか? ◦ ない! ◦ そもそも組織によって結構異なる ◦ アラーティングは、運用しながら育てる意識を持つこと
共通課題
それぞれ共通する課題 • コード化・自動化 ◦ Toilは極限まで減らす意識を持つこと ◦ 監視ルールは育てていくもの • 対応する人・組織・ロール ◦
できる限り自動化が前提 ◦ 単にコールを受けるだけのロールは悪手になりやすい • OSSか商用製品かManaged Serviceか ◦ ケースバイケース ◦ 無理に自前主義に走るのは考え物
Cloud Native Deep Dive https://www.meetup.com/ja-JP/Cloud-Native-Deep-Dive/ まずはJoin!
CloudNative Days
技術書典6 https://techbookfest.org/event/tbf06/circle/56220002 チェックリストに 追加してね!
おわり