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

Slide 1

Slide 1 text

やさしいかんし  ミートアップ  vol.2

Slide 2

Slide 2 text

こんにちは！

Slide 3

Slide 3 text

@o0h_です！

Slide 4

Slide 4 text

ࣗݾ঺հ • ίωώτגࣜձࣾ • αʔόʔαΠυΤϯδχΞ • ओʹCakePHPͳͲ

Slide 5

Slide 5 text

ࠓ೔ͷ͓͠ͳ͕͖ ᶃϞχλϦϯάܥͷπʔϧ͕͋·ͨ͋Δ ᶄKibana࢖ͬͯΈ·͠ΐ ᶅ࣭໰΍঺հɾࣗຫͳͲʂ(օ͞Μͷ൪ʂ)

Slide 6

Slide 6 text

PART1 モニタリング系のツールが  あまたある

Slide 7

Slide 7 text

俺たちのドックベースの話をしよう

Slide 8

Slide 8 text

πʔϧͨ͘͞Μ • ʮো֐ରԠʯ΋͘͠͸ʮϞχλϦϯάʯͱ͸ɺ  ʮͲ͜ʹ໰୊͕ੜ͍ͯ͡Δ͔ʯΛ੾Γ෼͚ Δɾ؂ࢹ͢ΔΞΫγϣϯ

Slide 9

Slide 9 text

πʔϧͨ͘͞Μ • Πϯγσϯτ࣌ʹ͸ʮͲ͜ͰԿ͕ى͖ͯΔͷ ͔ʯΛ͍ͪૣ͘ݟ͚ͭͨਓ͕ώʔϩʔʂ  ͦͷͨΊʹ࢖͑Δ΋ͷ͸ԿͰ΋࢖͏ • ʮπʔϧΛ࢖͑ΔʯΑ͏ʹͳΔ͜ͱ͕ೖΓޱ

Slide 10

Slide 10 text

΁ʔ͠Όͷπʔϧ܈ • ΠϯϑϥϞχλϦϯά • 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

Slide 11

Slide 11 text

͜ΕΛશ෦࢖͍͜ͳ͢ͷ͔ʁ  ଟ͘ͳ͍͔ʁ

Slide 12

Slide 12 text

ツールの「多くなりがち」問題そもそも「システム」とは・・・ • 「部品」が複雑に組み合わさり成り⽴つもの • 「監視ポイント」が増えると  それぞれに対応するツールが増えていきがち

Slide 13

Slide 13 text

No content

Slide 14

Slide 14 text

ツールが多い？少ない？⼊⾨監視「データベースを監視するのに4つのツールを使っていて、それらがすべて同じ情報を提供するなら、集約を考えましょう。⼀⽅で、データベースを監視する3つのツールがそれぞれ別の情報を提供するなら、おそらく問題ありません。」(P6)

Slide 15

Slide 15 text

ツールが多い？少ない？ • 「何個あるか」が正解ではない • 「使いこなせるか」「それぞれ使う場⾯・⽬的があるか」により(不)正解が変わる

Slide 16

Slide 16 text

͡Ό͋ɺશͯҧ͏໨తͰ  ಋೖ͞Ε͍ͯΔͷ͔Ͷʁ

Slide 17

Slide 17 text

ツールの「得⼿不得⼿」⼊⾨監視監視のアンチパターン 3-2:  アラートに関しては、OSのメトリクスはあまり意味がない • 低レベルなメトリクスではなく  「動いているか」を基準にアラートを送ることが有益 • 「動いている」とは(ユーザーが)ちゃんと使えていること • OSのメトリクスは  診断やパフォーマンス分析にとって重要です

Slide 18

Slide 18 text

微妙いアラート "QQ4FSWFSͷ  $16ར༻཰͕  ઌͷ࣌ؒͱൺ΂ͯ  ૿͍͑ͯΔΑʂʂ

Slide 19

Slide 19 text

微妙いアラート "QQ4FSWFSͷ  $16ར༻཰͕  ઌͷ࣌ؒͱൺ΂ͯ  ૿͍͑ͯΔΑʂʂ ΋͠ʮϢʔβʔ͕ී௨ʹ࢖͍͑ͯΔʯͳΒ  ͜ΕΛʮ໰୊ʯͱݺͿʹ͸ૣ͍ʂ

Slide 20

Slide 20 text

いいアラート ͳΜ͔ಈ͔ͳ͍Αʂʂ

Slide 21

Slide 21 text

