> ## Documentation Index > Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt > Use this file to discover all available pages before exploring further. # Operando o Lerian SCR > Operando o Lerian SCR: verificações de prontidão, namespaces de configuração em runtime, rotação de credencial, cache e retenção, métricas e a postura estrita. O Lerian SCR roda em um canal regulatório tarifado, e sua superfície operacional o protege. ## Saúde e prontidão *** `GET /health` responde liveness. `GET /readyz` responde uma entrada por dependência. | Verificação | O que verifica | Quando falha | | ---------------- | ----------------------------------------------------------------- | -------------------------------------------------------------- | | `postgres` | Um ping no pool primário. | Inalcançável: down. | | `redis` | Um ping no cliente do cache. | Inalcançável: down. Ausente: ignorado. | | `scr_endpoint` | Um handshake TLS limitado com o BACEN. Sem query, sem credencial. | Cadeia quebrada: down. Timeout de conexão: degradado. | | `vault` | Uma chamada de alcançabilidade no armazenamento de credenciais. | Inalcançável: degradado, uma credencial em cache ainda atende. | | `tenant_manager` | O diretório de tenants, apenas multi-tenant. | Inalcançável: down. | | `event_emission` | A postura de emissão declarada. | Nunca. Apenas reporta. | O resultado do handshake serve por 20 segundos, então a prontidão nunca conecta ao BACEN por requisição. O breaker em nível de pod abre apenas quando todos os breakers por instituição estão abertos. Uma instituição com falha mantém o pod pronto e responde `SCR-1002`. No encerramento, `/readyz` retorna 503 primeiro, e o listener permanece aberto por três segundos. `READYZ_DRAIN_DELAY` faz override disso. ## Configuração em runtime *** Nove namespaces chegam a um operador em `/v1/system`, sob o scope `scr:system:write`. A tabela lista os sete que o serviço lê. `scr.cors` e `scr.postgres` também existem no catálogo. O serviço obtém suas configurações de cross-origin e de pool de conexões a partir das [variáveis de ambiente](/pt/rails/scr/scr-environment-variables). Uma mudança de nível de log entra em vigor imediatamente. Uma mudança de retenção entra em vigor na próxima varredura de expurgo. O serviço lê todos os outros namespaces quando inicia, então uma mudança ali entra em vigor na próxima reinicialização. Veja [System plane](/pt/reference/platform/systemplane/overview). | Namespace | O que controla | Padrões | | --------------------- | ----------------------------------------------------- | ------------------------------------------ | | `scr.app` | Nível de log. | Configuração de inicialização. | | `scr.rate_limit` | Limite de entrada por IP. | 100 por 60 segundos. | | `scr.outbox` | Intervalo, tamanho de lote, tentativas de publicação. | `2s`, 50, 3. | | `scr.wsscr2n` | Deadline de requisição, conexões por instituição. | `25s`, 2. | | `scr.cache` | Tempos de vida de entrada. | `4h`, `720h`. | | `scr.circuit_breaker` | Limiares de acionamento, período de resfriamento. | 5 falhas, proporção 0,5, mínimo 10, `30s`. | | `scr.retention` | Janela de expurgo, cadência de varredura. | Vazio. Expurgo desativado. | Todo parâmetro carrega limites finitos. O deadline de requisição para abaixo de 28 segundos, então uma requisição nunca sobrevive ao gateway. O limite de conexão aceita 1 ou 2. ## Credenciais e rotação *** O tipo de armazenamento de segredos escolhe a origem da credencial. O tipo ambiente lê o usuário e a senha a partir do ambiente de deployment. O tipo vault gerenciado os resolve por instituição, e o banco de dados mantém apenas uma referência. O tipo vault gerenciado também monta `PUT /v1/scr/credential`. Ele grava no vault primeiro e nos metadados depois, então uma nova tentativa reutiliza a referência. A senha nunca alcança um log, um span, ou um erro. A operação de status retorna um nome de usuário mascarado. Uma indisponibilidade do vault responde `SCR-1002` e nunca aciona o breaker do canal. ## Cache e retenção *** O cache de resultado mantém uma entrada por instituição, índice cego do tomador e mês de referência. Cada valor carrega o envelope em repouso da linha de auditoria. Uma entrada do mês corrente vive quatro horas, uma entrada de mês fechado 720 horas. Uma entrada ilegível conta como um miss, e um deployment sem Redis dá miss sempre. O expurgo de auditoria permanece desativado até que um operador defina uma janela. Uma janela vazia não exclui nada. Com uma janela, uma varredura diária exclui linhas mais antigas em lotes limitados, e nunca as arquiva. ## Métricas e rastreamento *** A exportação padrão é push OTLP. Um listener de scrape do Prometheus é opt-in em um endereço loopback, `127.0.0.1:9075` por padrão. A porta da aplicação não tem nenhuma rota `/metrics`. Dois histogramas medem uma consulta: de ponta a ponta, e o overhead sem a chamada ao BACEN. Seus labels carregam a instituição, a flag de cache-hit, e o desfecho, nunca o tomador. Contadores cobrem códigos de decodificação desconhecidos e linhas expurgadas. ## Postura de deployment *** Um nome de ambiente de produção ou o modo de deployment SaaS seleciona a postura estrita. A inicialização estrita exige um modo de deployment explícito, o host do Postgres, banco de dados e usuário, e autorização sobre um endereço https. Exige a URL base do canal sobre https, e TLS no Postgres e em qualquer Redis ou broker configurado. Exige duas chaves de criptografia em repouso distintas e uma região para o vault gerenciado, e proíbe um intervalo de proxy wildcard. Uma lista de broker ou host Redis em branco recusa a inicialização, a menos que um operador declare o opt-out. O log de inicialização e o `/readyz` então nomeiam as proteções degradadas. Multi-tenancy precisa da URL do diretório de tenants e de uma chave de serviço. Caso contrário, um deployment atende uma instituição. Um operador aplica o esquema fora do processo de runtime. O serviço o lê e nunca o cria.