Les workflows remplacent le système notification classique pour . C'est une bonne nouvelle car Workflow est un système notification amélioré et flexible. Les workflows aident votre équipe à en savoir plus sur les erreurs potentielles dans le contexte plus large de votre stack afin que vous puissiez prendre des mesures immédiates et efficaces.
Que signifie cette migration pour votre équipe ? Dans notre modèle notification précédent, votre équipe créerait une condition d'alerte avec un seuil et un paramètre différents. Si cette condition était associée à une politique spécifique, qu'elle était violée et que vous souhaitiez que votre équipe en soit immédiatement informée, vous ajouteriez notification settings. Nos paramètres de notification indiqueraient à New Relic quelles données envoyer où.
Nous avons maintenant ajouté des workflows. À l’avenir, au lieu de configurer le canal de notification classique et de les associer à des politiques, des destinations notification sont créées et associées aux workflows. Les workflows peuvent traiter des données provenant d'une gamme de politiques et peuvent utiliser des attributs tels que des balises ou des priorités pour organiser les notifications.
À quoi s'attendre
La migration du système notification classique vers le workflow crée un destination pour chaque classic notification channel et les connecte à workflows créé pour chaque policy.. Seules les politiques avec des associations de canaux seront migrées.
- New Relic migrera automatiquement les comptes du 23 janvier au 15 mai 2023.
- New Relic peut migrer les comptes plus tôt, contactez simplement votre équipe de compte.
- Votre équipe peut éviter la migration automatisée en supprimant les canaux des politiques.
- Les API du canal de notification et les ressources Terraform continueront de fonctionner jusqu'au 31 décembre 2023.
Changements connus
La notification ne changera pas substantiellement pendant la migration. Ils continueront d’avoir les mêmes noms d’attributs et la plupart des mêmes valeurs. La migration vers le workflow modifiera les éléments suivants :
- Toutes les valeurs de l'attribut _url changeront et mèneront à des pages basées sur les problèmes, et non à des pages basées sur les événements d'alerte.
condition_idaura désormais toujours la même valeur quecondition_family_id. issue_ida été ajouté. le consommateur devrait changer toutes les intégrations pour utiliser leissue_idau lieu duincident_id, car leincident_idsera supprimé à un moment donné.radar_entity.entityGuidettargets[0].idsera un GUID d'entité lorsqu'il en existe un disponible pour tous les types, à l'exception des Webhooks.targets[0].labelscontiendra toutes les balises du problème, pas seulement la balise de l'entité définie par la cible.targets[0].linketviolation_callback_urlmènera à la page du problème.open_violations_count.criticalcontiendra le nombre de tous les événements d'alerte ouverts, toutes priorités confondues. Les décomptes spécifiques aux priorités sont indisponibles.open_violations_count.warningsera toujours0. Les décomptes spécifiques prioritaires ne sont pas disponibles.closed_violations_count.criticalcontiendra le nombre de tous les événements d'alerte fermés pour toutes les priorités. Les décomptes spécifiques aux priorités sont indisponibles.closed_violations_count.warningsera toujours0. Les décomptes spécifiques prioritaires ne sont pas disponibles.owneraura une valeur NA si le problème n'a pas été reconnu.timestamp_utc_stringpassera du formatYYYY-MM-DD, HH:MM UTCau formatYYYY-MM-DDThh:mm:ss.sssZconforme à la norme ISO 8601.violation_chart_urlaura une valeur deNot Availablesi la génération du graphique a échoué ou n'est pas revenue en temps opportun.- L'expéditeur de l'e-mail deviendra
noreply@notifications.newrelic.com.
incident_id
Le incident_id des notifications PagerDuty, Webhook, VictorOps, OpsGenie et xMatters fait référence à l'identifiant d'événement d'alerte classique. L'ID d'événement d'alerte classique est obsolète. Les consommateurs devraient commencer à utiliser le issue_id à la place.
Incident_id changements:
- Un
incident_idunique sera toujours généré pour chaque problème. La valeur sera différente de celles utilisées dans l’ API d’incident obsolète. - Pour limiter l'impact sur les notifications VictorOps, OpsGenie et xMatters, le
incident_idsera renseigné avec l'identifiant du problème. Cela empêchera les étapes New Relic d'acquitter ou de fermer un événement d'alerte dans xMatters de fonctionner.
Configuration des frais personnalisés
Lorsque vous passez du canal de notification aux workflows, votre équipe souhaitera peut-être apporter quelques modifications à votre charge personnalisée. Le workflow fonctionne toujours de la même manière que la notification dans le sens où, lorsqu'une condition n'est pas respectée, une notification est envoyée à un webhook et lorsqu'elle est envoyée, elle est accompagnée de ses frais personnalisés. La migration du canal de notification vers le workflow nécessite de modifier une partie de la terminologie de cette charge.
Le tableau suivant fournit une traduction entre les noms de charge utile du webhook utilisés dans notre système de notification classique et leurs nouveaux noms correspondants dans la charge utile du problème. Handlebars est le langage de création de modèles simple utilisé pour écrire des modèles de messages.
Pour de nombreuses clés, la charge utile du problème peut contenir une liste de valeurs. Pour fournir une modélisation un à un, seule la première valeur est utilisée dans le remplacement.
Alerts (classic) name | Alerts (classic) variable | Workflow message template replacement |
|---|---|---|
|
|
|
|
|
|
|
|
Le nombre d'événements d'alerte fermés pour toutes les priorités. |
|
|
Il n'existe pas de remplacement pour le nombre d'avertissements. Tous les décomptes d'événements d'alerte fermés seront représentés comme critiques pour éviter le double comptage des événements d'alerte. |
|
|
La description de l'événement d'alerte personnalisée, si elle est définie. |
|
|
|
| N/A |
Valable uniquement pour les conditions . |
| N/A |
Valable uniquement pour les conditions . |
|
|
|
|
|
L'état d'un problème comporte plusieurs états, mais n'en a pas pour reconnu. |
|
|
|
|
|
|
|
|
Il n’y a aucun attribut correspondant au niveau du problème. |
|
|
|
|
|
Préférez |
|
|
|
|
|
|
|
| |
|
|
Nombre d'événements d'alerte ouverts pour tous les événements d'alerte, quelle que soit la priorité. |
|
|
Nombre d'événements d'alerte ouverts pour tous les événements d'alerte, quelle que soit la priorité. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Un problème a une priorité, qui peut avoir des valeurs différentes de la gravité. |
|
| |
|
|
|
|
|
|
|
|
Il n’y a aucun attribut correspondant au niveau du problème. |
|
|
|
|
|
|