flujo de trabajo están reemplazando el tradicional sistema de notificación de . Esta es una buena noticia porque el flujo de trabajo es un sistema de notificación mejorado y flexible. flujo de trabajo ayuda a su equipo a conocer errores potenciales dentro del contexto más amplio de su stack para que pueda tomar medidas inmediatas y eficientes.
¿Qué significa esta migración para su equipo? En nuestro modelo de notificación anterior, su equipo crearía una condición de alerta con diferentes umbrales y parámetros. Si esa condición estuviera asociada con una política específica, se infringiera y quisiera que su equipo lo supiera de inmediato, agregaría notification settings. Nuestra configuración de notificaciones le indicaría a New Relic qué datos enviar y dónde.
Ahora hemos agregado flujo de trabajo. En el futuro, en lugar de configurar el canal de notificación clásico y asociarlos a políticas, se crean destinos de notificación y se asocian al flujo de trabajo. flujo de trabajo puede procesar datos de una variedad de políticas y puede usar atributos como etiqueta o prioridad para organizar la notificación.
Que esperar
La migración del sistema de notificaciones clásico a flujo de trabajo crea un destination para cada classic notification channel y los conecta a workflows creado para cada policy. Solo se migrarán políticas con asociaciones de canales.
- New Relic migrará automáticamente las cuentas del 23 de enero al 15 de mayo de 2023.
- New Relic puede migrar cuentas antes, solo comuníquese con su equipo de cuentas.
- Su equipo puede evitar la migración automatizada eliminando canales de las políticas.
- Las API del canal de notificación y los recursos de Terraform seguirán funcionando hasta el 31 de diciembre de 2023.
Cambios conocidos
La notificación no cambiará sustancialmente durante la migración. Continuarán teniendo los mismos nombres de atributos y la mayoría de los mismos valores. La migración a flujo de trabajo cambiará lo siguiente:
- Todos los valores del atributo _url cambiarán y conducirán a páginas basadas en problemas, no a páginas basadas en incidentes.
condition_id
ahora siempre tendrá el mismo valor quecondition_family_id
. issue_id
ha sido añadido. El consumidor debe cambiar toda la integración para usarissue_id
en lugar deincident_id
, ya queincident_id
se eliminará en algún momento.radar_entity.entityGuid
ytargets[0].id
será una guía de entidad cuando haya una disponible para todos los tipos excepto para Webhooks.targets[0].labels
contendrá todas las etiquetas del problema, no solo la etiqueta de la entidad definida por el objetivo.targets[0].link
yviolation_callback_url
le llevará a la página del problema.open_violations_count.critical
contendrá el recuento de todos los incidentes abiertos en todas las prioridades. Los recuentos específicos de prioridad no están disponibles.open_violations_count.warning
siempre será0
. Los recuentos específicos de prioridad no están disponibles.closed_violations_count.critical
contendrá el recuento de todos los incidentes cerrados en todas las prioridades. Los recuentos específicos de prioridad no están disponibles.closed_violations_count.warning
siempre será0
. Los recuentos específicos de prioridad no están disponibles.owner
tendrá un valor de NA si el problema no ha sido reconocido.timestamp_utc_string
cambiará del formatoYYYY-MM-DD, HH:MM UTC
al formatoYYYY-MM-DDThh:mm:ss.sssZ
compatible con ISO 8601.violation_chart_url
tendrá un valor deNot Available
si la generación del gráfico falló o no regresó de manera oportuna.- El remitente del correo electrónico cambiará a
noreply@notifications.newrelic.com
.
incident_id
El incident_id
en la notificación de PagerDuty, Webhook, VictorOps, OpsGenie y xMatters se refiere a la identificación de incidente clásica. La identificación de incidente clásica está en desuso. El consumidor debería comenzar a usar issue_id
en su lugar.
Incident_id
cambios:
- Se seguirá generando un
incident_id
único para cada problema. El valor será diferente a los utilizados en la API de incidentes obsoleta. - Para limitar el impacto en la notificación de VictorOps, OpsGenie y xMatters, el
incident_id
se completará con la identificación del problema. Eso hará que los pasos de New Relic para reconocer o cerrar un incidente en xMatters ya no funcionen.
Configurando carga personalizada
Al pasar del canal de notificación al flujo de trabajo, es posible que su equipo quiera hacer algunos ajustes a su carga personalizada. El flujo de trabajo todavía funciona de la misma manera que las notificaciones en el sentido de que, cuando se infringe una condición, se envía una notificación a un webhook y, cuando se envía, va con su carga útil personalizada. La migración del canal de notificación al flujo de trabajo requiere cambiar parte de la terminología en esta carga útil.
La siguiente tabla proporciona una traducción entre los nombres de carga útil de webhook utilizados en nuestro sistema de notificación clásico y sus nombres nuevos correspondientes en la carga útil del problema. Manillar es el lenguaje de plantillas simple que se utiliza para escribir plantillas de mensajes.
Para muchas claves, la carga útil del problema puede contener una lista de valores. Para proporcionar un mapeo uno a uno, solo se utiliza el primer valor en el reemplazo.
Alerts (classic) name | Alerts (classic) variable | Workflow message template replacement |
---|---|---|
|
|
|
|
|
|
|
|
El número de incidentes cerrados en todas las prioridades. |
|
|
No hay sustituto para los recuentos de advertencias. Todos los recuentos de incidentes cerrados se representarán como incidentes críticos para evitar un doble conteo. |
|
|
La descripción del incidente personalizada, si se define alguna. |
|
|
|
| N/A |
Sólo válido para condiciones. |
| N/A |
Sólo válido para condiciones. |
|
|
|
|
|
El estado de un problema tiene más estados, pero no tiene uno reconocido. |
|
|
|
|
|
|
|
|
No hay ningún atributo coincidente a nivel de problema. |
|
|
|
|
|
Prefiere |
|
|
|
|
|
|
|
|
|
|
|
El incidente abierto cuenta todos los incidentes independientemente de su prioridad. |
|
|
El incidente abierto cuenta todos los incidentes independientemente de su prioridad. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Un problema tiene prioridad, que puede tener valores diferentes a los de gravedad. |
|
|
|
|
|
|
|
|
|
|
|
No hay ningún atributo coincidente a nivel de problema. |
|
|
|
|
|
|