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
やさしい監視ミートアップ vol.2 / monitoring-at-ease-2
Search
hideki kinjyo
PRO
June 21, 2019
Technology
0
2.3k
やさしい監視ミートアップ vol.2 / monitoring-at-ease-2
社内で「監視の民主化」を推し進めている一環として、「監視に関するツールはたくさんあるが、全て使いこなす必要があるのか?」という話をしました。
hideki kinjyo
PRO
June 21, 2019
Tweet
Share
More Decks by hideki kinjyo
See All by hideki kinjyo
Composerが「依存解決」のためにどんな工夫をしているか #phpcon
o0h
PRO
1
230
Composerの依存解決 #phpstudy
o0h
PRO
0
99
「影響が少ない」を自分の目でみてみる
o0h
PRO
3
1.6k
PHPによる"非"構造化プログラミング入門 -本当に熱いスパゲティコードを求めて- #phperkaigi
o0h
PRO
0
1.5k
もう少しテストを書きたいんじゃ〜 #phpstudy
o0h
PRO
23
5.1k
『テスト書いた方が開発が早いじゃん』を解き明かす #phpcon_nagoya
o0h
PRO
10
3.6k
色んなオートローダーを覗き見る #phpcon_okinawa
o0h
PRO
5
650
ヒューマンエラーの本を読んだ ~報告会~
o0h
PRO
3
330
みんなでワイワイ「テスト駆動開発」の話をやる会 #techramen24conf
o0h
PRO
4
650
Other Decks in Technology
See All in Technology
BigQuery Remote FunctionでLooker Studioをインタラクティブ化
cuebic9bic
3
280
2年でここまで成長!AWSで育てたAI Slack botの軌跡
iwamot
PRO
4
700
Node-REDのFunctionノードでMCPサーバーの実装を試してみた / Node-RED × MCP 勉強会 vol.1
you
PRO
0
110
AWS CDK 実践的アプローチ N選 / aws-cdk-practical-approaches
gotok365
6
740
Javaで作る RAGを活用した Q&Aアプリケーション
recruitengineers
PRO
1
110
Fabric + Databricks 2025.6 の最新情報ピックアップ
ryomaru0825
1
130
rubygem開発で鍛える設計力
joker1007
2
200
HiMoR: Monocular Deformable Gaussian Reconstruction with Hierarchical Motion Representation
spatial_ai_network
0
110
ひとり情シスなCTOがLLMと始めるオペレーション最適化 / CTO's LLM-Powered Ops
yamitzky
0
430
Observability infrastructure behind the trillion-messages scale Kafka platform
lycorptech_jp
PRO
0
140
PHPでWebブラウザのレンダリングエンジンを実装する
dip_tech
PRO
0
200
~宇宙最速~2025年AWS Summit レポート
satodesu
1
1.8k
Featured
See All Featured
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
233
17k
Music & Morning Musume
bryan
46
6.6k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
35
2.3k
Become a Pro
speakerdeck
PRO
28
5.4k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.4k
Visualization
eitanlees
146
16k
How to train your dragon (web standard)
notwaldorf
93
6.1k
Done Done
chrislema
184
16k
Making Projects Easy
brettharned
116
6.3k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
252
21k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
5
210
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
Transcript
やさしいかんし ミートアップ vol.2
こんにちは!
@o0h_です!
ࣗݾհ • ίωώτגࣜձࣾ • αʔόʔαΠυΤϯδχΞ • ओʹCakePHPͳͲ
ࠓͷ͓͠ͳ͕͖ ᶃϞχλϦϯάܥͷπʔϧ͕͋·ͨ͋Δ ᶄKibanaͬͯΈ·͠ΐ ᶅ࣭հɾࣗຫͳͲʂ(օ͞Μͷ൪ʂ)
PART1 モニタリング系のツールが あまたある
俺たちのドックベース の話をしよう
πʔϧͨ͘͞Μ • ʮোରԠʯ͘͠ʮϞχλϦϯάʯͱɺ ʮͲ͜ʹ͕ੜ͍ͯ͡Δ͔ʯΛΓ͚ Δɾࢹ͢ΔΞΫγϣϯ
πʔϧͨ͘͞Μ • Πϯγσϯτ࣌ʹʮͲ͜ͰԿ͕ى͖ͯΔͷ ͔ʯΛ͍ͪૣ͘ݟ͚ͭͨਓ͕ώʔϩʔʂ ͦͷͨΊʹ͑ΔͷԿͰ͏ • ʮπʔϧΛ͑ΔʯΑ͏ʹͳΔ͜ͱ͕ೖΓޱ
ʔ͠Όͷπʔϧ܈ • ΠϯϑϥϞχλϦϯά • AWS CloudWatch • ΤϥʔτϥοΧʔ • Sentry
• ߦಈੳܥͷπʔϧ • mixpanel • Google Analytics • ֎ܗࢹ • Pingdom • Datadog • ϩΪϯά • PaperTrail • BigQuery / mamari_access_log • Athena • CloudWatch Logs • Amazon ECS Events/Log • Firebase Analytics • ϩάूܭ • Kibana • Amazon RDS Performance Insights
͜ΕΛશ෦͍͜ͳ͢ͷ͔ʁ ଟ͘ͳ͍͔ʁ
ツールの「多くなりがち」問題 そもそも「システム」とは・・・ • 「部品」が複雑に組み合わさり成り⽴つもの • 「監視ポイント」が増えると それぞれに対応するツールが増えていきがち
None
ツールが多い?少ない? ⼊⾨監視「データベースを監視するのに4つの ツールを使っていて、それらがすべて同じ情報 を提供するなら、集約を考えましょう。⼀⽅ で、データベースを監視する3つのツールがそれ ぞれ別の情報を提供するなら、おそらく問題あ りません。」(P6)
ツールが多い?少ない? • 「何個あるか」が正解ではない • 「使いこなせるか」「それぞれ使う場⾯・⽬ 的があるか」により(不)正解が変わる
͡Ό͋ɺશͯҧ͏తͰ ಋೖ͞Ε͍ͯΔͷ͔Ͷʁ
ツールの「得⼿不得⼿」 ⼊⾨監視 監視のアンチパターン 3-2: アラートに関しては、OSのメトリクスはあまり意味がない • 低レベルなメトリクスではなく 「動いているか」を基準にアラートを送ることが有益 • 「動いている」とは(ユーザーが)ちゃんと使えていること
• OSのメトリクスは 診断やパフォーマンス分析にとって重要です
微妙いアラート "QQ4FSWFSͷ $16ར༻͕ ઌͷ࣌ؒͱൺͯ ૿͍͑ͯΔΑʂʂ
微妙いアラート "QQ4FSWFSͷ $16ར༻͕ ઌͷ࣌ؒͱൺͯ ૿͍͑ͯΔΑʂʂ ͠ʮϢʔβʔ͕ී௨ʹ͍͑ͯΔʯͳΒ ͜ΕΛʮʯͱݺͿʹૣ͍ʂ
いいアラート ͳΜ͔ಈ͔ͳ͍Αʂʂ
いいアラート ͳΜ͔ಈ͔ͳ͍Αʂʂ ʮϢʔβʔ͕͍͑ͯͳ͍ʯͳΒୟ͖ىͯ͘͜͠Εʂ ͱ͍͏ͷ͕ʮ͍͍Ξϥʔτʯ
いいアラート ͳΜ͔ ͔͜͠·Γ·ͨ͠ʂ ͷൃੜঢ়گΛ֬ೝ͠·͢ʂ %#ʁ"QQ /FUXPSL
各ツールの⽴ち位置を考える • 監視すべきは「ユーザーに近い位置」から • 問題の分析は「内部状況」から Ξϥʔτ ۷ΓԼ͛
「⽬的」と「できること」を ⽐較検討してみると良さそう
ツールの「⽴ち位置」 観測主体: 外側 vs 内側 = ユーザーに近いvsシステムの内部 • クライアントサイドやシステム外部からの 監視
• OSや各コンポーネントの持つシステムメト リクス
ツールの「⽴ち位置」 観測種別: 俯瞰・定量 : 具体・訂正 = 全体を追うものvs個別のログを追うもの • 定量: 計量をして、数値の動きを記録
• 定性: 処理内容や処理結果をログやそれに近い レベルで記録(リクエストやユーザー単位など)
この2つの軸でプロットしてみると 「何に使えるか」が浮かんでくる(かも)
Ϣʔβʔʹ͍ۙ ػցͷଆ ۩ମɾఆੑ ၆ᛌɾఆྔ Logs コネヒトのモニタリングツールの 得意なポジションマップ
例① CloudWatch • サーバーやデータベースのメモリ使⽤量」「ロー ドバランサーへのリクエスト数」といった、”イン フラの数字"がみえる • 「複数のコンポーネントの中で、どこが不調か」 というのを切り分けるのに利⽤ •
「局所的な観測対象」の変化を⽰すため、 固執すると「実は意味のない」監視になるリスク
例② Mixpanel • リソースモニタリングのためのツールではな いが、「ユーザーが使えているか」という点 では⼤活躍! • ⼊⾨監視「ビジネスKPIの監視」 • 例えば「投稿数が著しく落ちている」なら異
常事態といえる
例③ Sentry • アプリケーションで発⽣・検知したエラー • 「アプリケーションがエラーを起こしている」の で、ユーザーが操作不能になっている可能性もある (個別的な判断が必要) • 実装上「例外」ではあっても、例えば「ユーザーの
⼊⼒ミス」など「システム異常」ではない場合も
「1つのツール」で、 みえる範囲や解像度は限界がある。 「複数のツール」を組み合わせることで ⽴体的な状況理解を得られる。
例えばの話① • Sentry「今までにないエラーが起きた よ〜!」 • Dev「あ、数少ないけどコレは致命的なエラー が起きる問題だ><」
例えばの話② • Sentry「今までにないエラーが起きたよ〜!」 • Dev「ランタイムエラー、実装ミスとは⾔えない かもな〜」 • CloudWatch「400が増えてるかもね!」 • Dev「ユーザーの操作が達成できなくなってる可
能性〜」
例えばの話③ • Sentry「今までにないエラーが起きたよ〜!」 • CloudWatch「500は特に増えてないし、ほとんどのリ クエストを200で返せてるなー」 • Mixpanel「対DAU⽐で投稿数がめっちゃ増えてる!」 • Dev「意図しないリクエストやチャタリングが起きて
るのかな〜〜!?」
(ちなみに) ⾃分の⼿慣れたツール増やしておくと 楽っすよ
ɾɾɾͰଟ͍ΑͶʁ
私「(せやな)」 • 似たような位置づけ、データソースのツールがあ る • 必ずしも「全部」使えるようにする必要はない • ものによっては集約を考えても良いかもしれない し、そのままでも良いかもしれない •
考えてるのでちょっと待って!(優先度⾼くない)
PART1 モニタリング系のツールが あまたある -fin-
(社外公開はここまで)