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
もう少しテストを書きたいんじゃ〜 #phpstudy
o0h
PRO
16
3.8k
『テスト書いた方が開発が早いじゃん』を解き明かす #phpcon_nagoya
o0h
PRO
8
2.4k
色んなオートローダーを覗き見る #phpcon_okinawa
o0h
PRO
5
560
ヒューマンエラーの本を読んだ ~報告会~
o0h
PRO
3
290
みんなでワイワイ「テスト駆動開発」の話をやる会 #techramen24conf
o0h
PRO
4
570
SPLから始める「データ構造」入門
o0h
PRO
7
1.9k
PHPUnit11の新しい仲間たち
o0h
PRO
3
420
単体テストを書かない技術 #phpcon_odawara
o0h
PRO
62
21k
パンフ記事 「初めてのリファクタリング!」 の裏側 #phperkaigi
o0h
PRO
2
180
Other Decks in Technology
See All in Technology
遷移の高速化 ヤフートップの試行錯誤
narirou
6
1.1k
PHPで印刷所に入稿できる名札データを作る / Generating Print-Ready Name Tag Data with PHP
tomzoh
0
180
Raycast Favorites × Script Command で実現するお手軽情報チェック
smasato
1
140
RayでPHPのデバッグをちょっと快適にする
muno92
PRO
0
190
AWS Well-Architected Frameworkで学ぶAmazon ECSのセキュリティ対策
umekou
2
140
日経のデータベース事業とElasticsearch
hinatades
PRO
0
210
システム・ML活用を広げるdbtのデータモデリング / Expanding System & ML Use with dbt Modeling
i125
1
320
デスクトップだけじゃないUbuntu
mtyshibata
0
820
What's new in Go 1.24?
ciarana
1
110
入門 PEAK Threat Hunting @SECCON
odorusatoshi
0
140
【5分でわかる】セーフィー エンジニア向け会社紹介
safie_recruit
0
18k
Cracking the Coding Interview 6th Edition
gdplabs
14
28k
Featured
See All Featured
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
133
33k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.1k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.4k
Testing 201, or: Great Expectations
jmmastey
42
7.2k
A Modern Web Designer's Workflow
chriscoyier
693
190k
KATA
mclloyd
29
14k
BBQ
matthewcrist
87
9.5k
Building an army of robots
kneath
303
45k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
47
5.2k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
366
25k
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
4 Signs Your Business is Dying
shpigford
182
22k
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-
(社外公開はここまで)