製品ドキュメント
高度な概念

Citrix ADM を使用して Citrix Cloud™ ネイティブネットワーキングのトラブルシューティングを行う

June 16, 2026
寄稿者: 
C C

概要

このドキュメントでは、Citrix ADM を使用して Kubernetes マイクロサービスアプリケーションを配信および監視する方法について説明します。また、CLI、サービスグラフ、およびトレースを使用して、プラットフォームチームと SRE チームがトラブルシューティングできるようにする方法についても詳しく説明します。

アプリケーションのパフォーマンスと遅延の概要

TLS 暗号化

TLS は、インターネット通信を保護するために設計された暗号化プロトコルです。TLS ハンドシェイクは、TLS 暗号化を使用する通信セッションを開始するプロセスです。TLS ハンドシェイク中に、通信する両側はメッセージを交換して、互いを認識し、互いを検証し、使用する暗号化アルゴリズムを確立し、セッションキーに合意します。TLS ハンドシェイクは、HTTPS の動作の基礎となる部分です。

TLS と SSL ハンドシェイク

SSL (Secure Sockets Layer) は、HTTP 向けに開発された元の暗号化プロトコルでした。TLS (Transport Layer Security) は、しばらく前に SSL に取って代わりました。現在、SSL ハンドシェイクは TLS ハンドシェイクと呼ばれていますが、「SSL」という名前は依然として広く使用されています。

TLS ハンドシェイクはいつ発生しますか？

TLS ハンドシェイクは、ユーザーが HTTPS 経由で Web サイトにアクセスし、ブラウザが最初に Web サイトのオリジンサーバーにクエリを開始するたびに発生します。TLS ハンドシェイクは、API 呼び出しや DNS over HTTPS クエリを含む、他の通信が HTTPS を使用するたびにも発生します。

TLS ハンドシェイクは、TCP ハンドシェイクを介して TCP 接続が開かれた後に発生します。

TLS ハンドシェイク中に何が起こりますか？

  • TLS ハンドシェイク中に、クライアントとサーバーは共同で次のことを行います。
    • 使用する TLS のバージョン (TLS 1.0、1.2、1.3 など) を指定します。
    • 使用する暗号スイート (次のセクションを参照) を決定します。
    • サーバーの公開鍵とSSL証明書認証局のデジタル署名によって、サーバーのIDを認証します。
    • ハンドシェイク完了後に、対称暗号化で使用するセッションキーを生成します。

TLSハンドシェイクのステップとは何ですか？

  • TLSハンドシェイクは、クライアントとサーバー間で交換される一連のデータグラム、つまりメッセージです。TLSハンドシェイクには複数のステップがあり、クライアントとサーバーはハンドシェイクを完了し、その後の通信を可能にするために必要な情報を交換します。

TLSハンドシェイク内の正確なステップは、使用される鍵交換アルゴリズムの種類と、両側でサポートされる暗号スイートによって異なります。RSA鍵交換アルゴリズムが最もよく使用されます。その手順は次のとおりです。

  1. 「クライアントハロー」メッセージ：クライアントは、サーバーに「ハロー」メッセージを送信してハンドシェイクを開始します。このメッセージには、クライアントがサポートするTLSバージョン、サポートされる暗号スイート、および「クライアントランダム」として知られるランダムなバイト列が含まれます。
  2. 「サーバーハロー」メッセージ：クライアントハローメッセージへの応答として、サーバーはサーバーのSSL証明書、サーバーが選択した暗号スイート、およびサーバーによって生成される別のランダムなバイト列である「サーバーランダム」を含むメッセージを送信します。
  3. 認証：クライアントは、サーバーのSSL証明書を発行した認証局で検証します。これにより、サーバーが主張する通りのものであること、およびクライアントがドメインの実際の所有者とやり取りしていることが確認されます。
  4. プリマスターシークレット：クライアントは、もう1つのランダムなバイト列である「プリマスターシークレット」を送信します。プリマスターシークレットは公開鍵で暗号化されており、サーバーによって秘密鍵でのみ復号化できます。（クライアントはサーバーのSSL証明書から公開鍵を取得します。）
  5. 秘密鍵の使用：サーバーはプリマスターシークレットを復号化します。
  6. セッションキーの作成：クライアントとサーバーの両方が、クライアントランダム、サーバーランダム、およびプリマスターシークレットからセッションキーを生成します。両者は同じ結果に到達するはずです。
  7. クライアントの準備完了：クライアントは、セッションキーで暗号化された「完了」メッセージを送信します。
  8. サーバーの準備完了：サーバーは、セッションキーで暗号化された「完了」メッセージを送信します。
  9. 安全な対称暗号化の達成：ハンドシェイクが完了し、セッションキーを使用して通信が続行されます。

