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
260
Composerの依存解決 #phpstudy
o0h
PRO
0
100
「影響が少ない」を自分の目でみてみる
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
340
みんなでワイワイ「テスト駆動開発」の話をやる会 #techramen24conf
o0h
PRO
4
650
Other Decks in Technology
See All in Technology
面倒な作業はAIにおまかせ。Flutter開発をスマートに効率化
ruideengineer
0
260
高速なプロダクト開発を実現、創業期から掲げるエンタープライズアーキテクチャ
kawauso
2
9.4k
無意味な開発生産性の議論から抜け出すための予兆検知とお金とAI
i35_267
4
13k
Geminiとv0による高速プロトタイピング
shinya337
1
270
DBのスキルで生き残る技術 - AI時代におけるテーブル設計の勘所
soudai
PRO
50
20k
Should Our Project Join the CNCF? (Japanese Recap)
whywaita
PRO
0
340
Reach American Airlines®️ Instantly: 19 Calling Methods for Fast Support in the USA
flyamerican
1
170
AWS Organizations 新機能!マルチパーティ承認の紹介
yhana
1
280
LLM時代の検索
shibuiwilliam
2
160
マネジメントって難しい、けどおもしろい / Management is tough, but fun! #em_findy
ar_tama
7
1.1k
SEQUENCE object comparison - db tech showcase 2025 LT2
nori_shinoda
0
140
Beyond Kaniko: Navigating Unprivileged Container Image Creation
f30
0
130
Featured
See All Featured
Product Roadmaps are Hard
iamctodd
PRO
54
11k
The Cost Of JavaScript in 2023
addyosmani
51
8.5k
The Straight Up "How To Draw Better" Workshop
denniskardys
234
140k
Faster Mobile Websites
deanohume
307
31k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
667
120k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
50
5.5k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
Art, The Web, and Tiny UX
lynnandtonic
299
21k
Typedesign – Prime Four
hannesfritz
42
2.7k
Six Lessons from altMBA
skipperchong
28
3.9k
A Tale of Four Properties
chriscoyier
160
23k
The Power of CSS Pseudo Elements
geoffreycrofte
77
5.9k
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-
(社外公開はここまで)