1aceac797d
Making the LoggingConfiguration part of the versioned component-base/config API
had the theoretic advantage that components could have offered different
configuration APIs with experimental features limited to alpha versions (for
example, sanitization offered only in a v1alpha1.KubeletConfiguration). Some
components could have decided to only use stable logging options.
In practice, this wasn't done. Furthermore, we don't want different components
to make different choices regarding which logging features they offer to
users. It should always be the same everywhere, for the sake of consistency.
This can be achieved with a saner Go API by dropping the distinction between
internal and external LoggingConfiguration types. Different stability levels of
indidividual fields have to be covered by documentation (done) and potentially
feature gates (not currently done).
Advantages:
- everything related to logging is under component-base/logs;
previously this was scattered across different packages and
different files under "logs" (why some code was in logs/config.go
vs. logs/options.go vs. logs/logs.go always confused me again
and again when coming back to the code):
- long-term config and command line API are clearly separated
into the "api" package underneath that
- logs/logs.go itself only deals with legacy global flags and
logging configuration
- removal of separate Go APIs like logs.BindLoggingFlags and
logs.Options
- LogRegistry becomes an implementation detail, with less code
and less exported functionality (only registration needs to
be exported, querying is internal)
|
||
|---|---|---|
| .. | ||
| contextual-logging | ||
| data | ||
| benchmark_test.go | ||
| common_test.go | ||
| load_test.go | ||
| load.go | ||
| README.md | ||
Benchmarking logging
Any major changes to the logging code, whether it is in Kubernetes or in klog, must be benchmarked before and after the change.
Running the benchmark
$ go test -bench=. -test.benchmem -benchmem .
Real log data
The files under data define test cases for specific aspects of formatting. To
test with a log file that represents output under some kind of real load, copy
the log file into data/<file name>.log and run benchmarking as described
above. -bench=BenchmarkLogging/<file name without .log suffix> can be used
to benchmark just the new file.
When using data/v<some number>/<file name>.log, formatting will be done at
that log level. Symlinks can be created to simulating writing of the same log
data at different levels.
No such real data is included in the Kubernetes repo because of their size. They can be found in the "artifacts" of this https://testgrid.kubernetes.io/sig-instrumentation-tests#kind-json-logging-master Prow job:
artifacts/logs/kind-control-plane/containersartifacts/logs/kind-*/kubelet.log
With sufficient credentials, gsutil can be used to download everything for a job with:
gsutil -m cp -R gs://kubernetes-jenkins/logs/ci-kubernetes-kind-e2e-json-logging/<job ID> .
Analyzing log data
While loading a file, some statistics about it are collected. Those are shown when running with:
$ go test -v -bench=. -test.benchmem -benchmem .