#はじめに
監視ツール、監視SaaSなどITシステム監視について、ツールや仕組みについての記事が多く掲載、議論されている。
しかしそもそもITシステム監視そのものについてはあまり語られる事が無い。
本記事では特定の監視ツールや監視サービスについてではなく
ITシステム監視そのものの定義や意義、監視サービスのあるべき未来について考察する。
#監視とは
プロセス監視や機器監視、アプリケーション監視、ログ監視など監視と呼ばれるものには複数あるが、システム監視の目的はシステムの安定稼働および、システム稼働効率の最適化を行うことである。
#監視の4要素
IT監視システムは以下の4要素の一部もしくは全てを具備している。
収集・判定・通知・分析
単一のソフトやサービスによって全てを実現する場合もあれば、複数のソフトウェアやサービスを組み合わせて機能を満たす場合もある。
##収集
対象システムやセンサー、ネットワーク機器等からデータを集める。
CPU使用率やメモリ使用率、ディスク情報やネットワーク負荷
ログ情報や環境データの収集を行う。
標準的なプロトコルやAPIにより監視ツールなどにデータ提供を行う対象システムや
監視システム独自Agentによって対象システムからデータ収集を行う場合のほか
対象システム自身の状態確認コマンド、統計コマンドにより出力される情報をスクリプトやAgent等により収集する場合もある。
##判定
収集により集められたデータに対して、正常・障害/ノーマル・アラートなどの判定を行う。
収集された生データを使う場合もあれば、生データに対して何らかの算術処理を行った後のデータに対して判定を行う場合もある。
判定では、「イコール/ノットイコール」や「含む/含まない」、「以上/以下（超過/未満）」
などにより、数値判定、文字列判定を行う。
文字列判定では正規表現が用いられる場合もある。
時系列の数値判定では2015年ごろから、近似計算による将来値予測を行いこの予測値に対する判定を行うシステムも登場している。
判定式を論理和・論理積、によって組み合わせ複数の条件による判定や複数の収集データによる判定を行うシステムも存在する。
##通知
判定結果を元に通知を行う通知を行う対象は必ずしも人間である必要は無い。
通知対象として、APIやシステムコマンド、監視対象機器の制御コマンドを通知先とすることによりシステムの自動復旧や、自律動作を可能とすることができる。
全ての判定結果を通知する必要はない。
対人通知を行う意義ある通知は、その通知を元にDR発動やメンテナンスページ切り替えなど
通知を受けた人物の 決断 が必要な場合である。
経緯把握ための通知であればリアルタイムで深夜や業務時間外にプライベートを侵食して通知しても価値はなく、心理的に監視システムに対する嫌悪感を煽るのみである。
意義ある通知設計は監視サービスや監視システムが『オオカミ少年』とならないための重要な要素である。
##分析
収集されたデータや判定の頻度を元にシステムの現状、および将来状態を推測、検討します。
分析では、リソースの時系列的な変化や異なる収集データ同士の相関関係などを読み取る事が重要となる。
適切な分析を行う事で、システムのボトルネックポイントの判断や、ボトルネック対策を行った場合のボトルネック推移の予測、インフラコストの最適化提案などが可能となる。
分析で重要となる能力は経験による勘ではなく、コンピュータサイエンスの正しい知識である
#なぜ可視化するのか
ITシステム監視で対象となるデータは基本的に時系列データと呼ばれる時間により変化するデータである、
瞬間的な値ではなく、時系列によりどのように推移したか
あるいは、複数の収集データで値が変化した際に同時にあるいは連動して推移したデータが無いかを把握するために可視化を行う。
時系列データの変化点を把握するには数値表を眺めるのでなく、グラフ化を行う事によって、変曲点を把握することが容易となる。
ITシステム監視において変曲点は、負荷状況の変化、ボトルネックの顕在化などイベントポイントとして出現することが多いため、この変曲点を迅速に把握するために柔軟な組み合わせ、任意のスケールでの可視化を行うことが重要となる。
#MSPという業態
ITシステムの監視、運用を提供する業態としてMSPが存在している。
しかしながら、日本における多くのMSPが実体として、
MSP（Managed Service Provider）ではなく
MSP（Monitoring Service Provider）と言うべき状況となっている。
MSPは本来運用サービスを提供するものであるが、実体としては監視サービスを提供し、サービス運用についてはエンドユーザの指示に従うような業態となっている。
#次世代MSPの誤解
AWSがMSPパートナープログラムとして、「Next Generation MSP」としてパートナー要件を定義した事によりより高度なナレッジ、システムの自動化、DevOpsの実現などが求められた。
しかしながら、実際に日本で次世代MSPと考えられているサービスはSaaS型の監視ツールの利用、監視アラートの集約サービスの利用など
その視点はどうしてもツールの選定に向いてしまっている。
そもそも、AWSのMSPパートナープログラムの要件を100％達成するにはMSPという業態では困難である。
DevOpsを実現するには監視結果を反映した改修開発を行うためSIer機能
ユーザに適切なナレッジを提供するコンサルティング機能
24-365のカスタマーサポート機能
が必要となる。
#SREが答えでは無い
2015年頃からDevOpsを実現するロールとしてSRE（Site Reliability Engineering）が提唱されるようになった。
GoogleやFacebookのような世界レベルのITサービス企業で取り組まれている役職のためこのSREという言葉に対する期待値は非常に高まっている。
しかしながら、SREとはITサービス企業自身の役割であり、MSPのようなアウトソーサーとして提供する事に向いたロールでは無い。
MSPが考えるべきはSREとなることではなく、ユーザ企業のSREに対してどのような価値を提供するかを考えるべきである。
#知識と技術
2015年頃からのIaC(Infrastructure as Code)の潮流によりコードやプログラミング偏重の風潮が強くなっていると考える。
これはITに限らず、日本社会の全体的な傾向でもあると思われる。
| 論理 | センス |
|---|---|
| 知識 | 技術 |
| 学者 | 職人 |
| コンピュータサイエンス | プログラミング |
本来これらはどちらが優れているではなく、人類が進歩するために必要な両輪である。
一部の天才的とされる人材は1人で両方のスキルを兼ね備える場合もあるが、組織設計においては本来両方が補完関係にあるべきである。
実際にSREが生まれたようなITサービス企業においては、コンピュータサイエンスの学位保持者の採用と、コードコンテストなどによるプログラミングスキルを持った人材の獲得とを並行して行っている。
#MSPがこの先生きのこるには
この考察の1つの答えであると同時に、「きのこる」が書きたかったから生まれたのが最後の本章である。
本章のヒントは、監視の4要素の中に書かれている。
それは 分析 である。
分析で必要となるのはコンピュータサイエンスの知識である。
CPUコアの負荷状態とネットワークインターフェイスのトラフィックとの関連性を見つけるためにはCPUにおけるIO処理が割り込みとして処理されることを理解している必要がある。
システムの応答性能が下がったときに、CPU使用率が下がっているのているという関連から
IOwaitを疑うためには、CPU使用率の定義を知る必要がある。
これらは、プログラミング知識ではなくコンピュータサイエンスの知識である。
これからのMSP事業者は監視システムの 読影を行い
ユーザ企業のSREや開発者、システムオーナーに対して適切なシステム構成やチューニングポイント、ボトルネック要因を提案するIT分析者となるべきである。
そのためには、どのようなツールを使うかではなく、コンピュータサイエンスに基づいて適切なシステム分析を行う事ができるかどうかが重要となる。