Draft: Migrate to OpenTelemetry tracing

changelog.d/13400.feature

@@ -0,0 +1 @@
+Migrate from OpenTracing to OpenTelemetry (config changes necessary).

docs/SUMMARY.md

@@ -88,7 +88,7 @@
   - [Git Usage](development/git.md)
   - [Testing]()
     - [Demo scripts](development/demo.md)
-  - [OpenTracing](opentracing.md)
+  - [Tracing](tracing.md)
   - [Database Schemas](development/database_schema.md)
   - [Experimental features](development/experimental_features.md)
   - [Dependency management](development/dependencies.md)

docs/opentracing.md

@@ -1,94 +1,3 @@
 # OpenTracing
 
-## Background
-
-OpenTracing is a semi-standard being adopted by a number of distributed
-tracing platforms. It is a common api for facilitating vendor-agnostic
-tracing instrumentation. That is, we can use the OpenTracing api and
-select one of a number of tracer implementations to do the heavy lifting
-in the background. Our current selected implementation is Jaeger.
-
-OpenTracing is a tool which gives an insight into the causal
-relationship of work done in and between servers. The servers each track
-events and report them to a centralised server - in Synapse's case:
-Jaeger. The basic unit used to represent events is the span. The span
-roughly represents a single piece of work that was done and the time at
-which it occurred. A span can have child spans, meaning that the work of
-the child had to be completed for the parent span to complete, or it can
-have follow-on spans which represent work that is undertaken as a result
-of the parent but is not depended on by the parent to in order to
-finish.
-
-Since this is undertaken in a distributed environment a request to
-another server, such as an RPC or a simple GET, can be considered a span
-(a unit or work) for the local server. This causal link is what
-OpenTracing aims to capture and visualise. In order to do this metadata
-about the local server's span, i.e the 'span context', needs to be
-included with the request to the remote.
-
-It is up to the remote server to decide what it does with the spans it
-creates. This is called the sampling policy and it can be configured
-through Jaeger's settings.
-
-For OpenTracing concepts see
-<https://opentracing.io/docs/overview/what-is-tracing/>.
-
-For more information about Jaeger's implementation see
-<https://www.jaegertracing.io/docs/>
-
-## Setting up OpenTracing
-
-To receive OpenTracing spans, start up a Jaeger server. This can be done
-using docker like so:
-
-```sh
-docker run -d --name jaeger \
-  -p 6831:6831/udp \
-  -p 6832:6832/udp \
-  -p 5778:5778 \
-  -p 16686:16686 \
-  -p 14268:14268 \
-  jaegertracing/all-in-one:1
-```
-
-Latest documentation is probably at
-https://www.jaegertracing.io/docs/latest/getting-started.
-
-## Enable OpenTracing in Synapse
-
-OpenTracing is not enabled by default. It must be enabled in the
-homeserver config by adding the `opentracing` option to your config file. You can find 
-documentation about how to do this in the [config manual under the header 'Opentracing'](usage/configuration/config_documentation.md#opentracing).
-See below for an example Opentracing configuration: 
-
-```yaml
-opentracing:
-  enabled: true
-  homeserver_whitelist:
-    - "mytrustedhomeserver.org"
-    - "*.myotherhomeservers.com"
-```
-
-## Homeserver whitelisting
-
-The homeserver whitelist is configured using regular expressions. A list
-of regular expressions can be given and their union will be compared
-when propagating any spans contexts to another homeserver.
-
-Though it's mostly safe to send and receive span contexts to and from
-untrusted users since span contexts are usually opaque ids it can lead
-to two problems, namely:
-
--   If the span context is marked as sampled by the sending homeserver
-    the receiver will sample it. Therefore two homeservers with wildly
-    different sampling policies could incur higher sampling counts than
-    intended.
--   Sending servers can attach arbitrary data to spans, known as
-    'baggage'. For safety this has been disabled in Synapse but that
-    doesn't prevent another server sending you baggage which will be
-    logged to OpenTracing's logs.
-
-## Configuring Jaeger
-
-Sampling strategies can be set as in this document:
-<https://www.jaegertracing.io/docs/latest/sampling/>.
+Synapse now uses OpenTelemetry and the [documentation for tracing has moved](./tracing.md).

docs/tracing.md

@@ -0,0 +1,90 @@
+# Tracing
+
+## Background
+
+OpenTelemetry is a semi-standard being adopted by a number of distributed
+tracing platforms. It is a common API for facilitating vendor-agnostic
+tracing instrumentation.
+
+Tracing is a tool which gives an insight into the causal
+relationship of work done in and between servers. The servers each track
+events and report them to a centralised server - in Synapse's case:
+Jaeger. The basic unit used to represent events is the span. The span
+roughly represents a single piece of work that was done and the time at
+which it occurred. A span can have child spans, meaning that the work of
+the child had to be completed for the parent span to complete, or it can
+have follow-on spans which represent work that is undertaken as a result
+of the parent but is not depended on by the parent to in order to
+finish.
+
+Since this is undertaken in a distributed environment a request to
+another server, such as an RPC or a simple GET, can be considered a span
+(a unit or work) for the local server. This causal link is what
+tracing aims to capture and visualise. In order to do this metadata
+about the local server's span, i.e the 'span context', needs to be
+included with the request to the remote.
+
+It is up to the remote server to decide what it does with the spans it
+creates. This is called the sampling policy and it can be configured
+through Jaeger's settings.
+
+For OpenTelemetry concepts, see
+<https://opentelemetry.io/docs/concepts/>.
+
+For more information about the Python implementation of OpenTelemetry we're using, see
+<https://opentelemetry.io/docs/instrumentation/python/>
+
+For more information about Jaeger, see
+<https://www.jaegertracing.io/docs/>
+
+## Setting up tracing
+
+To receive tracing spans, start up a Jaeger server. This can be done
+using docker like so:
+
+```sh
+docker run -d --name jaeger \
+  -p 6831:6831/udp \
+  -p 6832:6832/udp \
+  -p 5778:5778 \
+  -p 16686:16686 \
+  -p 14268:14268 \
+  jaegertracing/all-in-one:1
+```
+
+Latest documentation is probably at
+https://www.jaegertracing.io/docs/latest/getting-started.
+
+## Enable tracing in Synapse
+
+Tracing is not enabled by default. It must be enabled in the
+homeserver config by adding the `tracing` option to your config file. You can find 
+documentation about how to do this in the [config manual under the header 'Tracing'](usage/configuration/config_documentation.md#tracing).
+See below for an example tracing configuration: 
+
+```yaml
+tracing:
+  enabled: true
+  homeserver_whitelist:
+    - "mytrustedhomeserver.org"
+    - "*.myotherhomeservers.com"
+```
+
+## Homeserver whitelisting
+
+The homeserver whitelist is configured using regular expressions. A list
+of regular expressions can be given and their union will be compared
+when propagating any spans contexts to another homeserver.
+
+Though it's mostly safe to send and receive span contexts to and from
+untrusted users since span contexts are usually opaque ids it can lead
+to two problems, namely:
+
+-   If the span context is marked as sampled by the sending homeserver
+    the receiver will sample it. Therefore two homeservers with wildly
+    different sampling policies could incur higher sampling counts than
+    intended.
+-   Sending servers can attach arbitrary data to spans, known as
+    'baggage'. For safety this has been disabled in Synapse but that
+    doesn't prevent another server sending you baggage which will be
+    logged in the trace.

docs/usage/configuration/config_documentation.md

@@ -72,6 +72,7 @@ apply if you want your config file to be read properly. A few helpful things to
   In addition, each setting has an example of its usage, with the proper indentation
   shown.
 
+
 ## Modules
 
 Server admins can expand Synapse's functionality with external modules.
@@ -3643,47 +3644,50 @@ default_power_level_content_override:
 ```
 
 ---
-## Opentracing
-Configuration options related to Opentracing support.
+## Tracing
+Configuration options related to tracing support.
 
 ---
-### `opentracing`
+### `tracing`
 
-These settings enable and configure opentracing, which implements distributed tracing.
-This allows you to observe the causal chains of events across servers
-including requests, key lookups etc., across any server running
-synapse or any other services which support opentracing
-(specifically those implemented with Jaeger).
+These settings enable and configure tracing. This allows you to observe the
+causal chains of events across servers including requests, key lookups etc.,
+across any server running synapse or any other services which support
+OpenTelemetry.
 
 Sub-options include:
 * `enabled`: whether tracing is enabled. Set to true to enable. Disabled by default.
 * `homeserver_whitelist`: The list of homeservers we wish to send and receive span contexts and span baggage.
-   See [here](../../opentracing.md) for more.
+   See [here](../../tracing.md#homeserver-whitelisting) for more. 
    This is a list of regexes which are matched against the `server_name` of the homeserver.
    By default, it is empty, so no servers are matched.
-* `force_tracing_for_users`: # A list of the matrix IDs of users whose requests will always be traced,
+* `sample_rate`: The probability that a given span and subsequent child spans in the trace will be      
+   recorded. This controls the amount of spans that record and are exported from Synapse.
+* `force_tracing_for_users`: A list of the matrix IDs of users whose requests will always be traced,
    even if the tracing system would otherwise drop the traces due to probabilistic sampling.
     By default, the list is empty.
-* `jaeger_config`: Jaeger can be configured to sample traces at different rates.
-   All configuration options provided by Jaeger can be set here. Jaeger's configuration is
-   mostly related to trace sampling which is documented [here](https://www.jaegertracing.io/docs/latest/sampling/).
+* `jaeger_exporter_config`: Configure authentication and where you Jaeger instance is located.
+   Full options available in the [`JaegerExporter` API docs](https://opentelemetry-python.readthedocs.io/en/latest/exporter/jaeger/jaeger.html#opentelemetry.exporter.jaeger.thrift.JaegerExporter).
 
 Example configuration:
 ```yaml
-opentracing:
+tracing:
     enabled: true
     homeserver_whitelist:
       - ".*"
+
+    sample_rate: 1
     force_tracing_for_users:
       - "@user1:server_name"
       - "@user2:server_name"
 
-    jaeger_config:
-      sampler:
-        type: const
-        param: 1
-      logging:
-        false
+    jaeger_exporter_config:
+      agent_host_name: localhost
+      agent_port: 6831
+      # Split UDP packets so they fit within the limit (UDP_PACKET_MAX_LENGTH is set to 65k in OpenTelemetry)
+      udp_split_oversized_batches: true
+      # If you define a collector, it will communicate directly to the collector, bypassing the agent
+      #collector_endpoint: "http://localhost:14268/api/traces?format=jaeger.thrift"
 ```
 ---
 ## Coordinating workers

mypy.ini

@@ -174,9 +174,6 @@ ignore_missing_imports = True
 [mypy-pympler.*]
 ignore_missing_imports = True
 
-[mypy-rust_python_jaeger_reporter.*]
-ignore_missing_imports = True
-
 [mypy-saml2.*]
 ignore_missing_imports = True