Qualität durch zentrale Konfiguration und Überwachung

Von Patrick Schnell
1 Kommentar
NCA Congether Konfiguration bewachen

In Zeiten von verteilten Anwendungen, unterschiedlichen Plattformen und agiler Entwicklung stehen sich viele Ansprüche und Gegebenheiten oft im Weg. Wie erschafft man eine Software und Konfiguration, welche qualitativ hochwertig ist, immer anpassbar bleibt und eine hohe Flexibilität nach der Auslieferung erreicht?

Egal welche Projektmanagement-Künste eingesetzt werden, Ziel ist immer die Auslieferung einer Software und deren Inbetriebnahme. Dabei ist es egal, ob man eine individuelle Anwendung für einen Kunden entwickelt, eine IoT-Anwendung welche auf hunderten identischen Geräten läuft oder eine mobile App baut, welche auf verschiedenen Plattformen ausgeführt werden kann.

Erster Supportfall in 3…2…1…?

Doch ist es dann soweit hält die Freude zumindest bei den zuständigen Entwicklern nur sehr kurz. Meist dauert es nicht lange und einzelne oder gar grundsätzliche Probleme müssen gefunden, analysiert und zu guter Letzt abgestellt werden. Wenn man eine Anwendung entsprechend umgesetzt hat, existieren zumindest aussagekräftige Log-Dateien. Doch an diese Logs zu kommen ist zum einem oftmals schon eine Herausforderung und frisst den jeweiligen Mitarbeitern genügend Zeit und vor allem Nerven.

Ein Weg, solche Probleme im Voraus einzudämmen ist zum Beispiel die Verwendung einer zentralen Anwendungs-Konfiguration und–Überwachung. Hierzu gibt es diverse Möglichkeiten und Tools, welche in den eigenen Anwendungen integriert werden können. Eine Art von zentraler Anwendungsüberwachung kennt man von vielen großen Software-Applikationen, welche Absturzberichte oder Ähnliches an ihre Hersteller senden. Die zentrale Anwendungskonfiguration wird heutzutage oftmals über ausgelagerte Dateien im Internet gesteuert, welche bei vorhandenem Internetzugriff heruntergeladen und zwischengespeichert werden. Diese Varianten erfordern jedoch bisher einen großen eigenen Aufwand und das Umsetzen einer gesamten Infrastruktur.

Konfigurieren oder Hotfix?

Wenn sich ein Entwicklungsteam jedoch auf zum Beispiel eine zentrale Anwendungskonfiguration einigt, ergeben sich einige Vorteile. Die Zentralisierung und damit einhergehende Auslagerung der Konfigurationen bietet die Möglichkeit nahezu im Live-Betrieb diverse Anwendungsparameter zu ändern. Das können zum beispielsweise einfache Migrationen sein, falls sich z.B. Verbindungen zu APIs oder Datenbanken geändert haben, aber auch ganz simple Konfigurationen, wie z.B. ist ein Feature aktiv oder deaktiviert.

Ein weiterer Aspekt ist die Überwachung einer Anwendung. Wie bereits erwähnt kennen wir alle die typischen Dialoge im Fehlerfall mit der Bitte, Fehlerinformationen an den Hersteller zu senden. Ein Feature, welches Entwicklern weiterhelfen kann. Doch was, wenn das nicht reicht? Das Übertragen von Ereignissen an einen Server kann Entwicklern schneller helfen, mehrfach auftretende Fehler oder Anomalien z.B. welche nur bei einem Rechner auftreten schneller und genauer zu analysieren.

Bisher ist es jedoch so, dass solche Tools entweder von den Entwicklungsteams selber umgesetzt wurden, oder als Enterprise-Produkte zur Verfügung standen. Für reine mobile Apps öffnet sich der Markt langsam und es gibt diverse Anbieter, die reines App-Logging in der Cloud anbieten.

Spätestens bei dem Wort „Cloud“ und „Ereignisse an Server senden“ stellt sich bei den Meisten die Frage nach dem Datenschutz? Wer kann versichern, dass bei keinem der Anbieter diese Daten nicht doch auf irgendeine Art und Weise verwendet werden?

Heute möchte ich Euch ein Tool vorstellen, welches nicht nur die Anwendungskonfiguration, sondern auch die Überwachung in einer einzigen Anwendung unterbringt, sowie Euch die Möglichkeit gibt, diese Tools dort zu betreiben, wo es Eure Datenschutzrichtlinien und Eure Anforderungen verlangt.

Congether vereint Konfiguration und Analyse

