Entrevista de diseño de sistemas: ¿cómo diseñarías un sistema de monitoreo de métricas y alertas?

Problema y escenarios aplicables

Diseña un sistema de monitoreo de métricas y alertas compartido por múltiples equipos de ingeniería. Monitorea 50,000 instancias de servicio, cada una exponiendo 200 series temporales activas, y recolecta cada 15 segundos. Admite contadores, medidores (gauges) e histogramas; filtrado y agregación por etiquetas; paneles de control; y alertas basadas en reglas. Una nueva falla debe ingresar al enrutamiento de notificaciones dentro de los 60 segundos en el p99. Las consultas comunes de paneles durante las seis horas más recientes deben completarse dentro de dos segundos en el p95. Las muestras sin procesar se conservan durante siete días, los resúmenes de un minuto durante 90 días y los resúmenes de una hora durante 13 meses.

Asume una región con tres zonas de disponibilidad y autenticación confiable como fuente de identidad del inquilino. Los proveedores existentes de correo electrónico, chat y telefonía pueden entregar notificaciones; este diseño debe producirlas, deduplicarlas, agruparlas y enrutarlas de manera confiable. Los registros (logs) y los rastreos (traces) están fuera del alcance principal. La entrevista debe centrarse en etiquetas de alta cardinalidad, duplicados y muestras tardías, datos faltantes, estado de las alertas, aislamiento de consultas y detección de fallas en la propia plataforma de monitoreo.

El material actual de 2026 en inglés y chino presenta el monitoreo de métricas y alertas como un problema directo de entrevista de diseño de sistemas que involucra ingesta de series temporales, consultas, alertas y alta disponibilidad. La documentación de Prometheus proporciona la semántica principal para la identidad de series, recolección por extracción (pull), el WAL, alertas pendientes y disparadas, agrupación e inhibición. Google SRE aporta principios para alertas de bajo ruido y monitoreo de caja negra. Por lo tanto, el enunciado es representativo y técnicamente verificable en la actualidad.

Qué evalúa el entrevistador

Primero, ¿puede el candidato separar el rendimiento de muestras de la cardinalidad de las series temporales activas? El recuento de instancias, las series por instancia y el intervalo de recolección determinan las escrituras. La memoria, los índices y la distribución de consultas (fan-out) pueden fallar primero debido a la cardinalidad. Agregar user_id o request_id a las etiquetas puede crear órdenes de magnitud más de series sin aumentar el tráfico.

Segundo, ¿la ingesta duradera, las consultas de paneles y la detección de fallas forman una ruta completa? Que un recolector reciba una muestra no significa que sea duradera. Las reglas de alerta no deben depender de un grupo compartido que consultas ad hoc costosas puedan agotar. Una respuesta sólida define el límite de confirmación (acknowledgement boundary), reserva capacidad para alertas y especifica la semántica para datos tardíos, duplicados, faltantes y resultados parciales.

Tercero, ¿el almacenamiento coincide con el patrón de acceso? Los datos recientes se anexan y consultan con frecuencia. Los datos históricos se adaptan a bloques inmutables, compresión, índices y almacenamiento de objetos. El submuestreo (downsampling) no puede promediar promedios. Debe retener al menos sum, count, min y max; los histogramas requieren límites de depósitos (buckets) compatibles antes de poder fusionarse.

Por último, el sistema de alertas debe sobrevivir a los incidentes. Un incidente puede aumentar las métricas de error, las consultas y las notificaciones al mismo tiempo. El candidato debe cubrir la fragmentación (sharding) de reglas, la recuperación de estado, la deduplicación de notificaciones, las tormentas de alertas, los inquilinos ruidosos, el automonitoreo y una sonda de actividad (liveness probe) de extremo a extremo fuera del dominio de falla de la plataforma.

Preguntas de aclaración antes de responder

