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 ( 56(84) bytes of data.
64 bytes from ( icmp_seq=1 ttl=255 time=0.612 ms
64 bytes from ( icmp_seq=2 ttl=255 time=0.600 ms
64 bytes from ( icmp_seq=3 ttl=255 time=0.595 ms
64 bytes from ( 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 Connection refused then

telnet 3306
Connected to
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.

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.