-
Story
-
Resolution: Done
-
Major
-
None
-
None
-
None
As part of our overall debug enhancement work, we're interested in leveraging kubernetes events to convey debug information similar to Pods. The example typically given is: when you are debugging pods, generally you are not reading pod controller logs unless the issue is quite severe. Usually the user facing debug experience involves running a `kubectl describe <pod-name>` and viewing the events. If a pod isn't launching for example, you might find an event that says it failed to mount a volume.
I'm deliberately not prescribing exactly what events should be raised here, or where. We will need a distinct task to decide: what is our event strategy? What info belongs in logs vs. events? What information should be raised in events and when? I'd expect this is the bulk of the work involved in this story, as the implementation should be fairly straightforward once we know exactly when and what should be emitted.
- is related to
-
MIG-563 Improve user-centric logging and add structured logging
- Closed