Log¶

control.audit.log

Quem vê o diário¶

A secção Registo de auditoria é vista por dois papéis:

security — o papel de supervisão: o registo de auditoria e a própria conta (entrar, alterar a sua palavra-passe, sair). As definições, os streams e o estado observado estão-lhe totalmente fechados, leitura incluída.
superadmin — como tudo o resto no painel.

Os papéis admin e viewer não têm acesso: a supervisão dos operadores não pertence aos próprios operadores, e a um espectador o diário revelaria os logins dos administradores e os endereços de onde entram. A proibição é aplicada pelo servidor, não pelo menu: a um papel sem acesso a ligação direta também é recusada.

Os papéis são atribuídos na secção Contas. A quem vigia o que os operadores fazem cria-se uma conta própria com o papel security, em vez de lhe dar um superadministrador.

O que entra no diário¶

Deixa lançamento uma alteração que chegou a acontecer e o início de sessão:

a edição de definições — de um stream, de uma máquina, de um modelo, de uma fonte da guia, do acesso, da própria instalação de controlo;
o trabalho com as máquinas do cluster — registo, revogação, remoção, abertura e fecho da janela de adesão;
o trabalho com as contas — criação, edição, remoção, alteração da palavra-passe;
a migração de definições do Flussonic v3 — tanto a construção do plano como a sua aplicação;
a execução manual da atribuição;
o início de sessão de um administrador e a tentativa falhada;
o trabalho com o registo de clientes — criar, editar e eliminar um cliente, vincular e desvincular uma conta.

Uma operação em massa deixa um lançamento por cada objeto afetado, não um por chamada: migrar trezentos streams aparece como trezentos lançamentos, e a procura por nome encontra qualquer um deles.

À parte fica a revelação de um token de adesão válido: é uma leitura, mas revelar um segredo equivale a entregá-lo, por isso o lançamento mantém-se. O valor do token nunca entra nele.

A lista e as suas colunas¶

Os lançamentos vão dos novos para os antigos. O botão Carregar mais traz a página seguinte: a lista não acaba nos primeiros cinquenta lançamentos.

A tabela tem cinco colunas:

Hora — o momento da ação.
Ator — quem agiu. Ou o login de um administrador, ou um dos tipos de serviço: chave estática (entrada com as credenciais de emergência de /etc/mcaster/secrets.env, comuns a todos e por isso sem nome atrás) e nó (o registo de uma máquina do cluster, em que o ator é o seu identificador).
Ação — o que foi feito, com um nome de máquina da forma <recurso>.<verbo>: stream_config.put, node_config.patch, admin.create, auth.login. Os nomes são estáveis, o que é cómodo para procurar e filtrar.
Recurso — sobre o quê: tipo e nome, por exemplo stream/program-a.
Resultado — sucesso numa ação consumada e falha num início de sessão falhado.

A seta à esquerda da linha abre os detalhes do lançamento: o endereço de onde veio o pedido, o papel do administrador, a versão do documento depois da edição, a lista de campos alterados e — se o pedido chegou com um cabeçalho de rastreio — o seu identificador, com o qual o lançamento se cruza com os logs.

Procura no diário¶

Por cima da lista há cinco campos que funcionam em conjunto:

Tipo de recurso e Nome do recurso — «tudo o que foi feito a este stream».
Ator — «tudo o que esta pessoa fez».
De e Até — uma janela de tempo em formato RFC 3339, por exemplo 2026-08-14T14:00:00Z.

Aplicar relê a lista desde o início. Um campo vazio significa «não filtrar».

Um incidente costuma ser analisado em duas consultas: primeiro por recurso — o que aconteceu a este stream — e depois pelo ator do lançamento encontrado — que mais fez essa mesma pessoa nesse dia.