Citrix監視ガイド：メトリクスとアラート

紹介

Citrixのパフォーマンス問題は、完全な停止から始まることはほとんどありません。ログオンが徐々に長くなったり、1つのVDAが他のVDAから離れたり、接続の失敗が増えたり、セッションのレイテンシが予測可能な時間に上昇することがあります。効果的な監視は、ITチームがこれらの変化を早期に検出し、孤立した症状をより広範なインフラストラクチャ、ネットワーク、またはキャパシティの問題と区別するのに役立ちます。

この記事では、管理者がCitrixの問題をより効果的に診断するのに役立つツール、指標、および早期警告サインについて考察します。

Citrixモニタリングでカバーすべきレイヤーの種類は何ですか？

Citrix Virtual Apps と Desktop に考慮すべき複数の密接に関連したコンポーネントがあります。ユーザーセッションは、アプリやデスクトップが使用可能になる前に、ブローカー、認証、VDA、Windows サービス、ユーザープロファイル、GPO、ストレージ、アプリケーション、ネットワーク接続を含むことができます。良好な Citrix モニタリングには、4 つの微妙な点への可視性が必要です。

セッション層では、管理者はユーザーが接続できるかどうか、ログオンにかかる時間、セッションが引き続き応答するかどうかを知りたいと考えています。

Citrixの配信レイヤーでは、監視により、マシンが稼働して登録されていること、接続が失敗していること、そしてワークロードがどのようにバランスされているかを検出できます。

インフラストラクチャーレベルでは、CPU、メモリ、ストレージ、およびWindowsサービスをテストして、ホスティングシステムが対応可能であることを確認できます。

ネットワーク/歴史的なレベルで、レイテンシーがセッションの応答に影響を与えていないこと、またストレージやその他のリソースへの需要が時間とともに膨れ上がっていないことを確認する必要があります。

問題は、利用可能なすべてのカウンターを追跡することではなく、症状からおそらく根本的なインフラ層まで問題を追うことです。

各ユースケースに役立つツールは何ですか？

どの監視カテゴリも、すべてのアプリケーションやサービスに対して同じくらい良い洞察を提供することはありません。最適なツールセットは、あなたが見たいものやトラブルシューティングしたいものによって異なります。

Citrix Monitor and Director

これはCitrixの独自の監視ツールが最初に見るべき理にかなった場所です。

Citrix Monitor for Citrix DaaS と Director for Citrix Virtual Apps and Desktops は、セッション、接続およびマシンの障害、ログオン時間、負荷、マシンの利用率、マシンの健康状態についてお知らせします。時間の経過に伴うトレンドを表示できるため、現在のパフォーマンスを特定の時点と比較するのではなく、過去のデータと比較することができます。

この監視は、監視プロセス自体に光を当てます。

例えば、Citrixはあなたに提供できます ログオンにかかる時間の内訳 遅延が発生する場所: ブローカー、マシンの起動、HDX、ログオンスクリプト、グループポリシー、認証など。

ユーザーの苦情「ログオンが遅い」から、より有用なトラブルシューティングの質問に進むためのはるかに良い方法です：ログオンプロセスのどの部分が本来よりも長くかかっていますか？

インフラストラクチャとサーバー監視

Citrixの診断は、基盤となる配信プラットフォームの監視を置き換えることはありません。

サーバー監視は、持続的なCPU使用率、メモリ圧力、ディスクアクティビティ、ストレージ容量、奇妙なプロセスの動作を示すことができます。これらの読み取り値は、問題がCitrixで見られる場合に特に価値がありますが、原因はスタックの深い部分にあります。

ログオン時間の増加をどのように調査するか考えてみてください。ストレージのレイテンシも高い場合は、プロファイルとストレージを確認する必要があります。サーバーに問題がないがログオン時間が長くなっている場合は、サーバー認証、グループポリシー、または別の配信要因がより可能性が高いです。

インフラストラクチャの履歴監視 また、キャパシティプランニングにも役立ちます。サーバーの崩壊の数日前や数週間前にリソース消費が徐々に増加することは、コンポーネントを実際に停止させることなく、エンドポイントやホストに限界があることを示しています。

ネットワーク監視

Citrixによるアプリケーションとデスクトップの配信は、ユーザーデバイスとホスト間の良好なネットワーク接続に依存しています。

ネットワーク監視は、サーバー監視では説明できない遅延、混雑、帯域幅、信頼性の低下、またはサイト関連の問題の増加を示すことがあります。

Citrixセッションパフォーマンス分析は、ICAレイテンシのようなメトリクスを示すこともあります。 ICA 往復時間 (RTT) フレームレートと消費された帯域幅対無料帯域幅。