• ¿Son estables los objetivos de recolección? La mayoría son servicios de larga duración descubiertos por la plataforma; los trabajos cortos y las redes restringidas usan una puerta de enlace de inserción (push gateway).
• ¿La escala indicada es global o regional? Trátala como un pico regional. Las regiones adicionales recolectan de forma independiente y exponen consultas globales controladas.
• ¿Cuál es el límite de confirmación? La puerta de enlace de escritura responde con éxito solo después de que la muestra entra en un registro duradero replicado en todas las zonas de disponibilidad.
• ¿Se permiten duplicados y muestras fuera de orden? Los reintentos de red pueden duplicar datos y las muestras pueden llegar dentro de una ventana tardía acotada. Las series y marcas de tiempo idénticas usan una regla de conflicto determinista.
• ¿Una muestra faltante significa cero? No. Puede indicar un objetivo caído, recolección fallida o partición, lo cual difiere de un cero medido.
• ¿Cada consulta debe terminar en dos segundos? No. El SLO cubre consultas acotadas y comunes de seis horas. Los escaneos sin procesar de alta cardinalidad y de un mes de duración tienen cuotas o usan análisis asíncrono.
• ¿Cómo se decide la recuperación de alertas? La regla define el intervalo de evaluación, la duración de retención, la política de datos faltantes y la condición de recuperación. El servicio de notificación no los infiere.
• ¿Pueden los inquilinos crear etiquetas arbitrarias? Dentro de las cuotas, sujetas a límites de recuento de etiquetas, longitud, series activas y tasa de nuevas series.
• ¿Se requiere notificación exactamente una vez (exactly-once)? No. La entrega es al menos una vez (at-least-once), con idempotencia basada en una huella digital (fingerprint) de la alerta y la transición de estado.
• ¿Cómo se relacionan los datos sin procesar y los resumidos? Un resumen puede recalcularse mientras se retengan los bloques de origen, y registra su resolución y marca de cobertura (coverage watermark).

Estructura de respuesta de 30 segundos

“La escala es de 10 millones de series activas, alrededor de 667,000 muestras por segundo o 57.6 mil millones de muestras por día. Recolectores fragmentados extraen objetivos del descubrimiento de servicios, mientras que los trabajos cortos usan una puerta de enlace push. Las muestras normalizadas ingresan a un registro duradero entre zonas por inquilino y huella de serie, luego a un nivel de datos recientes y bloques de tiempo inmutables. Los índices de etiquetas atienden consultas y los presupuestos de cardinalidad restringen etiquetas peligrosas como user_id. Un motor de reglas aprovisionado por separado evalúa marcas de tiempo fijas y mantiene los estados inactivo, pendiente y disparado. Un administrador de alertas deduplica, agrupa, silencia, inhibe y enruta alertas. Verificaría la ruta con un aumento de diez veces en nuevas series, muestras duplicadas y tardías, fallas de zona y un canario externo.”

Análisis detallado paso a paso

Comienza con seis invariantes: las etiquetas de muestra no pueden declarar la identidad del inquilino; las muestras confirmadas han ingresado a un registro duradero; un reintento no puede producir un resultado diferente; los datos faltantes nunca se cambian silenciosamente a cero; la carga del panel no puede desabastecer las alertas; y cada rechazo, descarte, retraso y degradación tiene un recuento observable.

Paso uno: recalcular la escala y tratar la cardinalidad como un recurso de primer nivel.

El cálculo de series activas es:

50,000 instances × 200 series/instance = 10,000,000 active series
10,000,000 ÷ 15 seconds ≈ 666,667 samples/second
666,667 × 86,400 ≈ 57.6 billion samples/day

La documentación de almacenamiento de Prometheus ofrece un punto de partida aproximado para el almacenamiento local de uno a dos bytes por muestra. A esa tasa, los fragmentos de muestras comprimidos ocuparían aproximadamente 57.6–115.2 GB por día, o 172.8–345.6 GB por día con tres copias. Esta estimación excluye índices de etiquetas, el WAL, el head, metadatos de objetos, margen de seguridad más allá de las réplicas y efectos de distribución observados. Es una verificación de cordura, no un sustituto de una prueba de rendimiento con métricas representativas.

Las nuevas series son más peligrosas. Si un user_id a nivel de solicitud entra en el conjunto de etiquetas, la identidad de la serie cambia con cada valor. La plataforma debe limitar las series activas, la tasa de creación de nuevas series, el recuento de etiquetas, la longitud de las etiquetas y las claves permitidas por inquilino y métrica, con políticas explícitas de advertencia, cuarentena y rechazo.

Paso dos: usar recolección pull por defecto y push donde sea necesario.

El descubrimiento de servicios suministra el conjunto de objetivos. Un plano de control asigna objetivos a los recolectores mediante dispersión consistente o de encuentro (consistent/rendezvous hashing). Cada 15 segundos, los recolectores extraen por HTTP, adjuntan campos confiables de inquilino, clúster, trabajo e instancia, y producen métricas de recolección como up, duración del raspado (scrape), recuento de muestras y errores. La extracción hace que «el objetivo existía pero falló la recolección» sea directamente visible y permite a la plataforma controlar el ritmo.

Los trabajos por lotes de corta duración, las redes sin acceso entrante y los entornos que ya emiten OTLP usan una puerta de enlace regional. La puerta de enlace autentica la identidad, limita el tamaño del lote, normaliza los campos e ingresa al mismo contrato de ingesta. El éxito de envío del cliente no es el éxito final del almacenamiento; el éxito de la puerta de enlace significa que la plataforma alcanzó su límite duradero. Los recolectores usan colas locales acotadas durante la desconexión y rechazan con contadores cuando el espacio se agota en lugar de llenar los discos indefinidamente.

Paso tres: definir la identidad de las series y el contrato de ingesta.

Una serie se identifica de forma única mediante tenant_id + metric_name + canonical_labels. Las etiquetas se ordenan y codifican canónicamente antes del cálculo del hash. Una colisión de huellas digitales aún requiere comparar la identidad completa; el hash solo es insuficiente. Una muestra contiene la identidad de la serie, la hora de origen, la hora observada, el valor o histograma, el tipo de datos y la fuente de recolección.

WriteBatch {
  tenantId, sourceId, requestId,
  samples: [{ metric, labels, sourceTimestamp, value }]
}

La puerta de enlace realiza autenticación, normalización de etiquetas, validación de tipos, presupuesto de cardinalidad, verificaciones de rango de tiempo y límites de lotes. Luego particiona por tenant_id + series_fingerprint en un registro replicado entre zonas. La confirmación del registro es el límite de confirmación (ack). El mismo requestId se puede reintentar de forma segura y el almacenamiento deduplica por (series_id, source_timestamp). Valores diferentes en una misma serie y marca de tiempo siguen una política de conflicto fija e incrementan una métrica de conflicto; el orden de llegada no debe decidir silenciosamente.

Paso cuatro: separar datos recientes, bloques históricos e índices.

Un búfer de escritura (head) anexable retiene las horas más recientes y permite cambios acotados para datos tardíos. Procesos en segundo plano lo congelan en bloques inmutables particionados por tiempo y fragmento, usan compresión delta de marcas de tiempo y valores, y luego los suben al almacenamiento de objetos. Los metadatos del bloque contienen tiempo mínimo y máximo, inquilino, resolución, suma de verificación y marca de cobertura. La compactación fusiona bloques pequeños y elimina solo aquellos completamente cubiertos por reemplazos validados.

Un índice invertido mapea pares clave/valor de etiquetas a ID de series, que localizan los bloques de datos. Los metadatos de series y etiquetas activas pueden almacenarse en caché, pero la identidad del inquilino forma parte de cada clave de caché. El submuestreo crea bloques de un minuto y una hora con sum/count/min/max. Los contadores requieren manejo de reinicios y los histogramas se fusionan solo con esquemas de depósitos compatibles. Los bloques sin procesar duran siete días, los de un minuto 90 días y los de una hora 13 meses.

Paso cinco: hacer que el costo de las consultas sea predecible.

El coordinador de consultas analiza el rango de tiempo, los selectores de etiquetas, la agregación y el paso (step). Primero autoriza, usa el índice para encontrar series y lee los bloques relevantes en paralelo. Solo se selecciona un resumen agregado cuando el paso y la función solicitados lo permiten. Un promedio se recalcula a partir de sum/count; un percentil existente no se puede resumir en otro percentil correcto. Las consultas recientes fusionan el head con los bloques persistidos y deduplican en una marca de agua compartida.

