1章 監視のアンチパターン

Topics

• ツール駆動の監視はツールの限界以上のことをしなくなるため、ミッション駆動の監視が重要
• 監視とは様々な問題が複雑に絡み合っているものなので、銀の弾丸は存在しない
• 公開されているうまくいったツールや手順を信用しない。その手順によって成功したのではなく、チームが成功した結果その手順ができた。
• 監視は役割ではなくスキルであり、チーム全員が本番環境に責任を持つ
• ヘルスチェックをしよう
• OSのメトリクスを意味なくアラート項目にしない
• メトリクスの取得頻度を上げる。古いデータは間引きする。
• 障害に対して監視項目を増やすことで対応するのではなく、根本原因を治す
• 監視設定は自動化する

よくわからなかったところ

監視の自動化とはどのようなことを言っていて何をするのかがわからなかった。
とりあえず続きを読んでみる。

2章 監視のデザインパターン

Topics

デザインパターン1 組み合わせ可能な監視

監視サービスの要素

1. データ収集
2. データストレージ
3. 可視化
4. 分析とレポート
5. アラート

1. データ収集

データ収集方法はプル型とプッシュ型が存在する。

• プル型：データ収集を行う中央サービスが、監視対象からデータを定期的に取ってくる。中央サービスが全ての監視対象を把握してスケジュールしないといけないためスケールしにくい。
• プッシュ型：クライアント側がデータを能動的に送る。クライアントはデータの送り先さえ知っていればいいのでスケールしやすい。

送信するデータにはメトリクスとログが存在する。

• メトリクス：増加する値を示すカウンタと、ある時点での値を示すゲージがある。
• ログ：ただの文字列である非構造化ログと、主にJSON形式の構造化ログがある。

2. データストレージ

• メトリクスは通常時系列データベースTSDBに保存される
• 古いデータは基本トレンドさえ追えればいいので間引きしていい
• ログは通常のファイルとして保存するか、検索エンジン(Elasticsearchなど)に保存するか

3. 可視化

• 円グラフは使うな
• ダッシュボードは1サービス、または1プロダクトにつき1つ
• サービスまたはプロダクトの運用者(よく理解している人)がダッシュボードを作成すべき

4. 分析とレポート

• SLAを定めている場合など、単なる可視化ではなくレポート作成が求められる場合がある
• サンプリング周波数の兼ね合いで、正確に稼働時間を測定できていない可能性がある
• 高レイヤの可用性は低レイヤの可用性を上回れない(サービスの可用性はAWSの可用性を上回れない)
• 100％の可用性は現実的ではない。99.99...の9ひとつ増やすコストはかなり大きい。

5. アラート

• 監視はアラートを鳴らすために存在しているのではない
• 監視項目、可視化項目は必ずしもアラートと1対1対応している必要はなく、情報収集のために監視してもいい

デザインパターン2 ユーザー視点での監視

• ユーザーに近いところから監視を始める(httpレスポンス5xxやレスポンス時間など)
• CPU使用率が上がっていてもユーザー影響がないならそれは問題ではない
• 低レイヤの監視ももちろん必要だが、ユーザーの何を教えてくれるメトリクスか常に意識する

デザインパターン3 作るのではなく買う

• 監視プラットフォームが成熟していない段階から自作すべきではない
• 自前で作るより安い
• 自社に監視ツール作成の専門家はおそらくいない
• プロダクト開発に集中できる
• SaaSを使えているうちはSaaSを使ったほうが良い監視ができる

デザインパターン4 継続的改善

ネットに散見される素晴らしい監視の仕組みは長い時間をかけて構築されたものであることを忘れない

よくわからなかったところ

• SNMP/Nagios
• ネットワークインターフェースの32ビットカウンタのくだり
• 稼働時間の計算について、内部の冗長なコンポーネントの可用性を無視して全体の可用性を計算すると良いとはどういうことか