【教科書】 ITシステム監視の重要性(その3)

こんにちは。SolarWinds Japanの山田晃嗣<Kozy>です。

前回の(その2)に続き、「【教科書】 ITシステム監視の重要性」の(その3)です。


IT監視の要素技術

理論と概念を学んだ後は、いよいよ核心部分に入ります。このセクションでは、IT監視に使用できる様々な要素技術について説明します。

ここで注目していただきたいのは、いくつかの難解な例外を除いて、世の中にある監視データを収集するための方法は、ここに挙げるリストでおおよそ網羅されているということです。IT監視ソフトウェアベンダーも、以下のような要素技術を使っています。洗練されているのは、頻度、集計、表示の関連性、使いやすさ、集約などの側面です。これについては後ほどご紹介します。

以降のリストは各要素技術の概要であって、残念ながら詳細な説明ではありません。もし詳細な情報が必要であれば、Google先生に聞けばきっと優しく教えてくれるでしょう。

PING
古き良きPingは、すべてのIT監視の偉大な祖先です。Pingは対象となるデバイスにパケットを送信し、デバイスは(稼働していれば)「俺は生きているよ」と言った類の応答を返します。Pingの結果は、デバイスが応答しているかどうか(稼働しているかどうか)、そしてどのくらいの速さで応答したかを示します。

通常Pingを使った監視では、複数のパケットを送信し、戻ってきた正常な応答の数に基づいてアップ/ダウンを計算します。ツールによっては、Pingを1回だけ送信するものもあります。また、Pingを1回だけ送信し、応答がない場合はさらに送信して、デバイスが本当にダウンしているのか、単に動作が遅いだけなのかを検証するものもあります。

SNMP
SNMP(Simple Network Management Protocol)は、いくつかの要素を組み合わせることで、強力なIT監視ソリューションを提供します。

第一に、SNMPは特定のデバイスに関する個々の要素の情報で構成されています。それは例えば、CPU使用率、過去5分間の平均的な秒間送信ビット数、またはエラーのあるフレーム数などです。これらの要素にはそれぞれID(オブジェクトIDまたはOID)が割り当てられており、階層的にグループ化されています。OID全体は、管理情報ベース(MIB)に含まれています。

次に、SNMPサービス(SNMPエージェントとも呼ばれます)がターゲットデバイス上で実行され、それらの各要素とその現在値を追跡します。大量のデータのように見えますが、エージェントはローカルで動作しており、データ量は小さく、管理が容易です。さらに、エージェントは現在の数値を保持しているだけなので、情報を継続的に保存する必要もないため、動作は極めて軽いと言えます。

最後に、エージェントは、SNMP Trapトリガー、またはSNMP Pollリクエストに基づいてデータを提供します。両者の組み合わせにより、事前に設定された収集間隔で(ポーリング)、または特定のしきい値を超えたときに(トラップ)、デバイスに関する情報を収集することができます。

SNMP トラップ
トラップは、内部データポイントの1つがしきい値を超えたときに作動します(そのしきい値はMIB内にも示されています)。トリガーが引かれると、ターゲットデバイス上で実行されているSNMPプロセスは、トリガーされているOIDに関する情報を自ら発信します。SNMPエージェントは、トラップ送信先と呼ばれる環境内の別のシステムに情報を送信するように設定されています。

SNMP ポーリング
監視対象機器を外部機器からポーリングすることで、いつでもOIDのデータを要求することができます。これは、SNMP GETリクエストとも呼ばれます。

WMI
WMI (Windows Management Instrumentation) は、Windows オペレーティングシステムに組み込まれたスクリプト言語です。WMIを使ってさまざまなタスクを実行できますが、IT監視の目的では、ターゲットシステムに関する情報を収集して報告することに重点を置きます。

WMIの利点は、(パフォーマンスモニタのカウンターがそうであるように)適切な権限を持つリモートシステムがWMIスクリプトを実行できることです。監視対象上でエージェントが動作していなくても、かなりの情報を取得できます。

WMIがパフォーマンスモニタより優れている点は、監視対象のWindowsと対話できることです。WMIを介して、ディレクトリを読み込んだり、接続されているディスクの数を取得したり、ログインしているユーザーを調べたりするスクリプトを実行できます。

パフォーマンスモニタカウンタ
パフォーマンスモニタ(Perfmon)のカウンターは、Windows特有の監視オプションであり、システムのエラーや継続的なパフォーマンス統計など、多くの情報を得ることができます。パフォーマンスモニタカウンタには以下の属性があります。

» マシンの名前
» カウンターのカテゴリー(例:プロセッサ)
» カウンターの名前(例:% processor time)
» カウンターのインスタンス(ある場合の例:total)

