Freigeben über

Vorgehensweise: Verbinden verschiedener Datenquellen

  • Artikel

Wichtig

Ab dem 20. September 2023 können Sie keine neuen Metrics Advisor-Ressourcen mehr erstellen. Der Metrics Advisor-Dienst wird am 1. Oktober 2026 eingestellt.

Wichtig

Microsoft empfiehlt, immer den sichersten Authentifizierungsflow zu verwenden. Einige der in diesem Artikel beschriebenen Authentifizierungsflows erfordern ein sehr hohes Vertrauen in die Anwendung und bergen Risiken, die in anderen sichereren Flows nicht vorhanden sind. Sie sollten diesen Flow nur verwenden, wenn andere sicherere Flows (z. B. verwaltete Identitäten) nicht anwendbar sind.

Verwenden Sie diesen Artikel, um die Einstellungen und Anforderungen zum Herstellen einer Verbindung von verschiedenen Arten von Datenquellen mit Azure KI Metrics Advisor zu ermitteln. Informationen zur Verwendung von Daten mit Metrics Advisor finden Sie unter Onboarding von Daten.

Unterstützte Authentifizierungstypen

Authentifizierungstypen BESCHREIBUNG
Grundlegend Sie müssen grundlegende Parameter für den Zugriff auf Datenquellen bereitstellen. Beispielsweise können Sie eine Verbindungszeichenfolge oder ein Kennwort verwenden. Datenfeedadministratoren können diese Anmeldeinformationen anzeigen.
Verwaltete Azure-Identität Verwaltete Identitäten für Azure-Ressourcen sind ein Feature von Microsoft Entra ID. Damit wird in Microsoft Entra ID eine automatisch verwaltete Identität für Azure-Dienste bereitgestellt. Sie können die Identität für die Authentifizierung bei jedem Dienst verwenden, der die Microsoft Entra-Authentifizierung unterstützt.
Azure SQL-Verbindungszeichenfolge Speichern Sie die Azure SQL-Verbindungszeichenfolge als Anmeldeinformationsentität in Metrics Advisor, und verwenden Sie sie beim Importieren von Metrikdaten jedes Mal direkt. Nur Administratoren der Anmeldeinformationsentität können diese Anmeldeinformationen anzeigen, aber autorisierte anzeigende Benutzer können Datenfeeds erstellen, ohne dass sie die Details der Anmeldeinformationen kennen müssen.
Gemeinsam genutzter Schlüssel für Azure Data Lake Storage Gen2 Speichern Sie den Data Lake-Kontoschlüssel als Anmeldeinformationsentität in Metrics Advisor, und verwenden Sie sie direkt bei jedem Importieren von Metrikdaten. Nur Administratoren der Anmeldeinformationsentität können diese Anmeldeinformationen anzeigen, aber autorisierte anzeigende Benutzer können Datenfeeds erstellen, ohne dass sie die Details der Anmeldeinformationen kennen müssen.
Dienstprinzipal Speichern Sie den Dienstprinzipal als Anmeldeinformationsentität in Metrics Advisor, und verwenden Sie sie beim Importieren von Metrikdaten jedes Mal direkt. Nur Administratoren der Anmeldeinformationsentität können diese Anmeldeinformationen anzeigen, aber autorisierte anzeigende Benutzer können Datenfeeds erstellen, ohne dass sie die Details der Anmeldeinformationen kennen müssen.
Dienstprinzipal vom Schlüsseltresor Speichern Sie den Dienstprinzipal als Anmeldeinformationsentität in einem Schlüsseltresor in Metrics Advisor, und verwenden Sie sie beim Importieren von Metrikdaten jedes Mal direkt. Nur Administratoren der Anmeldeinformationsentität können diese Anmeldeinformationen anzeigen, aber anzeigende Benutzer können Datenfeeds erstellen, ohne dass sie die Details der Anmeldeinformationen kennen müssen.

Datenquellen und zugehörige Authentifizierungstypen

Datenquellen Authentifizierungstypen
Application Insights Basic
Azure Blob Storage (JSON) Basic
Verwaltete Identität
Azure Cosmos DB (SQL) Basic
Azure Data Explorer (Kusto) Basic
Verwaltete Identität
Dienstprinzipal
Dienstprinzipal vom Schlüsseltresor
Azure Data Lake Storage Gen2 Basic
Gemeinsam genutzter Schlüssel für Data Lake Storage Gen2
Dienstprinzipal
Dienstprinzipal vom Schlüsseltresor
Azure Event Hubs Basic
Azure Monitor-Protokolle Basic
Dienstprinzipal
Dienstprinzipal vom Schlüsseltresor
Azure SQL-Datenbank/SQL Server Basic
Verwaltete Identität
Dienstprinzipal
Dienstprinzipal vom Schlüsseltresor
Azure SQL-Verbindungszeichenfolge
Azure Table Storage Basic
InfluxDB (InfluxQL) Basic
MongoDB Basic
MySQL Basic
PostgreSQL Basic

In den folgenden Abschnitten werden die Parameter angegeben, die für alle Authentifizierungstypen in verschiedenen Datenquellenszenarios erforderlich sind.