Cada consulta tiene límites de series, puntos escaneados, concurrencia, memoria y tiempo límite. Los paneles comunes usan pasos fijos, preagregación y almacenamiento en caché de resultados cortos para apuntar a dos segundos en el p95 durante seis horas recientes. La exploración de alta cardinalidad durante un mes puede convertirse en un trabajo asíncrono. Cuando un fragmento falla, la API devuelve partial=true y el rango faltante. Las reglas de alerta rechazan resultados parciales por defecto.

QueryRange {
  tenantId, expression, start, end, step, maxSeries
}
QueryResult { data, resolution, watermark, partial, warnings }

Paso seis: separar la evaluación de reglas del enrutamiento de notificaciones.

Un programador divide los grupos de reglas por inquilino y evalúa cada 15 o 30 segundos en una marca de tiempo de evaluación explícita. Una instancia de alerta tiene una huella digital estable derivada de la regla y las etiquetas de resultado, y pasa por inactive -> pending -> firing. Una duración for filtra picos transitorios. keep_firing_for o una histéresis explícita evita que datos faltantes breves causen resoluciones repetidas. Cada regla también declara si los datos faltantes son normales, alertables o desconocidos.

Dos evaluadores de alta disponibilidad pueden enviar la misma huella digital a los administradores de alertas, que la deduplican. Los administradores de alertas enrutan por equipo, servicio y severidad; agrupan instancias de un incidente; inhiben alertas de instancias descendentes cuando un clúster es inaccesible; y aplican silencios con vencimiento durante el mantenimiento. El estado de las notificaciones reside en almacenamiento replicado. La entrega es al menos una vez y usa alert_fingerprint + state_transition + receiver como clave de idempotencia. El cómputo de reglas, el estado y las colas de notificación usan capacidad aislada de las consultas ad hoc de los paneles.

Paso siete: manejar fallas, aislamiento de inquilinos y automonitoreo.

Cuando un recolector cae, los arrendamientos de objetivos pasan a instancias en buen estado. La deduplicación absorbe la recolección superpuesta breve. Cuando el registro o el almacenamiento aplican contrapresión, las puertas de enlace reducen los lotes y rechazan explícitamente en lugar de construir una cola de memoria no acotada. Durante una interrupción del almacenamiento de objetos, el registro replicado y el head acotado continúan aceptando datos y la eliminación de bloques se detiene. Más allá de la marca de agua segura, las cuotas de inquilinos protegen las métricas críticas para alertas. La falla de una consulta no debe impedir que las reglas lean una marca de agua confirmada.

La identidad del inquilino proviene de mTLS o un token emitido por el servidor, nunca de una etiqueta de muestra tenant. Se aplican límites separados para la ingesta, las consultas y las reglas. RBAC controla los paneles y la configuración de alertas, y los cambios en reglas, silencios y rutas se auditan. La plataforma observa la latencia de ingesta, el retraso del registro (log backlog), las marcas de agua del head, la antigüedad de los bloques, los puntos de consulta escaneados, el retraso en la evaluación de reglas, los recuentos de alertas pendientes y disparadas, y las fallas de notificación.

El automonitoreo comparte el dominio de falla de la plataforma, por lo que un canario de caja negra externo escribe continuamente una métrica conocida desde un entorno independiente, espera a que su regla se dispare y llegue su notificación, y luego la resuelve. Una verificación de hombre muerto (dead-man check) externa utiliza una ruta de notificación independiente si los latidos esperados se detienen. Esto detecta una plataforma de monitoreo completamente silenciosa.

Paso ocho: validar promesas con pruebas de carga e inyección de fallas.

La carga en estado estable debe alcanzar al menos 667,000 muestras por segundo, seguida de una ráfaga del doble. Luego, genera una tasa de nuevas series diez veces mayor y verifica que el inquilino infractor esté aislado mientras otros inquilinos y la evaluación de reglas sigan cumpliendo sus SLO. Las pruebas de corrección cubren lotes duplicados, valores en conflicto en una misma marca de tiempo, la ventana tardía, reinicios de contadores, fusiones de histogramas, recálculo de resúmenes y resultados idénticos antes y después de la compactación de bloques.

