-
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ログサーバーはいくつのコンポーネントを処理できますか？最大制限はありますか？
単一のログサーバーは最大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
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に構成されたままになり、新しいディスクの接続は失敗し、次のようなエラーが表示されることがあります: A local disk is already mounted to the provider。
オプション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がエラーを返すことがあります。ディスクの接続を再試行する前に、ストレージ構成を確認してください。
ベストプラクティスとして、ハイパーバイザーまたはクラウドプロバイダーからディスクを削除またはデタッチする前に、必ずConnector Applianceの管理UIからログサーバーのストレージディスクをデタッチしてください。これにより、Connector Applianceはストレージ構成をクリーンアップし、古いストレージ参照が残るのを防ぎます。