パフォーマンスモニタのカウンターは、監視対象のサーバーに対する権限を持っていれば外部機器からでもリモートで情報を収集することができます。ハードウェアやオペレーティングシステムがデフォルトで用意している情報に加えて、多くのミドルウェアやアプリケーションも独自のパフォーマンスモニタカウンタを提供しています。これはすなわち、パフォーマンスモニタを使ってミドルウェアやアプリケーションの稼働状況の情報も収集できるということです。

IP SLA
IP SLA (Internet Protocol Service Level Agreements を略したもの) とは、Cisco製の機器(最近では他社製品も)に組み込まれている、VoIP (Voice over IP) の健全性を確保するための包括的な機能群です。

機能面の話をすると、IP SLAはネットワーク機器上の特定の操作を設定し、その操作の実行結果をリモートサーバーに送信させることができます。操作には、以下のような例があります。

» ウェブページが応答しているかどうかの確認
» DNSサーバーが応答し、正しく名前を解決しているかどうかの確認
» DHCPサーバーが応答し、IPアドレスを配布しているかどうか(配布可能なアドレスがあるかどうか)の確認
» 他のIP SLA対応機器との間で擬似的に電話をかけ、ジッター、パケットロス、MOSSなどの通話品質に関する統計情報を収集

IP SLAは、テストを実行するために別のデバイス(あるいはPCやサーバー上で動作するエージェント)をセットアップする必要がなく、ネットワーク・インフラの一部であるデバイスのみを使用するという点で大きな意味を持ちます。ネットワーク上の特定のポイント間のパフォーマンスをテストできることに加え、特定のテスト(DHCPに対するテストなど)は、応答するデバイスが配置されている同じネットワークセグメントの範囲内でのみ実行することもできます。

NETFLOW
標準的なIT監視では、ルーターのWANインターフェイスで1.4Mbpsのトラフィックが通過していることがわかります。しかし、誰がそのトラフィックを使用しているのでしょうか?どのような種類のデータが通過しているのでしょうか?HTTP、FTP、あるいはそれ以外のものでしょうか?SNMPはそれらの情報を提供しません。

これらの疑問に答えるのがNetFlowです。NetFlowでは、「カンバセーション(会話)」という観点から情報を提示します。カンバセーションとは、同じプロトコルを使用する2台のコンピュータ間のデータ転送の1つのセッションを意味します。DesktopComputer_123がFTPでServer_ABCにファイルを送信している場合、これは1つの会話としてカウントされます。同じPCがHTTPを使って同じサーバーのウェブページを閲覧している場合は、別の会話となります。同じPCがYouTubeからビデオをストリーミングしている場合(これもHTTPです)、3つ目の会話となります。

NetFlowデータは、ネットワークの中央付近にある1台以上のルーター(コアを経由しないサイト間通信がある場合は、各遠隔地に1台のルーター)など、会話の途中にあるネットワークデバイスによってキャプチャーされます。この装置は、NetFlowデータを収集し、監視サーバーに定期的に送信します。データの集計、解析、分析は監視サーバーに任されています。

なお、カンバセーションで表示する2台のマシン(この例ではDesktopComputer_123とServer_ABC)を(SNMPなどで)監視する必要はありません。監視するのはそれらの途中にあるコア・ネットワークデバイスだけです。逆に言えば、NetFlowデータをキャプチャーして送信する機能をコア・ネットワークデバイス自体が持っている必要があります。多くの(すべてではありませんが)Ciscoのルーティングデバイスはこれに対応しています。他のブランドやモデルでも対応可能な場合がありますが、確認が必要です。

SQLクエリー
興味深いことに、データベースはそれ単体で重要な監視対象となります。ほとんどのデータベース管理者は「待機」「ロック」「ブロッキング」に関心を持っていることでしょう。というのも、これらが表しているのは、データベースが何か他のことを誰かのためにしていて、ユーザー(またはユーザーの代わりに働くアプリケーション)がデータベースへの情報の出し入れができない時間を表しており、それがデータベースの性能に直結するからです。

その名の通り、このIT監視技術は、データベースに対してクエリーを実行し、データベースサーバー自体のパフォーマンスに関する情報を取り出します。したがって、(一般的には)システムテーブルを照会して、「待機」「ロック」「ブロッキング」のほか、クライアント接続数、1秒あたりのトランザクション数、トランザクションログのサイズなどを調べることになります。

シンセティック・トランザクション
システムやアプリケーションが何時間も停止していたにもかかわらず、ユーザーがそれに気付いて報告しなかったために障害が検出されなかったことほど悔しいことはありません。シンセティック・トランザクション・IT監視は、ユーザーが行うであろうアクションをシミュレートし、そのアクションを定期的に繰り返します。プロセスが失敗したり、予想/要求よりも時間がかかったりした場合、監視システムは警告を発し、実際のユーザーがシステムを利用する前に問題に対処することができます。システムやアプリケーションの負荷が非常に大きく、全体的なパフォーマンスやユーザーエクスペリエンスに影響を与える場合にも警告を発して、その問題を見つけることに役立ちます。

