Rails standardizes on X-Request-Id as its request correlation id, but Thruster — the layer right in front of it — never puts it in its access log, so the two logs can't be joined.
Rails' ActionDispatch::RequestId tags every log line with X-Request-Id and echoes it on the response, so the id is already passing through Thruster on every request.
Yet Thruster's own log entry shares no field with those Rails lines — to answer "which Thruster request produced this Rails error?" there's
nothing to join on except fuzzy timestamp/path matching, which breaks under concurrency.
Since Thruster is purpose-built to front Rails, surfacing X-Request-Id in its access log feels like a natural fit. It'd also help when Thruster runs standalone (ECS, Fly, behind other proxies), where there's no correlation key in its output today.
I'll leave the exact approach to you.
Rails standardizes on
X-Request-Idas its request correlation id, but Thruster — the layer right in front of it — never puts it in its access log, so the two logs can't be joined.Rails'
ActionDispatch::RequestIdtags every log line withX-Request-Idand echoes it on the response, so the id is already passing through Thruster on every request.Yet Thruster's own log entry shares no field with those Rails lines — to answer "which Thruster request produced this Rails error?" there's
nothing to join on except fuzzy timestamp/path matching, which breaks under concurrency.
Since Thruster is purpose-built to front Rails, surfacing
X-Request-Idin its access log feels like a natural fit. It'd also help when Thruster runs standalone (ECS, Fly, behind other proxies), where there's no correlation key in its output today.I'll leave the exact approach to you.