監視のいろはを学ぶ ！入門 監視を読んだ

会社では，オンプレにあるサービスの監視はZabbixを使っているが，クラウドで動いているサービスの監視はこれといった監視システムは決まっていない．何か新しいものを導入するのか，そのままZabbixを使っていくのかにかかわらず，Webサービスを提供する上での監視ってそもそもなんだっけ？という漠然としたことを知りたかったので，今回は「入門 監視」を読んだ．各章で語られる内容を今運用しているZabbixに当てはめて考えながら読んでみると，なるほどと納得することが多かった．この本では，監視する対象が網羅的に書かれていて，それぞれの詳しい監視の方法については別途他の書籍や記事が紹介されている．この記事では，監視の基本的なことが書いてある１章と２章，そして３章のアラートについてまとめようと思う．

入門 監視 ―モダンなモニタリングのためのデザインパターン

目次

• 1章 : 監視のアンチパターン
• 2章 : 監視のデザインパターン
• 3章 : アラート、オンコール、インシデント管理
• 4章 : 統計入門
• 5章 : ビジネスを監視する
• 6章 : フロントエンド監視
• 7章 : アプリケーション監視
• 8章 : サーバ監視
• 9章 : ネットワーク監視
• 10章 : セキュリティ監視
• 11章 : 監視アセスメントの実行
• 付録A : 手順書の例：Demo App
• 付録B : 可用性表
• 付録C : 実践 監視 SaaS

監視のアンチパターン１：ツール依存

ここでは「何を実現したいか」よりも「どのツールを使うか」に焦点があたってしまう問題を指摘している．

監視とは，単一の問題ではなく，いくつかの問題が複雑にからみあっているので，このツールを使えばいいという銀の弾丸はない．また，成功した企業が使っているツールを採用すればいいかと考える人もいるかもしれないが，それらの企業は成功するために必要だったからそのツールを採用したのであってその逆ではない．

そして，銀の弾丸がないからこそ複数のツールを使って問題を解決することもあるが，ツールを増やすことを無意味に怖がってはいけない．「仕事ができる最低限の数」であればツールは増やしても良いというのが執筆者の考えだ．

監視で可視化は重要であるが，「一目でわかるようにしてほしい」と言われたときは注意が必要だ．監視における「一目でわかる」アプローチとは，状態を見るための１つの場所が欲しいのであって，1つのツールや1つのダッシュボードが欲しいわけではない．ツールとダッシュボードは１対１に対応している必要はないので，複数のツールから１つのダッシュボードに出力することだってある．それらのダッシュボードシステムが「一目でわかる場所」にあればいいだけだ．

監視のアンチパターン２：役割としての監視

ここでは，監視は現場の人間が仕組み化することが重要だと述べられている．

会社に監視専門部隊があるとして，すべての監視をその部隊にやらせるのはアンチパターンである，監視対象に詳しくない人間が監視をするのは無理なので，アプリケーション・データベース・ネットワークエンジニアなどの現場のメンバーが監視の仕組みをデザインするべき．監視とは役割ではなくスキルである．監視専門部隊の仕事は現場のチームに監視ツールをサービスとして提供することになる．

監視のアンチパターン３：チェックボックス監視

チェックボックス監視とは「これを監視しています」と言うための，とりあえず設定したような監視システムのこと．以下のような兆候があると，このアンチパターンに陥ってしまっている可能性がある．

• システム負荷，CPU使用率，メモリ使用率などのメトリクスは記録しているが，システムがダウンしたことの理由は分からない
• 誤検知が多すぎるのでアラートを常に無視する
• 各メトリクスを５分あるいはそれより長い間隔で監視している
• メトリクスの履歴を保存していない

このアンチパターンは，監視のアンチパターン２と一緒に見つかることがある．監視を設定する人がシステムの動作を完全に理解していないと，シンプルで簡単なものの監視設定をしただけになるからである．このアンチパターンを直すにはいくつかの方法がある．

「動いている」かどうかを監視する

「動いている」ことを定義すると，何を監視すればよいかが決まり，それらは「何か」がおかしいことを示す優れた指標となる． 例えば，Webアプリケーションの場合，HTTPでGET /したレスポンスコードを記録し，HTTP 200 OKが返ってきているか，ページに特定の文字列があるかどうか，さらにリクエストのレイテンシが小さいかどうかを確認する．この監視１つで，アプリケーションが本当に動いているかどうかに関するたくさんの情報を得ることができる．

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

例えば，MySQLが継続的にCPUを全部使っていたとしても，レスポンスタイムが許容範囲に収まっていれば何も問題はない． CPU使用率やメモリ使用率のような低レベルなメトリクスで判断してアラートを送るよりは，「動いている」かどうかでアラートを送る方が有益である．

メトリクスをもっと高頻度で取得する

