Hope This Helps

Ich hatte ja schon mal einen lokalen Check geschrieben der das ganze mit VBS monitored, jetzt hab ich das alles mal in Powershell übersetzt um auch einen Windows 2019 Server sauber überwachen zu können.


Hier gehts zum Repo : https://github.com/Mokkujin/Checks-for-Check_MK/tree/main/FSRM-Quotas

Ich hab hier einen kleinen Check in Powershell für Mailstore gebaut. Hier wird ein Job überprüft ob das Ergebnis "succeeded" ist wenn ja ist der Job ok. Sollte etwas anderes als Rückgabewert kommen wird ein Fehler ausgegeben.

In der CheckMK Oberfläche sieht das ganze dann so aus:


Hier gehts zum github Repo : https://github.com/Mokkujin/Checks-for-Check_MK

Quelle:
https://help.mailstore.com/de/server/PowerShell_API-Wrapper_Tutorial
https://help.mailstore.com/en/server/MailStore_Server_Service_Configuration
https://help.mailstore.com/de/server/Administration_API_-_Function_Reference

Hier sollte ein Terminal Server (Windows 2019) in das Monitoring von CheckMK aufgenommen werden. Hier werden die Perf Counter des Terminal Servers benötigt. Als erstes dachte ich mir ich mach das mal einfach und lass einfach die perf counter raus. Das habe ich mit dem folgenden Befehl gemacht.

lodctr /S:C:\scripts\perf.txt

Leider steht hier in der Datei ein perf Counter mit diesem Wert

5736=Terminal Services Session

in der Datei. Scheinbar hat dieser Perfcounter nicht gestimmt und ich hab den nochmal manuell aus der Registry ermittelt. Dort sind diese Werte hinterlegt.

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib\_V2Providers\{f3b975e7-e068-4f66-81ef-b23e0a0e64c9}\{fc9e399c-c70a-4458-8430-ca249c371eb3}]
"NameResource"=dword:00000001
"ExplainResource"=dword:00000003
"NeutralName"="Terminal Services"
"InstanceType"=dword:00000000
"First Counter"=dword:0000142a
"Last Counter"=dword:00001430
"CounterBlock"=hex:01,00,00,00,00,00,01,00,01,00,00,00,00,00,00,00,64,00,00,00,\
  00,00,00,00,05,00,00,00,07,00,00,00,00,00,00,00,ff,ff,ff,ff,ff,ff,ff,ff,ff,\
  ff,ff,ff,ff,ff,ff,ff,00,00,00,00,02,00,00,00,00,00,01,00,01,00,00,00,00,00,\
  00,00,64,00,00,00,00,00,00,00,09,00,00,00,0b,00,00,00,00,00,00,00,ff,ff,ff,\
  ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,00,00,00,00,03,00,00,00,00,00,01,00,\
  01,00,00,00,00,00,00,00,64,00,00,00,00,00,00,00,0d,00,00,00,0f,00,00,00,00,\
  00,00,00,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,00,00,00,00
"CounterCount"=dword:00000003

Jetzt nimmt man den Wert der unter First Counter gelistet ist und rechnet diesen von HEX in DEZIMAL um. Also HEX 0000142a = DEZ 5162 , dann kommt man auf einen anderen Counter, verwendet man diesen jetzt in CheckMK funktioniert alles wie es soll. AAHHHHH
Auszug aus der check_mk.ini

[winperf]
    counters = 5162:ts_sessions

Ich hatte mal wieder mit haproxy zu tun, leider hatte diese niemand in das Monitoring eingepflegt.
Ist natürlich doof wenn immer die Sessions voll laufen und keiner was merkt.
Lange Rede kurzer Sinn
Python & Powershell reagieren gleich wenn

$WIPass = '' bzw WIPass = ''

wird der check ohne auth ausgeführt. Sollte eure Statusseite nicht über ssl erreichbar sein, sollte man noch die ssl checks rauswerfen ! Unter Powershell einfach diese Zeilen auskommentieren

SkipCertificateCheck

unter Python bitte das aus den Zeilen entfernen

, verify=False

Hier ist der Check in Powershell / Python und Bash.
Ich empfehle die Python Version
checkmk-haproxy-localcheck in powershell / python und bash

Cloudwatch liefert ja schon von Haus aus viele Metriken will man jedoch "tiefer" ins System schauen empfiehlt es sich einen anderen Agent zu verwenden (zusätzlich oder den Cloudwatch Agent nur als Bridge)

Ich habe mich für den Weg entschlossen die Metriken von collectd üder den cloudwatch agent in Cloudwatch zu reporten. Dort können dann wie gewohnt Alarme definiert werden.

Als erstes braucht man einen IAM User (Programmatic access) und eine IAM Role die das Recht besitzen in Cloudwatch zu reporten.


Die Role "ServerMonitoring" weißt man dann den EC2 Instanzen zu die in das Monitoring aufgenommen werden müssen.




Jetzt müssen die benötigten Packete heruntergeladen & installiert werden. Mein Beispiel ist für Debian 8 und Debian 9 geeignet. Bei anderen Linux Systemen ist der Ablauf etwas anders. Der Cloudwatch Agent kann auf der Seite ( Install Cloudwatch Agent ) für andere Systeme heruntergeladen werden. Das Github Repo für die collectd-cloudwatch Bridge ist hier GitHub - awslabs

