Developer Conference 2013

Die Developer Conferencce 2013 war sprichwörtlich ein “Klassentreffen” der Entwicklerszene. Sie wurde sehr gut organisiert wodurch die mehr als 1400 Teilnehmer sich nur sehr selten gequetscht auf die Füße getreten haben. Es gab viele interesssante Vorträge mit unterschiedlichen Skillleveln, sodass für jeden etwas dabei war. Das Speakersdinner und die After-Work Party zwischen den Konferenztagen waren ebenfalls sehr gut organisiert.

Nachfolgend ein paar Impressionen

DC13 Location

DC13 MongoDB

DC13 Welcome Session

Für diejenigen die es interessiert, mein Vortrag von der #dchh auf Speakerdeck:

MongoDB Berlin

Galerie

Diese Galerie enthält 3 Fotos.

Die Ende Februar in Berlin stattgefundene MongoDB Berlin war eine super Konferenz und auch für die MondoDB Usergroup Berlin ein tolles Ereignis. Wir konnten viele Kontakte knüpfen und waren mit zwei Vorträgen selbst vertreten. Ein Dankeschön an 10gen! Hier noch … Weiterlesen

MongoDB Sharding Hands on

Für unser drittes Treffen der MongoDB User Group Berlin hatte ich ein kleines Hands On für Sharding vorbereitet. Ziel war es mit Hilfe von Vagrant und Puppet ein einfach aufzusetzendes Sharding Setup zu haben, mit dem man Sharding schnell und unkompliziert ausprobieren kann.

Dazu haben Jörg und ich einige Vagrantdefinitionen und Puppetmanifeste erstellt, welche über den MUGBerlin Github Account abrufbar sind. Einmal ausgecheckt, kann direkt unter  sharding-playground mittels vagrant up der lokale Sharding “Cluster” hochgefahren werden. Vorbedingung ist natürlich ein installiertes Vagrant (am Besten die aktuellste Version der Vagrant Homepage) sowie ein aktuelles VirtualBox (auch am Besten von der Oracle Seite). Sollte Vagrant beim Starten Probleme bereiten, kann dies an deaktiverten Virtualisierungsoptionen im BIOS liegen – daher dort am Besten vorher nachsehen.

In der Readme auf Github haben wir alle Kommandos und dokumentiert, sodass man sich gut zurecht finden sollte. Um das lokale Setup nun mit Daten zu befüllen, schreibt man sich entweder selbst ein kleines Hilfstool, welches Daten über den mongos in das Setup einfügt oder man ändert ein wenig Beispielcode von mir, den ich auf meinem Github Account anbiete. Dieses kleine Hilfstool speichert einen Wikipedia Abstract XML Dump in dem lokalen MongoDB Cluster. Die wichtigsten Schritte habe ich auch hier in der Readme dokumentiert. Viel Spass beim Ausprobieren.

MUGBerlin Slides

Ich habe mal in dem MUGBerlin Bereich meiner Seite alle Links gesammelt zu den bisherigen Themen der User Group. Wer also noch Slides zu unserer User Group sucht, wird dort fündig. Ich werde dort auch künftige Slides verlinken.

Einfaches Alerting oder Reporting

Wer kennt das nicht, man deployed einen neuen Service oder eine neue Applikation und möchte “noch schnell” einen regelmäßigen Statusreport zugeschickt bekommen. Ich bevorzuge dafür sendemail, ein paar Shellscripte und einen Cronjob.

Nehmen wir mal an, man ist auf einem Ubuntuserver, dann müssen die folgenden Pakete installiert werden sudo apt-get install sendemail libio-socket-ssl-perl libnet-ssleay-perl und man sollte ein Mailkonto für die zu versendenden Mails eingerichtet haben.

Wenn wir jetzt annehmen, dass eine Javapplikation unter /var/log/myapp/app.log ihre Logmeldungen ablegt und uns etwa die tägliche Anzahl der Warnings und Errors interessiert baut man sich ein kleines Shellskript errors.sh:

#!/bin/sh
LOG=/var/log/myapp/app.log
echo "Warning count: $(grep 'WARN' ${LOG})"
echo "Error count: $(grep 'ERROR' ${LOG})"

Das Skript kann man so schon auf der Konsole testen und als kleinen Helfer einsetzen. Um das Ganze jetzt noch als nächtlichen Report zu verschicken fehlen noch ein weiteres kleines Skript (mail.sh) und ein Cronjob.

#!/bin/sh
MON_SCRIPT=/path/to/script/errors.sh
#enter your mailserver host
MAIL_SERVER=localhost
#authentication credentials for the mail account
MAIL_USER=username
MAIL_PASSWORD=password
MAIL_FROM=example@localhost
#your email address, multiple mail addresses whitespace seperated
MAIL_RECIPIENTS="your email address"
#e.g. use tls
MAIL_OPTS="tls=yes"


${MON_SCRIPT} > mail.txt
/usr/bin/sendemail -s ${MAIL_SERVER} -xu ${MAIL_USER} -xp ${MAIL_PASSWORD} -o ${MAIL_OPTS} -f ${MAIL_FROM} -t ${MAIL_RECIPIENTS} -u "Mail Report" -m "" -a mail.txt
rm mail.txt

Soll jetzt z.B. um 23:59 eine Mail verschickt werden, nur noch den folgenden Cronjob in die Crontab eintragen:

59 23 * * * /path/to/script/mail.sh > /dev/null 2>&1

Dies führt dazu, dass jeden Tag um 23:59 eine Mail mit dem Titel “Mail Report” mit dem Output des errors.sh Skripts versendet wird. Die Möglichkeiten Informationen in den Mails unterzubringen sind natürlich keine Grenzen gesetzt – (Shell) Skripten sei Dank.