TriggerMesh components communicate their internal events through a flexible logging system. Output format, structure, and granularity are adjustable through a configuration file. Information produced by the TriggerMesh logging system can be collected and stored by a centralized log management platform, such as the ELK stack or AWS CloudWatch, and used for further processing.
Log level configuration allows you to adjust the amount and detail of the logs produced by the TriggerMesh components. Logging configuration parameters are set through the configmap in the system namespace and applied on TriggerMesh components across all cluster namespaces.
Since TriggerMesh core components are heavily based on the Knative libraries, logging also complies with the upstream configuration approach described here.
Log levels supported by TriggerMesh components are:
debug- fine-grained debugging
info- normal logging
warn- unexpected but non-critical errors
error- critical errors; unexpected during normal operation
dpanic- in debug mode, trigger a panic (crash)
panic- trigger a panic (crash)
fatal- immediately exit with exit status 1 (failure)
Each logging level in this hierarchy includes all levels below, i.e. setting the
error level will silence the output
tagged as debug, info, and warn, but will keep error, panic, and fatal. Most information is produced at the
level - it can come in handy during integration development and tests. In the
error logging level nothing but errors
that require the operator's attention is emitted. By default, all components are set to the
info level that provides
general initialization information and some additional outputs that may be useful for the operator.
Configuring log levels
TriggerMesh components log levels are currently set from the
config-logging configmap in
triggermesh namespace. To
update the component’s logging level, the configuration must be either edited in place by executing this command:
kubectl -n triggermesh edit configmap config-logging
Or it can be changed in the project’s source and applied with:
kubectl apply -f config-logging.yaml
Components logging configuration is propagated through the containers environment and picked up at the initialization step, hence switching between levels may require resource re-creation.
The sample configuration fragment below sets the individual log levels for some of the TriggerMesh resources:
# Logging level overrides for the TriggerMesh control plane. loglevel.triggermesh-controller: error loglevel.triggermesh-webhook: error # Logging level overrides for TriggerMesh components. # The name of the logger is the Kubernetes kind of the component. loglevel.awss3target: debug loglevel.ibmmqsource: debug loglevel.transformation: debug
After we apply this configuration, TriggerMesh controller and webhook will switch to the
error level, while all newly
created AWS S3 targets, IBM MQ sources, and Transformations will have a
debug logging level.