Application Insights

  • Anwendungs-ID: Diese wird dazu verwendet, die betreffende Anwendung zu identifizieren, wenn die Application Insights-API verwendet wird. Führen Sie die folgenden Schritte aus, um die Anwendungs-ID abzurufen:

    1. Wählen Sie in Ihrer Application Insights-Ressource die Option API-Zugriff aus.

      Screenshot: Abrufen der Anwendungs-ID aus der Application Insights-Ressource

    2. Kopieren Sie die generierte Anwendungs-ID in Metrics Advisor in das Feld Anwendungs-ID.

  • API-Schlüssel: API-Schlüssel werden von Anwendungen außerhalb des Browsers für den Zugriff auf diese Ressource verwendet. Führen Sie zum Abrufen des API-Schlüssels die folgenden Schritte aus:

    1. Wählen Sie in der Application Insights-Ressource die Option API-Zugriff aus.

    2. Wählen Sie API-Schlüssel erstellen aus.

    3. Geben Sie eine kurze Beschreibung ein, wählen Sie die Option Telemetrie lesen und dann die Option Schlüssel generieren aus.

      Screenshot: Abrufen des API-Schlüssels im Azure-Portal

      Wichtig

      Kopieren und speichern Sie diesen API-Schlüssel. Der Schlüssel wird nicht erneut angezeigt. Wenn Sie diesen Schlüssel verlieren, müssen Sie einen neuen erstellen.

    4. Kopieren Sie den API-Schlüssel in das Feld API-Schlüssel in Metrics Advisor.

  • Abfrage: Application Insights-Protokolle basieren auf Azure Data Explorer, und Azure Monitor-Protokollabfragen verwenden eine Version derselben Kusto-Abfragesprache. Die Dokumentation zur Kusto-Abfragesprache ist die wichtigste Ressource zum Schreiben einer Abfrage für Application Insights.

    Beispielabfrage:

    [TableName] | where [TimestampColumn] >= datetime(@IntervalStart) and [TimestampColumn] < datetime(@IntervalEnd);

    Unter Tutorial: Schreiben einer gültigen Abfrage finden Sie konkretere Beispiele.

Azure Blob Storage (JSON)

  • Verbindungszeichenfolge: Es gibt zwei Authentifizierungstypen für Azure Blob Storage (JSON):

    • Basic: Informationen zum Abrufen dieser Zeichenfolge finden Sie unter Konfigurieren von Azure Storage-Verbindungszeichenfolgen. Sie können auch das Azure-Portal für Ihre Azure Blob Storage-Ressource besuchen und die Verbindungszeichenfolge direkt in Einstellungen>Zugriffsschlüssel ermitteln.

    • Verwaltete Identität: Verwaltete Identitäten für Azure-Ressourcen können den Zugriff auf Blob- und Warteschlangendaten autorisieren. Für das Feature werden Microsoft Entra-Anmeldeinformationen aus Anwendungen verwendet, die auf Azure-VMs ausgeführt werden, sowie aus Funktions-Apps, VM-Skalierungsgruppen und anderen Diensten.

      Sie können eine verwaltete Identität im Azure-Portal für Ihre Azure Blob Storage-Ressource erstellen. Wählen Sie unter Zugriffssteuerung (IAM) die Option Rollenzuweisungen und dann Hinzufügen aus. Ein empfohlener Rollentyp ist Storage-Blobdatenleser. Weitere Informationen finden Sie unter Verwenden der verwalteten Identität für den Zugriff auf Azure Storage.

      Screenshot: Blob einer verwalteten Identität

  • Container: Metrics Advisor erwartet, dass Zeitreihendaten als Blobdateien (ein Blob pro Zeitstempel) unter einem einzelnen Container gespeichert sind. Dies ist das Feld für den Containernamen.

  • Blobvorlage: Metrics Advisor verwendet einen Pfad, um die JSON-Datei in Blob Storage zu suchen. Dies ist ein Beispiel für eine Blobdateivorlage, die dazu verwendet wird, die JSON-Datei in Blob Storage zu finden: %Y/%m/FileName_%Y-%m-%d-%h-%M.json. %Y/%m ist der Pfad, und wenn Sie %d im Pfad haben, können Sie ihn nach %m hinzufügen. Wenn die JSON-Datei nach Datum benannt wird, können Sie auch %Y-%m-%d-%h-%M.json verwenden.

    Die folgenden Parameter werden unterstützt:

    • %Y ist das Jahr, formatiert als yyyy.
    • %m ist der Monat, formatiert als MM.
    • %d ist der Tag, formatiert als dd.
    • %h ist die Stunde, formatiert als HH.
    • %M ist die Minute, formatiert als mm.

    Im folgenden Dataset sollte die Blobvorlage beispielsweise %Y/%m/%d/00/JsonFormatV2.json sein.

    Screenshot: Blobvorlage

  • JSON-Formatversion: Definiert das Datenschema in den JSON-Dateien. Metrics Advisor unterstützt die folgenden Versionen. Sie können eine auswählen, um das Feld auszufüllen:

    • v1

      Nur die Metriken Name und Wert werden akzeptiert. Zum Beispiel:

      {"count":11, "revenue":1.23}

    • v2

      Die Metriken Dimensionen und Zeitstempel werden ebenfalls akzeptiert. Zum Beispiel:

      [
  {"date": "2018-01-01T00:00:00Z", "market":"en-us", "count":11, "revenue":1.23},
  {"date": "2018-01-01T00:00:00Z", "market":"zh-cn", "count":22, "revenue":4.56}
]

    Pro JSON-Datei ist nur ein Zeitstempel zulässig.

