Skip to main content

Application Performance Management for ASP.NET Core application: Azure Application Insights vs Elastic APM

APM is a necessity in the world of micro services, but knowing that we need it, raises the next question: which of the many available products to choose and how? Let's try and find out.

Summary

The following post tries to evaluate two APM alternatives from a perspective of a .NET Core application.
As it turns out the feature set is quite different, so there are several trade offs to make.

Disclaimer

This overview is done under the following architectural constraints:

  • APM agent is hosted in-process of the application
  • The application is built on ASP.NET Core.
The information is as of end of June 2019, both platforms are undergoing active development, so things will change!

Key characteristics

Evaluating and comparing each and every feature would of course be a complete and exhaustive approach. It would also be exhausting to read, and pretty expensive to conduct. Who would want to pay for that? Usually, for every investigation there is a time box, a limit on the budget of how much resource a company is ready to spend for research. This is exactly the case here.
So, only a subset of features is evaluated. 
How is it chosen?
Well, simply these are the features that mattered to us most and that directly impacted the nonfunctional requirements of our systems:
  1. APM Agent package/library readiness for PRODuction
  2. Data ingestion latency and time until data becomes indexed & searchable
  3. Out of the box tracing / instrumentation features
  4. Integration with native .NET mechanisms like Activity, DiagnosticListener, EventSource etc
  5. Distributed tracing
  6. Programming model, support for generic concepts like OpenTracing
  7. Support for custom metrics, logs, transactions, spans and ability to correlate and view them easily in one UI
Let's look into each of those topics in turn.

Agent package PROD readiness

we’re moving the Elastic APM agent for .NET from preview to beta status
Still, it is not production-ready, as can be easily seen from their GitHub apm-agent-dotnet
It's pretty lively in the commits section, but essentially there is only one contributor -
Gergely Kalapos. He's good, you shoud visit his blog. But he is still a one-man army.
So, in summary - Elastic will get there for sure, but probably not so soon.
Application Insights, on the other hand is a much more mature player in this space.
Let's compare NuGet packages popularity for Microsoft.ApplicationInsights and Elastic.Apm
Both of them have been around for about 5 months at this time, as for number of downloads:
Wow, 0% for Elastic, 100% for Application Insights. 
Clearly Elastic is moving to bite off some market share from Azure. 
But what is it that they have to offer? What's their competitive advantage?
Let's look at the data latency first.

Stay tuned for the next post.
.

Comments

Popular posts from this blog

Serilog with Application Insights: Correlating logs with other telemetry by using Operation Id

Despite the odds, Serilog and Application Insights are a fairly common combination. Let's dive in and find out if such partnership is well justified. Introduction Serilog  is an extremely popular structured logging library, with powerful DSL and serialization features. The  benefits of structured logging  are well known an widely appreciated, so if you're not convinced yet, do spend some time to read up on the topic. Application Insights  is a very popular APM SaaS offering from Microsoft on Azure, especially in the .NET world. Motivation Now, you might wonder -  why put those two together ? After all, not all great tech plays together well. And I completely agree with that. In fact, when starting a greenfield application, Elastic Search seems to be a better choice for storing and searching structured logs data. One of the obvious benefits would be the data ingestion pipeline speed. But logs are only part of the story, however. When we look at the APM in general, El

EnumeratorCancellation: CancellationToken parameter from the generated IAsyncEnumerable.GetAsyncEnumerator will be unconsumed

Introduction If you're lucky enough to be using moderately new tech at work, or you just love trying out all the new goodies, you've probably had a chance to play around with IAsyncEnumerable<T> It does not take long until you come across CS8425 compiler warning, specifically if you're using yield and await keywords, and letting compiler do the heavy lifting of generating an implementation for you. CS8425 Async-iterator member has one or more parameters of type 'CancellationToken' but none of them is decorated with the 'EnumeratorCancellation' attribute, so the cancellation token parameter from the generated 'IAsyncEnumerable<>.GetAsyncEnumerator' will be unconsumed Don't know about you, but I didn't really understand what this warning actually means the first time I saw it. And the second time too. 😁 But hey - as application developers we've authored quite a lot of unreadable error messages ourselves, we have

Elastic Index Lifecycle Management

Elastic Stack is quite capable of running blazing fast queries against your data. However, the more data you have, the more time it will take to query it. Most of the times, however, Elastic Stack will not be the mechanism you use for long time data retention. Consequently you will have to get rid of the old data. Let's find out how. Brief overview of steps required Pick a naming convention Create index lifecycle management policy Create an index template that connects the alias and the ilm policy Create an index  Associate an  alias  with the index Let's dig into the details. Pick a naming convention Depending on the size of your company, your topology, team and org structure, you will probably have a Elastic Stack deployment that is shared between several teams and used by multiple services (distributed tracing benefits).  Namespaces is a useful notion that we can leverage while naming ELK objects, even though the notion itself is not directly suppo