c4535cf5bf
Produced via: `prettier --write --prose-wrap=always $(find -name '*.md' | grep -v vendor | grep -v .github | grep -v docs/cmd/)` /assign n3wscott vagababov /cc n3wscott vagababov |
||
|---|---|---|
| .. | ||
| README.md | ||
| doc.go | ||
| interface.go | ||
| kubelogs.go | ||
| null.go | ||
README.md
How to use logstream
This is a guide to start using logstream in your e2e testing.
Requirements
- The
SYSTEM_NAMESPACEenvironment variable must be configured. Many of the knative test scripts already define this, and in some places (e.g. serving) randomize it. However, to facilitate usage outside of CI, you should consider including a package like this and linking it like this
- Test resources must be named with
test.ObjectNameForTest(t)
- At the start of your test add:
t.Cleanup(logstream.Start(t))
With that, you will start getting logs from the processes in the system
namespace interleaved into your test output via t.Log.
How it works
In Knative we use zap.Logger for all of our logging, and most of those loggers
(e.g. in the context of a reconcile) have been decorated with the "key" of the
resource being processed. logstream simply decodes these structured log
messages and when the key matches the naming prefix that ObjectNameForTest
uses, it includes it into the test's output.
Integrating in Libraries.
When a shared component is set up and called from reconciliation, it may have it's own logger. If that component is dealing with individual resources, it can scope individual log statements to that resource by decorating the logger with its key like so:
logger := logger.With(zap.String(logkey.Key, resourceKey))
Now, any log statements that the library prints through this logger will appear in the logstream!
For an example of this pattern, see the knative/networking prober library.