Agentic Ops mit Grafana und GitHub: Vom Alert zur Erstanalyse

Mail, Teams, oder Slack sind gute Benachrichtigungskanäle, aber schlechte Arbeitsobjekte für Incidents. Ein Alert verschwindet schnell in Threads, Weiterleitungen oder persönlichen Postfächern, obwohl genau dann Verbindlichkeit gebraucht wird.

Für operative Störungen brauchst du ein Arbeitselement mit Owner, Status und Historie. GitHub Issues passen dafür gut, wenn Code, Runbooks und Incident-Kommunikation ohnehin im Repository-Kontext liegen. Wenn euer Betrieb heute in Azure DevOps, Jira oder einem dedizierten Incident-Tool lebt, ist derselbe Ansatz dort oft sinnvoller als ein zusätzlicher Systemwechsel.

Der operative Gewinn entsteht nicht schon beim Alert, sondern erst dann, wenn nachvollziehbar ist, was passiert ist, wer gerade dran ist und ob derselbe Vorfall schon kurz zuvor ausgelöst wurde. Gleichzeitig hilft ein zentrales Arbeitselement beim Datenschutz, weil sensible Kontextinfos nicht unkontrolliert durch Weiterleitungen, Screenshots oder parallele Chat-Verläufe wandern.

Genau dort setzt der Workflow an. Grafana erkennt, GitHub trackt und ein Agent hilft bei der ersten Einordnung, statt dass Menschen bei jedem Alert wieder bei null anfangen.

Grafana-Alerts kontrolliert nach GitHub bringen

Der technische Startpunkt ist ein Webhook Contact Point in Grafana. Damit kann Grafana ein repository_dispatch-Event in GitHub auslösen und so einen Workflow starten.

Der direkte Aufruf der GitHub-API ist möglich, aber nicht immer die robusteste Variante. In vielen Teams ist ein kleiner Relay-Dienst, zum Beispiel per Azure Function oder Logic App, die sauberere Lösung. Dort lassen sich Authentifizierung, Schema-Validierung, Redaction und Retry-Verhalten kontrollierter umsetzen, bevor überhaupt ein Workflow in GitHub startet.

Wichtig ist in jedem Fall, die Payload klein und kontrollierbar zu halten. Ein Incident-Workflow braucht nicht den kompletten Alert-Kontext, keine ungekürzten Log-Ausschnitte und schon gar keine frei angehängten Dumps. Übermittle nur die Felder, die für Routing und Zuordnung notwendig sind, also Fingerprint, Status, Severity, Environment und Links zurück auf Dashboard oder Alert-Details.

on:
  repository_dispatch:
    types:
      - grafana_alert

permissions:
  contents: read # Read repo contents for context
  issues: write # Create and update issues
  actions: write # Call folow up actions

Gerade beim Datenschutz solltest du hier konsequent sein. Logs, Trace-Daten, Request-Bodies oder personenbezogene Informationen dürfen nicht unredigiert an den Agenten oder in das GitHub-Issue weitergereicht werden. Wenn du dazu eine robuste Grundlage suchst, schau in unseren Artikel zu Logging Redaction.

Ein minimales Payload-Beispiel reicht oft schon aus:

{
  "event_type": "grafana_alert",
  "client_payload": {
    "alerts": [
      {
        "fingerprint": "cpu-prod-api-01",
        "status": "firing",
        "title": "CPU hoch auf api-prod",
        "severity": "high",
        "environment": "prod",
        "dashboardUrl": "https://grafana.example.com/d/ops/api",
        "alertUrl": "https://grafana.example.com/alerting/123"
      }
    ]
  }
}

Das Beispiel zeigt bewusst nur das Minimum für Routing und Zuordnung. In der Praxis brauchst du zusätzlich klare Timeouts, Retry-Regeln und einen idempotenten Empfänger, damit ein kurzzeitiger Fehler nicht sofort zu doppelten Issues führt.

Auf GitHub solltest du mit minimalen Rechten arbeiten, idealerweise über einen eng begrenzten technischen Account oder einen GitHub-App-basierten Flow statt eines breit einsetzbaren Tokens. Der Workflow darf keine Payload-Felder ungeprüft in Shell-Befehle, Suchanfragen oder nachgelagerte Agent-Runs übernehmen. So bleibt der Webhook ein sauberer Eintrittspunkt und kein Seiteneingang in deine Betriebsumgebung.

Aus Alerts belastbare Issues statt Ticket-Dubletten machen

Der erste GitHub-Workflow sollte noch keine tiefe Analyse machen. Seine Aufgabe ist es, aus dem Alert einen stabilen Incident-Lifecycle zu bauen.

Im Kern heißt das, offene Incidents zum gleichen Alert zu suchen und nur dann ein neues Issue anzulegen, wenn wirklich noch keines existiert. Der primäre Schlüssel sollte die Alert-UID oder der Fingerprint sein. Fuzzy-Suchen über Titel oder Severity helfen nur als Fallback, weil sie sonst schnell doppelte oder falsch zusammengeführte Incidents erzeugen.

const existingIssues = await github.paginate(github.rest.issues.listForRepo, {
  owner: context.repo.owner,
  repo: context.repo.repo,
  state: 'open',
  labels: `env: ${environment}`,
  per_page: 100,
});
core.info(
  `Found ${existingIssues.length} open issue(s) with label "env: ${environment}".`,
);

const matchingIssues = existingIssues.filter(
  (issue) => !issue.pull_request && issue.title === alertName,
);

Für wiederkehrende Alerts ist ein Kommentar im bestehenden Issue oft wertvoller als ein neues Ticket. Bei einem resolved-Status solltest du dasselbe Issue wiederfinden, den Status ergänzen und es nur dann automatisch schließen, wenn eure Alert-Regeln zuverlässig sind und Flapping bereits abgefangen wird. In vielen Teams ist es sicherer, zunächst nur recovered zu markieren und das endgültige Schließen bewusst durch einen Menschen oder nach einem definierten Cooldown zu machen.

Auch hier gilt es, so wenig Daten wie möglich zu speichern. Im Issue landen besser normalisierte Zusammenfassungen und Links statt roher Logs, Request-Bodies oder anderer unredigierter Nutzdaten.

Eine einfache Feldzuordnung macht den Workflow konsistent:

Diese Struktur hilft auch später dem Agenten. Er startet nicht mit losem Alarmtext, sondern mit einem sauberen Arbeitselement, das Symptome, Verlauf und Aktualisierungen bereits gesammelt enthält.

Agentische Erstanalyse nur mit klaren Guardrails

Nach dem Issue ist die Arbeit noch nicht getan. Jetzt muss jemand Symptome bewerten, Hypothesen bilden und die richtigen nächsten Prüfschritte auswählen.

Dafür kann ein zweiter Workflow starten, zum Beispiel über workflow_dispatch oder über ein Label wie needs-agent-triage. Der Agent nutzt dann einen Azure MCP Server, also einen Model Context Protocol-Server für kontrollierte Tool-Zugriffe auf Azure-Ressourcen, Metriken und Log-Daten. Der gleiche Ansatz funktioniert aber auch mit anderem internen Tooling. Entscheidend ist nicht das Label MCP, sondern dass die Zugriffe begrenzt, nachvollziehbar und reviewbar sind.

mcp-servers:
  microsoftdocs:
    url: 'https://learn.microsoft.com/api/mcp'
    allowed: ['*']
  azure:
    command: 'npx'
    args: ['-y', '@azure/mcp@latest', 'server', 'start']
    allowed: ['*']
secrets:
  AZURE_CLIENT_ID: ${{ secrets.COPILOT_MCP_AZURE_CLIENT_ID }}
  AZURE_TENANT_ID: ${{ secrets.COPILOT_MCP_AZURE_TENANT_ID }}
steps:
  - name: Azure login
    uses: azure/login@532459ea530d8321f2fb9bb10d1e0bcf23869a43 # v3
    with:
      client-id: ${{ secrets.AZURE_CLIENT_ID }}
      tenant-id: ${{ secrets.AZURE_TENANT_ID }}
      allow-no-subscriptions: true

Die Sicherheitslinie sollte dabei klar sein. Für reine Analyse ist die Azure-Rolle Reader eine sinnvolle Basis. Zusätzlicher Zugriff auf Azure Monitor Logs sollte gezielt und getrennt vergeben werden, nicht als pauschal breites Recht auf die gesamte Subscription.

Rechte allein reichen aber nicht. Der Agent sollte nur auf allowlist-basierte Tools, vorbereitete Query-Templates und begrenzte Zeitfenster zugreifen dürfen. Freie Ad-hoc-Abfragen mit unklarem Datenscope klingen flexibel, erhöhen aber das Risiko, dass unnötig viele oder zu sensible Daten in der Analyse landen.

Datenschutz ist hier kein Randthema, sondern ein harter Guardrail. Der Agent sollte nie rohe Logs, komplette Tabellenabzüge oder unredigierte Fehlermeldungen mit möglichen Personenbezügen bekommen. Besser sind vorbereitete Queries, begrenzte Zeitfenster und bereits bereinigte Auszüge. Wenn du mit Log Analytics arbeitest, findest du dazu ergänzend unseren Artikel zu Azure Log Analytics.

Der Output des Agenten sollte ebenfalls knapp und überprüfbar bleiben. Sinnvoll sind Symptome, wahrscheinliche Ursachen, nächste Prüfschritte und eine Confidence-Einschätzung. Alles andere erzeugt nur Scheinsicherheit.

Welche Kontextquellen wirklich helfen

Der eigentliche Mehrwert entsteht, wenn der Agent nicht nur Telemetrie liest, sondern mehrere kuratierte Kontextquellen kombiniert. Dazu gehören Repository-Code, Betriebsdokumentation, frühere Incident-Issues und vorhandene Runbooks.

Gerade frühere Incidents sind oft Gold wert. Vielleicht gab es denselben Fehler schon nach einem Deployment, vielleicht existiert bereits ein Workaround, oder die Ursache lag letztes Mal gar nicht in Azure, sondern in einer Konfigurationsänderung im Repository.

Gib dem Agenten nicht pauschal alles, was irgendwo vorhanden ist. Stelle gezielt die Dokumente, Suchergebnisse und redigierten Ausschnitte bereit, die für die Fragestellung relevant sind. Das betrifft auch ältere Issues, Runbooks und Post Mortems, weil historische Tickets oft mehr sensible Details enthalten als für die aktuelle Erstanalyse wirklich nötig sind.

Wichtig ist, dass der Agent Hypothesen klar als Hypothesen kennzeichnet. Er soll den Einstieg beschleunigen, nicht menschliche Bewertung ersetzen.

Wenn der Agent schon einen Fix vorschlagen kann

Manche Incidents enden nicht bei einer Diagnose. Wenn die Hinweise klar genug sind, kann der Agent auch einen konkreten Fix-Vorschlag formulieren, etwa für einen falschen Alert-Schwellenwert, eine Retry-Konfiguration oder eine kleine IaC-Anpassung.

Die Leitplanke bleibt trotzdem eindeutig. Der Agent schlägt Änderungen vor, er setzt sie nicht direkt in Produktion um. Sauber ist ein Vorschlag im Issue oder ein Pull Request zur Review, damit Entscheidung und Umsetzung nachvollziehbar bleiben.

Ein möglicher Output kann so aussehen:

## Agentische Erstanalyse

- Symptome: CPU-Spitzen seit Deployment 2026.05.26.3, erhöhte 5xx-Rate
- Wahrscheinliche Ursache: Retry-Konfiguration für externen Dienst fehlt im neuen Codepfad
- Nächste Prüfschritte: Fehlerquote nach Rollback vergleichen, Dependency-Latency prüfen
- Möglicher Fix: Retry-Limit in `appsettings.Production.json` ergänzen
- Confidence: mittel

Auch hier solltest du aufpassen, welche Daten in den Vorschlag einfließen. Keine Secrets, keine unredigierten Log-Zeilen und keine personenbezogenen Inhalte gehören in PR-Beschreibungen oder Agent-Outputs. Der Mensch reviewt nicht nur den Fix, sondern auch den Kontext, auf dem er basiert.

Wichtig ist außerdem die Systemgrenze. Wenn produktive Konfiguration nicht im Repository liegt, sollte der Agent keinen Repo-Fix vortäuschen, sondern klar benennen, ob die Änderung in IaC, App Configuration, Key Vault oder im Alerting selbst stattfinden müsste.

## Analysis approach

1. Parse the issue to identify the affected environment, service, resource, alert identifier, and reported symptoms.
2. Cross-reference repository data to connect alerts with services, resource identifiers, and health check URLs. Focus on
   application code, initialization files, service documentation, and infrastructure-as-code to pinpoint the specific
   Azure resource or endpoint involved.
3. Leverage Azure diagnostics tooling to search for recent degradation, failures, dependency issues, resource contention,
   or infrastructure incidents.
4. Query health check endpoints to assess current service status—whether operational, impaired, or unavailable.
5. Combine findings to evaluate whether remediation is primarily operational in nature, requires code changes, or remains
   uncertain.

## Diagnosis workflow

Unless the issue already provides sufficient context, work through this sequence:

1. Define the alert timeframe using the issue timestamp, recent activity, Grafana URLs, and any numeric indicators provided.
2. Pinpoint the probable Azure resource and execution environment by analyzing issue metadata, labels, description, alert
   parameters, and documentation or code references.
3. Start with `resourcehealth` checks to confirm or rule out underlying platform issues impacting the resource.
4. For App Service resources, use `applens` and `appservice` tools to examine instance recycling, rollout errors, probe
   failures, autoscaling conditions, misconfigurations, and upstream service problems.
5. Use `monitor` to corroborate symptoms in your telemetry dataset. Focus particularly on:
   - request failures
   - error conditions
   - latency or availability issues with external services
   - error/warning logs during the alert period
   - anomalies in load, response times, or restarts