ロギング
"ログファイル監視 "は、通常、4つの異なる、相互に排他的な領域に適用されます。

1. SYSLOG
Syslogは、1台のマシンからUDPポート514で待ち受けるサーバーにメッセージを送信するためのプロトコルです。このプロトコルは、ネットワークやUnix、Linux系ノードを監視する際によく使用されますが、ファイアウォールやIDS/IPSシステムなどのネットワークおよびセキュリティデバイスも同様のメッセージを送信します。

SyslogメッセージはSNMPトラップと似ていますが、SNMPで必要とされるMIB-OID構造に依存せず、比較的自由な形式で表現されている点が異なります。

自由度が高いことに加えて、SyslogはSNMPトラップに比べて「おしゃべり」になりがちです。しかし、Syslogは柔軟性が高い仕組みだと言えるでしょう。SNMPトラップで開発者の事前作業なしに送信できるものはほとんどない一方で、多くのアプリケーションがSyslogメッセージを送信するように設定できるようになっています。

Syslogは、従来のログファイル監視の代わりとして使用することができます。ローカルのログファイルにメッセージを送信する代わりに、Syslogプロトコルを介して外部デバイスにメッセージを送信します。その外部デバイスでは、通常複数のデバイスからsyslogを収集し、それを分析したりトリガーに基づいてアクションを起こしたりします。

2. WINDOWS EVENT LOG
Windowsイベントログは、その名が示すとおり、Microsoft Windowsオペレーティングシステムに特有のものです。イベントログは、ログ「ファイル」ではなく、Windowsマシンに固有のデータベースです。

デフォルトでは、システム、セキュリティ、および(Windows標準の)アプリケーションのイベントに関するほとんどのメッセージがここに書き込まれます。イベントが書き込まれる際の標準的なデータ要素は以下の通りです。

» メッセージ:アプリケーションが制御するイベントメッセージ
» カテゴリー:イベントがどこに記録されるかを指定
» プライオリティ:イベントが記録されるかどうかを決定するために使用
» イベントID:イベントを分類するために使用
» シビアリティ(深刻度):イベントが通知されるかどうかを決定するために使用
» タイトル:イベントをさらに識別するために使用

イベントログ監視は、Windowsのイベントログを監視して、EventIDやカテゴリーなどの組み合わせを探し、一致するものが見つかった場合にアクションを実行します。

3. ログファイルの集約
ログファイルの集約とは、複数のシステムからログファイル(Windowsイベントログを含む)を収集し、それらを中央の場所に集めるプロセスです。このプロセスでは、データ要素が並べられ、すべての日付が同じ列とフォーマットで表示され、ソースシステムが特定されるなど、ログからのすべての情報が「正規化」されます。

このようにデータを組み合わせることで、集約システムはログがどのデバイスから発生したかを追跡することができます。また、管理者はルールを設定することで、何らかのトレンド(ログインの失敗など)を識別することができるのですが、重要なのは単一のシステムではなく全体で発生しているトレンドを識別できることです。あるいは「いつもと違うこと(Anomalies)」を見つけることもできます。これは全体の中の「よく分からないけど普通とは言えない動き(詳細は後述)」と言った類のものです。

4. 特定のサーバー上の個々のテキストファイルの監視
このアクティビティでは、特定のマシンの特定のディレクトリにある特定のファイル(通常はプレーンテキストで、上述したSyslogやWindows Event Logには該当しません)を監視し、文字列やパターンが表示されるかどうかを確認します。一致するパターンが見つかると、警告が発せられます。

もちろん、これよりももっと複雑なこともできます。

» 特定の固定されたファイル名ではなく、特定のパターン(日付など)に一致する名前のファイルを監視する
» 特定の場所にある最新のディレクトリにある最新のファイルを監視する
» 特定のパターンに一致する単語やフレーズ(「文字列」)を監視するのではなく、単語や単語のセットを監視する
» あるパターンが5分間に3回発生したときにトリガーする

複雑さやバリエーションにかかわらず目的は同じで、ファイル内の文字列やパターンを見つけることです。

スクリプト
これは、最も理解しやすい監視方法の一つであり、最も広い範囲をカバーしています。情報を収集するためにスクリプトを実行することは、スクリプト作成者の選択次第で簡単にも複雑にもできます。スクリプトは、同じデバイス上のエージェントによってローカルに実行されその結果を外部のシステムに報告することもできますし、必要な権限によりリモートから実行されることもあります。様々な選択肢がありますが、スクリプトの作成者と監視の専門家の判断で選択されます。

