Impftermin

Ein effektiver Schutz gegen Covid-19 soll eine Impfung sein und am 4.1.2020 konnten sich 80+ jährige auf der Webseite https://impftermin.rlp.de registrieren. Aber so einfach war das nicht, denn der Server war dem Ansturm anfangs nicht gewachsen und ich habe der Technik auf die Finger geschaut, um aus solchen Überlastsituationen etwas zum Cloud-Monitoring zu lernen.

Diese Seite behandelt ein Webportal zur Vereinbarung eines Impftermins und den Anlaufproblemen. Aus meiner Sicht steht es jedem Menschen frei, sich für oder gegen eine Impfung zu entscheiden. Es gibt natürlich Personen, die sich aus verschiedenen Gründen nicht impfen lassen können und daher darauf angewiesen sind, dass in der Umgebung möglichst wenig Personen infektiös sind. Vielleicht reduziert eine Impfung die Infektionsrate und die Weiterverbreitung. Sie dürfte aber einen weniger schweren Verläufen erwarten lassen.

Normalzustand

Wenn der Server nicht überlastet ist, dann sollte der Prozess wie folgt ablaufen:

  1. Anfordern eines Anmeldelinks auf https://impftermin.rlp.de
    Auf der Webseite werden ihnen Kontraindikationen angezeigt, wann Sie sich nicht anmelden sollten. Am Ende können Sie dann ein Formular mit ihrer Mailadresse, einem Captcha und den Einwilligungen zum Datenschutz ausfüllen, um ihre Anmeldung anzufordern:

    Mehr ist hier aber erst einmal nicht möglich. Ohne Mailadresse können Sie das System also nicht nutzen. Das könnte ein Problem werden, denn es ist eher das "Mittelalter", die eine Mailadresse haben. Ältere Personen werden hier Hilfe brauchen und ganz junge Mengen haben meist nicht mal eine aktiv genutzte Mailadresse.
  2. Anmeldelink per Mail
    An die hinterlegte Mailadresse wird dann ein Anmeldelink gesendet
  3. Anmeldung über Link
    Über den individualisierten Link kommen Sie dann auf die gleiche Webseite mit einem noch deutlich umfangreicheren Formular. Neben der Postadresse werden auch Krankheiten und Medikamente etc. abgefragt. Ob das ein 80+ Jähriger ohne Hilfe alles angeben kann. Ich frage mich schon, ob hier nicht die Hausärzte ihre "Kandidaten" besser kennen und melden sollten.
    Am Ende konnte der Anwender noch eine Terminpräferenz (Vormittag/Nachmittag) angeben. Eine Auswahl eines Wochentags o.ä. gab es nicht
  4. Abschlussmeldung per Mail und Web
    Den erfolgreichen Eintrag in der Datenbank wurde im Webbrowser bestätigt

    Interessanter ist aber die Mail, in der letztlich geschrieben wird, dass eine Einladung per Post verschickt wird.

Soweit der "geplante" Vorgang, wie es wohl auch der Entwickler sich vorgestellt hat.

Nicht erreichbar

Aber leider war Start dann doch nicht so reibungslos, denn mit erreichte kurz nach 08:00 der Hilferuf meiner Eltern, dass die Webseite nicht geht und sie nicht wissen, wie sie damit nun umgehen sollten.

Ich habe den Zugriff auch von meinem PC und unterschiedliche Provider versucht. Es liegt also definitiv nicht an deren PC oder Internetzugang. Also habe ich weiter geschaut.

NSLookup und Traceroute

Eine Namensauflösung ergab genau eine Adresse und auch die Anfrage über die Welt lieferte immer diesen Server.

C:>nslookup impftermin.rlp.de

Name: impftermin.rlp.de
Address: 83.243.49.213

Also kein Geo-DNS o.ä. was für eine rein deutsche Angelegenheit natürlich auch nicht zu erwarten ist. Ein Traceroute zeigt je nach Anschluss auch keine Probleme bis zum "Eingangspunkt".

Deutsche Glasfaser Kabel Deutschland 
C:>tracert impftermin.rlp.de

Routenverfolgung zu impftermin.rlp.de [83.243.49.213]
über maximal 30 Hops:

 1  2ms  1 ms  1 ms fritz.box [192.168.178.1]
 2 10ms  6 ms  5 ms 100.124.1.8
 3  8ms  6 ms  6 ms 100.127.1.13
 4  6ms  7 ms  5 ms 185.22.46.72
 5 10ms 10 ms 10 ms 185.22.45.11
 6 10ms 10 ms 10 ms fra1813aihb001.versatel.de [80.81.195.188]
 7 11ms 10 ms  9 ms 62.214.38.109
 8 15ms 15 ms 15 ms 80.242.169.54
 9    *     *     * Zeitüberschreitung der Anforderung.
10    *     *     * Zeitüberschreitung der Anforderung.
11    *     *     * Zeitüberschreitung der Anforderung.
 
C:>tracert impftermin.rlp.de

Routenverfolgung zu impftermin.rlp.de [83.243.49.213]
über maximal 30 Hops:

1  <1ms <1ms <1ms fritz.box [192.168.178.1]
2  14ms 13ms 12ms ip5f5824fe.dynamic.kabel-deutschland.de [95.88.36.254]
3   9ms 11ms 11ms ip5886d9a6.static.kabel-deutschland.de [88.134.217.166]
4  59ms 72ms 72ms ip5886c0b0.static.kabel-deutschland.de [88.134.192.176]
5  14ms 12ms 17ms 145.254.3.78
6  14ms 22ms 14ms 145.254.2.195
7  16ms 17ms 15ms fra020isp005.versatel.de [80.81.193.80]
8  18ms 13ms 15ms 62.214.38.109
9  18ms 18ms 22ms 80.242.169.54
10    *    *    * Zeitüberschreitung der Anforderung.
11    *    *    * Zeitüberschreitung der Anforderung.
12    *    *    * Zeitüberschreitung der Anforderung.

Leider blockiert hier anscheinend jemand zumindest ICMP-PING als Möglichkeit der Fehlersuche und Laufzeitmessung. Solange kein IPv6 genutzt wird, ist das auch tolerierbar.

Netzwerk-Standort

Aber wir haben ja die IP-Adresse und über das RIPE erhält man folgende Information:


Quelle https://apps.db.ripe.net/db-web-ui/query?searchtext=83.243.49.213

Das Netzwerk mit der IP-Range 83.243.48.0/22 (AS8881) wird von 1&1 Versatel betrieben

Auch in PeeringDB ist das Netzwerk mit einer Menge an öffentlichen und privaten Peerings gelistet:


Quelle: https://www.peeringdb.com/net/684

Insofern zeigt der Traceroute keine Probleme im "Peering" oder Interconnect und die letzten zwei Hops zeigen a auch keine höhere Latenzzeit:

 6 10ms 10 ms 10 ms fra1813aihb001.versatel.de [80.81.195.188]
 7 11ms 10 ms  9 ms 62.214.38.109
 8 15ms 15 ms 15 ms 80.242.169.54
 9    *     *     * Zeitüberschreitung der Anforderung.
10    *     *     * Zeitüberschreitung der Anforderung.

