You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Add support to export traces from the node via open-telemetry.
Using open-telemetry as a standard allows operators to choose their own monitoring backend.
This would be used for exporting metrics as well, but since we don't have any yet this isn't required at the moment. Depending on our own backend choices metrics might be derivable from traces.
The intent of this issue is to support basic monitoring for our testnet and devnet instances. This means it does not have to be perfect - just good enough to get started. open-telemetry is an evolving, complex specification and quite configurable (in theory). The rust implementation of this is not feature complete, nor always correct so we should be happy with something simple we can evolve to firstly match our needs, and then secondly be useable by other operators.
As an example, we should ideally have separate rpc, store and block-producer trace emitters; but this is confusing in our "one process" mode of operation. So initially maybe simply node is good enough.
The text was updated successfully, but these errors were encountered:
Add support to export
traces
from the node viaopen-telemetry
.Using
open-telemetry
as a standard allows operators to choose their own monitoring backend.This would be used for exporting metrics as well, but since we don't have any yet this isn't required at the moment. Depending on our own backend choices metrics might be derivable from traces.
The intent of this issue is to support basic monitoring for our testnet and devnet instances. This means it does not have to be perfect - just good enough to get started.
open-telemetry
is an evolving, complex specification and quite configurable (in theory). The rust implementation of this is not feature complete, nor always correct so we should be happy with something simple we can evolve to firstly match our needs, and then secondly be useable by other operators.As an example, we should ideally have separate
rpc
,store
andblock-producer
trace emitters; but this is confusing in our "one process" mode of operation. So initially maybe simplynode
is good enough.The text was updated successfully, but these errors were encountered: