SysAdmin Urbano: outubro 2025

terça-feira, 28 de outubro de 2025

Infoblox — do DNS ao Tuning [Capítulo 02]

Infoblox — do DNS ao Tuning [Capítulo 02] Zonas, Subzonas e Views: como o Infoblox organiza o DNS

Publicado por Sysadmin Urbano | Infraestrutura, SysOps e DevOps

Um guia prático para quem vive na linha de frente da operação de sistemas.

Pilar 1: DNS ➜ Pilar 2: Infoblox ➜ Pilar 3: Boas práticas. Exemplos: example.com, dev.example.com, IPs 198.51.100.0/24.

1) Conceito: zonas, subzonas e Views

Zona: recorte do namespace com SOA e NS próprios (ex.: example.com).
Subzona: porção delegada ou administrada dentro da zona (ex.: dev.example.com).
View: “universos DNS” paralelos (ex.: internal, external) — a mesma zona pode existir em múltiplas Views com respostas diferentes.

Regra Delegação e autoridade valem por View. Zona-pai e subzona precisam estar na mesma View para a delegação surtir efeito naquela audiência.

2) Infoblox: criando e organizando

2.1 Criar zona-pai e subzona (Authoritative local)

Data Management → DNS → Zones → Add → Authoritative Zone
Zone Name: example.com • View: internal
Crie a subzona: Add → Authoritative Zone com dev.example.com (na mesma View).

2.2 Delegar subzona pela zona-pai

Abra example.com (mesma View) e crie uma Delegation para dev.example.com.
Inclua NS que respondem pela subzona:

dev.example.com. IN NS ns1.dev.example.com.
dev.example.com. IN NS ns2.dev.example.com.
ns1.dev.example.com. IN A 198.51.100.31  ; glue se necessário
ns2.dev.example.com. IN A 198.51.100.32  ; glue se necessário

2.3 Subzona “None” (sem delegação)

Ao definir a subzona como None (sem delegação na pai), a autoridade fica local: você cria os NS dentro de dev.example.com.

Atenção “None” puxa a autoridade para o seu grid. Combine com times que operavam NS externos.

3) Delegation x None: como decidir

Delegation: quando outro time ou infraestrutura responde pela subzona (NS externos ou outro grid).
None: quando você quer administrar a subzona localmente no Infoblox.
Forward/Stub: não são autoridade — usados para encaminhamento/consulta, não para publicar registros.

Dica Em ambientes híbridos (internal/external), mantenha consistência por View: a delegação na View internal não vale para external.

4) Boas práticas

Naming previsível: ns1, ns2, api, mail.
Glue sempre que o NS estiver dentro da própria subzona.
Evite CNAME no apex e conflitos CNAME ↔ A/MX/NS.
TTL ajustado ao ciclo de mudanças (300–600s em migrações, 3600–14400s no estável).
Serial SOA em formato YYYYMMDDnn e incremente a cada alteração.

5) Validação e testes

5.1 Autoridade da zona-pai (sem recursão):

dig @198.51.100.10 example.com SOA +norec
dig @198.51.100.10 example.com NS  +norec

5.2 Delegação para a subzona (trace completo):

dig +trace dev.example.com NS

5.3 Windows (nslookup) apontando ao Member:

nslookup -type=SOA example.com     198.51.100.10
nslookup -type=NS  dev.example.com 198.51.100.10

6) Troubleshooting

Sem permissão ao editar NS na subzona? Ela está Delegated. Edite os NS na zona-pai (mesma View) ou mude para None.
Erro “An NS record requires at least one name server address”? Falta glue (A/AAAA) do host NS. Crie o A/AAAA ou anexe IP ao NS externo.
Respostas diferentes entre usuários? Views diferentes (ex.: internal vs external).
Forward/Stub não publica registros: converta para Authoritative se quiser servir a zona localmente.

Pro tip Em mudanças programadas, reduza TTL horas antes, valide, e só então restaure ao padrão.

7) Trilha de certificação (mapa do capítulo)

Conceito: zonas, subzonas, SOA, NS, delegação, glue, Views.
Infoblox: criação de zonas Authoritative, Delegation, edição por View.
Prática: validar SOA/NS, dig +trace, troubleshooting de delegação.

Objetivo Dominar onde criar registros e em qual View, pré-requisito para módulos de DDI e administração de Grid.

8) Próximo capítulo

Capítulo 03 — Delegação e Autoridade: onde o DNS “manda” e onde ele “ouve”
Casos práticos de Delegation x None no Infoblox, impacto por View e estratégia de migração segura com rollback.

Sobre o Sysadmin Urbano

O Sysadmin Urbano nasceu da vivência real no front das operações de infraestrutura moderna. Aqui falamos de servidores, containers, automação, boas práticas e também dos desafios invisíveis da rotina de quem mantém sistemas vivos. Sem fórmulas mágicas, sem tutoriais pela metade — apenas conteúdo prático, direto e feito para quem sabe que a TI é tanto técnica quanto sobrevivência.

🔗 Confira mais artigos ou volte para a página inicial.

Gostou deste conteúdo?

Siga o Sysadmin Urbano para mais artigos técnicos sobre Infraestrutura, SysOps e DevOps.

Voltar para a página inicial

sexta-feira, 24 de outubro de 2025

Zabbix — Season Finale - Temporada 1

Zabbix — Season Finale: Diário de Bordo e Checklist de Tuning

Publicado por Sysadmin Urbano | Infraestrutura, SysOps e DevOps

Um guia prático para quem vive na linha de frente da operação de sistemas.

Zabbix — Season Finale: Diário de Bordo e Checklist de Tuning

Parte 9 da série “Zabbix — da Migração ao Fine-Tuning” no Sysadmin Urbano.

Depois de oito capítulos aprofundados, esta Season Finale fecha a primeira temporada do projeto. Aqui reunimos tudo: um checklist de tuning, links de referência e o diário de bordo para documentar a jornada do seu Zabbix — desde a migração da versão 4 até o refinamento completo na 7.

“O tuning não termina — ele amadurece. A cada ajuste, o Zabbix se torna mais previsível, mais leve e mais seu.”

1) Objetivo

Transformar as oito partes anteriores em uma rotina prática de revisão, permitindo acompanhar e documentar a evolução do ambiente. Use esta página como checklist de tuning e guia de iteração contínua.

2) Linha do tempo da migração e tuning

Parte 1: Atualizando o Zabbix 4 para o Zabbix 5
Parte 2: Tabelas gigantes no Zabbix?
Parte 3: Particionamento no Zabbix
Parte 4: Conectando o Zabbix ao mundo (NetBox e LDAP)
Parte 5: Zabbix sob pressão: travas, timeouts e queries lentas
Parte 6: Automação de manutenção e scripts
Parte 7: Zabbix Proxies: distribuição e resiliência
Parte 8: Auditoria invisível: o Zabbix monitorando a si mesmo

3) Checklist de Tuning (versões 4 → 7)

📦 Backup total antes de qualquer atualização (base, config, /etc, /usr/share/zabbix)
🔧 Atualizar servidor principal e proxies em sincronia de versão
🗃️ Verificar engine InnoDB e charset UTF8MB4
📊 Validar histórico e trends após upgrade
⚙️ Aplicar particionamento em tabelas de histórico e trends
🧹 Implementar rotinas automáticas de limpeza e expurgo
🪶 Otimizar parâmetros do MySQL (buffer pool, log flush, io capacity)
📈 Ativar slow query log e monitorar queries pesadas
🌐 Configurar integração com NetBox (inventário dinâmico)
🔐 Integrar autenticação via LDAP corporativo
🛰️ Implantar proxies regionais e configurar cache
🧩 Validar triggers de auditoria interna (zabbix[queue], cache, pollers)
📬 Testar envios automáticos via zabbix_sender para scripts de manutenção
🧠 Ativar dashboard de autoconsciência do Zabbix Server
🪪 Verificar licenças, dependências e atualizações dos pacotes
📂 Agendar expurgo dos bancos locais dos proxies
🧾 Documentar versões, tempos médios de resposta e incidentes

4) Diário de Bordo de Tuning

Utilize este formato de registro em cada ciclo de manutenção:

# Diário de Bordo Zabbix — Temporada 1
Data: $(date +%F)
Responsável: <Nome do Administrador>
Versão atual: 7.0.2

## Contexto
Resumo da intervenção executada e motivo.

## Ações realizadas
- [ ] Revisão de tabelas particionadas
- [ ] Otimização de parâmetros MySQL
- [ ] Teste de replicação Proxy → Server

## Métricas observadas
- Fila média de itens: 2.3s
- Cache history: 74%
- Itens não suportados: 0.3%

## Próximas ações
- Revalidar rotinas de expurgo no próximo ciclo
- Revisar triggers de auditoria interna
- Atualizar documentação do template self-check

Esse modelo cria histórico técnico e facilita auditoria futura.

5) Manutenção contínua (segunda temporada)

Este Season Finale encerra o primeiro ciclo da jornada, mas o tuning nunca termina. A partir daqui, o foco se desloca para temas como:

Elasticidade e escalabilidade do banco de dados
Alta disponibilidade e redundância entre proxies
Monitoramento de performance do frontend
Integração com Prometheus, Grafana e OpenMetrics

“O Zabbix 7 não é o fim da estrada — é o ponto onde o monitoramento começa a se autogerir.” — *Dário Junior*

Sobre o Sysadmin Urbano

🔗 Confira mais artigos ou volte para a página inicial.

Gostou deste conteúdo?

Siga o Sysadmin Urbano para mais artigos técnicos sobre Infraestrutura, SysOps e DevOps.

Voltar para a página inicial

quinta-feira, 23 de outubro de 2025

Zabbix — da Migração ao Fine-Tuning - capítulo 8

Auditoria invisível: o Zabbix monitorando a si mesmo

Publicado por Sysadmin Urbano | Infraestrutura, SysOps e DevOps

Um guia prático para quem vive na linha de frente da operação de sistemas.

Auditoria invisível: o Zabbix monitorando a si mesmo

Capítulo 8 da série “Zabbix — da Migração ao Fine-Tuning” no Sysadmin Urbano.

Depois de integrar, automatizar e distribuir, falta apenas um passo para fechar o ciclo: ensinar o Zabbix a monitorar a si mesmo. Afinal, quem monitora o monitoramento?

“Todo sistema crítico precisa de autoconsciência: um Zabbix sem auditoria é um médico que nunca mede sua própria pressão.”

1) Itens internos: os sensores do próprio Zabbix

O Zabbix possui chaves internas que permitem medir a saúde de seus próprios processos e bancos de dados. Esses itens não exigem agentes nem proxies — são nativos.

zabbix[queue]
zabbix[process,dbsyncer,avg,busy]
zabbix[process,poller,avg,busy]
zabbix[cache,usage,history]
zabbix[cache,usage,trends]
zabbix[cache,buffer,free,pct]
zabbix[triggers,enabled]
zabbix[items,not_supported]
zabbix[proxy,,lastaccess]

Essas chaves mostram tudo — do uso de memória cache à fila de itens não processados.

2) Criando um template de auditoria

Crie um novo template chamado Template Audit — Zabbix Self Check e adicione os seguintes itens:

zabbix[queue] → Tipo: Zabbix internal → Unidade: s → Intervalo: 60s
zabbix[items,not_supported] → Tipo: Zabbix internal → Intervalo: 300s
zabbix[cache,usage,history] → Unidade: % → Intervalo: 60s
zabbix[process,dbsyncer,avg,busy] → Unidade: % → Intervalo: 60s

Com isso, você passa a ter uma visão clara de como o Zabbix está se comportando internamente.

3) Criando triggers inteligentes

Essas triggers ajudam a detectar anomalias antes que o sistema pare completamente:

{Zabbix server:zabbix[queue].avg(5m)}>10
  → Fila de processamento atrasada

{Zabbix server:zabbix[items,not_supported].avg(10m)}>50
  → Muitos itens não suportados

