Отчёт опубликован — но живёт ли он? Кто его открывает, какие страницы смотрят, не упёрлись ли вы в ёмкость, кто поменял доступ? Без ответов эксплуатация слепа. Power BI даёт несколько инструментов наблюдения — от метрик использования отчёта до журнала аудита всего тенанта.
Не про создание отчётов, а про наблюдаемость: данные о самой системе Power BI, которые нужны тем, кто отвечает за прод.
Метрики использования отчёта (usage metrics)
Самое прикладное: по каждому отчёту в Service доступен отчёт об использовании — сколько просмотров, уникальных пользователей, с каких устройств, динамика во времени.
Метрики использования отвечают на вопросы, без которых нельзя приоритизировать: какими отчётами реально пользуются, а какие мертвы (можно вывести из эксплуатации); кто аудитория; растёт ли спрос. Оптимизировать и поддерживать имеет смысл то, что используют, — а это видно только из метрик.
Журнал аудита и активность (audit log)
Для администратора есть журнал аудита (через Microsoft Purview / админ-портал) и лог активности — кто что делал на уровне тенанта: создал/удалил отчёт, поменял доступ, экспортировал данные, опубликовал приложение.
Это нужно для:
- безопасности — кто открыл доступ, кто выгрузил данные;
- расследований — «кто удалил этот датасет и когда»;
- комплаенса — отчётность перед ИБ.
Ёмкость: Premium / Fabric capacity metrics
Если контент живёт на выделенной ёмкости (Premium/PPU/Fabric), у неё есть лимит ресурсов. Специальное приложение Capacity Metrics показывает нагрузку: CPU, память, очереди обновлений, троттлинг.
Если отчёты разом начали тормозить независимо от их сложности — подозревайте ёмкость, а не конкретную меру. Capacity Metrics покажет, упёрлись ли вы в CPU/память, какие обновления и интерактивные запросы съедают ресурс. Это другой уровень диагностики, чем Performance Analyzer для одного отчёта (урок про оптимизацию): там — один отчёт, здесь — вся ёмкость.
Мониторинг обновлений
Отдельно стоит следить за расписанием обновления: какие датасеты обновляются, сколько длится, что падает. История обновлений в настройках датасета показывает сбои и их причины (часто — шлюз, истёкшие учётки, тайм-ауты источника). Настройте уведомления об ошибках обновления, чтобы узнавать о сбое раньше пользователей.
Без мониторинга проблемы всплывают через жалобы пользователей — поздно и репутационно дорого. Минимум для прода: следить за ошибками обновления (алерты), периодически смотреть метрики использования (что живо), а на выделенной ёмкости — Capacity Metrics. Это дешёвая страховка против «внезапно всё сломалось».
Что дальше
Систему видно и под контролем. Дальше — как переиспользовать подготовку данных между моделями, чтобы не дублировать ETL: dataflows. Следующий урок.