provider-gcp icon indicating copy to clipboard operation
provider-gcp copied to clipboard

Please allow for more verbose logging

Open timstoop opened this issue 5 years ago • 5 comments

What problem are you facing?

It would be nice if logging verbosity could be increased, at least to the level that it shows for each action what it's trying to do. This would also help in providing more information for bug reports, for instance, for my last bug report #164, it's impossible for me (ot at least not documented) how I should go about making stack gcp log what it's actually trying to do with the Google API.

How could Crossplane help solve your problem?

Allow logging of API calls in stack-gcp would be a good start.

timstoop avatar Feb 07 '20 14:02 timstoop

Some Slack conversation about this is available here.

Notably, the --debug option that can be sent to the stack-gcp controller can be added by editing the Stack's deployment (once it is deployed). kubectl edit -n crossplane-system deployment stack-gcp-controller and adding args to the containers: block under spec/template/spec/containers:

spec:
  template:
    spec:
      containers:
      - args:
        - --debug
      - image: crossplane/stack-gcp:v0.5.0

Making this change after install can be cumbersome. In the Slack thread the notion of specifying the intent for including debugging in the stack controller was suggested.

# This is not currently supported, but perhaps could be implemented as such
kind: StackInstall
spec:
  package: ...
  controllerArgs:
  - ...

In this suggestion, controllerArgs would be appended to those built into the Stack package install.yaml. Replacing the args may be a better choice. This suggestion also implies that a single controller would be deployed, but the StackInstall spec is open to multiple Stacks fulfilling a StackInstall.

This is related to https://github.com/crossplaneio/crossplane/issues/974, https://github.com/crossplaneio/crossplane/issues/1126, and https://github.com/crossplaneio/crossplane/issues/1238

displague avatar Feb 07 '20 14:02 displague

Just to point out, adding the --debug outputs a lot of lines, but none of them are really useful for the problem I was debugging.

2020-02-07T15:04:52.303Z        DEBUG   crossplane.controller   Reconciling     {"controller": "resourceclaim.crossplane.io", "request": "services/test-postgres"}
2020-02-07T15:04:52.303Z        DEBUG   controller-runtime.controller   Successfully Reconciled {"controller": "mysqlinstance.cloudsqlinstance.database.gcp.crossplane.io", "request": "services/test-postgres"}

Unless there are more options I could add that would show the API call it's sending?

timstoop avatar Feb 07 '20 15:02 timstoop

Adding some context here with a new observability guide that was recently added to our docs: https://crossplane.io/docs/master/observability-developer-guide.html

/cc @negz for theory behind logging strategy

hasheddan avatar Feb 07 '20 15:02 hasheddan

We don't quite log every API call, but we increased the amount of debug logging for stack-gcp in https://github.com/crossplaneio/stack-gcp/pull/142. You can see the new logs and events, and more importantly Kubernetes events, if you run the master build of this stack, or wait for next week's release. Please let us know whether they seem useful!

Edit: Here's an example - https://github.com/crossplaneio/crossplane-runtime/pull/108#issuecomment-578580816

negz avatar Feb 12 '20 20:02 negz

A workaround may be to use the GCP log explorer to inspect the payloads sent by crossplane provider-gcp and maybe compare them with a successful payloads.

gberche-orange avatar May 18 '22 14:05 gberche-orange