The following article will walk you through setting up RabbitMQ monitoring. LogicMonitor is fully equipped to gather both node performance and queue statistics of the RabbitMQ server.
To get started, you will need to set the following properties on your RabbitMQ device or group in LogicMonitor:
- rabbitmq.user=[your RabbitMQ username]
rabbitmq.pass=[your RabbitMQ password] rabbitmq.port=15672 rabbitmq.apiurl=[your RabbitMQ API URL] - system.categories includes “RabbitMQ”
The first four properties listed above can be defined using the following commands:
- def rabbitPort = hostProps.get(“rabbitmq.port”);
- def rabbitUser = hostProps.get(“rabbitmq.user”);
- def rabbitPass = hostProps.get(“rabbitmq.pass”);
- def rabbitAddr = hostProps.get(“rabbitmq.apiurl”);
Next, the updated user that was added above needs to have monitoring priveleges enabled. To do this, enter the following command line in your RabbitMQ terminal:
sudo rabbitmqctl set_user_tags
If running RabbitMQ in AWS EC2, you will also need to add the following management plugin listed on RabbitMQ’s support site, here. After completing these steps from RabbitMQ, enter the following command to enable the management plugin:
rabbitmq-plugins enable rabbitmq_management
Finally, you will need to make sure that the inbound/outbound rules for Port 15672 are configured to allow Collector access. Please note that, by default, the RabbitMQ port is 5672 but its management is performed via 15672. As such, the latter is required for Collector access.
Kafka is comprehensively monitored by LogicMonitor using JMX. This means that you will need to set up JMX (similar to other Java applications).
1. Before stating Kafka, export the environment variable JMX_PORT to configure Kafka to start with JMX enabled on the specified port.
For example, to enable JMX on port 9999, edit your Kafka startup script to include the line: export JMX_PORT=9999
2. Enable LogicMonitor to discover and monitor Kafka by setting the JMX port that Kafka is listening on as a property at the device level or higher (so that devices will inherit the property).
The Kafka port is set using the property: kafka.jmxport
3. On all the servers that run Kafka, set the category KafkaBroker so that the DataSources associate with the correct resources.
ActiveDiscovery should then find all the topics and comprehensive Kafka monitoring should start.
LogicMonitor offers Oracle MySQL monitoring, providing visibility and analytics into database performance. It automatically detects and monitors key metrics, including query throughput, connections, replication status, and resource utilization; and enables proactive management and alerting to maintain optimal performance and availability of MySQL environments.
Oracle MySQL Version 8 is a major update that introduces significant enhancements in performance, security, and usability. It includes features like window functions, common table expressions (CTEs), JSON support, atomic DDLs, improved InnoDB storage engine, and advanced role-based access control, solidifying its position as a robust choice for enterprise database management solutions.
In the latest release of Oracle MySQL the jdbc connection string has been exposed as a resource property. This allows for connections to databases that are different from “out of the box” configurations. All of the monitoring is now handled with scripted methods.
Compatibility
The MySQL modules have been tested with version 5.7–8.0.3x of Oracle MySQL and MariaDB version 11.
Setup Requirements
Note: LogicMonitor assumes that any host with a server on port 3306 that responds to a connection request with a MySQL error is running MySQL.
LogicMonitor requires a user and password, and this user needs the correct permissions to connect to the databases.
If you have MySQL running on multiple ports, add the ports in a comma separated list to the server resource as a property.
After the appropriate credentials are provided, the MySQL datasources are automatically applied where applicable.
Note: The replica monitoring will not fully work if you have not created a LogicMonitor database in your MySQL server.
Credentials
To monitor MySQL, the LogicMonitor collector must connect to a database. This requires the following:
- MySQL accepts network connections
Note: By default LogicMonitor attempts connections on port 3306, but this can be changed with resource properties.
- The collector uses a valid username and password that can connect to the database. These are defined by the following properties:
jdbc.mysql.userjdbc.mysql.pass
User Rights Needed for Monitoring
The following rights are necessary for each DataSource:
| Function | Rights Needed |
| Global statistics | USAGE |
| Table level monitoring – Space and Fragmentation of large tables. | SELECT on the relevant database |
| To monitor a replication client | REPLICATION CLIENT |
| To monitor a Source server in a replication scenario | REPLICATION CLIENT, INSERT and DELETE privileges for the heartbeat table in the logicmonitor datasource. ReplicationLag- requires SELECT. |
Add Resources into Monitoring
Add your MySQL Server hosts into monitoring. For more information on adding resources into monitoring, see Adding Devices.
Running MySQL Replica Monitoring
The Oracle MySQL ReplicaStatus datasource expects a specific database and table to exist. Create a monitoring user that has access only to that database:
- Perform the following operations as the root user on your Mysql source database:
create database logicmonitor;
use logicmonitor;
CREATE TABLE heartbeat (
id int NOT NULL PRIMARY KEY,
ts datetime NOT NULL
);
INSERT INTO heartbeat(id,ts) VALUES(1,now());
grant select,insert,delete on logicmonitor.* to 'COLLECTORUSER'@'COLLECTORHOST' \
identified by 'COLLECTORPASSWORD';
grant replication client on *.* to 'COLLECTORUSER'@'COLLECTORHOST' \
identified by 'COLLECTORPASSWORD';
flush privileges;- Set the authentication properties as the following:
jdbc.mysql.user=COLLECTORUSER
jdbc.mysql.pass=COLLECTORPASSWORDReplica Status
Oracle_MySQL_ReplicaStatus measures the difference between the replica SQL thread and the replica I/O thread (what the replica has read from the Source, and what it has applied). This indicates replica lag in the absence of network issues. If the replica cannot pull new data from the source, it reports it has applied all transactions and the lag is zero.
Note: This is not the same as being up to date with the actual Source.
This DataSource also checks that the Replica IO and SQL processes are running correctly.
In situations where the Source server does not update the Replica server, the field heartBeatTimeDifference reports the delay. Since the heartbeat is only updated on a collection cycle it only updates every minute.
Assign Properties to MySQL Server Resources
LogicMonitor attempts to automatically discover all properties needed for MySQL Server configurations. However, there may be use cases where you must manually enter properties or override auto-discovered properties. For more information on assigning properties, see Resource and Instance Properties.
The following properties can be set on the Oracle MySQL Server resource within LogicMonitor:
LogicMonitor:
| Property | Description | Required? |
| jdbc.mysql.port | The ports used my Oracle MySQL Enter a comma delimited string if there are MySQL instances on multiple ports (for example, 3306,3307,3309). Default port of 3306 is always checked. | No |
| jdbc.mysql.user jdbc.mysql.pass | MySQL Server username and passwordThis cannot be a Windows user account.This account must have the minimum SQL Server permissions. For more information, see Provide Credentials. | Yes |
| mysql.nossl | Adds the following to the connection string when true:?allowPublicKeyRetrieval=true&useSSL=falseDoes nothing if blank or set to false.Use this property when the SSL keys are not configured on the MySQL server. This is intended for development environments. | No |
| mysql.url_driver_properties | When configuring JDBC connections for MySQL, there are various driver properties that can be adjusted to optimize the connection and its behavior. These properties include settings for connection stability, like auto-reconnect options. Security features, such as SSL encryption, can also be toggled. The driver properties allows adjustments for character encoding and timezone settings to ensure data consistency and correct interpretation across different environments. In addition, properties related to performance, like query fetch size and connection timeouts, can be fine-tuned. Note: LogicMonitor does not lower security settings on connections. You must initiate this action. For example, mysql.driver_properties = ?allowPublicKeyRetrieval=true&useSSL=false adds the following string to the connection string for this device:?allowPublicKeyRetrieval=true&useSSL=false | No |
| (auto).mysql.port.url | For many configurations, this is set using the property source in auto-configuration. LogicMonitor does not control all aspects of the mysql connection manual entries. Manual configurations always override automatic configurations. For example, the following is a connection string for the MySQL server at the port: mysql.3306.url=jdbc:mysql://10.52.130.164:3306?allowPublicKeyRetrieval=true,useSSL=false | |
| mysql.exclude_databases | Use to exclude specific databases from monitoring. A comma delimited string of databases names. For example: mysql.exlcudedatabases = mysql,customers,products excludes these databases from monitoring. | No |
| mysql.remove_url | Set to True to delete any old mysql.port.url. Defaults to false and to be used sparingly. Only use when removing old MySQL servers. Removing MySQL connection strings deletes old instances and their history. | No |
| Mysql.sqltest | SQL Statement used by Oracle_MySQL_ConnectionStatus. The default SQL statement is SELECT CURRENT_DATE() as CurrentDate;Custom SQL statements must have the following: End with a semicolonCannot contain the words insert, update, or deleteCannot contain more than one semicolon | No |
Migration to Latest Modules
In December 2023, LogicMonitor’s MySQL Server package received significant updates to enhance performance and have a lower impact on Collector and server load. As a result of these updates, all previous DataSources are obsolete and have been replaced with new DataSources. The previous DataSources can co-exist with the new modules so in-place updates can work.
The following DataSources are deprecated:
Mysql-Mysql_Innodb-Mysql_SlaveMySql_ReplicaMysqlReplicationLagMySqlMaster
LogicModules in Package
LogicMonitor’s package for Oracle MySQL consists of the following LogicModules. For full coverage, ensure all of the following LogicModules are imported into your LogicMonitor platform.
platform.
| Display Name | Type | Description |
| addCategory_OracleMySQL | PropertySource | Identifies if the host is running MySQL server and adds a system category of ‘MySQL’. |
| MySQL Connection Status | DataSource | Checks the ability of the collector to connect to the MySQL instance. Also reports the round trip time for a select statement. Tries to determine the cause of the failure and report the error. Won’t create any alerts until the SQL server is collecting data to prevent un-configured servers from alerting. |
| MySQL Databases | DataSource | Monitors databases on a MySQL server for total size in rows and bytes. The row count is only an estimate. It executes the select statement: SELECT table_schema , sum(data_length + index_length) as dbSize, sum(table_rows) as dbRowcount FROM information_schema.tables WHERE table_schema not in (‘sys’,’information_schema’,’performance_schema’) GROUP BY table_schema; |
| MySQL InnoDB Statistics | DataSource | Monitors MySQL InnoDB performance, providing key metrics for optimizing database efficiency and stability. |
| MySQL Replica Status | DataSource | Executes “Show Replica status;” command and requires replication client privileges assigned to the monitoring user. Also need to have Select access to the logicmonitor.heartbeat table. |
| MySQL Source | DataSource | Updates timestamps of heartbeat table on the Source in a failover configuration. Must be set to 1 minute poll times. Requires LogicMonitor database to be installed. The purpose of this datasource is to show that the host is a Source in a failover configuration. It’s not supposed to show anything on the graph. |
| MySQL Status | DataSource | General statistics for Oracle MySQL or MariaDB servers. |
| MySQL Table Sizes | DataSource | Monitors the top ten tables by table size. |
When setting static datapoint thresholds on the various metrics tracked by this package’s DataSources, LogicMonitor follows the technology owner’s best practice KPI recommendations.
Recommendation: If necessary, adjust the predefined thresholds to meet the unique needs of your environment. For more information, see Tuning Static Thresholds for Datapoints.
ConnectionStatus DataSource
The Oracle_MySQL_ConnectionStatus DataSource is used to check connectivity from the collector to an MySQL database. By default, the DataSource attempts to connect to the MySQL database three times before alerting:
- First attempt fails: DataSource will wait three seconds and try to connect again.
- Second attempt fails: DataSource will wait 12 seconds and try to connect again.
- Third attempt fails: An alert is sent.
The number of tries, as well as the length of time between tries, can be set with device properties. Care must be taken to prevent the DataSource from hitting a timeout or exceeding the collection interval. The collection interval is 60 seconds timeout and it’s best to keep the retries withing the collection interval. The timeout for datasources defaults to 180 seconds, but it can be changed in the collector properties. Keep in mind these time constraints. If there is a slow unreliable connection the changing the collection interval to 3 minutes or more is recommended. On most servers the default is fine.
When a connection to the database is successful, the DataSource runs the select statement and reports the number of rows returned and the time for execution. This select statement can be overridden with a device property. Properties are in the form of mysql.propertyName or mysql.port.propertyName where port is the port number running MySQL. When mysql.port.propertyName is used, the property will be used for a specific MySQL instance running on a port. When there is no port specified, the DataSource will use the same property for each MySQL instance on the resource.
Properties
The following properties are optional, but can be leveraged for slower connections:
| Property Name | Description | Example | Default |
| mysql.sqltest or mysql.port.sqltest for specific port | SQL statement run each time the connection test is run. The jdbc.mysql.user must have access to this table for the statement to succeed. | SELECT user, FROM mysql.user; | SELECT CURRENT_DATE() as currentDate; |
| mysql.max_retries or mysql.port.max_retries | Number of retries before generating an alert. Setting this number too high may result in DataSource timeouts, and the alert will not be sent. The combination of max_retries and wait_time needs to be less than 180 seconds. | 5 | 3 |
| mysql.wait_time or mysql.port.wait_time | Wait time in seconds for the first try. Subsequent tries will be wait_time * retrycount. Setting this number too high will cause a collector timeout, as well as a possible missed alert. | 2 | 3 |
With LogicMonitor’s Oracle package, you can monitor a large number of Oracle operations including blocked session metrics, library cache performance, backup and recovery activities, and resource usage.
Oracle databases are monitored using Groovy with JDBC connections, through a user account with read-only permissions to statistics tables. If multiple instances are present, LogicMonitor will auto-discover them for clients with correctly configured systems (SSH for Linux or WMI for Windows access) and will automatically begin monitoring the new databases as they are found or created.
Compatibility
LogicMonitor’s Oracle package is verified to be compatible with Oracle version 12c through 21c. The package may work with earlier Oracle versions, however some datapoints may not be available.
Setup Requirements
The setup requirements are as follows:
- Import LogicModules
- Add devices into monitoring
- Set up Oracle user
Import LogicModules
From the LogicMonitor Exchange, install all Oracle LogicModules, which are listed in the LogicModules in Package section of this support article. If these LogicModules are already present, ensure you have the most recent version. For more information, see LM Exchange.
Add Devices Into Monitoring
Add your Oracle resources into monitoring. For more information on adding resources into monitoring, see Adding Devices.
Set Up Oracle User
The LogicMonitor Collector must provide the appropriate credentials in order to successfully access the Oracle resource. These credentials must belong to an Oracle user account with access to specific system tables. No user tables need to be exposed and the Oracle user account should be read only.
The process for setting up an Oracle user account for LogicMonitor monitoring purposes varies depending upon whether the Oracle database is a container or non-container database. Follow the instructions provided in the Determining Whether a Database Is a CDB section of the Oracle Database Administrator’s Guide to discover what type of Oracle database it is.
Note: The instructions provided in this section assume the reader has some knowledge of PL/SQL and has the administrative privileges (SYSDBA) necessary to set up a new user.
Container Database Setup
Run the following script to create an Oracle user on a container database with access to only those specific system tables queried by LogicMonitor. Be sure to update the <password>, <username> and <monitorProfile> placeholders with the credentials you want to assign to the user account.
CREATE USER <username> IDENTIFIED BY <password>;
CREATE PROFILE <monitorProfile> LIMIT SESSIONS_PER_USER 30;
GRANT SELECT ON DBA_DATA_FILES to <username> CONTAINER=ALL;
GRANT SELECT ON DBA_SEGMENTS TO <username> CONTAINER=ALL;
GRANT SELECT ON DBA_TABLESPACE_USAGE_METRICS to <username> CONTAINER=ALL;
GRANT SELECT ON DBA_TABLESPACES TO <username> CONTAINER=ALL;
GRANT SELECT ON DBA_TEMP_FILES to <username> CONTAINER=ALL;
GRANT SELECT ON V_$ASM_DISKGROUP to <username> CONTAINER=ALL;
GRANT SELECT ON V_$BACKUP_ASYNC_IO TO <username> CONTAINER=ALL;
GRANT SELECT ON V_$BACKUP_FILES TO <username> CONTAINER=ALL;
GRANT SELECT ON V_$DATAFILE TO <username> CONTAINER=ALL;
GRANT SELECT ON V_$DATAFILE_HEADER to <username> CONTAINER=ALL;
GRANT SELECT ON v_$LIBRARYCACHE TO <username> CONTAINER=ALL;
GRANT SELECT ON v_$LOCK TO <username> CONTAINER=ALL;
GRANT SELECT ON V_$LOG to <username> CONTAINER=ALL;
GRANT SELECT ON V_$RECOVERY_FILE_DEST to <username> CONTAINER=ALL;
GRANT SELECT ON V_$RESOURCE_LIMIT TO <username> CONTAINER=ALL;
GRANT SELECT ON V_$RMAN_BACKUP_JOB_DETAILS TO <username> CONTAINER=ALL;
GRANT SELECT ON v_$session TO <username> CONTAINER=ALL;
GRANT SELECT ON v_$SESSION_LONGOPS TO <username> CONTAINER=ALL;
GRANT SELECT ON v_$sql TO <username> CONTAINER=ALL;
GRANT SELECT ON v_$SYSMETRIC to <username> CONTAINER=ALL;
GRANT SELECT ON V_$SYSSTAT TO <username> CONTAINER=ALL;
GRANT SELECT ON V_$VERSION to <username> CONTAINER=ALL;For additional resources on setting up Oracle user accounts, see:
- Multitenant : Manage Users and Privileges For Container Databases (CDB) and Pluggable Databases (PDB) in Oracle Database 12c Release 1 (12.1)
- Overview of the Multitenant Architecture
Non-Container Database Setup
Run the following script to create an Oracle user on a non-container database with access to only those specific system tables queried by LogicMonitor. Be sure to update the <password>, <username> and <monitorProfile> placeholders with the credentials you want to assign to the user account.
CREATE USER <username> IDENTIFIED BY <password>;
CREATE PROFILE <monitorProfile> LIMIT SESSIONS_PER_USER 30;
ALTER USER <username> PROFILE <monitorProfile>
GRANT SELECT ON DBA_DATA_FILES to <username>;
GRANT SELECT ON DBA_SEGMENTS TO <username>;
GRANT SELECT ON DBA_TABLESPACE_USAGE_METRICS to <username>;
GRANT SELECT ON DBA_TABLESPACES TO <username>;
GRANT SELECT ON DBA_TEMP_FILES to <username>;
GRANT SELECT ON V_$ASM_DISKGROUP to <username>;
GRANT SELECT ON V_$BACKUP_ASYNC_IO TO <username>;
GRANT SELECT ON V_$BACKUP_FILES TO <username>;
GRANT SELECT ON V_$DATAFILE TO <username>;
GRANT SELECT ON V_$DATAFILE_HEADER to <username>;
GRANT SELECT ON v_$LIBRARYCACHE TO <username>;
GRANT SELECT ON v_$LOCK TO <username>;
GRANT SELECT ON V_$LOG to <username>;
GRANT SELECT ON V_$RECOVERY_FILE_DEST to <username>;
GRANT SELECT ON V_$RESOURCE_LIMIT TO <username>;
GRANT SELECT ON V_$RMAN_BACKUP_JOB_DETAILS TO <username>;
GRANT SELECT ON v_$session TO <username>;
GRANT SELECT ON v_$SESSION_LONGOPS TO <username>;
GRANT SELECT ON v_$sql TO <username>;
GRANT SELECT ON v_$SYSMETRIC to <username>;
GRANT SELECT ON V_$SYSSTAT TO <username>;
GRANT SELECT ON V_$VERSION to <username>;Set Up Credentials
Once an Oracle user account has been established for monitoring purposes, the credentials for that account must be set as properties on the Oracle resource(s) within LogicMonitor. As highlighted in the following tables, there are other (optional) properties that can also be set for Oracle resources. For more information on setting properties, see Resource and Instance Properties.
| Property | Description | Required or Optional |
| jdbc.oracle.user | Username assigned to the Oracle user account. It is easiest if the same username is set up everywhere. | Required |
| jdbc.oracle.pass | Password assigned to the Oracle user account. | Required |
| jdbc.oracle.port | Port number. If empty, the default port of 1521 is used. | Optional |
| ssh.user | For Linux systems, enter SSH username to enable database auto-discovery; Windows systems should automatically auto-discover databases. | Optional |
| ssh.pass | For Linux systems, enter SSH password to enable database auto-discovery; Windows systems should automatically auto-discover databases. | Optional |
| ssh.cert | For Linux systems, enter certificate (if required) for SSH to enable database auto-discovery; Windows systems should automatically auto-discover databases. | Optional |
| oracle.dbnames | Enter comma separated list of database names. | Required to monitor PDBs or if database auto-discovery is not enabled via SSH properties for Linux systems. |
| system.categories | When an Oracle server is found on a device, OracleDB is added to the value of system.categories. | Required. Under normal operations this property is auto populated; you can manually add OracleDB if missing. |
| oracle.<DatabaseName>.url | The connection string to the named database. | Required only if not created by the addCategory_OracleDatabase property source. Example: jdbc:oracle:thin:@[host]:[port]:[sid] or jdbc:oracle:thin:@[host]:[port]/[sid] |
| oracle.ssh.filemethod | Used to change the default method for finding database names and ports. | Optional. Only accepts listener as an option. |
| oracle.ssh.filelocation | Change the location of the file processed for database names.Accepts a directory nameThe default for the oratab file is \etc\ The default for listener.ora is /var/opt/oracle/Must end with a forward slash / | Optional |
If you have multiple Oracle databases with multiple users and/or port numbers, use the following properties to establish these settings on a per-database-basis. These properties must be set at the resource level to override the jdbc.oracle.user/pass/port properties highlighted in the previous table.
| Property | Description | Required or Optional |
| oracle.<DatabaseName>.user | The username assigned to the Oracle user account that has access to the database specified (substitute the <DatabaseName> placeholder in the property name with the name of the Oracle database). | Optional |
| oracle.<DatabaseName>.password | The password assigned to the Oracle user account that has access to the database specified (substitute the <DatabaseName> placeholder in the property name with the name of the Oracle database). | Optional |
| oracle.<DatabaseName>.port | The port number (if different than default port 1521 or port assigned by jdbc.oracle.port) used by the database specified (substitute the <DatabaseName> placeholder in the property name with the name of the Oracle database). | Optional |
| oracle.<DatabaseName>.url | The connection string to the named database. | Required only if not created by the addCategory_OracleDatabase property source. Example: jdbc:oracle:thin:@[host]:[port]:[sid] or jdbc:oracle:thin:@[host]:[port]/[sid] |
Migration from Legacy Oracle DataSources
In October of 2022, LogicMonitor released a new suite of Oracle DataSources. LogicMonitor has rewritten the Oracle modules to be consistent with the other database modules in LogicMonitor. The new modules require a JDBC connection string. A port is no longer required, but can still be used. The exposure of the connection string as a property on a device now allows LogicMonitor to monitor any Oracle database if there is a connection string, a username, and password. This can be an Oracle Cloud database, an Azure Oracle DB, or an AWS RDS instance.
Upgrading Existing Installations
For existing installations, you’ll need to install the new DataSources (conversion).
- Delete the PropertySources
Oracle_Database_Info. - Update the PropertySource
addCategory_OracleDatabaseandOracle_Database_Names. - Verify that
addCategory_OracleDatabasehas run and has added theOracleDBcategory to the device. - Verify that the
Oracle_Database_Names PropertySourcehas run and all of the Oracle databases have a propertyauto.oracle.dbnamesandauto.oracle.dbnames.urlwhere dbnames is one of the names in theauto.oracle.dbnamesproperty.
Note: If the device has manually configured properties for oracle.dbnames and oracle.port, Oracle_Database_Names will attempt to create the JDBC connection string. If this fails, you will need to add a connection string manually. For more information about disabling DataSources, see Disabling Monitoring for a DataSource or Instance.
Troubleshooting
The Oracle Database Troubleshooter DataSource exists to capture configuration and permissions issues on initial setup. It is not designed as a monitoring DataSource. If data is not being returned as expected, navigate to this DataSource in the Resources tree and check for the existence of errors. (Errors display as instances in the Resources tree). Additionally, any errors captured by the troubleshooter DataSource are included in alert details.
Note:
The module Oracle_Database_ConnectStatus should be used for continuous monitoring of connection and login problems.
LogicModules in Package
LogicMonitor’s package for Oracle consists of the following LogicModules. For full coverage, please ensure that all of these LogicModules are imported into your LogicMonitor platform.
| Name | Type | Description |
| addCategory_OracleDatabase | PropertySource | Adds OracleDB to the resource’s system.categories property. |
| Oracle_Database_Names | PropertySource | Creates properties for database names, connection strings (url) and database version. |
| Oracle_Database_ASMStorage | DataSource | Displays the status and percent used of Oracle ASM storage. |
| Oracle_Database_ConnectionStatus | DataSource | Checks the ability of the collector to connect to the Oracle database. Also reports the round trip time for a select statement. Returns either the TNS Error code or the ORA error code on a failure. For more information, see Oracle Connection Status DataSource. |
| Oracle_Database_DatafileStatus | DataSource | Displays the status of the data files. |
| Oracle_Database_DiskUsage | DataSource | Displays the amount of space used by data, log and temp files. |
| Oracle_Database_FRAUtilization | DataSource | displays information about the disk quota and current disk usage in the fast recovery area. Will alert if recovery area is close to full. |
| Oracle_Database_MonitorUser | DataSource | Monitors the number of sessions used by the monitoring user in Oracle. Reports active, inactive and killed sessions. |
| Oracle_Database_TableSpaceUsage | DataSource | Usage metrics for Oracle TableSpace. |
| Oracle_Database_TableSpaceUsageMaxGrowth | DataSource | Displays the allocated and free bytes for a tablespace within the data files, showing the maximum size to which a datafile can grow. |
| Oracle_Database_RMANBackupAsyncIOByType | DataSource | Performance information about ongoing and recently completed RMAN backups and restores. |
| Oracle_Database_RMANBackupSyncIOByType | DataSource | Performance information about ongoing and recently completed RMAN backups and restores. |
| Oracle_Database_RMANBackupSetsAge | Datasource | Displays the age of the latest backup set for each file type. Only available when RMAN is used for backups. Will look at whatever the last Backup Set that was created. No alerts are set since acceptable backup time differs for each database. |
| Oracle_Database_RMANLatestBackupFiles | DataSource | Information on backups without a Set type. |
| Oracle_Database_RMANLatestBackupJobByType | DataSource | Information about the latest RMAN Jobs. |
| Oracle_Database_BlockedSessions | DataSource | Creates an instance for every blocked session on the database. |
| Oracle_Database_BlockedSessionOverview | DataSource | The number of total blocked sessions on the database. |
| Oracle_Database_ResourceLimits | DataSource | displays information about global resource use for some of the system resources. |
| Oracle_Database_LongOperations | DataSource | Information about the latest operations lasting over six seconds. |
| Oracle_Database_SystemStats | DataSource | Get statistics from Oracle for the database instance. |
| Oracle_Database_SystemMetrics | DataSource | Displays the system metric values from the V$Sysmetric table on an Oracle database for the prior 60 seconds. |
| Oracle_Database_TableSpaceStatus | DataSource | Discovers Oracle database tablespaces and determines whether they are online, read-only or offline. |
| Oracle_Database_Troubleshooter | DataSource | Shows problems with Oracle Database configuration problems. Checks table permissions to make sure all tables are available. |
| Oracle_Database_IndividualSchemaSize | DataSource | The size of the individual schema for each owner. |
| Oracle_Database_SessionsWaiting_LockRelease | DataSource | The number of session blocked by another session with locks on a table, schema or database. |
| Oracle_Database_LibraryCache | DataSource | Information about about library cache performance and activity. |
| Oracle_Database_WinServices | DataSource | Monitors the status of the Windows Services associated with an Oracle database. |
When setting static datapoint thresholds on the various metrics tracked by this package, LogicMonitor follows the technology owner’s best practice KPI recommendations. If necessary, we encourage you to adjust these predefined thresholds to meet the unique needs of your environment. For more information on tuning datapoint thresholds, see Tuning Static Thresholds for Datapoints.
Oracle Connection Status DataSource
The Oracle_Database_ConnectionStatus DataSource is used to check connectivity from the collector to an Oracle database. By default, the DataSource will attempt to connect to the Oracle database three times before alerting:
- First attempt fails: DataSource will wait three seconds and try to connect again.
- Second attempt fails: DataSource will wait 12 seconds and try to connect again.
- Third attempt fails: An alert is sent.
The number of tries, as well as the length of time between tries, can be set with device properties. Care must be taken to prevent the DataSource from hitting a timeout. The timeout by default is 180 seconds, but it can be changed in the collector properties.
When a connection to the database is successful, the DataSource runs the select statement SELECT SYSDATE FROM DUAL; and reports the number of rows returned, as well as the time for execution. This select statement can be overridden with a device property. Properties are in the form of oracle.propertyName or oracle.dbname.propertyName. When oracle.dbname.propertyName is used, the property will be used for a specific database name. When there is no dbname specified, the DataSource will use the property for each database instance on the device.
Properties
All of these properties are optional, but may be needed for slower connections.
| Property Name | Description | Example | Default |
| oracle.sqltest or oracle.dbname.sqltest | SQL statement run each time the connection test is run. The jdbc.oracle.usermust have access to this table for the statement to succeed. | SELECT USER_ID FROM dba_users | SELECT SYSDATE FROM DUAL |
| oracle.max_retries or oracle.dbname.max_retries | Number of retries before generating an alert. Setting this number too high may result in DataSource timeouts, and the alert will not be sent. The combination of max_retries and wait_timeneeds to be less than 180 seconds. | 5 | 3 |
| oracle.wait_time or oracle.dbname.wait_time | Wait time in seconds for the first try. Subsequent tries will be wait_time * retrycount. Setting this number too high will cause a collector timeout, as well as a possible missed alert. | 4 | 3 |
Sample Setup
Redis monitoring simply requires that the Redis process be accessible from the collector. By default the collector will look for Redis processes on the default port of 6379, but you can define additional ports to by setting the property redis.ports, on a host or group level.
If using authentication, define the property redis.pass on a host or group level to tell LogicMonitor the password to use when authenticating the connection.
Detection of whether the Redis instance is a replica is automatic – if so, replica monitoring will be applied.
LogicMonitor’s MongoDB monitoring package offers monitoring for databases, server health, and replication for clusters. The package uses the MongoDB Java Driver to monitor the servers directly.
Compatibility
As of December 2023, LogicMonitor’s MongoDB package is known to be compatible with versions 6.0 or later.
Setup Requirements
Add Resources Into Monitoring
Add your MongoDB hosts into monitoring. For more information on adding resources into monitoring, see Adding Devices.
Obtain Credentials
LogicMonitor must provide the appropriate credentials in order to successfully access the MongoDB resource’s data. These credentials must belong to a user account that has been assigned the following minimum permissions:
| Role | Description |
| replSetGetStatus | Ability to run the replSetGetStatus command (required for monitoring replication) |
| serverStatus | Ability to run the serverStatus command (required for the MongoDB_Server_Overview DataSource) |
| dbStats | Ability to run the dbStats command |
Assign Properties to Resources
Set the following custom properties must be set on the MongoDB resource within LogicMonitor. For more information on setting properties, see Resource and Instance Properties.
| Property | Description |
| mongodb.user | (Required) MongoDB username. |
| mongodb.pass | (Required) MongoDB password. |
| mongodb.ssl | (Optional) Set this property to TRUE if the MongoDB server is setup to use SSL to connect. |
| mongodb.ports | (Optional) By default, LogicMonitor tries to connect to 27017. If there are multiple ports running MongoDB on the host, (for multiple instances on the same server), enter the ports as a comma-separated list. Note: If you do customize this property and 27017 is one of the ports LogicMonitor should try, ensure it is included in the comma-separated list. |
Import LogicModules
From the LogicMonitor public repository, import all MongoDB LogicModules, which are listed in the LogicModules in Package section of this support article. If these LogicModules are already present, ensure you have the most recent versions.
Once the LogicModules are imported (assuming all previous setup requirements have been met), data collection will automatically commence.
Consideration: Two Sets of LogicModules for MongoDB Monitoring
LogicMonitor currently has two sets of MongoDB LogicModules in our MongoDB monitoring package:
- Compatible ONLY with Collector versions 29.105 and lower. The original set of MongoDB DataSources will not work with Collector versions 29.106 and higher due to a hard JAR dependency.
- Compatible ONLY with Collector versions 29.106 and higher. The newer set of MongoDB DataSources use a newer MongoDB driver only available in newer Collectors.
Both sets offer similar coverage; their primary differentiator is Collector compatibility. You can see the LogicModules that make up both sets in the LogicModules in Package section of this support article.
LogicMonitor recommends that, even if you’re still using a Collector version lower than 29.106 to monitor MongoDB, you import the newer set as well. The newer set will not associate with any MongoDB resources until the Collector version is updated to 29.106 or higher at which time they will automatically associate, ensuring a smooth monitoring transition. At that time, the older set will cease to function.
LogicModules in Package
LogicMonitor’s package for MongoDB consists of the following LogicModules. For full coverage, please ensure that all of these LogicModules are imported into your LogicMonitor platform.
| Name | Type | Collector Version Compatibility | Description |
| addCategory_MongoDB | PropertySource | All | Adds “MongoDB” as a value to the system.categories property on MongoDB resources. |
| MongoDB_Server_Overview | DataSource | 29.106 or higher | High level overview of MongoDB server health and statistics. |
| MongoDB Server Databases | DataSource | 29.106 or higher | Monitors basic stats on MongoDB databases. |
| MongoDB_Sever_Replication | DataSource | 29.106 or higher | Discover all members of replica set and measures replication and status. |
| MongoDB Replication | DataSource | 29.105 or lower | Discover all members of replica set and measures replication and status. |
| MongoDB Databases | DataSource | 29.105 or lower | Monitors individual MongoDB databases on the host. |
| MongoDB- | DataSource | 29.105 or lower | Monitors core MongoDB functionality |
When setting static datapoint thresholds on the various metrics tracked by this package’s DataSources, LogicMonitor follows the technology owner’s best practice KPI recommendations. If necessary, we encourage you to adjust these predefined thresholds to meet the unique needs of your environment. For more information on tuning datapoint thresholds, see Tuning Static Thresholds for Datapoints.
LogicMonitor uses JMX for monitoring Java applications. For information about Tomcat monitoring, see here.
Enabling JMX
JMX is enabled by passing parameters to the Java JVM during startup. For full instructions on enabling JMX monitoring within your Java applications, see Monitoring and Management Using JMX.
To enable JMX monitoring of a java process with user name/password access:
- define the TCP port that JMX will listen on when you start the JVM:
- com.sun.management.jmxremote.port=portNum
- com.sun.management.jmxremote.rmi.port=portNum
- create a password file jmxremote.password, with the contents being a role and a password, space separated: e.g. monitorRole SecretPass
- create a password file jmxremote.access, with the contents being a role and an access level, space separated: e.g. monitorRole readonly
- ensure both files are owned by the user of the java process, and readable only by that user. (chmod 600 filename on linux)
You then need to pass these parameters to Java when you start your process:
com.sun.management.jmxremote.access.file=location of jmxremote.access file
com.sun.management.jmxremote.password.file=location of jmxremote.password file
com.sun.management.jmxremote.port=JMX port
com.sun.management.jmxremote.ssl=false
e.g.
In LogicMonitor, you would set the properties jmx.user, jmx.pass and jmx.ports to the appropriate username, password and port(s) required for jmx access. (You could set these properties at the global, group or device level. See Defining authentication credentials.
Note: jmx.ports can be a comma separated list of ports to check for JMX access on, if you run multiple JMX apps on different ports.
If JMX Access does not work
Note that during establishment of the JMX connection, the host being queried will reply back with the address for the RMI connection – this requires that that the /etc/hosts file on the Java system is correctly set up, such that the /etc/hosts file contain that hostname and resolves it to the same address that the querying host resolves it to.
e.g. a system with this for /etc/hosts:
127.0.0.1 demo1.logicmonitor.com would have all JMX connections to demo1.logicmonitor.com fail (as it will send a response indicating that the dynamic RMI connection should be made to 127.0.0.1), whereas if the /etc/hosts contained this:
10.4.4.4 demo1.logicmonitor.comit would succeed (assuming 10.4.4.4 was its actual IP address.)
An alternative to avoiding name resolution issues is to explicitly identify the hostname to use for RMI connections when starting the Java application, by the -Djava.rmi.server.hostname= parameter. We recommend using Jconsole to ensure you have JMX access set up correctly.
Note: by default, JMX access opens a dynamic port for RMI, above 1024. You may need to change firewall rules to allow the collector to make this connection to the Java server on non-privileged ports above 1024. You can also control the port used for the RMI access by explicitly setting it with the flag:
-Dcom.sun.management.jmxremote.rmi.port=PORT.It works to set the RMI port to the same port that JMX is using – so this means you only need to open up one port through a firewall.
LogicMonitor monitors Tomcat with two approaches:
- HTTP to check the server availability and responsiveness
- JMX to collect comprehensive internal server statistics
Monitoring Tomcat via HTTP
The datasource HTTP- and HTTPS- check the server availability and responsiveness by sending requests to ports 80 and 443.
If your Tomcat doesn’t listen on the standard port, or you have multiple Tomcat instances running on the same box, you can update the port list in the Active Discovery section of the datasources to add additional ports.
Monitoring Tomcat via JMX
LogicMonitor collects Tomcat internal statistics via JMX. To enable Tomcat JMX monitoring, please follow the steps below:
1. Enable JMX on your Tomcat application
To enable JMX monitoring without requiring a password, add the following parameters into the CATALINA_OPTS environment variable.
-Dcom.sun.management.jmxremote \
-Dcom.sun.management.jmxremote.port=%my.jmx.port% \
-Dcom.sun.management.jmxremote.ssl=false \
-Dcom.sun.management.jmxremote.authenticate=false \
-Djava.rmi.server.hostname=(The IP/DNS name of the server, as added to LogicMonitor)To enable JMX with password authentication, add the following properties:
-Dcom.sun.management.jmxremote \
-Dcom.sun.management.jmxremote.port=%my.jmx.port% \
-Dcom.sun.management.jmxremote.ssl=false \
-Dcom.sun.management.jmxremote.authenticate=true
-Dcom.sun.management.jmxremote.password.file=%my.conf.folder%/jmxremote.password \
-Dcom.sun.management.jmxremote.access.file=%my.conf.folder%/jmxremote.access \
-Djava.rmi.server.hostname=(The IP/DNS name of the server, as added to LogicMonitor)Then edit the %my.conf.folder%/jmxremote.access file to include:
monitorRole readonlyThen edit the %my.conf.folder%/jmxremote.password file to include:
monitorRole mypasswordThis creates a readonly user monitorRole with the password ‘mypassword‘. For more information on configuring JMX for Tomcat, refer to Tomcat’s Documentation here.
2. Set up device properties
Add the following three device properties to reflect what you have configured Tomcat JMX from Step 1:
tomcat.jmxports = <jmx_port>jmx.user = <jmx_user>jmx.pass = <jmx_pass>
Note: If you run multiple tomcat instances on your servers, or use different ports on different servers, you can specify a comma separated list of ports to query for JMX information in the tomcat.jmxports variable.
After several minutes, the LogicMonitor will update its database and start collecting Tomcat internal stats via JMX.
Tomcat Troubleshooting
If you finish the steps above, and find LogicMonitor still can’t collect Tomcat internal stats, the failure is usually caused by network issue (e.g. firewall), Tomcat configuration, or incorrect username/password. You can use jconsole (part of the SUN JDK) to check the real reason.
If LogicMonitor is not discovering Apache instances automatically, it is likely that the collector cannot access the server-status page. Ensure Apache is loading the mod_status module, and that the Apache configuration file is set to allow the collector to pull the server status page, by a section such as the following in the httpd.conf.
Substitute 10.0.0.12 for the IP address of the device where the collector is installed.
Apache will need a graceful restart after the config file has been changed.
You can test that Apache is set up correctly by attempting to load the server status page from the collector.
e.g.
No Redirects
One point to note is that you should not be getting the results of /server-status from a redirect, but must get it directly from the queried server. (LogicMonitor will not follow such redirects, as we want to be sure we are monitoring Apache response on the server being initially queried, not a possibly different server that is redirected to.)
If you are using rewrite rules, one way to ensure that the /server-status page is not being redirected is to insert the following immediately after enabling the rewrite engine:
To collect information about the number of requests, busy threads, etc from Nginx, LogicMonitor must be able to pull the status page. Ensure Nginx is compiled with the stub_status module, and that the Nginx configuration file is set to allow the collector to pull the server status page, by a section such as the following in the nginx.conf:
location /nginx_status {stub_status on;access_log off;allow COLLECTOR.IP.ADD.RESS;deny all;}
If you set the location of the status page to location other than /nginx_status, you will need to update the Nginx datasource. Change the location in the Active Discovery and Collector Attributes sections, as shown:
If the status page is accessible from by the collector, LogicMonitor will discover the Nginx server, and start monitoring it. You may want to manually run Active Discovery to force discovery.
