Konfigurieren von Azure Log Analytics für Power BI
Power BI ist in Azure Log Analytics integriert, damit Administratoren und Besitzer von Premium-Arbeitsbereichen eine Log Analytics-Verbindung mit ihrem Power BI-Abonnement konfigurieren können. In diesem Artikel wird beschrieben, wie die Integration zwischen Log Analytics und Power BI funktioniert, und wie sie für Ihre Umgebung konfiguriert wird.
Es gibt zwei Elemente, damit Azure Log Analytics für Power BI verwendet werden kann:
- Konfigurieren Sie Ihr Azure-Abonnement im Azure-Portal.
- Aktivieren Sie Log Analytics für Power BI im Power BI-Verwaltungsportal.
In den folgenden Abschnitten werden jeweils die einzelnen Schritte erläutert.
Voraussetzungen
Bevor Sie die Log Analytics-Integration von Power BI konfigurieren können, müssen Sie einen Log Analytics-Arbeitsbereich im Azure-Portal erstellen. Sie müssen auch die Berechtigung in Azure erteilen, damit der Power BI-Dienst Protokolle schreiben kann. Folgende Schritte müssen ausgeführt werden:
- Mitwirkenderzugriff auf das Azure-Abonnement.
- Registrieren Sie den Ressourcenanbieter „microsoft.insights“ in dem Azure-Abonnement, in dem Sie Power BI-Protokolldaten sammeln werden.
- Der Benutzer, der die Log Analytics-Integration in Power BI einrichtet, muss die Rolle „Log Analytics Mitwirkender“ für den Log Analytics-Arbeitsbereich haben. Unter „Häufig gestellte Fragen“ finden Sie Problemumgehungen, wenn die Rolle „Besitzer“ nicht angegeben werden kann.
Aktivieren des Ressourcenanbieters „microsoft.insights“
Log Analytics erfordert, dass der Ressourcenanbieter „microsoft.insights“ auf Azure-Abonnementebene aktiviert ist. Mit den folgenden Schritten können Sie diese Einstellung vornehmen.
Melden Sie sich beim Azure-Portal an, wählen Sie das Abonnement aus, das Sie mit Log Analytics verwenden möchten, und das Ihre Log Analytics-Arbeitsbereiche enthält. Wählen Sie im Abschnitt EinstellungenRessourcenanbieter aus (siehe folgende Abbildung).
Suchen Sie unter Ressourcenanbieter nach microsoft.insights. Klicken Sie anschließend auf Registrieren.
Festlegen von Berechtigungen
Stellen Sie sicher, dass der Benutzer, der die Log Analytics-Integration konfiguriert, über die Rolle Log Analytics-Mitwirkender des Log Analytics-Arbeitsbereichs verfügt. Wenn Sie im Azure-Portal die Option Zugriffssteuerung (IAM) für das Abonnement und dann Rollenzuweisungen aus der oberen Auswahl im Bereich wählen, muss der aktuelle Benutzer einen Eintrag sehen: Log Analytics Mitwirkender für den Benutzer, der Log Analytics konfiguriert:
Nachdem Sie diese Schritte ausgeführt haben, ist die Konfiguration von Azure Log Analytics abgeschlossen. Im nächsten Abschnitt erfahren Sie, wie Sie die Konfiguration im Power BI-Verwaltungsportal abschließen.
Protokollierung auf Arbeitsbereichsebene über das Verwaltungsportal zulassen
Ein Power BI-Administrator muss den folgenden Schritt ausführen, um Azure Log Analytics für Power BI Premium-Arbeitsbereiche zu aktivieren. Dadurch können Power BI Premium-Arbeitsbereichsadministratoren ihre Arbeitsbereichsprotokolle an Azure Log Analytics senden, wenn die Voraussetzungen erfüllt sind.
Navigieren Sie im Power BI-Verwaltungsportal zu Mandanteneinstellungen > Überwachungs- und Nutzungseinstellungen, und erweitern Sie Azure Log Analytics-Verbindungen für Arbeitsbereichsadministratoren. Wenn Sie Arbeitsbereichsadministrator*innen das Aktivieren von Log Analytics ermöglichen möchten, setzen Sie den Schieberegler auf Aktiviert, und geben Sie die erforderlichen Sicherheitsgruppen unter Anwenden auf an, wie in der folgenden Abbildung dargestellt.
Konfigurieren der Protokollierung in einem Premium-Arbeitsbereich
Im Premium-Arbeitsbereich können Arbeitsbereichsadministratoren Log Analytics aktivieren. Navigieren Sie dazu zu Einstellungen wie in der folgenden Abbildung.
Wählen Sie im Bereich EinstellungenAzure-Verbindungen aus, und erweitern Sie dann wie in der folgenden Abbildung Log Analytics.
Wählen Sie das Azure-Abonnement, die Ressourcengruppe und dann den im vorherigen Abschnitt konfigurierten Log Analytics-Arbeitsbereich aus. Wähle anschließend Speichern aus. Nach erfolgreichem Abschluss sieht der erweiterte Log Analytics-Abschnitt auf Mandantenebene in etwa wie in der folgenden Abbildung aus.
Azure Log Analytics trennen
Sie können die Verbindung mit Azure Log Analytics trennen, um das Senden von Protokollen an Azure zu beenden. Navigieren Sie zum Trennen in den Power BI-Arbeitsbereichseinstellungen zu den Einstellungen für Log Analytics. Klicken Sie auf Verbindung mit Azure trennen. Klicken Sie dann auf Speichern, um die Verbindung zu trennen.
Hinweis
Wenn Sie eine Verbindung eines Power BI-Arbeitsbereichs mit Azure Log Analytics trennen, werden keine Protokolle gelöscht. Ihre Daten bleiben erhalten und folgen den dort festgelegten Speicher- und Aufbewahrungsrichtlinien.
Verwendungsszenarios
Es gibt viele Möglichkeiten, wie Azure Log Analytics und Power BI ihnen dabei helfen können, reale Herausforderungen für Ihre Organisation zu lösen. Beachten Sie Folgendes:
- Identifizieren von Zeiträumen mit hoher oder ungewöhnlicher Aktivität der Analysis Services-Engine nach Kapazität, Arbeitsbereich, Bericht oder Benutzer
- Analysieren der Abfrageleistung und -trends, einschließlich externer DirectQuery-Vorgänge
- Analysieren der Aktualisierungsdauer für Semantikmodelle, Überlappungen und Verarbeitungsschritte
- Analysieren von benutzerdefinierten Vorgängen, die mithilfe des Premium-XMLA-Endpunkts gesendet werden
Geben Sie uns in der Power BI-Community Feedback dazu, wie Sie die Protokollierung verwenden und wie sie Ihrer Organisation hilft.
Fehlerbedingungen und Auflösungen
Die folgende Tabelle enthält eine Auflistung häufiger Fehler, der Ereignisse oder Konfigurationen, die sie ausgelöst haben, und Lösungsvorschläge.
| Auslöserbedingung | Typ | Meldung |
|---|---|---|
| Sie haben keine Schreibberechtigung für den Log Analytics-Arbeitsbereich. | Fehler: Fortsetzen nicht möglich | Sie benötigen Schreibberechtigungen für diesen Log Analytics-Arbeitsbereich, um ihn mit Power BI zu verbinden. Wenden Sie sich an die Person in Ihrer Organisation, die Azure-Abonnements verwaltet, um dieses Problem zu beheben. |
| Sie haben keine Schreibberechtigung für das Log Analytics-Arbeitsbereichskonto. | Fehler: Fortsetzen nicht möglich | Sie benötigen Schreibberechtigungen für diesen Log Analytics-Arbeitsbereich, um ihn mit Power BI zu verbinden. |
| Sie haben keinen Zugriff auf Azure-Abonnements. | Fehler: Fortsetzen nicht möglich | Sie haben keinen Zugriff auf Azure-Abonnements. Bitten Sie die Person, die in Ihrer Organisation Azure-Abonnements verwaltet, Ihnen mindestens die Zugriffsstufe Mitwirkender zu gewähren. |
| Sie haben keinen Zugriff auf Azure Log Analytics-Arbeitsbereiche innerhalb dieses Abonnements. | Fehler: Fortsetzen nicht möglich | Sie haben keinen Zugriff auf einen Azure Log Analytics-Arbeitsbereich. Bitten Sie die Person, die in Ihrer Organisation Azure-Abonnements verwaltet, Sie der Rolle Log Analytics-Besitzer oder -Mitwirkender hinzuzufügen. |
| Log Analytics ist auf Arbeitsbereichsebene beim Herstellen einer Verbindung deaktiviert. | Information | Bitten Sie Ihren Mandantenadministrator, Arbeitsbereichsadministratoren die Berechtigung zur Verbindung von Log Analytics-Arbeitsbereichen zu erteilen. |
| Log Analytics ist auf Arbeitsbereichsebene beim Trennen einer Verbindung deaktiviert. | Information | Ihr Mandantenadministrator hat die Berechtigung für Arbeitsbereichsadministratoren widerrufen, ihre eigenen Azure Log Analytics-Arbeitsbereiche zu verbinden. Wenn Sie die Verbindung trennen, können Sie keine Verbindung mit einem anderen Arbeitsbereich herstellen. |
Ereignisse und Schema
Nachdem Sie Azure Log Analytics aktiviert haben, werden die folgenden Ereigniskategorien protokolliert. Weitere Informationen zu diesen Ereignissen finden Sie unter Analysis Services-Ablaufverfolgungsereignisse.
- AggregateTableRewriteQuery
- Befehl
- Deadlock
- DirectQuery
- Entdecken
- Fehler
- ProgressReport
- Abfrage
- Sitzungsinitialisierung
- VertiPaqSEQuery
- Benachrichtigung
In der folgenden Tabelle wird das Schema beschrieben.
| Eigenschaft | Vorhandene Azure Analysis Services-Eigenschaft | BESCHREIBUNG |
|---|---|---|
| TimeGenerated | Der Zeitstempel (UTC), wann das Protokoll generiert wurde. | |
| OperationName | EventClass_s | Der mit der Protokollaufzeichnung verbundene Vorgang |
| CorrelationId | Die ID für korrelierte Ereignisse. Kann verwendet werden, um korrelierte Ereignisse zwischen verschiedenen Tabellen zu identifizieren. | |
| PowerBIWorkspaceId | Eindeutiger Bezeichner des Arbeitsbereichs, der das Artefakt enthält, das vom Vorgang betroffen ist. | |
| PremiumCapacityId | Eindeutiger Bezeichner der Premiumkapazität, die das Artefakt im Vorgang hostet | |
| ApplicationContext | ApplicationContext_s | Eigenschaftensammlung mit eindeutigen Bezeichnern, die Details zur Anwendung bereitstellen, die die Anforderung ausführt Beispiel: Berichts-ID |
| ApplicationName | ApplicationName_s | Enthält den Namen der Clientanwendung, die die Verbindung mit dem Server hergestellt hat. Diese Spalte wird mit den Werten aufgefüllt, die von der Anwendung übergeben werden, und nicht mit dem angezeigten Namen des Programms. |
| ArtifactId | Eindeutiger Bezeichner der Ressource, die die Daten protokolliert | |
| ArtifactKind | Artefakttyp, der den Vorgang protokolliert, z. B. Semantikmodell. | |
| CpuTimeMs | CPUTime_s | Die CPU-Zeit (in Millisekunden), die vom Ereignis verwendet wurde. |
| ArtifactName | DatabaseName_s | Der Name des Power BI-Artefakts, das diesen Vorgang protokolliert |
| LogAnalyticsCategory | Eindeutig | Kategorie der Ereignisse, z. B. Überwachung/Sicherheit/Anforderung |
| DatasetMode | Der Modus des Semantikmodells. Import, DirectQuery oder Zusammengesetzt | |
| DurationMs | Duration_s | Die für den Vorgang benötigte Zeit (in Millisekunden) |
| Benutzer | User_s | Der Benutzer, der dem ausgeführten Vorgang zugeordnet ist. Wird verwendet, wenn auf dem Server die Identität eines Endbenutzers angenommen werden muss |
| ExecutingUser | EffectiveUsername_s | Der Benutzer, der den Vorgang ausführt. |
| OperationDetailName | EventSubclass_s | Weitere Informationen zum Vorgang |
| XmlaObjectPath | ObjectPath_s | Objektpfad. Eine durch Trennzeichen getrennte Liste von übergeordneten Elementen, die beim übergeordneten Element des Objekts beginnt. |
| PowerBIWorkspaceName | Name des Power BI Arbeitsbereichs, im dem das Artefakt enthalten ist. | |
| StatusCode | Error_s | Der Statuscode des Vorgangs Dieser deckt Erfolg und Fehler ab. |
| ProgressCounter | ProgressTotal_s | Fortschrittszähler |
| XmlaProperties | RequestProperties_s | Eigenschaften der XMLA-Anforderung |
| XmlaSessionId | SPID_s | Analysis Services-Sitzungsbezeichner |
| Level | Severity_s | Enthält den Schweregrad des protokollierten Vorgangs Erfolg, Information, Warnung oder Fehler |
| Identität | Informationen zu Benutzern und Ansprüchen | |
| Status | Der Status des Vorgangs. | |
| EventText | TextData_s | Enthält ausführliche Informationen, die dem Vorgang zugeordnet sind, z. B. DAX-Abfrage. |
| CustomerTenantId | Power BI-Mandantenbezeichner des Kunden | |
| XmlaRequestId | RootActivityId_g | Eindeutiger Bezeichner der Anforderung |
| ReplicaId | Replikatbezeichner, mit dem Sie das Replikat identifizieren können, wenn Query Scale Out (QSO) aktiviert ist. Replikate mit Lese-/Schreibzugriff verfügen immer über ReplicaId='AAA', und schreibgeschützte Replikate verfügen über ReplicaId ab 'AAB'. Für Semantikmodelle ohne QSO-Unterstützung ist die ReplicaId immer „AAA“. |
ExecutionMetrics-Ereignis
Für jede Discover-, Command- und Query-Anforderung wird ein Ereignis mit dem Namen ExecutionMetrics am Ende der Anforderung erstellt. Dieses Ereignis enthält Ausführungsmetriken für die Anforderung, die Sie bei der Diagnose und Problembehandlung effektiver unterstützen kann. Die ExecutionMetrics-Ablaufverfolgung wird mit der nächsten [Entdecken|Befehl|Query]End-Ereignis.
Die folgende KQL-Abfrage ruft die ExecutionMetrics-Ereignisse für alle Aktualisierungsvorgänge eines semantischen Modells am letzten Tag ab:
let commands = PowerBIDatasetsWorkspace
| where TimeGenerated > ago(1d)
| where ArtifactId =~ "[Semantic Model Id]"
| where OperationName in ("CommandEnd")
| where EventText contains "<Refresh"
| project TimeGenerated, ArtifactId, CommandOperationName = OperationName, XmlaRequestId, CorrelationId, CommandText = EventText;
let executionMetrics = PowerBIDatasetsWorkspace
| where OperationName == "ExecutionMetrics"
| project TimeGenerated, XmlaRequestId, CorrelationId, EventText;
commands
| join kind=leftouter executionMetrics on XmlaRequestId
Die folgende KQL-Abfrage ruft Ereignisse ab, die am letzten Tag nach Arbeitsbereich, Element und Benutzer gedrosselt wurden:
let executionMetrics = PowerBIDatasetsWorkspace
| where TimeGenerated > ago(1d)
| where OperationName == "ExecutionMetrics"
| extend eventTextJson = parse_json(EventText)
| extend capacityThrottlingMs=toint(eventTextJson.capacityThrottlingMs)
| where capacityThrottlingMs > 0;
let commands = PowerBIDatasetsWorkspace
| where OperationName in ("CommandEnd", "QueryEnd", "DiscoverEnd")
| project
TimeGenerated,
ExecutingUser,
ArtifactId,
PowerBIWorkspaceId,
CommandOperationName = OperationName,
XmlaRequestId,
CorrelationId,
CommandText = EventText;
commands
| join kind=inner executionMetrics on XmlaRequestId
| project
TimeGenerated,
ArtifactId,
PowerBIWorkspaceId,
ExecutingUser,
CommandOperationName,
XmlaRequestId,
EventText,
CommandText,
capacityThrottlingMs
| summarize countThrottling = count(), avgThrottlingDuration = avg(capacityThrottlingMs) by PowerBIWorkspaceId, ArtifactId, ExecutingUser, CommandOperationName
Die Statistiken werden als JSON-Text in der EventText-Eigenschaft dargestellt, siehe die folgenden Beispiele.
{
"timeStart": "2024-03-20T12:39:59.681Z",
"timeEnd": "2024-03-20T13:01:14.241Z",
"durationMs": 1274559,
"vertipaqJobCpuTimeMs": 156,
"mEngineCpuTimeMs": 9617484,
"totalCpuTimeMs": 9618469,
"executionDelayMs": 10,
"approximatePeakMemConsumptionKB": 1683409,
"mEnginePeakMemoryKB": 1676816,
"tabularConnectionTimeoutMs": 18000000,
"refreshParallelism": 16,
"vertipaqTotalRows": 114,
"intendedUsage": 2
}
In der folgenden Tabelle werden alle möglichen Eigenschaften beschrieben. Nicht jede Eigenschaft wird in jedem Ereignis ausgegeben, da der Inhalt von der Anforderung und dem Semantikmodell abhängt.
| Eigenschaft | Beschreibung |
|---|---|
| timeStart | Der Zeitstempel (UTC) des Zeitpunkts, an dem die Anforderung gestartet wurde. |
| timeEnd | Der Zeitstempel (UTC) des Zeitpunkts, an dem die Anforderung beendet wurde. |
| durationMs | Gesamte Dauer der Ausführung. |
| datasourceConnectionThrottleTimeMs | Gesamtdrosselungszeit nach dem Erreichen des Grenzwerts für Datenquellenverbindung. Erfahren Sie hier mehr über maximale gleichzeitige Verbindungen. |
| directQueryConnectionTimeMs | Gesamtaufwand für das Erstellen einer neuen DirectQuery-Verbindung während der Anforderung |
| directQueryIterationTimeMs | Gesamtzeit für das Durchlaufen der Ergebnisse, die von den DirectQuery-Abfragen zurückgegeben werden. |
| directQueryTotalTimeMs | Gesamtzeit für das Ausführen und Lesen aller DirectQuery-Abfragen während der Anforderung. |
| executionDelayMs | Gesamtzeit für das Warten auf die Verfügbarkeit von Threadpoolthreads des Analysis Services-Moduls. |
| totalCpuTimeMs | Cpu-Gesamtzeit der Anforderung. |
| vertipaqJobCpuTimeMs | Die gesamte CPU-Zeit, die vom Vertipaq-Modul aufgewendet wurde. |
| mEngineCpuTimeMs | Die gesamte CPU-Zeit, die vom PowerQuery-Modul aufgewendet wurde. |
| queryProcessingCpuTimeMs | Die gesamte CPU-Zeit, die von Aufgaben im Analysis Services-Abfragethreadpoolthread aufgewendet wurde. |
| approximatePeakMemoryConsumptionKB | Ungefähre Spitzenauslastung des gesamten Arbeitsspeichers während der Anforderung. |
| mEnginePeakMemoryKB | Ungefähre Höchstspeicher-Commitgröße (in Kilobyte) in allen Mashupcontainern des PowerQuery-Moduls. |
| directQueryTimeoutMs | Timeout, das DirectQuery-Abfragen zugeordnet ist. |
| externalQueryTimeoutMs | Timeout, das Abfragen externen Datenquellen zugeordnet ist. |
| tabularConnectionTimeoutMs | Timeout, das externen tabellarischen Datenquellenverbindungen zugeordnet ist (e.g. SQL). |
| refreshParallelism | Effektives MaxParallelism, das in der Anforderung verwendet wird. |
| vertipaqTotalRows | Die Gesamtzahl der vom Vertipaq-Modul während eines Aktualisierungsvorgangs verarbeiteten Zeilen. |
| queryResultRows | Die Gesamtzahl der als Ergebnis der DAX-Abfrage zurückgegebenen Zeilen. |
| directQueryTotalRows | Die Gesamtzahl der Zeilen, die aus den verschiedenen DirectQuery-Abfragen gelesen werden. |
| directQueryRequestCount | Die Gesamtzahl der vom DAX-Modul ausgeführten Abfragen des DirectQuery-Speichermoduls. |
| errorCount | Die Gesamtzahl der Fehler für die aktuelle Anforderung. |
| qsoReplicaVersion | Replikatversion für QSO-aktivierte Semantikmodelle, dargestellt im FILETIME-Format. |
| intendedUsage | Beabsichtigte Verwendung: Standard (0); Geplante Aktualisierung oder API-Aktualisierung (1); On Demand Refresh (2); Dashboardkachel/Abfragecacheaktualisierung (3) |
| discoverType | Typ der vom Client angeforderten Ermittlung. Eine Liste der Ermittlungstypen finden Sie unter EventSubclass. |
| queryDialect | Der Typ des Dialekt, den der Client verwendet hat, um den Server abzufragen: Unbekannt (-1); MDX (0); DMX (1); SQL (2); DAX (3); JSON (4) |
| capacityThrottlingMs | Gesamtzeit, die die Anforderung aufgrund von Kapazitätsdrosselung verzögert wurde. Weitere Informationen zur Einschränkung finden Sie hier. |
- Alle Dauern und CPU-Zeiten werden in Millisekunden angegeben.
- Es können weitere Eigenschaften auftreten, die über die in der obigen Tabelle beschriebenen hinausgehen. Diese sollten als nicht dokumentiert betrachtet werden und können geändert werden.
Beispielhafte Log Analytics-KQL-Abfragen
Die folgenden Beispielabfragen können hilfreich sein, wenn Sie Azure Log Analytics mit Power BI verwenden. Sie können direkt im Azure-Portal oder über APIs ausgeführt werden, um die neuesten Daten abzufragen (diese sind in der Regel ca. 5–10 Minuten alt).
// log count per day for last 30d
PowerBIDatasetsWorkspace
| where TimeGenerated > ago(30d)
| summarize count() by format_datetime(TimeGenerated, 'yyyy-MM-dd')
// average query duration by day for last 30d
PowerBIDatasetsWorkspace
| where TimeGenerated > ago(30d)
| where OperationName == 'QueryEnd'
| summarize avg(DurationMs) by format_datetime(TimeGenerated, 'yyyy-MM-dd')
//query duration percentiles for a single day in 1 hour bins
PowerBIDatasetsWorkspace
| where TimeGenerated >= todatetime('2021-04-28') and TimeGenerated <= todatetime('2021-04-29')
| where OperationName == 'QueryEnd'
| summarize percentiles(DurationMs, 0.5, 0.9) by bin(TimeGenerated, 1h)
// refresh durations by workspace and semantic model for last 30d
PowerBIDatasetsWorkspace
| where TimeGenerated > ago(30d)
| where OperationName == 'CommandEnd'
| where ExecutingUser contains 'Power BI Service'
| where EventText contains 'refresh'
| project PowerBIWorkspaceName, DatasetName = ArtifactName, DurationMs
// query count, distinctUsers, avgCPU, avgDuration by workspace for last 30d
PowerBIDatasetsWorkspace
| where TimeGenerated > ago(30d)
| where OperationName == "QueryEnd"
| summarize QueryCount=count()
, Users = dcount(ExecutingUser)
, AvgCPU = avg(CpuTimeMs)
, AvgDuration = avg(DurationMs)
by PowerBIWorkspaceId
Power BI-Beispielberichtsvorlage
Erkunden Sie Azure Log Analytics Power BI-Daten und gewinnen Sie Erkenntnisse mithilfe einer Open-Source-Power BI-Berichtsvorlage auf GitHub.
Zugehöriger Inhalt
In den folgenden Artikeln können Sie mehr über Power BI und die Integration in Azure Log Analytics erfahren.
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Tickets als Feedbackmechanismus für Inhalte auslaufen lassen und es durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter: https://aka.ms/ContentUserFeedback.
Einreichen und Feedback anzeigen für