{Zabbix server:zabbix[cache,usage,history].avg(5m)}>90
  → Cache de histórico quase cheio

{Zabbix server:zabbix[process,dbsyncer,avg,busy].avg(5m)}>80
  → Processos de sincronização sobrecarregados

Essas triggers permitem agir proativamente — antes que o banco trave, o cache sature ou a fila exploda.

4) Dashboard de saúde do Zabbix

Monte um dashboard interno com quatro widgets principais:

Gráfico de fila de processamento (zabbix[queue])
Uso de cache de histórico (zabbix[cache,usage,history])
Processos DB Syncer (zabbix[process,dbsyncer,avg,busy])
Itens não suportados (zabbix[items,not_supported])

Isso cria uma “sala de controle” visual, onde é possível perceber desvios em tempo real — e reagir antes que o impacto apareça.

5) Auditoria do banco de dados

Adicione uma checagem SQL simples para validar acessibilidade e latência do banco:

#!/usr/bin/env bash
MYSQL="mysql --defaults-extra-file=$HOME/.my.cnf --batch --skip-column-names"
T1=$(date +%s%3N)
$MYSQL -e "SELECT 1" >/dev/null 2>&1
T2=$(date +%s%3N)
echo $((T2 - T1))

O resultado (em milissegundos) pode ser enviado ao Zabbix via zabbix_sender para compor o painel de auditoria.

6) Verificação de proxies

Para ambientes distribuídos, é essencial garantir que todos os proxies estejam sincronizando corretamente:

zabbix_get -s proxy01 -k "proxy.ping"
zabbix_get -s proxy02 -k "proxy.history.lastsync"
zabbix_get -s proxy03 -k "proxy.offlinebuffer.size"

Esses testes simples confirmam se cada proxy ainda “fala” com o servidor — e há quanto tempo o fez pela última vez.

7) Auditoria invisível via API

Com a API do Zabbix, você pode criar uma rotina que compare configurações críticas (como templates, usuários e hosts ativos) e alerte em caso de discrepância.

#!/usr/bin/env python3
import requests

ZABBIX_URL = "http://zabbix.local/api_jsonrpc.php"
USER = "Admin"
PASSWORD = "zabbix"

def zbx_request(method, params):
    payload = {"jsonrpc": "2.0", "method": method, "params": params, "id": 1}
    r = requests.post(ZABBIX_URL, json=payload)
    return r.json()["result"]

auth = zbx_request("user.login", {"user": USER, "password": PASSWORD})
users = zbx_request("user.get", {"output": ["alias", "type"], "auth": auth, "id": 2})

if any(u["type"] == "3" for u in users):
    print("Há usuários com privilégios de Super Admin — revisar!")

Esse tipo de auditoria preventiva evita surpresas de segurança e inconsistências administrativas.

8) Boas práticas

Mantenha todos os itens internos em um template dedicado e documentado.
Use triggers silenciosas (com prioridade “Information”) para alertas não críticos.
Adicione verificações de auditoria também em proxies.
Armazene o resultado das checagens em dashboards consolidados.
Revise periodicamente os thresholds das triggers.

9) Conclusão

O Zabbix pode — e deve — ser o primeiro a saber quando algo está errado. Ao se monitorar, ele se torna autossuficiente, capaz de detectar lentidão, falhas internas e anomalias operacionais antes que alguém perceba.

Auditar o próprio sistema é o estágio final da maturidade em monitoração: quando o Zabbix deixa de ser apenas uma ferramenta e passa a ser uma consciência operacional.

Sobre o Sysadmin Urbano

🔗 Confira mais artigos ou volte para a página inicial.

Gostou deste conteúdo?

Siga o Sysadmin Urbano para mais artigos técnicos sobre Infraestrutura, SysOps e DevOps.

Voltar para a página inicial

quarta-feira, 22 de outubro de 2025

Zabbix — da Migração ao Fine-Tuning - capítulo 7

Zabbix Proxies: distribuindo carga e garantindo resiliência

Publicado por Sysadmin Urbano | Infraestrutura, SysOps e DevOps

Um guia prático para quem vive na linha de frente da operação de sistemas.

Zabbix Proxies: distribuindo carga e garantindo resiliência

Capítulo 7 da série “Zabbix — da Migração ao Fine-Tuning” no Sysadmin Urbano.

O Zabbix Proxy é um dos recursos mais poderosos — e subutilizados — do ecossistema. Ele permite descentralizar a coleta, reduzir carga no servidor principal e manter a monitoração funcionando mesmo em caso de falhas de rede.

“Sem proxies, o Zabbix é uma estação meteorológica de um único sensor. Com proxies, torna-se uma rede completa de satélites.”

1) Por que usar proxies

Reduz carga e conexões simultâneas no servidor principal.
Coleta local mesmo sem link ativo com o servidor.
Permite segmentar monitorações por regiões, clientes ou data centers.
Armazena dados temporariamente e sincroniza quando possível.

2) Instalando um Zabbix Proxy

O processo é simples e pode ser feito tanto com SQLite (para ambientes pequenos) quanto MySQL/MariaDB (para alta escala).

# Exemplo para Oracle Linux / RHEL / CentOS
dnf install zabbix-proxy-mysql mariadb-server

systemctl enable --now mariadb
mysql_secure_installation

# Criar banco e permissões
mysql -e "CREATE DATABASE zabbix_proxy CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;"
mysql -e "CREATE USER 'zabbix'@'localhost' IDENTIFIED BY 'senha_proxy';"
mysql -e "GRANT ALL PRIVILEGES ON zabbix_proxy.* TO 'zabbix'@'localhost';"
mysql -e "FLUSH PRIVILEGES;"

# Importar schema
zcat /usr/share/zabbix-sql-scripts/mysql/proxy.sql.gz | mysql -uzabbix -p zabbix_proxy

3) Configuração do Proxy

O arquivo de configuração principal é /etc/zabbix/zabbix_proxy.conf. Os parâmetros críticos incluem:

