Administrace a monitoring

Administrace Power BI a Fabricu znamená práci na úrovni celého tenantu, ne jednoho workspace. Klíčová role je Fabric Administrator — sjednocená role, která je nadmnožinou dřívějšího „Power BI Admin"; obě agendy jsou dnes pod jednou střechou. Power Platform Administrator má implicitně také práva Fabric admina. Nad oběma stojí Global Administrator v Microsoft Entra ID, který má administrátorská práva napříč celým tenantem, Fabric nevyjímaje.

Primární cesta k administraci je dnes podle dokumentace OneLake catalog → Govern → Configurations → Tenant settings (a odtud dál Workspaces, Capacities a další oblasti správy). Tam, kde se OneLake catalog a Govern do daného regionu ještě nedostaly (postupný regionální rollout), platí jako záložní cesta Settings (ozubené kolo) → Admin portal — starší rozhraní se stejným obsahem.

Tenant setting může mít podle dokumentace pět stavů: Disabled for the entire organization, Enabled for the entire organization, Enabled for the entire organization except for certain groups, Enabled for a subset of the organization (konkrétní bezpečnostní skupiny) a Enabled for specific groups except for certain groups (kombinace povolené a vyloučené skupiny, platí vždy nejrestriktivnější pravidlo pro daného uživatele). Cílení na bezpečnostní skupiny umožňuje postupné, kontrolované zavádění funkce — třeba jen pro pilotní tým, než se pustí na celý tenant.

