Sensu Reviews

The monitoring framework following the microservice approach gives users the ability to fully embed Sensu Go into their environment and workflows. The strengths of Sensu Go consist in giving users endless possibilities to process events using the event pipeline with filters and mutators. Handlers represent the integration to 3rd party tools, which could be everything you can think of. Every event is...

Read more

Coming from classic montioring tools it takes some time to understand how Sensu Go works, but it's definitely worth it. At the moment Sensu Go brings some in-built filters (and simple filter examples in the docs) and some maintained handlers. If users want to go beyond that they need to look for community-implementations or write own filter expressions and handlers, what assumes that they are able to script or understand javascript (for filter expressions), golang or any other programming language (for handlers). What sounds like a con in one way is a pro in another, because it gives the user endless possibilities.

Sensu provides an extremely flexible monitoring event pipeline for users of all sizes. Sensu is available as an open source, MIT licensed product allowing even the smallest organizations to leverage Sensu to provide a robust and flexible monitoring pipeline for all of their environments. Additionally, Sensu provides enterprise features (LDAP, AD, native external integrations) along with an incredible support team for their enterprise version. Sensu provides native primitives that allow users to significantly reduce alert fatigue via filters, dependencies, aggregations, and scheduled silences. These primitives increase the value of Sensu monitoring event pipelines allowing "robots" to do the initial alert remediation and only notifying a human when there's real issues.

Sensu Core and Sensu Go both provide dashboards. In my experience, the larger the Sensu installation, the harder the provided dashboards become to use. However, Sensu Go now has native RBAC controls and appears to be significantly improving the dashboard with each release.

Sensu Go, the new version, is easy to deploy, and it's considerably easier to manage and scale as compared to Nagios, which we had been using.

The GUI interface still needs a lot of work; it's quite spartan compared to Nagios XI. The documentation isn't especially beginner-friendly; it lacks "hello world" examples and seems to assume that you're already intimately familiar with some of the concepts.

- Amazingly smooth way of deploying this. - No budget required. ;) - Easy to understand. - Solves most of your problems. - Have loads of plugins available.

- Cannot use a graph of the metrics throughout the day, or over a week in the dashboard. - The updates are not backward compatible.

Thanks for the great review, Debodirno! We're happy to hear you enjoy using Sensu. If you're referring to the responsive agents or the entity classes tiles on the dashboard, those displays are meant to be the current snapshot of the health of your environment. If you would like to discuss this in more detail, feel free to post your questions on Discourse [https://discourse.sensu.io/]

While many monitoring solutions try to be an out of box solution that is easy to get going and perform a prescriptive path Sensu took a step back and said instead of building a product we should build a framework. By taking the stance of framework first and product second what you get is a truly great experience where things work with little to no effort to get it spun up and going you can do so much more with it than the developers ever imagined people would use it. If you are willing to write code you can do pretty much anything you want by leveraging their framework and event pipeline. This can include writing new checks, metric gathering scripts, TSDB shippers, automated triage, automated remediation, etc.

Losing a lot of flexibility with filters in the transition from `sensu-ruby` to `sensu-go` but for most use cases you probably won't notice.

I like how customizable and flexible Sensu is. It lets us get very granular so we can set different thresholds for different servers, and send different alerts from the same server to different teams. It is not all or nothing per servers. You can also have multiple handlers for each check, so you can send events to more than one place. There are a lot of different TSDB handlers as well.

Out of the box, it doesn't really do much aside from send keepalives. It would be nice if it came predefined with CPU/Memory/Disk checks

So many important features and integrations. Awesome community plugins.

Most people do not manually instal sensu, they use config management, yet the documentations on how to get up and running using ansible or chef is very weak. This is present inside the community plugins and handlers. Do you know how hard it was to try and link sensu/chef/slack using the community plugins? There was no mentions of a sensu_snippet any where in the docs.

I did several PoC of Sensu and demonstrated it to a handful of clients. What I found from my PoC is that, unanimously everyone liked the solution. I personally found it interesting enough to propose it to the clients. The ease of configuration is definitely worth a mention, specially so with the ansible repository. It perfectly does what it advertises. I haven't dug very deep into the myriad customization available because I didn't need to. As a monitoring solution it pretty much serves perfectly.

The graphical dashboard (uchiwa) is pretty bare bones. It would be useful to have some more elegance (UI/UX wise) and bells and whistles into it. Another feedback that I obtained is that some folks wanted to set up monitoring/alerting from a graphical interface. I don't know whether open source sensu provides that.

easy to configure and maintain service monitoring via json files. Works with existing Nagios plugins, as well as a suite of plugins for sensu written in ruby. integrates well via webhooks with other notification tools (slack, pagerduty).

some seemingly simple functions like service dependencies can be tricky to implement properly. Can't set a different retry interval once a problem is detected, like you can in nagios. documentation is just ok. Initial setup can be challenging to troubleshoot.

This was 100% designed to monitor cloud infrastructure and is so versatile

I think it is time to add an admin interface​ of some sort.

Its simply fast, you can do anything, and great support

RabbitMQ and Redis, which were both fixed in 2.0 :)