lasciva blog

開発して得た知見やwebビジネスのストック

「入門 監視」を読んだ

入門 監視 ―モダンなモニタリングのためのデザインパターン

入門 監視 ―モダンなモニタリングのためのデザインパターン

読んだ目的、モチベーション

  • 所謂インフラの監視だけでなく、アプリケーションレイヤーの監視も対象にしていて面白そうだったため。
  • 監視はツール等は使ったりしてるが、そもそもどういう基準で原則的として監視すべきかなどの見識がなく、それを補うため。

全体の感想

  • ユーザ的な観点で動いているかどうかという原点に立って、何を監視すべきか判断するという考えは面白かった。
    • そこから、ビジネスや事業、会社のコンプライアンスなどから何が必要なのかブレークダウンしていく感覚も全体感が掴めてよかった。
    • ただし、個々の細かい個別のところまでは流石に行き届いてなかった(本書の目的外でもある)。
  • 監視ツールに関してそこまで興味がなかったが、nagiosがここまでオワコンのような扱いを受けてるとは思わなかった。
  • マイクロサービスはサービス全体としての健全性の監視も難しそうだなという印象を受けた。
  • 導入してみたいと思ったのもあった。
    • フロントエンドのパフォーマンス監視のための、WebpageTestのAPIをCIへ組み込み
    • アプリケーションのhealthエンドポイントでjsonを返して監視

目次

内容

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

  • ツールでも銀の弾丸はなく、専門性に応じて複数のツールを導入すべき。
    • 種類が多くても、出来ることが異なるなら導入すべき
  • 成功している企業が導入しているツールを導入したからといって、成功する訳ではない。
    • どのような規模や文化で運用されていて、なぜ導入されたかの理解が重要。
  • Prometheus - Monitoring system & time series databasegoogle社内の監視ツールのBorgmonにインスパイアされたオープンソース
  • メトリクスをもっと高頻度で取得しよう
    • 最低1分間隔で取得しないと、見逃すので意味ない
  • 手動設定はアンチパターン
    • 自動化しないと、ノード増やしたりしたときに対応しなくなり、役に立たないものになりスケールできない。

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

監視サービスのコンポーネント

  • データ収集
    • pull型とpush型に分類できて、多くはpush型の方がスケーラブル
      • pull型: 中央サービスがスケジュール監視して、リモートノードに対してノードの情報を送るように要求
      • push型: syslogなどで、クライアントが定期的にpush
        • サーバが増えても、処理等をログ管理サーバ側にまとめやすい。
      • ログ形式はJSONなどで構造化すると使いやすい
  • データストレージ
    • ログを全部保存するかどうかは、データ量と読み出しに時間がかかるのと、正確性のトレードオフ
      • 直近のデータは全部で、ある程度経過したら間引いて保存するなど使い分ける
    • データを構造化して検索エンジンで保存すると活用しやすい
  • 可視化
  • デザインパターン2:ユーザ視点での監視
    • OSの標準的なメトリクスを計測するだけでは、役に立たないので、実際に動いてるかどうかを監視すべき。
  • デザインパターン3:作るのではなく買う
    • メガ大企業でない限り、外部サービスを使った方がコストを抑えられる。
    • 性能もSaasの方が上になる。
  • デザインパターン4:継続的改善
    • 作ったら終わりではなく、運用やサービスの成長、社内環境の変化に応じて進化させていくこと。

3章 アラート、オンコール、インシデント管理

どうしたらアラートをよくできるか

  1. アラートにメールを使うのをやめよう
    • 量が多いとアラート疲れを起こすので、レベルに応じて分ける
      • SMS, PageDuty
      • チャット
      • ログ
  2. 手順書を書こう
    • やり方が自明でコピペするような内容であれば、アラートを飛ばさず自動化すべき
  3. 固定の閾値を決めることだけが方法ではない
    • 統計的な値を使って、的確にアラートを出す
  4. アラートを削除し、チューニングしよう
  5. メンテナンス期間を使おう
  6. まずは自動復旧を試そう

オンコール

  • オンコール担当者が不要なアラートを減らすorシステムを修復して、発生数を減らしていく。
  • ローテンション制にする
  • 必ず振り返りを行う

