Seite wählen

NETWAYS Blog

Neues in logstash 1.2.x

von | Sep 11, 2013 | ,

Ein Highlight der letzten PuppetConf war mit Sicherheit der Vortrag von Jordan Sissel zum Thema Logstash. Für Nutzer von Logstash war zwar nicht soviel Neues dabei, doch machte die ein oder andere Ankündigung für die neue Version neugierig und der Stil seines Vortrags war hinzu noch sehr unterhaltsam.

jordan_logstash

Logstash ist ein Werkzeug für das Management von Logdateien und man kann es sich grundsätzlich wie eine Art „Pipe“ mit verschiedenen Ein- und Ausgabeformaten vorstellen. Die Log-Informationen werden also via File, Socket oder diversen anderen Inputs angenommen, gefiltert, getagged und weitergeleitet. Logstash selbst hält keine Daten vor, sondern sorgt „lediglich“ für die konkrete Bearbeitung und Weiterleitung. Für die spätere Analyse setzt logstash auf elasticsearch als Datenhaltungsbackend.
Seit einigen Tagen steht nun die neue Version von logstash zur Verfügung, aber was gibt es Neues:

  • Neues Webinterface
    Man hatte fast den Eindruck dass Jordan etwas Scham beim Anblick seiner früheren Eigenentwicklung von logstash-web bekommen hat, aber man kann eben als Einzelkämpfer nicht alles perfekt lösen. Hier hat das Projekt Unterstützung von Rashid Khan bekommen und liefert ab sofort Kibana in der Version 3 mit aus. Das Javascript-Frontend läuft vollständig ohne Serverkomponenten und greift direkt auf das REST-Interface von elasticsearch zu.
  • Conditionals
    Viele Anwender wünschen sich dieses Feature seit langer Zeit und mit Version 1.2.x ist es nun endlich soweit. Zwar konnte man in der Vergangenheit bereits mit Tags ähnliche Ergebnisse erzielen, aber die integrierten Bedingungen erleichtern einem deutlich die praktische Arbeit. So ist bspw. eine Abfrage auf Umgebung und Loglevel möglich, welche dann nur kritische Events an das Monitoring-System oder einen Email-Account weiterleitet.Ein Beispiel:

    output {
  # Send production errors to nagios/icinga
  if [loglevel] == "ERROR" and [deployment] == "production" {
    nagios {
      ...
    }
  }
}
  • elasticsearch Bulk API
    Wie der Name vermuten lässt erlaubt elasticsearch mit Hilfe der Bulk API die gleichzeitige Ausführung von mehreren Operationen in einem Request. Bei großen Umgebungen konnte es in früheren Versionen durchaus manchmal zu Schwierigkeiten in der Verarbeitung kommen, welche sich durch die neuen Bulk-Requests und das optimierte JSON-Schema deutlich vermindern lassen.

Zu den beschriebenen Features gibt es noch eine ganze Menge neuer In- und Outputs sowie viele kleine Optimierungen hinsichtlich Performance und Usability. Logstash ist ein tolles Werkzeug und ich werde auch bei der kommenden OSMC die Gelegenheit nutzen, Logstash und ein paar Tools drumherum vorzustellen. Logstash und die Tatsache, dass die Gold-Pakete langsam knapp werden sollte eigentlich Motivation genug sein, den Anmeldebutton zu betätigen.

Bernd Erk
Bernd Erk
CEO
Bernd ist Geschäftsführer der NETWAYS Gruppe und verantwortet die Strategie und das Tagesgeschäft. Bei NETWAYS kümmert er sich eigentlich um alles, was andere nicht machen wollen oder können (meistens eher wollen). Darüber hinaus startete er früher das wöchentliche Lexware-Backup, welches er nun endlich automatisiert hat. So investiert er seine ganze Energie in den Rest der Truppe und versucht für kollektives Glück zu sorgen. In seiner Freizeit macht er mit sinnlosen Ideen seine Frau verrückt und verbündet sich dafür mit seinen beiden Söhnen und seiner Tochter.
Lies mehr von Bernd und triff unser Team

Die Macht von SQL-Triggern

von | Aug 21, 2013 | , ,

Trigger sind SQL-Anweisungen die bei bestimmten Events wie zum Beispiel Inserts, Deletes oder Updates ausgelöst werden. Mit Triggern ist es beispielsweise möglich komplexe Tabellenconstraints in MySQL zu realisieren, die wesentlich mächtiger als die herkömmlichen MySQL-Constraints sind. In diesem Blogpost will ich euch zeigen wie man Trigger verwendet und von welchen Anwendungen man besser die Finger lassen sollte.

Change-Logs mithilfe von Triggern in MySQL

Ein wirklich prominentes Beispiel für den Einsatz von Triggern ist das implementieren eines Change-Logs. Nehmen wir an, wir haben eine Anwendung die Blogposts verwaltet und wollen jetzt dem Nutzer zusätzlich anzeigen wann Änderungen an den Posts durchgeführt wurden.
Ausgangspunkt ist folgende Tabelle die einfach nur die Artikel eines Blogs enthält:

CREATE TABLE article (
   `id` INT AUTO_INCREMENT PRIMARY KEY,
   `title` VARCHAR(255),
   `author` VARCHAR(255),
   `text` VARCHAR(4096)
);

Wir können jetzt einen Trigger erstellen, der bei jedem UPDATE einer Tabellenzeile eine bestimmte Aktion durchführt. Für jede Änderung an einem Blogpost wollen wir den Text vor der Änderung, den Änderungszeitpunkt, die Aktion und den betroffenen Post speichern. Dafür erstellen wir uns eine Tabelle die die Einträge enthalten soll und einen Trigger der die Tabelle befüllt:

CREATE TABLE article_change_log (
   `article_id` INT, `time` DATETIME, `action` VARCHAR(16), `old` VARCHAR(4096)
);
CREATE TRIGGER update_article_logger
   BEFORE UPDATE ON article
   FOR EACH ROW
   INSERT INTO article_change_log SET
      `article_id` = NEW.`id`, `action` = 'update', `time` = NOW(), `old` = OLD.`text`;

CREATE TRIGGER erstellt einen Trigger der bei UPDATE einer Zeile der Tabelle „Article“ ausgelöst wird. Der Trigger führt dann für jede betroffene Zeile eine bestimmte Anweisung durch. Die Bezeichner OLD und NEW können innerhalb dieser Anweisung verwendet werden um auf die Daten der Zeile vor und nach dem Update zuzugreifen.
Um einen vollständigen Logger zu implementieren müssten noch ähnliche Trigger für INSERT und DELETE erstellt werden. Damit ihr gleich etwas zum selbst ausprobieren habt und um den Rahmen dieses Blogposts nicht zu sprengen, überlasse ich euch diese Schritte allerdings selbst.

Vorsicht, unsichtbare Trigger!

Ein anderes Wort für „automatisches“ Verhalten ist beim Programmieren auch oft „unsichtbares“ Verhalten. Da Trigger automatisch Dinge tun ohne dass sie der Benutzer der Datenbank direkt angewiesen hat, sind sie auch immer eine eventuelle Fehlerquelle. Wenn möglich sollten Trigger keine Daten erstellen oder verändern, die von der eigentlichen Anwendungslogik erstellt werden, sondern immer nur eigene Datensätze verwalten. Damit kann sichergestellt werden, dass übersehene Trigger bei späteren Änderungen an der Anwendung zu keinem fehlerhaften Verhalten führen.

Trainings

Web Services

Events