mkdir -p ~/downloads
cd ~/downloads
wget https://s3.amazonaws.com/amazoncloudwatch-agent/debian/amd64/latest/amazon-cloudwatch-agent.deb
wget https://github.com/awslabs/collectd-cloudwatch/archive/master.zip
dpkg -i amazon-cloudwatch-agent.deb
unzip master.zip

Unter Debian muss man das setup.py script leicht abändern

cd collectd-cloudwatch-master/src/
vi setup.py

dort suchen nach

DISTRIBUTION_TO_INSTALLER = {
    "Ubuntu": APT_INSTALL_COMMAND,
    "Red Hat Enterprise Linux Server": YUM_INSTALL_COMMAND,
    "Amazon Linux AMI": YUM_INSTALL_COMMAND,
    "Amazon Linux": YUM_INSTALL_COMMAND,
    "CentOS Linux": YUM_INSTALL_COMMAND,
}

ersetze mit

DISTRIBUTION_TO_INSTALLER = {
    "Debian GNU": APT_INSTALL_COMMAND,
    "Ubuntu": APT_INSTALL_COMMAND,
    "Red Hat Enterprise Linux Server": YUM_INSTALL_COMMAND,
    "Amazon Linux AMI": YUM_INSTALL_COMMAND,
    "Amazon Linux": YUM_INSTALL_COMMAND,
    "CentOS Linux": YUM_INSTALL_COMMAND,
}

Dann muss collectd installiert werden und die aws cli konfiguriert werden

apt install collectd
aws configure (AWS Key & Security Key von monitoring user angeben)

jetzt installieren wir noch die bridge

chmod u+x ~/downloads/collectd-cloudwatch-master/src/setup.py 
~/downloads/collectd-cloudwatch-master/src/setup.py 

jetzt wird das alles noch konfiguriert

/opt/aws/amazon-cloudwatch-agent/amazon-cloudwatch-agent-config-wizard
vi /etc/collectd/collectd.conf
/opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -c file:/opt/aws/amazon-cloudwatch-agent/bin/config.json -s

dann alles neu starten

systemctl restart amazon-cloudwatch-agent
systemctl restart collectd

es gibt im plugin cloudwatch-collectd zwei Dateien die jetzt steuern was bei cloudwatch ankommt und was nicht. In der Datei /opt/collectd-plugins/cloudwatch/config/blocked_metrics sind alle aktuell erkannten Metriken gelistet. Möchte man jetzt z.B. das der Speicher (memory) an cloudwatch reportet wird so muss dieser in der Datei whitelist.conf eingetragen werden. z.B. für Speicher (memory--.*) ob eure Werte ankommen oder nicht seht ihr nach einer Tasse Kaffee oder Tee hier in cloudwatch
die cloudwatch metriken liefern normalerweise

df-root-percent_bytes-used
memory--percent-used
swap--percent-used
cpu--percent-active

Das Ergebnis seht ihr hier :
für das debugen sollte dieses Log verwendert werden.

less /var/log/collectd.log

Quellen :
https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/install-CloudWatch-Agent-on-first-instance.html
https://github.com/awslabs/collectd-cloudwatch
https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-custom-metrics-collectd.html
https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/create-cloudwatch-agent-configuration-file-wizard.html

Kleines lokales Plugin für check_mk um die HAProxy Backends zu monitoren.

das Skript muss unter /usr/lib/check_mk_agent/local angelegt werden.

touch /usr/lib/check_mk_agent/local/haproxy-local.sh

Dort dann den nachfolgenden Code reinkopieren und Konfiguration anpassen.

#!/bin/bash
#
# checks haproxy
#

_awk_bin=$(which awk)
_status_url="http://localhost:9090/haproxy/"
_server_name="ha-cap-"
a=0

# $(curl -s ${_status_url}\;csv | grep "^${_server_name}" | grep -vE "(FRONTEND|BACKEND)")

for line in $(curl -s ${_status_url}\;csv | grep "^${_server_name}" | grep -vE "(FRONTEND|BACKEND)"); do
        _name=$(echo $line | ${_awk_bin} -F',' '{ print $1; }' )
        _host=$(echo $line | ${_awk_bin} -F',' '{ print $2; }' )
        _stat=$(echo $line | ${_awk_bin} -F',' '{ print $18; }')
        STATUSTXT="${_name}  ${_host}  ${_stat}"
        if [ ${_stat} == "UP" ]; then
                _check_response="0"
        else
                _check_response="2"
        fi
        if [ ${a} -lt 10 ]; then
                echo "${_check_response} BEHIND-HAPROXY-0${a} - ${STATUSTXT}"
        else
                echo "${_check_response} BEHIND-HAPROXY-${a} - ${STATUSTXT}"
        fi
        a=$((a+1))
done

Ergebnis sieht dann so aus

Natürlich muss auch der haproxy so konfiguriert sein das er die Statusseite ausliefert. Hier Auszug aus der haproxy.cfg

listen status
    bind *:9090
    mode http
    stats enable
    stats uri /haproxy
    acl localhost  src  127.0.0.1
    acl stats      path_beg  /haproxy
    http-request allow if stats localhost
    http-request deny  if stats !localhost