Las pruebas de fallas finalizan un recolector, una réplica de registro de una zona, un nodo head, un fragmento de consulta, un evaluador de reglas y un proveedor de notificaciones. Verifican que las muestras confirmadas permanezcan, que la superposición de arrendamientos se deduplique, que el estado de las reglas se recupere y que los reintentos de notificación no crezcan sin límite. Finalmente, mide la latencia del canario a través de la ingesta, la duración de retención de la regla, la espera de agrupación y la entrega. Confirma 60 segundos en el p99 o identifica la etapa que consumió su presupuesto.

Ejemplo de respuesta sólida

“Primero multiplicaría 50,000 instancias por 200 series para obtener 10 millones de series activas. Dividir entre 15 segundos da aproximadamente 667,000 muestras por segundo, o 57.6 mil millones por día. La planificación de capacidad debe incluir tanto los fragmentos de muestras como los índices de etiquetas. Los presupuestos para series activas y tasa de nuevas series evitan que etiquetas como user_id agoten la plataforma.

La ruta principal utiliza descubrimiento de servicios y recolectores pull fragmentados; los trabajos cortos usan una puerta de enlace push. Después de la autenticación, normalización de etiquetas y verificaciones de cuotas, las muestras ingresan a un registro replicado entre zonas por inquilino y huella de serie. Solo se confirma una escritura registrada en el log. Los datos recientes ingresan a un head, luego se congelan en bloques comprimidos inmutables y un índice invertido de etiquetas en almacenamiento de objetos. Los trabajos en segundo plano producen resúmenes de un minuto y una hora; los promedios se reconstruyen a partir de sum/count.

Un coordinador de consultas poda bloques por tiempo, etiquetas y resolución, con presupuestos para series, puntos, memoria y tiempos límite. Un motor de reglas aprovisionado por separado evalúa marcas de tiempo fijas y preserva los estados inactivo, pendiente y disparado. Los administradores de alertas deduplican por huella digital, luego agrupan, inhiben, silencian y enrutan. Los datos faltantes siguen una política de reglas explícita y las notificaciones usan entrega al menos una vez.

Haría pruebas de carga con 667,000 muestras por segundo, una ráfaga del doble y un aumento de diez veces en nuevas series. Luego inyectaría muestras duplicadas y tardías, una falla de zona, un fragmento de consulta fallido y un proveedor de notificaciones caído. Un canario en un entorno independiente ejercita continuamente desde la ingesta hasta la notificación, verificando el p99 de 60 segundos y detectando el silencio total de la plataforma.”

Errores comunes

• Calcular solo muestras por segundo → Los índices de etiquetas y las series activas pueden agotar la memoria primero → Presupuesta también 10 millones de series activas y la tasa de nuevas series.
• Permitir etiquetas user_id arbitrarias → Cada valor crea otra serie → Aplica políticas de etiquetas, presupuestos de cardinalidad y cuarentena.
• Confirmar al recibir la solicitud → Una falla de proceso o de zona puede perder datos confirmados → Confirma solo después del commit en el registro replicado.
• Tratar los datos faltantes como cero → Una falla de recolección parece una caída del negocio a cero → Preserva el estado obsoleto o desconocido y deja que las reglas elijan una política.
• Promediar promedios → Los depósitos con diferentes recuentos producen un resultado sesgado → Retén sum/count y recalcula.
• Prometer cada consulta en dos segundos → Las etiquetas y los rangos de tiempo ilimitados tienen un costo ilimitado → Delimita el SLO y aplica presupuestos de consulta y rutas asíncronas.
• Permitir que las reglas de alerta acepten resultados parciales → Un fragmento faltante puede parecer una recuperación → Requiere una marca de agua completa o entra en estado desconocido.
• Notificar por cada instancia → Una interrupción grande crea una tormenta de alertas → Agrupa incidentes y usa inhibición, silencios y límites de velocidad.
• Afirmar notificación exactamente una vez → Un tiempo de espera no puede probar si ocurrió la entrega → Usa entrega al menos una vez con claves de idempotencia estables.
• Monitorear la plataforma solo consigo misma → Una interrupción total no produce ninguna señal → Agrega un canario de caja negra independiente y una ruta de hombre muerto.

Preguntas de seguimiento y respuestas

Pregunta de seguimiento 1: ¿Por qué no permitir que todos los clientes envíen (push) directamente?

