> 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/monitoramento-continuo.md). # Monitoreo continuo Cómo el Power Monitor verifica continuamente la salud del entorno, abre y resuelve incidentes y envía alertas. El monitoreo continuo está separado de los [escaneos de inventario](/es/documentacion-tecnica/documentacao-tecnica/fluxo-de-scans.md). Mientras los escaneos recopilan **lo que existe** en el entorno, el monitoreo verifica la **salud** de los recursos y detecta **fallas** en ciclos cortos. ## Ciclo de verificación ``` Job de health check (cada 30 segundos) │ selecciona las tareas de monitoreo vencidas de cada organización ▼ Tarea de monitoreo (por tipo, con cadencia propia) │ consulta las APIs de Microsoft con el Service Principal de la organización ▼ Estado de salud del recurso ──▶ incidente abierto / mantenido / resuelto │ ▼ Política de notificación ──▶ correo, Teams, Slack, Telegram ``` | Tarea | Qué verifica | API | Cadencia | | ----------------------------------------- | ---------------------------------------------------------------------------------- | -------------------------------------------------------------------- | ---------- | | **Estado de gateways** | Cada gateway en el que el Service Principal es administrador | `GET /v1.0/myorg/gateways/{id}` | 5 minutos | | **Actualización de modelos semánticos** | Últimas actualizaciones de los modelos en capacidad de los workspaces monitoreados | `GET /v1.0/myorg/admin/capacities/refreshables` | 15 minutos | | **Ejecuciones de elementos de Fabric** | Pipelines, notebooks, Copy jobs y Dataflows Gen2 | APIs de job instances de Fabric | 2 horas | | **Programaciones de elementos de Fabric** | Recopilación de las programaciones (sin alerta) | APIs de programación de Fabric | 6 horas | | **Consumo de las capacidades** | Uso interactivo, en segundo plano y acumulado, por capacidad y por elemento | Consulta DAX (`executeQueries`) al modelo de Fabric Capacity Metrics | 5 minutos | Otros jobs programados complementan el monitoreo: | Job | Cadencia | | ---------------------------------------------------- | ---------------------------------------------- | | Detección de anomalías de consumo por elemento | 5 minutos (línea base recalculada diariamente) | | Desviación del tiempo de ejecución | Cada hora | | Actualización de Datos y Fabric Mirroring | 10 minutos | | Alertas de horarios de capacidad | 5 minutos | | Programaciones de pausa, reanudación y cambio de SKU | Cada minuto | | Escalado automático de capacidad | 5 minutos | | Alerta de costo de capacidad | Diario | | Checklist cada hora / Checklist diario | Cada hora / diario | | Conciliación de las tareas de monitoreo | 30 minutos | Las tareas de monitoreo se crean y se mantienen automáticamente cuando el administrador activa cada monitoreo en **Configuración › Monitoreo**. ## Estado de salud e incidentes Cada recurso monitoreado (gateway, modelo semántico, elemento de Fabric, capacidad) tiene un estado de salud: | Estado | Significado | | ------------- | ---------------------------------------------------------------------------------------------------------------------- | | **Unknown** | Aún no evaluado o indeterminado; no genera notificación | | **Healthy** | Funciona normalmente | | **Degraded** | Situación de atención (por ejemplo, consumo en segundo plano elevado o ejecución en curso) | | **Unhealthy** | Falla: gateway sin conexión, actualización con error, ejecución con error o cancelada, capacidad por encima del límite | | Transición | Efecto | | ----------------- | ------------------------------------------------------------------- | | Saludable → falla | **Abre un incidente** y envía la notificación de apertura | | Falla → falla | El incidente sigue abierto; las reincidencias se contabilizan | | Falla → saludable | **Cierra el incidente** y envía la notificación **Alerta Resuelta** | ## Política de notificación * **Gateways, modelos semánticos y elementos de Fabric:** correo **en la apertura y en la resolución** del incidente. Las reincidencias se suman al contador de fallas y aparecen en el **Checklist Cada Hora**, lo que evita el exceso de mensajes. * **Límite de uso de capacidad (80%):** avisos repetidos mientras la situación persista. * **Uso en segundo plano:** como máximo un aviso por día en cada franja (50–69%, 70–79%, 80–98% y 100% o más). * **Datos de consumo no disponibles:** una alerta por episodio, que se cierra automáticamente cuando los datos vuelven. * **Destinatarios:** se definen por tipo de alerta en **Configuración › Notificaciones**, respetando el alcance de workspaces de cada usuario. Los workspaces no monitoreados no generan alertas de actualización ni de elementos de Fabric. ## Registro * Cada alerta se registra y queda disponible en **Monitoreo › Alertas**. * Cada correo enviado queda registrado en **Auditoría › Auditoría de Correos**. * Los correos utilizan plantillas renderizadas en el servidor y se envían mediante SendGrid o mediante la cuenta SMTP configurada por la organización. Teams, Slack y Telegram utilizan el servicio de bot de Power Tuning. ## Páginas relacionadas * [Alertas en tiempo real](/es/principais-funcionalidades/alertas-em-tempo-real.md) * [Flujo de escaneos](/es/documentacion-tecnica/documentacao-tecnica/fluxo-de-scans.md) * [Modelo de datos](/es/documentacion-tecnica/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/es/documentacion-tecnica/documentacao-tecnica/monitoramento-continuo.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.