Planlegging av Power BI-implementering: Overvåking på datanivå

Merk

Denne artikkelen er en del av planleggingsserien for power BI-implementering av artikler. Denne serien fokuserer hovedsakelig på Power BI-opplevelsen i Microsoft Fabric. Hvis du vil ha en innføring i serien, kan du se Planlegging av Power BI-implementering.

Denne overvåkingsartikkelen på datanivå er rettet mot flere målgrupper:

• Dataopprettere og administratorer for arbeidsområder: Brukere som trenger å forstå bruk, innføring og ytelse av semantiske modeller, dataflyter og datamarts som de oppretter, publiserer og deler.
• Power BI-administratorer: Administratorene som er ansvarlige for å overvåke Power BI i organisasjonen. Power BI-administratorer må kanskje samarbeide med IT, sikkerhet, intern revisjon og andre relevante team. Power BI-administratorer må kanskje også samarbeide med innholdsopprettere når de feilsøker ytelsen.
• Power BI-kapasitetsadministratorer: Administratorene som er ansvarlige for å overvåke Premium-kapasitet i organisasjonen. Power BI-kapasitetsadministratorer må kanskje samarbeide med innholdsopprettere når de feilsøker ytelse.
• Center of Excellence- og IT- og BI-teamet: Teamene som også er ansvarlige for å overvåke Power BI. De må kanskje samarbeide med Power BI-administratorer og andre relevante team.
• Systemansvarlige: Teamet som er ansvarlig for å opprette og sikre Azure Log Analytics-ressurser , og databaseadministratorene som administrerer datakilder.

Viktig

Til tider refererer denne artikkelen til Power BI Premium eller dets kapasitetsabonnementer (P SKU-er). Vær oppmerksom på at Microsoft for øyeblikket konsoliderer kjøpsalternativer og trekker tilbake Power BI Premium per kapasitet sKU-er. Nye og eksisterende kunder bør vurdere å kjøpe Fabric-kapasitetsabonnementer (F SKU-er) i stedet.

Hvis du vil ha mer informasjon, kan du se Viktige oppdateringer som kommer til Power BI Premium-lisensiering og vanlige spørsmål om Power BI Premium.

Konseptene som dekkes i denne artikkelen gjelder hovedsakelig for løsninger som er opprettet for tre innholdsleveringsomfang, spesielt enterprise BI, departmental BI og team BI. Opprettere av personlige BI-løsninger kan også finne informasjonen i denne artikkelen nyttig. De er imidlertid ikke det primære målet.

Det er ikke mulig å oppnå god ytelse i rapporter og visualobjekter når den underliggende semantiske modellen og/eller datakilden ikke fungerer bra. Denne artikkelen fokuserer på overvåking og overvåking av semantiske modeller, dataflyter og datamarts. Det er den andre artikkelen i overvåkings- og overvåkingsserien fordi verktøyene og teknikkene er mer komplekse enn det som er beskrevet i revisjonsartikkelen på rapportnivå . Ideelt sett oppretter du delte semantiske modeller (beregnet for gjenbruk blant mange rapporter) før brukere oppretter rapporter. Derfor anbefaler vi at du leser denne artikkelen sammen med revisjonsartikkelen på rapportnivå .

Siden Power BI-semantiske modeller er bygget på Analysis Services-tabellmotoren, kan du koble til en lokal datamodell (i Power BI Desktop) eller en Premium-semantisk modell (i Power Bi-tjeneste) som om det er en Analysis Services-database. Derfor støttes mange av overvåkings- og overvåkingsfunksjonene i Analysis Services for Semantiske Modeller for Power BI Premium.

Merk

Hvis du vil ha mer informasjon om modeller som driftes i Analysis Services, kan du se Overvåkingsoversikt.

Resten av denne artikkelen fokuserer primært på modeller som er publisert i Power Bi-tjeneste.

Hendelseslogger for semantisk modell

Over tid kan dataopprettere og eiere oppleve situasjoner med semantiske modeller. En semantisk modell kan:

• Bli mer komplisert og inkluder komplekse mål.
• Bli større i datavolum.
• Bruk mer minne (noen ganger unødvendig når det ble tatt dårlige utformingsbeslutninger).
• Bruk mer varierte datakilder og mer komplekse tabellrelasjoner.
• Inkluder flere regler for sikkerhet på radnivå (RLS). Hvis du vil ha mer informasjon, kan du se Fremtvinge datasikkerhet basert på forbrukeridentitet.
• Ha flere rapporter som avhenger av det. Hvis du vil ha mer informasjon om hvordan du bruker live-tilkoblinger med en delt semantisk modell, kan du se det administrerte selvbetjente BI-bruksscenarioet .
• Ha flere nedstrøms datamodeller som avhenger av det. Hvis du vil ha mer informasjon om hvordan du bruker DirectQuery for Semantiske Power BI-modeller og Analysis Services med en delt semantisk modell, kan du se det tilpassbare administrerte selvbetjente BI-bruksscenarioet .
• Opplev langsommere kjøring av spørringer og langsommere dataoppdateringstider.
• Bidra til langsommere gjengivelse av rapporter og visualobjekter.

Hvis du vil sikre brukervennlighet, god ytelse og innføring av innholdet de oppretter, bør du overvåke bruken og ytelsen til dataressursene du er ansvarlig for å administrere. Du kan bruke hendelsesloggene for datasettet, som registrerer brukergenererte og systemgenererte aktiviteter som forekommer for en semantisk modell. De kalles også sporingshendelser, datasettlogger eller aktivitetslogger for datasett. Systemansvarlige kaller dem ofte sporingshendelser på lavt nivå fordi de er detaljerte.

Merk

Navneendringen for datasettet er rullet ut i Power Bi-tjeneste og i dokumentasjonen, selv om det kan være noen forekomster, for eksempel med navn på hendelsesloggoperasjoner, der endringen ikke har skjedd ennå.

Du bør analysere semantiske modellsporingshendelser til:

• Overvåk alle aktiviteter som har oppstått på en semantisk modell.
• Feilsøke og optimalisere semantisk modellytelse, minnebruk og spørringseffektivitet.
• Undersøk oppdateringsdetaljer for semantisk modell og varighet.
• Overvåk Power Query-formelspråk (M-spørringer) som sendes av Power Query.
• Overvåk DAX-formler og uttrykk som sendes til den semantiske modellen (Analysis Services-motoren).
• Kontroller om riktig lagringsmodus ble valgt basert på arbeidsbelastningene og behovet for å balansere ferske data og optimal ytelse.
• Overvåk hvilke sikkerhetsroller på radnivå som aktiveres, hvilke brukere og hvilke semantiske modeller.
• Forstå antall samtidige brukere.
• Valider en semantisk modell (for eksempel for å bekrefte datakvalitet og ytelse før du godkjenner en semantisk modell, eller før du publiserer den til et produksjonsarbeidsområde).

