Help us understand the problem. What is going on with this article?

我々はなぜ監視を行うのか【第二章】~監視システムチューニング編~

はじめに

【前回】→ 我々はなぜ監視を行うのか【第一章】~監視システム導入編~

【第二章】~監視システムチューニング編~

監視システムを導入したことで、担当者Aは既存の業務から解放され、やや余裕をもって仕事をすることができるようになった。
Aは監視システムに興味と好意が生じ、監視システムについて色々と調べるようになった。


監視には以下の4要素がある
監視論 by @qryuu氏から引用

収集
対象システムやセンサー、ネットワーク機器等からデータを集める。
CPU使用率やメモリ使用率、ディスク情報やネットワーク負荷
ログ情報や環境データの収集を行う。

標準的なプロトコルやAPIにより監視ツールなどにデータ提供を行う対象システムや
監視システム独自Agentによって対象システムからデータ収集を行う場合のほか
対象システム自身の状態確認コマンド、統計コマンドにより出力される情報をスクリプトやAgent等により収集する場合もある。

判定
収集により集められたデータに対して、正常・障害/ノーマル・アラートなどの判定を行う。
収集された生データを使う場合もあれば、生データに対して何らかの算術処理を行った後のデータに対して判定を行う場合もある。

判定では、「イコール/ノットイコール」や「含む/含まない」、「以上/以下(超過/未満)」
などにより、数値判定、文字列判定を行う。
文字列判定では正規表現が用いられる場合もある。

通知
判定結果を元に通知を行う通知を行う対象は必ずしも人間である必要は無い。
通知対象として、APIやシステムコマンド、監視対象機器の制御コマンドを通知先とすることによりシステムの自動復旧や、自律動作を可能とすることができる。

全ての判定結果を通知する必要はない。
対人通知を行う意義ある通知は、その通知を元にDR発動やメンテナンスページ切り替えなど
通知を受けた人物の 決断 が必要な場合である。

経緯把握ための通知であればリアルタイムで深夜や業務時間外にプライベートを侵食して通知しても価値はなく、心理的に監視システムに対する嫌悪感を煽るのみである。

意義ある通知設計は監視サービスや監視システムが『オオカミ少年』とならないための重要な要素である。

分析
収集されたデータや判定の頻度を元にシステムの現状、および将来状態を推測、検討します。
分析では、リソースの時系列的な変化や異なる収集データ同士の相関関係などを読み取る事が重要となる。
適切な分析を行う事で、システムのボトルネックポイントの判断や、ボトルネック対策を行った場合のボトルネック推移の予測、インフラコストの最適化提案などが可能となる。

分析で重要となる能力は経験による勘ではなく、コンピュータサイエンスの正しい知識である

......。
大事なことのように思えたが、担当者Aには、難しくてまだわからなかった。1

しかしそのまましばらく仕事をしていると、以下のような事象に悩まされるようになった。

  • 夜中にアラートが上がって、通知でたたき起こされる。慌てて画面を確認すると、一時的に2秒ほど画面が見れなくなっていただけであり、 すでに復旧していた(ページは見れるようになっていた)

Qiitaのトップページが2秒ほど見れなくなっても、そこまでユーザへの影響はない。
そもそも、Aが起き出して対応するまでにどうしても1分ほどかかる。2秒で復旧させるのは無理だ。

【第1章】のシナリオで出てきた通り、Aは監視設定について、「監視間隔は1秒、一度でも検知したら即異常」という判定を入れていた。
だが、この設定ではいわゆる「誤検知」が発生している。

Aの基準では、「数秒程度ページが見れなかった」というのは「問題がない」という判断基準になる。
だがシステムは、「1秒でもページが見れなかった」という状態を「異常」と判断してしまう。

これは監視システムがポンコツなのではなく、監視システムにAが判断基準を正しく伝えていないことにより発生している問題である。

Aは監視設定を調整し、「監視間隔は10秒、かつ60秒(1分間)継続してページが閲覧できなくなっていた場合にアラートを上げる」という設定に監視設定を調整した。

監視システムを調整したことによりアラートは減り、Aは不要不急のアラートにたたき起こされることがなくなった。
Aは満足した様子で、以前より更にぐっすりと眠れるようになった。

まとめ

  • 監視システムにおけるチューニングの重要性

適切に条件を設定することにより、本当に異常である場合にのみアラートを発生させることができる
監視論における『判定』の要素である)

  • 不要不急の通知は、極力出さないようにする

通知設計が監視設計の一つの肝であると考えている。
今回のように不要不急の通知は、極力出さないような監視設定とする。

今回の監視設定のチューニングは、【第一章】で説明した以下の価値をより高めるものとなる

人力による24/365の目視等を行わなくても、システムがそれを代行し、人間は異常がある状態を検知した時だけ対応すればよくなる

あとがき

現状のAの監視設定も、まだ理想的なものではない。

【次回】-> 我々はなぜ監視を行うのか【第三章】~自動復旧編~


  1. 非常に大事なことですので、皆様は一度リンク先を一読しご理解ください。本連載は「監視論」の記載をベースに進めます。 

Why do not you register as a user and use Qiita more conveniently?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away