-
Como posso verificar as configurações do servidor de log em execução, como MAX_RESERVE_DAYS?
Você pode verificar os valores do ambiente do contêiner usando um dos seguintes comandos:
docker inspect logserver |findstr MAX_RESERVE_DAYS Ou verificando o ambiente do contêiner: docker exec -it logserver env |grep MAX_RESERVE_DAYS
Se nada for retornado, significa que o servidor de log está usando o valor padrão: MAX_RESERVE_DAYS=7
-
Preciso comprar licenças do Docker Desktop ao instalar a imagem do contêiner do servidor de log no Windows?
Sim. É necessária uma licença válida do Docker Desktop.
-
Devo usar um novo servidor para a instalação do servidor de log?
Sim. Recomenda-se usar um servidor dedicado para a instalação do servidor de log para garantir desempenho e isolamento.
-
Qual é a capacidade de ingestão sustentada de um único Servidor de Log AOT? Quais são os limites máximos e seguros de Eventos Por Segundo (EPS)?
Um único Servidor de Log AOT suporta uma capacidade de ingestão sustentada de 10.000 eventos por segundo (EPS). Este valor representa tanto o máximo quanto o limite operacional seguro para ingestão contínua.
-
Quantos componentes um único Servidor de Log AOT pode manipular? Existe um limite máximo?
Um único Servidor de Log pode conectar até 128.000 componentes, mas só pode processar cerca de 10.000 logs por segundo. Portanto, o número de máquinas raramente é o problema — o verdadeiro fator de dimensionamento é quantos logs seus usuários geram durante a atividade de pico.
-
Qual é a tolerância a picos do Servidor de Log AOT? Quanto de pico repentino de log ele pode manipular sem perda ou violação do backlog?
O Servidor de Log AOT pode manipular picos de curto prazo de até 2x a taxa normal de eventos sem perder logs. Se o volume de logs aumentar além disso (por exemplo, 5x), o sistema não será capaz de persistir eventos de forma confiável, e o OpenSearch começará a descartar logs porque não consegue indexá-los rápido o suficiente.
-
O AOT Log Server pode compactar logs? Qual taxa de compressão devemos esperar?
Sim. O AOT Log Server usa o algoritmo de compressão LZ4 padrão para armazenar logs no OpenSearch. A taxa de compressão típica é de aproximadamente 2:1, o que significa que os dados de log são reduzidos para menos da metade do seu tamanho original, mantendo um desempenho rápido de leitura/gravação.
-
Para cada tipo de infraestrutura (local de site único, local de múltiplos sites, nuvem de região única, nuvem de múltiplas regiões, híbrido, MSP/locatário), onde o AOT Log Server deve ser implantado e por quê?
O AOT Log Server deve ser sempre implantado na mesma linha de visão dos VDAs. Isso garante conectividade estável e ajuda a manter baixa latência entre os componentes que geram logs e o servidor de logs que os ingere. Desde que cada componente (VDAs, DDCs, StoreFront, Gateway, etc.) possa alcançar o servidor de logs de forma confiável, o ambiente funcionará corretamente.
-
Precisamos de um servidor de logs por região, ou tudo pode ser centralizado? E quanto à latência e ao egresso?
Você pode centralizar o servidor de logs, mas os clientes devem avaliar as implicações de latência e custo de egresso para seu ambiente. A latência entre regiões pode afetar a ingestão de logs, especialmente durante períodos de alto volume. Se a latência de ida e volta for alta, picos ou rajadas de logs podem causar atrasos, acúmulo de backlog ou perda potencial durante cargas de pico. Taxas de egresso podem ser aplicadas quando os logs cruzam limites regionais ou de nuvem.
-
O AOT consome largura de banda de rede ou recursos do sistema significativos?
Não. O AOT foi projetado para ter impacto mínimo no endpoint, VDA ou qualquer componente, e no desempenho da rede.
O AOT coleta logs continuamente e os carrega para o AOT Log Server em tempo quase real via HTTPS. Registros de log individuais são tipicamente muito pequenos em tamanho (muitas vezes apenas alguns kilobytes), o que ajuda a minimizar a sobrecarga da rede durante a operação normal.
A largura de banda total consumida depende do número de sessões ativas, componentes habilitados e atividade do ambiente. Na maioria das implantações, o tráfego de log do AOT representa uma porcentagem muito pequena da utilização geral da rede.
O AOT também usa compressão para reduzir os requisitos de armazenamento e otimizar a transferência de dados para o Log Server.
-
Quais são as especificações mínimas de hardware para suportar 1.000 máquinas com o AOT Log Server?
Para ambientes com até 1.000 máquinas, você precisa de: 1 nó (Log Server + OpenSearch combinados), 4 vCPUs, 8 GB de RAM, 2.000 IOPS mínimo (SSD ou NVMe recomendado), NIC de 1 Gbps. Esta configuração é adequada para implantações pequenas ou de site único com volume de log moderado.
-
Como posso solucionar problemas se houver um problema com o Log Server?
O LogServer está sendo executado como um contêiner Docker, portanto, todos os comandos Docker podem ser usados para encontrar os problemas:
docker logs logserver
docker inspect logserver
E também, o usuário pode anexar ao contêiner em execução e visualizar os logs do próprio logserver:
docker exec –it logserver bash
No shell bash do contêiner docker do logserver, o usuário pode verificar a integridade do logserver e do opensearch:
curl http://localhost:5000/Ping
curl http://localhost:9200/_cluster/health?pretty
E verificar os logs dentro do contêiner:
tail Config/applogs.txt
tail Config/weblogs.txt
Se precisar de mais logs, o usuário pode modificar o LOG_LEVEL=0 em StartLogServer.sh/StartLogServer.bat e reiniciar o logserver usando esses arquivos de script. Então, os logs detalhados incluirão todos os níveis: TRACE, DEBUG, INFO, WARN, ERROR.
-
Recuperar de um disco de armazenamento do Log Server desanexado incorretamente
Se você remover ou desanexar o disco de armazenamento do Log Server diretamente do hypervisor ou provedor de nuvem sem primeiro desanexá-lo da interface de administração do Citrix Connector Appliance, o Connector Appliance retém a configuração de armazenamento e assume que o disco ainda está anexado. Como resultado, o disco previamente anexado permanece configurado no Connector Appliance, a anexação de um novo disco falha e você pode ver um erro semelhante a: Um disco local já está montado no provedor.
Opção 1 (Recomendado): Se o disco original ainda estiver disponível:
-
Reanexe o disco original à VM do Connector Appliance a partir do hypervisor ou provedor de nuvem.
-
Reinicie o Connector Appliance.
-
Após o appliance iniciar com sucesso, desanexe o disco usando a interface de administração do Connector Appliance.
-
Agora você pode anexar um novo disco, se necessário.
Opção 2: Se o disco original não estiver mais disponível, remova manualmente a configuração de armazenamento obsoleta executando a seguinte solicitação de API.
Recupere um token de Autorização e execute o comando apropriado:
Linux:
curl -X POST "https://<connector-fqdn>/storage/$detach" \
-H "Content-Type: application/json" \
-H "Authorization: Bearer <token>" \
-d '{"targetProvider":"logserver-provider","storageType":"local"}'
Windows:
curl -X POST "https://<connector-fqdn>/storage/$detach" ^
-H "Content-Type: application/json" ^
-H "Authorization: Bearer <token>" ^
-d "{\"targetProvider\":\"logserver-provider\",\"storageType\":\"local\"}"
A API pode retornar um erro mesmo que a configuração de armazenamento obsoleta seja removida com sucesso. Verifique a configuração de armazenamento antes de tentar novamente a anexação do disco.
Como uma prática recomendada, sempre desanexe o disco de armazenamento do Log Server da interface de administração do Connector Appliance antes de remover ou desanexar o disco do hipervisor ou provedor de nuvem. Isso garante que o Connector Appliance limpe sua configuração de armazenamento e evite referências de armazenamento obsoletas.