Hendelsene som genereres av en semantisk Power BI-modell, er avledet fra eksisterende diagnoselogger som er tilgjengelige for Azure Analysis Services. Det finnes mange typer sporingshendelser som du kan registrere og analysere, som er beskrevet i avsnittene nedenfor.

Azure Log Analytics

Azure Log Analytics er en komponent i Azure Monitor-tjenesten . Azure Log Analytics-integrering med Power BI lar deg fange opp semantiske modellhendelser fra alle semantiske modeller i et Power BI-arbeidsområde. Det støttes bare for Premium-arbeidsområder. Når du har konfigurert integrering og tilkoblingen er aktivert (for et Power BI Premium-arbeidsområde), registreres semantiske modellhendelser automatisk og sendes kontinuerlig til et azure Log Analytics-arbeidsområde. Semantiske modelllogger lagres i Azure Data Explorer, som er en tilføyingsdatabase som er optimalisert for å registrere telemetridata med høyt volum, nesten sanntid.

Du tilordner et Power BI Premium-arbeidsområde til et logganalysearbeidsområde i Azure. Du må opprette en ny Log Analytics-ressurs i Azure-abonnementet for å aktivere denne typen logging.

Logger fra ett eller flere Power BI-arbeidsområder sendes til et arbeidsområde for mållogganalyse. Her er noen måter du kan velge å organisere dataene på.

• Ett målarbeidsområde for alle overvåkingsdata: Lagre alle dataene i ett Arbeidsområde for logganalyse. Det er nyttig når samme administrator eller brukere får tilgang til alle data.
• Målarbeidsområder organisert etter emneområde: Organiser innholdet etter emneområde. Denne teknikken er spesielt nyttig når ulike administratorer eller brukere har tilgang til overvåkingsdataene fra Azure Log Analytics. Når du for eksempel trenger å skille salgsdata fra operasjonsdata.
• Ett målarbeidsområde for hvert Power BI-arbeidsområde: Konfigurere en én-til-én-relasjon mellom et Power BI-arbeidsområde og et azure Log Analytics-arbeidsområde. Dette er nyttig når du har spesielt sensitivt innhold, eller når dataene er underlagt spesifikke samsvarskrav eller forskriftsmessige krav.

Tips

Se gjennom dokumentasjonen og vanlige spørsmål om denne funksjonaliteten grundig, slik at du er tydelig på hva som er mulig, og at du forstår de tekniske kravene. Før du gjør denne funksjonaliteten tilgjengelig for administratorer for arbeidsområder i organisasjonen, bør du vurdere å gjøre et teknisk konseptbevis (POC) med ett Power BI-arbeidsområde.

Viktig

Selv om navnene er like, er ikke dataene som fanges opp av Azure Log Analytics, de samme som aktivitetsloggen for Power BI. Azure Log Analytics registrerer sporingshendelser på detaljnivå fra Analysis Services-motoren. Det eneste formålet er å hjelpe deg med å analysere og feilsøke semantisk modellytelse. Omfanget er på arbeidsområdenivå. Formålet med aktivitetsloggen er derimot å hjelpe deg med å forstå hvor ofte bestemte brukeraktiviteter forekommer (for eksempel redigere en rapport, oppdatere en semantisk modell eller opprette en app). Omfanget er hele Power BI-leieren.

Hvis du vil ha mer informasjon om brukeraktivitetene du kan overvåke for Power BI-leieren, kan du se overvåking på leiernivå.

Azure Log Analytics-tilkoblingen for leierinnstillinger for arbeidsområdeadministratorer kontrollerer hvilke grupper av brukere (som også har den nødvendige administratorrollen for arbeidsområdet) som kan koble et Power BI-arbeidsområde til et eksisterende Azure Log Analytics-arbeidsområde.

Før du kan konfigurere integrering, må du oppfylle forutsetningene for sikkerhet. Vurder derfor å aktivere power BI-leierinnstillingen bare for Administratorer for Power BI-arbeidsområder som også har de nødvendige tillatelsene i Azure Log Analytics, eller som kan få disse tillatelsene ved forespørsel.

Tips

Samarbeid med Azure-administratoren tidlig i planleggingsprosessen, spesielt når du får godkjenning til å opprette en ny Azure-ressurs, er en utfordring i organisasjonen. Du må også planlegge for sikkerhets forutsetningene. Bestem om du vil gi tillatelse til administratoren for Power BI-arbeidsområdet i Azure, eller om du vil gi tillatelse til Azure-administratoren i Power BI.

De semantiske modellloggene som fanges opp av Azure Log Analytics inkluderer semantiske modellspørringer, spørringsstatistikk, detaljert oppdateringsaktivitet, CPU-tid brukt på Premium-kapasiteter og mer. Fordi de er logger på detaljnivå fra Analysis Services-motoren, kan dataene være detaljerte. Store datavolumer er vanlige for store arbeidsområder som opplever høy semantisk modellaktivitet.

Slik optimaliserer du kostnader ved bruk av Azure Log Analytics med Power BI:

• Koble Power BI-arbeidsområder til Azure Log Analytics bare når du aktivt feilsøker, tester, optimaliserer eller undersøker semantisk modellaktivitet. Når du er tilkoblet, kjøres en sporing på alle semantiske modeller i arbeidsområdet.
• Koble Azure Log Analytics fra et Power BI-arbeidsområde når du ikke lenger trenger å feilsøke, teste, optimalisere eller undersøke semantisk modellaktivitet. Ved å koble fra avslutter du sporingen fra å kjøre på alle semantiske modeller i arbeidsområdet.
• Kontroller at du forstår kostnadsmodellen for hvordan Azure Log Analytics fasader for datainntak, lagring og spørringer.
• Ikke lagre dataene i Log Analytics lenger enn standard 30-dagers oppbevaringsperiode. Det er fordi semantisk modellanalyse vanligvis fokuserer på umiddelbare feilsøkingsaktiviteter.

Det finnes flere måter å få tilgang til hendelsene som sendes til Azure Log Analytics. Du kan bruke:

