Como o Litmus Decide Pass ou Fail: Probes

Ele passa porque, sem nenhuma probe anexada, o veredito basicamente checa se a falha foi injetada e se o alvo se recuperou para uma contagem saudável de pods. Ele nunca checou se o seu serviço continuou servindo tráfego. Um ChaosEngine sem probes te dá um verde que praticamente não significa nada. A correção são as probes, que é como você codifica a hipótese de steady state e alimenta o probeSuccessPercentage no veredito. O Litmus tem quatro tipos de probe: httpProbe acessa um endpoint e valida o status ou a resposta, cmdProbe roda um comando e compara a saída, k8sProbe valida o estado de um recurso do Kubernetes, e promProbe roda uma query PromQL e valida o resultado (por exemplo, a taxa de erro permanece abaixo de um limite). Mas o tipo importa menos que o modo. SOT e EOT rodam a probe uma única vez, no início ou no fim do teste. Edge roda nos dois extremos. Continuous faz polling durante toda a janela de chaos no probePollingInterval, e é esse que pega os 20 segundos de 502s, porque ele amostra enquanto a falha está acontecendo. Então adicione uma httpProbe em modo Continuous contra o serviço, com um intervalo de polling apertado e um orçamento de retry sensato. Se a disponibilidade cair durante o chaos, a probe falha, o probeSuccessPercentage cai, e o ChaosResult vira Fail. Agora Pass realmente significa que a falha foi injetada e o serviço se manteve no ar. A probe é a asserção do experimento. Sem uma, você está só deletando pods e torcendo.