Konfigurieren der Überwachung für Azure Functions

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 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.

Später in diesem Artikel erfahren Sie, wie Sie die Daten konfigurieren und anpassen, die Ihre Funktionen an Application Insights senden. Die allgemeine Protokollierungskonfiguration kann in der Datei host.json festgelegt werden. Standardmäßig steuern diese Einstellungen auch benutzerdefinierte Protokolle, die vom Code ausgegeben werden, obwohl dieses Verhalten in einigen Fällen zugunsten von Optionen deaktiviert werden kann, die Ihnen mehr Kontrolle über die Protokollierung geben. 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 über die 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. Die Protokollierungspipeline wird 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 Optionen zusammengefasst:

Sprachstapel	Konfiguration von benutzerdefinierten Protokollen
.NET (In-Process-Modell)	host.json
.NET (isoliertes Modell)	Standardeinstellung: host.json Option zum direkten Senden von Protokollen: Konfigurieren von Application Insights in HostBuilder
Node.JS	host.json
Python	host.json
Java	Standardeinstellung: host.json Option zum direkten Senden von Protokollen: Konfigurieren des Application Insights-Java-Agents
PowerShell	host.json

Wenn benutzerdefinierte Anwendungsprotokolle 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 möglicherweise Änderungen für beide 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:

Ab v2.x

Kategorie	Tabelle	BESCHREIBUNG
Function	traces	Enthält gestartete 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.

v1.x

Kategorie	Tabelle	BESCHREIBUNG
Function	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.Executor	traces	Enthält die gestartete Funktion und die abgeschlossene Funktion für bestimmte Funktionsausführungen. Bei erfolgreichen Ausführungen haben diese Protokolle die Stufe Information. Ausnahmen werden mit 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.
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.

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 dieser Werte auf zu hoch (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. Dies kann bei Bedarf in der lokalen Entwicklung oder bei Bedarf DebugüberschriebenTrace werden.

v2.x+

{
  "logging": {
    "fileLoggingMode": "debugOnly",
    "logLevel": {
      "default": "Warning",
      "Host.Aggregator": "Trace",
      "Host.Results": "Information",
      "Function": "Information"
    }
  }
}

v1.x

{
  "logger": {
    "categoryFilter": {
      "defaultLevel": "Warning",
      "categoryLevels": {
        "Host.Results": "Information",
        "Host.Aggregator": "Trace",
        "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:

v2.x+

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

v1.x

{
  "logger": {
    "categoryFilter": {
      "defaultLevel": "Information",
      "categoryLevels": {
        "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 die Kategorieprotokollebene auf einen anderen Wert als Information festlegen, wird verhindert, dass die Telemetriedaten in diese Tabellen eingehen. Infolgedessen können Sie die entsprechenden Daten nicht in Application Insights oder auf der Registerkarte Überwachung der Funktion sehen.

Für die obigen Beispiele gilt Folgendes:

• Wenn die Kategorie Host.Results auf die Protokollebene Error festgelegt ist, werden in der Tabelle requests nur Telemetrieereignisse zur Hostausführung für fehlerhafte Funktionsausführungen gesammelt. Dadurch wird verhindert, dass Details zu erfolgreichen Hostausführungen auf den Registerkarten Application Insights und Überwachung der Funktion angezeigt werden.
• Wenn die Kategorie Function auf die Protokollebene Error festgelegt ist, 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. Es werden nur traces gesammelt, die mit der Ebene Error protokolliert werden.

In beiden Fällen sammeln Sie weiterhin Fehler- und Ausnahmedaten auf den Registerkarten Application Insights und Überwachung der Funktion. 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. Hier sehen Sie ein 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:

v2.x+

{
  "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.

v1.x

{
  "applicationInsights": {
    "sampling": {
      "isEnabled": true,
      "maxTelemetryItemsPerSecond" : 5
    }
  }
}

Wenn Ihr Projekt zur manuellen Nachverfolgung der Telemetrie vom Application Insights SDK abhängig ist, kann unerwartetes 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) Folgendes 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, können Sie den Einstellungen Ihrer Funktions-App eine Anwendungseinstellung mit dem Namen SCALE_CONTROLLER_LOGGING_ENABLED hinzufügen. Der folgende Wert der Einstellung muss im Format <DESTINATION>:<VERBOSITY> enthalten sein:

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 mit nur einer der folgenden 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 souveränen Cloud ausgeführt wird. Die Verbindungszeichenfolge unterstützt andere neue Funktionen.
APPINSIGHTS_INSTRUMENTATIONKEY	Legacyeinstellung, die von Application Insights zugunsten der einstellung Verbindungszeichenfolge veraltet ist.

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 nächstgelegenen Region erstellt.

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.

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. Anschließend können Sie die Verbindungszeichenfolge aus dieser Ressource als Anwendungseinstellung in Ihrer Funktions-App 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.

   

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).

   

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. Wählen Sie in Ihrer Funktions-App unter Einstellungen die Option Konfiguration und dann Anwendungseinstellungen aus. Wenn die Einstellung APPLICATIONINSIGHTS_CONNECTION_STRING angezeigt wird, bedeutet dies, dass die Application Insights-Integration für Ihre unter Azure ausgeführte Funktions-App aktiviert ist. Wenn diese Einstellung aus irgendeinem Grund nicht vorhanden ist, fügen Sie sie mithilfe Ihrer Application Insights-Verbindungszeichenfolge als Wert hinzu.

Hinweis

Ältere Funktions-Apps können APPINSIGHTS_INSTRUMENTATIONKEY anstelle von APPLICATIONINSIGHTS_CONNECTION_STRING. Wenn möglich, sollten Sie Ihre App aktualisieren, um die Verbindungszeichenfolge anstelle des Instrumentierungsschlüssels zu verwenden.

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 sollen, müssen Sie eine Strategie zur Reduzierung der generierten Datenmenge festlegen. Mit dieser Strategie können Sie Ihre Funktions-Apps in einer Produktionsumgebung ordnungsgemäß überwachen, betreiben und diagnostizieren. Ziehen Sie folgende Optionen in Betracht:

• Stichprobenentnahme: Wie zuvor erwähnt, kann damit 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. Nun 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 die Standardprotokollebene 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 an diesem Punkt 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 der 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 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.

  

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

  

• 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 sowie in 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.

  

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

  

• 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:

Ab v2.x

{
  "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"
      }
    }
  }
} 

v1.x

{
  "logger": {
    "categoryFilter": {
      "defaultLevel": "Warning",
      "categoryLevels": {
        "Function": "Error",
        "Host.Aggregator": "Error",
        "Host.Results": "Information",
        "Host.Executor": "Warning"
      }
    }
  },
  "applicationInsights": {
    "sampling": {
      "isEnabled": true,
      "maxTelemetryItemsPerSecond" : 5
    }
  }
}

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.

• Die Kategorieprotokollebene Function ist auf Error festgelegt, sodass für alle Funktionen standardmäßig nur Ausnahmen und Fehlerprotokolle gesammelt werden (Abhängigkeiten sowie benutzergenerierte Metriken und 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 im 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 im Dashboard der Funktionsüberwachung und in Application Insights-Dashboards angezeigt.

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

  Hinweis

  Eine funktionsbezogene Konfiguration wird in Version 1.x 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 Sie die folgenden App-Einstellungen beispielsweise verwenden, um einzelne Funktionsprotokollebenen zu konfigurieren, wie oben in host.json geschehen.

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 auf dem Blatt „Konfiguration von Funktions-App“ oder mithilfe eines Azure CLI-Befehls oder PowerShell-Skripts überschreiben.

az cli

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

PowerShell

Update-AzFunctionAppSetting -Name MyAppName -ResourceGroupName MyResourceGroupName -AppSetting @{"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

Das Feature „Integritätsprüfung“ kann verwendet werden, 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“ (Pfad) 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.

Nächste Schritte

Weitere Informationen zur Überwachung finden Sie unter:

• Überwachen von Azure Functions
• Analysieren von Azure Functions-Telemetriedaten in Application Insights
• Application Insights