Problemas Conhecidos e Limitações

Consulte os problemas conhecidos e as limitações da observabilidade do IBM Instana.

Problemas Conhecidos

Incompatibilidade do sidecar do ` CrowdStrike Falcon ` com o agente ` Instana `

O contêiner do agente do ` Instana ` é incompatível com o sidecar do ` CrowdStrike Falcon `. Você só pode usar o Falcon como um servidor de e-mail ( DaemonSet ).

Problema de memória com o agente do ` Instana ` no ` Windows Server 2016`

Editar online

Em servidores que hospedam o Windows Server 2016, uma biblioteca utilizada pelo agente do Instana consome memória gradualmente sem liberá-la corretamente, o que pode causar um aumento no uso de memória nos sistemas do Windows afetados. Para manter o consumo de memória sob controle, os agentes do Instana são reiniciados automaticamente. O recurso de reinicialização automática é para evitar que o problema de memória afete as atualizações automáticas do agente Por padrão, todos os agentes do Instana instalados no Server 2016 do Windows são reiniciados a cada 7 dias, entre 5h e 5h30 da manhã. Esse recurso está disponível desde o pacote de agentes Instana 1.1.702. A versão do pacote do agente pode ser verificada nos registros de inicialização do agente em Instana.

Para alterar o comportamento padrão de reinicialização, defina as seguintes variáveis de ambiente antes de iniciar o agente do Instana.


Nome da variável de ambiente	Padrão	Comunicado
`INSTANA_AUTO_RESTART_WINDOWS_SERVER_2016_ENABLED`	`true`	O sinalizador para ativar ou desativar a reinicialização automática
`INSTANA_AUTO_RESTART_WINDOWS_SERVER_2016_RESTART_TIME`	`5:15`	O momento em que o agente do serviço de gerenciamento de energia ( Instana ) é reiniciado.
`INSTANA_AUTO_RESTART_WINDOWS_SERVER_2016_JITTER_IN_MIN`	`30`	O jitter em minutos para configurar o intervalo de tempo no qual o agente é reiniciado. O intervalo serve para evitar que os agentes do Instana sejam reiniciados simultaneamente. O tempo de reinicialização é selecionado aleatoriamente dentro do intervalo especificado Para modificar a randomização do tempo de reinicialização, configure um valor maior que 1... O intervalo de tempo para o tempo de reinicialização é calculado usando as fórmulas `INSTANA_AUTO_RESTART_WINDOWS_SERVER_2016_RESTART_TIME` -(`INSTANA_AUTO_RESTART_WINDOWS_SERVER_2016_JITTER_IN_MIN`/2) e `INSTANA_AUTO_RESTART_WINDOWS_SERVER_2016_RESTART_TIME` + (`INSTANA_AUTO_RESTART_WINDOWS_SERVER_2016_JITTER_IN_MIN`/2). Por exemplo, se a hora de reinício for definida para as 5.15 h com uma variação de 30 minutos, a reinicialização ocorrerá entre as 05:00 e as 05:30.
`INSTANA_AUTO_RESTART_WINDOWS_SERVER_2016_RESTART_MIN_INTERVAL_IN_DAYS`	`7`	O intervalo antes de a próxima reinicialização ocorrer. Configure um valor maior que zero.

Conflitos de ID de agente devido a endereços MAC idênticos

Editar online

Quando vários sistemas compartilham o mesmo endereço MAC, eles geram IDs de agente idênticos, o que causa conflitos de identidade de host. Isso faz com que os agentes sobrescrevam os dados uns dos outros, e um processo de um host pode ser atribuído incorretamente a outro.

Para resolver esse problema, você pode usar uma das seguintes opções de configuração:

Opção 1: Anexar o FQDN ao ID do agente

Defina a variável de ambiente INSTANA_APPEND_FQDN_TO_AGENT_ID=true para incluir o FQDN no ID do agente. Essa configuração garante que cada ID de agente seja único, independentemente de endereços MAC idênticos.

Use esta opção quando vários hosts compartilham o mesmo endereço MAC, mas possuem FQDNs ou nomes de host exclusivos.

Opção 2: Manter o ID exclusivo do host

Defina a variável de ambiente INSTANA_PERSIST_HOST_UNIQUE_ID=true para gerar e manter um ID de agente exclusivo baseado em hash. O agente gera um ID exclusivo na primeira inicialização e o armazena no disco, garantindo que o mesmo ID seja utilizado mesmo após reinicializações do agente.

O agente armazena o ID nos seguintes locais específicos da plataforma. Se o local principal não estiver acessível, o agente tenta automaticamente os locais alternativos:

Linux ou Unix:

Primário: /proc/1/root/var/lib/instana/instana-agent-id (funciona em contêineres e no host)
Solução alternativa: /var/lib/instana/instana-agent-id

macOS:

Primário: ~/Library/Application Support/com.instana.agent/instana-agent-id (específico do usuário)
Solução alternativa: /Library/Application Support/com.instana.agent/instana-agent-id (em todo o sistema)

Windows:

Primário: %LOCALAPPDATA%\Instana\agent\instana-agent-id
Alternativa: %APPDATA%\Instana\agent\instana-agent-id ou %PROGRAMDATA%\Instana\agent\instana-agent-id

Você pode substituir esses locais definindo a variável de ambiente INSTANA_AGENT_ID_FILE_PATH=/custom/path/to/instana-agent-id.

Use esta opção quando precisar de um ID de agente estável que permaneça mesmo após reinicializações, ou ao executar em ambientes em contêineres, onde os endereços MAC são temporários.

Opção 3: Configurar o ID estático do agente

Especifique manualmente um ID de agente estático no arquivo de configuração <instanaAgentDir>/etc/instana/com.instana.agent.main.config.Agent.cfg do agente, adicionando a seguinte linha:

uniqueAgentId=SomeUniqueString

Substitua SomeUniqueString pelo identificador exclusivo de sua preferência. Por exemplo:

uniqueAgentId=prod-server-01-custom-id

Use esta opção quando precisar de controle total sobre o ID do agente ou quiser usar uma convenção de nomenclatura específica.

Nota:

Quando várias opções de configuração são definidas, o agente as utiliza na seguinte ordem:

ID estático do agente (uniqueAgentId)
ID exclusivo persistido (INSTANA_PERSIST_HOST_UNIQUE_ID)
ID baseado em MAC com FQDN (INSTANA_APPEND_FQDN_TO_AGENT_ID)
ID padrão baseado em MAC

Falha na conexão CRI- API em configurações antigas do Kubernetes e containerd

Editar online

Em ambientes do tipo “ Kubernetes ” que executam versões mais antigas ou personalizadas do RKE2 e do Containerd, o agente de monitoramento pode não conseguir estabelecer comunicação com o ambiente de execução do contêiner por meio da Interface de Execução de Contêineres (CRI) gRPC API.

Versões de exemplo:

Versão do Container Runtime: containerd://1.4.12-k3s1
Versão do Kubelet: v1.21.8+rke2r1

Essa falha se manifesta por meio de erros semelhantes a:

io.grpc.StatusRuntimeException: UNIMPLEMENTED: unknown service runtime.v1.RuntimeService
at io.grpc.stub.ClientCalls.toStatusRuntimeException(ClientCalls.java:268) ~[?:?]

Esse problema ocorre porque versões mais antigas do Kubernetes e do Containerd podem não oferecer suporte total ao CRI gRPC API esperado pelo agente, causando falhas de conexão durante a interação com o ambiente de execução do contêiner.

Como solução alternativa, defina a variável de ambiente INSTANA_USE_CONTAINERD_CRI_CLIENT=false no agente para desativar a interação com o ambiente de execução do contêiner por meio do cliente CRI. O agente então usa ctr para coletar as métricas.

Limitações conhecidas

Editar online

Elasticsearch 8.18 + falha no monitoramento

Editar online

A partir da versão Elasticsearch 8.18.0, o agente Instana não consegue se conectar a JVMs Elasticsearch. Essa falha ocorre porque Elasticsearch 8.18.0 mudou definitivamente de Java SecurityManager para a estrutura de segurança Entitlements. Para obter mais informações, consulte as notas de lançamento do Elasticsearch 8.18.0.

