Conditions d'alerte pour Intelligence Coûts du cloud

Aperçu

Nous travaillons toujours sur cette fonctionnalité, mais nous aimerions que vous l'essayiez !

Cette fonctionnalité est actuellement fournie dans le cadre d'un programme d'aperçu conformément à nos politiques de pré-sortie.

Après avoir configuré Intelligence Coûts du cloud, créez des règles d’alerte avec des seuils pour recevoir des notifications proactives avant de dépasser les limites financières et éviter les frais inattendus. Dans un budget, vous pouvez définir plusieurs seuils d'alerte en fonction du pourcentage d'utilisation du budget.

Créer une nouvelle condition d'alerte

Une condition d'alerte est une requête exécutée en continu qui mesure un ensemble donné d'événements par rapport à un seuil défini et ouvre un incident lorsque le seuil est atteint pour une durée spécifiée.

Allez dans one.newrelic.com > Alerts > Alert Policies.
Sur la page de la liste des politiques, cliquez sur + New alert condition.
Pour créer des alertes à partir de zéro, utilisez Write your own query.

Définissez le comportement de votre signal

Vous pouvez utiliser une requête NRQL pour définir les signaux que vous souhaitez qu'une condition d’alerte utilise comme base pour votre alerte. Pour cet exemple, vous utiliserez cette requête :

FROM CloudCost SELECT sum(line_item_unblended_cost) FACET product_region_code

L'utilisation de cette requête pour votre condition d’alerte indique à New Relic que vous souhaitez connaître le coût non lissé ventilé par code de région du produit.

Pour en savoir plus sur l'utilisation de NRQL (le langage de requête de New Relic), consultez notre documentation NRQL.

Exécuter et prévisualiser votre signal

Après avoir défini votre signal, cliquez sur Run. Un graphique apparaîtra et affichera le paramètre que vous avez défini.
Conseil
Pour configurer des alertes inter-comptes, sélectionnez un data account dans la liste déroulante. Notez que vous ne pouvez interroger les données que d’un seul compte à la fois pour les alertes inter-comptes.
Pour cet exemple, le graphique affichera le coût d'utilisation estimé pour les ressources cloud de votre entreprise, ventilé par code de région du produit. Cela vous permet de monitorer le coût de vos ressources cloud dans différentes régions.
Cliquez sur Next et commencez à configurer votre condition d’alerte.

Fixer le seuil de condition d'alerte

Vous disposez désormais d'une condition entièrement définie et de règles pour ouvrir un incident si les seuils sont dépassés. Nommez la condition et associez-la à une stratégie pour terminer la configuration.

Fine-tune alert condition page with window duration highlighted

Ajouter des détails sur condition d'alerte

Votre condition d’alerte est entièrement définie et créera un incident lorsque vos seuils seront dépassés. Nommez cette condition et associez-la à une stratégie pour terminer la configuration.

Une stratégie est le système de tri pour vos incidents. Vous pouvez connecter des politiques à des workflows pour définir où vous souhaitez que New Relic envoie ces informations et à quelle fréquence.

A screenshot demonstrating how you can name a new alert condition.

Nom du champ	Description
Nommez votre condition d'alerte	Une bonne pratique pour nommer votre condition consiste à utiliser un format structuré qui transmet les informations essentielles en un coup d'œil. Incluez les éléments suivants dans les noms de vos conditions : Priorité: Indique la gravité ou l'urgence de l'alerte, comme P1, P2, P3. Signal: Spécifiez la métrique ou la condition monitorée, comme latence moyenne élevée ou débit faible. Entité: identifiez le système, l'application ou le composant affecté. Un exemple de nom de condition bien formé suivant cette structure serait `P2 \| High Avg Latency \| Cloud Cost Intelligence`.
Politique existante	Si vous avez déjà une politique que vous souhaitez connecter à une condition d’alerte, sélectionnez alors la politique existante. Consultez les règles d’alerte pour plus d’informations.
Nouvelle politique	Équilibrer la réactivité et la fatigue dans votre stratégie d'alerte est crucial. Explorons les options de stratégie : Un problème par politique (par défaut): Avantages: réduit le bruit et garantit une action immédiate. Inconvénients: regroupe tous les incidents sous un seul problème, même s'ils sont déclenchés par des conditions différentes. Ce n'est pas idéal pour les problématiques de pages vues multiples. Un problème par condition: Avantages: crée des problèmes distincts pour chaque condition, idéal pour isoler et résoudre des problèmes de latence spécifiques. Inconvénients: peut générer plus d'alertes, menant potentiellement à une fatigue. Un problème pour chaque incident: Avantages: fournit des détails granulaires pour les systèmes externes, mais n'est pas optimal pour une consommation interne en raison d'une surcharge potentielle. Inconvénients: c'est l'option la plus bruyante, et il est difficile de suivre les tendances plus larges et de hiérarchiser efficacement. Consultez Créer des politiques pour plus d’informations.
Fermer les événements d'alerte ouverts	Un incident se ferme automatiquement lorsque le signal cible revient à un état de non-violation pendant la période indiquée dans le seuil de la condition. Ce temps d’attente est appelé période de récupération. Lorsqu'un incident se ferme automatiquement : L'horodatage de clôture est rétroactif au début de la période de récupération. L'évaluation se réinitialise et redémarre à partir du moment où l'incident précédent s'est terminé. Toutes les conditions disposent d’un paramètre de limite de temps d’incident qui force automatiquement la fermeture d’un incident de longue durée. New Relic utilise automatiquement 3 jours par défaut et vous recommande d'utiliser nos paramètres par défaut pour votre première alerte. Une autre façon de fermer un incident ouvert lorsque le signal ne renvoie pas de données est de configurer un seuil `loss of signal` . Reportez-vous à la section sur le seuil de perte de signal ci-dessus pour plus de détails.
Modèle de titre	Étant donné que vous créez une condition d’alerte qui vous permet de savoir s'il existe des problèmes de latence avec votre `unblended cost`, vous souhaitez vous assurer que vos développeurs disposent de toutes les informations dont ils ont besoin lorsqu'ils sont informés de cet incident. Vous utiliserez le workflow pour informer un canal Slack d'équipe lorsqu'un incident est créé. Consultez incident personnalisé pour plus d’informations.
Modèle de description	L'utilisation du modèle de titre est facultative, mais nous la recommandons. Une condition d’alerte définit un ensemble de seuils que vous souhaitez monitorer. Si l'un de ces seuils est dépassé, un incident est créé. Des modèles de titre pertinents vous aident à identifier les problèmes et à résoudre les pannes plus rapidement. Consultez les modèles de titres pour plus d’informations.
URL du cahier d'exécution	Un runbook d'exploitation détaillant les étapes d'enquête, de triage ou de correction est souvent lié dans ce domaine.

Pour en savoir plus sur les alertes inter-comptes, consultez Alertes inter-comptes.