読書メモ: 入門監視 ―モダンなモニタリングのためのデザインパターン（１）

はじめに

• 入門監視の読書メモ。
• 第1章から第3章までで52ページ分に相当する。

入門 監視 ―モダンなモニタリングのためのデザインパターン
 - Mike Julian (著), 松浦 隼人  (翻訳)
 - ２０１９/01/16 初版第1刷発行

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

アンチパターン1. ツール依存

• ツールを入れること自体で満足しがちだが、「何をやるか」を蔑ろにして「ツール導入」が目的になってはならない。
• ツールを増やすこと自体に恐れる必要はない。気にするべきは、賢くツールを選び、使えないたくさんのツールやメトリクスの乱立を防ぐことである。

観察者効果は気にしない

• 観察者効果とは、監視する行為が監視対象を変化させてしまうことをいう。監視ツール自体がCPU負荷を増大させる、などである。だが現代では負荷も小さいはずなので大して問題にはならない。
• むしろツールやエージェントを導入しないことで、監視したいものを監視できなくなることを気にすべきである。

カーゴ・カルトなツールを避ける

• 成功したチームや会社のツールや手順を採用することで自分のチームを成功させようとするのは間違いである。
• チームが成功したことによりツールや手順が作られたのであり、これは原因と結果が逆になっているためである。
  • 住民が南洋の孤島で飛行場や滑走路をいくら整備しても、肝心の飛行機はやってこない。一番大事な本質を見落としてはならない。
• 他のチームが公開したツールを採用すべきでないというわけではない。そのツールが本当にあなたのチームで機能するかどうかを評価し試すことが大事である。

自分でツールを作らなければならない時もある

• 自分だけの特別なツールを作ることで、本来使うはずだったよりも短い時間で、効率よく問題を解決できることもある。
• 全く新しい監視プラットフォームを作ろうということではなく、小さく何かに特化したツールを作ることも時には必要ということである。

「一目でわかる」は迷信

• すべてを1つのツールあるいはダッシュボードシステムに詰め込もうとするのは、効率的に仕事をしようとするのを妨げてしまうことがある。
• ツールとダッシュボードは1対１に対応している必要はなく、1つのツールから複数のダッシュボードに出力するのも全く問題ない。ただ、情報が分散してしまうということがなく、「状態を見るためのまとまった1つの場所」があれば良い。

アンチパターン2. 役割としての監視

• ログ収集の専門家、サーバ管理の専門家、監視の仕組みを作り管理する専門家など、専門家したロールを作るべきではない。
• 監視とは役割ではなく「スキル」であり、チーム内の全員がある程度のレベルに至っているべきである。
• なぜならば、「理解できていないもの」に対して監視する仕組みは作れないためである。

アンチパターン3. チェックボックス監視

• チェックボックス監視とは「これを監視しています」と言うためだけの監視システムのことである。
• 監視を設定する人がシステムの動作を理解していないと、監視の役にも立たない簡単な監視設定だけして満足してしまうことがある。
• このアンチパターンに陥っている場合は、以下の兆候が見て取れる。

    1. システム負荷、CPU使用率、メモリ使用率などのメトリクスは記録しているが、システムがダウンしたことの理由はわからない
    2. 誤検知が多すぎるのでアラートを常に無視する
    3. 各メトリクスを5分あるいはそれより長い間隔で監視している
    4. メトリクスの履歴を保存していない（Nagiosお前のことだ） ※原文ママ

　「動いている」とはどういう意味か。「動いているか」どうかを監視しよう

• 「我々が監視しているのは何なのか」を理解しなければならない。「動いている」とはどういう状態なのかについて、必要ならばサービスやアプリケーションのオーナーに聞く必要がある。
• 「動いている」とはどういう状態なのかを理解すれば、「動いているか」を確認するための高レベルなチェックを設定できる。
  • たとえば、Webアプリケーションであれば、HTTPで GET/ した結果を確認することで、 HTTP 200 OK で返ってきているか、ページに特定の文字列があるかどうか、リクエストのレイテンシが小さいかなど、「アプリケーションが動いているかどうか」の多くの情報を得られる。

