Freigeben über

Konfigurieren der Überwachung für Azure Functions

  • Artikel

Die Integration von Azure Functions mit Application Insights ermöglicht Ihnen eine bessere Überwachung Ihrer Funktions-Apps. Application Insights, ein Feature von Azure Monitor, ist ein erweiterbarer Dienst für die Steuerung der Anwendungsleistung (Application Performance Management, APM), mit dem von Ihrer Funktions-App generierte Daten gesammelt werden (z. B. auch Informationen, die von Ihrer App in Protokolle geschrieben werden). Die Application Insights-Integration wird in der Regel beim Erstellen Ihrer Funktions-App aktiviert. Wenn für Ihre App kein Instrumentierungsschlüssel festgelegt ist, müssen Sie die Application Insights-Integration zunächst aktivieren.

Sie können Application Insights ganz ohne benutzerdefinierte Konfiguration verwenden. Die Standardkonfiguration kann jedoch zu großen Datenmengen führen. Wenn Sie ein Visual Studio Azure-Abonnement verwenden, erreichen Sie unter Umständen Ihr Datenlimit für Application Insights. Weitere Informationen zu Application Insights-Kosten finden Sie unter Abrechnung für Application Insights. Weitere Informationen finden Sie unter Lösungen mit großen Mengen an Telemetriedaten.

In diesem Artikel erfahren Sie, wie Sie die Daten konfigurieren und anpassen, die Ihre Funktionen an Application Insights senden. Sie können allgemeine Protokollierungskonfigurationen in der Datei host.json festlegen. Standardmäßig regeln diese Einstellungen auch benutzerdefinierte Protokolle, die von Ihrem Code ausgegeben werden. In einigen Fällen kann dieses Verhalten jedoch zugunsten von Optionen deaktiviert werden, die Ihnen mehr Kontrolle über die Protokollierung bieten. Weitere Informationen finden Sie unter Benutzerdefinierte Anwendungsprotokolle.

Hinweis

Sie können speziell konfigurierte Anwendungseinstellungen verwenden, um bestimmte Einstellungen in der Datei host.json für eine bestimmte Umgebung darzustellen. Hierdurch können Sie Einstellungen der Datei host.json auf effektive Weise ändern, ohne dass Sie die Datei host.json erneut in Ihrem Projekt veröffentlichen müssen. Weitere Informationen finden Sie unter Außerkraftsetzung der Werte in der Datei „host.json“.

Benutzerdefinierte Anwendungsprotokolle

Standardmäßig werden von Ihnen geschriebene benutzerdefinierte Anwendungsprotokolle an den Functions-Host gesendet, der sie dann unter der Kategorie „Worker“ an Application Insights sendet. Bei einigen Sprachenstapeln können Sie die Protokolle stattdessen direkt an Application Insights senden, sodass Sie die vollständige Kontrolle darüber erhalten, wie von Ihnen geschriebene Protokolle ausgegeben werden. In diesem Fall wird die Protokollierungspipeline von worker -> Functions host -> Application Insights in worker -> Application Insights geändert.

In der folgenden Tabelle sind die für die einzelnen Stapel verfügbaren Konfigurationsoptionen zusammengefasst:

Sprachstapel Ort zum Konfigurieren benutzerdefinierter Protokolle
.NET (In-Process-Modell) host.json
.NET (isoliertes Modell) Standard (Senden benutzerdefinierter Protokolle an den Functions-Host): host.json
Informationen zum direkten Senden von Protokollen an Application Insights: Konfigurieren von Application Insights in HostBuilder
Node.JS host.json
Python host.json
Java Standard (Senden benutzerdefinierter Protokolle an den Functions-Host): host.json
Informationen zum direkten Senden von Protokollen an Application Insights: Konfigurieren des Application Insights-Java-Agents
PowerShell host.json

Wenn Sie benutzerdefinierte Anwendungsprotokolle so konfigurieren, dass sie direkt gesendet werden, werden sie vom Host nicht mehr ausgegeben, und ihr Verhalten wird nicht mehr von host.json gesteuert. In ähnlicher Weise gelten die von jedem Stapel verfügbar gemachten Optionen nur für benutzerdefinierte Protokolle, und sie ändern nicht das Verhalten der anderen Laufzeitprotokolle, die in diesem Artikel beschrieben werden. Um das Verhalten aller Protokolle zu steuern, müssen Sie in diesem Fall möglicherweise Änderungen an beiden Konfigurationen vornehmen.

Konfigurieren von Kategorien

Die Azure Functions-Protokollierung enthält eine Kategorie für jedes Protokoll. Mit der Kategorie wird angegeben, von welchem Teil des Laufzeitcodes bzw. Ihres Funktionscodes das Protokoll geschrieben wurde. Kategorien unterscheiden sich für Version 1.x und höhere Versionen.

Kategorienamen werden in Funktionen im Vergleich zu anderen .NET Frameworks unterschiedlich zugewiesen. Wenn Sie beispielsweise ILogger<T> in ASP.NET verwenden, ist die Kategorie der Name des generischen Typs. C#-Funktionen verwenden auch ILogger<T>, aber anstatt den generischen Typnamen als Kategorie festzulegen, weist die Laufzeit Kategorien basierend auf der Quelle zu. Beispiel:

  • Einträge im Zusammenhang mit der Ausführung einer Funktion werden einer Kategorie von Function.<FUNCTION_NAME> zugewiesen.
  • Einträge, die von Benutzercode innerhalb der Funktion erstellt werden, z. B. beim Aufrufen von logger.LogInformation(), werden einer Kategorie von Function.<FUNCTION_NAME>.User zugewiesen.

In der folgenden Tabelle werden die Hauptkategorien der Protokolle beschrieben, die von der Laufzeit erstellt werden:

Kategorie Tabelle BESCHREIBUNG
Function traces Enthält die gestartete Funktion und abgeschlossene Protokolle für alle Funktionsausführungen. Bei erfolgreichen Ausführungen befinden sich diese Protokolle auf der Stufe Information. Ausnahmen werden auf der Stufe Error protokolliert. Von der Runtime werden auch Protokolle mit der Stufe Warning erstellt, z. B. wenn Warteschlangennachrichten an die Warteschlange für nicht verarbeitete Nachrichten gesendet werden.
Function.<YOUR_FUNCTION_NAME> dependencies Abhängigkeitsdaten werden für einige Dienste automatisch gesammelt. Bei erfolgreichen Ausführungen befinden sich diese Protokolle auf der Stufe Information. Weitere Informationen finden Sie unter Abhängigkeiten. Ausnahmen werden auf der Stufe Error protokolliert. Von der Runtime werden auch Protokolle mit der Stufe Warning erstellt, z. B. wenn Warteschlangennachrichten an die Warteschlange für nicht verarbeitete Nachrichten gesendet werden.
Function.<YOUR_FUNCTION_NAME> customMetrics
customEvents		 Mit SDKs für C# und JavaScript können Sie benutzerdefinierte Metriken erfassen und benutzerdefinierte Ereignisse protokollieren. Weitere Informationen finden Sie unter Benutzerdefinierte Telemetriedaten.
Function.<YOUR_FUNCTION_NAME> traces Enthält die gestartete Funktion und abgeschlossene Protokolle für bestimmte Funktionsausführungen. Bei erfolgreichen Ausführungen befinden sich diese Protokolle auf der Stufe Information. Ausnahmen werden auf der Stufe Error protokolliert. Von der Runtime werden auch Protokolle mit der Stufe Warning erstellt, z. B. wenn Warteschlangennachrichten an die Warteschlange für nicht verarbeitete Nachrichten gesendet werden.
Function.<YOUR_FUNCTION_NAME>.User traces Vom Benutzer generierte Protokolle mit einer beliebigen Protokollstufe. Weitere Informationen zum Schreiben von Daten in Protokolle aus Ihren Funktionen finden Sie unter Schreiben in Protokolle.
Host.Aggregator customMetrics Diese von der Runtime generierten Protokolle enthalten die Anzahl und Durchschnittswerte von Funktionsaufrufen für einen konfigurierbaren Zeitraum. Der Standardzeitraum beträgt 30 Sekunden oder 1.000 Ergebnisse, je nachdem, was früher eintritt. Beispiele hierfür sind die Ausführungsanzahl, die Erfolgsrate und die Dauer. Alle diese Protokolle werden auf der Stufe Information geschrieben. Wenn Sie nach Warning oder höheren Stufen filtern, finden Sie keine dieser Daten.
Host.Results requests Diese von der Runtime generierten Protokolle enthalten einen Hinweis zum Erfolg bzw. Misserfolg einer Funktion. Alle diese Protokolle werden auf der Stufe Information geschrieben. Wenn Sie nach Warning oder höheren Stufen filtern, finden Sie keine dieser Daten.
Microsoft traces Vollständig qualifizierte Protokollkategorie, die eine vom Host aufgerufene .NET-Runtimekomponente widerspiegelt.
Worker traces Protokolle, die vom Sprachworkerprozess für nicht zu .NET gehörende Sprachen generiert werden. Sprachworkerprotokolle können auch in einer Kategorie wie Microsoft.* protokolliert werden, z. B. Microsoft.Azure.WebJobs.Script.Workers.Rpc.RpcFunctionInvocationDispatcher. Diese Protokolle werden auf der Stufe Information geschrieben.

Hinweis

Für .NET-Klassenbibliotheksfunktionen wird bei diesen Kategorien davon ausgegangen, dass Sie ILogger verwenden und nicht ILogger<T>. Weitere Informationen finden Sie in der Dokumentation zu ILogger in Azure Functions.

In der Spalte Tabelle ist angegeben, in welche Tabelle in Application Insights das Protokoll geschrieben wird.

Konfigurieren von Protokollstufen

Jedem Protokoll wird eine Protokollebene zugewiesen. Der Wert ist eine ganze Zahl, die die relative Wichtigkeit angibt:

LogLevel Code BESCHREIBUNG
Trace 0 Protokolle, die die ausführlichsten Meldungen enthalten. Diese Meldungen enthalten möglicherweise vertrauliche Anwendungsdaten. Sie sind standardmäßig deaktiviert und sollten nie in einer Produktionsumgebung aktiviert werden.
Debuggen 1 Protokolle, die für interaktive Untersuchungen während der Entwicklung verwendet werden. Diese Protokolle sollten hauptsächlich für das Debuggen hilfreiche Informationen enthalten. Sie besitzen keinen langfristigen Nutzen.
Information 2 Protokolle, die den allgemeinen Ablauf der Anwendung nachverfolgen. Diese Protokolle sollten einen langfristigen Nutzen besitzen.
Warnung 3 Dies sind Protokolle, die ein ungewöhnliches oder unerwartetes Ereignis im Anwendungsfluss hervorheben, jedoch nicht bewirken, dass die Anwendung beendet wird.
Fehler 4 Dies sind Protokolle, die hervorheben, wenn der aktuelle Ausführungsfluss aufgrund eines Fehlers beendet wird. Diese Fehler sollten auf einen Fehler im Zusammenhang mit der aktuellen Aktivität und nicht auf einen anwendungsweiten Fehler hinweisen.
Kritisch 5 Protokolle, die einen nicht behebbaren Anwendungs- oder Systemabsturz beschreiben oder einen schwerwiegenden Fehler, der unmittelbare Aufmerksamkeit erfordert.
Keine 6 Hiermit wird die Protokollierung für die angegebene Kategorie deaktiviert.

