Unified Logging & Monitoring über alle Systeme, nicht ein Log je Anbieter
Jeder API-Aufruf wird in derselben strukturierten Form protokolliert: der Endpunkt, die Antwort, der Zeitstempel, das Zielsystem und der Account-Key. Die Systeme antworten alle verschieden, der Satz nicht, und er hält fest, dass übertragen wurde, statt zu speichern, was bewegt wurde.
Was ist Unified Logging & Monitoring
Mit einer Anbindung ist Debuggen das Lesen zweier Sätze: Ihres und des Systems. Die Kosten für das nächste System sind nicht linear, weil die Frage sich ändert. Sie ist nicht mehr, was in unserem Code schiefging, sondern wo das schiefging, und jedes System beantwortet diese Frage in seinem eigenen Format, über sein eigenes Portal oder über gar keines, nach seiner eigenen Uhr.
Unified Logging & Monitoring hält diese Frage von einer Stelle aus beantwortbar. Jeder API-Aufruf wird in derselben strukturierten Form protokolliert, mit dem aufgerufenen Endpunkt, der Antwort, dem Zeitstempel, dem Zielsystem und dem Account-Key. Das genügt, um für einen Mandanten über Systeme hinweg zu rekonstruieren, was wann geschah, ohne dass Sie sonst etwas öffnen.
Sätze werden bei Start und Scale 30 Tage und bei Enterprise 90 Tage oder länger aufbewahrt, wie weit zurück Sie untersuchen können, gehört also zu Ihrem Tarif.
Das arbeitende Wort ist unified. Die eigenen Antworten und Meldungen der Systeme haben nichts gemeinsam, und erst ihre Normalisierung macht eine einheitliche Satzform überhaupt möglich, ob Sie sie im Maesn-Portal oder über die API lesen. Es ist dasselbe Normalisierungsprinzip wie der Fehler-Umschlag, den Sie ohnehin verarbeiten, angewandt auf die Spur, die ein Aufruf hinterlässt, statt auf die Antwort, die er liefert.
Die Frage ist selten, was kaputtging, sondern wo
Vier Orte, an denen man bei einem gescheiterten Abgleich nachsieht, und jeder sieht nur einen Teil.
Ihre eigenen Logs zeigen den Aufruf, den Sie gemacht haben, und den Fehler, den Sie bekamen. Das genügt, um zu wissen, dass stromaufwärts etwas abgelehnt hat, und genügt nicht, um zu wissen, welches System Ihres Kunden es war oder woran es sich gestört hat. Das Portal des Herstellers weiß es, falls es eines gibt und falls der Kunde Ihnen Zugang gibt, und das sind zwei Bedingungen, die oft scheitern. Der Kunde weiß, dass etwas nicht stimmt, meist zuletzt, meist in Form eines Screenshots.
Das eigentliche Problem ist die vierte Kachel. Selbst mit allen drei Quellen offen verbindet sie nichts: keine gemeinsame Kennung, keine gemeinsame Uhr und kein gemeinsames Vokabular für das Geschehene. In dieser Zuordnungsarbeit gehen die Stunden drauf, und sie wächst mit jedem System, das Sie unterstützen.
Fünf Dinge, für jeden Aufruf
Ein Log nützt nur, wenn jeder Eintrag dieselbe Form hat, denn das macht es durchsuchbar, vergleichbar und zählbar. Maesn schreibt einen Satz je API-Aufruf mit denselben fünf Feldern, ob der Aufruf an ein System mit moderner REST-API ging oder an eines, das in Dateien antwortet, und das ist der Unterschied zwischen einer Spur, der Sie folgen können, und einem Haufen herstellerspezifischer Meldungen.
Er hält fest, dass eine Übertragung stattfand, nicht die übertragenen Daten. Die Nutzlast selbst wird nicht gespeichert.
Der letzte Streifen lohnt zweimal gelesen zu werden. Der Satz hält fest, dass eine Übertragung stattfand, mit welchem Endpunkt, zu welchem System, für welche Verbindung und wann. Er bewahrt die Nutzlast nicht auf, und so verträgt sich das damit, keine Kundendaten zu speichern. Sie können belegen, was Ihre Anbindung getan hat, ohne dass Maesn behält, was sie bewegt hat.
Dieselbe Spur, in Ihren eigenen Logs
Sechs dokumentierte Felder, die auf Ihrer Seite abzulegen sich lohnt, damit Ihre Sätze zu denen von Maesn passen statt daneben zu liegen.
Keines davon braucht eine eigene Anfrage. Legen Sie context neben Ihren eigenen Fehlersätzen ab, ist ein gescheiterter Abgleich schon einem System in einem Moment zuzuordnen, und eine Supportfrage wird zum Nachschlagen. Diese Verschiebung wirkt am stärksten bei Customer-Success-Teams, weil die Antwort nicht mehr davon abhängt, wer sich an den letzten Vorfall erinnert. Zeigen Sie meta.warnings irgendwo, wo ein Nutzer es sieht, hört das Feld, das ein Zielsystem still übergeht, auf, eine Entdeckung zu sein, die Sie sechs Wochen später in einem Report machen.
Arbeit im Hintergrund hinterlässt dieselbe Art Spur. Ein asynchroner Vorgang meldet seinen Fortschritt über die Aufgabe, die er zurückgibt, Eintrag für Eintrag statt als einzelnes Urteil, und jedes Webhook-Event benennt das Objekt, um das es ging, und kommt signiert an, ein überraschendes Event lässt sich also auf einen Datensatz und auf Maesn zurückführen.
Die Systeme beobachten, die Sie nicht gebaut haben
Am meisten schmerzen im Anbindungsgeschäft die Fehler bei einem Hersteller, bei dem Sie kein Konto haben. Ein System ist eine Stunde langsam, ein Endpunkt liefert nach einer Freigabe Fehler, ein Wartungsfenster, von dem Ihnen niemand erzählt hat, fällt mitten in Ihren nächtlichen Abgleich. Sie erfahren es von einem Kunden, und das ist der schlechteste verfügbare Kanal.
Maesn beobachtet die verbundenen Systeme, ihre Endpunkte und ihren Status, ein Problem bei einem Hersteller fällt also hier auf, statt Ihnen vom betroffenen Kunden gemeldet zu werden. Ist ein System betroffen, auf dem Ihre Mandanten laufen, sagt Ihr Ansprechpartner bei Maesn Ihnen über den Kanal Bescheid, den Sie ohnehin mit uns nutzen, bei den meisten Teams ist das Slack. Die Hersteller veröffentlichen diese Hinweise in ihren eigenen Formaten und häufig in ihrer eigenen Sprache, und was Sie erreicht, ist eine Form, aus welchem System es auch kam. Was Ihre Anwendung erreicht, ist ebenfalls keine Stille, sondern ein typisierter Fehler: Ein vorübergehend nicht erreichbares System kommt als 503 mit dem Typ service_unavailable an.
Wiederholen und Takten greifen enger. Maesn wiederholt und taktet auf den asynchronen Endpunkten. Alles Synchrone reicht die 429 des Zielsystems direkt durch, Backoff und Zeitplan bleiben also bei Ihnen. Das ist der Unterschied zwischen einem Abgleich, den Sie bewusst wiederholen, und einem, der verschwunden ist.
Eine Frage, ein Ort für die Antwort
- Ihre Logs mit jedem Portal abgleichen
- Raten, aus welchem System ein Fehler kam
- Von Ausfällen durch Kunden erfahren
- Verworfene Felder erst im Report entdecken
- Das System in der Antwort benannt
- Anfragen, Antworten und Webhooks protokolliert
- Verbundene Systeme für Sie überwacht
- Übergangene Felder als Warnungen benannt
Supportkosten sind der stille Teil der Gesamtkosten einer Anbindung. Sie stehen nicht in der Bauschätzung, sie kommen danach, und sie wachsen mit der Zahl der Systeme und der Zahl der Kunden statt mit der Menge Code. Der größte Hebel darauf ist, beantworten zu können, wo etwas geschah, ohne jemanden zu fragen.
Deshalb wird das System in der Antwort benannt, statt es Ihnen zum Erschließen zu überlassen, und deshalb wird ein Feld, das ein System nicht nutzt, als Warnung gemeldet statt still verworfen. Es ist dasselbe Prinzip wie das Common Data Model: Die Unterschiede zwischen Systemen werden abgefangen, und die, die Ihnen weiterhin wichtig sind, werden mit Absicht sichtbar gemacht.
Häufige Fragen
Was genau protokolliert Maesn?
Wie lange werden die Sätze aufbewahrt?
Enthalten die Logs die Daten unserer Kunden?
Warum zählt ein vereinheitlichtes Log mehr als ein Log?
Wie erkenne ich, aus welchem System ein Fehler kam?
Sehe ich, was das Zielsystem selbst gesagt hat?
Woran erkenne ich, dass ein Feld übergangen wurde?
Wie verfolge ich einen langlaufenden Vorgang?
Lassen sich Webhook-Events einem Satz zuordnen?
Was passiert bei einem Ausfall eines verbundenen Systems?
Warum zählt das bei einer Unified API mehr als bei einer Anbindung?
Einmal bauen, auf der Unified API.
Sehen Sie, wie Unified Logging & Monitoring für Ihre Integration funktioniert, oder steigen Sie in die technische Referenz ein.