Server=192.168.10.100
Hostname=proxy_datacenter1
DBName=zabbix_proxy
DBUser=zabbix
DBPassword=senha_proxy
ProxyLocalBuffer=24
ProxyOfflineBuffer=48
ConfigFrequency=3600
DataSenderFrequency=1
StartPollers=20

O parâmetro ProxyOfflineBuffer define quantas horas o proxy armazenará dados localmente caso o servidor principal fique indisponível.

4) Comunicação com o Zabbix Server

No servidor principal, cadastre o proxy em Administration → Proxies → Create Proxy. Defina o nome exatamente igual ao campo Hostname do arquivo de configuração.

Depois disso, os hosts poderão ser atribuídos a esse proxy, e o tráfego fluirá automaticamente.

5) Manutenção e expurgo do banco local

5.1) Verificando tamanho das tabelas

SELECT table_name,
       ROUND((data_length + index_length)/1024/1024, 2) AS tamanho_mb
FROM information_schema.tables
WHERE table_schema = 'zabbix_proxy'
ORDER BY tamanho_mb DESC
LIMIT 10;

Em proxies grandes, o banco local também cresce rapidamente. O mesmo processo de particionamento e expurgo pode ser aplicado aqui.

5.2) Script simples de limpeza

Para proxies menores (com SQLite), use a seguinte limpeza controlada por data:

#!/usr/bin/env bash
sqlite3 /var/lib/zabbix/zabbix_proxy.db \
"DELETE FROM history WHERE clock < strftime('%s','now','-7 day');
 VACUUM;"

Esse script remove dados mais antigos que 7 dias e compacta o banco.

5.3) Para bancos MySQL

#!/usr/bin/env bash
MYSQL="mysql --defaults-extra-file=$HOME/.my.cnf"
DB="zabbix_proxy"
DAYS=30
LOG="/var/log/zbx_proxy_cleanup_$(date +%F).log"

echo "== Limpando tabelas proxy ==" | tee -a "$LOG"
for T in history history_uint history_str history_text history_log; do
  echo "Tabela: $T" | tee -a "$LOG"
  $MYSQL -e "DELETE FROM ${DB}.${T} WHERE clock < UNIX_TIMESTAMP(DATE_SUB(NOW(), INTERVAL ${DAYS} DAY));" >> "$LOG" 2>&1
done
echo "== Concluído ==" | tee -a "$LOG"

6) Sincronização e cache

O proxy armazena dados temporariamente em memória e no disco até que consiga reenviar ao servidor. Para verificar o status dessa comunicação:

zabbix_get -s proxy_datacenter1 -k "proxy.ping"
zabbix_get -s proxy_datacenter1 -k "proxy.history.lastsync"
zabbix_get -s proxy_datacenter1 -k "proxy.history.fromserver"

Esses dados ajudam a entender se há atraso de envio ou fila acumulada no buffer local.

7) Estratégias de distribuição

Use proxies por segmento de rede ou cliente.
Evite proxies genéricos para todo o ambiente.
Proxies com banco local em SSD têm desempenho muito superior.
Monitore a fila de sincronização com um item do tipo zabbix[proxy,queue].

8) Boas práticas

Mantenha versões de proxy e server sempre alinhadas.
Evite SQLite em ambientes de alta coleta (prefira MySQL/MariaDB).
Automatize a limpeza local como no capítulo 6.
Em ambientes críticos, configure dual proxies para redundância.
Verifique o espaço em disco com alertas no próprio Zabbix.

9) Conclusão

Os proxies são o elo entre performance e resiliência no Zabbix. Eles distribuem o peso, reduzem a latência e garantem que nenhum dado se perca, mesmo sob falhas de rede. Com uma configuração bem planejada e manutenção automatizada, o ambiente cresce sem sustos — e com confiança.

Sobre o Sysadmin Urbano

🔗 Confira mais artigos ou volte para a página inicial.

Gostou deste conteúdo?

Siga o Sysadmin Urbano para mais artigos técnicos sobre Infraestrutura, SysOps e DevOps.

Voltar para a página inicial

terça-feira, 21 de outubro de 2025

Infoblox — do DNS ao Tuning [Capítulo 01]

Infoblox — do DNS ao Tuning [Capítulo 01] O que é DNS — muito além do A e do CNAME

Publicado por Sysadmin Urbano | Infraestrutura, SysOps e DevOps

Um guia prático para quem vive na linha de frente da operação de sistemas.

1) Introdução à série

Bem-vindo à série “Infoblox — do DNS ao Tuning”. Cada capítulo começa em DNS puro, traduz o conceito no Infoblox e fecha com boas práticas e validação. Vamos do alicerce ao fine-tuning, cobrindo também os tópicos chaves da jornada de certificação Infoblox.

Estrutura Conceito ➜ Implementação no Infoblox ➜ Boas práticas ➜ Testes e Troubleshooting

2) DNS — conceitos que importam

Autoridade: quem “manda” numa zona/subzona (quem publica o SOA/NS).
Recursão x Iteração: o resolvedor recursivo pergunta “em cadeia” até chegar à autoridade.
Cache: respostas são guardadas pelo TTL (quanto menor, mais tráfego; quanto maior, mais lentidão para propagar mudanças).
Zonas: porção do namespace servida por um conjunto de servidores autoritativos (definida por SOA e NS).

3) Registros essenciais

3.1 SOA (Start of Authority)

Define o início de autoridade da zona, serial e timers.

; SOA mínimo e didático (exemplo)
example.com. IN SOA ns1.example.com. hostmaster.example.com. (
  2025101601 ; serial (YYYYMMDDnn)
  3600       ; refresh
  900        ; retry
  1209600    ; expire
  300        ; minimum/negative TTL
)

3.2 NS, A/AAAA e CNAME

NS apontam para os servidores autoritativos. Se o NS está dentro da própria zona/subzona, é necessário o glue (A/AAAA do host NS).

; NS do apex + glue
example.com.     IN NS ns1.example.com.
example.com.     IN NS ns2.example.com.
ns1.example.com. IN A  198.51.100.11
ns2.example.com. IN A  198.51.100.12