Los servicios de larga duración se adaptan a la recolección pull: la plataforma conoce el conjunto de objetivos y la frecuencia, distingue un valor medido de una recolección fallida y adjunta etiquetas de recursos confiables de manera consistente. Los trabajos cortos, las redes restringidas y los clientes OTLP existentes se adaptan a push. Ambas entradas utilizan eventualmente la misma validación y el mismo contrato de ingesta duradera, evitando dos semánticas de consulta distintas.

Pregunta de seguimiento 2: ¿Cómo controlas la cardinalidad sin bloquear cargas de trabajo legítimas?

Mide tanto el stock como el flujo: limita las series activas por inquilino y métrica, y limita las nuevas series por minuto. Ofrece una vista previa de cardinalidad antes del despliegue. Advierte cerca del umbral, luego descarta una etiqueta peligrosa configurada, pon en cuarentena la métrica o rechaza nuevas series según la política del inquilino. Retén recuentos de descartes y diagnósticos representativos, pero no copies etiquetas sin procesar sensibles en registros ordinarios.

Pregunta de seguimiento 3: ¿Cómo afectan las muestras tardías a las alertas?

Las reglas leen una marca de agua confirmada en una marca de tiempo de evaluación fija y pueden agregar un pequeño retraso para la latencia normal. Las muestras más antiguas que llegan después de esa marca de agua pueden actualizar consultas históricas, pero no deben retractar una notificación humana por defecto. Si el producto necesita correcciones, emite un evento de corrección con versiones. La ventana tardía, el sesgo de reloj máximo y la regla de conflicto deben documentarse y probarse.

Pregunta de seguimiento 4: ¿Por qué no almacenar percentiles directamente?

Los valores p95 de varias instancias o depósitos de tiempo no se pueden promediar ni pasar por otra operación p95 para obtener el p95 global. Almacena histogramas o estructuras sketch fusionables, combina las distribuciones en el momento de la consulta y luego calcula el percentil. Límites de depósitos incompatibles o parámetros de sketch requieren resultados separados o una migración explícita.

Pregunta de seguimiento 5: ¿Cómo evitan los motores de reglas de alta disponibilidad las notificaciones duplicadas?

Ambos evaluadores pueden computar y enviar la misma instancia de alerta. La huella digital de la instancia es estable en toda la regla y las etiquetas de resultado. Los administradores de alertas usan el estado replicado para deduplicar, agrupar y enrutar por huella digital, estado y receptor. La evaluación no necesita convertirse en un proceso singleton. Una partición aún puede producir un duplicado raro, por lo que los receptores conservan la misma clave de idempotencia.

Pregunta de seguimiento 6: ¿Qué sucede cuando el almacenamiento de objetos no está disponible?

Continúa escribiendo nuevas muestras en el registro replicado y el head acotado. Pausa la carga de bloques, la eliminación por compactación y la aceptación más allá de las marcas de agua seguras. Protege las métricas críticas para alertas con cuotas de inquilinos. Si la recuperación no puede ocurrir dentro de la retención del registro, rechaza nuevas escrituras explícitamente y notifica a los operadores; nunca afirmes que todos los datos siguen siendo aceptados.

Pregunta de seguimiento 7: ¿Cómo funcionarían las consultas globales multirregión?

Cada región recolecta y alerta de forma independiente para que una partición de área amplia no silencie las alertas locales. Un coordinador global lee bloques inmutables publicados o terminales de consulta controlados y devuelve la marca de agua de cada región y el estado de partial. El pequeño conjunto de métricas de alerta verdaderamente globales se agrega primero a nivel regional y luego se replica como resultados de baja cardinalidad en un dominio de reglas separado.

Pregunta de seguimiento 8: ¿Cómo determinas qué etapa rompió el objetivo de alerta de 60 segundos?

Para las muestras del canario, registra la hora de origen, la hora observada, la marca de agua de confirmación del registro, la hora de evaluación de la regla, el intervalo pendiente, la espera de agrupación y la recepción de la notificación. Desglosa el histograma de extremo a extremo por etapa y verifica la llegada final externamente. La cláusula for de cinco minutos de una regla es una condición del producto, no una latencia de detección de la plataforma, por lo que debes informar el procesamiento de la plataforma y la duración de retención configurada por separado.