このデータは、ユーザーが接続できるが、アプリケーションやデスクトップが遅く表示されると言う場合に特に重要です。

デジタル体験とフルスタック監視

一部の環境では、インフラの可用性以上のことを考慮する必要があります。

デジタル体験監視と合成監視は、ログイン、アプリケーションの起動、取引の完了などのユーザー活動を模倣または監視することができます。サーバーが応答しているだけを見るのではなく、サービスがユーザーのために機能していることを確認することが目標です。

その区別は重要です。なぜなら、良いインフラストラクチャは良いユーザーエクスペリエンスを生み出さないからです。大規模な環境では、CitrixセッションをVDA、Windowsリソース、Active Directory、ストレージ、アプリケーションサーバー、ネットワークパスにリンクするフルスタックの可観測性プラットフォームを活用することもできます。

しかし、あなたはおそらくさらに多くのダッシュボードを望んでいないでしょう。監視プラットフォームは、可能性のある原因を絞り込み、管理者を変更されたレイヤーに導くときに真価を発揮します。

最も重要な指標の種類は何ですか？

Citrixプラットフォームから利用可能なカウンターは数千あります。最も有用な指標は、ユーザーエクスペリエンス、インフラストラクチャの健康、または特定の容量の変化に関連するものです。

ログオン時間

ログオン時間は、配信チェーンの複数の領域を明らかにするため、最も強力なユーザー中心の指標の一つです。

総ログオン時間は主要な指標ですが、診断中に詳細を隠す可能性があります。Citrixは、ブローカー、マシンの起動、HDX接続、ログオン認証、プロファイルの読み込み、ログオンスクリプト、およびグループポリシー処理を区別できるようになります。

プロファイルの読み込みにかかる時間が延長されると、フォーカスはプロファイル管理ストアに移ります。グループポリシーの処理が長引くと、検査は他の場所に移ります。遅いマシンの起動は、VDA、ホストシステム、または仮想化プラットフォームをフレーム内に残します。

総合的な期間は何かが異なることを示していますが、フェーズの内訳はどこが異なるかを明らかにします。

セッションの応答性

確立されたセッションは、応答性のあるセッションの指標ではありません。

ICA RTT、ICAレイテンシ、フレームレートおよび帯域幅のメトリクスは、接続されたデスクトップまたはアプリケーションが正常に動作しているかどうかを判断するために使用できます。

コンテキストは依然として重要です。もしあるオフィスのユーザーだけがパフォーマンスを失っている場合、ネットワークパスに問題がある可能性が高いです。

接続と機械の故障

接続の完全な喪失は緊急に対処する必要がありますが、その傾向は単一のイベントよりも意味がある場合があります。

接続がほとんど失敗しない背景の中での上昇は、ほとんどのユーザーが接続されたままであっても、ゆっくりと浮上している問題の指標となる可能性があります。

管理者は、障害の分布を調査する必要があります。個々のボックス、配信グループ、オフィス、または期間は、すべての障害のリストよりもはるかに有益な場合があります。

同時セッションと負荷

同時セッション数はほとんどすべてのインフラストラクチャメトリックの背景にあります。

非常に大きなログイン急増による大きなCPUスパイクは、単に需要の増加です。ユーザーに変化がないのにプロセッサの需要が同じように増加するのには別の原因があります。

計画には三つの要素を考慮する必要があります。

セッションボリューム → ホスト負荷 → 応答性

セッション数がホストの負荷や応答時間の増加に対応して増加しない場合、システムはそれをサポートできる可能性があります。

同じ数のセッションがより大きなプロセッサ負荷、メモリ競合、またはレイテンシをもたらす場合、ワークロードに他の何かが変化したことになります。

CPU、メモリ、ストレージ

CPU、メモリ、ストレージの利用状況を個々のパーセンテージではなく、パターンの観点から考えてください。

CPUを使用している場合、短いブリップは心配する必要がないかもしれません。持続的な使用、繰り返しの飽和、基準の増加、または他のホストと比較してプロセッサ時間を消費しているホストは、はるかに重要です。

メモリは視点からも見ることができます。高いRAM使用は、継続的な成長、急激な使用、異常なホスト間の違い、またはスパイク後にRAMが通常の状態に戻れない場合にのみ懸念事項です。

ストレージは、容量とパフォーマンスの監視の両方を必要とします。空き容量の減少は明らかなパフォーマンスリスクであり、高いディスクレイテンシやストレージの競合は、利用可能な容量がある場合でも、プロファイル、アプリケーションの起動、およびセッションの開始を遅くします。

Citrixの問題に直面する前の早期警告サインは何ですか？

Citrixのパフォーマンス問題は、障害に変わる前に偏差として現れることが多いです。したがって、最も早い指標は、単一のカウンターが閾値を超えるのではなく、複数のカウンター間の相関の変化です。

早期警告サイン	次に何を調べるか
ログオンが徐々に遅くなっています	ログオンフェーズ、プロファイル、グループポリシー、認証およびストレージ
接続の失敗が低いベースラインから増加しています	マシン、デリバリーグループ、最近の変更とネットワークの動作
リソースのピークは毎日同じ時間に発生します。	ログインの混雑、スケジュールされたジョブ、アプリケーションと利用可能な容量
一つのホストが繰り返し他のホストとは異なる動作をする	プロセス、サービス、構成とワークロードの分配
セッションのレイテンシが上昇する一方で、ホストリソースは正常のままです。	ネットワークパス、エンドポイントの場所、帯域幅
CPUまたはメモリが追加のユーザーなしで上昇します	アプリケーション、プロセス、パッチ、および構成変更
無料ディスクスペースは予測可能に減少します	プロファイル、ログ、一時データおよびアプリケーションストレージ
更新後にパフォーマンスが即座に変化します	最近のパッチ、ポリシー、アプリケーションまたは構成の変更

共通の要素は、期待される基準からの逸脱です。IT専門家が「この値は高いですか？」という質問と「なぜ基準と異なるのですか？」という質問を並べて考えると、監視がはるかに効果的になります。

なぜ基準にもっと焦点を当てるべきなのか、固定しきい値よりも？

固定の閾値は依然として必要です。管理者は、ディスクが不足する前、CPUが飽和状態に達する前、サービスが失敗して可用性に影響を与える前に警告を受ける必要があります。

しかし 包括的な単一の閾値 すべてのCitrix環境に適合しません。

ユーザーのログオンを完了するのに通常15秒かかる環境があり、そのメトリックが25秒以上に近づいているとしましょう。それは調査に値する領域であり、たとえ組織が30秒をアラートの閾値として定義していてもです。

異なる環境では、ログオン速度が通常30秒前後になる場合、その同じ数字はほとんど問題にならないでしょう。これは、異なる絶対値が異なる状況で非常に異なる意味を持つことの別の例です。

通常の機能では、ベースラインは以下のことを警告できます：

• 遅いパフォーマンスの変更
• ポストアップデートジャンプ
• ピーク使用時間の変更
• 増加する作業負荷
• サーバーのような違い
• 建物の収容能力の制約

アラート付きのベンチマークはシンプルです：異常な変化と絶対的な制限にアラートを出します。

あなたのITチームはどのようにしてCitrixのメトリックを相関させることができますか？

個々のCitrixメトリックは、インフラストラクチャとネットワークの動作に関連付けられたときに、その価値を本当に示します。これらの一般的なペアリングについて考えてみてください：

Citrixの症状	相関する証拠	調査方向
ログオンが遅くなります	ディスクのレイテンシも上昇します	プロファイル、ストレージおよびディスクI/O
ログオンが遅くなります	CPU、メモリ、ストレージは正常のままです	認証、GPO、プロファイル、ブローカーまたはその他のログオンステージ
セッション応答が劣化します	ホストの健康は安定しています	ネットワークパス、帯域幅、またはエンドポイントの場所
CPU使用率が上昇します	同時セッション数は変更されていません	プロセス、アプリケーションの変更、パッチまたはスケジュールされたワークロード
1つのVDAはパフォーマンスが悪いです。	比較可能なVDAは通常のままです	そのマシン上のローカルサービス、設定、またはワークロード
変更後に失敗が増加します	以前のベースラインは安定していました	最近の更新、ポリシーまたは設定の後退

これにより、IT管理者は各アラートを個別に処理することがなくなります。むしろ、それは根本原因分析の次の段階になります。

症状 → 関連メトリック → 影響を受けるレイヤー → 考えられる原因

それが監視データを持つことと、実際にそれを効果的に活用することの違いです。

Citrixアラートをどのように設定すべきですか？

良いアラートは、サービスレベルが低下する前に管理者が行動を起こすために十分早く警告することができます。ログオン時間、同時セッション、失敗、サーバーリソース、ストレージ効率、セッション応答性の基本レベルを設定します。この情報を使用して、警告状態と重大状態を定義します。

アラートは、管理時間を確保しつつ、通常からの重要な変化を示す必要がありますが、重要なイベントは行動を待つことができません。

Citrixは、複数の対策とデータに対する警告および重要なアラートポリシーをサポートしていますが、静的な閾値は、傾向と応答の精度に関する事前情報と併用することで最も効果的です。

アラートの最適な価値は、管理者を条件付け、重要な閾値の超過を見逃すことにつながる過剰なアラートを作成することなく情報を提供することです。迅速に繰り返されているのか、常に正常値を超えているのか、または異常なのかに焦点を当ててください。

