Hope This Helps

Problem : Eine Java Anwendung wirft nach einiger Zeit die Fehlermeldung "to much Files open". Grund hierfür ist das die Ulimits in Debian 9 nach unten korrigiert wurden.

Lösung : Vielleicht gibts einfachere Lösungen bei mir hat dieser Weg dazu geführt das die Anwendung stabil läuft.

In der Datei /etc/security/limits.conf habe ich die Limits auf die folgenden Werte gesetzt.

# nofile - max number of open files
*               hard    nofile          65536
*               soft    nofile          32768
root            soft    nofile          65536
 
# sigpending - max number of pending signals
*               hard    sigpending      516378
*               soft    sigpending      258189
root            soft    sigpending      516378
 
# nproc - max number of processes
*               hard    nproc           516378
*               soft    nproc           258189
root            soft    nproc           516378

Die Hardlimits sind die Default Werte aus Debian 8 , mit den Soft Limits muss man noch etwas "spielen".
Damit diese auch wirklich ausgewertet werden muss noch in der Datei /etc/pam.d/common-session & /etc/pam.d/common-session-noninteractive das pam_limit.so Modul includiert werden.

# include pam_limits.so
session required    pam_limits.so

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


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


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


Dann die Achsen konfigurieren



Jetzt die Darstellung unter Display konfigurieren



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.

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

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.
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

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 und fügen unsere Datenquelle hinzu. Die Einstellungen entnehmt bitte dem Screenshot.

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

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

Überprüfen ob ein Remote File vorhanden ist oder nicht.

if ssh USER@HOST "test -e DATEI_INCL_PFAD"; then
    echo "remote file ist DATEI_INCL_PFAD vorhanden"
else
    echo "remote file DATEI_INCL_PFAD ist NICHT vorhanden"
fi

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.