複雑なシステムでは，数分あるいは数秒の間にたくさんのことが起きるので，５分に１回しかメトリクスを取得しない設定などは実質的に何も見ていないのと同じ．最低でも６０秒に１回メトリクスを取得する．

監視のアンチパターン４：監視を支えにする

アプリケーションのバグが出た時に根本解決をせずにその場所に監視を仕込んで気づけるようにしておく暫定対応はよくない．監視を増やしてもシステムが直るわけではないので，状況の改善にならない．

監視のアンチパターン５：手動設定

監視は１００％自動化する．新しい監視設定を自動化していないと監視設定がストレスになり，やがて考えるのをやめてしまう．

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

組み合わせ可能な監視とは，専門化されたツールを複数使い，それらを疎に結合させて作る「監視プラットフォーム」である．利点として，１つのツールややり方に長期間にわたってコミットする必要がないことが挙げられる．あるツールがやり方に合わなくなった時，監視プラットフォーム全体を置き換えるのではなく，そのツールだけを削除して他のもので置き換えることが可能である．監視サービスには以下の５つの要素がある．

1. データ収集
2. データストレージ
3. 可視化
4. 分析とレポート
5. アラート

１．データ収集

データ収集コンポーネントは，その名の通りデータを収集する．データ収集を行うには主な方法としてプル型とプッシュ型がある．プル型は，サービスがリモートノードに対して，ノードの情報を送りつけてくるよう要求を出す．一方，プッシュ型は，クライアント（サーバやアプリケーションなど）はデータを他の場所に，一定間隔あるいはイベントが発生したタイミングでプッシュする．どちらの方法もそれぞれメリットとユースケースがある．

どんなデータを集めるかによって，メトリクスとログという２種類のデータがある．

メトリクス

メトリクスには２つの表現方法がある．
１つはカウンタである．カウンタは，車の走行距離計のような増加していくメトリクスで，Webサイトに訪れる累計人数を数えるといった用途に最適である．
もう１つはゲージである．ゲージは，車の速度計のようなある時点の値を表す．

ログ

ログは，基本的には連続した文字列のことで，いつイベントが発生したのかを示すタイムスタンプが関連づけられたものである．ログには構造化ログと非構造化ログの２種類がある．
非構造化ログとは，各フィールドに対して明確な意味のマッピングはない．例えば，Webサーバがデフォルトで出力するようなログが非構造化ログである．
反対に，構造化ログは各フィールドの意味が分かるようJSONやその他さまざまな形で非構造化ログをパースしたものである．

２．データストレージ

時系列データであるメトリクスは，通常は時系列データベース（TSDB：Time Series Database）に保存される．TSDBは，基本的にはタイムスタンプと値というキーと値のペアから構成される時系列データを保存するためにデザインされた専用のデータベースである．このキーと値のペアをデータポイントという．
TSDBの多くは，一定期間後にデータの「間引き」や「有効期限切れ」が発生する．これは，データが古くなったら，複数のデータポイントが１つのデータポイントにまとめられることを意味する．よくある間引きの方法としては平均化がある．

ログのストレージにはシステムにファイルとして保存するか検索エンジン（Elasticsearchなど）に保存するかの２つの方法がある．

３．可視化

収集したログやメトリクスをダッシュボードにまとめたりして可視化する．可視化はそれだけで１冊の本が書ける．以下はこの本で紹介されていた可視化についての書籍である．

The Visual Display of Quantitative Information

Information Dashboard Design: The Effective Visual Communication Of Data

４．分析とレポート

監視データの種類によっては，単なる可視化を超えて，分析とレポートの分野に踏み込むと有益な場合がある．よくあるユースケースの１つとして，アプリケーションとサービスのサービスレベルアグリーメント（SLA：Service Level Agreement）を決定し，レポートする場合が挙げられる．SLAとは，サービス提供者と顧客との間で取り交わされる，アプリケーションやサービスに期待される可用性についての契約である．

５．アラート

監視した結果をアラートとして人間に知らせる必要があるが，監視の目的をしっかり理解することが重要である．後半で詳しく説明する．

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

監視対象は数多く存在するが，まず監視するべきなのは，ユーザがアプリケーションとやり取りをするところである．もっとも効果的な監視ができる方法の１つが，HTTPレスポンスコードを使うことである．ここから監視を始め，徐々にWebのノードやワーカノードといったコンポーネントに監視を広げていくことになるが，常に「このメトリクスはユーザへの影響をどう教えてくれるか」と自問自答するべきである．

ユーザに近いところから監視を始める

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

監視ツールのSaaSサービスを使う．これはツール依存アンチパターンの答えにもなるようなデザインパターンである．執筆者がSaaSの購入を勧める理由は以下の通り．

• 安いから
• 監視ツールの設計を行う人がその道の専門家ではないことが多いから
• 簡単かつすぐに監視の仕組みを立ち上げられるのでプロダクトにフォーカスできるから
• SaaSを使わない合理的な理由が少ないから
  • SaaS監視サービスでは間違いなく足りない場合
  • セキュリティやコンプライアンス上の理由

