Telemetry integration for event tracing, metrics, and logging.
Redix connections (both Redix and Redix.PubSub) execute the
following Telemetry events:
[:redix, :connection]- executed when a Redix connection establishes the connection to Redis. There are no measurements associated with this event. Metadata are::connection- the PID of the Redix connection that emitted the event.:connection_name- the name (passed to the:nameoption when the connection is started) of the Redix connection that emitted the event.nilif the connection was not registered with a name.:address- the address the connection successfully connected to.:reconnection- a boolean that specifies whether this was a first connection to Redis or a reconnection after a disconnection. This can be useful for more granular logging.
[:redix, :disconnection]- executed when the connection is lost with the Redis server. There are no measurements associated with this event. Metadata are::connection- the PID of the Redix connection that emitted the event.:connection_name- the name (passed to the:nameoption when the:address- the address the connection was connected to. connection is started) of the Redix connection that emitted the event.nilif the connection was not registered with a name.:reason- the disconnection reason as aRedix.ConnectionErrorstruct.
[:redix, :failed_connection]- executed when Redix can't connect to the specified Redis server, either when starting up the connection or after a disconnection. There are no measurements associated with this event. Metadata are::connection- the PID of the Redix connection that emitted the event.:connection_name- the name (passed to the:nameoption when the connection is started) of the Redix connection that emitted the event.nilif the connection was not registered with a name.:addressor:sentinel_address- the address the connection was trying to connect to (either a Redis server or a Redis Sentinel instance).:reason- the disconnection reason as aRedix.ConnectionErrorstruct.
Redix connections execute the following Telemetry events when commands or
pipelines of any kind are executed.
[:redix, :pipeline, :start]- executed right before a pipeline (or command, which is a pipeline with just one command) is sent to the Redis server. Measurements are::system_time(integer) - the system time (in the:nativetime unit) at the time the event is emitted. SeeSystem.system_time/0.
Metadata are:
:connection- the PID of the Redix connection used to send the pipeline.:connection_name- the name of the Redix connection used to sent the pipeline. This isnilif the connection was not registered with a name or if the pipeline function was called with a PID directly (for example, if you didProcess.whereis/1manually).:commands- the commands sent to the server. This is always a list of commands, so even if you doRedix.command(conn, ["PING"])then the list of commands will be[["PING"]].:extra_metadata- any term set by users via the:telemetry_metadataoption inRedix.pipeline/3and other functions.
[:redix, :pipeline, :stop]- executed a response to a pipeline returns from the Redis server, regardless of whether it's an error response or a successful response. Measurements are::duration- the duration (in the:nativetime unit, seeSystem.time_unit/0) of back-and-forth between client and server.
Metadata are:
:connection- the PID of the Redix connection used to send the pipeline.:connection_name- the name of the Redix connection used to sent the pipeline. This isnilif the connection was not registered with a name or if the pipeline function was called with a PID directly (for example, if you didProcess.whereis/1manually).:commands- the commands sent to the server. This is always a list of commands, so even if you doRedix.command(conn, ["PING"])then the list of commands will be[["PING"]].:extra_metadata- any term set by users via the:telemetry_metadataoption inRedix.pipeline/3and other functions.
If the response is an error, the following metadata will also be present:
:kind- the atom:error.:reason- the error reason (such as aRedix.ConnectionErrorstruct).
Cluster events
Redix.Cluster connections execute the following Telemetry events:
[:redix, :cluster, :pipeline, :start]- executed when aRedix.Cluster.command/3,pipeline/3, ortransaction_pipeline/3call starts. Measurements are:system_time. Metadata are::cluster- the name of the cluster (the atom passed as:name).:call-:pipeline(forcommand/3andpipeline/3) or:transaction_pipeline.:route- the resolved:routeoption (:primary,:replica, or:prefer_replica).:commands- the commands passed to the call.:extra_metadata- the:telemetry_metadataoption passed to the call, or%{}.
Available since 1.7.0.
[:redix, :cluster, :pipeline, :stop]- executed when the call returns. It covers every node request and every MOVED/ASK hop the call performed. Measurements are::duration- the total time of the call (in native units).:command_count- the number of commands in the call.:node_count- the number of nodes the commands were split across.:redirections- the number of MOVED/ASK redirections followed.
Metadata are the same as for
:start, plus:result(the return value of the call).Available since 1.7.0.
[:redix, :cluster, :pipeline, :exception]- executed when the call raises or exits. Measurements are:duration. Metadata are the same as for:start, plus:kind,:reason, and:stacktrace.Available since 1.7.0.
[:redix, :cluster, :discovery_wait]- executed when a call had to wait for the initial topology discovery (only possible before the first topology fetch completes withsync_connect: false). Measurements are:duration. Metadata are:clusterand:result.Available since 1.7.0.
[:redix, :cluster, :topology_change]- executed when the cluster topology is successfully refreshed. Measurements are:duration(the time spent fetchingCLUSTER SLOTS) and:node_count. Metadata are::cluster- the name of the cluster (the atom passed as:name).:nodes- the list of primary node addresses (as"host:port"strings).:node_info- a list of maps with:id,:host,:port, and:role(:primaryor:replica) for every node the cluster connects to.
[:redix, :cluster, :failed_topology_refresh]- executed when the cluster manager fails to refresh the topology (no reachable node). Measurements are:duration. Metadata are::cluster- the name of the cluster.:reason- the error reason. This is{:no_reachable_node, node_errors}, wherenode_errorsis a list of{host, port, reason}triples, one per node that was tried, in the order tried, so you can tell (for example) a wrong password from a network partition instead of a single opaque reason.
[:redix, :cluster, :node_connection_failed]- executed when the cluster manager fails to establish a connection to a specific node. There are no measurements. Metadata are::cluster- the name of the cluster.:address- the node address (as a"host:port"string).:reason- the error reason.:kind-:start_failedif the connection could not be started, or:parkedif the connection stopped with a semantic error (such asNOAUTHorWRONGPASS) and is left for the next topology refresh instead of being restarted.
[:redix, :cluster, :node_connection_restarted]- executed when a node connection went down for a non-semantic reason (a crash or a kill) and the cluster manager restarts it right away. There are no measurements. Metadata are::cluster- the name of the cluster.:address- the node address (as a"host:port"string).:role-:primaryor:replica.:reason- the exit reason of the old connection.
Available since 1.7.0.
[:redix, :cluster, :node_role_changed]- executed when a topology refresh finds that a node changed role (typically after a failover) and its connections are restarted with the new role. There are no measurements. Metadata are::cluster- the name of the cluster.:address- the node address (as a"host:port"string).:from- the previous role (:primaryor:replica).:to- the new role.
Available since 1.7.0.
[:redix, :cluster, :redirection]- executed when a command receives aMOVEDorASKredirection from a cluster node. There are no measurements. Metadata are::cluster- the name of the cluster.:type- either:movedor:ask.:slot- the hash slot being redirected.:target_address- the target node address (as a"host:port"string).
More events might be added in the future and that won't be considered a breaking
change, so if you're writing a handler for Redix events be sure to ignore events
that are not known. All future Redix events will start with the :redix atom,
like the ones above.
A default handler that logs these events appropriately is provided, see
attach_default_handler/0. Otherwise, you can write your own handler to
instrument or log events, see the Telemetry page in the docs.
Summary
Functions
Attaches the default Redix-provided Telemetry handler.
Functions
@spec attach_default_handler() :: :ok | {:error, :already_exists}
Attaches the default Redix-provided Telemetry handler.
This function attaches a default Redix-provided handler that logs
(using Elixir's Logger) the following events:
[:redix, :disconnection]- logged at the:errorlevel[:redix, :failed_connection]- logged at the:errorlevel[:redix, :connection]- logged at the:infolevel if it's a reconnection, not logged if it's the first connection.[:redix, :cluster, :failed_topology_refresh]- logged at the:errorlevel[:redix, :cluster, :node_connection_failed]- logged at the:warninglevel[:redix, :cluster, :node_connection_restarted]- logged at the:warninglevel[:redix, :cluster, :node_role_changed]- logged at the:infolevel[:redix, :cluster, :redirection]- logged at the:infolevel
See the module documentation for more information. If you want to attach your own handler, look at the Telemetry page in the documentation.
Examples
:ok = Redix.Telemetry.attach_default_handler()