入門 監視
https://gyazo.com/e6fe670dc882315a38aa4a0650157830
アンチパターン
アンチパターン: チェックボックス監視
形骸化し、やっているだけの監視になる
システム負荷、CPU使用量、メモリ使用量のメトリクスは記録しているもののシステムダウンの理由はわからない。
誤検知が多すぎるのでアラートを常に無視する。
各メトリクスを5分以上の間隔で監視している。
メトリクスの履歴を保存していない
動いているとはどういう意味か。動いているかどうかを監視する
例: GET / で 200 が返ってくるか
アラートに関してはOSのメトリクスはあまり意味がない
プロセスが継続的にCPUを全部使い切ったとしていても、やることを正確に実行できている(いわゆる「動いている」)のであれば問題はない。
アンチパターン: 監視を支えにする
監視に寄りかかってはいけない。監視は問題を通知だけであり、問題の改修を忘れてはいけない。監視をどんどん追加している状況に気づいたら、回復力のあるシステムにすることが先決である。
アンチパターン: 手動設定
監視設定は100%自動化するべき。各サービスは勝手に登録されるようにする。監視に時間がかかるようであればだれも監視を登録しなくなってしまう。
デザインパターン
ユーザー視点での監視
まずはユーザーに近いところから監視をする。ユーザー視点を優先した可視化が必要
HTTPステータスコード、レイテンシ
継続的改善
常に改善し続けることが必要
アプリケーション監視
APM
スロークエリ
外部ベンダのAPIが応答するのにかかった時間
ビルド、リリースのパイプラインの監視
メタ情報
APIのエラー率とデプロイイベントを重ねる
トラブルシューティングに役立つ
health エンドポイントパターン
フロントエンド監視
フロントエンドのパフォーマンス監視のゴールは動き続けることではなく素早くロードされること
実際にユーザーが見ているページのロード時間を監視しましょう
サーバー監視
おすすめはすべて記録を撮っておくが、アラートの設定はしないでおく
CPU
cpuを使い切っている場合はプロセスを落とす。
メモリ
OOMKillerの呼び出しを監視することも有効
ネットワーク
アウトオクテット数、エラー数、ドロップ数を収集する
ディスク
IOPSを監視
SSL証明書
期限切れにならないように監視する
webサーバー
rps
ステータスコード
レイテンシ
dbサーバー
まずはコネクション数
スロークエリ
QPS
キャッシュ
追い出されたアイテム数
ヒット率
IOPS
オンコール
各アラートには手順書のリンクをいれる
手順書がコピペで終わる場合は自動化してアラートを削除する
アラートを削除し、チューニングしよう
アラートが多いと関しを信用しなくなり、無視するようになる
すべてのアラートは誰がアクションをする必要がある常態化?
1ヶ月のアラート履歴を振り返る
影響はどうだったか
削除できるもの、閾値を変更できるものはないか、より正確にできないか
削除するためにどんな自動化の仕組みが作れるか
監視自体は何も修復してくれないので、根本解決を行う
オンコールローテーション
多くても1人につき1ヶ月に1週間
インシデントが発生したあとは、インシデントに関する議論の場を常に設ける。再発防止のためにどう対応していくか議論しましょう
人を非難しないこと
ebiken.icon適切なアラートとは
信頼性を極度に上げるには高いコストがかかってしまう
https://gyazo.com/e7c6c0bcd3184d2905394cf2b7e8d885