Artikelserie: Closed Loop

martin 9 Kommentare

In dieser Serie von Artikel, möchte ich erklären, was ein Closed Loop System überhaupt ist, was man sich darunter vorstellen kann, was es braucht, was es kann, was es nicht kann und was für Variablen man ermitteln muss.

Es handelt sich hierbei um ein Do It Yourself (DIY) ClosedLoop, von daher ist jeder selbst für die Konfiguration, Einstellungen, Fehler usw. verantwortlich.

nightscout ansicht

Ich übernehme keine Haftung für falsche Handhabung! Falls du dir nicht sicher bist, frage in den jeweiligen Chats, Gruppen, Foren nach oder schau in der/das Doku/Wiki rein!

 

 

Wenn man nicht die benötigten Faktoren ermitteln möchten (wie ein Basalraten Test, mehrere…), dann bitte nicht weiter lesen und hier abbrechen!

Wenn man sich damit beschäftigen möchte und bereit ist, praktisch 3 Wochen lang jeden Tag ein Basalraten Test zu machen und weiß was ein cgm/fgm ist, wo der Unterschied zwischen dem GZ und BZ ist, dann herzlich willkommen 🙂

 

Inhaltsverzeichnis:

  1. Was ist ein Closed Loop, was versteht man darunter und was macht es?

  2. Was braucht man (Hardware/Software/Faktoren)?

  3. Wie ermittle ich die benötigten Faktoren?

  4. Installation/Nutzung von Nightscout

  5. AAPS konfigurieren

  6. APS und Safety Parameter

  7. Lernvorgang starten und verifizieren der Parameter

  8. Optimierungsmöglichkeiten (Autotune)

 

Sobald die einzelnen Punkte fertig geschrieben sind, werden diese hier dann verlinkt.

Ein Zeitplan dafür gibt es nicht. Also einfach auf Twitter, FB usw. mal schauen, ob es was neues gibt 🙂

 

Und auch alle externen Quellen:

Linkliste:

kommt bald

ns.10be.de — Ein neues Kapitel nach fast zwei Jahren Arbeit

martin Schreib einen Kommentar
ns.10be.de – One Click Nightscout Hosting

Ich schreibe diesen Post mit einem sehr guten Gefühl. Nicht weil alles perfekt ist — das wird es nie sein — sondern weil ich auf die letzten zwei Jahre zurückblicke und sehe, was entstanden ist.

 

Wie alles begann

Wer ns.10be.de kennt, weiß: Der Dienst läuft seit November 2017. Damals war die Idee einfach: anderen ermöglichen, Nightscout zu bekommen — ohne dass jeder selbst Serveradmin sein muss und ohne dass ich dabei viel manuell arbeiten muss. Was als kleines automatisiertes Projekt startete, wurde über die Jahre zu einer ernsthaften Infrastruktur mit Hunderten von Nutzern, mehreren Clustern, MongoDB-Servern, Proxy-Servern, Backup-Systemen und einer Menge Abenden vor dem Terminal.

Irgendwann war klar: Es muss komplett neu gebaut werden. Nicht weil es nicht lief — sondern weil der Code über die Jahre immer weiter gewachsen war, neue Funktionen wurden draufgestapelt, Updates blieben aus weil schlicht keine Zeit war, und irgendwann crashte es. Der Code war nicht mehr wartbar, zu viel war zusammengestückelt was eigentlich sauber hätte aufgebaut sein müssen. Es gab keine Alternative mehr — ein kompletter Neuaufbau war der einzige Weg nach vorne.

 

Fast zwei Jahre Arbeit im Hintergrund schon davor

Was die meisten Nutzer nicht sehen: Während alles lief wie gewohnt, wurde im Hintergrund schon viel früher praktisch alles neu aufgebaut. Neue Cluster. Neues OS. Neues Docker-Setup. Ein komplett neues Queuing-System das Befehle zuverlässig über einen eigenen Message-Queue-Server abarbeitet. Neue Proxy-Server auf HAProxy/TPROXY-Basis die das alte nginx-Setup ablösen.

Das klingt trocken — ist es aber nicht, wenn man nachts um 3 Uhr vor einem frisch abgestürzten Cluster sitzt und herausfindet, dass neue AMD-Hardware unter Last anders reagiert als erwartet. Oder wenn man merkt, dass RAM-Limits trotz korrekter Konfiguration nicht übernommen werden. Oder wenn ein unkontrolliert mehrfach laufender Verteilerprozess die gesamte neue Hardware in die Knie zwingt. Nach Tagen der Fehlersuche war die Lösung: Intel-Hardware, sauber konfiguriert, mit 10–20 % RAM-Reserve und vielen Anpassungen. Seitdem läuft alles stabil.

Parallel dazu: MongoDB Replica Set und PostgreSQL Replica aufgebaut — damit kein einzelner Datenbankausfall mehr zu Problemen führt. Zwei Proxy-Server in getrennten Rechenzentren mit automatischem Failover. 47 Tage Backup-Aufbewahrung statt der alten 28 Tage.

Und dann die Geschwindigkeit. Früher dauerte ein Deploy bis zu 15 Minuten für fünf Instanzen. Heute startet eine Nightscout-Instanz in unter 3 Sekunden. Ein Redeploy zum Version aktualisieren, in unter 5 Sekunden. Das ist das Ergebnis von monatelanger Arbeit an der Infrastruktur und dank der Nightscout- und DIY-Looper-Community möglich.

 

Die neue Webseite

Die Webseite hatte bereits eine solide Basis — aber das Design war über die Jahre zusammengestückelt und an vielen Stellen nicht mehr konsistent. Das wurde jetzt von Grund auf korrigiert und deutlich verbessert. Es gibt eine Erste-Schritte-Seite mit einer echten Schritt-für-Schritt-Anleitung, eine Tour-Seite die zeigt wie das Dashboard und die Konfiguration aussehen, eine Changelog-Seite mit allem was sich seit 2017 verändert hat, und eine überarbeitete FAQ.

Aber auch im Dashboard selbst hat sich viel getan: Man kann jetzt das eigene Abo direkt in NS10BE kündigen oder die Laufzeit wechseln — ohne Umweg über Stripe oder PayPal. Follower-Tokens sind per Klick erstellbar. Viele kleine Dinge die sich über die Zeit angesammelt haben und jetzt endlich sauber umgesetzt sind.

Fünf Sprachen — Deutsch, Englisch, Französisch, Spanisch und jetzt auch Polnisch. Darkmode, Schriftgrössenauswahl, Browser-Spracherkennung. Das klingt nach Details — aber genau diese Details machen den Unterschied für jemanden der spät abends versucht, Nightscout für sein Kind einzurichten.

 

Nocturne — die moderne Nightscout-Oberfläche

Ein weiteres Thema das viel Zeit gekostet hat: Nocturne. Die neue, modern entwickelte Nightscout-Oberfläche ist technisch eine andere Welt als das klassische Nightscout-UI — und entsprechend aufwändig war es, sie auf ns.10be.de zum Laufen zu bringen und ausgiebig zu testen. Es steckt einiges an Arbeit dahinter, das Ganze so zu integrieren dass es zuverlässig funktioniert und nicht mit dem Rest der Infrastruktur kollidiert.

Erste Entwickler können Nocturne auf ns.10be.de bereits nutzen. Wer als aktiver Nightscout-Entwickler testen möchte, soll sich gerne melden — allgemeine Verfügbarkeit folgt wenn alles ausreichend getestet und stabil ist.

Was als nächstes kommt

Der Hauptserver-Umzug ist vollzogen — und auch die Extra-Server für Medtrum, Libre, Diasend/Glooko und weitere sind neu installiert. Das war der Teil der mir am meisten Sorgen gemacht hat: rund 40 Server gleichzeitig neu installieren, im laufenden Betrieb. Im Test lief alles sauber — und zum Glück hat es auch in der Realität funktioniert. Immer wieder Ausfälle gab es, da die Erkennung von fehlerhaften Logins selbst fehlerhaft war :-). Dies ist aber nun alles gefixt.

Jetzt läuft alles auf dem neuen System. Was noch kommt, werden kleinere Verbesserungen und Feinschliff sein — und natürlich alles was die Community als nächstes braucht.

Ein persönliches Wort

ns.10be.de ist ein Projekt von jemandem der selbst betroffen ist und seit 2017 daran arbeitet, dass andere sich nicht um Technik kümmern müssen. Jede Verbesserung kommt aus echtem Feedback echter Nutzer. Jeder Fehler wird von mir persönlich behoben — meistens schneller als erwartet, weil ich direkt per Discord benachrichtigt werde.

Wenn ihr Fehler findet — bitte melden. Ich hab alles mehrfach getestet, aber vier Augen sehen mehr als zwei.

Danke an alle die seit 2017 dabei sind. 🙏

→ Screenshots & Tour ansehen

 

P.S. der Text wurde mit Hilfe von KI verbessert, ansonsten wäre der Blogpost viel, viel zu technisch und 10 Seiten lang geworden 🙂

Uptime und Traffic von ns.10be.de (managed nightscout service)

martin Schreib einen Kommentar

Uptime von ns.10be.de

In den letzten Tagen/Wochen, lief ns.10be.de sehr stabil.

Der Service von uptimerobot, welcher alle Server, die hinter ns.10be.de stehen überwacht, ob diese laufen und auch, ob auf den einzelnen Cluster eine Monitoring-Instanz, sowie die MongoDB-Dienste schnell genug antworten, hat für die letzten 90 Tage eine Uptime von:

99.974%

errechnet. Dabei sind die Probleme mit den Medtronic-Servern auch mit drin (seit dem 15.02.21 aber erst).
Vor ein paar Tagen, war z.B. der MongoDB-Server 2 down. Dank der Automatisierung, wurde diese aber automatisch vom System dann neu gestartet.
Eine Analyse hat ergeben, das dieser das swappen angefangen hat, da nach den Anpassungen der Config, ich vergessen hatte auf diesem die MongoDB-Datenbank-Server neu zu starten und somit die Anpassung noch nicht gegriffen hat.
Ebenso sind darin auch z.B. das Up-/Downgraden von Cluster/Proxy-Server enthalten. So lange mindestens noch ein Proxy-Server verfügbar ist, sind die Nightscout-Server erreichbar.

Detailtieres Monitoring:

Was noch fehlt, ist die Ermittlung, warum zwei Cluster manchmal eine stark erhöhte Load von > 100 haben für einige Minuten.
Ich denke, da wird evtl. jemand autotune oder ein export machen oder viele komplexe Queries senden. Zum Glück, konnte ich dies bisher nur bei zwei Clustern sehen.
Die Überwachung der Server erfolgt detaillierter über Munin:
Die Analyse, führen wir mit atop durch, welches alle 5 Minuten die Daten wie Ram-Auslastung, Prozesse mit der meisten CPU- oder RAM-Nutzung, speichert. So kann man dann feststellen, ob ein Systemprozess oder Dienst von 10be dafür verantwortlich ist, oder eine/mehrere Nightscout-Instanzen.

Requests, die bei 10be eingehen

Pro Sekunden gehen bei ns.10be.de ca. 120 Requests, verteilt auf drei Proxy-Server ein.

Durchschnittlich sind auf allen Proxy-Server zusammen 700.000 Verbindungen offen, welche z.B. durch xdrip, spike, androidaps, diabox usw. gemacht werden.