アラートに関しては、OSのメトリクスはあまり意味がない

• あるサーバのCPU使用率が高くても、そのサーバがやるべき処理をしているなら大抵の場合は問題ない。
  • たとえば、MySQLが継続的にCPU全部を使っていても、レスポンスタイムが許容範囲であれば問題はない。
• 役に立たないわけではないが、CPUやメモリ使用率のような低レベルのメトリクスではなく、「動いているか」を基準にアラートを送ることがより有益である。

メトリクスはもっと高頻度で取得しよう

• 最低でも60秒に一回メトリクスを取得する。
• 5分に一回などの荒すぎるメトリクスの取得は、たとえば30秒ごとにレイテンシが跳ね上がる場合を見逃してしまい、実際には何も見ていないのと同じになる。
• とはいえ長期間のログの保存も費用がかかるので、一定期間後に適切なデータの間引きするというような設定を行うのも忘れないようにする。（どこまで長期間保存すべきかを検討する）

アンチパターン4. 監視を支えにする

• 監視が杖であるかのように寄りかかってはならない。
• 監視は問題を通知することに長けているのであって、通知を受けた後にするべき修正を忘れてはならない。
• 監視を増やしてもシステムが直るわけではないので、問題の根本解決を図りたいところである。

アンチパターン5. 手動設定

• 自動化が素晴らしいことは周知の事実であるからこそ、監視の設定も自動で行われるべきである。
• 各サービスは誰かが設定を追加するのではなく、勝手に登録されるようにするのがよい。

まとめ

• ツールに依存しても、監視の仕組みは良くならない。
• 監視は全員がやるべき仕事であり、チームや部署内での役割ではない。
• 素晴らしい監視とは、チェックボックスに「これは監視してます」とチェックを入れるだけで済むものではない。
• 監視するだけでは壊れたものは直せない。
• 自動化が足りていないということは、何か重要なことを見落としている可能性を知る良い方法である。

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

デザインパターン1. 組み合わせ可能な監視（Composable Monitoring）

• 組み合わせ可能な監視とは、専門化されたツールを複数使い、それらを疎結合させて、監視「プラットフォーム」を作ることである。
• モノリシックツールなツール（たとえばNagios）とは対照的で、組み合わせ可能な監視はUnix哲学を実践的にした考え方とも言える。
• 組み合わせ可能な監視の利点としては、1つのツールのやり方に長期間に渡りコミットする必要がないことが挙げられる。疎結合に作ってしまえば、やり方が合わなくなった時に他のツールで簡単に置き換えることができる。

監視サービスのコンポーネント

データ収集

• プル型は中央システムがすべてのクライアントを把握してスケジュールし、応答をパースしなくてはならずスケールしづらい。
• プッシュ型はクライアントはデータを他の場所に一定間隔あるいはイベントが発生したタイミングでプッシュするため冗長性に優れ高可用性のある構成と言われる。
• どちらもメリット・デメリットがあるのでデータの集め方によって使い分ける。どんなデータを集めるかでメトリクスとログを使い分けることも重要である。

メトリクス
    - カウンタ：　増加していくメトリクス。車の走行距離計が良い例。アクセス累計数を数えるという用途もある。
    - ゲージ：　ある時点の値を表す。車の速度計が良い例。過去の値については情報を与えてくれないので、データを適時保存する必要はある。
ログ
    - 基本は連続した文字列とイベントが発生したタイムスタンプからなる。ログにはメトリクスが持つより多い情報を持てるので、情報抽出にパースが必要となることもある。
    - JSONのような形で構造化した「構造化ログ」と、Apacheのアクセスログのような「非構造化ログ」がある。
    - メジャーなOSやロギングデーモンにはログ転送機能があるので、複数のシステムのログを１箇所に集約して分析することができる。

データストレージ

• データを収集したら、どこに保存するかもデータタイプによって適切に保存する必要がある。
• 時系列データであるメトリクスは、基本的には時系列データベース（Time Series Database）に保存される。タイムスタンプと値というキーバリューのペア（データポイントと呼ぶ）で保存されることが多い。
• TSDBに多くは一定期間後にデータの「間引き」や「有効期限切れ」が発生し、複数のデータポイントが1つのデータポイントにまとめられる。
• 1日あたり数TBのログデータが記録されることもあるため、間引き・圧縮・保存期間を適切に設定してログ保存を管理してコストを抑えたい。

可視化

• 監視プラットフォームを目に見える形にしてくれるチャートとダッシュボードは便利だが、データが散らかっていたりややこしかったりと自身やチームの求めるものに沿った形でデータを理解できないならそのデータは無駄である。
• 最高のダッシュボードは1つのサービスあるいは一つのプロダクトのステータスを表示することに焦点を絞るものである。最も効果的なのは、そのサービスを最も良く理解している人たちによって作られ、運用されている時である。

分析とレポート

• 監視データの種類によっては、分析とレポートの分野に踏み込むと有益な場合がある。
• ユースケースとしては、サービスレベルアグリーメント（SLA。可用性に関する契約）を決定し、レポートする場合が挙げられる。
• 可用性の計算の公式は、稼働時間/総運用時間で求まり、監視データから算出できる。
• ただし、可用性に関して見逃しやすい問題としてはサンプリングエラーがある。
  • 標本化定理（ナイキスト・シャノンのサンプリング定理）によると、２分間のダウンタイムを計算するには１分感覚で、１秒間のダウンタイムを計測するには1秒未満の感覚でデータを収集する必要がある。
  • また、複雑なアーキテクチャでは稼働時間と総運用時間を計算するのはより大変である。

アラート

• 何か問題が起きた時にアラートを出すことが監視システムの目的ではない。
• 「監視は、質問を投げかけるためにある。」　Dave Josephsen, Monitorama 2016
• 監視とはアラートを出すためのものではなく、結果の一つの形でしかない。

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

• 監視を追加すべきなのは、ユーザがあなたのアプリケーションとやり取りするところである。
• ユーザが気にするのは「アプリケーションが動いているかどうか」であり、ユーザ視点を優先した可視化が必要である。CPU負荷が増大してもユーザが影響を受けていなければ、何ら問題はない。
  • Apacheのノードが何台動いているかなどはユーザは興味がない。シンプルにHTTPレスポンスコード（特にHTTP5xx番台）、リクエスト時間（レイテンシ）を測定する方が良いことが多い。
• 必要あれば、ユーザ視点以外の部分の監視の幅を広げても良いが、「このメトリクスはユーザへの影響をどう教えてくれるのだろうか」と常に自問自答することが重要である。

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

• 「ツール依存アンチパターン」に対する答えになる。
• 多くの企業はまずは監視のSaaSサービスを使うべきである。ある時点から監視の仕組みを社内に構築し、またそこから独自の監視プラットフォームを構築する、というように監視の仕組みが成熟した段階で各ステージに進むのが良い。
• 監視の仕組みが不十分なのに、一足飛びに独自の監視ツールや監視プラットフォームの構築に取り組まなくても良い。

安いから

• SaaSを使うコストとFOSS（Free and open-source software）や自前ツールで独自のプラットフォームをエンジニアが一から作るのにかける時間と機会損失を比較すると、SaaSを使った方が結果的に得になることも多い。

あなたは（おそらく）監視ツールを設計する専門家ではないから

• あたなはおそらく監視サービスを構築して運用する専門家ではない。
• 専門家が作ったSaaSソリューションを利用した方が、自前で構築するよりもずっとうまく運用できる。

SaaSを使うとプロダクトにフォーカスできるから

• SaaSを使えば数分で動く仕組みが手に入り、始めたタイミングからドキュメントなども手に入る。
• 本来の目的あh「プロダクトを作る」なのに、そこから離れた「自前のソリューションを作る」ということに煩わされることがない。

