New Sensu module

Archives Ansible Developer
1

Hey,

i’v been working on a sensu module to interact and manage sensu through sensu-api, it’s done and tested but i’d like to see your opinions about it before doing a PR, being my first module and all wanted to make sure it’s looking good.

https://github.com/anoutsider/ansible/blob/sensu_module/library/monitoring/sensu

I guess the main usage for this is scheduling outages during continuous integration/deployment, that’s my primary use case for it, but the module actually integrates fully with sensu-api so pretty much all the operations are available.

Sensu Api docs : http://sensuapp.org/docs/latest/api_overview

the module is well documented “i hope :)” and commented, it supports environment variables for host,port,user,password parameters and apart from urlib/urlib2 from fetch_url & json it has no dependencies, btw should those be added to the requirements doc?

and here are some examples :

`

2

Generally if we can get the modules to behave using “state=present/absent” (desired state based) versus action based that’s preferable. Actually I should say, required.

Having state=list in there is ok.

I’m not familiar with Sensu but some of the stash parameters seem a little low level for doing things like signaling an outage Window, would it be possible to pass higher level parameters instead?

Maybe even something like a state=outage and have a parameter named “reason” versus having to pass content as JSON?

Just thinking aloud. Others may have comments and I may have few more later, but that’s something to start with, perhaps.

3

Hi,

That’s mainly the reason i opened this for discussion before doing the PR to discuss the “interface”.

i used “action” instead of “state” because present/absent didn’t make sense for most of the api usage, if the state parameter is standard maybe we could just rename “action” to “state” while keeping the same choices.

here is a list of actions we have in the module :

‘create’,
‘delete’,
‘get’,
‘list’,
‘request’,
‘resolve’,
‘history’,
‘silence’,
‘unsilence’,

if this was changed into state, we could probably have “create” changed to present, and “delete” changed to absent, not sure how would they fit for the other actions : list,get,request,resolve,history,silence,unsilence - unless we add these as states as well.

stashes in sensu are essentially a way to save some json data, it’s main and i think only good usage so far is to silence clients/checks. so we really only need the silencing function here, but i made the whole stashes endpoint available just in case someone has other uses for it.

this is why i separated silencing/unsilencing with it’s own actions, because it has a specific way of creating the stash path, so you would only have to provide client/check parameters with it, as opposed to using the “create” action on the “stashes” endpoint and building your own path with templated vars, like so “path: ‘silence/’{{ host }}‘/’{{ check_name }}”

for silencing you don’t really need to use the “content” parameter, it’s optional and you can use it in cases where you need to add any info on the stash, maybe for some dashboard… so “reason” in my example, is just an example… people can have any sort of data there so i don’t see why we would limit this to a “reason” parameter since it’s not needed.

i will keep thinking of ways to interface this better, but i think i initially got the “action” parameter idea from the nagios plugin since it’s what relates to sensu usage most.

hopefully we will get input from other people who use sensu.

Thanks

4

“list,get,request,resolve,history,silence,unsilence - unless we add these as states as well.”

silenced/unsilenced feel like states.

I’m not sure of the reasons why there would be a seperate get/list/request/resolve though I’m not familiar with sensu.

A state=list is present in a few ansible modules and is somewhat reasonable, do we need the others?

They could be contained in a seperate ‘action’ parameter, but I’d like everything to be as stateful as possible.

5

sensu is a monitoring system that works as an event router, checks are ran on clients and results are picked up by the server from a rabbitmq stream, if threshold/conditions are met it triggers an event, which is also passed to handlers, “handlers” could be anything… mail,notifications… and one of the handlers available is actually a script that runs an ansible playbook.

in terms of stateful actions, get,list,history are mainly informational but there can probably be some use cases for them.

request is used to ask a client to run a specific check, and returns the check results, this can have many use cases, resolve can be used, resolve is used to resolve/end an event… these can be used during integration to check for services or resolve a certain monitoring event that was triggered by a another task in a playbook.

i didn’t plan this in terms of being stateful tbh, the idea was to expose integration with the api as a whole, where anyone could use it however they want, but we could try to make it look more “stateful”

we could get rid of the “endpoint” parameter and use action with states, for example

action:
client
check
event
stash

state:
present
absent
list
silenced
unsilenced
resolved

we’d have to add some extra parameters for “history” and “request” these would be extra parameters to the “check and client” endpoints with boolean values.

so now for example we could do:

this resembles an old “get” action on the “clients” endpoint

  • sensu: action=client state=present client=web1

this resembles an old “delete” action on the “clients” endpoint

  • sensu: action=client state=absent client=web1

this resembles an old “list” action on the “clients” endpoint

  • sensu: action=client state=list client=web1

this resembles an old “history” action on the “clients” endpoint

  • sensu: action=client state=list client=web1 history=yes

this resembles an old “resolve” action on the “events” endpoint

  • sensu: action=event state=resolved client=web1 check=check_disk

this resembles an old “silence” action on the “stashes” endpoint

  • sensu: action=stash state=silenced client=web2 expire=120

this resembles an old “request” action on the “checks” endpoint

  • sensu: action=check state=present client=web2 request=yes

i’m not sure if this simplifies things or actually complicates them, to me i feel the current use of the parameter is descriptive, i didn’t think about it in terms of being stateful, so let me know if you have any ideas.

Thanks,
Amr

6

I don’t think it would make sense to specify both an ‘action’ and a ‘state’ at the same time in the above.

I’m also a little unclear on how request and check modify things.

Can you help me understand why the user would need the information out of those other actions and checks from within an ansible playbook?

This may give me some ideas as to how to present them.