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; 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).
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) 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) |
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.
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).
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). 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.
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.
