Posts Tagged ‘ELK’

Freitag, 12. Februar 2021

Mit apt-get auf eine bestimmte Paket-Version downgraden

Link zu diesem Artikel

Gestern habe ich ohne lange zu Überlegen Kibana auf meinem ELK-Server gelüpft. Schlechte Idee:

{"type":"log","@timestamp":"2021-02-11T23:20:13+01:00","tags":["error","savedobjects-service"],"pid":501,"message":"This version of Kibana (v7.11.0) is incompatible with the following Elasticsearch nodes in your cluster: v7.10.0 @ 10.1.2.3:9200 (10.1.2.3)"}

Abbruch, zurückbuchstabieren — aber wie?

Zuerst überprüft man, was die letzte funktionierende vorherige Version war:

$ apt-cache madison kibana
    kibana |     7.11.0 | https://artifacts.elastic.co/packages/7.x/apt stable/main amd64 Packages
    kibana |     7.10.2 | https://artifacts.elastic.co/packages/7.x/apt stable/main amd64 Packages
    kibana |     7.10.1 | https://artifacts.elastic.co/packages/7.x/apt stable/main amd64 Packages
    kibana |     7.10.0 | https://artifacts.elastic.co/packages/7.x/apt stable/main amd64 Packages
    kibana |      7.9.3 | https://artifacts.elastic.co/packages/7.x/apt stable/main amd64 Packages
    kibana |      7.9.2 | https://artifacts.elastic.co/packages/7.x/apt stable/main amd64 Packages
    kibana |      7.9.1 | https://artifacts.elastic.co/packages/7.x/apt stable/main amd64 Packages
    kibana |      7.9.0 | https://artifacts.elastic.co/packages/7.x/apt stable/main amd64 Packages
    kibana |      7.8.1 | https://artifacts.elastic.co/packages/7.x/apt stable/main amd64 Packages
    kibana |      7.8.0 | https://artifacts.elastic.co/packages/7.x/apt stable/main amd64 Packages
    kibana |      7.7.1 | https://artifacts.elastic.co/packages/7.x/apt stable/main amd64 Packages
    kibana |      7.7.0 | https://artifacts.elastic.co/packages/7.x/apt stable/main amd64 Packages
    kibana |      7.6.2 | https://artifacts.elastic.co/packages/7.x/apt stable/main amd64 Packages
    kibana |      7.6.1 | https://artifacts.elastic.co/packages/7.x/apt stable/main amd64 Packages
    kibana |      7.6.0 | https://artifacts.elastic.co/packages/7.x/apt stable/main amd64 Packages
    kibana |      7.5.2 | https://artifacts.elastic.co/packages/7.x/apt stable/main amd64 Packages
    kibana |      7.5.1 | https://artifacts.elastic.co/packages/7.x/apt stable/main amd64 Packages
    kibana |      7.5.0 | https://artifacts.elastic.co/packages/7.x/apt stable/main amd64 Packages
    kibana |      7.4.2 | https://artifacts.elastic.co/packages/7.x/apt stable/main amd64 Packages
    kibana |      7.4.1 | https://artifacts.elastic.co/packages/7.x/apt stable/main amd64 Packages
    kibana |      7.4.0 | https://artifacts.elastic.co/packages/7.x/apt stable/main amd64 Packages
    kibana |      7.3.2 | https://artifacts.elastic.co/packages/7.x/apt stable/main amd64 Packages
    kibana |      7.3.1 | https://artifacts.elastic.co/packages/7.x/apt stable/main amd64 Packages
    kibana |      7.3.0 | https://artifacts.elastic.co/packages/7.x/apt stable/main amd64 Packages
    kibana |      7.2.1 | https://artifacts.elastic.co/packages/7.x/apt stable/main amd64 Packages
    kibana |      7.2.0 | https://artifacts.elastic.co/packages/7.x/apt stable/main amd64 Packages
    kibana |      7.1.1 | https://artifacts.elastic.co/packages/7.x/apt stable/main amd64 Packages
    kibana |      7.1.0 | https://artifacts.elastic.co/packages/7.x/apt stable/main amd64 Packages
    kibana |      7.0.1 | https://artifacts.elastic.co/packages/7.x/apt stable/main amd64 Packages
    kibana |      7.0.0 | https://artifacts.elastic.co/packages/7.x/apt stable/main amd64 Packages

Somit muss ich versuchen, 7.10.2 über 7.11.0 zu installieren. Doch wie macht man das?

# apt-get install kibana=7.10.2

Und damit beim nächsten Lauf Kibana 7.11.0 nicht erneut installiert wird, benötigt man noch einen Eintrag in /etc/apt/preferences:

...
Package: kibana
Pin: version 7.10.2
Pin-Priority: 1001

Tags: , , , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 9. September 2018

Zwischenstand abfragen bei „Elasticsearch is still initializing the kibana index“

Link zu diesem Artikel

In meinem Netzwerk läuft eine ElasticSearch-, Lucene- und Kibana- oder kurz ELK-Komponente, an welche alle Geräte im Netzwerk per syslog ihre Log-Events zusenden. Gelegentlich muss ich den ELK-Docker-Container herunter- und wieder hochfahren. Da ich ELK auf einem Laptop laufen lassen und die CPU-Frequenz des Geräts auf den tiefstmöglichen Wert für diese CPU festgelegt habe (1200 MHz; Überhitzung führte vorher zu unregelmässigen Abstürzen), kann es manchmal eine Weile dauern, bis ELK nach einem solchen Neustart wieder hochkommt. Doch bis es soweit ist, strahlt einem dieses Kibana Status-Fenster entgegen:

Wenn man sich dafür interessiert, wie weit der Kibana-Index bereits wiederhergestellt ist, ruft folgende URL auf:

http://1.2.3.4:9200/_cluster/health?pretty=true

Im Browser sieht man dort dann nützliche Informationen über den Cluster, und für unseren Fall ganz wichtig, das Attribut active_shards_percent_as_number:

{
  "cluster_name" : "elasticsearch",
  "status" : "red",
  "timed_out" : false,
  "number_of_nodes" : 1,
  "number_of_data_nodes" : 1,
  "active_primary_shards" : 1753,
  "active_shards" : 1753,
  "relocating_shards" : 0,
  "initializing_shards" : 4,
  "unassigned_shards" : 4035,
  "delayed_unassigned_shards" : 0,
  "number_of_pending_tasks" : 10,
  "number_of_in_flight_fetch" : 0,
  "task_max_waiting_in_queue_millis" : 807617,
  "active_shards_percent_as_number" : 30.265883977900554
}

Im Browser kann man nun regelmässig diese Seite neu laden und sollte sehen, wie active_shards_percent_as_number kontinuierlich nach oben zählt. Sobald 100 Prozent erreicht sind, läuft der Cluster wieder wie erwartet.

Wer nur eine Kommandozeile zur Verfügung hat, hilft sich folgendermassen:

$ watch -n 1 curl -XGET 'http://1.2.3.4:9200/_cluster/health?pretty=true'

Quelle: Monitor ElasticSearch cluster health – Useful for keeping an eye on ES when rebalancing takes place

Tags: , , , , , ,
Labels: IT, Linux

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 19. Februar 2017

ELK: Race Condition mit resolv.conf und WiFi

Link zu diesem Artikel

Seit einer Woche läuft auf einem Laptop bei mir zu Hause der ELK-Stack und sammelt per Syslog die Logs aller meiner Devices an drei Standorten. In unregelmässigen Abständen werde ich hier über Erkenntnisse berichten, die ich dank der zentralisierten Analyse der Logs gemacht habe.

Dank ELK fand ich auf Grund von postfix Log-Meldungen bald einmal heraus, dass mein Raspberry Pi 3, welcher ein Dashboard in unserer Wohnung antreibt, keine E-Mails versenden kann. postfix konnte den Hostnamen meines Mail-Providers nicht auflösen:

DASHBOARD postfix/error[1234]: ABCDEF: to=<log@domain.tld>, orig_to=<root@dashboard>, relay=none, delay=40662, delays=40584/78/0/0.27, dsn=4.4.3, status=deferred (delivery temporarily suspended: Host or domain name not found. Name service error for name=server41.cyon.ch type=A: Host not found, try again)

