Postmortem: VPS desligada na manutenção emergencial da Hostinger (16/10/2026)
Escrito durante o incidente, com o que já está medido. A VPS foi ligada manualmente no painel por volta das 17:20 UTC e ainda não respondia em nenhuma porta às 17:29 UTC, quando esta página foi escrita.
Falta confirmar: que o jogo e as 10 aplicações HTTP voltaram, qual versão de kernel entrou, e se a janela de manutenção da Hostinger provoca novo reinício. O aviso do provedor diz que a VPS reinicia pelo menos uma vez.
| Campo | Valor |
|---|---|
| Data do incidente | 16/10/2026, início às 15:13:30 UTC (12:13:30 local). Em aberto |
| Severidade | Indisponibilidade total. O jogo fora para os jogadores e as 10 aplicações HTTP públicas respondendo 530, há 2h16 no momento desta escrita |
| Status | Causa raiz identificada e externa. Mitigação manual iniciada (VM ligada no painel), ainda sem confirmação de retorno |
| Serviços afetados | Tudo o que roda na VPS Hostinger: os 9 workloads do jogo, as 12 aplicações do namespace apps, o Traefik, o cloudflared, o ArgoCD e o OpenTelemetry Collector do cluster |
| Detectado por | OpentelemetryCollectorK3sNoData, às 15:24:00 UTC, por ausência de dado |
| Mitigado por | Yslan Ramos, ligando a VM no painel da Hostinger |
| Investigação e escrita | Yslan Ramos |
| Provedor | Hostinger (VPS), host 89.116.225.172 |
| Postura | Blameless: a análise mira o sistema e o processo, não as pessoas |
Resumo
A Hostinger abriu uma manutenção emergencial de VPS às 11:20 UTC para corrigir uma vulnerabilidade crítica de kernel, avisando que cada VPS reiniciaria pelo menos uma vez. Às 15:13:30 UTC o patch chegou ao nosso host e a VM parou. Ela não voltou sozinha: voltou desligada, e precisou de um clique no painel quase duas horas depois.
O alerta próprio detectou em 11 minutos. O que faltou foi ligar a ausência de dado a uma causa externa, porque nada no nosso lado olha a página de status do provedor, e porque toda a detecção roda dentro do nó que caiu.
Linha do tempo
Horários em UTC. O local é UTC−3, e a coluna de local existe porque os horários do Prometheus e do Alertmanager saem em UTC enquanto a conversa aconteceu em local.
| UTC | Local | O que aconteceu |
|---|---|---|
| 11:20 | 08:20 | Hostinger abre VPS Emergency Maintenance, status Identified, para CVE-2026-99999, vulnerabilidade crítica de kernel Linux com CVSS 9.3. Afeta todos os planos VPS, e o aviso diz que a VPS do cliente reinicia pelo menos uma vez |
| 15:01:09 | 12:01:09 | Commit ea0b946, chart kelbi-platform 1.21.0, habilitando as métricas de utilização do kubeletstats (ação A9 do postmortem de 14/10/2026) |
| ~15:10 | ~12:10 | Mudança conferida no cluster: ClusterRole com nodes/pods, ConfigMap com as quatro métricas, pod do collector Running 1/1 |
| 15:13:30 | 12:13:30 | Última amostra de métrica do cluster. O patch chega ao nosso host |
| 15:24:00 | 12:24:00 | OpentelemetryCollectorK3sNoData entra em firing, severidade warning |
| ~17:20 | ~14:20 | VM encontrada desligada no painel da Hostinger e ligada manualmente |
| 17:29 | 14:29 | Portas 22, 6443 e 53310 ainda fechadas. admin, cdn e home.arcamh.com respondendo 530 |
O que esses horários somam
11 minutos entre a parada e a detecção automática. Cerca de 1h56 entre a detecção e a ação manual. 2h16 e contando de indisponibilidade no momento desta escrita.
A detecção não foi o gargalo. O intervalo entre o alerta e o clique no painel é 10 vezes maior que o tempo de detecção.
Evidência
O nó estava ocioso até o último instante
Load e memória do nó, colhidos do Prometheus na VPS de monitoração, que não caiu:
load 1m memória usada
11:59 0,46 3,66 GiB
12:05 0,61 3,78 GiB
12:11 0,36 3,70 GiB
12:13 0,36 3,70 GiB <- última amostra
Não houve degradação. Nem rampa de CPU, nem pressão de memória, nem queda gradual de coleta. Load abaixo de 0,7 e memória estável, e corte seco. Essa forma descarta sobrecarga do nó e descarta OOM.
Trinta dias sem uma única lacuna
Varredura de toda a janela de retenção do Prometheus, 10.771 pontos a cada 240s:
lacunas acima de 10 min em 30 dias: 0
O cluster ficou de pé ininterruptamente por 30 dias, sem um reinício sequer, e parou de uma vez. Foi essa medição que estabeleceu o evento como inédito, o que eliminou throttling recorrente e manutenção rotineira da lista de hipóteses.
A VM estava inacessível, não lenta
Testado de dois caminhos de rede diferentes, o Mac e a VPS da Contabo, para separar problema local de queda do host:
porta 22 fechada SSH
porta 6443 fechada API do k3s
porta 53310 fechada entranceserver, a porta do jogo
porta 80 fechada
porta 443 fechada
ping 100% de perda
Todas as portas fechadas, inclusive a 22. Nó sobrecarregado continua respondendo SSH; nó com todas as portas mudas está desligado ou isolado. Foi o que o painel do provedor confirmou depois.
A palavra do provedor
Da página de status da Hostinger, lida às 17:28 UTC:
VPS Emergency Maintenance — Oct 16, 2026 - 11:20 UTC — status
Identified"We are aware of CVE-2026-99999, a critical Linux kernel vulnerability (CVSS 9.3)" "customer VPS will restart at least once"
O nosso host foi atingido às 15:13:30 UTC, quase quatro horas depois da abertura da janela, o que é consistente com patch por lotes.
Impacto
O jogo saiu do ar. A 53310 do entranceserver fechada significa jogador sem conseguir conectar, e os 9 workloads do namespace kelbi indisponíveis.
As 10 aplicações HTTP públicas saíram do ar. admin.arcamh.com, cdn.arcamh.com e home.arcamh.com respondem 530, que é o Cloudflare dizendo que não alcança a origem. O cloudflared roda no cluster, então o túnel caiu com o nó. É exatamente o raio de alcance que a classificação de criticidade do kelbi-platform 1.18.0 previu para ele: critical, único caminho de entrada externa.
O banco produtivo parou. O kelbi-pg é StatefulSet no mesmo nó. Sem perda de dado esperada, porque o volume é local e persistente, mas isso precisa de confirmação quando a VM voltar.
A monitoração sobreviveu. Prometheus, Alertmanager, Grafana e o collector da Contabo seguiram de pé, porque estão em outra VPS e em outro provedor. É o que permitiu diagnosticar com dado em vez de com palpite.
Causa raiz
Gatilho
Manutenção emergencial da Hostinger para corrigir CVE-2026-99999, vulnerabilidade crítica de kernel. Causa externa, sem relação com mudança nossa.
Mecanismo
O provedor avisou que cada VPS reiniciaria pelo menos uma vez. A nossa não religou: voltou no estado desligado, e ficou assim até alguém abrir o painel e clicar.
Ou seja, o incidente não é a manutenção. A manutenção era inevitável e correta, dado um CVSS 9.3 em kernel. O incidente é que um reinício que deveria durar minutos durou mais de duas horas, porque a VM não tem religamento automático e porque nada nosso vigia o estado dela no provedor.
Por que isso virou mais de duas horas
Três lacunas, em ordem de custo:
- A VM não religa sozinha. Nenhuma política de restart automático está configurada no painel, se o plano oferecer uma.
- O alerta diz a coisa errada.
OpentelemetryCollectorK3sNoDatainforma que o collector do k3s parou de enviar dado. Isso é verdade e insuficiente: a mesma mensagem sai se o collector quebrar, se o OTLP perder rota, ou se o cluster inteiro desaparecer. Nada nela sugere "olhe o painel do provedor". - Toda a detecção roda dentro do que caiu. O collector, o jogo, as aplicações e o ArgoCD estão todos no nó da Hostinger. O único observador externo é a VPS da Contabo, e ela só consegue afirmar ausência, nunca a causa.
Por que não detectamos antes
Detectamos, em 11 minutos, e a detecção foi por ausência de dado, que é o padrão que a RFC 0003 prescreveu. O problema não foi detectar.
O que não existia era um caminho entre "o cluster calou" e "a VPS está desligada". Esse caminho foi percorrido à mão, com ping, teste de porta de dois lugares e leitura da página de status do provedor, e levou perto de duas horas para começar porque ninguém estava olhando o canal no momento.
Lições aprendidas
O que fomos bem
O alerta de ausência pagou o próprio custo. OpentelemetryCollectorK3sNoData é o tipo de regra que não dispara nunca até o dia em que é a única coisa que dispara. Detectou perda total de cluster em 11 minutos, sem nenhum alerta de sintoma para competir com ele, porque todos os alertas de sintoma morreram junto com a fonte de dado.
A monitoração em outro provedor valeu a separação. Prometheus e Alertmanager na Contabo foram o que permitiu reconstruir a linha do tempo com precisão de segundo, inclusive a última amostra antes do corte. Monitoração no mesmo nó não teria dito nada.
Medir dos dois caminhos de rede separou as hipóteses rápido. Testar as portas do Mac e da VPS da Contabo descartou problema de rede local em uma única rodada.
O que não fomos bem
A página de status do provedor deveria ser o primeiro passo, e foi o último. Com a hipótese "causa externa" na mesa, uma requisição HTTP resolveria o diagnóstico em segundos. Em vez disso levantei load, memória, lacunas de 30 dias e portas, e só li a página quando pedido. A ordem certa é a mais barata primeiro.
Minha ordem de suspeitas estava errada. Pus cobrança em primeiro lugar e manutenção emergencial em terceiro, raciocinando que "inédito em 30 dias" sugere data de renovação. Manutenção emergencial explica igualmente bem um evento inédito, e era verificável de graça. Acertei o lado, provedor e não mudança nossa, e errei a ordem dentro dele.
Três guard rails de higiene silenciaram junto com a fonte. MetricsWithVolatileLabels, MetricsWithoutEnvironment e ErupeRemnantsPresent contam séries k8s_*. Sem cluster não há séries, e os três saíram de firing como se tivessem sido resolvidos. Guard rail que fica quieto quando o dado morre é falso negativo, e isso vale para toda a família hygiene:* que conta séries de um cluster só.
Houve deploy com janela de manutenção aberta. O chart 1.21.0 foi aplicado às 15:01 UTC, dentro de uma janela que o provedor abriu às 11:20 UTC. Ninguém olhou a página de status antes, e por doze minutos a mudança foi suspeita da queda. Mudança própria e manutenção de provedor na mesma janela encarecem o diagnóstico de graça.
Onde tivemos sorte
O deploy era inocente. Se a mudança do collector tivesse causado a queda, o diagnóstico seria muito mais difícil, porque o nó ficou inacessível e não havia como inspecionar nada por dentro.
O incidente caiu num horário com alguém presente. Às 15:13 UTC de uma quinta, com a pessoa trabalhando no projeto. De madrugada, as mesmas duas horas seriam oito.
A retenção cobria exatamente a pergunta. Trinta dias de dado e zero lacunas deram a resposta de "é recorrente?" sem ambiguidade. Um dia mais velho e a janela não alcançaria.
Ações
| # | Ação | Custo |
|---|---|---|
| A1 | Sonda externa de porta na VPS da Hostinger, da VPS da Contabo: 53310 do jogo e 6443 do k3s. Dá um alerta que diz "o host está fora" em vez de "faltou dado" | 0, usa a VPS que já existe |
| A2 | Fazer a família hygiene:* distinguir "zero por estar são" de "zero por falta de fonte", com absent() ou sentinela de presença de cluster | 0 |
| A3 | Pôr na annotation do OpentelemetryCollectorK3sNoData o ponteiro para a página de status da Hostinger e para o painel da VPS | 0 |
| A4 | Verificar se o plano da Hostinger oferece religamento automático da VM e, se oferecer, ligar | 0 se existir no plano |
| A5 | Checar a página de status do provedor antes de aplicar mudança, e antes de atribuir queda a mudança própria | 0 |
| A6 | Confirmar a A9 do postmortem de 14/10/2026, que ficou sem verificação: as quatro métricas de utilização produzem série e as quatro recording rules saem do zero | 0 |
| A7 | Registrar a versão de kernel antes e depois do patch, para ter o dado se o comportamento do nó mudar | 0 |
| A8 | Confirmar a integridade do kelbi-pg e do volume local depois do retorno | 0 |
| A9 | Avaliar se o backup do kelbi-pg cobre o cenário de perda do nó inteiro, e não só de perda lógica. O postmortem de 14/10/2026 já registrou que nenhum dump foi restaurado uma vez | 0 para avaliar |
As ações A1, A2 e A3 atacam a mesma lacuna por ângulos diferentes: a detecção existe e não sabe dizer de que lado do túnel está o problema.
Referências
- Página de status da Hostinger
- Postmortem de 06/10/2026, o incidente anterior com intervenção do mesmo provedor
- Postmortem de 14/10/2026, de onde vem a ação A9 que estava sendo aplicada quando o nó caiu
- RFC 0003, que prescreveu a detecção por ausência de dado