Introduction

What is Observability?

In the ever-evolving landscape of distributed system operations, ensuring the reliability, performance, and scalability of complex applications has become increasingly more difficult. System Observability has emerged as a critical practice that empowers IT organizations to effectively monitor and gain deep insights into the inner workings of their software systems. By systematically collecting and analyzing data about applications, infrastructure, and user interactions, observability enables teams to proactively identify, diagnose, and resolve issues, ultimately leading to enhanced user experiences and operational efficiency.

What is OpenTelemetry?

OpenTelemetry is an open-source project that standardizes the collection of telemetry data from software systems, making it easier for organizations to gain holistic visibility into their environments. By seamlessly integrating with various programming languages, frameworks, and cloud platforms, OpenTelemetry simplifies the instrumentation of applications, allowing developers and operators to collect rich, actionable data about their systems' behavior.  The adoption of OpenTelemetry by software vendors and Application Performance Monitoring (APM) tools represents a significant shift in the observability landscape. OpenTelemetry has gained substantial traction across the industry due to its open-source, vendor-neutral approach and its ability to standardize telemetry data collection.

Many software vendors have started incorporating OpenTelemetry into their frameworks and libraries. Major cloud service providers like AWS, Azure, and Google Cloud have also embraced OpenTelemetry. In addition, many APM tools have integrated OpenTelemetry into their offerings. This integration allows users of these APM solutions to easily collect and visualize telemetry data from their applications instrumented with OpenTelemetry. It enhances the compatibility and flexibility of APM tools, making them more versatile in heterogeneous technology stacks.

Solution Architecture (Component Description)

Image Removed

Key Features (Controller, OMS, Agent, Extensions)

How to Get Started

Introduction

The following will provide a minimal setup to get started with Observability for Universal Automation Center.

The set-up is based on widely used Open Source tools.

The set-up is not intended for production use. To use the here provided set-up in a production environment, further configurations with regard to security have to be applied.

The set-up allows collecting Metrics and Trace data from Universal Automation Center. The collected Metrics data is stored in Prometheus for analysis in Grafana.

The collected Trace data is stored in Elasticsearch for analysis in Jaeger. The Jaeger UI is embed in the Universal Controller.

Jaeger, Prometheus and Grafana are selected for this Get Started Guide as examples. Any other data store or analysis tool could also be used.   

Metrics

Metrics data can be collected from Universal Controller, Universal Agent, OMS and Universal Tasks of type Extension.

Metrics data is pulled through the Prometheus metrics Web Service endpoint (Metrics API) and via user-defined Universal Event Open Telemetry metrics, which is exported to an Open Telemetry metrics collector (OTEL Collector).

The collected Metrics data exported to Prometheus for analysis in Grafana.

To enable Open Telemetry metrics, an Open Telemetry (OTEL) collector with a Prometheus exporter need to be configured.

Trace

Universal Controller will manually instrument Open Telemetry trace on Universal Controller (UC), OMS, Universal Agent (UA), and Universal Task Extension interactions associated with task instance executions, agent registration, and Universal Task of type Extension deployment.

The collected Trace data is stored in Elasticsearch for analysis in Jaeger. 

To enable tracing an Open Telemetry span exporter must be configured. 

Image Removed

Prerequisites

The sample set will done on a single on-premise Linux server. 

Server Requirements

• Linux Server 
  • Memory: 16GB RAM
  • Storage: 70GB Net storage 
  • CPU: 4 CPU
  • Distribution: Any major Linux distribution 
  • For the installation and configurations of the required Observability tools Administrative privileges are required
• Ports

The Following default ports will be used. 

...

Application

...

4317 (grpc), 4318 (http)

Pre-Installed Software Components

It is assumed that following components are installed and configured properly:

• Universal Agent 7.5.0.0 or higher
• Universal Controller 7.5.0.0 or higher

Please refer to the documentation for Installation and Applying Maintenance - Universal Controller 7.4.x - Stonebranch Documentation (atlassian.net)

