Ambrook steht für eine umfassende Finanzmanagementlösung, die speziell auf die Bedürfnisse von Landwirten in den Vereinigten Staaten zugeschnitten ist. Diese Nutzergruppe arbeitet oft unter anspruchsvollen Bedingungen, mit wechselnden Netzwerkumgebungen und unterschiedlichen Geräten, die vielfältige Herausforderungen an die digitale Infrastruktur stellen. Für eine Anwendung, die so zentral für den Erfolg und die Vertrauensbildung ihrer Kunden ist, sind Geschwindigkeit und Zuverlässigkeit von absoluter Bedeutung. Verzögerungen oder Inkonsistenzen bei Datenzugriff und Systeminteraktionen können schnell das Vertrauen der Nutzer beeinträchtigen. Vor diesem Hintergrund wurde bei Ambrook entschieden, die Plattform mit OpenTelemetry zu instrumentieren, um detaillierte Einblicke in das Systemverhalten zu erhalten und gezielte Verbesserungen vorzunehmen.
Die Ambrook-Anwendung basiert vollständig auf TypeScript und nutzt eine Reihe bewährter Open-Source-Technologien. Die Backend-Plattform ist als Monolith mit Next.js konzipiert, während die mobile Anwendung auf React Native basiert. Daten werden über eine GraphQL-API bereitgestellt, die von Apollo Server betrieben wird. Der bisherige Datenbestand lag in Firestore, wobei aktuell die Migration zu PostgreSQL läuft.
Obwohl dieses Setup solide funktionierte, zeigte sich, dass die reine Nutzung etablierter Technologien nicht automatisch einfache Tracing-Implementierungen bedeutet, wie sich im Verlauf herausstellte. Die erste Herausforderung lag in der Instrumentierung des Apollo Servers. Der initiale Einsatz des OpenTelemetry-Pakets für Node.js konnte zwar grundlegende Anfrage-Traces erfassen, doch der Versuch, standardmäßige GraphQL-Auto-Instrumentierung zu nutzen, schlug fehl. Das lag daran, dass Next.
js den Backend-Code beim Deployment zu optimierten Bundles zusammenfasst. Die spezifischen JavaScript-Dateien aus dem GraphQL-Paket, die für die automatische Instrumentierung notwendig sind, standen somit im Produktionsbetrieb nicht direkt im Dateisystem zur Verfügung. Ohne diese Dateien konnte kein GraphQL-Operationen-Tracking erfolgen. Da eine geeignete Open-Source-Lösung fehlte, entwickelte das Entwicklerteam bei Ambrook ein eigenes Apollo Server Plugin. Dieses fügt bei jeder Abfrage oder Mutation einen eigenen Tracing-Span hinzu, indem es die Lebenszyklus-Hooks von Apollo nutzt.
Dadurch wird zu Beginn jeder Query ein aktiver Span erzeugt, welcher mit dem Abschluss der Auftragsbearbeitung endet. Zusätzlich wurde jeder Resolver in der GraphQL-Schema-Struktur in einen eigenen Span eingebettet, um eine detailreiche Nachverfolgung der einzelnen Verarbeitungsschritte zu ermöglichen. Dieses Vorgehen schuf Transparenz, welche Komponenten einer Abfrage die meiste Zeit in Anspruch nehmen und diente gleichzeitig als Grundlage für die Identifikation von Engpässen. Die nächste Hürde gab die Datenbankinstrumentierung vor. Während PostgreSQL dank eines bestehenden OpenTelemetry-Instrumentierungspakets für postgres.
js unkompliziert eingebunden werden konnte, erwies sich das Tracing von Firestore als komplexer. Die standardmäßigen Tracing-Events des Firestore SDK waren zwar zahlreich, hatten aber nur begrenzte inhaltliche Tiefe. Dies führte zu einem hohen Datenaufkommen mit wenig aussagekräftigen Attributen, etwa fehlte oft die Information zur abgefragten Collection. Ambrook entschied sich, die Firestore-Operationen eigenständig zu instrumentieren. Da alle Datenbankaufrufe über eine zentrale, ORM-artige Abstraktion liefen, war es möglich, diese Schicht mit individuellen Tracing-Spans zu versehen.
Auf diese Weise konnte jede Firestore-Datenbankoperation nachvollziehbar mit einem eigenen Trace versehen werden, der relevante Metadaten enthielt. Dieses Vorgehen ermöglichte eine effiziente Lokalisierung von langsam laufenden oder besonders häufig genutzten Datenabrufen. Als weiteres Instrument zur Optimierung wurde das Client-Seitige Tracing nicht vernachlässigt. Zwar bietet OpenTelemetry browserbasierte Tracing-Werkzeuge, doch diese sind traditionell auf einfache Seiten mit statischem HTML ausgelegt. Moderne Anwendungen basieren jedoch auf JavaScript-Rendering, dynamischem Nachladen von Inhalten und API-Aufrufen außerhalb der initialen Seitenladung.
Standardinstrumentierungen erfassen daher oftmals nicht die tatsächlichen Lade- und Interaktionszeiten im Frontend. Das Entwicklungsteam konzipierte eine eigene Sitzungserfassung („Session Concept“), die mit der Seite geöffnet wird und erst mit dem vollständigen Rendering des Inhalts endet. Dadurch ließen sich detaillierte Metriken über das Laden von JavaScript-Bundles, das Rendern der Benutzeroberfläche und das Ausführen der API-Abfragen erfassen. Mit dieser Information gewannen die Entwickler ein umfassenderes Verständnis darüber, wie die Nutzererfahrung auf verschiedenen Geräten und unter unterschiedlichen Netzwerkbedingungen tatsächlich aussieht. Bei der Auswahl des Speicheranbieters für die Tracing-Daten war Ambrook auf flexible und skalierbare Lösungen angewiesen.
Die Einschränkungen zahlreicher Anbieter in Bezug auf Datentypen oder Volumen waren nicht akzeptabel, ebenso war die Verknüpfung von detaillierten Attributen wie Konten-IDs essenziell, um gezielte Leistungsanalysen durchführen zu können. Zudem sollte das System sowohl Spans für Tracing-Daten als auch Timeseries-Metriken unterstützen, um umfassende Monitoring-Dashboards und SLO-Kontrollen zu ermöglichen. Die Wahl fiel auf den Anbieter Honeycomb. Dieser erlaubt sogenannte „weite“ Events mit bis zu 2.000 Attributen pro Span und keine Begrenzung bei den einzelnen Werten.
Die Abrechnung erfolgt nach der Anzahl der Events, was Ambrook eine planbare Kostenstruktur mit hoher Datenflexibilität sichert. Preislich ermöglicht Honeycomb für etwa 130 US-Dollar pro Monat die Übertragung von 100 Millionen Events unter minimalem Betriebsaufwand. Durch die Kombination aus Tracing und Metriken sowie leistungsfähigen Analyse- und Alarmierungsfunktionen bietet Honeycomb eine ideale Plattform für ein tiefgehendes Monitoring. Die Ergebnisse des Einsatzes von OpenTelemetry und der darauf aufbauenden Analyse waren beeindruckend. Ambrook erreichte eine Leistungssteigerung von nahezu 30 Prozent und damit eine für Endkunden deutlich spürbare Verbesserung der Reaktionszeit und Zuverlässigkeit.
Die tiefgreifende Einsicht in die einzelnen Prozessschritte ermöglichte die Identifikation von kritischen Problemen, die vorher nur schwer reproduzierbar oder erkennbar waren. Besonders hervorzuheben ist die Entdeckung unnötiger Datenbankzugriffe: Einige GraphQL-Abfragen lösten erhebliche Mehrfachlesevorgänge in Firestore aus, die monatlich über 10 Millionen unnötige Datenbankzugriffe verursachten. Nach der Anpassung dieser Abfragen konnten die Zugriffsvolumina erheblich reduziert und damit nicht nur die Performance, sondern auch die Betriebskosten gesenkt werden. Darüber hinaus wurden sogenannte N+1-Query-Probleme im Finanzberichtsmodul aufgespürt und eliminiert. Das führte zu einem dramatischen Rückgang der Zeit zur Erstellung von Finanzberichten um 85 Prozent.
Kleinere Daten-Duplikationsfehler in den Kern-APIs konnten dank der besseren Sichtbarkeit ebenfalls adressiert werden, was die 90. Perzentil-Latenz für Anfragen außerhalb des Reporting-Bereichs von 0,9 auf 0,7 Sekunden reduzierte. Diese Verbesserungen summierten sich zu einer insgesamt effizienteren und stabileren Plattform, welche die Nutzererwartungen übertrifft. Die Fähigkeit, tief in einzelne Fehler oder Performance-Probleme zu tauchen, erwies sich als entscheidender Vorteil für das Entwicklungsteam, um präventiv und schnell reagieren zu können. Ambrooks Erfahrung zeigt exemplarisch, wie wichtig eine gründliche Datengrundlage für moderne Softwareentwicklung ist.
Nur durch detaillierte und verknüpfbare Telemetriedaten können Engpässe proaktiv identifiziert und die Kundenerfahrung nachhaltig verbessert werden. Ambrook geht dabei voran, indem es OpenTelemetry und maßgeschneiderte Instrumentierung einsetzt, um den Landwirten ein verlässliches und schnelles Werkzeug an die Hand zu geben, das den speziellen Herausforderungen ihres Arbeitsalltags gerecht wird. Zusammenfassend belegt der Erfolg von Ambrook, dass die Investition in umfassende Tracing-Technologien nicht nur technische Probleme löst, sondern auch direkte Auswirkungen auf Kundenzufriedenheit und Geschäftserfolg hat. Für Unternehmen, die ihre Anwendungen verbessern möchten, ist die Einführung solcher Instrumente ein essenzieller Schritt auf dem Weg zu stabilen, skalierbaren und benutzerfreundlichen Systemen.
