Citrix Virtual Apps and Desktops

よくある質問

August 28, 2026

寄稿者:

MAX_RESERVE_DAYS のような、実行中のログサーバー構成を確認するにはどうすればよいですか？

以下のいずれかのコマンドを使用して、コンテナ環境の値を確認できます。

docker inspect logserver |findstr MAX_RESERVE_DAYS または、コンテナ環境を確認します。 docker exec -it logserver env |grep MAX_RESERVE_DAYS

何も返されない場合、ログサーバーはデフォルト値を使用しています。 MAX_RESERVE_DAYS=7
Windows にログサーバーコンテナイメージをインストールする場合、Docker Desktop ライセンスを購入する必要がありますか？

はい。有効な Docker Desktop ライセンスが必要です。
ログサーバーのインストールには新しいサーバーを使用すべきですか？

はい。パフォーマンスと分離を確保するために、ログサーバーのインストールには専用サーバーを使用することをお勧めします。
単一の AOT ログサーバーの持続的な取り込み容量はどれくらいですか？最大および安全な 1 秒あたりのイベント数 (EPS) の制限は何ですか？

単一の AOT ログサーバーは、1 秒あたり 10,000 イベント (EPS) の持続的な取り込み容量をサポートします。この値は、継続的な取り込みにおける最大値と安全な運用しきい値の両方を表します。
単一の AOT Log Server はいくつのコンポーネントを処理できますか？最大制限はありますか？

単一のログサーバーは最大 128,000 のコンポーネントに接続できますが、1 秒あたり約 10,000 のログしか処理できません。そのため、マシンの数は問題になることはほとんどありません。実際のサイジング要因は、ピークアクティビティ中にユーザーが生成するログの数です。
AOT ログサーバーのバースト耐性はどれくらいですか？損失やバックログの超過なしに、どれくらいの突然のログスパイクを処理できますか？

AOT ログサーバーは、ログを失うことなく、通常のイベントレートの 2 倍までの短期的なバーストを処理できます。ログの量がこれを超えて急増した場合（たとえば 5 倍）、システムはイベントを確実に永続化できなくなり、OpenSearch はログをインデックス化する速度が追いつかないため、ログを破棄し始めます。
AOTログサーバーはログを圧縮できますか？期待できる圧縮率はどのくらいですか？

はい。AOTログサーバーは、OpenSearchにログを保存するためにデフォルトのLZ4圧縮アルゴリズムを使用します。一般的な圧縮率は約2:1で、ログデータは元のサイズの半分以下に削減され、高速な読み取り/書き込みパフォーマンスを維持します。
各インフラストラクチャタイプ（シングルサイトオンプレミス、マルチサイトオンプレミス、シングルリージョンクラウド、マルチリージョンクラウド、ハイブリッド、MSP/テナント）について、AOTログサーバーはどこに展開すべきですか、またその理由は何ですか？

AOTログサーバーは常にVDAと同じ視線上に展開する必要があります。これにより、安定した接続が確保され、ログを生成するコンポーネントとそれを取り込むログサーバー間の低遅延が維持されます。すべてのコンポーネント（VDA、DDC、StoreFront、Gatewayなど）がログサーバーに確実に到達できる限り、環境は正しく機能します。
リージョンごとに1つのログサーバーが必要ですか、それともすべてを集中化できますか？遅延とエグレスについてはどうですか？

ログサーバーを集中化することは可能ですが、お客様は自身の環境における遅延とエグレスコストの影響を評価する必要があります。リージョン間の遅延はログの取り込みに影響を与える可能性があり、特に大量の期間中に顕著です。往復遅延が高い場合、ログの急増やバーストにより、ピーク負荷時に遅延、バックログの蓄積、または潜在的な損失が発生する可能性があります。ログがリージョンまたはクラウドの境界を越える場合、エグレス料金が発生する場合があります。
AOTは大量のネットワーク帯域幅やシステムリソースを消費しますか？

いいえ。AOTは、エンドポイント、VDA、その他のコンポーネント、およびネットワークパフォーマンスへの影響を最小限に抑えるように設計されています。

AOTはログを継続的に収集し、HTTPS経由でほぼリアルタイムでAOTログサーバーにアップロードします。個々のログレコードは通常非常に小さく（多くの場合わずか数キロバイト）、これにより通常の操作中のネットワークオーバーヘッドが最小限に抑えられます。

消費される全体的な帯域幅は、アクティブなセッション数、有効なコンポーネント、および環境のアクティビティによって異なります。ほとんどの展開において、AOTのログトラフィックは全体のネットワーク利用率のごく一部を占めるにすぎません。

AOTは、ストレージ要件を削減し、ログサーバーへのデータ転送を最適化するために圧縮も使用します。
AOTログサーバーで1,000台のマシンをサポートするための最小ハードウェア仕様は何ですか？

1,000台のマシンまでの環境では、次のものが必要です。1ノード（ログサーバー + OpenSearchの組み合わせ）、4 vCPU、8 GB RAM、2,000 IOPS以上（SSDまたはNVMeを推奨）、1 Gbps NIC。このセットアップは、ログ量が中程度の小規模またはシングルサイト展開に適しています。
ログサーバーに問題がある場合、どのようにトラブルシューティングできますか？

LogServerはDockerコンテナとして実行されているため、すべてのDockerコマンドを使用して問題を特定できます。
```
docker logs logserver
docker inspect logserver

```
また、ユーザーは実行中のコンテナにアタッチして、ログサーバー自身のログを表示できます。
```
docker exec –it logserver bash

```
ログサーバーのDockerコンテナのbashシェルで、ユーザーはログサーバーとOpenSearchの健全性を確認できます。
```
curl http://localhost:5000/Ping
curl http://localhost:9200/_cluster/health?pretty

```
そして、コンテナ内のログを確認します。
```
tail Config/applogs.txt
tail Config/weblogs.txt

```
さらにログが必要な場合は、ユーザーはStartLogServer.sh/StartLogServer.batでLOG_LEVEL=0を修正し、これらのスクリプトファイルでログサーバーを再起動できます。そうすると、詳細なログにはTRACE、DEBUG、INFO、WARN、ERRORのすべてのレベルが含まれるようになります。
不適切にデタッチされたログサーバーのストレージディスクからの復旧

Citrix Connector Applianceの管理UIからログサーバーのストレージディスクを最初にデタッチせずに、ハイパーバイザーまたはクラウドプロバイダーから直接削除またはデタッチした場合、Connector Applianceはストレージ構成を保持し、ディスクがまだアタッチされていると見なします。その結果、以前にアタッチされたディスクはConnector Applianceに構成されたままであり、新しいディスクのアタッチは失敗し、ローカルディスクはすでにプロバイダーにマウントされていますのようなエラーが表示されることがあります。

オプション1（推奨）： 元のディスクがまだ利用可能な場合：
1. ハイパーバイザーまたはクラウドプロバイダーから、元のディスクをConnector Appliance VMに再アタッチします。
2. Connector Applianceを再起動します。
3. アプライアンスが正常に起動した後、Connector Applianceの管理UIを使用してディスクをデタッチします。
4. 必要に応じて、新しいディスクをアタッチできるようになります。
オプション2: 元のディスクが利用できなくなった場合は、以下のAPIリクエストを実行して、古いストレージ構成を手動で削除します。認証トークンを取得し、適切なコマンドを実行します。

リナックス：
```
curl -X POST "https://<connector-fqdn>/storage/$detach" \
-H "Content-Type: application/json" \
-H "Authorization: Bearer <token>" \
-d '{"targetProvider":"logserver-provider","storageType":"local"}'

```
ウィンドウズ：
```
curl -X POST "https://<connector-fqdn>/storage/$detach" ^
-H "Content-Type: application/json" ^
-H "Authorization: Bearer <token>" ^
-d "{\"targetProvider\":\"logserver-provider\",\"storageType\":\"local\"}"

```
注：

古いストレージ構成が正常に削除されたとしても、APIはエラーを返す可能性があります。ディスクのアタッチを再試行する前に、ストレージ構成を確認してください。

As a best practice, always detach the Log Server storage disk from the Connector Appliance administration UI before removing or detaching the disk from the hypervisor or cloud provider. This ensures that the Connector Appliance cleans up its storage configuration and prevents stale storage references.

この製品ドキュメントの正式なバージョンは英語版です。英語以外のすべてのバージョンは、お客様の利便性のためにのみ提供され、機械翻訳された内容が含まれている場合があります。詳しくは、Cloud Software Group home で機械翻訳に関する免責事項（Machine Translation Disclaimer）をご覧ください。

この情報は役に立ちましたか?

よくある質問

August 28, 2026

寄稿者:

August 28, 2026

寄稿者:

この記事の概要

この情報は役に立ちましたか?