Durch die Konfiguration der host.json-Datei wird bestimmt, welcher Protokollierungsgrad von einer Funktions-App an Application Insights gesendet wird.

Für jede Kategorie geben Sie zu sendende Mindestprotokollebene an. Die Einstellungen für host.json variieren je nach Version der Functions-Runtime.

In den folgenden Beispielen wird die Protokollierung anhand der folgenden Regeln definiert:

  • Die Standardprotokollierungsebene ist so festgelegt, dass Warning die übemäßige Protokollierung für unerwartete Kategorien verhindert wird.
  • Host.Aggregator und Host.Results werden auf niedrigere Ebenen festgelegt. Das Festlegen der Protokollierungsstufen auf zu hohe Werte (insbesondere höher als Information) kann zu einem Verlust von Metriken und Leistungsdaten führen.
  • Die Protokollierung für Funktionsausführungen ist auf Information festgelegt. Bei Bedarf können Sie diese Einstellung in der lokalen Entwicklung durch Debug oder Trace überschreiben.
{
  "logging": {
    "fileLoggingMode": "debugOnly",
    "logLevel": {
      "default": "Warning",
      "Host.Aggregator": "Trace",
      "Host.Results": "Information",
      "Function": "Information"
    }
  }
}

Wenn host.json mehrere Protokolle enthält, die mit der gleichen Zeichenfolge beginnen, werden zuerst die stärker definierten Protokolle abgeglichen. Sehen Sie sich das folgende Beispiel an, bei dem alle Elemente der Runtime, mit Ausnahme von Host.Aggregator, mit der Stufe Error protokolliert werden:

{
  "logging": {
    "fileLoggingMode": "debugOnly",
    "logLevel": {
      "default": "Information",
      "Host": "Error",
      "Function": "Error",
      "Host.Aggregator": "Information"
    }
  }
}

Sie können die Protokollstufeneinstellung None verwenden, um zu verhindern, dass Protokolle für eine Kategorie geschrieben werden.

Achtung

Azure Functions ist in Application Insights so integriert, dass Telemetrieereignisse in Application Insights-Tabellen gespeichert werden. Wenn Sie einen Kategorieprotokolliergrad auf einen anderen Wert als Information festlegen, wird verhindert, dass die Telemetrie an diese Tabellen übertragen werden, und Sie können auf den Registerkarten Application Insights und Funktionsüberwachung keine zugehörigen Daten sehen.

Für die vorherigen Beispiele gilt etwa Folgendes:

  • Wenn Sie die Kategorie Host.Results auf den Protokolliergrad Error festlegen, sammelt Azure in der Tabelle requests nur Telemetrieereignisse zur Hostausführung. Dadurch wird verhindert, dass Details zu erfolgreichen Hostausführungen auf den Registerkarten Application Insights und Funktionsüberwachung angezeigt werden.
  • Wenn Sie die Kategorie Function auf den Protokolliergrad Error festlegen, wird das Sammeln von Funktionstelemetriedaten im Zusammenhang mit dependencies, customMetrics und customEvents für alle Funktionen beendet, wodurch diese Daten nicht in Application Insights angezeigt werden. Azure sammelt nur traces-Daten, die auf der Stufe Error protokolliert werden.

In beiden Fällen sammelt Azure weiterhin Fehler- und Ausnahmedaten auf den Registerkarten Application Insights und Funktionsüberwachung. Weitere Informationen finden Sie unter Lösungen mit großen Mengen an Telemetriedaten.

Konfigurieren des Aggregators

Wie im vorherigen Abschnitt erwähnt, werden von der Laufzeit Daten zu den Funktionsausführungen in einem bestimmten Zeitraum aggregiert. Der Standardzeitraum beträgt 30 Sekunden oder 1.000 Ausführungen, je nachdem, was früher eintritt. Sie können diese Einstellung in der Datei host.json konfigurieren. Zum Beispiel:

{
    "aggregator": {
      "batchSize": 1000,
      "flushTimeout": "00:00:30"
    }
}

Konfigurieren des Samplings

Application Insights verfügt über ein Feature zur Stichprobenentnahme als Schutz davor, dass bei Spitzenlast zu viele Telemetriedaten für erfolgte Vorgänge produziert werden. Wenn die Rate der eingehenden ausgeführten Vorgänge einen bestimmten Schwellenwert übersteigt, beginnt Application Insights, einige der eingehenden ausgeführten Vorgänge nach dem Zufallsprinzip zu ignorieren. Die Standardeinstellung für die maximale Anzahl ausgeführter Vorgänge pro Sekunde ist 20 (5 in Version 1.x). Sie können die Stichprobenentnahme in der Datei host.json konfigurieren. Hier sehen Sie ein Beispiel:

{
  "logging": {
    "applicationInsights": {
      "samplingSettings": {
        "isEnabled": true,
        "maxTelemetryItemsPerSecond" : 20,
        "excludedTypes": "Request;Exception"
      }
    }
  }
}

Sie können bestimmte Arten von Telemetriedaten aus der Stichprobenentnahme ausschließen. In diesem Beispiel werden Daten vom Typ Request und Exception aus der Stichprobenentnahme ausgeschlossen. Hierdurch wird sichergestellt, dass alle Funktionsausführungen (Anforderungen) und Ausnahmen protokolliert werden, während für andere Arten von Telemetriedaten weiterhin die Stichprobenentnahme verwendet wird.

Wenn Ihr Projekt zur manuellen Nachverfolgung der Telemetrie vom Application Insights SDK abhängig ist, kann ungewöhnliches Verhalten auftreten, wenn Ihre Konfiguration der Stichprobenentnahme von der Konfiguration in Ihrer Funktions-App abweicht. Verwenden Sie in solchen Fällen dieselbe Konfiguration für die Stichprobenentnahme wie die Funktions-App. Weitere Informationen finden Sie unter Erstellen von Stichproben in Application Insights.

Aktivieren der SQL-Abfragesammlung

Application Insights sammelt automatisch Daten zu Abhängigkeiten für HTTP-Anforderungen, Datenbankaufrufe und diverse Bindungen. Weitere Informationen finden Sie unter Abhängigkeiten. Bei SQL-Aufrufen wird der Name des Servers und der Datenbank immer gesammelt und gespeichert, aber SQL-Abfragetext wird nicht standardmäßig gesammelt. Sie können dependencyTrackingOptions.enableSqlCommandTextInstrumentation verwenden, um SQL-Abfragetextprotokollierung zu aktivieren, indem Sie (mindestens) folgende Einstellungen in der Datei host.json festlegen:

"logging": {
    "applicationInsights": {
        "enableDependencyTracking": true,    
        "dependencyTrackingOptions": {
            "enableSqlCommandTextInstrumentation": true
        }
    }
}

Weitere Informationen finden Sie unter Erweiterte SQL-Nachverfolgung, um eine vollständige SQL-Abfrage zu erhalten.

Konfigurieren von Skalierungscontrollerprotokollen

Dieses Feature befindet sich in der Vorschauphase.

Der Skalierungscontroller von Azure Functions kann Protokolle an Application Insights oder an den Blobspeicher ausgeben, damit sie die Entscheidungen, die der Skalierungscontroller für Ihre Funktions-App trifft, besser nachvollziehen können.

Um dieses Feature zu aktivieren, fügen Sie den Einstellungen Ihrer Funktions-App eine Anwendungseinstellung mit dem Namen SCALE_CONTROLLER_LOGGING_ENABLED hinzu. Der folgende Wert der Einstellung muss das Format <DESTINATION>:<VERBOSITY> haben. Weitere Informationen finden Sie in der Tabelle unten:

Eigenschaft Beschreibung
<DESTINATION> Das Ziel, an das Protokolle gesendet werden. Gültige Werte sind AppInsights und Blob.
Wenn Sie AppInsights verwenden, vergewissern Sie sich, dass Application Insights in der Funktions-App aktiviert ist.
Wenn Sie das Ziel auf Blob festgelegt haben, werden Protokolle in einem Blobcontainer mit dem Namen azure-functions-scale-controller in dem Standardspeicherkonto erstellt, das in der Anwendungseinstellung AzureWebJobsStorage festgelegt ist.
<VERBOSITY> Gibt die Protokollierungsstufe an. Unterstützte Werte sind None, Warning und Verbose.
Wenn diese Einstellung auf Verbose festgelegt ist, protokolliert der Skalierungscontroller einen Grund für jede Änderung an der Workeranzahl sowie Informationen zu den Triggern, die diese Entscheidungen beeinflussen. Ausführliche Protokolle enthalten Triggerwarnungen und die Hashes, die von den Triggern vor und nach dem Ausführen des Skalierungscontrollers verwendet werden.

Tipp

Beachten Sie, dass es Auswirkungen auf die potenziellen Kosten für die Überwachung Ihrer Funktions-App haben kann, wenn die Protokollierung des Skalierungscontrollers weiterhin aktiviert ist. Erwägen Sie, die Protokollierung zu aktivieren, bis Sie genügend Daten gesammelt haben, um das Verhalten des Skalierungscontrollers nachzuvollziehen, und deaktivieren Sie sie dann.

Mit dem folgenden Azure CLI-Befehl wird beispielsweise die ausführliche Protokollierung des Skalierungscontrollers in Application Insights aktiviert:

az functionapp config appsettings set --name <FUNCTION_APP_NAME> \
--resource-group <RESOURCE_GROUP_NAME> \
--settings SCALE_CONTROLLER_LOGGING_ENABLED=AppInsights:Verbose

Ersetzen Sie in diesem Beispiel <FUNCTION_APP_NAME> und <RESOURCE_GROUP_NAME> durch den Namen Ihrer Funktions-App bzw. durch den Namen der Ressourcengruppe.

Durch den folgenden Azure CLI-Befehl wird die Protokollierung deaktiviert, indem die Ausführlichkeit auf None festgelegt wird:

az functionapp config appsettings set --name <FUNCTION_APP_NAME> \
--resource-group <RESOURCE_GROUP_NAME> \
--settings SCALE_CONTROLLER_LOGGING_ENABLED=AppInsights:None

Sie können die Protokollierung auch deaktivieren, indem Sie die Einstellung SCALE_CONTROLLER_LOGGING_ENABLED mithilfe des folgenden Azure CLI-Befehls entfernen:

az functionapp config appsettings delete --name <FUNCTION_APP_NAME> \
--resource-group <RESOURCE_GROUP_NAME> \
--setting-names SCALE_CONTROLLER_LOGGING_ENABLED

Wenn die Skalierungscontrollerprotokollierung aktiviert ist, können Sie jetzt Ihre Skalierungscontrollerprotokolle abfragen.

Aktivieren der Application Insights-Integration

Damit eine Funktions-App Daten an Application Insights sendet, muss sie mithilfe nur einer dieser Anwendungseinstellungen eine Verbindung mit der Application Insights-Ressource herstellen:

Einstellungsname Beschreibung
APPLICATIONINSIGHTS_CONNECTION_STRING Dies ist die empfohlene Einstellung, die erforderlich ist, wenn Ihre Application Insights-Instanz in einer Sovereign Cloud ausgeführt wird. Die Verbindungszeichenfolge unterstützt andere neue Funktionen.
APPINSIGHTS_INSTRUMENTATIONKEY Legacyeinstellung, die von Application Insights zugunsten der Einstellung der Verbindungszeichenfolgen nicht mehr unterstützt wird.

Unabhängig davon, ob Sie Ihre Funktions-App im Azure-Portal, über die Befehlszeile mithilfe der Azure Functions Core Tools oder mit Visual Studio Code erstellen, wird die Integration in Application Insights automatisch aktiviert. Die Application Insights-Ressource hat den gleichen Namen wie Ihre Funktions-App und wird entweder in der gleichen oder in der nächstgelegenen Region erstellt.

Microsoft Entra-Authentifizierung erfordern

Sie können die APPLICATIONINSIGHTS_AUTHENTICATION_STRING-Einstellung verwenden, um Verbindungen mit Application Insights mithilfe der Microsoft Entra-Authentifizierung zu aktivieren. Dadurch wird eine einheitliche Authentifizierung für alle Application Insights-Pipelines, einschließlich Profiler und Snapshot-Debugger, sowie vom Functions-Host und sprachspezifischen Agents erstellt.

Hinweis

Es gibt keine Entra-Authentifizierungsunterstützung für die lokale Entwicklung.

Der Wert enthält entweder Authorization=AAD für eine vom System zugewiesene verwaltete Identität oder ClientId=<YOUR_CLIENT_ID>;Authorization=AAD für eine vom Benutzer zugewiesene verwaltete Identität. Die verwaltete Identität muss bereits für die Funktions-App verfügbar sein, mit einer zugewiesenen Rolle, die dem Herausgeber von Überwachungsmetriken entspricht. Weitere Informationen finden Sie unter Microsoft Entra-Authentifizierung für Application Insights.

Die APPLICATIONINSIGHTS_CONNECTION_STRING-Einstellung ist weiterhin erforderlich.

Hinweis

Wenn Sie APPLICATIONINSIGHTS_AUTHENTICATION_STRING zum Herstellen einer Verbindung mit Application Insights mithilfe der Microsoft Entra-Authentifizierung verwenden, sollten Sie auch Lokale Authentifizierung für Application Insights deaktivieren. Diese Konfiguration erfordert die Microsoft Entra-Authentifizierung, damit Telemetrie in Ihren Arbeitsbereich aufgenommen werden kann.

Neue Funktions-App im Azure-Portal

Zum Überprüfen der Application Insights-Ressource, die erstellt wird, wählen Sie sie aus, um das Fenster Application Insights zu erweitern. Sie können den neuen Ressourcennamen ändern oder einen anderen Standort in einer Azure-Region auswählen, in der Sie Ihre Daten speichern möchten.

Screenshot: Aktivieren von Application Insights beim Erstellen einer Funktions-App

Wenn Sie Erstellen auswählen, wird eine Application Insights-Ressource mit Ihrer Funktions-App erstellt, bei der APPLICATIONINSIGHTS_CONNECTION_STRING in den Anwendungseinstellungen festgelegt ist. Alles ist betriebsbereit.

Ergänzen einer vorhandenen Funktions-App