すべてのTLSハンドシェイクは非対称暗号化（公開鍵と秘密鍵）を使用しますが、すべてがセッションキーの生成プロセスで秘密鍵を使用するわけではありません。たとえば、一時的なDiffie-Hellmanハンドシェイクは次のように進行します。

  1. クライアントハロー：クライアントは、プロトコルバージョン、クライアント乱数、および暗号スイートのリストを含むクライアントハローメッセージを送信します。
  2. サーバーハロー：サーバーは、そのSSL証明書、選択された暗号スイート、およびサーバー乱数で応答します。前のセクションで説明したRSAハンドシェイクとは対照的に、このメッセージではサーバーは以下の情報も含まれます（ステップ3）。
  3. サーバーのデジタル署名：サーバーは秘密鍵を使用して、クライアント乱数、サーバー乱数、およびそのDHパラメーター*を暗号化します。この暗号化されたデータはサーバーのデジタル署名として機能し、サーバーがSSL証明書の公開鍵と一致する秘密鍵を持っていることを確立します。
  4. デジタル署名の確認：クライアントは公開鍵でサーバーのデジタル署名を復号し、サーバーが秘密鍵を制御しており、自己申告どおりであることを確認します。クライアントDHパラメーター：クライアントはDHパラメーターをサーバーに送信します。
  5. クライアントとサーバーがプリマスターシークレットを計算：RSAハンドシェイクのようにクライアントがプリマスターシークレットを生成してサーバーに送信する代わりに、クライアントとサーバーは交換したDHパラメーターを使用して、一致するプリマスターシークレットを個別に計算します。
  6. セッションキーの作成：これで、クライアントとサーバーは、RSAハンドシェイクと同様に、プリマスターシークレット、クライアント乱数、およびサーバー乱数からセッションキーを計算します。
    • クライアントの準備完了： RSAハンドシェイクと同じ
    • サーバーの準備完了
    • 安全な対称暗号化が達成されました

    *DHパラメーター：DHはDiffie-Hellmanの略です。Diffie-Hellmanアルゴリズムは、指数計算を使用して同じプリマスターシークレットに到達します。サーバーとクライアントはそれぞれ計算用のパラメーターを提供し、それらが結合されると、各側で異なる計算が行われ、結果は等しくなります。

一時的なDiffie-Hellmanハンドシェイクと他の種類のハンドシェイクとの違い、およびそれらが前方秘匿性をどのように実現するかについて詳しく知るには、このTLSプロトコルドキュメントを参照してください。

暗号スイートとは？

  • 暗号スイートとは、安全な通信接続を確立するために使用される暗号化アルゴリズムのセットです。（暗号化アルゴリズムとは、データをランダムに見せるためにデータに対して実行される一連の数学的操作です。）広く使用されているさまざまな暗号スイートがあり、TLSハンドシェイクの重要な部分は、そのハンドシェイクに使用される暗号スイートについて合意することです。

開始するには、リファレンス：TLSプロトコルドキュメントを参照してください。

シトリックス アプリケーション デリバリー マネジメント SSL ダッシュボード

Citrix Application Delivery Management (ADM) は、証明書管理のあらゆる側面を効率化します。単一のコンソールを通じて、適切な発行者、鍵強度、正しいアルゴリズムを保証するための自動ポリシーを確立し、未使用または期限切れ間近の証明書を綿密に監視できます。Citrix ADM の SSL ダッシュボードとその機能の使用を開始するには、SSL 証明書とは何か、そして Citrix ADM を使用して SSL 証明書を追跡する方法を理解する必要があります。

Secure Socket Layer (SSL) 証明書は、あらゆる SSL トランザクションの一部であり、企業（ドメイン）または個人を識別するデジタルデータ形式（X509）です。この証明書には、サーバーとの安全なトランザクションを開始したいすべてのクライアントに表示される公開鍵コンポーネントが含まれています。対応する秘密鍵は、Citrix Application Delivery Controller™ (ADC) アプライアンスに安全に格納されており、非対称鍵（または公開鍵）の暗号化と復号化を完了するために使用されます。

SSL 証明書と鍵は、以下のいずれかの方法で取得できます。

  • 認定された証明機関 (CA) から
  • Citrix ADC アプライアンスで新しい SSL 証明書と鍵を生成する

Citrix ADM は、管理対象のすべての Citrix ADC インスタンスにインストールされている SSL 証明書の一元的なビューを提供します。SSL ダッシュボードでは、証明書の発行者、鍵強度、署名アルゴリズム、期限切れまたは未使用の証明書などを追跡するのに役立つグラフを表示できます。また、仮想サーバーで実行されている SSL プロトコルの分布と、それらで有効になっている鍵も確認できます。

証明書の有効期限が近づいているときに通知を受け取るように設定することもでき、どの Citrix ADC インスタンスがそれらの証明書を使用しているかに関する情報も含まれます。

