Skip to content
This repository has been archived by the owner on Jul 11, 2023. It is now read-only.

Improve logs for GET /tasks/:guid #199

Open
gcapizzi opened this issue Apr 14, 2021 · 0 comments
Open

Improve logs for GET /tasks/:guid #199

gcapizzi opened this issue Apr 14, 2021 · 0 comments
Milestone

Comments

@gcapizzi
Copy link
Contributor

gcapizzi commented Apr 14, 2021

Nothing is logged when the details of a Task are requested. Instead, it would be nice to log something like this:

{"timestamp":"...","level":"info","source":"api","message":"get-task.started","data":{"session":"218"}}
{"timestamp":"...","level":"info","source":"api","message":"get-task.listing-jobs","data":{"session":"218", "label-selector": "..."}}
{"timestamp":"...","level":"info","source":"api","message":"get-task.ended","data":{"session":"218", "response-code": 200}}

Let's also make sure that any errors are logged correctly and only once. Refer to #177562455 for details about how we want to log errors.

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.

@gcapizzi gcapizzi added this to the logging milestone Apr 14, 2021
gcapizzi pushed a commit to eirini-forks/cli that referenced this issue Sep 23, 2021
Instead of parsing the kube config ourselves and invoking a credentials
plugin if configured, we can use the client-go similarly to how we used
it for auth-provider users.

The catch is that the exec authenticator sets details on a transport
config object, but it is still possible to extract certificate
information and to use the request wrapping.

This feels slightly more hacky than the auth-provider code. But then
again, the k8s folks seem careful with their private methods, so we
might assume that the public interface will be maintained.

Issue: cloudfoundry/cf-crd-explorations#64
Co-authored-by: Anonymous Eirininaut <eirini@cloudfoundry.org>
Issue: cloudfoundry/eirini-release#182
Issue: cloudfoundry/eirini-release#184
Issue: cloudfoundry/eirini-release#185
Issue: cloudfoundry/eirini-release#187
Issue: cloudfoundry/eirini-release#186
Issue: cloudfoundry/eirini-release#183
Issue: cloudfoundry/eirini-release#192
Issue: cloudfoundry/eirini-release#193
Issue: cloudfoundry/eirini-release#194
Issue: cloudfoundry/eirini-release#191
Issue: cloudfoundry/eirini-release#196
Issue: cloudfoundry/eirini-release#199
Issue: cloudfoundry/eirini-release#200
Issue: cloudfoundry/eirini-release#219
Issue: cloudfoundry/eirini-release#220
Issue: cloudfoundry/eirini-release#221
Issue: cloudfoundry/eirini-release#218
Issue: cloudfoundry/eirini-release#222
Issue: cloudfoundry/eirini-release#223
Issue: cloudfoundry/eirini-release#224
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant