Seite wählen

NETWAYS Blog

Hier erfährst Du alles was uns bewegt. Technology, Hardware, das Leben bei NETWAYS, Events, Schulungen und vieles mehr.

Open Source Backup Conference – 7 reasons | part 4

Hello again! Today, we want to present the location for the special OSBConf evening event on the first conference day: The restaurant “Belgischer Hof” is in the belgian quarter of Cologne and fascinates with it’s cozy and relaxed atmosphere. Take the opportunity to...

NETWAYS Trainings – Advanced Puppet

Nach den großen Sommerferien geht es weiter mit unseren Schulungen. Im September haben wir noch freie Plätze für alle, die Ihr Puppet-Wissen erweitern wollen! Vom 26.-28. September heißt es bei NETWAYS "Advanced Puppet", Konfigurationsmanagement für Fortgeschrittene....

Lösungen & Technology

SLA Reporting: Beta-Tester gesucht!

Gute Neuigkeiten habe ich heute für Freunde von SLA Reports. Und natürlich auch für all jene, die die Anforderungen derjeniger ausbaden dürfen, die ebensolche Reports haben wollen. Ein neues Reporting-Package für Icinga ist auf dem Weg und steht unter dem...

Git unter Mountain Lion

Wer seinen Mac schon auf das neueste Betriebssystem aktualisiert hat und anschließend über den Mac Store (der goldene Käfig lässt grüßen) XCode aktualisiert wird vermutlich die Git-CLI Tools vermissen. Das Problem lässt sich ganz einfach in den XCode-Preferences durch...

Events & Trainings

OSDC 2017 – What a great week full of open source!

Over the weekend, we caught up on missed sleep and we were really happy about the successful Open Source Data Center Conference last week in Berlin. The OSDC 2017 began with our workshop day on Tuesday with „Graylog-Centralized Log Management“, „Mesos Marathon –...

OSDC 2017 – What a great week full of open source!

Over the weekend, we caught up on missed sleep and we were really happy about the successful Open Source Data Center Conference last week in Berlin. The OSDC 2017 began with our workshop day on Tuesday with „Graylog-Centralized Log Management“, „Mesos Marathon –...

OSDC 2017 – What a great week full of open source!

Over the weekend, we caught up on missed sleep and we were really happy about the successful Open Source Data Center Conference last week in Berlin. The OSDC 2017 began with our workshop day on Tuesday with „Graylog-Centralized Log Management“, „Mesos Marathon –...

Keine Ergebnisse gefunden

Die angefragte Seite konnte nicht gefunden werden. Verfeinern Sie Ihre Suche oder verwenden Sie die Navigation oben, um den Beitrag zu finden.

Web Services

Keine Ergebnisse gefunden

Die angefragte Seite konnte nicht gefunden werden. Verfeinern Sie Ihre Suche oder verwenden Sie die Navigation oben, um den Beitrag zu finden.

Keine Ergebnisse gefunden

Die angefragte Seite konnte nicht gefunden werden. Verfeinern Sie Ihre Suche oder verwenden Sie die Navigation oben, um den Beitrag zu finden.

Keine Ergebnisse gefunden

Die angefragte Seite konnte nicht gefunden werden. Verfeinern Sie Ihre Suche oder verwenden Sie die Navigation oben, um den Beitrag zu finden.

Keine Ergebnisse gefunden

Die angefragte Seite konnte nicht gefunden werden. Verfeinern Sie Ihre Suche oder verwenden Sie die Navigation oben, um den Beitrag zu finden.

Unternehmen

Inhaltsverzeichnis November 2008

Cougar Bay TriMS Server Open Source Meets Business 2009 Weihnachtsspecial Nagios Schulungen Nagios beim Klinikum Bremen-Mitte MySQL Performance Serie - Addon: Analyze Table Links 002 Konferenzbericht des Linux Magazins online UML für zwischendurch Linux Monitoring -...

Nagios beim Klinikum Bremen-Mitte

NETWAYS hat das Klinikum Bremen-Mitte dabei unterstützt die internen EDV-Dienstleistungen mit einer modernen Nagios Monitoring Lösung zu überwachen. Dabei wurde eine ältere Nagios Installation abgelöst und durch einen Nagios Cluster nach derzeitigem technischen Stand...

MySQL Performance Serie – Addon: Analyze Table

Im MySQL-Umfeld gibt es, wie in unsere Performance-Serie ausführlich geschildert, eine Vielzahl an Stellschrauben zur Optimierung. Ein ganz wichtiger Punkte zur Optimierung von Joined-Selects ist die regelmässige Pflege der der internen Datenbankstatistiken. Hierfür...

Blogroll

Da hast Du einiges zu lesen …

logstash – Der 15 Minuten Quickstart Guide

Da ich mich die letzte Zeit intensiv auf logstash Schulungen und – Consulting vorbereitet habe, liegt es nur nahe, dass ich auch zu diesem Thema blogge. Bei so zentralen Systemen ist es natürlich wichtig, sich intensiv damit auseinander zu setzen und viel Zeit zu investieren, um erstmal die Hintergründe und Zusammenhänge zu verstehen, damit man eine Installation planen kann, bevor man das erste Mal Code in die Hand nimmt. Prinzipiell ist das so richtig, aber es muss auch mal ok sein, einfach mal mit einem neuen, interessanten System rumzuspielen, bevor man sich intensiver damit beschäftigt, um erstmal ein gewisses Gefühl für die Arbeitsweise zu bekommen und weil es einfach Spass macht.

natural_logstashUnd genau dafür soll dieser Quickstart Guide sein. Zuvor aber dennoch ein paar Worte dazu, was logstash denn nun eigentlich ist und wozu man es verwenden kann und soll. Wer das schon weiss, darf auch weiter nach unten scrollen. Aber keine Sorge, weitere Infos über die Abläufe in einer logstash Installation kommen noch in dieser Blogserie. Genauso ein paar Beispiele, wie Logs von logstash aufbereitet werden können. Wer also keine Lust hat, sich mal kurz logstash zu installieren, muss nur ein wenig warten.

Jeder Computer und auch sonst fast jedes Gerät, mit dem man in der IT zu tun bekommt, schreibt Logfiles, wo besondere Ereignisse festgehalten werden. Das hilft nicht nur, aber insbesondere, beim Erkennen und Nachvollziehen von aufgetretenen Fehlern. Als Administrator steht man nun vor dem Problem, dass diese Logfiles auf den Systemen bleiben und man sich erstmal dorthin verbinden muss, um sie zu lesen. So bleiben oft kleinere Fehler, die grössere Ausfälle im Vorfeld ankündigen und helfen würden, diese zu verhinlogstash_01dern, unerkannt. Für diesen Fall bieten wir gerne Unterstützung mit Monitoring wie Icinga an. Wer aber nicht erst warten möchte, bis es kracht, sondern schon proaktiv handeln möchte, muss irgendwie an die Logfiles rankommen, ohne den halben Tag damit zu verbringen, sie von den Systemen abzuholen. Natürlich gibt es noch viele weitere Gründe, Logs zu sammeln, zu lesen und auszuwerten, aber das würde den Rahmen eines Einleitungsartikels sprengen. Es gibt bereits seit langer Zeit Lösungen wie logwatch oder syslog Server, die zumindest helfen, die Informationen aus Logfiles zu sammeln. Wozu dann logstash? Ein paar der Vorteile gegenüber herkömmlicher Lösungen sind:

  • logstash kann auf vielen verschiedenen Systemen ausgeführt werden und ist als Java (bzw. JRuby) Anwendung nicht auf ein paar Betriebssysteme beschränkt
  • logstash kann alle möglichen und unmöglichen Formate lesen. Syslog und Windows Eventlog sind naheliegend, aber auch über das Drupal dblog oder IRC können Nachrichten in logstash kommen. Gibt es keine Schnittstelle für einen Dienst, können auch beliebige Textfiles auf Systemen als Logfile angesehen und ausgewertet oder die Rückgabe beliebiger Programme gelesen werden.
  • logstash ist von vornherein darauf ausgelegt, hervorragend zu skalieren. Alle Komponenten können mehr oder weniger auf beliebig viele Server ausgebracht und miteinander verbunden werden. Teilweise als sehr einfach zu verwaltende loadbalancing und high availability cluster, teilweise einfach als redundante Instanzen, die nichts voneinander wissen und einfach jeweils nur einen Teil der zu verarbeitenden Daten erhalten. Und das, wie von Tools, die wir unterstützen, nicht anders zu erwarten, alles ohne Lizenzkosten. Wer dann noch freie Linux Distributionen einsetzt, wird eigentlich nur durch Anschaffungs- und Betriebskosten der Hardware in der Grösse der logstash Installation beschränkt.
  • logstash leitet Logs nicht einfach stumpf weiter, sondern zerlegt sie in Felder, die dann in der Auswertung genutzt werden können. Damit fällt die Regexbastelei zum Küren des grössten Spamempfängers anhand der Sendmail Logs weg, denn eine Information wie die Empfängeradresse kann schon beim Verarbeiten der Logs als eigenes Feld ausgewiesen werden, nach dem dann gefiltert oder mit dem dann Berechnungen angestellt werden können.

Jetzt aber wie versprochen die Kurzanleitung:

logstash wird als .jar File zum Download angeboten, das auch gleich ein paar andere der benötigten Tools in embedded Versionen enthält. Den Download findet man prominent unter http://logstash.net/ . Ausserdem muss Java installiert sein. logstash ist ziemlich unempfindlich, welche Java Version eingesetzt wird. In Tests hat OpenJDK-7 hervorragend funktioniert.

Als nächstes wird eine einfache Konfigurationsdatei namens logstash-quickstart.conf angelegt:

input {
  stdin {
    type => "stdinput"
  }
  file {
    path => "/var/log/messages"
    type => "syslog"
  }
}
output {
  stdout {
    codec => rubydebug
  }
  elasticsearch {
    embedded => true
  }
}

Dieses Beispiel muss mit einem User gestartet werden, der Leserechte auf /var/log/messages hat. Wer das nicht für einen Test möchte, kann den file Part einfach weglassen. Dieses Konfigfile lässt logstash Events aus /var/log/messages sowie von stdin annehmen und gibt sie auf stdout aus, speichert sie aber auch gleichzeitig in die im .jar File mitgebrachte Elasticsearch Instanz.

Gestartet wird logstash mit

java -jar logstash-1.3.3-flatjar.jar agent -f logstash-quickstart.conf -- web

Dann passiert erstmal nicht viel. Nach ein paar Sekunden erhält man eine Warnung, dass verwendete Plugins noch nicht als stabil gekennzeichnet sind, die man für einen Test einfach mal ignorieren kann. Dann wartet logstash auf neue Logmeldungen. Falls nicht zufällig eine neue Nachricht in /var/log/messages geschrieben wird, kann man auch einfach eine Testnachricht abschicken, die dann logstash durchläuft und aufgeschlüsselt wieder ausgegeben wird. Ohne weitere Konfiguration wird aber natürlich nicht viel aufgeschlüsselt, sondern die gesamte Nachricht im message Feld wieder ausgegeben. Ein paar zusätzliche Felder fügt logstash automatisch hinzu und der type wurde ebenfalls über die Konfiguration gesetzt.

[root@fenris ~]# java -jar logstash-1.3.3-flatjar.jar agent -f logstash-quickstart.conf -- web
Using milestone 2 input plugin 'file'. This plugin should be stable, but if you see strange behavior, please let us know! For more information on plugin milestones, see http://logstash.net/docs/1.3.3/plugin-milestones {:level=>:warn}
hello world
{
       "message" => "hello world",
      "@version" => "1",
    "@timestamp" => "2014-01-23T12:06:27.895Z",
          "type" => "stdinput",
          "host" => "fenris.int.netways.de"
}

„hello world“ ist die eingetippte Testnachricht.

Um logstash zu beenden, kann Ctrl+C gedrückt werden. Aber zuvor lohnt sich ein Blick auf http://localhost:9292/index.html#/dashboard/file/logstash.json . Woah! Das ist Kibana. Das mitgelieferte Webinterface zur Analyse der gespeicherten Events.schulung_logstash

