Hi,

the setup you describe is fully supported by Db2 and is in fact a recommended pattern for monitoring purposes. I'd like to outline how we can implement it.

1) Authentication model
Db2 supports local implicit connections for the instance owner via OS-level authentication. When a process runs under the db2inst1 OS account, it can attach to the instance and connect to the local databases without supplying a username or password - the identity is inherited from the operating system session and validated by the server's underlying security facility (this corresponds to the SERVER authentication type, which is the default for newly created instances).

Reference: IBM Documentation - "Authentication methods for your server"
https://www.ibm.com/docs/en/db2/11.5.x?topic=details-authentication-methods-servers

2) Required configuration
•⁠  ⁠The monitoring agent must be executed under the db2inst1 OS user (e.g. via a systemd unit with User=db2inst1, or an equivalent service account configuration).
•⁠  ⁠The Db2 environment must be initialised before any connection attempt by sourcing the instance profile:
    . /home/db2inst1/sqllib/db2profile
•⁠  ⁠No DBM CFG changes are required if the instance is using the default SERVER authentication type.

3) Database discovery
Once the agent is connected as db2inst1, the list of cataloged databases can be retrieved with:
    db2 list database directory
or programmatically through the SYSIBMADM administrative views, depending on the capabilities of the monitoring product.

4) Authorisation
As the instance owner, db2inst1 holds SYSADM authority by default and therefore also implicitly SYSMON, which is sufficient to read all snapshot and monitoring views (MON_GET_, SNAP_, etc.). No additional GRANT statements are required.

5) Security considerations
This approach is generally preferable to credential-based authentication for unattended monitoring, since:
•⁠  ⁠no secrets are stored at rest in configuration files;
•⁠  ⁠access is governed by OS-level permissions on the db2inst1 account;
•⁠  ⁠audit trails attribute all monitoring activity to a single, well-defined identity.

Could you please confirm which monitoring product is being used (e.g. Datadog Agent, Zabbix, Prometheus db2_exporter, IBM Instana)?

Best regards,
Roberto

------------------------------
Roberto Renna
------------------------------

Hi,

the setup you describe is fully supported by Db2 and is in fact a recommended pattern for monitoring purposes. I'd like to outline how we can implement it.

1) Authentication model
Db2 supports local implicit connections for the instance owner via OS-level authentication. When a process runs under the db2inst1 OS account, it can attach to the instance and connect to the local databases without supplying a username or password - the identity is inherited from the operating system session and validated by the server's underlying security facility (this corresponds to the SERVER authentication type, which is the default for newly created instances).

Reference: IBM Documentation - "Authentication methods for your server"
https://www.ibm.com/docs/en/db2/11.5.x?topic=details-authentication-methods-servers

2) Required configuration
•⁠  ⁠The monitoring agent must be executed under the db2inst1 OS user (e.g. via a systemd unit with User=db2inst1, or an equivalent service account configuration).
•⁠  ⁠The Db2 environment must be initialised before any connection attempt by sourcing the instance profile:
    . /home/db2inst1/sqllib/db2profile
•⁠  ⁠No DBM CFG changes are required if the instance is using the default SERVER authentication type.

3) Database discovery
Once the agent is connected as db2inst1, the list of cataloged databases can be retrieved with:
    db2 list database directory
or programmatically through the SYSIBMADM administrative views, depending on the capabilities of the monitoring product.

4) Authorisation
As the instance owner, db2inst1 holds SYSADM authority by default and therefore also implicitly SYSMON, which is sufficient to read all snapshot and monitoring views (MON_GET_, SNAP_, etc.). No additional GRANT statements are required.

5) Security considerations
This approach is generally preferable to credential-based authentication for unattended monitoring, since:
•⁠  ⁠no secrets are stored at rest in configuration files;
•⁠  ⁠access is governed by OS-level permissions on the db2inst1 account;
•⁠  ⁠audit trails attribute all monitoring activity to a single, well-defined identity.

Could you please confirm which monitoring product is being used (e.g. Datadog Agent, Zabbix, Prometheus db2_exporter, IBM Instana)?

Best regards,
Roberto

------------------------------
Roberto Renna
------------------------------

Hi Saury,

thanks for the details. There are two separate issues here, and the second one is the root cause of what you're seeing.

1) The Instana Db2 sensor REQUIRES username and password in its configuration
Even when the agent runs as db2inst1, the Db2 sensor connects to the database via JDBC (TCP), not through Db2's local implicit OS authentication. There is currently no option in the Db2 sensor to use OS-level authentication - user and password must always be provided in the configuration. This is a sensor design limitation, independent of how Db2 itself authenticates the instance owner locally. All IBM-published examples of the Db2 sensor configuration include explicit credentials.

2) Your current configuration is incomplete → "connection URL: null"
This error means the sensor couldn't build a JDBC URL because mandatory fields are missing. The minimum required fields for local monitoring are instance, host, port, user, password, and databases. Your snippet only has instance/user/password.

A working configuration in <agent_install_dir>/etc/instana/configuration.yaml looks like this:

com.instana.plugin.db2:
  local:
    - instance: 'db2inst1'
      host: 'localhost'
      port: '50000'         # see below to find the right value
      user: 'db2inst1'
      password: 'xxxx'
      databases:
        - 'SAMPLE'
        - 'TEST'

To find the correct TCP port for your instance:

    db2 get dbm cfg | grep -i SVCENAME
    grep <svcename> /etc/services

After saving the file, restart the agent (./stop && ./start under /opt/instana-agent/bin) and check <agent_install_dir>/data/log/agent.log for the Db2 sensor messages.

3) Recommended approach for the password requirement
Since a password is unavoidable, the cleanest pattern is:

•⁠  ⁠Create a dedicated low-privilege OS user for monitoring (e.g. instana_mon) at OS level.
•⁠  ⁠Grant it only the minimum Db2 authorities required by the sensor (typically SYSMON at instance level, plus SELECT on the SYSIBMADM views the sensor uses; the IBM MustGather guide for the Db2 sensor lists the exact permissions: https://www.ibm.com/support/pages/node/7245691).
•⁠  ⁠Store the password using the Instana agent key store / encrypted secrets feature instead of plain text in the YAML.

This keeps db2inst1 untouched, avoids embedding the instance owner's password in a config file, and limits the monitoring account's blast radius.

If you confirm the Instana agent and Db2 sensor versions in use, I can validate the exact YAML schema for your release - there were small changes around v1.0.24.

Thanks

Regards