Das gute bei den JiffyBox-Servern von df.eu ist, das man sie sehr schnell vergrößern/verkleinern kann. Aktuell sind beim proxy2 z.B. viel mehr Requests eingegangen, als üblich und dadurch kam dieser an seine Grenzen.

Daher wird dieser nun in einen größeren Tarif gerade gewechselt und ist in paar Minuten wieder online mit mehr Ram und CPU-Power.

Aktuell stehen hinter ns.10be.de 43 Server und es soll bald noch ein Proxy-Server im asiatischen und amerikanischen Raum dazu kommen, um von dort den Verbindungsaufbau und die Geschwindigkeit dort zu erhöhen.

Traffic von ns.10be.de

Im Monat 04/2021, hatten die Server bei Provider 1 ein Traffic von:

23.768,920 GB

Bei Provider 2 kamen im April:

53.260,035 GB

 

Zusammen also grob:

77TB

Dies konnte reduziert werden, da bei einigen Punkten, wie z.B. MySQL-Queries, welche von den Cluster-Servern (Dienste von 10be), die prüfen ob sich Daten einer Instanz geändert haben (Server erstellt, editiert oder z.B. auf redeploy geklickt wurde), komprimiert gesendet werden.

Ebenso wurde durch die Stabilität, die Anzahl der Neuverbindungen und Abbrüche reduziert, was auch etwas Traffic spart.

Und im April haben praktisch keine Umzüge stattgefunden, wo von Server 1 auf Server 2, Daten kopiert werden, was auch wieder pro Umzug einige bis hunderte MB einspart.

 

 

Lyumjev VS. Fiasp und warum ich zu Fiasp zurück bin

martin Ein Kommentar

Ich hatte nun 11 Tage das neue Insulin Lyumjev von Lilly drin.

Nach allerdings 11 Tagen, bin ich nun wieder zu Fiasp zurück, da mein Insulin Verbrauch von ca. 50ie pro Tag auf 70ie pro Tag gestiegen ist und es beim spritzen und die ganze Zeit „dumpf“ brennt.

Beim Fiasp, hatte ich ja das erste halbe Jahr bis ganze Jahr beim spritzen auch immer einen stechenden Schmerz/Brennen, aber das war nur kurz, tat zwar mehr weh als beim Lyumjev, aber war nur kurz.

Beim Lyumjev war es nicht so schmerzhaft, aber dafür dauerhaft und die Spritzstellen waren gehärtet (so einen kleinen Finger breit). Dazu tat es beim drauf kommen deutlich weh.

Ebenso musste ich die Faktoren anpassen und verbrauchte so mehr Insulin, aber blieb viel länger hoch.

 

Hier einmal der Vergleich:

 

 

 

 

 

 

 

Was ansonsten auffällt, ist das es nachts länger „flach“ ist als beim Fiasp (kann evtl. auch an mehr fpe von der vorherigen Woche liegen?):

 

 

 

 

 

 

Also mit Fiasp bin ich an sich, niedriger, aber Nachts, ist die „gleich-bleibe“-Phase kürzer.

 

Schneller, bzw. weniger kurze Peaks nach dem Essen, hat es mit dem Lyumjev  schon:

Ebenso sieht man, das wenn z.B. 2h Basal aus ist, der BZ dann schneller/stärker ansteigt.

Wenn der höhere Verbrauch, das lange hoch bleiben und brennen nicht wäre, würde es sich für mich die Optimierung/Anpassung der BR und Faktoren lohnen.

Aber alleine wegen dem dauerhaften brennen/schmerzen, die unangenehmer als bei Fiasp (waren) sind, bin ich wieder zurück.

 

Wie ist ns.10be.de aufgebaut. Struktur, Skripte, Abläufe…

martin Ein Kommentar

Also, wie sieht es denn so hinter ns.10be.de aus?

Eigentlich ist 10be nur ein Web-Frontend, welches die Bedienung von der Nightscout-Erstellung erleichtert und im Hintergrund das macht, was Heroku & co auch machen.

Die Einstellungen, welcher der User auf der Seite macht, werden in einer Datenbank gespeichert und zur Nightscout-Instanz weitergeleitet und dort in die Config eingetragen.

Nightscout selbst, händelt dann die ganzen Daten bz, treatments, profile etc und speichert dies in der MongoDB-Datenbank, welche bei 10be für den User beim erstellen vom Server gemacht wurden.

 

 

Aus User/Anwender Sicht: Ganz grob so:

 

  1. Also der Client (Browser, App etc), stellt eine Anfrage wie z.B. gib mir die Seite xxxxxxx.ns.10be.de und diese geht beim Proxy1 oder Proxy2 ein (Round Robin).
  2. Wenn es im nginx eine Config für den Hostnamen oder Port gibt, wird die Anfrage im Hintergrund an den Cluster zu der Nightscout-Instanz weitergeleitet.
  3. Nightscout selbst, holt sich die Daten aus der MongoDB, die auf dedizierten Server laufen (Ram wäre sonst auf den Clustern zu wenig und ist weniger flexible um eine einzelne Instanz auf einen anderen Cluster zu ziehen).
    1. Dann wird das Ergebnis an den Client zurück gegeben und die Webseite wird angezeigt.

 

 

Und was machen die anderen Sachen da?

  1. Da werden die Daten auf den zweiten Proxy gesynct, das falls der Hauptserver mal länger ausfällt, man diesen mit etwas Handarbeit als Ersatz nutzten kann.Das es auch ohne eingreifen geht, wäre möglich, aber habe ich noch nicht hinbekommen, da es viel Aufwand ist.
  1. und 6. Beim share-Server, liegen die Nightscout-Dateien, sowie die DB-Backups und die Autotune-Auswertung.
    Die Proxy-Server dürfen lesen auf die DB-Backups zugreifen, ansonsten pusht dieser nur die Daten/Files.Sprich dort werden die neuen Dateien/updates zuerst geladen, dann getestet und dann nach und nach auf den Cluster geladen.

 

 

Allgemeine Prüfung der Erreichbarkeit und der Instanzen

Dazu laufen alle paar Minuten Prüfungen ob servername.ns.10be.de:xxx/api/v1/status ein „OK“ zurück gibt und das innerhalb von 3 Sekunden.

Wenn dies in 15 Minuten mehr als 3 Mal fehlgeschlagen ist, wird die Instanz neu deployed.

Dazu laufen auf dem Cluster Daemons, welche prüfen, das die Instanzen laufen und auf dem Port reagieren. Läuft ein Prozess nicht oder antwortet dieser nicht, wird die Instanz neu gestartet.

 

 

Prüfung der VPS-Server

Die Server werden alle paar Minuten geprüft, ob diese erreichbar sind und wie der Status vom Server selbst in der api ist.

Wenn ein Server mehrmals nach 30 Sekunden Timeout nicht reagiert, aber gestartet ist, so wird dieser neu gestartet.

Wenn nach einer Stunde immer noch keine Antwort erfolgt, gibt es vom Slack-Bot eine Nachricht und ein reboot wird erneut probiert.

Ebenso wird eine Meldung auf Twitter und hier https://ns.10be.de/de/status.html gepostet.

Dies funktioniert meist gut, aber leider auch nicht immer korrekt, dann muss man immer mal wieder (selten), von Hand eingreifen.

 

 

 

Probleme letzer Woche

Die Hauptprobleme sind mittlerweile der nginx auf Proxy1 und Proxy2.

Die Requesttime liegt meist bei:

req_time=0.002

bis

req_time=0.295

im Normallfall (und aktuell auch wieder).

Bei dem Probleme letzter Woche, gab es aber Werte mit 5 Sekunden und höher, sowie loops, das der Proxy2 erst zum Proxy1 und von dort dann zum Cluster die Verbindung geleitet hat.

Dies kamm zum Teil von dem folgenden Fehler auf dem Proxy1:

could not allocate node in cache keys zone "STATIC"

Und durch die falsche DNS-Auflösung beim proxy2.

Den Fehler von Proxy1 konnte ich leider auch nach vielen Versuchen und Tipps nicht lösen, wodurch der Cache für statische Files, nun komplett deaktiviert ist.

 

 

Warum gibt es dann immer noch immer mal wieder Connection Timeouts?

Der Nginx-Dienst muss seit dem die 1.000 Instanzen überschritten wurde, leider mit einem restart neu gestartet werden, da ein reload nicht nur ewig lange dauert, sondern auch danach dieser die neuen Instanzen einfach nicht kennt und daher nicht eingelesen hat.

Beim einem restart werden allerdings die offenen Verbindungen beendet, was zu dem Timeout und ähnlich führen kann. Da dies aber auf dem Proxy1 und 2 mit zwei Minuten Verzögerung passiert, ist immer ein Proxy online.

Man könnte es alles in eine Config-Datei schreiben, dann würde der reload vermutlich gehen, dafür ist aber viel Arbeit zum umbauen der Skripte nötig…….

Allerdings habe ich heute eine andere Änderung gemacht, die es besser machen sollte.

 

 

 

Bitte beachte weiterhin, es ist immer noch ein Gefallen, der hier gemacht wird!

Es gibt keine Garantien oder ähnliches!

Es steckt verdammt viel Arbeit drin und ich versuche mein bestes, aber auch die Freizeit und das Wissen in allen Bereichen ist begrenzt (wächst, aber trotzdem begrenzt).

 

Von daher, kann es immer wieder zu solchen Probleme kommen und wie beim letzten Fall, wo man denkt, es ist gelöst, tritt dann aber wieder auf und wieder und wieder, kann sich die Lösung hinziehen.

Wer z.B. immer noch Probleme in aaps hat (was bei mir in der DEV nicht auftritt und auch nie aufgetreten ist), kann ich leider nur hier her verweisen:

https://github.com/MilosKozak/AndroidAPS/issues/2481#issuecomment-595903148

 

[UPDATE 27.05.2020]

Seit den letzten Anpassungen vom März, läuft alles wieder reibungslos.

Das letzte Problem Anfang/Mitte April, das timezone-Paket von npm nun eine Anpassung braucht, die in nightscout noch nicht drin ist, wurde lokal gefixt.

Abgesehen von Hardware-Probleme, die bei einem technischen Defekt auch etwas länger andauern können, gab es keine Verzögerungen, Ausfälle oder ähnliches.

 

#DBW2019 Sonntag: Hast Du das jetzt wirklich gesagt ?

martin Schreib einen Kommentar

#DBW2019 Sonntag: Hast Du das jetzt wirklich gesagt ?

Hast Du das jetzt wirklich gesagt ?

Menschen reden und sagen oftmals unbedacht Dinge, die uns aufregen.

Was sind die schlimmsten verbalen Entgleisungen die du dir von Ärzten, Diabetesberatern oder Freunden und Angehörigen jemals anhören musstest und was hat das in dir ausgelöst?

 

Da gibt es eigentlich nicht viel, außer das ich den Diabetes hasse (damals) und kein Bock drauf habe und damals oft genug gesagt habe.

Es gibt noch eine Situation, die ich aber öffentlich nicht beschreiben werde, da mir diese mittlerweile zum Nachteil ausgelegt werden könnte.

 

Daher muss ich hier leider passen und kann nur sagen, es dauert sehr, sehr, sehr lange bis ich etwas „wütendender“ oder „aggressiver“ werde.

Außer natürlich wie jeder in der Hypo, wenn er nichts zuckerhaltiges bekommen kann und man merkt, das es sehr knapp ist, aber da sage ich eigentlich nur „zucker, zucker, zucker“.