A estrutura de segurança intercepta e restringe operações sensíveis do JDK realizadas por código carregado dinamicamente. Quando o agente do Instana tenta usar o API padrão do JVM, ele injeta um componente carregador no JVM de destino. O carregador deve realizar várias operações para estabelecer o monitoramento, tais como criar um ` ClassLoaders, ` usando o `Instrumentation` API ` para modificar o bytecode, abrir uma conexão de saída ` TCP ` de volta ao agente e iniciar threads em segundo plano para a coleta de dados.

A estrutura de segurança do Elasticsearch bloqueia essas operações silenciosamente. Como resultado, o carregador não consegue concluir sua sequência de inicialização nem estabelecer a conexão de retorno de chamada necessária. O agente aguarda 90 segundos por uma resposta. Se não receber uma resposta, o agente marca o endereço JVM como excluído e interrompe todas as tentativas de monitoramento. Devido a esse comportamento, o agente do Instana não consegue monitorar os processos Elasticsearch, 8.18 + e Java.

Observação: as versões do Elasticsearch 8.18 e posteriores são compatíveis a partir da versão 1.2.61 do agente Instana, lançada sob a tag de alteração 2026.04.16.1110. Esta atualização introduz compatibilidade com o sistema de direitos do Elasticsearch por meio da transformação de bytecode. Isso permite que o agente do Instana funcione corretamente sem acionar violações de segurança ou de direitos d Elasticsearch.

Informações sobre o grupo de processadores em Windows

Editar online

Nos servidores d Windows, lançados entre 2008 e 2019, que utilizam mais de 64 núcleos, o agente do Instana pode monitorar apenas os núcleos do grupo de processadores que lhe foi atribuído. Essa limitação ocorre porque a versão atual do agente não reconhece grupos de processos, o que significa que ele não consegue identificar os núcleos que não fazem parte do grupo do processador.

Análise de rastreios e chamadas

Editar online

Quando as chamadas são agrupadas por log.level ou log.message, o grupo de tags especiais Tag not present não é exibido da mesma maneira que outras tags

Para obter mais informações sobre esse recurso, consulte Analisando rastreamentos e chamadas.

Filtragem com foco dinâmico

Editar online

Para obter mais informações sobre esse recurso, consulte Filtragem com foco dinâmico

Restrições de sintaxe

Editar online

Espaço em branco não é permitido entre o ! e a consulta a ser negado. Use !<query> ou NOT <query> no lugar.
Quando várias palavras-chave entity.application.name, entity.service.name, entity.endpoint.name do Dynamic Focus são usadas juntas, elas podem ser unidas somente pelo operador OR. E.g. Essas consultas não são entity.application.name:foo AND entity.application.name:barentity.application.name:foo entity.application.name:bar suportadas. A consulta entity.application.name:foo OR entity.application.name:bar é suportada.
Quando várias das diferentes palavras-chave entity.application.name, entity.service.name, entity.endpoint.name do Dynamic Focus são usadas juntas, elas podem ser unidas somente pelo operador AND. E.g. a consulta entity.application.name:foo OR entity.service.name:bar não é suportada, enquanto que a consulta entity.application.name:foo AND entity.service.name:bar é suportada.
Consultas contendo uma negação de aplicativo, serviço ou nome de terminal não são suportadas. Consequentemente, NOT entity.application.name:foo, !entity.service.name:bar e NOT entity.endpoint.name:foobar não são válidas. No entanto, a filtragem de eventos de um aplicativo, serviço ou terminal ainda é possível usando NOT event.entity.label:foo no lugar.
Consultas de Foco Dinâmico entity.application.name:<term>, entity.service.name:<term> e entity.endpoint.name:<term> são avaliadas usando a sequência contains lógica, por exemplo, Consulta de Foco Dinâmico entity.application.name:shop também corresponderia entity.application.name:shop-frontend.
As palavras-chave de consulta entity.application.name, entity.service.name e entity.endpoint.name do Dynamic Focus são suportados apenas em consultas booleanas (consulte as restrições da lógica booleana acima), consultas de termos, consultas de frase e consultas de prefixo.

Limitações de consulta

Editar online

A consulta de Dynamic Focus em event.text contendo hifens pode retornar resultados inesperados. Por ex. event.text:"foo-bar-random" também retornaria eventos contendo apenas foo ou bar ou random devido à tokenização do analisador Lucene.
As entidades a seguir como um contêiner Docker , como Host ou Zona de disponibilidade, não podem ser selecionadas ao definir o escopo na maioria das palavras-chave do Kubernetes . Como exemplo, a consulta entity.kubernetes.deployment.name:my-K8s-deployment AND entity.selfType:host não retorna nenhum host. Por outro lado, a consulta entity.kubernetes.deployment.name:my-K8s-deployment AND entity.selfType:docker retorna todos os contêineres do Docker relacionados à implementação. No entanto, há algumas palavras-chave do Kubernetes que podem ser usadas para selecionar entidades de Host, isto é, entity.kubernetes.cluster.* e entity.kubernetes.node.*. Por exemplo, a consulta entity.kubernetes.cluster.label:my-K8s-cluster AND entity.selfType:host retorna todos os hosts relacionados do cluster.

Métricas de infraestrutura

Editar online

Por motivos de desempenho, as entidades estão limitadas a exibir no máximo 3.000 métricas na interface do usuário do Instana. Painéis com mais métricas do que esse limite terão métricas ausentes.
Valores de métrica negativos não são exibidos.

Monitoramento do Enzima Conversora de Eletroquímicos ( IBM App Connect Enterprise, ACE)

Editar online

Se a verificação de integridade de certificado ( HTTPS ) estiver ativada para a interface REST API, é necessário especificar os parâmetros keystore e keystorePassword no arquivo <agent_install_dir>/etc/instana/configuration.yaml. Para o tipo de keystore, apenas JKS ou P12 é suportado.
O método de rastreamento de user exit do ACE suporta apenas configurações de um único nó. Configurações de alta disponibilidade (HA) e ambientes em cluster não são suportados. Para implantações de HA ou ambientes em cluster, utilize o suporte nativo ao rastreamento do ` OpenTelemetry ` em vez do método de saída do usuário.

Para obter mais informações sobre esse recurso, consulte Monitoramento do ACE ( IBM App Connect Enterprise )

Monitoramento de um aplicativ IBM API Connect

Editar online

DataPower O rastreamento é compatível apenas com o gateway de protocolo único ( API ) e não é compatível com outros serviços, como o gateway multiprotocolo e o proxy de serviço web.

Para obter mais informações sobre esse recurso, consulte Monitoramento de um aplicativo do IBM API Connect

Jaeger traçando

Editar online

Os dados de rastreio coletados do Jaeger não seriam correlacionados com os dados de rastreio coletados via AutoTrace, resultando em traços separados mesmo se os sistemas rastreados por Jaeger e Instana AutoTrace, respectivamente, estivessem interagindo diretamente uns com os outros.
Como os dados de rastreamento do ` Jaeger ` não indicam qual processo os está enviando ao agente do host, o ` Instana ` correlaciona esses rastreamentos com o host no qual o agente do host está hospedado. Isso impede a associação com o processo e, consequentemente, também com a hierarquia de contêineres e plataformas (por exemplo, um pod d Kubernetes, um namespace e um cluster).
Jaeger não possui nenhum mecanismo de monitoramento de usuários (embora isso possa vir a mudar com a adoção de W3C TraceContext.md); portanto, os beacons coletados pelo Instana Website Monitoring não serão correlacionados com os rastreamentos de back-end coletados em Jaeger.
O agente de host suporta a coleção de rastreios do Jaeger somente por meio de HTTP. O UDP, que é o protocolo usado ao configurar as variáveis de ambiente JAEGER_AGENT_HOST e JAEGER_AGENT_PORT, não é suportado.

Para obter mais informações sobre esse recurso, consulte Jaeger

OpenTelemetry traçando

Editar online

OpenTelemetry não links são compatíveis.
A combinação do propagador de contexto padrão d Instana com outros propagadores de W3C Trace Context contexto não é suportada. W3C Trace Context é o propagador de contexto padrão do ` OpenTelemetry `.

Para obter mais informações sobre esse recurso, consulte Rastreamento do OpenTelemetry

IBM MQ Traçado

Editar online

Um problema conhecido na plataforma Windows impede o uso conjunto dos níveis de monitoramento da fila de destino (IBMMQ_DEST_MONITOR_LEVEL_*) e do nível de monitoramento global (MONITOR_LEVEL).

Na plataforma AIX, o protocolo OTLP gRPC (ativado quando você define OTLP_EXPORTER_GRPC_ENDPOINT) não está disponível, portanto, HTTP é usado por padrão.

Zipkin traçando

Editar online

Os dados de rastreio coletados do Zipkin não seriam correlacionados com os dados de rastreio coletados via AutoTrace, resultando em traços separados mesmo se os sistemas rastreados por Zipkin e Instana AutoTrace, respectivamente, estivessem interagindo diretamente uns com os outros.
Zipkin não possui nenhum mecanismo de monitoramento de usuários (embora isso possa vir a mudar com a adoção de W3C TraceContext.md); portanto, os beacons coletados pelo Instana Website Monitoring não serão correlacionados com os rastreamentos de back-end coletados em Zipkin.
O agente de host suporta a coleta de rastreios do Zipkin somente por meio de HTTP, o que corresponde à configuração COLLECTOR_HTTP_ENABLED do Zipkin.

Para obter mais informações sobre esse recurso, consulte Zipkin

Monitorando o Containerd

Editar online

As métricas CPU Total Normalized e Memory Working Set Usage % estão disponíveis apenas em sistemas que estão usando Grupo de Controle v1 (cgroupv1).

Monitorando o Amazon MSK

Editar online

O sensor Amazon MSK suporta o monitoramento apenas para o tipo de cluster MSK fornecido. O tipo de cluster sem servidor não é suportado

Suporte da ALPN

Editar online

O agente e o backend do Instana oferecem suporte à conexão por meio da Negociação de Protocolo na Camada de Aplicação (ALPN) quando os seguintes requisitos são atendidos:

Netty 4.1.49.Final ou posterior
Java Kit de Desenvolvimento (JDK) 1.8.0_251 ou versão posterior

Como resolver o problema do alto consumo de CPU

Editar online

Alto uso de CPU é observado em agentes baseados em ponto de acesso com o contêiner do agente 1.263.3 e anterior. Para resolver esse problema, reinstale o agente O tamanho do cache de código reservado agora foi aumentado para suportar o alto uso de CPU. Para os agentes executados em um ambiente de host, remova o agente e, em seguida, reinstale-o.

Se você estiver usando Kubernetes (k8s) ou OpenShift Container Platform (OCP), conclua as etapas a seguir:

Desinstalar agente:

kubectl delete agents.instana.io instana-agent -n instana-agent --wait; helm uninstall instana-agent -n instana-agent; kubectl delete crd agents.instana.io; kubectl delete namespace instana-agent

Agente de instalação:

Para instalar o agente do Instana, use o gráfico do Helm disponível em Kubernetes ou OpenShift Container Platform.

Atributos de teste sintéticos

Editar online

O uso do Jest como um ` scriptType ` não é compatível com os testes Browser Simple, ` API Script` e ` API Simple` na interface do usuário e no ` API `. O Jest como um ` scriptType ` só pode ser usado com testes de script de navegador.

Alguns atributos de teste sintético não são compatíveis com a interface do usuário do Instana. Para definir esses atributos, use o Open API ou a synctl ferramenta. Os atributos não suportados na interface do usuário do Instana estão listados na tabela a seguir:


Atributo de teste..	Script de Navegador	Simples de Navegador	API Simple	API Script
navegador	☒	☒	N/D	N/D
expectExists	N/D	N/D	☒	N/D
expectNotEmpty	N/D	N/D	☒	N/D
ScriptType	☒	N/D	N/D	☒
HEAD (Operação)	N/D	N/D	☒	N/D
DELETE (Operação)	N/D	N/D	☒	N/D
OPTIONS (Operação)	N/D	N/D	☒	N/D
PATCH (Operação)	N/D	N/D	☒	N/D
POST (Operação)	N/D	N/D	☒	N/D
PUT (Operação)	N/D	N/D	☒	N/D

O símbolo ☒ indica que o atributo não é compatível com a interface do usuário do Instana.

N/A indica que o atributo não é aplicável para o tipo de teste

Processos de negócios

Editar online

Uma limitação conhecida em determinadas versões do BAW ( Business Automation Workflow ) executadas no IBM J9 JVM pode afetar os recursos dos processos de negócios. Esse problema pode fazer com que alguns ou todos os processos fiquem invisíveis ou inacessíveis no sistema.

Perspectivas do negócio

Editar online

A guia "Perspectivas de negócios" fica desativada se o Instana não detectar nenhum agente conectado. Para visualizar suas oportunidades de negócios, certifique-se de que haja pelo menos um agente conectado.

Renderização em tela

Editar online

Algumas telas podem não ser exibidas corretamente na interface do usuário do Instana ao usar o Safari. Isso inclui:

O mapa de fluxo dos processos de negócios
O gráfico de infraestrutura
Topologia das causas prováveis do evento
Gráfico do editor de configuração do coletor do OTel

Use outros navegadores, como o Chrome ou o Firefox, para obter uma melhor exibição.