Citrix Virtual Apps and Desktops

よくある質問

August 29, 2026

寄稿者:

C C

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 Log Server の持続的な取り込み容量はどのくらいですか？最大および安全な Events-Per-Second (EPS) 制限はどのくらいですか？

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

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

AOT Log Server は、ログを失うことなく、通常のイベントレートの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はエラーを返す可能性があります。ディスクのアタッチを再試行する前に、ストレージ構成を確認してください。

ベストプラクティスとして、ハイパーバイザーまたはクラウドプロバイダーからディスクを削除またはデタッチする前に、常にLog ServerストレージディスクをConnector Appliance管理UIからデタッチしてください。これにより、Connector Applianceはストレージ構成をクリーンアップし、古いストレージ参照を防ぎます。

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

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

よくある質問

August 29, 2026

寄稿者:

C C

August 29, 2026

寄稿者:

C C

この記事の概要

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