Citrix ADC インスタンスの証明書を CA 証明書にリンクできます。ただし、同じ CA 証明書にリンクする証明書が同じソースと発行者を持っていることを確認してください。証明書を CA 証明書にリンクした後、それらのリンクを解除できます。

SSL ダッシュボード

開始するには、以下のSSL Dashboard Documentationを参照してください。

サードパーティ統合

アプリケーションの遅延はミリ秒単位で測定され、使用されるメトリックに応じて2つのことのいずれかを示す可能性があります。遅延を測定するより一般的な方法は「ラウンドトリップタイム」（または RTT）と呼ばれます。RTT は、データパケットがネットワーク上のある地点から別の地点へ移動し、応答がソースに返されるまでにかかる時間を計算します。もう1つの測定方法は「ファーストバイトまでの時間」（または TTFB）と呼ばれ、パケットがネットワーク上のある地点を出発してから目的地に到着するまでの時間を記録します。RTT は、ネットワーク上の単一の地点から実行でき、宛先地点にデータ収集ソフトウェアをインストールする必要がないため（TTFB のように）、遅延を測定するためにより一般的に使用されます。

ADM サービスは、アプリケーションの帯域幅使用量とパフォーマンスをリアルタイムで監視することで、問題を簡単に特定し、ネットワーク上のユーザーに影響を与える前に潜在的な問題を未然に解決できるようにします。このフローベースのソリューションは、インターフェイス、アプリケーション、および会話ごとに使用状況を追跡し、ネットワーク全体の活動に関する詳細情報を提供します。

Splunk ツールを使用する

インフラストラクチャとアプリケーションのパフォーマンスは相互に依存しています。全体像を把握するために、SignalFx はクラウドインフラストラクチャとその上で実行されるマイクロサービス間のシームレスな相関を提供します。メモリリーク、ノイジーネイバーコンテナ、またはその他のインフラストラクチャ関連の問題によりアプリケーションが異常な動作をした場合、SignalFx が通知します。全体像を完成させるために、Splunk のログとイベントへのコンテキスト内アクセスにより、より深いトラブルシューティングと根本原因分析が可能になります。

スプランク

SignalFx Microservices APMとSplunkを使用したトラブルシューティングの詳細については、Splunk for DevOpsの情報を参照してください。

MongoDB Support

MongoDBは、柔軟なJSONのようなドキュメントにデータを保存します。つまり、フィールドはドキュメントごとに異なり、データ構造は時間の経過とともに変更できます。

ドキュメントモデルはアプリケーションコード内のオブジェクトにマッピングされるため、データを扱いやすくなります。

オンデマンドクエリ、インデックス作成、リアルタイム集計により、データにアクセスして分析するための強力な方法が提供されます。

MongoDBは本質的に分散データベースであるため、高可用性、水平スケーリング、地理的分布が組み込まれており、簡単に使用できます。

MongoDBは、以下の技術基盤を通じて、最新のアプリの要求を満たすように設計されています。

  • ドキュメントデータモデル – データと連携するための最良の方法を提供します。
  • 分散システム設計 – データを必要な場所にインテリジェントに配置できます。
  • どこでも実行できる統一されたエクスペリエンス – 将来にわたって作業を保証し、ベンダーロックインを排除できます。

これらの機能により、MongoDBを基盤とするインテリジェントな運用データプラットフォームを構築できます。詳細については、MongoDB Documentationを参照してください。

TCPまたはUDPベースのアプリケーションへのイングレストラフィックを負荷分散する方法

Kubernetes環境では、IngressはKubernetesクラスターの外部からKubernetesサービスへのアクセスを許可するオブジェクトです。標準のKubernetes Ingressリソースは、すべてのトラフィックがHTTPベースであると想定しており、TCP、TCP-SSL、UDPなどの非HTTPベースのプロトコルには対応していません。したがって、DNS、FTP、LDAPなどのL7プロトコルに基づく重要なアプリケーションは、標準のKubernetes Ingressを使用して公開することはできません。

標準のKubernetesソリューションは、LoadBalancerタイプのサービスを作成することです。詳細については、Citrix ADCのサービスタイプLoadBalancerを参照してください。

2番目のオプションは、イングレスオブジェクトにアノテーションを付けることです。Citrix ingress controllerを使用すると、TCPまたはUDPベースのイングレストラフィックをロードバランシングできます。これは、Kubernetes Ingressリソース定義で使用してTCPまたはUDPベースのイングレストラフィックをロードバランシングできる、次のアノテーションを提供します。

  • ingress.citrix.com/insecure-service-type: このアノテーションは、Citrix ADC のプロトコルとしてTCP、UDP、またはANYを使用したL4ロードバランシングを有効にします。
  • ingress.citrix.com/insecure-port: このアノテーションはTCPポートを設定します。このアノテーションは、マイクロサービスアクセスが非標準ポートで必要な場合に役立ちます。デフォルトでは、ポート80が設定されています。

詳細については、TCPまたはUDPベースのアプリケーションへのイングレストラフィックのロードバランシング方法を参照してください。

TCPまたはUDPベースのアプリケーションのパフォーマンスを監視および改善する

アプリケーション開発者は、Citrix ADC の豊富なモニター（TCP-ECV、UDP-ECVなど）を通じて、TCPまたはUDPベースのアプリケーションの健全性を綿密に監視できます。ECV（拡張コンテンツ検証）モニターは、アプリケーションが期待されるコンテンツを返しているかどうかを確認するのに役立ちます。

また、Source IPなどの永続化メソッドを使用することで、アプリケーションのパフォーマンスを向上させることができます。これらのCitrix ADC機能は、Kubernetes のSmart Annotationsを通じて使用できます。以下はその一例です。

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
    name: mongodb
    annotations:
        ingress.citrix.com/insecure-port: “80”
        ingress.citrix.com/frontend-ip: “192.168.1.1”
        ingress.citrix.com/csvserver: ‘{“l2conn”:”on”}’
        ingress.citrix.com/lbvserver: ‘{“mongodb-svc”:{“lbmethod”:”SRCIPDESTIPHASH”}}’
        ingress.citrix.com/monitor: ‘{“mongodbsvc”:{“type”:”tcp-ecv”}}’
Spec:
    rules:
    - host: mongodb.beverages.com
      http:
        paths:
        - path: /
          backend:
            serviceName: mongodb-svc
            servicePort: 80
<!--NeedCopy-->

シトリックス アプリケーション デリバリー マネジメント (ADM) サービス

Citrix ADM Service には次の利点があります。

  • アジャイル – 操作、更新、利用が簡単です。Citrix ADM Service のサービスモデルはクラウド経由で利用できるため、提供される機能を簡単に操作、更新、使用できます。更新頻度と自動更新機能の組み合わせにより、Citrix ADC の展開が迅速に強化されます。
  • 価値実現までの時間短縮 – ビジネス目標をより迅速に達成できます。従来のオンプレミス展開とは異なり、数回クリックするだけでCitrix ADM Service を使用できます。インストールと構成の時間を節約できるだけでなく、潜在的なエラーに時間とリソースを浪費することも回避できます。
  • マルチサイト管理 – マルチサイトデータセンター全体のインスタンスを単一の画面で管理できます。Citrix ADM Service を使用すると、さまざまな種類の展開にあるCitrix ADCs を管理および監視できます。オンプレミスとクラウドに展開されたCitrix ADCs をワンストップで管理できます。
  • 運用効率 – 運用生産性を高めるための最適化された自動化された方法。Citrix ADM Service を使用すると、従来のハードウェア展開の保守とアップグレードにかかる時間、費用、リソースを節約することで、運用コストを削減できます。

Kubernetes アプリケーションのサービスグラフ

Citrix ADM のクラウドネイティブアプリケーション機能のサービスグラフを使用すると、次のことができます。

  • エンドツーエンドのアプリケーション全体のパフォーマンスを確保する
  • アプリケーションのさまざまなコンポーネントの相互依存性によって生じるボトルネックを特定する
  • アプリケーションのさまざまなコンポーネントの依存関係に関するインサイトを収集する
  • Kubernetesクラスター内のサービスを監視する
  • どのサービスに問題があるかを監視する
  • パフォーマンスの問題に寄与する要因を確認する
  • サービスHTTPトランザクションの詳細な可視性を表示する
  • HTTP、TCP、およびSSLメトリックを分析する

Citrix ADMでこれらのメトリックを視覚化することで、問題の根本原因を分析し、必要なトラブルシューティングアクションをより迅速に実行できます。サービスグラフは、アプリケーションをさまざまなコンポーネントサービスで表示します。Kubernetesクラスター内で実行されているこれらのサービスは、アプリケーション内外のさまざまなコンポーネントと通信できます。

開始するには、「サービスグラフの設定」を参照してください。

3層Webアプリケーションのサービスグラフ

