やさしい監視ミートアップ 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. ツールの「多くなりがち」問題 そもそも「システム」とは・・・ • 「部品」が複雑に組み合わさり成り⽴つもの • 「監視ポイント」が増えると
 それぞれに対応するツールが増えていきがち

13. None

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. (社外公開はここまで)