Saltar al contenido principal
Lerian SCR se ejecuta sobre un canal regulatorio tarifado, y su superficie operativa lo protege.

Salud y readiness


GET /health responde liveness. GET /readyz responde una entrada por dependencia. El resultado del handshake sirve durante 20 segundos, por lo que readiness nunca marca a BACEN por solicitud. Un breaker del canal abierto reporta scr_endpoint como down. Un scr_endpoint caído o degradado no lleva /readyz a 503, por lo que el servicio sigue en rotación durante una caída de BACEN. Una consulta que nunca llegó a BACEN responde entonces SCR-1002, y su detail nombra a BACEN. Al apagar, /readyz pasa a 503 primero, y el listener permanece abierto tres segundos. READYZ_DRAIN_DELAY lo anula.

Configuración en tiempo de ejecución


Siete espacios de nombres llegan a un operador en /v1/system, bajo el ámbito scr:system:write. El servicio toma su configuración de pool de conexiones desde las variables de entorno. Un cambio de nivel de log surte efecto de inmediato. Un cambio de retención surte efecto en el siguiente barrido de purga. El servicio lee cualquier otro espacio de nombres al iniciar, por lo que un cambio ahí surte efecto en el siguiente reinicio. Consulta System plane. El plazo configurado para la consulta debe ser inferior a 28 segundos. La persistencia de auditoría tiene un timeout separado. El tope de conexiones acepta 1 o 2.

Credenciales y rotación


El tipo de secret store elige la fuente de la credencial. El tipo de entorno lee el usuario y la contraseña desde el entorno de despliegue. El tipo de vault gestionado los resuelve desde el vault, y la base de datos guarda solo una referencia. El tipo de vault gestionado también habilita PUT /v1/scr/credential. Escribe primero el vault y luego los metadatos, por lo que un reintento reutiliza la referencia. La contraseña nunca llega a un log, un span, o un error. La operación de estado devuelve un nombre de usuario enmascarado. Una caída del vault responde SCR-1002 y nunca activa el breaker del canal.

Caché y retención


La caché de resultados contiene una entrada por índice ciego del prestatario y mes de referencia. Cada valor lleva el sobre en reposo de la fila de auditoría. Una entrada del mes en curso vive cuatro horas, una entrada de un mes cerrado 720 horas. Una entrada ilegible cuenta como un fallo de caché. La purga de auditoría permanece desactivada hasta que establezcas una ventana: la clave retention.audit_max_age de client_policy en /v1/client-system. Una ventana vacía no elimina nada. Con una ventana, un barrido elimina las filas más antiguas en lotes acotados, y nunca las archiva.

Métricas y trazas


Con ENABLE_TELEMETRY=true, las métricas salen por OTLP push. Un listener de scrape de Prometheus es de activación explícita, en una dirección loopback, 127.0.0.1:9075 por defecto. El puerto de la aplicación no tiene ninguna ruta /metrics. Dos histogramas miden una consulta: de extremo a extremo, y la sobrecarga sin la llamada a BACEN. Sus etiquetas llevan la institución, la marca de acierto de caché, y el resultado, nunca al prestatario. Los contadores cubren códigos de decodificación desconocidos, entradas de caché ilegibles, y filas purgadas.

Postura de despliegue


Un nombre de entorno de producción o el modo de despliegue SaaS selecciona la postura estricta. El arranque estricto exige un modo de despliegue explícito, el host, la base de datos y el usuario de Postgres, y autorización sobre una dirección https. Exige la URL base del canal sobre https, y TLS en Postgres y en cualquier Redis o broker configurado. Exige dos claves en reposo distintas y una región para el vault gestionado, y prohíbe un rango de proxy comodín. Una lista de brokers o un host de Redis en blanco rechaza el arranque, a menos que un operador declare la exclusión explícita. El log de arranque y /readyz entonces nombran las protecciones degradadas. Un operador aplica el esquema fuera del proceso en tiempo de ejecución. El servicio lo lee y nunca lo crea.