Getting Started with Trento

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 Trento Agent is a single background process (trento-agent) running on each monitored host of the SAP infrastructure.

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, you need to allocate at least 1.5GB 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:

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.

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) in order 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 in order 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.

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 initial discovery of a pacemaker cluster requires the DC node to be online. Once the cluster has been discovered, all nodes can be stopped and Trento will continue to discover the cluster.

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

Supported deployment methods:

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

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

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

Consider the following when performing an update:

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

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

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

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:

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

To update the Trento Agent, follow the procedure below:

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:

To uninstall a Trento Agent, perform the following steps:

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 node-exporter-target with value <ip_address>:<port> in the agent configuration file.

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

When using the Helm chart to deploy Trento Server on a Kubernetes cluster, an image of Prometheus Server is deployed automatically. No further actions are required by the user, other than ensuring that it can reach the node-exporter in the agent hosts.

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

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

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.

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

Supported installation methods:

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

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.

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:

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

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:

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.

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.

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.

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

The following protocols are supported:

Trento collects system events and user actions in the Activity Log. It can be accessed from the left-hand side panel of the Trento console.

Each entry in the Activity Log includes the following:

Clicking on the chevron icon in the activity log entry opens a modal window containing the activity metadata.

It is possible to search the activity metadata of the activity log entries. You can use wildcards as well as the OR and AND logical operators for advanced search queries. The OR operator is applied by default, meaning that a query like term1 term2 term3 is treated as term1 OR term2 OR term3. You can combine multiple logical operators, keeping in mind that they are parsed from left to right.

The Activity Log allows you to filter by the type of event or user action (commonly referred to as resource type), by the user that triggered the event or performed the action, and by severity status. Only active users are available for filtering. The Activity Log also allows you to filter out entries that are newer and/or older than an specific date and time (UTC timezone).

Once a filter has been set, click Apply to filter out the undesired entries and Reset to remove all the filters.

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

The Activity Log features a privacy-related access level controlled through the activity_log:users permission. For users without this permission, user-related info in the Activity Log is redacted. Unprivileged users can only see their own user names as well as user system.

Entries in the Activity Log are sorted from newer to older. Click Refresh to update the Activity Log view with entries generated since they accessed the view or after the last refresh. You can also enable the auto-refresh feature by selecting the desired auto-refresh interval.

The pagination features at the bottom of the Activity Log allow you to specify the number of entries to display in a page, go to the next or previous page of the view, and jump to the last page and back to first one.

The default retention time for entries in the Activity Log is one month. This can be changed in the Activity Log section under Settings. Changing the retention time requires the all:settings permissions. Entries older than the specified retention time are deleted every day at midnight (UTC timezone).

The correlation functionality of the Activity Log links related events together, offering a chronological, linear view of a chain of events in multi-step workflows triggered by a user action.

For example, the clean-up action in a host that runs a single instance HANA database of an SAP system de-registers the database instance, de-registers the database itself, de-reregisters the SAPsystem and its instances and then de-registers the host. These correlated entries are displayed in a linked, linear view, when you navigate to the host clean-up entry modal in the Activity Log and then click the link in the Related Events section named Show Events.

The following categories of Activity Log entries provide a view of linked or related events:

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.

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.

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.

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.

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.

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

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

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:

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.

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.

The dashboard allows you to determine at a glance the health status of your SAP environment. It is the main page of the Trento Web, and you can always switch to it by clicking on Dashboard in the left sidebar.

The health status of a registered SAP system is the sum of its health status at three different layers representing the SAP architecture:

In addition to the operating system layer, there is also information about the health status of the HA components, where they exist:

The dashboard groups systems in three different health boxes (see Dashboard with the global health state):

The health boxes in the dashboard are clickable. Clicking on a box filters the dashboard by systems with the corresponding health status. In large SAP environments, this feature can help the SAP administrator to determine which systems are in a given status.

The icons representing the health summary of a particular layer contain links to the views in the Trento console that can help determine the source of the issue:

Grey status is returned when either a component does not exist, or it is stopped (as returned by sapcontrol), or its status is unknown (for instance, if a command to determine the status fails).

Grey statuses are not yet counted in the calculation of the global health status.

The status allows you to see if any of the systems need to be examined further.

The following subsection gives you an overview of specific parts of your SAP Landscape to show their state. Each status site shows an overview of the health states.

To display the lists of registered hosts and their details, proceed as follows:

To display a list of all available Pacemaker clusters and their details, proceed as follows:

To display a list of all available SAP Systems and their details, proceed as follows:

To display a list of all available SAP HANA databases and their details, proceed as follows:

Users with the all:settings permissions can use the Settings view of Trento Web to modify the following:

For any registered host, the details view provides the following operations:

When a user requests a cluster operation, Trento checks the cluster state using cs_clusterstate -i. If the Trento Agent cannot find the cs_clusterstate executable or 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:

For any registered SAP HANA database that is not part of a HANA replication system, the details view provides the following operations at the top:

For any registered SAP HANA database that is part of a HANA replication system, the details view provides the following operations in the corresponding sections:

For any registered SAP system, the details view provides the following operations:

There are two tools you can use to collect information and data that can be useful when troubleshooting and analyzing issues with Trento Server.

A scenario dump is a dump of the Trento database. It helps the Trento team to recreate the scenario to test it.

A script is available in the Trento upstream project. The script helps generate a scenario dump when the server is running on a Kubernetes cluster. Using this script requires a host with the following setup:

To generate the dump, proceed as follows:

In case of a deployment on K3s, the descriptions and logs of the Trento Server pods can be useful for analysis and troubleshooting purposes (in addition to the output of the trento-support.sh script and the dump scenario script). These descriptions and logs can be obtained with the kubectl command. For this to work, you need a host with kubectl is installed and connected to the K3s cluster running Trento Server.