Debian 9 : Installation - InfluxDB / Grafana und collectd

Eine kleiner Monitoring Umgebung mit InfluxDB / Grafana und collectd aufzubauen ist recht einfach. Man benötigt dazu eine Datenbank und ein Werkzeug das die Daten anzeigt, Grafana ist hier ganz schick.

Meiner Meinung nach ist Grafana nur dazu geeignet Metriken der laufenden Systeme anzuzeigen. Wer ein funktionales (notifications/business intelligence/usw...) Monitoring benötigt ist bei check_mk besser aufgehoben.
Ich möchte hier aber nur die Metriken anzeigen damit unsere Kunden einen Überblick über die Systeme haben.

Das Beispiel hier ist auf Debian 9 entstanden. Für mich haben sich folgende Pakete für das tägliche arbeiten bewährt.
Zu allererst werden wir root um die Packete zu installieren.
su - root
apt install ccze htop vim mc wget curl w3m screen net-tools -y
dann installieren wir collectd, dieser sammelt die Informationen auf dem System ein und schreibt diese in die InfluxDB, das kann mit dem Befehl
apt install collectd
erledigt werden. Keinen Schreck bekommen das bringt einiges an Abhängigkeiten mit. Bei mir waren das ca. 280MB
Jetzt muß man collectd natürlich konfigurieren.
vi /etc/collectd/collectd.conf
Hier ist jetzt natürlich nur eine kleine Grundkonfiguration es gibt einige collectd-plugins die man aktivieren kann.
Hier meine kleine Beispielkonfiguration :
FQDNLookup  true
BaseDir     "/var/lib/collectd"
PIDFile     "/var/run/collectd.pid"
PluginDir   "/usr/lib/collectd"
TypesDB     "/usr/share/collectd/types.db"
LoadPlugin  syslog
LoadPlugin cpu
LoadPlugin df
LoadPlugin  interface
LoadPlugin  load
LoadPlugin memory
LoadPlugin  network

<Plugin cpu>
        ReportByCpu true
        ReportByState true
        ValuesPercentage false
</Plugin>

<Plugin df>
#       Device "/dev/sda1"
#       Device "192.168.0.2:/mnt/nfs"
#       MountPoint "/home"
#       FSType "ext3"

        # ignore rootfs; else, the root file-system would appear twice, causing
        # one of the updates to fail and spam the log
        FSType rootfs
        # ignore the usual virtual / temporary file-systems
        FSType sysfs
        FSType proc
        FSType devtmpfs
        FSType devpts
        FSType tmpfs
        FSType fusectl
        FSType cgroup
        IgnoreSelected true

#       ReportByDevice false
#       ReportInodes false

#       ValuesAbsolute true
#       ValuesPercentage false
</Plugin>

<Plugin interface>
        Interface "enp0s3"
        # hier muss natürlich der Interface Name 
        # eurer Netzwerkkarte rein
        IgnoreSelected false
        ReportInactive true
        UniqueName false
</Plugin>

<Plugin load>
        ReportRelative true
</Plugin>

<Plugin memory>
        ValuesAbsolute true
        ValuesPercentage false
</Plugin>

<Plugin load>
    ReportRelative true
</Plugin>

<Plugin network>
    Server "192.168.2.180" "25251"
    # um die Konfiguration dann auf alle Server 
    # im Netz kopieren zu können gebe ich 
    # hier immer die wirklich IP an
</Plugin>
jetzt stellen wir sicher das collectd aktiviert ist und starten es neu
systemctl enable collectd.service
systemctl restart collectd.service

Jetzt laden wir das Paket für die InfluxDB herunter und installieren es.
wget https://dl.influxdata.com/influxdb/releases/influxdb_1.4.3_amd64.deb && dpkg -i influxdb_1.4.3_amd64.deb
Install InfluxDB
Install InfluxDB