and Universal Agent 7.4.x for UNIX Quick Start Guide - Universal Agent 7.4.x - Stonebranch Documentation (atlassian.net) for further information on how to install Universal Agent and Universal Controller.

Required Software for the Observability  

The following Opensource Software needs to be installed and configured for use with Universal Automation Center.

Note: This Startup Guide has been tested with the provide Software Version in the table below. 

...

otelcol-contrib

...

jaeger

...

prometheus

...

grafana-enterprise

...

Configuration

Open Source Setup

It is important to follow the installation in the here given order, because the Software components have dependencies between each other.

Example:

• Jaeger needs Elasticsearch to store the trace data.
• OTEL Collector needs Prometheus to store the metrics data.
• Grafana needs Prometheus as data source for displaying the dashboards

Set up Elasticsearch

Description:

Elasticsearch is a distributed, RESTful search and analytics engine designed for real-time search and data storage. It is used for log and event data analysis, full-text search, and more.

In this set-up Elasticsearch is used as the storage backend for Jaeger.

Installation Steps:

Follow the official documentation to install Elasticsearch on the Linux Server.

Install the Version listed in under Required Software for the Observability

Official Documentation: Elasticsearch Installation Guide

Configuration Files:

• elasticsearch.yml: Main configuration file for Elasticsearch, containing cluster, node, network, memory, and other settings.
• ~/elasticsearch/config/elasticsearch.yml
  ~/elasticsearch/config/jvm.options
  ~/elasticsearch/config/jvm.options.d/jvm_heap_size.options

Set JVM Memory Options:

create the file: ~/elasticsearch/config/jvm.options.d/jvm_heap_size.options

Note: Make sure you have enough memory ( ps -weaf |grep -i java ), otherwise Universal Controller does not work

~/elasticsearch/config/jvm.options.d/jvm_heap_size.options
cat jvm.options.d/jvm_heap_size.options
-Xms1g
-Xmx1g

Test the Installation:

ss -tuln | grep 9200

curl -XGET "http://127.0.0.1:9200"

Setup up Jaeger

Description:

Jaeger is an open-source distributed tracing system used for monitoring and troubleshooting microservices-based applications. 

In this set-up Universal Controller will manually instrument Open Telemetry trace on Universal Controller (UC), OMS, Universal Agent (UA), and Universal Task Extension interactions associated with task instance executions, agent registration, and Universal Task of type Extension deployment.

The collected Trace data is stored in Elasticsearch for analysis in Jaeger. 

Installation Steps:

Configuration Files:

• jaeger-agent-config.yaml: Configuration for the Jaeger agent, responsible for trace collection.
• jaeger-collector-config.yaml: Configuration for the Jaeger collector, handling trace reception and processing.
• jaeger-query-config.yaml: Configuration for the Jaeger query service, used for trace querying and visualization.

Official Documentation: Jaeger Installation Guide

Test the Installation:

http://ps1.stonebranchdev.cloud:16686/

Setup OTEL Collector

Description:

OpenTelemetry Collector is a vendor-agnostic observability data collector that gathers traces, metrics, and other telemetry data from various sources and sends it to different backends for analysis.

In this set-up OpenTelemetry collects Metrics data from Universal Controller, Universal Agent, OMS and Universal Tasks of type Extension.

Installation Steps:

Configuration Files:

• config.yaml: Primary configuration file for the OpenTelemetry Collector, defining data sources, exporters, processors, and components.

Official Documentation: OpenTelemetry Collector Installation

Test the Installation:

.

Set up Prometheus

Description:

Prometheus is an open-source monitoring and alerting toolkit designed for reliability and scalability. It collects metrics from monitored targets, stores them, and provides powerful querying and alerting capabilities.

In this set-up Prometheus is used to store the Metrics data retrieved via Opentelemetry and the Universal Controller Metrics REST API. 

Installation Steps:

Configuration Files:

• prometheus.yml: Main configuration file for Prometheus, defining scrape targets (what to monitor), alerting rules, and other settings.