4章 統計入門

  • 取りたい異常値の種類に応じて、平均値や中央値などを使い分けようという話だった。
  • 安易に平均値を使ったりすると、検出すべき特異値が検出できないなど。

5章 ビジネスを監視する

  • 事業的に重要な数字やKPI等を視覚化して、健全性を見ること。
    • 売上
    • ユーザ数
    • (投稿サービスにおける)コメント数など

6章 フロントエンド監視

フロントエンドの監視はされないことが多いが、ビジネスに直結するため監視すべき。

  1. 成果例
  2. DOM
    • 基本的にはツールを導入することになる。
    • Navigation Timing API
      • ブラウザのAPIを通じて監視
      • navigationStart: ブラウザによってページリクエストが開始されたタイミング
      • domLoading: DOMがコンパイルされロードが始まったタイミング
      • domInteractive: ページが使用可能になったと考えられるタイミング(正確とは限らない)
      • domContentLoaded: すべてのスクリプトが実行されたタイミング
      • domComplete: ページがすべてのロードを終えたタイミング
    • Speed Index
      • 詳細な情報は取れないが、ユーザから見た視覚的な観点でのロード時間を取れる。
      • sites.google.com
  3. ロギング
  4. Saasを使ってjsのエラーログを取るべき
  5. シンセティック監視
  6. プルリクエストごとにフロントエンドへの計測できる環境が望ましく、WebpageTestのAPIをCIに組み込むことで実現できる。

7章 アプリケーション監視

  1. メトリクスでアプリケーションを計測する
    • StatsDは気軽に導入できるのでオススメ
    • github.com
  2. ビルドとリリースのパイプラインの監視
    • デプロイの日時・担当者を記録しておくと、他のメトリクスと重ね合わせて調査しやすくなる。
  3. healthエンドポイントパターン
    • /healthというエンドポイントを用意して、アプリケーション側で正常か否かチェックしてJSON等でレスポンスを返してチェックすること。
    • 特にマクロサービス化を導入していると、サービス全体の状態が把握しやすい。
  4. マイクロサービスアーキテクチャを監視する
    • 分散トレーシング
      • システムに入ってくるリクエストにIDを付与して、各々のサービスでどれぐらい処理に時間がかかるかを測定する。
      • zipkin.io

8章 サーバ監視

  1. OSの標準的なメトリクス
    • ロードアベレージ
      • 代理指標にはなり得るが、高くてもサービスは動くケースは多々あり、あまり当てにならない。
  2. SSL証明書の有効期限
  3. SNMP
  4. データベースサーバ
  5. スケジュールジョブの監視
    • sh run-backup.sh 2>1& backup.log || echo "Job failed" > backup.log
    • 解決策の一つは デッドマン装置
  6. ロギング
    • 段階に応じて対応する。
      1. 収集
      2. 保存
        • syslogで突っ込むだけでは使われないので、適切なサービスを使って保存する。
      3. 分析

9章 ネットワーク監視

  1. SNMPのつらさ
    • 唯一の手段だが、レガシーでかなり辛いらしい(私は使ったことないので想像つかない)。
      • 知人が殺されたのかっていうぐらい批判的に記述されてた。
  2. 構成管理
  3. 音声と映像
    • レイテンシ、ジッタ、パケットロスを計測するのが基本中の基本。

10章 セキュリティ監視

詳しく深掘りたいなら、この本がオススメと記載されていた。

The Practice of Network Security Monitoring: Understanding Incident Detection and Response

The Practice of Network Security Monitoring: Understanding Incident Detection and Response

  1. ユーザ、コマンド、ファイルシステムの監査
    • auditdはLinuxカーネルへの直接のフックを使い、他のサブシステムに依存せず動作するインタフェース。
    • audisp-remoteを使って、リモートのsyslogに送信
      • ローカル保存だと、改竄される可能性があるため。
      • rsyslogを使うのはrsyslogを無効化された際にセキュリティ的にリスクがあるので、分けたほうが良いため。
  2. rkhunter
  3. ネットワーク侵入検知システム(NIDS)

入門 監視 ―モダンなモニタリングのためのデザインパターン

入門 監視 ―モダンなモニタリングのためのデザインパターン