Testing Instana for APM

I’ve recently started looking at Instana, who make an Enterprise Observability Platform for APM, Web Site, Cloud & Infrastructure, and Microservices monitoring. This is something that’s been of interest to me for quite a while being a developer. In every conversation I have regarding monitoring, it’s always been about instrumentation – making sure the right information is exposed from the application, or the right tracing capability leveraged. Applications can be difficult enough to troubleshoot at the best of times, but with application components becoming more distributed (and smaller), this is something whose complexity has only increased. I was curious to see how easily Instana integrated into some .NET Core applications, containerised in a docker environment on Linux.

Instana works in a similar manner to many of the APM tools – there’s a small software agent deployed to the servers, a software agent deployed to kubernetes/openshift clusters, and instrumentation added to the applications’ code. You technically don’t need to instrument your applications (have the application output tracing, performance data, errors etc), but the more information you expose, the better the monitoring experience and capability.

I started a two week trial account, and installed the agent on a few dev servers. The install was pretty straight forward – certainly more so than some more traditional monitoring agent deployments over the years. I decided to use the SaaS version of Instana for the test, rather than the on-prem version. It’s good they have an on-prem version, but the goal should always be to leverage the SaaS version where possible (for so many reasons). It’s a dynamic agent, so it will automatically configure/load any additional modules it needs based on what it needs to monitor. You can see from the below picture for how many environments the agent is built. I just started with a Linux agent (and I used the systemd service option). The agent is supplied with an API key to connect it back to your account.

Given I was just deploying the standard agent from the script, I then had a couple of post-install config changes to make – which you’d organize in advance for an enterprise wide distribution. I turned on the .NET CLR module as I wanted insights into a .NET Core application. The configuration is there so you can stop the agent going crazy and monitoring every single component it finds.

I started the agent, and a few minutes later the SaaS console started reporting data. I used that time to deploy it to another couple of hosts as well. The initial pictures reminded me very much of Lex trying to find the door locks on the Unix system in Jurassic Park – I am a sucker for fancy graphics on dashboards. The diagram below shows two on-prem Ubuntu servers, and one Azure based Ubuntu server – all running docker. The layers represented discovered components – containers, processes, etc.

So that was easy and took a few minutes. I was then able to see docker containers running the dotnet process, but understandably not a lot more than that. The next step was to enable the instrumentation within my .NET Core container. This was relatively trivial as well. I followed the instructions here, added the Instana NuGet package to the application, added a couple of environment variables to the Dockerfile, and a couple to the compose script I use to start the container. After committing the code, Jenkins kicked off a new build and push to the repository. I pulled the new version of the container down to the host after updating the compose file, and sure enough a few minutes later the Instana portal was now showing insights within the application. I’ve included a couple of screenshots below. It started picking up API calls my app was making, their latency/status etc, and started tracking the APIs exposed by my app.

Great start – there was a huge amount of information there, and very easy to consume. I then decided to check out the web site monitoring functionality. I added a site, and it then gave me the script code to include in the website to enable the reporting.

I added the code into my web application, and started receiving data. You can see from the headings below, and the screenshots on the Instana site what kind of data is made available.

The whole process took 10 minutes – granted its a lot easier when you’re able to push straight to production and don’t have outbound firewall rules to deal with, but nonetheless it was very straight forward. Very easy to get started with as well for testing the capability.

~ Mike

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s