O que o Sentrya lê do seu Zabbix
A lista completa do que o Sentrya pede ao seu Zabbix, para quê e quando. Quase tudo é leitura. O Sentrya escreve no seu Zabbix em só dois casos: o reconhecimento (ACK) que alguém da sua equipe faz pelo Sentrya e os tokens de API que ele cria, renova e apaga para vincular cada pessoa ao usuário dela.
Em uma frase
- O que é do Sentrya fica no banco do Sentrya: incidentes, reconhecimentos, recorrências e os grupos de cada incidente.
- O que é do Zabbix (hosts, itens, triggers e valores) é lido na hora e fica só na memória do serviço, por poucos minutos. Nada disso é gravado no banco do Sentrya.
- O Sentrya nunca pede campos com credencial ou configuração sensível, e o Sentrya Connector recusa esses campos mesmo que alguém peça.
O que é lido, e para quê
| Recurso do Sentrya | Métodos | Quando |
|---|---|---|
| Coleta de incidentes | problem.get, trigger.get, hostgroup.get, event.get | A cada ciclo da coleta: problemas abertos, o host de cada problema, as triggers monitoradas, os grupos dos hosts e, quando uma trigger aparece pela primeira vez, quantas vezes ela abriu problema nos últimos 30 dias. Veja O que é coletado. |
| Verificar a conexão | apiinfo.version, host.get (só a contagem) | Ao conectar e ao tocar em Verificar conexão. |
| Descobrir o usuário da coleta | user.login (usuário e senha), user.checkAuthentication e token.get (token de API), user.get | Depois de uma verificação que dá certo: ao salvar o servidor, em Verificar conexão e ao trocar a conexão. Lê só quem é o usuário da credencial e o tipo dele (Super admin, Admin ou User), para dizer em nome de quem sai o ACK de quem não tem vínculo. Pelo Sentrya Connector, só user.get. Veja Conectar o Zabbix. |
| Reconhecer (ACK) e Histórico de ACKs | event.acknowledge (escrita), event.get | Quando alguém reconhece, comenta, muda a severidade ou fecha um problema pelo Sentrya, e ao abrir o Histórico de ACKs. |
| Assistente de ouvintes, filtros e visões | hostgroup.get, host.get, trigger.get | Ao navegar pelos grupos, hosts e gatilhos do Zabbix nessas telas. |
| Histórico do item | item.get, history.get, trend.get | Só quando alguém abre o gráfico de um item. |
| Explorar (app) | host.get, hostgroup.get, item.get, trigger.get, event.get, trend.get | Só quando alguém abre as telas Hosts, Dados recentes ou Triggers no app. |
| Entrada da equipe (painel de administração) | user.get, usergroup.get | Só nessa tela: a lista de usuários do Zabbix e os grupos de um usuário. |
| Vínculo do usuário com o Zabbix por token de API | user.checkAuthentication (Zabbix 6.0 ou mais novo) ou token.get (5.4), e user.get, todos com o token que a pessoa colou | Quando a pessoa cola o token e a cada Verificar conexão: descobre de quem é o token e confere que o papel dele permite a API. |
| Vínculo por usuário e senha | user.login, user.get, token.get, token.delete, token.create, token.generate, user.logout e, às vezes, user.checkAuthentication, com a sessão da própria pessoa | Uma vez, quando a pessoa vincula: entra com a senha dela, confere que o papel dela permite a API, apaga um token Sentrya · … de mesmo nome que tenha sobrado de um vínculo anterior, cria o token dela, encerra a sessão e descarta a senha. Se o papel dela não permite criar token, e o usuário da coleta é Super admin, token.get, token.delete, token.create e token.generate saem com o usuário da coleta. Num Zabbix anterior à 5.4, só user.login: a sessão é reaproveitada nos reconhecimentos e conferida com user.checkAuthentication. Pelo Sentrya Connector que guarda os tokens de pessoa, as mesmas chamadas passam pelo conector: o token.create sai com o usuário da pessoa, o conector guarda o token gerado e devolve ao Sentrya só o identificador, e a conferência final é um user.get do próprio usuário da pessoa, com o token guardado. Pelo Sentrya Connector que não guarda tokens de pessoa (de uma versão anterior, com eles desligados ou num Zabbix anterior à 5.4), só user.login e user.get: o Sentrya grava só quem a pessoa é no Zabbix, sem token e sem senha. |
| Vínculo pelo Microsoft 365 | user.get (só o nome de usuário e os grupos de cada usuário), token.get, token.delete, token.create, token.generate, com o usuário da coleta (Super admin); depois, user.checkAuthentication ou token.get, e user.get, com o token novo da pessoa | Só nos servidores em que o administrador ligou o vínculo automático: a cada login Microsoft de quem ainda não está vinculado, ao ligar e em Vincular agora. Procura o usuário de cada pessoa pelo nome de usuário, apaga um token Sentrya · … de mesmo nome que tenha sobrado, cria o token dela e confere, com o próprio token, que o papel dela permite a API. Se não permite, o token é apagado e nada é gravado. Pelo Sentrya Connector que guarda os tokens de pessoa, as mesmas chamadas passam pelo conector, que guarda o token, e a conferência do token criado é um user.get do próprio usuário da pessoa, com ele. |
| Usar permissões do Zabbix (o que cada um enxerga) | user.get (os grupos de usuários e o tipo de cada pessoa vinculada e, na mesma chamada, o tipo do próprio usuário da coleta, para conferir que ele continua Super admin), usergroup.get (se o grupo está ativo, os direitos dele nos grupos de hosts, inclusive os negados, e os filtros de tag) e, quando alguma pessoa vinculada é Super admin no Zabbix, hostgroup.get (só os ids dos grupos de hosts), com o usuário da coleta (Super admin) | Só nos servidores em que o administrador ligou a opção: a cada cerca de 10 minutos, ao ligar, em Atualizar permissões agora, quando alguém vincula e quando o Zabbix recusa uma ação por falta de permissão. São poucas chamadas por servidor, para todas as pessoas vinculadas de uma vez, nunca uma por pessoa. Pelo Sentrya Connector, as mesmas leituras passam pela guarda do conector: com o conector atualizado, elas passam; um conector que as recuse faz a atualização falhar com "O Sentrya Connector não deixou ler as permissões: atualize o conector.", e quem está vinculado fica com o acesso inicial (ou com o que foi lido por último). |
| Manter os tokens das pessoas | token.create, token.generate, token.delete, com o usuário da coleta (Super admin); user.logout com a sessão antiga da pessoa | Em conexão direta ou pelo Sentrya Connector que guarda os tokens de pessoa, renova o token que o Sentrya criou 30 dias antes de vencer (pelo conector, o token renovado fica guardado nele). Apaga do Zabbix o token que o Sentrya criou quando a pessoa desvincula, toca em Não sou eu, é desativada ou excluída, quando a conexão do servidor muda e quando o servidor ou a empresa é excluído. Sem Super admin, ou com o Zabbix fora do ar, o Sentrya deixa de usar o token e o lista para o administrador em Tokens a apagar no Zabbix; a cada hora, tenta apagá-los de novo nos servidores cujo usuário da coleta é Super admin, em conexão direta ou pelo Sentrya Connector que guarda os tokens de pessoa. O user.logout só existe para os vínculos antigos por senha, que guardam uma sessão: ele encerra essa sessão ao desvincular, no Não sou eu, ao desativar ou excluir a conta e ao excluir o servidor ou a empresa. Na troca de conexão não há user.logout: nada sai com a credencial da pessoa para o endereço novo, e a sessão só é esquecida. |
Campos lidos
| Objeto | Campos |
|---|---|
| Host | id, nome técnico, nome visível, se está monitorado, se está em manutenção, descrição, grupos, tags, interfaces (tipo, IP ou DNS, porta, disponibilidade e erro) e, só na ficha, a quantidade de itens e triggers. |
| Item | id, host, nome, chave, tipo, tipo de valor, unidade, intervalo, retenção, estado, erro, último valor, valor anterior, hora da última verificação, descrição, mapa de valores e tags. |
| Trigger | id, nome, severidade, estado, desde quando, se está habilitada, erro, expressão, expressão de recuperação, comentários, URL, host, itens e tags. |
| Problema e evento | id, trigger, hora, nome, severidade, dados operacionais, se foi reconhecido e a trilha de reconhecimentos. |
| Valores de itens | Horário e valor (bruto) ou horário e média, mínimo e máximo por hora, só de itens numéricos. |
O que o Sentrya nunca lê
- Usuário, senha, parâmetros (scripts e SQL), cabeçalhos, corpo e URL de itens HTTP, SSH, Telnet, banco de dados e JMX, e as chaves e senhas de certificado.
- Community e senhas do SNMP (os "detalhes" das interfaces).
- Macros, inventário, pré-processamento, regras de descoberta, templates, usuário e senha de IPMI e as chaves PSK.
- Valores de itens de log (nos servidores atrás do Sentrya Connector, o conector também os esconde). O nome de um problema, os dados operacionais e a descrição de uma trigger são textos que o próprio Zabbix monta: se a trigger usa uma macro como
{ITEM.VALUE}neles, o valor vem dentro do texto. Valores de itens de texto só são pedidos e mostrados no Explorar se o administrador ligar Mostrar valores de texto, cortados em 200 caracteres. - Dos usuários do Zabbix, só login, nome, tipo, papel e grupos e, com Usar permissões do Zabbix, os direitos e os filtros de tag dos grupos de usuários: nunca senha, mídias (e-mails e telefones de notificação) nem os tipos de mídia (tokens de webhook e SMTP). O vínculo pelo Microsoft 365 também não lê mídias: ele compara só o nome de usuário.
- Dos tokens de API que já existem, só o id, o nome, o dono e o vencimento: nunca o token em si. O Sentrya só tem o segredo dos tokens que ele mesmo cria para as pessoas vinculadas e dos tokens que as pessoas colam no vínculo, e guarda os dois cifrados. Num servidor ligado pelo Sentrya Connector, o token que o Sentrya cria para a pessoa fica guardado no conector, e o Sentrya nunca o vê. Senha de pessoa só fica guardada, também cifrada, no vínculo por usuário e senha de um Zabbix anterior à 5.4, que não tem token de API.
Não guarde senha na chave do item. A chave, a mensagem de erro e a URL da trigger aparecem no Explorar. O Sentrya mascara os padrões óbvios (
PWD=, password=, token= e usuário:senha@ numa URL), mas não reconhece todos, como o parâmetro de senha de alguns plugins do Zabbix Agent 2. Use uma macro secreta do Zabbix: ela nunca volta expandida pela API.O Sentrya pede ao Zabbix uma lista fixa de campos em cada consulta (nunca "todos os campos"). Em servidores atrás do Sentrya Connector, o conector confere de novo cada consulta e recusa qualquer campo fora da lista ou sensível, sem tocar o Zabbix. Veja Segurança do Sentrya Connector.
Papel de API recomendado
O jeito mais seguro é dar ao Sentrya um usuário do Zabbix só de leitura, com um papel de API que libere apenas os métodos acima, e leitura só nos grupos de hosts que o Sentrya deve ver. O Sentrya só enxerga o que esse usuário pode ler: se o usuário não vê um grupo, o Sentrya também não vê.
| Método | Precisa para |
|---|---|
problem.get, trigger.get, hostgroup.get, host.get, event.get | Coleta de incidentes (obrigatórios). |
item.get | Histórico do item e Explorar. |
history.get, trend.get | Gráficos e minigráficos. |
event.acknowledge | Só se a equipe for reconhecer pelo Sentrya. Quem reconhece sem Vínculo com o Zabbix usa este usuário, e esse reconhecimento sempre leva um comentário (o nome da pessoa no fim): o papel do usuário precisa poder reconhecer e comentar problemas. |
user.get, usergroup.get | Entrada da equipe, Vínculo com o Zabbix e Usar permissões do Zabbix (que também exige o usuário da coleta Super admin). O user.get também descobre o nome do usuário da coleta (sem ele, os avisos dizem "o usuário da coleta") e procura o usuário de cada pessoa no vínculo pelo Microsoft 365. |
token.get | Descobrir o usuário da coleta quando a credencial é um token de API num Zabbix 5.4, e achar tokens Sentrya · … que sobraram de um vínculo anterior. |
token.create, token.generate, token.delete | Criar, renovar e apagar os tokens das pessoas: no vínculo pelo Microsoft 365, no vínculo por senha quando o papel da pessoa não cria o próprio token, e ao desfazer vínculos. Todos exigem o usuário da coleta Super admin. Veja Dar Super admin ao usuário da coleta. |
O que o vínculo faz com o token ou a senha da própria pessoa depende do papel dela no Zabbix, não do usuário da coleta: event.acknowledge e a verificação (user.checkAuthentication, token.get, user.get) e, no vínculo por senha, também token.get, token.delete, token.create, token.generate e user.logout. Pelo Sentrya Connector que guarda os tokens de pessoa, o token da pessoa só entra no event.acknowledge e no user.get da verificação, que lê só o próprio usuário dela.
O passo a passo para criar o papel e o usuário está em Preparar o usuário no Zabbix; vale igual para servidores conectados direto. Se um método não estiver liberado, a tela que depende dele avisa "O usuário do Zabbix usado pelo Sentrya não pode ler…" e o resto continua funcionando.
Quanto o Sentrya pede
- A coleta de incidentes roda a cada poucos segundos, com os limites descritos em O que é coletado.
- Histórico e Explorar só consultam quando alguém abre a tela, com teto de consultas simultâneas por servidor somando todas as pessoas, respostas compartilhadas por alguns minutos entre quem olha a mesma coisa e uma pausa automática quando o Zabbix fica lento. Os números estão em cada página.
- O administrador desliga o Histórico ao vivo e o Explorar (app) por servidor, a qualquer momento.