Jetzt kommt die Konfiguration
vi /etc/influxdb/influxdb.conf
jetzt passen wir die Werte für den collectd deamon an. Hier wieder meine Beispiel Konfiguration , sucht den Bereich collectd und setzt diese Werte
[[collectd]]
   enabled = true
   bind-address = ":25251"
   database = "collectd"
  # retention-policy = ""
  #
  # The collectd service supports either scanning a directory for multiple types
  # db files, or specifying a single db file.
   typesdb = "/usr/share/collectd/types.db"
dann stellen wir wieder sicher das influxdb automatisch startet und machen einen neustart
systemctl enable influxdb.service
systemctl restart influxdb
Jetzt kann man schonmal testen ob Daten rein kommen.
Influx DB
Influx DB

Wenn es so aussieht bei euch wie auf meinem Screenshot ist alles richtig.

Jetzt fehlt nur noch Grafana das installieren wir mir dem Befehl :
wget https://s3-us-west-2.amazonaws.com/grafana-releases/release/grafana_4.6.3_amd64.deb && dpkg -i grafana_4.6.3_amd64.deb
dann stellen wir wieder sicher das grafana automatisch startet.
systemctl enable grafana-server.service
systemctl start grafana-server.service
Grafana systemctl
Jetzt können wir uns in Grafana anmelden (admin/admin) dazu öffnen wir die Adresse im webbrowser http://192.168.2.180:3000.
Direkt nach dem anmelden klicken wir auf add datasource grafana und fügen unsere Datenquelle hinzu. Die Einstellungen entnehmt bitte dem Screenshot.data source influxdb
Hier mal zur Erinnerung diese Anleitung dient nur zum spielen in einer produktiven Umgebung muss natürlich mehr Wert auf Sicherheit genommen werden

Jetzt könnt ihr loslegen und euer erstes Dashboard zusammen bauen. Das mach ich in einem anderen Artikel.

AWS : Remote IP hinter Application Loadbalancer

Problem : Man benötigt bei einem Webserver hinter einem AWS Application Loadbalancer die RemoteIP des Clients. Das Vorgehen ist eigentlich für alle LBs gültig.

Lösung : Ich verwende hier Debian auf anderen Distries sollte es ähnlich sein.
Es wird das Modul remoteip_module benötigt.
a2enmod remoteip
Dann legt man eine neue config an und aktiviert diese.
vi /etc/apache2/conf-available/loadbalancer_remoteip.conf
dort diesen Inhalt einfügen
# Settings for mod_remoteip:
# the Header X-Forwarded-For comes from AWS Application Loadbalancer
RemoteIPHeader X-Forwarded-For
RemoteIPInternalProxy xxx.xxx.xxx.xxx # 1.Loadbalancer IP Intern
RemoteIPInternalProxy xxx.xxx.xxx.xxx # 2.Loadbalancer IP Intern usw.
# dont log healthy checks
SetEnvIf User-Agent ELB-HealthChecker nolog
die config aktiviert man mit
a2enconf loadbalancer_remoteip
dann anpassen der apache2.conf
# mod_remoteip LogFormat
LogFormat "%a %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" combined
in der VHost der Website dann das CustomLog anpassen bzw. eintragen
CustomLog "/var/log/apache2/site/access.log" combined env=!nolog
jetzt kann man mal testen ob die config so läuft
apache2ctl configtest
der output sollte lauten
root@xxx.xxx.xxx.xxx:/> apache2ctl configtest
Syntax OK
dann den Apache neu starten und überprüfen ob alles so läuft wie es soll
systemctl restart apache2
less +F -S /var/log/apache2/site/access.log

Bash : SSH Skript mit eigener known_hosts

Problem : Wir arbeiten hier auf einem Server mit mehreren Usern, es kommt immer wieder vor das jemand die known_hosts überschreibt. Den Schuldigen haben wir noch nicht gefunden ;-) Also verwenden wir jetzt in unseren Skripts eigene known_hosts files.

Lösung :
Ich habe mir angewöhnt im Skript Ordner einen Ordner ssh anzulegen in dem dann die known_hosts liegt.
Somit bin ich unabhängig von anderen.
Setzen einer Variable im Skript
SSH_KNOWN_HOST="-o ConnectTimeout=30 -o UserKnownHostsFile=$(dirname $(readlink -f ${0}))/ssh/known_hosts"
Im Skript selbst kann man das so verwenden.
ssh ${SSH_KNOWN_HOST} USER@HOSTNAME
Da sftp und ssh die selben Parameter kennen kann man diese Variable beim Aufruf von ssh und sftp verwenden.

