Seite wählen

NETWAYS Blog

Events im Elastic Stack verfolgen

von | Nov 26, 2020 |

Im folgenden gebe ich einen kurze Übersicht über ein paar Handgriffe, die sich beim Debuggen des Elastic Stack bewährt haben. Vor allem beim Beantworten der Frage „Wo verdammt sind meine Events?“

In Kibana

Zuerst wird man wohl bemerken, dass Events fehlen, wenn man sie in Kibana nicht finden kann. Bevor man sich aber in die Tiefen der Konfiguration begibt, sollte man also erstmal die Möglichkeiten des Webinterface völlig ausschöpfen.

  • Ist ein Filter gesetzt, der die Nachrichten ausblendet?
  • Wurde ein falscher Zeitbereich gewählt?
  • Kann es sein, dass der sendende Host eine falsche Zeiteinstellung hat und die Events deshalb an einer falschen Position des Zeitstrahls angezeigt werden?
  • Wurde das falsche Index-Pattern gewählt?

Einfach zurück setzen kann man die meisten dieser Einstellungen durch einen Klick auf die „New“ Schaltfläche im Kibana-Discover.

Führt all das nicht zum Erfolg, folgen tiefer greifende Schritte.

Message Broker

Sehr leicht nachvollziehen kann man, ob Nachrichten im Message broker festhängen, falls man denn einen benutzt. Füllen sich Redis, Kafka oder ähnliches, dann ist auf jeden Fall im Ablauf etwas falsch oder der Stack zu klein gesized. Bei mehreren Pipelines kann hier auch gut nachvollzogen werden, an welcher Stelle es klemmt. Dabei helfen aussagekräftige Namen beim Ablegen im Broker z.B. für Keys in Redis.

Den Füllstand des Brokers sollte man übrigens auch deshalb ständig im Blick haben. Das check_redis.pl Plugin für Icinga bietet sich dafür an.

Logstash

Bevor an der Konfiguration Änderungen vorgenommen werden, sollte unbedingt das Log von Logstash und Elasticsearch geprüft werden. Ein häufiges Problem ist ein „type mismatch“ in einem Feld, das verhindert, dass ein Event in Elasticsearch geschrieben wird. Beim Verwenden von dynamic mapping (dem default) wird jedem Feld der Typ verpasst, den das erste Event aufweist, das in diesen Index geschrieben wird. Steht also in client.port eine Nummer, wird Elasticsearch hier den Typ int zuweisen. Kommt später ein Event, wo client.port Text enthält (warum auch immer), dann wird dieses Event mit einer Meldung im Logstash Log verworfen.

Führt auch das nicht zum Erfolg, gibt es einige Tricks, die man anwenden kann, um die Funktionsweise genauer zu durchleuchten.

  • Einzelne Pipelines können in der pipelines.yml vorübergehend deaktiviert werden. Das bietet sich vor allem für „output“ oder „forwarder“ pipelines an, die an Elasticsearch schreiben
  • Jedem Filter eine id zu vergeben ist immer eine gute Idee. Damit kann man auch sehr gut im Kibana Monitoring sehen, welcher Filter wie viele Events verarbeitet
  • Praktisch ist auch, sich Konfigdateien zurecht zu legen, die nur für’s Debugging gebraucht werden. Bei Bedarf kann man diese in die Verzeichnisse der Pipelines kopieren und danach wieder löschen. Ich verwende dabei gern einen mutate Filter, der einfach nur ein Tag setzt, um zu sehen, ob überhaupt bestimmte Events durch eine Pipeline kommen. Außerdem eine weitere Datei mit einem file Output, der mir alle Events in der Pipeline in eine Testdatei schreibt. Optional kombiniert mit dem dot Codec kann man so sehen, wie viel durch fließt, wenn die genauen Events gar nicht relevant sind. Diese Files kann man dann einfach in die einzelnen Pipelines legen und wieder raus nehmen. Verwendet man sie mehrfach, muss man aber darauf achten, Doubletten zu vermeiden, also verschiedene Namen für Tags, verschiedene Files als Ziel etc.
  • Der obige Tip funktioniert natürlich auch mit mutate Filtern, die man kurzerhand mitten in die eigene Konfig schreibt – z.B. in ein if – um dort Tags und Felder mitzugeben, nach denen man dann sucht
  • Falls Logstash eine Pipeline nicht starten kann, liegt das häufig an Tippfehlern in der Konfiguration. Um diese zu finden kann man den Pfad der Konfig einer Pipeline aus der pipelines.yml kopieren und durch cat anzeigen lassen. Dieser Copy&Paste Ansatz verhindert, dass man z.B. nur eine einzige Datei in der pipelines.yml angegeben hat, aber erwartet, dass das ganze Verzeichnis angezogen wird. Wichtig dabei zu wissen ist, dass Logstash durchaus auch eine einzelne Pipeline offline nehmen kann und der Rest weiter läuft