実際のところSaaSの方がよいから

• SaaSを使わない合理的理由は、「SaaS監視サービスでは間違いなく機能が足離ない場合（ほぼ稀である）」「セキュリティやコンプライアンス上の理由（ログへ機密情報を送りたくない、など）」の主に2つだけである。
• SaaSを使いたがらない人が挙げる理由のほとんどは認知コストに行き着くことが多い。技術的あるいは経済的理由をもとにしているわけでない事が多い。

デザインパターン4. 継続的改善

• Google, Facebook, Twitter, Netflix, Etsyといった進歩的な企業の大規模な監視ツールは一朝一夕でできたものではない。
• 世界レベルの仕組みは1週間ではできず、数ヶ月あるいは数年間にわたる継続した注意深さと改善から生まれる。

まとめ

以下の4つを適用すれば、ほとんどの仕組みより素晴らしい監視プラットフォームを作れるだろう。

• 組み合わせ可能な監視の仕組みは、物知りっくな仕組みよりも効果的である
• ユーザ視点有線での監視によって、より効果的な可視化ができる。
• 監視の仕組みは、可能な限り自分で作るのではなく買うことを選ぶ。
• 常に改善し続けよう。

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

• 監視とは、「あるシステムやそのシステムのコンポーネントの振る舞いや出力を観察しチェック強い続ける行為」である。
• アラートは監視システムの重要な機能の1つではあるが、監視の目的を達成するための一つの方法でしかない。
• 適切なアラートの実現は難しい。
  • 1つ目の理由として、システムのメトリクスは急激に変化するため、そのままデータポイントを使うと誤った警報を送ってしまう。一方で移動平均でデータを鳴らしてしまうと情報の粒度が落ち、重要なイベントを見逃してしまう。
  • 2つ目の理由として、アラートは人間に送られる一方で、人間の注意力には限界があるため。アラートを受け取るたびに、監視システムに注意力が少しずつ削れれていってしまう。

どうしたらアラートをよくできるか

• アラートには2種類のものがある。入門監視では前者を取り扱う。

    誰かを叩き起こすためのアラート
        - 緊急の対応が求められ、でなければシステムがダウンしてしまうもの。電話、テキストメッセージ、アラームなどで送られる。

    参考情報（FYI）としてのアラート
        - すぐに対応する必要はないが、アラートが来たことは誰かが確認すべきものである。

アラートにメールを使うのをやめよう

• メールは誰かを叩き起こすためのものではないし、そのために使おうと思うべきでもない。メールによるアラートは受け取る人が最もうんざりしてしまう方法である。
• アラートの使い道は次の3つに集約される。

    すぐに応答かアクションが必要なアラート
        - SMS, PagerDutyなどのページャに送る。これらが上述の定義でいう本来のアラートである。

    注意が必要だがすぐにアクションは必要ないアラート
        - 社内のチャットルームに送るのが著者の好みである。
        - メールで送るのもありだが、受信箱をいっぱいにしがちなので注意する。
        - 他の方法があるのであればそちらを利用するとよい。

    履歴や診断のために保存しておくアラート
        - これらの情報はログファイルに送りましょう。

アラートのログをとる

• アラートのログを保存しておき、後でレポートを送れるようにしておくと良い。
• アラートのレポートを送ると、アプリケーションやサービスのどの部分でトラブルが多く、どこに改善の焦点を合わせれば良いのかがわかる。

手順書を書こう

• 手順書（runbook）は、アラートが来たときに素早く自分の進むべき方向性を示す素晴らしい方法である。
• システムが複雑になると、誰もが各システムのことを知っているわけではなくなり、手順書が知識を広める方法となる。
• 良い手順書とは特定のサービスについて以下のような質問に答えるものである。

    - これは何のサービスで、何をするものか
    - 誰が責任者か
    - どんな依存性を持っているか
    - インフラの構成はどのようなものか
    - どんなメトリクスやログを送っていて、それらはどういう意味なのか
    - どんなアラートが設定されていて、その理由は何なのか

• アラートには対象手順書のリンクを貼っておく。ただし、手順書がアラートに対するコピペで済む内容になっている場合は、問題修復までを自動化すべきである。

固定の閾値を閾値を決めることだけが方法ではない

• Nagiosのおかげでアラートの基準に固定の閾値を決めることに慣れてしまっているが、これは間違いである。
• たとえば「空き容量が10%以下」という固定値を決めてしまうと、ディスク容量が11%から80%まで急激に増えるケースを見逃してしまう。（本当に知らせてほしいのはこういうケースのことが多い）
• これを解決するために、たとえば「一晩でディスク使用量が50%増加した」といった内容を知らせてくれるよう、「変化量」あるいは「グラフの傾き」を使うようにする方法もある。

アラートを削除し、チューニングしよう

• うるさいアラートによって人は監視システムを信用しなくなり、さらにはすっかり無視してしまうようになる。アラート疲れへの対策は一見シンプルに見えて簡単ではないが、アラート量を減らすいくつかの方法はある。

    1. 初心に戻りましょう。すべてのアラートは誰かがアクションする必要がある状態か。
    2. 1ヶ月間のアラートの履歴を見てみよう。
        - どんなアラートがあるか。
        - どんなアクションを取ったか。
        - 各アラートの影響はどうだったか。
        - 削除してしまえるアラートはないか。
        - 閾値を変更できないか。
        - 監視の内容をより正確にするようにデザインし直せないか。
    3. アラートを完全に削除するために、どんな自動化の仕組みが作れるか。

メンテナンス期間を使おう

• 何らかのサービスで作業する必要があり、そのサービスにステムダウンしたら送られるアラートが設定されているなら、アラートをメンテナンス期間に入れる。
  • メンテナンスする予定があり、その作業がアラートを送られてしまうことがわかっているなら、そもそもその期間はアラートを送るのを止めるという仕組みにする方が、作業者や他の人の邪魔をしないで済む。
• ただし、アラートの止め過ぎには注意する。知らない依存性により、本来検知すべき他のサービスのアラートまで見逃すということがあり得る。

まずは自動復旧を試そう

• アラートに対する代表的なアクションが既知で用意された手順に沿って対応するだけなら、その作業は完全に自動化しよう。
• 自動復旧はアラート疲れを防ぐ一つの良い手段である。自動復旧で解決できない時にアラートを送れば良い。

オンコール

• オンコールとは、何か問題が起きたという時に呼び出しに答えられるようにしている担当のことである。
• 誤報やわかりにくいアラート、場当たり的対応に悩まされがちだが、どうしたらそうならないか・何ができるかは常に考える必要がある。

誤報を修正する

• 100%正確なアラートを実現するのは非常に難しいが、アラートをチューニングするという努力は行わないといけない。
• アラートをチューニングする簡単な方法が1つある。以下の通りである。

    1. オンコール担当が前日に送られたすべてのアラートの一覧を作成する。
    2. 一覧に目を通しながら、各アラートはどのように改善できるか、あるいはアラートを削除してしまえないかどうか、を分析する。
    3. オンコールの担当毎に毎回一覧の作成と分析を行い、適宜対応を行なっていく。

無用の場当たり的対応を減らす

• 監視自体は何も修復はしてくれないため、何かが壊れたらそれを修復しましょう。
• 場当たり的な対応を止めるには、その根本原因であるシステム自体を改善する必要がある。
• この習慣を身につけるためには、以下の2つの効果的な戦略が有効である。

    1. オンコールシフト中、場当たり的対応をしていない時間は、システムの回復力や安定性に対して取り組むのをオンコール担当の役割にする。
    2. 前週のオンコールの際に収集した情報を元に、翌週のスプリント計画やチーム会議時にシステムの回復性や安定性について取り上げる計画を立てる

上手にオンコールローテーションを組む

