table of contents
MongoDB::Monitoring(3pm) | User Contributed Perl Documentation | MongoDB::Monitoring(3pm) |
NAME¶
MongoDB::Monitoring - Internal event monitoring API for instrumentation
VERSION¶
version v2.2.2
DESCRIPTION¶
The MongoDB::MongoClient takes an optional "monitoring_callback" attribute, which can be used to monitor events that occur during the operation of the driver.
The API is very simple: given a code reference, a hashref for each event is passed to the code reference. Here is a simple example that just accumulates events in an array:
our @events; my $cb = sub { push @events, $_[0] }; MongoDB->connect( $uri, { monitoring_callback => $cb } );
EVENT TYPES¶
Every event is a hash reference, with a "type" field indicating the type, e.g. "command_started". Each type is described below.
Command Monitoring¶
These events are fired for commands directly to the wire and the response.
command_started
This event is sent just before a command is put one the wire. It will be followed by either a "command_succeeded" or "command_failed" event.
Fields:
- type: "command_started"
- databaseName: the name of the database to which the command applies
- commandName: the name of the command being executed; for legacy operations that don't use commands, the driver will convert them to appear as if they are in command form.
- command: a hash reference representing the full command to be sent
- requestId: the request identifier sent to the server
- connectionId: address and port of the destination server
command_succeeded
This event is sent just after a command reply is received, but only if the database reply document contains a non-false "ok" field. NOTE: write errors will have "ok:1" even though they have write errors; for writes, success indicates that the write attempt was valid, not that the write succeeded.
Fields:
- type: "command_succeeded"
- commandName: the name of the command being executed
- durationSecs: the elapsed time in seconds since the "command_started" event.
- reply: a hash reference representing the full database reply
- requestId: the request identifier sent to the server
- connectionId: address and port of the destination server
command_failed
This event is sent just after a command reply is received, but only if the database reply document contains a false "ok" field or if an exception occurred during send or receive operations.
Fields:
- type: "command_failed"
- commandName: the name of the command being executed
- durationSecs: the elapsed time in seconds since the "command_started" event.
- failure: a string with a error message about the failure
- eval_error: if an exception occurs, this contains the value of $@ when the exception was caught
- reply: a hash reference representing the full database reply or an empty hashref if the failure is due to an exception
- requestId: the request identifier sent to the server
- connectionId: address and port of the destination server
Server Discovery and Monitoring¶
These events are fired when servers and topology are amended.
server_opening_event
This event is sent when a new server is added to the topology.
Fields:
- type: "server_opening_event"
- topologyId: The topology refaddr
- address: address of the server
server_closed_event
This event is sent when a server is removed from the topology.
Fields:
- type: "server_closed_event"
- topologyId: The topology refaddr
- address: address of the server
server_description_changed_event
This event is sent when the server description changes, but does not include changes to the RTT.
Fields:
- type: "server_description_changed_event"
- address: address of the server
- topologyId: The topology refaddr
- previousDescription: Server Description before the change
- newDescription: Server Description after the change
topology_opening_event
This event is sent when the topology is created.
Fields:
- type: "topology_opening_event"
- topologyId: The topology refaddr
topology_closed_event
This event is sent when the topology is closed.
Fields:
- type: "topology_closed_event"
- topologyId: The topology refaddr
topology_description_changed_event
This event is sent when the topology description changes.
Fields:
- type: "topology_description_changed_event"
- topologyId: The topology refaddr
- previousDescription: Topology Description before the change
- newDescription: Topology Description after the change
server_heartbeat_started_event
This event is sent before the ismaster command is sent to the server.
Fields:
- type: "server_heartbeat_started_event"
- connectionId: address of the link to connect to
server_heartbeat_succeeded_event
This event is sent after the reply from the ismaster command arrives from a successful reply.
Fields:
- type: "server_heartbeat_succeeded_event"
- duration: time it took to send and receive a reply
- reply: the ismaster command reply
- connectionId: address of the server
server_heartbeat_failed_event
This event is sent if there is a failure from the ismaster command, which returns an error string of some sort.
Fields:
- type: "server_heartbeat_failed_event"
- duration: time it took to send and receive a reply
- failure: Returns an error string of the failure
- connectionId: address of the server
REDACTION¶
Certain commands are considered sensitive. When any of the following commands are seen in monitoring, the command body and database reply body are replaced with an empty document:
- authenticate
- saslStart
- saslContinue
- getnonce
- createUser
- updateUser
- copydbgetnonce
- copydbsaslstart
AUTHORS¶
- David Golden <david@mongodb.com>
- Rassi <rassi@mongodb.com>
- Mike Friedman <friedo@friedo.com>
- Kristina Chodorow <k.chodorow@gmail.com>
- Florian Ragwitz <rafl@debian.org>
COPYRIGHT AND LICENSE¶
This software is Copyright (c) 2020 by MongoDB, Inc.
This is free software, licensed under:
The Apache License, Version 2.0, January 2004
2022-06-30 | perl v5.34.0 |