アプリケーションダッシュボードのサービスグラフ機能を使用すると、以下を表示できます。

  • アプリケーションがどのように構成されているか（コンテンツスイッチング仮想サーバーと負荷分散仮想サーバーを使用）の詳細
    • GSLBアプリケーションの場合、データセンター、ADCインスタンス、CS、およびLB仮想サーバーを表示できます
  • クライアントからサービスへのエンドツーエンドのトランザクション
  • クライアントがアプリケーションにアクセスしている場所
  • クライアント要求が処理されるデータセンター名と、関連するデータセンターのCitrix ADCメトリック (GSLBアプリケーションのみ)
  • クライアント、サービス、仮想サーバーのメトリック詳細
  • エラーがクライアントからのものか、サービスからのものか
  • Critical、Review、Good などのサービスステータス。Citrix ADMは、サービス応答時間とエラー数に基づいてサービスステータスを表示します。
    • Critical (赤) - 平均サービス応答時間 > 200 ms かつ エラー数 > 0 の場合に示されます。
    • Review (オレンジ) - 平均サービス応答時間 > 200 ms または エラー数 > 0 の場合に示されます。
    • Good (緑) - エラーがなく、平均サービス応答時間 < 200 ms の場合に示されます。
  • Critical、Review、Good などのクライアントステータス。Citrix ADMは、クライアントネットワーク遅延とエラー数に基づいてクライアントステータスを表示します。
    • Critical (赤) - 平均クライアントネットワーク遅延 > 200 ms かつ エラー数 > 0 の場合に示されます。
    • Review (オレンジ) - 平均クライアントネットワーク遅延 > 200 ms または エラー数 > 0 の場合に示されます。
    • Good (緑) - エラーがなく、平均クライアントネットワーク遅延 < 200 ms の場合に示されます。
  • Critical、Review、Good などの仮想サーバーのステータス。Citrix ADMは、アプリスコアに基づいて仮想サーバーのステータスを表示します。
    • Critical (赤) - アプリスコア < 40 の場合に示されます。
    • Review (オレンジ) - アプリスコアが40から75の間である場合に示されます。
    • 良好 (緑) - アプリスコアが75を超える場合に示されます

注意点:

  • ロードバランシング、コンテンツスイッチング、およびGSLB仮想サーバーのみがサービスグラフに表示されます。
  • カスタムアプリケーションに仮想サーバーがバインドされていない場合、そのアプリケーションの詳細はサービスグラフに表示されません。
  • 仮想サーバーとWebアプリケーション間でアクティブなトランザクションが発生している場合にのみ、サービスグラフでクライアントとサービスのメトリックを表示できます。
  • 仮想サーバーとWebアプリケーション間でアクティブなトランザクションがない場合、ロードバランシング、コンテンツスイッチング、GSLB仮想サーバー、サービスなどの構成データに基づいて、サービスグラフの詳細のみを表示できます。
  • アプリケーション構成の更新がサービスグラフに反映されるまでに10分かかる場合があります。

詳細については、アプリケーションのサービスグラフを参照してください。

サービスフローチャート

開始するには、サービスグラフのドキュメントを参照してください。

Citrix ADCチームのトラブルシューティング

Citrix ADCプラットフォームのトラブルシューティングで最も一般的な属性のいくつかについて説明し、これらのトラブルシューティング手法がマイクロサービストポロジのTier-1展開にどのように適用されるかについて説明します。

Citrix ADCには、コマンドをリアルタイムで表示し、ランタイム構成、静的情報、およびポリシー構成を特定するのに役立つコマンドラインインターフェイス (CLI) があります。これは、「SHOW」コマンドを介して実行されます。

SHOW - ADC CLI操作を実行します:

>Show running config (-summary -fullValues)

 Ability to search (grep command)
>“sh running config | -i grep vserver”

Check the version.
>Show license
  “sh license"
<!--NeedCopy-->

SSL統計を表示

>Sh ssl
        System
        Frontend
        Backend
        Encryption
<!--NeedCopy-->

SSL統計を表示(/ja-jp/advanced-concepts/media/show-ssl-statistics.png)

Citrix ADCには、7秒のカウンター間隔に基づいてすべてのオブジェクトの統計を列挙するコマンドがあります。これは、「STAT」コマンドを介して実現されます。

Citrix ADCによる高粒度L3-L7テレメトリ

  • システムレベル: ADCのCPUおよびメモリ使用率。
  • HTTPプロトコル: リクエスト/レスポンス数、GET/POST分割、N-SおよびE-WのHTTPエラー (サービスメッシュライトのみ、サイドカーは近日対応)。
  • SSL: サービスメッシュライトのみのN-SおよびE-Wトラフィックのセッション数とハンドシェイク数。
  • IPプロトコル: 受信/送信パケット数、受信/送信バイト数、切り捨てられたパケット数、およびIPアドレスルックアップ数。
  • Citrix ADC AAA: アクティブセッション数
  • インターフェース: マルチキャストパケット総数、転送バイト総数、および受信/送信ジャンボパケット数。
  • 負荷分散仮想サーバーおよびコンテンツスイッチング仮想サーバー: パケット数、ヒット数、および受信/送信バイト数。

STAT - ADC CLI操作を実行する:

>Statistics
“stat ssl”
<!--NeedCopy-->

SSLを開始(/ja-jp/advanced-concepts/media/start-ssl.png)

Citrix ADCには、「NSCONMSG」コマンドを介して特定のトラブルシューティングエラー発生時に統計とカウンターを検索できるログアーカイブ構造があります。

NSCONMSG - メインログファイル (nsデータ形式) 

    Cd/var/nslog

    “Mac Moves”
    nsconmsg -d current -g nic_err
<!--NeedCopy-->

コマンドフロー(/ja-jp/advanced-concepts/media/command-flow.png)