Azure Cosmos DB (SQL)

  • Verbindungszeichenfolge: Die Verbindungszeichenfolge für den Zugriff auf Ihre Azure Cosmos DB-Instanz. Diese finden Sie in der Azure Cosmos DB-Ressource im Azure-Portal unter Schlüssel. Weitere Informationen finden Sie unter Sicherer Zugriff auf Daten in Azure Cosmos DB.

  • Datenbank: Die Datenbank, die abgefragt werden soll Navigieren Sie im Azure-Portal unter Container zu Durchsuchen, um die Datenbank zu suchen.

  • Sammlungs-ID: Die Sammlungs-ID, die abgefragt werden soll. Navigieren Sie im Azure-Portal unter Container zu Durchsuchen, um die Sammlungs-ID zu suchen.

  • SQL-Abfrage: Eine SQL-Abfrage zum Abrufen und Formulieren von Daten in mehrdimensionalen Zeitreihendaten. Verwenden Sie die Variablen @IntervalStart und @IntervalEnd in der Abfrage. Sie müssen wie folgt formatiert werden: yyyy-MM-ddTHH:mm:ssZ.

    Beispielabfrage:

    SELECT [TimestampColumn], [DimensionColumn], [MetricColumn] FROM [TableName] WHERE [TimestampColumn] >= @IntervalStart and [TimestampColumn] < @IntervalEnd

    Weitere Informationen finden Sie im Tutorial zum Schreiben einer gültigen Abfrage.

Azure Data Explorer (Kusto)

  • Verbindungszeichenfolge: Es gibt vier Authentifizierungstypen für Azure Data Explorer (Kusto): Basic, Dienstprinzipal, Dienstprinzipal aus Key Vault und verwaltete Identität. Die Datenquelle in der Verbindungszeichenfolge muss das URI-Format aufweisen (beginnt mit „https“). Sie können den URI im Azure-Portal finden.

    • Basic: Metrics Advisor unterstützt den Zugriff auf Azure Data Explorer (Kusto) über die Microsoft Entra-Anwendungsauthentifizierung. Sie müssen eine Microsoft Entra-Anwendung erstellen und registrieren und diese anschließend für den Zugriff auf eine Azure Data Explorer-Datenbank autorisieren. Weitere Informationen finden Sie unter Erstellen einer Microsoft Entra-App-Registrierung in Azure Data Explorer. Hier ist ein Beispiel für eine Verbindungszeichenfolge:

      Data Source=<URI Server>;Initial Catalog=<Database>;AAD Federated Security=True;Application Client ID=<Application Client ID>;Application Key=<Application Key>;Authority ID=<Tenant ID>

    • Dienstprinzipal: Ein Dienstprinzipal ist eine konkrete Instanz, die aus dem Anwendungsobjekt erstellt wurde. Der Dienstprinzipal erbt bestimmte Eigenschaften von diesem Anwendungsobjekt. Das Dienstprinzipalobjekt definiert, was die App tatsächlich im jeweiligen Mandanten ausführen kann, wer auf die App zugreifen kann und auf welche Ressourcen die App zugreifen kann. Einen Dienstprinzipal verwenden Sie in Metrics Advisor wie folgt:

      1. Erstellen Sie die Microsoft Entra-Anwendungsregistrierung. Weitere Informationen finden Sie unter Erstellen einer Microsoft Entra-App-Registrierung in Azure Data Explorer.

      2. Verwalten Sie die Berechtigungen für Datenbanken in Azure-Daten-Explorer. Weitere Informationen finden Sie unter Verwalten der Berechtigungen für Datenbanken in Azure Data Explorer.

      3. Erstellen Sie eine Entität mit Anmeldeinformationen in Metrics Advisor. Hier erfahren Sie, wie Sie eine Entität mit Anmeldeinformationen in Metrics Advisor erstellen, damit Sie diese Entität auswählen können, wenn Sie einen Datenfeed für den Dienstprinzipal-Authentifizierungstyp hinzufügen.

      Hier ist ein Beispiel für eine Verbindungszeichenfolge:

      Data Source=<URI Server>;Initial Catalog=<Database>

    • Dienstprinzipal aus Key Vault: Azure Key Vault hilft beim Schützen von kryptografischen Schlüsseln und Geheimniswerten, die von Cloudanwendungen und -diensten verwendet werden. Mit Key Vault können Sie Schlüssel und Geheimniswerte verschlüsseln. Sie müssen zuerst einen Dienstprinzipal erstellen und den Dienstprinzipal dann in Key Vault speichern. Weitere Informationen finden Sie unter Erstellen einer Anmeldeinformationsentität für einen Dienstprinzipal aus Key Vault. Führen Sie die ausführlich erläuterten Verfahrensschritte durch, um den Dienstprinzipal aus Key Vault festzulegen. Hier ist ein Beispiel für eine Verbindungszeichenfolge:

      Data Source=<URI Server>;Initial Catalog=<Database>

    • Verwaltete Identität: Eine verwaltete Identität für Azure-Ressourcen kann den Zugriff auf Blob- und Warteschlangendaten autorisieren. Die verwaltete Identität verwendet Microsoft Entra-Anmeldeinformationen aus Anwendungen, die auf Azure-VMs ausgeführt werden, sowie aus Funktions-Apps, VM-Skalierungsgruppen und anderen Diensten. Durch Verwendung einer verwalteten Identität für Azure-Ressourcen zusammen mit der Microsoft Entra-Authentifizierung können Sie vermeiden, dass Anmeldeinformationen mit den in der Cloud ausgeführten Anwendungen gespeichert werden. Hier erfahren Sie, wie Sie eine Autorisierung mit einer verwalteten Identität durchführen.

      Sie können eine verwaltete Identität im Azure-Portal für Azure Data Explorer (Kusto) erstellen. Klicken Sie auf Berechtigungen>Hinzufügen. Der empfohlene Rollentyp lautet: Administrator/Anzeigender Benutzer.

      Screenshot: verwaltete Identität für Kusto

      Hier ist ein Beispiel für eine Verbindungszeichenfolge:

      Data Source=<URI Server>;Initial Catalog=<Database>

  • Abfrage: Unter Kusto-Abfragesprache finden Sie Informationen zum Abrufen und Formulieren von Daten in mehrdimensionalen Zeitreihendaten. Verwenden Sie die Variablen @IntervalStart und @IntervalEnd in der Abfrage. Sie müssen wie folgt formatiert werden: yyyy-MM-ddTHH:mm:ssZ.

    Beispielabfrage:

    [TableName] | where [TimestampColumn] >= datetime(@IntervalStart) and [TimestampColumn] < datetime(@IntervalEnd);

    Weitere Informationen finden Sie im Tutorial zum Schreiben einer gültigen Abfrage.