Und jetzt kommt der Clou: Die logstash Installation ist voll funktionsfähig und die gesammelten Events bleiben auch gespeichert, wenn man logstash beendet und später wieder neu startet. Ab hier geht es „nur“ mehr darum, die Daten in mehr und brauchbare Felder zu zerlegen, sie von mehr Quellen zu sammeln, sie zwischen Hosts mit logstash Instanzen weiterzuleiten und die beteiligten Systeme zu tunen und zu skalieren. Dazu wird es Sinn machen, die embedded Versionen von Elasticsearch und Kibana als eigenständige Instanzen ausserhalb des .jar Files zu installieren und es um weitere Tools wie Redis zu ergänzen.

Wer jetzt schon überzeugt ist, dass logstash eine feine Sache ist, findet sich sicher etwas bei unseren logstash Starterpaketen oder logstash Schulungen . Wer nicht, hat noch ein paar Folgen dieser Blogserie Zeit, sich überzeugen zu lassen.

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...

Bash Prompt mit Git Branch Anzeige

Obwohl es da draußen die eine oder andere IDE gibt, die einem beim Entwickeln unter die Arme greift, bin ich doch sehr oft in der Shell in GIT Repositories unterwegs – sowohl privat als auch in der Arbeit auf Debian Stable und Testing sowie für den Paketbau in den diversen CentOS, OpenSUSE, etc VMs. Nachdem ich zudem noch ein fauler Mensch bin, der sich beim 10ten Mal Befehl eintippen oder in der History (Strg+R) suchen dann einen Bash Alias schreibt, geht mir der „in welchem Git Branch bin ich eigentlich grade“ Befehl

$ git branch

ziemlich auf den Keks. Vor allem inmitten eines Rebase/Merge, wo ich dann auch noch ein ‚git status‘ bemühen muss. Das sind Dinge, die ich sofort auf der Shell sehen möchte. Und dann auch noch farblich so hervorgehoben, dass mans kontrastreich erkennen kann.
Über die Jahre hinweg bastelt man dann dahin mit diversen sed Orgien auf git branch Befehle, bis man dann endlich die ultimative Lösung findet: Das Debian Paket ‚bash-completion‘ bietet diese Funktionalität bereits an, und liefert in der Variable $(__git_ps1) den benötigten Output, welcher Branch bzw. welcher Status.

# apt-get install bash-completion

Auf CentOS und Konsorten gibts das Paket (noch) nicht, man kann sich aber mit folgendem Trick behelfen (muss für alle Benutzer durchgeführt werden):

# curl https://raw.github.com/git/git/master/contrib/completion/git-prompt.sh > ~/.bash_git
# vim ~/.bashrc
source ~/.bash_git
# . ~/.bashrc

Nachdem das ja zu einfach wäre, muss man sich dann auch noch mit den Eigenheiten der Bash auseinandersetzen, was Terminalformatierung betrifft. Ich gehe mal nicht davon aus, dass das dem geneigten Leser Freude bereitet, und hängs mal mit an.
Ich verfolge dabei bestimmte Grundprinzipien, die jeder für sich selbst anpassen kann.

  • Eine Zeile für alles, inkl aktuellem Pfad (für Copypaste). Meine native Auflösung ist mind. 1680×1050, bevorzugt 1920×1080 mit entsprechender gnome-terminal Breite.
  • user@hostname sowie hostname als Root Benutzer.
  • Der root Benutzer wird rot dargestellt, der Benutzer hingegen grün (so visualisiere ich u.a. , warum das blöde rm nicht geht 😉 )
  • Das abschliessende Zeichen ist # (root) sowie $ (normaler Benutzer)
  • In Git Repositories wird $(__git_ps1) als (branchname) (dunkelgrün) angezeigt

Folgendes in die .bashrc eintragen und danach sourcen:

