「入門監視」を読んでみて

背景

近々、監視の見直しを行う必要がありそうなのと、弊社の現状の監視はこの書籍を参考に設計されているとのことだったので、体系的に学ぶために読みました。
本記事は書籍のアウトプット、感想になります。

メモ

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

監視の設計は、「システムが動いている状態」の定義から。
ツールやプラクティスなどに沿って設計するのではなく、本来は扱うシステムによって監視すべき項目は変わってくるということ。
監視には顕在化していない段階でシステムの不調を知れることを求めたいので、単に障害通知用に外形監視を入れるだけでは不十分。(直近で社内でヒヤリハットがあった)

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

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

監視用コンポーネントを疎結合させて監視プラットフォーム化したほうが良い。アーキテクチャが複雑になるものの、不要になったツールだけ削除して他に置き換えられるのはメリット。
「良い設計は悪い設計より変更しやすい」(達人プログラマー)

-監視用コンポーネント一覧-
①データ収集
コンポーネントを設計するときには、以下の要素がある。
データ収集方法(プッシュ/プル)
メトリクスの種類(カウンタ/ゲージ)
ログの種類(構造化/非構造化)

②データストレージ
データタイプや収集データの用途によって保存方法を決める。
ex)時系列データは時系列DB(TSDB)
ログ活用ならElasticsearchなど
データの使用用途から考えて、データを間引けるなら間引いてしまっていい。

③可視化
ダッシュボードは理想を言えば、1サービスor1プロダクトのステータス表示に焦点を絞るのが良い。
可視化方法は折れ線や棒グラフが多そう、このあたりも用途から逆算して考える。

④分析とレポート
SLAを設定している場合など、レポートとして対外的に公開できる状態にしておきたい場合に実装する。

⑤アラート
アラートは必ずしも問題が起きたときに出すものではない。
アラートを契機にシステムを見直すためにある。
そのため、収集しているメトリクスやグラフはアラートと1対1対応している必要はない。
(アラートにしないが、収集しておくメトリクスもあるということ)

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

ユーザ視点を優先した可視化は大切。
シンプルな実装方法はHTTPレスポンスコードを使用する方法。
次点でリクエスト時間を取ることも有益。
ユーザがアプリケーションとやり取りする部分から監視を始めて、Webサーバ→DBへの監視も順次設計していくのが現実的なやり方。

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

自社の監視プラットフォームを作るタイミングは、監視系SaaSで監視の仕組みを成熟させつつ、追加で監視すべき項目を整理できたタイミング。
監視を始めるところからいきなり自社の監視プラットフォームの構築にジャンプすると大抵失敗する。

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

監視とは、あるシステムやそのシステムのコンポーネントの振る舞いや出力を観察しチェックし続ける行為である。→アラート発砲が目的ではない。

-良いアラートを作る6か条-
①アラートにメールを使うのをやめよう。
②手順書を書こう。
③固定の閾値を決めることだけが方法ではない。
→本当に知りたい情報を整理できていればそれを拾えるようにおのずと設計できるはず。それは固定の閾値を決める方法だけでは拾えないこともある。
④アラートを削除し、チューニングしよう。
→ノイズになっているアラートはないか日々チェック。
⑤メンテナンス期間を使おう。
→リリース時に発生してしまうようなアラートは事前にメンテナンス状態にしておくといい。
⑥まずは自動復旧を試そう。

-オンコール対応(ITILのプロセスをシンプルにしたもの)-
①インシデントの認識(監視が問題を認識)
②インシデントの記録(インシデントに対して監視の仕組みが自動でチケットを作成)
③インシデントの診断、分類、解決、クローズ
④必要に応じて問題発生中にコミュニケーションをとる
⑤インシデント解決後、回復力を高めるための改善策を考える(ポストモーテム)

4章　統計入門

データを残しておけば、統計を取って問題の発見に役立てられるのでメトリクスは捨てないこと。

-統計データ参照時の値の選定-
①移動平均
スパイクを無視したい場合に有効。
正確性を損ねることがある。(スパイクを平準化するため)
②中央値
平均が対象を正確に表さない時に効果的。データセットの中央の値を表す。
一方向に大きな偏りのあるデータを扱う場合は中央値の方がデータの特性をよく理解してから参照すること。
③周期性
データポイントがパターンを繰り返すこと。
未来の計画を立てたり予測したりするのに使うことになる。
④分位数
パーセンタイルで表されることが多い。
データの大部分がどうなっているかを理解するのに便利。
※本来この方法は、極端なデータを無視するものであり、ある程度のデータポイントを捨てていることに注意。
⑤標準偏差
平均からどの程度離れているか、どの程度近いかを表現する方法。
※正規分布しているデータセットに対してのみ、期待するような結果がでる。

5章　ビジネスを監視する

ビジネスKPIは非常に重要なメトリクスであり、アプリケーションやインフラの調子やパフォーマンスを示す先行指標。

以降は、ツール系の話が多めなので、ほぼメモ。

6章　フロントエンド監視

フロントエンドのパフォーマンス監視のゴールは、動き続けることではなく、素早くロードされること。

