【Zscaler ZDX】～新UI Experience CenterでZDX Probeを作成してみた～
投稿者：セキュリティ&ネットワーク事業本部 上田
みなさんこんにちは、NI＋Cセキュリティエンジニア 上田です。
Zscalerの運用管理画面は、新しくリリースされた統合プラットフォーム「Experience Center」によって、これまで各サービスごとに分かれていた管理画面が一つに統合されます。
本記事では、新UIを用いたZDXのProbeの作成手順を解説します。「どこに何があるかわからない」という戸惑いや不安を少しでも解消いただけると幸いです。
目次
1.ZDXとは？
2.Experience CenterでのZDX Probeの作成方法
3.おわりに
1.ZDXとは？
ZDXとは、Zscaler Digital Experienceの略称となり、エンドユーザーの視点からクラウドアプリケーションの利用体験（デジタルエクスペリエンス）をリアルタイムで監視・分析するソリューションです。
従来の監視ツールは、サーバーやネットワーク機器といった「点」の状態を見るものが中心でした。しかし、ZDXはユーザーのデバイスからアプリケーションに至るまでの「エンドツーエンド」の経路を可視化します。これにより、ハイブリッドワーク環境などで発生する「Web会議が重い」「アプリの反応が遅い」といったトラブルの原因が、ユーザーのWi-Fiにあるのか、ISP（プロバイダー）にあるのか、あるいはクラウドアプリ側にあるのかを即座に特定できます。
また、ZDXは、以下の3つのデータを組み合わせることで、ユーザー体験を数値化（ZDXスコア）します。
①デバイスのパフォーマンス：CPUやメモリの使用率、Wi-Fiの信号強度など、端末側の状態を把握します。
②ネットワークのパフォーマンス：デバイスからアプリまでの経路をホップバイホップで計測し、遅延が発生している箇所を特定します。
③アプリケーションのパフォーマンス：DNSの解決時間やレスポンスタイムを測定し、アプリが正常に稼働しているかを監視します。
2.Experience CenterでのZDX Probeの作成方法
Probe(プローブ)とは、ユーザーが利用するアプリケーションに関するデータ（遅延、パフォーマンス、ネットワーク経路など）を記録するためのものです。プローブを設定する主な目的やメリットは、ユーザーの端末からアプリケーションに至るまでの通信経路や、アプリケーション自体のパフォーマンスを可視化し、ユーザー体験（体感品質）を正確に評価・監視することにあります。また、プローブは、ZDXスコアを算出するために必要となる、1章から引用すると、② ネットワークのパフォーマンス、 ③ アプリケーションのパフォーマンスのデータ収集に貢献します。
プローブでは、ユーザーの通信を監視するアプリケーションを、以下の様な構成で設定します。
・ Webプローブ（Web Probe）
Webプローブは、特定のWebアプリケーション自体のパフォーマンスやレイテンシを測定するためのプローブです。ZDXスコアの算出に利用されるデータを収集し、ユーザーがWebサービスを利用する際の問題を特定する役割を持ちます。
・ クラウドパスプローブ（Cloud Path Probe）
クラウドパスプローブは、ユーザーのデバイスから設定されたホスト（アプリケーション）までのネットワーク経路（パス）を特定し、パフォーマンスを監視するためのプローブです。経路全体のほか、ホップごとのネットワークメトリック（遅延やパケットロスなど）を測定することで、クラウドサービスへのアクセス時に発生する接続問題を検出・解決するのに役立ちます。
それでは、Probeの設定方法を説明していきますが、Probe設定の前の大前提として、Administration>Entitlements>Digital Experienceの以下「ZDX Enabled by Default」が有効化されているか確認してください。無効化されている場合は、有効化し、Saveで保存します。
Probeの設定に移っていきましょう。
Probeの設定箇所はPolicies>Digital Experience MonitoringのConfiguration配下にあります。
まず初めに、Probeを設定するためのアプリを作成します。
事前に定義されたアプリもありますが、今回はカスタムでアプリを作成していきます。
Custom Apps Collectionの「+」をクリックすると、以下のような画面になります。
Nameを記入し、ApplicationTypeはCustomを選択し、Saveにて保存します。
※Enable Real User Monitoringは、デバイスのWebブラウザを介したアプリケーションとのユーザーメトリクスを収集します。必要に応じてEnableにします。
Custom Applicationの下に、先ほど作成したカスタムアプリが作成されていることが確認できます。
それでは、Web Probeから作成していきます。
上記の画面で、画面下方のAdd Probeをクリックします。
AddProbeをクリック後、以下の画面でEnd User Webを選択し、Nextをクリックします。
以下の画面にて、それぞれの項目を設定していきます。
・Name:名前を設定
・Run Frequency (minutes):プローブ実行頻度を設定します。※デフォルトのプローブ実行頻度は、ご契約プランによって異なります。
・DestinationURL:Web Probeが要求するアドレスを入力します。
続いて、プロービング条件を記入します。
ここでは、複数のユーザーグループ、特定の場所や部署のユーザー、またはこれらの組み合わせを監視するようにプローブを設定できます。
Exclusion Criteriaにて、除外条件も適用できます。
たとえば、特定のユーザーまたはデバイスのプロービングを除外することができます。
追加のパラメータにて、以下の設定も可能です。
・Request Header(任意) ：リクエストヘッダーの名前と値を入力します。複数の名前と値のペアを入力する必要がある場合は、「Add More」をクリックして追加します。これは、プローブの一部として渡すHTTPリクエストヘッダーをカスタマイズ出来ます。たとえば、セキュリティトークンを渡すためのヘッダーの認証を指定できます。
・HTTP Response Status Codes ：特定のHTTPステータスコードを入力します。デフォルトのリストにないHTTPコードは、100～599の範囲の任意の数値を入力することで追加可能です。デフォルトでは、1xx（情報）、2xx（成功）、3xx（リダイレクト）のコードが適用されます。
・Number of Attempts：監視要求が失敗とみなされるまでの試行回数を指定することができます。
・Timeout (seconds)：タイムアウト値を入力します。デフォルト値は60秒です。
・Follow Redirect ：リダイレクトのプローブについて、有効または無効にします。リダイレクトの発生するサイトをProbeする場合は、有効にします。
・Maximum Redirects:これは、プローブがHTTPリダイレクトを追跡しようと試みる回数を指定します。この回数を超えると、失敗とみなされます。デフォルトは5回です。定義済みのアプリケーションでは、リダイレクト回数を変更することはできません。Follow Redirectが無効になっている場合、最大リダイレクト数も無効になります。
※定義済みのアプリケーションでは、上記について一部設定不可のものがございます。
記入が完了したら、次へをクリックして設定内容を確認します。
すべての設定が正しければ、SubmitをクリックしてWebプローブを作成します。
カスタムアプリのWeb Probeが作成されていることが確認出来ました。
下記の画面でWeb Probeを有効化したい場合は、赤枠にてステータスをEnableに変更すると有効化が可能です。
続いて、Cloud Path Probeを作成していきます。
上記の画面右上の、AddProbeをクリックします。
Add to Applicationにて対象のアプリを選択し、
End User Cloud Pathを選択したのち、Nextをクリックします。
以下の画面にて、それぞれの項目を設定していきます。
・Name:名前を設定
・Follow Web Probe:追跡するWebプローブを選択します。(選択推奨)
・Run Frequency (minutes):制限の中でプローブ実行頻度を設定します。※デフォルトのプローブ実行頻度は、ご契約プランによって異なります。
・Cloud Path Host:クラウドパスホストのアドレス(FQDN or domain or IPv4/IPv6)を入力します。
Web Probeと同様に、Probing CriteriaとExclusion Criteriaは必要に応じて設定します。
Additional Parametersでは、以下の設定が可能です。
・Protocol:Adaptive、ICMP、TCP、UDPから選択できます。Adaptiveモードを使用すると、プローブの実行ごとにTCP、UDP、ICMPのプロトコルが試行され、Cloud Path（ネットワーク経路）の各レグ（区間）において、最も遅延やパケットロスが少ない最適なプロトコルが自動検出されます。これにより、経路内で複数のプロトコルが組み合わされて使用されることもあります。※Adaptiveモードは非常に有効な設定ですが、ZPA経由でアクセスする内部アプリケーションに対してはサポートされていません。
・Packet Count:ホップ検出ごとに送信されるプローブパケットのうち、TTL値が同じものの数です。デフォルト値は5パケット、最大値は20パケット、最小値は3パケットです。
・Interval:同じTTLを持つプローブパケット間の時間間隔のことです。TTLが段階的に変化するプローブパケットは、この時間間隔内で均等に送信されます。反復回数またはサイクル数は、設定されたパケット数によって決まります。デフォルト値は1000、最小値は1000、最大値は10000です。
・Timeout:プローブパケットからの応答を待つ時間であり、応答がないとパケットが失われたとみなされます。デフォルト値は1000、最小値は500、最大値は5000です。
※・Force Reverse Cloud Path in Trusted Network
ネットワーク機器によって順方向のクラウドパスがブロックされており、設定変更による解消が難しい場合にチェックを入れます。これを有効にすることで、逆方向のクラウドパスを実行し、遅延（レイテンシ）のメトリクスを正常に取得できるようになります。
パラメータ値を記入後、Nextをクリックします。
設定に問題がなければ、Submitをクリックします。
対象のカスタムアプリに、Cloud Path Probeが設定されていることが確認できます。
対象のアプリのProbeを有効化するため、赤枠内をクリックし、Enableに変更します。
有効化されると、以下の様な表示になります。
ユーザーのZDXについては、Analytics>Digital Experience Usersにて、UsersOverviewから、Applicationをフィルタリングして確認可能です。(ユーザーも指定する場合、Usersから指定可能です。)
ユーザーエクスペリエンスを確認したいアプリを選択します。
選択したアプリにヒットしたユーザが表示されました。
ユーザーをクリックしてみます。
ユーザーのデバイスの詳細情報や、対象アプリにまつわるZDXスコアなどが表示されました。
下にスクロールしていくと、Web Probeで収集されたPageFetchTimeや、
Cloud Path Probeで収集されたHop情報が確認できます。
※Probeの設定項目のでデフォルト値は、ライセンスにより異なる場合がございます。
※Probeに関する詳細情報は公式ドキュメントも合わせてご確認ください。
https://help.zscaler.com/zdx
おわりに
本記事では、Zscalerの新統合プラットフォーム「Experience Center」における、ZDX（Zscaler Digital Experience）のプローブ作成手順について解説しました。
最初は必須の条件（例：「すべてのユーザー」や「特定の大きなグループのみ」）だけを設定し、確実にパフォーマンスデータが収集できているかを確認し、データが集まり始めた後、特定の拠点や部門にターゲットを絞って分析したい場合は、徐々に「AND」条件（例：AND「特定の部門」）を追加して対象を狭めていくと、設定ミスによるデータの欠損を防ぐことができます。
また、プローブを設定することにより、プローブによって収集されたパフォーマンスデータ（遅延、パケットロス、ZDXスコアなど）を基に、それぞれの値が特定のしきい値に達した際に、アラートをトリガーさせることも可能です。
Webプローブとクラウドパスプローブを適切に設定することで、デバイス・ネットワーク・アプリケーションの各観点からエンドツーエンドの通信状態を可視化できるようになります。本記事の手順を参考に、ぜひ自社環境でのZDX運用にお役立てください。
なお、ZDXに関連する内容として、過去のテックブログでは、新UI「Zscaler Experience Center」の管理画面を紹介した記事や、プローブなどで収集した情報を活用してトラブルシューティングを支援する「ZDX Copilot」の検証記事も公開しています。ZDXの設定後にどのような形で情報を確認・活用できるのかをイメージする参考として、ぜひあわせてご覧ください。
【Zscaler】新しい統合ポータルExperience Centerを触ってみた！
Zscaler ZDX Copilotで運用はどう変わる？～AIを活用したトラブルシューティングをちょこっと検証してみた～
最後までお読みいただきありがとうございました。
