Como cambiar el nivel de log en runtime

Cuando un servicio en produccion tiene un comportamiento sospechoso, activar DEBUG puntual sobre un paquete y restaurarlo al terminar suele ser mas rapido que un redeploy con la configuracion ajustada. El arquetipo deja expuesto /actuator/loggers para ese flujo — los cambios aplican de inmediato y se revierten al reiniciar el proceso.

El endpoint requiere autenticacion en una configuracion de produccion tipica (la NetworkPolicy y el web.security.unauthenticated-paths lo expone solo a clientes internos). Los ejemplos de abajo asumen que la autenticacion es resuelta por la red (operador con acceso al pod via kubectl port-forward o sidecar autenticador).

Ver el nivel actual de un logger

curl http://localhost:8080/actuator/loggers/io.zutun.templates.orders

Respuesta:

{
  "configuredLevel": null,
  "effectiveLevel": "INFO"
}

  • configuredLevel: nivel seteado explicitamente en este logger. null significa que hereda del padre.

  • effectiveLevel: nivel que efectivamente se aplica, despues de resolver herencia.

Para listar todos los loggers conocidos: GET /actuator/loggers.

Subir el nivel a DEBUG

curl -X POST http://localhost:8080/actuator/loggers/io.zutun.templates.orders \
  -H 'Content-Type: application/json' \
  -d '{"configuredLevel": "DEBUG"}'

El cambio aplica de inmediato — el siguiente log emitido por cualquier clase bajo io.zutun.templates.orders sale con nivel DEBUG. La respuesta es 204 No Content cuando tiene exito.

Niveles aceptados: TRACE, DEBUG, INFO, WARN, ERROR, FATAL, OFF.

Restaurar al default

Para volver a heredar el nivel del padre — es decir, deshacer el override y dejar que la configuracion de application.yaml o las variables de entorno gobiernen otra vez — se manda null:

curl -X POST http://localhost:8080/actuator/loggers/io.zutun.templates.orders \
  -H 'Content-Type: application/json' \
  -d '{"configuredLevel": null}'

Tambien se puede usar DELETE con el mismo efecto:

curl -X DELETE http://localhost:8080/actuator/loggers/io.zutun.templates.orders

Los cambios en runtime no persisten al restart. Cuando el proceso reinicia, los loggers vuelven a la configuracion declarada en application.yaml / logback-spring.xml. Si el nivel debe persistir, agregarlo a la configuracion del servicio.

Ajustar varios loggers a la vez

/actuator/loggers no soporta batch. Para mover multiples loggers, encadenar requests — por ejemplo en un script:

for pkg in \
    io.zutun.templates.orders \
    io.zutun.templates.commons.adapter.in \
    org.springframework.transaction
do
  curl -X POST "http://localhost:8080/actuator/loggers/$pkg" \
    -H 'Content-Type: application/json' \
    -d '{"configuredLevel": "DEBUG"}'
done

Caso de uso: investigar un evento que no se publica

Escenario: un evento de dominio no aparece en el broker. La hipotesis es que el outbox no esta dispatching, pero los logs en INFO no muestran nada.

  1. Subir a DEBUG el procesador de outbox y la publicacion:

    curl -X POST http://localhost:8080/actuator/loggers/io.zutun.templates.commons.adapter.in.tasks \
  -H 'Content-Type: application/json' \
  -d '{"configuredLevel": "DEBUG"}'

  2. Reproducir el flujo. Los logs ahora muestran cada poll, cada batch, y la decision de publicar o saltear.

  3. Restaurar:

    curl -X DELETE http://localhost:8080/actuator/loggers/io.zutun.templates.commons.adapter.in.tasks

Para investigar el estado de la bandeja sin tocar logs, ver Inspeccionar las bandejas de mensajeria.

Ver tambien