Changes for content/relay-operators/relay-bridge-overloaded/contents.lr: 236 added lines, 49 removed lines.
Original line number
Diff line number
Diff line
@@ -70,9 +70,217 @@ For a more detailed explanation about ``MetricsPort`` and ``MetricsPortPolicy``
### MetricsPort output
Here is an example of what output enabling ``MetricsPort`` will produce:
Here is an example of what output enabling ``MetricsPort`` will produce (we omitted any congestion control related metrics as we still need to stabilize that interface):
```
# HELP tor_relay_connections Total number of opened connections
@@ -157,9 +341,12 @@ It can happen that this pool starts dropping work due to memory or CPU pressure
If your server is running at capacity this will likely be triggered.
The ntor and ntor_v3 values will be the same at the moment which is a [bug we
need to fix](https://gitlab.torproject.org/tpo/core/tor/-/issues/40638).
### tor_relay_exit_dns_error_total{...}
Any counter in the "*_dns_error_total" realm indicates a potential DNS related problem.
Any counter in the "*_dns_error_total" realm (apart from the one for successful queries) indicates a potential DNS related problem.
However, we realized during the 0.4.7 release cycle that DNS errors are way too noisy and contain too many false positives to be useful for overload reporting purposes.
We therefore don't use them anymore for that purpose starting with 0.4.6.9 and 0.4.7.4-alpha. However, we still keep DNS metrics around to give the relay operator insight into what is going on with their relay.
@@ -197,7 +384,7 @@ In this case the OS could OOM tor, without tor even noticing memory pressure.
### tor_relay_load_socket_total
These lines indicate the relay is running out of sockets.
If the number of opened sockets is close to or the same as total sockets available then this indicates the relay is running out of sockets.
The solution is to increase ``ulimit -n`` for the tor process.