Enterprises worldwide are accelerating their digital transformation initiatives, with many starting years earlier than originally planned. However, too often, these initiatives are hampered by the lack of deep technical expertise required to get projects off the ground and deliver digital products and solutions. WSO2 addresses this challenge with the introduction of Choreo, the new integration platform as a service (iPaaS) for cloud-native engineering.
Choreo aims to make a developer’s life easier by empowering users to rapidly develop, operate, and evolve cloud-native enterprise applications. As an AI-based tool, Choreo’s observability features help to effortlessly find and troubleshoot problems. Moreover, since Choreo runs in the cloud and is hosted by a service provider, users cannot log in to the machines their applications are running. Hence, the value of troubleshooting support cannot be understated.
Choreo’s observability architecture
Figure 1: High-level overview of observability architecture in Choreo
The above diagram shows the high-level architecture of Choreo’s observability. There are two main components: the data collection and observability views.
Choreo collects a rich set of information without the user having to add any instrumentation. It collects three types of data from your application.
- Application and container level logs. These are collected by agents from the containers and stored in a NoSQL database.
- CPU, memory, and other telemetrics from the pods and machines where the application is running. These are collected by agents from the K8s clusters and stored in a NoSQL database .
- Detailed, statement-level trace and metric data collected from the application. Each Choreo application runs as a Ballerina program, and we have built efficient deep tracing and telemetry collection into Ballerina that can provide activity and performance data at the statement level. We push the data through an open telemetry compatible GRPC-based protocol, and save them to a NoSQL database through a message queue.
While troubleshooting, we believe the best experiences are provided by rich, nuanced, and detailed profiler views, such as via flame graphs, rather than allowing the user to create their visualizations, which are often poor at providing a great troubleshooting experience. More details about the views can be found here.
Figure 2: Observability view in Choreo
The observability view presents the low-code diagram of a Choreo application on the left, this also includes annotations about the success rates of different paths and the time taken by different statements in the system. The righthand panel shows throughput, latency data, and logs.
As we noted in the architecture section, the observability implementation queries the cloud databases for application execution traces and uses the information to recreate full details about the execution.
Figure 3: Root cause analysis view
The root cause analysis view presents logs, latency, and other telemetry data aligned by timelines, which lets us see all events in context to each other and detect patterns. The implementation queries the cloud database, based on time range and aligns data accordingly.
Figure 4: A flame graph in diagnostic view
The flame graph builds a stack trace using the application execution traces and is helpful in finding bottlenecks in the application. The implementation loads data from the cloud database and renders the flame graph.
The deep observability capabilities in Choreo enable enterprises to view observability data at both design-time and run-time in order to troubleshoot issues. Additionally, AI-based anomaly alerts call attention to developers when required and help isolate the problem. In this article, we discussed the key observability features and dug into their architecture and innerworkings.
Click here to find out more on how Choreo gives organizations a single, all-inclusive platform for creating integrations, services and APIs; managing APIs; and deploying services and APIs—going from ideas to production in hours.