Citrix Virtual Apps and Desktops

FAQ

January 23, 2026

Grazie al contributo di:

Come posso verificare le configurazioni del server di log in esecuzione, come MAX_RESERVE_DAYS?

È possibile controllare i valori dell’ambiente del container utilizzando uno dei seguenti comandi:

docker inspect logserver |findstr MAX_RESERVE_DAYS Oppure controllando l’ambiente del container: docker exec -it logserver env |grep MAX_RESERVE_DAYS

Se non viene restituito nulla, significa che il server di log sta utilizzando il valore predefinito: MAX_RESERVE_DAYS=7
È necessario acquistare licenze Docker Desktop quando si installa l’immagine del container del server di log su Windows?

Sì. È richiesta una licenza Docker Desktop valida.
È consigliabile utilizzare un nuovo server per l’installazione del server di log?

Sì. Si raccomanda di utilizzare un server dedicato per l’installazione del server di log per garantire prestazioni e isolamento.
Qual è la capacità di acquisizione sostenuta di un singolo AOT Log Server? Quali sono i limiti massimi e sicuri di eventi al secondo (EPS)?

Un singolo AOT Log Server supporta una capacità di acquisizione sostenuta di 10.000 eventi al secondo (EPS). Questo valore rappresenta sia il massimo che la soglia operativa sicura per l’acquisizione continua.
Quanti componenti può gestire un singolo AOT Log Server? Esiste un limite massimo?

Un singolo Log Server può connettere fino a 128.000 componenti, ma può elaborare solo circa 10.000 log al secondo. Pertanto, il numero di macchine è raramente il problema — il vero fattore di dimensionamento è quanti log i vostri utenti generano durante i periodi di attività di picco.
Qual è la tolleranza ai picchi dell’AOT Log Server? Quanti picchi improvvisi di log può gestire senza perdita o superamento del backlog?

L’AOT Log Server può gestire picchi a breve termine fino a 2 volte la normale frequenza di eventi senza perdere log. Se il volume dei log supera questo limite (ad esempio, 5 volte), il sistema non sarà in grado di persistere gli eventi in modo affidabile e OpenSearch inizierà a scartare i log perché non riesce a indicizzarli abbastanza velocemente.
L’AOT Log Server può comprimere i log? Quale rapporto di compressione dovremmo aspettarci?

Sì. L’AOT Log Server utilizza l’algoritmo di compressione predefinito LZ4 per l’archiviazione dei log in OpenSearch. Il rapporto di compressione tipico è di circa 2:1, il che significa che i dati dei log sono ridotti a meno della metà della loro dimensione originale, mantenendo al contempo prestazioni di lettura/scrittura rapide.
Per ogni tipo di infrastruttura (on-premise a sito singolo, on-premise multi-sito, cloud a regione singola, cloud multi-regione, ibrido, MSP/tenant), dove dovrebbe essere distribuito l’AOT Log Server e perché?

L’AOT Log Server dovrebbe essere sempre distribuito nella stessa linea di vista dei VDA. Ciò garantisce una connettività stabile e aiuta a mantenere una bassa latenza tra i componenti che generano i log e il server di log che li acquisisce. Finché ogni componente (VDA, DDC, StoreFront, Gateway, ecc.) può raggiungere in modo affidabile il server di log, l’ambiente funzionerà correttamente.
È necessario un server di log per regione, oppure tutto può essere centralizzato? Che dire della latenza e dell’egress?

È possibile centralizzare il server di log, ma i clienti dovrebbero valutare le implicazioni di latenza e costo di egress per il loro ambiente. La latenza tra le regioni può influire sull’acquisizione dei log, specialmente durante i periodi di alto volume. Se la latenza di andata e ritorno è elevata, picchi o raffiche di log possono causare ritardi, accumulo di backlog o potenziale perdita durante i carichi di punta. Potrebbero essere applicati costi di egress quando i log attraversano i confini regionali o del cloud.
Quali sono le specifiche hardware minime per supportare 1.000 macchine con l’AOT Log Server?

Per ambienti con un massimo di 1.000 macchine, sono necessari: 1 nodo (Log Server + OpenSearch combinati), 4 vCPU, 8 GB di RAM, 2.000 IOPS minimi (SSD o NVMe consigliati), NIC da 1 Gbps. Questa configurazione è adatta per distribuzioni piccole o a sito singolo con un volume di log moderato.
Come posso risolvere i problemi se c’è un problema con il Log Server?

LogServer è in esecuzione come container Docker, quindi tutti i comandi Docker possono essere utilizzati per individuare i problemi:
```
docker logs logserver
docker inspect logserver

```
Inoltre, l’utente può collegarsi al container in esecuzione e visualizzare i log del LogServer stesso:
```
docker exec –it logserver bash

```
Nella shell bash del container Docker del LogServer, l’utente può verificare lo stato di salute del LogServer e di OpenSearch:
```
curl http://localhost:5000/Ping
curl http://localhost:9200/_cluster/health?pretty

```
E controllare i log all’interno del container:
```
tail Config/applogs.txt
tail Config/weblogs.txt

```
Se sono necessari ulteriori log, l’utente può modificare LOG_LEVEL=0 in StartLogServer.sh/StartLogServer.bat e riavviare il LogServer tramite questi file di script. I log dettagliati includeranno quindi tutti i livelli: TRACE, DEBUG, INFO, WARN, ERROR.

La versione ufficiale di questo contenuto è in inglese. Per alcuni dei contenuti della documentazione Cloud Software Group è stata impiegata la traduzione automatica solo per comodità. Cloud Software Group non ha alcun controllo sui contenuti tradotti in modo automatico, che possono contenere errori, imprecisioni o linguaggio inadatto. Non viene offerta alcuna garanzia di alcun tipo, espressa o implicita, circa l'accuratezza, l'affidabilità, l'idoneità o la correttezza di qualsiasi traduzione dall'originale inglese in qualsiasi altra lingua, o che il prodotto o servizio Cloud Software Group sia conforme a qualsiasi contenuto in traduzione automatica, e qualsiasi garanzia fornita ai sensi del contratto di licenza per l'utente finale applicabile o i termini di servizio, o qualsiasi altro accordo con Cloud Software Group che il prodotto o il servizio sia conforme a qualsiasi documentazione non si applicheranno nella misura in cui tale documentazione sia in traduzione automatica. Cloud Software Group non sarà ritenuta responsabile per eventuali danni o problemi che potrebbero derivare dall'utilizzo di contenuti per cui si è impiegata la traduzione automatica.

È stato utile?

FAQ

January 23, 2026

Grazie al contributo di:

January 23, 2026

Grazie al contributo di:

In questo articolo

È stato utile?