Teilen über

Arbeitsbereichsbasierte Application Insights-Ressourcen

  • Artikel

Arbeitsbereichsbasierte Azure Monitor Application Insights-Ressourcen integrieren Application Insights und Log Analytics.

Mit arbeitsbereichsbasierten Ressourcen sendet Application Insights Telemetriedaten an einen gemeinsamen Log Analytics-Arbeitsbereich, der Vollzugriff auf alle Features von Log Analytics bietet und gleichzeitig Anwendungs-, Infrastruktur- und Plattformprotokolle in einem einzigen konsolidierten Speicherort speichert. Diese Integration ermöglicht auch eine gemeinsame rollenbasierte Zugriffssteuerung in Azure für Ihre gesamten Ressourcen, und die Notwendigkeit anwendungs- bzw. arbeitsbereichsübergreifender Abfragen entfällt.

Hinweis

Die Abrechnung der Datenerfassung und -aufbewahrung für arbeitsbereichsbasierte Application Insights-Ressourcen erfolgt über den Log Analytics-Arbeitsbereich, in dem sich die Daten befinden. Weitere Informationen zur Abrechnung für arbeitsbereichsbasierte Application Insights-Ressourcen finden Sie unter Azure Monitor-Protokolle: Preisdetails.

Neue Funktionen

Eine arbeitsbereichsbasierte Application Insights-Instanz wird in Azure Monitor und Log Analytics integriert, um Funktionen zu verbessern:

Erstellen einer arbeitsbereichsbasierten Ressource

Melden Sie sich beim Azure-Portal an, und erstellen Sie eine Application Insights-Ressource.

Screenshot einer arbeitsbereichsbasierten Application Insights-Ressource.

Wenn Sie noch nicht über einen Log Analytics-Arbeitsbereich verfügen, sehen Sie sich die Dokumentation zum Erstellen von Log Analytics-Arbeitsbereichen an.

Arbeitsbereichsbasierte Ressourcen sind zurzeit in allen kommerziellen Regionen und für Azure Government verfügbar. Wenn sich Application Insights und Log Analytics in zwei verschiedenen Regionen befinden, kann sich dies auf die Wartezeit auswirken und die Zuverlässigkeit der Überwachungslösung insgesamt verringern.

Nachdem Sie Ihre Ressource erstellt haben, werden entsprechende Arbeitsbereichsinformationen im Bereich Übersicht angezeigt.

Screenshot eines Arbeitsbereichsnamens.

Wählen Sie den blauen Linktext aus, um zum zugeordneten Log Analytics-Arbeitsbereich zu gelangen, wo Sie die neue einheitliche Umgebung für Arbeitsbereichsabfragen nutzen können.

Hinweis

Wir bieten weiterhin vollständige Abwärtskompatibilität für Ihre klassischen Application Insights-Ressourcenabfragen, Arbeitsmappen und protokollbasierten Warnungen. Um die neue arbeitsbereichsbasierte Tabellenstruktur und das neue Tabellenschema anzuzeigen und abzufragen, müssen Sie zuerst zu Ihrem Log Analytics-Arbeitsbereich wechseln. Wählen Sie Protokolle (Analytics) in den Application Insights-Bereichen aus, um Zugriff auf die klassische Application Insights-Abfrageerfahrung zu erhalten.

Verbindungszeichenfolge kopieren

Die Verbindungszeichenfolge identifiziert die Ressource, der Sie Ihre Telemetriedaten zuordnen möchten. Sie können damit auch die Endpunkte ändern, die Ihre Ressource als Ziel für die Telemetrie verwendet. Sie müssen die Verbindungszeichenfolge kopieren und dem Code Ihrer Anwendung oder einer Umgebungsvariable hinzufügen.

Konfigurieren der Überwachung

Nach dem Erstellen einer arbeitsbereichsbasierten Application Insights-Ressource konfigurieren Sie die Überwachung.

Codebasierte Anwendungsüberwachung

Für die codebasierte Anwendungsüberwachung installieren Sie das geeignete Application Insights SDK und verweisen die Verbindungszeichenfolge auf Ihre neu erstellte Ressource.

Informationen zum Einrichten eines Application Insights SDK für codebasierte Überwachung finden Sie in der folgenden für die Sprache oder das Framework spezifischen Dokumentation:

Überwachung ohne Code

Für die codelose Überwachung von Diensten wie Azure Functions und Azure App Services können Sie zuerst Ihre arbeitsbereichsbasierte Application Insights-Ressource erstellen. Anschließend verweisen Sie bei der Konfiguration der Überwachung auf diese Ressource. Alternativ können Sie eine neue Application Insights-Ressource als Teil der Application Insights-Aktivierung erstellen.