Nstcpdump

低レベルのトラブルシューティングにはnstcpdumpを使用できます。nstcpdumpはnstraceよりも詳細度の低い情報を収集します。ADC CLIを開き、shellと入力します。nstcpdumpでフィルターを使用できますが、ADCリソースに固有のフィルターは使用できません。ダンプ出力はCLI画面内で直接表示できます。

CTRL + C – これらのキーを同時に押すと、nstcpdumpを停止します。

nstcpdump.sh dst host x.x.x.x – 宛先ホストに送信されたトラフィックを表示します。

nstcpdump.sh -n src host x.x.x.x – 指定されたホストからのトラフィックを表示し、IPアドレスを名前に変換しません (-n)。

nstcpdump.sh host x.x.x.x – 指定されたホストIPとの間のトラフィックを表示します。

例 `nstcpdump`

NSTRACE - パケットトレースファイル

NSTRACEは、ネットワークのトラブルシューティングのための低レベルのパケットデバッグツールです。これにより、アナライザツールを使用してさらに分析できるキャプチャファイルを保存できます。一般的なツールは、Network AnalyzerとWiresharkの2つです。

`nstrace`の出力

パケットトレースの出力

ADC上の/var/nstraceにNSTRACEキャプチャファイルが作成されると、そのキャプチャファイルをWiresharkにインポートして、パケットキャプチャとネットワーク分析を行うことができます。

SYSCTL - 詳細なADC情報: 説明、モデル、プラットフォーム、CPUなど 

    sysctl -a grep hw.physmem

    hw.physmem: 862306304
    netscaler.hw_physmem_mb: 822
<!--NeedCopy-->

aaad.debug - 認証デバッグ情報用のオープンパイプ

aaad.debug

ADCまたはADC Gatewayを介した認証の問題をaaad.debugモジュールでトラブルシューティングする方法の詳細については、このaaad.debugサポート記事を参照してください。

ADCのパフォーマンス統計とイベントログを直接取得する機能もあります。詳細については、このADCサポートドキュメントを参照してください。

SREおよびプラットフォームチームのトラブルシューティング

Kubernetesトラフィックフロー

南北:

  • North/southトラフィックとは、ユーザーからクラスターへ、イングレスを介して流れるトラフィックのことです。

東西:

  • East/westトラフィックとは、Kubernetesクラスター内を流れるトラフィックのことです。サービス間またはサービスとデータストア間のトラフィックです。

Kubernetes環境におけるCitrix ADC CPXのEast-Westトラフィックフローの負荷分散方法

Kubernetesクラスターを展開したら、ADMでKubernetes環境の詳細を指定して、クラスターをADMと統合する必要があります。ADMは、サービス、エンドポイント、イングレスルールなどのKubernetesリソースの変更を監視します。

KubernetesクラスターにADC CPXインスタンスを展開すると、自動的にADMに登録されます。登録プロセスの一環として、ADMはCPXインスタンスのIPアドレスと、NITRO REST APIを使用してインスタンスを構成するために到達できるポートを学習します。

次の図は、ADC CPXがKubernetesクラスターでEast-Westトラフィックフローの負荷分散を行う方法を示しています。

Kubernetesの負荷分散の様子(/ja-jp/advanced-concepts/media/load-balance-kubernetes.png)

この例では、

Kubernetesクラスターのノード1とノード2には、フロントエンドサービスとバックエンドサービスのインスタンスが含まれています。ADC CPXインスタンスがノード1とノード2に展開されると、ADC CPXインスタンスは自動的にADMに登録されます。Kubernetesクラスターの詳細をADMで構成することにより、KubernetesクラスターをADMと手動で統合する必要があります。

クライアントがフロントエンドサービスを要求すると、イングレスリソースは2つのノード上のフロントエンドサービスのインスタンス間で要求をロードバランスします。フロントエンドサービスのインスタンスがクラスター内のバックエンドサービスから情報を必要とする場合、そのノード内のADC CPXインスタンスに要求を転送します。そのADC CPXインスタンスは、クラスター内のバックエンドサービス間で要求をロードバランスし、東西トラフィックフローを提供します。

アプリケーション用ADMサービスグラフ

Citrix ADMのサービスグラフ機能を使用すると、すべてのサービスをグラフィカルに表現して監視できます。この機能は、詳細な分析と有用なメトリックも提供します。以下のサービスグラフを表示できます。

開始するには、サービスグラフの詳細を参照してください。

マイクロサービスアプリケーションカウンターの表示

サービスグラフには、Kubernetesクラスターに属するすべてのマイクロサービスアプリケーションも表示されます。サービスにマウスポインターを合わせると、メトリックの詳細が表示されます。

以下を表示できます。

  • サービス名
  • SSL、HTTP、TCP、SSL over HTTPなど、サービスで使用されるプロトコル
  • ヒット数 – サービスが受信したヒットの総数
  • サービス応答時間 – サービスからの平均応答時間。 (応答時間 = クライアントRTT + リクエストの最後のバイト – リクエストの最初のバイト)
  • エラー – 4xx、5xxなどのエラーの総数
  • データ量 – サービスによって処理されるデータの総量
  • 名前空間 – サービスの名前空間
  • クラスター名 – サービスがホストされているクラスター名
  • SSLサーバーエラー – サービスからのSSLエラーの総数

低速なアプリケーション(/ja-jp/advanced-concepts/media/slow-application.png)

これらの特定のカウンターとトランザクションログは、Citrix Observability Exporter (COE) を介して、サポートされているさまざまなエンドポイントを使用して抽出できます。COE の詳細については、以下のセクションを参照してください。

Citrix ADC統計情報のエクスポーター

これは、Citrix ADCの統計情報をスクレイピングし、HTTP経由でPrometheusにエクスポートするシンプルなサーバーです。Prometheusは、Grafanaにデータソースとして追加することで、Citrix ADCの統計情報をグラフィカルに表示できます。

Citrix ADCインスタンスの統計情報とカウンターを監視するには、citrix-adc-metric-exporter をコンテナまたはスクリプトとして実行できます。エクスポーターは、仮想サーバーへの総ヒット数、HTTPリクエストレート、SSL暗号化/復号化レートなどのCitrix ADC統計情報をCitrix ADCインスタンスから収集し、Prometheusサーバーが統計情報をプルしてタイムスタンプとともに保存するまで保持します。その後、GrafanaをPrometheusサーバーに接続して統計情報を取得し、プロットしたり、アラームを設定したり、ヒートマップを作成したり、テーブルを生成したりするなど、Citrix ADCの統計情報を分析するために必要な操作を実行できます。

図に示すような環境でエクスポーターを動作させるための設定の詳細は、以下のセクションで説明します。エクスポーターがデフォルトでスクレイピングするCitrix ADCエンティティ/メトリクスと、それを変更する方法についても説明します。

Citrix ADC用エクスポーターの詳細については、Metrics Exporter GitHub を参照してください。

ADMサービス分散トレース

サービスグラフでは、分散トレースビューを使用して次のことができます。

  • サービス全体のパフォーマンスを分析する。
  • 選択したサービスとその相互依存サービス間の通信フローを視覚化する。
  • エラーを示すサービスを特定し、そのエラーのあるサービスをトラブルシューティングします。
  • 選択したサービスと、相互に依存する各サービス間のトランザクションの詳細を表示します。

ADM分散トレースの前提条件

サービスのトレース情報を表示するには、次の操作を行う必要があります。

  • アプリケーションが東西トラフィックを送信する際に、以下のトレースヘッダーを維持していることを確認します。

トレースヘッダー(/ja-jp/advanced-concepts/media/trace-headers.png)

  • CPX YAMLファイルをNS_DISTRIBUTED_TRACINGと値YESで更新します。 開始するには、分散トレースを参照してください。

シトリックス オブザーバビリティ エクスポーター (COE) 解析

Citrix Observability Exporterは、Citrix ADCからメトリックとトランザクションを収集し、サポートされているエンドポイントに適した形式（JSON、AVROなど）に変換するコンテナです。Citrix Observability Exporterによって収集されたデータを目的のエンドポイントにエクスポートできます。エンドポイントにエクスポートされたデータを分析することで、Citrix ADCによってプロキシされたアプリケーションのマイクロサービスレベルで貴重な洞察を得ることができます。

COEの詳細については、COE GitHubを参照してください。

トランザクションエンドポイントとしてのElasticsearchとCOE

シーオーイー

Elasticsearchがトランザクションエンドポイントとして指定されている場合、Citrix Observability ExporterはデータをJSON形式に変換します。Elasticsearchサーバー上で、Citrix Observability Exporterは各ADCのElasticsearchインデックスを1時間ごとに作成します。これらのインデックスは、データ、時間、ADCのUUID、およびHTTPデータタイプ（http_eventまたはhttp_error）に基づいています。その後、Citrix Observability Exporterは、各ADCのElasticsearchインデックスの下にJSON形式でデータをアップロードします。すべての通常のトランザクションはhttp_eventインデックスに配置され、異常はhttp_errorインデックスに配置されます。

シーオーイー ジェイソン

Zipkinによる分散トレースのサポート

マイクロサービスアーキテクチャでは、単一のエンドユーザーリクエストが複数のマイクロサービスにまたがることがあり、トランザクションの追跡やエラーの原因特定を困難にします。このような場合、従来のパフォーマンス監視方法では、障害が発生している場所やパフォーマンスが低い原因を正確に特定することはできません。リクエストを処理する各マイクロサービスに固有のデータポイントをキャプチャし、それらを分析して意味のある洞察を得る方法が必要です。

分散トレーシングは、トランザクションをエンドツーエンドで追跡し、複数のマイクロサービス間でどのように処理されているかを理解する方法を提供することで、この課題に対処します。

OpenTracingは、分散トレーシングの設計と実装のための仕様および標準APIセットです。分散トレーサーを使用すると、マイクロサービス間のデータフローを視覚化し、マイクロサービスアーキテクチャのボトルネックを特定するのに役立ちます。

Citrix Observability Exporterは、Citrix ADCの分散トレーシングを実装しており、現在、分散トレーサーとしてZipkinをサポートしています。

現在、Citrix ADCを使用してアプリケーションレベルでパフォーマンスを監視できます。Citrix Observability ExporterをCitrix ADCと併用することで、Citrix ADC CPX、MPX、またはVPXによってプロキシされた各アプリケーションのマイクロサービスのトレースデータを取得できます。

開始するには、(https://github.com/citrix/citrix-observability-exporter)を参照してください。

(/ja-jp/advanced-concepts/media/coe-adc.png)

アプリケーションデバッグのためのZipkin

Zipkinは、オープンソースの分散トレーシングシステムであり、GoogleのDapper論文に基づいています。Dapperは、Googleが本番環境でのシステム分散トレーシングのために使用しているシステムです。Googleは論文で次のように説明しています。「私たちは、Googleの開発者に複雑な分散システムの動作に関するより多くの情報を提供するためにDapperを構築しました。」特にシステムが複雑で分散している場合、トラブルシューティング時にはさまざまな角度からシステムを観察することが重要です。

以下のZipkinトレースデータは、Watchesサンプルアプリケーションに関連する合計5つのスパンと5つのサービスを特定します。トレースデータは、5つのマイクロサービスにわたる特定のスパンデータを示しています。

開始するには、以下のZipkinを参照してください。

(/ja-jp/advanced-concepts/media/zipkin-traces.png)

(/ja-jp/advanced-concepts/media/amazon-span.png)

初期ページロードリクエストのアプリケーションレイテンシを示すZipkinスパンの例：

サンプル Zipkinサービス(/ja-jp/advanced-concepts/media/sample-zipkin-service.png)

データの表示にKibanaを使用

Kibanaは、Elasticsearchデータを視覚化し、Elastic Stackをナビゲートできるオープンなユーザーインターフェイスです。クエリ負荷の追跡から、リクエストがアプリを介して流れる方法の理解まで、あらゆることを実行できます。

アナリストであろうと管理者であろうと、Kibanaは次の3つの主要な機能を提供することで、データを実用的なものにします。

  • オープンソースの分析および視覚化プラットフォーム。 Kibanaを使用してElasticsearchデータを探索し、美しい視覚化とダッシュボードを構築します。
  • Elastic Stackを管理するためのUI。 セキュリティ設定の管理、ユーザーロールの割り当て、スナップショットの取得、データのロールアップなど、すべてKibana UIの利便性から実行できます。
  • Elasticソリューションの中央ハブ。 ログ分析からドキュメント検出、SIEMまで、Kibanaはこれらの機能やその他の機能にアクセスするためのポータルです。

Kibanaは、データソースとしてElasticsearchを使用するように設計されています。Elasticsearchをデータを保存および処理するエンジンと見なし、Kibanaはその上に位置します。

ホームページから、Kibanaはデータを追加するための次のオプションを提供します。

Kibanaは、探索するElasticsearchインデックスを指示するためにインデックスパターンを使用します。ファイルをアップロードしたり、組み込みのチュートリアルを実行したり、サンプルデータを追加したりすると、無料でインデックスパターンが提供され、探索を開始できます。独自のデータをロードする場合は、Stack Managementでインデックスパターンを作成できます。

ステップ1：Logstashのインデックスパターンを構成する

ステップ2：インデックスを選択し、トラフィックを生成してデータを投入します。

ステップ3：ログフィードからの非構造化データからアプリケーションを生成します。

ステップ4：KibanaはLogstashの入力をフォーマットして、レポートとダッシュボードを作成します。

  • 時間範囲
  • 表形式ビュー
  • アプリケーションに基づいたヒット数。
    • 時間、IP、エージェント、マシンOS、レスポンスコード (200)、URL
    • 値でフィルタリング

ステップ5：集計レポートでデータを視覚化します。

  • チャートレポートでの結果集計（円グラフ、棒グラフなど）

Kibanaダッシュボード

キバナ エイチティーティーピー

Citrix ADM を使用して Citrix Cloud™ ネイティブネットワーキングのトラブルシューティングを行う
June 16, 2026
寄稿者: 
C C
June 16, 2026
寄稿者: 
C C

この記事の概要

サイトに関するフィードバック | Your privacy choices footer linkプライバシーに関する選択肢 | プライバシーと法令 | Cookieの設定 | 同意設定 | docs.cloud.com
© 1999- Cloud Software Group, Inc. All rights reserved.