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. Le flux de travail aide 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é un flux de travail. À 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 au flux de travail. Le flux de travail peut traiter des données provenant d'une gamme de politiques et peut 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 d'attribut _url changeront et conduiront à des pages basées sur des problèmes, et non à des pages basées sur incident .
condition_id
aura désormais toujours la même valeur quecondition_family_id
. issue_id
a été ajouté. le consommateur devrait changer toutes les intégrations pour utiliser leissue_id
au lieu duincident_id
, car leincident_id
sera supprimé à un moment donné.radar_entity.entityGuid
ettargets[0].id
sera un GUID d'entité lorsqu'il en existe un disponible pour tous les types, à l'exception des Webhooks.targets[0].labels
contiendra toutes les balises du problème, pas seulement la balise de l'entité définie par la cible.targets[0].link
etviolation_callback_url
mènera à la page du problème.open_violations_count.critical
contiendra le nombre de tous les incidents ouverts dans toutes les priorités. Les décomptes spécifiques prioritaires ne sont pas disponibles.open_violations_count.warning
sera toujours0
. Les décomptes spécifiques prioritaires ne sont pas disponibles.closed_violations_count.critical
contiendra le nombre de tous les incidents clôturés dans toutes les priorités. Les décomptes spécifiques prioritaires ne sont pas disponibles.closed_violations_count.warning
sera toujours0
. Les décomptes spécifiques prioritaires ne sont pas disponibles.owner
aura une valeur NA si le problème n'a pas été reconnu.timestamp_utc_string
passera du formatYYYY-MM-DD, HH:MM UTC
au formatYYYY-MM-DDThh:mm:ss.sssZ
conforme à la norme ISO 8601.violation_chart_url
aura une valeur deNot Available
si 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
La notification incident_id
sur PagerDuty, Webhook, VictorOps, OpsGenie et xMatters fait référence à l'ID incident classique. L'ID d'incident classique est obsolète. Le consommateur devrait plutôt commencer à utiliser le issue_id
.
Incident_id
changements:
- Un
incident_id
unique 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_id
sera renseigné par l'ID du problème. Cela entraînera que les étapes New Relic permettant de reconnaître ou de fermer un incident dans xMatters ne fonctionneront plus.
Configuration des frais personnalisés
Lorsque vous passez du canal de notification au flux de travail, 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'incidents clôturés dans toutes les priorités. |
|
|
Rien ne remplace les avertissements. Tous incident fermés seront représentés comme critiques pour éviter un double comptage des incidents. |
|
|
La description de l'incident personnalisé, 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 |
|
|
|
|
|
|
|
|
|
|
|
Ouvrir le incident de tous incident quelle que soit leur priorité. |
|
|
Ouvrir le incident de tous les incidents, quelle que soit leur 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. |
|
|
|
|
|
|