• 単にいつでもオンコールになってしまっているという状態は人を燃え尽きさせる最高の方法である。だからこそ適切なローテーションを組むことが重要である。

インシデント管理

• インシデント管理とは、発生した問題を扱う正式な手順のことである。
• 最も広く使われているフレームワークの1つがITILからきたものである。
• ITILのインシデント管理のプロセスは以下のようなものである。

    1. インシデントの認識
    2. インシデントのロギング
    3. インシデントの分類
    4. インシデントの優先順位付け
    5. 初期診断
    6. 必要に応じたレベル２サポートへのエスカレーション
    7. インシデントの解決
    8. インシデントのクローズ
    9. インシデント発生中におけるユーザコミュニティとのコミュニケーション

• 形式張った表現であるが、インシデントの認識と対応に関する正規で一貫した方法があることで、チームには一定の厳格さと規律が生まれる。
• しかし、このプロセスを採用しつつ、やりすぎにならないようシンプルに以下のようにしても悪くない。

    1. インシデントの認識（監視が問題を認識）
    2. インシデントの記録（インシデントに対して監視の仕組みが自動でチケットを作成）
    3. インシデントの診断、分類、解決、クローズ（オンコール担当がトラブルシュートし、問題を修正し、チケットにコメントや情報を添えて解決済みとする）
    4. 必要に応じて問題発生中にコミュニケーションを取る
    5. インシデント解決後、回復力を高めるための改善策を考える

• もし数分以上かかる本当のサービス停止を伴うインシデントについては、明確に定義された以下のような役割が重要になる。

    - 現場指揮官（Incident Commander）
        - この役割の人の仕事は決断すること。改善・顧客や社内とのコミュニケーション・調査には関わらない。
        - サービス停止に関する調査を監督する役割であり、それだけである。
        - インシデントの初期段階では、オンコール担当がICの役割を担うことがある。
    - スクライブ
        - 初期の仕事は、起こったことを記録しておくことである。誰が何をいつ行ったのか。どんな決断がされたのか。どんなフォローアップすべき事項が見つかったのか。
        - この役割の人も、調査や改善は行わない。
    - コミュニケーション調整薬
        - この役割の人は、社内外問わず利害関係者に最新状況のコミュニケーションを取る。
        - ある意味で、インシデント対応する人や何が起きているか知りたい人たちにとって、この人が唯一のコミュニケーションポイントである。
        - 利害関係者、インシデントの解決に取り組んでいる人たちに最新情報を直接聞いてしまってインシデント解決を邪魔することがないようにするのも、仕事の1つである。
    - SME（Subject Matter Expert）
        - 実際にインシデント対応する人である。

• インシデント管理の役割は、通常の上下関係と一緒である必要ではない。
  • むしろマネージャはICよりコミュニケーション調整役にし、エンジニアをICにすることをおすすめする。
  • マネージャがチームを割り込みから守り、エンジニアがリスクとトレードオフを評価して適切に決断をするようにするのである。

振り返り

• インシデント発生後は、インシデントに関する議論（何が起きたのか、なぜ起きたのか、どうやって修正したのか等）の場を常に設けるべきである。
• 原則的に、利害関係のあるすべての組織から人を集め、何が問題で、なぜ発生して、再発防止のためにチームでどう対応していくのかを議論する。
• この際に、誰かを非難してはいけない。ミスに対する非難や罰はインシデントの原因を隠す方向に働くため、インシデントの本当の原因を改善することはできなくなる。

まとめ

• アラートは難しいが、ヒントを活用することで正しい方向に進める。
  • アラートをメールで送らないようにする。
  • 手順書を書く。
  • すべてのアラートがシンプルな閾値で決められるわけではない。
  • 常にアラートを見直そう。
  • メンテナンス期間を使おう。
  • 誰かにアラートを送る前に自動復旧を試そう。
• いくつかの方法を使えばオンコールの仕組みを改善するのは難しくない。
• 自社にあったシンプルで使い道のあるインシデント管理プロセスを作るのを優先する。