Effective observability using OpenTelemetry and Sitecore MVC

OpenTelemetry (OTel for short) is a open source, cross platform, vendor neutral framework and specification/protocol for making systems observable. This is done through instrumenting code so it emits traces, metrics and logs in a common format so that can be sent to a observability backend. Backends can be open source systems as https://www.jaegertracing.io/, https://prometheus.io/, https://signoz.io/ or commercial offerings that also supports the OpenTelemetry Protocol (OTLP) specification such has New Relic, DataDog, Azure App Insights etc.

Sitecore MVC vs Sitecore rendering hosts

If you do a headless implementation using either the Sitecore ASP.NET Core SDK (now open source yay!) or the Sitecore JavaScript Rendering SDK (JSS) then it is easy to add OTel to you head implementation in a few minutes, see .NET 6+ guide or Node.js guide. But for classic .NET 4.8 framework / Sitecore MVC sites it's another story which this post is all about!

.NET 4.8 is supported but Sitecore Platform DXP is making it more difficult then it should be mostly due to lots of very old dependencies used in Sitecore Platform DXP, even in the latest (in time of writing) 10.4.0 release.

Implementing OTel support in Sitecore MVC sites

I have create a complete example implementation here that is wired up to use the ASP.NET Aspire Dashboard as a OTel compatible backend to store traces, metrics and logs in memory only (good for local development environments).

ASP.NET Aspire Dashboard showing a trace

What you get is:

Some interesting implementation details:

  1. Biggest challenge was to get the OTel nuget packages to work with Sitecore due to Sitecore has lots of old (and deprecated) dependencies, see this transform.
  2. Since Sitecore uses log4net and forwards Microsoft.Extensions.Logging logs into that I needed to reverse that process so that log4net messages is forwarded to Microsoft.Extensions.Logging instead as it's automatically picked up by OTel! See the ServiceConfigurator and MsForwardingAppender
  3. The whole OTel configuration is wired up in an old school HttpApplication that you need to inherit in your own Global.asax

You can also find more useful OTel extensions here: https://github.com/open-telemetry/opentelemetry-dotnet-contrib/tree/main/src

Conclusion

I really like the fact that OTel is a vendor neutral and agreed upon (and CNCF backed) approach to observability across different technology stacks which is very useful in these composable times.

Checkout even more possibilities on the OpenTelemetry ecosystem page.