Alertas (alerter)

O alerter é o 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, e, em uma rede com a replicação pelo 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 replicar os alertas pelo 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 legível do objeto.

• 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 se transformar 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: uma recuperação breve não os resolve. Alguns se resolvem sozinhos, mas só quando a causa é realmente eliminada; outros permanecem até serem 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 tem um interruptor que silencia por completo os seus alertas (junto com os das suas entradas e saídas) e um atraso de alerta: uma fonte que se restabelece dentro do tempo definido não gera 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 na reserva (código 27, input-fallback, Lista de alertas), adiado por esse mesmo atraso. 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 ficam na seção de alertas e exigem a função 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 pelo domínio a partir dos nós vizinhos.

• Replicação em todo o domínio (ativada por padrão): o 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. Um super-node, em um domínio adicional, aceita alertas apenas dos vizinhos da sua lista e não gera o alerta de código 26 (node-down) sobre os outros nós desse domínio — o estado deles é visível no mapa da rede.

• Replicação de alertas do sistema (desativada por padrão): os alertas sobre o hardware do nó (CPU e memória do host, do processo do streamer e dos transcodificadores, carga de rede e da GPU, preenchimento da memória de vídeo da GPU, threads de trabalho e o frontend DVB — códigos 16–23, 40–45 e 64) são locais por padrão; ative-a para que também sejam replicados pelo 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).

• Entradas de reserva e ressincronização (desde a versão 2.0.2.420; os blocos «Ressincronização de entrada (códigos 58, 59, 61)» e «Entradas de reserva (código 65)» da tela Alertador): o alerta de reserva com defeito (código 65, backup-input-error) e o prazo após o qual uma entrada de reserva que não é mais verificada sai da sua lista; os limiares dos códigos 58 (sync-gap-resync), 59 (sync-rt-resync) e 61 (sync-gap-absorbed) (o do código 61 fica desativado por padrão) e o número de horas tranquilas até que sejam retirados (Catálogo de códigos de alerta).

• Tempo de retenção do alerta de erros CC (código 15, cc-error, a partir da versão 2.0.2.417). O alerta é gerado ou sobe de nível somente quando as perdas continuam por 30 segundos; pausas curtas entre as perdas não zeram a contagem. Ele é removido após 60 segundos sem perdas. O nível de erro se mantém até que o número de erros na janela caia abaixo da metade do limiar de erro. Por isso, um único pacote perdido não gera alerta, e uma fonte que perde pacotes o tempo todo gera um único alerta estável em vez de uma série de gerações e remoções. Os tempos são definidos na tela Alertador ou pelas chaves stream-cc-raise-sec e stream-cc-clear-sec da seção alerter do arquivo de configuração (O arquivo de configuração pss.json): de 0 a 3600 segundos; 0 significa imediatamente, como nas versões anteriores. A verificação TR 101 290 (1.4 e veredito geral, código 49, tr101290) não muda.

• Limiares de recursos do nó — pares «aviso / erro» em porcentagem para a CPU e a memória do host, o processo do streamer e os transcodificadores, a carga da interface de rede e da 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. Os limiares de preenchimento da memória de vídeo das GPUs NVIDIA (código 64, gpu-memory) são a linha «Memória de vídeo da GPU», 85% e 95% por padrão (chaves gpu-mem-warning-pct e gpu-mem-error-pct da seção alerter do arquivo de configuração, O arquivo de configuração pss.json).

• Tempo de retenção dos alertas do sistema (a partir da versão 2.0.2.416). Um alerta sobre os recursos do nó (códigos 16–24, 40 e 64) é gerado ou sobe de nível somente quando o valor permanece além do limiar por 30 segundos. Ele desce de nível ou é removido quando o valor permanece abaixo do limiar por 60 segundos. Assim, uma carga que oscila acima e abaixo do limiar de uma medição para outra não produz alertas que aparecem e desaparecem em segundos. Os tempos são definidos na tela Alertador ou pelas chaves system-alert-raise-sec e system-alert-clear-sec da seção alerter do arquivo de configuração: de 0 a 3600 segundos; 0 significa imediatamente, como nas versões anteriores.

