Skip to content

Conversation

MadLittleMods
Copy link
Contributor

@MadLittleMods MadLittleMods commented Aug 25, 2025

Background

As part of Element's plan to support a light form of vhosting (virtual host) (multiple instances of Synapse in the same Python process), we're currently diving into the details and implications of running multiple instances of Synapse in the same Python process.

"Per-tenant logging" tracked internally by https://github.com/element-hq/synapse-small-hosts/issues/48

Prior art

Previously, we exposed server_name by providing a static logging MetadataFilter that injected the values:

log_metadata_filter = MetadataFilter({"server_name": config.server.server_name})

While this can work fine for the normal case of one Synapse instance per Python process, this configures things globally and isn't compatible when we try to start multiple Synapse instances because each subsequent tenant will overwrite the previous tenant.

What does this PR do?

We remove the MetadataFilter and replace it by tracking the server_name in the LoggingContext and expose it with our existing LoggingContextFilter that we already use to expose information about the request.

This means that the server_name value follows wherever we log as expected even when we have multiple Synapse instances running in the same process.

Todo

Pull Request Checklist

  • Pull request is based on the develop branch
  • Pull request includes a changelog file. The entry should:
    • Be a short description of your change which makes sense to users. "Fixed a bug that prevented receiving messages from other servers." instead of "Moved X method from EventStore to EventWorkerStore.".
    • Use markdown where necessary, mostly for code blocks.
    • End with either a period (.) or an exclamation mark (!).
    • Start with a capital letter.
    • Feel free to credit yourself, by adding a sentence "Contributed by @github_username." or "Contributed by [Your Name]." to the end of the entry.
  • Code style is correct (run the linters)

This allows us to get access to `server_name` before
which we may want to use in the `with LoggingContext("main"):`
call early on.

This also allows us more flexibility to parse config however
we want and setup a Synapse homeserver. Like what we do
in Synapse Pro for Small Hosts.
There are no instances where we don't provide it either
@github-actions github-actions bot deployed to PR Documentation Preview August 25, 2025 22:47 Active
@MadLittleMods MadLittleMods changed the title Better expose server_name to logging Fix server_name in logging context for multiple Synapse instances in one process Aug 25, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant