Closed5
「入門 監視」 読書メモ
aseiide- 第1章
- 監視のアンチパターン
- 1: ツール依存
- 監視とは単一の問題ではない
- 1つのツールで解決できる問題ではない
- 必要に応じて汎用的あるいは専門化されたツールが必要
- ツールの数は仕事ができる最低限の数にする
- 「一目で分かる」は迷信
- 2: 役割としての監視
- 監視は役割ではなくスキル
- 監視は他の仕組みから孤立した仕組みではなく、サービスのパフォーマンスのために重要
- オペレーションチームだけでなく全員が本番環境全体に責任を持つこと
- 3: チェックボックス監視
- 世の中には監視項目をエクセルでチェックボックスでチェックするものがあるらしい
- 「動いている」を正確に把握し、「動いている」かどうかを監視する
- 4: 監視を支えにする
- 監視とは、問題を通知することに長けているのであり、通知を受け取った次にするべき
- 5: 手動設定
- 監視は自動化すべき
- 手順書依存
- 手順書がやることの羅列なら、自動化のきっかけになるかもしれない
- 1: ツール依存
- 監視のアンチパターン
aseiide- 第2章
- 監視のデザインパターン
- 1: 組み合わせ可能な監視
- 専門家されたツールを複数使い、それらを疎に結合させて監視のプラットフォームをつくる
- 監視サービスの要素
- 一口に「監視」と言っても次の5つの要素がある
- データ収集
- メトリクス
- カウンタ
- ゲージ
- ログ
- 非構造化ログ
- 構造化ログ
- データ・ストレージ
- 可視化
- 分析とレポート
- アラート
- アラートは結果の1つの形でしかない
- メトリクス
- データ収集
- 一口に「監視」と言っても次の5つの要素がある
aseiide全部の章をメモして公開しようと思ったけど時間なくて無理だったので以降は印象に残った章だけ公開していく
aseiide- 3章 アラート、オンコール、インシデント管理
- 監視とは、あるシステムやシステムのコンポーネントの振る舞いや出力を観察しチェックし続ける行為である
- 良いアラートの仕組みを作る6つの方法
-
- アラートにメールを使うのをやめよう
- すぐに応答かアクションが必要なアラートはSMS, pagerDutyなどのページャに送る
- 注意が必要だがすぐにアクションは必要ないアラートはチャットに送る
- 履歴や診断のために保存しておくアラートはログファイルに送る
-
- 手順書を書こう
- 手順書は、何らかの問題を解決するのに、人間の判断と診断が必要なときのためのもの
-
- 固定の閾値を決めることだけが方法ではない
- 固定の閾値(ディスク使用量90%超えたらアラートを出す)だけではなく、変化量やグラフの傾きなども考慮して柔軟に決める
-
- アラートを削除し、チューニングしよう
- うるさいアラートによって、人々は監視システムを信用しなくなり、さらにはすっかり無視してしまうようになる
- アラートの量をへらす方法
- すべてのアラートは誰かがアクションする必要がある状態か
- 1ヶ月のアラートの履歴を見てみましょう。どんなアラートがあるでしょうか。どんなアクションを取ったか。各アラートの影響はどうだったか。削除してしまえるアラートではないか。閾値を変更できないか。監視の内容をより正確にするようにデザインし直せないか
- アラートを完全に削除するためにどんな自動化の仕組みが作れるでしょうか
-
- メンテナンス期間を使おう
- メンテナンスに入るときはツール側でメンテナンス設定をしてアラートを止めるべき
-
- まずは自動復旧を試す
-
- オンコール
- 無用の場当たり的対応を減らす
- 監視自体は修復はしてくれないので日頃から安定性や回復力に取り組んだ開発をすべき
- 無用の場当たり的対応を減らす
aseiide- 8章 サーバ監視
- OSの標準的なメトリクス
- 標準的メトリクス: CPU, メモリ, ロードアベレージ, ネットワーク, ディスク
- これらは全く役に立たないわけではないが、使う場面は少ないのでアラートは設定しない
- 全システムで自動的に記録するようにしておく
- データベースサーバ
- 秒間クエリ数が直接サーバの忙しさを測る指標
- OSの標準的なメトリクス
このスクラップは2022/12/13にクローズされました