• 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 com falha 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 interface web mostra o alerta não pelo código, mas pelo token, por exemplo no-data; todos os códigos com seus tokens, níveis e versões estão reunidos em Lista de alertas. A coluna «Replicação» indica se o alerta é replicado pelo 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 entrega dados por mais 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 parou à espera de ação do administrador: não resta nenhuma entrada utilizável (não há entradas ou todas estão em pausa)	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
62	um módulo CI separado, ao qual a entrada entrega o fluxo, está indisponível ou deixou de devolver pacotes: a entrada transmite o fluxo sem desembaralhamento	em todo o domínio
65	enquanto o fluxo passa por uma entrada, suas outras entradas estão em erro — a reserva está com defeito (desde a versão 2.0.2.420)	em todo o domínio

Desde a versão 2.0.2.420, o alerta de código 1 (io-error) é sempre crítico: significa que o fluxo perdeu a fonte ou a entrega. Uma saída com falha sempre o recebe — atrás de uma saída não há reserva. Uma entrada com falha só o recebe se o fluxo passa justamente por ela ou se ainda não há entrada ativa. As entradas que falharam enquanto o fluxo passa por outra entrada não recebem um alerta de código 1 (io-error) próprio: assim que o fluxo assume outra entrada, suas linhas são retiradas, e a reserva com defeito é descrita por um único alerta de código 65 (backup-input-error) por fluxo. Assim uma reserva defeituosa não pinta de crítico um fluxo saudável. Antes da versão 2.0.2.420, cada uma dessas entradas mantinha a sua própria linha de código 1 (io-error) com o nível «erro», e um destino externo recebia a atualização dela de «crítico» para «erro»; agora ele recebe a retirada da linha de código 1 (io-error) e a abertura do código 65 (backup-input-error). A causa pela qual o fluxo saiu de uma entrada permanece visível na interface como histórico (Redundância de fontes).

O alerta de código 65 (backup-input-error, nível «aviso») lista as entradas com defeito do fluxo na ordem de reserva, cada uma com o seu último erro: no máximo cinco e, depois, quantas mais existem. São tanto uma entrada principal com falha enquanto o fluxo passa por uma de reserva quanto uma entrada de reserva que não subiu em uma tentativa de comutação. O alerta é aberto após o atraso de alertas do fluxo e somente quando o fluxo já passa de forma estável por uma mesma entrada; uma lista alterada reescreve a mensagem somente depois de se manter por pelo menos um minuto (ou pelo atraso de alertas do fluxo, se for maior). Enquanto o fluxo não passa por nenhuma entrada, o alerta não muda: a pane é descrita pelos códigos 60 (stream-no-source) e 1 (io-error). O alerta é retirado quando não resta nenhuma entrada com defeito — a entrada se recuperou ou foi pausada, o fluxo voltou para ela — e também ao parar, pausar ou excluir o fluxo. Uma entrada de reserva que fica abaixo da ativa na ordem não é mais verificada enquanto o fluxo funciona, por isso sai da lista um dia após o seu último erro. O prazo é definido pela chave stream-backup-input-max-age-min da seção alerter do arquivo de configurações (em minutos, padrão 1440, 0 — nunca retirar pelo prazo), na tela Alertador, o campo «Esquecer o erro de uma entrada de reserva após, min»; a chave stream-backup-input-alert desativa o alerta (ativado por padrão), na tela, a chave «Alertar sobre entradas de reserva com falha». Uma entrada que fica acima da ativa é verificada o tempo todo e permanece na lista até se recuperar.

O código 60 (stream-no-source) 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. O código 1 (io-error), ao contrário, está sempre ligado a uma entrada ou saída específica e, por isso, em um fluxo com reserva se fragmenta em vários incidentes efêmeros. A condição precisa durar quinze segundos, de modo que a inicialização do nó e a aplicação de configurações, em que as entradas deixam de entregar dados por um instante, não geram o código 60 (stream-no-source). Não se enquadram nele o fluxo em pausa e o fluxo parado à espera de ação do administrador: esse estado é descrito pelos códigos 13 (admin-wait) e 14 (io-admin-wait).