• Malappen for den forhåndsbygde logganalysen for Power BI Semantic Models.
• Power BI Desktop-koblingen for Azure Data Explorer (Kusto). Bruk Kusto Query Language (KQL) til å analysere dataene som er lagret i Log Analytics. Hvis du har SQL-spørringsopplevelse, finner du mange likheter med KQL.
• Den nettbaserte spørringsopplevelsen i Azure Data Explorer.
• Alle spørringsverktøy som kan kjøre KQL-spørringer.

Tips

Fordi det er et stort volum av semantiske modellsporingshendelser, anbefaler vi at du utvikler en DirectQuery-modell for å analysere dataene. Med en DirectQuery-modell kan du spørre etter dataene i nær sanntid. Hendelsene kommer vanligvis innen fem minutter.

Hvis du vil ha mer informasjon, kan du se Styre Azure-tilkoblinger.

Sjekkliste – Når du planlegger å bruke Azure Log Analytics, omfatter viktige beslutninger og handlinger:

• Vurder en teknisk poc: Planlegg for et lite prosjekt for å sikre at du fullt ut forstår de tekniske kravene, sikkerhetskravene, hvilke hendelser som skal registreres, og hvordan du analyserer loggene.
• Bestem hvilke arbeidsområder som skal integreres med Log Analytics: Bestem hvilke Premium-arbeidsområder som inneholder semantiske modeller som du er interessert i å analysere.
• Bestem om Logganalyse skal aktiveres på heltid for alle arbeidsområder: For kostnadsoptimalisering må du avgjøre om det finnes situasjoner (eller bestemte arbeidsområder) der logging skal aktiveres permanent. Bestem om arbeidsområder skal kobles fra når feilsøking ikke skjer.
• Bestem hvor lenge logganalysedataene skal beholdes: Bestem om det er behov for å angi en lengre oppbevaringsperiode enn 30-dagers standard.
• Klargjør prosessen for å be om nytt arbeidsområde for logganalyse: Samarbeid med Azure-administratoren for å klargjøre hvordan forespørsler om en ny Log Analytics-ressurs skal sendes inn av administratorer for Power BI-arbeidsområdet.
• Bestem hvordan sikkerhet vil fungere: Samarbeid med Azure-administratoren for å avgjøre om det er mer mulig for en administrator for Power BI-arbeidsområdet å få rettigheter til et Azure Log Analytics-arbeidsområde, eller for at en Azure-administrator skal få rettigheter til et Power BI-arbeidsområde. Når du tar denne sikkerhetsbeslutningen, bør du vurdere planen for å koble til og koble fra arbeidsområder regelmessig (for kostnadsoptimalisering).
• Bestem hvordan du organiserer arbeidsområdene for mållogganalyse: Vurder hvor mange arbeidsområder i Azure Log Analytics som passer til å organisere dataene fra ett eller flere Power BI-arbeidsområder. Juster denne beslutningen med sikkerhetsbeslutningene for hvem som har tilgang til loggdataene.
• Bestem hvilke arbeidsområdeadministratorer som har tillatelse til å koble til: Bestem hvilke grupper av arbeidsområdeadministratorer som kan koble et Power BI-arbeidsområde til et arbeidsområde for logganalyse. Angi azure Log Analytics-tilkoblingen for leierinnstillingen for administratorer for arbeidsområdet slik at den samsvarer med denne beslutningen.
• Opprett Azure Log Analytics-ressursen: Samarbeid med Azure-administratoren for å opprette hvert Log Analytics-arbeidsområde. Kontroller og oppdater tillatelsene som er tilordnet i Azure for å sikre at Power BI-konfigurasjonen kan oppstå uten problemer. Valider at dataene som er lagret i Azure, er i riktig geografisk område.
• Angi Logganalyse-tilkoblingen for hvert Power BI-arbeidsområde: Samarbeid med administratorer for Power BI-arbeidsområdet for å konfigurere tilkoblingen til Log Analytics for hvert Power BI-arbeidsområde. Kontroller at loggdataene flyter riktig til logganalysearbeidsområdet.
• Opprett spørringer for å analysere dataene: Konfigurer KQL-spørringer for å analysere dataene i Log Analytics basert på brukstilfellet og gjeldende behov.
• Inkluder veiledning for administratorer for Power BI-arbeidsområder: Gi informasjon og forutsetninger til administratorer for Power BI-arbeidsområdet for hvordan du ber om et nytt arbeidsområde for logganalyse og hvordan du kobler til et Power BI-arbeidsområde. Forklar også når det er aktuelt å koble fra et Power BI-arbeidsområde.
• Gi veiledning og eksempelspørringer for analyse av dataene: Opprett KQL-spørringer for arbeidsområdeadministratorer for å gjøre det enklere for dem å komme i gang med å analysere dataene som er registrert.
• Overvåk kostnader: Samarbeid med Azure-administratoren for å overvåke Log Analytics-kostnader kontinuerlig.

Profileringsverktøy for SQL Server

Du kan bruke SQL Server Profiler (SQL Profiler) til å registrere semantiske modellhendelser i Power BI. Det er en komponent i SQL Server Management Studio (SSMS). Tilkobling til en semantisk Power BI-modell støttes med SSMS fordi den er basert på Analysis Services-arkitekturen som oppsto i SQL Server.

Du kan bruke SQL Profiler i ulike faser av livssyklusen til en semantisk modell.

• Under utvikling av datamodell: SQL Profiler kan koble til en datamodell i Power BI Desktop som et eksternt verktøy. Denne fremgangsmåten er nyttig for datamodellerere som ønsker å validere datamodellen, eller utføre ytelsesjustering.
• Når den semantiske modellen er publisert til Power Bi-tjeneste: SQL Profiler kan koble til en semantisk modell i et Premium-arbeidsområde. SSMS er ett av mange støttede klientverktøy som kan bruke XMLA-endepunktet for tilkobling. Denne fremgangsmåten er nyttig når du vil overvåke, overvåke, validere, feilsøke eller justere en publisert semantisk modell i Power Bi-tjeneste.

Det er også mulig å bruke SQL Profiler som et eksternt verktøy i DAX Studio. Du kan bruke DAX Studio til å starte en profiler-sporing, analysere dataene og formatere resultatene. Datamodellerere som bruker DAX Studio foretrekker ofte denne tilnærmingen kontra å bruke SQL Profiler direkte.

Merk

Bruk av SQL Profiler er et annet brukstilfelle enn aktiviteten til profilering av data. Du profilerer data i Power Query-redigering for å få en dypere forståelse av egenskapene. Selv om dataprofilering er en viktig aktivitet for datamodellerere, er den ikke i omfang for denne artikkelen.

