> 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/perguntas-frequentes/duvidas-gerais/como-funciona-o-monitoramento-proativo.md). # ¿Cómo funciona el monitoreo proactivo? Cómo el Power Monitor verifica su entorno de forma continua, con qué frecuencia y cómo le llegan las alertas. El monitoreo del Power Monitor es **continuo y automático**: no necesita abrir el sistema para descubrir que algo falló. El Power Monitor consulta su tenant mediante las APIs oficiales de Microsoft en ciclos regulares y, cuando detecta un problema, **abre un incidente y envía una alerta** a los destinatarios configurados. Cuando el problema se resuelve, envía el aviso de **resolución**. ### ¿Qué se verifica y con qué frecuencia? | Situación | Cómo se detecta | Frecuencia aproximada | | ----------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | --------------------- | | **Falla en la actualización de un modelo semántico** | Historial de actualizaciones de los modelos en capacidad, en todos los workspaces monitoreados | Cada 15 minutos | | **Falla en un elemento de Fabric** (pipeline de datos, notebook, Copy job, Dataflow Gen2) | Ejecuciones que terminan con error o cancelación | Cada 2 horas | | **Gateway sin conexión** | Estado de cada gateway en el que la aplicación del Power Monitor es administradora | Cada 5 minutos | | **Límite de uso de capacidad** | Uso acumulado de la capacidad, leído de la aplicación Fabric Capacity Metrics, igual o superior al **80%** | Cada 5 minutos | | **Uso en segundo plano elevado** | Consumo en segundo plano por franjas (50%, 70%, 80% y 100%) | Cada 5 minutos | | **Datos de consumo no disponibles** | Ningún dato nuevo de consumo de la capacidad desde hace más de 45 minutos (por ejemplo, capacidad pausada o fuente de métricas no disponible) | Cada 5 minutos | | **Anomalía de consumo por elemento** | Consumo de un elemento por encima de la línea base de los últimos 7 días | Cada 5 minutos | | **Desviación del tiempo de ejecución** (opcional, por elemento) | Ejecución mucho más larga que el promedio del elemento | Cada hora | | **Costo de la capacidad** | Costo diario por encima del promedio de los últimos 30 días más el porcentaje configurado | Diariamente | | **Capacidad encendida fuera del horario** | Capacidad activa fuera de la ventana configurada | Cada 5 minutos | | **Actualización de datos** y **Fabric Mirroring** | Monitores configurados por elemento (retraso máximo de los datos, estado del reflejo) | Cada 10 minutos | Además de las alertas por evento, existe el **Checklist Diario** (un resumen diario del entorno) y el **Checklist Cada Hora** (que se envía solo cuando hay alguna incidencia). {% hint style="info" %} Solo los **workspaces monitoreados** generan alertas de actualización y de elementos de Fabric. Consulte [Workspaces](/es/power-monitor/governanca/workspaces.md). {% endhint %} ### ¿Por dónde llegan las notificaciones? Un administrador configura los canales en **Configuración › Alertas**: * **Correo**, mediante el servidor del Power Monitor o una **cuenta SMTP** de su propia empresa; * **Microsoft Teams**, mediante el bot del Power Monitor instalado en el equipo y el canal elegidos; * **Slack**; * **Telegram**. ### ¿Puedo elegir qué alertas recibir? Sí. En **Configuración › Notificaciones**, el administrador elige **qué tipos de alerta** recibe cada destinatario y puede **Probar** el envío. Además: * los usuarios con **alcance de workspaces** reciben solo las alertas de los workspaces a los que están vinculados (las alertas sin workspace, como las de gateways y capacidades, se envían a todos los destinatarios elegibles); * la **desviación del tiempo de ejecución** se activa elemento por elemento; * el **umbral mínimo de consumo** de las anomalías y el **porcentaje** de la alerta de costo son configurables. {% hint style="warning" %} Actualmente el Power Monitor **no** tiene horario de silencio (ventana sin notificaciones) ni webhooks genéricos. El límite del 80% de la alerta de uso de capacidad es fijo. {% endhint %} ### ¿Y si el problema continúa? Para gateways, modelos semánticos y elementos de Fabric, el correo se envía **en la apertura y en la resolución del incidente**; las reincidencias mientras el incidente está abierto se contabilizan y aparecen en el **Checklist Cada Hora**. Para el límite de uso de capacidad, los recordatorios continúan mientras la situación persista. Todas las alertas quedan registradas en **Monitoreo › Alertas**. ### ¿El monitoreo funciona 24/7? Sí. Las verificaciones se ejecutan de forma continua, las 24 horas del día, los 7 días de la semana, incluso fuera del horario comercial. ### ¿Quiere que nuestro equipo actúe sobre las alertas? Power Tuning ofrece el [Monitoreo Gestionado](/es/monitoreo-gestionado/monitoramento-gerenciado.md), en el que nuestro equipo actúa sobre las alertas críticas de su entorno, con un SLA de 2 horas para la primera atención. ### Páginas relacionadas * [Alertas](/es/power-monitor/monitoramento/alertas.md) * [Configuración](/es/power-monitor/configuracoes.md) * [Alertas en tiempo real](/es/principais-funcionalidades/alertas-em-tempo-real.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/es/perguntas-frequentes/duvidas-gerais/como-funciona-o-monitoramento-proativo.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.