Storing Data from the Test Monitor Service on an External PostgreSQL Server

Configure SystemLink Enterprise to store data from the Test Monitor Service on an external PostgreSQL server.

For this configuration, you need the hostname of the database server and at least one set of credentials with access to the database server. You might also require a public certificate for TLS authentication with the server.
You need access to create databases and users on your PostgreSQL server for the following steps.
  1. Create a database for the Test Monitor Service on your database server. A good default name for this database is nisystemlink.
  2. Create a user with CREATE privileges for the database.
  3. With this information, including the user credentials, choose one of the following configuration options.
    Note Future updates of the Test Monitor Service chart may require modifications to the schema and table. To perform these modifications, the Test Monitor Service chart must act as the user that owns the schema and tables. In addition to the user that handles day-to-day operations, you can specify a separate user with higher permissions to perform database migrations.
    Option Steps
    Use a PostgreSQL connection string stored as a Kubernetes secret.
    1. In systemlink-secrets.yaml, configure the testmonitorservice.secrets.database.connectionString value with the user to use for day-to-day operation.
    2. Optional: To specify a user with ownership of the schema and tables to perform database migrations, configure the following settings.
      1. In systemlink-secrets.yaml, configure the testmonitorservice.secrets.database.migrationConnectionString value with the user that owns the schema.
      2. In systemlink-values.yaml, configure the testmonitorservice.database.connectionString.migrationConnectionStringKey value.
    Note You can also manually create these secrets if you are not managing secrets in the Helm chart.
    Configure the individual connection parameters for the database in the Helm chart.
    1. In systemlink-values.yaml, comment out the testmonitorservice.database.connectionString group.
    2. Uncomment the testmonitorservice.database.connectionInfo group.
    3. Configure the testmonitorservice.database.connectionInfo.user value to the user to use for day-to-day operation.
    4. In systemlink-secrets.yaml, configure the testmonitorservice.secrets.database.connectionPassword value or create the required secret manually.
    5. Optional: To specify a user with ownership of the schema and tables to perform database migrations, configure the following settings.
      1. In systemlink-values.yaml, configure the testmonitorservice.database.connectionInfo.migrationUser to the user that owns the schema and tables.
      2. Configure the testmonitorservice.database.connectionInfo.migrationPasswordKey value.
      3. In systemlink-secrets.yaml, configure the testmonitorservice.secrets.database.migrationConnectionPassword value to the password to the user configured in testmonitorservice.database.connectionInfo.migrationUser or create the required secret manually.
      4. Configure testmonitorservice.secrets.database.connectionPassword value to the password to the user configured in testmonitorservice.database.connectionInfo.user.
    The Test Monitor Service creates the required database schema and tables on initial launch of the service. You can then revoke ownership of the database schema and tables from the provided user. The Test Monitor Service requires a user with the following privileges for day-to-day operation.
    Location Privileges
    On the database specified in the configuration CONNECT
    On the "TestMonitor" schema CREATE

    USAGE
    On all tables within the "TestMonitor" schema DELETE

    INSERT

    SELECT

    UPDATE

Once tables are created, SystemLink Enterprise is responsible for the TestMonitor schema and all tables within it. Users must access schema data through the SystemLink web application or the Test Monitor Service API. The schema and schema data are internal implementations of the Test Monitor Service. The schema and schema data might change without notice.