『入門 監視』を読んだ
『入門 監視』 という本を読んだ。 普段は低レベルな部分の監視が多くて見失いがちだった、高レベルなポイントの監視について思いを馳せる機会を与えてもらったので読んでよかった。
以下、個人的に心の動いたポイントを記す。 本の内容については大して触れていないので、本書の内容そのものが知りたい人は読むしかない。
p.12 1.3.2 アラートに関しては、OSのメトリクスはあまり意味がない
体感としてもOSメトリクス自体にアラートつけて意味のあるアラート出せたことそんなに無かった。 監視を始めるにあたっていきなりこのOSメトリクスから取り組んでアラートを設定すると疲弊しそう。
メトリクス自体はとってもよい。 しかしトラブルが起きた時の解析材料としてのみ有用だと考えた方がよい。 OSから収集できるロードアベレージやメモリ使用率などが上昇したからといって、 必ずしもサービスに影響を与えるとは限らないことがある。 これに対してアラートを発することは、無駄なアラートの原因にもなる。 そのためメトリクス自体は収集しておいて、後のトラブルシュートで役立てる、というのがベターな使い方になる。
p.25 お願いだから円グラフは使わないで
かつてメモリの使用量を表示するグラフが円グラフで提供されていたことがあった。 実際に役に立たなかったのでそのとおりだと思う。
円グラフはあくまでも表示された瞬間のスナップショットでしかなく、時系列データの表現ではない。 メモリの枯渇を起こすまでの 傾向 がまったく可視化されないので肝心の時に役に立たない。 時系列データに対しては少なくともこの円グラフの表現は適切ではないと言える。
p.28 デザインパターン2: ユーザ視点での監視
経験的にサービス故障を検知する監視を最初に定義していたので、結果的にこのパターンに沿っていたように思う。
監視はいきなりシステムの深部から始めるのではなく、 システムの外側、つまりユーザが観測できるポイントから監視しましょう、ということ。
これまでの仕事柄、サーバサイドやネットワーク周辺の監視の仕事が多かった。 RESTful APIを提供しているサーバだと、特定のシナリオに従ってAPIを呼び出すようなスクリプトを定期的に実行し、その結果を監視するのが一番よさそう。 ネットワークにおいてはエッジからエッジまでユーザデータの転送を流し続けられるといい。JunosだとReal-time Performance Monitoring (RPMと呼ぶ)という機能を設定しておくと、同じ機能を持っているルータ間での実測性能をメトリクスとして蓄積できる。ルータ間でiperf動かしているような感じ。
p.47 3.3 インシデント管理
自分の対応を振り返ってみると、対応が終わったあとの振り返りが徹底できていないかな、という反省もあるので付箋を貼ったところ。
インシデント管理のラフなフローは下記のように
- 認識
- 記録
- 診断、分類、解決、クローズ
- 問題発生中のコミュニケーション
- 改善策
アラートとチケットについて
アラートをトリガとしてチケットが作成されるしかけができていると、 上記のリストの1, 2あたりは達成されていると思う。
しかしAtlassianの記事にはこんな注意事項もコメントされている。
現在の監視ツールの多くはノイズが非常に大きいことを考えると、アラートに基づいた自動チケット作成は、アラートのノイズ問題をチケット作成のノイズ問題へと拡大することになります。
アラートにノイズが多いのは現場あるあるかなと思う。 こんな現場ではチケット作成の自動化にすぐ飛びつくだけだとアラートのノイズの問題がチケットの滞留の問題に転化されるだけになってしまう。
このままでは運用が機能しなくなるので先にノイズを減らす対策をした方がよさそう。 本書でも「チェックボックス監視」というアンチパターンで指摘されているように不要な監視・アラートが仕込まれていることが原因でこのようにノイズに埋もれがちになる。
問題発生中のコミュニケーション
問題の解析とか対処している時は、他の部署とのコミュニケーションまで手が回らないことがあると思う。 本書ではインシデントの解消に取り組む人とは別に「コミュニケーション調整役」を定義している。
絶対そういうロール分けがあった方がいいと思う。 問題を解決を実行的に担当する人間には部署間調整やユーザへの周知などまで手が回らないのは容易に想像できる。 したがって作業担当と調整担当が最速の状況を把握しつつも、調整担当が関連部署への連絡をすることで、作業担当も集中して取り組めてミスも減らせる。
p.59 4.7 分意数
最小、平均、最大だけだと見逃す性質があるのですごく重要な観点。
システムのメトリクスをとっていると飛び抜けて大きいデータが急に現れたりすることがある。 最小、平均、最大だけ見ていると、最大がこの外れたデータで見えたりして驚く。 実際には70〜95パーセンタイルあたりをみてみると、外れたデータはなくて許容範囲に収まっていることが多い。
このようにGauge型メトリクスの跳躍を正しくとらえるためにも分意数による観測はとても役に立つ。 最小、最大だけでなくその間にあるデータの分布も見ましょう、ということなんだけど。
p.65 5.1 ビジネスKPI
サービスの正しさを監視する目的で実装をしてきたことが多いので、この視野での監視はカバーできていなかった。 本書でおさらいしてみて、こういうハイレベルなメトリクスの収集も面白そうだなと感じた。
こういうデータって経営層にレポートするのだろう。 報告に向けたレポート能力や定量データだけに頼りすぎないように誘導する議論のスキルが必要だったりしそう。 いろいろデータ以外にも配慮するべきところありそうだ。
p.80 6.3.1 フロントエンドパフォーマンスのメトリクス
必要性は認識していながら、サーバ側ばかりやってて実装方法をあまり知らなかったのだけど、本書を読んでなんとなくイメージついた。 ブラウザがAPI持っているらしい。(知らなかった)
バックエンドでどんなにチューニングしてもフロントエンドがボトルネックになってユーザ体験損なうということもあるだろう。 そういう問題を倒すための手法としてフロントエンドでの観察方法も身につけていく機会が持てればいいのだけど。
ユーザに近いことから監視ポイントを作っていくっていう目線で考えると、 ユーザにエラー表示した時点でアラート上がるように仕組みを作るのが第一歩になるのかな。
p.93 7.3 healthエンドポイントパターン
ping/pongくらいな単調なやつかと思ったらけっこうしっかりしたエンドポイントだった。
この例ではデータベース検索やキャッシュの取り出しを一回のリクエストの中で行うことで、 サブシステムとの結合をテストする目的があるらしい。
テスト、と書いたのがまさにこの監視の本質なのではないかと個人的には思っている。 少なくともサービスの正常性を監視をしようとするなら、継続的にテストを行うのが一番良いのはないか。 だから自動テストが常にプロダクション環境でも回るようにしておく。 勿論そのテストシナリオが複雑になりすぎないようにいくらかのトレードオフはあるはず。 しかし、いずれにせよ定期的なテストをサービス提供の裏で続けることでシステムの複合的なヘルスチェックを行う意義は大きいように思う。
このhealthエンドポイントではそうしたテストの中でも比較的小さいスコープ、つまり「コンポーネント同士のネットワーク間連携」を中心にチェックしている。 アプリケーションそれ自体で提供するならそのくらいの機能で十分かもしれない。
p.119 8.5 データベースサーバ
性能劣化に気づく重要な指標としてスロークエリは割と認識していたけど、 ミドルウェアの特性にあった監視戦略は引き出しにあまり無いなと感じた。
本書で紹介されているような 『実践ハイパフォーマンスMySQL』 のような本を読みたくなる日が来そう。 (その前に 『詳解システムパフォーマンス』 が読みたいが)
p.140 9.1.5 インタフェイスのメトリクス
スループットは事前の検証で計測することが多かったので、リアルタイムに監視する発想がなかった。 なのでなるほどと思う。
しかしプロダクション環境で物理帯域ぎりぎりのトラフィックをテスト的に印加するのは他のユーザへの影響があることも考えると気軽にできない。 スループットのテストはやはり定常監視とは別で議論した方がいいのか。
あまりすっきりした結論が出ず、個人的にはもやもやしている。
p.146 9.4 ルーティング
BGPのピアの監視はしていたが、下記のポイントは今までケアできていなかった。
- TCAMのサイズ
- ASパスの変更
- 送受信プレフィクス数
サービス提供するお客様のBGPルータから広報される経路は、事前の設計で取り決めたものがあったので、 当時はあまり気にしていなかった。 しかし、いま考えてみるとお客様の使い方を観測するためにも上記のような監視ポイントを押さえておいても良かったのかもしれない。
という反省。
p.147 9.6.2 ハードウェア
個人的にはネットワーク機器の監視の中でもちょっと面白いと感じている部分だったりする。
- シャーシの内部にどんな部品が内蔵されており、どんな役割をするのか。
- 壊れるとしたらどんなアラートが上がるのか。
など、そのシステム(=ルータ)を分解していくような楽しさがあって、ハードウェア監視は好き。
LinuxのベアメタルとかもメーカごとのMIBを読んでどこを監視するのか探るのは面白い。
雑感
本書を読んでも分かるけど監視のスキルといっても幅広い。 うまく監視するためには監視対象をよく知らないといけない。
個人的には監視周りのことを仕事でやって面白いのはそんなふうに監視対象をハックしていく瞬間だったりする。 監視をするためにその対象をよく調べて発見をしていく過程が楽しい。
あと、本書に通底するNagiosへの怒り（「ただしNagios、てめーはだめだ」的な雰囲気)が非常にパーソナルで良かった。
