読書メモ「入門監視」
以前から購入していて積読となっていた「入門監視」を読んだ。
オライリー本では珍しい分野の書籍で発売時には話題になったことを憶えている。以下、読書メモ。
「何をやるか」が本質で、ツールに焦点を当てすぎないこと。
zabbixを利用したいとか、SaaSの監視サービスを利用したいとかは、本質ではなくて、対象プロダクトに対して何を確認したいかを考える。まずは、エンドユーザ視点でサービスが継続的に利用できていることを確認することが重要になる。当たり前のことを記載しているがわりと重要。エンジニアが集まっていると、本質からそれるってのは良くある。経験談としては、バックアップ方式の議論をしていて、そもそもバックアップ対象が何か決まってないってことがあった。
システムにインストールするエージェントは良しとする。エージェントレスな監視は柔軟性に欠ける。
システムに対してエージェントをインストールするリスクは是とする。エージェントインストールについてリスクを議論するとキリがないので、実績のある監視ツールであれば、エージェントインストールは是として進める。
5分に1回しかメトリクスを取得しないでは、実質的には何も見ていないのと同様である。
メトリクスを頻繁に取得するとシステム負荷がかかるという人もいるが、モダンなサーバやネットワーク機器は高性能であるから、あまり気にする必要はない。一方で、取得したデータの保存はコスト増につながるので、メトリクスに応じたデータの間引き設定を行う。取得したデータを間引くナレッジは別途確認する必要がある。解析系のデータについても取得対象が多いが故、容量が大きくなってくる。ある程度の古いデータは間引いて平均化してデータ量を減らすことがバッチなどで実装できるとよい。60秒ごとにノードからデータを収集した場合、24時間分のメトリクスは86,400データポイントにも上る。このあたりのデータ保持に関する設計は必要になってくる。例えばデータ保持期間を2年とサービス上明記している場合には、その期間分のユーザ数＊データポイントを見積もって、どのように保持していくか計画しておく。DBについても、データ行が多くなると、DBパフォーマンスに影響がでる。(DMLのトランザクション処理に時間がかかる等)
監視設定は100％自動化すべき、各サービスは誰かが設定を追加するのではなく、勝手に登録されるようにする。
Ansibleとかでサーバ初期設定のスクリプトに組み込む形になる。
組み合わせ可能な監視(composable monitoring)を採用し、専門化されたツールを複数使い、それらを疎結合させて監視プラットフォームを作る。
いろんなツールが入り乱れることは避けたいが、ツールを増やして品質を上げるのはあり。
可用性に対して見落とされがちなのが、依存するコンポーネント(AWS EC2等)がある場合である。あるサービスの可用性はそのサービスの下のレイヤにあるコンポーネントの可用性を超えることはできない。
依存するコンポーネントに関連するインシデントを除いた形で、SLAを設定すること。AWS等の障害であれば、それは自社SLAとは関係ないというサービス整理をしておくこと。
ソフトウェアエンジニアをオンコールのローテーションに入れるのが良い。ソフトウェアエンジニアリングにおける「丸投げ」を避けるという意図がある。
これを実施できている組織の運用について確認すること。自社組織でもやってみたい。
インシデント管理のアンチパターンの一つに、会社での上下関係にインシデント対応の際も従ってしまうということがある。
あたらめて注意すべきポイント。マネジメントラインは周りとの連絡係に徹した方が良い。立場の高い人の進捗確認が原因で、進捗確認報告のための時間がとられてしまって、肝心のインシデント対応が滞ることがないように。社内向けのインシデント進捗報告方法は整理すべき。(それでも聞いてくる人はいるけど)
フロントエンドのパフォーマンス監視のゴールは動き続けることではなく、素早くロードされること。ページロード時間は目安として4秒以下を目指すと良い。
オンラインショッピングを運営しているユースケースだと、フロントエンドのパフォーマンスによって売り上げが大きく変わってくるということが多くの企業の結果が出ている。フロントエンドのパフォーマンス監視は自社でもあまり取り組めていないので、深堀をしないといけない部分である。バックエンドのAPIからデータ取得して、画面に表示しているユースケースだとフロンドエンドではなく、改修すべきはバックエンドAPIとなるので、そのあたりの切り分けができる監視手法が必要となる。
しかし、一部レスポンスが悪いAPIがあったとしても、フロンドエンドとしてはDOMのパースが完了すればよいので、フロンドエンド側で独立の監視メトリクスを設けることはできると思われる。
statsDはコードの中にメトリクスを追加するためのツールである。Etsyによって2011年に作られた以来その簡単さと柔軟性からStatsDはモダンな監視スタックには不可欠な存在である。サーバレスプラットフォームは、StatsDを使って監視する。
コード中にstatsDを仕込む形になるので、アプリケーション実装と密にかかわることになる。コード実装者と監視担当との情報連携が必須となる。監視設定する場合も、どういうデータ取得をしているか、理解する必要がある。
分散トレーシング(distributed tracing)は、マイクロサービスアーキテクチャの複雑なサービス間のやり取りを監視するための方法論とツールチェーンのこと。
マイクロサービス環境下の監視については、多く書かれていなかった。直近では、分散トレーシングによる監視手法は確立されているかもしれない。
ネットワークパフォーマンス監視における最大の課題はSNMPを使わなければならないということ。
ネットワーク機器監視において、SNMP v2cを利用するってのは、まだ変わっていない。ベンダーMIBを監視マネージャーにインストールして、専用の監視ネットワーク(アウトバウント)を設けて監視するってのは現在も変わっていない。
Discussion