ドン・ジョーンズ。 「環境内での統合IT監視システムの作成」第4章監視：データセンターの向こう側

この章では、外部監視と内部監視を組み合わせる方法について説明します。 システムを構築するときに何を探すべきですか、制限は何ですか？ ささいなことを見逃さず、下から上だけでなく上から下まで写真を見る機会を得る方法。





内容



第1章IT環境の管理：間違っている4つのこと

第2章IT管理における個々のサイトの管理慣行の排除

第3章すべてを単一のIT管理サイクルに接続する

第4章監視：データセンターの向こう側

第5章：問題を解決策に変える

第6章：例による統合管理

第4章：監視：データセンターの先を見る

ITはすでに自社のデータセンターを超えており、ほぼすべての組織が1つまたは2つのサービスを外部委託しています。 監視と管理のための独自のホームツールが常にある場合もありますが、ほとんどの場合、監視はデータセンターを超えて継続する必要があることを理解する必要があります。 これは、リモートサービスの配置と、そのようなサービスを使用してユーザーが実際に経験することのより正確な理解に適用されます。

テクニカルメーターとエンドユーザーエクスペリエンス（EUE）の監視

IT監視の従来のアプローチを「内部から外部（または反転）に」と呼びます。 データセンターから開始し、徐々にエンドユーザーに移行します。 図4.1は、典型的な監視システムがDBMSサーバー、アプリケーション、Webサーバー、クラウドサーバーなどのバックエンドでどのように起動するかを示しています。 このような構造を支持する最も合理的な議論は、データセンターに設置された機器を最適に制御できるということです。 データセンター内ですべてが正常に機能する場合、データセンターのサービスを使用するエンドユーザーが非常に満足すべきであると信じるあらゆる理由があります。



図4.1：データセンターからの監視。



ほとんどのSLAはこのアプローチに基づいています。 サービス可用性の特定の値を規定し、メトリクスのしきい値を設定します。データセンターで収集される情報は、CPU、ネットワーク、ディスク使用率などです。 また、要求に対する応答時間、ディスク応答時間、ネットワーク遅延などの低レベルのパラメーターにも関心があります。



このアプローチの最初の前提には非常に不正確なものがあります：建設中に美しいレンガを手に入れた場合、それから家を建てることができるということはありません。 つまり、エンドユーザーが作業中に感じるのは、技術的なデータセンターのメトリックの単純な合計ではありません。 データセンターが正常に機能している場合、ユーザーは通常満足していますが、常にそうであるとは限りません。



明らかに、データセンターの主要なパラメータを監視することは非常に重要ですが、監視および測定する必要があるのはこれらだけではありません 。 現在、業界では、ユーザーが経験していることを直接測定する必要があるという意見があります。 実際、「エンドユーザーエクスペリエンス」またはEUEは、高度なITマネージャーの間で一般的に使用される用語になっています。



別の例を挙げることができます。 あなたがレストランに来たとしましょう：あなたのステーキは調理されていないようです、彼らはあなたに間違ったサイドディッシュと無礼なウェイターをもたらしました。 そして、キッチンにいるマネージャーは、すべてが順調だと考えています。ステーキも野菜も暑く、ウェイターはマネージャーが彼（彼女）を見るたびに彼に微笑んでいます。 彼はキッチンのバックエンドについてのみ考えており、あなたの不当な期待については何も知りません。 レストランでは、この問題は、マネージャーが定期的にホールに行ってゲストに尋ねることによって解決されますが、大丈夫ですか？ これがEUEの監視方法です。内側のキッチンのメトリックを評価する代わりに、レストランの感覚でキューブの山に出て、そこで何が起こっているのかを自分で確認する必要があります。

EUEがSLAを改善する方法

実際、EUEで大きく異なる値のメトリックを設定します。そのようなトランザクションを完了するのに必要な秒数などです。 このメトリックが実際の状況に対応していない場合は、インフラストラクチャの詳細を理解し始めることができます。なぜそうでないのかを理解できます。 また、従来のデータセンターを描く必要があります。 ただし、同時に、「クエリ実行時間」というメトリックや他の純粋に技術的なメトリックを使用する代わりに、「ユーザーの認識」というメトリックを使用して、何かが機能していないとユーザーが思った場合のトラブルシューティングに使用します。 図4.2。 EUEモニタリングがモデルをどのように変えているかを示しています。





図4.2：EUEの監視。



まだしきい値とその他の制限がありますが、それらはすべてEUEが実行された履歴レベルで設定されています。 図に示すように。 4.3。、動作不能なEUEは、エンドユーザーの問題の原因を特定できる測定のより深くより技術的なレベルを理解するための出発点です。





図4.3：悪いEUEの原因の追跡。



実際には、EUEの新たな問題に、バックエンドの具体的な変化が常に伴うわけではありません。 DBMSサーバーの応答時間は1〜2ミリ秒短縮されます。これにより、アプリケーションサーバーがトランザクションを処理するためにさらに0.5秒必要になります。 。 これらの数秒に就業時間の長さを掛けると、1時間以上が失われ、ユーザーは会社の顧客の多くに「今日はコンピューターが遅くなっているのでごめんなさい」と言わざるを得なくなります。 図 4.3。、DBMSサーバーとクラウドコンピューティングサービスが赤旗でゆっくりと応答します。 それとは別に、それらのどれもアラームをトリガーしませんが、それらの共同作業はエンドユーザーに目立つ問題を引き起こします。 通常、DBMSサーバーの小さな変動はアラームをトリガーしません。イベントのカスケード全体が悪いEUEにつながります。 確かにわかっていることの1つは、EUEが予想されたものから逸脱し始めた場合、これは理由の調査を開始する機会です。 問題の原因を探しているだけでなく、定期的な監視を行うだけではないため、インフラストラクチャの運用におけるわずかな逸脱をさらに詳しく調べます。



EUEを測定する機能により、より現実的なSLAを作成できます。 ユーザーに「システムが2秒以内にリクエストに応答することを保証します」と言う代わりに、「そのようなトランザクションは3秒以内に処理されます」と言います。 これは、ユーザーがこれらのことを自分で測定できることを意味します。「入力を押して数えます-1、2、3 ...ああ、うまくいきました！」 このタイプのSLAは、ユーザーフレンドリーで理解しやすいフレームワークを確立します。 彼らはあなたと同じものを測定するので、システムがいつゆっくり動作し始めたかを知っています。



ユーザーの視点からプロセスを測定するツールがあるので、理想的には、ユーザーが気付かないうちに、またはそれに非常に近いシステムパフォーマンスの低下について知ることができます。

方法：合成トランザクション、トランザクション追跡など。

このタイプの監視は必ずしも簡単ではありません。 もちろん、エンドユーザーのコンピューターに監視エージェントを配置するのはそれほど難しくありませんが、エンドユーザーが実際に会社の外部クライアントであるWebアプリケーションをどうするのでしょうか。 エージェント監視ソフトウェアをインストールするという申し出は、アプリケーションのパフォーマンスを測定する機会が得られるようになるだけで、彼らはまったく喜んでいません。



代わりに、最新の監視システムはトランザクション 追跡方法に依存しています。 この場合、最後にコンポーネントを監視すると、特定のトランザクションがシステム全体をどのように通過するかを、開始から完了までの時間を正確に測定して確認できます。 これは、さまざまな詳細レベルで実行できます。 たとえば、ソフトウェアパフォーマンスのプロファイリングを可能にするツールは、個々のソフトウェアモジュールを通じて非常に詳細な情報の追跡を実行できます。 わずかに高いシステム管理レベルでは、トランザクションの開始時間と終了時間のみを追跡できます。



多くの場合、システムの実際の状態を判別するこのアプローチは、システムに合成トランザクションを挿入することで実行できます。 監視システムはクライアントになりすまし、システムにトランザクションを配置します。結果はデー​​タに変更を加えず、無視されます。 これにより、監視システムは、さまざまな操作の実際の実行時間をより詳細に把握できます。 このアプローチを図4.4に示します。



図4.4：トランザクション追跡を使用してEUEを監視する。



これらの方法には多くのバリエーションがあり、これらすべてを実装できる専用ソフトウェアもあります。 要約すると、このアクティビティはすべて、EUEの測定のみを目的としていることを常に覚えておく必要があります。 この観点からは、システムパフォーマンスの状態を理解しようとしたり、問題の主な原因を見つけようとはしていません。 問題があるかどうかを把握しようとしているだけです。

トップダウン監視：EUEからすべての悪の根源まで

EUEは非常に高レベルの診断と見なされます。 彼女はただ「何かがうまくいかなかった」と言っているが、正確には何も言っていない。 理由を理解するには、いつも知っていて愛していた従来の監視システムに戻る必要があります。今回だけは、空の場所を調べません。保証された既存の問題の原因を探します。



ところで、これは特別なソフトウェアを明らかにする必要がある瞬間ではありません -これについては前の章で説明しました。 1枚のガラスですべてを見ることができる監視システムを使用する予定です。 ただし、これは必ずしも特殊なツールを統合する何らかのシェルを意味するものではなく、各システムを表示できる監視システムを意味します。 各コンポーネントのレベルでパフォーマンスがどうあるべきかを正しく理解していれば、そのようなシステムは問題がどこにあるかをすぐに知ることができます。 そして今、あなたは特別なツールを入手して、特定の問題に対処することができます-再び、問題がどこにあり、あなたが見ているコンポーネントが本当にそのソースであることを知っています。

EUEはどこから来たのですか

EUEが期待値から逸脱していることが理解できるバックエンドのステータスを監視する監視システムで、境界値のより慎重な選択を使用できないのはなぜですか？ その理由は、EUEがシステム全体のパフォーマンスを評価するためです。 データベースの実行速度は遅くなりますが、その動作はインフラストラクチャの残りの部分には影響しません。 ルーターの速度が遅くても、必ずしもEUEが悪化するわけではありませんが、他の要因と組み合わせることで分岐点になる可能性があります。 そのため、エンドユーザーの状況を直接確認し、すべての悪の根源を探す必要があります。

エージェント監視とエージェントレス監視

最良の監視方法のそれぞれを支持する多くの議論があります。 エージェントをインストールしますか？ 一部の人々はこれを行い、エージェントが情報を提供する最も詳細な方法を提供すると信じています。 他の人はエージェントのインストールを信じておらず、環境のすべての要素から遠く離れてエージェントが原理的にインストールできると正しく指摘します。 通常、責任の範囲外にあるルーターまたはサービスは、監視ソフトウェアに情報を送信したり、制限付きでサポートしたりしません。

1つのケースでは、図4.5に示すように、エージェントをインストールできます。



図4.5：エージェントを介した監視。



通常、エージェントは中央監視システムに情報を返します。 選択したアプローチに応じて、 原則として 、おそらくスポットモニタリング用のユーザーコンピューター上にも、インストール可能な場所にこれらのエージェントをインストールできます（通常は、これを行わないようにしますが）



一部の監視ソリューションでは、各システムにエージェントをインストールせずに実行できます（どこでもインストールする必要はない場合があります）。 図4.6に示すように、これらのソリューションは通常、外部ツールを使用してシステムパフォーマンスを評価します。





図4.6：エージェントレス監視。



エージェントレス監視が大量のデータを収集できるか、一般にすべてのデータを原則的に収集できるかは、ネットワーク上のコンポーネントの種類と使用されるテクノロジーに大きく依存します。 これは多くのソフトウェアメーカー間の重要な競争ポイントであり、これには細心の注意を払う必要があります。



図4.6の「監視プロバイダー」。 私たちが現代のアプリケーションについて話すなら、私の出発点です。 監視オブジェクトの一部がデータセンターの外部に配置される場合のみ、一部のエージェントと一部のエージェントレス監視に依存するハイブリッドシステムを展開する必要があります。

自分のものではないものの監視

オフィスの外にある機器や責任は、通常の監視が機能しない場所です。 AmazonがElastic Compute Cloud（EC2）の健全性に関する詳細な統計情報を提供する可能性は低く、MicrosoftがWindows Azureに対して同じことを行う可能性は低いです。 SalesForce.comは、WebサーバーのDBMS応答時間値またはCPU使用率パラメーターを送信しません。 サーバーをホストしているホスティング会社でさえ、ルーターで失われたパケットの割合やインフラストラクチャからのその他の統計に関する詳細情報を表示しません。



しかし、実際には、これらの数字はあなたにとって重要です。 クラウドコンピューティングコンポーネント、コロケーションサーバー、SaaSソリューション、またはその他の外部委託コンポーネントに依存するアプリケーションがある場合、これらのコンポーネントのパフォーマンスは、アプリケーションとEUEのパフォーマンスに影響します。 つまり、Amazonにパフォーマンスの問題がある場合、ユーザーにも同じことが言えます。 そして、ここでハイブリッド監視が登場します。 図4.7は、「クラウドコンポーネント」のほとんどの外部委託サービスプロバイダーから主要なパフォーマンス情報を収集する外部監視アプリケーションの外観を持っていることを示しています。 収集されたデータは赤い線で示され、中央監視コンソールに送信されるデータは緑で示されます。



前の章でリストしたものの多くは、1つの写真にまとめられます。

• 単一のビューに表示される内部システムと外部コンポーネントが必要です。 すべてのコンポーネントを単一の監視スペースにアセンブルする機会がない場合、サブシステムをシステムとして使用する方法はありません。
• ハイブリッド監視サービスの主要な競争力のある機能は、監視できる外部コンポーネントの数です。 選択したソリューションが、アウトソースされたサービスや機器を含むすべてを監視できることを確認してください。
• EUEユーザーの期待を追跡することは重要です。これは、外部サービスとユーザーの使用との間に大きな変動がある可能性があるためです。 たとえば、ユーザーがこのサービスを使用していない期間にAzureの応答が遅くなるかどうかをまったく意識する必要はありません。 それに注意を払い、ユーザーが操作中に問題が発生した場合にのみ、そのステータスに関する通知を受け取る必要があります 。

