We introduce an updated version of diagnostics sent from a TypeDB server.
config.yml gets a new field deploymentID for the diagnostics section. This field should be used for collecting the data from multiple servers of a single TypeDB Cloud deployment.
The updated diagnostics data contains more information about the server resources and details for each separate database. More details can be found in the examples below.
For the JSON reporting, we calculated diffs between the current timestamp and the sinceTimestamp (the previous hour when the data had to be sent: it's updated even if we had errors sending the data for simplicity). For the Prometheus data, we send raw counts as Prometheus calculates diffs based on its queries and expects raw diagnostics from our side.
For the JSON monitoring, we show only the incrementing counters from the start of the server just as for the Prometheus diagnostics data (also available through the monitoring page). This way, the content is different from the reporting data.
The schema and data diagnostics about each specific database are sent only from the primary replica of a deployment at the moment of the diagnostics collection. The connection peak values diagnostics regarding a database are still reported by a non-primary replica if the database exists or there were established transactions within the last hour before the database had been deleted.
If the statistics reporting is turned off in the config, we send a totally safe part of the diagnostics data once to notify the server about the moment when the diagnostics were turned off. No user data is shared in this snapshot (see examples below). This action is performed only if the server is up for 1 hour (to avoid our CI tests report data), and only if the server has not successfully sent such a snapshot after turning the statistics reporting off the last time. If there is an error in sending this snapshot, the server will try again after a restart (no extra logic here).
Usage and product changes
We introduce an updated version of diagnostics sent from a
TypeDB
server.config.yml
gets a new fielddeploymentID
for thediagnostics
section. This field should be used for collecting the data from multiple servers of a singleTypeDB Cloud
deployment.JSON
reporting, we calculated diffs between the current timestamp and thesinceTimestamp
(the previous hour when the data had to be sent: it's updated even if we had errors sending the data for simplicity). For thePrometheus
data, we send raw counts asPrometheus
calculates diffs based on its queries and expects raw diagnostics from our side.JSON
monitoring, we show only the incrementing counters from the start of the server just as for the Prometheus diagnostics data (also available through the monitoring page). This way, the content is different from the reporting data.schema
anddata
diagnostics about each specific database are sent only from the primary replica of a deployment at the moment of the diagnostics collection. Theconnection
peak values diagnostics regarding a database are still reported by a non-primary replica if the database exists or there were established transactions within the last hour before the database had been deleted.Example diagnostics data for Prometheus (http://localhost:4104/metrics?format=prometheus):
Example diagnostics JSON data from monitoring (http://localhost:4104/metrics?format=JSON):
Example of diagnostics JSON data sent when the reporting flag is turned on:
Example of diagnostics JSON data sent once when the reporting flag is turned off:
Implementation
There is no huge refactoring as it's planned to be a cleaner feature in the incoming 3.0.