Verwenden Sie die folgenden Schritte zum Erstellen der entsprechenden Ressource, falls für Ihre Funktions-App keine Application Insights-Ressource erstellt wurde. Sie können dann die Verbindungszeichenfolge dieser Ressource Ihrer Funktions-App als Anwendungseinstellung hinzufügen.

  1. Suchen Sie im Azure-Portal nach Funktions-App, und wählen Sie diese Option und dann Ihre Funktions-App aus.

  2. Wählen Sie oben im Fenster das Banner Application Insights ist nicht konfiguriert aus. Sollte dieses Banner nicht angezeigt werden, ist Application Insights möglicherweise bereits für Ihre App aktiviert.

    Screenshot: Aktivieren von Application Insights beim Erstellen über das Portal

  3. Erweitern Sie Ressource ändern, und erstellen Sie eine Application Insights-Ressource. Verwenden Sie dazu die Einstellungen, die in der folgenden Tabelle angegeben sind:

    Einstellung Vorgeschlagener Wert BESCHREIBUNG
    Name der neuen Ressource Eindeutiger App-Name Es ist am einfachsten, den gleichen Namen wie für Ihre Funktionen-App zu verwenden, der in Ihrem Abonnement eindeutig sein muss.
    Location Europa, Westen Wählen Sie nach Möglichkeit dieselbe Region wie für Ihre Funktions-App (oder eine Region in der Nähe).

    Screenshot: Erstellen einer Application Insights-Ressource

  4. Wählen Sie Übernehmen.

    Die Application Insights-Ressource wird in derselben Ressourcengruppe und unter demselben Abonnement wie Ihre Funktionen-App erstellt. Schließen Sie nach der Erstellung der Ressource das Fenster Application Insights.

  5. Erweitern Sie in Ihrer Funktions-App Einstellungen, und wählen Sie dann Umgebungsvariablen aus. Wenn auf der Registerkarte App-Einstellungen eine App-Einstellung namens APPLICATIONINSIGHTS_CONNECTION_STRING angezeigt wird, ist die Application Insights-Integration für Ihre unter Azure ausgeführte Funktions-App aktiviert. Falls diese Einstellung nicht vorhanden ist, fügen Sie sie mithilfe Ihrer Application Insights-Verbindungszeichenfolge als Wert hinzu.

Hinweis

Ältere Funktions-Apps verwenden u. U. APPINSIGHTS_INSTRUMENTATIONKEY anstelle von APPLICATIONINSIGHTS_CONNECTION_STRING. Aktualisieren Sie Ihre App möglichst so, dass anstelle des Instrumentierungsschlüssels die Verbindungszeichenfolge verwendet wird.

Deaktivieren der integrierten Protokollierung

In früheren Versionen von Azure Functions wurde die integrierte Überwachung verwendet, was nicht mehr empfohlen wird. Wenn Sie Application Insights aktivieren, deaktivieren Sie die integrierte Protokollierung mit Verwendung von Azure Storage. Die integrierte Protokollierung ist für Tests mit einfachen Workloads hilfreich, aber sie ist nicht für die Nutzung in der Produktion mit hohen Auslastungen bestimmt. Für die Produktionsüberwachung empfehlen wir die Verwendung von Application Insights. Bei Nutzung der integrierten Protokollierung in der Produktion kann der Protokollierungsdatensatz aufgrund einer Drosselung von Azure Storage ggf. unvollständig sein.

Löschen Sie die App-Einstellung AzureWebJobsDashboard, um die integrierte Protokollierung zu deaktivieren. Weitere Informationen zum Löschen von App-Einstellungen im Azure-Portal finden Sie im Abschnitt Anwendungseinstellungen unter Verwalten einer Funktionen-App im Azure-Portal. Stellen Sie vor dem Löschen der App-Einstellung sicher, dass sie nicht für vorhandene Funktionen in derselben Funktions-App für Azure Storage-Trigger oder -Bindungen verwendet wird.

Lösungen mit großen Mengen an Telemetriedaten

Funktions-Apps sind ein wesentlicher Bestandteil von Lösungen, die große Mengen an Telemetriedaten verursachen können, wie z. B. IoT-Lösungen, schnelle ereignisgesteuerte Lösungen, Finanzsysteme mit hoher Datenlast und Integrationssysteme. In diesem Fall sollten Sie eine zusätzliche Konfiguration in Betracht ziehen, um die Kosten zu senken und sich gleichzeitig Einblicke zu sichern.