6. Examine recent health endpoint state against historical metrics from your alert period. Differentiate between:
   - presently non-functional
   - recently recovered but showed failures
   - infrastructure operating normally with external dependency failures
7. Highlight the most compelling evidence and classify your assessment as `confirmed`, `likely`, or `guess`.

## Response structure

Provide a single focused response containing these parts:

### Symptoms

- Summary of observed conditions and key supporting evidence.

### Likely cause

- Describe the most probable underlying issue.
- Include one classification:
  - `Confidence: confirmed`
  - `Confidence: likely`
  - `Confidence: guess`

### Recommended actions

- Sequential list of steps for ops staff or developers to take immediately.

### Suggested fix

- If an operational solution exists, describe it.
- If a code change appears necessary, explain the indication and reasoning.
- If the resolution remains unclear, acknowledge this explicitly.

Post-Mortem-Entwürfe direkt aus dem Incident ableiten

Nach der Umsetzung endet der Nutzen des Workflows nicht. Gerade wenn ein Incident bereits als GitHub-Issue mit Timeline, Kommentaren, Labels und Entscheidungen dokumentiert ist, kann ein Agent daraus direkt einen Post-Mortem-Entwurf erzeugen.

Das funktioniert besonders gut, weil die relevanten Bausteine schon vorhanden sind. Der Agent kann Informationen aus dem Incident-Issue bündeln, also Timeline, vermutete oder bestätigte Root Cause, beobachtete Symptome, getroffene Lösung und offene Follow-ups, und daraus einen strukturierten Entwurf für deine Review erstellen.

Wichtig ist wieder die Datenschutzperspektive. Auch ein Post Mortem darf keine unredigierten Logs, keine personenbezogenen Daten und keine unnötigen internen Details enthalten, die für den Lerneffekt nicht gebraucht werden. Der Agent sollte daher nur bereinigte Inhalte übernehmen und sensible Stellen explizit zur menschlichen Prüfung markieren.

Ein Entwurf bleibt aber nur ein Entwurf. Wenn Timeline, Entscheidungen oder Impact im Incident-Issue lückenhaft dokumentiert wurden, macht der Agent diese Lücken höchstens sichtbarer. Genau deshalb verbessert der Workflow nicht nur die Analyse, sondern auch die spätere Dokumentationsqualität.

## Purpose

Postmortems serve to chronicle the sequence of events, identify root causes, detail how resolution was achieved, and outline what lessons should inform future practices.

## Writing Best Practices

- Stick to verified facts and evidence; avoid attributing blame.
- Align with your organization's postmortem template and established incident workflows.
- Pull context from support tickets, system logs, timestamps, deployment histories, and related code changes.
- Clearly separate root causes from contributing factors and immediate remediation steps.
- Report only confirmed information; explicitly flag areas where additional investigation is needed.

## Core Components

A comprehensive postmortem should include:

- Executive summary with business impact,
- detailed chronology of events,
- root cause analysis,
- resolution actions taken,
- follow-up tasks with clear ownership.

## Timeline Reconstruction and Follow-up Tracking

- Rebuild the timeline using evidence from git commits, issue reports, subtasks, and other system records.
- Organize follow-ups by category: monitoring improvements, process changes, code fixes, and knowledge documentation.
- Don't speculate about missing details; instead, explicitly note what remains unclear.

## Completion Criteria

The postmortem is considered complete when it can be reviewed in the next retrospective and the improvement actions are trackable.

Weniger Alarm-Pingpong, mehr Incident-Fortschritt

Agentic Ops ist kein Ersatz für Verantwortung. Der Gewinn liegt darin, dass zwischen Alert, Tracking und erster Analyse weniger Reibung entsteht und dass Wissen aus früheren Vorfällen nicht jedes Mal neu zusammengesucht werden muss.

Grafana erkennt das Signal, GitHub hält den Lifecycle fest und der Agent liefert eine erste, nachvollziehbare Einordnung. Menschen entscheiden weiterhin, welche Hypothese trägt, welcher Fix umgesetzt wird und welche Informationen aus Datenschutzsicht überhaupt weitergegeben werden dürfen.

Wenn du den Ansatz einführst, beginne klein. Minimiere die Webhook-Payload, etabliere eine saubere Deduplizierung und gib dem Agenten nur kuratierten, redigierten Kontext. Ein bewusstes manuelles Gate vor Analyse oder Umsetzung ist am Anfang oft klüger als Vollautomatisierung.

Wie würdest du Alerts in deinem Betrieb lieber weiterverarbeiten, direkt in ein Incident-Issue mit agentischer Erstanalyse oder mit einem bewussten manuellen Gate dazwischen? Schau gerne bei uns auf LinkedIn vorbei und diskutiere mit.