Vurder å bruke SQL Profiler i stedet for Azure Log Analytics når:

• Organisasjonen tillater deg ikke å bruke eller opprette Azure Log Analytics-ressurser i Azure.
• Du vil registrere hendelser for en datamodell i Power BI Desktop (som ikke har blitt publisert til et Premium-arbeidsområde i Power Bi-tjeneste).
• Du vil registrere hendelser for én semantisk modell i en kort tidsperiode (i stedet for alle semantiske modeller i et Premium-arbeidsområde).
• Du vil bare registrere bestemte hendelser under en sporing (for eksempel bare hendelsen Spørringsslutt ).
• Du vil starte og stoppe sporinger ofte (for eksempel når du trenger å registrere semantiske modellhendelser som forekommer nå).

I likhet med Azure Log Analytics (beskrevet tidligere i denne artikkelen), er semantiske modellhendelser som fanges opp av SQL Profiler, avledet fra eksisterende diagnoselogger som er tilgjengelige for Azure Analysis Services. Det er imidlertid noen forskjeller i hendelsene som er tilgjengelige.

Tips

Bruken av SQL Profiler for overvåking av Analysis Services dekkes i mange bøker, artikler og blogginnlegg. Mesteparten av denne informasjonen er relevant for overvåking av en Semantisk Power BI-modell.

Viktig

Du kan også bruke SQL Profiler til å overvåke spørringer som sendes fra Power Bi-tjeneste til de underliggende datakildene (for eksempel til en SQL Server-relasjonsdatabase). Muligheten til å spore en relasjonsdatabase er imidlertid avskrevet. Tilkobling til Analysis Services-motoren støttes ikke og avskrives ikke. Hvis du er kjent med utvidede Analysis Services-hendelser og foretrekker å bruke dem, er tilkobling fra SSMS mulig for en datamodell i Power BI Desktop. Det støttes imidlertid ikke for Power BI Premium. Denne delen fokuserer derfor bare på standard SQL Profiler-tilkobling.

Tillat XMLA-endepunkter og analyser i Excel med lokale semantiske modeller, kontrollerer hvilke grupper av brukere (som også er tilordnet rollen bidragsyter, medlem eller administratorarbeidsområde, eller kompileringstillatelsen for den individuelle semantiske modellen) kan bruke XMLA-endepunktet til å spørre og/eller vedlikeholde semantiske modeller i Power Bi-tjeneste. Hvis du vil ha mer informasjon om hvordan du bruker XMLA-endepunktet, kan du se det avanserte bruksscenariet for datamodellbehandling .

Merk

Du kan også bruke SQL Profiler til å feilsøke og feilsøke bestemte DAX-uttrykk. Du kan koble SQL Profiler til Power BI Desktop som et eksternt verktøy. Se etter hendelsesklassen for DAX-evalueringsloggen for å vise mellomliggende resultater av et DAX-uttrykk. Denne hendelsen genereres når du bruker EVALUATEANDLOG DAX-funksjonen i en modellberegning.

Denne funksjonen er bare ment for utviklings- og testformål. Du bør fjerne den fra datamodellberegningene før du publiserer datamodellen til et produksjonsarbeidsområde.

Sjekkliste – Når du planlegger å bruke SQL Profiler, omfatter viktige beslutninger og handlinger:

• Bestem hvem som kan ha SSMS eller DAX Studio installert: Bestem om du vil tillate at alle Power BI-innholdsopprettere i organisasjonen kan installere SSMS og/eller DAX Studio, slik at de kan bruke SQL Profiler. Bestem om disse tilleggsverktøyene installeres på forespørsel, eller en del av et standard sett med programvare som er installert for godkjente dataopprettere i organisasjonen.
• Legg til SQL Profiler på menyen Eksterne verktøy i Power BI Desktop: Hvis dataopprettere ofte bruker SQL Profiler, ber du IT om å legge den til automatisk på menyen Eksterne verktøy i Power BI Desktop for disse brukerne.
• Bestem hvem som kan bruke XMLA-endepunktet: Bestem om alle brukere har tillatelse til å koble til publiserte semantiske modeller ved hjelp av XMLA-endepunktet, eller om det bare er begrenset til godkjente dataopprettere. Angi innstillingen Tillat XMLA-endepunkter og Analyser i Excel med lokale semantiske modeller for leier for å justere med denne beslutningen.
• Gi veiledning og eksempelspørringer for analyse av dataene: Opprett dokumentasjon for dataoppretterne, slik at de forstår den anbefalte måten å overvåke og overvåke semantiske modeller på. Gi veiledning for vanlige brukstilfeller for å gjøre det enklere for dem å komme i gang med å samle inn og analysere sporingsdata.

Metadata for datamodell

Siden Semantiske Modeller for Power BI er bygget på Analysis Services-motoren, har du tilgang til verktøyene som kan spørre metadataene til en datamodell. Metadata omfatter alt om datamodellen, inkludert tabellnavn, kolonnenavn og måluttrykk.

Dynamiske administrasjonsvisninger

Dynamiske administrasjonsvisninger for Analysis Services (DMV-er) kan spørre etter metadataene for datamodellen. Du kan bruke DMV-ene til å overvåke, dokumentere og optimalisere datamodellene på et tidspunkt.

Spesielt kan du:

• Overvåk datakildene som brukes av en modell.
• Finn ut hvilke objekter som bruker mest minne i en modell.
• Bestem hvor effektivt kolonnedata kan komprimeres.
• Finn kolonner i en modell som ikke brukes.
• Overvåk aktive brukerøkter og tilkoblinger.
• Kontroller modellens struktur.
• Se gjennom DAX-uttrykk som brukes av beregnede tabeller, beregnede kolonner, mål og regler for sikkerhet på radnivå (RLS).
• Identifiser avhengigheter mellom objekter og mål.

Tips

DMV-ene henter informasjon om gjeldende tilstand for en semantisk modell. Tenk på dataene som returneres av DMV-er som et øyeblikksbilde av hva som skjer på et tidspunkt. Derimot henter de semantiske modellhendelsesloggene (beskrevet tidligere i denne artikkelen) informasjon om hvilke aktiviteter som skjedde for en semantisk modell mens en sporingstilkobling var aktiv.

SSMS er et verktøy som vanligvis brukes til å kjøre DMV-spørringer. Du kan også bruke Invoke-ASCmd PowerShell-cmdleten til å opprette og kjøre XMLA-skript som spør på DMV-ene.

