Use cases for OpenTelemetry and extended observability that drive efficient issue resolution
Leveraging OpenTelemetry tools, IT teams can handle many complex tasks in place of an SRE. The intuitive user interface of OpenText Application Observability takes this even further, enabling them to:
Set up service-level objectives and service-level indicators (SLOs and SLIs) for an application. An SLO sets the bar for satisfactory application performance, and an SLI is one of several metrics that make up an SLO. An SLO forms the basis of a service-level agreement (SLA).
Set up synthetic monitoring for an application. By simulating user interactions with machine-generated transactions, synthetic monitoring enables administrators to test applications to ensure that they are running as they should, without any slowdowns.
Read and understand application metrics, events, logs, and traces. Starting with an application event or a trace, admins and operators can pinpoint where a slowdown is occurring. Following up, the administrator reviews metrics and logs, with the help of the automatic correlation that is native to OpenTelemetry-standard tools.
Participate in a blameless postmortem. This approach avoids the assignment of blame for slow performance or downtime, taking an objective approach to what happened. The metrics and measurements applied by IT admins help identify slowdowns quickly and recommend infrastructure changes to correct the issues identified.
The automatic correlation provided by OpenTelemetry-standard tools helps administrators gain insights from metrics and logs that point to where slowdowns are impeding data traffic. Result: Admins can deliver higher levels of reliability.
With the ability to handle a wide variety of tasks, central-IT staff can handle a broad range of use cases. For example:
Use case #1: An IT operations manager uses an observability tool to detect a problem with payment processing. Instead of sending a trouble ticket to an application developer or an SRE for further investigation, the operations manager opens a ticket against the third party that is processing the payment directly.
The result: Issue resolution is streamlined and conserves the time of the developer or SRE by removing the need to respond to a ticket.
Use case #2: An IT administrator receives an alert that an application is performing slowly. The administrator examines the relevant trace and correlated logs and discovers a long wait when the cloud application makes a call to the data center and to the on-premises identity management system. The administrator opens a ticket directly with the ISP that provides the connection and with the networking team.
The result: Performance is restored without involving a developer or SRE.
Use case #3: An IT admin sees that a new feature within an application is creating an excessive number of errors. With insight into the specific code impacted by the update, the IT admin assigns a ticket directly to the developer responsible for that code. The result: The developer corrects the issue promptly so that the application feature achieves its intended level of performance.
The OpenTelemetry Collector: How it works
The OpenTelemetry Collector plays a key role in enabling standards-based interoperability between tools. Because of its open design, the data collector enables multiple observability tools to draw from the same data sets.
In a typical scenario, an application consisting of microservices is instrumented either automatically or by a developer. When running, the microservices export telemetry data via online transaction processing (OLTP) to the OpenTelemetry Collector, which receives the data; processes it; and exports traces, logs, and metrics to a destination such as OpenText Application Observability. It is there that the user, who may now be a member of central-IT staff rather than a developer or an SRE, observes how the application is running and whether any slowdowns might be occurring.
The interoperability enabled by the OpenTelemetry Collector makes it possible for an organization to use multiple tools rather than consolidating on a single tool. For example, when a new tool is brought in, those users who have mastered a previous tool can continue to use it rather than undergo retraining on the new tool. Thus, the openness of the OpenTelemetry Collector conserves training budgets and maintains the productivity of the users who have invested time and labor in gaining expertise in a given set of tools.
