Now that Sensu Go is out, I thought this would be a great time to circle back and follow up on the Sensu Summit 2018 breakout session concerning Sensu 1.x to Sensu Go workload migration challenges. That session had some great feedback from Sensu users; we’ve been heads down over the past few months putting the pieces together to make it easier to move your existing workloads when you upgrade to Sensu Go and keep your existing Sensu Plugins working while you transition.
To start off the session, I ran through steps for migrating functional Sensu 1.x event pipeline configs into early Sensu Go Beta configurations — a huge thanks to the users out there who contributed sanitized workloads for me to look at ahead of the session! I made sure my migration examples covered the possible pain points I discussed previously as a way to facilitate discussion around some of the more complicated migration issues.
Here’s an update for each of the key takeaways from the Sensu Summit session:
- Everyone at the session seemed to be happy with the functionality in the Sensu translator tool to help rewrite existing Sensu 1.x configurations into Sensu Go resources. The latest translator rubygem released just before Sensu Go GA is up to date and ready for use with Sensu Go 5.0. If you installed Sensu translator during the Sensu Go Betas, please make sure you update to the latest Sensu translator release with
gem update sensu-translatorto make sure you’re translating to the final Sensu Go configuration spec. There was one feature request to enhance the translator to be able to automatically translate the old token substitution syntax to the new syntax as used in check configurations, which is now filed. If you think you can help implement this feature, give me a poke in the Sensu Community Slack — I’d love to work with someone to help make this happen.
- I demonstrated prototype logic to map Sensu Go events into Sensu 1.x events as an aid for existing Community Plugin handlers and mutators and I’m happy to report that a new sensu-plugin rubygem release is out with the new mapping logic! You can use the provided mapping mutator with any Sensu Plugin handler expecting consume a Sensu 1.x event. I cover the mapping functionality in detail here.
- We spent some time thinking about the best way to provide a dependable Ruby environment from which to run the Community Plugin Ruby executables: checks, mutators, and handlers. In the end, we thought the easiest thing to do was to provide the Sensu 1.x embedded Ruby environment as a standalone package, installed into a different directory as to not conflict with Sensu 1.x. We’ve documented how to install those packages as part of the Sensu Go installation guide.
All in all, it looks like the most needed pieces to enable Sensu 1.x users to upgrade to Sensu Go have come together. This is a great time for users to kick the tires by upgrading mature workloads from Sensu 1.x for use in Sensu Go.
Get started upgrading to Sensu Go with the Sensu sandbox
You can use the Sensu Go sandbox VM to upgrade Sensu 1.x configurations into Sensu Go. The sandbox comes provisioned with several additional utilities useful for testing workload migration:
sensu-plugins-rubypackage, which provides the embedded Ruby environment used in Sensu Core. You’ll be able to use
sensu-installto install existing Sensu Community plugins.
- Sensu Go event mapping mutator — from the updated
sensu-pluginrubygem — installed into the embedded Ruby environment, so you can continue to use Sensu Plugin handlers not yet updated to work with Sensu Go events.
- The Sensu translator tool, which helps you start converting Sensu 1.x configuration files into Sensu Go configuration syntax to use with the
sensuctl create -fcommand. Not everything can be translated — filters are just too complex to safely convert — but the translated configs will give you a decent starting point from which you can make adjustments as necessary.
Let’s keep the conversation going
If you're working on migrating from Sensu 1.x to Sensu Go, we’d love to hear about your migration experiences — both the successes and difficulties — over in the Sensu Go section of our Community Forum. Start a new topic and tag it with
1.x-migration. I’m interested in hearing about the migration experience from Sensu Go early adopters and driving some of that knowledge into a Sensu sandbox lesson plan and documentation to help future users.