> 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/es/documentacion-tecnica/documentacao-tecnica.md).

# Documentación Técnica del Sistema

Documentación técnica consolidada del Power Monitor: arquitectura, recopilación de datos, monitoreo continuo, modelo de datos, seguridad e instalación.

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

Esta página reúne, en un solo lugar, la visión técnica del Power Monitor para los equipos de TI, arquitectura y seguridad. Cada tema tiene una página propia con más detalles.

***

## Índice

1. [Qué es el Power Monitor](#1-que-es-el-power-monitor)
2. [Arquitectura](#2-arquitectura)
3. [Recopilación de datos (escaneos)](#3-recopilacion-de-datos-escaneos)
4. [Monitoreo continuo y alertas](#4-monitoreo-continuo-y-alertas)
5. [Modelo de datos](#5-modelo-de-datos)
6. [Seguridad y privacidad](#6-seguridad-y-privacidad)
7. [Instalación y permisos](#7-instalacion-y-permisos)

***

## 1. Qué es el Power Monitor

El **Power Monitor** es una plataforma **SaaS multi-tenant** de Power Tuning para el **monitoreo, la gobernanza, la calidad de datos y la auditoría** de entornos **Microsoft Fabric** y **Power BI**. Se conecta al tenant del cliente mediante las APIs oficiales de Microsoft, recopila **metadatos y estado operativo** y avisa automáticamente cuando algo falla o se sale de lo normal.

| Característica                    | Detalle                                                                       |
| --------------------------------- | ----------------------------------------------------------------------------- |
| **100% SaaS**                     | Acceso desde el navegador; no se instala nada en el entorno del cliente       |
| **Solo metadatos**                | No copia ni almacena los datos de negocio de los modelos e informes           |
| **Inicio de sesión con Entra ID** | Solo cuentas Microsoft del tenant del cliente, registradas en la organización |
| **Monitoreo continuo**            | Verificaciones en ciclos de 30 segundos a unas pocas horas, según el tipo     |
| **Multilingüe**                   | Portugués, inglés, español, italiano y japonés                                |
| **Prueba gratuita**               | 30 días                                                                       |

Las funcionalidades se describen en [Funcionalidades principales](/es/principais-funcionalidades.md).

***

## 2. Arquitectura

La plataforma se ejecuta en **Microsoft Azure** y está compuesta por:

* **Portal web y API REST** (ASP.NET Core, .NET 10, con SPA en Vue.js 3 + TypeScript), que también procesa la cola de escaneos en segundo plano;
* **Azure Functions** con decenas de jobs programados y activados por cola (health checks cada 30 segundos, consumo de capacidades, anomalías, eventos de actividad, costos, programaciones de capacidad, facturación y notificaciones);
* **PostgreSQL** (Entity Framework Core 10), con los datos aislados por organización;
* **Azure Key Vault** para las claves de cifrado de las credenciales de los clientes;
* **Azure Storage Queues** para distribuir el trabajo entre los jobs;
* **Correo** (SendGrid o SMTP del cliente) y **Teams, Slack y Telegram** mediante el servicio de bot de Power Tuning;
* **OpenTelemetry** para la observabilidad.

Integraciones con Microsoft: Power BI REST y Admin APIs (incluida la Scanner API), Fabric REST APIs, API de consultas de Power BI (para la aplicación Fabric Capacity Metrics), XMLA (estructura y tamaño de los modelos), endpoints SQL de Fabric (Query Insights), Microsoft Graph, Azure Resource Manager y Cost Management.

Detalles en [Visión general de la arquitectura](/es/documentacion-tecnica/documentacao-tecnica/visao-geral.md).

***

## 3. Recopilación de datos (escaneos)

* Los escaneos se almacenan en una **cola persistente** en la base de datos y se procesan **una tarea a la vez por organización**, con registro del progreso, el resultado y los errores (**Mapeo › Registros de Escaneos**).
* Tipos principales: **Full**, **Incremental**, **Capacity**, **Gateway**, **Connection**, **App**, **DatasetConnection** y **DataflowConnection**, además de recopilaciones especializadas (tamaño de modelos, estructura de informes, mapeo de modelos, dominios, eventos de actividad, costos, métricas de consumo por elemento).
* Ejecución: al final de la instalación, **diariamente** (03:00 UTC) y a demanda por parte de los administradores.
* El escaneo completo utiliza la **Scanner API** (`admin/workspaces/getInfo`) en lotes de hasta 100 workspaces, con linaje, orígenes de datos, esquema y expresiones de los modelos y usuarios con acceso.
* Los elementos que desaparecen del tenant se **marcan como eliminados** y salen de los recuentos.
* Solo los **workspaces monitoreados** aparecen en las pantallas, las alertas y la facturación.

Detalles en [Flujo de escaneos](/es/documentacion-tecnica/documentacao-tecnica/fluxo-de-scans.md).

***

## 4. Monitoreo continuo y alertas

| Verificación                                                    | Cadencia   |
| --------------------------------------------------------------- | ---------- |
| Estado de gateways                                              | 5 minutos  |
| Fallas de actualización de modelos semánticos (en capacidad)    | 15 minutos |
| Ejecuciones de pipelines, notebooks, Copy jobs y Dataflows Gen2 | 2 horas    |
| Consumo de las capacidades (Fabric Capacity Metrics)            | 5 minutos  |
| Anomalías de consumo por elemento                               | 5 minutos  |
| Actualización de Datos y Fabric Mirroring                       | 10 minutos |
| Desviación del tiempo de ejecución                              | 1 hora     |
| Costo de capacidad                                              | Diario     |

* Cada recurso tiene un **estado de salud** (Unknown, Healthy, Degraded, Unhealthy). La primera falla **abre un incidente**; la recuperación lo **cierra** con el aviso **Alerta Resuelta**.
* Para gateways, modelos y elementos de Fabric, el correo se envía **en la apertura y en la resolución**; las reincidencias aparecen en el **Checklist Cada Hora**. El límite de uso de capacidad (80%) genera avisos mientras persista.
* Canales: **correo**, **Microsoft Teams**, **Slack** y **Telegram**. Destinatarios por tipo de alerta, respetando el alcance de workspaces de cada usuario.

Detalles en [Monitoreo continuo](/es/documentacion-tecnica/documentacao-tecnica/monitoramento-continuo.md) y [Alertas en tiempo real](/es/principais-funcionalidades/alertas-em-tempo-real.md).

***

## 5. Modelo de datos

* **Organización** (un tenant de Entra ID), **usuarios y perfiles**, **workspaces** y **34 tipos de elemento** (informes, modelos semánticos, dashboards, dataflows, lakehouses, warehouses, notebooks, pipelines, eventstreams y demás elementos de Fabric), además de capacidades, gateways, conexiones y apps.
* **Tareas** de escaneo y monitoreo, **estados de salud**, **alertas**, **historiales** de actualizaciones, ejecuciones y consumo, **costos** y **anomalías**.
* **Auditoría**: eventos de actividad del tenant, eventos de la aplicación, correos enviados y acciones de capacidad.
* **Facturación**: medición diaria de los elementos monitoreados, mensualidades y cuotas de la tarifa de adhesión.
* Todo registro de cliente pertenece a una organización; las fechas se guardan en UTC.

Detalles en [Modelo de datos](/es/documentacion-tecnica/documentacao-tecnica/modelo-de-dados.md).

***

## 6. Seguridad y privacidad

* **Aislamiento por organización:** toda consulta se filtra por la organización del usuario autenticado, obtenida de la identidad del inicio de sesión. Los recursos de otra organización se tratan como inexistentes.
* **Autenticación:** OpenID Connect con Microsoft Entra ID; solo ingresan los usuarios registrados. **Autorización:** roles (Usuario, Administrador), perfiles, alcance de workspaces y bloqueo de páginas, con las acciones de escritura validadas en el servidor.
* **Credenciales:** cifrado de sobre (AES-256, con la clave protegida por RSA-OAEP-256 en **Azure Key Vault**). El secret nunca vuelve al navegador.
* **Acceso al tenant:** mediante el Service Principal del propio cliente; las acciones específicas usan el token delegado del administrador que las ejecuta. Los permisos temporales de la instalación automática se revocan al finalizar.
* **Auditoría:** inicios de sesión, páginas visitadas y cambios de configuración registrados con usuario, fecha/hora e IP.
* **IA:** solo con el proveedor configurado por la propia organización; envía metadatos y métricas (nunca el contenido de los datos), con registro de uso y límites mensuales.
* **Fin del contrato:** los datos almacenados se eliminan definitivamente.

Detalles en [Seguridad y privacidad de los datos](/es/perguntas-frequentes/duvidas-tecnicas/seguranca-e-privacidade.md).

***

## 7. Instalación y permisos

* **Instalación automática:** el asistente crea **PowerMonitor-APP** (App Registration y Service Principal), el client secret y el grupo **PowerMonitor-Group**, asigna el permiso de aplicación **Directory.Read.All** de Graph y aplica la **configuración de inquilino de Fabric** al grupo. Requiere Administrador global y, para la configuración de Fabric, Administrador de Fabric.
* **Instalación manual:** el cliente informa el Client ID, el Client Secret y, opcionalmente, el Group ID de un App Registration existente, y habilita él mismo la configuración de inquilino.
* **Configuración de inquilino obligatoria:** `AllowServicePrincipalsUseReadAdminAPIs`, `AdminApisIncludeDetailedMetadata`, `AdminApisIncludeExpressions` y `ServicePrincipalAccessGlobalAPIs`.
* **Permisos adicionales** (opcionales): lectura de Graph (vigencia del secret, usuarios y grupos), administración de gateways, bot de Teams, roles de Azure para capacidades (Administrador, Colaborador, Lector) y costos (Cost Management Reader).
* **Escritura en el tenant:** la recopilación es de solo lectura; los cambios solo se producen en acciones explícitas (configuración durante la instalación, concesión de accesos a la aplicación, pausa/escalado de capacidades, reprocesamiento de actualizaciones y modificación de programaciones).

Detalles en [Requisitos previos](/es/documentacion-tecnica/instalacao/pre-requisitos.md), [Paso a paso de la instalación](/es/documentacion-tecnica/instalacao/passo-a-passo.md) y [¿Cómo instalar el Power Monitor?](/es/readme/como-instalar-o-power-monitor.md)

***

## Referencias

* [Sitio del Power Monitor](https://powermonitor.com.br)
* [Agendar instalación (prueba gratuita de 30 días)](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/es/documentacion-tecnica/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.