> 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/visao-geral.md). # Overview Components, technologies, integrations, multi-tenancy, and security of the Power Monitor platform. Power Monitor is a **multi-tenant SaaS** application hosted by Power Tuning on **Microsoft Azure**. It collects metadata and status from each customer's Power BI / Microsoft Fabric environment through the official Microsoft APIs, stores this information in a relational database isolated per organization, and runs continuous checks that generate alerts. ## Components ``` ┌──────────────────────────────────────────────┐ Browser ─────▶ │ Web portal (SPA) + REST API │ (Entra ID) │ OpenID Connect authentication with Entra ID │ │ background scan processing │ └───────────────┬──────────────────────────────┘ │ ┌───────────────▼──────────────────────────────┐ │ Azure Functions (scheduled jobs and queues) │ │ health checks, consumption, anomalies, │ │ events, billing, notifications │ └───────────────┬──────────────────────────────┘ │ ┌──────────────────────────┼─────────────────────────────┐ ▼ ▼ ▼ PostgreSQL Azure Key Vault Azure Storage Queues (data per organization) (encryption keys) (work distribution) │ ▼ Microsoft APIs: Power BI / Fabric (REST, Admin, Scanner, XMLA), Microsoft Graph, Azure Resource Manager, Cost Management ``` | Component | Role | | ------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Web portal and API** | ASP.NET Core application that serves the portal (SPA) and the REST API it uses. It also runs the background processing of **scans** (persistent task queue) | | **Azure Functions** | Dozens of scheduled and queue-triggered jobs: health checks (every 30 seconds), capacity consumption, anomaly detection, activity events, costs, capacity schedules, checklists, billing, and emails | | **PostgreSQL** | Relational database with all organization data, isolated per organization | | **Azure Key Vault** | Stores the keys used to encrypt customer credentials | | **Azure Storage Queues** | Distribution of work among the jobs (for example, one message per organization) | | **Notification delivery** | Email (SendGrid or the customer's own SMTP) and Microsoft Teams, Slack, and Telegram through the Power Tuning bot service | | **Observability** | Tracing and structured logs with OpenTelemetry | ## Technologies | Layer | Technologies | | ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Backend** | .NET 10 / ASP.NET Core, Entity Framework Core 10 with Npgsql, NodaTime, MediatR (commands), FluentValidation, Microsoft Identity Web (OIDC), Azure Functions (isolated worker) | | **Frontend** | Vue.js 3, TypeScript, Vite, Vue Router, Pinia, Vue I18n (5 languages), Bootstrap, Axios; installable app (PWA) on phones and tablets | | **Data** | PostgreSQL, dates in UTC (`timestamptz`) | | **Email** | Razor templates rendered on the server; delivery through SendGrid or the organization's SMTP | ## Code organization The solution follows a layered architecture: | Layer | Responsibility | | ------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Domain** | Entities, business rules, commands, and validations. It does not depend on infrastructure | | **Application** | Use cases and services consumed by the API and the jobs | | **Scan and monitoring engines** | Execution of inventory scans and health checks, with one specification per task type | | **Infrastructure** | Integrations: database, Power BI/Fabric, Microsoft Graph, Azure (Key Vault, queues, costs), XMLA (Analysis Services), Fabric SQL endpoints, AI providers, email, notifications, IP geolocation, and billing | | **Web and Functions** | Hosts: API/portal and scheduled jobs | ## External integrations | Integration | Use | | ------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------ | | **Power BI REST and Admin APIs** (including the Scanner API) | Inventory, metadata, lineage, permissions, refresh history, gateways, capacities, activity events | | **Microsoft Fabric REST APIs** | Fabric item runs, schedules, Mirroring, domains | | **Power BI query API (executeQueries)** | DAX query to the Fabric Capacity Metrics app model (capacity consumption) | | **XMLA (Analysis Services)** | Reading the structure and size of models (VertiPaq) in the Model Size Scan and in the Performance Assessment | | **Fabric SQL endpoints** | Query Insights for warehouses and lakehouses | | **Microsoft Graph** | Automatic installation; reading users, groups, and members; client secret expiration | | **Azure Resource Manager and Cost Management** | Pausing, resuming, and scaling capacities; capacity cost | | **AI providers** (configured by the organization itself) | AI Assistant and suggestions | | **IP geolocation services** | Estimated country/state/city for view events | ## Multi-tenancy * Each customer is an **organization**, associated with a Microsoft Entra ID tenant. * All customer data records belong to an organization, and every query is **filtered by the authenticated user's organization**, obtained from the sign-in identity, never from parameters sent by the browser. * A resource that belongs to another organization is treated as **nonexistent** (the API does not reveal that it exists). * A second layer restricts the data of users with a **workspace scope**. ## Security * **Authentication:** OpenID Connect with Microsoft Entra ID. Only users registered in the organization can sign in; there are no Power Monitor-specific passwords. * **Authorization:** profiles and roles (User and Administrator), workspace scope, and page blocking. Write actions require an Administrator, validated on the server. * **Customer credentials:** Client ID, Client Secret, and AI provider keys are protected by **envelope encryption**: the data is encrypted with AES-256 and the AES key is encrypted with an RSA key (RSA-OAEP-256) kept in **Azure Key Vault**. The secret is never returned to the browser. * **Access to the customer's tenant:** through the customer's own Service Principal (client credentials) and, in specific actions, through the delegated token of the administrator who performs them. * **Audit:** sign-ins, pages accessed, and configuration changes are recorded with user, date/time, IP, and previous and new values (**Audit › Application Events**). * **Metadata only:** Power Monitor does not copy the content of the business data of models and reports. See [Data security and privacy](/en/perguntas-frequentes/duvidas-tecnicas/seguranca-e-privacidade.md). ## Related pages * [Scan Flow](/en/technical-documentation/documentacao-tecnica/fluxo-de-scans.md) * [Continuous Monitoring](/en/technical-documentation/documentacao-tecnica/monitoramento-continuo.md) * [Data Model](/en/technical-documentation/documentacao-tecnica/modelo-de-dados.md) --- # 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/visao-geral.md?ask=&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.