Os códigos 58 (sync-gap-resync), 59 (sync-rt-resync) e 61 (sync-gap-absorbed) indicam 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 abre um incidente quando eles passam do limiar. Eles se distinguem pelo custo para o destinatário. O código 58 (sync-gap-resync) é 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 (sync-gap-absorbed) é a mesma ruptura da linha do tempo da fonte, conduzida sem perdas. Desde a versão 2.0.2.420, o código 61 (sync-gap-absorbed) tem o nível «informação» (antes, «aviso»; com o limiar padrão dos destinos externos, ele não chega a eles) e fica desativado por padrão: o seu limiar é definido por uma chave própria stream-sync-absorbed-count da seção alerter (de 0 a 256, 0 — desativado), e a chave stream-sync-gap-count agora se refere apenas ao código 58. Os eventos são contados mesmo com o alerta desativado, por isso ativá-lo avalia de imediato o histórico acumulado. O código 59 (sync-rt-resync) 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. Isso se corrige aumentando o buffer (Sincronização) e, em uma 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 quando o número de eventos se mantém abaixo do limiar por duas janelas horárias seguidas. O número de janelas é definido pela chave stream-sync-quiet-clear-windows da seção alerter (de 1 a 24, padrão 2); antes da versão 2.0.2.420 eram necessárias seis horas sem um único evento, e uma fonte com uma ou duas rupturas por hora mantinha a linha indefinidamente. Desde a versão 2.0.2.420, também é retirada a linha da entrada da qual o fluxo comutou para outra entrada, assim como a linha de um fluxo pausado. 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 de 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 de 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 se aplica 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
63	o frontend DVB mantém a captura (lock), mas o multiplex não é recebido: a PAT não é analisada por 20 segundos, três ressintonizações seguidas
64	preenchimento da memória de vídeo da GPU NVIDIA acima do limiar (por dispositivo)

Todos os alertas deste grupo são locais por padrão. Os códigos 16–23, 40–45 e 64 podem ser replicados pelo domínio com o interruptor de replicação de alertas do sistema; os códigos 24–25 e 63 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 (dvb-no-lock) é gerado na perda da captura (lock). O BER (44) está desativado por padrão, pois a escala bruta depende do receptor (veja Receptor DVB). O código 63 (dvb-no-pat) é gerado apenas em um adaptador ao qual há fluxos conectados, e os indicadores do sinal podem continuar normais. Após a terceira ressintonização, o adaptador repete a tentativa a cada cinco minutos; o alerta é removido assim que a PAT é analisada.

O código 23 (gpu) acompanha a carga da GPU, e o código 64 (gpu-memory), quanta memória de vídeo da placa está ocupada. Uma placa com a memória de vídeo cheia não consegue iniciar um novo canal de transcodificador, embora sua carga possa parecer normal nesse momento. O código 64 (gpu-memory) é gerado apenas para placas NVIDIA que informam o preenchimento da memória; para GPUs Intel ele não existe. Se uma placa deixar de informar o preenchimento, o alerta é removido. Um nó de uma versão anterior (antes da 2.0.2.416) mostra sem nome um alerta de código 64 (gpu-memory) replicado pelo domínio até ser atualizado.

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)

Desde a versão 2.0.2.417, o alerta de código 26 (node-down) é gerado somente quando o nó fica em silêncio por mais de um minuto, embora no mapa da rede ele seja marcado como indisponível já após 15 segundos. Por isso, uma reinicialização rápida de um vizinho não gera alerta. O atraso é definido pelo campo «Alerta de nó fora após, s» do bloco «Contato da Meshwork (avançado)» das configurações do servidor (Configurações do servidor) e, no arquivo de configuração, pelo parâmetro cluster-node-down-sec da seção cluster (O arquivo de configuração pss.json): 60 segundos por padrão, de 0 a 3600; ele nunca é menor que 15 segundos.

