HTTP-Trigger im Azure SRE-Agent

HTTP-Trigger in Azure SRE Agent sind Webhook-Endpunkte, die externe Systeme verwenden, um Ihren Agent bei Bedarf aufzurufen. Wenn eine fortlaufende Integrations- und Kontinuierliche Übermittlung (CI/CD)-Pipeline fehlschlägt, erkennt ein Warnungstool eine Anomalie, oder ein HTTP-Client sendet eine POST Anforderung, erhält der Agent den Ereigniskontext und beginnt sofort mit der Arbeit.

Das Problem: Warnungen und Pipelinefehler benötigen eine manuelle Überprüfung

Ihr Team verfügt bereits über Benachrichtigungs-, Einblick- und Workflow-Tools wie Datadog, Dynatrace, Jira, Splunk und Grafana – sowie CI/CD-Pipelines, die fehlschlagen. Wenn ein Fehler auftritt, ist die Antwort jedes Mal gleich:

  • Ein Ingenieur wird per Pager benachrichtigt: Der Ingenieur öffnet das Überwachungstool, liest die Alarmmeldung und öffnet dann manuell Protokolle, Metriken und Bereitstellungsverläufe über mehrere Dashboards hinweg, um herauszufinden, was passiert ist.
  • Eine Pipeline schlägt fehl Jemand muss die aktuelle AKtivität unterbrechen, die Buildausgabe überprüfen, mit den letzten Änderungen korrelieren und entscheiden, ob ein Rollback oder ein Forward Fix durchgeführt werden soll.
  • Kontext ist verstreut: Die Datadog-Warnung besagt: "CPU-Anstieg auf prod-api". Die Ursache erfordert das Korrelieren von Protokollen aus drei Diensten, das Überprüfen der letzten Bereitstellungen und das Überprüfen von Dynatrace-Traces.

Funktionsweise von HTTP-Triggern

MIT HTTP-Triggern können Sie jedes Tool verbinden, das Webhooks direkt mit Ihrer Instanz des SRE-Agents unterstützt. Anstelle eines Technikers, der die manuelle Triage durchführt, teilt das System, das das Problem erkannt hat, unabhängig davon, ob es sich um eine Datadog-Warnung, eine Dynatrace-Anomalie, einen Jira-Workflowübergang oder einen Pipelinefehler handelt, dem Agent die Untersuchung an. Der Kontext wird automatisch übergeben.

Jeder Trigger ist ein benannter Webhook-Endpunkt auf Ihrem Agent mit einer eindeutigen URL. Wenn ein externes System diese URL über HTTP POSTaufruft, führt der Agent die konfigurierte Eingabeaufforderung des Triggers aus, die mit allen JSON-Daten im Anforderungstext bereichert wird.

Wichtige Konzepte

Konzept So funktioniert es
Auslöser Ein benannter Endpunkt mit einem Prompt, ein zugewiesener Agent (Standard- oder Unteragent) und eine Autonomiestufe (autonom oder Überprüfung).
Trigger-URL Die eindeutige Webhook-URL, die beim Erstellen eines Triggers generiert wird. Diese Webhook-URL wird von externen Tools aufgerufen.
JSON-Kontext Optionaler JSON-Text, der mit der POST Anforderung gesendet wird. Es wird Teil der Eingabeaufforderung des Agents, sodass er über vollständigen Kontext verfügt.
Ausführungsverlauf Jeder Aufruf wird mit einem Zeitstempel, Threadlink und Erfolgs- oder Fehlerstatus protokolliert.
Aktivieren/Deaktivieren Ein- oder Ausschalten von Triggern ohne Löschen. Deaktivierte Trigger geben 404 zurück.

Aufrufen eines Triggers

Rufen Sie die Trigger-URL mit einer HTTP-Anforderung POST auf:

curl -X POST \
  https://your-agent.sre.azure.com/api/v1/httptriggers/trigger/<TRIGGER_ID> \
  -H "Authorization: Bearer <ARM_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{
    "source": "datadog",
    "alert_title": "High error rate on checkout-api",
    "severity": "critical",
    "service": "checkout-api",
    "region": "eastus2",
    "metric": "error_rate",
    "value": "8.2%",
    "threshold": "5%"
  }'
