やさしい監視ミートアップ vol.2 / monitoring-at-ease-2

社内で「監視の民主化」を推し進めている一環として、「監視に関するツールはたくさんあるが、全て使いこなす必要があるのか？」という話をしました。

Transcript

1. やさしいかんし
 ミートアップ
 vol.2
2. こんにちは！
3. @o0h_です！
4. ࣗݾ঺հ • ίωώτגࣜձࣾ • αʔόʔαΠυΤϯδχΞ • ओʹCakePHPͳͲ
5. ࠓ೔ͷ͓͠ͳ͕͖ ᶃϞχλϦϯάܥͷπʔϧ͕͋·ͨ͋Δ ᶄKibana࢖ͬͯΈ·͠ΐ ᶅ࣭໰΍঺հɾࣗຫͳͲʂ(օ͞Μͷ൪ʂ)
6. PART1 モニタリング系のツールが
 あまたある
7. 俺たちのドックベース の話をしよう
8. πʔϧͨ͘͞Μ • ʮো֐ରԠʯ΋͘͠͸ʮϞχλϦϯάʯͱ͸ɺ
 ʮͲ͜ʹ໰୊͕ੜ͍ͯ͡Δ͔ʯΛ੾Γ෼͚ Δɾ؂ࢹ͢ΔΞΫγϣϯ
9. πʔϧͨ͘͞Μ • Πϯγσϯτ࣌ʹ͸ʮͲ͜ͰԿ͕ى͖ͯΔͷ ͔ʯΛ͍ͪૣ͘ݟ͚ͭͨਓ͕ώʔϩʔʂ
 ͦͷͨΊʹ࢖͑Δ΋ͷ͸ԿͰ΋࢖͏ • ʮπʔϧΛ࢖͑ΔʯΑ͏ʹͳΔ͜ͱ͕ೖΓޱ
10. ΁ʔ͠Όͷπʔϧ܈ • ΠϯϑϥϞχλϦϯά • 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
11. ͜ΕΛશ෦࢖͍͜ͳ͢ͷ͔ʁ
 ଟ͘ͳ͍͔ʁ
12. ツールの「多くなりがち」問題 そもそも「システム」とは・・・ • 「部品」が複雑に組み合わさり成り⽴つもの • 「監視ポイント」が増えると
 それぞれに対応するツールが増えていきがち
14. ツールが多い？少ない？ ⼊⾨監視「データベースを監視するのに4つの ツールを使っていて、それらがすべて同じ情報 を提供するなら、集約を考えましょう。⼀⽅ で、データベースを監視する3つのツールがそれ ぞれ別の情報を提供するなら、おそらく問題あ りません。」(P6)
15. ツールが多い？少ない？ • 「何個あるか」が正解ではない • 「使いこなせるか」「それぞれ使う場⾯・⽬ 的があるか」により(不)正解が変わる
16. ͡Ό͋ɺશͯҧ͏໨తͰ
 ಋೖ͞Ε͍ͯΔͷ͔Ͷʁ
17. ツールの「得⼿不得⼿」 ⼊⾨監視 監視のアンチパターン 3-2:
 アラートに関しては、OSのメトリクスはあまり意味がない • 低レベルなメトリクスではなく
 「動いているか」を基準にアラートを送ることが有益 • 「動いている」とは(ユーザーが)ちゃんと使えていること • OSのメトリクスは
 診断やパフォーマンス分析にとって重要です
18. 微妙いアラート "QQ4FSWFSͷ
 $16ར༻཰͕
 ઌͷ࣌ؒͱൺ΂ͯ
 ૿͍͑ͯΔΑʂʂ
19. 微妙いアラート "QQ4FSWFSͷ
 $16ར༻཰͕
 ઌͷ࣌ؒͱൺ΂ͯ
 ૿͍͑ͯΔΑʂʂ ΋͠ʮϢʔβʔ͕ී௨ʹ࢖͍͑ͯΔʯͳΒ
 ͜ΕΛʮ໰୊ʯͱݺͿʹ͸ૣ͍ʂ
