Die Cloud wird das schon machen

28 Feb 2017 Lesezeit: ~1 Minute

So zumindest erscheint es mir immer mehr und vor allem immer wieder. Das bewusstsein, dass es sich dabei nur um "somebody else computer" handelt scheint weitestgehend zu verschwinden. Umso lustiger ist es dann für mich, wenn man mit den ganzen Fehlerhaften annahmen aufräumen kann. das heißt dann auch, dass man mal bei einem Outtake schauen kann, was da so los ist.

Heute ist so ein Denkwürdiger Tag. Die Amazon S3 Cloud hat Schluckauf und die darin genutztne mehr als 143,000 Webseiten ebenso.

Amazon S3


Smart Status per SNMP Monitoren

4 Mär 2016 Lesezeit: 4 Minuten

Wer Server betreibt möchte in der Regel seine Ruhe haben (ausgenommen Windows Administratoren, die haben immer was zu tun). Damit das so ist, gilt es an einen Punkt zu kommen, an dem ein "Status Quo" erreicht ist. Diesen Status gilt es dann zu halten.

Nun kann man zu Fortuna beten oder sich ein Monitoring einrichten. Dienste und Co lassen sich in der Regel ziemlich einfach beobachten und dementsprechend prüfen. Bei der Hardware sieht es zumeist anders aus. Wer nun denkt das man aufwendige Agenten installieren muss und sonst welche Bemühungen zu betreiben hat, damit man an die Daten kommt liegt einfach falsch. Natürlich kann man mit einem Agenten eine ganze Menge machen. Wenn man das aber nicht will oder gar die gewünschte Funktion nicht gegeben ist, dann braucht man die Möglichkeit den ohnehin vorhandenen SNMP-Server um die gewünschten Werte zu erweitern.

In meinem Fall wollte ich wissen wie es den eingebauten Festplatten geht. Zunächst reicht mir erst einmal der HEALTH-Status des S.M.A.R.T. Will man mehr ist das aber auch kein großes Problem.

Wenn man seinen RAID-Controller ordentlich installiert hat, so kann man sich beliebige Ausgaben zusammenbauen. Zunächst einmal muss aber herausgefunden werden, was da so geht.

Ich wollte erst einmal wissen welche Festplatten an dem Controller hängen.

smartctl --scan
/dev/sda -d scsi # /dev/sda, SCSI device
/dev/bus/0 -d megaraid,8 # /dev/bus/0 [megaraid_disk_08], SCSI device
/dev/bus/0 -d megaraid,9 # /dev/bus/0 [megaraid_disk_09], SCSI device
/dev/bus/0 -d megaraid,10 # /dev/bus/0 [megaraid_disk_10], SCSI device
/dev/bus/0 -d megaraid,11 # /dev/bus/0 [megaraid_disk_11], SCSI device
/dev/bus/0 -d megaraid,14 # /dev/bus/0 [megaraid_disk_14], SCSI device
/dev/bus/0 -d megaraid,15 # /dev/bus/0 [megaraid_disk_15], SCSI device

Mit diesen Informationen schaue ich nun, wie es der jeweiligen festplatte geht:

smartctl -H /dev/sda -d megaraid,8 | grep -i health
SMART overall-health self-assessment test result: PASSED

Damit kann ich nun schon beginnen mein Monitoring aufzubauen. Dazu gebe ich in die /etc/snmp/snmpd.conf folgende Inhalte hinzu:

exec smart-sda1a /bin/sh -c "/usr/sbin/smartctl -H /dev/sda -d megaraid,8 | grep -i health

Nun gehe ich weiter zu meinem Icinga und erstelle zunächst einen Checkcommand:

define command {
  command_name snmpsmarthealth
  command_line /usr/lib/nagios/plugins/check_snmp -H $HOSTADDRESS$ -C public -o $ARG1$ -r $ARG2$
}

 In der jeweiligen Host-Konfiguration erstelle ich nun einen Service, welcher mir abbildet, was ich zu prüfen gedenke

define service {
  use snmp-service
  host_name SERVERNAME
  service_description HDD 1 Health
  check_command snmpsmarthealth!iso.3.6.1.4.1.2021.8.1.101.2!PASSED!
}

 

snmpsmarthealth Aufruf meines Checkcommands
! Trennzeichen
iso.3.6.1.4.1.2021.8.1.101.2 Jeweiliges Unterverzeichnis des SNMP Baums
PASSED Zu suchender Begriff

Das Ganze wiederhole ich nun für sämtliche lokal ausgeführten Kommandos des zu überwachenden Servers.

wie komme ich denn nun zu den komischen SNMP-Tailbäumen mit den merkwürdigen Zahlen? Im Zweifelsfall starte ich dazu einen Suchlauf mittels snmpwalk

snmpwalk -c public -v 2c SERVERNAME | grep -i BEGRIFF DEN ICH ERWARTE

 

Nun kann ich alles Monitoren, was ich will oder benötige. Ohne Agenten, ohne viele Plugins. Das Leben ist so einfach!

Seiten die mir geholfen haben:

http://www.bitbull.ch/wiki/index.php/Simple_way_to_read_SMART_status_from_harddisk_via_SNMP


Mit Ansible die Landschaft aktualisieren

2 Mär 2016 Lesezeit: 2 Minuten

Das Ansible für mich der logische nächste schritt nach der Shell ist, sobald es um die Verwaltung von Servern geht, habe ich vielleicht hier und da schon mal durchblicken lassen. Der Hintergrund ist einfach:

  • Es sollte ein Anliegen sein wiederkehrende Arbeitsschritte systematisch gleich durchzuführen
  • Es sollte ein Anliegen sein die zu erledigenden Aufgaben transparent zu halten
  • Es sollte ein Anliegen sein seine Arbeiten reproduzierbar auf andere Systeme anwenden zu können
  • Es macht einfach Spaß, wenn man sich nicht mehr mit dem quatsch der unterschiedlichen Systeme befassen zu müssen.

Mit Ansible Playbooks habe ich als Systemverwalter die Möglichkeit meine Schritte in einfacher Art und Weise (fast schon stenografisch) nieder zuschreiben und so einen Ablauf zu skizzieren, welche Arbeiten/Schritte/Rahmenbedingungen auf dem von mir zu verwaltenden System durchgeführt/vorhanden sein sollen.

Ansible selbst kümmert sich dann um die Abstraktion zum System hin, auf dem ich dann letztendlich die Skizze ausführe.

Wenn ich nun eine gewachsene Landschaft mit unterschiedlichen Linux-Distributionen habe, kann Ansible mir helfen diese aktuell zu halten. Das einfache Playbook dazu sieht wie folgt aus:

---
- hosts: all:!switche:!windows
 user: root
 gather_facts: true

 tasks:
 - name: apt update
 action: apt update_cache=yes
 when: ansible_distribution == "Ubuntu" or ansible_distribution == "Debian"

 - name: apt upgrade
 action: apt upgrade=dist force=yes
 when: ansible_distribution == "Ubuntu" or ansible_distribution == "Debian"

 - name: yum upgrade
 action: yum name=* state=latest
 when: ansible_distribution == "CentOS"

 - name: dnf upgrade
 action: yum name=* state=latest
 when: ansible_distribution == "Fedora"

Wenn ich dieses Playbook nun auf meine Landschaft loslasse:

ansible-playbook playbooks/linux-upgrade.yml

 spielt es keine Rolle mehr, ob die Eingesetzte Distribution ein Debian, Ubuntu, Fedora oder CentOS ist. Alle werden mit den eigenen Paketmanagern aktualisiert