Conversation
|
Hey @ndbroadbent thanks for the quick PR ! Since this is a more structural PR than a simple feature, and as I did with the semantic logger PR, I would want to do an extra check using the test app, can you create a branch (and a PR from it) in the test app repo that configures logstruct and makes sure all log lines are displayed in the tui? Here's some instructions => open in new tab, the internal navigation in github is broken for comments I just realized
|
6a60315 to
08a48a3
Compare
|
Hmm how are you linking the actual job executions to a request ID? I think that is a bit out of scope for LogStruct (ensuring a request ID is passed with each job invocation and tying all the logs together), so I'm wondering how you've done that for log_bench? |
|
@ndbroadbent certainly is not the job of LogStruct or Lograge, it's LogBench ... But since you are adding logstruct as an alternative, you need to make sure you can configure logbench to keep the same functionality it does with Lograge. Check https://github.com/silva96/log_bench/blob/main/lib/log_bench/railtie.rb and https://github.com/silva96/log_bench/blob/main/lib/log_bench/json_formatter.rb |
|
OH awesome, that makes a lot of sense! I didn't fully understand what LogBench was doing before. Got it. I'll try to find some time to update the PR to show actual job executions as well |
Add support for LogStruct job execution events: - JobStartEntry for evt:start with src:job - JobFinishEntry for evt:finish with src:job These entries are linked to requests via the job_id → request_id mapping, allowing the full job lifecycle (enqueue → start → finish) to be tracked and grouped with the originating HTTP request. Also adds evt:enqueue detection for immediate job enqueues (in addition to existing evt:schedule for delayed jobs).
|
@ndbroadbent I will have a look tomorrow, sorry for the delay. |


Adds support for LogStruct:
Also with some compatibility for SemanticLogger PR #66. Shared patterns (both PRs use):