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
Composerが「依存解決」のためにどんな工夫をしているか #phpcon
o0h
PRO
1
330
Composerの依存解決 #phpstudy
o0h
PRO
0
100
「影響が少ない」を自分の目でみてみる
o0h
PRO
3
1.6k
PHPによる"非"構造化プログラミング入門 -本当に熱いスパゲティコードを求めて- #phperkaigi
o0h
PRO
0
1.5k
もう少しテストを書きたいんじゃ〜 #phpstudy
o0h
PRO
23
5.1k
『テスト書いた方が開発が早いじゃん』を解き明かす #phpcon_nagoya
o0h
PRO
10
3.7k
色んなオートローダーを覗き見る #phpcon_okinawa
o0h
PRO
5
660
ヒューマンエラーの本を読んだ ~報告会~
o0h
PRO
3
340
みんなでワイワイ「テスト駆動開発」の話をやる会 #techramen24conf
o0h
PRO
4
660
Other Decks in Technology
See All in Technology
CDK Vibe Coding Fes
tomoki10
1
510
ビジネス職が分析も担う事業部制組織でのデータ活用の仕組みづくり / Enabling Data Analytics in Business-Led Divisional Organizations
zaimy
1
310
OpenTelemetryセマンティック規約の恩恵とMackerel APMにおける活用例 / SRE NEXT 2025
mackerelio
2
1.6k
話題の MCP と巡る OCI RAG ソリューションの旅 - Select AI with RAG と Generative AI Agents ディープダイブ
oracle4engineer
PRO
5
110
オーティファイ会社紹介資料 / Autify Company Deck
autifyhq
10
130k
CDKTFについてざっくり理解する!!~CloudFormationからCDKTFへ変換するツールも作ってみた~
masakiokuda
1
200
Rethinking Incident Response: Context-Aware AI in Practice
rrreeeyyy
1
330
SEQUENCE object comparison - db tech showcase 2025 LT2
nori_shinoda
0
280
ポストコロナ時代の SaaS におけるコスト削減の意義
izzii
1
200
Delta airlines®️ USA Contact Numbers: Complete 2025 Support Guide
airtravelguide
0
350
敢えて生成AIを使わないマネジメント業務
kzkmaeda
2
500
ABEMAの本番環境負荷試験への挑戦
mk2taiga
5
770
Featured
See All Featured
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
46
9.6k
Speed Design
sergeychernyshev
32
1k
Building a Modern Day E-commerce SEO Strategy
aleyda
42
7.4k
Visualization
eitanlees
146
16k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.4k
Build The Right Thing And Hit Your Dates
maggiecrowley
37
2.8k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
Git: the NoSQL Database
bkeepers
PRO
430
65k
Unsuck your backbone
ammeep
671
58k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
331
22k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
107
19k
KATA
mclloyd
30
14k
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-
(社外公開はここまで)