Automatisches Erstellen einer Ressource

Azure CLI

Für den Zugriff auf die Azure CLI-Befehle (Vorschauversion) von Application Insights müssen Sie zuerst Folgendes ausführen:

 az extension add -n application-insights

Wenn Sie den Befehl az extension add nicht ausführen, wird eine Fehlermeldung mit dem folgenden Text angezeigt: az : ERROR: az monitor: 'app-insights' is not in the 'az monitor' command group. See 'az monitor --help'.

Jetzt können Sie folgenden Code ausführen, um Ihre Application Insights-Ressource zu erstellen:

az monitor app-insights component create --app
                                         --location
                                         --resource-group
                                         [--application-type]
                                         [--ingestion-access {Disabled, Enabled}]
                                         [--kind]
                                         [--only-show-errors]
                                         [--query-access {Disabled, Enabled}]
                                         [--tags]
                                         [--workspace]

Beispiel

az monitor app-insights component create --app demoApp --location eastus --kind web -g my_resource_group --workspace "/subscriptions/00000000-0000-0000-0000-000000000000/resourcegroups/test1234/providers/microsoft.operationalinsights/workspaces/test1234555"

Vollständige Informationen zu diesem Befehl finden Sie in der Azure CLI-Dokumentation.

Azure PowerShell

Erstellen Sie eine neue arbeitsbereichsbasierte Application Insights-Ressource.

New-AzApplicationInsights -Name <String> -ResourceGroupName <String> -Location <String> -WorkspaceResourceId <String>
   [-SubscriptionId <String>]
   [-ApplicationType <ApplicationType>]
   [-DisableIPMasking]
   [-DisableLocalAuth]
   [-Etag <String>]
   [-FlowType <FlowType>]
   [-ForceCustomerStorageForProfiler]
   [-HockeyAppId <String>]
   [-ImmediatePurgeDataOn30Day]
   [-IngestionMode <IngestionMode>]
   [-Kind <String>]
   [-PublicNetworkAccessForIngestion <PublicNetworkAccessType>]
   [-PublicNetworkAccessForQuery <PublicNetworkAccessType>]
   [-RequestSource <RequestSource>]
   [-RetentionInDays <Int32>]
   [-SamplingPercentage <Double>]
   [-Tag <Hashtable>]
   [-DefaultProfile <PSObject>]
   [-Confirm]
   [-WhatIf]
   [<CommonParameters>]

Beispiel

New-AzApplicationInsights -Kind java -ResourceGroupName testgroup -Name test1027 -location eastus -WorkspaceResourceId "/subscriptions/00000000-0000-0000-0000-000000000000/resourcegroups/test1234/providers/microsoft.operationalinsights/workspaces/test1234555"

Die vollständige PowerShell-Dokumentation für dieses Cmdlet und Informationen zum Abrufen der Verbindungszeichenfolge finden Sie in der Azure PowerShell-Dokumentation.

Azure-Ressourcen-Manager-Vorlagen

@description('Name of Application Insights resource.')
param name string

@description('Type of app you are deploying. This field is for legacy reasons and will not impact the type of App Insights resource you deploy.')
param type string

@description('Which Azure Region to deploy the resource to. This must be a valid Azure regionId.')
param regionId string

@description('See documentation on tags: https://learn.microsoft.com/azure/azure-resource-manager/management/tag-resources.')
param tagsArray object

@description('Source of Azure Resource Manager deployment')
param requestSource string

@description('Log Analytics workspace ID to associate with your Application Insights resource.')
param workspaceResourceId string

resource component 'Microsoft.Insights/components@2020-02-02' = {
  name: name
  location: regionId
  tags: tagsArray
  kind: 'other'
  properties: {
    Application_Type: type
    Flow_Type: 'Bluefield'
    Request_Source: requestSource
    WorkspaceResourceId: workspaceResourceId
  }
}

Parameterdatei

{
  "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentParameters.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "name": {
      "value": "my_workspace_based_resource"
    },
    "type": {
      "value": "web"
    },
    "regionId": {
      "value": "westus2"
    },
    "tagsArray": {
      "value": {}
    },
    "requestSource": {
      "value": "CustomDeployment"
    },
    "workspaceResourceId": {
      "value": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourcegroups/testxxxx/providers/microsoft.operationalinsights/workspaces/testworkspace"
    }
  }
}

Ändern des zugeordneten Arbeitsbereichs

