Limites de calcul Autopilot

Les limites de calcul de New Relic Autopilot offrent un niveau de gouvernance budgétaire pour aider à mieux gérer les budgets d’entreprise. Les événement d’observabilité à haute fréquence (tels que les tempêtes d’alertes d’incident ou les défaillances de conditions en cascade) peuvent déclencher des rafales de prompt d’investigation ou d’analyses qui peuvent faire grimper les coûts des ressources de calcul, entraînant potentiellement des surprises sur la facture. Les limites de calcul de New Relic Autopilot aident à fournir une budgétisation proactive basée sur des politiques qui vous permet de mettre en œuvre certaines limites opérationnelles pour les coûts liés aux exécutions de Autopilot.

Les allocations de calcul d’entreprise sont configurées par les gestionnaires de l’organisation sous forme de budgets quotidiens et mensuels libellés en unité de capacité de calcul Advanced Compute (Advanced CCU). Ces rôles peuvent désormais créer des sous-budgets pour les workflows d’identité système (SI) relatifs à New Relic Autopilot. Les investigations d’alertes en arrière-plan contiennent également leur propre allocation dédiée. Définir des budgets pour ces actions vous aide à mieux gérer le quota de calcul utilisé lors des investigations actives d’incident à l’aide de Autopilot.

Rôles d’utilisateur et capacités de gouvernance

Le contrôle d’accès pour les limites de calculer de Autopilot suit le framework de contrôle d’accès basé sur les rôles (RBAC) de New Relic. La matrice ci-dessous définit les autorités administratives par rapport aux capacités opérationnelles en lecture seule à travers les workflows de la plateforme :

La section suivante détaille les workflows, et les procédures administratifs requis pour configurer les limites de calcul au sein de la plateforme New Relic.

Configurer les budgets de calculer (workflow d’administration)

Les budgets de calcul permettent aux responsables d’aider à faire respecter les politiques financières, ou les politiques budgétaires avec des contraintes configurables dans l’interface utilisateur. En utilisant l’interface utilisateur de New Relic, les administrateur établissent des limites organisationnelles qui appliquent dynamiquement les limites souhaitées sur l’exécution du système à travers les sessions interactives, et l’automatisation en arrière-plan.

Navigation dans l’interface utilisateur et paramètres configurables

Pour configurer les budgets de calculer, accédez à Autopilot Configuration Modal / Onboarding Panel > Compute Limits & Budgeting.

Les administrateurs peuvent définir quatre paramètres principaux dans l’interface de configuration :

• Budget Autopilot quotidien total (CCU avancés/jour): définit le plafond de dépenses à l’échelle de l’entreprise pour toutes les sessions utilisateur interactives, et les workflows automatisés combinés par jour civil (évalué dans le fuseau horaire de l’organisation).
• Sous-budget quotidien automatisé, et asynchrone (CCU avancés/jour): alloue un sous-quota quotidien dédié strictement aux workflows d’identité du système (SI), tels que les webhooks d’alerte, et les notification de workflow.
• Budget Autopilot mensuel total (CCU avancées/mois): établit le plafond du budget de calculer mensuel au niveau macro pour toutes les exécutions Autopilot.
• Sous-budget mensuel automatisé et asynchrone (Advanced CCUs/mois): définit une sous-allocation mensuelle dédiée exclusivement réservée aux investigations autonomes en arrière-plan.

Règles de validation des paramètres, et mécanismes de conversion backend

L’interface utilisateur de la plateforme applique des règles de validation des intrants au point d’entrée de la configuration pour éviter des états de politique invalides ou conflictuels :

• Règle 1 (Hiérarchie des sous-budgets): les sous-budgets automatisés doivent être strictement inférieurs à leur budget total correspondant (Automated Sub-budget < Total budget).
• Règle 2 (Multiplicateur temporel): lorsque les budgets quotidiens, et mensuels sont configurés, le budget mensuel ne doit pas dépasser 30 fois le budget quotidien (Monthly budget <= 30 * Daily budget).
• Flexibilité de la politique: tous les paramètres de limite sont facultatifs. Les organisations peuvent configurer des politiques partielles (comme l’application d’un budget total quotidien sans budget mensuel) en fonction de besoins opérationnels spécifiques.

Les administrateurs définissent des limites de budget à l’aide d’une seule métrique (Advanced CCUs), créant une limite de dépenses exacte, et non négociable qui empêche automatiquement une IA d’accumuler d’énormes factures inattendues lors de l’exécution de tâches rapides, et complexes.

Spécification du log des modifications d’audit

Chaque modification de configuration est suivie dans NrAuditEvent comme suit :

Une fois que les politiques administratives sont enregistrées, et validées, la plateforme évalue dynamiquement les seuil de budget pour appliquer des états d’exécution déterministes pour tous les utilisateur.

Expérience utilisateur, et seuils de budget

Autopilot fonctionne de manière déterministe : les requests s’exécutent avec un raisonnement de modèle complet à plusieurs étapes, ou sont bloquées à l’entrée une fois que les budgets sont atteints.

Machine à états, et comportements d’exécution

Le système évalue la consommation de calcul sur trois niveaux opérationnels en fonction des dépenses totales par rapport au budget configuré :

