AWS, Cloudflare, Vercel, Supabase und Headless CMS – Was bleibt übrig?
Hallo, ich bin Otsuka, CTO bei Liberogic.
Im letzten Teil haben wir die Unterschiede zwischen Zugriffsprotokollen, Anwendungsprotokollen und Audit-Protokollen geklärt.
Diesmal werfen wir einen konkreteren Blick darauf, welche Art von Protokollen bei AWS, Cloudflare, Vercel, Supabase und Headless CMS verfügbar sind, die wir täglich nutzen.
Allerdings geht es hier nicht um einen detaillierten Vergleich der Preise und Funktionen der einzelnen Dienste.
Die Unterschiede zwischen den Diensten sind erheblich – sowohl was standardmäßig protokolliert wird als auch wie weit zurück man nachschauen kann. Wir verschaffen uns hier einen groben Überblick.
Leistungen | Protokolle, die hauptsächlich verfügbar sind | Ansatz zur Langzeitspeicherung | Wichtige Hinweise |
|---|---|---|---|
AWS | Ausführung, Zugriff, Verwaltungsvorgänge | CloudWatch und S3 kombinieren | Konfiguration pro Service erforderlich |
Cloudflare | Workers-Ausführung, Ausnahmen usw. | Weiterleitung zu R2 oder externen Services | Statische Bereitstellung ist separat von Ausführungsprotokollen |
Vercel | Functions, Deployment, Ausführungsprotokolle | Weiterleitung nach außen über Log Drains usw. | Speicherbereich hängt vom Plan ab |
Supabase | DB, API, Authentifizierung, Verwaltungsvorgänge | Weiterleitung nach außen über Log Drains usw. | App-spezifische Vorgänge erfordern separate Implementierung |
Headless CMS | Inhaltsaktualisierungen, Verwaltungsvorgänge | Verlauf- und Audit-Funktionen des Service nutzen | Zieloperationen und Pläne unterscheiden sich |
Datadog／Sentry | Konsolidierte Protokolle und Fehlerinformationen | Nach Verwendungszweck und Speichermenge konzipiert | „Nur durch die Implementierung entsteht noch kein Audit-Log" |
Obwohl es sich um die gleiche „Protokollierungsfunktion" handelt, unterscheiden sich die betroffenen Vorgänge und die Aufbewahrungsdauer.
Darüber hinaus ist die Anzeige im Verwaltungsbereich etwas anderes als die Speicherung über längere Zeit für Audit-Zwecke.
AWS ist zwar vollständig vorhanden, erfordert aber Konfiguration.
AWS bietet umfangreiche Dienste für Protokollverwaltung an.
Zum Beispiel werden Ausführungsstatus von Lambda und API Gateway in CloudWatch Logs erfasst. Operationen, die in der AWS-Managementkonsole oder über API durchgeführt werden, können mit CloudTrail protokolliert werden.
Grob gesagt,
- CloudWatch Logs: Überwachung des Verhaltens von Anwendungen und AWS-Services
- CloudTrail: Nachverfolgung von Benutzeraktionen in der AWS-Umgebung
- S3: Langfristige Speicherung von Protokollen
Diese Aufteilung der Verantwortung.
Da Suche, Überwachung, Benachrichtigungen und Langzeitarchivierung innerhalb von AWS zusammengefügt werden können, lässt sich diese Architektur leicht an Systeme mit strengeren Audit-Anforderungen anpassen.
Allerdings ist es nicht so, dass alles automatisch protokolliert wird, nur weil Sie AWS nutzen.
Sie müssen die Protokollausgabe für jeden verwendeten Service konfigurieren und Aufbewahrungsdauer sowie Speicherort festlegen. Da Sie große Flexibilität haben, ist eine sorgfältige Planung unerlässlich.
Cloudflare unterscheidet zwischen kurzfristiger Analyse und externer Speicherung
Bei Cloudflare Workers können Sie mit console.log() ausgegebene Inhalte und Fehler in Workers Logs einsehen.
Dies ist sehr praktisch für Überprüfungen während der Entwicklung und für aktuelle Fehlersuche, aber bei längerfristigen Audit-Trails ist es besser, sich nicht nur auf den Standard-Protokollbildschirm zu verlassen.
Bei Protokollen, die lange Zeit gespeichert werden müssen, sollten Sie eine Konfiguration in Betracht ziehen, die Logpush verwendet, um Daten an R2 oder externe Log-Management-Dienste zu senden.
Wenn Sie statische Websites mit Cloudflare Pages oder Workers bereitstellen, werden nicht alle Zugriffe im Ausführungsprotokoll des Workers protokolliert.
Die Website wird normal angezeigt, daher könnte man annehmen, dass es selbstverständlich Zugriffsprotokolle gibt, aber die Bereitstellung statischer Dateien und die Worker-Ausführung sind unterschiedliche Dinge.
Cloudflare macht es relativ einfach, kompakte Konfigurationen zu erstellen, erfordert aber ein Verständnis dafür, welche Verarbeitung wo durchläuft, um Protokolle richtig zu gestalten.
Vercel erleichtert die Überprüfung von Next.js-Protokollen
Bei Vercel können Sie Protokolle, die von Next.js Functions oder Server Actions ausgegeben werden, direkt aus dem Verwaltungsbereich überprüfen.
Da Bereitstellung und Ausführungsprotokolle nah beieinander liegen, ist die Umgebung für Entwickler übersichtlich und die tägliche Fehlersuche wird erleichtert.
Andererseits unterscheiden sich der Zeitraum, für den Protokolle abrufbar sind, und der Umfang der externen Übertragung je nach Plan.
Wenn Sie Protokolle über längere Zeit aufbewahren möchten, benötigen Sie einen anderen Mechanismus, z. B. die Verwendung von Drains, um Daten an externe Speicherorte zu senden.
Unabhängig von Vercel ist die Anzeige von Protokollen im Verwaltungsbereich etwas anderes als die Langzeitspeicherung für Auditzwecke.
Diese zwei müssen separat überprüft werden.
Supabase protokolliert viele Dinge außer Datenbankaktivitäten.
Supabase ist zwar ein auf PostgreSQL basierendes Service, besteht aber tatsächlich nicht nur aus einer Datenbank, sondern aus mehreren Funktionen wie Authentifizierung, API, Speicherung und Edge Functions.
Da Sie die einzelnen Protokolle über die Verwaltungsoberfläche einsehen können, lässt sich die Gesamtfunktion der Anwendung leicht nachverfolgbar gestalten.
Darüber hinaus gibt es Authentifizierungsprotokolle sowie Audit-Logs zur Überprüfung von Vorgängen in der Supabase-Verwaltungskonsole.
Allerdings sollte man hier beachten, dass die Verwaltungsvorgänge von Supabase und die Vorgänge innerhalb der selbst erstellten Anwendung unterschiedlich sind.
Beispielsweise kann "wer die Projekteinstellungen in Supabase geändert hat" auf der Dienstseite protokolliert werden, aber "wer Kundeninformationen in unserem eigenen Admin-Dashboard geändert hat" muss auf der Anwendungsseite protokolliert werden.
Verlauf der Headless-CMS-Vorgänge überprüfen
Bei Headless-CMS wie microCMS, Kuroco und NILTO sind Aktualisierungsverlauf für Inhalte und Bedienungsprotokolle der Verwaltungsoberfläche verfügbar.
Aufzeichnungen darüber, wer einen Artikel aktualisiert hat, wann er veröffentlicht wurde oder welche Einstellungen und Berechtigungen geändert wurden, sind wichtig als Audit-Protokoll für den Betrieb von Websites.
Allerdings unterscheiden sich die aufgezeichneten Operationen, der überprüfbare Zeitraum und die verfügbaren Pläne je nach Service.
Auch wenn Sie die Aktualisierungsverlauf von Inhalten einsehen können, bedeutet das nicht, dass alle Verwaltungsoperationen als Audit-Protokoll aufgezeichnet werden.
Darüber hinaus verfügt ein CMS grundsätzlich nur über Operationsprotokolle innerhalb des CMS selbst. Zugriffe auf die veröffentlichte Website und Fehler auf der Frontend-Seite müssen in der Hosting-Umgebung überprüft werden.
Bei Headless-CMS-Projekten ist es verständlicher, nicht nur das CMS, sondern auch das Frontend, Hosting und API als ein System zu betrachten.
Wenn Sie Datadog oder Sentry hinzufügen
Wenn Protokolle über mehrere Services verteilt sind, müssen Sie bei jedem Fehler verschiedene Admin-Dashboards öffnen und untersuchen.
Wenn Sie sie in einem Log-Management-Service wie Datadog konsolidieren, können Sie Protokolle aus mehreren Umgebungen zusammen durchsuchen und Anomalien erkennen sowie Benachrichtigungen erhalten.
Sentry wird auch häufig verwendet, aber dieser Service ist darauf spezialisiert, den Ort und den Einflussbereich von Fehlern zu ermitteln.
Beide sind praktisch, aber die Implementierung allein führt nicht automatisch zu einem vollständigen Audit-Protokoll.
Die Anwendung muss entscheiden, welche Daten ausgegeben werden, und wenn alle Protokolle über längere Zeit gespeichert werden, erhöhen sich die Kosten je nach Datenmenge.
Speichermethode | Geeignete Anwendungsfälle | Merkmale |
|---|---|---|
Verwaltungsoberfläche und Log-Management-Service | Tägliche Fehlersuche | Schnelle Durchsuchbarkeit, aber Kosten steigen mit der Speichermenge |
Speicher wie R2 oder S3 | Audit und Langzeitspeicherung von Nachweisen | Kostengünstig zu speichern, erfordert aber Abrufvorgänge bei der Recherche |
In der Praxis ist es sinnvoll, die Logs zu trennen, die Sie regelmäßig durchsuchen, von den Logs, die Sie für den Notfall aufbewahren.
Welcher Service ist der beste? Das lässt sich so nicht entscheiden.
Es ist nicht möglich, nur die Logs zu vergleichen und zu sagen, AWS sei am besten oder Cloudflare sei am besten.
Wichtig ist, was Sie für Ihr Projekt erfassen müssen.
- Fehler eines Services untersuchen
- Aktionen von Administratoren dokumentieren
- Aktualisierungsverlauf des CMS überprüfen
- Authentifizierung und Berechtigungsänderungen nachverfolgen
- Langfristige Speicherung für Audit-Zwecke
Wenn Sie wissen, was Sie benötigen, wird klar, welche Teile durch die Standardfunktionen der einzelnen Services abgedeckt sind und wo zusätzliche Lösungen erforderlich sind.
Auch wir bereiten nicht von Anfang an eine große Log-Infrastruktur vor, sondern gestalten die Konfiguration entsprechend den Anforderungen und dem Budget des Projekts.
Beim nächsten Mal werden wir uns genauer ansehen, wie diese Services kombiniert werden, welche Logs die Anwendungsseite ausgibt und wo diese gespeichert werden – wir stellen praktischere Aspekte vor.
Naja dann.
Das Rückgrat der Technologieabteilung von Liberogic. Wenn sie einen Wunsch hört wie "Ich würde mir das wünschen, das wäre praktisch" – setzt sie ihn sofort mit ihrem natürlichen Gespür um und verleiht der Lösung noch zusätzlichen Mehrwert. Sie ist ein Schatz unseres Unternehmens mit großem Geschick in der Kommunikation und vielen begeisterten Kunden – und eine absolute Katzenliebhaberin.
Sho Otsuka
Geschäftsführender CTO / Chief Engineer / Vertreter der Godo Kaisha Neko Ana / Sieht unnötig jung aus