Remove timestamp from active log file

[idrennanvmware]

Nomad has recently introduced this change hashicorp/nomad#11070 which removes the timestamp from the active logging file. This is highly desirable for us and makes it easy to provide some processes around agents (filebeat for example). We would love to see this feature make it to Consul as well and would like to request parity here.

Thanks!
Ian

[jkirschner-hashicorp]

Thanks for the suggestion!

This is closely related to #9906. The solution proposed there is slightly different, which is the only reason I haven't marked one as a duplicate and closed. When someone submits a PR for this, it should address/close both this issue and #9906.

[idrennanvmware]

Thanks @jkirschner-hashicorp !

From a consumer point of view, we would definitely prefer a cohesive or similar experience across the products (we aren't partial to one or the other solution, just a consistent one). FWIW it's definitely easier to do some things when the "active" file has a predictable and static name. Please let us know if we can help shape this in any way :)

Thanks
Ian

[jkirschner-hashicorp]

Hi @idrennanvmware,

We'll need to think through design options and how to limit disruption to existing users who may be relying on the current behavior. I may reach out in the future to get your thoughts on an option(s).

Thanks!

[idrennanvmware]

Thanks @jkirschner-hashicorp - totally understand.

We have upgraded to nomad 1.1.5 and are loving the log file being just the file name (with archived files having the timestamp)

Not to beat the subject in to the ground but consistency is a really nice experience across the Hashi products so we're 🤞 that Consul will follow suit :)

[jkirschner-hashicorp]

Hi @idrennanvmware,

Part of the challenge here is that I was initially trying to address #9287 (which I started on before this was posted), but it probably doesn't make sense to address #9287 without addressing this enhancement (#10976) as well. Both affect the log file configuration options, so should be considered together (unless we choose not to do 9287).

I haven't yet come up with a solution I like that:

• Has a good configuration UX
• Is a non-breaking change to the current behavior (e.g., opt-in)

If you're interested in discussing some options and how they do (or don't) support your use cases, send me a brief message at the email address in my Github profile. We could schedule a time to talk in a few weeks.

And yes, 100% agree that consistency is an important UX principle!