User Documentation

Table of Contents

1. What is Trento?

Trento is the official version of the Trento community project. It is a comprehensive monitoring solution consisting of two main components: the Trento Server and the Trento Agent. Trento provides the following functionality and features:

  • A user-friendly reactive Web interface for SAP Basis administrators.

  • Automated discovery of Pacemaker clusters using SAPHanaSR classic or angi as well as different fencing mechanisms, including diskless SBD.

  • Automated discovery of SAP systems running on ABAP or JAVA stacks and HANA databases.

  • Visibility into Pacemaker maintenance status of clusters, nodes, or resources.

  • Configuration validation for SAP HANA Scale-Up Performance/Cost-optimized, SAP HANA Scale-out and ASCS/ERS clusters deployed on Azure, AWS, GCP or on-premises bare metal platforms, including KVM and Nutanix.

  • Insights about the execution of configuration checks.

  • Delivery of configuration checks decoupled from core functionality.

  • Email alerting for critical monitoring events.

  • Integration of saptune into the console and specific configuration checks at host and cluster levels.

  • Information about relevant patches and upgradable packages for registered hosts via integration with SUSE Multi-Linux Manager.

  • Monitoring of CPU, memory, filesystem and swap usage at host level through basic integration with Prometheus.

  • API-based architecture to facilitate integration with other monitoring tools.

  • Rotating API key to protect communication from the Trento Agent to the Trento Server.

  • AI assistance via Model Context Protocol (MCP) integration.

  • Housekeeping capabilities.

1.1. Trento Architecture

trento high level architecture
Figure 1. Architectural overview

1.2. Trento Server

The Trento Server is an independent, distributed system designed to run on a Kubernetes cluster or as a regular systemd stack. It provides both a Web front-end for user interaction and backend APIs for automation and integration with components such as the Trento MCP Server. Together with the optional Trento MCP Server, it enables secure, AI-assisted operations by exposing Trento Server APIs for natural-language interactions with tools like MCPHost, Copilot, Claude, and SUSE AI.

The Trento Server consists of the following components:

  • The Web component that acts as a control plane responsible for internal and external communications as well as rendering the UI.

  • The orchestration engine named Wanda that orchestrates the execution of compliance checks and operations.

  • The Trento MCP Server which creates a secure bridge between the infrastructure data collected by Trento and your Large Language Model (LLM) of choice.

  • A PostgreSQL database for data persistence.

  • The RabbitMQ message broker for communication between the orchestration engine and the agents.

  • A Prometheus instance that retrieves the metrics collected by the Prometheus node exporter in the registered hosts. This Prometheus instance is optional in a systemd deployment.

1.3. Trento Agent

The Trento Agent is a single background process (trento-agent) running on each monitored host of the SAP infrastructure.

2. Lifecycle

Trento is part of SUSE Linux Enterprise Server for SAP applications. Trento’s two main components have the following product lifecycles:

Trento Agent
Delivery mechanism

RPM package for SUSE Linux Enterprise Server for SAP applications 15 SP4 and newer, and SUSE Linux Enterprise Server for SAP applications 16.0.

Supported runtime

Supported in SUSE Linux Enterprise Server for SAP applications 15 SP4 and newer, and SUSE Linux Enterprise Server for SAP applications 16.0, on x86_64 and ppc64le architectures.

Trento Server
Delivery mechanisms

A set of container images from the SUSE public registry together with a Helm chart that facilitates their installation or a set of RPM packages for SUSE Linux Enterprise Server for SAP applications 15 SP4 and newer, and SUSE Linux Enterprise Server for SAP applications 16.0.

Kubernetes deployment

The Trento Server runs on any current Cloud Native Computing Foundation (CNCF)-certified Kubernetes distribution based on a x86_64 architecture. Depending on your scenario and needs, SUSE supports several usage scenarios:

  • If you already use a CNCF-certified Kubernetes cluster, you can run the Trento Server in it.

  • If you don’t have a Kubernetes cluster, and need enterprise support, SUSE recommends SUSE Rancher Prime Kubernetes Engine (RKE) (RKE) version 2.

  • If you do not have a Kubernetes enterprise solution but you want to try Trento, SUSE Rancher’s K3s provides you with an easy way to get started. But keep in mind that K3s default installation process deploys a single node Kubernetes cluster, which is not a recommended setup for a stable Trento production instance.

systemd deployments

Supported in SUSE Linux Enterprise Server for SAP applications 15 SP4 and newer, and SUSE Linux Enterprise Server for SAP applications 16.0 on x86_64 and ppc64le architectures.

3. Requirements

This section describes requirements for the Trento Server and its Trento Agents, as well as the SAP systems and clusters that we want to monitor in the backend environment.

3.1. Trento Server requirements

Running all the Trento Server components requires a minimum of 4 GB of RAM, two CPU cores and 64 GB of storage. When using K3s, such storage should be provided under /var/lib/rancher/k3s.

Trento is based on event-driven technology. Registered events are stored in a PostgreSQL database with a default retention period of 10 days. For each host registered with Trento, allocate at least 3 GB of space in the PostgreSQL database.

Trento Server supports different deployment scenarios: Kubernetes and systemd. A Kubernetes-based deployment of Trento Server is cloud-native and OS-agnostic. It can be performed on the following services:

  • RKE2

  • A Kubernetes service in a cloud provider

  • Any other CNCF-certified Kubernetes running on x86_64 architecture

The Helm chart and the container images required for a Kubernetes-based deployment are available in SUSE public registry.

A production-ready Kubernetes-based deployment of Trento Server requires Kubernetes knowledge. The Helm chart is intended to be used by customers without in-house Kubernetes expertise, or as a way to try Trento with a minimum of effort. However, Helm chart delivers a basic deployment of the Trento Server with all the components running on a single node of the cluster.

The packages required for a systemd deployment are available in the repositories of SUSE Linux Enterprise Server for SAP applications 15 (SP4 or higher) or SUSE Linux Enterprise Server for SAP applications 16.0.

3.2. Trento Agent requirements

The resource footprint of the Trento Agent is designed to not impact the performance of the host it runs on.

The Trento Agent component needs to interact with several low-level system components that are part of the SUSE Linux Enterprise Server for SAP applications distribution.

The hosts must have unique machine identifiers (ids) to be registered in Trento. This means that if a host in your environment is built as a clone of another one, make sure to change the machine’s identifier as part of the cloning process before starting the Trento Agent on it.

Similarly, the clusters must have unique authkeys to be registered in Trento.

The Trento Agent package is available in the repositories of SUSE Linux Enterprise Server for SAP applications 15 (SP4 or higher) or SUSE Linux Enterprise Server for SAP applications 16.0.

3.3. Network requirements

Required inbound connectivity:

  • From any Trento Agent host to Trento Server at port TCP/80 (HTTP), or TCP/443 (HTTPS) if SSL is enabled.

  • From any Trento Agent host to Trento Server at port TCP/5672 (Advanced Message Queuing Protocol or AMQP)

  • From the user network to Trento Server at port TCP/80 (HTTP), or TCP/443 (HTTPS) if SSL is enabled.

  • If the Trento MCP Server is installed and enabled:

    • For a Kubernetes deployment, from the MCP client to the Trento Server ingress at TCP/80 or TCP/443. Internally, the MCP Server Pod uses TCP/5000 and TCP/8080 if the health check is enabled.

    • For a systemd deployment, from the user network to Trento MCP Server at TCP/5000.

  • Optionally: From the user network to Trento Server at ports TCP/4000, TCP/4001 and TCP/8080 (health checks for web, wanda and MCP, respectively).

  • From Prometheus server, when it exists, to each Trento Agent host at the port used by the Node Exporter.

3.4. SAP requirements

An SAP system must run on a HANA database to be discovered by Trento. In addition, the parameter dbs/hdb/dbname must be set in the DEFAULT profile of the SAP system to the correct database (tenant) name.

The agent must be installed in all the hosts that are part of the SAP system architecture. Particularly:

  • The host where the ASCS instance is running

  • The host where the ERS instance, if it exists, is running

  • All the hosts where an application server instance is running

  • All the database hosts

3.5. Cluster requirements

The initial discovery of a Pacemaker cluster requires all cluster nodes to be online. After the cluster is discovered, all nodes can be stopped and Trento continues to discover the cluster.

4. Installation

4.1. Installing Trento Server

Trento Server can be deployed in different ways depending on your infrastructure and requirements.

Supported deployment methods:

4.1.1. Kubernetes deployment

The subsection uses the following placeholders:

  • TRENTO_SERVER_HOSTNAME: the host name used by the end user to access the console.

  • ADMIN_PASSWORD: the password of the admin user created during the installation process.

    The password must meet the following requirements:

    • minimum length of 8 characters

    • the password must not contain 3 identical numbers or letters in a row (for example, 111 or aaa)

    • the password must not contain 4 sequential numbers or letters (for example, 1234, abcd, ABCD)

By default, the provided Helm chart uses Traefik as ingress class
Main usages are related to:

  • path rewriting

  • endpoint protection

Search for Traefik specific usage scenarios on GitHub. In case another ingress controller is used, adapt accordingly.
Installing Trento Server on an existing Kubernetes cluster

Trento Server consists of a several components delivered as container images and intended for deployment on a Kubernetes cluster. A manual production-ready deployment of these components requires Kubernetes knowledge. Customers without in-house Kubernetes expertise and those who want to try Trento with a minimum of effort, can use the Trento Helm chart. This approach automates the deployment of all the required components on a single Kubernetes cluster node. You can use the Trento Helm chart to install Trento Server on a existing Kubernetes cluster as follows:

The examples in this section do not specify a Kubernetes namespace for simplicity. By default, Helm installs to the default namespace.

For production deployments, create and use a dedicated namespace.

Example:

kubectl create namespace trento
helm upgrade \
   --install trento-server oci://registry.suse.com/trento/trento-server \
   --namespace trento \
   ...

The examples in this section deliver an installation of Trento Server without Prometheus. If you want to have Prometheus installed and enabled along Trento Server refer to Prometheus integration.

  1. Install Helm:

    curl https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 | bash

  2. Connect Helm to an existing Kubernetes cluster.

  3. Use Helm to install Trento Server with the Trento Helm chart:

    helm upgrade \
   --install trento-server oci://registry.suse.com/trento/trento-server \
   --set global.trentoWeb.origin=TRENTO_SERVER_HOSTNAME \
   --set trento-web.adminUser.password=ADMIN_PASSWORD \
   --set prometheus.enabled=false

    Where:

    global.trentoWeb.origin

    Uses the provided hostname (for example, trento.example.com) to configure internal functionalities such as the interactive API portal, websockets, or certificate generation.

    trento-web.adminUser.password

    Sets the initial password for the default admin account to access the Trento console.

    prometheus.enabled

    Enables or disables the deployment of Prometheus. For more information, see Prometheus integration.

  4. To verify that the Trento Server installation was successful, open the URL of the Trento Web (http://TRENTO_SERVER_HOSTNAME) from a workstation on the SAP administrator’s LAN.

Installing Trento Server on K3s

If you do not have a Kubernetes cluster, or you have one but you do not want to use it for Trento, you can use SUSE Rancher’s K3s as an alternative. To deploy Trento Server on K3s, you need a server or VM (see Trento Server requirements for minimum requirements) and follow the steps in the following procedure.

The following procedure deploys Trento Server on a single-node K3s cluster. Note that this setup is not recommended for production use.

  1. Log in to the Trento Server host.

  2. Install K3s either as root or a non-root user.

    • Installing as user root:

      curl -sfL https://get.k3s.io | INSTALL_K3S_SKIP_SELINUX_RPM=true sh

    • Installing as a non-root user:

      curl -sfL https://get.k3s.io | INSTALL_K3S_SKIP_SELINUX_RPM=true sh -s - --write-kubeconfig-mode 644

  3. Install Helm as root.

    curl https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 | bash

  4. Set the KUBECONFIG environment variable for the same user that installed K3s:

    export KUBECONFIG=/etc/rancher/k3s/k3s.yaml

  5. With the same user that installed K3s, install Trento Server using the Helm chart:

    helm upgrade \
   --install trento-server oci://registry.suse.com/trento/trento-server \
   --set global.trentoWeb.origin=TRENTO_SERVER_HOSTNAME \
   --set trento-web.adminUser.password=ADMIN_PASSWORD \
   --set prometheus.enabled=false

    Where:

    global.trentoWeb.origin

    Uses the provided hostname (for example, trento.example.com) to configure internal functionalities such as the interactive API portal, websockets, or certificate generation.

    trento-web.adminUser.password

    Sets the initial password for the default admin account to access the Trento console.

    prometheus.enabled

    Enables or disables the deployment of Prometheus. For more information, see Prometheus integration.

  6. Monitor the creation and start-up of the Trento Server pods, and wait until they are ready and running:

    watch kubectl get pods

    All pods must be in the ready and running state.

  7. Log out of the Trento Server host.

  8. To verify that the Trento Server installation was successful, open the URL of the Trento Web (http://TRENTO_SERVER_HOSTNAME) from a workstation on the SAP administrator’s LAN.

Deploying Trento Server on selected nodes

If you use a multi-node Kubernetes cluster, it is possible to deploy Trento Server images on selected nodes by specifying the field nodeSelector in the helm upgrade command as follows:

 helm upgrade \
   --install trento-server oci://registry.suse.com/trento/trento-server \
   --set global.trentoWeb.origin=TRENTO_SERVER_HOSTNAME \
   --set trento-web.adminUser.password=ADMIN_PASSWORD \
   --set postgresql.primary.nodeSelector.LABEL=VALUE \
   --set trento-web.nodeSelector.LABEL=VALUE \
   --set prometheus.enabled=false

Replace LABEL and VALUE with the actual label key and value of your target node.

Enabling email alerts

Email alerting feature notifies the SAP Basis administrator about important changes in the SAP Landscape being monitored by Trento.

The reported events include the following:

  • Host heartbeat failed

  • Cluster health detected critical

  • Database health detected critical

  • SAP System health detected critical

This feature is disabled by default. It can be enabled at installation time or anytime at a later stage. In both cases, the procedure is the same and uses the following placeholders:

SMTP_SERVER

The SMTP server designated to send email alerts

SMTP_PORT

Port on the SMTP server

SMTP_USER

User name to access SMTP server

SMTP_PASSWORD

Password to access SMTP server

ALERTING_SENDER

Sender email for alert notifications

ALERTING_RECIPIENT

Email address to receive alert notifications.

The command to enable email alerts is as follows:

helm upgrade \
   --install trento-server oci://registry.suse.com/trento/trento-server \
   --set global.trentoWeb.origin=TRENTO_SERVER_HOSTNAME \
   --set trento-web.adminUser.password=ADMIN_PASSWORD \
   --set prometheus.enabled=false \
   --set trento-web.alerting.enabled=true \
   --set trento-web.alerting.smtpServer=SMTP_SERVER \
   --set trento-web.alerting.smtpPort=SMTP_PORT \
   --set trento-web.alerting.smtpUser=SMTP_USER \
   --set trento-web.alerting.smtpPassword=SMTP_PASSWORD \
   --set trento-web.alerting.sender=ALERTING_SENDER \
   --set trento-web.alerting.recipient=ALERTING_RECIPIENT
Enabling SSL

Ingress may be used to provide SSL termination for the Web component of Trento Server. This would allow to encrypt the communication from the agent to the server, which is already secured by the corresponding API key. It would also allow HTTPS access to the Web console with trusted certificates.

Configuration must be done in the tls section of the values.yaml file of the chart of the Trento Server Web component.

For details on the required Ingress setup and configuration, refer to: https://kubernetes.io/docs/concepts/services-networking/ingress/. Particularly, refer to section https://kubernetes.io/docs/concepts/services-networking/ingress/#tls for details on the secret format in the YAML configuration file.

Additional steps are required on the Agent side.

4.1.2. systemd deployment

A systemd-based installation of the Trento Server using RPM packages can be performed manually on the latest supported versions of SUSE Linux Enterprise Server for SAP applications, from 15 SP4 up to 16. For installations on service packs other than the current one, make sure to update the repository URL as described in the relevant notes throughout this guide.

List of dependencies
Install Trento dependencies
Install PostgreSQL

The current instructions are tested with the following PostgreSQL versions:

SUSE Linux Enterprise Server for SAP applications PostgreSQL Version

15 SP4

14.10

15 SP5

15.5

15 SP6

16.9

15 SP7

17.5

16.0

17.6

Using a different version of PostgreSQL may require different steps or configurations, especially when changing the major number. For more details, refer to the official PostgreSQL documentation.

  1. Install PostgreSQL server:

    sudo zypper install postgresql-server

  2. Enable and start PostgreSQL server:

    sudo systemctl enable --now postgresql
Configure PostgreSQL

  1. Start psql with the postgres user to open a connection to the database:

    sudo su - postgres
psql

  2. Initialize the databases in the psql console:

    CREATE DATABASE wanda;
CREATE DATABASE trento;
CREATE DATABASE trento_event_store;

  3. Create the users:

    The values WANDA_USER, WANDA_PASSWORD, TRENTO_USER, and WEB_PASSWORD are placeholders. Replace them with your own secure values before running these commands.

    		 
    CREATE USER WANDA_USER WITH PASSWORD 'WANDA_PASSWORD';
CREATE USER TRENTO_USER WITH PASSWORD 'WEB_PASSWORD';

  4. Grant required privileges to the users and close the connection:

    \c wanda
GRANT ALL ON SCHEMA public TO WANDA_USER;
\c trento
GRANT ALL ON SCHEMA public TO TRENTO_USER;
\c trento_event_store
GRANT ALL ON SCHEMA public TO TRENTO_USER;
\q

  5. Exit the postgres user session:

    exit

  6. Allow the PostgreSQL database to receive connections to the respective databases and users. To do this, add the following to /var/lib/pgsql/data/pg_hba.conf:

    The pg_hba.conf file works sequentially. This means that the rules on the top have preference over the ones below. The following example shows a permissive address range. So for this to work, the new entries must be written at the top of the host section. For further information, refer to the pg_hba.conf documentation.

    		 
    host   wanda                      WANDA_USER    0.0.0.0/0     scram-sha-256
host   trento,trento_event_store  TRENTO_USER   0.0.0.0/0     scram-sha-256

  7. Allow PostgreSQL to bind on all network interfaces in /var/lib/pgsql/data/postgresql.conf by changing the following line:

    listen_addresses = '*'

  8. Restart PostgreSQL to apply the changes:

    sudo systemctl restart postgresql
Install RabbitMQ

  1. Install RabbitMQ server:

    sudo zypper install rabbitmq-server

  2. Allow connections from external hosts by modifying /etc/rabbitmq/rabbitmq.conf, so the Trento-agent can reach RabbitMQ:

    listeners.tcp.default = 5672

  3. If firewalld is running, add a rule to firewalld:

    sudo firewall-cmd --zone=public --add-port=5672/tcp --permanent
sudo firewall-cmd --reload

  4. Enable the RabbitMQ service:

    sudo systemctl enable --now rabbitmq-server
Configure RabbitMQ

To configure RabbitMQ for a production system, follow the official suggestions in the RabbitMQ guide.

  1. Create a new RabbitMQ user:

    The values TRENTO_USER and TRENTO_USER_PASSWORD are placeholders. Replace them with your own secure values before running these commands.

    		 
    sudo rabbitmqctl add_user TRENTO_USER TRENTO_USER_PASSWORD

  2. Create a virtual host:

    sudo rabbitmqctl add_vhost vhost

  3. Set permissions for the user on the virtual host:

    sudo rabbitmqctl set_permissions -p vhost TRENTO_USER ".*" ".*" ".*"
Install Trento using RPM packages

The trento-web and trento-wanda packages are available by default on supported SUSE Linux Enterprise Server for SAP applications distributions.

Install Trento web, wanda and checks:

sudo zypper install trento-web trento-wanda
Create the configuration files

Both services depend on respective configuration files. They must be placed in /etc/trento/trento-web and /etc/trento/trento-wanda respectively, and examples of how to modify them are available in /etc/trento/trento-web.example and /etc/trento/trento-wanda.example.

You can create the content of the secret variables such as SECRET_KEY_BASE, ACCESS_TOKEN_ENC_SECRET and REFRESH_TOKEN_ENC_SECRET using openssl:

openssl rand -out /dev/stdout 48 | base64

  1. Create the /etc/trento/trento-web configuration file. For example:

    The values TRENTO_USER, TRENTO_USER_PASSWORD, and WEB_PASSWORD are placeholders. Replace them with your own secure values before running these commands.

    		 
    # /etc/trento/trento-web
AMQP_URL=amqp://TRENTO_USER:TRENTO_USER_PASSWORD@localhost:5672/vhost
DATABASE_URL=ecto://TRENTO_USER:WEB_PASSWORD@localhost/trento
EVENTSTORE_URL=ecto://TRENTO_USER:WEB_PASSWORD@localhost/trento_event_store
ENABLE_ALERTING=false
CHARTS_ENABLED=false
ADMIN_USER=admin
ADMIN_PASSWORD=trentodemo
ENABLE_API_KEY=true
PORT=4000
LOG_LEVEL=info
TRENTO_WEB_ORIGIN=trento.example.com
IPV4_OR_IPV6=ipv4
SECRET_KEY_BASE=some-secret
ACCESS_TOKEN_ENC_SECRET=some-secret
REFRESH_TOKEN_ENC_SECRET=some-secret
CHECKS_SERVICE_BASE_URL=/wanda
OAS_SERVER_URL=https://trento.example.com

    • The LOG_LEVEL variable sets how much detail Trento Web writes to the log. The default value is info. For more information, see Configuring log levels.

    • The TRENTO_WEB_ORIGIN variable configures internal functionalities such as the interactive API portal, websockets, or certificate generation.

      Ensure that a valid hostname, FQDN, or IP address is configured in TRENTO_WEB_ORIGIN when using HTTPS. Otherwise, websocket connections will fail, preventing real-time updates in the web interface.

    • The IPV4_OR_IPV6 variable defines whether the Trento Web service binds to an IPv4 or IPv6 address. Set it according to what is available on the host at the time the service starts. The accepted values are ipv4 and ipv6 (case-insensitive). If the variable is not set, Trento Web binds to IPv4.

    • The ADMIN_PASSWORD variable must meet the following requirements:

      • Minimum of 8 characters

      • The password not contain 3 consecutive identical numbers or letters (for example, 111 or aaa)

      • The password must not contain 4 consecutive numbers or letters (for example, 1234, abcd, ABCD)

    • The ENABLE_ALERTING variable enables the alerting system to receive email notifications. Set ENABLE_ALERTING to true and add additional variables to the /etc/trento/trento-web to enable the feature:

      # /etc/trento/trento-web
ENABLE_ALERTING=true
ALERT_SENDER=<<SENDER_EMAIL_ADDRESS>>
ALERT_RECIPIENT=<<RECIPIENT_EMAIL_ADDRESS>>
SMTP_SERVER=<<SMTP_SERVER_ADDRESS>>
SMTP_PORT=<<SMTP_PORT>>
SMTP_USER=<<SMTP_USER>>
SMTP_PASSWORD=<<SMTP_PASSWORD>>

  2. Create the /etc/trento/trento-wanda configuration file. For example:

    The values WANDA_USER, WANDA_PASSWORD, TRENTO_USER, and TRENTO_USER_PASSWORD are placeholders. Replace them with your own secure values before running these commands.

    		 
    # /etc/trento/trento-wanda
CORS_ORIGIN=http://localhost
AMQP_URL=amqp://TRENTO_USER:TRENTO_USER_PASSWORD@localhost:5672/vhost
DATABASE_URL=ecto://WANDA_USER:WANDA_PASSWORD@localhost/wanda
PORT=4001
LOG_LEVEL=info
IPV4_OR_IPV6=ipv4
SECRET_KEY_BASE=some-secret
OAS_SERVER_URL=https://trento.example.com/wanda
AUTH_SERVER_URL=http://localhost:4000

    Ensure the IPV4_OR_IPV6 variable matches the value you configured for the Trento Web service in the previous step.

  3. Secure the configuration files.

    To protect sensitive information, the configuration files must have 600 permissions so that only the root user can read them:

    sudo chmod 600 /etc/trento/trento-web
sudo chmod 600 /etc/trento/trento-wanda
Start the services

In some SUSE Linux Enterprise Server for SAP applications environments, SELinux may be enabled and set to enforcing mode by default. If Trento services fail to start or show permission-related errors, check the SELinux status:

sudo getenforce

If SELinux is set to enforcing, switch it to permissive mode either temporarily or permanently:

  • Temporary change (until reboot):

    sudo setenforce 0

  • Permanent change (persists after reboot):

    Edit /etc/selinux/config and set:

    SELINUX=permissive

Enable and start the services:

sudo systemctl enable --now trento-web trento-wanda
Monitor the services

Use journalctl to check if the services are up and running correctly. For example:

sudo journalctl -fu trento-web
Check the health status of Trento Web and Trento Wanda

You can check if Trento Web and Trento Wanda services function correctly by accessing the healthz and readyz API.

If Trento web and wanda are ready, and the database connection is set up correctly, the output should be as follows:

{"ready":true}{"database":"pass"}

  1. Check Trento Web health status using curl:

    curl http://localhost:4000/api/readyz
    curl http://localhost:4000/api/healthz

  2. Check Trento Wanda health status using curl:

    curl http://localhost:4001/api/readyz
    curl http://localhost:4001/api/healthz
Install and configure NGINX

  1. Install NGINX package:

    sudo zypper install nginx

  2. If firewalld is running, add firewalld rules for HTTP and HTTPS:

    sudo firewall-cmd --zone=public --add-service=https --permanent
sudo firewall-cmd --zone=public --add-service=http --permanent
sudo firewall-cmd --reload

  3. Start and enable NGINX:

    sudo systemctl enable --now nginx

  4. Create a /etc/nginx/conf.d/trento.conf Trento configuration file:

    map $http_upgrade $connection_upgrade {
  default upgrade;
  '' close;
}

upstream web {
  server 127.0.0.1:4000 max_fails=5 fail_timeout=60s;
}

upstream wanda {
  server 127.0.0.1:4001 max_fails=5 fail_timeout=60s;
}

server {
    # Redirect HTTP to HTTPS
    listen 80;
    server_name trento.example.com;
    return 301 https://$host$request_uri;
}

server {
    server_name trento.example.com;
    listen 443 ssl;

    ssl_certificate /etc/nginx/ssl/certs/trento.crt;
    ssl_certificate_key /etc/ssl/private/trento.key;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384';
    ssl_prefer_server_ciphers on;
    ssl_session_cache shared:SSL:10m;

    # Wanda rule
    location /wanda/  {
        allow all;

        # Proxy Headers
        proxy_http_version 1.1;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host;
        proxy_set_header X-Cluster-Client-Ip $remote_addr;

        # Important Websocket Bits!
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";

        # Add final slash to replace the location path value by the value in proxy_pass
        # https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_pass
        proxy_pass http://wanda/;
    }

    # Web rule
    location / {
        # this endpoint should not be accessible publicly
        # it is internally used by wanda to introspect access tokens and personal access tokens
        location /api/session/token/introspect {
            deny all;
            return 404;
        }

        allow all;

        # Proxy Headers
        proxy_http_version 1.1;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host;
        proxy_set_header X-Cluster-Client-Ip $remote_addr;

        # The Important Websocket Bits!
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";

        proxy_pass http://web;
    }
}

    The previous example reaches Trento Web and Trento Wanda over IPv4. If you set IPV4_OR_IPV6=ipv6 in the service configuration files, adjust the NGINX configuration accordingly:

    • Change the upstream addresses from 127.0.0.1 to [::1].

    • Add IPv6 listeners to the server blocks: listen [::]:80; and listen [::]:443 ssl;.
Prepare SSL certificate for NGINX

Create or provide a certificate for NGINX to enable SSL for Trento. Choose one of the following methods:

Create a self-signed certificate

Manually generate a self-signed certificate and ensure it is trusted by the system.

  1. Generate a self-signed certificate:

    Adjust subjectAltName = DNS:trento.example.com by replacing trento.example.com with your domain and change the value 5 to the number of days for which you need the certificate to be valid. For example, -days 365 for one year.

    		 
    openssl req -newkey rsa:2048 --nodes -keyout trento.key -x509 -days 5 -out trento.crt -addext "subjectAltName = DNS:trento.example.com"

  2. Copy the generated trento.key to a location accessible by NGINX:

    sudo cp trento.key /etc/ssl/private/trento.key

  3. Create a directory for the generated trento.crt file. The directory must be accessible by NGINX:

    sudo mkdir -p /etc/nginx/ssl/certs/

  4. Copy the generated trento.crt file to the created directory:

    sudo cp trento.crt /etc/nginx/ssl/certs/trento.crt

  5. Ensure the self-signed certificate is trusted:

    1. Convert trento.crt to the PEM format:

      openssl x509 -in trento.crt -out trento.pem -outform PEM

    2. Copy the certificate in PEM format to /etc/pki/trust/anchors/:

      sudo cp trento.pem /etc/pki/trust/anchors/

    3. Run the update-ca-certificates command:

      sudo update-ca-certificates

  6. Check the NGINX configuration:

    sudo nginx -t

    If the configuration is correct, the output should be as follows:

    nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

    If there are issues with the configuration, the output indicates what needs to be adjusted.

  7. Enable NGINX:

    sudo systemctl restart nginx
Create a signed certificate with Let’s Encrypt using PackageHub repository

Automate obtaining a signed certificate with Let’s Encrypt and configure NGINX to use it.

  1. Enable the PackageHub repository (replace x.x with your OS version, for example 15.7):

    sudo SUSEConnect --product PackageHub/x.x/x86_64
sudo zypper refresh

  2. Find the Certbot NGINX plug-in package available in your current Service Pack:

    zypper search certbot-nginx

    Example output:

    S  | Name                    | Summary                  | Type
---+-------------------------+--------------------------+--------
   | python313-certbot-nginx | Nginx plugin for Certbot | package

  3. Install Certbot and its NGINX plug-in. Use the specific package name returned in the output of the previous step. For example:

    sudo zypper install certbot python313-certbot-nginx

  4. Obtain a certificate and configure NGINX with Certbot:

    Replace trento.example.com with your domain. For more information, refer to Certbot instructions for NGINX

    		 
    sudo certbot --nginx -d trento.example.com

    Certbot certificates are valid for 90 days. Refer to the above link for details on how to renew certificates.
Accessing the trento-web UI

Pin the browser to https://trento.example.com. You should be able to login using the credentials specified in the ADMIN_USER and ADMIN_PASSWORD environment variables.

4.2. Installing Trento Agents

Before you can install a Trento Agent, you must obtain the API key of your Trento Server. Proceed as follows:

  1. Open the URL of the Trento Web console. It prompts you for a user name and password:

    trento-web-login

  2. Enter the credentials for the admin user (specified during installation of Trento Server).

  3. Click Login.

  4. When you are logged in, go to Settings:

    trento-settings-apikey

  5. Click the Copy button to copy the key to the clipboard.

Install the Trento Agent on an SAP host and register it with the Trento Server as follows:

  1. Install the package:

    sudo zypper ref
sudo zypper install trento-agent

    A configuration file named /agent.yaml is created under /etc/trento/ in SUSE Linux Enterprise Server for SAP applications 15 or under /usr/etc/trento/ in SUSE Linux Enterprise Server for SAP applications 16.

    To protect sensitive information, the agent.yaml configuration file is automatically created with 600 permissions so that only the root user can read or modify it.

  2. Open the configuration file and uncomment (remove the # character) the entries for facts-service-url, server-url and api-key. Update the values if necessary:

    • facts-service-url: the address of the AMQP RabbitMQ service used for communication with the checks engine (wanda). The correct value of this parameter depends on how Trento Server was deployed.

      In a Kubernetes deployment, it is amqp://trento:trento@TRENTO_SERVER_HOSTNAME:5672/. If the default RabbitMQ username and password (trento:trento) were updated using Helm, the parameter must use a user-defined value.

      In a systemd deployment, the correct value is amqp://TRENTO_USER:TRENTO_USER_PASSWORD@TRENTO_SERVER_HOSTNAME:5672/vhost. If TRENTO_USER and TRENTO_USER_PASSWORD have been replaced with custom values, you must use them.

    • server-url: URL for the Trento Server (http://TRENTO_SERVER_HOSTNAME)

    • api-key: the API key retrieved from the Web console

    • prometheus-mode: Determines how metrics are collected. Valid values are pull (default) for node_exporter-based collection, or push for Grafana Alloy-based collection. See Prometheus metrics configuration for details.

  3. If SSL termination has been enabled on the server side, you can encrypt the communication from the agent to the server as follows:

    1. Provide an HTTPS URL instead of an HTTP one.

    2. Import the certificate from the Certificate Authority that has issued your Trento Server SSL certificate into the Trento Agent host as follows:

      1. Copy the CA certificate in the PEM format to /etc/pki/trust/anchors/. If the CA certificate is in the CRT format, convert it to PEM using the following openssl command:

        openssl x509 -in mycert.crt -out mycert.pem -outform PEM

      2. Run the update-ca-certificates command.

  4. Start the Trento Agent:

    sudo systemctl enable --now trento-agent

  5. Check the status of the Trento Agent:

    sudo systemctl status trento-agent

● trento-agent.service - Trento Agent service
     Loaded: loaded (/usr/lib/systemd/system/trento-agent.service; enabled; vendor preset: disabled)
     Active: active (running) since Wed 2021-11-24 17:37:46 UTC; 4s ago
   Main PID: 22055 (trento)
      Tasks: 10
     CGroup: /system.slice/trento-agent.service
             ├─22055 /usr/bin/trento agent start --consul-config-dir=/srv/consul/consul.d
             └─22220 /usr/bin/ruby.ruby2.5 /usr/sbin/SUSEConnect -s

[...]

  6. Repeat this procedure on all SAP hosts that you want to monitor.

4.2.1. Prometheus metrics configuration

Trento collects system metrics (CPU, memory) using different exporters depending on the operating system version:

  • SUSE Linux Enterprise Server for SAP applications 15: Uses node_exporter in pull mode by default.

  • SUSE Linux Enterprise Server for SAP applications 16: Uses Grafana Alloy in push mode.

SUSE Linux Enterprise Server for SAP applications 15 SP7 also provides Grafana Alloy as an optional package. Users who prefer to use Alloy on SUSE Linux Enterprise Server for SAP applications 15 SP7 can manually install and configure it following the same procedure described for SUSE Linux Enterprise Server for SAP applications 16.

When using Grafana Alloy (on SUSE Linux Enterprise Server for SAP applications 16 or optionally on SUSE Linux Enterprise Server for SAP applications 15 SP7), additional configuration is required. See the Prometheus integration documentation for details on configuring Alloy.

The following parameters control the metrics collection behavior:

prometheus-mode

Determines how metrics are collected. Valid values are pull (default) for node_exporter-based collection, or push for Grafana Alloy-based collection.

prometheus-exporter-name

The name used to identify the exporter in Prometheus. Defaults to node_exporter in pull mode or grafana_alloy in push mode.

Pull mode parameters (SUSE Linux Enterprise Server for SAP applications 15)

These parameters apply when prometheus-mode is set to pull (the default):

prometheus-node-exporter-target

Specifies IP address and port for the node exporter as <ip_address>:<port>. In situations where the host has multiple IP addresses and/or the exporter is listening to a port different from the default one, configuring this setting enables Prometheus to connect to the correct IP address and port of the host. If not set, Prometheus uses the lowest IPv4 address discovered in the host with default port 9100.

The legacy parameter name node-exporter-target is still supported for backward compatibility.
Push mode parameters (Grafana Alloy)

These parameters apply when prometheus-mode is set to push, which is required for SUSE Linux Enterprise Server for SAP applications 16 and optional for SUSE Linux Enterprise Server for SAP applications 15 SP7. They are used both by the agent and by the trento-agent generate alloy command to produce the Grafana Alloy configuration:

prometheus-url

The Prometheus remote write endpoint URL where Alloy will push metrics. Required in push mode.

prometheus-scrape-interval

The interval at which Alloy scrapes local metrics. Defaults to 15s. Used by trento-agent generate alloy only.

prometheus-auth

The authentication method for the Prometheus remote write endpoint. Valid values are none, basic (default), bearer, or mtls. Used by trento-agent generate alloy only.

prometheus-auth-username

Username for basic authentication. Required when prometheus-auth is set to basic. Used by trento-agent generate alloy only.

prometheus-auth-password

Password for basic authentication. Required when prometheus-auth is set to basic. Used by trento-agent generate alloy only.

prometheus-auth-bearer-token

Bearer token for authentication. Required when prometheus-auth is set to bearer. Used by trento-agent generate alloy only.

prometheus-tls-ca-cert

Path to CA certificate file for TLS verification. Used by trento-agent generate alloy only.

prometheus-tls-client-cert

Path to client certificate file for mTLS authentication. Required when prometheus-auth is set to mtls. Used by trento-agent generate alloy only.

prometheus-tls-client-key

Path to client private key file for mTLS authentication. Required when prometheus-auth is set to mtls. Used by trento-agent generate alloy only.

The trento-agent generate alloy command reads these parameters to generate the Grafana Alloy configuration file. See the Prometheus integration documentation for detailed instructions on deploying the generated configuration.

4.3. Automated Installation with Ansible

You can perform an automated installation of Trento using RPM packages with Ansible playbooks provided by the ansible-trento package.

4.3.1. Supported operating systems

Execute the playbooks only on target nodes running SUSE Linux Enterprise Server for SAP applications 15-SP5 and higher, or 16.0 and higher. The supported SUSE Linux Enterprise Server for SAP applications systems for the control node are the same. However, the requirements for the control nodes are less strict. You can use any operating system if the installed Ansible version is compatible with the Python interpreter available on the managed target nodes. Refer to the support matrix in the Ansible documentation.

Currently, Trento Server cannot be installed with the Ansible playbook on target nodes running SUSE Linux Enterprise Server for SAP applications 15 SP5.

4.3.2. Requirements

As a prerequisite, enable the following modules on SUSE Linux Enterprise Server for SAP applications 15. Replace x with your SP version.

Control node module requirements:

  • Enable the Systems Management module (not needed for SP5).

    sudo SUSEConnect -p sle-module-systems-management/15.x/x86_64

    This repository contains Ansible.

Target node module requirements:

  • Enable the Python 3 module.

    sudo SUSEConnect -p sle-module-python3/15.x/x86_64

    This repository contains essential Python dependencies.

  • Enable SUSE Package Hub.

    sudo SUSEConnect -p PackageHub/15.x/x86_64

    This module is optional. Use it when you need to install Prometheus.

Additionally, install the following packages regardless of the operating system version.

Control node package requirements:

  • Install Ansible.

    sudo zypper install ansible

Target node package requirements:

  • Install Python version 3.11 or higher.

    sudo zypper install python311

4.3.3. Installation

For SLES-based operating systems, install the ansible-trento package using Zypper.

sudo zypper install ansible-trento

4.3.4. Components

The playbooks comprise the following components.

Trento Server components:

web

The main component of the Trento Server, containing the backend and frontend.

wanda

Checks engine component.

Trento Agent:

agent

Agent collecting information and processing commands, installed on SAP infrastructure host machines.

Third-party dependencies:

PostgreSQL

Database server.

RabbitMQ

Messaging broker.

Prometheus

Metrics collecting and processing server.

NGINX

HTTP server used as reverse proxy.

Diagnostics tooling:

supportutils

Installs the SUSE supportutils package and the Trento-specific supportutils-plugin-trento plug-in on Trento Server and Trento Agent hosts, so that supportconfig can collect Trento diagnostics.

The ansible-trento package provides an Ansible role for every one of these components.

4.3.5. Playbooks overview

Trento provides the following playbooks:

server

Installs Trento Server components (Web and Wanda) along with the supporting third-party application dependencies.

agent

Installs and configures the Trento Agent.

site

Performs a full Trento installation. It installs both the server components and agents. An additional feature of this playbook is that the API key for the agents is automatically retrieved from the Trento Server and passed to the deployed agents.

cleanup

Tries to undo operations performed by executing the other playbooks. It only reverts a subset of the operations. Consult the code of that playbook for full details.

4.3.6. Setting up the inventory

Prepare an inventory file for your Ansible deployment. Create an inventory.yml file defining the IP addresses or domain names of the target nodes for each group expected in the playbooks. The inventory must have the following structure:

all:
  children:
    trento_server:
      hosts:
        vitellone:
          ansible_host: "your-host"
          ansible_user: "your-user"
          ansible_ssh_private_key_file: "/home/user/.ssh/id_rsa"
    postgres_hosts:
      hosts:
        vitellone:
          ansible_host: "your-host"
          ansible_user: "your-user"
          ansible_password: "your-password"
    rabbitmq_hosts:
      hosts:
        vitellone:
          ansible_host: "your-host"
          ansible_user: "your-user"
          ansible_ssh_private_key_file: "/home/user/.ssh/id_rsa"
    prometheus_hosts:
      hosts:
        vitellone:
          ansible_host: "your-host"
          ansible_user: "your-user"
          ansible_ssh_private_key_file: "/home/user/.ssh/id_rsa"
   agents:
     hosts:
       vitellone:
          ansible_host: "your-host"
          ansible_user: "your-user"
          ansible_password: "your-password"

In this example, every component is installed on the same host, named vitellone. Adapt this example to your concrete case.

You can skip certain host groups if you are not provisioning them with ansible-trento. For example, skip defining postgres_hosts if you use a PostgreSQL installation managed by an external team. If you only use the agent playbook, define only agents in your inventory. Refer to the Configuration section to see how to make ansible-trento skip provisioning a given component.

In the example above, a mixture of authentication methods accesses the target nodes. When using SSH to connect (ansible_ssh_private_key_file), ensure all target nodes contain the public key of the control node. To copy your public key from the control node to the target node, use the following command:

ssh-copy-id USERNAME@IP_OR_DOMAIN_NAME_OF_THE_NODE

4.3.7. Running the playbooks

To run a playbook, use the following command:

ansible-playbook -i PATH_TO_INVENTORY suse.trento.PLAYBOOK_NAME

Replace PLAYBOOK_NAME with one of the following: server, agent, or site.

4.3.8. Configuration

You can configure two types of variables: playbook-level and role-level variables. They differ in how you configure them and the scope of the changes they imply. We try to keep playbook-level variables to a minimum.

Playbook-level configuration

These variables affect how the playbooks execute. The available configuration options are:

provision_postgres

Whether to install and configure PostgreSQL.

provision_prometheus

Whether to install and configure Prometheus.

provision_rabbitmq

Whether to install and configure RabbitMQ.

provision_proxy

Whether to install and configure a reverse proxy like NGINX.

Supply playbook-level variables using --extra-vars or -e on the command line during every playbook execution:

ansible-playbook -i PATH_TO_INVENTORY suse.trento.site -e provision_postgres=false -e provision_rabbitmq=false

When disabling the provisioning of a Trento component, you must manually set the respective *_host role-level variables, which the playbook otherwise populates automatically. For example, if you specify -e provision_postgres=false when executing the server or site playbook, explicitly set trento_postgres_host in your inventory.
Role-level configuration

Almost all settings are configured via role-level variables. Set them in the inventory file under the vars: section:

all:
  children:
    trento_server:
      hosts: ...
    postgres_hosts:
      hosts: ...
    rabbitmq_hosts:
      hosts: ...
    prometheus_hosts:
      hosts: ...
    agents:
      hosts: ...

  vars:
    trento_server_name: "trento-deployment.example.com"
    trento_web_admin_password: "adminpassword"
    trento_web_postgres_password: "postgres"
    trento_wanda_postgres_password: "postgres"
    trento_rabbitmq_password: "guest"
    rproxy_ssl_cert: "SSL_CERTIFICATE_IN_BASE64"
    rproxy_ssl_key: "SSL_CERTIFICATE_KEY_IN_BASE64"

Certain role-level variables are mandatory.

For Trento Server, these are:

Name Description

trento_server_name

Domain name of the Trento web application.

trento_web_admin_password

Password of the admin user in Web component.

trento_web_postgres_password

Password of the PostgreSQL user used in Web component.

trento_wanda_postgres_password

Password of the PostgreSQL user used in Wanda component.

trento_rabbitmq_password

Password of the RabbitMQ user configured for the Trento project.

rproxy_ssl_cert

String with the content of the .crt file used by the reverse proxy for HTTPS.

rproxy_ssl_key

String with the content of the .key file used to generate the certificate.

For Trento Agent, they are:

Name Description

agent_web_api_key

API key for accessing the Trento Web collection endpoint.

The rest of the variables are optional. You can find the full listing on the Trento Ansible project page.

4.3.9. Support tooling

The server, agent, and site playbooks install the SUSE supportutils package together with the Trento-specific supportutils-plugin-trento plug-in. This allows supportconfig to collect Trento diagnostics on both Trento Server and Trento Agent hosts. The installation is performed by the supportutils role and is enabled by default; no additional opt-in is required.

Configuration

Override the following role-level variables in your inventory to change the default behavior:

Name Default Description

supportutils_enabled

true

Set to false to skip installation entirely.

supportutils_package_name

supportutils

Base SUSE diagnostics package name.

supportutils_plugin_package_name

supportutils-plugin-trento

Trento plug-in package name.

supportutils_update_cache

true

Refresh the Zypper cache before installing.

To disable installation on all hosts, set the variable in the vars: section of your inventory:

all:
  vars:
    supportutils_enabled: false
Generating a support archive

After the playbook runs, generate a support archive on any installed host with:

sudo supportconfig

The resulting tarball includes the Trento-specific data collected by the plug-in and can be attached to SUSE support cases.

Cleanup behavior

The cleanup playbook removes only the supportutils-plugin-trento package from Trento Server and Trento Agent hosts. The base supportutils package is intentionally retained, because it is general-purpose SUSE tooling that other diagnostic workflows may rely on.

4.3.10. Example scenarios

The playbooks in ansible-trento allow for different installation scenarios.

Every component on a dedicated node

The following inventory file installs every Trento component on a different host. It also enables and configures optional e-mail alerting:

all:
  children:
    trento_server:
      hosts:
        vitellone:
          ansible_host: "your-host"
          ansible_user: "your-user"
    postgres_hosts:
      hosts:
        vitellone-pg:
          ansible_host: "your-host"
          ansible_user: "your-user"
    rabbitmq_hosts:
      hosts:
        vitellone-mq:
          ansible_host: "your-host"
          ansible_user: "your-user"
    prometheus_hosts:
      hosts:
        vitellone-metrics:
          ansible_host: "your-host"
          ansible_user: "your-user"
    agents:
      hosts:
        hana01:
          ansible_host: "your-hana01-host"
          ansible_user: root
        hana02:
          ansible_host: "your-hana02-host"
          ansible_user: root

  vars:
    trento_server_name: "yourserver.com"
    trento_web_admin_password: "adminpassword"
    trento_web_postgres_password: "pass"
    trento_wanda_postgres_password: "wanda"
    trento_rabbitmq_password: "trento"
    rproxy_ssl_cert: |-
      -----BEGIN CERTIFICATE-----
      MIIEZDCCA0ygAwIBAgIUAue46Y/9kwT+zvPPW2xfuNv1+Z4wDQYJKoZIhvcNAQEL
      ...
      vzczKRPmQOQbiu02WM2hivWtPBH//A5N
      -----END CERTIFICATE-----
    rproxy_ssl_key: |-
      -----BEGIN PRIVATE KEY-----
      MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQC1L7Ddc6oYaNPC
      ...
      mpNiKDOPALNTs+Ukdkt5KlE=
      -----END PRIVATE KEY-----

    web_enable_alerting: true
    web_alert_sender: "trento@example.com"
    web_alert_recipient: "trento_maintainers@example.com"
    web_smtp_server: "smtp.example.com"
    web_smtp_port: 587
    web_smtp_user: "smtp_user"
    web_smtp_password: "stmp_pass"

Execute Ansible by running the following command:

ansible-playbook -i PATH_TO_INVENTORY suse.trento.site
Trento with externally managed PostgreSQL, RabbitMQ and Prometheus

The following inventory file does not provision PostgreSQL, RabbitMQ, or Prometheus.

There is no configuration for postgres_hosts, rabbitmq_hosts, and prometheus_hosts. Instead, explicit trento_postgres_host and trento_rabbitmq_host variables are configured.

 
all:
  children:
    trento_server:
      hosts:
        vitellone:
          ansible_host: "your-host"
          ansible_user: "your-user"
    agents:
      hosts:
        hana01:
          ansible_host: "your-hana01-host"
          ansible_user: root
        hana02:
          ansible_host: "your-hana02-host"
          ansible_user: root

  vars:
    trento_postgres_host: "yourexternalpg.com"
    trento_rabbitmq_host: "yourexternalrabbit.com:5671"

    trento_server_name: "your-servername.com"
    trento_web_admin_password: "adminpassword"
    trento_web_postgres_username: "postgres"
    trento_web_postgres_password: "trentoansible1"
    trento_wanda_postgres_username: "postgres"
    trento_wanda_postgres_password: "trentoansible1"
    trento_rabbitmq_username: "trentoansible"
    trento_rabbitmq_password: "trentoansible1"
    rproxy_ssl_cert: |-
      -----BEGIN CERTIFICATE-----
      MIIEZDCCA0ygAwIBAgIUAue46Y/9kwT+zvPPW2xfuNv1+Z4wDQYJKoZIhvcNAQEL
      ...
      vzczKRPmQOQbiu02WM2hivWtPBH//A5N
      -----END CERTIFICATE-----
    rproxy_ssl_key: |-
      -----BEGIN PRIVATE KEY-----
      MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQC1L7Ddc6oYaNPC
      ...
      mpNiKDOPALNTs+Ukdkt5KlE=
      -----END PRIVATE KEY-----

Execute Ansible using the following command:

ansible-playbook -i PATH_TO_INVENTORY suse.trento.site -e provision_postgres=false -e provision_rabbitmq=false -e provision_prometheus=false
Deploy only Trento agents

Use the following inventory file to install and configure only the Trento agents. You must explicitly specify the agent_web_api_key variable. Acquire this key manually before running the agent playbook alone.

all:
  children:
    agents:
      hosts:
        hana01:
          ansible_host: "your-hana01-host"
          ansible_user: root
        hana02:
          ansible_host: "your-hana02-host"
          ansible_user: root

  vars:
    agent_web_api_key: "yourserver.com"

Execute Ansible by specifying the agent playbook:

ansible-playbook -i PATH_TO_INVENTORY suse.trento.agent

Custom-tailored inventories are not a requirement. They are used only to highlight which parameters are needed in specific cases. You can easily use a single, fully populated inventory and run only a subset of the operations, such as installing only the agent or skipping the PostgreSQL installation. The playbook automatically picks up or skips variables in the inventory as appropriate for the desired execution configuration.

4.3.11. Reference

For more information, refer to the Trento Ansible project page.

5. Update

5.1. Updating Trento Server

The procedure to update Trento Server depends on the chosen deployment option: Kubernetes or systemd.

Consider the following when performing an update:

  • Before updating Trento Server, ensure that all the Trento Agents in the environment are supported by the target version. For more information, see section Compatibility matrix between Trento Server and Trento Agents.

  • When updating Trento to version 2.4 or higher, the admin password may need to be adjusted to follow the rules described in the User Management section.

In a Kubernetes deployment, you can use Helm to update Trento Server:

helm upgrade \
   --install trento-server oci://registry.suse.com/trento/trento-server \
   --set global.trentoWeb.origin=TRENTO_SERVER_HOSTNAME \
   --set trento-web.adminUser.password=ADMIN_PASSWORD \
   ...

If you have configured/enabled options, the Helm command must be adjusted accordingly. In this case, consider the following:

  • If you are using a version of Helm lower than 3.8.0, you need to set HELM_EXPERIMENTAL_OCI=1 in front of the helm command.

  • When updating Trento to version 2.0.0 or higher, an additional flag must be set in the Helm command:

    helm upgrade \
   --install trento-server oci://registry.suse.com/trento/trento-server \
   --set global.trentoWeb.origin=TRENTO_SERVER_HOSTNAME \
   --set trento-web.adminUser.password=ADMIN_PASSWORD \
   --set rabbitmq.auth.erlangCookie=$(openssl rand -hex 16)

  • When updating Trento to version 2.3 or higher, a new API key is generated and the configuration of all registered Trento Agents must be updated accordingly.

  • When updating to version 3.1 or higher, connection to Prometheus requires authentication. You must configure authentication to continue using Prometheus.

In a systemd deployment, you can use zypper to update Trento Server:

 zypper refresh
 zypper update trento-web
 zypper update trento-wanda
 systemctl restart trento-web
 systemctl restart trento-wanda

5.2. Updating Trento Checks

Configuration checks are an integral part of the checks engine, but they are delivered separately. This allows customers to update the checks catalog in their setup whenever updates to existing checks and new checks are released, without waiting for a new version release cycle.

The procedure of updating the configuration checks depends on the Trento Server deployment type: Kubernetes or systemd.

In a Kubernetes deployment, checks are delivered as a container image, and you can use Helm with the following options to pull the latest image:

  helm ... \
 --set trento-wanda.checks.image.tag=latest \
 --set trento-wanda.checks.image.repository=registry.suse.com/trento/trento-checks  \
 --set trento-wanda.checks.image.pullPolicy=Always \
 ...

In a systemd deployment, checks are delivered as an RPM package, and you can use Zypper to update your checks catalog:

sudo zypper ref
sudo zypper update trento-checks

5.3. Updating a Trento Agent

To update the Trento Agent, follow the procedure below:

  1. Log in to the Trento Agent host.

  2. Stop the Trento Agent:

    sudo systemctl stop trento-agent

  3. Install the new package:

    sudo zypper ref
sudo zypper install trento-agent

  4. Copy the file /etc/trento/agent.yaml.rpmsave to /etc/trento/agent.yaml. Make sure that entries facts-service-url, server-url, and api-key in /etc/trento/agent.yaml are correct.

  5. Start the Trento Agent:

    sudo systemctl start trento-agent

  6. Check the status of the Trento Agent:

    sudo systemctl status trento-agent
● trento-agent.service - Trento Agent service
   Loaded: loaded (/usr/lib/systemd/system/trento-agent.service; enabled; vendor preset: disabled)
   Active: active (running) since Wed 2021-11-24 17:37:46 UTC; 4s ago
 Main PID: 22055 (trento)
    Tasks: 10
   CGroup: /system.slice/trento-agent.service
           ├─22055 /usr/bin/trento agent start --consul-config-dir=/srv/consul/consul.d
           └─22220 /usr/bin/ruby.ruby2.5 /usr/sbin/SUSEConnect -s

[...]

  7. Check the version in the Hosts overview of the Trento UI (URL http://TRENTO_SERVER_HOSTNAME).

  8. Repeat this procedure in all Trento Agent hosts.

6. Uninstallation

6.1. Uninstalling Trento Server

The procedure to uninstall the Trento Server depends on the deployment type: Kubernetes or systemd. The section covers Kubernetes deployments.

If Trento Server was deployed manually, you need to uninstall it manually. If Trento Server was deployed using the Helm chart, you can also use Helm to uninstall it as follows:

helm uninstall trento-server

6.2. Uninstalling a Trento Agent

To uninstall a Trento Agent, perform the following steps:

  • Log in to the Trento Agent host.

  • Stop the Trento Agent:

    sudo systemctl stop trento-agent

  • Remove the package:

    sudo zypper remove trento-agent

7. Prometheus integration

Prometheus Server is a Trento Server component responsible for retrieving host metrics from the agent hosts and serving them to the web component. The web component renders some of these metrics as graphical charts in the details view of the registered hosts. Particularly: memory, CPU, filesystem and swap utilization. Note that metrics are stored in UTC in Prometheus Server; the web UI converts and renders chart axes and hover timestamps using each user’s preferred timezone.

7.1. Metrics collection overview

Trento supports two methods for collecting system metrics, depending on the operating system version running on your monitored hosts:

  • SUSE Linux Enterprise Server for SAP applications 15: Uses node_exporter in pull mode by default. Prometheus Server periodically scrapes metrics from each host’s node_exporter endpoint.

  • SUSE Linux Enterprise Server for SAP applications 16: Uses Grafana Alloy in push mode. Alloy collects metrics locally and pushes them to the Prometheus remote write endpoint.

SUSE Linux Enterprise Server for SAP applications 15 SP7 also provides Grafana Alloy as an optional package. Users who prefer to use Alloy on SUSE Linux Enterprise Server for SAP applications 15 SP7 can manually install and configure it following the same procedure described for SUSE Linux Enterprise Server for SAP applications 16.
In environments where at least one host uses Grafana Alloy (either SUSE Linux Enterprise Server for SAP applications 16 or SUSE Linux Enterprise Server for SAP applications 15 SP7 with Alloy manually configured), you must enable the Prometheus remote write endpoint. See Enabling Prometheus remote write for Grafana Alloy hosts for details.

7.2. Requirements for SUSE Linux Enterprise Server for SAP applications 15 hosts (pull mode)

The node_exporter must be installed and running in the agent hosts and Prometheus Server must be able to reach the agent hosts at the IP address and port that the node_exporter is bound to.

The IP address and port that Prometheus Server uses to reach the node_exporter can be changed by setting parameter prometheus-node-exporter-target with value <ip_address>:<port> in the agent configuration file. The legacy parameter name node-exporter-target is still supported for backward compatibility.

If the parameter is not set, Prometheus Server uses the lowest IPv4 address discovered in the host with default port 9100.

7.3. Requirements for SUSE Linux Enterprise Server for SAP applications 16 hosts (push mode)

SUSE Linux Enterprise Server for SAP applications 16 uses Grafana Alloy instead of node_exporter for metrics collection. In this mode:

  • Grafana Alloy must be installed and running on the agent hosts.

  • The Prometheus remote write endpoint must be enabled on Trento Server.

  • The Trento Agent generates the Alloy configuration using the trento-agent generate alloy command.

See Configuring Grafana Alloy for detailed setup instructions.

7.4. Kubernetes deployment

To enable Prometheus alongside Trento Server in a Kubernetes cluster, see Enabling Prometheus remote write for Grafana Alloy hosts.

In a Kubernetes cluster with multiple nodes, the user can select on which node to deploy Prometheus Server by adding the following flag to the Helm installation command:

--set prometheus.server.nodeSelector.LABEL=<value>

Where <value> is the label assigned to the node where the user wants Prometheus Server to be deployed.

7.5. systemd deployment

In a systemd deployment of Trento Server, you can choose between using an existing installation of Prometheus Server, installing a dedicated Prometheus Server instance, or not using Prometheus Server at all.

7.5.1. Use an existing installation

If you already have an existing Prometheus Server that you want to use with Trento Server, you must set CHARTS_ENABLED=true and PROMETHEUS_URL pointing to the right address and port in the Trento Web configuration file. You must restart restart the Trento Web service to enable the changes.

The lowest required Prometheus Server version is 2.28.0.

Use the section "Install Prometheus on SUSE Linux Enterprise Server for SAP applications" as a reference to adjust the Prometheus Server configuration.

7.5.2. Install Prometheus on SUSE Linux Enterprise Server for SAP applications

  1. Create the Prometheus user and group:

    groupadd --system prometheus
useradd -s /sbin/nologin --system -g prometheus prometheus

  2. Enable the SUSE Package Hub repository. Replace VERSION with the version of your operating system, for example, 15.7 or 16.0:

    SUSEConnect --product PackageHub/VERSION/x86_64
zypper refresh
    SUSE Package Hub packages are tested by SUSE but are not officially supported as part of the SUSE Linux Enterprise Server for SAP applications base product. Users should assess the suitability of these packages based on their own risk tolerance and support needs.

  3. Install Prometheus using Zypper:

    zypper install golang-github-prometheus-prometheus

  4. Configure Prometheus for Trento by replacing or updating the existing configuration at /etc/prometheus/prometheus.yml:

    global:
  scrape_interval: 30s
  evaluation_interval: 10s

scrape_configs:
  - job_name: "http_sd_hosts"
    honor_timestamps: true
    scrape_interval: 30s
    scrape_timeout: 30s
    scheme: http
    follow_redirects: true
    http_sd_configs:
      - follow_redirects: true
        refresh_interval: 1m
        url: http://localhost:4000/api/prometheus/targets
    the value of the url parameter above assumes that the Trento Web service is running in the same host as Prometheus Server.

  5. Enable and start the Prometheus service:

    systemctl enable --now prometheus

  6. If firewalld is running, allow Prometheus to be accessible and add an exception to firewalld:

    firewall-cmd --zone=public --add-port=9090/tcp --permanent
firewall-cmd --reload

  7. Set CHARTS_ENABLED=true and PROMETHEUS_URL=http://localhost:9090 in the Trento Web configuration file and restart the Trento Web service:

    systemctl restart trento-web
    the value of the PROMETHEUS_URL parameter above assumes that the Trento Web service is running in the same host as Prometheus Server.

7.5.3. Not using Prometheus Server

If you decide not to use Prometheus Server in your Trento installation, you must disable graphical charts in the UI by setting CHARTS_ENABLED=false in the Trento Web configuration file.

7.6. Enabling Prometheus remote write for Grafana Alloy hosts

If your environment includes at least one host using Grafana Alloy for metrics collection (either SUSE Linux Enterprise Server for SAP applications 16 or SUSE Linux Enterprise Server for SAP applications 15 SP7 with Alloy manually configured), you must enable the Prometheus remote write endpoint to receive pushed metrics.

The authentication type must be explicitly configured during installation or upgrade. Both the Helm chart and the Ansible playbook fail if the authentication type is left unconfigured, preventing an unprotected remote write endpoint from being silently exposed.

7.6.1. Kubernetes deployment

The Helm chart enables the Prometheus remote write receiver and deploys an NGINX sidecar container in the Prometheus pod to handle authentication. The Kubernetes Ingress routes traffic to the NGINX sidecar (port 8081) instead of directly to Prometheus (port 9090).

The NGINX sidecar protects the /prometheus/api/v1/write endpoint with HTTP Basic Auth. Other Prometheus routes (UI and query API) remain accessible without authentication.

To enable Prometheus with basic authentication, replace flag --set prometheus.enabled=false in the Helm installation command with the following:

--set prometheus.enabled=true \
--set prometheus.server.auth.type=basic \
--set prometheus.server.auth.basic.username=<username> \
--set prometheus.server.auth.basic.password=<password>

The auth.type field must be explicitly set to basic or none. An empty value causes the chart to fail validation.

To explicitly disable authentication (not recommended for production):

--set prometheus.server.auth.type=none
Running without authentication allows anyone with network access to push arbitrary metrics to Prometheus.

7.6.2. Ansible deployment

The Ansible playbook configures basic authentication on the existing NGINX reverse proxy. The reverse proxy terminates TLS and enforces basic auth on the Prometheus write endpoint.

Set the following inventory variables:

all:
  vars:
    trento_prometheus_auth: "basic"
    trento_prometheus_auth_username: <username>
    trento_prometheus_auth_password: <password>

The trento_prometheus_auth variable must be explicitly set to basic or none. The playbook fails if Prometheus is enabled and this variable is not set.

When set to basic, the playbook:

  • Validates that both username and password are provided

  • Generates an htpasswd file at /etc/nginx/prometheus.htpasswd

  • Configures the NGINX reverse proxy to enforce basic authentication on the /prometheus/api/v1/write endpoint

These credentials propagate automatically to the agent role, so agents deployed by the same playbook are configured to authenticate against the Prometheus endpoint without additional setup.

To explicitly disable authentication (not recommended for production):

all:
  vars:
    trento_prometheus_auth: "none"
Running without authentication allows anyone with network access to push arbitrary metrics to Prometheus.

7.6.3. Custom deployments

For custom deployments not using the official Helm chart or Ansible playbook, the Prometheus remote write endpoint must be enabled and exposed manually. The procedure below walks through how to add an authenticated /prometheus/ endpoint to an existing Trento Server installation that already has NGINX running as a TLS-terminating reverse proxy in front of the Trento Web and Trento Wanda services.

Grafana Alloy supports basic authentication, bearer token, and mutual TLS (mTLS) when pushing metrics. Configure your reverse proxy to validate credentials using the method of your choice. The example below uses HTTP basic authentication.

Enable the Prometheus remote write receiver

Prometheus must be started with the --web.enable-remote-write-receiver flag. How to set this flag depends on how Prometheus is managed on your platform (for example, via a sysconfig file, a systemd drop-in, or a command-line argument). In a sysconfig file scenario, add ARGS="--web.enable-remote-write-receiver" to the /etc/sysconfig/prometheus configuration file.

After enabling the flag, restart Prometheus and confirm it is healthy:

systemctl restart prometheus
systemctl status prometheus --no-pager
Create the htpasswd file for basic authentication

Generate the password hash with openssl passwd -apr1:

PROM_USER='prometheus'
PROM_PASS='<choose a strong password>'

printf '%s:%s\n' "$PROM_USER" \
  "$(openssl passwd -apr1 "$PROM_PASS")" \
  > /etc/nginx/prometheus.htpasswd

chown root:nginx /etc/nginx/prometheus.htpasswd
chmod 0640       /etc/nginx/prometheus.htpasswd

Verify that the file contains exactly one line of the form prometheus:$apr1$<salt>$<hash>.

Patch the NGINX vhost

  1. Edit /etc/nginx/conf.d/trento.conf and add a prometheus upstream alongside the existing web and wanda upstreams. Adjust the address and port to match your Prometheus installation:

    upstream prometheus {
  server 127.0.0.1:9090 max_fails=5 fail_timeout=60s;
}

  2. Inside the existing server { listen 443 ssl; …​ } block, add a /prometheus/ location before the catch-all location / { …​ } block:

    # Prometheus API
location /prometheus/ {
  auth_basic           "Prometheus";
  auth_basic_user_file /etc/nginx/prometheus.htpasswd;

  # Sized for remote_write batches and longer queries
  client_max_body_size 16m;
  proxy_read_timeout   120s;
  proxy_send_timeout   60s;

  proxy_http_version 1.1;
  proxy_set_header Host                 $http_host;
  proxy_set_header X-Forwarded-For      $proxy_add_x_forwarded_for;
  proxy_set_header X-Forwarded-Proto    $scheme;
  proxy_set_header X-Cluster-Client-Ip  $remote_addr;

  # Trailing slash strips the /prometheus/ prefix:
  # /prometheus/api/v1/write -> /api/v1/write upstream
  proxy_pass http://prometheus/;
}

  3. Validate and reload NGINX:

    nginx -t && systemctl reload nginx

7.7. Configuring Grafana Alloy

On SUSE Linux Enterprise Server for SAP applications 16, Grafana Alloy replaces node_exporter for collecting system metrics. On SUSE Linux Enterprise Server for SAP applications 15 SP7, Alloy is available as an optional package for users who prefer push-based metrics collection.

The Trento Agent provides a command to generate the required Alloy configuration.

7.7.1. Prerequisites

  • Grafana Alloy must be installed on the host:

    • On SUSE Linux Enterprise Server for SAP applications 16, it is available in the default repositories.

    • On SUSE Linux Enterprise Server for SAP applications 15 SP7, it is available as an optional package.

  • The Prometheus remote write endpoint must be enabled on Trento Server (see Enabling Prometheus remote write for Grafana Alloy hosts).

7.7.2. Generate and deploy the Alloy configuration

  1. Install Grafana Alloy:

    zypper install alloy

  2. Configure the Trento Agent with the required parameters for push mode in /etc/trento/agent.yaml. At minimum, you must set:

    prometheus-mode: push
prometheus-url: https://<trento-server>/prometheus/api/v1/write
prometheus-auth: basic
prometheus-auth-username: <username>
prometheus-auth-password: <password>

    Replace <username> and <password> with the credentials configured on Trento Server.

    When using the Ansible playbook, the agent configuration is set automatically from the inventory variables.

    The Trento Agent also supports bearer, mtls, and none authentication methods. See the Trento Agent configuration documentation for the complete list of available parameters.

  3. Generate the Alloy configuration and deploy it:

    The generated configuration enables the following collectors by default:

    Collector Description

    cpu

    CPU usage statistics

    cpufreq

    CPU frequency scaling

    loadavg

    System load averages

    meminfo

    Memory usage statistics

    filesystem

    Filesystem usage and capacity

    netdev

    Network device statistics

    uname

    System information (kernel version, architecture)

    These collectors cover the metrics used by Trento to render CPU and memory charts in the host detail view. If you need additional system metrics, you can edit the generated Alloy configuration to add more collectors from the full list of available collectors.

    Generate the Trento-specific Alloy configuration using the Trento Agent:

    trento-agent generate alloy > /etc/alloy/trento.alloy
chown alloy:alloy /etc/alloy/trento.alloy
chmod 640 /etc/alloy/trento.alloy

    Grafana Alloy supports loading a single configuration file or multiple files from a directory. SUSE Linux Enterprise Server for SAP applications 16 ships Alloy with a default configuration file at /etc/alloy/config.alloy. Choose one of the following approaches to integrate the Trento configuration:

    • Single configuration file: Append the content of /etc/alloy/trento.alloy to the existing /etc/alloy/config.alloy file.

    • Import configuration file: Keep /etc/alloy/trento.alloy as a separate file and include it in the main configuration using the import directive. See import.file.

    • Configuration directory: Keep /etc/alloy/trento.alloy as a separate file and configure Alloy to automatically load all *.alloy files from the /etc/alloy/ directory. This can be set up by overriding the CONFIG_FILE environment variable in the alloy.service systemd unit using a systemd drop-in file. See systemd.unit.

    Regardless of the chosen approach, all components defined in the Trento configuration must have unique names across all configuration files to avoid conflicts.

  4. Enable and start the Alloy service:

    systemctl enable --now alloy

    If Alloy is already running, reload the configuration:

    systemctl reload alloy

  5. Start or restart the Trento Agent:

    systemctl enable --now trento-agent

7.7.3. Verifying the configuration

After completing the setup, verify that metrics are being pushed successfully:

  1. Check that Alloy is running without errors:

    systemctl status alloy
journalctl -u alloy -f

  2. In the Trento web console, navigate to the host details view. The CPU and memory charts should display data after a short time.

8. Trento AI integrations

Trento provides AI-driven capabilities to help you monitor and troubleshoot your SAP landscape using natural language. You can use these features directly within the web console, or connect Trento data to your own external AI tools.

8.1. Liz AI assistant in Trento Web

Liz is a chat-based AI assistant built directly into Trento Web. It lets you ask questions about your SAP landscape in natural language. By analyzing the live state of your systems and best-practice validations, Liz helps you actively monitor health and identify issues, all without requiring any additional deployment.

This chapter covers the following topics:

8.1.1. About the Liz AI assistant

Liz is part of Trento Web itself and requires no additional deployment. You only need to supply an API key for a supported large language model (LLM) provider.

Liz is guided by built-in system instructions tailored for Trento, ensuring it understands your SAP landscape right out of the box.

Data privacy

Liz sends your prompts and the system data needed to answer them to the third-party LLM provider you configure. Review your organization’s data handling policy before enabling this feature.
Which providers and models are supported?

Liz AI assistant currently supports the following LLM providers:

  • Anthropic Claude

  • Google Gemini

  • OpenAI GPT

Each provider offers several models. To ensure compatibility, Trento only displays models capable of powering the assistant.

How does Liz access data?

Liz answers queries using live SAP landscape state from Trento Web, and check results from Trento Wanda.

Access is bound to your Trento user account. When you open a chat session, Liz can only access data you are authorized to see. Your existing Trento roles and permissions remain unchanged.

8.1.2. Configuring Liz

You can configure Liz from your user profile in Trento Web.

Requirements:

  • A user account in Trento Web. AI configuration is per user and each user configures their own provider and model.

  • An API key for one of the supported providers.

To configure Liz:

  1. In the Trento Web console, click your user icon and select Profile to open your profile page.

  2. Go to the AI Configuration section and click Edit Settings.

  3. Select a provider and model from the supported list.

  4. Enter your API key for the chosen provider.

  5. Click Save to save your configuration.

Liz becomes available as soon as the configuration is saved.

You can change your model or provider at any time from the Profile page without the need to reload the web console. Changes apply starting with your next prompt; any prompt currently processing finishes using the previous configuration.

To stop using Liz, clear your AI configuration from the Profile page. If the chat window is open, Liz goes offline and the conversation becomes read-only. Once the window is closed, the chat launcher is disabled.

8.1.3. Using Liz

Open the chat launcher in Trento Web and type your question. Your chat session remains active as long as you are logged into the Trento Web console.

Example queries:

  • What is the tuning status of the registered hosts?

  • Which hosts are affected by patch XYZ?

  • Provide a summary of checks not passing for cluster XYZ and step-by-step remediation instructions.

If you did not configure a provider and model, the launcher is disabled. See Configuring Liz for more information.

While a conversation is open you can perform the following actions:

Action Description

Stop

Stop Liz processing the current question. The assistant stays available for your next question.

Retry

Re-send your last prompt.

Copy

Copy a reply to the clipboard. Liz formats its responses in Markdown, so pasting into compatible tools (like wikis or issue trackers) preserves the text formatting.

Selecting Learn more in the assistant opens the Trento documentation in a new browser tab.

Clicking New chat in Liz immediately ends the active conversation and clears its history. Previous chats cannot be recovered once a new session starts.

8.2. MCP Integration

While Trento provides the built-in Liz assistant for AI conversations directly inside the Trento Web console, you can also integrate Trento’s data into your own external AI tools and workflows. The Trento MCP Server is an optional component that enables this external AI-assisted infrastructure management for your SAP landscape.

Trento MCP Server exposes Trento functionality through the Model Context Protocol (MCP), an open standard that facilitates secure communication between data sources and AI agents. While the core Trento Server operates independently, the Trento MCP Server component allows you to integrate Trento into an agentic AI workflow. This enables the use of Large Language Models (LLMs) to perform common monitoring and troubleshooting tasks using natural language, providing a standardized way for AI tools to access real-time system state and best-practice validations.

This chapter covers the following topics:

8.2.1. Installing Trento MCP Server

The Trento MCP Server can be deployed in different ways depending on your infrastructure and requirements.

Supported installation methods:

Prerequisites Trento MCP Server

The Trento MCP Server is lightweight and stateless. No persistent storage is required; allocate space for logs as per your logging policy. Before installing the Trento MCP Server, both Trento Web and Trento Wanda components must be running and be accessible for the Trento MCP Server to function properly.

  • There must be network connectivity between the Trento MCP Server and Trento Server components.

  • Access to the Trento Server URL (important when deployed behind NGINX, or any other reverse proxy) must be possible.

Kubernetes deployment of Trento MCP Server

The subsection uses the following placeholders:

  • TRENTO_SERVER_HOSTNAME: the host name used by the end user to access the console.

  • ADMIN_PASSWORD: the password of the admin user created during the installation process.

    The password must meet the following requirements:

    • minimum length of 8 characters

    • the password must not contain 3 identical numbers or letters in a row (for example, 111 or aaa)

    • the password must not contain 4 sequential numbers or letters (for example, 1234, abcd, ABCD)

Enable the Trento MCP Server

When installing Trento Server following the instructions in Kubernetes deployment, the Trento MCP Server is disabled by default. Enable it by passing --set trento-mcp-server.enabled=true:

helm upgrade --install trento-server oci://registry.suse.com/trento/trento-server \
  --set global.trentoWeb.origin=TRENTO_SERVER_HOSTNAME \
  --set trento-web.adminUser.password=ADMIN_PASSWORD \
  --set trento-mcp-server.enabled=true

The Trento MCP Server will automatically connect to the Trento Web and Trento Wanda internal services within the Kubernetes cluster.

Verify the Trento MCP Server installation

  1. Check that the Trento MCP Server Pod is running:

    kubectl get pods -l app.kubernetes.io/name=mcp-server

    Example output:

    NAME                                       READY   STATUS    RESTARTS   AGE
trento-server-mcp-server-xxxxxxxxxx-xxxxx  1/1     Running   0          2m

  2. Check the logs:

    kubectl logs -l app.kubernetes.io/name=mcp-server

  3. Check the Trento MCP Server health endpoints:

    # Expose the health check port from the Pod, as it is not exposed as a Kubernetes Service.
kubectl port-forward --namespace default \
  $(kubectl get pods --namespace default -l app.kubernetes.io/name=mcp-server -o jsonpath="{.items[0].metadata.name}") \
  8080:8080

    While the previous command is running, perform the following check:

    # Liveness endpoint:
curl http://localhost:8080/livez
    # Readiness endpoint:
curl http://localhost:8080/readyz

    Example output:

    # Liveness:
{"info":{"name":"trento-mcp-server","version":"0.1.0"},"status":"up"}

# Readiness:
{"status":"up","details":{"mcp-server":{"status":"up","timestamp":"2025-10-09T12:11:09.528898849Z"},"wanda-api":{"status":"up","timestamp":"2025-10-09T12:11:09.544855047Z"},"web-api":{"status":"up","timestamp":"2025-10-09T12:11:09.544855047Z"}}}
Trento MCP Server Helm configuration options

The Trento MCP Server Helm chart supports various configuration options:

Customize Ingress Path

By default, ingress is enabled. To customize the ingress configuration in a basic K3s installation, run the command below:

helm upgrade --install trento-server oci://registry.suse.com/trento/trento-server \
  --set global.trentoWeb.origin=TRENTO_SERVER_HOSTNAME \
  --set trento-web.adminUser.password=ADMIN_PASSWORD \
  --set trento-mcp-server.enabled=true \
  --set trento-mcp-server.ingress.hosts[0].host=TRENTO_SERVER_HOSTNAME \
  --set trento-mcp-server.ingress.hosts[0].paths[0].path=/mcp-server-trento \
  --set trento-mcp-server.ingress.hosts[0].paths[0].pathType=ImplementationSpecific

The Trento MCP Server endpoint will be: https://TRENTO_SERVER_HOSTNAME/mcp-server-trento/mcp

Adjust Log Verbosity

The default log level is info. Adjust it for debugging:

helm upgrade --install trento-server oci://registry.suse.com/trento/trento-server \
  --set global.trentoWeb.origin=TRENTO_SERVER_HOSTNAME \
  --set trento-web.adminUser.password=ADMIN_PASSWORD \
  --set trento-mcp-server.enabled=true \
  --set trento-mcp-server.mcpServer.verbosity=debug
Adjust Resource Limits

For production deployments with different resource requirements:

helm upgrade --install trento-server oci://registry.suse.com/trento/trento-server \
  --set global.trentoWeb.origin=TRENTO_SERVER_HOSTNAME \
  --set trento-web.adminUser.password=ADMIN_PASSWORD \
  --set trento-mcp-server.enabled=true \
  --set trento-mcp-server.resources.requests.cpu=100m \
  --set trento-mcp-server.resources.requests.memory=128Mi \
  --set trento-mcp-server.resources.limits.cpu=1000m \
  --set trento-mcp-server.resources.limits.memory=1Gi
Disable Health Check Probes

Health check probes are enabled by default. To disable them if needed, run the following command:

helm upgrade --install trento-server oci://registry.suse.com/trento/trento-server \
  --set global.trentoWeb.origin=TRENTO_SERVER_HOSTNAME \
  --set trento-web.adminUser.password=ADMIN_PASSWORD \
  --set trento-mcp-server.enabled=true \
  --set trento-mcp-server.livenessProbe.enabled=false \
  --set trento-mcp-server.readinessProbe.enabled=false
Complete configuration example

Below is a complete example that configures external access via a custom ingress path:

helm upgrade --install trento-server oci://registry.suse.com/trento/trento-server \
  --set global.trentoWeb.origin=https://trento.example.com \
  --set trento-web.adminUser.password=SecurePassword123 \
  --set trento-mcp-server.enabled=true \
  --set trento-mcp-server.mcpServer.trentoURL=https://trento.example.com \
  --set trento-mcp-server.ingress.hosts[0].host=trento.example.com \
  --set trento-mcp-server.ingress.hosts[0].paths[0].path=/mcp-server-trento \
  --set trento-mcp-server.ingress.hosts[0].paths[0].pathType=ImplementationSpecific
systemd deployment

A systemd-based installation of the Trento MCP Server using RPM packages can be performed manually on the latest supported versions of SUSE Linux Enterprise Server for SAP applications.

Supported versions:

  • SUSE Linux Enterprise Server for SAP applications 15: SP4–SP7

  • SUSE Linux Enterprise Server for SAP applications 16.0

Installing Trento MCP Server using RPM packages

  • Install the Trento MCP Server package:

    zypper install mcp-server-trento
Configure Trento MCP Server

  1. Create the Trento MCP Server configuration file /etc/trento/mcp-server-trento by copying the example:

    cp /etc/trento/mcp-server-trento.example /etc/trento/mcp-server-trento

  2. Edit the configuration file to point to your Trento Server:

    vim /etc/trento/mcp-server-trento

    Example configuration:

    AUTODISCOVERY_PATHS=/api/all/openapi,/wanda/api/all/openapi
ENABLE_HEALTH_CHECK=false
HEADER_NAME=Authorization
HEALTH_API_PATH=/api/healthz
HEALTH_PORT=8080
# OAS_PATH=https://trento.example.com/api/all/openapi,https://trento.example.com/wanda/api/all/openapi
PORT=5000
TAG_FILTER=MCP
TRANSPORT=streamable
TRENTO_URL=https://trento.example.com
VERBOSITY=info
INSECURE_SKIP_TLS_VERIFY=false

Configure the Trento MCP Server using either TRENTO_URL or OAS_PATH.
If OAS_PATH is left empty, the Trento MCP Server automatically discovers the APIs from the Trento Server using TRENTO_URL.
If OAS_PATH is set, it takes precedence and TRENTO_URL is ignored.

Use TRENTO_URL when one or more of the following conditions apply:

  • Trento Server is deployed behind a reverse proxy (NGINX, etc.).

  • The Trento MCP Server runs on a different host or network than Trento Server.

  • You want to use external or public URLs.

  • You prefer automatic API autodiscovery.

Use OAS_PATH when one or more of the following conditions apply:

  • You want to connect directly to internal services without autodiscovery.

  • You need to bypass reverse proxy configurations.

Start the Trento MCP Server service

  • Enable and start the Trento MCP Server service:

    systemctl enable --now mcp-server-trento
Verify the Trento MCP Server service

  1. Verify the service is running:

    systemctl status mcp-server-trento

    Expected output:

    ● mcp-server-trento.service - Trento MCP Server service
     Loaded: loaded (/usr/lib/systemd/system/mcp-server-trento.service; enabled)
     Active: active (running) since ...

  2. Check the service logs:

    journalctl -u mcp-server-trento -f

  3. If firewalld is running, allow Trento MCP Server to be accessible and add an exception to firewalld:

    firewall-cmd --zone=public --add-port=5000/tcp --permanent
firewall-cmd --reload

  4. If you enabled health checks and want to expose them, also allow the health check port:

    firewall-cmd --zone=public --add-port=8080/tcp --permanent
firewall-cmd --reload

  5. If you enabled health checks, verify the endpoints locally:

    # Note: Replace localhost with the server's IP/hostname if running these commands from a remote machine,
# and ensure the health port is allowed by your firewall.

# Liveness endpoint:
curl http://localhost:8080/livez

# Example output:
# {"info":{"name":"trento-mcp-server","version":"0.1.0"},"status":"up"}

# Readiness endpoint:
curl http://localhost:8080/readyz

# Example output:
# {"status":"up","details":{"mcp-server":{"status":"up","timestamp":"2025-10-09T12:11:09.528898849Z"},"wanda-api":{"status":"up","timestamp":"2025-10-09T12:11:09.542078327Z"},"web-api":{"status":"up","timestamp":"2025-10-09T12:11:09.544855047Z"}}}

8.2.2. Configuring Trento MCP Server

This section provides an overview of how to configure the Trento MCP Server depending on the deployment method.

Configuration in a Kubernetes deployment
Configuration Sources

The Trento MCP Server supports multiple configuration sources with the following priority order (highest to lowest):

  1. Environment variables - Used for containerized deployments.

  2. Built-in defaults - Fallback values.

Configuration Overview
Environment Variable Default Value Description

TRENTO_MCP_AUTODISCOVERY_PATHS

/api/all/openapi,/wanda/api/all/openapi

Custom paths for API autodiscovery.

TRENTO_MCP_ENABLE_HEALTH_CHECK

false

Enable the health check server.

TRENTO_MCP_CONFIG

(empty)

Configuration file path.

TRENTO_MCP_HEADER_NAME

Authorization

Header name used to pass the Trento API key to the Trento MCP Server.

TRENTO_MCP_HEALTH_API_PATH

/api/healthz

API path used for health checks on target servers.

TRENTO_MCP_HEALTH_PORT

8080

Port where the health check server runs.

TRENTO_MCP_INSECURE_SKIP_TLS_VERIFY

false

Skip TLS certificate verification when fetching OAS specs from HTTPS.

TRENTO_MCP_OAS_PATH

[]

Path(s) to OpenAPI specification file(s). Can be set multiple times.

TRENTO_MCP_PORT

5000

Port where the Trento MCP Server runs.

TRENTO_MCP_TAG_FILTER

["MCP"]

Only include operations that contain one of these tags.

TRENTO_MCP_TRANSPORT

streamable

Protocol to use: streamable or sse.

TRENTO_MCP_TRENTO_URL

(empty)

Target Trento server URL. Required for autodiscovery if OAS path is not set.

TRENTO_MCP_VERBOSITY

info

Log level: debug, info, warning, or error.
Kubernetes Deployment Example
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mcp-server-trento
spec:
  template:
    spec:
      containers:
      - name: mcp-server-trento
        image: mcp-server-trento:latest
        env:
        - name: TRENTO_MCP_PORT
          value: "5000"
        - name: TRENTO_MCP_HEALTH_PORT
          value: "8080"
        - name: TRENTO_MCP_ENABLE_HEALTH_CHECK
          value: "true"
        - name: TRENTO_MCP_TRENTO_URL
          value: "https://trento.example.com"
        - name: TRENTO_MCP_VERBOSITY
          value: "info"
        ports:
        - containerPort: 5000
          name: mcp
        - containerPort: 8080
          name: health
Configuration in a systemd deployment
Configuration Sources

The Trento MCP Server supports multiple configuration sources with the following priority order (highest to lowest):

  1. Command-line flags - Override config for the current process.

  2. Configuration file - Persistent settings configuration.

Configuration Overview

The mcp-server-trento binary accepts several command-line flags to configure its behavior. The following table lists all available configuration options, their corresponding flags, configuration variables, and default values.

Flag Config Variable Default Value Description

--autodiscovery-paths, -A

AUTODISCOVERY_PATHS

/api/all/openapi,/wanda/api/all/openapi

Custom paths for API autodiscovery.

--config, -c

(empty)

(empty)

Configuration file path.

--enable-health-check, -d

ENABLE_HEALTH_CHECK

false

Enable the health check server.

--header-name, -H

HEADER_NAME

Authorization

Header name used to pass the Trento API key to the Trento MCP Server.

--health-api-path, -a

HEALTH_API_PATH

/api/healthz

API path used for health checks on target servers.

--health-port, -z

HEALTH_PORT

8080

Port where the health check server runs.

--insecure-skip-tls-verify, -i

INSECURE_SKIP_TLS_VERIFY

false

Skip TLS certificate verification when fetching OAS specs from HTTPS.

--oas-path, -P

OAS_PATH

[]

Path(s) to OpenAPI specification file(s). Can be set multiple times.

--port, -p

PORT

5000

Port where the Trento MCP Server runs.

--tag-filter, -f

TAG_FILTER

["MCP"]

Only include operations that contain one of these tags.

--transport, -t

TRANSPORT

streamable

Protocol to use: streamable or sse.

--trento-url, -u

TRENTO_URL

(empty)

Target Trento server URL. Required for autodiscovery if OAS path is not set.

--verbosity, -v

VERBOSITY

info

Log level: debug, info, warning, or error.
Configure Trento MCP Server with Command-Line Flags

Trento MCP Server allows you to override configuration settings using command-line flags for temporary changes. These overrides are not persistent and are lost when the process stops or the system is rebooted. To make configuration changes permanent for the systemd service, update /etc/trento/mcp-server-trento and restart the service.

Basic usage with custom port, verbosity, and target URL:

mcp-server-trento --port 9000 --verbosity debug --trento-url https://trento.example.com

Using multiple OpenAPI specifications:

mcp-server-trento --oas-path https://api1.example.com/openapi.json --oas-path https://api2.example.com/openapi.json

Autodiscovery with custom paths:

mcp-server-trento --trento-url https://trento.example.com --autodiscovery-paths /api/v1/openapi,/wanda/api/v1/openapi

Enable health checks on a custom port:

mcp-server-trento --enable-health-check --health-port 8080 --port 5000
Help and Validation

You can see all available flags by running:

mcp-server-trento --help

The server will validate the configuration on startup and log any issues with debug verbosity enabled.

Health Check Configuration

The Trento MCP Server includes built-in health check endpoints for systemd and Kubernetes integration.

Health check functionality is disabled by default and must be explicitly enabled using the --enable-health-check flag or the TRENTO_MCP_ENABLE_HEALTH_CHECK environment variable.
Health Check Endpoints

The health check server provides the following endpoints:

  • /livez - Liveness probe for Kubernetes pod restart decisions.

  • /readyz - Readiness probe for traffic routing decisions.

The readiness endpoint performs comprehensive health checks, including:

  • mcp-server - Validates Trento MCP Server connectivity using an MCP client.

  • api-server - Verifies connectivity to the configured Trento API server.

Enable Health Checks with Helm on a Kubernetes deployment

Enable health checks when deploying on Kubernetes with Helm:

helm upgrade \
  --install trento-server oci://registry.suse.com/trento/trento-server \
  --set global.trentoWeb.origin=TRENTO_SERVER_HOSTNAME \
  --set trento-web.adminUser.password=ADMIN_PASSWORD \
  --set trento-mcp-server.enabled=true \
  --set TRENTO_MCP_ENABLE_HEALTH_CHECK=true \
  --set TRENTO_MCP_HEALTH_PORT=8080

The health port is internal to the Kubernetes cluster. To reach it from the host running Kubernetes, forward the Pod port. Replace NAMESPACE with your target namespace (Helm defaults to default).

kubectl port-forward --namespace NAMESPACE \
  $(kubectl get pods --namespace NAMESPACE -l app.kubernetes.io/name=mcp-server -o jsonpath="{.items[0].metadata.name}") \
  8080:8080 &

With the port forward active, test the endpoints in Testing Health Endpoints.

Enable Health Checks with the command-line for systemd deployment
mcp-server-trento --enable-health-check
mcp-server-trento --enable-health-check --health-port 8080
Testing Health Endpoints
# Test liveness endpoint
curl http://localhost:8080/livez

# Test readiness endpoint
curl http://localhost:8080/readyz

# Expected readiness response format:
# {"status":"up","checks":{"mcp-server":{"status":"up"},"api-server":{"status":"up"},"api-documentation":{"status":"up"}}}

# Expected liveness response format:
# {"status":"up"}
Troubleshooting

This section provides solutions for common issues when deploying and using the Trento MCP Server.

Connection Issues

  • Trento MCP Server cannot connect to Trento API

    • Verify the TRENTO_URL or OAS_PATH configuration points to accessible endpoints

    • Check network connectivity between the Trento MCP Server and Trento components

    • Ensure API authentication is properly configured with valid tokens

  • MCP clients cannot connect to Trento MCP Server

    • Verify the Trento MCP Server is running and listening on the correct port (default: 5000)

    • Check firewall rules allow access to the Trento MCP Server port

    • Ensure the Trento MCP Server endpoint URL is correctly configured in client applications

Authentication Issues

  • API token authentication fails

    • Verify the Personal Access Token is valid and not expired

    • Ensure the token has the necessary permissions in Trento

    • Check that the HEADER_NAME configuration matches between server and client

  • Token not accepted

    • Confirm the token was generated from the correct Trento instance

    • Verify the token format and ensure it includes the "Bearer " prefix if required

Configuration Issues

  • OpenAPI specification not found

    • Check that TRENTO_URL or OAS_PATH point to valid Trento API endpoints

    • Verify the Trento Web and Trento Wanda services are running and accessible

    • Ensure autodiscovery paths are correct if using TRENTO_URL

  • Tools not appearing in MCP clients

    • Check the TAG_FILTER configuration - only operations with matching tags are exposed

    • Verify the OpenAPI specifications are accessible and valid

    • Ensure the Trento MCP Server can parse the API documentation

Performance Issues

  • Slow response times

    • Check network latency between Trento MCP Server and Trento components

    • Review Trento API performance and database query times

    • Consider enabling debug logging to identify bottlenecks

  • High resource usage

    • Monitor Trento MCP Server memory and CPU usage

    • Check for memory leaks in long-running processes

    • Consider adjusting logging verbosity to reduce I/O overhead

Health Check Issues

  • Health checks failing

    • Verify health check endpoints are accessible

    • Check that all required services (Trento API, Trento MCP Server) are responding

    • Review health check configuration and timeouts

Logging and Debugging

  • Enable debug logging

    • Set VERBOSITY=debug to get detailed logs

    • Check Trento MCP Server logs for error messages and connection attempts

    • Review Trento component logs for API-related issues

  • Common log messages

    • "Failed to fetch OpenAPI specification" - Check API endpoint accessibility

    • "Authentication failed" - Verify API token configuration

    • "No tools available" - Check tag filtering and API documentation

Getting Help

If you continue to experience issues:

  1. Check the Trento MCP Server logs for detailed error messages

  2. Verify configuration values:

    1. For systemd deployments, use mcp-server-trento --help

    2. For Kubernetes deployments, run Helm with --render-subchart-notes to view the rendered Trento MCP Server settings

  3. Test API connectivity directly using curl or similar tools

  4. Check the Trento server logs for API authentication and access issues

8.2.3. Using the Trento MCP Server

The Trento MCP Server provides the interface for AI-assisted infrastructure operations, enabling agentic assistants to integrate with Trento. By utilizing the Model Context Protocol, these assistants can perform monitoring and troubleshooting tasks through natural language. See MCPHost on SLES or Using alternative MCP clients for details.

Integrating the Trento MCP Server with MCPHost

This guide explains how to connect the Trento MCP Server to SUSE Linux Enterprise Server 16 using MCPHost, a lightweight CLI tool for the Model Context Protocol (MCP).

Supported only on SUSE Linux Enterprise Server for SAP applications 16.0
Prerequisites

To configure MCPHost, ensure you have the following:

  • An LLM provider and credentials.

    • Public hosted options, such as Google Gemini, OpenAI, etc.

    • Private/on-premises option, such as SUSE AI.

  • A running Trento Server installation with the Trento MCP Server component enabled.

  • A Trento Personal Access Token generated in Trento Web Profile view.

    Generate a Personal Access Token in Trento
    Figure 2. Generate a Personal Access Token in Trento
Install MCPHost

To install MCPHost, open a terminal and run the following commands:

sudo zypper refresh
sudo zypper install mcphost

After installation, verify that MCPHost is available and working by checking its version:

mcphost --version
Configure MCPHost

MCPHost reads its configuration from several locations; one common location is ~/.mcphost.yml. Create ~/.mcphost.yml with the following content:

mcpServers:
  trento-mcp-server:
    type: "remote"
    url: https://trento.example.com/mcp-server-trento/mcp
    headers:
      - "Authorization: Bearer ${env://TRENTO_PAT}"

  • Replace https://trento.example.com/mcp-server-trento/mcp with the actual URL where your Trento MCP Server is accessible:

    • For Kubernetes deployments with ingress, use the ingress URL (e.g., https://trento.example.com/mcp-server-trento/mcp).

    • For local or development setups, use http://localhost:5000/mcp (adjust the port as needed).

    • The transport type is configured on the Trento MCP Server, if using Server-Sent Events (SSE) transport instead of the default streamable transport, change the path from /mcp to /sse.

  • If you configured a custom header name (using HEADER_NAME or --header-name), update Authorization accordingly.

Security best practice: Keep secrets out of configuration files. Store your keys in environment variables instead of hardcoding them.

Export your keys in the shell before running MCPHost. For example:

export GOOGLE_API_KEY=<your-google-api-key>
export TRENTO_PAT=<your-trento-personal-access-token>

Configure remote LLM models directly in your MCPHost configuration. For example, to use Google Gemini as your model provider:

model: "google:gemini-2.5-flash"
provider-url: "https://generativelanguage.googleapis.com/v1beta/openai/"
provider-api-key: "${env://GOOGLE_API_KEY}"
mcpServers:
  mcp-server-trento:
    type: "remote"
    url: https://trento.example.com/mcp-server-trento/mcp
    headers:
      - "Authorization: Bearer ${env://TRENTO_PAT}"
Run MCPHost and use Trento tools

  1. Start MCPHost:

    mcphost

    If no servers appear on startup, confirm your configuration file exists at ~/.mcphost.yml and that your environment variables are exported in the same shell session.

  2. Verify the connection to Trento and basic status:

    /servers
    MCPHost initial screen
    Figure 3. MCPHost initial screen with the Trento MCP Server connected
Use MCPHost to interact with Trento Server
Ask the model to invoke Trento tools using natural language prompts, such as:

  • "List all SAP systems managed".

  • "Show my HANA clusters".

  • "Are my SAP systems compliant?"

  • "What is the health status of my SAP landscape?"

  • "Show me all hosts running SAP applications".

  • "Are there any critical alerts I need to address?"

  • "Get details about the latest check execution results".

  • "Which SAP systems are currently running?"

Example MCPHost session querying Trento about SAP systems:

Example MCPHost session with Trento
MCPHost Troubleshooting

If you encounter issues connecting MCPHost to the Trento MCP Server:

  • Connection errors

    • Verify that the Trento MCP Server URL in ~/.mcphost.yml is correct and accessible from your system.

    • Check if the Trento MCP Server is running by reviewing logs from your Trento installation.

    • Ensure network connectivity and that any required firewall rules are in place.

    • Test basic connectivity: curl -I https://trento.example.com/mcp-server-trento/mcp.

  • Authentication errors

    • Verify that your personal access token is valid by testing it directly with your Trento Server API.

    • Ensure TRENTO_PAT is exported in the same shell session before running mcphost.

    • Check that the header name matches your server configuration (default: Authorization).

    • Ensure the token has the necessary permissions in Trento.

  • LLM provider errors

    • Verify that LLM GOOGLE_API_KEY (or your provider’s API key) is exported correctly.

    • Check the provider-url and model configuration in your ~/.mcphost.yml.

    • Confirm that your API key has sufficient quota and permissions with your provider.

  • General issues

    • Check the MCPHost terminal output for detailed error messages during startup or operation.

    • Review the Trento MCP Server logs for connection attempts and errors.

    • Verify that your configuration file exists at ~/.mcphost.yml and has correct YAML syntax.

Integrating the Trento MCP Server with other clients

The Trento MCP Server can be integrated with any client application that supports the Model Context Protocol. This makes it possible to interact with the Trento API and execute tools defined in the OpenAPI specification through your preferred AI assistant or development tool.

This guide uses Visual Studio Code with GitHub Copilot as an example, but the configuration procedures apply to any MCP-compatible client.

Prerequisites

To configure your client, make sure that you have the following:

  • An LLM provider and credentials.

    • Public hosted options, such as Google Gemini, OpenAI, etc.

    • Private/on-premises option, such as SUSE AI.

  • A running Trento Server installation with the Trento MCP Server component enabled.

  • A Trento Personal Access Token generated in Trento Web Profile view.

    Generate a Personal Access Token in Trento
    Figure 4. Generate a Personal Access Token in Trento
Configuring your client

Once you have your Trento Server installation ready with the Trento MCP Server URL and API token, you can configure the MCP Server client. The examples below show JSON configuration format used by most MCP Server clients, including VS Code, Claude Desktop, and others.

  • Option 1: Configuration with prompted input

    This configuration asks for your personal access token when the client starts, keeping credentials secure and out of configuration files. The password: true setting ensures your personal access token input is masked when you type it.

    This option is supported by most clients, including VS Code. Check your client’s documentation if the prompt feature is not available.

    		 
    {
  "servers": {
    "trento": {
      "type": "http",
      "url": "https://trento.example.com/mcp-server-trento/mcp",
      "headers": {
        "Authorization": "${input:trento-personal-access-token}"
      }
    }
  },
  "inputs": [
    {
      "type": "promptString",
      "id": "trento-personal-access-token",
      "description": "Trento API key",
      "password": true
    }
  ]
}

  • Option 2: Direct header configuration

    For clients that don’t support prompted input, or for testing purposes, set your Trento personal access token directly in the configuration file.

    When using this option, ensure your configuration file has appropriate permissions and is not committed to version control systems.

    		 
    {
  "servers": {
    "trento": {
      "type": "http",
      "url": "https://trento.example.com/mcp-server-trento/mcp",
      "headers": {
        "Authorization": "trento-personal-access-token"
      }
    }
  }
}

    Replace https://trento.example.com/mcp-server-trento/mcp with your actual Trento MCP Server endpoint URL from your installation.

  • Client options

    For detailed guidance on taking advantage of MCP capabilities in different tools, refer to the following official documentation:

9. Core Features

9.1. User management

Trento provides a local permission-based user management feature with optional multi-factor authentication. This feature enables segregation of duties in the Trento interface and ensures that only authorized users with the right permissions can access it.

User management actions are performed in the Users view in the left-hand side panel of the Trento UI.

By default, a newly created user is granted display access rights except for the Users view. Where available, a user with default access can configure filters and pagination settings matching their preferences.

To perform protected actions, the user must have additional permissions added to their user profile. Below is the list of currently available permissions:

  • all:users: grants full access to user management actions under the Users view

  • all:checks_selection: grants check selection capabilities for any target in the registered environment for which checks are available

  • all:checks_execution: grants check execution capabilities for any target in the registered environment for which checks are available and have been previously selected

  • all:tags: allows creation and deletion of the available tags

  • cleanup:all: allows triggering housekeeping actions on hosts where agents heartbeat is lost and SAP or HANA instances that are no longer found

  • all:settings: grants changing capabilities on any system settings under the Settings view

  • all:all: grants all the permissions above

Using the described permissions, it is possible to create the following types of users:

  • User managers: users with all:users permissions

  • SAP Basis administrator with Trento display-only access: users with default permissions

  • SAP Basis administrator with Trento configuration access: users with all:checks_selection, all:tags and all:settings permissions

  • SAP Basis administrator with Trento operation access: users with all:check_execution and cleanup:all permissions.

The default admin user created during the installation process is granted all:all permissions and cannot be modified or deleted. Use it only to create the first user manager (a user with all:users permissions who creates all the other required users). Once a user with all:users permissions is created, the default admin user must be treated as a fallback user in case all other access to the console is lost. If the password of the default admin user is lost, it can be reset by updating the Helm chart or the web component configuration, depending on which deployment method was used to install Trento Server.

User passwords, including the default admin user password, must follow the rules below:

  • Password must contain at least 8 characters

  • The same number or letter must not be repeated three or more times in a row (for example: 111 or aaa)

  • Password must not contain four consecutive numbers or letters (for example: 1234, abcd or ABCD)

The Create User and Edit User views provide a built-in password generation button that allows user managers to easily generate secure and compliant passwords. The user manager must provide the user with their password through an authorized secure channel.

User managers may also set a preferred timezone for the account from the Create User and Edit User views. Individual users can configure their own preference later in the Profile view. The web console displays dates and times according to each user’s preferred timezone for presentation; if no preference is set, UTC is used. This preference affects only how timestamps are presented in the UI — backend storage, API payloads, logs and scheduled tasks continue to use UTC.

A user can reset their password in the Profile view. In this view, they can also update their name and email address as well as activate multi-factor authentication using an authenticator app. Multi-factor authentication increases the security of a user account by requesting a temporary second password or code when logging in the console. User managers can disable multi-factor authentication for any given user that has it enabled. However, user managers cannot enable multi-factor authentication on their behalf. The default admin user cannot enable its own multi-factor authentication.

Security Tip for Multi-Factor Authentication

Since multi-factor authentication cannot be enabled for the default admin user, keeping its password safe is imperative. If the default admin user’s password is compromised, reset it immediately by updating the Helm chart or the web component configuration, depending on which deployment method was used to install Trento Server.

User managers can enable and disable users. When a user logged in the console is disabled by a user admin, their session is terminated immediately.

9.2. Single Sign-On integration

Trento can be integrated for Single Sign-On (SSO) with a third-party identity provider (IDP).

Trento cannot start with multiple SSO options together, so only one can be chosen.

The following protocols are supported:

  • OpenID Connect (OIDC)

  • Open Authorization 2.0 (OAuth 2)

  • Security Assertion Markup Language (SAML)

9.2.1. User roles and authentication

User authentication is entirely managed by the IDP, which is responsible for maintaining user accounts. A user, who does not exist on the IDP, is unable to access the Trento web console.

During the installation process, a default admin user is defined using the ADMIN_USER variable, which defaults to admin. If the authenticated user’s IDP username matches this admin user’s username, that user is automatically granted all:all permissions within Trento.

User permissions are entirely managed by Trento, they are not imported from the IDP. The permissions must be granted by some user with all:all or all:users rights (admin user initially). This means that only basic user information is retrieved from the external IDP.

9.2.2. Using OpenID Connect

Trento integrates with an IDP that uses the OIDC protocol to authenticate users accessing the Trento web console.

By default, OIDC is disabled.

Enabling OpenID Connect when using a Kubernetes deployment

To enable OIDC when using a Kubernetes deployment with helm, add the following variables to the previously documented helm installation command:

helm ... \
   --set trento-web.oidc.enabled=true \
   --set trento-web.oidc.clientId=<OIDC_CLIENT_ID> \
   --set trento-web.oidc.clientSecret=<OIDC_CLIENT_SECRET> \
   --set trento-web.oidc.baseUrl=<OIDC_BASE_URL>
Enabling OpenID Connect when using RPM packages

To enable OIDC when using RPM packages, proceed as follows:

  1. Open the file /etc/trento/trento-web.

  2. Add the following environment variables to this file. Required variables are:

    ENABLE_OIDC=true
OIDC_CLIENT_ID=<OIDC_CLIENT_ID>
OIDC_CLIENT_SECRET=<OIDC_CLIENT_SECRET>
OIDC_BASE_URL=<OIDC_BASE_URL>

  3. Optionally, add the OIDC callback URL to the configuration. This can be useful if for some reason the default callback URL cannot be used, for example, if http is used instead of https. Use the next variable for that:

    OIDC_CALLBACK_URL=<OIDC_CALLBACK_URL>

  4. Restart the application.

Available variables for OpenID Connect
OIDC_CLIENT_ID

OIDC client id

OIDC_CLIENT_SECRET

OIDC client secret

OIDC_BASE_URL

OIDC base url

OIDC_CALLBACK_URL

OIDC callback url where the IDP is redirecting once the authentication is completed (default value: https://#{TRENTO_WEB_ORIGIN}/auth/oidc_callback)

9.2.3. Using OAuth 2.0

Trento integrates with an IDP that uses the OAuth 2 protocol to authenticate users accessing the Trento web console.

By default, OAuth 2.0 is disabled.

Enabling OAuth 2.0 when using a Kubernetes deployment

To enable OAuth 2.0 when using a Kubernetes deployment with helm, proceed as follows:

  1. Add the following variables to the previously documented helm installation command:

    helm ... \
   --set trento-web.oauth2.enabled=true \
   --set trento-web.oauth2.clientId=<OAUTH2_CLIENT_ID> \
   --set trento-web.oauth2.clientSecret=<OAUTH2_CLIENT_SECRET> \
   --set trento-web.oauth2.baseUrl=<OAUTH2_BASE_URL> \
   --set trento-web.oauth2.authorizeUrl=<OAUTH2_AUTHORIZE_URL> \
   --set trento-web.oauth2.tokenUrl=<OAUTH2_TOKEN_URL> \
   --set trento-web.oauth2.userUrl=<OAUTH2_USER_URL>

    Additionally, the following optional values are available:

    helm ... \
   --set trento-web.oauth2.scopes=<OAUTH2_SCOPES>
Enabling OAuth 2.0 when using RPM packages

To enable OAuth 2.0 when using RPM packages, proceed as follows:

  1. Open the file /etc/trento/trento-web.

  2. Add the following environment variables to this file. Required variables are:

    # Required:
ENABLE_OAUTH2=true
OAUTH2_CLIENT_ID=<OAUTH2_CLIENT_ID>
OAUTH2_CLIENT_SECRET=<OAUTH2_CLIENT_SECRET>
OAUTH2_BASE_URL=<OAUTH2_BASE_URL>
OAUTH2_AUTHORIZE_URL=<OAUTH2_AUTHORIZE_URL>
OAUTH2_TOKEN_URL=<OAUTH2_TOKEN_URL>
OAUTH2_USER_URL=<OAUTH2_USER_URL>

# Optional:
OAUTH2_SCOPES=<OAUTH2_SCOPES>
OAUTH2_CALLBACK_URL=<OAUTH2_CALLBACK_URL>

  3. Restart the application.

Available variables for OAuth 2.0
OAUTH2_CLIENT_ID

OAUTH2 client id

OAUTH2_CLIENT_SECRET

OAUTH2 client secret

OAUTH2_BASE_URL

OAUTH2 base url

OAUTH2_AUTHORIZE_URL

OAUTH2 authorization url

OAUTH2_TOKEN_URL

OAUTH2 token url

OAUTH2_USER_URL

OAUTH2 token url

OAUTH2_SCOPES

OAUTH2 scopes, used to define the user values sent to the SP. It must be adjusted depending on IDP provider requirements (default value: profile email)

OAUTH2_CALLBACK_URL

OAUTH2 callback url where the IDP is redirecting once the authentication is completed (default value: https://#{TRENTO_WEB_ORIGIN}/auth/oauth2_callback)

9.2.4. Using SAML

Trento integrates with an IDP that uses the SAML protocol to authenticate users accessing the Trento web console. Trento will behave as a Service Provider (SP) in this case.

Commonly, SAML protocol messages are signed with SSL. This is optional using Trento, and the signing is not required (even though it is recommended). If the IDP signs the messages, and expect signed messages back, certificates used by the SP (Trento in this case) must be provided to the IDP, the public certificate file in this case.

To use an existing SAML IDP, follow the next instructions to met the specific requirements. You need:

  1. Obtain metadata content from the IDP

  2. Start Trento to generate the certificates and get them (SAML must be enabled for this)

  3. Provide the generated certificate to the IDP

  4. Configure SAML IDP and user profiles

See the following subsections for details.

Obtaining metadata content from the IDP

The metadata.xml file defines the agreement between SP and IDP during SAML communications. It is used to identify the SAML client as well. The content of this file must be provided to Trento. Options SAML_METADATA_URL and SAML_METADATA_CONTENT are available for that.

If the SAML_METADATA_CONTENT option is being used, the content of this variable must be updated with the IDP metadata as single line string. On the other hand, if SAML_METADATA_URL is used, the new metadata is automatically fetched when Trento starts. If neither of these steps are completed, communication will fail because the message signatures will not be recognized.

If the used IDP has the endpoint to provide the metadata.xml file content, prefer the variable SAML_METADATA_URL. Trento will automatically fetch metadata when started.

Getting certificates from Trento

Trento provides a certificates set created during the installation. Regardless of the installation mode, when Trento is installed the first time and SAML is enabled the certificates are created and the public certificate file content is available in the https://#{TRENTO_WEB_ORIGIN}/api/public_keys route.

Use the following command to get the certificate content:

curl https://#{TRENTO_WEB_ORIGIN}/api/public_keys

Copy the content of the certificate from there and provide it to the IDP. This way, the IDP will sign its messages and verify the messages received from Trento.

To get the certificate using this route Trento must be configured to start with SAML enabled.
Configuring SAML IDP setup

Configure the existing IDP with the next minimum options to be able to connect with Trento as a Service Provider (SP).

Providing certificates

As commented previously, a set of certificates is needed to enable signed communication. Provide the certificate generated by Trento to the IDP (each IDP has a different way to do this). Make sure that the configured certificate is used for signing and encrypting messages.

Configuring SAML user profile

Users provided by the SAML installation must have some few mandatory attributes to login in Trento. The required attributes are: username, email, first name and last name. All of them are mandatory, even though their field names are configurable.

By default, Trento expects the username, email, firstName and lastName attribute names. All these 4 attribute names are configurable using the next environment variables, following the same order: SAML_USERNAME_ATTR_NAME, SAML_EMAIL_ATTR_NAME, SAML_FIRSTNAME_ATTR_NAME and SAML_LASTNAME_ATTR_NAME.

Both IDP and Trento must know how these 4 fields are mapped. To do this, follow the next instructions:

  1. Add the attributes if they don’t exist in the IDP user profile. If they already exist, don’t change the attributes and keep their original values.

  2. Configure Trento to use the IDP attribute field names. To do this, set the SAML_USERNAME_ATTR_NAME, SAML_EMAIL_ATTR_NAME, SAML_FIRSTNAME_ATTR_NAME and SAML_LASTNAME_ATTR_NAME environment values with the values configured in the IDP. For example, if the IDP user profile username is defined as attr:username use SAML_USERNAME_ATTR_NAME=attr:username.

SAML URLs

Trento exposes some SAML related URLs when SAML is enabled:

  • Assertion consumer service (or ACS): an endpoint to accept SAML messages to establish a session into the Service Provider. The endpoint for ACS in Trento is: https://#{TRENTO_WEB_ORIGIN}/sso/sp/consume/#{SAML_IDP_ID}

  • Single logout service (or SLS): an endpoint to initiate a logout request from the IdP. The endpoint for SLS in Trento is: https://#{TRENTO_WEB_ORIGIN}/sso/sp/logout/#{SAML_IDP_ID}

  • Metadata: an endpoint to retrieve Trento metadata for SAML. The endpoint for metadata in Trento is: https://#{TRENTO_WEB_ORIGIN}/sso/sp/metadata/#{SAML_IDP_ID}. This URL is used as default value for SAML_SP_ENTITY_ID if the configuration variable is not set

Enabling SAML when using a Kubernetes deployment

To enable SAML when using a Kubernetes deployment with helm, proceed as follows:

  1. Add the following variables to the previously documented helm installation command:

    helm ... \
   --set trento-web.saml.enabled=true \
   --set trento-web.saml.idpId=<SAML_IDP_ID> \
   --set trento-web.saml.spId=<SAML_SP_ID> \
   --set trento-web.saml.metadataUrl=<SAML_METADATA_URL>

    To use the SAML_METADATA_CONTENT option rather than SAML_METADATA_URL use:

    helm ... \
   --set trento-web.saml.enabled=true \
   --set trento-web.saml.idpId=<SAML_IDP_ID> \
   --set trento-web.saml.spId=<SAML_SP_ID> \
   --set trento-web.saml.metadataContent=<SAML_METADATA_CONTENT>

    Additionally, the following optional values are available:

    helm ... \
   --set trento-web.saml.idpNameIdFormat=<SAML_IDP_NAMEID_FORMAT> \
   --set trento-web.saml.spDir=<SAML_SP_DIR> \
   --set trento-web.saml.spEntityId=<SAML_SP_ENTITY_ID> \
   --set trento-web.saml.spContactName=<SAML_SP_CONTACT_NAME> \
   --set trento-web.saml.spContactEmail=<SAML_SP_CONTACT_EMAIL> \
   --set trento-web.saml.spOrgName=<SAML_SP_ORG_NAME> \
   --set trento-web.saml.spOrgDisplayName=<SAML_SP_ORG_DISPLAYNAME> \
   --set trento-web.saml.spOrgUrl=<SAML_SP_ORG_URL> \
   --set trento-web.saml.usernameAttrName=<SAML_USERNAME_ATTR_NAME> \
   --set trento-web.saml.emailAttrName=<SAML_EMAIL_ATTR_NAME> \
   --set trento-web.saml.firstNameAttrName=<SAML_FIRSTNAME_ATTR_NAME> \
   --set trento-web.saml.lastNameAttrName=<SAML_LASTNAME_ATTR_NAME> \
   --set trento-web.saml.signRequests=<SAML_SIGN_REQUESTS> \
   --set trento-web.saml.signMetadata=<SAML_SIGN_METADATA> \
   --set trento-web.saml.signedAssertion=<SAML_SIGNED_ASSERTION> \
   --set trento-web.saml.signedEnvelopes=<SAML_SIGNED_ENVELOPES>
Enabling SAML when using RPM packages

To enable SAML when using RPM packages, proceed as follows:

  1. Open the file /etc/trento/trento-web.

  2. Add the following environment variables to this file. Required variables are:

    # Required:
ENABLE_SAML=true
SAML_IDP_ID=<SAML_IDP_ID>
SAML_SP_ID=<SAML_SP_ID>
# Only SAML_METADATA_URL or SAML_METADATA_CONTENT must by provided
SAML_METADATA_URL=<SAML_METADATA_URL>
SAML_METADATA_CONTENT=<SAML_METADATA_CONTENT>

# Optional:
SAML_IDP_NAMEID_FORMAT=<SAML_IDP_NAMEID_FORMAT>
SAML_SP_DIR=<SAML_SP_DIR>
SAML_SP_ENTITY_ID=<SAML_SP_ENTITY_ID>
SAML_SP_CONTACT_NAME=<SAML_SP_CONTACT_NAME>
SAML_SP_CONTACT_EMAIL=<SAML_SP_CONTACT_EMAIL>
SAML_SP_ORG_NAME=<SAML_SP_ORG_NAME>
SAML_SP_ORG_DISPLAYNAME=<SAML_SP_ORG_DISPLAYNAME>
SAML_SP_ORG_URL=<SAML_SP_ORG_URL>
SAML_USERNAME_ATTR_NAME=<SAML_USERNAME_ATTR_NAME>
SAML_EMAIL_ATTR_NAME=<SAML_EMAIL_ATTR_NAME>
SAML_FIRSTNAME_ATTR_NAME=<SAML_FIRSTNAME_ATTR_NAME>
SAML_LASTNAME_ATTR_NAME=<SAML_LASTNAME_ATTR_NAME>
SAML_SIGN_REQUESTS=<SAML_SIGN_REQUESTS>
SAML_SIGN_METADATA=<SAML_SIGN_METADATA>
SAML_SIGNED_ASSERTION=<SAML_SIGNED_ASSERTION>
SAML_SIGNED_ENVELOPES=<SAML_SIGNED_ENVELOPES>

  3. Restart the application.

Available variables for SAML
SAML_IDP_ID

SAML IDP id. This is a user-defined string used to identify the associated IDP in Trento. The value is used as well to compose relevant SAML URLs like the ACS and metadata URLs. It can have any value, for example: trento

SAML_SP_ID

SAML SP id. This is a user-defined string to identify Trento as service provider. It can have any value, for example: trento

SAML_METADATA_URL

URL to retrieve the SAML metadata xml file. One of SAML_METADATA_URL or SAML_METADATA_CONTENT is required

SAML_METADATA_CONTENT

One line string containing the SAML metadata xml file content (SAML_METADATA_URL has precedence over this)

SAML_IDP_NAMEID_FORMAT

SAML IDP name id format, used to interpret the attribute name. Whole urn string must be used (default value: urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified)

SAML_SP_DIR

SAML SP directory, where SP specific required files (such as certificates and metadata file) are placed (default value: /etc/trento/saml)

SAML_SP_ENTITY_ID

SAML SP entity id. This value must match with the entity ID configured in the IDP as SAML client (default value: https://#{TRENTO_WEB_ORIGIN}/sso/sp/metadata/#{SAML_IDP_ID})

SAML_SP_CONTACT_NAME

SAML SP contact name (default value: Trento SP Admin)

SAML_SP_CONTACT_EMAIL

SAML SP contact email (default value: admin@trento.suse.com)

SAML_SP_ORG_NAME

SAML SP organization name (default value: Trento SP)

SAML_SP_ORG_DISPLAYNAME

SAML SP organization display name (default value: SAML SP build with Trento)

SAML_SP_ORG_URL

SAML SP organization url (default value: https://www.trento-project.io/)

SAML_USERNAME_ATTR_NAME

SAML user profile "username" attribute field name. This attribute must exist in the IDP user (default value: username)

SAML_EMAIL_ATTR_NAME

SAML user profile "email" attribute field name. This attribute must exist in the IDP user (default value: email)

SAML_FIRSTNAME_ATTR_NAME

SAML user profile "first name" attribute field name. This attribute must exist in the IDP user (default value: firstName)

SAML_LASTNAME_ATTR_NAME

SAML user profile "last name" attribute field name. This attribute must exist in the IDP user (default value: lastName)

SAML_SIGN_REQUESTS

Sign SAML requests in the SP side (default value: true)

SAML_SIGN_METADATA

Sign SAML metadata documents in the SP side (default value: true)

SAML_SIGNED_ASSERTION

Require to receive SAML assertion signed from the IDP. Set to false if the IDP doesn’t sign the assertion (default value: true)

SAML_SIGNED_ENVELOPES

Require to receive SAML envelopes signed from the IDP. Set to false if the IDP doesn’t sign the envelopes (default value: true)

9.2.5. Troubleshooting failed login

In some cases, the IDP successfully authenticates a user, but Trento fails to create a session and displays a "Login Failed" page. This typically indicates that Trento encountered an error while processing the authentication response.

To find the specific cause:

  • Open the Network tab in your browser’s Developer Tools

  • Attempt the login again

  • Look for a 4xx HTTP response

  • View the Response payload. This contains the internal error details, such as missing required user attributes, needed to troubleshoot the failure

For example, the error Some mandatory SAML user attributes are missing means that Trento didn’t receive some expected user attributes. Have a look into the Configuring SAML user profile section.

9.3. Tracking events and user actions with the Activity Log

Trento collects system events and user actions in the Activity Log. It records what happened in the monitored landscape and who triggered the event. With the Activity Log, you can discover health and heartbeat changes, host de-registrations, login attempts, user updates and more.

The Activity Log can be accessed from the left-hand side panel of the Trento console.

9.3.1. Understanding an Activity Log entry

Entries are listed from newest to oldest. Each entry in the Activity Log includes the following information:

Timestamp

When the system event or user action occurred. Timestamps are displayed in the user’s preferred timezone, which is set in the user profile. If no preference is set, times default to UTC.

Message

Type of the occurred event or user action.

User

The user that triggered the event or performed the action. User system marks events triggered by the system itself.

Severity status

The log shows Info, Warning and Critical entries by default.

The list view is a summary. To see the full context of an entry, such as the affected resource and the values involved, click the chevron icon (>) on the entry. This opens the Activity Details window with the activity metadata.

9.3.2. Filtering for relevant log entries

You can use filters to isolate the entries you are interested in. For more specific queries, use the search field to find exact terms from the activity metadata, such as a specific host name or setting value.

  1. In the Activity Log view, set one or more of the following filters:

    • User: The user who triggered the entry. Only active users are available for filtering.

    • Type: The type of event or user action.

    • Severity: Info, Warning, Critical, or Debug.

    • From date and To date: A date and time range. Both accept user’s preferred timezone. If no preference is set, time defaults to UTC.

  2. To match the content of the activity metadata, enter a query in the search field.

    The field supports wildcards and the OR and AND logical operators, which you can combine in a single query. Operators are parsed from left to right, and OR is applied by default. For example, the query term1 term2 term3 is treated as term1 OR term2 OR term3.

  3. Click Apply Filter.

To remove all the filters, click Reset Filters.

9.3.3. Following a chain of related events

Certain user actions and system events trigger a multi-step workflow that produces several log entries. Trento correlates those entries, so that you can review the workflow as one chronological, linear chain instead of reconstructing it from individual entries.

Example workflows that produce such chains include:

  • De-registration of hosts

  • API key re-generation

  • SUSE Multi-Linux Manager settings save or update

  • Host, cluster and SAP operations

For example, cleaning up a host that runs a single-instance SAP HANA database de-registers the database instance, the database itself, the SAP system and its instances, and then the host.

To review the whole chain:

  1. Click the chevron icon (>) for the action that is a part of the workflow to open the Activity Details window.

  2. In the Related Events section, click Show Events.

    The Activity Log is then automatically filtered by correlation_id to show you the chain of related events.

Not every entry must belong to a chain. If an entry is not part of a larger workflow, clicking Show Events filters the log to display only that single entry.

9.3.4. Refreshing the Activity Log

New entries are not automatically added to an open view. Click Refresh to load any new entries generated since the view was opened or last refreshed. If you are monitoring an ongoing operation, select an auto-refresh interval instead and let the view update itself.

9.3.5. Getting access to user data

Not every user sees the same Activity Log. Permissions govern which entries are listed, and whether the user names in them are readable.

all:all and all:users

Entries related to user management can only be displayed by users that have the all:all or all:users permissions.

This includes for example:

  • Login attempts

  • User creations

  • User modifications

  • User deletions

  • Profile updates

activity_log:users

This permission controls a privacy-related access level. For users without this permission, only their own user name and the user system is visible in the Activity Log.

For more information about permissions, see User management.

9.3.6. Modifying log retention time

Entries are retained for one month by default. Increase the retention time if you need a longer audit history, or reduce it to limit database growth. Changing it requires the all:settings permission.

  1. In the left sidebar of the Trento Web console, click Settings.

  2. In the Activity Logs section, click Edit Settings.

  3. Set the desired retention time and save the change.

Entries older than the retention time are deleted every day at midnight UTC. The cleanup schedule always uses UTC, regardless of the preferred timezone that the console uses to display timestamps.

9.4. Housekeeping

When the heartbeat of an agent fails, an option to clean-up the corresponding host is displayed in the Hosts overview and the corresponding Host details view.

trento-cleanup-hosts-overview
Figure 5. Clean up button in Hosts overview
trento-cleanup-host-details-view
Figure 6. Clean up button in Host details view

Use the Clean up button to remove all the components discovered by the agent in the host (including the host itself and other components that might depend on the ones running on the host) from the console.

For example, when cleaning up the host where the primary application server of an SAP System is registered, the entire SAP System is removed from the console.

Similarly, when a registered application or SAP HANA instance is no longer discovered, an option to clean it up is displayed in the corresponding overview and the corresponding details view.

trento-cleanup-sap-instance-overview
Figure 7. Clean up button SAP systems overview
trento-cleanup-sap-instance-details-view
Figure 8. Clean up button in SAP system details view

Use the Clean up button to remove the instance and any dependencies from the console.

For example, cleaning up the ASCS instance of an SAP system removes the entire SAP system from the console.

9.5. Managing Trento Server storage

To preserve peak performance and manage disk space, administrators can optimize the storage used by Trento Server by adjusting data retention.

Several factors impact the amount of storage Trento Server uses, such as:

Database event retention

The number of registered events stored in the database. The default retention time is 10 days. You can change the default retention by following the configuration procedures in this section.

Activity log retention

The retention time for entries in the Activity Log. The default retention time is 1 month. You can change the default retention through the UI as described in Modifying log retention time.

Component log level

The log level for the different components of Trento Server. The debug level produces considerably more traces than the default info level. For more information about log levels, see Configuring log levels.

A shorter retention time reduces storage consumption but limits the capability to analyze and troubleshoot issues beyond that time frame.

The event pruning feature allows administrators to manage how long registered events are stored in the database and how often the expired events are removed.

The following configuration options are available:

Kubernetes option systemd option Description Default value

pruneEventsOlderThan

PRUNE_EVENTS_OLDER_THAN

The number of days registered events are stored in the database.

10

pruneEventsCronjobSchedule

PRUNE_EVENTS_INTERVAL

The frequency of the cron job that deletes expired events. The default runs daily at midnight.

"0 0 * * *"

9.5.1. Configuring event retention on Kubernetes deployments

For Kubernetes deployments, use the helm upgrade command to set the configuration options.

Example command to retain events for 30 days and schedule pruning daily at 3 AM:

helm upgrade \
   --install trento-server oci://registry.suse.com/trento/trento-server \
   --set global.trentoWeb.origin=TRENTO_SERVER_HOSTNAME \
   --set trento-web.adminUser.password=ADMIN_PASSWORD \
   --set prometheus.enabled=false \
   --set trento-web.pruneEventsOlderThan=30 \
   --set trento-web.pruneEventsCronjobSchedule="0 3 * * *"

9.5.2. Configuring event retention on systemd deployments

For systemd deployments, perform the following steps:

  1. Add or modify the environment variables in the /etc/trento/trento-web Trento Web configuration file:

    Example values that retain events for 30 days and schedules pruning daily at 3 AM:

    PRUNE_EVENTS_OLDER_THAN=30
PRUNE_EVENTS_INTERVAL="0 3 * * *"

  2. Restart the trento-web service for the changes to take effect:

    systemctl restart trento-web

9.6. Configuring log levels

You can adjust the level of detail that Trento Server components write to their logs to manage disk space, capture more detailed information, for example for troubleshooting purposes, or to reduce log noise. The available log levels are debug, info, warning and error, and the default level is info for every component and deployment type. You can change log levels for Trento Web, Trento Wanda and Trento MCP Server.

The Trento MCP Server has a separate implementation with its own configuration options and naming conventions, using verbosity instead of log level. The configuration settings described in this section, such as global.logLevel in Helm or trento_log_level in Ansible, do not influence Trento MCP Server.

To set the log level of the Trento MCP Server with its own options, see the documentation at MCP Integration.

9.6.1. Available log levels

Every trace starts with its log level, so you can identify which level produced each line. For example:

08:56:57.668 [info] Access TrentoWeb.Endpoint at http://localhost:4000
08:56:57.760 [debug] Attempting to start Postgrex

A component outputs logs for the configured level and all higher-severity levels. For example, setting the level to warning also includes error traces.

The following log levels are available, listed from lowest to highest severity:

debug

Troubleshooting level. Prints low-level traces that help analyze the behavior of the system. We recommend this level when you prepare a support case.

Log level changes apply only to new traces. Diagnostic data collected from a component that ran at the info level does not contain the debug traces that support might need.

To gather the needed logs, set the log level to debug and reproduce the issue. For more information about collecting diagnostic data, see Reporting an issue.

After the diagnostic data is collected, we recommend setting the level back to info to prevent excessive disk consumption.
info

Default level. Prints traces of standard actions that serve informative purposes.

warning

Prints traces about potentially dangerous situations that require attention. These traces do not mean that the system works incorrectly.

error

Prints traces about failures or about data that a component receives but cannot process. These traces require attention.

9.6.2. Configuring log levels on Kubernetes deployments

For Kubernetes deployments, use the helm upgrade command to set the log level.

  • To use the same log level for Trento Web and Trento Wanda, set global.logLevel:

    helm upgrade \
   --install trento-server oci://registry.suse.com/trento/trento-server \
   --set global.logLevel=warning \
   ...

  • To use a different log level for each component, set the component-specific flags: trento-web.logLevel and trento-wanda.logLevel. A component option takes precedence over global.logLevel:

    helm upgrade \
   --install trento-server oci://registry.suse.com/trento/trento-server \
   --set trento-web.logLevel=info \
   --set trento-wanda.logLevel=debug \
   ...

To set the log level of the Trento MCP Server, see Adjust Log Verbosity.

9.6.3. Configuring log levels on systemd deployments

For systemd deployments, perform the following steps:

  1. Add or modify the LOG_LEVEL variable in the configuration file of the component.

    To set the log level for Trento Web, edit /etc/trento/trento-web. To set the log level for Trento Wanda, edit /etc/trento/trento-wanda:

    LOG_LEVEL=debug

  2. Restart the services for the changes to take effect:

    systemctl restart trento-web
systemctl restart trento-wanda

To set the log level of the Trento MCP Server, see Configure Trento MCP Server.

9.6.4. Configuring log levels with Ansible

For Ansible deployments, the log level is a role-level variable. Set it in the vars: section of the inventory file, or pass it on the command line with --extra-vars. For more information about role-level variables, see Role-level configuration.

  • To use the same log level for Trento Web and Trento Wanda, set the trento_log_level variable:

    all:
  vars:
    trento_log_level: "debug"

  • To use a different log level for each component, set the component-specific variables: web_log_level and wanda_log_level. A component variable takes precedence over trento_log_level:

    all:
  vars:
    web_log_level: "info"
    wanda_log_level: "debug"

  • To set the variables during a playbook run, use the --extra-vars option:

    ansible-playbook -i PATH_TO_INVENTORY suse.trento.site --extra-vars trento_log_level=debug

9.7. Managing tags

Tags are used to label specific objects with location, owner, etc. The objects can be hosts, clusters, databases or SAP systems. Tags make it easier to distinguish and show all these different objects, making your lists more readable and searchable. You can use any text you like to create your tags except blank spaces and special characters other than + - = . , _ : and @.

The following subsection shows how you can add, remove, and filter objects based on your tags.

9.7.1. Adding tags to hosts, clusters, databases, and SAP Systems

To add one or more tags to your objects, proceed as follows:

  1. Log in to Trento.

  2. In the Trento dashboard, go to the overview of the desired object. For example, the Hosts overview.

  3. In the Hosts overview, search for the host you want to tag.

  4. In the Tags column, click the Add Tag entry.

  5. Enter the desired tag and press Enter.

  6. Use the described steps to assign other tags to the same or a different host.

You can use the procedure to assign tags to other objects, such as Clusters, SAP Systems, or HANA Databases.

9.7.2. Removing tags

To remove existing tags, click the appropriate part in the dashboard:

  1. Log in to Trento.

  2. In the Trento dashboard, go to the overview of the desired object. For example, the Hosts overview.

  3. In the Hosts overview, search for the host you want to remove a tag from.

  4. In the Tags column, click the × icon to remove the tag.

  5. Use the described steps to remove other tags from the same or a different host.

9.7.3. Filter by tags

Tags can be used to filter objects.

  1. In the Trento dashboard, go to the desired overview.

  2. In the second row, click the Filter tags drop-down list to view all existing tags.

  3. Select one or more tags to display all hosts that have the selected tags.

To remove the filter, click the × icon from the same drop-down list.

9.8. Rotating API keys

Communication from the Trento Agent to the Trento Server is secured by a API key that must be provided in the agent configuration file.

By default, the API key does not have an expiration date. You can set up a custom expiration date to increase the overall security of the setup and meet internal security requirements. If an expiration date is configured, it is displayed in the user’s timezone but stored in UTC.

To do this, go to the Settings view and click the Generate Key button in the API Key section:

trento-api-key-settings
Figure 9. Checks catalog

Whenever a new key is generated, the configuration of all the reporting agents must be updated accordingly.

9.9. Personal access tokens

Trento allows users to create personal access tokens (PATs) for authentication and authorization purposes in third-party integrations with the APIs exposed by its components:

9.9.1. Creating a personal access token

Log in to Trento Web UI, click on your username in the top-right corner, and select Profile from the drop-down menu.

trento-web-profile
Figure 10. Profile

  1. Click Generate Token in the Personal Access Tokens section.

  2. When prompted, provide a name and an expiration date (shown in the user’s timezone but stored in UTC), then click Generate Token.

    trento-web-generate-pat
    Figure 11. Generate personal access token modal

  3. Copy the generated token starting with trento_pat_. Keep in mind that the token is shown only once. If you lose the token, you must generate a new one.

    trento-web-generated-pat
    Figure 12. Generated personal access token

9.9.2. Using a personal access token

You can use the created personal access token to authenticate API requests by including it in the Authorization header as a Bearer token.

$ curl -X GET "..." -H "Authorization: Bearer trento_pat_<rest_of_token>"

9.9.3. Deleting a personal access token

To delete personal access token, click its contextual Delete button in the Personal Access Tokens section of the profile.

trento-web-pats-list
Figure 13. Personal access tokens section

Confirm the deletion

trento-web-delete-pat-confirmation
Figure 14. Delete personal access token modal

9.9.4. Notes for user admins

User admins can delete tokens for other users. However, admins cannot create new tokens for other users.

To delete a token for another user, a user admin must perform the following steps:

  1. navigate to the Users page

  2. select a user

  3. click a token’s contextual Delete button in the Personal Access Tokens section

10. Compliance Features

10.1. Performing configuration checks

Trento provides configuration checks that ensure your infrastructure setup adheres to our or other vendor’s Best Practices, and it does not diverge with time. Configuration checks are available for HANA clusters, ASCS/ERS clusters and hosts. The following procedure is specific to a HANA cluster. The procedure for an ASCS/ERS cluster or a host would be exactly the same, except it starts from the corresponding Details view.

  1. Log in to Trento

  2. In the left panel, click Cluster.

  3. In the list, search for a SAP HANA cluster.

  4. Click the desired cluster name in the Name column. The Details view opens.

    trento-web-pacemaker-cluster-details-view
    Figure 15. Pacemaker cluster details

  5. Click the Settings button to change the cluster settings of the respective cluster. For checks to be executed, a checks selection must be made. Select the checks to be executed and click Select Checks for Execution.

    trento-web-pacemaker-clustersettings-checks
    Figure 16. Pacemaker Cluster Settings—Checks Selection

  6. You can then either wait for Trento to execute the selected checks or trigger an execution immediately by clicking the button in the Checks Selection tab.

  7. Investigate the result in the Checks Results view. Each row in the view displays a check ID, a short description of the check and the check execution result. Click on a row to open a section that provides information about the execution on each node of the cluster.

    trento-web-checkresult
    Figure 17. Check results for a cluster

    The result of a check execution can be passing, warning, critical:

    • Passing means that the checked configuration meets the recommendation.

    • Warning means that the recommendation is not met but the configuration is not critical for the proper running of the cluster.

    • Critical means that either the execution itself failed (for example, a timeout) or the recommendation is not met and is critical for the well-being of the cluster.

      Use the filter to narrow the list to specific results (for example, critical).

  8. Click a check’s link to open a modal box with the check description. This displays an abstract and a possible solution to the problem. The References section contains links to the documentation from the different vendors for more context when necessary. Close the modal box by pressing the Esc key or click outside of the box.

    For each unmet expected result, there is a detailed view with information about it: what facts were gathered, what values were expected, and what was the result of the evaluation. This helps to understand why a certain configuration check is failing:

    trento-web-nonmetexpectation
    Figure 18. Unmet expected result detail view

When checks for a given cluster have been selected, Trento executes them automatically every five minutes, updating the results. A spinning check execution result icon means that an execution is running.

10.2. Checks Customization

10.2.1. Overview of checks Customization

Trento makes it possible to adjust expected check values to match target-specific requirements. This can be done directly through the Trento Web console without modifying the original check or impacting other targets.

The Trento web console receives a check catalog from Wanda. In the check selection view of a specific target, you can see all available check categories. Click on a category to expand the list of checks associated with it. If you have the required permissions, a settings icon appears to the right of a customizable check. Click on the settings icon to open a modal window where you can adjust check values.

The check customization modal includes the following elements:

  • Selected Check ID.

  • Check description.

  • Warning message that neither Trento nor SUSE can be held responsible for system malfunctions caused by deviations in the target configuration from best practices.

  • A list of all customizable check values. Each value includes a value name with the original default check value and an input field with the current customized or default value.

  • The current target-specific provider.

  • Save, Reset and Close buttons at the bottom.

The Save button is disabled by default. The button is enabled when the user checks the warning and modifies a value. The custom values are stored in the Wanda’s database, so they persist across system reboots.

The Reset button is enabled only when the check has been customized. Use the button to reverse the changes.

A Modified Pill indicator next to the check ID indicates that the values have been customized. A Reset icon next to the Settings icon can be used to revert to default values.

10.2.2. Target-specific check customization

A check is always executed on a target, which can be a host or a cluster. Users can customize check values specific to the target environment to ensure optimal system performance. Customizations are target-specific, and they do not affect other targets or the original default check values.

10.2.3. Required permissions

Only admin users and users with the all:checks_customization permission can customize checks. The customization button in the Trento Web console is not shown for users without this permission. If a check has been modified, the modified Pill is shown for all users.

10.2.4. Customizable checks

All checks with the following value types are customizable:

  • String

  • Number

  • Boolean

User input is validated to ensure that the input value matches the expected type before allowing to save the custom values in Wanda’s database. If the input type is incorrect or mixed, the customization fails, triggering a toast notification, that checks customization failed and a warning message in the modal itself.

10.2.5. Check customization persistence

Customized check values are persistently stored in Wanda’s database. This ensures that any modifications made by users are consistently applied across subsequent executions. Additionally, customized values remain in effect even after system restarts or updates, ensuring continuous adherence to target-specific configurations.

11. Monitoring SAP health in the Trento Web console

Trento Web combines the individual values of your SAP landscape into one aggregated health value per host, cluster, SAP HANA database and SAP system. You can therefore use the Trento Web console to identify which parts of your SAP landscape need attention.

This document explains what the health values mean, which factors Trento combines to calculate them, how to recognize outdated data, and how to trace a warning or a critical value back to its source.

To access this data, use the left sidebar in the Trento Web console. It contains the following entries:

Dashboard

Identify at a glance which SAP systems need attention, and filter systems by health value.

Hosts

Review all hosts that run the Trento Agent, including, for example, their tuning status, available software updates or check results.

Clusters

Review all discovered Pacemaker clusters, their configuration and their node health.

SAP Systems

Review all discovered SAP systems by system ID, including the status of each instance.

SAP HANA Databases

Review all discovered SAP HANA databases by system ID, including the status of each database instance.

Checks catalog

Browse the configuration checks that Trento can run, by target type (hosts or clusters), cluster type (HANA scale up, HANA scale out or ASCS/ERS) and supported platform (Azure, AWS, GCP, Nutanix, on-premises/KVM or VMware).

Activity Log

Review system events and user actions, with the timestamp, message, user, and severity of each entry.

Settings

Modify user-defined settings, including API keys, the SUSE Multi-Linux Manager connection, Activity Log retention, and email alerts.

About

View the Trento Server component versions, a link to the Trento Web GitHub repository, and the number of discovered SUSE Linux Enterprise Server for SAP applications subscriptions.

11.1. Understanding aggregated health in Trento

Every host, cluster, SAP HANA database and SAP system in Trento Web displays one health icon, which represents its aggregated health value. This value is the combination of several factors that Trento discovers separately.

To know why a component requires your attention, you need to know which factors contribute to its health. The following sections explain the aggregated health icons, factors for each component, and the rule that combines the factors into a single health value.

11.1.1. Aggregated health icons in Trento Web

Every health icon in Trento Web console shows one of the following values.

Table 1. Aggregated health in Trento Web console
Value Icon color Meaning

passing

Green

No action needed.

warning

Yellow

Needs attention, but not urgently.

critical

Red

Needs immediate attention.

stopped/unknown

Gray

A contributing component is not running, or Trento cannot determine its value. For example, when the connection to SUSE Multi-Linux Manager fails.

stale

Any of the previous colors, with a clock overlay

The value shown in the console is the last one received. The responsible Trento Agent has stopped reporting. For more information, see Identifying stale data.

A dash — in the dashboard means that no Pacemaker cluster manages the corresponding layer of that SAP system. It is not a health value and it needs no action.
Trento dashboard showing the passing
Figure 19. Dashboard with the dash indicators

11.1.2. How Trento calculates aggregated health

Trento evaluates each factor separately, then reduces the results to one aggregated value and reflects that value in the corresponding aggregated health icon in the Trento Web console. The factors are combined as follows:

passing

All factors passing

warning

At least one warning, all others passing

critical

At least one critical, all others warning or passing

stopped or unknown

At least one stopped or unknown, where applicable

Depending on the component, the aggregated health is calculated as a compound of different factors:

Table 2. Health factors per component
Component Contributing factors

Hosts

saptune tuning status, available software updates, check results

SAP HANA clusters

SAP HANA secondary sync state, check results, health of SBD devices

ASCS/ERS clusters

ASCS/ERS distribution status, check results, health of SBD devices

SAP HANA databases

Overall status of SAP HANA instances

SAP systems

Overall status of SAP instances, aggregated health of the SAP HANA database

Application instances in the dashboard

Status of SAP instances

Hosts in the dashboard

Aggregated health of hosts that belong to the SAP system and its database

Each factor is evaluated on its own, as follows:

saptune tuning status

Contributes only when Trento discovers an SAP workload on the host. saptune ships with SUSE Linux Enterprise Server for SAP applications and verifies that a host is configured for the workload it runs.

Condition Health value

saptune is not installed, or the version is lower than 3.1

warning

Version 3.1 or higher, but no solution applied

warning

Version 3.1 or higher, solution applied, tuning status compliant

passing

Version 3.1 or higher, solution applied, tuning status not compliant

critical
Available software updates

Contributes only when connection data for SUSE Multi-Linux Manager is saved under the Settings menu. For more information, see Integration with SUSE Multi-Linux Manager.

Condition Health value

The connection fails, the host is not found, or the data cannot be retrieved

unknown

No software updates are available

passing

Updates are available, none of them security related

warning

At least one available update is security related

critical
Check results

Contributes only when checks are selected to run on the target.

Condition Health value

All checks passing

passing

At least one check warning, all others passing

warning

At least one check critical, all others warning or passing

critical
SAP HANA secondary sync state

Applies to SAP HANA clusters only.

Condition Health value

SOK, meaning the secondary site is in sync

passing

SFAIL, meaning replication has failed

critical
ASCS/ERS distribution status

Applies to ASCS/ERS clusters only.

Condition Health value

ASCS and ERS instances run on different hosts

passing

Both run on the same host

critical
Health of SBD devices

Applies to clusters using file-based SBD fencing.

Condition Health value

All devices healthy

passing

At least one device not healthy

critical
Overall status of SAP HANA database instances / SAP instances

sapcontrol reports a status for each SAP HANA database instance and each SAP application instance, which Trento Web shows as a color.

Condition Health value

All GREEN

passing

At least one YELLOW, all others GREEN

warning

At least one RED, all others GREEN or YELLOW

critical

At least one GRAY

stopped

11.1.3. Aggregated health in the dashboard

The dashboard is the main page of Trento Web, and you can always return to it by clicking Dashboard in the left sidebar. It presents the health of each SAP system across the layers of the SAP architecture, and groups the systems in three health boxes:

Passing

Systems whose layers all report passing.

Warning

Systems with at least one layer with warning health and all remaining layers passing.

Critical

Systems with at least one layer with critical health.

Trento dashboard showing the Passing
Figure 20. Dashboard with the global health

The boxes are clickable. Clicking a box filters the dashboard by systems with a layer with that aggregated health, which is the fastest way to isolate the affected systems in a large landscape.

Two dashboard columns carry aggregated values of their own:

  • The Application instances value combines the status of the individual SAP instances of the system. Database instances are not taken into consideration here.

  • The Hosts value combines the aggregated health of all hosts that belong to the system and to its database.

For more information on how the aggregated health is calculated for those columns, see How Trento calculates aggregated health.

11.2. Identifying stale data

A Trento Agent is continuously sending up-to-date data to Trento Web. When an agent stops reporting, for example due to a connectivity issue, service crash, or host crash, Trento Web keeps displaying the last data it received from that agent.

Data that is no longer refreshed is marked as stale. A stale value was correct when it was last received, but it might not reflect the current health of the component. Therefore, the stale value should be treated as unverified until the agent reports again.

Trento Web marks stale data in the following ways:

  • Stale icon. The regular health icon is shown with a clock overlay.

  • Tooltip. When you hover over a stale icon, it displays the date and time the value became stale.

  • Warning banner. The Details views of affected hosts, clusters, SAP HANA databases and SAP systems display a warning banner.

  • Grayed-out rows. In relevant views, the row of the affected host, cluster, database, system or instance is grayed out.

  • Activity log entry. Trento creates an entry with severity debug when a value becomes stale.

Health icons with a clock overlay
Figure 21. Stale health icons
A banner with warning about agent not reporting
Figure 22. Stale warning banner
Table 3. How stale data affects each component
Component When it becomes stale Where you see it

Host

The agent of the host stops reporting

Stale icon in the relevant views, grayed-out row in the Hosts overview, warning banner in the Host Details view

Cluster

The agent of one of the cluster hosts stops reporting

Stale icon in the relevant views and in the dashboard, grayed-out row in the Clusters overview, warning banner in the Cluster Details view

SAP HANA database instance

The agent of the host that runs the instance stops reporting

Stale icon and grayed-out rows in the relevant views

SAP instance

The agent of the host that runs the instance stops reporting

Stale icon and grayed-out rows in the relevant views

SAP HANA database

The status of any of its instances becomes stale

Stale icon in the relevant views and in the dashboard, grayed-out row in the Databases overview, warning banner in the SAP HANA Database Details view

SAP system

The status of any of its instances becomes stale, including database instances

Stale icon in the relevant views, grayed-out row in the SAP systems overview, warning banner in the SAP System Details view

Application instances in the dashboard

The status of any application instance of the SAP system becomes stale

Stale icon in the dashboard

Hosts in the dashboard

The aggregated health of any host of the SAP system or of its database becomes stale

Stale icon in the dashboard

When you find a stale value, verify the reporting path before you investigate the component itself: check if the host is reachable and running, and whether the Trento Agent service is running on it.

Once the agent reports again, Trento Web replaces the stale value with the current one and removes the clock marker.

11.3. Finding the cause of a health issue

A non-passing aggregated health value indicates that something needs attention. To find out what, follow the aggregation from the dashboard to the factor that caused the non-passing health.

  1. In the Trento Web console Dashboard, click the health box that matches the value you want to investigate, for example Critical. The dashboard now lists only the systems with a layer matching health value.

  2. Identify the layer that carries the value and select the desired view. Each layer icon links to the view that holds the underlying data:

    • The application instances health icon opens the SAP System Detail view.

    • The application cluster health icon opens the ASCS/ERS Cluster Details view.

    • The database health icon opens the SAP HANA Database Details view.

    • The database cluster health icon opens the SAP HANA Cluster Details view.

    • The hosts health icon opens the Hosts overview, filtered by SID equal to the SAPSID and the DBSID of the corresponding SAP system.

  3. Check whether a stale banner is displayed. If it is, investigate the reporting problem first. For more information, see Identifying stale data.

  4. Identify the factor that caused the value and investigate, using the information in How Trento calculates aggregated health.

11.4. Configuring Trento Web settings

Users with the all:settings permission can use the Settings view of Trento Web to modify the following:

If any of the email settings are specified through environment variables, the web-based email configuration is disabled. For more information, see Enabling email alerts.

11.5. Troubleshooting

When monitoring your SAP landscape in the Trento Web console, you might encounter unfamiliar health icons, unexpected system values, or sudden alerts. The following frequently asked questions address common scenarios and provide immediate starting points for your investigation.

Why is a health icon gray?

A gray icon means either stopped or unknown health. Stopped means the component exists but is not running, as reported by sapcontrol. Unknown means Trento cannot determine the value, most often because the connection to SUSE Multi-Linux Manager fails, the host is not found, or the data cannot be retrieved.

Why does a health icon show a clock?

The clock marks a stale value. This happens when the responsible Trento Agent stops reporting. The console shows the last known value. Hover over the icon to see exactly when the value became stale. For more information on how to investigate stale data, see Identifying stale data.

Why does the dashboard show a dash (—) instead of a cluster health?

The dash means that no Pacemaker cluster manages that layer of the SAP system. The dash is not an error and requires no action.

The health of a host or cluster is warning or critical, but all checks pass. Where does the value come from?

Check results are only one of the factors Trento evaluates. Investigate the other contributing factors. For more information, see Finding the cause of a health issue.

An SAP system is critical, but all its instances are green. Why?

The aggregated health of the SAP HANA database contributes to the health of the SAP system. Investigate the SAP HANA Database Details view to find the root cause.

Why is the host showing a warning for saptune?

This happens when Trento discovers an SAP workload on the host, and either saptune is not installed, the installed version is older than 3.1, or no tuning solution is applied to the host. If the host shows a critical value instead, it means the tuning status is not compliant. In this last case, run saptune note verify on the host for further details.

The Activity Log is becoming cluttered with old events. Can old events be cleared automatically?

Trento Web allows you to configure automatic retention limits to manage storage consumption and reduce clutter. For steps on how to do this, see Tracking events and user actions with the Activity Log.

What is the fastest way to investigate email alerts, such as "Host stopped reporting" or "Cluster needs attention"?

These alerts are triggered by Trento’s event-driven architecture when a stale or critical value is detected. For the fastest way to investigate, see Finding the cause of a health issue.

How are pending software updates applied for hosts shown in Trento?

While Trento Web shows when updates are missing and flags the health as a warning or critical, the actual patching is managed by SUSE Multi-Linux Manager. Log into your SUSE Multi-Linux Manager interface to view and apply the specific packages for that host.

Which data should be collected before reporting an issue with Trento itself?

For information on which data to collect for support, see Reporting an issue.

12. Integration with SUSE Multi-Linux Manager

Trento can be integrated with SUSE Multi-Linux Manager to provide the SAP administrator with information about relevant patches and upgradable packages for any host that is registered with both applications.

The user must enter the connection settings for SUSE Multi-Linux Manager in the Settings view:

trento-suse-manager-settings
Figure 23. SUSE Multi-Linux Manager settings

When the SUSE Multi-Linux Manager settings are configured, the SAP Basis administrator can test the connection by clicking the Test button. If the connection is successful, the Host Details view of each host managed by SUSE Multi-Linux Manager displays a summary of available patches and upgradable packages:

trento-summary-of-available-software-updates
Figure 24. Available software updates in the Host Details view

Click Relevant Patches to view a list of patches available for the host:

trento-available-patches-overview
Figure 25. Available Patches overview

Click Upgradable Packages to view a list of packages that can be upgraded on that particular host:

trento-upgradable-packages-overview
Figure 26. Upgradable Packages overview

Click an advisory or patch link to access the corresponding details view with relevant information, such us whether it requires a reboot or not, associated vulnerabilities, or a list of affected hosts:

trento-advisory-details-view
Figure 27. Advisory Details view

There are three types of patches or advisories: security advisories, bug fixes and feature enhancements. Security advisories are considered critical. If an advisory is available, the health of the host is set to critical. If there are available patches but none of them is a security one, the health of the host switches to warning. When a host cannot be found in SUSE Multi-Linux Manager, or there is a problem retrieving the data for it, its health is set to unknown.

You can clear the SUSE Multi-Linux Manager settings from the Settings view at any time. When you do this, all information about available software updates disappears from the console, and the status of the hosts is adjusted accordingly.

13. Operations

Operations in Trento follow five principles:

  1. Permissions: Only users with operation:all permissions can perform operations.

  2. Contextual UI paths: The path to request an operation depends on the target. To enable maintenance on an entire cluster, use the Operation button in the cluster details view. To enable maintenance on a specific node or resource, use the options menu in the corresponding row.

  3. Single operation concurrency: Trento permits only one operation at a time on a target. While an operation runs, all other operations for that target (host, cluster, SAP system, or SAP HANA database) are disabled.

  4. Safety policies: Internal policies prevent users from executing operations that violate established best practices, even if the user has the permission to so. For example, if a user attempts to stop a SAP HANA database managed by a cluster, Trento forbids the operation and displays a reason. Each operation has specific internal policies that are listed in the use cases below.

  5. Target heartbeat: The execution of an operation depends on the heartbeat status of the target host(s). If the heartbeat is not active the operation is not allowed.

    1. Single-host resource operations: The target host must have an active heartbeat. This applies to operations in resources like: Host, Cluster node, SAP instance, etc.

    2. Multi-host resource operations: At least one constituent target host must have an active heartbeat. This applies to operations in resources like: Cluster, Database, SAP system, etc.

Internal policies prevent users from making basic operational mistakes, but they cannot guarantee that an operation will not damage the environment. The user is ultimately responsible for performing operations.

Every operation request generates an entry in the activity log with a specific activity type. After a successful operation request, Trento attempts to perform the operation. The activity log records the completion of the operation, regardless of success, with the activity type Operation Completed. This entry correlates to the request entry (see Activity Log for details). If an operation fails, the Operation Completed entry provides additional troubleshooting data: the errors field provides detailed reasons for each affected target and the failed_step field identifies where the operation failed. In such cases, Trento restores the original state by rolling back the operation.

To prevent endless execution when an agent is unresponsive, an internal timeout constrains every operation. When the timeout is reached, the operation execution resets.

13.1. Host operations

For any registered host, the details view provides the following operations:

  • Apply saptune Solution: Enabled when an SAP workload is discovered on the host, but no saptune solution is applied. Trento restricts the available solutions based on the SAP workload type. If the SAP workload is a SAP HANA instance, the choice is between HANA and S4HANA-DESERVER. If the SAP workload is an application instance, the choice is between NETWEAVER and S4HANA-APPSERVER.

    • Activity type: Host Operation Requested

    • Internal policies: The SAP workload must be stopped.

    • Internal timeout: 5m

  • Change saptune Solution: Enabled when an SAP workload is discovered on the host and a saptune solution is already applied. As with the apply operation, Trento restricts the available solutions based on the SAP workload type.

    • Activity type: Host Operation Requested

    • Internal policies: The SAP workload must be stopped.

    • Internal timeout: 5m

  • Reboot Host: Schedules a reboot of the target host within one minute of the request.

    • Activity type: Host Operation Requested

    • Internal policies:

      • If an SAP workload is discovered on the host, it must be stopped.

      • If the host is a cluster node, the Pacemaker service must be disabled at boot and stopped (the node must be offline).

    • Internal timeout: 5m

13.2. Cluster operations

When a user requests a cluster operation, Trento checks the cluster state running crmadmin -qS NODE (NODE being the DC node). If the command returns any state other than IDLE, the operation fails. This restriction prevents users from executing operations while the cluster is in transition.

For any registered cluster, the details view provides the following operations:

  • At cluster level:

    • Cluster maintenance: Enabled when at least one node in the cluster is online. It turns maintenance on or off in the cluster, depending on the current status.

      • Activity type: Cluster Operation Requested

      • Internal policies: Not applicable.

      • Internal timeout: 5m

    • Refresh resources: Enabled when at least one node in the cluster is online. It refreshes all the resources in the cluster.

      • Activity type: Cluster Operation Requested

      • Internal policies: Not applicable.

      • Internal timeout: 5m

  • At node level:

    • Node maintenance: Enabled when the node is online. It turns maintenance on or off in the node, depending on its current status.

      • Activity type: Operation Requested on a cluster host

      • Internal policies: Not applicable.

      • Internal timeout: 5m

    • Enable Pacemaker at boot: Enabled when the service is disabled at boot in the corresponding host.

      • Activity type: Operation Requested on a cluster host

      • Internal policies: Not applicable.

      • Internal timeout: 5m

    • Disable Pacemaker at boot: Enabled when the service is enabled at boot in the corresponding host.

      • Activity type: Operation Requested on a cluster host

      • Internal policies: Not applicable.

      • Internal timeout: 5m

    • Set node online in cluster: Enabled when the node is offline.

      • Activity type: Operation Requested on a cluster host

      • Internal policies: In a SAP HANA cluster, if the node is managing a secondary instance, all the nodes managing primary instances must be online.

      • Internal timeout: 5m

    • Set node offline in cluster: Enabled when the node is online.

      • Activity type: Operation Requested on a cluster host

      • Internal policies: In a SAP HANA cluster, if the node is managing a primary instance, all the nodes managing secondary instances must be offline.

      • Internal timeout: 5m

  • At resource level:

    • Resource maintenance: Enabled when at least one node in the cluster is online. It turns maintenance on or off in the resource, depending on its current status.

      • Activity type: Cluster Operation Requested

      • Internal policies: Not applicable.

      • Internal timeout: 5m

    • Refresh resource: Enabled when at least one node in the cluster is online. It refreshes the resource.

      • Activity type: Cluster Operation Requested

      • Internal policies: Not applicable.

      • Internal timeout: 5m

13.3. SAP HANA operations

For any registered SAP HANA database, the details view provides the following operations at the top:

  • Start database: Enabled when the database, or any database site in a HANA replication setup, is stopped. It calls sapcontrol with the function StartSystem. In a HANA replication setup, it starts the entire database layer, calling the sapcontrol function in each database site ordered by the tier number from smallest to highest.

    • Options:

      • Timeout: Establishes the time in minutes that Trento waits for the database to start before initiating a rollback.

    • Activity type: Database Operation Requested

    • Internal policies:

      • If the database is managed by a Pacemaker cluster, the corresponding multistate resource or the cluster itself must be in maintenance mode.

    • Internal timeout: 12 hours

  • Stop database: Enabled when the database, or any database site in a HANA replication setup, is started. It calls sapcontrol with the function StopSystem. In a HANA replication setup, it stops the entire database layer, calling the sapcontrol function in each database site ordered by the tier number from highest to smallest.

    • Options:

      • Timeout: Establishes the time in minutes that Trento waits for the database to stop before initiating a rollback.

    • Activity type: Database Operation Requested

    • Internal policies:

      • If the database is managed by a Pacemaker cluster, the corresponding multistate resource or the cluster itself must be in maintenance mode.

      • If there is an application layer (SAP system) on top of the database, all application server instances must be stopped.

    • Internal timeout: 12 hours

For any registered SAP HANA database that is part of a HANA replication system, the details view provides the following operations in the different layout sections:

  • Start database: Enabled when the database site is stopped. It calls sapcontrol with the function StartSystem.

    • Options:

      • Timeout: Establishes the time in minutes that Trento waits for the database to start before initiating a rollback.

    • Activity type: Database Operation Requested

    • Internal policies:

      • If the database is managed by a Pacemaker cluster, the corresponding multistate resource or the cluster itself must be in maintenance mode.

      • If the database site is a secondary one, the database site being replicated must be started.

    • Internal timeout: 12 hours

  • Stop database: Enabled when the database site is started. It calls sapcontrol with the function StopSystem.

    • Options:

      • Timeout: Establishes the time in minutes that Trento waits for the database to stop before initiating a rollback.

    • Activity type: Database Operation Requested

    • Internal policies:

      • If the database is managed by a Pacemaker cluster, the corresponding multistate resource or the cluster itself must be in maintenance mode.

      • If the database site is being replicated (by a secondary or disaster recovery site), the replicating database site must be stopped.

      • If the database site is a primary one and there is an application layer (SAP system) on top of the database, all application server instances must be stopped.

    • Internal timeout: 12 hours

13.4. SAP operations

For any registered SAP system, the details view provides the following operations:

  • Start system: Enabled when at least one instance of the system is stopped. It calls sapcontrol with the function StartSystem and the parameter selected as Instance Type:

    • Options:

      • Instance Type: The available values are:

        • All instances: Select to start all the instances in the system.

        • ABAP: Select to start the instances with ABAP work processes.

        • J2EE: Select to start the instances with J2EE work processes.

        • ASCS/SCS: Select to start the instance with a message server and an enqueue server.

        • ENQREP: Select to start the instance with an enqueue replication server.

      • Timeout: Establishes the time in minutes that Trento waits for the SAP system to start before initiating a rollback.

    • Activity type: SAP System Operation Requested

    • Internal policies: If any of the instances included in the Instance Type selection is managed by a cluster, the corresponding resource or the cluster itself must be in maintenance mode.

    • Internal timeout: 1h

  • Stop system: Enabled when at least one instance of the system is started. It calls sapcontrol with the function StopSystem and the parameter selected as Instance Type:

    • Options:

      • Instance Type:

        • All instances: Select to stop all the instances in the system.

        • ABAP: Select to stop the instances with ABAP work processes.

        • J2EE: Select to stop the instances with J2EE work processes.

        • ASCS/SCS: Select to stop the instance with a message server and an enqueue server.

        • ENQREP: Select to stop the instance with an enqueue replication server.

      • Timeout: Establishes the time in minutes that Trento waits for the SAP system to stop before initiating a rollback.

    • Activity type: SAP System Operation Requested

    • Internal policies: If any of the instances included in the Instance Type selection is managed by a cluster, the corresponding resource or the cluster itself must be in maintenance mode.

    • Internal timeout: 1h

  • Start instance: Enabled when the instance is stopped. It calls sapcontrol with the corresponding instance number and function Start in the host where the instance was discovered.

    • Activity type: Application Instance Operation Requested

    • Internal policies:

      • If the instance is managed by a cluster, the corresponding resource or the cluster itself must be in maintenance mode.

      • In the case of an application server instance, the ASCS/SCS instance and the database must be running.

      • In the case of an ERS instance, the ASCS/SCS instance must be running.

    • Internal timeout: 5m

  • Stop instance: Enabled when the instance is started. It calls sapcontrol with the corresponding instance number and function Stop in the host where the instance was discovered.

    • Activity type: Application Instance Operation Requested

    • Internal policies:

      • If the instance is managed by a cluster, the corresponding resource or the cluster itself must be in maintenance mode.

      • In the case of an ASCS instance, the application server instances and, if it exists, the ERS instance must be stopped.

    • Internal timeout: 5m

14. Reporting an issue

To report an issue with Trento, open a support case through the appropriate channel, collect the required diagnostic data from Trento Server and the relevant Trento Agents, and attach all that information to your support case.

14.1. Opening a support case

SUSE customers with registered SUSE Linux Enterprise Server for SAP applications 15 (SP4 or higher) or SUSE Linux Enterprise Server for SAP applications 16 distributions can report Trento issues either directly in the SUSE Customer Center or through the corresponding vendor, depending on their licensing model.

  • Report the problems under SUSE Linux Enterprise Server for SAP applications 15 or 16 and component trento.

  • Specify the relevant deployment option for Trento Server: Kubernetes, or systemd deployment.

  • Depending on your deployment type, use the corresponding procedure to collect and provide either K3s server diagnostic data or systemd server diagnostic data.

    If the issue is reproducible, set the log level of the affected components to debug, reproduce the issue and then collect the diagnostic data. Traces written before the change are not affected by the new level. For more information, see Configuring log levels.

  • If the issue involves a particular Trento Agent or a component discovered by it, you must also provide Trento Agent diagnostic data.

14.2. Collecting Trento Server diagnostic data: K3s deployments

For K3s (Kubernetes) deployments, provide the output of the Trento support script, a scenario dump, pod descriptions and pod logs.

Before proceeding, ensure your host meets the following requirements:

  • A SUSE Linux Enterprise Server for SAP applications 15 SP4 or higher is installed.

  • Packages jq and yq are installed.

  • Helm is installed.

  • kubectl is installed and connected to the Kubernetes cluster where Trento Server is running.

  1. Use the Trento support plug-in to automate the collection of logs and relevant runtime information on the server side.

    1. Install the plug-in package:

      zypper ref
zypper install supportutils-plugin-trento

    2. Run the trento-support.sh script:

      trento-support --output file-tgz --collect all

      The script accepts the following options:

      • -o, --output Output type (stdout, file, file-tgz)

      • -c, --collect Collection options (configuration, base, kubernetes, all)

      • -r, --release-name Release name to use for the chart installation. Default is trento-server

      • -n, --namespace Kubernetes namespace used when installing the chart. Default is default

      • --help Shows help messages

    3. Save the generated archive file to send to support.

  2. Generate a scenario dump of the database to help the Trento team re-create and test the scenario.

    1. Download the latest version of the dump script from the Trento upstream project:

      wget https://raw.githubusercontent.com/trento-project/web/main/hack/dump_scenario_from_k8.sh

    2. Make the script executable:

      chmod +x dump_scenario_from_k8.sh

    3. Run the script:

      ./dump_scenario_from_k8.sh --name SCENARIO_NAME --path PATH

    4. Package all generated JSON files found under PATH/scenarios/SCENARIO_NAME to send to support.

  3. Collect pod descriptions and logs to provide additional context and details for support.

    1. List the pods running in Kubernetes cluster to view their statuses and names:

      kubectl get pods

    2. Retrieve the description of a pod:

      kubectl describe pod POD_NAME

    3. Retrieve the log of a pod:

      kubectl logs POD_NAME

    4. Save the generated pod descriptions and log outputs to text files to send to support.

14.3. Collecting Trento Server diagnostic data: systemd deployments

For systemd environments, provide the output of the Trento support plug-in, which automates the collection of logs and relevant runtime information on the server side.

  1. Install the plug-in package:

    zypper ref
zypper install supportutils-plugin-trento

  2. Run the supportconfig command to call the plug-in. For more information on how to run this command, see https://documentation.suse.com/smart/systems-management/html/supportconfig/index.html.

    In systemd scenarios, the Trento support plug-in also generates a scenario dump when you run it.

  3. Save the generated output to send to support for analysis.

14.4. Collecting Trento Agent diagnostic data

For issues with a particular Trento Agent, or a component discovered by a Trento Agent, provide the following data:

15. Analytics

15.1. What is Analytics?

Analytics is the collection of information related to the installation of Trento and feature usage of the product. This information is used by the Trento team to help improve the product and it is not shared with third-parties.

15.2. What information is collected?

No specific information related to usernames, passwords and the names of user resource addresses will be collected.

Types of information that will be collected include:

  • Name of the page URLs.

  • Page links clicked.

  • Names of pages viewed.

  • Name and version of installed Trento application.

  • Unique randomly-generated identifier for each Trento Installation.

15.3. How to opt-in or opt-out analytics collection?

A user can manage their analytics preference by navigating to the Profile screen. They can then click the Analytics Opt-in toggle button to update their preference.

16. Compatibility matrix between Trento Server and Trento Agents

Table 4. Compatibility matrix between Trento Server and Trento Agents
Trento Agent Trento Server

1.0

1.1

1.2

2.0

2.1

2.2

2.3

2.4

2.5

3.0

3.1

1.0

✓

✓

✓

1.1

✓

✓

1.2

✓

2.0

✓

✓

✓

✓

✓

✓

2.1

✓

✓

✓

✓

✓

2.2

✓

✓

✓

✓

2.3

✓

✓

✓

2.4

✓

✓

2.5

✓

3.0

✓

✓

3.1

✓

17. Highlights of Trento versions

Below is a list of the most important user-facing features in the different versions of Trento. For a more detailed information about the changes included in each new version, visit https://github.com/trento-project.

Software Components

Packaging & Deployment

Version 3.1 (released on 2026/05/27, last updated: 2026/09/18)

Includes Helm chart 3.1.5, Trento Web component 3.1.6, orchestration engine (Wanda) 2.1.1, compliance checks 1.3.2, MCP Server 1.1.2, Trento Agent 3.1.3, and Trento Ansible 1.0.1 with the following highlights:

  • Opt-in analytics option

  • Timezone awareness

  • Integration with Grafana Alloy

  • Information about versions of all Trento Server components

  • Last boot information in Host details view

  • Improved AI capabilities by exposing collected host metrics to MCP Server

  • Improved monitoring of cluster shutdown

  • Filesystem and swap utilization dashboards in Host details view

  • Improved saptune gatherer

  • Improved UX around operations:

    • Cluster state information in Cluster details view

    • Troubleshooting information about operation failures in Activity Log

    • Heartbeat of target host taken into account when requesting operations

    • Direct access from operation forbidden modals to relevant details views

  • New operations:

    • Cluster resource refresh

    • Stop/start entire database layer in SAP HANA HA setups

  • Bug fixes:

    • Discovery of SAP HANA multi-tier setups

    • Flaky host heartbeat producing false negatives

    • Trento Agent requiring restart to connect to message broker

    • Enabling alert emails with Helm chart flags in Kubernetes deployments

Version 3.0.0 (released on 2025/12/16)

Includes Helm chart 3.0.0, Web Component 3.0.0, orchestration engine (Wanda) 2.0.0, compliance checks 1.2.0, MCP Server 1.0.0, and agent 3.0.0, with the following highlights:

  • First operation use cases

  • MCP Server integration

  • A more flexible, secure alert emails configuration

  • A more helpful activity log with correlation of entries

  • Improved observability around offline clusters and SAP HANA native HA scenarios (including multi target/tier setups)

  • Improved compliance validation with additional scenario-specific checks

Version 2.5.0 (released on 2025/08/07)

Includes Helm chart 2.5.0, Web Component 2.4.0, checks engine (wanda) 1.5.0, configuration checks 1.1.0 and agent 2.5.0, with the following highlights:

  • Discovery of HANA scale-up cost-optimized clusters

  • Checks customization

  • Enhanced activity log (search by metadata, auto refresh capabilities, severity information and permission-based access level)

  • A more flexible Prometheus integration

  • Discovery optimization in edge-case scenarios

  • Major updates to the Checks Catalog

Version 2.4.0 (released on 2024/12/06)

Consisting of Helm chart 2.4.0, Web component 2.4.0, checks engine (wanda) 1.4.0, configuration checks 1.0.0 and agent 2.4.0.

  • New permission-based user management system with optional MFA.

  • SSO and third-party IDP integration via OIDC, OAUTH2 and SAML protocols.

  • Contextual, detailed overview of available patches and upgradable packages in the SUSE Multi-Linux Manager integration.

  • Inception of the Activity Log, allowing users to browse a single centralized event log for their entire SAP landscape.

  • Trento Checks delivery is now decoupled from the core platform, and the Checks themselves have been relicensed from Apache 2.0 to GPL 3.0

  • Enhanced discovery capabilities including clusters using angi architecture and SAP systems running on JAVA stacks.

  • New HANA scale-out cluster configuration checks.

  • More ASCS/ERS cluster configuration checks.

Version 2.3.2 (released on 2024/09/01)

Consisting of Helm chart 2.3.2, Web component 2.3.2, checks engine (wanda) 1.3.0 and agent 2.3.0.

  • Fix for bug in the web component causing it to crash upon certain events after update from an earlier version.

Version 2.3.1 (released on 2024/06/18)

Consisting of Helm chart 2.3.1, Web component 2.3.1, checks engine (wanda) 1.3.0 and agent 2.3.0.

  • non-K8s installation of Trento Server.

  • Enhanced discovery capabilities, including improved support HANA multi-tenant architecture, HANA scale out cluster discovery, discovery of clsluters using diskless SBD and maintenance awareness.

  • Information about available patches and upgradable packages for each registered hosts via integration with SUSE Multi-Linux Manager.

  • Rotating API key.

  • Saptune configuration checks.

  • Simpler, more secure architecture without Grafana.

  • Revamped metric visualization.

  • Enhanced Checks Catalog view with dynamic filtering capabilities.

Version 2.2.0 (released on 2023/12/04)

Consisting of Helm chart 2.2.0, Web component 2.2.0, checks engine (wanda) 1.2.0 and agent 2.2.0.

  • saptune Web integration.

  • Instance clean-up capabilities.

  • Ability to run host-level configuration checks.

Version 2.1.0 (released on 2023/08/02)

Consisting of Helm chart 2.1.0, Web component 2.1.0, checks engine (wanda) 1.1.0 and agent 2.1.0.

  • ASCS/ERS cluster discovery, from single-sid, two-node scenarios to multi-sid, multi-node setups. The discovery covers both versions of the enqueue server, ENSA1 and ENSA2, and both scenarios with resource managed instance filesystems and simple mount setups.

  • Host clean-up capabilities, allowing users to get rid of hosts that are no longer part of their SAP environment.

  • New checks results view that leverages the potential of the new checks engine (wanda) and provides the user with insightful information about the check execution.

Version 2.0.0 (released on 2023/04/26)

Consisting of Helm chart 2.0.0, Web component 2.0.0, checks engine (wanda) 1.0.0 and agent 2.0.0.

  • A brand-new safer, faster, lighter SSH-less configuration checks engine (wanda) which not only opens the door to configuration checks for other HA scenarios (ASCS/ERS, HANA scale-up cost optimized, SAP HANA scale-out) and other targets in the environment (hosts, SAP HANA databases, SAP NetWeaver instances), but also will allow customization of existing checks and addition of custom checks.

  • Addition of VMware to the list of known platforms.

  • Versioned external APIs for both the Web and the checks engine (wanda) components. The full list of available APIs can be found at https://www.trento-project.io/web/swaggerui/ and https://www.trento-project.io/wanda/swaggerui/ respectively.

Version 1.2.0 (released on 2022/11/04)

Consisting of Helm chart 1.2.0, Web component 1.2.0, checks engine (runner) 1.1.0 and agent 1.1.0.

  • Configuration checks for HANA scale-up performance optimized two-node clusters on on-premise bare metal platforms, including KVM and Nutanix.

  • A dynamic dashboard that allows you to determine, at a glance, the overall health status of your SAP environment.

Version 1.1.0 (released on 2022/07/14)

Consisting of Helm chart 1.1.0, Web component 1.1.0, checks engine (runner) 1.0.1 and agent 1.1.0.

  • Fix for major bug in the checks engine that prevented the Web component to load properly.

Version 1.0.0 (general availability, released on 2022/04/29)

Consisting of Helm chart 1.0.0, Web component 1.0.0, checks engine (runner) 1.0.0 and agent 1.0.0.

  • Clean, simple Web console designed with SAP basis in mind. It reacts in real time to changes happening in the backend environment thanks to the event-driven technology behind it.

  • Automated discovery of SAP systems, SAP instances and SAP HANA scale-up two-node clusters

  • Configuration checks for SAP HANA scale-up performance optimized two-node clusters on Azure, AWS and GCP.

  • Basic integration with Grafana and Prometheus to provide graphic dashboards about CPU and memory utilization in each discovered host.

  • Basic alert emails for critical events happening in the monitored environment.

18. More information