Just want to follow up on one question from the webinar today.
“Can you prune based on last execution, say 1 month old”
I gave an answer in the webinar about using a sensuctl command plugin for that, but i want to be a little more explicit about the answer. The question really goes to the heart of what prune is intended to do.
What is the difference between prune and delete? The prune api (and sensuctl prune command) are really aimed at pipeline element management, and not the event resources. The prune API essentially wraps several resource actions, list, get, delete, create into a convenient operation that lets you sync declarative resource definitions with the running Sensu cluster state.
Events are a bit special, in that they aren’t expected to be created with sensuctl, but sensuctl can manage them via deleting them. So using prune on the Events doesn’t make sense as intended. I would just use the Events API list and delete methods and script the stale event removal, and I’d make that script a sensuctl command plugin.
The sensuctl command plugin is also a newer feature, but it’s really powerful way to build specialized sensuctl actions that interact with the Sensu apis, assuming the sensuctl brokered user authentication. A sensuctl command plugin makes it possible to build reusable bits of logic to stitch together multiple Sensu API calls meant for adhoc Sensu operators.
We’ll be putting work into the Sensu plugins golang SDK to make sharable golang based sensuctl command plugins a bit easier to create, like we;ve done for the other plugin types. But you can write your own for in-house use in pretty much any language your team’s workstation env support.
I think the sensuctl command plugins are one of the most powerful features added to Sensu Go, once we drop the barrier to entry for operators to write and share command plugins I think its going to be really popular, especially for teams of operators who want to encode operational knowledge for other teammates to reuse.