; CNAME (não use CNAME no apex e não conflita com A/MX/NS)
www.example.com. IN CNAME app.example.net.

3.3 MX, PTR e TXT

; MX (e o A do host de mail)
example.com.   IN MX 10 mail.example.com.
mail.example.com. IN A 198.51.100.20

; PTR (zona reversa)
11.100.51.198.in-addr.arpa. IN PTR server11.example.com.

; TXT (usos diversos: SPF, verificações, etc.)
example.com. IN TXT "v=spf1 -all"

4) Delegação, glue e autoridade

Delegar uma subzona (ex.: dev.example.com) significa publicar, na zona-pai (example.com), os NS que “mandam” naquela subzona. Se os NS forem dentro de dev.example.com, crie os glue records (A/AAAA) para o recursor saber o IP desses NS.

; Na zona-pai (example.com)
dev.example.com. IN NS ns1.dev.example.com.
dev.example.com. IN NS ns2.dev.example.com.
; Glue (pode estar na própria pai, se necessário)
ns1.dev.example.com. IN A 198.51.100.31
ns2.dev.example.com. IN A 198.51.100.32

Atenção Sem glue, muitos resolvedores não conseguem chegar nos NS da subzona → falhas intermitentes.

5) Como isso se traduz no Infoblox

5.1 Zonas e Views

Views são “universos DNS” distintos (ex.: internal, external).
A zona-pai e a subzona precisam estar na mesma View para a delegação valer naquela audiência.

5.2 Onde criar NS

Subzona Authoritative/None (local): crie NS dentro da subzona (Add → Record → NS), com A/AAAA dos hosts NS.
Subzona Delegated: crie/edite NS na zona-pai (Delegation da subzona) e garanta o glue.
Forward/Stub: não criam NS locais (são modos especiais).

5.3 Erro comum que veremos muito

Erro clássico “An NS record requires at least one name server address.” — Crie o A/AAAA do host NS (glue) antes ou informe o IP ao cadastrar o NS externo.

6) Boas práticas desde o Dia 1

Serial SOA no formato YYYYMMDDnn e incremente a cada mudança.
TTL razoável: 300–600s para ambientes em mudança; 3.600–14.400s para estáveis.
Naming claro para NS (ex.: ns1, ns2) e serviços (api, auth).
Evite CNAME no apex e conflitos CNAME ↔ A/MX/NS.
Delegação: sempre garantir glue quando necessário.
Manter Views coerentes (pai e subzona na mesma view).

7) Validação com dig/nslookup

7.1 SOA/NS da zona-pai (autoridade local, sem recursão):

dig @198.51.100.10 example.com SOA +norec
dig @198.51.100.10 example.com NS  +norec

7.2 Cadeia de delegação até a subzona:

dig +trace dev.example.com NS

7.3 Consultas Windows (nslookup):

nslookup -type=SOA example.com       198.51.100.10
nslookup -type=NS  dev.example.com   198.51.100.10

8) Checklist do capítulo

SOA e NS definidos para example.com.
Subzona dev.example.com com delegação correta e glue quando necessário.
Entendimento de Views e onde editar NS (pai vs. subzona).
TTL ajustado ao seu contexto.
Validações com dig e nslookup realizadas.

Pro tip Em janelas de mudança, reduza o TTL horas antes. Após estabilizar, volte ao padrão.

9) Próximo capítulo

Capítulo 02 — Zonas, Subzonas e Views: como o Infoblox organiza o DNS
Hierarquia prática, tipos de zona (Authoritative, Delegated, Forward, Stub), quando usar cada um e como manter consistência entre Views.

Sobre o Sysadmin Urbano

🔗 Confira mais artigos ou volte para a página inicial.

Gostou deste conteúdo?

Siga o Sysadmin Urbano para mais artigos técnicos sobre Infraestrutura, SysOps e DevOps.

Voltar para a página inicial

segunda-feira, 20 de outubro de 2025

Zabbix — da Migração ao Fine-Tuning - capítulo 6

Automação de manutenção: scripts que mantêm seu Zabbix saudável

Publicado por Sysadmin Urbano | Infraestrutura, SysOps e DevOps

Um guia prático para quem vive na linha de frente da operação de sistemas.

Automação de manutenção: scripts que mantêm seu Zabbix saudável

Capítulo 6 da série “Zabbix — da Migração ao Fine-Tuning” no Sysadmin Urbano.

Com o banco de dados particionado e os ajustes de desempenho feitos, o próximo passo é deixar tudo autônomo. Este capítulo reúne os principais scripts de manutenção que mantêm o Zabbix limpo, rápido e previsível — sem depender de ações manuais.

“Manter um Zabbix saudável é mais sobre rotina do que intervenção. Automatize o que é repetitivo, e o sistema fará o resto.”

1) Estrutura de diretórios e boas práticas

Crie um diretório dedicado para armazenar todos os scripts e logs de manutenção:

mkdir -p /opt/zbx_maintenance
mkdir -p /var/log/zbx_maintenance
chmod 750 /opt/zbx_maintenance
chmod 770 /var/log/zbx_maintenance

Manter tudo centralizado facilita auditoria, versionamento e integração com ferramentas de monitoramento externas.

2) Script de expurgo manual (por data)

Ideal para bancos ainda não particionados ou ambientes pequenos, o script abaixo remove dados antigos de acordo com uma data de corte definida.

#!/usr/bin/env bash
set -euo pipefail

MYSQL="mysql --defaults-extra-file=$HOME/.my.cnf --batch --raw"
DB="zabbix"
CUTOFF_DAYS=90
LOG="/var/log/zbx_maintenance/cleanup_$(date +%F).log"

echo "== Expurgo de dados antigos (history*) iniciado em $(date -Is) ==" | tee -a "$LOG"

for T in history history_uint history_str history_text history_log; do
  echo "Limpando tabela $T ..." | tee -a "$LOG"
  $MYSQL -e "DELETE FROM ${DB}.${T} WHERE clock < UNIX_TIMESTAMP(DATE_SUB(NOW(), INTERVAL ${CUTOFF_DAYS} DAY));" \
    >> "$LOG" 2>&1 || echo "Erro em $T, continuando..." | tee -a "$LOG"
done

echo "== Expurgo concluído em $(date -Is) ==" | tee -a "$LOG"

3) Script de criação automática de partições

Este script complementa o particionamento do Capítulo 3 e garante que o banco sempre tenha a partição do dia seguinte e remova partições expiradas.

# /opt/zbx_maintenance/partitions.sh
#!/usr/bin/env bash
set -euo pipefail

DB="zabbix"
MYSQL="mysql --defaults-extra-file=$HOME/.my.cnf --batch --raw"
HISTORY_RETENTION_DAYS=90
TRENDS_RETENTION_DAYS=365
LOG="/var/log/zbx_maintenance/partitions_$(date +%F).log"

echo "== Manutenção de partições iniciada em $(date -Is) ==" | tee -a "$LOG"

# Criação da partição do dia seguinte
TOMORROW=$(date -u -d "tomorrow" +%F)
NEXT=$(date -u -d "$TOMORROW +1 day" +%F)

for T in history history_uint history_str history_text history_log; do
  echo "Verificando tabela $T..." | tee -a "$LOG"
  $MYSQL -e "ALTER TABLE ${DB}.${T}
             REORGANIZE PARTITION pMAX INTO (
               PARTITION p${TOMORROW//-/\_} VALUES LESS THAN (UNIX_TIMESTAMP('${NEXT}')),
               PARTITION pMAX VALUES LESS THAN (MAXVALUE)
             );" >> "$LOG" 2>&1 || echo "  - Partição já existe." | tee -a "$LOG"
done

echo "== Concluído em $(date -Is) ==" | tee -a "$LOG"

4) Script de auditoria de integridade

O script abaixo checa se as tabelas de histórico possuem a partição do dia atual, se o disco tem espaço livre suficiente e se o banco está acessível.

#!/usr/bin/env bash
set -euo pipefail

DB="zabbix"
MYSQL="mysql --defaults-extra-file=$HOME/.my.cnf --batch --raw"
LOG="/var/log/zbx_maintenance/audit_$(date +%F).log"

echo "== Auditoria de partições $(date -Is) ==" | tee -a "$LOG"

for T in history history_uint history_str history_text history_log; do
  echo -n "$T: " | tee -a "$LOG"
  $MYSQL -N -e "SELECT COUNT(*) FROM information_schema.PARTITIONS
                WHERE TABLE_SCHEMA='${DB}' AND TABLE_NAME='${T}'
                  AND PARTITION_NAME=CONCAT('p', REPLACE(CURDATE(), '-', '_'));" | tee -a "$LOG"
done

echo "== Verificando espaço em disco =="
df -h | grep -E 'Filesystem|mysql' | tee -a "$LOG"

echo "== Finalizado em $(date -Is) ==" | tee -a "$LOG"

5) Automatizando no cron

Com os scripts prontos, crie uma agenda diária de manutenção:

# /etc/cron.d/zbx_maintenance
# Executa às 01h10 (partições) e às 02h00 (auditoria)
10 1 * * * root /opt/zbx_maintenance/partitions.sh >> /var/log/zbx_maintenance/cron.log 2>&1
0  2 * * * root /opt/zbx_maintenance/audit.sh >> /var/log/zbx_maintenance/cron.log 2>&1

A auditoria noturna é útil para enviar resultados via e-mail ou mesmo para um item no próprio Zabbix via zabbix_sender.

6) Relatório de integridade via Zabbix Sender

Com o zabbix_sender, é possível enviar resultados dos scripts para o próprio Zabbix Server.

#!/usr/bin/env bash
STATUS=$(grep "Erro" /var/log/zbx_maintenance/audit_$(date +%F).log | wc -l)

if [ "$STATUS" -gt 0 ]; then
  zabbix_sender -z 127.0.0.1 -s "Zabbix Server" -k maintenance.audit -o 0
else
  zabbix_sender -z 127.0.0.1 -s "Zabbix Server" -k maintenance.audit -o 1
fi

Depois, crie um item Zabbix trapper com chave maintenance.audit e uma trigger para alertar caso o valor seja 0 (falha).

7) Boas práticas

Centralize todos os logs em /var/log/zbx_maintenance/.
Use nomes de partição previsíveis (pYYYY_MM_DD).
Evite cron jobs com overlap — cada script deve terminar antes do próximo.
Valide o espaço em disco e os backups antes de executar expurgos automáticos.
Documente os scripts e commits de alteração em repositório Git.

8) Conclusão

Com poucas linhas de bash, o Zabbix passa a cuidar de si mesmo. Essas automações previnem o crescimento descontrolado do banco e criam uma camada de previsibilidade — o que antes era manutenção emergencial vira rotina programada.

Sobre o Sysadmin Urbano

🔗 Confira mais artigos ou volte para a página inicial.

Gostou deste conteúdo?

Siga o Sysadmin Urbano para mais artigos técnicos sobre Infraestrutura, SysOps e DevOps.

Voltar para a página inicial

sexta-feira, 17 de outubro de 2025

Zabbix — da Migração ao Fine-Tuning - capítulo 5

Zabbix sob pressão: resolvendo travas, timeouts e queries lentas

Publicado por Sysadmin Urbano | Infraestrutura, SysOps e DevOps

Um guia prático para quem vive na linha de frente da operação de sistemas.

Zabbix sob pressão: resolvendo travas, timeouts e queries lentas

Capítulo 5 da série “Zabbix — da Migração ao Fine-Tuning” no Sysadmin Urbano.

Mesmo depois de otimizar e particionar o banco, é inevitável: em algum momento o Zabbix vai trabalhar no limite e começar a mostrar sintomas de pressão — travas, timeouts e queries lentas. Este capítulo é o manual de sobrevivência para quando o banco “agarra” e o Zabbix Server não responde como deveria.

“Quando o Zabbix fica lento, quase nunca é o Zabbix — é o banco implorando por ajuda.” Este guia é essa ajuda.

1) Entendendo o sintoma: lock, timeout ou lentidão?

Lock: uma sessão está impedindo outra de alterar a tabela. Sintoma clássico: Lock wait timeout exceeded.
Timeout: uma operação ultrapassou o tempo máximo de espera definido pelo MySQL (innodb_lock_wait_timeout).
Lentidão: queries que antes rodavam em segundos passam a demorar minutos — normalmente reflexo de índices desatualizados ou tabelas inchadas.

Em ambientes grandes, os três problemas podem ocorrer simultaneamente.

2) Diagnóstico rápido: quem está travando?

2.1) Identificando bloqueios no MySQL

SELECT ml.LOCK_STATUS, ml.LOCK_TYPE, ml.LOCK_MODE,
       ps.ID AS thread_id, ps.USER, ps.HOST, ps.TIME, ps.STATE, ps.INFO
FROM performance_schema.metadata_locks ml
JOIN performance_schema.threads th ON ml.OWNER_THREAD_ID = th.THREAD_ID
JOIN information_schema.PROCESSLIST ps ON th.PROCESSLIST_ID = ps.ID
WHERE ml.OBJECT_SCHEMA = 'zabbix'
  AND ml.LOCK_STATUS = 'GRANTED'
ORDER BY ps.TIME DESC;

Quando encontrar uma sessão que mantém lock há muito tempo, elimine-a com:

KILL <thread_id>;

2.2) Listando queries lentas

Ative o log de queries lentas para entender onde o gargalo está.

SET GLOBAL slow_query_log = 1;
SET GLOBAL long_query_time = 3;
SHOW VARIABLES LIKE 'slow_query_log_file';

O arquivo registrado mostrará as consultas mais demoradas. Muitas vezes o culpado é o próprio Housekeeper.

3) Recuperando tabelas bloqueadas

3.1) History travada durante TRUNCATE

Se você receber Lock wait timeout exceeded ao tentar truncar:

-- Ver quem está segurando o lock
SELECT * FROM information_schema.PROCESSLIST WHERE STATE LIKE '%lock%';

-- Encerrar a sessão problemática
KILL <id>;

-- Repetir TRUNCATE
TRUNCATE TABLE zabbix.history;

Caso o TRUNCATE ainda não funcione, prefira o método de rename swap:

CREATE TABLE zabbix.history_tmp LIKE zabbix.history;
RENAME TABLE zabbix.history TO zabbix.history_old,
             zabbix.history_tmp TO zabbix.history;
DROP TABLE zabbix.history_old;

Essa troca é quase instantânea e evita o bloqueio prolongado.

4) Lentidão geral: verificando índices e estatísticas

4.1) Recriar estatísticas de tabela

ANALYZE TABLE zabbix.history;
ANALYZE TABLE zabbix.trends;

4.2) Verificar índices ausentes

O Zabbix já cria índices padrão, mas após migrações antigas é comum faltar algum.

SHOW INDEX FROM zabbix.history;

-- Índices recomendados:
ALTER TABLE zabbix.history
  ADD INDEX idx_clock (clock),
  ADD INDEX idx_itemid (itemid);

5) Consultas úteis para auditoria

5.1) Tabelas mais pesadas

SELECT table_name,
       ROUND((data_length + index_length) / 1024 / 1024, 2) AS tamanho_mb
FROM information_schema.tables
WHERE table_schema = 'zabbix'
ORDER BY tamanho_mb DESC
LIMIT 10;

5.2) Status atual do InnoDB

SHOW ENGINE INNODB STATUS\G

5.3) Sessões e queries abertas

SELECT id, user, host, db, command, time, state, info
FROM information_schema.PROCESSLIST
ORDER BY time DESC;

6) Timeouts e parâmetros críticos

6.1) Ajustes no MySQL

Revise estes parâmetros em /etc/my.cnf:

[mysqld]
innodb_lock_wait_timeout = 120
wait_timeout = 600
max_connections = 500
innodb_flush_log_at_trx_commit = 2
innodb_buffer_pool_size = 4G
innodb_io_capacity = 4000

6.2) Ajustes no Zabbix Server

Verifique os valores em /etc/zabbix/zabbix_server.conf:

CacheSize=1G
HistoryCacheSize=512M
HistoryIndexCacheSize=256M
TrendCacheSize=128M
StartDBSyncers=8
StartPollers=50

7) Boas práticas de manutenção

Evite DELETE massivo — prefira partições ou rename swap.
Faça ANALYZE e OPTIMIZE TABLE em períodos de baixa carga.
Mantenha slow_query_log ativo em ambientes de produção.
Monitore os tempos de resposta do banco com SHOW GLOBAL STATUS LIKE 'Threads_running'.
Agende o script de limpeza de partições (do capítulo anterior) com logs centralizados.

8) Conclusão

Travas e lentidão são sinais de que o Zabbix está crescendo — e isso é bom. O segredo é reconhecer cedo quando o banco pede alívio, aplicar técnicas de particionamento e manter os índices saudáveis. O resultado: menos sustos e mais estabilidade.

Sobre o Sysadmin Urbano

🔗 Confira mais artigos ou volte para a página inicial.

Gostou deste conteúdo?

Siga o Sysadmin Urbano para mais artigos técnicos sobre Infraestrutura, SysOps e DevOps.

Voltar para a página inicial

quinta-feira, 16 de outubro de 2025

Zabbix — da Migração ao Fine-Tuning - capítulo 4

Conectando o Zabbix ao mundo: integração com NetBox e LDAP

Publicado por Sysadmin Urbano | Infraestrutura, SysOps e DevOps

Um guia prático para quem vive na linha de frente da operação de sistemas.

Conectando o Zabbix ao mundo: integração com NetBox e LDAP

Capítulo 4 da série “Zabbix — da Migração ao Fine-Tuning” no Sysadmin Urbano.

