---
title: Alertas (alerter)
url: https://doc2.pstreamer.tv/pt/manual/meshwork/alerts.html
lang: pt-BR
product: Perfect Streamer
version: 2.0.2.362
---

# Alertas (alerter)

O alerter é um serviço de notificações integrado. Ele monitora o estado dos fluxos, do hardware do nó, da recepção DVB e da gravação DVR, e gera **alertas** (incidentes) quando algo ultrapassa os limites definidos. A lista de alertas ativos é visível no painel de administração; em uma rede com a replicação em todo o domínio ativada, cada nó mostra um conjunto consolidado de alertas de todo o domínio.

O alerter também funciona em um nó isolado — o Meshwork só é necessário para a replicação de alertas em todo o domínio.

## Como funciona um alerta

- Cada incidente tem um **identificador estável**: a reincidência do mesmo problema é o mesmo incidente, não um novo.
- Um incidente passa por estados: **gerado** (observado pela primeira vez), **atualizado** (observado novamente com uma alteração significativa), **resolvido** (o problema desapareceu). O conjunto ativo são os incidentes que ainda não foram resolvidos.
- Cada alerta tem um **nível de gravidade** (em ordem crescente: informação, aviso, erro, crítico, requer ação do administrador), um **código** (o tipo numérico de incidente — veja o catálogo abaixo), uma **fonte** (fluxo, nó, armazenamento), um **nó de origem** (quem gerou o alerta) e um nome de objeto legível.
- O nível de gravidade não fica preso ao incidente para sempre. Enquanto o incidente estiver aberto, o serviço o reavalia junto com as demais verificações (cerca de uma vez a cada 5 segundos) e, havendo alteração, passa o incidente ao estado «atualizado» — com o mesmo identificador, por isso uma segunda linha não aparece na lista, e a lista é reordenada. Aos destinatários externos essa alteração não é enviada: uma reavaliação não deve transformar-se em um e-mail ou em uma mensagem de chat.
- A maioria dos alertas é **baseada em nível**: o serviço reavalia periodicamente a condição e gera ou resolve o alerta por conta própria. Parte dos alertas que exigem ação do administrador é **persistente** — eles não se resolvem sozinhos enquanto a causa não for eliminada (são resolvidos manualmente, veja Visualização e resolução de alertas).

A lista de alertas ativos é mantida na memória e é apagada ao reiniciar o serviço.

Controle no nível do fluxo. Cada fluxo dispõe de um interruptor que silencia por completo os seus alertas (junto com os das suas entradas e saídas) e de um atraso de alerta: uma fonte que se restabelece dentro do tempo definido não levanta alerta — isso suaviza oscilações breves. O mesmo atraso absorve também uma falha curta da entrada principal: se o fluxo chegou a passar para a reserva antes de ele expirar, não haverá alerta algum de erro de entrada — a comutação é informada pelo alerta de operação em reserva (código 27), que esse mesmo atraso adia. O limiar de ausência de dados de um fluxo é contado à parte e não é contido pelo atraso, por isso pode disparar antes.

## Configurações do alerter

