Zenn
Closed8

入門監視・読書感想scrap

プラハの社長プラハの社長

1章

  • アンチパターンの定義は「一見良いアイデアに見えて」実は悪いアイデア
  • 監視は役割ではなくスキル。役割とスキルを区別することは他のことにも応用できそう
  • メトリクス設定の基準：その監視項目は誰かを叩き起こすに値するか

2章

監視に必要な5つの要素

  • データ収集
  • データ保存
  • 可視化
    • grafana, smashing
    • the visual display of quantitative information
    • information dashboard design
  • 分析とレポート
    • 2分間のダウンタイムを計測するには1分感覚でデータ収集が必要
    • EC2のSLAは1リージョンで99.95%（スリーナイン）
      • 説明するときの基準としてちょうど良さそう
      • 「S3は可用性がすごい」って言われがちだけどフォーナイン。すごいのは耐久性
  • アラート

監視は組み合わせ可能な状態にしておく

  • 実際に対応する人、管理している人にとって行動に移しやすいことが大事
  • そのためにはカスタマイズしやすいことが大事
  • オールインワンで使用をパーフェクトに満たすツールより疎結合なツールが良い
    • ゴリゴリGUI充実しているツールよりAPI公開しているツールの方が良い、みたいな判断基準だろうか

ユーザー視点から監視を考える

  • ユーザーはCPU使用率を気にしない
  • まずはHTTPレスポンスステータスみたいにユーザーに直結するところから考え始める
  • 中間メトリクスを追加する際は「これはユーザにどんな影響を与えるのか」の視点を忘れない
プラハの社長プラハの社長
  • 例としてログイン成功イベントだけを追うより成功と失敗イベントを分けて追った方が良い
    • 失敗数の方がアラート（とその対応）に直結するため
    • 成功が少ないのは失敗が多いからなのか、単に試行回数が少ないからなのか、区別がつかないから？
  • 特定の閾値を決めるより傾斜を見た方が役立つことが多い
    • CPU使用率99%よりCPU使用率が5分間でX%上昇、とか
  • 手順書が単純なコマンドの列挙になってきたら自動化するサイン
  • レイテンシは取ってないことが多いので今後気をつけよう
プラハの社長プラハの社長

フロントエンドの監視

load

  • 全てのリソースがメモリ上に展開された状態

dom content loaded

  • DOMのロードが完了した状態。全てのリソースがロードしているわけではない
  • domさえあればよければこの辺で操作を始めて良さそう
  • 「めっちゃサブリソース多いからdom content loadedが遅い」って言われたらダウト
  • scriptは実行を待つ必要がある（DOMを操作しかねないから）のでdclに影響しそう
  • この辺の詳しい説明
    https://www.html5rocks.com/tutorials/internals/howbrowserswork/

interactive

webpagetest apiでテスト環境をモニタリング
https://azu.github.io/slide/2018/roppongijs/webpagetest-performance.html

プラハの社長プラハの社長

アプリケーションの監視

  • メトリクス見るのも大事だけどクリティカルパスのメトリクスは重要度がより高かったりするし、ドメイン知識は開発者（運用者？）が把握しておかなきゃダメ
  • statsd,graphite,opentsdb,influxdb
  • ヘルスチェックエンドポイントで依存モジュールのステータスまで返してる
    • 必要なのかな？各モジュールがSaaSのように提供されている最近は重要性が下がっている気もする
    • httpステータスだけ見てるとさほど重要ではない一部が壊れた時に過剰なエラー対応になりそうだから200だけどエラーメッセージ含む、みたいなパターンも考えられそう
    • エンドポイントが1つだと要件（レスポンスタイムとか）も依存モジュールに対して統一されてしまうから、重要度に応じて異なるエンドポイントを作るのも有効かもしれない
    • それかエンドポイントは1つだけどパラメーターに応じて検査項目が変わるとか
  • 都度ログをネットワーク越しに送信しているとコネクションコストがかかるので一度ファイルに退避させてまとめて送るような仕組みになっているSaaSも多い
  • プッシュ型とプル型のメリデメとしてcloud functionsみたいなエフェメラルな実行環境だとポーリングの周期が長すぎてデータが取れないことも挙げられそう
プラハの社長プラハの社長

サーバの監視

  • 基本的にOS関連のメトリクスに悩んだら/proc配下をみよう
  • cpuメトリクス
    • cpu使用率はuser,sys,ni,hi,siを足し合わせてください→実際どういう分子と分母で計算するんだろう
      • 分子：全てのプロセスがCPUを利用した時間（秒数とクロック数どちらが一般的なんだろ）
      • 分母：経過した時間
      • 「プロセスがCPUを利用した時間」には正確にはメモリI/Oの待ち時間が含まれているため、CPUを利用しているからといって実際にプロセスが進んでいることを保証するわけではない
      • iowaitとここでいうメモリI/Oは別物なので注意が必要
    • steal時間→仮想CPUが待機させられている時間。物理CPUをそのまま使っていたら0で良いのかな
  • メモリ
    • free,used,shared,cached,buffers
      • bufferとcacheの違い→保存するのがディレクトリ構造や権限などのメタデータか、ファイルコンテンツそのものか
    • swap
      • 最近のクラウドインフラではスワップパーティションが切られていることは少ないと記載されているが、なぜだろか。インスタンス変更して対応できるからあえて遅いスワップは不要だよね、って発想なんだろか
    • oomkillerの呼び出し
      • systemlogをkilled processでgrepすれば出せる
  • ロードアベレージ
    • 1,5,15分間のCPU処理待ちプロセス数
      • 1分間のプロセス数が15分間のプロセス数より多ければロードが増えていることがわかる（逆も）
    • uptime
    • ロードアベレージが高くても問題ないサーバーは多いそうだが、なぜだろうか
      • あくまで1分間の平均だから瞬間的に高くて落ち着いたなら問題なさそう
    • 他にこういう指標も良さそう
      • per-CPU utilization: eg, using mpstat -P ALL 1
      • per-process CPU utilization: eg, top, pidstat 1, etc.
      • per-thread run queue (scheduler) latency: eg, in /proc/PID/schedstats, delaystats, perf sched
      • CPU run queue latency: eg, in /proc/schedstat, perf sched, my runqlat bcc tool.
      • CPU run queue length: eg, using vmstat 1 and the 'r' column, or my runqlen bcc tool.

証明書監視

  • ワイルドカード証明書の場合は、使われている場所ではなく証明書自体のチェックなので特に問題です、って書いてあるけどなんでだろう？
    • 設定ミスによって正しく証明書が使われていないときに気づけないとか？
    • ブラウザによって失効した証明書の扱いが若干異なるため、証明書自体をチェックしても結果が異なる可能性があるから？
  • statuscake, pingdom,collectd,telegraf,diamond

DB監視

キュー

  • 長さと、処理されたメッセージの比率（消費率）を見ておくと良い

キャッシュ

  • 大事なのはヒット率とevicted items（退避数？)
  • 「モダンアプリケーションでキャッシュヒット率１００％は現実的ではありません」は何故か
    • どこのキャッシュの話をしているんだろう
    • 動的情報のやりとりが多すぎてキャッシュできない？
    • 扱うデータ量が多すぎて全てキャッシュしようとすると容量が足りない？

NTP

  • 分散システムにおいてはタイムドリフトは深刻な影響を及ぼす
    • 分散システムに限らずDNSとかいろんなサイトに影響が及んだ)
    • CPUに激しい負荷がかかる処理はタイムドリフトを引き起こしやすい...らしい
    • 「現在時刻より先になることはないだろ」って思い込みでコードを書くのは注意が必要
    • 数字型を厳密に定義する言語だと符号の影響でオーバーフローすることも（こういう時TSは便利だな）
    • だし時刻はデバッグしづらいからこそ色んなところで無邪気に現在時刻を取得するのは避けたいと再認識した

ログ

  • syslog: プロトコル
  • syslogサーバに送るなとのこと（grepするしかなくて使い勝手が悪いからだろうか）
    • 実際どこまで今でもsyslog使われてるんだろう？
    • 一応Logstashのinput pluginとして用意されているけど
    • コンテナが流行ってきたことで最注目されているそうな。サイドカーパターンの一種としてログ収集をサイドコンテナに任せる感じ
プラハの社長プラハの社長

セキュリティ

  • auditd
    • macosの場合はrootのみアクセス可能なvar/audit配下に入っている
    • sudo -sでrootに切り替えて一覧表示したらクラッシュレポートとか保存されていた
    • /etc/audit配下に格納されているconfファイルにルールを記述すれば特定ファイルの監視を追加できる
    • syslogとあえて分けられているのはセキュリティの観点からsyslogサブシステムには依存させたくないから？
    • この文脈でよく出てくる「facility」はログを飛ばしたプロセスを指している(userも含まれる)
    • audit監視系saasも基本的にはこのあたりに格納されているログを読み込んでいると考えると少しイメージが湧きやすくなる
  • HIDS
    • ホストに侵入されたことを検知する
    • ルートキット、rkhunter、ファイルハッシュ比較
  • NIDS
    • ネットワークタップ
    • ネットワークが狭まっている箇所に設置する
    • fail-open（故障してもカプラとして動作し続ける）
プラハの社長プラハの社長

監視アセスメント（おさらい）

題材アプリケーションの何を監視するか

  • 全体
    • 各モジュールのヘルスチェック
  • CDN
    • キャッシュヒット率
  • フロントエンド
    • クラッシュレポート（サーバに届かないエラーを検知する）
    • RUM（first contentful paint, dom interactiveなど）
  • webサーバ
    • リクエストの成功（http200番台）比率
    • レスポンスにかかる時間
    • アプリケーション固有メトリクス
      • 検索（成功回数+失敗回数）（アプリケーションエラーのヒント）
      • 評価（成功回数+失敗回数）（アプリケーションエラーのヒント）
  • セッションストレージ（redis）
    • キャッシュヒット率（キャッシュすべき対象を見直すヒント）
    • キャッシュから追い出される量（容量を増やすヒント）
  • DB
    • レスポンスにかかる時間（スロークエリのヒント）

synthetic analytics

  • lighthouseとか
プラハの社長プラハの社長

付録

  • 監視とは継続的なテストである
  • ヘルスチェックに対するレスポンスの標準仕様を提案している
    • httpステータスで返さないのはそもそもhealthエンドポイントに届いていないことと区別できないからかな
  • openmetricsも案のひとつ
  • healthはステートレスに保つべし
    • 前回の問い合わせからの差分などはクライアント側の集計に任せる方がシンプル
    • 生のデータを返し、解釈は任せる
  • observability
    • メトリクス、トレース、ログ
    • 何が起きているのかをメトリクスでしり、トレースでどこで起きているのか断定して、ログで原因を探る
    • 読んだけどいまいちピンとこない
このスクラップは2022/04/12にクローズされました