API de Consulta Degradada Desempenho impactando Projetos EUA
- investigating
Mixpanel está experimentando o desempenho da API da Consulta degradada, resultando em respostas HTTP 500 ao consultar relatórios para projetos com a Residência de Dados dos EUA. Os projectos com a UE e a Residência de Dados não são afectados. Agradecemos sua paciência enquanto nossos engenheiros trabalham para restaurar a funcionalidade normal. Publicaremos atualizações de progresso em nossa página de status. Se tiver alguma dúvida, contacte o suporte.
- identified
A questão foi identificada e está a ser implementada uma solução.
- monitoring
Uma correção foi implementada, e estamos vendo taxas de sucesso melhoradas para a API Consulta. Continuaremos a acompanhar para garantir a estabilidade.
- resolved
Este incidente foi resolvido.
- postmortem
# Mixpanel RCA: Interrupção do Serviço de Consulta Temporária para Projetos dos EUA 26 de agosto de 2026 Resumo Entre aproximadamente **2:02 PM e 3:19 PM PT em 26 de agosto de 2026**, projetos na região dos EUA experimentaram falhas no carregamento de relatórios e execução de consultas através da Mixpanel UI e Consulta API. Durante esta janela, algumas consultas na região falharam ou retornaram erros. ** Nenhum dado do cliente foi perdido, e a ingestão de dados não foi afetada. ** Todos os eventos continuaram sendo coletados e armazenados normalmente durante todo o incidente; uma vez que o serviço de consulta foi restaurado, todos os relatórios refletiam dados completos e precisos, sem necessidade de ação do cliente. A causa foi identificada como uma ferramenta interna recentemente implantada para replay de consulta diagnóstica, uma capacidade que nossos engenheiros usam para re-executar cópias de consultas passadas para depurar o desempenho, que inesperadamente escreveu grandes quantidades de dados para os discos de nossos servidores de consulta, consumindo capacidade de armazenamento que os servidores precisam operar. Quando esses discos foram preenchidos, os servidores afetados saíram do serviço. Serviço foi restaurado, os servidores impactados foram trazidos de volta on-line, eo ferramental interno foi desativado. As remediações abaixo adicionam salvaguardas de armazenamento para remover a capacidade interna de ferramentas de consumir recursos em servidores de consulta, e são projetadas para evitar que essa classe de falha aconteça novamente no futuro. # O que aconteceu O mecanismo de consulta da Mixpanel é executado em uma frota de servidores que cada um usa um conjunto de volumes de armazenamento local para armazenar os dados necessários para responder consultas rapidamente. Separadamente, nossos engenheiros usam ferramentas de replay de consultas diagnósticas, uma capacidade que nossos engenheiros usam para reproduzir e depurar o desempenho da consulta. Ao aplicar a ferramenta de replay de consulta diagnóstica a uma consulta grande e complexa, um bug de software fez com que a replay de consulta capturasse toda a frota em vez de permanecer confinado a um único servidor. Além disso, causou muito mais dados do que pretendia ser salvo sem despejo oportuno em um único servidor. Em seguida, dois fatores ampliaram o impacto da questão: * Um único volume de armazenamento completo levou um servidor completamente fora de serviço. Cada servidor trata seu cache como não saudável se qualquer um de seus volumes de armazenamento cruzar um limiar de uso, mesmo quando todos os outros volumes são saudáveis. Os dados de repetição foram escritos para um volume específico em cada servidor, de modo que os servidores em toda a região falharam em suas verificações de saúde quase simultaneamente. * Limites de limpeza não contabilizam o tamanho dos dados. A salvaguarda limitando dados de repetição no disco contou itens no nível da aplicação em vez de bytes no nível do sistema de arquivos, então um pequeno número de captura inesperadamente grandes passou a verificação enquanto consumia a maior parte da capacidade do volume. Juntos, estes permitiram um único fluxo de trabalho de depuração que normalmente tem uma pegada insignificante para interromper a consulta de produção servindo em toda a região dos EUA. # Timeline \(Tempo Pacífico, 26 de agosto de 2026\) * ** 2:00 PM** — Primeira captura de replay de diagnóstico superdimensionada foi escrita; volumes de armazenamento começaram a atingir sua capacidade e taxa de sucesso da consulta começou a cair pouco depois. * **2:17 PM** — Alerta automático chamou o engenheiro de plantão; a investigação começou imediatamente e engenheiros adicionais foram envolvidos. * **2:39 PM** — Incidente de página de status postado; banner no aplicativo exibido às 2:40 PM. * **2:53 PM** — Causa raiz identificada; os esforços de recuperação começaram no primeiro grupo de servidor afetado. * **3:19 PM** — Serviço de consultas restaurado para a grande maioria do tráfego; o grupo de servidor final totalmente recuperado às 3:27 PM. * 3:45 PM** — Incidente resolvido após um período de observação estável. A ferramenta de repetição diagnóstica que desencadeou o problema foi totalmente desativada na mesma noite. Causa raiz 1. **Um bug de software em nossa ferramenta de replay de consulta causado unbounded escreve ao armazenamento de produção.** Uma capacidade recentemente implantada para reproduzir consultas manuseou uma determinada classe de consultas complexas, fazendo com que as capturas se espalhassem para cada servidor de consultas na região e escrevessem muito mais dados para os volumes afetados do que o projeto assumido. 2. **Replay arquivos consumidos capacidade de disco que serviço de consulta depende.** O replay tooling escreveu seus arquivos para os discos locais dos servidores de consulta, então a capacidade de armazenamento esgotada de dados de replay em fuga que os servidores precisam responder às consultas. 3. ** As salvaguardas apenas parcialmente contabilizadas para o comportamento. ** A política de limpeza para dados de replay diagnóstico limitou o número de itens no disco, mas não o seu tamanho total, por isso não engajou. Alertar sobre volumes de armazenamento marcou o crescimento, mas não foi escalado como crítico em uma base por servidor, que atrasou a detecção até que as falhas da consulta começaram. O que estamos a mudar O estado final que estamos construindo para: dados internos de replay de consulta diagnóstica armazenados em armazenamento de objetos dedicado, não colocando carga em servidores de produção de consulta. Já implantado: * **Desativado o tooling interno** que causou o incidente, e remediado o problema subjacente para que as capturas diagnósticas são confinadas a um único servidor e a classe de consulta específica é tratada corretamente. * **Documentado o procedimento de recuperação direcionado** usado durante o incidente, ou seja, limpando apenas o volume de armazenamento afetado em vez de reiniciar grupos de servidores completos, em nossos runbooks operacionais, encurtando o tempo de recuperação se a capacidade de qualquer volume se esgotar no futuro. Em progresso: * **Filesystem-level, tamanho-based limites em dados de replay diagnóstico**, capping bytes totais no disco em vez de contagens de itens, então capturas superdimensionadas são rejeitadas ou despejadas antes que possam afetar a capacidade do volume. * **Stricter storage alertando**, aumentando a saturação de volume por servidor como crítico antes que possa afetar a verificação de saúde da consulta. * **Movendo dados de replay de consulta para o armazenamento de objetos dedicado,** então ele não consome recursos em servidores de consulta de produção. Perguntas comuns * ** Algum dado foi perdido?** Não. A ingestão de dados não foi afetada durante todo o incidente: os eventos continuaram a ser coletados, em fila e armazenados normalmente. Apenas a capacidade de consulta foi interrompida. Uma vez que o serviço foi restaurado, todos os relatórios refletiam dados completos. * ** Foram afetados relatórios salvos, painéis ou configurações de projeto?** Não. O incidente afetou apenas a execução da consulta. Nada armazenado no seu projeto mudou. * ** Por que afetou vários projetos americanos ao mesmo tempo?** Os dados sobredimensionados de replay de diagnóstico escritos nos discos de cada servidor de consulta quase ao mesmo tempo, e cada servidor se remove do serviço quando qualquer volume preenche. A prevenção de ferramentas internas de consumir o armazenamento de servidor de consultas é uma parte essencial do nosso trabalho de remediação. * ** Como isso é impedido de ir em frente?** O problema do ferramental é resolvido e o ferramental permanece desativado até que os limites baseados no tamanho estejam em vigor. O alerta de armazenamento está sendo apertado, então a saturação é captada antes de afetar o serviço de consulta. Estruturalmente, estamos movendo os dados de diagnóstico para fora dos servidores de pesquisa de produção inteiramente, então dados internos de depuração não consumirão armazenamento nos servidores responsáveis pelo processamento de consultas. Pedimos desculpa pela interrupção e pelo tempo que os relatórios não estavam disponíveis. Por favor, entre em contato com sua equipe de conta ou suporte com quaisquer perguntas.
Traduzido automaticamente da atualização oficial do incidente.