SysAdmin Urbano

terça-feira, 4 de novembro de 2025

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

Infoblox — do DNS ao Tuning [Capítulo 03] Delegation x None: autoridade, migração segura e rollback

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, Member 198.51.100.10.

1) Visão geral: quem manda (autoridade)

Autoridade é definida por SOA e NS da zona.
Delegation: a zona-pai publica os NS da subzona → a autoridade fica nos servidores delegados.
None (na zona-pai): remove a delegação → a subzona passa a ser Authoritative local no Infoblox.
Views: tudo é por View. Delegar na internal não tem efeito na external.

Regra Edite os NS na zona-pai se a subzona está Delegated. Edite os NS dentro da subzona se a autoridade é local (None/Authoritative).

2) Quando usar Delegation vs None

Delegation quando: outro time/appliance responde pela subzona; integração multi-ambiente; terceirização de operação.
None quando: você quer administrar localmente (centralização), aplicar políticas de Grid, logging e tuning internos.
Forward/Stub não publicam registros — não confundir com Delegation.

3) Planejamento da mudança (TTL, View e glue)

TTL: reduza para 300–600s horas antes de mudanças de NS/autoridade.
View: confirme que example.com e dev.example.com estão na mesma View.
Glue: se os NS da subzona estão dentro dela (ex.: ns1.dev.example.com), garanta A/AAAA:

ns1.dev.example.com. IN A 198.51.100.31
ns2.dev.example.com. IN A 198.51.100.32

4) Procedimento A — Trocar NS mantendo Delegation

Use quando a autoridade permanece externa e você só precisa atualizar os NS.

Abra a zona-pai example.com (View correta) no Infoblox.
Edite a delegação da subzona dev.example.com e atualize os NS:

dev.example.com. IN NS ns1.dev.example.com.
dev.example.com. IN NS ns2.dev.example.com.

Garanta/atualize os glue quando necessário (A/AAAA para ns1/ns2).
Publique as alterações (Grid Master → Members) e respeite o TTL reduzido.

Atenção Não edite NS dentro da subzona quando ela está Delegated. O lugar correto é sempre a zona-pai.

5) Procedimento B — Trazer autoridade (Delegation → None)

Use quando você quer que o Infoblox passe a publicar e responder pela subzona.

No Infoblox, abra a zona-pai example.com na View correta.
Altere a subzona dev.example.com de Delegation para None (remoção da delegação).
Abra a própria subzona dev.example.com (agora Authoritative local) e crie os NS desejados:

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
ns2.dev.example.com. IN A 198.51.100.32

Publique as alterações no Grid.
Se aplicável ao público externo, ajuste também na View external (mesma decisão de autoridade).

Impacto A resolução de dev.example.com passa a sair do seu Grid. Valide aplicações dependentes e ACLs de consulta.

6) Validação pós-mudança

6.1 Consultas diretas ao Member (sem recursão):

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

6.2 Cadeia completa de delegação:

dig +trace dev.example.com NS

6.3 Windows (nslookup):

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

6.4 Limpe o cache do cliente, se necessário:

ipconfig /flushdns

7) Rollback rápido

Se trouxe autoridade (None) e quer reverter: volte à zona-pai e redefina Delegation com os NS antigos; remova/ignore os NS locais.
Se apenas trocou NS na Delegation e quer reverter: restaure os NS anteriores na zona-pai.
Valide novamente com dig +trace e consultas diretas ao Member.

8) Troubleshooting

“An NS record requires at least one name server address”: crie A/AAAA (glue) do host NS ou anexe o IP ao NS externo.
Sem permissão para editar NS na subzona: ela está Delegated; edite na zona-pai ou mude para None.
Respostas diferentes por público: verifique a View (internal/external).
Forward/Stub: não publicam registros; converta para Authoritative para servir a zona.
Grid secundário: alterações só no Primary.

Pro tip Reduza o TTL antes, mude, valide, e só depois restaure o TTL padrão.

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

Conceito: autoridade, delegação, Views, glue.
Infoblox: Delegation x None, edição por View, publicação e replicação de Grid.
Prática: migração segura, validação com dig, rollback.

Objetivo Saber escolher entre Delegation e None, executar a transição com baixo risco e voltar rápido se necessário.

10) Próximo capítulo

Capítulo 04 — DNS Records em profundidade (A/AAAA/NS/CNAME/MX/PTR/TXT) no Infoblox
Criação correta, conflitos comuns (CNAME no apex, colisões CNAME↔A/MX/NS), TTLs e políticas de naming.

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

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

🔗 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