Diese Plattform nennt sich Congether (https://congether.com). Ziel von Congether istes, Anwendungen zu dirigieren und Tools bereitzustellen, welche prinzipiell sich um alles kümmern, was nach der Veröffentlichung geschieht. In Congether können somit Anwendungen und derer Anwendungsversionen, sowie einzelne Installationen der Anwendung als Entitäten verwaltet werden. Des Weiteren und je nach Edition können Anwendungen auf den gleichen Geräten zusammengefasst verwaltet werden. Dies ist vor Allem für IoT-Projekte hilfreich, wenn auf einem Gerät mehrere Anwendungen laufen, welche mit Congether geführt werden. Die Anbindung der eigenen Anwendung mit Congether kann hier über eine einfache WebAPI oder über entsprechende SDKs, welche jedoch derzeit nur für .NET und Angular zur Verfügung stehen, erfolgen.

Kann man das noch Konfigurieren oder muss das weg?

Das Modul, welches sich um zentrale Anwendungskonfiguration kümmert, nennt sich „Conductor“. Mit Conductor können diverse Konfigurations-Sets für eine gewünschte Ebene (Anwendung, Version, Gerät oder Installation)erstellt werden. In diesen Konfigurations-Sets können dann die einzelnen Parameter (als Key-Value) hinterlegt werden. Die großartige Besonderheit dieses Moduls liegt darin, dass diese Konfigurationen von der darunterliegenden Ebene überschrieben werden können. Das heißt, meldet sich eine Anwendung A mit der Version 1.0 und der Geräte-ID X, dann erhält genau dieses Gerät eine Konfiguration, welche entsprechend alle Parameter für diesen Endpunkt vorsieht. Somit erhält jeder Endpunkt eine individuelle Konfiguration – das ist ein Feature, welches das Arbeiten mit zentralen Konfigurationen vollständig dynamisch macht und einen echten Nutzen bringt.

Um das zu verdeutlichen, hier ein kleines Beispiel: Existiert also ein Parameter mit dem Namen „IsBetaFeaturesActive“ mit dem Wert „false“ auf Ebene der Anwendung, kann dieser z.B. für ein bestimmtes Gerät (in diesem Beispiel „Gerät X“) auf „true“ gesetzt werden. Somit überschreibt die gerätespezifische Konfiguration den Wert der Anwendung. Wird also die Anwendung auf Gerät X gestartet und fragt diese, ihre Konfiguration ab, so erhält nur dieses Gerät den Wert „true“. Dies ist natürlich ein großer Vorteil, wenn man für einen bestimmten Kreis oder nur einzelne Geräte spezifische Parameter ändern möchte.

Probleme: Hinter welcher Ecke lauert das nächste?

Das zweite Modul behandelt das Thema Anwendungsüberwachung und –Logging und nennt sich „Tracer“. Mit Tracer können diverse Elemente festgelegt werden, welche überwacht werden können. Hierbei senden die entsprechenden Anwendungsendpunkte entweder vereinzelte „Log“-Nachrichten, sprich eventbasierte Informationen. Zusätzlich gibt es den Typ der „Metrics“, also Ereignisse, welche einen messbaren Zahlenwert beinhalten. Somit können zum Beispiel Informationen wie Dauer eines Requests übermittelt und entsprechend – entweder direkt in Congether oder über Dritt-Systeme analysiert werden. Dabei ist die Datenhaltung in Congether gänzlich offen verwendbar. Hierbei können, entweder direkt über die Datenbank oder via API, entsprechende Analysen getätigt und z.B. auch an dritte Systeme weitergegeben werden.

Fazit

Mit der Kombination der beiden Module kann eine Anwendung im Laufe Ihrer Lebenszeit im Verhalten verändert und durch entsprechende messbare und analysierbare Parameter an den richtigen Stellen korrigiert werden.

Im Laufe der Zeit werden selbstverständlich weitere Module und Erweiterungen folgen. Der Anspruch ist es, dass der Entwickler sich auf das konzentrieren kann, was zählt – nämlich die Umsetzung der Anwendung – Komponenten, welche während der Lebenszeit einer Anwendung oder rein für administrative Zwecke benötigt werden, sollten langfristig von Congether übernommen werden können. Demnach müssen Entwickler sich nicht mehr auf verschiedene Anbieter und verschiedene Tools einlassen und unterschiedliche APIs einbinden. Für Congether reicht demnach eine API bzw. ein SDK für alle Module aus. Demnach sind bereits weitere Module in der Planung und Entwicklung – mit jedem Release wird also der Nutzen dieser Plattform größer und größer.

Congether ist als „Essential“-Version frei erhältlich und für Open-Source-Projekte oder kleine Projekte ausgerichtet. Für den kommerziellen Zweck dienen weitere Lizenzierungsmodelle, welche je nach Anforderungen zur Verfügung stehen.

Die Plattform kann entweder manuell für Windows oder Linux installiert werden, steht als Docker-Image zur Verfügung oder kann als OVA-Image genutzt werden. Letzteres dient ebenfalls dazu direkt in der Cloud betrieben zu werden.

Wird also zentrale Anwendungskonfiguration, wie auch derer Überwachung richtig eingesetzt, können Entwickler einen Großteil an lästigen Arbeiten, welche nichts mit der Fachlichkeit der Anwendungzu tun haben nicht nur auslagern, sondern auch die Entwicklung dynamischer und die Problemanalyse genauer durchführen.

1 Kommentar

Tutorials und Top Posts

1 Kommentar

oh-my-zsh Timestamp - Date im Terminal - HowTo Tutorial 3. April 2019 - 14:12

[…] Individuelle Konfigurationen gehören ja nicht in die Vendor Library. Von daher kann man die Ausgabe einfach in seiner lokalen Konfiguration vornehmen. Ich kann jetzt gar nicht sagen, wie das mit anderen Themes kollidiert, wenn die schon Einstellungen für die oh-my-zsh- Timestamp-Ausgabe in sich haben.Deren User werden dieses Problem ja erst einmal nicht haben, aber bei einem Wechsel muß man sich das vielleicht noch einmal ins Bewusstsein rufen. Hier ist das Setting für die lokale .zshrc Datei im Root Verzeichnis. Das kann einfach am Ende hinzugefügt werden und wird dann direkt in einem neuen Tab oder mit dem source Kommando aktiv. […]

Reply

Gib uns Feedback

Diese Seite benutzt Cookies. Ein Akzeptieren hilft uns die Seite zu verbessern. Ok Mehr dazu