Moving (and moving on up) to Sensu Go at Iforium

The following is a guest post from Michael Eaton, Senior DevOps Engineer at Iforium, an eGaming software development company.

I work at Iforium, an eGaming company based on the Isle of Man, where — for the past three years — we’d been using Sensu Core to monitor our infrastructure.

Earlier this year we began our migration to Sensu Go. In this post, I’ll share a bit about our journey, offering some background on Iforium and our technical stack, our monitoring pain points, and our take on Sensu Go so far.

Iforium: the Gateway to eGaming

As a leading eGaming software development company, Iforium focuses on providing the next-generation casino platform Gameflex™, our multi-award winning aggregation platform that delivers the largest casino and gaming portfolio in the industry with a focus on regulated markets. Major global household names are included in our client list.

IaC at Iforium

We’re an Ansible shop, and as such rely on an Infrastructure as Code (IaC) workflow for our day-to-day technical operations. For the past three years, we’ve used Sensu Core (the original version of Sensu) to monitor our infrastructure and have recently migrated to Sensu Go. We’ve since migrated three of our datacenters with no real issues.

By and large, we’re a static operation — for example, I just finished setting up Sensu Go in our London datacenter, which is our largest, but we generally won’t see much change with regards to monitoring requirements for a while.

Easier configuration with the Ansible Collection for Sensu Go

We’re using the Ansible Collection to configure our Sensu Go cluster and agents, which is quite a step up from Sensu Core, where everything was JSON files and custom Ansible tasks and plugin copying to client machines. Sensu Go makes this easier by making the plugins available at a central location (in our case, the Sensu backend server, served by Nginx).

Easier custom deployments with Sensu assets

I love assets. They just make sense. In case you’re not familiar, assets are shareable, reusable packages that make it easier to deploy Sensu plugins. As a long-time Sensu Core user, I was very familiar with plugins and their benefits — as well as limitations. At Iforium, we have four of our own custom assets for some of the custom checks we do, written in a combination of Python, Perl, and bash scripts. We host them on the backend server and serve them via Nginx.

We currently rely on the Ruby runtime as well as the check when using assets — which isn’t necessarily ideal or intuitive — but are looking forward to checking out some of the community plugin projects created by the Sensu Developer Advocacy team which should help streamline that workflow. Specifying versions of assets has definitely been helpful, for when I turn to my next environment to migrate, I simply use the same version and I know that things will just work the way I’m expecting them to. Assets make everything easier — there’s now just one place to go to propagate an update across our Sensu Go monitoring clusters.

With assets, our current workflow is to ensure that Python is installed on the agent. We have some assets that run on the proxy client, and we need to ensure that the agent and proxy client have the correct version of Python.

A single pane of glass

One thing I especially loved about Sensu Core was Uchiwa, the legacy dashboard. With Uchiwa, we had a single dashboard showing us everything that was going with all our different datacenters around the world, with all our events and incidents in one place in our NOC.

Now that we’re looking at using the commercial distribution of Sensu Go though, I look forward to using Sensu’s federation to achieve that same level of multi-cluster visibility.

Flexibility to make changes in the command line or the UI

I tend to use the Sensu Go Ansible Collection to make changes over the Sensu web UI or directly with the sensuctl CLI tool, but it’s nice to know you can use both. The sensuctl tool is very handy and I’ve used it a few times during testing to delete assets or check definitions, but I can do that via the UI as well, whereas before (in Sensu Core) I couldn’t. It’s quite useful to have those command-line tools available when you need them.

Having recently started using Kubernetes and kubectl, the Kubernetes command-line tool, it is comforting (and handy) to see just how sensuctl and kubectl are similar in their approaches to managing resources.

Going forward

I’m looking forward to continuing our Sensu Go journey — learning more about how it works as well as seeing what’s coming up on the roadmap. My advice for anyone considering a migration would be to plan things out, look at any custom plugins you have and figure out their requirements first, then start with the simple checks, like disk, CPU, memory, etc. Once you’re comfortable with this, start looking at packaging your own assets.

Thanks, Michael, for the writeup! If you have your own Sensu Go migration story to share, let us know in our Community Forum, below.