The Sensu Plugin architecture is what make Sensu the rich and extensible monitoring framework that it is. Sensu 2.0 provided us with an exciting opportunity to reimagine the user and developer experience for plugins. Sensu 2.0 assets give us a new kind of flexibility that removes our dependency on system packages and gives us a mechanism for uniformly packaging and shipping plugins to Sensu installations.
In this talk from Sensu Summit 2018, Greg Poirier, SVP of Engineering, walks you through assets in Sensu 2.0, our ideas about how assets may impact the community plugins, and what we have planned for Sensu Enterprise integrations as assets.
1 of 29
Download to read offline
More Related Content
Editor's Notes
Plugins are what make Sensu Sensu.
Sensu is the skeleton, but plugins are the muscles that make motion possible.
They¡¯re the glue you use to connect the different components of your infrastructure.
component health is possibly mutated and then sent to handlers that do some kind of reporting
metrics
events
alerts
Sensu was written in Ruby
Systems programming language of the past decade
Follows that plugins were also primarily written in Ruby
Sensu was born alongside configuration management
Considerable automation to deploy and manage Sensu components
Does all of the heavy lifting for plugins as well
- There are several components of getting plugins onto hosts
The base of the hierarchy is configuration management
It installs the Sensu omnibus Ruby package and Sensu
Part of the omnibus package is a tool called sensu-install that we use to install plugins packaged as gems.
Let¡¯s get to 2.0.
I have a 3 step program that¡¯s going to change the way you think about plugins.
As I said last year when I spoke about 2.0
We care about our existing users and we¡¯re doing everything we can to make the transition to 2.0 easier.
We¡¯re working on a sensu omnibus package that CM can use to install Sensu plugins alongside 2.0.
We want to leverage existing community member expert knowledge so that we¡¯re not pulling the rug out from underneath everyone.
This first step ignores assets completely, though.
So step 2 is, let¡¯s introduce assets into the ecosystem.
Since not everyone understands what assets are, I¡¯d like to give a brief overview of assets and how Sensu 2.0 uses them.
An asset is a package for Sensu plugins.
Helm charts. Habitat plans. Docker containers. Sensu assets.
Packaging. It¡¯s so hot right now.
Assets are a secure, compressed archive that Sensu can download and expand as needed.
Whether that¡¯s the first time the asset is encountered or when Sensu is informed of an update to the plugin.
How does that work? I¡¯ll focus on check assets, since that¡¯s what¡¯s currently available in 2.0.
Check request issued w/ asset definition
Agent checks if local
Fetch if not
Verify the asset archive
Expand the asset
Execute the check
As I mentioned, these are currently available in 2.0 for checks
Handlers, mutators, and extensions are coming soon
And each plugin can have multiple assets associated with it
This can be useful if a particular plugin is used on multiple operating systems or architectures
I always think about Ruby assets first
Want to continue to leverage the massive resource of community plugins
Show a path for users to manage their own internal Ruby assets
And other languages with a VM
The biggest problem with languages with a separate runtime is building and packaging them for assets
If you¡¯ve ever run gem install openssl, you know how exciting gems as packages are
What used to be a platform-independent dependency becomes a platform and architecture dependent dependency with compiled components
How do we approach this problem that creates as little work as possible for users
We¡¯re looking at a couple of approaches
Build packs and a single ruby asset
We¡¯ve focused on asking ourselves, ¡°Which is better?¡±
If we can get both to work, then the score is actually tied between them.
So that begs the question...
Why not both?
Assets are flexible enough that they can support arbitrary workloads.
It might be expensive, but hey... you... all of you... we would love your help exploring these ideas.
But what if things could be easier?
We¡¯ve been working with Go for the last year and a half, and a lot of the problems that interpreted languages like Ruby and Python have, Go doesn¡¯t.
Sensu engineers have come to love and appreciate Go, and as a systems programming language, it¡¯s dominating the landscape.
Plugins, and therefore assets, written in Go are smaller, have no external dependencies, and are significantly easier to package.
And Sensu engineers are developing considerable expertise that we can lend to the community in developing and building Go plugins.
The future for Sensu assets is exciting.
Building binaries for multiple platforms and architectures is trivial with tools like go-releaser.
GitHub releases can be used to publish assets.
And in the future, you¡¯ll be able to share your asset and make it discoverable by other engineers with the Bonsai Asset Index
Of course, this isn¡¯t just limited to Go.
This workflow and assets are language agnostic.
As Kelsey said earlier, if you can put it in a tar ball, you can put it in an asset.
Thank you all for being here.
We would love to hear your thoughts and work with you as you start to play with Sensu 2.0 and assets.
Feel free to stop by the community Slack in the #sensu2 channel to chat with other users experimenting with Sensu 2.0 as well as members of our engineering team.