Tredjepartsverktøy og eksterne verktøy er også populære i Power BI-fellesskapet. Disse verktøyene bruker de offentlig dokumenterte DMV-ene til å forenkle tilgangen og arbeide med data som returneres av DMV-ene. Et eksempel er DAX Studio, som inkluderer eksplisitt funksjonalitet for å få tilgang til DMV-er. DAX Studio inkluderer også en innebygd Visningsmåledata-funksjon, som er kjent som Vertipaq Analyzer. Vertipaq Analyzer har et brukergrensesnitt for å analysere strukturen og størrelsen på tabeller, kolonner, relasjoner og partisjoner i en datamodell. Du kan også eksportere (eller importere) metadataene for datamodellen til en VPAX-fil. Den eksporterte filen inneholder bare metadata om datamodellstrukturen og -størrelsen, uten å lagre modelldata.

Tips

Vurder å dele en VPAX-fil med noen når du trenger hjelp med en datamodell. På den måten deler du ikke modelldataene med denne personen.

Du kan bruke DMV-spørringer i ulike faser av livssyklusen til en semantisk modell.

• Under utvikling av datamodell: Det aktuelle verktøyet kan koble til en datamodell i Power BI Desktop som et eksternt verktøy. Denne fremgangsmåten er nyttig for datamodellerere som ønsker å validere datamodellen, eller utføre ytelsesjustering.
• Når den semantiske modellen er publisert til Power Bi-tjeneste: Det aktuelle verktøyet kan koble til en semantisk modell i et Premium-arbeidsområde. SSMS er ett av mange støttede klientverktøy som bruker XMLA-endepunktet for tilkobling. Denne fremgangsmåten er nyttig når du vil overvåke eller validere en publisert semantisk modell i Power Bi-tjeneste.

Tips

Hvis du bestemmer deg for å skrive dine egne DMV-spørringer (for eksempel i SSMS), må du være oppmerksom på at DMV-ene ikke støtter alle SQL-operasjoner. Enkelte DMV-er støttes heller ikke i Power BI (fordi de krever administratortillatelser for Analysis Services-serveren som ikke støttes av Power BI).

Tillat XMLA-endepunkter og analyser i Excel med lokale semantiske modeller, kontrollerer hvilke grupper av brukere (som også er tilordnet rollen bidragsyter, medlem eller administratorarbeidsområde, eller kompileringstillatelsen for den individuelle semantiske modellen) kan bruke XMLA-endepunktet til å spørre og/eller vedlikeholde semantiske modeller i Power Bi-tjeneste.

Hvis du vil ha mer informasjon om hvordan du bruker XMLA-endepunktet, tredjepartsverktøy og eksterne verktøy, kan du se det avanserte bruksscenarioet for datamodellbehandling .

Analyse av anbefalte fremgangsmåter

Best Practice Analyzer (BPA) er en funksjon i Tabellredigering, som er et tredjepartsverktøy som har oppnådd omfattende innføring av Power BI-fellesskapet. BPA inneholder et sett med regler som kan tilpasses, som kan hjelpe deg med å overvåke kvaliteten, konsistensen og ytelsen til datamodellen.

Tips

Hvis du vil konfigurere BPA, laster du ned settet med anbefalte fremgangsmåter, som leveres av Microsoft på GitHub.

Først og fremst kan BPA hjelpe deg med å forbedre konsekvensen av modeller ved å oppdage suboptimale utformingsbeslutninger som kan redusere ytelsesproblemer. Det er nyttig når du har selvbetjente datamodellerere fordelt på ulike områder i organisasjonen.

BPA kan også hjelpe deg med å overvåke og styre datamodellene dine. Du kan for eksempel bekrefte om en datamodell inneholder noen RLS-roller (row-level security ). Du kan også validere om alle modellobjekter har en beskrivelse. Det er nyttig når målet for eksempel er å sikre at en datamodell inneholder en dataordliste.

BPA kan avsløre utformingsproblemer som kan hjelpe Kompetansesenteret med å avgjøre om det er nødvendig med mer opplæring eller dokumentasjon. Det kan iverksette tiltak for å lære dataopprettere om anbefalte fremgangsmåter og organisasjonsretningslinjer.

Tips

Husk at BPA kan oppdage eksistensen av en egenskap (for eksempel sikkerhet på radnivå). Det kan imidlertid være vanskelig å avgjøre om det er riktig konfigurert. Av den grunn kan det hende at en fagekspert må foreta en gjennomgang. Derimot betyr ikke ikke-eksistensen av en bestemt egenskap nødvendigvis ikke nødvendigvis en dårlig design; datamodellereren kan ha en god grunn til å produsere en bestemt design.

Sjekkliste – Når du planlegger å få tilgang til metadata for datamodeller, omfatter viktige beslutninger og handlinger:

• Bestem hvem som kan ha SSMS installert: Finn ut om du vil tillate at alle Power BI-innholdsopprettere i organisasjonen kan installere SSMS, slik at de kan koble til publiserte semantiske modeller. Bestem om det er installert på forespørsel, eller som en del av et standard sett med programvare som er installert for godkjente dataopprettere i organisasjonen.
• Bestem hvem som kan ha tredjepartsverktøy installert: Bestem om du vil tillate at alle Power BI-innholdsopprettere i organisasjonen installerer tredjepartsverktøy (for eksempel DAX Studio og Tabellredigering), slik at de kan overvåke lokale datamodeller og/eller publiserte semantiske modeller. Bestem om de er installert på forespørsel, eller som en del av et standard sett med programvare som er installert for godkjente dataopprettere i organisasjonen.
• Konfigurere regler for anbefalte fremgangsmåter: Beste praksisanalyseregler kan skanne datamodellene i organisasjonen.
• Bestem hvem som kan bruke XMLA-endepunktet: Bestem om alle brukere har tillatelse til å koble til semantiske modeller ved hjelp av XMLA-endepunktet, eller om det bare er begrenset til godkjente dataopprettere. Angi innstillingen Tillat XMLA-endepunkter og Analyser i Excel med lokale semantiske modeller for leier for å justere med denne beslutningen.
• Gi veiledning for innholdsopprettere: Opprett dokumentasjon for dataoppretterne, slik at de forstår de anbefalte måtene å analysere semantiske modeller på. Gi veiledning for vanlige brukstilfeller for å gjøre det enklere for dem å starte innsamling og analyse av DMV-resultater og/eller ved hjelp av Best Practice Analyzer.

Datamodell og spørringsytelse

Power BI Desktop inneholder flere verktøy som hjelper dataopprettere med å feilsøke og undersøke datamodellene sine. Disse funksjonene er rettet mot datamodellerere som ønsker å validere datamodellen, og utføre ytelsesjustering før publisering til Power Bi-tjeneste.

Ytelsesanalyse

Bruk Ytelsesanalyse, som er tilgjengelig i Power BI Desktop, til å overvåke og undersøke ytelsen til en datamodell. Ytelsesanalyse hjelper rapportopprettere med å måle ytelsen til individuelle rapportelementer. Vanligvis er imidlertid årsaken til ytelsesproblemer relatert til utforming av datamodell. Derfor kan en semantisk modelloppretter også dra nytte av å bruke Ytelsesanalyse. Hvis det finnes ulike innholdsopprettere som er ansvarlige for å opprette rapporter kontra semantiske modeller, er det sannsynlig at de må samarbeide når de feilsøker et ytelsesproblem.

Tips

Du kan bruke DAX Studio til å importere og analysere loggfilene som genereres av Ytelsesanalyse.

Hvis du vil ha mer informasjon om Ytelsesanalyse, kan du se Overvåking på rapportnivå.

Spørringsdiagnose

Bruk Spørringsdiagnose, som er tilgjengelig i Power BI Desktop, til å undersøke ytelsen til Power Query. De er nyttige for feilsøking, og for når du trenger å forstå hva Power Query-motoren gjør.

Informasjonen du kan få fra spørringsdiagnose inkluderer:

• Ekstra detaljer relatert til feilmeldinger (når det oppstår et unntak).
• Spørringene som sendes til en datakilde.
• Om spørringsdelegering er eller ikke forekommer.
• Antall rader som returneres av en spørring.
• Potensielle nedgangstider under en dataoppdateringsoperasjon.
• Bakgrunnshendelser og systemgenererte spørringer.

Avhengig av hva du leter etter, kan du aktivere én eller alle loggene: aggregerte, detaljerte, ytelsestellere og datavernpartisjoner.

Du kan starte øktdiagnose i Power Query-redigering. Når aktivert, samles spørrings- og oppdateringsoperasjoner til diagnosesporingen stoppes. Dataene fylles ut direkte i redigeringsprogrammet for spørring så snart diagnosen stoppes. Power Query oppretter en diagnosegruppe (mappe), og legger til flere spørringer i den. Deretter kan du bruke standard Power Query-funksjonalitet til å vise og analysere diagnosedata.

Alternativt kan du aktivere en sporing i Power BI Desktop i Diagnose-delen i Alternativer-vinduet . Loggfiler lagres i en mappe på den lokale maskinen. Disse loggfilene fylles ut med dataene etter at du har lukket Power BI Desktop, og da stoppes sporingen. Når Power BI Desktop er lukket, kan du åpne loggfilene med det foretrukne programmet (for eksempel et tekstredigeringsprogram) for å vise dem.

Spørringsevaluering og folding

Power Query støtter ulike funksjoner for å hjelpe deg med å forstå spørringsevalueringen, inkludert spørringsplanen. Det kan også hjelpe deg med å finne ut om spørringsdelegering forekommer for en hel spørring, eller for et delsett av trinnene i en spørring. Spørringsdelegering er en av de viktigste aspektene ved ytelsesjustering. Det er også nyttig å se gjennom de opprinnelige spørringene som sendes av Power Query når du overvåker en datakilde, som beskrives senere i denne artikkelen.

Premium-måledataapp

Når du feilsøker, kan det være nyttig å samarbeide med power bi Premium-kapasitetsadministratoren. Kapasitetsadministratoren har tilgang til Power BI Premium-bruks- og måledataappen. Denne appen kan gi deg et vell av informasjon om aktiviteter som forekommer i kapasiteten. Denne informasjonen kan hjelpe deg med å feilsøke semantiske modellproblemer.

Tips

Premium-kapasitetsadministratoren kan gi tilgang til flere brukere (ikke-kapasitetsadministratorer) for å gi dem tilgang til Premium-måledataappen.

Premium metrics-appen består av en intern semantisk modell og et innledende sett med rapporter. Det hjelper deg med å utføre nesten sanntidsovervåking av en Power BI Premium-kapasitet (P SKU) eller Power BI Embedded (A SKU)-kapasitet. Den inneholder data for de siste to til fire ukene (avhengig av måleverdien).

Bruk Premium-måledataappen til å feilsøke og optimalisere semantiske modeller. Du kan for eksempel identifisere semantiske modeller som har et stort minneavtrykk , eller som opplever rutinemessig høy CPU-bruk. Det er også et nyttig verktøy for å finne semantiske modeller som nærmer seg grensen for kapasitetsstørrelsen.

Sjekkliste – Når du vurderer tilnærminger til bruk for overvåking av datamodell og spørringsytelse, omfatter viktige beslutninger og handlinger:

• Identifiser ytelsesmål for semantisk modellspørring: Sørg for at du har en god forståelse av hva god semantisk modellytelse betyr. Bestem når du vil kreve bestemte mål for spørringsytelse (for eksempel må spørringer for å støtte rapporter gjengis innen fem sekunder). I så fall må du kontrollere at målene formidles til dataoppretterne i organisasjonen.
• Identifiser ytelsesmål for semantisk modelloppdatering: Bestem når du krever bestemte mål for dataoppdatering (for eksempel fullføring av en dataoppdateringsoperasjon innen 15 minutter og før kl. 05.00). I så fall må du kontrollere at målene formidles til dataoppretterne i organisasjonen.
• Lær kundestøtteteamet ditt: Sørg for at det interne brukerstøtteteamet er kjent med diagnosefunksjonene, slik at de er klare til å støtte Power BI-brukere når de trenger hjelp.
• Koble til kundestøtteteamet og databaseadministratorer: Kontroller at kundestøtteteamet vet hvordan de skal kontakte de riktige administratorene for hver datakilde (for eksempel ved feilsøking av spørringsdelegering).
• Samarbeid med premium-kapasitetsadministratoren: Samarbeid med kapasitetsadministratoren for å feilsøke semantiske modeller som befinner seg i et arbeidsområde som er tilordnet Premium-kapasitet eller Power BI Embedded-kapasitet. Når det er aktuelt, ber du om tilgang til Premium-måledataappen.
• Gi veiledning for innholdsopprettere: Opprett dokumentasjon for dataoppretterne, slik at de forstår hvilke handlinger som skal utføres når du feilsøker.
• Inkluder i opplæringsmateriell: Gi veiledning til dataoppretterne om hvordan du oppretter velpresterende datamodeller. Hjelp dem med å ta i bruk gode designvaner tidlig. Fokuser på å lære dataopprettere hvordan du tar gode utformingsbeslutninger.

Overvåking av datakilde

Noen ganger er det nødvendig å overvåke en bestemt datakilde som Power BI kobler til direkte. Du kan for eksempel ha et datalager som opplever økt arbeidsbelastning, og brukere rapporterer ytelsesreduksjon. Vanligvis overvåker en databaseadministrator eller systemansvarlig datakilder.

Du kan overvåke en datakilde til:

• Overvåk hvilke brukere som sender spørringer til datakilden.
• Overvåk hvilke programmer (for eksempel Power BI) som sender spørringer til datakilden.
• Se gjennom hvilke spørringssetninger som sendes til datakilden, når og av hvilke brukere.
• Bestem hvor lang tid det tar for en spørring å kjøre.
• Overvåk hvordan sikkerhet på radnivå aktiveres av kildesystemet når det bruker enkel pålogging (SSO).

Det finnes mange handlinger som en Power BI-innholdsoppretter kan utføre når de analyserer overvåkingsresultater. De kunne:

• Juster og begrens spørringene som sendes til datakilden, slik at de er så effektive som mulig.
• Valider og juster de opprinnelige spørringene som sendes til datakilden.
• Reduser antall kolonner som importeres til en datamodell.
• Fjern kolonner med høy presisjon og høy kardinalitet som importeres til en datamodell.
• Reduser mengden historiske data som er importert til en datamodell.
• Juster oppdateringstidene for Power BI-data for å bidra til å spre etterspørselen etter datakilden.
• Bruk trinnvis dataoppdatering for å redusere belastningen på datakilden.
• Reduser antallet Power BI-dataoppdateringer ved å konsolidere flere semantiske modeller til en delt semantisk modell.
• Juster innstillingene for automatisk sideoppdatering for å øke oppdateringsfrekvensen, og reduser derfor belastningen på datakilden.
• Forenkle beregninger for å redusere kompleksiteten i spørringer som sendes til datakilden.
• Endre datalagringsmodus (for eksempel til importmodus i stedet for DirectQuery) for å redusere konsekvent spørringsbelastning på datakilden.
• Bruk teknikker for spørringsreduksjon for å redusere antall spørringer som sendes til datakilden.

Systemansvarlige kan utføre andre handlinger. De kunne:

• Introduser et mellomliggende datalag, for eksempel Power BI-dataflyter (når et datalager ikke er et levedyktig alternativ). Power BI-innholdsopprettere kan bruke dataflytene som datakilde i stedet for å koble direkte til datakilder. Et mellomliggende datalag kan redusere belastningen på et kildesystem. Det har også den ekstra fordelen av å sentralisere dataforberedelseslogikk. Hvis du vil ha mer informasjon, kan du se det selvbetjente bruksscenarioet for klargjøring av data.
• Endre datakildeplasseringen for å redusere virkningen av nettverksventetid (for eksempel bruke samme dataområde for Power Bi-tjeneste, datakilder og gatewayer).
• Optimaliser datakilden slik at den mer effektivt henter data for Power BI. Flere commons-teknikker inkluderer oppretting av tabellindekser, oppretting av indekserte visninger, oppretting av faste beregnede kolonner, vedlikehold av statistikk, bruk av tabeller i minnet eller kolonnelager og oppretting av materialiserte visninger.
• Be brukere om å bruke en skrivebeskyttet replika av datakilden, i stedet for en opprinnelig produksjonsdatabase. En replika kan være tilgjengelig som en del av en databasestrategi med høy tilgjengelighet (HA). En fordel med en skrivebeskyttet replika er å redusere strid på kildesystemet.

Verktøyene og teknikkene du kan bruke til å overvåke datakilder, avhenger av teknologiplattformen. Databaseadministratoren kan for eksempel bruke utvidede hendelser eller spørringslageret for overvåking av Azure SQL Database og SQL Server-databaser.

Noen ganger får Power BI tilgang til en datakilde via en datagateway. Gatewayer håndterer tilkobling fra Power Bi-tjeneste til bestemte typer datakilder. De gjør imidlertid mer enn bare å koble til data. En gateway inkluderer en mashup-motor som utfører behandlings- og datatransformasjoner på maskinen. Den komprimerer og krypterer også dataene slik at de kan overføres effektivt og sikkert til Power Bi-tjeneste. Derfor kan en ikke-administrert eller ikke-optimalisert gateway bidra til flaskehalser for ytelse. Vi anbefaler at du snakker med gatewayadministratoren for å få hjelp til å overvåke gatewayer.

Tips

Power BI-administratoren kan kompilere en fullstendig leierbeholdning (som inkluderer avstamming) og få tilgang til brukeraktiviteter i aktivitetsloggen. Ved å relatere avstamming og brukeraktiviteter kan administratorer identifisere de mest brukte datakildene og gatewayene.

Hvis du vil ha mer informasjon om leierbeholdningen og aktivitetsloggen, kan du se Overvåking på leiernivå.

Sjekkliste – Når du planlegger å overvåke en datakilde, omfatter viktige beslutninger og handlinger:

• Bestem bestemte mål: Når du overvåker en datakilde, kan du få klarhet i nøyaktig hva du trenger for å oppnå og målene for feilsøking.
• Samarbeid med databaseadministratorer: Samarbeid med databasen eller systemansvarlige for å få hjelp når de overvåker en bestemt datakilde.
• Samarbeid med gatewayadministratorer: Samarbeid med gatewayadministratorer for datakilder som kobler til via en datagateway, ved feilsøking av gatewayen.
• Koble til kundestøtteteamet og databaseadministratorer: Kontroller at kundestøtteteamet vet hvordan du kontakter de riktige administratorene for hver datakilde (for eksempel når du feilsøker spørringsdelegering).
• Oppdater opplæring og veiledning: Inkluder viktig informasjon og tips for dataopprettere om hvordan du arbeider med organisasjonsdatakilder. Inkluder informasjon om hva du skal gjøre når noe går galt.

Overvåking av dataoppdatering

En dataoppdateringsoperasjon innebærer å importere data fra underliggende datakilder til en semantisk Power BI-modell, dataflyt eller datamart. Du kan planlegge en dataoppdateringsoperasjon eller kjøre den ved behov.

Serviceavtale

IT bruker vanligvis serviceavtaler (SLAer) til å dokumentere forventningene til dataressurser. Vurder å bruke en serviceavtale for kritisk innhold eller innhold på bedriftsnivå for Power BI. Det inkluderer vanligvis når brukere kan forvente at oppdaterte data i en semantisk modell er tilgjengelig. Du kan for eksempel ha en serviceavtale som alle dataoppdateringer må fullføre innen kl. 07.00 hver dag.

