Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Speaker Deck
PRO
Sign in
Sign up
for free
やさしい監視ミートアップ vol.2 / monitoring-at-ease-2
hideki kinjyo
PRO
June 21, 2019
Technology
0
1.5k
やさしい監視ミートアップ vol.2 / monitoring-at-ease-2
社内で「監視の民主化」を推し進めている一環として、「監視に関するツールはたくさんあるが、全て使いこなす必要があるのか?」という話をしました。
hideki kinjyo
PRO
June 21, 2019
Tweet
Share
More Decks by hideki kinjyo
See All by hideki kinjyo
o0h
PRO
0
25
o0h
PRO
1
1.5k
o0h
PRO
4
3.4k
o0h
PRO
1
4.3k
o0h
PRO
0
540
o0h
PRO
0
780
o0h
PRO
1
1.8k
o0h
PRO
1
710
o0h
PRO
0
520
Other Decks in Technology
See All in Technology
ozuma
0
100
terurou
0
180
sadayoshitada0919
1
280
sky_joker
0
120
yosuke_matsuura
PRO
0
3.6k
saik1010
0
240
stakaya
14
8.3k
nwiizo
1
130
yosuke_furukawa
PRO
48
16k
chaspy
1
390
kraj
0
3.6k
nkjzm
1
860
Featured
See All Featured
searls
204
35k
schacon
145
6.6k
qrush
285
18k
shpigford
368
42k
mza
80
4.1k
reverentgeek
168
7.2k
samanthasiow
56
6.3k
brad_frost
156
6.4k
moore
125
21k
keathley
18
650
geoffreycrofte
19
810
stephaniewalter
260
11k
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-
(社外公開はここまで)