Wer noch mehr zum Thema Troubleshooting bei Elastic Stack wissen will und das auch mal praktisch ausprobieren möchte, hat dazu in unseren Elastic Stack Schulungen zum Thema Logmanagement Gelegenheit.

Thomas Widhalm
Thomas Widhalm
Manager Operations
Pronomina: er/ihm. Anrede: "Hey, Du" oder wenn's ganz förmlich sein muss "Herr". Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 ist er bei der NETWAYS. Zuerst als Consultant, jetzt als Leiter vom Operations Team der NETWAYS Professional Services, das unter anderem zuständig ist für Support und Betriebsunterstützung. Nebenbei hat er sich noch auf alles mögliche rund um den Elastic Stack spezialisiert, schreibt und hält Schulungen und macht auch noch das eine oder andere Consulting zum Thema. Privat begeistert er sich für Outdoorausrüstung und Tarnmuster, was ihm schon mal schiefe Blicke einbringt...
Lies mehr von Thomas und triff unser Team

Debugging mit Docker

von | Mai 13, 2016 | , ,

docker
Docker ist uns allen als leichtgewichtige Lösung bekannt mit deren Hilfe man Anwendungen in Containern bereitstellen kann. Ist man etwas kreativ, kann man mit Docker aber viel mehr „verbrechen“. So kann man beispielsweise Docker sehr gut zum debuggen von Applikationen verwenden.
Jetzt fragt ihr euch sicher: „Was ist den bei dem kaputt? Zum debuggen brauch ich in 90 % aller Fälle eine Konsole“. Aber warum den nicht!? Es ist zwar gegen die Idee von Docker, aber man kann damit natürlich auch einen kleine Debugging-Container mit SSH betreiben.
 
 
Hier ein kurzes Beispiel in Form eines Dockerfiles:
FROM debian:8.4
MAINTAINER $your_name $your_email

# install needed packages
RUN apt-get update && apt-get install -y openssh-server rsync rsnapshot vim git sudo ntpdate ethtool screen dnsutils shorewall curl unzip telnet net-tools ntp ntpdate

# prepare root account and login
RUN mkdir /var/run/sshd
# SSH login fix. Otherwise user is kicked off after login
RUN sed 's@session\s*required\s*pam_loginuid.so@session optional pam_loginuid.so@g' -i /etc/pam.d/sshd
ENV NOTVISIBLE "in users profile"
RUN echo "export VISIBLE=now" >> /etc/profile

# prepare user
RUN groupadd -g 10000 $your_name
RUN useradd -g 10000 -u 10000 -s /bin/bash -m $your_name
RUN mkdir /home/$your_name/.ssh && chmod 750 /home/$your_name/.ssh && chown $your_name. /home/$your_name/.ssh
RUN echo "<$your_ssh_key>" > /home/$your_name/.ssh/authorized_keys && chmod 600 /home/$your_name/.ssh/authorized_keys && chown $your_name. /home/$your_name/.ssh/authorized_keys
RUN echo "$your_name ALL=NOPASSWD: ALL" > /etc/sudoers.d/$your_name && chmod 640 /etc/sudoers.d/$your_name

# map ssh port and run ssh
EXPOSE 22
CMD ["/usr/sbin/sshd", "-D"]

Wenn ihr jetzt alle $your_name durch euren Benutzernamen ersetzt (Variablen funktionieren bei Docker leider nicht in der RUN-Umgebung) erhaltet ihr ein aktuelles Debian 8.4 mit einem SSH Zugang. Dieses Dockerfile mit SSH kann man nun z. B. sehr einfach um Icinga2 Pakete erweitern. Etwas weiter gesponnen könnte man noch verschiedene Betriebssystemversionen oder die Auswahl Icinga2 Stable oder Snapshot mit einbauen.
Alles in allem erhält man einen sehr leichtgewichtigen Container der das Debuggen ermöglicht, der sehr schnell provisioniert ist und man mit der entsprechenden Storage Config sogar anwendungsspezifische Konfigurationen und Dateien mit schleppen kann.