# =========================================================
# COLOR PROMPTS WITH GIT BRANCH
# =========================================================
function myPrompt() {
        local GREEN_BOLD="\[\033[01;32m\]"
        local RED_BOLD="\[\033[01;31m\]"
        local BLUE_BOLD="\[\033[01;34m\]"
        local GREEND="\[\033[02;32m\]"
        local REDD="\[\033[02;32m\]"
        local DEFAULT="\[\033[00m\]"
        # \h ... hostname
        # \w ... workdir
        # \$? ... RC
        # \u ... user
        # \$(__git_ps1) ... git branch/action if available
        local USER_BOLD=$GREEN_BOLD
        local USERD=$GREEND
        local USERAT="\u@\h"
        local USERHASH="\$"
        if [ `/usr/bin/whoami` = 'root' ]
        then
                USER_BOLD=$RED_BOLD
                USERD=$REDD
                USERAT="\h"
                USERHASH="#"
        fi
        PS1="$USER_BOLD$USERAT$DEFAULT $BLUE_BOLD\w$DEFAULT"
        PS1=$PS1"$DEFAULT$GREEND\$(__git_ps1)$BLUE_BOLD $USERHASH $DEFAULT"
        # window title
        case "$TERM" in
                xterm*|rxvt*)
                        PS1="\[\e]0;\h: \w (\u)\a\]$PS1"
                        ;;
        esac
}
# set git colored prompt based on uid
myPrompt

Für den Icinga 2 Entwickler sieht das dann so aus
git_bash_promt_user
während man als Root Benutzer das praktischerweise bei unterschiedlichen Konfigurationstests ebenso sieht.
git_bash_promt_root

Jitsi – aka SIP Communicator

Der heutige Post ist recht kurz und bündig, aber mit gutem Inhalt gefüllt. Wir möchten Euch einen der zahlreichen Chat und Telefon Clients vorstellen, welcher sich in der Praxis gut bewährt hat und wohl die aktuell gängigsten Protokolle unterstützt. Die Rede ist von Jitsi oder auch bekannt als SIP Communicator.
Dieser dient nicht nur als Chat Client für IRC, Jabber, Facebook und CO, sondern kann dank SIP auch gleichzeitig mit als Soft-Phone genutzt werden. Zusammen mit dem Bezug auf Mikrofon und auch Kamera lässt sich das ganze auch noch weiter aufbessern und z.B. in einen Jabber Server mit Openfire als Videokonferenz Tool einbinden.
Wer also auf der Suche nach einem neuen Client ist, kann sich hier einmal ausprobieren. Und Open-Source typisch ist er sogar für alle Plattformen erhältlich.

OSDC 2014: Der Countdown läuft – nur noch 78 Tage

Red Hats Cloud-Profi Justin Clift gibt heute praktische Lebenshilfe und erklärt uns, wie man die totale Katastrophe in den Griff bekommt.

OSDC? Noch nie gehört…
Das ist aber schade und fast schon ein unentschuldbares Versäumnis!
Aber wir holen das nach:
Die Open Source Data Center Conference (kurz OSDC) ist unsere internationale Konferenz zum Thema Open Source Software in Rechenzentren und großen IT-Umgebungen. 2014 findet sie zum sechsten Mal statt und bietet mit dem Schwerpunktthema Agile Infrastructures ganz besonders erfahrenen Administratoren und Architekten ein Forum zum Austausch und die Gelegenheit zur Aneignung des aktuellsten Know-Hows für die tägliche Praxis. Diesmal treffen wir uns dafür in Berlin!
Workshops am Vortag der Konferenz und das im Anschluss an die Veranstaltung stattfindende Puppet Camp komplettieren dabei das Rundum-sorglos-Paket für Teilnehmer, die gar nicht genug Wissen in sich aufsaugen können.

Weekly Snap: Logstash Starter Pack, Schema.org & Monitoring Plugins

weekly snap13 – 17 January looked at logs, Windows 8 media applications, monitoring plugins and a handy page mark-up format.
Eva began the week by counting 85 days to the OSDC with Jan Doberstein’s talk, ‘The Truth is in the Logs”.
Martin continued in theme and introduced our new Logstash starter packs to get the log management tool up and running.
Ronny shared his experience with Windows 8 and media problems, while Michael forwarded news of a new monitoring plugins URL for Nagios and Icinga users.
Finally, Eric recommended webmasters to check out schema.org, the page mark-up format supported by Google, Bing and Yahoo.