FAQ

Comment puis-je vérifier les configurations du serveur de journaux en cours d’exécution, comme MAX_RESERVE_DAYS ?

Vous pouvez vérifier les valeurs de l’environnement du conteneur en utilisant l’une des commandes suivantes :

docker inspect logserver |findstr MAX_RESERVE_DAYS Ou en vérifiant l’environnement du conteneur : docker exec -it logserver env |grep MAX_RESERVE_DAYS

Si rien n’est renvoyé, cela signifie que le serveur de journaux utilise la valeur par défaut : MAX_RESERVE_DAYS=7

Dois-je acheter des licences Docker Desktop lors de l’installation de l’image du conteneur du serveur de journaux sur Windows ?

Oui. Une licence Docker Desktop valide est requise.

Dois-je utiliser un nouveau serveur pour l’installation du serveur de journaux ?

Oui. Il est recommandé d’utiliser un serveur dédié pour l’installation du serveur de journaux afin de garantir les performances et l’isolation.

Quelle est la capacité d’ingestion soutenue d’un seul serveur de journaux AOT ? Quelles sont les limites maximales et sûres d’événements par seconde (EPS) ?

Un seul serveur de journaux AOT prend en charge une capacité d’ingestion soutenue de 10 000 événements par seconde (EPS). Cette valeur représente à la fois le maximum et le seuil de fonctionnement sûr pour une ingestion continue.

Combien de composants un seul serveur de journaux AOT peut-il gérer ? Y a-t-il une limite maximale ?

Un seul serveur de journaux peut connecter jusqu’à 128 000 composants, mais il ne peut traiter qu’environ 10 000 journaux par seconde. Le nombre de machines est donc rarement le problème — le véritable facteur de dimensionnement est le nombre de journaux générés par vos utilisateurs pendant les périodes de pointe.

Quelle est la tolérance aux pics du serveur de journaux AOT ? Quelle quantité de pics de journaux soudains peut-il gérer sans perte ni dépassement du backlog ?

Le serveur de journaux AOT peut gérer des pics à court terme allant jusqu’à 2 fois le taux d’événements normal sans perdre de journaux. Si le volume de journaux dépasse cette limite (par exemple, 5 fois), le système ne pourra pas persister les événements de manière fiable, et OpenSearch commencera à supprimer les journaux car il ne pourra pas les indexer assez rapidement.

Le serveur de journaux AOT peut-il compresser les journaux ? Quel taux de compression devons-nous attendre ?

Oui. Le serveur de journaux AOT utilise l’algorithme de compression LZ4 par défaut pour stocker les journaux dans OpenSearch. Le taux de compression typique est d’environ 2:1, ce qui signifie que les données de journal sont réduites à moins de la moitié de leur taille d’origine tout en conservant des performances de lecture/écriture rapides.

Pour chaque type d’infrastructure (sur site à site unique, sur site multi-site, cloud à région unique, cloud multi-régions, hybride, MSP/locataire), où le serveur de journaux AOT doit-il être déployé et pourquoi ?

Le serveur de journaux AOT doit toujours être déployé dans la même ligne de visée que les VDA. Cela garantit une connectivité stable et aide à maintenir une faible latence entre les composants générant les journaux et le serveur de journaux qui les ingère. Tant que chaque composant (VDA, DDC, StoreFront, Gateway, etc.) peut atteindre le serveur de journaux de manière fiable, l’environnement fonctionnera correctement.

Avons-nous besoin d’un serveur de journaux par région, ou tout peut-il être centralisé ? Qu’en est-il de la latence et de l’égression ?

Vous pouvez centraliser le serveur de journaux, mais les clients doivent évaluer les implications en termes de latence et de coût d’égression pour leur environnement. La latence entre les régions peut affecter l’ingestion des journaux, en particulier pendant les périodes de fort volume. Si la latence aller-retour est élevée, les pics ou les rafales de journaux peuvent entraîner des retards, une accumulation de retards ou une perte potentielle pendant les charges de pointe. Des frais d’égression peuvent s’appliquer lorsque les journaux traversent les limites régionales ou du cloud.

L’AOT consomme-t-il une bande passante réseau ou des ressources système importantes ?

Non. L’AOT est conçu pour avoir un impact minimal sur les performances des points d’extrémité, des VDA ou de tout autre composant, ainsi que sur les performances réseau.

L’AOT collecte les journaux en continu et les télécharge vers le serveur de journaux AOT en quasi temps réel via HTTPS. Les enregistrements de journaux individuels sont généralement de très petite taille (souvent seulement quelques kilo-octets), ce qui contribue à minimiser la surcharge réseau pendant le fonctionnement normal.

La bande passante globale consommée dépend du nombre de sessions actives, des composants activés et de l’activité de l’environnement. Dans la plupart des déploiements, le trafic de journaux AOT représente un très faible pourcentage de l’utilisation globale du réseau.

L’AOT utilise également la compression pour réduire les besoins en stockage et optimiser le transfert de données vers le serveur de journaux.

Quelles sont les spécifications matérielles minimales pour prendre en charge 1 000 machines avec le serveur de journaux AOT ?

Pour les environnements comptant jusqu’à 1 000 machines, vous avez besoin de : 1 nœud (serveur de journaux + OpenSearch combinés), 4 vCPU, 8 Go de RAM, 2 000 IOPS minimum (SSD ou NVMe recommandé), Carte réseau 1 Gbit/s. Cette configuration convient aux déploiements de petite taille ou à site unique avec un volume de journaux modéré.

Comment puis-je dépanner s’il y a un problème avec le serveur de journaux ?

LogServer s’exécute en tant que conteneur Docker, donc toutes les commandes Docker peuvent être utilisées pour trouver les problèmes :

docker logs logserver
docker inspect logserver
<!--NeedCopy-->

Et aussi, l’utilisateur pourrait s’attacher au conteneur en cours d’exécution et visualiser les journaux du logserver lui-même :

docker exec –it logserver bash
<!--NeedCopy-->

Dans le shell bash du conteneur Docker du logserver, l’utilisateur peut vérifier l’état de santé du logserver et d’Opensearch :

curl http://localhost:5000/Ping
curl http://localhost:9200/_cluster/health?pretty
<!--NeedCopy-->

Et vérifier les journaux à l’intérieur du conteneur :

tail Config/applogs.txt
tail Config/weblogs.txt
<!--NeedCopy-->

Si plus de journaux sont nécessaires, l’utilisateur peut modifier LOG_LEVEL=0 dans StartLogServer.sh/StartLogServer.bat et redémarrer le logserver à l’aide de ces fichiers de script. Les journaux détaillés incluront alors tous les niveaux : TRACE, DEBUG, INFO, WARN, ERROR.

Récupérer un disque de stockage de serveur de journaux détaché de manière incorrecte

Si vous supprimez ou détachez le disque de stockage du serveur de journaux directement de l’hyperviseur ou du fournisseur de cloud sans l’avoir préalablement détaché de l’interface utilisateur d’administration de Citrix Connector Appliance, le Connector Appliance conserve la configuration de stockage et suppose que le disque est toujours attaché. Par conséquent, le disque précédemment attaché reste configuré dans le Connector Appliance, l’attachement d’un nouveau disque échoue, et vous pouvez voir une erreur similaire à : Un disque local est déjà monté sur le fournisseur.

Option 1 (Recommandée) : Si le disque d’origine est toujours disponible :

1. Rattachez le disque d’origine à la VM du Connector Appliance depuis l’hyperviseur ou le fournisseur de cloud.

2. Redémarrez le Connector Appliance.

3. Une fois l’appliance démarrée avec succès, détachez le disque à l’aide de l’interface utilisateur d’administration du Connector Appliance.

4. Vous pouvez maintenant attacher un nouveau disque si nécessaire.

Option 2 : Si le disque d’origine n’est plus disponible, supprimez manuellement la configuration de stockage obsolète en exécutant la requête API suivante. Récupérer un jeton d’autorisation et exécutez la commande appropriée :

Linux :

curl -X POST "https://<connector-fqdn>/storage/$detach" \
-H "Content-Type: application/json" \
-H "Authorization: Bearer <token>" \
-d '{"targetProvider":"logserver-provider","storageType":"local"}'
<!--NeedCopy-->

Windows :

curl -X POST "https://<connector-fqdn>/storage/$detach" ^
-H "Content-Type: application/json" ^
-H "Authorization: Bearer <token>" ^
-d "{\"targetProvider\":\"logserver-provider\",\"storageType\":\"local\"}"
<!--NeedCopy-->

Remarque :

L’API peut renvoyer une erreur même si la configuration de stockage obsolète est supprimée avec succès. Vérifiez la configuration du stockage avant de retenter la connexion du disque.

En tant que bonne pratique, détachez toujours le disque de stockage du serveur de journaux de l’interface d’administration de l’appliance Connector avant de supprimer ou de détacher le disque de l’hyperviseur ou du fournisseur de cloud. Cela garantit que l’appliance Connector nettoie sa configuration de stockage et empêche les références de stockage obsolètes.