Die generierten Telemetriedaten können in Echtzeitdashboards, Warnungen, detaillierten Diagnosen usw. verwendet werden. Je nachdem, wie die generierten Telemetriedaten genutzt werden, müssen Sie eine Strategie zur Reduzierung der generierten Datenmenge festlegen. Mit dieser Strategie können Sie Ihre Funktions-Apps in der Produktion ordnungsgemäß überwachen, betreiben und diagnostizieren. Ziehen Sie folgende Möglichkeiten in Betracht:

  • Stichprobenentnahme verwenden: Wie zuvor erwähnt, kann mit der Stichprobenentnahme die Menge der erfassten Telemetrieereignisse erheblich reduziert werden, während statistisch korrekte Analysen erhalten bleiben. Es kann vorkommen, dass Sie selbst bei Stichprobenentnahmen immer noch eine große Menge an Telemetriedaten erhalten. Überprüfen Sie die von der adaptiven Stichprobenerstellung bereitgestellten Optionen. Legen Sie zum Beispiel den Wert maxTelemetryItemsPerSecond so fest, dass das generierte Volume mit Ihren Überwachungsanforderungen in Einklang ist. Beachten Sie, dass die Stichprobenentnahme für Telemetrie für jeden Host angewendet wird, der Ihre Funktions-App ausführt.

  • Standardprotokollebene: Verwenden Sie Warning oder Error als Standardwert für alle Telemetriekategorien. Später können Sie entscheiden, welche Kategorien Sie auf der Ebene Information festlegen möchten, damit Sie Ihre Funktionen ordnungsgemäß überwachen und diagnostizieren können.

  • Funktionstelemetrie optimieren: Wenn der Standardprotokolliergrad auf Error oder Warning festgelegt ist, werden keine detaillierten Informationen von jeder Funktion gesammelt (Abhängigkeiten, benutzerdefinierte Metriken, benutzerdefinierte Ereignisse und Ablaufverfolgungen). Definieren Sie für die Funktionen, die für die Produktionsüberwachung von entscheidender Bedeutung sind, einen expliziten Eintrag für die Kategorie Function.<YOUR_FUNCTION_NAME>, und legen Sie die Kategorie auf Information fest, um ausführliche Informationen sammeln zu können. Um das Sammeln von benutzergenerierten Protokolle auf der Ebene Information zu vermeiden, legen Sie die Kategorie Function.<YOUR_FUNCTION_NAME>.User auf die Protokollebene Error oder Warning fest.

  • Host.Aggregator-Kategorie: Wie unter Konfigurieren von Kategorienbeschrieben, stellt diese Kategorie aggregierte Informationen zu Funktionsaufrufen bereit. Die Informationen aus dieser Kategorie werden in der Application Insights-Tabelle customMetrics gesammelt und im Azure-Portal auf der Registerkarte Übersicht für die Funktion angezeigt. Je nachdem, wie Sie den Aggregator konfigurieren, ziehen Sie in Betracht, dass es bei den gesammelten Telemetriedaten zu einer Verzögerung kommt, die von der Einstellung flushTimeout bestimmt wird. Wenn Sie diese Kategorie auf einen anderen Wert als Information festlegen, wird das Sammeln der Daten in der Tabelle customMetrics beendet, und auf der Registerkarte Übersicht für die Funktion werden keine Metriken angezeigt.

    Der folgende Screenshot zeigt Host.Aggregator-Telemetriedaten, die auf der Registerkarte Übersicht der Funktion gezeigt werden.

    Screenshot: Host.Aggregator-Telemetriedaten der Registerkarte „Übersicht“ der Funktion

    Der folgende Screenshot zeigt Host.Aggregator-Telemetriedaten, die in der Application Insights-Tabelle customMetrics enthalten sind:

    Screenshot: Host.Aggregator-Telemetriedaten in der Application Insights-Tabelle „customMetrics“

  • Kategorie „Host.Results“: Wie unter Konfigurieren von Kategorien beschrieben, stellt diese Kategorie die zur Laufzeit generierten Protokolle bereit, die eine erfolgreiche oder fehlerhafte Ausführung eines Funktionsaufrufs angeben. Die Informationen dieser Kategorie werden in der Application Insights-Tabelle requests gesammelt und auf der Registerkarte Überwachung der Funktion sowie auf verschiedenen Application Insights-Dashboards (Leistung, Ausfälle usw.) gezeigt. Wenn Sie diese Kategorie auf einen anderen Wert als Information festlegen, werden nur Telemetriedaten erfasst, die auf der festgelegten Protokollebene (oder höher) generiert wurden. Wenn Sie sie z. B. auf error festlegen, werden Anforderungsdaten nur für fehlgeschlagene Ausführungen nachverfolgt.

    Der folgende Screenshot zeigt die Host.Results-Telemetriedaten, die auf der Registerkarte Überwachung der Funktion gezeigt werden.

    Screenshot: Host.Results-Telemetriedaten auf der Registerkarte „Überwachung“ der Funktion

    Der folgende Screenshot zeigt die Host.Results-Telemetriedaten, die im Application Insights-Dashboard „Leistung“ angezeigt werden:

    Screenshot: Host.Results-Telemetriedaten auf dem Application Insights-Dashboard „Leistung“

  • Vergleich von Host.Aggregator und Host.Results: Beide Kategorien liefern hilfreiche Erkenntnisse über Funktionsausführungen. Bei Bedarf können Sie die ausführlichen Informationen aus einer dieser Kategorien entfernen, sodass Sie die andere für Überwachung und Warnungen verwenden können. Hier ein Beispiel:

{
  "version": "2.0",  
  "logging": {
    "logLevel": {
      "default": "Warning",
      "Function": "Error",
      "Host.Aggregator": "Error",
      "Host.Results": "Information", 
      "Function.Function1": "Information",
      "Function.Function1.User": "Error"
    },
    "applicationInsights": {
      "samplingSettings": {
        "isEnabled": true,
        "maxTelemetryItemsPerSecond": 1,
        "excludedTypes": "Exception"
      }
    }
  }
}

