Linkerd ejecuta un proxy invisible junto a cada servicio en la malla, por lo que sin observabilidad a nivel de malla puede ver lo que hacen los servicios, pero no cómo se comunican entre sí.
Esta integración utiliza el receptor Prometheus del Collector de OpenTelemetry para extraer las métricas del proxy y del plano de control de Linkerd automáticamente, sin cambios en el código y sin instrumentación por servicio. Obtiene la tasa de solicitudes, la latencia y el estado de mTLS para cada workload en la malla de forma predeterminada, y puede agregar opcionalmente rastreos distribuidos que unen los tramos a nivel de malla en la misma cascada que las trazas de APM de la aplicación.
Beneficios clave
- Señales doradas a nivel de malla: vea la tasa de solicitudes, la latencia (p50/p95/p99), la tasa de éxito y las conexiones TCP para cada workload en la malla, recopiladas automáticamente sin cambiar ningún código de la aplicación.
- Visibilidad de mTLS y seguridad: rastree el vencimiento de certificados, la tasa de rotación y los recuentos de permisos/denegaciones de autorización en un solo lugar.
- Estado del plano de control: monitoree la profundidad de la cola, los recuentos de extremos activos, la tasa de emisión de certificados y la actividad del inyector de proxy para el propio plano de control de Linkerd.
- Visibilidad de relaciones de APM: cuando habilita el rastreo distribuido (Linkerd 2.19+), Linkerd sintetiza los spans de proxy en la misma entidad que los servicios de APM, por lo que no necesita un backend de rastreo independiente.
- Cero cambios de código: el sidecar proxy de cada pod en la malla expone métricas en
:4191, y el OTel Collector las recopila automáticamente.
Caso de uso
Si es un equipo de plataforma o de ingeniería de fiabilidad del sitio (SRE) que ejecuta microservicios nativos de Kubernetes, la visibilidad a nivel de malla le ayuda a identificar el servicio ascendente que causa un pico de latencia, detectar certificados mTLS antes de que caduquen, comprender las tormentas de reintentos y correlacionar la carga del plano de control con el rendimiento de la aplicación. Obtiene todo esto desde una única entidad de New Relic.
Capacidades
- Métricas: tasa de solicitudes, latencia (p50/p95/p99), tasa de éxito y estadísticas de conexión TCP para cada workload en la malla, además del vencimiento del certificado mTLS y el estado del plano de control, recopiladas automáticamente sin cambios en el código
- Trazas (opcional, Linkerd 2.19+): spans del proxy de Linkerd sintetizados en la misma cascada que las trazas de APM, para que la latencia a nivel de malla y los spans a nivel de aplicación se muestren juntos
- Logs:
linkerd-proxyregistros de contenedor sidecar adjuntos a la misma entidad que las métricas y trazas - Entidades: una entidad de Linkerd por workload en malla, correlacionada con el despliegue subyacente de Kubernetes
Elija su ruta de instalación
- NRDOT con Helm (recomendado): distribución de OpenTelemetry Collector con soporte de New Relic, instalada de la misma manera en que la mayoría de los usuarios de Kubernetes ya gestionan las versiones de Helm
- NRDOT con manifiesto: el mismo recolector de NRDOT, para clústeres que administran la configuración a través de manifiestos de Kubernetes sin procesar en lugar de Helm
- OTel Collector Contrib con Helm: el OpenTelemetry Collector de la comunidad, si ya está estandarizado en él en lugar de NRDOT
- OTel Collector Contrib con manifiesto: el mismo recolector de la comunidad, instalación basada en manifiesto
Instalación de un vistazo
- Verifique la compatibilidad y reúna los requisitos previos
- Instale el recolector y configúrelo para recopilar datos de Linkerd
- Aplique la configuración mínima
- Encuentre y use los datos en New Relic
Siguiente: instalar y configurar
- Uso de NRDOT con Helm
- Uso de NRDOT con manifiesto
- Uso de OTel Collector Contrib con Helm
- Uso de OTel Collector Contrib con manifiesto