Getting Started with 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:

The Trento Server is an independent, distributed system designed to run on a Kubernetes cluster or as a regular systemd stack. The Trento Server provides a Web front-end for user interaction. 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.

See Architectural overview for additional details.

Trento is part of SUSE Linux Enterprise Server for SAP applications, and it is available since version 15 SP3. Trento’s two main components have the following product lifecycles:

This section describes requirements for the Trento Server and its Trento Agents.

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:

Prometheus Server is a Trento Server component responsible for pulling the Memory and CPU utilization metrics collected by the node-exporter in the agent hosts and serving them to the web component. The web component renders the metrics as dynamic graphical charts in the details view of the registered hosts.

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 Web.

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

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 left sidebar in the Trento Web contains the following entries:

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.

Trento can be inegrated 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:

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:

Click Relevant Patches to view a list of patches available for the host:

Click Upgradable Packages to view a list of packages that can be upgraded on that particular host:

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:

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.

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:

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:

To update the Trento Agent, follow the procedure below:

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:

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:

SUSE customers with registered SUSE Linux Enterprise Server for SAP applications 15 (SP4 or higher) or SUSE Linux Enterprise Server for SAP applications 16.0 distributions can report Trento issues either directly in the SUSE Customer Center or through the corresponding vendor, depending on their licensing model. Problems must be reported under SUSE Linux Enterprise Server for SAP applications 15 and component trento.

When opening a support case for Trento, provide the relevant deployment option for Trento Server: Kubernetes, or systemd RPM installation.

In case of a Kubernetes deployment, provide the output of the Trento support script as explained in section Problem Analysis.

In case of a systemd deployment, provide the output of the Trento support plugin, as explained in section Problem Analysis.

For issues with a particular Trento Agent, or a component discovered by a particular Trento Agent, also provide the following:

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.