Nach dem Erstellen einer arbeitsbereichsbasierten Application Insights-Ressource können Sie den zugeordneten Log Analytics-Arbeitsbereich ändern.

Wählen Sie im Bereich der Application Insights-Ressource Eigenschaften>Arbeitsbereich ändern>Log Analytics-Arbeitsbereiche aus.

Exportieren von Telemetriedaten

Die Legacyfunktion für den fortlaufenden Export wird für arbeitsbereichsbasierte Ressourcen nicht unterstützt. Wählen Sie stattdessen in Ihre Application Insights-Ressource Diagnoseeinstellungen>Diagnoseeinstellung hinzufügen aus. Sie können alle Tabellen oder eine Teilmenge der Tabellen auswählen, die Sie in einem Speicherkonto archivieren möchten. Sie können sie auch an einen Azure Event Hub streamen.

Hinweis

Der Export von Diagnoseeinstellungen kann die Kosten erhöhen. Weitere Informationen finden Sie unter Exportieren von Telemetrie aus Application Insights. Preisinformationen für dieses Feature finden Sie auf der Seite Azure Monitor – Preise. Zu Beginn des Abrechnungszeitraums erhalten Sie eine entsprechende Benachrichtigung. Wenn Sie den Telemetrieexport über den Benachrichtigungszeitraum hinaus weiter verwenden, wird Ihnen dies mit dem entsprechenden Tarif in Rechnung gestellt.

Wie viele Application Insights-Ressourcen sollte ich bereitstellen?

Wenn Sie die nächste Version einer Webanwendung entwickeln, sollten Sie die Application Insights-Telemetriedaten der neuen Version nicht mit denen der bereits veröffentlichten Version verwechseln.

Um Verwirrung zu vermeiden, senden Sie die Telemetriedaten aus verschiedenen Entwicklungsphasen mit separaten Verbindungszeichenfolgen an getrennte Application Insights-Ressourcen.

Wenn Ihr System eine Instanz von Azure Cloud Services ist, gibt es eine andere Methode zum Festlegen separater Verbindungszeichenfolgen.

Kontoschlüssel und Verbindungszeichenfolgen

Wenn Sie Application Insights-Überwachung für Ihre Web-App einrichten, erstellen Sie in Azure eine Application Insights-Ressource. Sie öffnen die Ressource im Azure-Portal, um die von Ihrer App gesammelten Telemetriedaten anzuzeigen und zu analysieren. Eine Verbindungszeichenfolge identifiziert die Ressource. Wenn Sie das Application Insights-Paket installieren, um Ihre App zu überwachen, konfigurieren Sie die App mit dieser Verbindungszeichenfolge und teilen ihr so mit, wohin die Telemetriedaten gesendet werden sollen.

Jede Application Insights-Ressource umfasst Metriken, die vordefiniert verfügbar sind. Wenn gesonderte Komponenten an dieselbe Application Insights-Ressource melden, ist es möglicherweise nicht sinnvoll, bei diesen Metriken zu warnen.

Verwenden einer einzelnen Application Insights-Ressource

Verwenden Sie eine einzelne Application Insights-Ressource für Folgendes:

  • Optimieren der DevOps/ITOps-Verwaltung für gemeinsam bereitgestellte Anwendungen, die in der Regel vom selben Team entwickelt und verwaltet werden
  • Standardmäßiges Zentralisieren von Key Performance Indicators (KPI), z. B. Antwortzeiten und Fehlerraten, auf einem Dashboard. Segmentieren Sie im Metrik-Explorer bei Bedarf nach Rollennamen.
  • Wenn keine unterschiedliche Verwaltung der rollenbasierten Zugriffssteuerung in Azure zwischen den Anwendungskomponenten erforderlich ist
  • Wenn Warnungskriterien für identische Metriken, fortlaufende Exporte und Abrechnungs-/Kontingentverwaltung über Komponenten hinweg ausreichen
  • Wenn es für einen API-Schlüssel akzeptabel ist, auf Daten aus allen Komponenten gleichermaßen zuzugreifen und 10 API-Schlüssel die Anforderungen für alle Komponenten erfüllen
  • Wenn die gleichen Einstellungen für die intelligente Erkennung und Arbeitselementintegration für alle Rollen geeignet sind

Hinweis

Wenn Sie mehrere Application Insights-Ressourcen konsolidieren möchten, können Sie Ihre vorhandenen Anwendungskomponenten auf eine neue, konsolidierte Application Insights-Ressource verweisen. Die in Ihrer alten Ressource gespeicherten Telemetriedaten werden nicht an die neue Ressource übertragen. Löschen Sie die alte Ressource also erst, wenn Sie über genügend Telemetriedaten zur Geschäftskontinuität in der neuen Ressource verfügen.