Bei dieser Konfiguration gilt Folgendes:

  • Der Standardwert für alle Funktionen und Telemetriekategorien ist auf Warning festgelegt (einschließlich der Kategorien „Microsoft“ und „Worker“). Daher werden standardmäßig alle Fehler und Warnungen gesammelt, die sowohl von der Runtime als auch von der benutzerdefinierten Protokollierung generiert werden.

  • Der Protokolliergrad der Kategorie Function ist auf Error festgelegt, sodass für alle Funktionen standardmäßig nur Ausnahmen und Fehlerprotokolle erfasst werden. Abhängigkeiten, vom Benutzer generierte Metriken und vom Benutzer generierte Ereignisse werden übersprungen.

  • Da die Kategorie Host.Aggregator auf die Protokollebene Error festgelegt ist, werden in der Application Insights-Tabelle customMetrics keine aggregierten Informationen aus Funktionsaufrufen gesammelt, und auf dem Dashboard der Funktionsübersicht werden keine Informationen zur Anzahl von Ausführungen (Gesamtanzahl, Erfolgreich, Fehler) angezeigt.

  • Für die Kategorie Host.Results werden alle Informationen zur Hostausführung in der Application Insights-Tabelle requests gesammelt. Alle Aufrufergebnisse werden auf dem Dashboard für die Funktionsüberwachung und auf Application Insights-Dashboards angezeigt.

  • Für die Funktion mit dem Namen Function1 haben wir den Protokolliergrad auf Information festgelegt. Dadurch werden für diese konkrete Funktion alle Telemetriedaten gesammelt (Abhängigkeit, benutzerdefinierte Metriken und benutzerdefinierte Ereignisse). Für dieselbe Funktion legen wir die Kategorie Function1.User (vom Benutzer generierte Ablaufverfolgungen) auf Error fest, sodass nur die benutzerdefinierte Fehlerprotokollierung gesammelt wird.

    Hinweis

    Eine funktionsbezogene Konfiguration wird in Version 1.x der Functions-Laufzeit nicht unterstützt.

  • Die Stichprobenentnahme ist so konfiguriert, dass pro Sekunde und Typ ein Telemetrieelement gesendet wird, außer für Ausnahmen. Diese Stichprobenentnahme erfolgt für jeden Serverhost, auf dem unsere Funktions-App ausgeführt wird. Wenn wir also über vier Instanzen verfügen, gibt diese Konfiguration vier Telemetrieelemente pro Sekunde und Typ sowie alle Ausnahmen aus, die möglicherweise auftreten.

    Hinweis

    Metrikwerte wie z. B. die Anforderungs- und Ausnahmerate werden zum Kompensieren der Stichprobenrate angepasst, sodass im Metrik-Explorer annähernd korrekte Werte angezeigt werden.

Tipp

Experimentieren Sie mit verschiedenen Konfigurationen, um Ihre Anforderungen an Protokollierung, Überwachung und Warnungen zu erfüllen. Stellen Sie auch sicher, dass Sie über detaillierte Diagnosen für unerwartete Fehler oder Fehlfunktionen verfügen.

Außerkraftsetzen der Überwachungskonfiguration zur Laufzeit

Es kann Situationen geben, in denen Sie das Protokollierungsverhalten einer bestimmten Kategorie in der Produktionsumgebung schnell ändern müssen und Sie nicht nur für eine Änderung in der Datei host.json eine vollständige Bereitstellung erstellen möchten. In solchen Fällen können Sie die Werte in der Datei „host.json“ außer Kraft setzen.

Um diese Werte auf App-Einstellungsebene zu konfigurieren (und eine erneute Bereitstellung nur bei Änderungen an host.json zu vermeiden), sollten Sie bestimmte host.json-Werte außer Kraft setzen, indem Sie einen entsprechenden Wert als Anwendungseinstellung erstellen. Wenn die Runtime eine Anwendungseinstellung im Format AzureFunctionsJobHost__path__to__setting ermittelt, wird die entsprechende host.json-Einstellung in der host.json-Datei unter path.to.setting außer Kraft gesetzt. Bei der Angabe als Anwendungseinstellung wird der Punkt (.), mit dem die JSON-Hierarchie angegeben wird, durch einen doppelten Unterstrich (__) ersetzt. Sie können beispielsweise die folgenden App-Einstellungen verwenden, um einzelne Funktionsprotokollebenen in host.json zu konfigurieren.

Host.json-Pfad App-Einstellung
logging.logLevel.default AzureFunctionsJobHost__logging__logLevel__default
logging.logLevel.Host.Aggregator AzureFunctionsJobHost__logging__logLevel__Host__Aggregator
logging.logLevel.Function AzureFunctionsJobHost__logging__logLevel__Function
logging.logLevel.Function.Function1 AzureFunctionsJobHost__logging__logLevel__Function__Function1
logging.logLevel.Function.Function1.User AzureFunctionsJobHost__logging__logLevel__Function__Function1__User

Sie können die Einstellungen direkt im Azure-Portal im Bereich „Konfiguration von Funktions-App“ oder mithilfe eines Azure CLI- oder PowerShell-Skripts überschreiben.

az functionapp config appsettings set --name MyFunctionApp --resource-group MyResourceGroup --settings "AzureFunctionsJobHost__logging__logLevel__Host__Aggregator=Information"

Hinweis

Wenn Sie die host.json-Datei durch Ändern der App-Einstellungen außer Kraft setzen, wird Ihre Funktions-App neu gestartet. App-Einstellungen, die einen Zeitraum enthalten, werden nicht unterstützt, wenn sie unter Linux im Plan „Elastisch Premium“ oder dem Plan „Dedicated“ (App Service) ausgeführt werden. In diesen Hostingumgebungen sollten Sie weiterhin die Datei host.json verwenden.

Überwachen von Funktions-Apps mithilfe der Integritätsprüfung

Sie können das Feature „Integritätsprüfung“ verwenden, um Funktions-Apps in den Plänen „Premium“ (Elastic Premium) und „Dedicated“ (App Service) zu überwachen. Die Integritätsprüfung ist keine Option für den Verbrauchsplan. Weitere Informationen zur Konfiguration finden Sie unter Überwachen von App Service-Instanzen mit der Integritätsprüfung. Ihre Funktions-App sollte über eine HTTP-Triggerfunktion verfügen, die mit dem HTTP-Statuscode 200 auf demselben Endpunkt reagiert, der im Parameter Path der Integritätsprüfung konfiguriert ist. Sie können diese Funktion auch zusätzliche Überprüfungen ausführen lassen, um sicherzustellen, dass abhängige Dienste erreichbar sind und funktionieren.

Zugehöriger Inhalt

Weitere Informationen zur Überwachung finden Sie unter: