Clock skew / problema de NTP

Sintoma

Diferenças de relógio entre os nós do cluster; inconsistências de replicação/eleição, 'certificate not yet valid', saltos de tempo nos logs.

1. Reconheça o sintoma

O clock skew é traiçoeiro: eleições oscilando no Mongo/Redis Sentinel, erros TLS 'not yet valid/expired', erros de Kerberos, timestamps voltando no tempo nos logs. Em sistemas distribuídos, é a raiz da maioria das esquisitices 'inexplicáveis'.

2. Meça a diferença

Em cada nó, compare a fonte de tempo e o offset: timedatectl, chronyc tracking (ou ntpq -p) e date -u entre os nós. Quantos ms/s de diferença há?

3. Corrija o NTP/chrony

O chronyd/ntpd está rodando, alcança suas fontes de tempo, está sincronizado? Inicie o serviço e corrija a fonte; para offsets grandes, ajuste com cuidado (um salto repentino pode afetar alguns bancos).

4. Verifique o componente afetado

Depois de corrigir o relógio, verifique: a eleição do replica set do MongoDB está estável, o Redis Sentinel/Cluster está saudável, os handshakes TLS funcionam, as métricas de lag de replicação se normalizaram?

5. Definitivo

Torne o NTP obrigatório em todos os nós e monitore o offset (alerta: >100ms). Em máquinas virtuais, defina a configuração de sincronização de tempo host-guest; de preferência, use uma única hierarquia de fontes de tempo confiável.