We are delighted to report that our friends at Sensu have delivered their first Stable Release of Sensu Go, which was officially announced on December 5, 2018. With this 3-part blog series I would like to introduce this exciting new solution to all of our friends and colleagues who might benefit from its features and to try to explain as simply as possible what Sensu Go is and what functionality it offers.
Part 2 soon
Part 3 soon
Following up on the first Nightly Build released in February 2018 and the first Beta Release from April, this is the first stable version of Sensu Go. Putting it simply, Sensu Go is both a monitoring tool and a rewrite of the predecessor versions – Sensu 1.x (Sensu Core) written in Ruby and 3.x (Sensu Enterprise) written in the programming language Go, developed by Sensu. Sensu Go continues the series with this new version, Number 5. There are different reasons for the name chosen, one of which is the affinity for the Japanese language. Sensu is the Japanese word for the traditional hand-held fan depicted in the company logo, while Go is the name of the number five.
The first update to Sensu Go took place on the 19th of December 2018 (Sensu Go 5.1), the second took place on the 7th of February 2019 (Sensu Go 5.2) and the third on the 11th of March. (Sensu Go 5.3) I intend to write something about the content of these updates in my last blogpost, so stay tuned!
Sensu Go is comprised of the packages Sensu Backend and Sensu Agent. It is delivered with one Go binary and one configuration file. There are no further package dependencies. The package Sensu CLI allows you to use the command line sensuctl to create, update, query and delete all content in Sensu Go, including checks, handlers, filters, etc. Sensuctl communicates with the RESTful API of the Sensu backend. In this way, Sensu Go can be operated in its entirety using the API. (which is what we mean when we say “api-driven”) The entire communication is encrypted and conducted via WebSockets.
In addition to providing the RESTful API, the backend is also responsible for processing monitoring results. Sensu refers to an event pipeline which every event is passed through. An event is understood to be a result of the checks performed by the agents. Under the application of filters, mutators and handlers, events can be filtered in any of a number of ways, adapted to the required output and passed to scripts. This structure allows Sensu Go to be combined with virtually any third-party solution or to be integrated into existing environments. Just as one possible example, you could set up InfluxDB as a timeseries database (TSDB), Grafana to visualize the gathered metrics, and Slack to notify all your responsible parties using readily-available ready-to-go handlers in just a few minutes.
The Sensu backend also uses an integrated etcd instance to store the configuration, the current result of each check, and its current status. By simply adding additional backend instances you can arrange for clustering to provide security against outages and to spread the workload. Etcd is a NoSQL key-value store which is used in a variety of applications, Kubernetes among them. It works in cluster mode for communication in accordance with the Raft algorithm. (https://raft.github.io/) If a Sensu Go cluster is required then it is highly recommended to use an odd number of instances, as with many other cluster methods. If an etcd cluster already exists, then it is possible to allow it to be used by Sensu Go as well. It is only necessary to adapt the etcd parameters in the Sensu backend’s configuration file.
And that’s about it for Part 1 on Sensu Go and the functions of the Sensu backend. We expect to publish Part 2 soon, in which I will talk about how the Sensu agents do their thing and the way checks are distributed. If you have any questions in the meantime, don’t hesitate to contact us!