20. いいアラート ͳΜ͔ಈ͔ͳ͍Αʂʂ
21. いいアラート ͳΜ͔ಈ͔ͳ͍Αʂʂ ʮϢʔβʔ͕࢖͍͑ͯͳ͍ʯͳΒୟ͖ىͯ͘͜͠Εʂ
 ͱ͍͏ͷ͕ʮ͍͍Ξϥʔτʯ
22. いいアラート ͳΜ͔ ͔͜͠·Γ·ͨ͠ʂ
 ໰୊ͷൃੜঢ়گΛ֬ೝ͠·͢ʂ
 %#ʁ"QQ /FUXPSL
23. 各ツールの⽴ち位置を考える • 監視すべきは「ユーザーに近い位置」から • 問題の分析は「内部状況」から Ξϥʔτ ۷ΓԼ͛
24. 「⽬的」と「できること」を
 ⽐較検討してみると良さそう
25. ツールの「⽴ち位置」 観測主体:
 外側 vs 内側 = ユーザーに近いvsシステムの内部 • クライアントサイドやシステム外部からの 監視 • OSや各コンポーネントの持つシステムメト リクス
26. ツールの「⽴ち位置」 観測種別:
 俯瞰・定量 : 具体・訂正
 = 全体を追うものvs個別のログを追うもの • 定量: 計量をして、数値の動きを記録 • 定性: 処理内容や処理結果をログやそれに近い レベルで記録(リクエストやユーザー単位など)
27. この2つの軸でプロットしてみると
 「何に使えるか」が浮かんでくる(かも)
28. Ϣʔβʔʹ͍ۙ ػցͷ಺ଆ ۩ମɾఆੑ ၆ᛌɾఆྔ Logs コネヒトのモニタリングツールの
 得意なポジションマップ
29. 例① CloudWatch • サーバーやデータベースのメモリ使⽤量」「ロー ドバランサーへのリクエスト数」といった、”イン フラの数字"がみえる • 「複数のコンポーネントの中で、どこが不調か」 というのを切り分けるのに利⽤ • 「局所的な観測対象」の変化を⽰すため、
 固執すると「実は意味のない」監視になるリスク
30. 例② Mixpanel • リソースモニタリングのためのツールではな いが、「ユーザーが使えているか」という点 では⼤活躍！ • ⼊⾨監視「ビジネスKPIの監視」 • 例えば「投稿数が著しく落ちている」なら異 常事態といえる
31. 例③ Sentry • アプリケーションで発⽣・検知したエラー • 「アプリケーションがエラーを起こしている」の で、ユーザーが操作不能になっている可能性もある (個別的な判断が必要) • 実装上「例外」ではあっても、例えば「ユーザーの ⼊⼒ミス」など「システム異常」ではない場合も
32. 「1つのツール」で、
 みえる範囲や解像度は限界がある。 「複数のツール」を組み合わせることで
 ⽴体的な状況理解を得られる。
33. 例えばの話① • Sentry「今までにないエラーが起きた よ〜！」 • Dev「あ、数少ないけどコレは致命的なエラー が起きる問題だ><」
34. 例えばの話② • Sentry「今までにないエラーが起きたよ〜！」 • Dev「ランタイムエラー、実装ミスとは⾔えない かもな〜」 • CloudWatch「400が増えてるかもね！」 • Dev「ユーザーの操作が達成できなくなってる可 能性〜」
35. 例えばの話③ • Sentry「今までにないエラーが起きたよ〜！」 • CloudWatch「500は特に増えてないし、ほとんどのリ クエストを200で返せてるなー」 • Mixpanel「対DAU⽐で投稿数がめっちゃ増えてる！」 • Dev「意図しないリクエストやチャタリングが起きて るのかな〜〜！？」
36. (ちなみに)
 ⾃分の⼿慣れたツール増やしておくと
 楽っすよ
37. ɾɾɾͰ΋ଟ͍ΑͶʁ
38. 私「(せやな)」 • 似たような位置づけ、データソースのツールがあ る • 必ずしも「全部」使えるようにする必要はない • ものによっては集約を考えても良いかもしれない し、そのままでも良いかもしれない • 考えてるのでちょっと待って！(優先度⾼くない)
39. PART1 モニタリング系のツールが
 あまたある -fin-
40. (社外公開はここまで)