図4.7：ハイブリッド監視。

実際、ほとんどの組織はクラウドコンピューティングに依存できないと感じているため、外部の外部委託コンポーネントを監視するこの方法は重要なポイントです。 「これをどのように管理しますか？」彼らは自問します。「これをどのように監視しますか？」 データセキュリティに加えて、これはおそらく、企業がITポートフォリオに「クラウド」を追加することを検討し始めたときに発生する最も深刻な問題です。 これらは、この方法で監視できます。単一のコントロール画面に「クラウド」を追加する特別な監視サービスを使用します。 これらのようなツールは、ローカルコンポーネントと同じ制御レベルで社外に配置されたコンポーネントを配置し、同様の方法でそれらを監視できるようにします。



一部のベンダーがこのようなソリューションのアーキテクチャを開発するときに選択する興味深い方法。 それらの多くはローカルソリューションを販売しています。これは多くの点で図に示されているものに似ています。 4.7。 実際、プロバイダー側​​でクラウドコンポーネントを監視しますが、同時にこの情報をユーザーに送信します。 そのソリューションは、ローカル機器からデータを収集し、統合された形式で情報を提示します。



しかし、これが唯一の方法ではありません。 図 4.8。 ホストされた監視ソリューションは 、 内部パフォーマンス情報がクラウドに送信され（青色の線で表示）、クラウドがクラウドコンポーネントのヘルス情報（赤色の線）と結合され、Web上の単一のビューに表示されます。ポータルまたはその他の方法。





図4.8：外部のハイブリッド監視。



これは、監視のほとんどの責任から解放されるかなり興味深いモデルであり、ユーザーに提供されるサービスに集中することができます。 しかし、オプションとして検討する価値はありますが、どの組織にとっても適切なモデルになるとは考えないでください。

重要な制限： すべてを制御する必要がある場合

パズルの最後の重要な要素は、すべてを監視することです。 オールオールオール!!! この章で使用したインフラストラクチャを使用して、図4.9をご覧ください。 それに欠けているものはありますか？ 表示されている各コンポーネントを追跡する場合、監視は十分ですか？



図4.9：監視する必要があるすべてのものがここにありますか？



絶対にありません。 このスキームには多くの省略があり、ほとんどの場合、これらはパフォーマンスに大きな影響を与える可能性があります。 図4.10を見てください。ここでは、すべてが少し充実していて詳細になっています。





図4.10：すべてを管理していることを確認してください。



ルーター、スイッチ、ファイアウォール、ディレクトリサービスサーバー、DNSは、内部と外部の両方であり、おそらくそれ以上です。 EUEが通常の値から逸脱し始めた場合は、運が良ければ、すでに悪の根源を探す必要があります。 ただし、監視ソリューションで問題の潜在的な原因を特定できる場合にのみ、これを行うことができます。



このため、今日のほとんどの監視ソリューションは自動検出を提供しており、さらに、コンポーネントを自分で追加する可能性が常にあります。 自動検出は見逃したものをキャッチできますが、それらについてもシステム全体の一部であると想定する人はいません。 マーシャリゼーターやスイッチなどのインフラストラクチャ要素。 ディレクトリサービスとDNS間の依存関係。 ファイアウォールやプロキシなどの潜在的なボトルネック。 これは通常の操作ではすべて重要であり、すべてを1つの図にまとめる必要があります。これにより、システムの一般的な状態が監視されます。

おわりに

監視は、SLAの管理を可能にし、問題の場所を特定し、業務を遂行するビジネスに適した状態にシステムを維持するのに役立つソリューションです。 しかし、従来の監視は、常にビジネスニーズを満たす唯一または最良の方法を意味するわけではありません。 さらに重要なことに、企業はローカルシステムの外部のコンポーネントにますます依存するようになっているため、従来の監視では必要な情報をすべて1つのスペースに収集することはできません。 しかし、これらのタスクはハイブリッド監視システムの能力を超えています。 従来の監視技術の組み合わせ、クラウドシステムからのパフォーマンスデータの取得、およびその他の方法を使用して、単一のビュー、共通のインジケーターパネル、および全体像でシステムの状態に関する情報を収集できます。

次の章では...

次の章では、すべての組織が対処しなければならない基本的な問題、 再現性について説明します。 言い換えれば、問題が解決された後、突然再び発生した場合、どのようにして問題をより速く解決することができますか？ 問題を解決策に変える方法と、今後サービスの提供を改善する方法を検討します。