Aus dem Routing ist nun natürlich nicht ersichtlich wie die weitere interne Struktur beim Landesbetrieb Daten und Information (https://ldi.rlp.de/de/startseite/) aussieht.

Wireshark

Wenn ein PING nicht mehr zeigt, dann kann Wireshark auf dem Kabel genauer Aufschluss geben und da war ziemlich viel "Rot":

Schon erst erste TCP-Connect reagiert erst nach entsprechend vielen "Retransmits" bis nach 7 Sekunden erst der "TCP ACK" kommt und auch auf das "Client Hello" kam erst nach 37 Sekunden das ACK. Das ist schon eine deutliche "Überlastung" des Servers oder eines Teilstücks zu sehen.

Leider habe ich keinen Einblick in die Server-Auslastung oder Netzwerkanbindung und ein PRTG-Monitoring habe ich noch nicht vorab aufgebaut. Aber als Betreiber sollte man da ja entsprechende Möglichkeiten nutzen. Leider scheint die komplette Kommunikation nur über die Adresse https://impftermin.rlp.de zu gehen. Ich hätte vielleicht zwei URLs genutzt, um eine "leichte" Willkommensseite mit einem Status anzuzeigen, die auch besser gegen DoS-Attacken zu verteidigen wäre.

So könnte es aber wohl dazu geführt haben, dass Interessenten immer und immer wieder ein "Reload" gemacht haben und die Situation sich damit hochgeschaukelt hat. Vielleicht war aber der Server tatsächlich nicht für die Last ausreichend dimensioniert.

Fiddler

Also habe ich im Browser und mit Fiddler den HTTP-Requests auf die Finger geschaut und ein interessantes Verhalten gesehen.

Der erste Request ist die Startseite, die 08:49:25 geladen wird. Der Browser holt dann sehr schnell parallel die verlinke CSS-Datei, die aber hier schon einen 502-Fehler produziert. Auch die im HTML-Dokument schon verlinkten Bilder werden erst mit 2 Minuten Verspätung angefordert. Entweder das war nun ein 2-Minuten-"Netzwerkaussetzer" oder der Webserver war tatsächlich so beschäftigt. Einige Zeit später bei "Normalbetrieb" sah dies nämlich so aus:

Da parallel Pings bis "nahe" an das Ziel aber keine Auffälligkeiten zeigten, können wir nun nur raten, ob der letzte Hop zum Server zu voll war oder der Server einfach die Last nicht bedienen konnte.

Wenn ich mir die Funktion der beiden Formular anschaue, dann frage ich mich aber schon, ob es dazu ein 178kByte großes "gijio.min.js"-JavaScript bedarf, zumal ich gar kein "Datagrid" erkennen kann.

  • GIJGO
    https://gijgo.com/grid
    "jQuery Grid by Gijgo.com is a plug-in for the jQuery Javascript library. It is a very fast and extandable datagrid, and will add advanced interaction controls to any HTML table."

Wenn ich das Captcha falsch eingebe, dann kommen zu den eigentlichen Daten sogar noch eine 650kbyte große "bootstrap.min.cs.map" dazu, die man sicher nicht braucht:

Ich denke schon, dass ein Web-Entwickler hier sicher optimierter arbeiten könnte, z.B. indem CSS, JS, Schriften und Image-Dateien zumindest einige Zeit im Cache verbleiben könnten oder von einer anderen Umgebung ausgeliefert werden. Nicht ganz verstehen kann ich den Aufwand, die eigentlich statischen Inhalte mit einem Parameter zu versehen, so dass der Browser diese Antworten nicht cached.

Die langen Antwortzeiten für einen Teilmenge der Dateien deutet aber schon auf Probleme des Webservers hin und weniger auf die eigentliche Netzwerk-Verbindung. Vielleicht bloggt das LDI ja über ihre Erfahrungen mit der Bereitstellung von https://impftermin.rlp.de/ und den Anlaufproblemen.

Auflösung nach 9:00 Uhr

Ca. eine Stunde später konnte ich dann tatsächlich die erste Maske erfolgreich für meine Eltern abschließen. Die Mail mit dem Link für die zweite Phase war innerhalb von Sekunden da und auch das zweite Formular konnte erfolgreich befüllt werden. Auch dieser Schritt wurde per Mail bestätigt. Nun warten wir auf den "Post-Brief" mit dem Termin.

Vielleicht hatte der Ausfall ja auch etwas mit dem "Hackerangriff" an die Schulcloud in Rheinland-Pfalz zu tun

Wobei Presse sehr schnell von "Hackern" sprich, wo es vermutlich nur eine DoS-Überlastung war, die als "Service" einfach einzukaufen ist. Klar, dass dann auch die Opposition dann wieder der Regierung die Schuld geben möchte. Aber das ist ja über alle Parteien hinaus verbreitet.

Einschätzung

Für einen Anbieter einer Plattform ist es immer schwer den Ressourcenbedarf abzuschätzen. Schließlich weiß man vorher nicht, wie viele Clients zu Spitzenzeiten das System nutzen werden und wie viele "Störer" noch parallel den Prozess stören wollen. Dennoch sehe ich schon Potential zur Verbesserung z.B.

  • Auslagerung statischer Inhalte an ein Content Delivery Netzwerk
    Man kann den eigentlichen Hauptserver sehr einfach entlasten, indem man z.B. CSS, JavaScript-Quellen und Schriften auf andere Server auslagert. Vielleicht wurde das im Hintergrund über einen Reverse Proxy auch gemacht.
  • Zuverlässige Willkommensseite
    Ich habe fast eine Stunde immer wieder die Startseite laden müssen. Oft war sie gar nicht erreichbar, manchmal wurde sie teilweise geladen und war damit unbrauchbar und selbst wenn ich Mailadresse und Captcha ausgefüllt habe, landete dann der "Form Post" auf einem Fehler. Das Ziel muss eine zuverlässig erreichbare Startseite sein, auf der z.B. auch aktuelle Probleme angezeigt werden könnten oder ein Throttling stattfindet, ehe man schon Mailadresse und Captcha ausgefüllt hat.

Der größte Fehler ist meiner Ansicht nach aber, dass ein "Windhundverfahren" geschürt wurde. Die Politik wollte viele Impfwillige bei knappen Impfdosen und suggeriert damit, dass die Reihenfolge der Anmeldung relevant ist. Natürlich wird es am Anfang mehr Anmeldungen als Impfdosen geben aber vielleicht hätte schon die Kommunikation anders laufen müssen. Über die Webseite kann man anmelden aber die Reihenfolge wird vermutlich eh das "Impfteam" festlegen.

Wenn es für den Interessent egal ist, ob er gleich morgens um 08:00 die Webseite bestürmt oder im laufe der Woche seine Daten erfasst, dann gäbe es auch die Spitzen nicht. Weder bei der Webseite noch beim Hotline-Telefon, welches angeblich "bis zu 70 Agenten" hat. Ich stelle mir gerade vor, wie 70 Agenten von alten Menschen all die Daten erfasst, die ich mal schnell auf der Webseite "angekreuzt" habe. Ob das skaliert?

Aus technischer Sicht habe ich gelernt, dass eine Überwachung eines "Cloud Service" drei Aspekte unterscheiden kann:

  • Erreichbarkeit über das Netzwerk
    Per Ping kann man zumindest eine Teilstrecke messen und damit die generelle Erreichbarkeit (DNS, ICMP, ROUTING) prüfen, auch wenn in dem Beispiel man nicht bis zum finalen Ziel kommt. Das wird aber mit IPv6 eh besser, wenn ICMP für die Aushandlung der Windowsize nicht mehr geblockt wird..
  • Performance von statischen/dynamischen Inhalten
    Eine Webseite liefert immer auch Inhalte aus, die sich nicht ändern und damit aus einem Cache kommen können. Bei dem Beispiel kommen diese von der gleichen URL aber zeigen schon unterschiedliche Reaktionszeiten. Ein Monitoring der statischen Inhalte wie "Favicon.ico" sagt nicht viel über die gefühlte Performance aus

Gerade dem letzten Punkt sollte ich zukünftig genauer betrachten, wenn ich Cloud-Dienste überwache. Vielleicht ist es mal Zeit für ein End2End-PHP aus meiner Ende zu Ende Monitoring-Serie. Das funktioniert natürlich nur, wenn ich auch Kontrolle über den Webserver hätte.

Weitere Links