cwjohnston

blueprint:
  name: Low battery level detection & notification for all battery sensors
  description: Regularly test all sensors with 'battery' device-class for crossing
    a certain battery level threshold and if so execute an action.
  domain: automation
  input:
    threshold:
      name: Battery warning level threshold
      description: Battery sensors below threshold are assumed to be low-battery (as
        well as binary battery sensors with value 'on').

cwjohnston

#!/bin/bash
TOKEN="YOUR_TOKEN_HERE"  # The API v2 OAuth token
ACCOUNT_ID="YOUR_ACCOUNT_ID_HERE"        # Replace with your account ID
ZONE_ID="example.com"  # The zone ID is the name of the zone (or domain)
RECORD_ID="42424242"       # Replace with the Record ID
IP=`curl -s -4 v4.ifconfig.co` # or provide your own value
curl -H "Authorization: Bearer $TOKEN" \
     -H "Content-Type: application/json" \
     -H "Accept: application/json" \
     -X "PATCH" \

cwjohnston

# postgres setup on centos 7
```
yum install https://download.postgresql.org/pub/repos/yum/10/redhat/rhel-7.7-x86_64/pgdg-redhat10-10-2.noarch.rpm
yum install postgresql10-server postgresql10
/usr/pgsql-10/bin/postgresql-10-setup initdb
systemctl start postgresql-10
systemctl enable postgresql-10
systemctl status postgresql-10 
sudo -u postgres psql
```

cwjohnston

#!/usr/bin/env bash

count=0

if [ -n "${1}" ] && [ "${1}" -eq "${1}" ] 2>/dev/null; then
  count=$1
else
  echo "${0}: \"${1}\" is not a number"
  exit 1
fi

cwjohnston

---
type: Asset
api_version: core/v2
metadata:
  name: nagios-foundation-linux
  namespace: default
spec:
  filters:
  - entity.system.os == 'linux'
  - entity.system.arch == 'amd64'

cwjohnston

$ aws ec2 describe-account-attributes --attribute-names supported-platforms
{
    "AccountAttributes": [
        {
            "AttributeName": "supported-platforms", 
            "AttributeValues": [
                {
                    "AttributeValue": "EC2"
                }, 
                {

cwjohnston

Configure Sensu Go Agent as a Windows service with WinSW

NOTE: These instructions are provided as a temporary workaround due to current lack of an official Windows package for Sensu Go. Should you follow these instructions, you may need to take manual steps prior to installing the planned official Windows package.

1. Follow [Windows installation instructions][install-win] to obtain the binary-only distribution
2. Create directories %PROGRAMDATA%\sensu\config and %PROGRAMFILES%\sensu
3. Download the [example agent.yml][example-agent-yml], edit as needed, and place in %PROGRAMDATA%\sensu\config
4. Unpack binary-only distribution (e.g. using 7zip) and copy executables into C:\Program Files\sensu\
5. Download appropriate [WinSW][winsw-releases] release, this will be WinSW.NET4.exe for most recent Windows versions.
6. Place WinSW executable in %PROGRAMFILES%\sensu\ and rename to sensu-agent-service.exe

cwjohnston

Pre-compiling native extensions for Sensu Plugins gem dependencies

Sources:

• GitHub - luislavena/gem-compiler: A RubyGems plugin that generates binary gems

Assumptions:

• Centos 7 platform
• You have some way to store these artifacts and make them available for systems in your environment

Caveats:

cwjohnston

# rpmrebuild autogenerated specfile

BuildRoot: /home/vagrant/.tmp/rpmrebuild.5522/work/root
AutoProv: no
%undefine __find_provides
AutoReq: no
%undefine __find_requires
# Do not try autogenerate prereq/conflicts/obsoletes and check files
%undefine __check_files
%undefine __find_prereq

cwjohnston

Sensu Scheduled Downtime Event Annotation

As part of helping a customer develop their proof of concept monitoring system with Sensu Enterprise, I worked up a mutator which uses stash data to determine if an event occurred within a pre-defined maintenance window.

The idea here is that event data needs to be annotated to indicate whether an event occurred during a scheduled maintenance window for SLA reporting purposes. With this added downtime context, events logged to an external source (e.g. greylog, elasticsearch) via Sensu Enterprise event bridge should provide enough information to determine whether or not a client's check result matches a scheduled downtime window.

Please note that I have done very little in the way of testing so this plugin is not likely to be very robust. Since this mutator probably needs to be applied to every event, it should probably be implemented as an extension before being put into a production system.

Assumptions