Degradado Query API Performance impactando proyectos estadounidenses
- investigating
Mixpanel está experimentando el rendimiento de Query API degradado, dando como resultado respuestas HTTP 500 al consultar informes para proyectos con la Residencia de Datos de EE.UU. Los proyectos con la UE e IN Data Residency siguen sin afectarse. Apreciamos su paciencia mientras nuestros ingenieros trabajan para restaurar la funcionalidad normal. Publicaremos actualizaciones de progreso en nuestra página de estado. Si tiene alguna pregunta, por favor contacte con soporte.
- identified
Se ha determinado la cuestión y se está aplicando una solución.
- monitoring
Se ha implementado una solución, y estamos viendo mejores tasas de éxito para la API de consulta. Seguiremos vigilando para asegurar la estabilidad.
- resolved
Este incidente ha sido resuelto.
- postmortem
# Mixpanel RCA: Interrupción de Servicio de Consulta Temporal para Proyectos de Estados Unidos 26 de agosto de 2026 # Resumen Entre aproximadamente **2:02 PM y 3:19 PM PT el 26 de agosto de 2026**, los proyectos en la región de Estados Unidos experimentaron fracasos cargando informes y realizando consultas a través de la UI Mixpanel y la API Query. Durante esta ventana, algunas consultas en la región fallaron o devolvieron errores. **No se perdieron datos de clientes, y la ingestión de datos no fue afectada.** Todos los eventos continuaron siendo recogidos y almacenados normalmente durante todo el incidente; una vez restaurado el servicio de consulta, todos los informes reflejaron datos completos y precisos sin necesidad de acción del cliente. La causa fue identificada como una herramienta interna recientemente implementada para la repetición de consultas diagnósticas, una capacidad que nuestros ingenieros utilizan para re-corrir copias de consultas pasadas para depurar el rendimiento, que imprevisto escribió grandes cantidades de datos a los discos de nuestros servidores de consultas, consumiendo capacidad de almacenamiento que los servidores necesitan operar. Cuando esos discos se llenaron, los servidores afectados se sacaron del servicio. El servicio fue restaurado, los servidores afectados fueron devueltos en línea, y la herramienta interna fue deshabilitada. Las remediaciones a continuación añaden salvaguardias de almacenamiento para eliminar la capacidad de herramientas internas de consumir recursos en servidores de consulta, y están diseñadas para evitar que esta clase de fracaso vuelva a suceder en el futuro. Lo que pasó El motor de búsqueda de Mixpanel funciona en una flota de servidores que cada uno utiliza un conjunto de volúmenes de almacenamiento local para cachear los datos necesarios para responder las consultas rápidamente. Por separado, nuestros ingenieros utilizan herramientas de replay de consultas diagnósticas, una capacidad que nuestros ingenieros usan para reproducir y depurar el rendimiento de la consulta. Si bien la aplicación de la replay de la consulta diagnóstica a una consulta grande y compleja, un error de software causó que las capturas de reproducción de la consulta se fanearan a través de toda la flota en lugar de permanecer limitado a un solo servidor. Además, causó mucho más datos de los que se pretendía guardar sin el desalojo oportuno en un solo servidor. Dos factores ampliaron el impacto de la cuestión: * Un solo volumen de almacenamiento completo tomó un servidor completamente fuera de servicio. Cada servidor trata su caché como poco saludable si alguno de sus volúmenes de almacenamiento cruza un umbral de uso, incluso cuando todos los demás volúmenes son saludables. Los datos de reproducción fueron escritos a un volumen específico en cada servidor, por lo que los servidores de toda la región fallaron sus cheques de salud casi simultáneamente. * Los límites de limpieza no contabilizaron el tamaño de los datos. La salvaguardia que limita los datos de repetición en los elementos contados en disco a nivel de aplicación en lugar de bytes a nivel del sistema de archivos, por lo que un pequeño número de capturas inesperadamente grandes pasaron el cheque mientras que consume la mayor parte de la capacidad del volumen. Juntos, esto permitió un único flujo de trabajo depurante que normalmente tiene una huella insignificante para interrumpir la consulta de producción que sirve en toda la región estadounidense. # Timeline \(Pacific Time, August 26, 2026\) * **2:00 PM** — Se escribió la primera captura de reproducción de diagnóstico sobredimensionada; los volúmenes de almacenamiento comenzaron a alcanzar su capacidad y la tasa de éxito de consulta comenzó a caer poco después. * **2:17 PM** — El aviso automatizado llamó al ingeniero de guardia; la investigación comenzó inmediatamente y se contrataron otros ingenieros. * **2:39 PM** — incidente de la página del estado publicado; banner de la aplicación mostrado a las 2:40 PM. * **2:53 PM** — Causa raíz identificada; los esfuerzos de recuperación comenzaron en el primer grupo servidor afectado. * **3:19 PM** — Servicio de consulta restaurado para la gran mayoría de tráfico; el grupo final del servidor se recuperó completamente a las 3:27 PM. * **3:45 PM** — El incidente resuelto después de un período de observación estable. La herramienta de repetición de diagnóstico que provocó el problema fue completamente deshabilitado la misma noche. # Root cause 1. **Un error de software en nuestra búsqueda replay tooling causó escritos sin límites al almacenamiento de producción.** Una capacidad recientemente desplegada para reproducir las consultas malinterpretó una clase particular de consulta compleja, causando capturas que se propagan a cada servidor de consulta en la región y para escribir más datos a los volúmenes afectados que el diseño asumido. 2. **Replay archivos consumidos capacidad de disco de la query porción depende.** El replay tooling escribió sus archivos a los discos locales de los servidores de consulta, por lo que los datos de replayaway agotaron la capacidad de almacenamiento que los servidores necesitan para responder preguntas. 3. **Las salvaguardias sólo representaron parcialmente el comportamiento.** La política de limpieza de los datos de repetición de diagnóstico limitó el número de elementos en disco, pero no su tamaño total, por lo que no se involucró. Al alertar sobre los volúmenes de almacenamiento se registró el crecimiento, pero no se intensificó como crítico sobre una base por servicio, lo que atrasó la detección hasta que se iniciaron fallos de consulta. Lo que estamos cambiando El estado final que estamos construyendo hacia: datos de reproducción de consultas de diagnóstico interno almacenados en almacenamiento de objetos dedicados, sin carga en servidores de búsqueda de producción. Ya desplegado: * **Deshabilitado la herramienta interna** que causó el incidente, y remediado el problema subyacente por lo que las capturas de diagnóstico se limitan a un solo servidor y la clase de consulta específica se maneja correctamente. * **Documentó el procedimiento de recuperación selectiva** utilizado durante el incidente, es decir, despejar sólo el volumen de almacenamiento afectado en lugar de reiniciar grupos de servidores completos, en nuestros registros operativos, acortando el tiempo de recuperación si la capacidad de cualquier volumen se agota en el futuro. En curso: * ** Límites a nivel de sistema, basados en tamaños sobre los datos de repetición de diagnóstico**, capturando los bytes totales en el disco en lugar de los recuentos de elementos, por lo que las capturas de tamaño superior son rechazadas o desalojadas antes de que puedan afectar la capacidad del volumen. * **Aviso de almacenamiento más estricto**, escalando la saturación de volumen por servidor como crítica antes de que pueda afectar las consultas de salud. * **Moving query replay data to dedicated object storage,** so it consume no resources on production query servers. # Common questions * ** ¿Se perdieron datos?** No. La ingestión de datos no se vio afectada durante todo el incidente: los eventos siguieron siendo recogidos, consultados y almacenados normalmente. Sólo se interrumpió la capacidad de consulta. Una vez restaurado el servicio, todos los informes reflejan datos completos. * **¿Fueron afectados los informes guardados, los paneles o la configuración del proyecto?** No. El incidente solo afectó la ejecución de la consulta. Nada almacenado en su proyecto cambió. * **¿Por qué afectó a varios proyectos estadounidenses a la vez?** Los datos de repetición de diagnóstico sobredimensionados escritos a los discos de cada servidor de consultas casi al mismo tiempo, y cada servidor se retira del servicio cuando un volumen se llena. Evitar el uso de herramientas internas del almacenamiento del servicio de consultas es una parte fundamental de nuestro trabajo de rehabilitación. * **¿Cómo se impide esto avanzar?** La cuestión de la herramienta se resuelve y la herramienta sigue siendo desactivada hasta que existan límites basados en el tamaño. La alerta de almacenamiento se está endureciendo así que la saturación es atrapada antes de que afecta el servicio de consulta. Structuralmente, estamos moviendo datos de diagnóstico de servidores de búsqueda de producción enteramente, por lo que los datos de depuración interna no consumirán almacenamiento en los servidores responsables del procesamiento de consultas. Nos disculpamos por la interrupción y por los informes de tiempo no estaban disponibles. Por favor, contacte a través de su equipo de cuenta o apoyo con cualquier pregunta.
Traducido automáticamente desde la actualización oficial del incidente.