いいアラート ͳΜ͔ಈ͔ͳ͍Αʂʂ ʮϢʔβʔ͕࢖͍͑ͯͳ͍ʯͳΒୟ͖ىͯ͘͜͠Εʂ  ͱ͍͏ͷ͕ʮ͍͍Ξϥʔτʯ

Slide 22

Slide 22 text

いいアラート ͳΜ͔ ͔͜͠·Γ·ͨ͠ʂ  ໰୊ͷൃੜঢ়گΛ֬ೝ͠·͢ʂ  %#ʁ"QQ /FUXPSL

Slide 23

Slide 23 text

各ツールの⽴ち位置を考える • 監視すべきは「ユーザーに近い位置」から • 問題の分析は「内部状況」から Ξϥʔτ ۷ΓԼ͛

Slide 24

Slide 24 text

「⽬的」と「できること」を  ⽐較検討してみると良さそう

Slide 25

Slide 25 text

ツールの「⽴ち位置」観測主体:  外側 vs 内側 = ユーザーに近いvsシステムの内部 • クライアントサイドやシステム外部からの監視 • OSや各コンポーネントの持つシステムメトリクス

Slide 26

Slide 26 text

ツールの「⽴ち位置」観測種別:  俯瞰・定量 : 具体・訂正  = 全体を追うものvs個別のログを追うもの • 定量: 計量をして、数値の動きを記録 • 定性: 処理内容や処理結果をログやそれに近いレベルで記録(リクエストやユーザー単位など)

Slide 27

Slide 27 text

この2つの軸でプロットしてみると  「何に使えるか」が浮かんでくる(かも)

Slide 28

Slide 28 text

Ϣʔβʔʹ͍ۙ ػցͷ಺ଆ ۩ମɾఆੑ ၆ᛌɾఆྔ Logs コネヒトのモニタリングツールの  得意なポジションマップ

Slide 29

Slide 29 text

例① CloudWatch • サーバーやデータベースのメモリ使⽤量」「ロードバランサーへのリクエスト数」といった、”インフラの数字"がみえる • 「複数のコンポーネントの中で、どこが不調か」というのを切り分けるのに利⽤ • 「局所的な観測対象」の変化を⽰すため、  固執すると「実は意味のない」監視になるリスク

Slide 30

Slide 30 text

例② Mixpanel • リソースモニタリングのためのツールではないが、「ユーザーが使えているか」という点では⼤活躍！ • ⼊⾨監視「ビジネスKPIの監視」 • 例えば「投稿数が著しく落ちている」なら異常事態といえる

Slide 31

Slide 31 text

例③ Sentry • アプリケーションで発⽣・検知したエラー • 「アプリケーションがエラーを起こしている」ので、ユーザーが操作不能になっている可能性もある (個別的な判断が必要) • 実装上「例外」ではあっても、例えば「ユーザーの⼊⼒ミス」など「システム異常」ではない場合も

Slide 32

Slide 32 text

「1つのツール」で、  みえる範囲や解像度は限界がある。「複数のツール」を組み合わせることで  ⽴体的な状況理解を得られる。

Slide 33

Slide 33 text

例えばの話① • Sentry「今までにないエラーが起きたよ〜！」 • Dev「あ、数少ないけどコレは致命的なエラーが起きる問題だ><」

Slide 34

Slide 34 text

例えばの話② • Sentry「今までにないエラーが起きたよ〜！」 • Dev「ランタイムエラー、実装ミスとは⾔えないかもな〜」 • CloudWatch「400が増えてるかもね！」 • Dev「ユーザーの操作が達成できなくなってる可能性〜」

Slide 35

Slide 35 text

例えばの話③ • Sentry「今までにないエラーが起きたよ〜！」 • CloudWatch「500は特に増えてないし、ほとんどのリクエストを200で返せてるなー」 • Mixpanel「対DAU⽐で投稿数がめっちゃ増えてる！」 • Dev「意図しないリクエストやチャタリングが起きてるのかな〜〜！？」

Slide 36

Slide 36 text

(ちなみに)  ⾃分の⼿慣れたツール増やしておくと  楽っすよ

Slide 37

Slide 37 text

ɾɾɾͰ΋ଟ͍ΑͶʁ

Slide 38

Slide 38 text

私「(せやな)」 • 似たような位置づけ、データソースのツールがある • 必ずしも「全部」使えるようにする必要はない • ものによっては集約を考えても良いかもしれないし、そのままでも良いかもしれない • 考えてるのでちょっと待って！(優先度⾼くない)