A gestão de inventário e autenticação são dois pontos que normalmente fogem da rotina de monitoramento, mas que, integrados ao Zabbix, transformam o ambiente em algo muito mais coerente e automatizado. Neste capítulo, vamos explorar duas integrações fundamentais:

NetBox — como base única de inventário e sincronização com hosts do Zabbix.
LDAP — autenticação corporativa, testável direto do terminal.

O NetBox passa a ser o “Source of Truth” (fonte de verdade) da sua infraestrutura, enquanto o Zabbix apenas reflete essa realidade e aplica a monitoração. O LDAP garante que só usuários corporativos possam acessar o sistema, eliminando cadastros manuais.

1) Integrando o Zabbix ao NetBox

1.1) Por que integrar

O NetBox, criado pela DigitalOcean, é hoje a principal ferramenta open source de DCIM + IPAM. Ele centraliza o cadastro de hosts, interfaces, racks, IPs e serviços. A integração com o Zabbix evita duplicidade de inventário e mantém tudo sincronizado: o que está no NetBox é o que o Zabbix deve monitorar.

1.2) Criando o Token no NetBox

Autenticação via token é obrigatória para chamadas de API.

# No NetBox:
Perfil → API Tokens → Add a Token

# Ou via API:
curl -X POST http://netbox.local/api/users/tokens/ \
  -H "Content-Type: application/json" \
  -H "Authorization: Token SEU_TOKEN_ADMIN" \
  -d '{"user": "zabbix", "write_enabled": false, "description": "Token para integração Zabbix"}'

Guarde o token gerado — ele será usado no script de integração abaixo.

1.3) Conferindo divergências entre NetBox e Zabbix

Em vez de criar hosts automaticamente (risco de poluir o ambiente), é mais seguro apenas conferir diferenças — por exemplo, identificar o que existe em um mas não no outro.

#!/usr/bin/env python3
import requests

# Configurações
NETBOX_URL = "http://netbox.local/api/dcim/devices/"
NETBOX_TOKEN = "SEU_TOKEN_AQUI"
ZABBIX_URL = "http://zabbix.local/api_jsonrpc.php"
ZABBIX_USER = "Admin"
ZABBIX_PASS = "zabbix"

# 1. Pegar hosts do NetBox
nb = requests.get(
    NETBOX_URL,
    headers={"Authorization": f"Token {NETBOX_TOKEN}"}
).json()
netbox_hosts = [d["name"] for d in nb["results"]]

# 2. Pegar hosts do Zabbix
payload = {
    "jsonrpc": "2.0",
    "method": "user.login",
    "params": {"user": ZABBIX_USER, "password": ZABBIX_PASS},
    "id": 1
}
token = requests.post(ZABBIX_URL, json=payload).json()["result"]

payload = {
    "jsonrpc": "2.0",
    "method": "host.get",
    "params": {"output": ["host"]},
    "auth": token,
    "id": 2
}
zbx_hosts = [h["host"] for h in requests.post(ZABBIX_URL, json=payload).json()["result"]]

# 3. Comparar listas
faltando_no_zabbix = set(netbox_hosts) - set(zbx_hosts)
faltando_no_netbox = set(zbx_hosts) - set(netbox_hosts)

print("\\n--- Divergências ---")
print(f"NetBox → não estão no Zabbix: {sorted(faltando_no_zabbix)}")
print(f"Zabbix → não estão no NetBox: {sorted(faltando_no_netbox)}")

Execute o script periodicamente (via cron) para gerar alertas ou logs de divergências. Essa checagem também pode alimentar um item no próprio Zabbix com zabbix_sender.

2) Testando LDAP via Bash

2.1) Diagnóstico direto do terminal

Antes de integrar o Zabbix à autenticação corporativa, é essencial validar o acesso via linha de comando. Com o pacote ldap-utils instalado, você pode testar a conexão, bind e busca de usuários.

# Testar conexão (anônimo)
ldapsearch -x -H ldap://ldap.suaempresa.local -b "dc=suaempresa,dc=local" "(cn=usuario)"

# Testar autenticação (bind)
ldapwhoami -x -H ldap://ldap.suaempresa.local -D "uid=usuario,ou=pessoas,dc=suaempresa,dc=local" -W

# Testar TLS
openssl s_client -connect ldap.suaempresa.local:636 -showcerts

Se a autenticação for bem-sucedida, o próximo passo é configurar o Zabbix para usar esse mesmo DN e filtro.

3) Configuração do LDAP no Zabbix

A configuração pode ser feita via interface (Administration → Authentication) ou diretamente no banco:

UPDATE config
SET ldap_host = 'ldap.suaempresa.local',
    ldap_port = 389,
    ldap_base_dn = 'dc=suaempresa,dc=local',
    ldap_search_attribute = 'uid',
    ldap_bind_dn = 'cn=zabbix,ou=service,dc=suaempresa,dc=local',
    ldap_bind_password = 'senha_segura',
    authentication_type = 1;  -- 1 = LDAP

Depois disso, usuários com contas válidas no domínio poderão logar no Zabbix sem cadastro prévio.

4) Dicas e melhores práticas

Evite criar hosts automaticamente via API até validar todas as relações do NetBox.
Tokens do NetBox não expiram por padrão — mas crie um usuário dedicado e com permissões mínimas.
Monitore a validade do certificado LDAP se usar StartTLS ou LDAPS.
Para ambientes com vários domínios, crie filtros LDAP específicos (ex.: (|(memberOf=grp_zabbix)(memberOf=grp_admins))).
Centralize logs das integrações em /var/log/zabbix-integration/.

5) Conclusão

A combinação Zabbix + NetBox + LDAP cria um ecossistema integrado: inventário único, autenticação centralizada e automação mais segura. Você elimina redundâncias e aumenta a confiabilidade da monitoração, porque cada dado nasce e morre no lugar certo.

Sobre o Sysadmin Urbano

🔗 Confira mais artigos ou volte para a página inicial.

Gostou deste conteúdo?

Siga o Sysadmin Urbano para mais artigos técnicos sobre Infraestrutura, SysOps e DevOps.

Voltar para a página inicial