Registro
O módulo "Registro" na Platform OneEntry permite que os administradores monitorem tanto as ações de outros administradores no sistema quanto a atividade da API de Conteúdo pública. O módulo consiste em quatro abas:
| Aba | O que mostra |
|---|---|
| Registro de ações do admin | Todas as ações dos administradores no sistema: criação, modificação, exclusão de entidades. |
| Tráfego dos admins | Sessões de login dos administradores: quando entraram, quando saíram, de qual dispositivo. |
| Estatísticas da API de Conteúdo | Contadores de chamadas de todos os endpoints públicos do site em diferentes períodos. |
| Erros da API de Conteúdo | Todas as respostas 4xx/5xx da API pública com detalhes da solicitação e stack trace. |
Na interface do módulo, as abas estão nomeadas como: Registro de Admin, Registro de Acesso ao Aplicativo Admin, Estatísticas da API de Conteúdo, Erros da API de Conteúdo.
Cada aba está disponível sob uma permissão separada — veja Permissões para o registro.
Registro de ações do admin
A aba principal, que mostra todas as ações dos administradores no sistema. Anteriormente, era chamada simplesmente de "Registro de ações do admin" — agora foi renomeada para "Registro de ações do admin", para diferenciá-la das novas abas.
Elementos da interface
A aba consiste em dois blocos:
- Filtros
- Lista de ações
Filtros
Para filtrar ações, os seguintes campos estão disponíveis:
- De — campo de texto para a data a partir da qual as ações devem ser filtradas.
- Até — campo de texto para a data até a qual as ações devem ser filtradas.
As datas podem ser inseridas como uma string no formato de data da sua região, além de poder escolher a data necessária usando o calendário que aparece ao clicar no campo de entrada de data.
- ID do Administrador — campo numérico para o identificador único do administrador.
- Ações do usuário — lista suspensa de ações do usuário:
- Criação
- Modificação
- Exclusão
- Status — lista suspensa de status das ações:
- Sucesso
- Erro
- Nome do módulo — lista suspensa de nomes de módulos:
- Administradores
- Conjuntos de atributos
- Backup
- Gerenciamento de blocos
- Gerenciamento de eventos
- Configurações gerais
- Upload de arquivos
- Editor de arquivos
- Gerenciamento de formulários
- Localização
- Marcadores
- Menu
- Módulos
- Gerenciamento de conteúdo
- Produtos
- Gerenciamento de pedidos
- Configurações básicas
- Gerenciamento de pagamentos
- Gerenciamento de status de produtos
- USUÁRIO
- Gerenciamento de provedores de autenticação e usuários
- Gerenciamento de templates
- Gerenciamento de templates de visualização
- ID do Registro — campo numérico para o identificador único do registro.
Abaixo do bloco de filtros, há dois botões:
- Excluir dados — exclui registros do registro de ações do admin para o período definido pelos campos De / Até (veja Limpeza de registros manualmente).
- Redefinir — redefine os filtros aplicados.
Lista de ações
A lista de ações é apresentada em forma de tabela com seis colunas:
- Ações do usuário
- Status
- Login do usuário
- Nome do módulo
- ID do registro
- Data e hora
Para cada coluna, é possível ordenar os dados clicando no cabeçalho da coluna. O primeiro clique ordena em ordem decrescente, o segundo em ordem crescente, e o terceiro redefine a ordenação.
Auditoria de visibilidade do bloco
Cada alternância de visibilidade do bloco (toggle "mostrar/não mostrar" na administração de blocos) é automaticamente registrada no Registro de ações do admin. É possível ver qual admin e quando alterou o estado de um bloco específico.
A alternância de visibilidade do bloco não era registrada — não era possível descobrir quem e quando escondeu/mostrou o bloco. Agora isso está disponível, e a operação é exibida na lista geral com o tipo "Gerenciamento de blocos".
Tráfego dos admins (Registro de Acesso do Admin)
A aba "Tr áfego dos admins" mostra cada entrada e saída de um administrador no sistema como um registro separado. Agora é possível ver imediatamente quem e quando acessou a administração — sem precisar recorrer ao Grafana/Loki. Útil para auditoria (especialmente para equipes grandes com vários administradores).
Campos da tabela
A tabela consiste em seis colunas:
| Coluna | O que significa |
|---|---|
| Login | login do administrador |
| IP | endereço IP de onde o admin acessou |
| Hora do Login | data e hora do login |
| Hora do Logout | data e hora do logout (para sessões ainda abertas — vazio) |
| Duração | duração da sessão (para ativa — do login até o momento atual) |
| Razão | razão para o fechamento da sessão: logout (o próprio usuário clicou em "Sair") ou admin_revoked (outro admin forçou o encerramento da sessão, por exemplo, através do logoutAll) |
Assim como no Registro de ações do admin, qualquer coluna pode ser ordenada clicando em seu cabeçalho.
A expiração do token (expired) e a reautenticação (refresh) não são registradas como um registro separado — tal sessão é simplesmente marcada como encerrada de forma preguiçosa, quando realmente não é mais utilizada.
Filtros
- De / até — período (campos de entrada de data com calendário).
- ID do Administrador — campo numérico para filtrar por um administrador específico.
- Status da Sessão — lista suspensa de status da sessão: Todos / Ativa / Fechada.
Botão "Excluir dados"
Exclui registros de sessões para o período definido pelos campos De / Até. Ao clicar, uma caixa de diálogo de confirmação é aberta:
Confirmar ação — Excluir todas as sessões fechadas para o período especificado? Esta ação é irreversível. Sessões ativas permanecerão.
Somente sessões fechadas são excluídas. Sessões ativas (com autenticação aberta) não são afetadas — isso é uma proteção contra a exclusão acidental de colegas que estão trabalhando.
Estatísticas da API de Conteúdo
A aba "Estatísticas da API de Conteúdo" mostra contadores de chamadas de todos os endpoints públicos do site (API de storefront) em diferentes períodos — 1 hora, 24 horas, 7 dias.
O que mostra
- Lista de todos os endpoints públicos (
GET /api/content/...) — é coletada automaticamente do código, nada precisa ser mantido manualmente. - Contador ao lado de cada endpoint — quantas vezes foi chamado no período selecionado.
- Os números são retirados da métrica centralizada Prometheus do nginx-ingress, que é responsável pelo nosso tráfego. Nenhum contador separado é criado no banco de dados do projeto.
Elementos da interface
- Período — lista suspensa de período: Última Hora / Últimas 24 Horas / Últimos 7 Dias (por padrão — Últimas 24 Horas).
- Atualizar — botão para forçar a atualização dos dados.
Os dados são apresentados em uma tabela com quatro colunas:
| Coluna | O que significa |
|---|---|
| Caminho | caminho do endpoint (/api/content/...) |
| Método | método HTTP (GET, POST, …) |
| Descrição | breve descrição do endpoint |
| Solicitações | número de chamadas no período selecionado |
No topo da página, é exibido um banner informativo:
Limpeza automática não aplicável — Os dados são lidos em tempo real do Prometheus, a retenção é configurada no nível da infraestrutura de monitoramento. Esta aba não armazena dados no banco de dados CMS.
Se o Prometheus estiver indisponível, um aviso "Métrica temporariamente indisponível. Todos os endpoints são exibidos com contagem zero." aparecerá acima da tabela — a lista de endpoints ainda será exibida, mas com contador 0.
Os dados são armazenados no Prometheus com retenç ão em nível de infraestrutura (geralmente 30 dias). Para análises mais longas, é necessário armazenar manualmente. O banner informativo no topo da página alerta sobre isso.
Por que é necessário
O marketing e o produto podem ver quais recursos da API de storefront estão realmente sendo utilizados e quais estão inativos. Também é conveniente monitorar "se tudo está funcionando" — uma queda acentuada nas chamadas de um endpoint geralmente indica um problema no lado do front-end.
A resposta é armazenada em cache por 60 segundos no Redis — para não sobrecarregar o Prometheus a cada clique em "Atualizar".
Erros da API de Conteúdo
A aba "Erros da API de Conteúdo" mostra todas as respostas 4xx/5xx que a API pública retornou durante o período. Para os desenvolvedores que integram o aplicativo cliente com nossa API, agora não é necessário ter acesso aos logs do servidor — todos os erros de suas solicitações são visíveis diretamente na administração.
O que mostra
Cada registro é um erro HTTP separado. A tabela consiste em cinco colunas:
| Coluna | O que significa |
|---|---|
| Hora | timestamp do erro |
| Status | status HTTP (4xx / 5xx) |
| Método | método da solicitação (GET, POST, …) |
| Caminho | caminho (/api/content/...) |
| Mensagem | texto do erro |
Se não houver erros no período selecionado, em vez da tabela, será exibida a mensagem "Nenhum erro registrado para o período selecionado".
O campo "Mais detalhes" abre uma tela detalhada com:
- Corpo da solicitação (sem segredos — senhas, tokens, cabeçalhos de autorização são mascarados)
- Query — parâmetros da string de consulta
- Cabeçalhos
- Stack trace — expandido (até 8 KB)
Filtros
- De / até — período (campos de entrada de data com calendário).
- Status HTTP — lista suspensa de status. É possível escolher um grupo (4xx - Lado do Cliente, 5xx - Lado do Servidor) ou um código específico: 400, 401, 403, 404, 422, 500, 502, 503.
- Caminho — campo de texto para filtrar pelo caminho (por exemplo,
/api/content/blocks/*).
Botão "Excluir dados"
Exclui registros de erros para o período definido pelos campos De / Até. Se o período não for definido — exclui todos os erros.
Segurança — sanitizador
O sanitizador automaticamente remove dados sensíveis. Os campos password, token, authorization, api_key, x-app-token, cookie, set-cookie (sem distinção de maiúsculas e minúsculas) são substituídos por ***. Corpos grandes são cortados para 2 KB.
Arquitetura
Os erros são registrados através de uma fila leve Bull, para que a gravação no registro não atrase o processamento da solicitação. Se a fila estiver cheia (mais de 1000 tarefas pendentes) — novos erros são silenciosamente descartados, para não "derrubar" o Redis.
Limpeza de registros manualmente
Os registros são limpos manualmente — em cada aba que armazena dados no banco de dados, há um botão "Excluir dados":
| Aba | O que exclui |
|---|---|
| Registro de ações do admin | registros de ações do admin para o período selecionado |
| Tráfego dos admins | somente fechadas sessões para o período selecionado |
| Erros da API de Conteúdo | registros de erros para o período selecionado |
O período de exclusão é definido pelos campos De / Até nos filtros da aba. Se o período não for definido — todos os registros do tipo correspondente são excluídos. Antes da exclusão, sempre é exibida uma caixa de diálogo de confirmação "Confirmar ação", a operação é irreversível.
O botão "Excluir dados" na aba "Tráfego dos admins" não exclui sessões ativas dos admins — mesmo que um período que sobreponha o momento atual seja definido, a sessão aberta de um colega que está trabalhando não será excluída. Somente sessões fechadas são excluídas.
Os dados de estatísticas são lidos em tempo real do Prometheus e não são armazenados no banco de dados CMS, portanto, não há botão "Excluir dados" nesta aba — isso é informado pelo banner "Limpeza automática não aplicável".
Permissões para o registro
Cada aba do registro está disponível sob uma permissão separada no árvore de permissões:
| Aba | Permissão |
|---|---|
| Registro de ações do admin | journal.viewAdminActions (permissão existente, sem alterações) |
| Tráfego dos admins | journal.viewAdminAccess (nova permissão) |
| Estatísticas da API de Conteúdo | journal.viewContentApiStats (nova permissão) |
| Erros da API de Conteúdo | journal.viewContentApiErrors (nova permissão) |
Durante a atualização do sistema, ambas as novas permissões (journal.viewContentApiStats, journal.viewContentApiErrors) foram automaticamente concedidas a todos os administradores existentes com a permissão admins.get — através de migração de seed. Para os papéis atuais, nada foi quebrado.