- Alerts and Monitoring >
- Alerts >
- Alert Conditions
Alert Conditions¶
On this page
Overview¶
For each group or global alert you create, you must set a target and a condition or metric. The target points to what changed: the Ops Manager component. If your condition becomes true or a metric meets your set threshold, Ops Manager triggers an alert.
To set a condition:
- Select a Target from the list.
- Select a condition in the condition/metric list.
Ops Manager triggers an alert when the condition is true
on the specified target
MongoDB instance.
To set a metric:
- Select on a Target from the list.
- Select on a metric in the condition/metric list.
- Select if this metric should be Below or Above the threshold.
- Type a threshold value. All thresholds are numbers.
- Select the unit of measure for the threshold.
Ops Manager triggers an alert when the metric threshold is met on the specified target MongoDB instance.
Host Alerts¶
When setting an alert for a host, select the host type that applies to this alert and the condition that triggers this alert.
Host Types¶
For host type, set an alert for all or one of the following types of MongoDB processes:
Set Host Type to: | Alert Includes |
---|---|
Any type | All the types described in this table. |
Standalone | Any mongod instance that is neither part of a replica set or sharded cluster nor used as a config server. |
Primary | All replica set primaries. |
Secondary | All replica set secondaries. |
Mongos | All mongos instances. |
Conf | All mongod instances used as config servers. |
Host Alert Conditions¶
Change in Host Status¶
You can set an alert for when MongoDB instance changes. Host status conditions include:
Condition | Alert Trigger |
---|---|
Host added | Ops Manager starts monitoring or managing a mongod or mongos process for the first time. |
Host removed | Ops Manager stops monitoring or managing a mongod or mongos process for the first time. |
Host added to replica set | The specified type of mongod process is added to a replica set. |
Host removed from replica set | The specified type of mongod process is removed from a replica set. |
Host has restarted | Ops Manager detects that a host has been restarted. |
Host is recovering | A secondary enters the RECOVERING state. To
learn more about the RECOVERING state, see
Replica Set Member States. |
Host does not have the latest version | The revision of MongoDB running on a host is two or more revisions behind the current stable release of MongoDB. Example If the current stable release is MongoDB 3.2.9, a host running MongoDB 3.2.8 would not trigger an alert but a host running MongoDB version 3.2.7 would trigger an alert. For more information on MongoDB version numbering, see MongoDB Version Numbers in the MongoDB manual. |
Host’s SSL certificate will expire within 30 days | The SSL certificate for a MongoDB instance is 30 days from expiration. Ops Manager resends the alert every 24 hours until resolved or acknowledged. If you do not resolve or acknowledge the alert and the certificate expires, Ops Manager continues to send the alert. If the certificate expires, the Monitoring Agent can no longer connect to the MongoDB instance. |
Host is down | Ops Manager does not receive a ping from a host for more than 4 minutes. Under normal operation, the Monitoring Agent connects to each monitored host about once per minute. Ops Manager waits 4 minutes before triggering the alert to minimize false positives, as would occur during a host restart. If the host continues to be unreachable, the Monitoring Agent eventually reduces ping frequency to every 5 minutes for a mongod and every 20 minutes for a mongos. If a mongod or mongos again becomes reachable, Ops Manager recognizes the process within 5 minutes. If Ops Manager Automation does not manage a mongos process and that process remains unreachable for 30 days, Ops Manager removes the process from the Deployment tab. However, if you restart the mongos process, Ops Manager detects it. To resolve this alert, see Host Down. |
---|
Asserts¶
You may set alerts for how many assertion errors per second the instance has created.
How It Is Measured
MongoDB reports on opscounters using the asserts
document that the
serverStatus command returns.
Assert metrics include:
Metric | Alert Trigger |
---|---|
Asserts: Regular is | The rate of regular asserts meets your specified threshold. |
Asserts: Warning is | The rate of warnings meets your specified threshold. |
Asserts: Msg is | The rate of message asserts meets your specified threshold. Message asserts are internal server errors. Stack traces are logged for these. |
Asserts: User is | The rate of asserts users create meets your specified threshold. |
Note
You can view these metrics directly. On the Metrics page for the host under MongoDB Metrics, click Asserts.
Average Execution Time¶
Applies to MongoDB 3.4 or later only
The following metrics apply only to deployments running MongoDB version 3.4 or later.
You may set alerts for how long operations take to complete. Execution time metrics include:
Metric | Alert Trigger |
---|---|
Average Execution Time: Commands is | The average execution time for command operations meets your specified threshold. |
Average Execution Time: Reads is | The average execution time for read operations meets your specified threshold. |
Average Execution Time: Writes is | The average execution time for write operations meets your specified threshold. |
Document Metrics¶
You may set alerts for how many MongoDB documents are processed per second. Document processing metrics include:
Metric | Alert Trigger |
---|---|
Document Metrics: Deleted is | Average rate per second of documents deleted meets your specified threshold. |
Document Metrics: Inserted is | Average rate per second of documents inserted meets your specified threshold. |
Document Metrics: Returned is | Average rate per second of documents returned meets your specified threshold. |
Document Metrics: Update is | Average rate per second of documents updated meets your specified threshold. |
Note
You can view these metrics directly. On the Metrics page for the host under MongoDB Metrics, click Document Metrics.
Query Executor¶
You may set alerts for how fast MongoDB scans items during queries and how many items are scanned compared to documents returned. Query execution time metrics include:
How It Is Measured
MongoDB measures query performance based on the explain command.
Condition | Alert Trigger |
---|---|
Query Executor: Scanned is | The average rate per second to scan index items during queries and query-plan evaluations meets your specified threshold. |
Query Executor: Scanned Objects is | The average rate per second to scan documents meets your specified threshold. |
Query Executor: Scanned / Returned is | The ratio of index items scanned to documents returned meets the specified threshold. |
Query Executor: Scanned Objects / Returned is | The ratio of documents scanned to documents returned meets the specified threshold. |
Note
You can view these metrics directly. On the Metrics page for the host under MongoDB Metrics, click Query Executor (Scanned) or Query Targeting (Scanned / Returned).
Opcounter¶
You may set alerts for how many database operations are completed per second.
How It Is Measured
MongoDB reports on opscounters using the opscounters
document that the
serverStatus command returns.
Operation metrics include:
Condition | Alert Trigger |
---|---|
Opcounter: Cmd is | The average rate of commands performed per second meets your specified threshold. |
Opcounter: Delete is | The average rate of deletes performed per second meets your specified threshold. |
Opcounter: Getmores is | The average rate of getMores performed per second meets your specified threshold. On a primary, this number can be high even if the query count is low. The secondaries “getMore” from the primary as part of replication. |
Opcounter: Insert is | The average rate of inserts performed per second meets your specified threshold. |
Opcounter: Query is | The average rate of queries performed per second meets your specified threshold. |
Opcounter: Update is | The average rate of updates performed per second meets your specified threshold. |
Note
You can view these metrics directly. On the Metrics page for the host under MongoDB Metrics, click Opscounters.
Opcounter - Repl¶
You may set alerts for how many database operations per second are replicated to a MongoDB secondaries.
How It Is Measured
MongoDB reports on opscounters using the opscountersRepl
document of
that the serverStatus command
returns.
Replication operation metrics include:
Metric | Alert Trigger |
---|---|
Opcounter: Repl Cmd is | The average rate of replicated commands applied per second meets your threshold. |
Opcounter: Repl Delete is | The average rate of replicated deletes applied per second meets your threshold. |
Opcounter: Repl Insert is | The average rate of replicated inserts applied per second meets your threshold. |
Opcounter: Repl Update is | The average rate of replicated updates applied per second meets your threshold. |
Note
You can view these metrics directly. On the Metrics page for the host under MongoDB Metrics, click Opcounters - Repl.
Memory¶
You may set alerts for how much memory a MongoDB instance uses. Set this threshold in bits, kilobits, megabits, gigabits, bytes, kilobytes, megabytes, gigabytes, terabytes or petabytes.
How It Is Measured
MongoDB reports on memory using the mem
document that the
serverStatus command returns.
Memory metrics include:
Metric | Alert Trigger |
---|---|
Memory: Resident is | The resident memory size for the mongod process meets your specified threshold. Over time on a dedicated database host, the resident memory may approach the amount of RAM on the host. |
Memory: Virtual is | The virtual memory size for the mongod process meets your specified threshold. You can use this alert to flag excessive memory outside of memory mapping. |
Memory: Mapped is | The mapped memory size for the mongod process meets your specified threshold. As MongoDB memory-maps all the data files, the size of mapped memory should approach total database size. |
Memory: Computed is | The virtual memory size for the mongod process that is not accounted for by memory-mapping meets your specified threshold. If this number is very high (multiple gigabytes), it indicates that excessive memory is being used outside of memory mapping. |
Note
You can view these metrics directly. On the Metrics page for the host under MongoDB Metrics, click Memory. For an explanation of the chart lines, click the i icon on each chart.
WiredTiger Cache¶
You may set alerts for how much WiredTiger cache a MongoDB instance uses. Set this threshold in bits, kilobits, megabits, gigabits, bytes, kilobytes, megabytes, gigabytes, terabytes or petabytes.
How It Is Measured
MongoDB reports on memory using the cache
document that the
serverStatus command returns.
WiredTiger cache metrics include:
Metric | Alert Trigger |
---|---|
Cache: Bytes Read Into Cache is | The average rate of bytes per second read into WiredTiger’s cache meets your specified threshold. |
Cache: Bytes Written From Cache is | The average rate of bytes per second written from WiredTiger’s cache meets your specified threshold. |
Cache: Dirty Bytes is | The number of tracked dirty bytes currently in the WiredTiger cache. |
Cache: Used Bytes is | The number of bytes currently in the WiredTiger cache. |
Note
You can view these metrics directly. On the Metrics page for the host under MongoDB Metrics, click one or more of the following:
- Cache Activity
- Cache Usage
For an explanation of the chart lines, click the i icon on each chart.
B-tree¶
Applies to MongoDB 2.2 to 2.6 only
These metrics only triggers alerts on deployments running MongoDB versions 2.2 through 2.6.
You may set alerts for how many btree operations on the MongoDB instance are completed per second. B-Tree metrics include:
Metric | Alert Trigger |
---|---|
B-tree: accesses is | The number of accesses to B-tree indexes meets your specified threshold. |
B-tree: hits is | The number of times a B-tree page was in memory meets your specified threshold. |
B-tree: misses is | The number of times a B-tree page was not in memory meets your specified threshold. |
B-tree: miss ratio is | The ratio of misses to hits meets your specified threshold. |
Effective Lock %¶
Applies to MongoDB 2.2 to 2.6 only
This metric only triggers alerts on deployments running MongoDB versions 2.2 through 2.6.
You may set alerts for what percentage of time the MongoDB instance is term:write locked <write lock>. Effective Lock percentage metrics include:
Metric | Alert Trigger |
---|---|
Effective Lock % is | If the percent of total time the instance is write locked meets your specified threshold. |
Background Flush Average¶
Applies to databases running MMAPv1 only
This metric only triggers alerts on deployments running MMAPv1 storage engines for their MongoDB databases.
You may set an alert for how long in milliseconds the average flush on the MongoDB instance take to complete. A flush is the writing of data to disk from memory.
How It Is Measured
MongoDB reports on average background flush time using the
backgroundFlushing.average_ms
value that the serverStatus command returns.
Background flush average metrics include:
Metric | Alert Trigger |
---|---|
Background Flush Average is | The average time for background flushes meets your specified threshold. |
See also
For details on how flushing works, see server-status-backgroundflushing in the MongoDB manual.
Connections¶
You may set alerts for the active connections to the MongoDB instance.
How It Is Measured
MongoDB reports on memory using the connections
document that the
serverStatus command returns.
Connection metrics include:
Metric | Alert Trigger |
---|---|
Connections is | The number of active host connections meets your specified threshold. |
Connections % of configured limit is | The percentage of active host connections to the total number of possible connections meets your specified threshold. |
Note
You can view these metrics directly. On the Metrics page for the host under MongoDB Metrics, click Connections. For an explanation of the chart lines, click the i icon on each chart.
Queues¶
You may set alerts for the operations waiting on locks.
How It Is Measured
MongoDB reports on memory using the globalLock.currentQueue
document
that the serverStatus command
returns.
Queue metrics include:
Metric | Alert Trigger |
---|---|
Queues: Total is | The number of operations waiting on a lock of any type meets your specified threshold. |
Queues: Readers is | The number of reader operations waiting on a lock of any type meets your specified threshold. |
Queues: Writers is | The number of writer operations waiting on a lock of any type meets your specified threshold. |
Note
You can view these metrics directly. On the Metrics page for the host under MongoDB Metrics, click Queues. For an explanation of the chart lines, click the i icon on each chart.
Page Faults¶
Applies to MongoDB 2.2 to 2.6 only
The Accesses Not In Memory: Total is and Page Fault Exceptions Thrown: Total is metrics only trigger alerts on deployments running MongoDB versions 2.2 through 2.6.
You may set alerts for page faults.
How It Is Measured
MongoDB reports on memory using the extra_info.page_faults
document
that the serverStatus command
returns.
MongoDB 2.2 through 2.6 reported on the Accesses Not In Memory:
Total is and Page Fault Exceptions Thrown: Total is metrics
using the recordStats
document that the serverStatus command returned.
Page Fault metrics include:
Metric | Alert Trigger |
---|---|
Accesses Not In Memory: Total is | The rate of disk accesses meets your specified threshold. MongoDB must
access data on disk if your working set does not fit in memory.
This metric is found on the host’s Record Stats chart. |
Page Fault Exceptions Thrown: Total is | The rate of page fault exceptions thrown meets your specified threshold.
This metric is found on the host’s Record Stats chart. |
Page Faults is | The rate of page faults (whether or not an exception is thrown) meets
your specified threshold. This metric is found on the host’s Page
Faults chart. |
Note
You can view these metrics directly. On the Metrics page for the host under MongoDB Metrics, click Page Faults. For an explanation of the chart lines, click the i icon on each chart.
Cursors¶
You may set alerts for the number of open and timed-out cursors for a MongoDB process.
How It Is Measured
MongoDB reports on memory using the metrics.cursor
document that the
serverStatus command returns.
Cursor metrics include:
Metric | Alert Trigger |
---|---|
Cursors: Client Cursors Size is | The amount of memory the host uses to maintain cursors meets your specified threshold. |
Cursors: Open is | The number of cursors the host is maintaining for clients meets the specified threshold. |
Cursors: Timed Out is | The number of timed-out cursors the host is maintaining for clients meets your specified threshold. |
Note
You can view these metrics directly. On the Metrics page for the host under MongoDB Metrics, click Page Faults. For an explanation of the chart lines, click the i icon on each chart.
Network¶
You may set alerts for the network throughput for a MongoDB process.
How It Is Measured
MongoDB reports on memory using the network
document that the
serverStatus command returns.
Network metrics include:
Metric | Alert Trigger |
---|---|
Network: Bytes In is | The number of bytes sent to the database host meets your specified threshold. |
Network: Bytes Out is | The number of bytes sent from the database host meets your specified threshold. |
Network: Num Requests is | The number of requests sent to the database host meets your specified threshold. |
Note
You can view these metrics directly. On the Metrics page for the host under MongoDB Metrics, click Network. For an explanation of the chart lines, click the i icon on each chart.
Replication Oplog¶
You may set alerts for the replication oplogs for a MongoDB process.
How It Is Measured
MongoDB reports on the Replication Oplog using the oplog
document that the serverStatus
command returns combined with results from
rs.status() and
rs.conf().
Replication oplog metrics include:
Metric | Alert Trigger |
---|---|
Replication Headroom is | The difference between the primary’s replication oplog window
and the secondary’s replication lag meets your specified
threshold. A secondary can go into RECOVERING if this value goes to
0 . |
Replica Time is | The approximate amount of time in milliseconds available in the primary’s replication oplog meets your specified threshold. |
Oplog Data Per Hour is | The average rate of gigabytes of oplog the primary generates per hour meets your specified threshold. |
Replication Lag is | The approximate number of seconds the secondary is behind the primary in write application. Only accurate if the lag is larger than 1-2 seconds, as the precision of this statistic is limited. |
Note
You can view these metrics directly. On the Metrics page for the host under MongoDB Metrics, click one or more of the following:
- Replication Oplog Window
- Replication Lag
- Replication Headroom
- Oplog GB/Hour
For an explanation of the chart lines, click the i icon on each chart.
Operations Scan and Order¶
You may set alerts for the scan and order operations for a MongoDB process.
How It Is Measured
MongoDB reports on the Replication Oplog using the
metrics.operation.scanAndOrder
document that the
serverStatus
command returns.
Operations metrics include:
Metric | Alert Trigger |
---|---|
Operations: Scan and Order is | The average rate per second over your specified threshold of queries that return sorted results that cannot perform the sort operation using an index. |
DB Storage¶
You may set alerts for the amount of data storage used. Database storage metrics include:
Metric | Alert Trigger |
---|---|
DB Storage is | The amount of on-disk storage space used by extents meets your specified threshold. |
DB Data Size is | The actual data size in the database meets your specified threshold. |
Note
You can view these metrics directly. On the Metrics page for the host under MongoDB Metrics, click DB Storage. For an explanation of the chart lines, click the i icon on each chart.
Journaling¶
You may set alerts for the amount of journaling storage used. Journaling metrics include:
Metric | Alert Trigger |
---|---|
Journaling Commits in Write Lock is | The rate of commits that occurred while the database was in write lock meets your specified threshold. |
Journaling MB is | The average amount of data in megabytes Ops Manager writes to the recovery log per second meets your specified threshold. |
Journaling Write Data Files MB is | The average rate of data in megabytes Ops Manager writes to the databases datafiles per second meets your specified threshold. As these writes are already journaled, they can occur lazily, and thus the number indicated here may be lower than the amount physically written to disk. |
Note
You can view these metrics directly. On the Metrics page for the host under MongoDB Metrics, click DB Storage. For an explanation of the chart lines, click the i icon on each chart.
WiredTiger Storage Engine¶
You may set alerts for WiredTiger tickets.
How It Is Measured
MongoDB reports on WiredTiger using the wiredTiger.cache
and wiredTiger.concurrentTransactions
documents that the
serverStatus command returns.
WiredTiger storage engine conditions include:
Metric | Alert Trigger |
---|---|
Tickets Available: Reads is | The number of read tickets available to the WiredTiger storage engine meet your specified threshold. |
Tickets Available: Writes is | The number of write tickets available to the WiredTiger storage engine meet your specified threshold. |
Note
You can view these metrics directly. On the Metrics page for the host under MongoDB Metrics, click one or more of the following:
- Tickets Available
- Cache Activity
- Cache Usage
For an explanation of the chart lines, click the i icon on each chart.
System and Disk Alerts¶
You may set alerts for compute and disk utilization. System resource conditions include:
Metric | Alert Trigger |
---|---|
System: CPU (Steal) % is | The percentage of time the CPU is in a state of “involuntary wait”. This is time for which the kernel cannot otherwise account. |
System: CPU (User) % is | The normalized CPU usage of the MongoDB process, which is scaled to a range of 0-100%. |
Disk space % used on Data Partition is | The percentage of disk space used on any partition that contains the MongoDB collection data. |
Disk space % used on Index Partition is | The percentage of disk space used on any partition that contains the MongoDB index data. |
Disk space % used on Journal Partition is | The percentage of disk space used on the partition that contains the MongoDB journal, if journaling is enabled. |
Disk I/O % utilization on Data Partition is | The percentage of time during which requests are being issued to any partition that contains the MongoDB collection data. This includes requests from any process, not just MongoDB processes. |
Disk I/O % utilization on Index Partition is | The percentage of time during which requests are being issued to any partition that contains the MongoDB index data. This includes requests from any process, not just MongoDB processes. |
Disk I/O % utilization on Journal Partition is | The percentage of time during which requests are being issued to the partition that contains the MongoDB journal, if journaling is enabled. This includes requests from any process, not just MongoDB processes. |
Note
You can view these metrics directly. On the Metrics page for the host under Hardware Metrics, click one or more of the following:
- System CPU
- Disk Space Used - Xvdf
- Disk IOPS
Replica Set Alerts¶
You may set alerts about the status of the primary and the number of healthy members in a replica set. Replica set conditions include:
Condition | Alert Trigger |
---|---|
Replica set elected a new primary | A set elects a new primary. Each time Ops Manager receives a ping, it inspects the output of the replica set’s rs.status() method for the status of each replica set member. From this output, Ops Manager determines which replica set member is the primary. If the primary found in the ping data is different than the current primary known to Ops Manager, this alert triggers. Receiving this alert does not always mean that the set elected a new primary. This alert may also trigger when the same primary is re- elected. This can happen when Ops Manager processes a ping in the midst of an election. |
Replica set has no primary | A replica set does not have a primary. Specifically, when none
of the members of a replica set have a status of If the Monitoring Agent collects data during an election for primary, this alert might send a false positive. To prevent such false positives, set the alert configuration’s after waiting interval (in the configuration’s Send to section). For resolutions, see No Primary. |
Replica set metrics include:
Metric | Alert Trigger |
---|---|
Number of healthy members is | A replica set has fewer healthy members than your specified threshold. |
Number of unhealthy members is | A replica set has more unhealthy members than your specified threshold. |
Sharded Cluster Alerts¶
You may set an alert for a mongos
missing from a sharded cluster.
Sharded cluster conditions include:
Condition | Alert Trigger |
---|---|
Cluster is missing an active mongos | Ops Manager cannot reach a mongos for the cluster. |
Agent Alerts¶
You may set alerts for agent status or versioning. Agent conditions include:
Condition | Alert Trigger |
---|---|
Automation Agent is down | No Automation Agent is detected for at least 1 minute. Under normal operation, the Automation Agent sends a ping to Ops Manager roughly once every 10 seconds. If Ops Manager does not receive a ping for at least 1 minute, this alert triggers. However, this alert never triggers for a group that has no managed hosts or managed agents configured. |
Monitoring Agent is down | No Monitoring Agent is detected for at least 7 minutes. Under normal operation, the Monitoring Agent sends a ping to Ops Manager roughly once per minute. If Ops Manager does not receive a ping for at least 7 minutes, this alert triggers. However, this alert never triggers for a group that has no hosts configured. Important When the Monitoring Agent is down, Ops Manager triggers no other alerts for any host. For example: if a host is down there is no Monitoring Agent to send data to Ops Manager that could trigger new alerts. |
Monitoring Agent does not have the latest version | The Monitoring Agent is not running the latest version of the software. |
Backup Agent is down | The Backup Agent for a group with at least one active replica set or cluster is down for more than 1 hour. To resolve this alert:
|
Backup Agent does not have the latest version | The Backup Agent is not running the latest version of the software. |
Backup Agent has too many conf call failures | The cluster topology known to monitoring does not match the backup configuration from conf calls the Backup Agent makes. The number of attempts meets the threshold you specified in
Note Global alert only |
---|
Backup Alerts¶
You may set alerts for backup oplog, resync and inconsistencies. Backup conditions include:
Condition | Alert Trigger |
---|---|
Backup oplog is behind | The most recent oplog data received by Ops Manager is more than 75 minutes old. To resolve this alert, see Backup Oplog is Behind. |
Backup requires a resync | The replication process for a backup falls too far behind the oplog to catch up. This occurs when the host overwrites oplog entries that backup has not yet replicated. When this happens, you must resync backup, as described in the procedure Resync a Backup. Also, check the corresponding Backup Agent log. If you see a “Failed Common Points” test, one of the following may have happened.
|
Inconsistent backup configuration has been detected | Ops Manager has detected that the configuration for a backup does not match the configuration of the MongoDB deployment it backs up. To resolve this alert, see Inconsistent Backup Configuration. |
Inconsistent cluster snapshot count is… | Ops Manager fails a consecutive number of times to successfully take a cluster snapshot. This alert is triggered when the number of attempts meets your specified threshold. The alert text may contain the reason for the problem. Common problems include:
|
Backup could not be assigned to a backup daemon | A backup job fails to bind to a Backup Daemon. Example Reasons that a job might fail to bind include, but are not limited to:
In both cases, resolve the issue and then restart the initial sync of the backup. As an alternative, you can manually bind jobs to daemons through the Admin interface. See Jobs Page for more information. Note Global alert only |
---|---|
Backup has reached a high number of retries | Sends an alert if the same task fails repeatedly. This could happen, for example, during maintenance. Check the corresponding job log for an error message explaining the problem. Contact MongoDB Support if you need help interpreting the error message. Note Global alert only |
Backup is in an unexpected state | Something unexpected happened and the Backup state for the replica
set is In case of a Note Global alert only |
Replica set has a late snapshot | A snapshot has failed to complete before the next snapshot is scheduled to begin. Check the job log in the Ops Manager Admin interface for any errors. Note Global alert only |
Sync slice transfer has not progressed in… | An initial sync has started but then subsequently stalled. Issues that can cause this, include, but are not limited to:
Note Global alert only |
Backup job is busy for… | One backup job has been working for more hours within a 24-hour period than your specified threshold. Different backup jobs share Backup Daemons or snapshot stores. Backup job execution time can vary. Long running backup jobs can cause the remaining jobs to fall behind or fail. Set this metric to how long you expect backups should take to complete in your deployment. You should check the corresponding job log for error messages. Contact MongoDB Support if you need help interpreting the error message. Note Global alert only |
User Alerts¶
You may set alerts for user addition, removal and role changes. User conditions include:
Condition | Alert Trigger |
---|---|
User joined the group | A new user joins the group. |
User left the group | A user leaves the group. |
User had their role changed | A user’s roles have been changed. |
Group Alerts¶
You may set alerts for user approval and authentication configuration. Group conditions include:
Condition | Alert Trigger |
---|---|
Users do not have two-factor authentication enabled | The group has users who have not set up two-factor authentication. |
Server Pool Alert¶
You may set alerts for server pool allocation. Server pool allocation conditions include:
Condition | Alert Trigger |
---|---|
Not all servers allocated from server pool request | A server pool request cannot be fulfilled by the available servers in the pool. |