Linkerd executa um proxy invisível ao lado de cada serviço em malha, portanto, sem a observabilidade no nível da malha, você pode ver o que seus serviços fazem, mas não como eles se comunicam entre si.
Esta integração usa o receptor Prometheus do OpenTelemetry Collector para extrair as métricas de proxy e do plano de controle do Linkerd automaticamente, sem alterações de código e sem instrumentação por serviço. Você obtém a taxa de solicitações, a latência e o status de mTLS para cada workload em malha de forma nativa, e pode, opcionalmente, adicionar distributed traces que unem os spans no nível da malha na mesma cascata que os traces de APM do seu aplicativo.
Principais benefícios
- Sinais clássicos no nível da malha: veja a taxa de solicitações, a latência (p50/p95/p99), a taxa de sucesso e as conexões TCP para cada workload em malha, coletados automaticamente sem alterar nenhum código de aplicativo.
- Visibilidade de mTLS e segurança: acompanhe a expiração de certificados, a taxa de rotação e as contagens de permissão/negação de autorização em um só lugar.
- Integridade do plano de controle: monitore a profundidade da fila, as contagens de endpoints ativos, a taxa de emissão de certificados e a atividade do injetor de proxy para o próprio plano de controle do Linkerd.
- Visibilidade de relacionamento do APM: quando você ativa o distributed tracing (Linkerd 2.19+), o Linkerd sintetiza os spans de proxy na mesma entidade que seus serviços de APM, para que você não precise de um backend de rastreamento separado.
- Zero alterações de código: o sidecar de proxy de cada pod em malha expõe métricas em
:4191, e o OTel Collector as extrai automaticamente.
Caso de uso
Se você for uma equipe de plataforma ou SRE executando microsserviços nativos do Kubernetes, a visibilidade no nível da malha ajuda a identificar o serviço upstream que está causando um pico de latência, capturar certificados mTLS antes que expirem, entender tempestades de novas tentativas e correlacionar a carga do plano de controle com o desempenho do aplicativo. Você obtém tudo isso de uma única entidade do New Relic.
Capacidades
- Métricas: taxa de requisições, latência (p50/p95/p99), taxa de sucesso e estatísticas de conexão TCP para cada workload na malha, além da expiração do certificado mTLS e da integridade do control-plane, coletadas automaticamente sem alterações de código
- Traces (opcional, Linkerd 2.19+): spans de proxy do Linkerd sintetizados na mesma cascata que seus traces de APM, para que a latência no nível da malha e os spans no nível do aplicativo apareçam juntos
- Logs: logs do contêiner sidecar
linkerd-proxyanexados à mesma entidade que as métricas e os traces - Entidades: uma entidade do Linkerd por workload em malha, correlacionada com a implantação subjacente do Kubernetes
Escolha seu caminho de instalação
- NRDOT com Helm (recomendado): distribuição do OpenTelemetry Collector com suporte da New Relic, instalada da mesma forma que a maioria dos usuários do Kubernetes já gerencia os releases do Helm
- NRDOT com manifesto: o mesmo coletor NRDOT, para clusters que gerenciam a configuração por meio de manifestos brutos do Kubernetes em vez do Helm
- OTel Collector Contrib com Helm: o OpenTelemetry Collector da comunidade, se você já o adotou como padrão em vez do NRDOT
- OTel Collector Contrib com manifesto: o mesmo coletor da comunidade, instalação baseada em manifesto
Instalação em um relance
- Verifique a compatibilidade e reúna os pré-requisitos
- Instale o coletor e configure-o para fazer o scrape do Linkerd
- Aplicar a configuração mínima
- Encontre e use os dados no New Relic
Próximo: instalar e configurar
- Usando o NRDOT com Helm
- Usando o NRDOT com manifesto
- Usando o OTel Collector Contrib com Helm
- Usando o OTel Collector Contrib com manifesto