最高のCitrix監視ワークフローとは何ですか？

ユーザーは「Citrixが遅い」と不満を言っています - 一度に多くの設定が変更されると問題を特定するのに時間がかかることがあります。明確に定義されたワークフローは、修正を試みる前に問題を絞り込むことに集中するのに役立ちます。

1. 範囲は何ですか？

特定のユーザー、複数のユーザー、1つのアプリケーション、1つのVDA、1つの配信グループ、1つの場所、またはすべての環境に影響していますか？

範囲はすぐに多くの潜在的な原因を除外します。

2. ステージは何ですか？

接続前、ログイン/認証中、アプリケーション起動中、またはセッション内にいるときの遅延ですか？遅いログインと遅いセッションは異なるものです。

3. Citrix特有の手がかり

セッション情報、接続失敗、マシンの故障を検索する VDAの失敗/エラー ログオンフェーズおよびその他のセッションパフォーマンスカウンター。

これにより、Citrixがすでにどの段階が遅れているか、または劣化しているかを示しているかどうかがわかります。

4. インフラストラクチャとネットワークデータを相互参照する

Citrixのデータを同じ期間のCPU、メモリ、ストレージ、ネットワークカウンターと照合します。可能な限り、互いにではなく良好なマシンと照合してバイアスを避けます。

過去を振り返る

この行動はどのくらい続いていますか？これはWindowsの更新、アプリケーションのアップグレード、グループポリシーの変更、プロファイルの変更、またはインフラの変更の後に始まりましたか？

現在の状況を過去のパフォーマンスと比較してください。突然の急落のように見える状況は、長期的なトレンドの延長である可能性があります。

これにより、繰り返し可能な手順が提供されます。

症状 → 範囲 → ステージ → 相関メトリック → 最近の変化 → 可能性のある原因

Citrix Monitoring: それはいつアーキテクチャの問題になりますか？

監視の複雑さは、Citrixを置き換えるべきだという意味ではありません。

一部の大規模または複雑な展開では、Citrixの仮想化、アプリケーション配信、HDX、および管理機能が依然として必要です。そのような環境では、マルチレイヤー監視はアーキテクチャ全体を機能させるためのパラダイムの一部に過ぎません。

監視が異なる問題を明らかにする場所は、このアプリケーションの配信に必要以上に広範囲なアーキテクチャであるということです。

それは、Windows内で公開するのが非常に簡単な配信に対して、大量のインフラストラクチャと管理の労力を費やしているときに始まります。

指標は次のようになります：

• 運用の労力があまりにも多くの提供エンティティに分散されています。
• この展開に対してこれほど厳重に監視する必要はありません。
• シンプルなアプリケーションの公開に関するインフラがあまりにも多すぎます。 リモートアクセス
• ユーザーはアプリケーションにアクセスするためにブラウザまたはRDPアクセスが必要です。
• 管理コストとインフラストラクチャの影響が深刻な問題となる

要するに、それはもはやトラブルシューティングの質問ではありません。それはアーキテクチャの質問です。質問は「このCitrix環境をより良く監視するにはどうすればよいか？」から「このユースケースはまだアーキテクチャを必要としていますか？」に移行したかもしれません。

TSplusはCitrixの代替となる方法は？

Citrixの監視は、インフラストラクチャと管理の労力が、リモートユーザーにWindowsアプリケーションやデスクトップを公開するための比較的単純な要件に対して不釣り合いになっている時期を明らかにすることができます。

その状況では、問題は監視の改善よりも、配信アーキテクチャが実際のユースケースにまだ合致しているかどうかに関するものである可能性があります。

TSplus リモートアクセス RDP互換接続またはHTML5ウェブポータルを通じて、マルチユーザーアプリケーションおよびデスクトップ配信のためのよりシンプルなアーキテクチャを提供します。これは、フルCitrix環境の広範な仮想化および管理レイヤーなしで、Windowsアプリケーションおよびデスクトップへの簡単なアクセスが必要な組織に適しています。

結論

効果的なCitrixの監視は、利用可能なすべてのカウンターを収集することよりも、重要なカウンターがどのように関連しているかを理解することに関するものです。ログオン時間、セッションの応答性、失敗、ホストリソース、ストレージおよびネットワークの動作は、歴史的なベースラインや互いに比較することで最も有用になります。

その相関関係は、ITチームがあいまいな症状から影響を受けたレイヤーと考えられる原因に移行するのに役立ちます。また、問題が修正が必要なパフォーマンスにあるのか、運用の複雑さがより広範なレビューに値するアーキテクチャにあるのかを明らかにすることもできます。