Die API war weg, wie kam es denn dazu?

Viele unserer Kunden kennen und schätzen unsere APIs und die Möglichkeiten der Nutzung. (Und wem das jetzt noch gar nichts sagt, der kann diesen Artikel lesen, danach ist garantiert alles klar.) Letzte Woche Mittwoch allerdings war die XMLRPC-API, die die Grundlage für unseren Faxdrucker, das Firefox-Plugin und viele von unseren Kunden selbst entwickelte Lösungen bildet, für mehrere Stunden nicht verfügbar. Wir wollen kurz erklären, wie es dazu kam und was wir getan haben, dass das hoffentlich nicht wieder vorkommt.

Was war passiert?

Gegen Mittag berichteten mehr und mehr Kunden, dass sie Probleme mit dem Faxversand und -empfang hätten. Ein Blick in die Graphen unseres Monitorings zeigte auch, dass da etwas „komisch“ war. Also haben wir uns rollenübergreifend zusammengesetzt und versucht, das Problem zu verstehen. Und ziemlich schnell kamen wir auf ein System, das für das Speichern und Abrufen von Eventlisteneinträgen, Faxen, Voicemails, Gesprächsmitschnitten usw. zuständig ist.

Und was hat das mit der API zu tun?

Wir haben dann festgestellt, dass ziemlich viele Anfragen an dieses System von der API kamen. Und der Grund dafür war auch recht verständlich. Wenn ein Kunde über die API ein Fax verschickt, z.B. über den Faxdrucker, dann möchte dieser auch wissen, ob das Fax erfolgreich versendet wurde. Und dafür fragt er regelmäßig nach, wie der Status dieses Faxes nun ist. Und zwar so lange bis wir eine endgültige Antwort geben.

Für ein einzelnes Fax mag das nicht schlimm sein. Wir haben allerdings auch Kunden, die mehrere Tausend Faxe pro Tag versenden. Und wenn die Applikation des Kunden nun für jedes Fax immer wieder nach dem Status fragt, gleichzeitig aber auch immer mehr Faxe bei uns zum Versand abkippt, werden die Anfragen an unsere API immer mehr. Und irgendwann macht das oben genannte System nichts mehr als der API zu antworten, dass es keine Neuigkeiten zu all den Faxen gibt.

Aber was war denn nun das eigentliche Problem?

Wir haben deshalb die API eine Zeit lang abgeschaltet, um dem System Luft zu geben, die eigentlichen Aufgaben zu erledigen. Das hat allerdings nicht die erhoffte Entspannung gebracht, also haben wir weiter gesucht. Schlussendlich stellte sich eine Datenbank als Verursacher der Probleme heraus, die zwar noch lief aber nicht wie gewohnt arbeitete. Als recht deutlichen Indikator dafür konnte man sehen, dass die laufenden und gelockten Transaktionen zum Beginn des Problems schlagartig in die Höhe gingen. Leider hatten wir diesen Wert zwar im visuellen Monitoring (also Graphen), allerdings nicht im Alarmierungssystem.

Ein Neustart hat den ganzen Spuk beendet – unbefriedigend, ich weiß. Nachdem die angesammelten Eventlisteneinträge, Faxe und Voicemails dann nach und nach abgearbeitet wurden, haben wir die API wieder eingeschaltet. Am Ende stand dann aber leider doch ein Ausfall von mehreren Stunden zu Buche.

Passiert das jetzt häufiger?

Nein. Zumindest haben wir alles dafür getan, um es beim nächsten Mal schneller mitzubekommen und zu beheben. Wir haben uns am nächsten Tag zusammengesetzt, die Gründe und Auswirkungen nochmals beleuchtet und entsprechende Maßnahmen getroffen. Diese sind:

• Wir überwachen den Füllstand bestimmter Tabellen dieser Datenbank und werden bei Überschreiten von Schwellwerten alarmiert.
• Wir überwachen mehr Performance-Werte aller Datenbanken und werden bei Überschreiten von Schwellwerten alarmiert.
• Die API speichert Anfragen nach dem Faxstatus für eine gewisse Zeit zwischen und verhindert somit eine Servicedegradierung durch wildgewordene Client-Applikationen.

Diese Maßnahmen sollten uns helfen, beim erneuten Auftreten des Problems schneller die Ursache zu erkennen und die Auswirkungen zu begrenzen.