PostgreSQL monitoring configuration

After you define the scope of your configuration, you need to identify the following:

Example payload

Example payload to activate the PostgreSQL extension:

[
  {
    "value": {
      "enabled": true,
      "description": "My PostgreSQL extension",
      "version": "0.1.1",
      "featureSets": [
        "io",
        "cpu",
      ],
      "sqlPostgresRemote": {
        "endpoints": [
          {
            "host": "psqlserver.org",
            "port": 1521,
            "databaseName": "dbname",
            "authentication": {
              "scheme": "basic",
              "username": "user",
              "password": "password"
            },
            "ssl": false
          }
        ]
      }
    },
    "scope": "ag_group-default"
  }
]

Parameters

Enabled

If set to true, the configuration is active and Dynatrace starts monitoring immediately.

Description

A human-readable description of the specifics of this monitoring configuration.

Version

The version of this monitoring configuration. Note that a single extension can run multiple monitoring configurations.

Feature sets

Add a list of feature sets you want to monitor. To report all feature sets, add all.

"featureSets": [
  "cpu",
  "io"
  ]

Endpoints

You can define up to 20,000 endpointsin a single monitoring configuration in the sqlPostgresRemote section.

"sqlPostgresRemote": {
        "endpoints": [
            {
                "host": "psqlserver.org",
                "port": 1433,
                "databaseName": "dbname",
                "authentication": {
                    "scheme": "basic",
                    "username": "user",
                    "password": "password"
                }
            }
        ]
    }

To define the PostgreSQL Database server, add the following details in the endpoints section:

Authentication

Authentication details passed to the Dynatrace API when activating monitoring configuration are obfuscated and it's impossible to retrieve them.

Credential vault

The credential vault authentication type provides a more secure approach to using extensions by securely storing and managing user credentials. To use this, you must be the owner of the credentials and have a credential vault that meets the following criteria:

"authentication": {
   "scheme": "basic",
   "useCredentialVault": true,
   "credentialVaultId": "some-credential-vault-id"
}

SSL

ActiveGate version 1.269+

Enable SSL to make the data source verify the server certificate and use SSL encryption instead of native encryption.

"ssl": true

Enable SSL without a local truststore

When SSL is enabled and the server's certificate chain is publicly verifiable (for example, issued by Azure or other well-known CAs), there's no need to manually create a truststore. The system will automatically trust the server's certificate based on the trusted CAs in the environment.

However, if you need to use a local truststore for certificates not globally recognized or for additional security measures

Validate SSL certificates

ActiveGate version 1.269+

The certificate is additionally validated with hostname, which means that the domain from the certificate must match the one from the endpoint passed in the monitoring configuration.

Enable this option when connecting to databases using custom certificates.

"validateCertificates": true

Scope

Note that each ActiveGate host running your extension needs the root certificate to verify the authenticity of your extension. For more information, see Sign extension.

The scope is an ActiveGate group that will execute the extension. Only one ActiveGate from the group will run this monitoring configuration. If you plan to use a single ActiveGate, assign it to a dedicated group. You can assign an ActiveGate to a group during or after installation. For more information, see ActiveGate group.

Use the following format when defining the ActiveGate group:

"scope": "ag_group-<ActiveGate-group-name>",

Replace <ActiveGate-group-name> with the actual name.