-
-
Criar e gerenciar conexões e recursos
-
Pools de identidade de diferentes tipos de junção de identidade de máquina
-
Serviço Cloud Connector Standalone Citrix Secure Ticketing Authority (STA)
-
-
-
-
-
-
Coletar um Rastreamento do Citrix Diagnostic Facility (CDF) na Inicialização do Sistema
-
This content has been machine translated dynamically.
Dieser Inhalt ist eine maschinelle Übersetzung, die dynamisch erstellt wurde. (Haftungsausschluss)
Cet article a été traduit automatiquement de manière dynamique. (Clause de non responsabilité)
Este artículo lo ha traducido una máquina de forma dinámica. (Aviso legal)
此内容已经过机器动态翻译。 放弃
このコンテンツは動的に機械翻訳されています。免責事項
이 콘텐츠는 동적으로 기계 번역되었습니다. 책임 부인
Este texto foi traduzido automaticamente. (Aviso legal)
Questo contenuto è stato tradotto dinamicamente con traduzione automatica.(Esclusione di responsabilità))
This article has been machine translated.
Dieser Artikel wurde maschinell übersetzt. (Haftungsausschluss)
Ce article a été traduit automatiquement. (Clause de non responsabilité)
Este artículo ha sido traducido automáticamente. (Aviso legal)
この記事は機械翻訳されています.免責事項
이 기사는 기계 번역되었습니다.책임 부인
Este artigo foi traduzido automaticamente.(Aviso legal)
这篇文章已经过机器翻译.放弃
Questo articolo è stato tradotto automaticamente.(Esclusione di responsabilità))
Translation failed!
Perguntas Frequentes
-
Como 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_DAYSOu verificando o ambiente do contêiner:docker exec -it logserver env |grep MAX_RESERVE_DAYSSe nada for retornado, isso significa que o servidor de log está usando o valor padrão: MAX_RESERVE_DAYS=7
-
É necessário adquirir 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.
-
É recomendável usar um novo servidor para a instalação do servidor de log?
Sim. É recomendável 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áximo e seguro 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 gerenciar? Existe um limite máximo?
Um único Servidor de Log pode conectar até 128.000 componentes, mas pode processar apenas 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 um pico repentino de logs ele pode suportar sem perda ou violação do backlog?
O Servidor de Log AOT pode lidar com picos de curto prazo de até 2 vezes a taxa normal de eventos sem perder logs. Se o volume de logs exceder isso (por exemplo, 5 vezes), o sistema não conseguirá 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 Servidor de Log AOT pode compactar logs? Qual taxa de compactação devemos esperar?
Sim. O Servidor de Log AOT usa o algoritmo de compactação LZ4 padrão para armazenar logs no OpenSearch. A taxa de compactaçã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 Servidor de Log AOT deve ser implantado e por quê?
O Servidor de Log AOT deve ser sempre implantado na mesma linha de visão que os VDAs. Isso garante conectividade estável e ajuda a manter baixa latência entre os componentes que geram logs e o servidor de log que os ingere. Desde que cada componente (VDAs, DDCs, StoreFront, Gateway, etc.) possa alcançar o servidor de log de forma confiável, o ambiente funcionará corretamente.
-
Precisamos de um servidor de log por região, ou tudo pode ser centralizado? E quanto à latência e ao egresso?
É possível centralizar o servidor de log, 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.
-
Quais são as especificações mínimas de hardware para suportar 1.000 máquinas com o Servidor de Log AOT?
Para ambientes com até 1.000 máquinas, você precisa de: 1 nó (Servidor de Log + 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 solucionar problemas se houver um problema com o Servidor de Log?
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 <!--NeedCopy-->Além disso, o usuário pode se conectar ao contêiner em execução e visualizar os logs do próprio logserver:
docker exec –it logserver bash <!--NeedCopy-->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 <!--NeedCopy-->E verificar os logs dentro do contêiner:
tail Config/applogs.txt tail Config/weblogs.txt <!--NeedCopy-->Se precisar de mais logs, o usuário pode modificar o LOG_LEVEL=0 em StartLogServer.sh/StartLogServer.bat e reiniciar o logserver por meio desses arquivos de script. Então, os logs detalhados incluirão todos os níveis: TRACE, DEBUG, INFO, WARN, ERROR.
Compartilhar
Compartilhar
Neste artigo
This Preview product documentation is Citrix Confidential.
You agree to hold this documentation confidential pursuant to the terms of your Citrix Beta/Tech Preview Agreement.
The development, release and timing of any features or functionality described in the Preview documentation remains at our sole discretion and are subject to change without notice or consultation.
The documentation is for informational purposes only and is not a commitment, promise or legal obligation to deliver any material, code or functionality and should not be relied upon in making Citrix product purchase decisions.
If you do not agree, select I DO NOT AGREE to exit.