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

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:

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:

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:

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

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

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

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

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

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

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:

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:

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.

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.

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

   

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

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.

  

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

  

  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:

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

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

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

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.

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"

Update-AzFunctionAppSetting -Name MyAppName -ResourceGroupName MyResourceGroupName -AppSetting @{"AzureFunctionsJobHost__logging__logLevel__Host.Aggregator" = "Information"}

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

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