Official Documentation: Prometheus Installation Guide

Test the Installation:

...

Introduction

What is Observability?

In the ever-evolving landscape of distributed system operations, ensuring the reliability, performance, and scalability of complex applications has become increasingly more difficult. System Observability has emerged as a critical practice that empowers IT organizations to effectively monitor and gain deep insights into the inner workings of their software systems. By systematically collecting and analyzing data about applications, infrastructure, and user interactions, observability enables teams to proactively identify, diagnose, and resolve issues, ultimately leading to enhanced user experiences and operational efficiency.

What is OpenTelemetry?

OpenTelemetry is an open-source project that standardizes the collection of telemetry data from software systems, making it easier for organizations to gain holistic visibility into their environments. By seamlessly integrating with various programming languages, frameworks, and cloud platforms, OpenTelemetry simplifies the instrumentation of applications, allowing developers and operators to collect rich, actionable data about their systems' behavior.  The adoption of OpenTelemetry by software vendors and Application Performance Monitoring (APM) tools represents a significant shift in the observability landscape. OpenTelemetry has gained substantial traction across the industry due to its open-source, vendor-neutral approach and its ability to standardize telemetry data collection.

Many software vendors have started incorporating OpenTelemetry into their frameworks and libraries. Major cloud service providers like AWS, Azure, and Google Cloud have also embraced OpenTelemetry. In addition, many APM tools have integrated OpenTelemetry into their offerings. This integration allows users of these APM solutions to easily collect and visualize telemetry data from their applications instrumented with OpenTelemetry. It enhances the compatibility and flexibility of APM tools, making them more versatile in heterogeneous technology stacks.

Solution Architecture (Component Description)

Image Added

Key Features (Controller, OMS, Agent, Extensions)

How to Get Started

Introduction

The following will provide a minimal setup to get started with Observability for Universal Automation Center.

The set-up is based on widely used Open Source tools.

The set-up is not intended for production use. To use the here provided set-up in a production environment, further configurations with regard to security have to be applied.

The set-up allows collecting Metrics and Trace data from Universal Automation Center. The collected Metrics data is stored in Prometheus for analysis in Grafana.

The collected Trace data is stored in Elasticsearch for analysis in Jaeger. The Jaeger UI is embed in the Universal Controller.

Jaeger, Prometheus and Grafana are selected for this Get Started Guide as examples. Any other data store or analysis tool could also be used.   

Metrics

Metrics data can be collected from Universal Controller, Universal Agent, OMS and Universal Tasks of type Extension.

Metrics data is pulled through the Prometheus metrics Web Service endpoint (Metrics API) and via user-defined Universal Event Open Telemetry metrics, which is exported to an Open Telemetry metrics collector (OTEL Collector).

The collected Metrics data exported to Prometheus for analysis in Grafana.

To enable Open Telemetry metrics, an Open Telemetry (OTEL) collector with a Prometheus exporter need to be configured.

Trace

Universal Controller will manually instrument Open Telemetry trace on Universal Controller (UC), OMS, Universal Agent (UA), and Universal Task Extension interactions associated with task instance executions, agent registration, and Universal Task of type Extension deployment.

The collected Trace data is stored in Elasticsearch for analysis in Jaeger. 

To enable tracing an Open Telemetry span exporter must be configured. 

Image Added

Prerequisites

The sample set will done on a single on-premise Linux server. 

Server Requirements

• Linux Server 
  • Memory: 16GB RAM
  • Storage: 70GB Net storage 
  • CPU: 4 CPU
  • Distribution: Any major Linux distribution 
  • For the installation and configurations of the required Observability tools Administrative privileges are required
• Ports

The Following default ports will be used. 

Pre-Installed Software Components

It is assumed that following components are installed and configured properly:

• Universal Agent 7.5.0.0 or higher
• Universal Controller 7.5.0.0 or higher

Please refer to the documentation for Installation and Applying Maintenance - Universal Controller 7.4.x - Stonebranch Documentation (atlassian.net)

and Universal Agent 7.4.x for UNIX Quick Start Guide - Universal Agent 7.4.x - Stonebranch Documentation (atlassian.net) for further information on how to install Universal Agent and Universal Controller.

Required Software for the Observability  

The following Opensource Software needs to be installed and configured for use with Universal Automation Center.

Note: This Startup Guide has been tested with the provide Software Version in the table below. 

Configuration

Open Source Setup

It is important to follow the installation in the here given order, because the Software components have dependencies between each other.

Example:

• Jaeger needs Elasticsearch to store the trace data.
• OTEL Collector needs Prometheus to store the metrics data.
• Grafana needs Prometheus as data source for displaying the dashboards

Set up Elasticsearch

Description:

Elasticsearch is a distributed, RESTful search and analytics engine designed for real-time search and data storage. It is used for log and event data analysis, full-text search, and more.

In this set-up Elasticsearch is used as the storage backend for Jaeger.

Installation Steps:

Follow the official documentation to install Elasticsearch on your Linux Server.

Official Documentation: Elasticsearch Installation Guide

Install the Version listed in chapter Required Software for the Observability.

Configuration File:

• elasticsearch.yml: Main configuration file for Elasticsearch, containing cluster, node, network, memory, and other settings.

No adjustments to the default elasticsearch.yml file are required. 

# ======================== Elasticsearch Configuration =========================
#
# NOTE: Elasticsearch comes with reasonable defaults for most settings.
#       Before you set out to tweak and tune the configuration, make sure you
#       understand what are you trying to accomplish and the consequences.
#
# The primary way of configuring a node is via this file. This template lists
# the most important settings you may want to configure for a production cluster.
#
# Please consult the documentation for further information on configuration options:
# https://www.elastic.co/guide/en/elasticsearch/reference/index.html
#
# ---------------------------------- Cluster -----------------------------------
#
# Use a descriptive name for your cluster:
#
#cluster.name: my-application
#
# ------------------------------------ Node ------------------------------------
#
# Use a descriptive name for the node:
#
#node.name: node-1
#
# Add custom attributes to the node:
#
#node.attr.rack: r1
#
# ----------------------------------- Paths ------------------------------------
#
# Path to directory where to store the data (separate multiple locations by comma):
#
#path.data: /path/to/data
#
# Path to log files:
#
#path.logs: /path/to/logs
#
# ----------------------------------- Memory -----------------------------------
#
# Lock the memory on startup:
#
#bootstrap.memory_lock: true
#
# Make sure that the heap size is set to about half the memory available
# on the system and that the owner of the process is allowed to use this
# limit.
#
# Elasticsearch performs poorly when the system is swapping the memory.
#
# ---------------------------------- Network -----------------------------------
#
# By default Elasticsearch is only accessible on localhost. Set a different
# address here to expose this node on the network:
#
#network.host: 192.168.0.1
#
# By default Elasticsearch listens for HTTP traffic on the first free port it
# finds starting at 9200. Set a specific HTTP port here:
#
#http.port: 9200
#
# For more information, consult the network module documentation.
#
# --------------------------------- Discovery ----------------------------------
#
# Pass an initial list of hosts to perform discovery when this node is started:
# The default list of hosts is ["127.0.0.1", "[::1]"]
#
#discovery.seed_hosts: ["host1", "host2"]
#
# Bootstrap the cluster using an initial set of master-eligible nodes:
#
#cluster.initial_master_nodes: ["node-1", "node-2"]
#
# For more information, consult the discovery and cluster formation module documentation.
#
# ---------------------------------- Various -----------------------------------
#
# Require explicit names when deleting indices:
#
#action.destructive_requires_name: true
#
# ---------------------------------- Security ----------------------------------
#
#                                 *** WARNING ***
#
# Elasticsearch security features are not enabled by default.
# These features are free, but require configuration changes to enable them.
# This means that users don’t have to provide credentials and can get full access
# to the cluster. Network connections are also not encrypted.
#
# To protect your data, we strongly encourage you to enable the Elasticsearch security features. 
# Refer to the following documentation for instructions.
#
# https://www.elastic.co/guide/en/elasticsearch/reference/7.16/configuring-stack-security.html

Test the Installation:

# Check default Port:
ss -tuln | grep 9200

# Result:
tcp    LISTEN  0       128      [::ffff:127.0.0.1]:9200                 *:*

# Check Eleasticserach is running
curl -XGET "http://127.0.0.1:9200"

# Result:
{
  "name" : "wiesloch",
  "cluster_name" : "elasticsearch",
  "cluster_uuid" : "tFSoPN8lT1yS4_hEv6nzzQ",
  "version" : {
    "number" : "7.17.12",
    "build_flavor" : "default",
    "build_type" : "tar",
    "build_hash" : "e3b0c3d3c5c130e1dc6d567d6baef1c73eeb2059",
    "build_date" : "2023-07-20T05:33:33.690180787Z",
    "build_snapshot" : false,
    "lucene_version" : "8.11.1",
    "minimum_wire_compatibility_version" : "6.8.0",
    "minimum_index_compatibility_version" : "6.0.0-beta1"
  },
  "tagline" : "You Know, for Search"
}

Setup up Jaeger

Description:

Jaeger is an open-source distributed tracing system used for monitoring and troubleshooting microservices-based applications. 

In this set-up Universal Controller will manually instrument Open Telemetry trace on Universal Controller (UC), OMS, Universal Agent (UA), and Universal Task Extension interactions associated with task instance executions, agent registration, and Universal Task of type Extension deployment.

The collected Trace data is stored in Elasticsearch for analysis in Jaeger. 

Installation Steps:

Follow the official documentation to install Jaeger on your Linux Server.

Official Documentation: Jaeger documentation (jaegertracing.io)

Install the Version listed in chapter Required Software for the Observability.

For a quick local installation the Jaeger all-in-one executable can be used. It includes the Jaeger UI, jaeger-collector, jaeger-query, and jaeger-agent, with an in memory storage component.

Configuration:

When starting the jaeger-all-in-one application the following command-line argument need to be set:

• --collector.otlp.grpc.host-port :14317: This is a command-line argument passed to the Jaeger all-in-one binary to configure the host and port for the gRPC OTLP ( OpenTelemetry Protocol) endpoint. It specifies that the gRPC OTLP endpoint should listen on port 14317.
• --collector.otlp.http.host-port :14318: This is another command-line argument that configures the host and port for the HTTP OTLP endpoint, specifying port 14318.

Example:

./jaeger-all-in-one --collector.otlp.grpc.host-port :14317 --collector.otlp.http.host-port :14318 ..

Test the Installation:

# Check default Port:
ss -tuln | grep 16686

# Result:
tcp    LISTEN  0       128                       *:16686                *:*

Test that the Jaeger GUI is accessibly: http://<hostname>:16686/search

Image Added

Setup OTEL Collector

Description:

OpenTelemetry Collector is a vendor-agnostic observability data collector that gathers traces, metrics, and other telemetry data from various sources and sends it to different backends for analysis.

In this set-up OpenTelemetry collects Metrics data from Universal Controller, Universal Agent, OMS and Universal Tasks of type Extension.

Installation Steps:

Follow the official documentation to install OpenTelemetry on your Linux Server.

Official Documentation: OpenTelemetry Collector Installation

Install the Version listed in chapter Required Software for the Observability.

Configuration Files:

• config.yaml: Primary configuration file for the OpenTelemetry Collector, defining data sources, exporters, processors, and components. For UAC the HTTP receiver for the OpenTelemetry Collector needs to be configured. The HTTP port (4318) should match the port configured in the 'omss.conf' and 'uags.conf' files.

No adjustments to the default config.yaml file is required, if in omss.conf and uags.conf the port is set to 4318. refer to Configuring OTLP Endpoint for theomss.conf and uags.conf port configuration.