Azure Data Lake Storage Gen2

  • Kontoname: Die Authentifizierungstypen für Azure Data Lake Storage Gen2 sind Basic, Gemeinsam verwendeter Azure Data Lake Storage Gen2-Schlüssel, Dienstprinzipal und Dienstprinzipal aus Key Vault.

    • Basic: Der Kontoname Ihres Azure Data Lake Storage Gen2-Kontos. Diesen finden Sie in der Azure Storage-Kontoressource (Azure Data Lake Storage Gen2) unter Zugriffsschlüssel.

    • Gemeinsam verwendeter Azure Data Lake Storage Gen2-Schlüssel: Geben Sie zunächst den Kontoschlüssel für den Zugriff auf Azure Data Lake Storage Gen2 an (dies entspricht dem Kontoschlüssel im Authentifizierungstyp „Basic“. Diesen finden Sie in der Azure Storage-Kontoressource (Azure Data Lake Storage Gen2) unter Zugriffsschlüssel. Anschließend erstellen Sie eine Anmeldeinformationsentität für den Typ eines gemeinsam verwendeten Azure Data Lake Storage Gen2-Schlüssels und geben den Kontoschlüssel ein.

      Der Kontoname entspricht dem Authentifizierungstyp „Basic“.

    • Dienstprinzipal: Ein Dienstprinzipal ist eine konkrete Instanz, die aus dem Anwendungsobjekt erstellt wird und bestimmte Eigenschaften von diesem Anwendungsobjekt erbt. Ein Dienstprinzipal wird in jedem Mandanten erstellt, in dem die Anwendung verwendet wird, und verweist auf das global eindeutige Anwendungsobjekt. Das Dienstprinzipalobjekt definiert, was die App tatsächlich im jeweiligen Mandanten ausführen kann, wer auf die App zugreifen kann und auf welche Ressourcen die App zugreifen kann.

      Der Kontoname entspricht dem Authentifizierungstyp „Basic“.

      Schritt 1: Erstellen und registrieren Sie eine Microsoft Entra-Anwendung, und autorisieren Sie diese dann für den Zugriff auf die Datenbank. Weitere Informationen finden Sie unter Erstellen einer Microsoft Entra-App-Registrierung.

      Schritt 2: Weisen Sie Rollen zu.

      1. Navigieren Sie im Azure-Portal zum Speicherkonten-Dienst.

      2. Wählen Sie das Azure Data Lake Storage Gen2-Konto für diese Anwendungsregistrierung aus.

      3. Wählen Sie Access Control (IAM) aus.

      4. Wählen Sie + Hinzufügen und dann im Menü die Option Rollenzuweisung hinzufügen aus.

      5. Legen Sie das Feld Auswählen auf den Namen der Microsoft Entra-Anwendung und die Rolle auf Mitwirkender an Storage-Blobdaten fest. Klicken Sie dann auf Speichern.

      Screenshot: Schritte zum Zuweisen von Rollen

      Schritt 3: Erstellen Sie eine Anmeldeinformationsentität in Metrics Advisor, damit Sie diese Entität auswählen können, wenn Sie einen Datenfeed für den Dienstprinzipal-Authentifizierungstyp hinzufügen.

    • Dienstprinzipal aus Key Vault: Key Vault hilft, kryptografische Schlüssel und Geheimniswerte zu schützen, die von Cloudanwendungen und -diensten verwendet werden. Mit Key Vault können Sie Schlüssel und Geheimniswerte verschlüsseln. Erstellen Sie zuerst einen Dienstprinzipal, und speichern Sie den Dienstprinzipal dann in einem Schlüsseltresor. Weitere Informationen finden Sie unter Erstellen einer Anmeldeinformationsentität für den Dienstprinzipal aus Key Vault. Der Kontoname entspricht dem Authentifizierungstyp „Basic“.

  • Kontoschlüssel (nur für den Authentifizierungstyp „Basic“ erforderlich): Geben Sie den Kontoschlüssel für den Zugriff auf Azure Data Lake Storage Gen2 an. Diesen finden Sie in der Azure Storage-Kontoressource (Azure Data Lake Storage Gen2) unter Zugriffsschlüssel.

  • Dateisystemname (Container) : Für Metrics Advisor speichern Sie Zeitreihendaten als Blobdateien (ein Blob pro Zeitstempel) unter einem einzelnen Container. Dies ist das Feld für den Containernamen. Sie finden es in der Azure Storage-Kontoinstanz (Azure Data Lake Storage Gen2). Wählen Sie in Data Lake Storage die Option Container aus. Dann wird der Name des Containers angezeigt.

  • Verzeichnisvorlage: Dies ist die Verzeichnisvorlage der Blobdatei. Die folgenden Parameter werden unterstützt:

    • %Y ist das Jahr, formatiert als yyyy.
    • %m ist der Monat, formatiert als MM.
    • %d ist der Tag, formatiert als dd.
    • %h ist die Stunde, formatiert als HH.
    • %M ist die Minute, formatiert als mm.

    Abfragebeispiel für eine tägliche Metrik: %Y/%m/%d.

    Abfragebeispiel für eine stündliche Metrik: %Y/%m/%d/%h.

  • Dateivorlage: Von Metrics Advisor wird ein Pfad dazu verwendet, in Blob Storage nach der JSON-Datei zu suchen. Im Folgenden finden Sie ein Beispiel für eine Blobdateivorlage, die dazu verwendet wird, in Blob Storage nach der JSON-Datei zu suchen: %Y/%m/FileName_%Y-%m-%d-%h-%M.json. %Y/%m ist der Pfad, und wenn Sie %d im Pfad haben, können Sie ihn nach %m hinzufügen.

    Die folgenden Parameter werden unterstützt:

    • %Y ist das Jahr, formatiert als yyyy.
    • %m ist der Monat, formatiert als MM.
    • %d ist der Tag, formatiert als dd.
    • %h ist die Stunde, formatiert als HH.
    • %M ist die Minute, formatiert als mm.

    Metrics Advisor unterstützt das Datenschema in den JSON-Dateien wie im folgenden Beispiel:

    [
   {"date": "2018-01-01T00:00:00Z", "market":"en-us", "count":11, "revenue":1.23},
   {"date": "2018-01-01T00:00:00Z", "market":"zh-cn", "count":22, "revenue":4.56}
]

Azure Event Hubs

  • Einschränkungen: Beachten Sie die folgenden Einschränkungen bei der Integration.

    • Die Metrics Advisor-Integration mit Event Hubs unterstützt derzeit nicht mehr als drei aktive Datenfeeds in einer einzigen Metrics Advisor-Instanz in der Public Preview.

    • Metrics Advisor beginnt immer mit der Verarbeitung von Nachrichten aus dem letzten Offset, einschließlich der Reaktivierung eines angehaltenen Datenfeeds.

      • Nachrichten während der Pausenphase des Datenfeeds gehen verloren.
      • Die Startzeit der Datenerfassung für den Datenfeed wird automatisch auf den aktuellen Zeitstempel nach koordinierter Weltzeit festgelegt, wenn der Datenfeed erstellt wird. Diese Zeit dient nur zu Referenzzwecken.

    • Pro Consumergruppe kann nur ein einziger Datenfeed verwendet werden. Zum Wiederverwenden einer Consumergruppe aus einem anderen gelöschten Datenfeed müssen Sie nach dem Löschen mindestens zehn Minuten warten.

    • Die Verbindungszeichenfolge und die Consumergruppe können nach dem Erstellen des Datenfeeds nicht mehr geändert werden.

    • Für Event Hubs-Nachrichten wird nur JSON unterstützt, und die JSON-Werte können kein geschachteltes JSON-Objekt sein. Das Element der obersten Ebene kann ein JSON-Objekt oder ein JSON-Array sein.

      Die folgenden Nachrichten sind gültig:

      Einzelnes JSON-Objekt:

      {
"metric_1": 234, 
"metric_2": 344, 
"dimension_1": "name_1", 
"dimension_2": "name_2"
}

      JSON-Array:

      [
    {
        "timestamp": "2020-12-12T12:00:00", "temperature": 12.4,
        "location": "outdoor"
    },
    {
        "timestamp": "2020-12-12T12:00:00", "temperature": 24.8,
        "location": "indoor"
    }
]

  • Verbindungszeichenfolge: Wechseln Sie zur Instanz Event Hubs. Fügen Sie dann eine neue Richtlinie hinzu, oder wählen Sie eine vorhandene SAS-Richtlinie (Richtlinie für den gemeinsamen Zugriff) aus. Kopieren Sie die Verbindungszeichenfolge im Popupbereich. Screenshot: Event Hubs

    Screenshot: SAS-Richtlinien

    Hier ist ein Beispiel für eine Verbindungszeichenfolge:

    Endpoint=<Server>;SharedAccessKeyName=<SharedAccessKeyName>;SharedAccessKey=<SharedAccess Key>;EntityPath=<EntityPath>

  • Consumergruppe: Eine Consumergruppe ist eine Ansicht (Status, Position oder Offset) eines gesamten Event Hubs. Sie finden sie im Menü Consumergruppen einer Instanz von Azure Event Hubs. Eine Consumergruppe kann nur einen einzigen Datenfeed verarbeiten. Erstellen Sie für jeden Datenfeed eine neue Consumergruppe.

  • Zeitstempel (optional): Metrics Advisor verwendet den Event Hubs-Zeitstempel als Ereigniszeitstempel, wenn die Benutzerdatenquelle kein Zeitstempelfeld enthält. Das Zeitstempelfeld ist optional. Wenn keine Zeitstempelspalte ausgewählt wird, verwendet der Dienst den Zeitpunkt der Einreihung in die Warteschlange als Zeitstempel.

    Das Zeitstempelfeld muss mit einem der beiden folgenden Formate übereinstimmen:

    • YYYY-MM-DDTHH:MM:SSZ
    • Die Anzahl von Sekunden oder Millisekunden ab der Epoche von 1970-01-01T00:00:00Z.

    Der Zeitstempel wird links an der Granularität ausgerichtet. Wenn der Zeitstempel beispielsweise 2019-01-01T00:03:00Z lautet, beträgt die Granularität 5 Minuten, und Metrics Advisor richtet den Zeitstempel an 2019-01-01T00:00:00Z aus. Wenn der Ereigniszeitstempel 2019-01-01T00:10:00Z ist, wird der Zeitstempel von Metrics Advisor direkt ohne Ausrichtung verwendet.

Azure Monitor-Protokolle

Azure Monitor-Protokolle weisen die folgenden Authentifizierungstypen auf: Basic, Dienstprinzipal und Dienstprinzipal aus Key Vault.

  • Basic: Sie müssen die Werte für Mandanten-ID, Client-ID, Geheimer Clientschlüssel und Arbeitsbereichs-ID ausfüllen. Informationen zum Abrufen von Mandanten-ID, Client-ID und Geheimer Clientschlüssel finden Sie unter Registrieren von Anwendung oder Web-API. Die Arbeitsbereichs-ID finden Sie im Azure-Portal.

    Screenshot: Ort der Arbeitsbereichs-ID im Azure-Portal

  • Dienstprinzipal: Ein Dienstprinzipal ist eine konkrete Instanz, die aus dem Anwendungsobjekt erstellt wird und bestimmte Eigenschaften von diesem Anwendungsobjekt erbt. Ein Dienstprinzipal wird in jedem Mandanten erstellt, in dem die Anwendung verwendet wird, und verweist auf das global eindeutige Anwendungsobjekt. Das Dienstprinzipalobjekt definiert, was die App tatsächlich im jeweiligen Mandanten ausführen kann, wer auf die App zugreifen kann und auf welche Ressourcen die App zugreifen kann.

    Schritt 1: Erstellen und registrieren Sie eine Microsoft Entra-Anwendung, und autorisieren Sie diese dann für den Zugriff auf eine Datenbank. Weitere Informationen finden Sie unter Erstellen einer Microsoft Entra-App-Registrierung.

    Schritt 2: Weisen Sie Rollen zu.

    1. Navigieren Sie im Azure-Portal zum Speicherkonten-Dienst.

    2. Wählen Sie Access Control (IAM) aus.

    3. Wählen Sie + Hinzufügen und dann im Menü die Option Rollenzuweisung hinzufügen aus.

    4. Legen Sie das Feld Auswählen auf den Namen der Microsoft Entra-Anwendung und die Rolle auf Mitwirkender an Storage-Blobdaten fest. Klicken Sie dann auf Speichern.

      Screenshot: Zuweisen von Rollen

    Schritt 3: Erstellen Sie eine Anmeldeinformationsentität in Metrics Advisor, damit Sie diese Entität auswählen können, wenn Sie einen Datenfeed für den Dienstprinzipal-Authentifizierungstyp hinzufügen.

  • Dienstprinzipal aus Key Vault: Key Vault hilft, kryptografische Schlüssel und Geheimniswerte zu schützen, die von Cloudanwendungen und -diensten verwendet werden. Mit Key Vault können Sie Schlüssel und Geheimniswerte verschlüsseln. Erstellen Sie zuerst einen Dienstprinzipal, und speichern Sie den Dienstprinzipal dann in einem Schlüsseltresor. Weitere Informationen finden Sie unter Erstellen einer Anmeldeinformationsentität für den Dienstprinzipal aus Key Vault.

  • Abfrage: Legen Sie die Abfrage fest. Weitere Informationen finden Sie unter Protokollabfragen in Azure Monitor.

    Beispielabfrage:

    [TableName]
| where [TimestampColumn] >= datetime(@IntervalStart) and [TimestampColumn] < datetime(@IntervalEnd)
| summarize [count_per_dimension]=count() by [Dimension]

    Weitere Informationen finden Sie im Tutorial zum Schreiben einer gültigen Abfrage.

Azure SQL-Datenbank | SQL Server

  • Verbindungszeichenfolge: Die Authentifizierungstypen für Azure SQL-Datenbank und SQL Server sind Basic, verwaltete Identität, Azure SQL-Verbindungszeichenfolge, Dienstprinzipal und Dienstprinzipal aus Key Vault.

    • Basic: Metrics Advisor akzeptiert eine Verbindungszeichenfolge im ADO.NET-Stil für eine SQL Server-Datenquelle. Hier ist ein Beispiel für eine Verbindungszeichenfolge:

      Data Source=<Server>;Initial Catalog=<db-name>;User ID=<user-name>;Password=<password>

    • Verwaltete Identität: Eine verwaltete Identität für Azure-Ressourcen kann den Zugriff auf Blob- und Warteschlangendaten autorisieren. Dazu verwendet sie Microsoft Entra-Anmeldeinformationen aus Anwendungen, die auf Azure-VMs ausgeführt werden, sowie aus Funktions-Apps, VM-Skalierungsgruppen und anderen Diensten. Durch Verwendung einer verwalteten Identität für Azure-Ressourcen zusammen mit der Microsoft Entra-Authentifizierung können Sie vermeiden, dass Anmeldeinformationen mit den in der Cloud ausgeführten Anwendungen gespeichert werden. Führen Sie folgende Schritte aus, um Ihre verwaltete Identität zu aktivieren:

    1. Eine systemseitig zugewiesene verwaltete Identität wird mit einem Mausklick aktiviert. Wechseln Sie im Azure-Portal für Ihren Metrics Advisor-Arbeitsbereich zu Einstellungen>Identität>Vom System zugewiesen. Legen Sie den Status auf Ein fest.

      Screenshot: auf „Ein“ festgelegter Status

    2. Aktivieren Sie die Microsoft Entra-Authentifizierung. Wechseln Sie im Azure-Portal für Ihre Datenquelle zu Einstellungen>Active Directory-Administrator. Wählen Sie Administrator festlegen und dann ein Microsoft Entra-Benutzerkonto aus, das als Administrator des Servers festgelegt werden soll. Wählen Sie anschließend Auswählen aus.

      Screenshot: Festlegen des Administrators

    3. Aktivieren Sie die verwaltete Identität in Metrics Advisor. Sie können eine Abfrage im Datenbankverwaltungstool oder im Azure-Portal bearbeiten.

      Verwaltungstool: Wählen Sie im Datenbankverwaltungstool im Authentifizierungsfeld die Option Active Directory: universell mit MFA-Unterstützung aus. Geben Sie im Feld Benutzername den Namen des Microsoft Entra-Kontos ein, das Sie in Schritt 2 als Serveradministrator festgelegt haben. Beispielsweise könnte dies test@contoso.com sein.

      Screenshot: Festlegen von Verbindungsdetails

      Azure-Portal: Wählen Sie in der SQL-Datenbank die Option Abfrage-Editor aus, und melden Sie sich beim Administratorkonto an. Screenshot: Bearbeiten von Abfragen im Azure-Portal

      Führen Sie dann im Abfragefenster Folgendes aus (beachten Sie, dass dies für die Verwaltungstoolmethode identisch ist):

      CREATE USER [MI Name] FROM EXTERNAL PROVIDER
ALTER ROLE db_datareader ADD MEMBER [MI Name]

      Hinweis

      MI Name bezeichnet den Namen der verwalteten Identität in Metrics Advisor (für den Dienstprinzipal muss dieser durch den Dienstprinzipalnamen ersetzt werden). Weitere Informationen finden Sie unter Autorisieren mit einer verwalteten Identität.

      Hier ist ein Beispiel für eine Verbindungszeichenfolge:

      Data Source=<Server>;Initial Catalog=<Database>

    • Azure SQL-Verbindungszeichenfolge:

      Hier ist ein Beispiel für eine Verbindungszeichenfolge:

      Data Source=<Server>;Initial Catalog=<Database>;User ID=<user-name>;Password=<password>

    • Dienstprinzipal: Ein Dienstprinzipal ist eine konkrete Instanz, die aus dem Anwendungsobjekt erstellt wird und bestimmte Eigenschaften von diesem Anwendungsobjekt erbt. Ein Dienstprinzipal wird in jedem Mandanten erstellt, in dem die Anwendung verwendet wird, und verweist auf das global eindeutige Anwendungsobjekt. Das Dienstprinzipalobjekt definiert, was die App tatsächlich im jeweiligen Mandanten ausführen kann, wer auf die App zugreifen kann und auf welche Ressourcen die App zugreifen kann.

      Schritt 1: Erstellen und registrieren Sie eine Microsoft Entra-Anwendung, und autorisieren Sie diese dann für den Zugriff auf eine Datenbank. Weitere Informationen finden Sie unter Erstellen einer Microsoft Entra-App-Registrierung.

      Schritt 2: Führen Sie die zuvor unter Verwaltete Identität in SQL Server dokumentierten Schritte aus.

      Schritt 3: Erstellen Sie eine Anmeldeinformationsentität in Metrics Advisor, damit Sie diese Entität auswählen können, wenn Sie einen Datenfeed für den Dienstprinzipal-Authentifizierungstyp hinzufügen.

      Hier ist ein Beispiel für eine Verbindungszeichenfolge:

      Data Source=<Server>;Initial Catalog=<Database>

    • Dienstprinzipal aus Key Vault: Key Vault hilft, kryptografische Schlüssel und Geheimniswerte zu schützen, die von Cloudanwendungen und -diensten verwendet werden. Mit Key Vault können Sie Schlüssel und Geheimniswerte verschlüsseln. Erstellen Sie zuerst einen Dienstprinzipal, und speichern Sie den Dienstprinzipal dann in einem Schlüsseltresor. Weitere Informationen finden Sie unter Erstellen einer Anmeldeinformationsentität für den Dienstprinzipal aus Key Vault. Sie finden die Verbindungszeichenfolge auch in Ihrer Azure SQL Server-Ressource unter Einstellungen>Verbindungszeichenfolgen.

      Hier ist ein Beispiel für eine Verbindungszeichenfolge:

      Data Source=<Server>;Initial Catalog=<Database>

  • Abfrage: Verwenden Sie eine SQL-Abfrage zum Abrufen und Formulieren von Daten in mehrdimensionalen Zeitreihendaten. Sie können in der Abfrage @IntervalStart und @IntervalEnd verwenden, um einen erwarteten Metrikwert in einem Intervall abzurufen. Sie müssen wie folgt formatiert werden: yyyy-MM-ddTHH:mm:ssZ.

    Beispielabfrage:

    SELECT [TimestampColumn], [DimensionColumn], [MetricColumn] FROM [TableName] WHERE [TimestampColumn] >= @IntervalStart and [TimestampColumn] < @IntervalEnd

Azure Table Storage

  • Verbindungszeichenfolge: Erstellen Sie eine SAS-URL (Shared Access Signature), und geben Sie diese hier ein. Die einfachste Möglichkeit, eine SAS-URL zu generieren, ist die Verwendung des Azure-Portals. Navigieren Sie unter Einstellungen zu dem Speicherkonto, auf das Sie zugreifen möchten. Wählen Sie dann Shared Access Signature aus. Aktivieren Sie die Kontrollkästchen Tabelle und Objekt, und wählen Sie dann SAS und Verbindungszeichenfolge generieren aus. Kopieren Sie im Metrics Advisor-Arbeitsbereich die SAS-URL für Tabellendienst, und fügen Sie diese in das Textfeld ein.

    Screenshot: Generieren der Shared Access Signature in Azure Table Storage

  • Tabellenname: Geben Sie eine Tabelle an, die abgefragt werden soll. Sie finden diese in Ihrer Azure Storage-Kontoinstanz. Klicken Sie im Abschnitt Tabellendienst auf Tabellen.

  • Abfrage: Sie können in der Abfrage @IntervalStart und @IntervalEnd verwenden, um einen erwarteten Metrikwert in einem Intervall abzurufen. Sie müssen wie folgt formatiert werden: yyyy-MM-ddTHH:mm:ssZ.

    Beispielabfrage:

    PartitionKey ge '@IntervalStart' and PartitionKey lt '@IntervalEnd'

    Weitere Informationen finden Sie im Tutorial zum Schreiben einer gültigen Abfrage.

InfluxDB (InfluxQL)

  • Verbindungszeichenfolge: Die Verbindungszeichenfolge für den Zugriff auf InfluxDB.

  • Datenbank: Die Datenbank, die abgefragt werden soll

  • Query (Abfrage): Eine Abfrage zum Abrufen und Formulieren von Daten in mehrdimensionalen Zeitreihendaten für die Erfassung

    Beispielabfrage:

    SELECT [TimestampColumn], [DimensionColumn], [MetricColumn] FROM [TableName] WHERE [TimestampColumn] >= @IntervalStart and [TimestampColumn] < @IntervalEnd

Weitere Informationen finden Sie im Tutorial zum Schreiben einer gültigen Abfrage.

  • Benutzername: Dies ist für die Authentifizierung optional.
  • Kennwort: Dies ist für die Authentifizierung optional.

MongoDB

  • Verbindungszeichenfolge: Die Verbindungszeichenfolge für den Zugriff auf MongoDB.

  • Datenbank: Die Datenbank, die abgefragt werden soll

  • Abfrage: Ein Befehl zum Abrufen und Formulieren von Daten in mehrdimensionalen Zeitreihendaten für die Erfassung. Überprüfen Sie den Befehl für db.runCommand().

    Beispielabfrage:

    {"find": "[TableName]","filter": { [Timestamp]: { $gte: ISODate(@IntervalStart) , $lt: ISODate(@IntervalEnd) }},"singleBatch": true}

MySQL

  • Verbindungszeichenfolge: Die Verbindungszeichenfolge für den Zugriff auf MySQL DB.

  • Query (Abfrage): Eine Abfrage zum Abrufen und Formulieren von Daten in mehrdimensionalen Zeitreihendaten für die Erfassung

    Beispielabfrage:

    SELECT [TimestampColumn], [DimensionColumn], [MetricColumn] FROM [TableName] WHERE [TimestampColumn] >= @IntervalStart and [TimestampColumn]< @IntervalEnd

    Weitere Informationen finden Sie im Tutorial zum Schreiben einer gültigen Abfrage.

PostgreSQL

  • Verbindungszeichenfolge: Die Verbindungszeichenfolge für den Zugriff auf PostgreSQL DB.

  • Query (Abfrage): Eine Abfrage zum Abrufen und Formulieren von Daten in mehrdimensionalen Zeitreihendaten für die Erfassung

    Beispielabfrage:

    SELECT [TimestampColumn], [DimensionColumn], [MetricColumn] FROM [TableName] WHERE [TimestampColumn] >= @IntervalStart and [TimestampColumn] < @IntervalEnd

    Weitere Informationen finden Sie im Tutorial zum Schreiben einer gültigen Abfrage.

Nächste Schritte