Weitere Überlegungen

Um Portaloberflächen zu aktivieren, fügen Sie benutzerdefinierten Code hinzu, um dem Attribut Cloud_RoleName aussagekräftige Werte zuzuweisen. Ohne diese Werte funktionieren Portalfeatures nicht.

Bei Azure Service Fabric-Anwendungen und klassischen Clouddiensten konfiguriert das SDK automatisch Dienste, indem es aus der Azure-Rollenumgebung liest. Bei anderen App-Typen müssen Sie sie in der Regel festlegen.

Livemetriken können Daten nicht nach Rollenname teilen.

Erstellen weiterer Application Insights-Ressourcen

Informationen zum Erstellen einer Application Insights-Ressource finden Sie unter Erstellen einer Application Insights-Ressource.

Warnung

Es können zusätzliche Netzwerkkosten anfallen, wenn Ihre Application Insights-Ressource eine Azure-Ressource (die Telemetriedaten erzeugt) in einer anderen Region überwacht. Die Kosten werden je nach Region variieren, aus der die Telemetriedaten stammen und wohin sie gehen. Weitere Informationen finden Sie unter Azure-Bandbreite – Preise.

Abrufen der Verbindungszeichenfolge

Die Verbindungszeichenfolge identifiziert die von Ihnen erstellte Ressource.

Sie benötigen die Verbindungszeichenfolgen aller Ressourcen, an die Ihre App Daten sendet.

Filtern nach Buildnummer

Wenn Sie eine neue Version Ihrer App veröffentlichen, sollten Sie die Telemetriedaten aus verschiedenen Builds trennen können.

Sie können die Eigenschaft Anwendungsversion festlegen, sodass Sie die Ergebnisse in der Suche und im Metrik-Explorer filtern können.

Es gibt mehrere unterschiedliche Methoden, um die Eigenschaft Anwendungsversion festzulegen.

  • Direktes Festlegen:

    telemetryClient.Context.Component.Version = typeof(MyProject.MyClass).Assembly.GetName().Version;

  • Umschließen Sie diese Zeile mit einem Telemetrieinitialisierer, um sicherzustellen, dass alle TelemetryClient-Instanzen konsistent festgelegt sind.

  • ASP.NET: Legen Sie die Version in BuildInfo.config fest. Das Webmodul übernimmt die Version aus dem Knoten BuildLabel. Schließen Sie diese Datei in Ihr Projekt ein, und denken Sie daran, die Eigenschaft Immer kopieren im Projektmappen-Explorer festzulegen.

    <?xml version="1.0" encoding="utf-8"?>
<DeploymentEvent xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="https://www.w3.org/2001/XMLSchema" xmlns="http://schemas.microsoft.com/VisualStudio/DeploymentEvent/2013/06">
  <ProjectName>AppVersionExpt</ProjectName>
  <Build type="MSBuild">
    <MSBuild>
      <BuildLabel kind="label">1.0.0.2</BuildLabel>
    </MSBuild>
  </Build>
</DeploymentEvent>

  • ASP.NET: Generieren Sie BuildInfo.config automatisch in der Microsoft-Build-Engine. Fügen Sie Zweck Ihrer .csproj-Datei ein paar Zeilen hinzu:

    <PropertyGroup>
  <GenerateBuildInfoConfigFile>true</GenerateBuildInfoConfigFile>    <IncludeServerNameInBuildInfo>true</IncludeServerNameInBuildInfo>
</PropertyGroup>

    Durch diesen Schritt wird eine Datei namens NameIhresProjekts.BuildInfo.config generiert. Der Veröffentlichungsprozess benennt diese Datei in BuildInfo.config um.

    Die Buildbezeichnung enthält einen Platzhalter (*AutoGen_...*), wenn Sie für die Erstellung Visual Studio verwenden. Wenn die Erstellung jedoch mit der Microsoft-Build-Engine erfolgt, wird er mit der richtigen Versionsnummer aufgefüllt.

    Damit die Microsoft-Build-Engine Versionsnummern generieren kann, legen Sie die Version wie 1.0.* in AssemblyReference.cs fest.

Versionsnachverfolgung

Stellen Sie für die Nachverfolgung der Anwendungsversion sicher, dass der Microsoft-Build-Engine-Prozess buildinfo.config generiert. Fügen Sie in der .csproj-Datei Folgendes hinzu:

<PropertyGroup>
  <GenerateBuildInfoConfigFile>true</GenerateBuildInfoConfigFile>
  <IncludeServerNameInBuildInfo>true</IncludeServerNameInBuildInfo>
