> For the complete documentation index, see [llms.txt](https://docs.powermonitor.com.br/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.powermonitor.com.br/en/technical-documentation/documentacao-tecnica.md).

# System Technical Documentation

Consolidated Power Monitor technical documentation: architecture, data collection, continuous monitoring, data model, security, and installation.

Power Tuning · [powermonitor.com.br](https://powermonitor.com.br)

This page brings together, in one place, the technical view of Power Monitor for IT, architecture, and security teams. Each topic has its own page with more details.

***

## Table of contents

1. [What is Power Monitor](#1-what-is-power-monitor)
2. [Architecture](#2-architecture)
3. [Data collection (scans)](#3-data-collection-scans)
4. [Continuous monitoring and alerts](#4-continuous-monitoring-and-alerts)
5. [Data model](#5-data-model)
6. [Security and privacy](#6-security-and-privacy)
7. [Installation and permissions](#7-installation-and-permissions)

***

## 1. What is Power Monitor

**Power Monitor** is a **multi-tenant SaaS** platform from Power Tuning for **monitoring, governance, data quality, and audit** of **Microsoft Fabric** and **Power BI** environments. It connects to the customer's tenant through the official Microsoft APIs, collects **metadata and operational status**, and automatically notifies you when something fails or deviates from the norm.

| Characteristic            | Detail                                                                             |
| ------------------------- | ---------------------------------------------------------------------------------- |
| **100% SaaS**             | Access through the browser; nothing is installed in the customer's environment     |
| **Metadata only**         | Does not copy or store the business data of models and reports                     |
| **Sign-in with Entra ID** | Only Microsoft accounts from the customer's tenant, registered in the organization |
| **Continuous monitoring** | Checks in cycles ranging from 30 seconds to a few hours, depending on the type     |
| **Multilingual**          | Portuguese, English, Spanish, Italian, and Japanese                                |
| **Free trial**            | 30 days                                                                            |

The features are described in [Main Features](/en/principais-funcionalidades.md).

***

## 2. Architecture

The platform runs on **Microsoft Azure** and consists of:

* **Web portal and REST API** (ASP.NET Core, .NET 10, with an SPA in Vue.js 3 + TypeScript), which also processes the scan queue in the background;
* **Azure Functions** with dozens of scheduled and queue-triggered jobs (health checks every 30 seconds, capacity consumption, anomalies, activity events, costs, capacity schedules, billing, and notifications);
* **PostgreSQL** (Entity Framework Core 10), with data isolated per organization;
* **Azure Key Vault** for the encryption keys of customer credentials;
* **Azure Storage Queues** to distribute work among the jobs;
* **Email** (SendGrid or the customer's SMTP) and **Teams, Slack, and Telegram** through the Power Tuning bot service;
* **OpenTelemetry** for observability.

Microsoft integrations: Power BI REST and Admin APIs (including the Scanner API), Fabric REST APIs, Power BI query API (for the Fabric Capacity Metrics app), XMLA (model structure and size), Fabric SQL endpoints (Query Insights), Microsoft Graph, Azure Resource Manager, and Cost Management.

Details in [Architecture Overview](/en/technical-documentation/documentacao-tecnica/visao-geral.md).

***

## 3. Data collection (scans)

* Scans are placed in a **persistent queue** in the database and processed **one task at a time per organization**, with progress, result, and error logging (**Mapping › Scan Logs**).
* Main types: **Full**, **Incremental**, **Capacity**, **Gateway**, **Connection**, **App**, **DatasetConnection**, and **DataflowConnection**, in addition to specialized collections (model size, report structure, model mapping, domains, activity events, costs, per-item consumption metrics).
* Execution: at the end of the installation, **daily** (03:00 UTC), and on demand by administrators.
* The full scan uses the **Scanner API** (`admin/workspaces/getInfo`) in batches of up to 100 workspaces, with lineage, data sources, model schema and expressions, and users with access.
* Items that disappear from the tenant are **marked as deleted** and leave the counts.
* Only **monitored workspaces** are included in the screens, alerts, and billing.

Details in [Scan Flow](/en/technical-documentation/documentacao-tecnica/fluxo-de-scans.md).

***

## 4. Continuous monitoring and alerts

| Check                                                       | Cadence    |
| ----------------------------------------------------------- | ---------- |
| Gateway status                                              | 5 minutes  |
| Semantic model refresh failures (on capacity)               | 15 minutes |
| Runs of pipelines, notebooks, Copy jobs, and Dataflows Gen2 | 2 hours    |
| Capacity consumption (Fabric Capacity Metrics)              | 5 minutes  |
| Consumption anomalies by item                               | 5 minutes  |
| Data Freshness and Fabric Mirroring                         | 10 minutes |
| Execution time deviation                                    | 1 hour     |
| Capacity cost                                               | Daily      |

* Each resource has a **health state** (Unknown, Healthy, Degraded, Unhealthy). The first failure **opens an incident**; recovery **closes** it with the **Alert Resolved** notice.
* For gateways, models, and Fabric items, the email is sent **when the incident is opened and when it is resolved**; recurrences appear in the **Hourly Checklist**. The capacity usage limit (80%) generates notices while it persists.
* Channels: **email**, **Microsoft Teams**, **Slack**, and **Telegram**. Recipients per alert type, respecting each user's workspace scope.

Details in [Continuous Monitoring](/en/technical-documentation/documentacao-tecnica/monitoramento-continuo.md) and [Real-time alerts](/en/principais-funcionalidades/alertas-em-tempo-real.md).

***

## 5. Data model

* **Organization** (one Entra ID tenant), **users and profiles**, **workspaces**, and **34 item types** (reports, semantic models, dashboards, dataflows, lakehouses, warehouses, notebooks, pipelines, eventstreams, and other Fabric items), in addition to capacities, gateways, connections, and apps.
* Scan and monitoring **tasks**, **health states**, **alerts**, **history** of refreshes, runs, and consumption, **costs**, and **anomalies**.
* **Audit**: tenant activity events, application events, sent emails, and capacity actions.
* **Billing**: daily measurement of monitored items, monthly fees, and onboarding fee installments.
* Every customer record belongs to an organization; dates are stored in UTC.

Details in [Data Model](/en/technical-documentation/documentacao-tecnica/modelo-de-dados.md).

***

## 6. Security and privacy

* **Isolation per organization:** every query is filtered by the authenticated user's organization, obtained from the sign-in identity. Resources from another organization are treated as nonexistent.
* **Authentication:** OpenID Connect with Microsoft Entra ID; only registered users can sign in. **Authorization:** roles (User, Administrator), profiles, workspace scope, and page blocking, with write actions validated on the server.
* **Credentials:** envelope encryption (AES-256, with the key protected by RSA-OAEP-256 in **Azure Key Vault**). The secret never returns to the browser.
* **Tenant access:** through the customer's own Service Principal; specific actions use the delegated token of the administrator who performs them. The temporary permissions of the automatic installation are revoked at the end.
* **Audit:** sign-ins, pages accessed, and configuration changes recorded with user, date/time, and IP.
* **AI:** only with the provider configured by the organization itself; it sends metadata and metrics (never the content of the data), with usage logging and monthly limits.
* **End of contract:** the stored data is permanently deleted.

Details in [Data security and privacy](/en/perguntas-frequentes/duvidas-tecnicas/seguranca-e-privacidade.md).

***

## 7. Installation and permissions

* **Automatic installation:** the wizard creates **PowerMonitor-APP** (App Registration and Service Principal), the client secret, and the **PowerMonitor-Group** group, assigns the Graph **Directory.Read.All** application permission, and applies the **Fabric tenant settings** to the group. It requires a Global Administrator and, for the Fabric settings, a Fabric Administrator.
* **Manual installation:** the customer provides the Client ID, Client Secret, and, optionally, the Group ID of an existing App Registration, and enables the tenant settings themselves.
* **Required tenant settings:** `AllowServicePrincipalsUseReadAdminAPIs`, `AdminApisIncludeDetailedMetadata`, `AdminApisIncludeExpressions`, and `ServicePrincipalAccessGlobalAPIs`.
* **Additional permissions** (optional): Graph read access (secret expiration, users, and groups), gateway administration, Teams bot, Azure roles for capacities (Administrator, Contributor, Reader) and costs (Cost Management Reader).
* **Writing to the tenant:** collection is read-only; changes only occur in explicit actions (configuration during installation, granting access to the application, pausing/scaling capacities, reprocessing refreshes, and changing schedules).

Details in [Prerequisites](/en/technical-documentation/instalacao/pre-requisitos.md), [Installation step by step](/en/technical-documentation/instalacao/passo-a-passo.md), and [How do I install Power Monitor?](/en/readme/como-instalar-o-power-monitor.md)

***

## References

* [Power Monitor website](https://powermonitor.com.br)
* [Schedule an installation (30-day free trial)](https://powermonitor.com.br/instalacao)
* [Power Tuning](https://powertuning.com.br)
* [Microsoft Learn: Microsoft Fabric](https://learn.microsoft.com/fabric/)
* [Microsoft Learn: Power BI REST APIs](https://learn.microsoft.com/rest/api/power-bi/)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.powermonitor.com.br/en/technical-documentation/documentacao-tecnica.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.