Bauteil Was es ist
URL Der eindeutige Webhook-Endpunkt des Triggers. Suchen Sie sie in der Trigger-Detailansicht unter Trigger-URL.
Authorization Ein Azure Resource Manager Bearer-Token. Siehe Authentifizierung zum Auslösen des Aufrufs.
Inhaltstyp Muss application/json sein, wenn Sie einen JSON-Datenkörper senden.
JSON-Textkörper (optional) Alle JSON-Daten, die der Agent sehen soll. Diese Daten werden Teil der Aufforderung des Agenten. Geben Sie jeglichen Kontext an, der dem Agenten bei der Untersuchung hilft, wie zum Beispiel der Name der Warnung, der Schweregrad und der betroffene Dienst.

Der JSON-Text ist optional. Wenn Sie den Trigger ohne Textkörper aufrufen, wird der Agent nur mit der konfigurierten Eingabeaufforderung des Triggers ausgeführt. Mit einem Body sieht der Agent sowohl den Prompt als auch die von Ihnen gesendeten Daten.

Authentifizierung für Triggeraufrufe

Der Triggerendpunkt erfordert ein Azure Resource Manager Bearer-Token im Authorization: Bearer <TOKEN> Header. Der Aufrufer benötigt Microsoft.App/agents/threads/write die Berechtigung für die Agentressource.

Möglichkeiten zum Abrufen eines Tokens

Methode Am besten geeignet für: Einzelheiten
Service Principal CI/CD-Pipelines, automatisierte Systeme Erstellen Sie eine App-Registrierung, weisen Sie die Rolle der Agent-Ressource zu und nutzen Sie den Client-Credentials-Flow, um ein Token zu erhalten.
Verwaltete Identität Von Azure gehostete Dienste (Azure Functions, Azure Virtual Machines, Azure Container Apps) Keine Geheimnisse zu verwalten. Die Azure-Ressource authentifiziert sich automatisch.
Azure-Befehlszeilenschnittstelle (Azure CLI) Testen und Entwickeln Führen Sie az account get-access-token --resource https://management.azure.com --query accessToken -o tsv aus.

Verbinden externer Tools, die die Azure-Authentifizierung nicht unterstützen

Tools wie Datadog, Dynatrace, Jira und Splunk senden Webhooks mit ihren eigenen Authentifizierungsformaten, nicht mit Azure Resource Manager-Token. Um die Lücke zu überbrücken, verwenden Sie einen der folgenden Vermittler.

Vermittler So funktioniert es
Azure-Funktionen Empfängt den Webhook, ruft ein Azure Resource Manager-Token mithilfe seiner verwalteten Identität ab und leitet den Aufruf an die Trigger-URL weiter.
Azure Logic Apps Kein Codeworkflow, der Webhooks von allen Quellen empfängt und Azure-APIs mit integrierter Azure Resource Manager-Authentifizierung aufruft.
Azure-API-Verwaltung Befindet sich vor der URL des Triggers und handhabt die Token-Validierung und Transformation über Richtlinien.

Antwort

{
  "message": "HTTP trigger execution initiated",
  "executionTime": "2026-03-13T10:30:00Z",
  "threadId": "thread-abc123",
  "success": true
}

Der Trigger gibt HTTP 202 (Akzeptiert) sofort zurück. Der Agent verarbeitet die Anforderung asynchron.

Was macht diesen Ansatz anders

HTTP-Trigger verbinden Ihre vorhandenen Warn- und CI/CD-Tools direkt mit Ihrem Agenten, ohne dass ein Ingenieur im Prozess ist. Das System, das das Problem erkannt hat, weist den Agenten an, zu untersuchen, und übermittelt den vollständigen Kontext automatisch. Es gibt kein Paging, keinen Wechsel des Dashboards und kein manuelles Erfassen von Kontext.

Vor und nachher

Vorher (manuelles Triage) After (HTTP-Trigger)
Datadog-Alarm wird ausgelöst. Der Ingenieur erhält einen Pager-Alarm, öffnet drei Dashboards und beginnt die Untersuchung. Datadog-Webhook-Aufrufe lösen Aktionen aus. Der Agent untersucht und veröffentlicht Ergebnisse automatisch.
Pipelineunterbrechungen. Techniker überprüft Buildprotokolle, überprüft PRs und entscheidet über den nächsten Schritt. Auslöser für Aufrufe des Pipelinefehlerhandlers. Der Agent analysiert den Ausfall und veröffentlicht die Ursache.
Dynatrace erkennt Anomalien. Ingenieur korreliert manuell über Dienste hinweg. Dynatrace-Webhook-Anrufe werden mit Anomaliekontext ausgelöst. Der Agent korreliert Protokolle, Metriken und Bereitstellungen.

