Erfahren Sie von Ausfällen durch Ihre Nutzer? Monitoring einer .NET-Anwendung mit Application Insights

Montag, 9:15 Uhr. Ein Kunde ruft an: “Es funktioniert nicht.” Das Team loggt sich auf dem Server ein und wühlt sich durch Logs, und eine Stunde später merkt jemand, dass die Datenbankverbindung um drei Uhr nachts abgerissen ist. Die Anwendung war sechs Stunden lang halb tot, und Sie haben es von einem Kunden erfahren.

Die Frage ist nicht, ob das passiert. Die Frage ist, ob Sie es als Erster erfahren.

Was Sie sehen, wenn Monitoring eingerichtet ist

Application Insights ist das Monitoring-Werkzeug von Microsoft für Anwendungen auf Azure. Ist es eingeschaltet, sieht der Unterschied so aus:

Frage	Ohne Monitoring	Mit Application Insights
Läuft die Anwendung gerade?	Jemand öffnet sie und schaut	Ein Verfügbarkeitstest alle paar Minuten und ein Alarm, wenn er fehlschlägt
Warum ist sie langsam?	Raten	Der genaue Bildschirm, die Datenbankabfrage und ihre Dauer
Was ist um drei Uhr nachts kaputtgegangen?	Suche in den Logs auf dem Server	Der Fehler mit vollständigem Verlauf, an einer Stelle
Wie viele Nutzer waren betroffen?	Niemand weiß es	Die Zahl der fehlgeschlagenen Anfragen und betroffenen Nutzer
Ist ein externer Dienst schuld?	Gegenseitige Schuldzuweisung	Jeder Aufruf an Datenbank und externe APIs, mit Dauer und Ergebnis

Für die Geschäftsführung heißt das zweierlei: Sie erfahren von einem Problem vor dem Kunden, und wenn man später bespricht, was passiert ist, liegen Zahlen auf dem Tisch statt Eindrücken.

Die Einrichtung: ein paar Zeilen Code

Für eine ASP.NET-Core-Anwendung genügt das Microsoft-Paket Azure.Monitor.OpenTelemetry.AspNetCore und eine Zeile in Program.cs:

builder.Services.AddOpenTelemetry().UseAzureMonitor();   // Anfragen, Fehler, Datenbank- und externe Aufrufe

var app = builder.Build();

app.MapHealthChecks("/health");                          // die Adresse, die der Verfügbarkeitstest prüft

Die Verbindung zu Application Insights läuft über die Einstellung APPLICATIONINSIGHTS_CONNECTION_STRING in App Service, nicht über den Code. Ab dann werden alle Anfragen, Fehler und Aufrufe an Datenbank und externe Dienste automatisch erfasst.

Das ist der einfache Teil. Der schwierige Teil ist die Entscheidung, was Sie um drei Uhr nachts wecken soll und was bis zum Morgen warten kann.

Fünf Alarme, die jede Anwendung braucht

1. Der Verfügbarkeitstest ist fehlgeschlagen. Azure öffnet Ihre Anwendung alle paar Minuten von mehreren Standorten weltweit. Antwortet sie nicht, gibt es einen Alarm.
2. Plötzlich mehr fehlgeschlagene Anfragen. Wenn Fehler über ihr übliches Niveau springen, hat sich etwas geändert, meist eine neue Version oder ein externer Dienst.
3. Antworten werden langsam. Die Antwortzeit liegt länger als ein paar Minuten über einer vereinbarten Schwelle.
4. Aufrufe an Datenbank oder externe Dienste schlagen fehl. Die häufigste Ursache für “die App geht nicht”, die nicht im eigenen Code liegt.
5. Der Server ist am Limit. CPU oder Speicher lange über, sagen wir, 80 %. Eine Warnung, bevor daraus ein Ausfall wird.

Ein Alarm muss bei einem Menschen ankommen, der reagiert: per E-Mail, SMS oder in Teams. Ein Alarm in einem Postfach, das niemand liest, ist so gut wie keiner.

Wenn Sie die alten Verfügbarkeitstests nutzen: Stichtag 30. September 2026

Microsoft stellt die alten URL-Ping-Tests in Application Insights am 30. September 2026 ein. Wenn Sie sie noch nutzen, stellen Sie auf Standardtests um. Sonst hört Ihr Verfügbarkeits-Monitoring still und leise auf zu funktionieren, und genau für solche Fehler hätten Sie gern einen Alarm.

Damit das Monitoring nicht die Rechnung auffrisst

Application Insights wird nach der Menge der erfassten Daten abgerechnet. Deshalb zahlen manche Unternehmen für das Monitoring mehr als für die Anwendung selbst. Drei Dinge halten das unter Kontrolle:

• Sampling. Nicht jede erfolgreiche Anfrage muss erfasst werden. Ein repräsentativer Anteil reicht, und Fehler werden alle behalten.
• Log-Level. In der Produktion braucht man nicht alles, was während der Entwicklung ausgegeben wird. Detaillierte Logs werden für eine Untersuchung eingeschaltet und danach wieder aus.
• Eine Tagesobergrenze. Ein Limit als Sicherheitsnetz, falls ein Fehler plötzlich Tausende Einträge pro Minute schreibt.

So führen wir es ein

1. EinschaltenPaket, Einstellung, Verfügbarkeitstest
2. AlarmeFünf Alarme, an die richtigen Leute
3. ÜbersichtEin Bildschirm für den Zustand der App
4. RoutineEin wöchentlicher Blick auf die Trends

Wenn das Monitoring läuft, ist der nächste Schritt, es zu nutzen: Welche Bildschirme sind am langsamsten, welche Fehler kommen immer wieder? Es ist dieselbe Messung, über die wir im Artikel über langsame Anwendungen geschrieben haben, nur dass die Daten jetzt von selbst kommen.

Wie wir arbeiten

ProCoding ist ein .NET-Studio aus Split, Kroatien, und Azure für .NET-Anwendungen ist eine unserer Spezialisierungen. Monitoring, Alarme und eine Kostenanalyse richten wir im Rahmen eines Azure Health Checks ein oder gemeinsam mit Ihrem Team. Der erste Schritt ist ein kostenloses 30-minütiges Gespräch.

Quellen

• Verfügbarkeitstests in Application Insights, Microsoft Learn
• Azure Monitor OpenTelemetry für .NET-Anwendungen aktivieren, Microsoft Learn