Welcome to pysensu-yelp’s documentation!

Contents:

Functions

pysensu_yelp.human_to_seconds(string)

Convert internal string like 1M, 1Y3M, 3W to seconds.

Parameters:string (str) – Interval string like 1M, 1W, 1M3W4h2s… (s => seconds, m => minutes, h => hours, D => days, W => weeks, M => months, Y => Years).
Return type:int
Returns:The conversion in seconds of string.
pysensu_yelp.send_event(name, runbook, status, output, team, page=False, tip=None, notification_email=None, check_every='30s', realert_every=-1, alert_after='0s', dependencies=[], irc_channels=None, slack_channels=None, ticket=False, project=None, source=None, tags=[], ttl=None, sensu_host='169.254.255.254', sensu_port=3030, component=None, description=None)

Send a new event with the given information. Requires a name, runbook, status code, event output, and team but the other keys are kwargs and have defaults.

Parameters:
  • name (str) – Name of the check
  • runbook (str) – The runbook associated with the check
  • status (int) – Exit status code, 0,1,2,3. Must comply with the Nagios conventions. See the Sensu docs for the exact specification.
  • output (str) – The output of the check itself. May include CRIT/WARN/OK to make it easy to evaluate how things went. Should be newline separated, but try to put the most relevant data in the first line. Example: OK: Everything is fine or CRIT: Accounts are locked. Users can’t buy widgets.
  • team (str) – Team responsible for this check. This team must already be defined server-side in the Sensu handler configuration.
  • page (bool) – Boolean on whether this alert is page-worthy. Activates handlers that send pages.
  • tip (str) – A short 1-line version of the runbook. Example: “Set clip-jawed monodish to 6”
  • notification_email (str) – A comma-separated string of email destinations. Unset will default to the “team” default.
  • check_every (str) – Human readable time unit to let Sensu know how of then this event is fired. Defaults to “30s”. If this parameter is not set correctly, the math for alert_after will be incorrect.
  • realert_every (int) – Integer value for filtering repeat occurrences. A value of 2 would send every other alert. Defaults to -1, which is a special value representing exponential backoff. (alerts on event number 1,2,4,8, etc)
  • alert_after (str) – A human readable time unit to suspend handler action until enough occurrences have taken place. Only valid when check_every is accurate.
  • dependencies (list) – An list of strings representing checks that this check is dependent on.
  • irc_channels (list) – An list of IRC channels to send the event notification to. Defaults to the team setting. Set an empty list to specify no IRC notifications.
  • slack_channels (list) – An list of Slack channels to send the event notification to. Defaults to the team setting. Set an empty list to specify no Slack notifications.
  • ticket (bool) – A Boolean value to enable ticket creation. Defaults to false.
  • project (str) – A string representing the JIRA project that the ticket should go under. Defaults to the team value.
  • source (str) – Allows “masquerading” the source value of the event, otherwise comes from the fqdn of the host it runs on. This is especially important to set on events that could potentially be created from multiple hosts. For example if send_event is called from three different hosts in a cluster, you wouldn’t want three different events, you would only want one event that looked like it came from the_cluster, so you would set source='the_cluster'.
  • tags (list) – An list of arbitrary tags that can be used in handlers for different metadata needs such as labels in JIRA handlers.
  • ttl (str) – A human readable time unit to set the check TTL. If Sensu does not hear from the check after this time unit, Sensu will spawn a new failing event! (aka check staleness) Defaults to None, meaning Sensu will only spawn events when send_event is called.
  • sensu_host (str) – The IP or Name to connect to for sending the event. Defaults to the yocalhost IP.
  • component (list) – Component(s) affected by the event. Good example here would would be to include the service that is being affected or a module of that service such as healthcheck.
  • description (str) – Human readable text giving more context on the event. This could include information on what the check means or why was it created.

Note on TTL events and alert_after: alert_after and check_every only really make sense on events that are created periodically. Setting alert_after on checks that are not periodic is not advised because the math will be incorrect. For example, if check was written that called send_event on minute values that were prime, what should the check_every setting be? No matter what it was, it would be wrong, and therefore alert_after would be incorrectly calculated (as it is a function of the number of failing events seen multiplied by the check_every setting). If in doubt, set alert_after to 0 to ensure you never miss an alert due to incorrect alert_after math on non-periodic events. (See also this Pull request)

Indices and tables