Uno de los principios clave para operar un sistema fiable es enfocarse en lo que realmente importa medir. Esto implica evaluar tanto lo que es esencial para el negocio como lo que es fundamental para la resolución de problemas. New Relic mide lo esencial utilizando New Relic. Esto incluye el uso de nuestros agentes, el producto de objetivos de nivel de servicio (SLO) y el producto de alertas.
Agentes APM en New Relic
A los equipos de ingeniería les gusta ejecutar el agente de monitoreo del rendimiento de aplicaciones (APM) para sus servicios, y todo el hardware suele monitorearse mediante el agente de infraestructura de New Relic. Esto crea un conjunto coherente de métricas para que cualquier ingeniero pueda pasar de un servicio a otro y seguir comprendiendo las métricas de salud esenciales.
Los agentes APM de New Relic están cuidadosamente ajustados para proporcionar las métricas clave necesarias para detectar y diagnosticar problemas de servicio. Entre estas métricas clave se incluyen los tiempos de respuesta HTTP, los tiempos de llamadas a bases de datos y los tiempos de llamadas HTTP externas.
Además, aunque los equipos dedicados a los agentes suelen añadir nueva instrumentación a nuestros agentes, otros equipos de ingeniería —aquellos que utilizan los agentes para monitorear su propia infraestructura, bases de datos y servicios de streaming— también han contribuido con instrumentación para nuestros agentes. Un gran ejemplo es la instrumentación actual de Kafka en el agente de Java. Esta instrumentación fue creada originalmente por un equipo de New Relic que gestiona muchos servicios de streaming de Kafka. Esta instrumentación fue creada originalmente como una extensión del agente de Java. Después de que muchos equipos internos la adoptaran, la instrumentación se incorporó finalmente al producto APM. La UI de Kafka, que muestra estas métricas, también fue creada conjuntamente por un equipo de producto APM junto con nuestros equipos principales de Kafka y de servicios de streaming.
Instrumentación efectiva
Uso de dashboards y Nerdpacks para eliminar los cambios de contexto
Los equipos de New Relic están formados para pensar en los datos de observabilidad durante el desarrollo. Además de la instrumentación predeterminada que proporcionan nuestros agentes, los equipos de ingeniería tienen la capacidad de crear instrumentación personalizada adicional. Algunos equipos envían instrumentación personalizada a New Relic utilizando agentes APM. Otros han creado bibliotecas para enviar la instrumentación directamente a nuestros extremos públicos de métricas, eventos, logs y trazas. Entre los ejemplos de instrumentación personalizada se incluyen un evento de New Relic para cada consulta a la base de datos de New Relic (NRDB) y un evento para cada conexión inicial de un agente APM a New Relic. Luego, los equipos muestran estos eventos personalizados en dashboards o Nerdpacks personalizados (aplicaciones personalizadas). Estas aplicaciones personalizadas integran instrucciones textuales con resultados de consultas en vivo y visualizaciones.
Por ejemplo, los problemas de bloqueo en los pipelines de Kafka pueden diagnosticarse mediante vistas en un Nerdlet personalizado, que además genera automáticamente el comando necesario para extender la retención de datos, transformando un proceso manual de varios pasos en una única acción de copiar y pegar. Esto reduce considerablemente los cambios de contexto y acelera la resolución.
Objetivos de nivel de servicio
Lograr objetivos empresariales con los SLO
Los SLO son importantes porque definen y miden la experiencia del cliente en un período de tiempo determinado. Son fundamentales para equilibrar el trabajo de fiabilidad con la incorporación de nuevas funcionalidades. En New Relic, requerimos que todos los equipos mantengan un conjunto interno de SLO. Antes de aplicar los SLO en toda la empresa, descubrimos que nuestros datos de telemetría eran muy ricos, pero estaban orientados a la resolución de problemas y no a medir la experiencia del cliente. Por ello, creamos un programa de mejora de SLO que ayudó a los equipos a crear SLO enfocados en el cliente, con valores que reflejaban la realidad del momento.
Gracias a estas mediciones, pudimos compartir con la dirección de la empresa el costo de operar con los SLO actuales y el trabajo necesario para incrementarlos. Los equipos que más se han beneficiado de los SLO supervisan sus SLO a diario y toman medidas correctivas cuando es necesario. Estos equipos no solo han mejorado la experiencia del cliente, sino que también han reducido considerablemente su carga de notificaciones.
Alertas y Terraform
Cómo automatizar la información proactiva
En New Relic, nuestros equipos usan New Relic Alerting para recibir notificaciones de cualquier anomalía del sistema. Esto permite a los ingenieros de New Relic actuar rápidamente para mitigar cualquier posible degradación del sistema. La mayoría de los equipos usa Terraform para crear y mantener sus alertas en el control de versiones. La mayoría de los equipos también usa alertas facet para asegurarse de que se creen alertas para cualquier nueva celda o entorno. A continuación, se muestra un ejemplo de alerta facet aplicado al nombre de host:
SELECT latest(etcdServerProposalsFailedRate) FROM K8sEtcdSample WHERE clusterName = 'my-cluster' FACET hostname
Para garantizar que los equipos tengan las alertas adecuadas, New Relic proporciona un conjunto de alertas recomendadas a los equipos en nuestros Estándares de ingeniería. Estas incluyen alertas por finalizaciones de procesos por falta de memoria (OOM), pods en espera, retraso en Kafka y tasas de error, entre otros. Luego, los líderes visualizan en dashboards las alertas de su equipo (ya que cada alerta se registra en el NRDB) y observan las tendencias semanalmente.