Um nó que é parado ou reinicializado intencionalmente (parada ou reinicialização do serviço, a ação «Reiniciar agora» no painel de administração, restauração da configuração, atualização da licença) primeiro avisa os vizinhos. Durante 5 minutos, os vizinhos não geram para ele o alerta de código 26 (node-down), e na tabela de nós ele consta como «Reiniciando (N s)» (Nós); se nesse tempo o nó não tiver voltado, o alerta é gerado normalmente. O prazo é definido pelo campo «Carência após parada planejada, s» do mesmo bloco e, no arquivo de configuração, pelo parâmetro cluster-leave-grace-sec da mesma seção: 300 segundos por padrão, de 0 a 86400. O aviso chega aos vizinhos aos quais o próprio nó se conecta; um vizinho que apenas se conecta a ele (por exemplo, um nó atrás de NAT) não recebe o aviso, e para ele vale o atraso normal. Nós de versões anteriores à 2.0.2.417 ignoram o aviso. Desde a versão 2.0.2.420, um nó avisa apenas os vizinhos da versão 2.0.2.417 ou mais recente (e aqueles cuja versão ainda é desconhecida), e todos de uma vez; por isso, em uma rede com nós antigos, a parada do serviço fica cerca de 3 segundos mais curta. Uma parada do serviço por causa da licença (expirada, não autêntica ou rejeitada) não avisa os vizinhos.

O alerta de código 26 (node-down) se mantém 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 se 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 e não é recriado — falha do disco (requer ação do administrador); registros isolados danificados do índice são ignorados sem este alerta
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	o nó está com a licença expirando: um aviso duas semanas antes do fim do prazo e, depois que o prazo vence, requer ação do administrador, e o nó reinicia o serviço; o serviço não voltará a iniciar enquanto não houver uma licença válida no nó	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 avaliação temporária, por isso uma perpétua dessa geração é recusada de imediato	em todo o domínio

O alerta de código 35 (cert-acme-error) é resolvido sozinho na próxima emissão bem-sucedida do certificado e também ao desativar a emissão automática. Desde a versão 2.0.2.417, um alerta sobre um problema do próprio nó (não há servidor HTTPS com o nome do host, a porta da validação HTTP-01 está ocupada, erro da chave da conta ACME) é resolvido assim que a próxima tentativa de emissão passa dessa etapa; antes, ele se mantinha até a desativação da emissão automática (Certificados HTTPS).

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

Um módulo CI separado, ao qual a entrada entrega o fluxo (CI/CAM na entrada de um fluxo), informa a falha pelo código de fluxo 62 (cam-pipe), e não pelos códigos deste grupo. Cada entrada tem um único alerta desse tipo, mesmo que use vários slots. Ele é removido quando o módulo volta a responder por 30 segundos, quando o módulo é retirado da entrada ou quando a entrada é excluída. Um módulo que responde, mas não desembaralha nada, não gera esse alerta.

Visualização e resolução de alertas

O painel de administração tem uma seção de alertas com a 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: depois que a causa é eliminada, esse incidente é resolvido (confirmado) manualmente. A resolução vale no nó que gerou o alerta: se na rede você vir um incidente alheio (replicado pelo domínio), resolva-o 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 é gerado e resolvido repetidamente deixa de ser apagado de imediato pelo nó. Após três ciclos completos de «geração — 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). Uma nova geração cancela a contagem, e a série é lida como um incidente contínuo em vez de uma dezena de curtos. Uma primeira recuperação ou uma recuperação rara é apagada instantaneamente, 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 vizinhos 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, a expiração da licença, a licença considerada não autêntica e a licença de uma geração que esta versão não aceita mais.

• 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, a perda do multiplex na captura DVB (código 63, dvb-no-pat). 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 vizinho que parou de responder; por isso, para um mesmo nó que caiu, os vizinhos dele gerarão esse 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 pelo domínio) cujo nível não seja inferior a este, tanto na geração quanto na resolução. O nível se aplica ao incidente como um todo: se a gravidade subiu até o nível depois da geração, a geração é informada no momento do aumento, e a resolução é sempre informada quando a geração foi informada — geração e resolução chegam em par. Os parâmetros de conexão de cada canal estão descritos na seção Interface web. Como o comando externo é executado, o que ele recebe e como escrever um script para ele, com modelos prontos em /bin/sh e Python, está descrito em Scripts externos para alertas.

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 vizinhos não estão visíveis. Verifique se a replicação pelo 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 no 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.