Better parseable dumps/traces #2960
Comments
|
That's a good idea. I think it could even be done before 3.2-final if we know exactly what we want, because it's not something that should disrupt users experience. And I agree that for setups with tens to hundreds of threads it could significantly ease the dump extraction from the logs. |
|
Just to be certain, you'd want to have this as a prefix for every stdout/stderr line when emitting warnings and backtraces ? Because right now I'm reazlizing that it's already multiline output that is normally not sent to logs, so maybe it ends up mixed with logs via systemd or equivalent, but I would be sure not to make a mistake if that's the case. |
Exactly. Right now we're just matching the program name "haproxy" in syslog-ng and direct anything into a haproxy log. |
|
It's just that they're not sent as logs but really as stderr. Thus it's systemd which re-encodes them as syslog and passes them. But your point remains, even in this ecosystem I understand how it could be useful to have that. Ideally, if systemd was able to prepend a recognizable header (e.g. "stderr") in front of all of them, that would be very helpful. Right now the messages are written as multi-line blocks, and we'll have to find a way to post-process and reformat them to insert headers after each LF, which is not the most trivial to do where it happens (there's just a write() call). |
|
a naive question, but can't open telemetry be used to collect traces? |
|
You're right. It probably comes directly from systemd/journald as I can see journald only has non http(s)log and tcplog logs, like the traces or warnings / notices. So that makes it easier for us to get those. |
Your Feature Request
Hi,
not sure if it's just for me or others as well. I thought it might be cool to have some kind of keyword in front of any dump/trace related message. Like in #2959 (comment)
Having something like:
May 5 16:35:40.996 n095143 haproxy[64306]: DEBUG ...DEBUG or BACKTRACE or something
for every line would make grepping for it much easier.
One could easily do e.g.
grep ': DEBUG 'Would that make sense?
Right now we have like gigabytes of logs where the http(s)log, tcplog and those mentioned are mixed. We could also improve our logging but it could be helpful for others as well, perhaps.
What are you trying to do?
N/A
Output of
haproxy -vvThe text was updated successfully, but these errors were encountered: