> For the complete documentation index, see [llms.txt](https://wiki.datadike.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://wiki.datadike.com/product-guide/configuracoes/rmm/alertas-e-relatorios.md).

# Alertas e Relatórios

Este módulo cobre as duas telas de observabilidade da frota — **Alertas** (regras que disparam eventos) e **Relatórios** (KPIs + gráficos sobre a telemetria coletada).

## Alertas

Aberta em `/alert-rules`. O objetivo é transformar telemetria bruta em **eventos acionáveis** para o time de operação.

### Tipos de regra suportados

| Tipo                | Trigger                            | Parâmetros                                          |
| ------------------- | ---------------------------------- | --------------------------------------------------- |
| **BATTERY\_LOW**    | Bateria do device ≤ threshold      | `threshold` (percentual, ex.: 20)                   |
| **DEVICE\_OFFLINE** | Último checkin > threshold minutos | `threshold` (minutos, ex.: 30)                      |
| **GEOFENCE\_EXIT**  | Device saiu de uma geofence        | `geofenceId` (opcional — vazio = qualquer geofence) |

### Como cada regra é avaliada

O motor de avaliação de regras processa suas regras a cada minuto:

1. Verifica todas as regras ativadas na sua organização
2. Para cada dispositivo, avalia se as condições foram atingidas (bateria atual, último checkin, eventos recentes de geofence)
3. Respeita o cooldown configurado — se a mesma regra já disparou para o mesmo device dentro do intervalo, ela é silenciada até o cooldown expirar
4. Ao disparar, uma nova notificação aparece no sino do header em tempo real

### Configurações por regra

| Campo             | O que faz                                                               |
| ----------------- | ----------------------------------------------------------------------- |
| `name`            | Título visível na UI                                                    |
| `type`            | BATTERY\_LOW / DEVICE\_OFFLINE / GEOFENCE\_EXIT                         |
| `threshold`       | Ponto de gatilho (contexto por tipo)                                    |
| `cooldownMinutes` | Não redisparar para o mesmo device dentro desse intervalo (evita flood) |
| `notifyUsers[]`   | IDs de usuários que recebem. Vazio = todos admins do tenant             |
| `enabled`         | Toggle rápido — desativa sem apagar                                     |

### UI

* Aba **Rules**: tabela com search + sort + toggle switch de ativação + edit + delete
* Aba **History**: cronológico dos disparos com device, valor detectado, timestamp

### Deduplicação

Cada disparo é registrado no histórico com regra + dispositivo + timestamp. O motor consulta esse histórico antes de disparar novamente, para evitar flood — se a mesma combinação foi acionada dentro do intervalo de cooldown, o disparo é suprimido.

Para regras de `GEOFENCE_EXIT`, o sistema garante ainda que cada evento único de saída seja processado apenas uma vez, mesmo em cenários de reprocessamento.

### Entrega das notificações

Cada alerta disparado aparece imediatamente no **sino do header** do portal, para todos os usuários listados em `notifyUsers` (ou para todos os admins da organização, se o campo estiver vazio). O sino atualiza a cada poucos segundos e mostra:

* Título da regra
* Nome do dispositivo
* Valor detectado que estourou o limite
* Horário do disparo

Admins podem marcar como vista clicando na notificação. O histórico completo com todos os disparos (mesmo os já vistos) fica disponível na aba **History** da tela de Alertas.

## Relatórios

Aberta na **Home** (`/`) do portal, para dar destaque.

### Estrutura

* **Filtro de data** com presets 7/30/90 dias + range customizado
* **6 KPI cards**: Total de dispositivos, Offline, Bateria baixa (≤20%), Dados móveis totais, Dados Wi-Fi totais, Chamadas
* **Gráficos ApexCharts**:
  * Consumo de dados no tempo (área empilhada: mobile + wifi)
  * Chamadas no tempo (barras)
  * Dispositivos ativos no tempo (área)
  * Distribuição de bateria (donut com 5 buckets: 0-20 / 21-40 / 41-60 / 61-80 / 81-100 + Unknown)
* **Tabela de Top devices** — toggle entre "por consumo de dados" e "por chamadas"

### Buckets de agregação

Os gráficos podem ser agrupados por **hora**, **dia**, **semana** ou **mês**, dependendo do período selecionado.

### Limites

* Faixa de datas máxima: **366 dias** por consulta
* Faixa padrão: **últimos 7 dias**
* Métricas e buckets são validados na hora da consulta para evitar cargas excessivas na base

### Export CSV

Cada card + tabela tem seu próprio botão CSV que baixa aquela seção específica:

* `summary.csv` — 10 linhas de KPI (Metric / Value)
* `devices.csv` — inventário completo com battery / online / lastSeen / model / OS
* `data-usage-{bucket}.csv` — timestamp + mobile MB + wifi MB
* `calls-{bucket}.csv` — timestamp + count + duration total
* `status-{bucket}.csv` — timestamp + active devices
* `top-devices-{metric}.csv` — deviceId + deviceName + colunas específicas por métrica

### Export PDF

O botão **Salvar como PDF** aciona `window.print()`. Uma stylesheet `@media print` inline esconde:

* Sidebar
* Header (toolbar, alertas, user)
* Botões de export (`.no-print`)

O usuário escolhe "Salvar como PDF" no dialog do navegador. Zero dependências novas (não usa `jsPDF` ou `html2canvas`).

## Combinação típica de Alertas + Relatórios

Fluxo operacional recomendado:

1. **Alertas** — cria regra `DEVICE_OFFLINE ≥ 60 min` e `BATTERY_LOW ≤ 15%` para todos os devices
2. Admin recebe notificações no sino em tempo real quando algo dispara
3. **Relatórios** — analista revisa semanalmente para spotting de tendências (aparelho X sempre offline aos sábados? bateria degradando faster?)
4. **Ação** — se pattern for observado, redistribui a policy (ex.: `stayOnPluggedModes` para setups sedentários) ou substitui hardware


---

# 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://wiki.datadike.com/product-guide/configuracoes/rmm/alertas-e-relatorios.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.