Cesta k tenant settings: OneLake catalog → Govern → Configurations → Tenant settings (fallback při postupném regionálním rollout: Settings → Admin portal → Tenant settings). Změna se do celého tenantu projeví do 15 minut — není okamžitá, což je důležité vědět při troubleshootingu i při demu („nastavil jsem to, ale ještě to nevidím" může být jen otázka pár minut čekání).

Pár nastavení má neúměrně velký dopad, pokud jsou nastavená špatně. Následující výběr patří mezi ta, která byste měli zkontrolovat jako první:

Přístup: workspace → report → … → View usage metrics report (případně přímo Open usage metrics, podle verze rozhraní). Ukazuje počet zobrazení a unikátní uživatele v čase, rozpad podle Distribution (jak se ke konzumentovi obsah dostal — sdílení, workspace, app) a podle Platform (web, mobilní aplikace, embedded) a výkonnost otevírání reportu. Report lze zkopírovat a upravit do vlastního monitoring dashboardu.

Prerekvizity: Pro nebo PPU licence, edit přístup k reportu (role Contributor a vyšší ve workspace) a zapnutý tenant setting Usage metrics for content creators (skupina Audit and usage settings) — bez něj Fabric administrátor funkci pro organizaci vypnul.

Existují dvě varianty vedle sebe:

Monitoring hub sleduje položky, na které má přihlášený uživatel přístup — refresh historii, selhání, běžící operace. Je to first-line nástroj pro běžného vlastníka obsahu, ne administrátorský nástroj pro celý tenant.

Admin monitoring workspace jde dál — obsahuje širší sadu reportů (audit, inventář obsahu) nad celým tenantem a administrátor ho může zpřístupnit i uživatelům bez administrátorské role, typicky přidáním do role Viewer ve workspace nebo sdílením konkrétní položky — na rozdíl od Build permission u běžných sémantických modelů zde jde hlavně o standardní sdílení workspace obsahu. Přístup jednou uděleným uživatelům nejde odebrat jinak než reinicializací workspace. Podle jednoho z Learn dokumentů je Admin monitoring workspace uveden jako preview funkce — přesný stav ověřte v dokumentaci.

Instalace z AppSource: vyhledejte „Microsoft Fabric Capacity Metrics" a připojte ji ke konkrétní kapacitě. Aplikace ukazuje CU % využití v čase, throttling events (kdy a co bylo zpomaleno) a top items podle CU spotřeby.

Operace se dělí na dva typy s rozdílnou prioritou při přetížení:

• Interactive — dotaz uživatele (otevření reportu, interakce s vizuálem) — při přetížení je brzděn jako první
• Background — refresh, pipeline, scheduled operace — nižší priorita, ale zpoždění tu bolí jinak (data nejsou aktuální)

Pro orientaci v číslech, které Capacity Metrics app ukazuje: kapacita F2 odpovídá 2 CU, tedy 2 × 3600 = 7 200 CU-sekund za hodinu dostupných pro veškeré výpočty na této kapacitě. Konkrétní spotřeba jednotlivých operací (refresh, DAX dotaz) se liší podle modelu a dotazu natolik, že univerzální čísla nemají smysl — první orientaci dá až pohled do vlastní Capacity Metrics app po pár dnech provozu.

Smoothing rozprostírá spotřebu CU v čase, aby krátké špičky nevedly hned k omezení: interaktivní operace se rozprostírají v okně 5 až 64 minut, operace na pozadí přes 24 hodin (v timepointech po 30 sekundách). Smoothing snižuje pravděpodobnost throttlingu, ale negarantuje, že k němu nedojde.

Odkaz na audit log v Admin portálu vede do Microsoft Purview — samotný audit log v portálu fyzicky není, portál na něj jen odkazuje. Podle dokumentace se většina událostí Power BI/Fabric aktivit objeví v auditním logu do 30 minut, se zpožděním až 60 minut; pro core služby Microsoft 365 obecně platí orientační SLA 60–90 minut.

Pro programový přístup k aktivitám existuje Activity Events API (Power BI REST API) — vrací maximálně jeden den dat na jeden request (start a end date musí být stejný den, v UTC), se stránkováním přes continuation token. PowerShell cmdlet Get-PowerBIActivityEvent má stejné omezení jako REST API — jedno volání pokryje jeden den, ne čtyři týdny — ale sám za vás řeší continuation token a stránkování napříč velkým počtem záznamů. Activity log jako celek drží data maximálně 28 dní zpětně; pro delší historii je nutný pravidelný, alespoň denní export do vlastního úložiště.

Pro strukturální metadata (kdo má co, jaké míry, jaké role, jaké datasources) slouží Scanner API (metadata scanning), postavené na sekvenci volání GetModifiedWorkspaces → PostWorkspaceInfo → GetScanStatus → GetScanResult.

Tři hlavní cesty, jak automatizovat správu Power BI/Fabric obsahu:

• Power BI / Fabric REST API — přímá volání, např. refresh sémantického modelu, správa workspace, přiřazení kapacity
• MicrosoftPowerBIMgmt PowerShell modul — instalace přes Install-Module -Name MicrosoftPowerBIMgmt, obsahuje submoduly Admin, Capacities, Data, Profile, Reports, Workspaces; cmdlety s parametrem -Scope Organization operují nad celým tenantem a vyžadují administrátorskou roli
• fabric-cicd — oficiální, Microsoft-podporovaná open-source Python knihovna pro nasazování Fabric položek (včetně PBIP) ze source control, s klíčovými funkcemi publish_all_items() a unpublish_all_orphan_items(); integruje se s Fabric Git integrací, REST API a Fabric CLI

Prerekvizity pro automatizaci pod service principalem se liší podle toho, jaké API voláte:

• Uživatelské REST API (refresh, správa obsahu v rámci běžných Power BI oprávnění) — tenant setting Service principals can call Fabric public APIs (Developer settings, viz sekce 7.4) a v případě potřeby i oddělené Service principals can create workspaces, connections, and deployment pipelines
• Admin API (Scanner API, Activity Events API a další operace nad celým tenantem) — samostatná skupina Admin API settings: Service principals can access read-only admin APIs pro čtení a Service principals can access admin APIs used for updates pro zápisové admin operace

Service principal by měl být členem konkrétní bezpečnostní skupiny, na kterou je cílené povolení nastaveno — ne otevřený pro celý tenant. Protože admin API prerekvizity dávají přístup k metadatům celého tenantu bez vazby na konkrétní Power BI oprávnění, doporučuje se je držet pod přísnou kontrolou a přiřazovat jen vybraným service principalům.

# pripojeni sluzebnim uctem / interaktivne (podle konfigurace tenantu)
Connect-PowerBIServiceAccount

# stazeni activity events za jeden den (placeholder datumy)
$events = Get-PowerBIActivityEvent `
    -StartDateTime '<YYYY-MM-DD>T00:00:00' `
    -EndDateTime '<YYYY-MM-DD>T23:59:59' `
    -ActivityType 'ViewReport'

$events | ConvertFrom-Json | Export-Csv -Path '<cesta-k-exportu>.csv' -NoTypeInformation

# obecne volani REST API, napr. refresh datasetu (placeholder ID)
Invoke-PowerBIRestMethod -Url "groups/<workspace-id>/datasets/<dataset-id>/refreshes" -Method Post

Built-in nástroje pokrývají většinu běžných potřeb, ale mají pevné limity: Usage Metrics a Capacity Metrics app mají omezenou retenci (viz sekce 7.5 a 7.7), nejde v nich kombinovat data z více zdrojů a nejdou snadno automatizovat do vlastních alertů. Když tohle nestačí, řešením je stáhnout si data přes Scanner API a Activity Events API do vlastního úložiště a postavit nad tím vlastní report bez časového omezení.

Sedm kapitol tohoto kurzu tvoří sedm vrstev jedné architektury správy Power BI obsahu v Microsoft Fabricu:

• Administrator roles in Fabric (EN)
• Developer settings — service principals (EN)
• Usage Metrics report (klasický) (EN)
• Modern Usage Metrics report (EN)
• Capacity Metrics app — features (EN)
• Throttling — triggers and stages (EN)
• Admin monitoring workspace (EN)
• Metadata scanning (Scanner API) overview (EN)
• Activity log / Activity Events API (EN)
• fabric-cicd — deploy Fabric items (EN)