Format d’affichage de la carte d’erreur de l’interface utilisateur

Lorsqu’une organisation atteint 100 % de son allocation de calculer, les sessions de chat interactives présentent la carte d’erreur standard suivante :

⚠️ Limite quotidienne de calcul (compute) pour Autopilot atteinte

Votre organisation a consommé 100 % de son budget de calcul quotidien alloué (limite d’Advanced CCU dépassée). Le raisonnement interactif et les investigations automatisées sont temporairement suspendus.

Prochaines étapes: contactez le manager de votre organisation New Relic pour augmenter votre budget, ou réessayez après la réinitialisation de minuit (00:00 UTC).

Alors que les sessions interactives d’utilisateur fournissent des indicateurs visuels et un retour immédiat par carte d’erreur, les opérations automatisées en arrière-plan nécessitent des cycles de vie de traitement dédiés.

Échec de récupération de la métrique en temps réel, et état indisponible

Lorsque l’interface utilisateur de la plateforme est incapable de récupérer les métriques d’utilisation en temps réel à partir du cache de télémétrie du backend, le système passe à un état visuel dégradé non bloquant. L’application du budget du backend reste continuellement active indépendamment de la disponibilité des données de l’interface utilisateur.

• Texte du badge de la pastille de statut: affiche Daily Usage: Unavailable ⚠ dans la barre de contexte.
• Infobulle contextuelle: au survol de la pastille indisponible, affiche : "impossible de récupérer les métriques d’utilisation en temps réel. L’application de votre budget backend reste active. [Réessayer]"

Triage automatisé des alertes, et workflows d’identité du système (SI) asynchrones

Le triage automatisé d’incident repose sur les workflows d’identité du système (SI) qui traitent les alertes entrantes de manière asynchrone. Pendant les pannes majeures du système, les tempêtes d’alertes (« thunderstorms ») peuvent déclencher simultanément des dizaines de webhooks concurrents. Les sous-budgets SI dédiés isolent le moteur d’ingestion en arrière-plan, garantissant que les rafales d’alertes automatisées n’impactent pas les budgets d’investigation humaine interactive.

Cycle de vie d’exécution de l’identité du système

Lorsqu’un déclencheur automatisé se produit (par exemple, alert_webhook ou workflow_notification), le chemin d’exécution varie en fonction de la consommation actuelle du sous-budget :

Cas limites, budgets de simultanéité, et garanties

Les budgets quotidiens et mensuels d’Advanced CCU évaluent les dépenses cumulées totales, mais ils ne peuvent pas empêcher les rafales soudaines d’événement où des centaines de webhooks entrants se déclenchent simultanément avant que l’utilisation ne puisse être traitée et écrite dans le stockage de télémétrie. Pour gérer ces scénarios extrêmes, la plateforme utilise des mesures de protection de défense en profondeur à la porte d’entrée.

Architecture d’atténuation des tempêtes d’alertes

Pour maintenir la stabilité de la plateforme et protéger les budgets de l’organisation lors de pics d’alertes soudains, deux mécanismes de protection simultanés opèrent à la porte d’entrée :

• Budget de simultanéité automatisé par organisation: impose un plafond strict d’un maximum de 20 exécutions automatisées actives simultanées par organisation. Les requêtes arrivant pendant que 20 exécutions automatisées sont en cours sont immédiatement rejetées.
• Réservations Valkey atomiques: avant de générer une tâche d’exécution asynchrone (asyncio.create_task), la porte d’entrée incrémente de manière atomique les compteurs Valkey à grande vitesse selon une estimation prudente. À la fin de l’exécution, le moteur d’orchestration réconcilie la réservation avec la consommation réelle. Si une réservation initiale amène le compteur de l’organisation à dépasser sa limite configurée, la transaction est annulée, et la demande est immédiatement rejetée.

Haute disponibilité, et reprise après sinistre : politique de secours en cas de panne de Valkey

Pendant les pannes du cache local, ou de l’infrastructure Valkey, le moteur d’orchestration applique une politique de repli opérationnel par niveau :

Rapprochement de la facturation, décalage des données, et clauses de non-responsabilité

Les architectures de systèmes distribués maintiennent une séparation structurelle entre le contrôle d’entrée en temps réel et le traitement asynchrone des métriques de facturation.

Architecture des compteurs, et rapprochement des décalages de pipeline

La plateforme utilise un modèle à double stockage pour équilibrer l’application à faible latence avec la précision comptable :

• Couche d’application en temps réel: les compteurs Valkey inférieurs à la milliseconde évaluent les points d’entrée pour bloquer instantanément les exécutions dépassant le budget.
• Pipeline de facturation et de reporting: les pipeline de métrique NRDB historiques (resourceConsumption) agrègent les données de manière asynchrone, avec un décalage de traitement prévu de 2 heures.
• Absorption de la marge d’erreur: en raison de la simultanéité d’exécution à haute fréquence, un léger décalage des compteurs peut créer une variance de dépassement temporaire de 5 % à 10 %. New Relic absorbe tous les coûts de dépassement en interne ; les comptes clients ne sont jamais facturés pour une utilisation qui dépasse leur budget strict explicitement configuré.

Remarques et limitations importantes