Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
documentation.suse.com / Getting started with Trento Premium

Getting started with Trento Premium

SUSE® Linux Enterprise Server for SAP Applications

Trento Premium is an open cloud-native web console that aims to help SAP Basis consultants and administrators to monitor the entire OS stack of their SAP environments, including HA features.

Publication Date: 07/01/2022

Copyright © 2010–2022 SUSE LLC and contributors. All rights reserved.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or (at your option) version 1.3; with the Invariant Section being this copyright notice and license. A copy of the license version 1.2 is included in the section entitled “GNU Free Documentation License”.

For SUSE trademarks, see http://www.suse.com/company/legal/. All third-party trademarks are the property of their respective owners. Trademark symbols (®, ™ etc.) denote trademarks of SUSE and its affiliates. Asterisks (*) denote third-party trademarks.

All information found in this book has been compiled with utmost attention to detail. However, this does not guarantee complete accuracy. Neither SUSE LLC, its affiliates, the authors nor the translators shall be held liable for possible errors or the consequences thereof.

Important
Important: Trento is an evolving product

The product continues to be under active development, but is available for any SUSE customer with a registered SUSE Linux Enterprise Server for SAP Applications 15 (SP1 or higher). Contact https://www.suse.com/support for further assistence.

1 What is Trento Premium?

Trento Premium is the extended version of the Trento community project containing additional checks. Apart from their naming, both are comprehensive monitoring solutions consisting of two main components, the Trento Server and the Trento Agent. Both Trento variants provide the following features:

  • A simplified, reactive web UI targeting SAP admins.

  • Automated discovery of SAP Systems, SAP Instances, and SAP HANA clusters.

  • Configuration validation for SAP HANA Scale-Up Performance-Optimized scenarios deployed on MS Azure cloud, AWS or GCP.

  • Monitoring of CPU and Memory usage at host level through basic integration with Grafana and Prometheus.

  • Email alerting for critical events in the monitored landscape.

The Trento Server is an independent, cloud-native, distributed system and designed to run on a Kubernetes cluster. The Trento Server interacts with users via a web front end.

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

For Trento Premium, SUSE collects telemetry data relevant for further product development.

See Figure 1, “Architectural overview” for additional details.

Architectural overview
Figure 1: Architectural overview

2 Product lifecycle and update strategy

The main components have different product lifecycles:

Trento Agent

Delivery mechanism: RPM package for SUSE Linux Enterprise Server for SAP Applications 15 SP1 and newer.

Supported runtime:  Supports SUSE Linux Enterprise Server for SAP Applications 15 SP1 and newer.

Trento Server

Delivery mechanism:  A set of container images from the SUSE registry together with a Helm chart for easy installation.

Kubernetes:  The Trento Server runs on any current Cloud Native Computing Foundation (CNCF) certified Kubernetes distributions. Depending on your background and needs, SUSE support several usage scenarios:

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

  • If you have no Kubernetes and want enterprise support, SUSE recommends SUSE Rancher with Rancher Kubernetes Engine (RKE) either version 1 or 2.

  • If you do not have Kubernetes enterprise solution and you would like to test Trento, an easy option could be SUSE's K3s project which provides a single node Kubernetes cluster. Note, this is not a recommended solution for a stable Trento production, but a viable way to get started.

3 Requirements

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

3.1 Trento Server requirements

Running all the Trento Server components requires a minimum of 2GB of RAM, two CPU cores and 64GB of storage.

While the Trento Server supports various usage scenarios, depending on the existing infrastructure, it's designed to be cloud-native and OS agnostic. As such, the default installation method provisions a minimal, single node, K3S Kubernetes cluster for running its components in Linux containers. The Trento Server can be installed on the following services:

  • RKE1 (Rancher Kubernetes Engine version 1)

  • RKE2

  • any other CNCF certified Kubernetes

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.

3.3 Network requirements

  • The Trento component running Kubernetes has network access to the SAP landscape.

  • Trento Server must be reachable via HTTP (port TCP/80) or via HTTPS (port TCP/443) if SSL is enabled, from any Trento Agent host.

  • Trento Server must be able to reach the Trento Agents hosts via SSH (port TCP/22).

  • The SAP administrator also needs access to Trento Server via HTTP (port TCP/80) or via HTTPS (port TCP/443) if SSL is enabled.

