ばーろぐわにる

SIerからWEB系？インフラエンジニアにジョブチェンジした見習いの備忘録。投稿内容は私個人の意見であり、所属企業・部門見解を代表するものではありません。

「入門 監視」を読んだ

読書メモ 監視

なにこれ

こちらを読んだのでそのメモです。

www.oreilly.co.jp

メモ

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

  • ツールで監視を決めるな。やりたいことに合わせてツールを選び、組み合わせ、必要であれば作る
  • 監視はスキル。全員が一定水準を満たすべき
    • 誰かに責任を押し付けてはいけない
  • メトリクスは高頻度で投げる。最低でも1分に1回
  • 障害→監視の追加を繰り返すのはNG。何回か繰り返すようならアプリケーションを安定して動くように作り直すべき

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

  • できる限り構造化ログを使う
    • ログ量が少なかったり、複雑な解析を行わなければ非構造化でもよし
  • ダッシュボードはそのシステムを一番知ってる人に作らせる
  • メトリクスはアラートを出すために集めているわけではない。質問を投げかけるためにある
    • エモい
  • 使えるならSaaS使おう

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

  • 通知方法
    • 即時対応が必要→SMSなどのページャ
    • 注意が必要→チャット
  • アラートレポートで改善点を見つけ出す
  • オンコール
    • バックアップ担当は作らないほうがいい。2倍のシフト数になる
    • オンコール担当は責任を負う。何回も対応できないなら問題あり
  • インシデント管理プロセスは作っておこう

4章 統計入門

  • 中央値はサンプリングしたデータの真ん中の値
    • (n+1)/2 番目の値
  • パーセンタイル
    • データを昇順にならべて小さい方から数えて任意の位置に存在する値
    • 90パーセンタイル → 小さい順から並べて90番目のデータ
  • 標準偏差
    • 正規分布なデータにしか適用できない。監視では使えないことが多い

5章 ビジネスを監視する

  • ビジネスKPIはアプリケーション、インフラの調子をも示してくれる
  • KPIを全員がすぐに目が届くところに表示しておく
  • 成功よりも失敗のメトリクスを追う。Goal(サービスが満たすべき目標)に直結するので
  • 何をKPIにすべきかは人と話して決める
    • プロダクトオーナー、エンジニアリングマネージャ、シニアエンジニア

6章 フロントエンド監視

  • フロントエンドのパフォーマンス監視のゴールは動き続けることではなく、素早くロードされること
  • フロントエンドのパフォーマンス改善はビジネスに大きなインパクトを与える
    • 特にロード時間。業績に影響を与えた実績あり
    • ロード時間は4秒以下を目指せ
  • JavaScriptの仕組みは理解しておこう(=監視対象の仕組みは理解しておこう)
    • <script> はDOMのパースを中断してスクリプトのダウンロードをおこなう。故にスクリプト数を増やせば増やすほどロードに時間がかかる。
    • HTML5でasync属性が追加、バックグラウンドでスクリプトをダウンロードできるようになった。
  • Navigation Timing API
    • ブラウザが提供するAPI。ここを通じてページパフォーマンスのメトリクスを公開
    • 各処理の開始、終了時間をメトリクスとして提供
  • ログ収集はSaaSを使おう
    • Sentryとか
  • シンセティック監視
    • 外部監視的なやつ。外からcurl叩くイメージ
    • CIでロード時間を定期的に計測

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

  • APMはビジネスコンテキストまでは理解してくれてない。当然だけど。
  • ビルド、デプロイの監視
    • デプロイ後、エラー率が高まってないかの相関を調べれる
  • healthエンドポイントパターン
    • ヘルスチェック用のエンドポイントを作る
    • 依存性があるリソース(DB, Cache, 外部エンドポイント)があれば、その接続まで含めてヘルスチェックしたほうがよい
      • ただし、リソースにかかる負荷が大きくなるので要検討
  • アプリケーションロギング
    • 構造化ログを使おう
    • ログにするかメトリクスにするかはユースケース次第。チームで相談しよう
  • ログレベルの問題点
    • ログレベルはアプリケーションを作るときに決まる。また、全て正常に動いている前提で重要度が振られる
      • ある問題が発生した場合、DEBUGレベルの情報が必要な場合でもデフォルトがINFOで取得してたら情報を失う
      • インフラの構成によってはそれはERRORなのか？というものも出てくる
      • 例えばリトライ処理もできている場合、接続失敗はERRORとして出すか？
  • ログはディスクに書き込み、その後ネットワーク越しに送るが良い
    • ログ送信が非同期になるから
  • 分散トレーシング
    • マイクロサービスなど1リクエストが複数のサービスにまたがって処理される場合に有用
    • リクエストに一意なIDを付与、そのIDをつけて回ることでリクエストを追跡して監視、各サービスでどれぐらい時間がかかったかを計測できる

8章 サーバ監視

  • OS標準(CPU, MEM, DISK)のメトリクスは取得するが、アラートは設定しないのがおすすめ
  • メモリ
    • /proc/meminfo
      • Buffers
      • Cached
        • 最近アクセスされたファイルのコンテンツのキャッシュ
      • MemAvairable
        • 利用可能なメモリ領域
    • OOM Killer
      • システムログを killed process でgrepすれば発見できる
      • OOM Killerが発生したらアラートを投げる仕組みを作っておいたほうがよい
  • ディスク
    • /proc/diskstats から情報を取得してることが多い
    • iostat -x
      • iowaitが高くなってないか
      • utilが100%になってないか
  • ロードアベレージ
    • CPUに処理してもらうのを待っているプロセスがいくつあるか
    • システムによっては高くても動くものはあるので一概に高いと良くないとは言えない
  • SNMP
    • サーバ監視で使うのはやめたほうがよい
  • WEBサーバ
    • 秒間リクエスト数
    • 5XX、4XXの数
  • データベースサーバ
    • コネクション数
      • MySQLでは=スレッド数
    • 秒間クエリ数
  • ロードバランサ
    • WEBサーバと同じ
  • キュー
    • キューの長さ
    • キューの消費率
  • キャッシュ
    • キャッシュから追い出されたアイテム数
    • ヒット、ミス比率
  • NTP
    • ntpstatコマンドの終了コードで監視するのがおすすめ
  • スケジュールジョブの監視

9章 ネットワーク監視

  • 現状すぐに利用することはなさそうなので読み飛ばした

10章 セキュリティ監視

11章 監視アセスメントの実行

  • 監視アセスメントのデモだったので省略

感想

書かれていることが普段の監視でやっていること大きなズレが無くて安心しました。サーバ監視の章は具体的なコマンド、実装例が書かれていて参考になりました。また監視を構築する上でコミュニケーションはとても大切で、それが今足りてないかもなという気づきもあり読んでよかったです。