SaaSを使いたがらない人が挙げる理由のほとんどは，上記の認知コストに行き着く．オンプレの監視の仕組みを成長させるのに必要なお金や時間が，SaaSの監視の仕組みを成長させるお金や時間を超えることは往往にしてあるので検討する余地はある．

監視のデザインパターン４：継続的改善

監視の仕組みを常に改善したり再構築を重ねることで監視を育てていく．

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

監視システムを構築すれば必ずアラートの設定は必要になるのに，アラートはなぜか無視されたり気づかれなかったりする．人間の注意力には限りがあるので，アラートをどうやったらよくできるかという課題はとても重要である．アラートをコンテキストによって２つの意味で使い分けている人が多いので，まずそれを定義する．

• 誰かを叩き起こすアラート
  • 緊急の対応が求められ，でなければシステムがダウンしてしまう
  • 例：全Webサーバがダウンし，メインサイトへの疎通が取れない
• 参考情報としてのアラート
  • すぐに対応する必要はないが，アラートが来たことは誰かが確認すべきもの
  • 例：夜間バックアップジョブの失敗

ここでは前者について取り上げる．よいアラートの仕組みを作るために気をつけるべき項目を以下に示す．

1. アラートにメールを使うのをやめる
2. 手順書を書く
3. 固定の閾値を決めることだけが方法ではない
4. アラートを削除してチューニングする
5. メンテナンス期間を使う
6. まずは自動復旧を試す

それぞれ説明する．

１．アラートにメールを使うのをやめる

メールでアラートを送るのは，受け取る人がうるさくて最もうんざりしてしまう方法で，アラート疲れの原因になる．そこで以下の３つのパターンでアラートの送り先を変える．

すぐに応答かアクションが必要なアラート

これらはSMS，PagerDutyなどに送る．

注意は必要だがすぐにアクションは必要ないアラート

これらは社内のチャットルームに送るのがおすすめ．メールだと受信箱をいっぱいにしてしまいがちなので，他の場所があるならそちらの方がよい．

履歴や診断のために保存しておくアラート

必要なアラートはログファイルにも送る．アラートを保存しておくと，あとでどのアプリケーションやサービスでトラブルが多いかというレポートを送ることができる．

２．手順書を書く

手順書は，アラートが来た時に自分のやるべきことが分かるすばらしい方法である．また，環境が複雑になってくると，チームの誰もが各システムのことを知っているわけではなくなるので，手順書が知識を広めるよい方法にもなる．よい手順書とは，以下のような質問に答えるように書かれたものである．

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

ただし，手順書はなんでもかんでも作ればいいというものではない．例えば，修復手順がコピーアンドペーストでできるような内容ならば，その修復を自動化してアラート自体を削除できる．手順書は，何らかの問題を解決するのに，人間の判断と診断が必要な時に使うものである．

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

「この値がXを超えた」といったアラートに意味がない場合はたくさんある．典型的な例としては，ディスク使用量がある．「空き容量が１０％以下」という固定された閾値を決めてしまうと，ディスク使用量が１１％から８０％まで急激に増えるというケースを見逃してしまう．これを解決する方法の１つに，変化量やグラフの傾きを使うことがあげられる．

４．アラートを削除してチューニングする

うるさすぎるアラートは監視システムの信頼をなくし，アラートを受け取る人はアラートを無視してしまうようになる．しかし，それが監視の仕組みを完全に信頼しない理由にはならないので監視を継続するが，時間が経つとアラート疲れを起こしてしまう．この対策はシンプルでアラートを減らすことに尽きる．以下に示すのは，アラートを減らす際に考えるべき項目である．

• すべてのアラートは誰かがアクションする必要がある状態か
• １ヶ月間のアラートの履歴を見て，どんなアラートがあるか，どんなアクションを取ったか，各アラートの影響はどうか，削除できるか，閾値を変更できるか，監視の内容をより正確にできるかを考える
• アラートを完全に削除するために，どんな自動化の仕組みが作れるか

５．メンテナンス期間を使う

何らかのサービスで作業をする必要があり，そのサービスにはアラートが設定されているなら，アラートをメンテナンス期間に入れる．これにより不要なアラートは飛ばなくなる．ただし，アラートの止めすぎには注意する．作業をしていたら，知らなかった依存性があり，他のサービスで問題が起きることもある．

６．まずは自動復旧を試す

自動復旧はアラート疲れを避けるすばらしい方法なので，アラートを送る前にまずは自動復旧ができるかを考える．

まとめ

• 「入門 監視」を読んだ
• １，２章を読んで，目的にあったツールを選んでいこうと思えた
• レイヤーに関係なく網羅的に監視の話が書かれているので，それぞれのレイヤーで何が監視対象になりうるか全体像が把握できた