API
実はここにAPIについて掲載することを躊躇しました。一方で、おそらく皆さんは何かの販促資料でAPIについて読むことがあるだろうと思い、それが正しく何を言っているのかを知ってもらいたいとも考えました。ここで注意したいのは、JSON/RESTフレームワークを使ったAPIのことではないということです。JSON/RESTは間違いなく有用ですので、次のセクションでカバーします。

監視製品のベンダーが自社のソリューションに「API」を使用してデータを収集すると言った場合、これは世の中に存在する技術(似非技術も含めて)の中で最も曖昧なものです。基本的に、アプリケーションには「フック」(利用者が独自の処理を追加できるようにする仕組み)が組み込まれています。フックを使うことで、理論的にはデータ要求への応答としてデータを送信することができます。これはこの文書のどこにも書かれていない要素技術に基づいたものです。

これが怪しげな魔法に聞こえたなら、あなたの感覚は間違っていません。このような奇跡的なことを実現するソリューションはほとんどないのです。実はいたって単純なことをしているだけで、それをいかにも凄いことのように見せかけているだけなのです。

このカテゴリーで注目すべき例外は、MicrosoftとVMwareです。その違いは、MicrosoftのAPIは自社のSCOM監視製品でしか利用できないのに対し、VMwareのAPIは公開されていて、複数のIT監視ベンダーが利用していることです。

もしあなたの監視ソフトがこの2社のAPIを利用できるなら素晴らしいことです。そうでない場合は、このソースからのデータを要求して処理するための独自のプログラムを書かない限り、どうしようもありません。

JSON/REST
前節で「API」と言ったときにJSON/RESTを明示的に省いたのは、これも「API監視」とも呼ばれることが多く、私の意見では役に立つ唯一のAPI監視技術だからです。

それにしてもこの技術はいったい何なのでしょう?どのように動作するのでしょう?
REST(Representational State Transfer)とは、システム間でデータを転送する方法のことです。対象となるデータが一般的なテキストであろうと、XMLやJSONなどであろうと関係ありません。RESTでは、特定のURLを指定してアクセスします。通常のWeb閲覧であれば、HTMLウェブページが返ってきますが、RESTでは一連のデータが返ってきます。その特定のURLの例は、次のようなものです。

http://www.myapplication.com/api.php?id=MonitoringCompanies

このWebページにアクセスすると(Webブラウザからでも他のプログラムからでも)、サーバーはデータのセットを返してくれます。

一方、2002年に開発されたJSON(Java Script Object Notation)は、データの構造を指します。「自己記述性」(人間が読めること)と「階層性」(値の中に値があること)を特徴とし、さまざまなプログラミング言語から読み込んで利用することができます。

上記のURLが返すJSONデータは、例えば以下のようになります。

{”Monitoring_Companies”:[

{ “Name”:”SolarWinds,” “Location”:”Austin,” “Website”:”www.solarwinds.com” },

{ “Name”:”Pingdom,” “Location”:”Austin,” “Website”:”www.solarwinds.com/pingdom” },

{ “Name”:”Papertrail,” “Location”:”Austin ,” “Website”:”www.solarwinds.com/papertrail” }

]}

JSON/REST APIを介してアプリケーションを監視できるということは、プログラムがデバイスを監視し、URLを介して渡されたパラメータに基づいて一連のデータや統計情報を提供する準備ができているということです。

これにより、自社のアプリケーションに関するデータを公開したいと考えているベンダーにとって、選択肢が大きく広がります。

同時に、これは(比較的)新しい監視方法であり、データを収集する手段は各ベンダーの実装に大きく依存するため、IT監視ソリューションにとっては、標準化しにくいという課題があります。

アプリケーション・トレース
本書の冒頭で述べたように、昔々(とは言ってもせいぜい10年ほど前の意味)、アプリケーション・トレースはアプリケーションの開発者がコードをスポット的にチェックするためにほぼ限定的に使用されていました。今では、オブザーバビリティ(詳しくは後述)の柱の1つであり、企業全体のインサイトを監視するための重要な技術となっています。

アプリケーション・トレースのメカニズムは様々ありますが目的は同じで、システムを通過する実際のトランザクションの流れを理解することです(前述したシンセティック・トランザクションでは、ユーザーの体感を見ていました)。トレースを行うことで、ウェブインターフェイス、アプリケーション、データベース、後処理のいずれの段階で発生しているかに関わらず、ボトルネックを特定することができます。健全に作られたシステムでは、スローダウンやエラーの原因となっているコードの1行1行にまで迫ることができ、迅速かつ正確なトラブルシューティングが可能です。


次の(その4)にて完結します。