As configurações estão na seção de alertas e exigem o papel de administrador. Os campos exatos estão descritos na seção [Interface web](../webui/index.md#webui); abaixo, o que pode ser configurado.

- **Interruptor principal** do serviço de notificações (ativado por padrão). Um alerter desativado silencia por completo: o nó não gera alertas próprios e não envia nada aos destinos externos — nem os seus alertas, nem os replicados em todo o domínio a partir dos nós vizinhos.
- **Replicação em todo o domínio** (ativada por padrão): um nó compartilha seus alertas com os nós do mesmo domínio e recebe os deles — cada nó mostra um conjunto consolidado. Só tem efeito quando um domínio está definido.
- **Replicação de alertas do sistema** (desativada por padrão): os alertas sobre o hardware do nó (CPU e memória do host, processo do streamer e transcodificadores, carga de rede e GPU, threads de trabalho e o frontend DVB — códigos 16–23 e 40–45) são locais por padrão; ative-a para que também sejam replicados em todo o domínio. Os alertas de armazenamento (códigos 24–25) permanecem sempre locais.
- **Limiares de fluxo**: tempo limite de ausência de dados (padrão 15 s), taxa de bits mínima admissível (verificação desativada por padrão), limiar de erros do contador de continuidade em uma janela de 10 s (níveis de aviso e erro).
- **Limiares de recursos do nó** — pares «aviso / erro» em porcentagem para o CPU e a memória do host, o processo do streamer e os transcodificadores, a carga da interface de rede e do GPU, bem como o preenchimento do armazenamento DVR. Os limiares do host são definidos mais altos que os do processo do streamer e dos transcodificadores, para que um componente individual avise antes que toda a máquina fique saturada. O valor 0 desativa o nível correspondente.
- **Limiares do frontend DVB** — nível de sinal, SNR/qualidade, taxa de erros de bit e blocos não corrigidos; aplicados a um adaptador com captura de sinal (lock).
- **Limiares de gravação DVR** — o número de gravações falhadas consecutivas, o multiplicador de estagnação da gravação, a proporção de não cobertura do arquivo e o tempo de leitura/gravação dos chunks no disco.

## Catálogo de códigos de alerta

O código é o tipo numérico de incidente, conveniente para agrupamento e localização. A coluna «Replicação» indica se o alerta é replicado em todo o domínio (quando a replicação está ativada) ou permanece local ao nó.

**Fluxos: estado e ciclo de trabalho** (fonte — fluxo)

| Código | Evento | Replicação |
| --- | --- | --- |
| 1 | uma entrada ou saída passou ao estado de erro | em todo o domínio |
| 2 | erro irrecuperável do ciclo de trabalho, é necessário reset manual (requer ação do administrador) | em todo o domínio |
| 3 | um fluxo em execução não fornece dados por mais tempo que o tempo limite | em todo o domínio |
| 4 | a taxa de bits do fluxo permanece abaixo do mínimo | em todo o domínio |
| 13 | o fluxo está pausado: não resta nenhuma entrada utilizável (requer ação do administrador) | em todo o domínio |
| 14 | uma entrada ou saída se autoestacionou e não se recupera na nova tentativa (requer ação do administrador) | em todo o domínio |
| 27 | o fluxo funciona na entrada de reserva — ocorreu uma comutação | em todo o domínio |
| 39 | carga alta de CPU pela thread de trabalho do fluxo | em todo o domínio |
| 58 | um salto de PCR da fonte além da janela de descontinuidade rompeu a emissão — o acumulado foi descartado | em todo o domínio |
| 59 | a emissão foi ressincronizada pelo tempo real: a alimentação não sustenta o atraso configurado | em todo o domínio |
| 60 | um fluxo em execução ficou sem nenhuma entrada que o alimente | em todo o domínio |
| 61 | um salto de PCR da fonte além da janela de descontinuidade ocorreu sem perdas | em todo o domínio |

O nível de um alerta de código 1 é determinado pelas consequências da falha, e não pelo simples fato de haver um erro. Uma saída com falha é sempre «crítica»: atrás dela não há reserva, é entrega perdida. Uma entrada com falha só é crítica se o fluxo passa justamente por ela ou se ainda não há entrada ativa; a falha de uma entrada que o fluxo não está usando no momento é uma perda de redundância, e a esse alerta é atribuído o nível «erro». Assim a gravidade consolidada de um fluxo concorda com o seu estado: uma reserva defeituosa não pinta de crítico um fluxo saudável. E se já não há para onde comutar e o fluxo parou, um incidente sobre uma entrada que ainda tenta subir lê-se como «crítico» — atrás dela já não há reserva. Ao comutar para a reserva, o incidente da entrada abandonada é retirado por completo: a entrada é parada, enquanto a causa pela qual o fluxo saiu dela permanece visível na interface como histórico ([Redundância de fontes](../streamer/spts.md#streamer-spts-reservation)).

O código 60 descreve o fluxo por inteiro, e não um ponto isolado: ele se mantém enquanto nenhuma entrada de um fluxo em execução trouxer dados, e sobrevive a qualquer número de comutações para a reserva — ao contrário do código 1, sempre ligado a uma entrada ou saída específica e que, num fluxo com reserva, se fragmenta em vários incidentes efêmeros. A condição precisa durar quinze segundos, de modo que a partida do nó e a aplicação de configurações, em que as entradas deixam de entregar dados por um instante, não levantam o código 60. Um fluxo parado pelo administrador ou colocado em pausa não se enquadra nele: esse estado é descrito pelos códigos 13 e 14.

Os códigos 58, 59 e 61 são uma recomendação sobre os ajustes de sincronização da entrada, e não o relato de uma falha isolada: o nó conta esses eventos em uma janela deslizante de uma hora e levanta um incidente quando passam do limiar. Eles se distinguem pelo custo para o destinatário. O código 58 é um salto de PCR da fonte que custou conteúdo: o buffer de sincronização foi descartado e a emissão se rompeu; a mensagem informa quanto do fluxo acumulado o último caso desse tipo descartou. O código 61 é a mesma ruptura da linha do tempo da fonte, conduzida sem perdas. O código 59 não trata da fonte de modo algum: o buffer de sincronização se esvaziava, ou seja, a alimentação não sustenta o atraso configurado — corrige-se aumentando o buffer ([Sincronização](../streamer/spts.md#streamer-spts-sync)) e, numa entrada de transcodificador, também suavizando o bitrate no fluxo pai. Os três são persistentes: reconectar a entrada não os resolve. O incidente se resolve sozinho quando se altera qualquer um dos ajustes de sincronização da entrada ou do fluxo — o ajuste alterado é reavaliado — ou após seis horas sem um único evento. Um fluxo parado conserva o incidente: a recomendação continua valendo.

**Conformidade do fluxo de transporte (analisador TR 101 290)** (fonte — fluxo; todos replicados em todo o domínio)

| Código | Evento |
| --- | --- |
| 5 | descontinuidades PCR repetidas (TR 101 290, 2.3) |
| 6 | intervalo de repetição PCR maior que 40 ms (2.3a) |
| 7 | intervalo de repetição PAT maior que 500 ms (1.3) |
| 8 | intervalo de repetição PMT maior que 500 ms (1.5) |
| 9 | intervalo de repetição PTS maior que 700 ms (2.5) |
| 10 | precisão PCR pior que 500 ns (2.4) |
| 11 | estouro ou subfluxo do buffer T-STD para vídeo (3.3) |
| 12 | deriva PCR maior que 30 ppm (histórico: o alerta não é mais gerado, a deriva é exibida como métrica — [Medições contínuas](../streamer/analyzer.md#streamer-analyzer-metrics)) |
| 15 | erros do contador de continuidade acima do limiar em uma janela curta (1.4) |
| 46 | erro de CRC nas tabelas PSI (2.2) |
| 47 | o indicador transport_error_indicator está ativado (2.1) |
| 48 | intervalo de repetição da tabela SI excedido (SDT / EIT / TDT / NIT) |
| 49 | veredito geral: o fluxo não está em conformidade com a TR 101 290 |

Parte dos códigos do analisador aparece apenas quando as opções de análise estão ativadas (análise profunda, análise de descontinuidades PTS, análise do buffer T-STD) e aplica-se somente a fluxos de taxa de bits constante; o veredito geral (49) só é emitido para uma taxa de bits comprovadamente constante. Mais detalhes na seção [Analisador](../streamer/analyzer.md#streamer-analyzer).

**Recursos e hardware do nó** (fonte — sistema)

| Código | Evento |
| --- | --- |
| 16 | carga de CPU do host acima do limiar |
| 17 | uso de memória do host acima do limiar |
| 18 | CPU do processo do streamer acima do limiar |
| 19 | memória do processo do streamer acima do limiar |
| 20 | CPU total dos transcodificadores acima do limiar |
| 21 | memória total dos transcodificadores acima do limiar |
| 22 | carga da interface de rede acima do limiar (por interface) |
| 23 | carga de GPU acima do limiar (por dispositivo) |
| 24 | preenchimento do armazenamento DVR acima do limiar (por armazenamento) |
| 25 | o sistema de arquivos do armazenamento DVR está indisponível (requer ação do administrador) |
| 40 | carga alta de CPU pela thread de trabalho do adaptador DVB |
| 41 | o frontend DVB perdeu o sinal (lock) |
| 42 | nível de sinal DVB abaixo do limiar |
| 43 | SNR/qualidade do sinal DVB abaixo do limiar |
| 44 | taxa de erros de bit (BER) DVB acima do limiar |
| 45 | blocos não corrigidos DVB acima do limiar |

Todos os alertas deste grupo são locais por padrão. Os códigos 16–23 e 40–45 podem ser replicados em todo o domínio com o interruptor de replicação de alertas do sistema; os códigos 24–25 permanecem sempre locais. Os alertas de limiar do frontend DVB (42–45) são avaliados apenas em um adaptador com captura de sinal; o código 41 é gerado na perda do enganche (lock). O BER (44) está desativado por padrão, pois a escala bruta depende do receptor (veja [Receptor DVB](../streamer/dvb.md#streamer-dvb)).

**Meshwork e ciclo de vida** (fonte — rede/sistema; local)

| Código | Evento |
| --- | --- |
| 26 | um nó da rede ficou em silêncio — parou de confirmar a conexão |
| 28 | o processo do streamer concluiu a inicialização (notificação de curta duração) |
| 37 | dois nós com o mesmo nome em um mesmo domínio (requer ação do administrador) |

O alerta de código 26 mantém-se durante todo o tempo em que o nó constar como indisponível — até uma semana ([Mapa da rede](map.md#meshwork-map-nodes)). Ele é resolvido sozinho quando o nó volta a comunicar e desaparece junto com a linha do nó, se o nó indisponível tiver sido esquecido manualmente.

**Saúde da gravação DVR** (fonte — fluxo; local)

| Código | Evento |
| --- | --- |
| 29 | as gravações de segmentos ou do índice DVR falham — o arquivo não está sendo gravado |
| 30 | a gravação DVR estagnou: há entrada, mas um novo segmento não é salvo há muito tempo |
| 31 | o arquivo DVR degradou — lacunas na cobertura recente |
| 32 | o índice do arquivo DVR está corrompido (requer ação do administrador) |
| 50 | tempo de leitura/gravação elevado dos chunks DVR no disco |

**Configuração, transcodificadores, OTT, certificados e licença** (fonte — sistema/fluxo)

| Código | Evento | Replicação |
| --- | --- | --- |
| 33 | a configuração principal não foi carregada na inicialização, o serviço iniciou com a de reserva (requer ação do administrador) | em todo o domínio |
| 34 | no modo low-latency HLS/DASH, as faixas de áudio em um codec não suportado foram descartadas (AAC e AC-3 são suportados) | em todo o domínio |
| 35 | não foi possível emitir ou renovar o certificado HTTPS por meio do cliente ACME integrado | em todo o domínio |
| 36 | um transcodificador configurado não foi carregado na inicialização — não há arquivo executável ou dispositivo (requer ação do administrador) | em todo o domínio |
| 38 | o fluxo requer um transcodificador (software, NVIDIA ou Intel VPL) indisponível neste nó (requer ação do administrador) | local |
| 55 | a licença do nó está expirando: um aviso duas semanas antes do fim do prazo e, uma vez atingido este, requer ação do administrador, e o nó reinicia o serviço | em todo o domínio |
| 56 | a licença do nó foi considerada não autêntica (requer ação do administrador): o nó reinicia o serviço e a inicialização é recusada — o serviço permanece parado até que haja uma licença autêntica no nó e ele seja iniciado novamente | em todo o domínio |
| 57 | a licença do nó é autêntica, mas pertence a uma geração que esta versão não aceita mais (requer ação do administrador): o prazo não venceu e não há falsificação — a geração 2 é aceita apenas como licença de teste temporária, por isso uma perpétua dessa geração é recusada de imediato | em todo o domínio |

**Desembaralhamento: módulo de acesso condicional (CI/CAM, EN 50221) e BISS** (fonte — sistema; local)

| Código | Evento |
| --- | --- |
| 51 | o módulo CAM foi removido (requer ação do administrador) |
| 52 | sem assinatura: o módulo informa que o programa não está pago |
| 53 | erro CI/CA — um erro irrecuperável de canal ou de acesso condicional |
| 54 | o desembaralhamento não funciona: um programa com a chave BISS definida ou atribuído ao CAM continua embaralhado |

## Visualização e resolução de alertas

O painel de administração tem uma seção de alertas com uma lista de alertas. Ela pode ser filtrada por conjunto (apenas ativos / apenas resolvidos / todos), por nível de gravidade, por tipo e identificador da fonte, por código, por domínio e por tempo, e também é possível pesquisar pelo texto da mensagem. Por padrão são exibidos tanto os registros ativos quanto os recentemente resolvidos (o log de transições), por isso o número total de linhas pode exceder o número de incidentes ativos — para o conjunto ativo atual, escolha o modo «apenas ativos».

Não é necessário consultar o estado manualmente: o painel de administração recebe as alterações do conjunto ativo em tempo real e atualiza a lista por conta própria, assim que um alerta é gerado, atualizado ou resolvido.

Os alertas baseados em nível são resolvidos automaticamente quando a condição desaparece. Os alertas persistentes que exigem ação do administrador (por exemplo, um erro de carregamento da configuração, a indisponibilidade do armazenamento, um erro grave do ciclo de trabalho) não se resolvem sozinhos: após a eliminação da causa, tal incidente é resolvido (confirmado) manualmente. A resolução tem efeito no nó que gerou o alerta: se na rede você vir um incidente alheio (replicado em todo o domínio), deve resolvê-lo no nó de origem (ele é indicado na linha). Se a fonte se calar, os vizinhos retiram as linhas dela da sua lista consolidada cerca de quarenta e cinco segundos após a última mensagem. Isso não é uma resolução do incidente, e sim a remoção da cópia: na própria fonte o incidente permanece e, quando o nó voltar a se comunicar, as linhas não resolvidas ali retornarão à lista. É assim que também sai da lista consolidada o alerta de licença vencida de um nó parado — não é possível resolvê-lo na fonte, porque ali o serviço não está funcionando.

Um incidente que se levanta e se resolve repetidamente deixa de ser apagado de imediato pelo nó. Após três ciclos completos de «levantamento — resolução» separados por não mais de dez minutos, as resoluções ficam retidas: a linha permanece no conjunto ativo, e uma única resolução verdadeira só sai depois que a condição se mantiver resolvida por pelo menos o tempo da própria série — por padrão, esses mesmos dez minutos. Um novo levantamento cancela a contagem, e a série se lê como um incidente contínuo em vez de uma dezena de curtos. Uma recuperação primeira ou rara é apagada instantaneamente, como antes, ao passo que a resolução manual, a exclusão do fluxo, o desligamento dos alertas no fluxo e o desligamento do próprio serviço contornam a espera. O mecanismo vem ativado por padrão e é necessário sobretudo para a entrega externa: sem ele, uma condição oscilante enviaria aos destinatários um par de mensagens por ciclo.

## Replicação de alertas em todo o domínio

Com a replicação ativada e um domínio definido, cada nó mostra um conjunto ativo consolidado de todo o domínio: os alertas próprios do nó mais os alertas dos peers do mesmo domínio. Cada linha indica o nó de origem, de modo que se vê em qual nó exatamente o problema ocorreu.

- **Replicados em todo o domínio:** os alertas de fluxo e os alertas de conformidade do fluxo de transporte, a comutação para a entrada de reserva, os erros de carregamento da configuração e do transcodificador, o descarte de áudio OTT, o erro de certificado ACME, o vencimento da licença e a sua consideração como não autêntica.
- **Permanecem locais:** os alertas de recursos sobre hardware e armazenamento, «nó em silêncio», a colisão de nomes de nós, a notificação de inicialização do serviço, os alertas de saúde da gravação DVR, a exigência de um transcodificador indisponível no nó, os alertas do módulo de acesso condicional e o desembaralhamento malsucedido. Os alertas do sistema sobre o hardware (códigos 16–23 e 40–45) podem ser passados para replicação com o interruptor de replicação de alertas do sistema.

Cada nó gera por conta própria o alerta «nó da rede em silêncio» sobre o peer que parou de responder — por isso, para um mesmo nó que caiu, seus peers gerarão tal alerta independentemente uns dos outros.

## Entrega externa de alertas

Além da lista no navegador, os alertas podem ser entregues a um comando externo, a um chat do Telegram e por e-mail (SMTP). Cada canal é independente e está desativado por padrão, e realiza a entrega em sua própria thread em segundo plano, de modo que um destinatário lento ou inacessível não atrasa os demais canais nem o próprio serviço.

Cada canal tem um nível de gravidade mínimo para a entrega (aviso por padrão): é entregue cada alerta visível no nó (próprio ou replicado em todo o domínio) que não seja inferior a este nível, tanto na geração quanto na resolução. Os parâmetros de conexão de cada canal estão descritos na seção [Interface web](../webui/index.md#webui).

Os canais são independentes apenas entre si: os três estão subordinados ao interruptor principal do alerter (Configurações do alerter). Com o serviço desativado não sai nada — nem pelos alertas próprios, nem pelos replicados a partir dos nós vizinhos, nem pela resolução de um incidente já comunicado.

## Problemas comuns

- **Os alertas dos peers não estão visíveis.** Verifique se a replicação em todo o domínio está ativada nos nós e se há um domínio comum definido. Os alertas do sistema sobre o hardware são locais por padrão — ative a replicação de alertas do sistema se você também precisar vê-los em todo o domínio.
- **Um alerta persistente não desaparece após a eliminação da causa.** Resolva-o manualmente no nó de origem.
- **As notificações externas não chegam, embora o canal esteja configurado e o limiar seja adequado.** Verifique o interruptor principal do alerter no nó de que você espera a entrega: um serviço desativado silencia também os alertas alheios, replicados em todo o domínio, embora eles continuem visíveis no painel de administração.