Nach einer längeren Debugging-Session dann die Erkenntnis:

The problem is that Postfix checks /etc/resolv.conf before the WiFi is connected. Therefore, /var/spool/etc/postfix/resolv.conf stays empty after the boot and mails cannot be sent.

Quelle: Postfix error: Host or domain name not found

Genau das war das Problem. Während der Kommentator auf Superuser empfiehlt, postfix erst nach der erfolgreichen WiFi-Verbindung zu starten, löste ich das Problem anderweitig, indem ich einen Cron-Job einrichtete:

...
*/1 * * * *	root	cp /etc/resolv.conf /var/spool/postfix/etc/resolv.conf
...

Sicherlich nicht sexy, aber es löst das Problem (und schafft eventuell einige andere).

Tags: , , , , , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 19. Februar 2017

ELK: snmpd: Cannot statfs

Link zu diesem Artikel

Seit einer Woche läuft auf einem Laptop bei mir zu Hause der ELK-Stack und sammelt per Syslog die Logs aller meiner Devices an drei Standorten. In unregelmässigen Abständen werde ich hier über Erkenntnisse berichten, die ich dank der zentralisierten Analyse der Logs gemacht habe.

Heute geht es um snmpd und Mounts, deren Attribute der Daemon nicht auslesen kann. Dies äussert sich auf ELK mit folgenden Log-Meldungen:

... snmpd[1234] Cannot statfs /var/lib/docker/containers/: Permission denied ...
... snmpd[1234] Cannot statfs /var/lib/docker/aufs/mnt/: Permission denied ...
... snmpd[1234] Cannot statfs /run/docker/netns/: Permission denied ...
... snmpd[1234] Cannot statfs /run/user/1000/gvfs: Permission denied ...
... snmpd[1234] Cannot statfs /sys/kernel/debug/tracing: Permission denied ...

Ich versuchte mit verschiedenen Einträgen in /etc/snmp/snmpd.conf das auslesen dieser Mounts zu verhindern. Zuerst mittels der Direktive ignoredisk:

...
ignoredisk /run/user/*
ignoredisk /var/lib/docker/containers/*
ignoredisk /var/lib/docker/aufs/mnt/*
ignoredisk /run/docker/netns/*
ignoredisk /sys/kernel/debug/tracing
...

Das Blacklisting hatte leider keine Wirkung.

Auch der umgekehrte Weg, das Whitelisting, funktionierte nicht:

...
#includeAllDisks 10%
disk / 10%
...

Nach längeren Recherchen im Netz musste ich zum Schluss kommen, dass man solche Meldungen nicht mit Anpassungen an der SNMP-Konfiguration unterdrücken kann. Der Grund:

Because as I wrote in comment #2, snmpd reads /proc/mounts and runs statfs on each entry there. If any statfs call fails it logs an error. So, either stafs must not fail (i.e. no „net:[4026532288]“ entries in /proc/mounts) or snmpd must be fixed to log something more useful and only once.

Quelle: Bug 1314610 – snmpd complaining twice „Cannot statfs net:[********]#***: No such file or directory“ every 10 minutes

snmpd iteriert über die Einträge in /proc/mounts und führt ein statfs auf jeden Mountpoint durch. Das ist der Moment, in dem die Fehlermeldung geloggt wird.

Eine potentielle Lösung:

There needs to be an option to just make snmpd not try to look at these sort of mount points. The problem is that ignoreDisk only works for the devices, not mount points and a tmpfs has no „device“ name to match it by.

Quelle: snmpd storage reports all tmpfs and floods logfile

Dem Problem begegne ich nun, indem ich mit rsyslog solche snmpd-Fehlermeldungen ausfiltere und nicht zu Logstash übermittle. Der Filter dazu lautet:

...
if $programname == 'snmpd' and $msg contains 'statfs' then {
    stop
}
...

Tags: , , , , , , ,
Labels: Uncategorized

Keine Kommentare | neuen Kommentar verfassen