Monitoring - 入門監視

監視とはいったいどのような状態を指すのか、何の目的でどの項目をどのように「監視」したら良いのか。普段何気なく行なっている監視について改めて考え直します。

Transcript

1.       ⼩南 英司 Eiji KOMINAMI fukushima.dev #8 Monitoring
2. 2 本⽇の勉強会について   本⽇のゴール   監視に対する共通認識を持つ   監視のベストプラクティスを学ぶ   現体制/環境に適した監視の形を議論する   参考テキスト
3. 3 狭義の監視   あるシステムや そのコンポーネントの振る舞いや出⼒を 観察しチェックし続ける⾏為   システムに関する リアルタイム定量データを 収集、処理、集計、表⽰を⾏うこと
4. 4 監視サービスの機能とその⽬的   システムの健全性と可⽤性を追及するための主要な⼿段   データの収集   データの蓄積 •  ビジネス分析のための⽣データの提供   可視化 •  ダッシュボード   分析とレポート •  サービス変更に対するインパクトの計測 •  ⻑期トレンドの分析 •  サービス達成度の計測 •  時間軸や実験グループ間での⽐較 •  振り返り分析（でバッキング）   アラートとオンコール •  緊急対応（とその対応への科学的⼿法の適⽤）
5. アンチパターン
6. 6 ツールに依存しない   ツールの制限や機能に囚われない   複数のツールを併⽤する •  ⼀⽬で分かる単⼀のツールなど存在しない –  ⼀⽬で分かる環境を構築することは重要 •  複数のツールを統合してまとめる必要はない –  ただし、ツール同⼠が連携できるかどうかは意識する   ⽬的に合ったツールを選択する •  チーム内できちんと利⽤されるツールを選択する •  有名だから…はNG –  なぜそのツールが開発されてなぜそれがうまく動くのかは、 単にそのツールを導⼊するだけでは分からない •  ある程度の苦労は受忍する –  ⾃分でツールを作ることも検討 •  エージェントのインストールを恐れない
7. 7 監視を特定の⼈に押し付けない   監視はスキルであって役割ではない   チーム全体が監視について⼀定レベルの知識を有すべき •  ⾃分が理解できないシステムを監視だけすることはできない •  チーム全員が監視について責任を持つ   監視とは他のサービスから孤⽴した存在ではない •  監視できていないサービスは本番サービスとは呼べない
8. 8 形だけの監視はしない   「監視してますよ」と⾔うためならやらない⽅がいい   形だけ監視の例 •  エラーの理由が分からない •  アラートが発⽣しても無視をする •  過去の履歴を振り返ることができない   やるべきこと •  動いているとはどういう状態であるのかを定義し⾼いレベルで確認する •  メトリクスは少なくとも1分に1回の⾼頻度で取得する
9. 9 その他のアンチパターン   ⽼朽化したシステムを延命するための監視   異常の発⽣源は必ず修正する   その場の対応のためだけに時間を割くことは、 将来のためのシステム改善の時間を奪うということを意識する   設定を⼿動で⾏う   監視の設定も⾃動化すべき •  新しい監視設定やノードの追加がすぐにできないのは、⼤きな負荷となる •  監視の⼿順書が存在するのであれば、その⼿順の⾃動化を検討
10. デザインパターン
11. 11 組み合わせ可能な監視①   専⾨的な複数のツールを組み合わせる   データ収集 •  プッシュ型（=エージェント）とプル型に⼤きな差はないが、プッシュ型の⽅がスケールする •  メトリクス –  カウンタ型 数値がインクリメントされていく –  ゲージ型 任意のポイントの数値のみ。過去の値が分からない。 •  ログ –  ログはメトリクスより多くのデータを持てることを理解する –  ログをパースして解析 »  構造化ログと⾮構造化ログ –  アプリケーションのログは必ず出⼒する »  Syslog等を⽤いてログを1ヵ所で管理/解析することも可能   ストレージ •  メトリクス 時系列データベースに保存 •  ログ syslogやElasticsearchなどを利⽤、容量が多いので保存コストには注意
12. 12 組み合わせ可能な監視②   専⾨的な複数のツールを組み合わせる   可視化 •  ⾃分⽤に表⽰が組み合わせられるツールが望ましい –  そのサービスを理解した⼈間がダッシュボードを作る –  疑問に対してすぐに答えを提⽰できるものが望ましい   分析とレポート   アラート •  アラートは、あくまで監視の結果の1つ •  アラートを上げるために監視しているのではない
13. 13 その他のデザインパターン   どこを監視すべきかをユーザ視点で考える   ユーザが気にするのはアプリケーションが正常に動いているかどうか   個別のコンポーネントの正常性を気にしているわけではない   作るのではなく買う   今あるSaaSサービスの機能で⼗分   ⾃分たちで構築するために占有される時間 ドキュメント作成や使い⽅の習熟などで失う遺失損失を考える   継続的改善
14. サービスの健全性
15. 15 リスクと信頼性、サービスレベルの規定   ビジネスKPIに即したリスクと信頼性の算出   コスト/メリット分析 •  求められている以上に信頼性を⾼めてはいけない •  過度な信頼性の向上は、不要なエンジニアリングリソースを消費するだけ   サービスリスクの指標 •  計画外の停⽌時間 •  リクエスト成功率   ユーザの要求に即した個別のサービスレベルの算出   指標の例 •  リクエストレイテンシ, エラー率, システムスループット, 可⽤性…   項⽬の例 •  ユーザ数, ユーザログイン, コメント投稿, スレッド作成, 広告の購⼊…
16. 何を監視すべきか
17. 17 監視アセスメント   何を監視すべきなのか、 なぜ監視すべきなのかをシステマチックに判断する⼿法   アプリケーションとインフラをより明確に理解することが⽬的   何が問題で何が問題ではないのかを考える出発点
18. 18 監視システムが答えなければならない問い  何が壊れたのか  なぜ壊れたのか
19. 19 監視の種類   ブラックボックスモニタリング   ユーザが⽬にする外部的な振る舞いのテスト   フロントエンド監視   ユーザ⽬線の監視が最も重要 •  Javascriptを含むフロントエンドの挙動がサービスに与える影響の増加 –  SPA（Single Page Application）の普及 •  遅いアプリケーションのコスト –  ページのロードが1秒遅くなるとページビューが11%下がる –  ページのロードは4秒以内を⽬指す   ⼈間の⼿が必要なのは既に進⾏していて実際に症状が出ている事象   ホワイトボックスモニタリング   システム内部のメトリクスに基づくモニタリング •  マスクされている障害や近々に⽣じることになりそうな問題を検出できる
20. 20 監視の4⼤シグナル   レイテンシ   エラーのレイテンシも計測 •  ⾼速なエラーよりも低速なエラーの⽅が問題   トラフィック   エラー   サチュレーション   システムの利⽤率
21. 21 フロントエンド監視   リアルユーザ監視   実際のユーザトラフィックを⽤いて監視する   Google Analyticsが代表例   監視項⽬ •  Navigation Timing API –  navigationStart, domLoading, domInteractive, domContentLoaded, domCreated •  Javascriptの例外をロギング   シンセティック監視   テスト環境下で偽のトラフィックを⽣成   ロードが許容時間内に収まるかなどを計測 WebpageTestが代表例 •  Speed Indexの利⽤
22. 22 アプリケーション監視   性能評価   ARMツール（Datadogなど）を使⽤   ツールの制限事項やどのような観点で評価すべきかに注意   ビルドとリリースの監視   障害の70%はシステム変更の結果⽣じる   変更管理の⾃動化 •  漸進的なロールアウト •  ⾼速かつ正確な問題の検出 •  問題が⽣じたときのロールバック   ヘルスポイントデザインパターン   アプリのステータスをWebのレスポンスコードで返す   複雑性, メンテナンス性, 実装量の増加に注意
23. 23 サーバ監視   OSの標準的なメトリクス   あまり意味を成さない場合が多い •  アプリケーションが動いているかどうかが重要 •  診断やトラブルシューティングには有効   アラート設定の対象にしないほうが良い   確認項⽬の詳細は後述
24. 24 ログ監視   Syslogの利⽤   Syslogに送信   Syslogがディスク上のログを収集するように設定変更   データの保存   SaaSサービスの利⽤が便利   分析の例   HTTPレスポンス sudoの利⽤   SSHログイン   Cronジョブの結果   DBのスロークエリ
25. アラート
26. 26 良いアラートにするためには？   良いアラートは難しい   アラートの設定⾃体がそもそも難しい   受け取る⼈間の注意⼒には限界がある   何のためのアラートか   誰かをたたき起こすためのアラート •  確実に気づく必要がある   参考情報としてのアラート
27. 27 メールは使わない   メールは不適切な連絡⼿段   メールで⼈を叩き起こすことは出来ない   受け取る側がうんざりする   情報のレベルに合わせて送り先を変える   すぐに応答する必要があるものはSMS等を⽤いる   参考情報や喚起情報はチケット, チャット等に送信する   経歴や診断が必要な情報はログに書き込む        ...など
28. 28 障害対応⼿順書を作成する   ⼿順書は知識を共有するための良い⼿段   以下の疑問に答える内容が望ましい •  何をするための何のサービスか •  誰が責任者か •  どんな依存性を持っているか •  インフラの構成はどのようなものか •  どんなメトリクスを送っていて、それらはどういう意味なのか •  どんなアラートが設定されていて、その理由は何なのか   アラートの中に以下を記述する •  ⼿順書へのリンク •  期待される動作と実際の動作   ⼿順書の内容が簡単なものであれば⼿順⾃体を⾃動化すべき •  ⼿順書は⼈間の判断と診断が存在するからこそある
29. 29 設定の最適化①   シンプルなルール   チーム全員でシンプルかつ包括的なものを保つ   ルールは理解しやすく障害を明確に表現するものであるべき •  そのルールは、そのルール無しには検出できないものか •  そのアラートは無害だとして無視してよいものか –  どういったときに無視してよいのか •  ユーザに悪影響を与えるものか •  アラートに対してアクションを起こせるか –  どのくらいの時間でアクションを取らないといけないか   ルールとターゲットを分離   固定の閾値だけがアラートの基準値ではない   閾値だけでは変化量に気づけない   変化量やグラフの傾きなども材料にする
30. 30 設定の最適化②   アラートの量を減らす   ⼤量のアラートはアラート疲れを引き起こす •  エンジニアの負荷を適度に低く保つことが必要 •  何かがおかしいというだけでアラートを上げてはいけない   以下に限ってアラートを出すべき •  システム⾃⾝が⾃動修復できないもの •  ⼈間の判断と診断を必要とし具体的な対応が可能であるもの –  調査 –  問題に対処 –  根本原因を判断 •  緊急でユーザに影響を与えるもの
31. オンコールと緊急対応
32. 32 オンコールとは   システムの守護者 1.  アラートの受信 2.  ⼀連の観察結果と理論的な基盤を基に原因の仮説を⽴てる 3.  事前に合意したレスポンスタイム（5-30分）内に処理を⾏う •  他のエンジニアとの協⼒とエスカレーション –  イベント対応の優先度を規定 –  影響度に応じてエスカレーション
33. 33 オンコールと緊急対応①   トラブルシューティングの⼿法   トリアージ •  問題の持つインパクトを判断 •  インパクトに応じて何をすべきかはっきりさせる •  根本原因の追究を急ぐのではなく、まずはサービスの継続⽅法を模索する   観察と検証 •  ダッシュボードを⽤いてメトリクスとログの確認 •  経験が少ない場合、関係のない症状を⾒たりメトリクスの意味を取り違えたりする場合がある
34. 34 オンコールと緊急対応②   トラブルシューティングの⼿法   診断 •  システム構成や本来の動作、障害の発⽣パターンから仮説を⽴てる –  何が、どこで、なぜ –  最後の修正や更新を確認する •  単純化と削減 –  コンポーネント間の接続およびその情報を⾒て正しく動作しているか判断 –  既知のテストデータを与えてた悪しく動作するか確認 »  再現性のあるテストケースがあればデバッグが進む –  分割統治法 »  コンポーネントを順番に追いかける »  もしくはパスを2つに分けて追いかけてエラーの発⽣したパスを掘り進む •  あり得ない仮説を⽴てたり過去の原因に固執すると判断を誤る •  相関と因果を誤り間違った関係性を追求してしまう場合がある
35. 35 オンコールと緊急対応③   トラブルシューティングの⼿法   テストおよび対処 •  証拠を⾒つけ出して根本原因を特定する •  システムに⼿を加えて再度観察する –  システムに与える影響を考慮してテストを進める •  経験が少ない場合にシステムの⼊⼒や環境の変更⽅法を誤解する場合がある
36. 36 良いオンコール体制を築くためには？①   負荷の低減と均⼀化   量におけるバランス •  ローテーションを導⼊ •  PagerDutyなどのツールの活⽤   質におけるバランス •  緊急対応が発⽣した場合 その対応とポストモーテムの執筆に掛かる平均時間は約6時間 •  ソフトウェア等の品質向上によって緊急対応の頻度を下げる   過負荷の防⽌ •  チケット数などを⽤いた負荷の計測 •  アラートルールの⾒直し •  負荷が低すぎるのも問題（！）   補償
37. 37 良いオンコール体制を築くためには？②   継続的改善   前⽇に送られたアラートに⽬を通して、 アラートの出し⽅を改善/削除できないか検討する、など   場当たり的な対応を減らす   監視⾃体はシステムを何も修復してくれない •  システムを修復するのは⼈間 •  システム⾃体の回復⼒を⾼める   ストレスを軽減することで理性かつ集中を保った対処を実現する •  エスカレーションパスの⽤意 •  インシデントの管理規定を準備 •  ⾮難を伴わないポストモーテム⽂化
38. インシデント管理
39. 39 インシデント管理プロセス① 1.  インシデントの認識 2.  インシデントのロギング   ライブインシデントドキュメントの作成 3.  チケットの発⾏ 4.  インシデントの分類 5.  インシデントの優先順位付け 1.  事態の深刻化を避ける 2.  サービスを復旧させる 3.  根本原因を追究する
40. 40 インシデント管理プロセス② 6.  初期診断 7.  エスカレーション   責任の再帰的な分離 •  ⾃分の役割を認識して他の誰かの領域に踏み込まない   はっきりとした引継ぎ 8.  インシデントの解決   ⾃⼰観察 •  ⾃分の感情の状態に注意を払う 9.  インシデントのクローズ
41. 41 インシデントの定義と発⽣時の役割分担   インシデントの定義の例   別のチームに関わってもらう必要がある   サービス障害がユーザに影響している   集中して分析を1時間⾏っても解決していない   インシデント発⽣時の役割分担   1⼈が2つ以上の役割を担当しない •  現場指揮官 –  エンジニアが望ましい •  記録係 •  対外連絡調整係 –  マネージャーや役職者が望ましい •  SME（Subject Matter Expert） –  実際のインシデントに対応する⼈
42. 監視項⽬の例
43. 43 監視項⽬の例① ߲໨ ίϚϯυ΍ϩάͷྫ ϝτϦΫεͷྫ CPU top Memory free MemAvaliable εϫοϓ਺ /var/log/messages OOMKiller Network τϥϑΟοΫྔ Τϥʔ υϩοϓ਺ Disk iostat iowait await util IOPS Τϥʔ Load Avarage procs ϩʔυΞϕϨʔδ   OSの標準的メトリクス ߲໨ ϝτϦΫεͷྫ SSLূ໌ॻ Web Server Load Balancer ඵؒϦΫΤετ ਺ Ϩεϙϯείʔ υ ϦΫΤετ࣌ؒ Database ඵؒΫΤϦ਺ εϩʔΫΤϦ ϨϓϦΧͷڍಈ IOPS Message Que Amazon SQS Ωϡʔͷ௕͞ ফඅ཰ Cache Elasticache Ωϟογϡ͔Β ௥͍ग़͞Εͨ ΞΠςϜ਺ ώοτ/ϛε཰   その他 ߲໨ ϝτϦΫεͷྫ DNS κʔϯసૹ ඵؒΫΤϦ਺ NTP time drift DHCP Ϧʔε਺ SMTP ֎޲͚ ϝοηʔδΩϡ ʔ ϝʔϧ૯਺ ड৴ശͷαΠζ
44. 44 監視項⽬の例②   ネットワーク監視   SNMPはつらい •  セキュリティ上の問題 •  ポーリングであるためスケールアウトが難しい   でもネットワーク機器のほとんどがSNMPが標準 •  監視項⽬の例 –  インタフェース »  帯域幅 »  スループット »  レイテンシ »  エラー（送受信, ドロップ, CRC, オーバラン, キャリア, リセット, コリジョン） –  ログ »  トランクポートへの変更 »  リンクアグリゲーションの設定変更