search

cloudfoundry / eirini-release

Helm release for Project Eirini
Apache License 2.0
36 stars 34 forks source link

Improve logs for Docker staging #185

Open gcapizzi opened 3 years ago

gcapizzi commented 3 years ago

When pushing a Docker app, this is the only staging-related logs printed:

2021/04/06 16:13:44 [DEBUG] POST http://capi.cf-system.svc.cluster.local:9023/internal/v3/staging/65545898-befa-4078-9fa2-7c84693008cb/build_completed?start=false

This is not a lager log. Also, it would be nice to see when staging starts and ends, and when we invoke the Docker registry, as info logs. Something like this:

{"timestamp":"...","level":"info","source":"api","message":"docker-staging.started","data":{"session":"218", "param-1": "...", "param-2": "...", ...}}
{"timestamp":"...","level":"info","source":"api","message":"docker-staging.fetching-image-metadata","data":{"session":"218", "ref": "..."}}
{"timestamp":"...","level":"info","source":"api","message":"docker-staging.notifying-completion","data":{"session":"218", "guid": "..."}}
{"timestamp":"...","level":"info","source":"api","message":"docker-staging.ended","data":{"session":"218", "response-code": 200}}

Dev Notes

Ensure logs are correlated using lager session IDs. This requires using the logger.Session method and passing the logger through method calls. It will not work if the logger is stored in a struct.

Logger can be passed as an explicit method argument, or might also be passed as part of the context object that is already passed around (see the https://github.com/cloudfoundry/lager/tree/master/lagerctx package, and note in this story). With lagerctx, there is the risk of accidentally and unknowingly using the fallback discard logger if the original context is somehow lost while passing through methods. So explicitly passing both context and logger as separate method parameters throughout might be the safest option, giving compile-time guarantees of having logging correctly propagated.