Skip to content
This repository has been archived by the owner on Apr 26, 2024. It is now read-only.

Make log correlation more configurable (support analysis services, e.g. Google, New Relic) #14413

Open
bradjones1 opened this issue Nov 11, 2022 · 0 comments
Labels
A-Logging Synapse's logs (structured or otherwise). Not metrics. O-Occasional Affects or can be seen by some users regularly or most users rarely S-Minor Blocks non-critical functionality, workarounds exist. T-Enhancement New features, changes in functionality, improvements in performance, or user-facing enhancements.

Comments

@bradjones1
Copy link
Contributor

Description:

Thanks everyone who works on Synapse, it's really great.

The recent PR #13801 added the ability to specify the header from which to pull a request ID. This is a great step toward log correlation, but it more-or-less requires manual action to correlate.

I am using Google's Cloud Logging (aka Stackdriver) and logs may be correlated automatically in their tooling if the structured logs contain a trace key with a value following a particular convention. Something similar exists for New Relic, see discussion at Seldaek/monolog#1735).

It would be awesome if Synapse could support this. I think it could be as simple as:

  • Make the name of the request ID key, currently fixed to request, configurable. (E.g., I would set this to trace).
  • Drop the auto-prefixing of the request with the method name. The method is already included in the log (method).

In my case, I am currently setting the trace-id with a little bit of lua magic with an openresty reverse proxy, e.g.:

server {
    location @default {
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_set_header X-Forwarded-Proto 'https';
        set_by_lua $trace_id 'return string.sub(ngx.req.get_headers()["traceparent"], 4, 35)';
        proxy_set_header trace-id $trace_id;
        set $upstream {{ .Env.UPSTREAM }};
        proxy_pass http://$upstream:{{ default .Env.UPSTREAM_PORT "8008" }};
    }
}

And if this were supported, I would simply update this to include the additional data Google is looking for, e.g. the project ID. Synapse would then be responsible for hairpinning that back to me.

Alternatively, I suppose this could be viewed as more an extension of the opentracing implementation, and Synapse could read out the Trace ID from the traceparent header and include it somehow in the logs. However, that wouldn't address the need for making the log value configurable (e.g., prefixing it with additional cloud provider namespacing.)

@squahtx squahtx added A-Logging Synapse's logs (structured or otherwise). Not metrics. S-Minor Blocks non-critical functionality, workarounds exist. T-Enhancement New features, changes in functionality, improvements in performance, or user-facing enhancements. O-Occasional Affects or can be seen by some users regularly or most users rarely labels Nov 11, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
A-Logging Synapse's logs (structured or otherwise). Not metrics. O-Occasional Affects or can be seen by some users regularly or most users rarely S-Minor Blocks non-critical functionality, workarounds exist. T-Enhancement New features, changes in functionality, improvements in performance, or user-facing enhancements.
Projects
None yet
Development

No branches or pull requests

2 participants