Siga una solicitud lenta antes de redimensionar

Elija una solicitud con un resultado esperado claro

Para un endpoint de informe ilustrativo, registre el patrón de ruta, el tamaño aproximado de los datos, el contexto de autenticación y si genera trabajo en segundo plano. Use una cuenta de prueba y datos saneados representativos. No copie tokens, identificadores de clientes ni cuerpos de solicitud completos en una nota de incidente.

Separe el costo de inicio de la primera solicitud del comportamiento estable repetido. Registre la ventana UTC y la revisión de la versión. Determine si todas las rutas son lentas, si solo se ven afectados los informes grandes o si el retraso sigue a una dependencia externa. Estas distinciones hacen que la siguiente medición sea más útil que una amplia recopilación de métricas no relacionadas.

Construya una línea de tiempo sin contar dos veces

Las trazas de OpenTelemetry conectan spans relacionados mediante contexto propagado a través de los límites de servicio. Solo coincidir las marcas de tiempo no es suficiente. Los spans síncronos anidados y las llamadas paralelas pueden solaparse. Los hijos asíncronos pueden sobrevivir a su padre, por lo que sumar la duración de cada span puede contar dos veces el tiempo transcurrido. Siga las operaciones que determinan cuándo se completa la solicitud.

Referencia técnica: Trazas de OpenTelemetry · Comportamiento de finalización de spans de OpenTelemetry.

El intervalo más grande sugiere dónde inspeccionar, no la causa raíz. Un intervalo de base de datos medido en la API puede incluir la espera de una conexión antes de que una consulta llegue a la base de datos. La telemetría ausente tampoco prueba que no haya ocurrido trabajo; inspeccione el muestreo y la cobertura de instrumentación.

Correlacione las observaciones de la aplicación y del host

Recopile tiempos de solicitud, errores, uso de conexiones de base de datos, antigüedad de la cola, CPU, memoria y presión de disco para la misma ventana. Anote copias de seguridad, migraciones o versiones concurrentes. Una sola captura de pantalla de utilización puede pasar por alto el pico que afectó a la solicitud.

Use IDs de correlación y marcas de tiempo en registros redactados con la retención y los controles de acceso adecuados. Evite secretos sin procesar, payloads de clientes y etiquetas de métricas ilimitadas. Instrumente el límite necesario para la hipótesis y revise la sobrecarga. Un nuevo agente de trazado es en sí mismo un cambio que vale la pena observar.

Inspeccione la consulta sin causar otro incidente

Identifique primero la forma de la consulta, las características del tamaño de entrada y las esperas de conexión o bloqueo. PostgreSQL EXPLAIN describe un plan; EXPLAIN ANALYZE ejecuta realmente la sentencia y añade sobrecarga de instrumentación. Una escritura puede cambiar datos, mientras que una lectura costosa igualmente genera carga. Use una base de datos representativa aislada para la investigación inicial.

El costo del planificador no son milisegundos transcurridos. Una tabla de prueba diminuta puede producir un plan diferente al del conjunto de datos más grande de la aplicación. Revise estadísticas, índices y distribución, y compare la misma forma de consulta después de cambiarla. Nunca pegue una escritura desconocida en un comando de análisis en producción solo para obtener tiempos.

Referencia técnica: PostgreSQL EXPLAIN.

Prediga qué debería mejorar un cambio

Si domina la espera del pool, inspeccione las conexiones de los workers o las solicitudes que retienen una conexión innecesariamente. Si domina la ejecución de la consulta, inspeccione el plan y las filas solicitadas. Si domina una API externa, revise los tiempos de espera, los reintentos y si el trabajo debe ser síncrono. La saturación de CPU durante la serialización apunta a un experimento diferente.

Escriba una predicción: reducir la concurrencia de exportaciones debería reducir la espera del pool de la API mientras las exportaciones tardan más. Esto expone la disyuntiva. Repita la misma mezcla de solicitudes, compare latencia y errores, y compruebe que la mejora no simplemente trasladó el fallo a una cola en constante crecimiento.

Conserve el resultado y su incertidumbre

Registre la observación original, el cambio probado, el método de comparación y la incertidumbre restante. Si la evidencia contradice la hipótesis, deshaga el cambio aislado donde corresponda e investigue otro límite. Evite acumular cambios de ajuste permanentes sin explicación.

Redimensione cuando las mediciones identifiquen una restricción de recursos que una asignación adicional podría abordar. Use el presupuesto de carga de trabajo y capture una regresión de versión en el informe de incidente. El resultado es un diagnóstico razonado, no una latencia prometida ni un benchmark de proveedor.