-フロントエンド監視の2つのアプローチ-
①リアルタイムユーザ監視(RUM)
実際のユーザトラフィックを監視するもの。
実際のユーザーの挙動を理解し、サイトの最適化に活かす。
②Synthetic監視
偽のリクエストを送り、機能が正常に動いているか監視するもの。

-フロントエンドのパフォーマンスチューニング
Webアクセスからページが完全に読み込まれるまでの各フェーズ

Navigation Timing APIを使うことで、どのフェーズがボトルネックとなっているか確認できる。
※ただし、カテゴリがわかるだけなので、具体的にコンポーネントレベルまで原因を掘り下げるには別のツールが必要

画像の中で特に大切なメトリクス
①navigationStart
ブラウザによってページリクエストが開始されたタイミング
②domLoading
DOMがコンパイルされロードが始まったタイミング
③domInteractive
ページが使用可能になったと考えられるタイミング
※ただし、ページのロードが終わっているとは限らない。
domContentLoaded
全てのスクリプトが実行されたタイミング
domCoplete
ページが全て(HTML,CSS,JavaScript)のロードを終えたタイミング

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

アプリケーション自体のメトリクス取得はアプリ自体のパフォーマンスを確認する際に役立つので絶対にやっておくべき。
CI/CD実行履歴やhealthエンドポイント監視を組み合わせることで、より詳細にアプリケーションを理解でき、トラブルシューティング時にも役立つ。
※メトリクスはアプリの監視には適しているが、処理ごとの挙動など細かい部分までは確認できないので、ログ設計も同じように大切。
↑上記の理由から、アプリごとにメトリクス/ログどちらでとるか、両方でとるか、ログなら何をログにするべきかなど欲しい情報から逆算して設計する必要がある。

-ログをディスクに書くか、ネットワーク越しに外部に送るか-
①ディスクに書く場合
ログ転送はアプリのトラフィックが増えると面倒なボトルネックになりがちだが、ディスクに書き込めばその心配はない。一方で定期的にログローテーションしつつ、非同期で外部に送るなどしないとディスク容量を圧迫するので注意。
②ネットワーク越しに外部に送る場合
簡単に実装できるが、前述のボトルネックが発生しかねない。

※ディスク書き込み＆定期的に外部にデータを送るようにするのが良い。

マイクロサービス＆分散トレーシング
マイクロサービスになると、ノード間の通信が増え、ユーザリクエストに何が起きているのか理解するのが難しくなる。→分散トレーシングの出番
※分散トレーシングは実装が難しいので、本当に必要な場合にのみ使用すること。

-分散トレーシングの仕組み-
①システムに入ってくるリクエストに一意のリクエストIDをタグ付け。
②リクエストIDを元に、各リクエストがどのサービスにアクセスしたか、どれくらい時間がかかったかがわかる。
※トレーシングは個別のリクエストに焦点を当てている点が、メトリクスとの違い。

8章　サーバ監視

CWAで大体メトリクスはダッシュボード化してくれるとはいえ、この辺は知っておいた方がいいかも。

監視対象	ファイル	コマンド
CPU	/proc/stat	top
メモリ	/proc/meminfo	free
ネットワーク	/proc/net/dev	ifconfig/ip
ディスク	/proc/diskstats	iostat
ロードアベレージ	/proc/loadavg	uptime

以下は脳死で入れておくべき監視項目(クラウドならデフォでとられていそうなものが多め)

監視対象	監視項目
Webサーバ	秒間リクエスト数、HTTPステータスコード
DB	コネクション数、スロークエリ、IOPS
ロードバランサー	フロント、バックエンドのヘルスチェック
メッセージキュー	キューの長さ、消費率
キャッシュ	キャッシュから追い出されたアイテム数、キャッシュヒット率
ロギング	HTTPレスポンス、sudoの使用、SSHログイン、cronジョブ結果、スロークエリ

9章　ネットワーク監視

最近ほとんどオンプレを触る機会がないため、この章は必要な時に読み直す。

10章　セキュリティ監視

auditdはsyslogサブシステムに依存しないので、rsyslogが無効化されていても監査イベントを記録できるのがいいので使いましょうという話。
インスタンス内でユーザー認証の試行、失敗や特権ユーザレベルでの操作と実行ユーザーなどを記録できる。

ホスト型侵入検知システム(HIDS)
ホスト上で不正な行為が行われていないか。要はAWS Inspector
ネットワーク型侵入検知システム（NIDS）
ネットワーク自体に対する脅威を検知する仕組み。AWS GuardDutyの一部分

まとめ

本書を通して、監視にシルバーバレットはないということを学びました。
現実的にはプラクティスに沿って、監視を実装していくのがスタートになると思います。
サービスやシステム特性を踏まえた上で、そこから監視を昇華させられるかどうかがSREエンジニアとして必要なんだなと感じました。
信頼性もしくはシステムKPIを定めて、関連情報を特定する。
それを元に、信頼性を損なう予兆となるものを拾える監視状態を構築できればって感じなのでしょうか。