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.5k
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
AI によってシステム障害が増える!? ~AI エージェント時代だからこそ必要な、インシデントとの向き合い方~
jacopen
4
240
インシデント対応に必要となるAIの利用パターンとPagerDutyの関係
jacopen
0
100
今日からはじめるプラットフォームエンジニアリング
jacopen
8
3.7k
Platform Engineeringで クラウドの「楽しくない」を解消しよう
jacopen
8
830
トラシューアニマルになろう ~開発者だからこそできる、安定したサービス作りの秘訣~
jacopen
4
5.1k
あなたの興味は信頼性?それとも生産性? SREとしてのキャリアに悩むみなさまに伝えたい選択肢
jacopen
7
9.5k
PaaSの歴史と、 アプリケーションプラットフォームのこれから
jacopen
7
2.8k
AI x インシデント管理で拡げるサービスオーナーシップ
jacopen
0
260
間違いだらけのポストモーテム - ホントに役立つレビューはこうだ!
jacopen
7
1.9k
Other Decks in Technology
See All in Technology
エラーとアクセシビリティ
schktjm
0
1k
Kiroと学ぶコンテキストエンジニアリング
oikon48
6
9k
【Grafana Meetup Japan #6】Grafanaをリバプロ配下で動かすときにやること ~ Grafana Liveってなんだ ~
yoshitake945
0
330
AI開発ツールCreateがAnythingになったよ
tendasato
0
110
Webブラウザ向け動画配信プレイヤーの 大規模リプレイスから得た知見と学び
yud0uhu
0
210
下手な強制、ダメ!絶対! 「ガードレール」を「檻」にさせない"ガバナンス"の取り方とは?
tsukaman
2
350
Nstockの一人目エンジニアが 3年間かけて向き合ってきた セキュリティのこととこれから〜あれから半年〜
yo41sawada
0
210
異業種出身エンジニアが気づいた、転向して十数年経っても変わらない自分の武器とは
macnekoayu
0
300
なぜテストマネージャの視点が 必要なのか? 〜 一歩先へ進むために 〜
moritamasami
0
140
サンドボックス技術でAI利活用を促進する
koh_naga
0
190
Grafana Meetup Japan Vol. 6
kaedemalu
1
300
20250903_1つのAWSアカウントに複数システムがある環境におけるアクセス制御をABACで実現.pdf
yhana
2
360
Featured
See All Featured
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
7
840
Testing 201, or: Great Expectations
jmmastey
45
7.6k
Embracing the Ebb and Flow
colly
87
4.8k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
34
3.1k
Site-Speed That Sticks
csswizardry
10
810
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
126
53k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
49
3k
Automating Front-end Workflow
addyosmani
1370
200k
What's in a price? How to price your products and services
michaelherold
246
12k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
Build The Right Thing And Hit Your Dates
maggiecrowley
37
2.8k
Building Adaptive Systems
keathley
43
2.7k
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 チェックリストに 追加してね!
おわり