Tobias Redel
Tobias Redel
Head of Professional Services
Tobias hat nach seiner Ausbildung als Fachinformatiker bei der Deutschen Telekom bei T-Systems gearbeitet. Seit August 2008 ist er bei NETWAYS, wo er in der Consulting-Truppe unsere Kunden in Sachen Open Source, Monitoring und Systems Management unterstützt. Insgeheim führt er jedoch ein Doppelleben als Travel-Hacker und renoviert, baut und bastelt als Heimwerker an allem was er finden kann.
Lies mehr von Tobias und triff unser Team

Besserer Python-Debugger gefällig?

von | Jan 10, 2013 |

Welcher Python-Programmierer hat sich nicht schon einmal über die kleinen Macken des builtin-debuggers (im folgenden der „Normale“) geärgert oder schmerzlich Syntax-highlightning und TAB-Vervollständigung vermisst? Nun, ich bin so einer und möchte euch deshalb heute pdb++ vorstellen. Einmal installiert ersetzt dieser Debugger den normalen aus der stdlib und wartet mit einigen sehr nützlichen Features auf. mehr lesen…

Johannes Meyer
Johannes Meyer
Lead Developer
Johannes ist seit 2011 bei uns und inzwischen, seit er 2014 die Ausbildung abgeschlossen hat, als Lead Developer für Icinga Web 2, Icinga DB Web sowie alle möglichen anderen Module und Bibliotheken im Web Bereich zuständig. Arbeitet er gerade mal nicht, macht er es sich bei schlechtem Wetter am liebsten zum zocken oder Filme/Serien schauen auf dem Sofa gemütlich. Passt das Wetter, geht's auch mal auf eines seiner Zweiräder. Motorisiert oder nicht.
Lies mehr von Johannes und triff unser Team

Weekly Snap: Puppet 2.5, Python Debugger, OSDC Partners & Icinga/Nagios Training

von | Apr 2, 2012 |


26 – 30 March ended the month with a good mix of Python and Puppet tips, MySQL lessons and events.
Eva started by thanking our sponsors, Linux Magazin, Admin Magazin and SuSE in the lead up to the Open Source Data Center Conference on 25 – 26 April.
Sebastian then encountered a strange MySQL master-master cluster error while Eric explained how to use the Python Debugger and Bernd forwarded news of the latest Puppet Enterprise 2.5 release.
Lastly, Phillipp celebrated our inaugural Icinga/Nagios Availability Monitoring training course in Düsseldorf, with a second to come on 21 – 25 May.

Weekly Snap: GDB for Debugging, ispCP for Web Server Admin, 1 New Job & 3 New Hardware

von | Aug 8, 2011 |

1 – 6 August started the month with blogging from across the office. First on new products from the hardware store, tips from the development and managed services teams and also a new job opening on the sales team.
Starting the week, Marcus shared a tip for web server management with isp Contol Panel Omega. A fork of the now inactive VHCS project, ispCP is an open source, multi server control and administration panel for internet service providers. He likes ispCP for its user interface and ability assign various roles to users such as ‘administrator’, ‘reseller’ and ‘user’ to apply refined user rights and principles. Installation is easy with the helpful official documentation and ispCP is available in a stable v1.0.7. However for a look at its new features Marcus recommends the v1.1.0 beta version or simply their online demos.
From the development team, Gunnar showed how to use GDB for debugging. As of v.7.0, GDB can “record” and replay program execution allowing the user to pinpoint problem areas in the source code. Handy indeed, but he cautioned that GDB significantly slows the program when “recording” and should be used for the shortest process portions possible.
Following on from Sales, Peter posted a position for a Junior Account Manager. The ideal candidate would have some experience in hosting, systems management, monitoring etc and enjoy dealing with customers. More on the position and application can be found on the jobs area of our website.
From our hardware shop, Martin announced the arrival of Kentix AlamManager, Multi Sensor LAN and the new Multi-Tech Multi Modem for SMS. The Kentis Alarm Manager Set consists of a base station and wireless multi sensor. The base station facilitates communication with the company network and sends SMS alerts through the in-built GSM modem. The sensor monitors temperature, humidity, dew point, fire/carbon monoxide and movement, communicating to the base station wirelessly via Zig Bee. For smaller environments, the Multi Sensor LAN is also available, offering a version that is integrated into the company network via a network cable (with PoE). As alway. Icinga/Nagios  plugins can be downloaded at www.netways.org
Finally, the last addition to the shop is the follower to the Multi-Tech Multi Modem MTCBA-G-EN-F4-ED-EU, known as the Multi-Tech Multi Modem MTCBA-G2-EN2-F4-ED-EU. From in-house tests, Martin noted that interceptty is no longer needed; instead communication can be set simply in the SMS server tool config.

Trainings

Web Services

Events