OpenAPM

Application performance management (APM) is an essential part of today’s IT landscape. Doing consulting work at our enterprise customers, we most often encounter commercial APM suites. While the market of holistic, out-of-the-box APM solutions is certainly dominated by commercial vendors, the open-source community provides a variety of technologies, each of them excelling at an individual aspect of APM. In addition to these technologies, the community has also brought to life APM-related standards and frameworks, such as OpenTracing or OpenCensus.

Combining the aspects and strengths of available open-source APM technologies to create a custom APM solution can be a worthwhile effort, depending on your specific APM use case. Such a system may very well match commercial solutions in individual aspects. For example, Grafana provides excellent dashboarding features that greatly exceed everything commercial solutions can offer. If such key aspects are important for your use case, a custom APM solution may be the perfect fit for you.

However, combining and tailoring requires deep knowledge about the functionality and interoperability of open source tools in order to fit to your specific contexts and use cases. As many different combination and integration possibilities of open source tools exist, it is a challenging task to compose suitable solutions. This results in a high effort for web research and the need to implement and test different prototypes in a try and error manner. Therefore, we created the OpenAPM initiative.

OpenAPM fosters the creation of open and tailored APM solutions. OpenAPM consolidates and provides knowledge about the interoperability of relevant open source tools. Moreover, we strive to identify and close interoperability gaps by gathering and providing required extensions and tool integrations. The publicly available interactive landscape (at https://openapm.io) enables you to configure OpenAPM solutions by visualizing possibilities of interoperability between relevant open source tools.

To assess the viability of a custom APM solution based on OpenAPM, we first have to look at the different aspects of APM and decide which of them matter to a present APM use case. In the following, we describe the most important aspects we need to address when creating custom APM solutions.

Aspects of APM

The idea of a holistic APM solution incorporates a set of technical features and requirements. On a high level, APM can be thought of as a data pipeline structured in the aspects data collection, transformation, storage and value creation (usage) out of application performance measurements. We structured OpenAPM into these different aspects as well.

Data Collection

APM uses instrumentation to collect measurements. Instrumentation adjusts code to measure run times, correlate method calls and extract context data. This is done either using agents or instrumentation frameworks and libraries.

Agents are added to the application at startup time and run as part of the application code in order to collect the desired data. In dynamic languages (e.g. Java, .NET), agents can even adjust the instrumentation at runtime.
Instrumentation frameworks and libraries are a more recent phenomenon. They are direct dependencies to the application and taking measurements is part of the application’s actual source code. This way, instrumentation as to be applied at compilation time.

The extracted measurement data is then send to collectors, which often serve as a hub for a particular set of agents. After possibly batching the data, collectors pass the data on to the subsequent APM components.

Transformation and Storage

Before actually analyzing the data, we might want to transform our measurements. Transformation tools receive data in one format, possibly enrich data, and then convert it into a different representation. Example are aggregation of raw data or feature creation. Components that do data transformation typically receive ingress traffic from multiple sources and may send data to multiple destination systems as well.

To monitor performance and analyze it over time, we then need to persist the performance data to disk or memory. In APM, we typically find different kinds of long-term storage systems.

Time series databases lend themselves well to store high amounts of metric data, aggregated response time measures for example. We can analyze and transform this time series data, for example to compute baselines or to detect anomalies.
Certain NoSQL technologies are suitable to store large quantities of unstructured performance data, such as traces or user session data. This kind of data is valuable for detailed problem analysis as well as for the analysis of user behavior.
Relational storage systems are used in APM as well, mostly to persist configuration options and meta data about the application landscape.

Usage and Value Creation

Now that we have the data in place, we want to get some value out of it. First, to make it accessible to humans, we need visualization technologies that offer user interfaces to interact with performance data, configurations, APM results and insights.

In APM, visualizations typically covers different aspects, such as displaying traces, metrics, or application architectures and flows. With dashboards, we can cohesively visualize certain key performance indicators relevant to a particular subject, such as a specific application or business transaction, in a single view.

Moreover, another typical APM use case is alerting. Alerting is the process of continually checking defined conditions based on operational performance metrics. In case a condition is not satisfied, APM systems dispatch appropriate notifications through channels such as email, SMS, or third-party applications to inform relevant stakeholders.

The OpenAPM Landscape

After having introduced the typical aspects of an APM architecture, we now show you how you can create custom APM solutions using openapm.io. We explain the OpenAPM landscape based on some concrete examples.

Monitoring Node.js Applications with the Elastic Stack

Let’s start with a simple example and assume your company has an Elastic stack already in place. Which open source tools can be integrated with the Elastic Stack in order to create a tailored APM solution? Let’s say you are using Node.js as a basis for your applications. What is a pragmatic way to monitor your applications, retrieve distributed traces, and visualized the results in dashboards? In the OpenAPM landscape, you would first select Elasticsearch for the storage dimension. Then you can filter for Node.js and tracing in the filter section to see only tools that integrate with Elasticsearch. The figure below illustrates an OpenAPM solution fitting our example:

In case Elastic decides to offer Java Monitoring or Anomaly Detection in the future, the open source community may update the landscape accordingly.

Monitoring Spring Boot Applications

Another example is to monitor spring boot applications. For these applications, we would like to monitor metrics and traces as well, and additionally integrate alerting functionality. After we filtered the landscape to reflect these requirements, it shows a selection of tools from which we can compose a suitable APM solution, such as in the figure below.

Monitoring Go Applications

If you want to monitor the performance of applications written in Go instead, exploring the OpenAPM landscape might lead you to a solution as illustrated below:

The OpenAPM landscape includes our own open source APM tool inspectIT as well. If you want to monitor Java applications, a typical setup could look like this.

Build Your Own, Custom APM Solution

Having this rich OpenAPM toolset at your disposal, you can tailor your custom APM solution that meets your needs best. Naturally, this requires some customization effort depending on your specific APM requirements. However, in comparison with commercial APM solutions, you get unique benefits:

Own the solution: You’re not tied to any vendor’s decisions. Your solution can be flexible and extendable, move at your own pace.
Only pay for what you use. With commercial APM suites, we often find that customers pay huge license fees and invest a lot of time in an initial configuration. In practice however, only a fraction of the features available is ever used.
Re-use, re-purpose, and integrate technologies that are already in place at your organization. For example, add an Elastic agent to your team’s existing Elastic stack to get your custom APM started.

Following this introductory piece, we will share our own experiences and show you examples of custom OpenAPM implementations in upcoming blog posts.

Tell us what you think! If you are interested in OpenAPM or APM in general and would like to know more, talk to us in the comment section below or reach out to us via email at apm@novatec-gmbh.de.