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.3k
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
ゲームから学ぶ、いちばん速いインシデント対応
jacopen
0
18
PEK2024 Recap
jacopen
2
110
クラウドネイティブの本質から考える、生産性と信頼性の両立
jacopen
3
780
「責任ある開発」を!フルサービスオーナーシップが変えるエンジニアリング文化
jacopen
9
1.9k
手を動かさないインシデント対応〜自動化で迅速・正確な運用を目指す〜
jacopen
3
400
エンジニアとしてのキャリアを支える自宅サーバー
jacopen
12
7.1k
Grafana x PagerDuty Better Together
jacopen
1
640
「共通基盤」を超えよ! 今、Platform Engineeringに取り組むべき理由
jacopen
27
8.3k
いろんな外資、いろんなロールで働いてみた話
jacopen
14
5k
Other Decks in Technology
See All in Technology
Product Utilization of Large Language Models Starting Today
ymatsuwitter
2
450
RAGの性能を評価しよう
kurahara
1
270
DenoでもViteしたい!インポートパスのエイリアスを指定してラクラクアプリ開発
bengo4com
0
1.7k
【shownet.conf_】ネットワークテストの最適化と利便性の追求
shownet
PRO
0
230
Authenticator のエミュレーションによる パスキーのログインテスト/nikkei-tech-talk-25
nikkei_engineer_recruiting
0
140
マルチAWSアカウント間のストリーミングによるデータ同期/AWS SaaS Builders Forum 2024
visional_engineering_and_design
1
110
エンジニアは伝え方が9割/90% of what engineers need is communication skills
ykanoh
2
150
Pythonを活用したLLMによる構造的データ生成の手法と実践
brainpadpr
2
210
All your memory are belong to… whom?
ennael
PRO
0
520
Rubyはなぜ「たのしい」のか? / Why is Ruby a programmers' best friend? #tqrk15
expajp
4
1.7k
【shownet.conf_】3Dアプローチで守るセキュリティ
shownet
PRO
0
270
【ログ分析勉強会#5】Elasticsearch/Kibana のパイプ型クエリー言語ES|QLの紹介 ~ Pandasと一緒にログ分析してみた
nobuhikosekiya
0
160
Featured
See All Featured
Art, The Web, and Tiny UX
lynnandtonic
295
20k
Designing Experiences People Love
moore
138
23k
Designing for Performance
lara
604
68k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
279
13k
The Cost Of JavaScript in 2023
addyosmani
43
5.8k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
504
140k
Building an army of robots
kneath
302
42k
GraphQLの誤解/rethinking-graphql
sonatard
65
9.9k
Build The Right Thing And Hit Your Dates
maggiecrowley
31
2.3k
Navigating Team Friction
lara
183
14k
Web development in the modern age
philhawksworth
205
10k
Documentation Writing (for coders)
carmenintech
65
4.3k
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 チェックリストに 追加してね!
おわり