Troubleshooting
When setting up DBmarlin the most common problems are due to connectivity between the DBmarlin agent and the target databases and hosts that need to be monitored.
Connectivity issues​
The DBmarlin server needs to be able to make a database connection to the target database instance you wish to monitor. Here
Can the name be resolved to the correct IP?​
From the DBmarlin server, you can use ping
to make sure that the host name you are entering can be resolve by DNS to the correct IP. If you don't get a response from ping
that isn't necessarily a problem as ICMP protocol could be blocked but that isn't required by DBmarlin. The main thing here is that the name resolves to the correct IP.
ping mysql.webtuna.com
PING mysql.webtuna.com (172.30.1.44) 56(84) bytes of data.
64 bytes from mysql.webtuna.com (172.30.1.44): icmp_seq=1 ttl=255 time=0.612 ms
64 bytes from mysql.webtuna.com (172.30.1.44): icmp_seq=2 ttl=255 time=0.600 ms
64 bytes from mysql.webtuna.com (172.30.1.44): icmp_seq=3 ttl=255 time=0.595 ms
64 bytes from mysql.webtuna.com (172.30.1.44): icmp_seq=4 ttl=255 time=0.589 ms
Possible causes and suggestions​
- If the name does not resolve it could be you are using the wrong name
- It could be a DNS problem
- Try using the IP instead of the host name
- Try using a fully qualified DNS name
Is the port open?​
From the DBmarlin server, you can use telnet
to make sure that the port you are connecting to on the host is open and not blocked. If you see Escape character is '^]'
then a connection can be made. If you see telnet: connect to address 172.30.1.44: Connection refused
then
telnet mysql.webtuna.com 3306
Trying 172.30.1.44...
Connected to mysql.webtuna.com.
Escape character is '^]'.
Possible causes and suggestions​
- Check the port number you are using is the correct one for the database.
- Typical ports are Oracle (1521), SQL Server (1433), MySQL (3306), PostgreSQL (5432) but of course they could have been customized.
- It could be that a firewall is blocking the port. This could be a software firewall such as Windows firewall or a hardware firewall between DBmarlin and the target database instance.
- There maybe no route from the network where DBmarlin is installed to the network of the database server.
- If you are running in the cloud, think about VPCs and Security groups which could prevent connectivity.
SQL Statements are truncated​
There is a limit on the length of SQL text that can be captured for PostgreSQL, MySQL and MariaDB databases. In most cases the default value is 1024 characters. This means that large SQL statements are truncated and also that the statements cannot be explained, causing the Execution Plans tab to be empty.
- See here to increase the limit for PostgreSQL
- See here to increase the limit for MySQL and MariaDB
Missing Execution plans for statements​
The most likely reason is that your SQL statements are being truncated (See above).
It could also be that the type of statement is not explainable. For MySQL for example only SELECT
statements can be explained and INSERT
, UPDATE
, DELETE
will not. Also statements like ANALYZE
, COMMIT
etc will not be able to be explained for most databases.
If execution plans are missing but the reasons above do not explain the reason then it could be releated to permissions or something else. In this case you can turn on Debug for the Sensor for a few minutes which will log and explain plan failures to the tomcat/log/localhostXXXX.log
file.