3.4 Installation pre-requisites

  • Trento Server. Access to SUSE registry for the deployment of Trento Server premium containers.

  • Trento Agents. A registered SUSE Linux Enterprise Server for SAP Applications distribution.

  • A Trento service user.  Able to sudo to root without password in the Trento Agent hosts. In this example, we will refer to it as trentoservice. You can use any desired user name, but we recommend you use it consistently across the landscape.

4 Installing Trento Server

Important
Important: Expect changes in the installation procedure

The product is under active development. Expect changes in the described installation procedure.

The procedure uses the following placeholders:

  • TRENTO_SERVER_HOSTNAME: the host name of the Trento Server host.

  • PRIVATE_SSH_KEY: the absolute path to the private SSH key that Trento Server will use to connect to the Trento Agent hosts.

  • ADMIN_PASSWORD: the password that the SAP administrator will use to access the web console.

Trento Server premium is delivered as a Helm chart in order to facilitate its installation process. If you already have a Kubernetes cluster in place and want to use it to run Trento Server, all you have to do is to install Helm (Step 3) and then run command in Step 5 to deploy the Helm chart in your Kubernetes cluster. If you don't have a Kubernetes cluster or have one but don't want to use it for Trento, you can deploy a small VM (see section Section 3.1, “Trento Server requirements” for minimum requirements) and follow steps in Procedure 1, “Manually installing Trento on a Trento Server host” to get Trento Server up and running.

If you choose to deploy the VM with a registered SLES for SAP 15 distro, instead of executing Step 2 thru Step 5, you can install package trento-server-installer and then execute script install-trento-server: it will run those steps for you automatically.

Procedure 1: Manually installing Trento on a Trento Server host

  1. Log on the Trento Server host.

  2. Install Kubernetes, for example, K3s for a single server install:

    • Installing as user root

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

    • Installing as 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. Export 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 the Trento Server container using Helm: 

    HELM_EXPERIMENTAL_OCI=1 helm upgrade \
   --install trento-server oci://registry.suse.com/trento/trento-server \
   --set trento-web.adminUser.password=ADMIN_PASSWORD \
   --set-file trento-runner.privateKey=PRIVATE_SSH_KEY

    Note that the experimental flag is not needed as of Helm version 3.8.0.

  6. Log out the Trento Server host.

  7. To verify that the Trento Server installation was successful, open the URL of the Trento web console (http://TRENTO_SERVER_HOSTNAME) from a workstation located in the SAP administrator's LAN.

4.1 Enabling email alerts

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

Some of the notified events are:

  • 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 alerting emails.

SMTP_PORT

The port on the SMTP server.

SMTP_USER

Username to access SMTP server.

SMTP_PASSWORD

Password to access SMTP server.

ALERTING_RECIPIENT

Recipient email for alerting notifications.

The command to enable email alerting is the following: 

HELM_EXPERIMENTAL_OCI=1 helm upgrade \
   --install trento-server oci://registry.suse.com/trento/trento-server \
   --set trento-web.adminUser.password=ADMIN_PASSWORD \
   --set-file trento-runner.privateKey=PRIVATE_SSH_KEY \
   --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.recipient=ALERTING_RECIPIENT

4.2 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 please 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.

5 Installing Trento Agents

Important
Important: Expect changes in the installation procedure

The product is under active development. Expect changes in the described installation procedure.

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

  1. Open the URL of the Trento web console (http://TRENTO_SERVER_HOSTNAME). It prompts you for a username and password:

  2. Enter the credentials for the admin user (established when installing Trento Server).

  3. Click Login. As this is the first time you access the console, you will be prompted to accept the license agreement. Click Accept to continue. Otherwise, you cannot use Trento.

  4. Once inside the console, go to Settings:

  5. Click the Get your key now! button.

  6. Write down the API key.

To install the Trento Agent, repeat the steps in Procedure 2, “Installing Trento Agents” on each host to be monitored in your SAP environment.

The procedure uses the following placeholders:

  • TRENTO_SERVER_IP: local IP address of the Trento Server host.

  • TRENTO_AGENT_IP: local IP address of the Trento Agent host.

  • TRENTO_AGENT: host name of the Trento Agent host.

To install the Trento Agent software on the host and register it with the Trento Server, proceed as follows:

Procedure 2: Installing Trento Agents

  1. On the Trento Agent host, add the public SSH key used for the installation of Trento Server to the ~/.ssh/authorized_keys file of the user trentoservice. This step is necessary to enable the runner checks in the Trento Agent host via SSH.

  2. Add the Trento Agent host to the list of known hosts on your Trento Server by logging in once via SSH as trentoservice:

    1. Log in on the Trento Server host.

    2. Connect to the Trento Agent host as trentoservice using SSH and answer yes when asked whether to continue or not with the connection process: 

      > ssh trentoservice@TRENTO_AGENT_IP
[...]
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'TRENTO_AGENT_IP' (ECDSA) to the list of known hosts.

    3. Log out to go back to the Trento Agent host.

  3. Install the package: 

    > sudo zypper ref
> sudo zypper install trento-agent

  4. Open the configuration file /etc/trento/agent.yml uncomment (use #) the entries for ssh-address, server-url, and api-key and update the values appropriately:

    • ssh-address: local IP address

    • server-url: URL for the Trento Server (http://TRENTO_SERVER_HOSTNAME). If SSL termination has been enabled, you can encrypt the communication from the agent to the server by providing an HTTPS URL instead of an HTTP one. Refer to Section 4.2, “Enabling SSL”.

    • api-key: the API key retreived from the Web console.

  5. Start the Trento Agent: 

    > sudo systemctl enable --now 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. Repeat this procedure in all Trento Agent hosts.

6 Using Trento web console

When you access the Trento web console for the first time, it asks to accept the license. Click Accept to continue.

After you have accepted the license, Trento can be used. The left sidebar in the Trento web console contains the following entries:

  • Dashboard.  Determine at a glance the health status of your SAP environment.

  • Hosts. Overview of all registered hosts running the Trento Agent.

  • Clusters. Overview of all discovered Pacemaker clusters.

  • SAP Systems. Overview of all discovered SAP Systems; identified by the corresponding system IDs.

  • HANA Databases.  Overview of all discovered SAP HANA databases; identified by the corresponding system IDs.

  • Checks catalog.  Overview of all catalog of configuration checks that Trento may carry out for the different cluster components (Pacemaker, Corosync, SBD, etc.) in any of the supported platforms: Azure, AWS or GCP.

  • Settings.  It lets you retrieve the API key for this particular installation.

  • About.  Shows the Trento flavor, the current server version, a link to the GitHub repository of the Trento web component, and the number of registered SUSE Linux Enterprise Server for SAP Applications subscriptions.

The following subsections provides an overview of Trento's functionality.

6.1 Dashboard

The dashboard allows you to determine at a glance the Health Status of your SAP environment.

Dashboard
Figure 2: Dashboard

The Global Health section on top shows a summary of the Health Status of the registered SAP systems.

The Health Status of a registered SAP system is the compound of its Health Status at four diferent layers, which are a reflection of the SAP architecture:

  • Hosts: it collects the running status of the Trento Agent and the Node Exporter.

  • Pacemaker Clusters: the status here is based on the running status of the cluster and the results of the configuration checks.

  • Database: it collects the status of the HANA instances as returned by sapcontrol.

  • SAP instances: it summarizes the status of the ABAP instances as returned by sapcontrol.

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

  • For a system Global Health status to be Passing, all components must be in passing (green) status.

  • A system with at least one component in warning (yellow) status, but no components in critical (red) status, will be computed as Warning in the Global Health section.

  • A system with at least one component in critical (red) status, will be computed as Critical in the Global Health section.

Grey statuses are not counted in the calculation of the Global Health status.

6.2 Hosts view

To display the lists of registered hosts, click the Hosts entry in the left sidebar.

Hosts entry
Figure 3: Hosts entry

This view provides the following information:

  • A Health section on top with a summary of the health status of the registered hosts.

  • A list of registered host with the following info for each one of them: Health status (Passing, Warning or Critical), host name and local IP address(es). When applicable, it shows the cloud provider, the cluster name, and the system ID. Otherwise all fields are empty. The row ends with the Trento Agent's version and custom tags that you can add and remove manually.

  • Ability to filter the list by health status, host name, SAP System ID, or custom tags.

Clicking on a host name opens the corresponding Host details view, where you can see the following:

Host details view

  • Hosts details section: it shows the status of both the Trento Agent and the Node Exporter and provides the host name, the cluster name (when applicable) and the Trento Agent version.

  • Monitoring dashboard: it shows the CPU and Memory usage for the specific hosts.

  • Cloud details section: when applicable, it provides the name of the virtual machine, the name of the resource group it belongs to, the location, the size of the virtual machine, and other information.

  • SUSE subscription details section: it lists the different components or modules that are part of the subscription and for each one of them it provides the architecture, the version and type, the registration and subscription status as well as the start and end dates of the subscription.

  • SAP instances section: lists the ID, SID, type, features, and instance number of any SAP instance running on the host (SAP NetWeaver or SAP HANA).

6.3 Clusters

To display a list of the discovered Pacemaker clusters, click the Pacemaker Clusters entry on the left sidebar.

Important
Important

Keep in mind that only SAP HANA scale-up clusters on Azure, AWS, or GCP are currently under consideration.

Pacemaker clusters
Figure 4: Pacemaker clusters

This view provides the following:

  • A Health section on top with a summary of the health of the clusters based on the runtime status and the selected configuration checks for each one of them. See Pacemaker Cluster details view for more information.

  • A Filters section to filter clusters by health status, cluster name, SID, type, or tags.

  • A list of registered clusters with the following information for each one of them: status (based on runtime status and configuration checks), cluster name, cluster ID, cluster type, SID (when applicable), number of hosts, number of resources, and custom tags that can added/removed manually.

Clicking on the name of a SAP HANA scale-up cluster, opens the corresponding Cluster details page in which we can find the following:

Pacemaker Cluster details view

  • A Settings button next to the Pacemaker Cluster details title which will open the Cluster settings window: Figure 5, “Cluster settings”.

    Cluster settings
    Figure 5: Cluster settings

    In this window you have two tabs:

    Cluster settings

    • Connection settings tab: set the user that the Trento Server will use to connect via SSH to the cluster nodes to perform the HA configuration checks. In this article, it is trentoservice.

      • The default connection user in Azure environments is the Azure admin user used to deploy the VMs.

      • The default connection user in AWS and GCP is root.

      If you change the default connection user, you need to click on Apply Connection Settings to save the changes.

    • Checks selection tab: select/deselect a complete category of checks (such as Corosync or Pacemaker etc.) or individual checks. Whenever you make a new selection of checks you need to click Select Checks for Execution to save the change.

    Whenever a change is made and saved in either tab, if any check is selected a button will show up allowing the user to start the check execution right away.

  • Next to the Settings button there are two other buttons:

    • A Show Results button, shows the results of the last execution, if any.

    • A Start Execution button, enabled only when checks are selected and the connection settings are appropriate. By clicking this button, the user manually triggers the execution of the selected checks. In addition to manually triggered executions, Trento execute the selected checks every 5 minutes.

  • On the top of the details view, a section with the most relevant cluster attributes including SAP HANA system replication mode, SAP HANA system replication operation mode, SAPHanaSR health state and SAP HANA secondary sync state.

  • When there are stopped resources in the cluster, a Stopped resources section listing which resources are in that status.

  • A Pacemaker Site details section showing the different sites that are configured for this cluster. For each site, its name is displayed along with the host name, the role, the local IP(s), and the virtual IP. Clicking on the Details button on the right opens a Site details window where you can, on top, view the main attributes of the node. At the bottom you can see the list of resources running on it.

  • A SBD/Fencing section listing the configured SBD devices and their location, in the case of Azure environments.

6.4 SAP Systems view

Click the SAP Systems entry in the left sidebar to get an overview of the registered SAP Systems:

SAP Systems
Figure 6: SAP Systems

This view provides the following:

  • A Health section on top with a summary of the SAP systems statuses based on their runtime status (according to sapcontrol).

  • A list of registered SAP Systems with the following information for each one of them: health status, system ID (SID), database ID, tenant database, database IP address, and custom tags that you can manually set/remove. By clicking on the row of one particular system, a section opens up listing its SAP NetWeaver instances on top and the database instances underneath, with relevant information for each one of them:

  • Ability to filters SAP Systems by heath status, SID, and tags.

Clicking on a SID entry, opens up the SAP Systems details view which displays the following:

SAP System details

  • the Name and Type of this SAP System.

  • The NetWeaver; instances layout: for each instance, virtual host name, instance number, features (processes), HTTP and HTTPS ports, start priority, and SAPControl status.

  • The list of hosts where the different NetWeaver instances are running, with the host name, the IP address, the cloud provider (when applicable), the cluster name (when applicable), and the Trento Agent version for each listed host. When you click the host name, it takes you to the corresponding Host details view.

SAP System Details
Figure 7: SAP System Details

6.5 SAP HANA databases view

To get an overview of registered SAP HANA databases, click the HANA databases entry in the left sidebar.

HANA databases
Figure 8: HANA databases

This view provides the following:

  • A Health section on top with a summary of the status of the SAP HANA databases based on their runtime status (according to sapcontrol).

  • A list of registered SAP HANA databases with the following information for each one of them: health status, system ID (SID), a summary of the database instances and their status and custom tags that you can manuall set/remove. By clicking on the row of one particular database, a list of all related instances is displayed and for each one of them you can see the corresponding health status, its instance number, the feature (role) it provides, the system replication role and status (when applicable), the cluster name (when applicable) and the host where it is running.

  • Ability to filters SAP HANA databases by health status, SID, and custom tags.

Clicking on one of the SIDs opens the HANA Databases detail view which shows the following:

HANA Database details view

  • Layout section: lists all related SAP HANA instances with their corresponding virtual hostname, instance number, features (roles), HTTP/HTTPS ports, start priorities, and SAPControl status.

  • Hosts section: lists the hosts where all the related instances are running and for each host it provides the host name, the local IP address(es), the cloud provider (when applicable), the cluster name (when applicable), the system ID, and the Trento Agent version.

    Clicking on a host name takes you to the corresponding Host details view.

HANA Database details
Figure 9: HANA Database details

6.6 HA configuration checks

To get an overview of the configuration checks that Trento can manage click the Checks catalog entry in the left sidebar.

Checks catalog
Figure 10: Checks catalog

The view allows you to select the platform which values you want to review: Azure, AWS, or GCP. For each platform, it shows the configuration checks that Trento can perform for the different cluster components: Corosync, Pacemaker, SBD, Azure Fence Agent, SAP HANA System Replication Resource Agent, OS and package version, and miscellaneous.

Checks are grouped by components. Each test is identified by a test ID, next to which we can see the check description and an info icon. By clicking on the info icon we get detail information about the corresponding check: abstract, remediation actions (what to do when the check is negative) and related references.

What checks are carried out for each particular cluster is determined using the Settings button in the corresponding cluster detail view. See Cluster settings for details.

7 Updating Trento Server

To update the Trento Server, do the following:

  1. Ensure the Trento Server is running.

  2. Ensure that credentials for Kubernetes are set up correctly. For example, if you installed K3s, export the KUBECONFIG environment variable for the same user that performed the installation: 

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

  3. With the same user, start the update of the Trento Server. It is exactly the same command as for the installation: 

    HELM_EXPERIMENTAL_OCI=1 helm upgrade \
   --install trento-server oci://registry.suse.com/trento/trento-server \
   --set trento-web.adminUser.password=ADMIN_PASSWORD \
   --set-file trento-runner.privateKey=PRIVATE_SSH_KEY

    Note that the experimental flag is not needed as of Helm version 3.8.0.

    If email alerting is enabled in the environment, then the update command should include the corresponding options: 

    HELM_EXPERIMENTAL_OCI=1 helm upgrade \
   --install trento-server oci://registry.suse.com/trento/trento-server \
   --set trento-web.adminUser.password=ADMIN_PASSWORD \
   --set-file trento-runner.privateKey=PRIVATE_SSH_KEY \
   --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.recipient=ALERTING_RECIPIENT

  4. Check the Trento Server processes:

    kubectl get pod

  5. Open the Trento web console URL http://TRENTO_SERVER_HOSTNAME.

  6. To check the new version, hover the mouse pointer over the info button in the lower-left corner.

8 Updating a Trento Agent

To update the Trento Agent, do the following:

  1. Log in the Trento Agent host.

  2. Stop the Trento Agent:

    > sudo systemctl stop trento-agent

  3. Install the package: 

    > sudo zypper ref
> sudo zypper install trento-premium

  4. Ensure that entries ssh-address, server-url, and api-key are maintained properly in the Trento Agent configuration file /etc/trento/agent.yaml:

    • ssh-address: local IP address

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

    • api-key: the API key retreived from the Web console.

  5. Restart the Trento Agent: 

    > sudo systemctl restart 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 on the Trento web console (URL http://TRENTO_SERVER_HOSTNAME).

  8. Repeat this procedure in all Trento Agent hosts.

9 Uninstalling Trento Server

To uninstall Trento Server, proceed as follows:

  1. Ensure that credentials for Kubernetes are set up correctly. For example, if you installed K3s, set the KUBECONFIG environment variable for the user that performed the installation: 

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

  2. With the same user, run the following command: 

    helm uninstall trento-server

10 Uninstalling a Trento Agent

To uninstall a Trento Agent, perform the following steps:

  1. Log in the Trento Agent host.

  2. Stop the Trento Agent:

    > sudo systemctl stop trento-agent

  3. Remove the package: 

    > sudo zypper remove trento-agent

11 More information