Semantiske modelllogger

Hendelsesloggene for semantisk modell fra Azure Log Analytics eller SQL Profiler (beskrevet tidligere i denne artikkelen) inneholder detaljert informasjon om hva som skjer i en semantisk modell. De registrerte hendelsene inkluderer semantisk modelloppdateringsaktivitet. Hendelsesloggene er spesielt nyttige når du trenger å feilsøke og undersøke semantiske modelloppdateringer.

Semantiske modeller for Premium-kapasitet

Når du har innhold som driftes i en Power BI Premium-kapasitet, har du flere muligheter til å overvåke dataoppdateringsoperasjoner.

• Sammendragssiden for Power BI-oppdateringer i administrasjonsportalen inneholder et sammendrag av oppdateringsloggen. Dette sammendraget gir informasjon om varighet og feilmeldinger for oppdatering.
• Power BI Premium-bruks- og måledataappen inneholder også nyttig oppdateringsinformasjon. Det er nyttig når du må undersøke oppdateringsaktivitet for en Power BI Premium-kapasitet (P SKU) eller Power BI Embedded (A SKU)-kapasitet.

Forbedrede semantiske modelloppdateringer

Innholdsopprettere kan starte semantiske modelloppdateringer programmatisk ved hjelp av forbedret oppdatering med Oppdater datasett i gruppens REST-API for Power BI. Når du bruker forbedret oppdatering, kan du overvåke historiske, gjeldende og ventende oppdateringsoperasjoner.

Overvåking av tidsplan for dataoppdatering

Power BI-administratorer kan overvåke tidsplaner for dataoppdatering i leieren for å avgjøre om det er planlagt mange oppdateringsoperasjoner samtidig i løpet av en bestemt tidsramme (for eksempel mellom 05.00 og 07.00, noe som kan være et spesielt travelt dataoppdateringstidspunkt). Administratorer har tillatelse til å få tilgang til metadataene for semantisk modelloppdatering fra API-ene for skanning av metadata, som kalles skanner-API-er.

Power BI REST API-er

For kritiske semantiske modeller må du ikke stole utelukkende på e-postvarsler for overvåking av problemer med dataoppdatering. Vurder å kompilere dataoppdateringsloggen i et sentralisert lager der du kan overvåke, analysere og behandle den.

Du kan hente dataoppdateringsloggen ved hjelp av:

• Hent oppdateringslogg i REST-API-en for gruppe for å hente oppdateringsinformasjon for et arbeidsområde.
• Hent oppdateringer for REST-API-en for kapasitet for å hente oppdateringsinformasjon for en kapasitet.

Tips

Vi anbefaler på det sterkeste at du overvåker oppdateringsloggen for semantiske modeller for å sikre at gjeldende data er tilgjengelige for rapporter og instrumentbord. Det hjelper deg også å vite om SLAer blir oppfylt.

Sjekkliste – Når du planlegger overvåking av dataoppdatering, omfatter viktige beslutninger og handlinger:

• Bestem bestemte mål: Når du overvåker dataoppdateringer, kan du få klarhet i nøyaktig hva du trenger å oppnå og hva omfanget av overvåking skal være (for eksempel semantiske modeller for produksjon, sertifiserte semantiske modeller og andre).
• Vurder å konfigurere en serviceavtale: Bestem om en serviceavtale vil være nyttig for å angi forventninger til datatilgjengelighet og når tidsplaner for dataoppdatering skal kjøres.
• Samarbeid med database- og gatewayadministratorer: Samarbeid med database- eller systemansvarlige og gatewayadministratorer for å overvåke eller feilsøke dataoppdatering.
• Kunnskapsoverføring for kundestøtteteamet: Kontroller at kundestøtteteamet vet hvordan de kan hjelpe innholdsopprettere når det oppstår problemer med dataoppdatering.
• Oppdater opplæring og veiledning: Inkluder viktig informasjon og tips for dataopprettere om hvordan du oppdaterer data fra organisasjonsdatakilder og vanlige datakilder. Inkluder anbefalte fremgangsmåter og organisasjonsinnstillinger for hvordan du administrerer dataoppdatering.
• Bruk en e-postadresse for kundestøtte for varsler: Hvis du vil ha kritisk innhold, konfigurerer du oppdateringsvarsler til å bruke en e-postadresse for kundestøtte.
• Konfigurer sentralisert oppdateringsovervåking: Bruk REST-API-ene for Power BI til å kompilere dataoppdateringsloggen.

Dataflytovervåking

Du oppretter en Power BI-dataflyt med Power Query Online. Mange av funksjonene for spørringsytelse, og Power Query-diagnostikken, som ble beskrevet tidligere, gjelder.

Du kan også angi arbeidsområder til å bruke Azure Data Lake Storage Gen2 for dataflytlagring (kjent som bring-your-own-storage) i stedet for intern lagringsplass. Når du bruker bring-your-own-storage, bør du vurdere å aktivere telemetri , slik at du kan overvåke måledata for lagringskontoen. Hvis du vil ha mer informasjon, kan du se det selvbetjente dataforberedelsesbruksscenarioet og det avanserte dataforberedelsesbruksscenarioet .

Du kan bruke REST-API-ene for Power BI til å overvåke dataflyttransaksjoner. Bruk for eksempel API-en Hent dataflyttransaksjoner til å kontrollere statusen for dataflytoppdateringer.

Du kan spore brukeraktiviteter for Power BI-dataflyter med Power BI-aktivitetsloggen. Hvis du vil ha mer informasjon, kan du se Overvåking på leiernivå.

Tips

Det finnes mange anbefalte fremgangsmåter du kan ta i bruk for å optimalisere dataflytutformingene. Hvis du vil ha mer informasjon, kan du se Anbefalte fremgangsmåter for dataflyter.

Datamart-overvåking

Et Power BI-datamart inneholder flere integrerte komponenter, inkludert en dataflyt, en administrert database og en semantisk modell. Se de forrige delene av denne artikkelen for å finne ut mer om overvåking og overvåking av hver komponent.

Du kan spore brukeraktiviteter for Power BI-datamarts ved hjelp av Power BI-aktivitetsloggen. Hvis du vil ha mer informasjon, kan du se Overvåking på leiernivå.

Relatert innhold

I den neste artikkelen i denne serien kan du lære mer om overvåking på leiernivå.