You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Dec 21, 2021. It is now read-only.
Currently this information is written in prose, e.g. "Invocation ID could not be stored. Container handle for pod [{:?}] and container [{}] not found". But sometimes not all questions are answered in the log message and must therefore be gathered from previous log messages, e.g. "No data found in ConfigMap..". If several pods are running then it is hard to find the correct context.
I propose to unify all logs messages to the following format: [{namespace}/{pod} {container_type}/{container}] {reason}
(container_type is app or init).
The full log line would then be: [2021-07-27T09:23:34Z ERROR stackable_agent::provider::states::pod::starting] [default/kafka app/service] Invocation ID could not be stored. Container handle not found.
I think it is also sufficient to mention the systemd service unit once and not in every log message. The context given by pod and container makes it clear which unit file is meant.
[2021-07-27T09:23:28Z DEBUG stackable_agent::provider::states::pod::terminated] Stopping systemd unit [default-agent-service-integration-test-restart-6e50b029-433b-43d0-80ba-cd670d717024-nostop-service.service]
[2021-07-27T09:23:28Z DEBUG stackable_agent::provider::systemdmanager::manager] Trying to stop systemd unit [default-agent-service-integration-test-restart-6e50b029-433b-43d0-80ba-cd670d717024-nostop-service.service]
[2021-07-27T09:23:34Z DEBUG stackable_agent::provider::systemdmanager::manager] Successfully stopped service [default-agent-service-integration-test-restart-6e50b029-433b-43d0-80ba-cd670d717024-nostop-service.service]
[2021-07-27T09:23:34Z DEBUG stackable_agent::provider::states::pod::terminated] Removing systemd unit [default-agent-service-integration-test-restart-6e50b029-433b-43d0-80ba-cd670d717024-nostop-service.service]
[2021-07-27T09:23:34Z DEBUG stackable_agent::provider::systemdmanager::manager] Disabling unit [default-agent-service-integration-test-restart-6e50b029-433b-43d0-80ba-cd670d717024-nostop-service.service]
[2021-07-27T09:23:34Z DEBUG stackable_agent::provider::systemdmanager::manager] Trying to disable systemd unit [default-agent-service-integration-test-restart-6e50b029-433b-43d0-80ba-cd670d717024-nostop-service.service]
[2021-07-27T09:23:34Z DEBUG stackable_agent::provider::systemdmanager::manager] Successfully disabled service [default-agent-service-integration-test-restart-6e50b029-433b-43d0-80ba-cd670d717024-nostop-service.service]
[2021-07-27T09:23:34Z DEBUG stackable_agent::provider::systemdmanager::manager] Removing unit [default-agent-service-integration-test-restart-6e50b029-433b-43d0-80ba-cd670d717024-nostop-service.service] from systemd
[2021-07-27T09:23:34Z DEBUG stackable_agent::provider::systemdmanager::manager] Removing ["/home/sigi/.config/systemd/user/default-agent-service-integration-test-restart-6e50b029-433b-43d0-80ba-cd670d717024-nostop-service.service"]
The text was updated successfully, but these errors were encountered:
For every log output, the same questions arise:
Currently this information is written in prose, e.g.
"Invocation ID could not be stored. Container handle for pod [{:?}] and container [{}] not found"
. But sometimes not all questions are answered in the log message and must therefore be gathered from previous log messages, e.g."No data found in ConfigMap.."
. If several pods are running then it is hard to find the correct context.I propose to unify all logs messages to the following format:
[{namespace}/{pod} {container_type}/{container}] {reason}
(container_type is app or init).
The full log line would then be:
[2021-07-27T09:23:34Z ERROR stackable_agent::provider::states::pod::starting] [default/kafka app/service] Invocation ID could not be stored. Container handle not found.
I think it is also sufficient to mention the systemd service unit once and not in every log message. The context given by pod and container makes it clear which unit file is meant.
The text was updated successfully, but these errors were encountered: