crmsh.log lack marker to distinguish user command from internal sub-commands

[zzhou1]

When executing a high-level composite crmsh command such as

adm@161-1:~> sudo -E crm cluster health sbd --fix

crmsh automatically runs multiple hidden internal subcommands.

All INFO log lines for both the original user command and every auto-spawned internal subcommand are printed without any distinguishing marker.

adm@161-1:~> sudo tail -f /var/log/crmsh/crmsh.log
2026-06-17T18:57:45.317+0800 161-1 crmsh.ui_context: INFO: crm(live/161-1)# cluster health sbd --fix
2026-06-17T18:57:47.112+0800 161-1 crmsh.ui_context: INFO: crm(live/161-1)# configure show related:stonith
2026-06-17T18:57:47.306+0800 161-1 crmsh.ui_context: INFO: crm(live/161-1)# configure show xml
2026-06-17T18:57:47.741+0800 161-1 crmsh.ui_context: INFO: crm(live/161-1)# configure show related:stonith
2026-06-17T18:57:47.958+0800 161-1 crmsh.ui_context: INFO: crm(live/161-1)# configure show xml
2026-06-17T18:57:49.827+0800 161-1 crmsh.ui_context: INFO: crm(live/161-1)# configure get_property stonith-watchdog-timeout
2026-06-17T18:57:50.206+0800 161-1 crmsh.ui_context: INFO: crm(live/161-1)# configure get_property stonith-timeout
2026-06-17T18:57:50.318+0800 161-1 crmsh.utils: WARNING: "stonith-timeout" is deprecated, please consider using "fencing-timeout"
2026-06-17T18:57:51.487+0800 161-1 crmsh.utils: WARNING: "stonith-timeout" is deprecated, please consider using "fencing-timeout"
2026-06-17T18:57:51.529+0800 161-1 crmsh.utils: WARNING: "stonith-enabled" is deprecated, please consider using "fencing-enabled"
2026-06-17T18:57:51.535+0800 161-1 crmsh.sbd: INFO: SBD: Check sbd timeout configuration: OK.

[fmherschel]

Thanks @zzhou1

[nicholasyang2022]

We could adopt the industry-standard observability practices by implementing distributed tracing¹ with trace context² propagation.

Using an environment variable TRACEPARENT, we could generate a new trace_id for external calls and propagate it through internal calls. This will work across ssh calls, and even with other programs supporting observability standards.

We will not only be able to distinguish external vs internal calls, but also to filter the log by trace_id and to see the entire calling chain across multiple nodes in a cluster.

Footnotes

1. https://opentelemetry.io/docs/concepts/observability-primer/#understanding-distributed-tracing ↩

2. https://www.w3.org/TR/trace-context/ ↩