</PropertyGroup>

Wenn das Application Insights-Webmodul über die Buildinformationen verfügt, fügt es jedem Telemetrieelement automatisch die Anwendungsversion als Eigenschaft hinzu. Aus diesem Grund können Sie nach der Version filtern, wenn Sie Diagnosesuchen durchführen oder Metriken untersuchen.

Die Microsoft-Build-Engine generiert exklusiv die Buildversionsnummer, nicht den Entwicklerbuild aus Visual Studio.

Versionsanmerkungen

Bei Verwendung von Azure DevOps können Sie Ihren Diagrammen einen Anmerkungsmarker hinzufügen lassen, wenn Sie eine neue Version veröffentlichen.

Häufig gestellte Fragen

Dieser Abschnitt enthält Antworten auf häufig gestellte Fragen.

Wie kann ich eine Application Insights-Ressource in eine neue Region verschieben?

Das Übertragen vorhandener Application Insights-Ressourcen zwischen Regionen wird nicht unterstützt, und Sie können historische Daten nicht zu einer neuen Region migrieren. Die Problemumgehung umfasst Folgendes:

  • Erstellen einer neuen arbeitsbereichsbasierten Application Insights-Ressource in der gewünschten Region
  • Neuerstellen aller eindeutigen Anpassungen der ursprünglichen Ressource in der neuen Ressource
  • Aktualisieren Ihrer Anwendung mit der Verbindungszeichenfolge der Ressource in der neuen Region
  • Testen mit der neuen Application Insights-Ressource, um die erwartungsgemäße Funktionsweise sicherzustellen
  • Festlegen, ob die ursprüngliche Application Insights-Ressource beibehalten oder gelöscht werden soll. Beim Löschen einer klassischen Ressource gehen alle historischen Daten verloren. Wenn die Ressource arbeitsbereichsbasiert ist, verbleiben die Daten in Log Analytics, sodass der Zugriff auf historische Daten bis zum Ablauf des Aufbewahrungszeitraums möglich ist.

Eindeutige Anpassungen, die für die Ressource in der neuen Region normalerweise manuell neu erstellt oder aktualisiert werden müssen, umfassen beispielsweise Folgendes:

  • Neuerstellen von benutzerdefinierten Dashboards und Arbeitsmappen.
  • Neuerstellen oder Aktualisieren des Umfangs von benutzerdefinierten Protokoll-/Metrikwarnungen.
  • Neuerstellen von Verfügbarkeitswarnungen.
  • Neuerstellen aller benutzerdefinierten Einstellungen für die rollenbasierte Zugriffssteuerung in Azure, die Ihre Benutzer für den Zugriff auf die neue Ressource benötigen.
  • Replizieren der Einstellungen, bei denen es um die Aktivierung für die Erfassungs-Stichprobenerstellung, Datenaufbewahrung, tägliche Obergrenze und benutzerdefinierten Metriken geht Diese Einstellungen werden über den Bereich Nutzungs- und geschätzte Kosten gesteuert.
  • Jede Integration, die auf API-Schlüsseln basiert, z. B. Versionsanmerkungen, und Livemetriken, schützen Sie den Steuerungskanal. Sie müssen neue API-Schlüssel generieren und die zugeordnete Integration aktualisieren.
  • Der fortlaufende Export in klassische Ressourcen muss erneut konfiguriert werden.
  • Diagnoseeinstellungen in arbeitsbereichsbasierten Ressourcen müssen erneut konfiguriert werden.

Hinweis

Falls durch die Ressource, die Sie in einer neuen Region erstellen, eine klassische Ressource ersetzt wird, empfehlen wir Ihnen, sich über die Vorteile der Erstellung einer neuen arbeitsbereichsbasierten Ressource zu informieren. Alternativ migrieren Sie Ihre vorhandene Ressource zu einer arbeitsbereichsbasierten Ressource.

Kann ich „providers('Microsoft.Insights', 'components').apiVersions[0]“ in meinen Azure Resource Manager-Bereitstellungen verwenden?

Es wird davon abgeraten, diese Methode zum Auffüllen der API-Version zu verwenden. Die neueste Version kann Vorschaureleases darstellen, die Breaking Changes enthalten können. Auch bei neueren Releases, die keine Vorschauversion darstellen, sind die API-Versionen nicht immer abwärtskompatibel mit vorhandenen Vorlagen. In einigen Fällen ist die API-Version möglicherweise nicht für alle Abonnements verfügbar.

Nächste Schritte