-
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 はいくつのコンポーネントを処理できますか？最大制限はありますか？
単一の Log Server は最大 128,000 のコンポーネントに接続できますが、1 秒あたり約 10,000 のログしか処理できません。そのため、マシンの数が問題になることはほとんどなく、実際のサイジング要因は、ピークアクティビティ中にユーザーが生成するログの数です。
-
AOT ログサーバーのバースト耐性はどれくらいですか？損失やバックログの超過なしに、どれくらいの突然のログスパイクを処理できますか？
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
logserver docker コンテナのbashシェルで、ユーザーはlogserverと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を変更し、これらのスクリプトファイルでlogserverを再起動できます。そうすると、詳細なログにはTRACE、DEBUG、INFO、WARN、ERRORのすべてのレベルが含まれるようになります。
-
不適切にデタッチされたログサーバーのストレージディスクからの回復
Citrix Connector Applianceの管理UIから最初にデタッチせずに、ログサーバーのストレージディスクをハイパーバイザーまたはクラウドプロバイダーから直接削除またはデタッチした場合、Connector Applianceはストレージ構成を保持し、ディスクがまだアタッチされていると見なします。その結果、以前にアタッチされたディスクはConnector Applianceに構成されたままであり、新しいディスクのアタッチは失敗し、「ローカルディスクはすでにプロバイダーにマウントされています」のようなエラーが表示されることがあります。
オプション1（推奨）： 元のディスクがまだ利用可能な場合：
-
ハイパーバイザーまたはクラウドプロバイダーから、元のディスクをConnector Appliance VMに再接続します。
-
Connector Applianceを再起動します。
-
アプライアンスが正常に起動した後、Connector Applianceの管理UIを使用してディスクをデタッチします。
-
必要に応じて、新しいディスクを接続できるようになります。
オプション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はストレージ構成をクリーンアップし、古いストレージ参照を防ぎます。