Geplante Aufgaben im Vergleich zu HTTP-Triggern

Geplante Vorgänge HTTP-Trigger
Zeitbasiert (chronologischer Zeitplan). Ereignisgesteuert (auf Abruf).
Wird unabhängig davon ausgeführt, ob etwas geschehen ist oder nicht. Wird nur ausgeführt, wenn aufgerufen.
Keine externe Eingabe pro Ausführung. Nutzlastdaten, die in jeden Aufruf eingefügt wurden.
Am besten geeignet für wiederkehrende Prüfungen. Am besten geeignet für ereignisgesteuerte Reaktionen.

Verwenden Sie beides zusammen. Verwenden Sie geplante Aufgaben für proaktive Überwachung und HTTP-Trigger für die reaktive Ereignisbehandlung.

Anwendungsfälle

CI/CD-Pipeline-Integration

Wenn eine Bereitstellungspipeline fehlschlägt, rufen Sie den Agent auf, um den Fehler zu analysieren:

# In your pipeline's failure handler
curl -X POST "$AGENT_TRIGGER_URL" \
  -H "Authorization: Bearer $ARM_TOKEN" \
  -H "Content-Type: application/json" \
  -d "{\"pipeline\": \"$PIPELINE_NAME\", \"run_id\": \"$RUN_ID\", \"error\": \"$ERROR_MESSAGE\"}"

Warnungsgesteuerte Untersuchung

Verbinden Sie Ihr Benachrichtigungssystem, damit eine automatisierte Untersuchung ausgelöst wird, wenn kritische Alarme eintreten.

{
  "alert_name": "Error rate > 5%",
  "severity": "P1",
  "service": "checkout-api",
  "region": "eastus2",
  "start_time": "2026-03-13T10:15:00Z"
}

Überprüfungen der Compliance bei der Bereitstellung

Lösen Sie nach dem Bereitstellen einer Bereitstellung eine Compliance-Prüfung aus:

curl -X POST "$AGENT_TRIGGER_URL" \
  -H "Authorization: Bearer $ARM_TOKEN" \
  -d '{"deployment_id": "deploy-456", "environment": "production", "changes": ["config update", "image bump"]}'

API-Referenz

Endpunkt Methode Beschreibung
/api/v1/httptriggers GET Listet alle Auslöser auf.
/api/v1/httptriggers/create POST Erstellen Sie einen neuen Auslöser.
/api/v1/httptriggers/{id} GET Triggerdetails abrufen.
/api/v1/httptriggers/{id} PUT Aktualisieren von Triggereigenschaften.
/api/v1/httptriggers/{id} DELETE Trigger löschen.
/api/v1/httptriggers/{id}/enable POST Aktivieren Sie einen Trigger.
/api/v1/httptriggers/{id}/disable POST Deaktivieren Sie einen Trigger.
/api/v1/httptriggers/{id}/execute POST Führen Sie einen Trigger manuell aus.
/api/v1/httptriggers/{id}/executions GET Abrufen des Ausführungsverlaufs.
/api/v1/httptriggers/trigger/{id} POST Externer Webhook-Endpunkt.

Problembehandlung

Trigger gibt 404 zurück.

  • Stellen Sie sicher, dass der Trigger aktiviert ist. Deaktivierte Trigger geben 404 zurück.
  • Überprüfen Sie, ob die Trigger-ID in der URL korrekt ist.

401 Nicht autorisiert

  • Die Zielgruppe des Tokens muss mit der SRE-Agent-App-ID übereinstimmen, nicht https://management.azure.com.
  • Verwenden Sie az account get-access-token --resource 59f0a04a-b322-4310-adc9-39ac41e9631e --query accessToken -o tsvzum Abrufen eines Tokens zum Testen .

Trigger wird ausgeführt, der Agent reagiert jedoch nicht

  • Prüfen Sie den Prompt des Agents. Eine leere Eingabeaufforderung erzeugt möglicherweise keine nützliche Ausgabe.
  • Stellen Sie sicher, dass der ausgewählte Subagent über die tools verfügt, die für den Vorgang erforderlich sind.
  • Überprüfen Sie den Ausführungsverlauf auf Fehlerdetails.

Einschränkungen

Ressource Begrenzung
Trigger pro Agent Kein hartes Limit.
Maximale Umdrehungen pro Ausführung 250 Drehungen.
Authentication Der Bearer-Token ist für jede Trigger-URL erforderlich.

Verwandte Inhalte

  • Last updated on