Saúde, observabilidade e diagnóstico

Existir, expor e autorizar

Um endpoint pode existir no contexto sem estar exposto pela web. As listas web e JMX são independentes; exclude prevalece sobre include. Só health está exposto por defeito nesta versão. Escolher health e info é uma decisão de superfície disponível, não uma política completa de acesso.

Com Spring Security e sem cadeia própria, o Boot fornece proteção automática para actuators além de health. Quando defines SecurityFilterChain, essa configuração automática recua e a aplicação passa a controlar as regras. Revê também os caminhos de sondas adicionados à porta principal; não presumas que uma regra antiga já os abrange.

Saúde e detalhe público

O resultado health agrega os contribuintes configurados. Um indicador de base pode verificar se consegue obter uma ligação; isso não demonstra que todas as queries de negócio são rápidas ou que uma migração é compatível. Regista que indicadores entram no resultado antes de usar UP como condição de entrega.

show-details controla o detalhe disponibilizado. O excerto usa never, reduzindo informação pública. Endpoints como env e configprops podem conter dados sensíveis e têm regras próprias de sanitização. Não troques a minimização por exposição ampla para facilitar uma investigação; fornece acesso operacional com âmbito explícito.

A sonda deve corresponder à decisão

Liveness informa uma decisão de reinício da instância. Incluir uma base partilhada nessa sonda pode reiniciar todas as instâncias quando a base falha, sem reparar a dependência. Readiness informa a aceitação de tráfego; a escolha de dependências externas precisa de considerar o contrato funcional e os modos degradados.

Uma dependência opcional com fallback não deve retirar desnecessariamente toda a capacidade. Uma dependência essencial partilhada exige uma decisão explícita: retirar tráfego ou tratar a falha noutro nível. Nenhuma escolha elimina a necessidade de observar o impacto para os clientes.

Cobrir o conector que serve clientes

Uma porta de gestão separada usa infraestrutura que pode continuar funcional quando o conector principal está saturado ou indisponível. Por isso, obter health UP na porta 9091 não contradiz automaticamente uma falha dos clientes na porta 8080. Os dois pedidos não percorrem necessariamente a mesma infraestrutura.

add-additional-paths disponibiliza /livez e /readyz na porta principal. Isso acrescenta cobertura desse conector, mas ainda pode deixar de fora gateway, TLS externo, autorização funcional ou uma operação com dados. A aceitação deve ligar as sondas ao percurso realmente afetado pelo incidente.

Agregação com cardinalidade controlada

Micrometer Observation permite gerar métricas e traces a partir de observações. Etiquetas de baixa cardinalidade entram em ambos; etiquetas de alta cardinalidade entram apenas nos traces. Para comparar duração por operação e região, escolhe nomes estáveis e conjuntos limitados, em vez de criar uma série por id de pedido.

Cardinalidade não substitui uma política de dados. Um segredo continua inadequado num trace. A instrumentação MVC produz normalmente http.server.requests; algumas exceções tratadas não entram automaticamente na etiqueta de exceção. A ausência dessa etiqueta não é prova de ausência de erro funcional.

Correlação ao atravessar threads

Uma observação pode perder continuidade quando a execução passa para outra thread. No executor Async auto-configurado desta versão, a propagação precisa da opção spring.task.execution.propagate-context. A presença de um ThreadLocal na thread original não demonstra que o valor estará disponível no trabalho assíncrono.

Identifica primeiro a fronteira e o executor usado. Um executor configurado manualmente pode exigir integração própria com o mecanismo de propagação; não atribuas esse apoio automaticamente à configuração Boot. A propagação de observabilidade também não significa propagar uma transação JDBC entre threads.

Conservar evidência útil

Actuator pode publicar eventos de sucesso e falha de autenticação e acesso negado através do mecanismo de auditoria. Um AuditEventRepository permite conservar esses eventos. A implementação em memória tem capacidades limitadas e destina-se a desenvolvimento; não demonstra durabilidade após reinício nem partilha entre instâncias.

Para um requisito de produção, define armazenamento, controlo de acesso, retenção e correlação apropriados. Distingue eventos de segurança de resultados de negócio: autenticação bem-sucedida não prova que uma reserva foi confirmada. A cronologia precisa de identificar o efeito observado e o que ainda é desconhecido.

Armadilhas comuns

Expor todos os actuators por conveniência; incluir dependências partilhadas em liveness; confundir UP com todos os fluxos recuperados; usar ids de pedidos como etiquetas de métricas; conservar auditoria apenas em memória.