# the http port 4318 (default) should be the same as in the omss.conf and uags.conf
      http:
        #tls:
        #cert_file: ue-cert.crt
        #key_file: ue-cert.key
        #endpoint: 0.0.0.0:4318

Test the Installation:

# the http port 4318 (default) should be the same as in the omss.conf and uags.conf
      http:
        #tls:
        #cert_file: ue-cert.crt
        #key_file: ue-cert.key
        #endpoint: 0.0.0.0:4318

.

Set up Prometheus

Description:

Prometheus is an open-source monitoring and alerting toolkit designed for reliability and scalability. It collects metrics from monitored targets, stores them, and provides powerful querying and alerting capabilities.

In this set-up Prometheus is used to store the Metrics data retrieved via Opentelemetry and the Universal Controller Metrics REST API. 

Installation Steps:

Follow the official documentation to install Prometheus on your Linux Server.

Official Documentation: Prometheus Installation Guide

Install the Version listed in chapter Required Software for the Observability.

Configuration Files:

• prometheus.yml: Main configuration file for Prometheus, defining scrape targets (what to monitor), alerting rules, and other settings. 

In the prometheus.yaml configuration file for UAC the following scrape jobs are defined what metrics to collect and from where. 

• OTelCollector' job, Prometheus collects metrics from the target 127.0.0.1:8881, which corresponds to the OpenTelemetry Collector's OTLP endpoint.
• prometheus job, with the the /metrics endpoint provides internal metrics related to the Prometheus server's performance and resource utilization.
• controller job, Prometheus collects data via the Universal Controller Webservice Metrics API. Replace 'ops.admin' and 'xxx' with the actual username and password required to access the metrics.
  

# my global config
global:
  scrape_interval: 15s # Set the scrape interval to every 15 seconds. Default is every 1 minute.
  evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute.
  # scrape_timeout is set to the global default (10s).

# Alertmanager configuration
alerting:
  alertmanagers:
    - static_configs:
        - targets:
          # - alertmanager:9093

# Load rules once and periodically evaluate them according to the global 'evaluation_interval'.
rule_files:
  # - "first_rules.yml"
  # - "second_rules.yml"

# A scrape configuration containing exactly one endpoint to scrape:
# Here it's Prometheus itself.
scrape_configs:
  # The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.

    # metrics_path defaults to '/metrics'
    # scheme defaults to 'http'.

  - job_name: 'OTelCollector'
    static_configs:
      - targets: ["127.0.0.1:8881"]
        #- job_name: "OTelCollector"
        #static_configs:
        #- targets: ["127.0.0.1:8888"]

  - job_name: 'prometheus'
    metrics_path: /metrics
    static_configs:
    - targets:
      - localhost:9090
      
  - job_name: 'controller'
    basic_auth:
       username: 'ops.admin'
       password: 'canton123'
    metrics_path: '/uc/resources/metrics'  # The correct path where the metrics are exposed by the web service. Note for cloud controller: '/resources/metrics'
    static_configs:
      - targets:
              - 'localhost:8080'  # Use the correct hostname or IP address and port of your web service.

Test the Installation:

# Check default Port:
ss -tuln | grep 9090

# Result:
tcp    LISTEN  0       128                       *:9090                 *:*

Test that the prometheus GUI is accessibly: http://<hostname>:9090

Image Added

Set up Grafana

Description:

Grafana is an open-source platform for monitoring and observability that allows you to create, explore, and share dynamic dashboards and visualizations for various data sources, including time series databases.

In the this set-up Grafana is used to Visualize and Analyze the Metrics data store in Prometheus data source (time series database). 

Installation Steps:

Follow the official documentation to install Grafana on your Linux Server.

Install the Version listed in chapter Required Software for the Observability.

Configuration Files:

• grafana.ini: Grafana's main configuration file, including database connections, server settings, and global configurations.
• datasources.yaml: Configuration for data sources (e.g., Prometheus) that Grafana connects to.
• dashboards: Grafana dashboards are often defined as JSON files that can be imported into Grafana.

...