Application Performance Monitoring System Design Using Opentelemetry and Grafana Stack

Abstract

The increasingly massive use of digital technology requires that the application architecture be designed to have high availability and reliability. This is because when an application cannot be accessed, it will cause no small loss to the organization. Therefore, the development and operation teams must be able to detect when their system is not working well. For that, we need a system that can monitor application performance. In this research, a system is developed to collect telemetry data, namely metrics and traces from an online donation backend application based on the REST API. OpenTelemetry produces telemetry as an open-source telemetry instrumentation tool. Then the telemetry data is collected by the OpenTelemetry Collector which is then stored on the backend of each telemetry. Metrics are sent to Prometheus and traces are sent to Jaeger. The data metrics collected are throughput, request latency, and error rate which are visualized using the Grafana dashboard. The test results show that the monitoring system can collect real-time metrics data with an average delay of 13,8 seconds. The system can also detect when an anomaly occurs in the app and sends notifications via Slack. In addition, the trace data collected can be used to simplify the debugging process when an error occurs in the application. However, the implementation of OpenTelemetry in a REST API-based backend application to monitor metrics and traces has a negative impact on the performance of the application itself, which can reduce the number of request throughput with an average decrease of 23.32% and increase request latency with an average increase of 22.80%.

Telemetry of Legacy Web Applications: An Industrial Case Study

“…Our findings highlight different levels of similarities and differences between the instrumented applications. Regarding the studied platforms, we mainly identify web [14]- [16], [21], [44]- [47], desktop [14], [48], and IoT [21], [44], [48], [49] applications. These applications are developed based on different architectural styles such as Monolithic [48], N-Tiers [14], Follower-Leader [50] and Microservices [16], [21], [45], [46], [51].…”

“…These applications are developed based on different architectural styles such as Monolithic [48], N-Tiers [14], Follower-Leader [50] and Microservices [16], [21], [45], [46], [51]. In terms of their implementation, they adopt different technologies, such as Vaadin [14], Spigo [16], AngularJS [46], and Vue [52] for the frontend and Spring Cloud [49], Spring Boot [46], [53] and Node.js [46], [47] for the backend. Moreover, they can be community-based [46], industrial [16], [21], [47], [51], benchmark-oriented [44], [45], [48] or used for demonstration purposes [14].…”

“…In terms of their implementation, they adopt different technologies, such as Vaadin [14], Spigo [16], AngularJS [46], and Vue [52] for the frontend and Spring Cloud [49], Spring Boot [46], [53] and Node.js [46], [47] for the backend. Moreover, they can be community-based [46], industrial [16], [21], [47], [51], benchmark-oriented [44], [45], [48] or used for demonstration purposes [14]. However, none of these approaches tackle industrial GWT-Spring applications.…”

“…Furthermore, the telemetry approaches used to instrument these applications collect various telemetry data types, including traces [16], [45], [47], metrics [14], [44], [46], [54] and logs [46], [55]. Some approaches collect traces [16], [21], [45], metrics [44], or logs [55] exclusively, while others collect multiple telemetry data types [46], [51], [54].…”

“…Some of these approaches resort to AspectJ [14] or Spring Boot Sleuth [53] for the instrumentation of their target applications. To collect the generated telemetry data and transmit it to the telemetry backend, the examined approaches rely on telemetry data collectors provided by OpenTelemetry [21], [47], [56], Jaeger [16], [47] or Fluentd [14]. To store, index, analyze, and visualize their collected telemetry data, many approaches relied on one or multiple telemetry backends, including the Elastic Stack [14], [51], [54], [55], Jaeger [16], [45]- [47], Zipkin [48], [53], and Prometheus [47], [48], [54].…”