AWS : Cloudwatch Agent & collectd

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.
IAM UserIAM Role

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

attach iam role
attach iam role to instance

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 AWS Collectd Metriken
die cloudwatch metriken liefern normalerweise
df-root-percent_bytes-used
memory--percent-used
swap--percent-used
cpu--percent-active
Das Ergebnis seht ihr hier :AWS_MEMORY Cloudwatch collectd
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

Check_MK monitoren der haproxy Backends

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
check_mk + haproxy
check_mk + haproxy

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

Check_MK Agent über SSH Verbindung

Wenn man das Check_MK Monitoring nicht über den Standardport (xinet) laufen lassen möchte / kann besteht dich Möglichkeit dies über eine SSH Verbindung zu realisieren. Hierfür muss nur einiges an Vorarbeit erledigt werden.

Auf jedem Host der zu monitoren ist legt man einen User für den Check_Mk Agents an.
useradd -d /home/monitor -c 'CHECK_MK User' -g monitor -m -s /bin/bash monitor
Auf dem Monitoring-Server einen SSH Key für das monitoring erstellen. Dazu logt ihr euch über ssh auf dem Server ein und wechselt mit su - sitename auf die Check_MK Site (User). Dort legt ihr ein SSH-Keypair an.
ssh-keygen -t monitor
dann zeigt ihr euch den schlüssel über cat an und pflegt diesen auf den zu monitorenden Hostsystemen unter dem User monitor ein ( /home/monitor/.ssh/authorized_keys )
cat ~/.ssh/id_monitor.pub
Eintrag auf den Hostsystemen :
command="sudo /usr/bin/check_mk_agent" ssh-rsa [SSH KEY DES SERVERS]
Jetzt muss noch die sudoers Config angepasst werden.
vi /etc/sudoers
Dort fügt man die folgenden Zeilen ein, trägt man den User monitor ein
# Allow User monitor to run check_mk_agent
monitor ALL=NOPASSWD: /usr/bin/check_mk_agent
Jetzt kann man das bis jetzt mal testen.Wenn ihr euch über ssh auf dem Host als User monitor anmeldet, oder den check_mk_agent lokal auf dem Host als User monitor ausführt, muss der selbe output zu sehen sein.

Ist das der Fall muss jetzt noch in der WATO eine Regel erstellt werden.
Unter Host & Service ParametersDatasource ProgramsIndividual program call instead of agent access eine Regel für die Umgebung erstellen
	ssh -i ~/.ssh/id_rsa -o StrictHostKeyChecking=no monitor@$HOSTADDRESS$
dann sollten nach einem TabulaRasa alle Services zu sehen sein.
check_mk_agent über ssh
check_mk_agent über ssh


Mehr Info : Check_MK - Anleitung zu diesem Thema

InfluxDB - Aufbewahrung der Daten managen

Wenn eine Datenbank in Influx erstellt wird gibt es eine default RETENTION POLICY (Aufbewahrungsrichtlinie) mit den Namen "autogen" die DURATION ist dort auf Unendlich und die shardGroupDuration auf 7 Tage konfiguriert . Dies kann man auch bei der Erstellung einer Datenbank mitgeben (allerdings darf man das nicht vergessen ;-)) DATABASE MANAGMENT
>SHOW RETENTION POLICIES
name              duration  shardGroupDuration replicaN default
----              --------  ------------------ -------- -------
autogen           0s        168h0m0s           1        true
lässt man eine größere Umgebung mit diesen default Werten monitoren ist die Datenbank recht schnell voll und wächst und wächst .......

Um realistische Aufbewahrungsfristen zu realisieren kann man eine neue Policy schreiben, es kommt natürlich immer auf den jeweiligen Anwendungsfall an !
CREATE RETENTION POLICY "twelve_weeks_only" ON "collectd" DURATION 12w SHARD DURATION 1d DEFAULT
nun sieht die Retention Policy schon anders aus
>SHOW RETENTION POLICIES
name              duration  shardGroupDuration replicaN default
----              --------  ------------------ -------- -------
autogen           0s        168h0m0s           1        false
twelve_weeks_only 2016h0m0s 24h0m0s            2        true
die Werte müssen natürlich je nach Anwendungsfall angepasst werden.

Zur Erklärung :

Erstellt eine neue RETENTION POLICY in der Datenbank collectd mit den Namen twelve_weeks_only
CREATE RETENTION POLICY "twelve_weeks_only" ON "collectd"
Die Aufbewahrungsfrist der Daten beträgt hier 12 Wochen -> Duration units
DURATION 12w
In einer einzelnen Shard-Group können mehrere Shards vorhanden sein. Jeder Shard enthält eine bestimmte Reihe von Serien. Alle Punkte, die auf eine bestimmte Serie in einer bestimmten Shard-Gruppe fallen, werden im selben Shard (TSM-Datei) auf der Festplatte gespeichert.(auszug InfluxDB Doku)
SHARD / SHARD Groups / SHARD Duration
SHARD DURATION 1d
Setzt die neue Policy als DEFAULT für die Datenbank collectd
DEFAULT
Um mir wieder Platz zu schaffen habe ich danach die Policy "autogen" aus der InfluxDB gelöscht
DROP RETENTION POLICY "autogen" ON "collectd"

Nach der Erstellung der neuen RETENTION POLICY begann die Aufzeichnung der Messwerte wieder bei Null, sollte das nicht gewünscht werden kann man auch die RETENTION POLICY ändern. Der Weg ist aber ungetestet !!
ALTER RETENTION POLICY "autogen" ON "collectd" DURATION 12w SHARD DURATION 7d DEFAULT

Debian 9 : Grafana Dashboard bauen

Das erste Dashboard in Grafana ist schnell gebaut, ich zeig das hier mal exemplarisch für Load/Ram in einem Graph.

So soll unser Ziel dann aussehen
Grafana Dashboard load und ram

Dazu klicken wir erstmal auf "New Dashboard" um dann dem panel einen Graph hinzu zufügen.
Graph in Grafana

Unter Metrics stellt ihr folgende Konfiguration ein. Ich hab hier nur A und D expandiert die anderen Konfigurationen könnt ihr daraus entnehmen.
Metrics konfigurieren

Dann die Achsen konfigurieren
Grafana Graph - Axes


Jetzt die Darstellung unter Display konfigurieren
Grafana Display
Grafana Display 1

Jetzt schließen wir das mit dem kleinen x und der Graph sollte so wie unser Ziel aussehen.

Hier noch ein Beispiel für einen Netzwerkgraph.

Grafana Netwerk
Grafana Netwerk 1
“Sicher ist, dass nichts sicher ist. Selbst das nicht.”
Joachim Ringelnatz