Ein Problem zu dem es viele Lösungsansätze gibt, ist folgender PHP Fehler. Er tritt beispielsweise auf, beim Verbinden auf externe Anwendungen oder APIs:
php_network_getaddresses: getaddrinfo failed: No address associated with hostname
Im Netz kursieren Teilweise die wildesten Lösungsansätze. Da ich vor kurzem mit eben diesem Problem konfrontiert wurde, möchte ich meine Erfahrung mit euch teilen. In der “php.ini” gibt es einen Parameter, der diesen Fehler verursachen kann.
Dieser kann unterschiedlich gefüllt sein und ist per default leer.
disable_functions = pcntl_alarm,pcntl_fork,,pcntl_wait,pcntl_wifexited,pcntl_wifstopped,pcntl_wifsignaled,pcntl_wexitstatus,pcntl_wtermsig,,pcntl_signal,,pcntl_get_last_error,pcntl_strerror,pcntl_sigprocmask,pcntl_sigwaitinfo,,pcntl_exec,pcntl_getpriority,pcntl_setpriority
Um obigen Fehler zu beheben, kann es also reichen, sich diesen Parameter anzusehen und notfalls sogar komplett zu leeren.
NETWAYS Blog
Numeric datatypes as primary key in databases
Most likely primary keys in databases are numbers. But what happens, when an administrator uses the wrong numeric data type? In the worst case, databases can’t write down entries anymore.
For example, if an administrator wants to write customer information into the databases and wants to use the customerID itself as the primary key, then the numeric data type “TINYINT” would cause that only 255 entries can be written. But on the other hand the “BIGINT” numeric data type, could be too large for smaller databases.
So when you are setting up a database, you should think about how many entries will be written the next months/years and think about which datatype is the right one for your setup. Also you should think about if you should use the data types unsigned or not. This value will change the range of the datatypes.
| Typ | signed | unsigned | ||
|---|---|---|---|---|
| Min | Max | Min | Max | |
TINYINT |
-128 | +127 | 0 | 255 |
SMALLINT |
-32.768 | +32.767 | 0 | 65.535 |
MEDIUMINT |
-8.388.608 | +8.388.607 | 0 | 16.777.215 |
INT/INTEGER |
-2.147.483.647 | +2.147.483.646 | 0 | 4.294.967.295 |
BIGINT |
-263 | +263 – 1 | 0 | 264 – 1 |
Another example:
If an administrator wants to store 60000 customer information in the database, he should use at least a “SMALLINT”. Should he use the unsigned version or not? Lets have a look.
With the signed data type he has a range from -32.768 up to +32.767, but no customerID (primary key as mentioned above) has a negative number, so a “unsigned SMALLINT” would be necessary.
The case, that you thought about the questions above but your data type got out of range, could happen. There is a way to change the datatype and to increase the range in a simple way.
*ALTER TABLE tablename MODIFY column MEDIUMINT UNSIGNED;*
But remember: The larger your database is, the longer will it take to do such changes!
Clustershell und Foreman-API
Foreman bietet die Möglichkeit verschiedene Informationen über die Hosts einzusehen. Dazu gehören der Status, das Betriebssystem, Ressourcen etc. Möchte man nun, auf mehreren Hosts gleichzeitig ein Kommando absetzen, kann man sich auf jedem einzelnen einloggen oder eine Clustershell aufbauen.
Hierfür gibt es verschiedene Tools die dies erlauben. Eine Unbequemlichkeit die hier jedoch schnell aufkommt, ist das kopieren und einfügen der Hostnamen in die Commandline. Aus diesem Grund, habe ich etwas Zeit investiert und ein Ruby Script geschrieben, das es mir ermöglicht, mit festgelegten Filtern nach speziellen Listen von Hostnamen zu suchen und diese als eine einzige Ausgabe zu speichern. Ich habe für das erzeugen von Clustershells “csshX” im Einsatz, welches ich auch direkt mit eingebunden habe.
Das get_hosts Script gibt es als GIST.
In diesem Script wird zunächst eine “config.yml” geladen, in der die Foreman-URL und der Nutzername definiert sind. Eine Passwortabfrage erfolgt in diesem Script direkt auf der Commandline. Anschließend wird die Ausgabe der Foreman-API nach dem Auflisten aller Hostinformationen in JSON geparst und alle verfügbaren Parameter für die Hosts in das entsprechende Array gespeichert. Mit dem Parameter “-s / –server” gibt man einen String an, nachdem speziell gesucht werden soll. Diese Ausgabe wird zusätzlich mit angehängt.
Gefiltert wird nach:
1) Reports enabled
2) OS Ubuntu 14.04 / Debian 8
3) Kein Match auf net-* oder netways.de (Als Beispiel)
Von den selektierten Hosts werden die Hostnamen in einer Commandline-Ausgabe mit einem Leerzeichen getrennt ausgegeben. Verschiedene werden sich eventuell fragen: “Wofür brauche ich das? Wieso sollte ich so ein Script verwenden?”
Die Antwort ist einfach: Bequemlichkeit und live Übersicht, was gerade passiert. Die Suchparameter lassen sich sehr leicht anpassen und die Ausgabe des Scriptes wird etwas an Zeit der administrativen Aufgaben sparen, vorallem dann, wenn man mehr als nur 2 oder 3 Server mit Puppet bespielen lassen möchte.
user@computer ~/Documents/ruby/foreman $ ruby script.rb
Enter password:
[ ] Trying to establish a connection...
[OK] Password correct
[OK] Connection established
[ ] Collecting data...
[OK] Data collected
[RESULTS]
Ubuntu
csshX --login root test1.test.de test2.test.de test34.test.de test19.test.de mail.test.de icinga-001.test.de
Debian
csshX --login root icinga-002.test.de db-003.test.de db-021.test.de
Finished succesfully
Wie bereits erwähnt, ist hierfür noch eine “config.yml” Datei nötig, die gewünschte Parameter enthält. In diesem Fall die URL und den usernamen. Aber auch ein Gemfile, das sich in Ruby um bestimmte Versionen von Gems kümmert. (Mit einem “bundle install” können diese installiert werden)
Die config.yml und das Gemfile gibt es ebenfalls als GIST.
Eingebaute “rescue Execptions” im Script selbst, geben entsprechende Rückmeldung, sollte der Login oder eine der auszuführenden Verarbeitungsschritte fehlschlagen und brechen den Vorgang an dieser Stelle ab.
"Multiline" mit Filebeat
simpl
Das analysieren von Logs mit dem ELK-Stack ist an sich relativ simpel. Ein Problem auf das man hierbei stoßen kann, sind jedoch Logeinträge aus mehreren Zeilen bestehen (“Multiline”). Das Problem hierbei ist, das Logstash jede dieser Zeilen als einzelne Events versteht und verarbeitet, wodurch das Kibana sehr schnell unübersichtlich werden kann.
Wenn man hierzu etwas recherchiert, kommt man sehr schnell auf eine “Lösung” die wie folgt aussieht:
filter {
multiline {
type => "type"
pattern => "regexpattern"
negate => boolean
what => "previous" or "next"
}
}
Mit dieser Methode, wird am Logstash ein Filter angelegt, der “multiline” erkennt und diese anhand von Regexpattern zusammenfügt. Erfahrungsgemäß funktioniert dies jedoch nicht immer wie gewünscht. Eine wesentlich bessere Methode ist meiner Meinung nach, direkt am Client anzusetzen, der die Logs verschickt. Hierzu kann ich den Einsatz von Filebeat empfehlen.
Die Installation ist sehr simpel:
curl -L -O https://download.elastic.co/beats/filebeat/filebeat_1.3.1_amd64.deb
sudo dpkg -i filebeat_1.3.1_amd64.deb
Alternativ, kann man natürlich auch die Apt-Source mit dem entsprechenden Key lokal hinzufügen und mit dem Paketmanager arbeiten. Nach der Installation steht die Konfiguration aus. Die dafür zuständige Datei ist “/etc/filebeat/filebeat.yml”. Die ist zwar dank vielen Kommentaren sehr lang, doch das wesentliche sieht in einem Beispiel wie folgt aus:
filebeat:
prospectors:
-
paths:
- /var/log/my_multiline_1/*
input_type: log
multiline:
pattern: ^[a-zA-Zä]{3}\ [0-9]{2}\,\ [0-9]{4}
negate: true
match: after
######
-
paths:
- /var/log/my_multiline_2/*
input_type: log
multiline:
pattern: ^[a-zA-Zä]{3}\ [0-9]{2}\,\ [0-9]{4}
negate: true
match: after
######
registry_file: /var/lib/filebeat/registry
######
output:
logstash:
hosts: ["$IP_OF_LOGSTASH:$INPUT_PORT"]
######
logging:
files:
rotateeverybytes: 10485760 # = 10MB
Hierbei werden für verschiedene Logs verschiedene “Prospectors” konfiguriert. Hierzu sind lediglich Informationen über den “input_type”, den Regexpattern nötig und eine Art und Weise wie Logs zusammengefügt werden sollen nötig. In diesem Beispiel würden alle Zeilen, auf die der Regexpattern nicht zutrifft, an die Zeile angefügt, auf die der Regexpattern zutrifft. Mit jeder Änderung am Filebeat, muss der dienst neu gestartet werden.
Damit Logstash aber auch zusätzlich Daten von der neuen Quelle “Filebeat” annimmt und verarbeitet, muss ein neuer “Input” und “Output” definiert werden.
input {
beats {
port => $INPUT_PORT
}
}
output {
redis {
data_type => "list"
key => "logstash"
}
}
Auch hier muss der Logstash natürlich neu gestartet werden. Anschließend können die zusammengefügten Logeinträge im Kibana unter die Lupe genommen werden und im Logstash weiter zerlegt werden.
Icinga2 API und BitBar auf MacOs
Wir wollen APIs, warum? Weil sie schnell, einfach zu integrieren und zu bedienen sind. Nun hat Icinga2 eine API und es entstehen ganz viele Möglichkeiten diese zu nutzen. Wir bauen uns Dashboards mit Dashing oder zeigen den Status von Hosts in Foreman an.
Ich bin letztens über ein Tool BitBar gestolpert, dieses Tool kann mit einfachen Skripten die eigene “Mac OS X menu bar” erweitern. Hierfür braucht es nur die richtige Formatierung der Ausgabe und BitBar generiert ein weiteres Dropdown Menu.
Ich hab mir die Icinga2 API zu nutze gemacht und eine kleine Erweiterung gebaut um mir den Status von Icinga2 in meiner Menubar anzuzeigen.
Im Menu wird dann der globale Status entweder in grün oder rot, abhängig davon ob Hosts “down” und “unhandled” sind, angezeigt.
Der Aufruf dafür kann der Adresszeile im Browser entnommen werden.
/icingaweb2/monitoring/list/hosts?host_state=1&sort=host_severity&host_unhandled=1
Wenn wir am Ende dann ein “&format=json” an die URL hängen, haben wir ein gängiges Format um das Ergebnis in jeglichen Applikationen zu verwenden.
[{"host_icon_image":"","host_icon_image_alt":"","host_name":"web01","host_display_name":"web01","host_state":"1","host_acknowledged":"0","host_output":"DOWN","host_attempt":"1\/3","host_in_downtime":"0","host_is_flapping":"0","host_state_type":"1","host_handled":"0","host_last_state_change":"1474556541","host_notifications_enabled":"1","host_active_checks_enabled":"0","host_passive_checks_enabled":"1"},
Mehr dazu gibts auf Github unter icinga2_api_examples oder natürlich in der Icinga2 Dokumentation.
Thilo Wening
Manager Consulting
Thilo hat bei NETWAYS mit der Ausbildung zum Fachinformatiker, Schwerpunkt Systemadministration begonnen und unterstützt nun nach erfolgreich bestandener Prüfung tatkräftig die Kollegen im Consulting. In seiner Freizeit ist er athletisch in der Senkrechten unterwegs und stählt seine Muskeln beim Bouldern. Als richtiger Profi macht er das natürlich am liebsten in der Natur und geht nur noch in Ausnahmefällen in die Kletterhalle.