ntop : Eigene Anwendung zu Port zuordnen

Erstmal was ist ntop eigentlich.
ntop (network top) ist eine quelloffene und freie Software, mit der Netzwerkverkehr mitgeschnitten und analysiert werden kann.
Quelle : https://de.wikipedia.org/wiki/Ntop

Diese Software kann schön genutzt werden um z.B. auf einem Gateway oder einer Firewall zu monitoren wo der Traffic so hin läuft. Es werden schon ein ganzer Pack Plugins mitgeliefert aber eigene Anwendungen werden nicht erkannt. Ich habe hier eine kleine Anwendung geschrieben die über udp Port 5404 Daten versendet. Jetzt möchte ich natürlich das auch in meinem Gateway angezeigt bekommen um zu beurteilen wieviel Traffic darüber läuft. Das kann man relativ einfach realisieren jedoch hat es mir auch etwas Arbeit gekostet diesen einfachen Weg zu finden ;-)

Erstellt eine Datei in der später die Protokolle hinzugefügt werden.
touch /usr/share/ntopng/httpdocs/protocol-app.txt
Jetzt füge ich meine Anwendung hinzu, das diese auch im Webfrontend nicht mehr unter UNKNOWN läuft.
echo "udp:5404 @MyApp" > /usr/share/ntopng/httpdocs/protocol-app.txt 
dann müssen wir noch dafür sorgen das diese Datei auch beim Start von ntopng gelesen wird dazu editieren wir das configfile unter /etc/ntopng mit dem Befehl.
echo "-p /usr/share/ntopng/httpdocs/protocol-app.txt" >> /etc/ntopng/ntopng.conf
Dann starten wir den Server neu mit dem Befehl
service ntopng restart
Wenn dann bei den Protokollen MyApp steht wurde alles richtig gemacht ;-) ntop beispiel

Mehr Infos :
http://www.ntop.org/ndpi/configuring-ndpi-for-custom-protocol-detection/

AWS : Mount eines S3 Buckets unter Debian

Installation des benötigten Packetes auf der Debian Kiste.
apt install s3fs
Erstellen einer Passwort Datei im Home Directory
touch ~/.passwd-s3fs
echo "accessKeyId:secretAccessKey" > ~/.passwd-s3fs
Wenn mehrere Amazon S3 Buckets verwendet werden müssen kann auch der Name des Buckets vor den Zugangsdaten hinzugefügt werden.
echo "bucketName:accessKeyId:secretAccessKey" > ~/.passwd-s3fs
Da hier sensible Zugangsdaten in der Datei stehen müssen die Rechte auf 600 geändert werden !
chmod 600 ~/.passwd-s3fs
Wenn alles richtig ist kann das Amazon S3 Buckets gemountet werden
s3fs [BUCKET-NAME] [MOUNT-POINT]
Der Eintrag für /etc/fstab sieht dann so aus, hier ist debug noch aktiv. Das sollte für einen Betrieb in der Produktion deaktiviert werden.
# MOUNT S3 MIT DEBUG
[BUCKET-NAME] [MOUNTPOINT] fuse.s3fs _netdev,allow_other,dbglevel=dbg,curldbg 0 0
# MOUNT S3 OHNE DEBUG
[BUCKET-NAME] [MOUNTPOINT] fuse.s3fs _netdev,allow_other 0 0

Quellen :
https://cloud.netapp.com/blog/amazon-s3-as-a-file-system
https://github.com/s3fs-fuse/s3fs-fuse/wiki/Fuse-Over-Amazon
“Das einzig sichere System müsste ausgeschaltet, in einem versiegelten und von Stahlbeton ummantelten Raum und von bewaffneten Schutztruppen umstellt sein.”
Gene Spafford (Sicherheitsexperte)