Seguimiento de cambios en New Relic con GitHub Actions

Cuando una alerta te despierta a las 3 de la mañana, lo último que quieres es perder tiempo descifrando gráficos. El seguimiento de cambios en New Relic te permite visualizar cada despliegue como un marcador sobre tus métricas, para que sepas qué cambió, quién lo hizo y cómo impactó el rendimiento de tu aplicación.

¿Qué es el seguimiento de cambios y por qué importa?

El change tracking coloca marcadores visuales sobre tus gráficos cada vez que ocurre un despliegue o modificación. Así dejas de adivinar y empiezas a correlacionar causa y efecto.

Esta capacidad reduce el tiempo de investigación, contextualiza el rendimiento con marcadores de despliegue, ayuda a identificar regresiones y mejora la comunicación del equipo. Cada marcador trae detalles de quién hizo el cambio, así puedes contactar directamente a esa persona si necesitas resolver algo rápido [0:55].

¿Qué es un marcador de seguimiento de cambios? Es una marca visual sobre tus gráficos en New Relic que indica que ocurrió un despliegue o modificación. Incluye autor, versión y métricas asociadas para entender su impacto.

¿Qué capacidades ofrece change tracking en New Relic?

La plataforma combina varias formas de registrar y visualizar los cambios. Estas son las cuatro principales:

• Registro de cambios vía New Relic API, NerdGraph, CLI, Jenkins o GitHub Actions.
• Visualización de marcadores en APM, browser, infraestructura y demás productos.
• Interfaz detallada con tendencias de logs, errores y análisis de impacto.
• Almacenamiento inmutable durante 13 meses en su forma original [2:20].

Esa retención de 13 meses es clave: puedes consultar cambios anteriores y usarlos como referencia cuando un despliegue nuevo se comporte raro.

¿Cómo configurar GitHub Actions para change tracking?

El flujo arranca dentro de la plataforma de New Relic, en la entidad APM que quieras instrumentar. En el ejemplo trabajamos con el servicio Space Rover Fleet Command.

Generar la API key de usuario

Desde la página de resumen de APM, busca el recuadro de deployments y haz clic en configurar ahora. Esto abre la instalación guiada con todos los métodos disponibles. Selecciona GitHub Actions y genera una nueva user API key o reutiliza una existente. Copia la clave porque la necesitarás como secreto en GitHub [3:35].

Guardar los secretos en el repositorio

En tu repositorio de GitHub, ve a Settings, luego a Secrets and variables bajo seguridad, y entra a Actions. Necesitas crear dos repository secrets con los nombres exactos que indica New Relic:

• El primero corresponde a tu New Relic user API key.
• El segundo es el GUID de la entidad que estás instrumentando.

Los nombres tienen que coincidir tal cual los muestra New Relic, porque el archivo YAML los va a referenciar literalmente.

¿Por qué necesito dos secretos en GitHub? Uno autentica tu cuenta con New Relic mediante la API key, y el otro identifica la entidad específica con su GUID. Sin ambos, la acción no puede crear el marcador.

¿Cómo se estructura el archivo YAML del workflow?

Dentro de tu código fuente, crea el directorio .github/workflows y añade el archivo newrelic-change-tracking.yml con el contenido que entrega New Relic.

En la línea 2, el bloque on indica el desencadenante: en este caso, publicar un release. Puedes configurar otros disparadores como pull requests, pero los releases representan versiones estables del código. Después, el job le indica a New Relic que tome el release a partir de la tag, pasando atributos como API key y GUID. La acción comunica también qué usuario de GitHub realizó el cambio y qué versión se está publicando [7:10].

Una vez listo el archivo, haces commit, push, abres un pull request contra main y lo fusionas.

¿Cómo se crea el release que dispara el marcador?

Desde la página principal del repositorio, entra a Releases en la barra lateral derecha y crea uno nuevo. Asigna una tag nueva, por ejemplo 1.0.1, ponle un título descriptivo como Implementando change tracking y publica.

Un detalle importante: la acción solo se dispara con tags nuevas. Si reutilizas una etiqueta que ya existía, no se genera marcador. Por eso en la demo terminamos en la versión 1.0.2, después de que la 1.0.1 ya estuviera asociada a cambios previos [9:50]. El marcador tarda entre tres y cinco minutos en aparecer en la interfaz.

¿Qué información muestra la vista detallada del cambio?

Al hacer clic sobre el marcador, New Relic abre un panel con toda la telemetría relevante. En el lado derecho aparecen los detalles que vienen directamente de GitHub: autor, versión y descripción.

La vista incluye datos de impacto que te ayudan a entender el efecto real:

• Ocurrencias de errores y si hay nuevos grupos o regresiones.
• Variación de log messages, que en el ejemplo bajaron alrededor de 99%.
• Impacto en transacciones web, tiempo de respuesta y throughput.
• Predicción de comportamiento con datos de tres horas antes y después del cambio.

Esa predicción es una función reciente: New Relic usa tus datos históricos para proyectar cómo el cambio podría afectar el rendimiento futuro. Si ves un gráfico que parece caer en picada después del marcador, revisa bien, porque puede tratarse de la zona predictiva, no de datos reales [11:30].

¿Cuándo cobra sentido todo este flujo en producción?

Imagina que trabajas en una fintech y la alerta que te despierta está asociada al servicio de aprobación de verificación de crédito. Los clientes ven errores, la satisfacción cae y los ingresos se afectan porque las verificaciones no se completan.

Con un marcador de cambio puedes identificar al equipo responsable, contactarlo, encontrar la causa raíz y restablecer la experiencia del usuario sin pasar horas leyendo gráficos a ciegas. Toma una captura de pantalla de tu marcador y de la vista detallada, y compártela en los comentarios para que el resto del grupo vea cómo te quedó la implementación.