凡ジニアのtxt

エンジニアリングができない凡ジニア

"入門 監視"を読んでみて

"入門 監視"を読んでみて

 監視システムを運用するようになってから、2年近くになってきました。監視について勉強しているときに、オライリー本の"入門 監視"も読んでいました。再度、この本を読んで、思ったことを書きます。

 以下に、オライリー公式のリンクを貼っておくので、興味ある方はぜひ検討してみてください。 www.oreilly.co.jp

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

 監視とはいっても、OSや物理リソースまたは仮想リソース、はたまたそれらの上で稼働しているアプリケーション、ネットワークなど多くのドメインに対して監視する必要がある。監視するにしても、対象ドメインの知識は必要となり、属人化してはならない。うちのチームと照らし合わすと、「.......、まぁ属人化してますな.....」。

 あとは監視ツールは最小限にすべきとあるが、開発体制や予算の都合でさまざまな監視ツールが存在する組織もあるだろう。Grafana/Prometheus/Kibana/NewRelicがあるが、ドメインによっては複数のGrafana/Kibanaが多く運用されている。アクセス方法やユーザー管理もそれぞれ違うチームが対応するので、運用観点から統一してほしい。統一できるように行動はしているが、あまり上の了承が得られないのが悩みどころになっている。了承を得られるまで、粘ってみたいと思う。

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

 監視デザインパターンの一つとして、監視の仕組みを作るのではなく、買うこともひとつとある。New Relicやdata dogがこれらに当てはまる。New Relicを使っているが、確かにこれは便利である。

 例えば、PrometheusとGrafanaを同時に作ることは一般的であると思う。しかし、メトリックス収集用のExporterをインストールしたり、どのようにメトリックスをグラフ化するかなど結構工数がかかったり、仕様変更などの対応も大変だったりする。NewRelicのAgentをインストールすれば、すぐにデフォルトのグラフが表示できるので、楽である。(楽は正義....)

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

 一番大切なことは「アラートにメールを使うのをやめよう」だ。意外とアラートをメールで投げている会社は多いのではないか。うちも考慮漏れされたシステムの監視方法に対してメール発報がある。これは、関連のあるシステム動作も追うことは困難になるし、必ずアラート数が増える。何度も言う「アラートにメールを使うのはやめよう」。

 Runbookの作成や不要なアラートの削減は効果的であると思う。Runbookは、他メンバーの教育にもなるし、属人化を避けることができる唯一の手段になる。また、不要なアラートの削減に対しては、アラートの目的を明確にして、閾値をシンプルしていった方がいいと思う。

4章 統計入門

 私は統計学がわかるとまで必要ではなく、最低限で簡単な数式を理解できればいいかなと思っている。例えば、Prometheusでよく使われるrate関数がある。これは最新x分範囲で抽出されたデータセットの増加率を調べるものである。

 最新5分範囲のデータセットをx = [1, 2, 3, 4, 5]とした場合に、(5 - 1) / (5 * 60) * 100 = 1.33333...% の増加率となる。なので、1分単位で0.8ずつ値が増えていることとなる。観測対象によるが、この増加率以下となれば、システムは正常に稼働している。増加率以上になれば、システムに何かしらの不具合が起きているという判断になると思う。HTTP 5xxが常に応答されている等。

 ここで述べたのは、専門的な統計学ではなく、高校で習う数列と乗算ぐらいで最低限は通じるはずである。(複雑な場合は、都度勉強すればいいと思う。)

5章 ビジネスを監視する

 ビジネスと言えばKPIが重視される。監視観点から、一般的なのはApdexではないだろうか。これはWebシステムに対するユーザーの満足度を計測しているものとなっている。この閾値が下がれば、レスポンスの遅さに不満を抱いている可能性があるから、パフォーマンス改善が求められている。

 New RelicではAPM上で観測でき、アラートも設定できる。これで一早くビジネスに影響を与える要因を探して対応すれば、ビジネスに貢献できるのではないだろうか。計算式は以下New Relicの公式サイトに説明されているので割愛します。

docs.newrelic.com

6章 フロントエンド監視 & 7章 アプリケーション監視

 ロード時間、例外処理もみようぜ。また最近はマイクロサービス化されているから、分散トレーシングしていこうぜ。

8章 サーバ監視

 CPU、メモリ、ストレージを監視しようぜ。あとはOOM Killerには気をつけよう。うん、OOM Killer怖い。でも、起きることはしょうがないので、すばやく対応できるようにしておこう。

9章 ネットワーク監視

 ネットワーク監視といっても、プロトコルだけでなく、インターフェース、スイッチ、シャーシなど数多くの監視対象があるので、大変だよね。

10章 セキュリティ監視

 セキュリティ知識があまりないが、audit logと取ってセキュリティ違反者を探そうぜってことかな。よくsshのパスワードなど間違えて、セキュリティ違反対象になる。とほほ。。。

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

 ここの章は、本誌で述べたことをチェックリストみたいなものなので、見たい方は本誌を購入してみてください。

終わりに

 後半は、本誌で紹介されている例が多かったので、感想しか書けなかった。しかし、改めてどのように監視を改善してビジネスを成長させられるかがよく書かれた本だと思う。まだまだ監視について、出来ていない箇所(特に6&7章)があるので、また振り返って監視を強化していきたい。また本誌で説明されていることは、New Relicやdatadog、mackerelなどの監視用SaaSで対応できるから、すごい世の中になったなと思う。