FAQ

Come posso controllare 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.

Dovrei usare un nuovo server per l’installazione del server di log?

Sì. Si consiglia 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 server di log AOT? Quali sono i limiti massimi e sicuri di eventi al secondo (EPS)?

Un singolo server di log AOT 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 server di log AOT? Esiste un limite massimo?

Un singolo server di log può connettere fino a 128.000 componenti, ma può elaborare solo circa 10.000 log al secondo. Quindi il numero di macchine è raramente il problema — il vero fattore di dimensionamento è quanti log i tuoi utenti generano durante l’attività di picco.

Qual è la tolleranza ai picchi del server di log AOT? Quanti picchi improvvisi di log può gestire senza perdita o violazione del backlog?

Il server di log AOT può gestire picchi a breve termine fino a 2 volte la normale frequenza degli 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 eliminare i log perché non può indicizzarli abbastanza velocemente.

Il server di log AOT può comprimere i log? Quale rapporto di compressione dovremmo aspettarci?

Sì. Il server di log AOT utilizza l’algoritmo di compressione LZ4 predefinito per archiviare i log in OpenSearch. Il rapporto di compressione tipico è di circa 2:1, il che significa che i dati di log sono ridotti a meno della metà della loro dimensione originale, mantenendo al contempo prestazioni di lettura/scrittura veloci.

Per ogni tipo di infrastruttura (on-premise a sito singolo, on-premise multisito, cloud a regione singola, cloud multiregione, ibrido, MSP/tenant), dove dovrebbe essere distribuito il server di log AOT e perché?

Il server di log AOT 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.

Abbiamo bisogno di un server di log per regione, o 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 il server di log AOT?

Per ambienti con un massimo di 1.000 macchine, sono necessari: 1 nodo (server di log + OpenSearch combinati), 4 vCPU, 8 GB di RAM, 2.000 IOPS minimo (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 server di log?

LogServer è in esecuzione come container docker, quindi tutti i comandi docker possono essere utilizzati per trovare i problemi:

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

Inoltre, l’utente può collegarsi al container in esecuzione e visualizzare i log del logserver stesso:

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

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
<!--NeedCopy-->

E controllare i log all’interno del container:

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

Se sono necessari più 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.