AWS, Cloudflare, Vercel, Supabase, headless CMS: wat blijft er over?
Hallo, ik ben Otsuka, CTO bij Liberogic.
Eerder hebben we de verschillen tussen toegangslogboeken, applicatielogboeken en auditlogboeken onderzocht.
Deze keer kijken we concreter naar wat voor logs beschikbaar zijn in de services die we regelmatig gebruiken: AWS, Cloudflare, Vercel, Supabase en headless CMS.
Dit gaat echter niet over een gedetailleerde vergelijking van prijzen en functies per service.
Omdat elke service qua karakteristieken aanzienlijk verschilt in "wat standaard wordt bewaard" en "wat u later nog kunt controleren", ordenen we dit globaal.
Diensten | Primair beschikbare logs | Benadering voor langdurige opslag | Opmerkingen |
|---|---|---|---|
AWS | Uitvoering, toegang, beheerbewerkingen | Cloudflare CloudWatch en S3 combineren | Configuratie per service vereist |
Cloudflare | Workers-uitvoering, uitzonderingen, enzovoort | Doorsturen naar R2 of externe services | Statische levering gescheiden van uitvoeringslogboeken |
Vercel | Functions, implementatie, uitvoeringslogboeken | Doorsturen naar externe services via Log Drains en dergelijke | Opslagbereik afhankelijk van plan |
Supabase | Database, API, authenticatie, beheerbewerkingen | Doorsturen naar externe services via Log Drains en dergelijke | App-specifieke bewerkingen vereisen afzonderlijke implementatie |
Headless CMS | Content-updates, beheersoperaties | Gebruik van servicehistorie- en auditfuncties | Doeloperaties en abonnementen verschillen |
Datadog／Sentry | Geconsolideerde logboeken, foutinformatie | Ontworpen op basis van gebruik en opslagcapaciteit | Implementatie alleen leidt niet tot een auditlogboek |
Zelfs bij dezelfde 'logboekfunctie' kunnen de doeloperaties en opslagperiode verschillen.
Bovendien is het weergeven in het beheersscherm iets anders dan het lange termijn bewaren voor audit doeleinden.
AWS heeft alles in zich, maar configuratie is nodig
AWS beschikt over aanzienlijke logboekgerelateerde services.
Bijvoorbeeld, de uitvoering van Lambda en API Gateway wordt verzameld in CloudWatch Logs. Bewerkingen die in de AWS-beheerconsole of via API zijn uitgevoerd, kunnen worden geregistreerd in CloudTrail.
Kort gezegd:
- CloudWatch Logs: het gedrag van applicaties en AWS-services monitoren
- CloudTrail: zien wie wat in uw AWS-omgeving heeft gedaan
- S3: logboeken langdurig opslaan
Dit is de verdeling van verantwoordelijkheden.
Omdat zoeken, monitoring, meldingen en langdurige opslag allemaal in AWS kunnen worden samengesteld, is dit een configuratie die gemakkelijk aan stelsels met sterke auditsvereisten kan voldoen.
Maar 'omdat we AWS gebruiken, wordt alles automatisch opgeslagen' is niet waar.
U moet logoutvoer per service configureren en ook bepalen hoelang en waar u wilt opslaan. Vanwege de hoge mate van flexibiliteit is een grondige opzet een vereiste.
Cloudflare scheidt onderzoek op korte termijn en externe opslag
Met Cloudflare Workers kunt u de uitvoer van console.log() en fouten weergeven in Workers Logs.
Dit is erg handig voor verificatie tijdens ontwikkeling en onderzoek van recente storingen, maar voor het bewaren van audittrails gedurende lange perioden is het beter om niet alleen op het standaard logscherm te vertrouwen.
Voor logbestanden die langdurig moeten worden bewaard, overweeg je een configuratie die Logpush of vergelijkbare tools gebruikt om naar R2 of externe logbeheerdiensten te sturen.
Bovendien: als je statische websites aanbiedt via Cloudflare Pages of Workers, worden niet alle toegangen in het uitvoeringslogboek van Worker geregistreerd.
De site wordt normaal weergegeven, dus je zou kunnen denken: "Natuurlijk zijn er ook toegangslogs." Maar het versturen van statische bestanden en de uitvoering van Workers zijn twee verschillende dingen.
Cloudflare maakt het relatief eenvoudig om compacte configuraties op te bouwen, maar je moet begrijpen welke verwerking via welk onderdeel loopt om de logs correct in te richten.
Vercel maakt Next.js-logboeken gemakkelijk zichtbaar
Bij Vercel kun je logboeken controleren die zijn gegenereerd door Next.js Functions, Server Actions en dergelijke rechtstreeks vanuit het beheerdashboard.
Omdat implementatie en uitvoeringslogboeken dicht bij elkaar liggen, is het duidelijk voor ontwikkelaars en makkelijk om dagelijks fouten op te sporen.
Aan de andere kant verschilt de periode waarvoor je logboeken kunt raadplegen en het bereik van externe overdracht afhankelijk van je abonnement.
Wil je logboeken lange tijd bewaren, dan heb je aanvullende mechanismen nodig, zoals het gebruik van Drains om naar externe opslaglocaties te sturen.
Los van Vercel, het feit dat logs in het beheerpaneel worden weergegeven en dat deze voor audit-doeleinden langdurig worden opgeslagen, zijn twee verschillende zaken.
Het is belangrijk om deze twee afzonderlijk te controleren.
Supabase genereert veel logs buiten de database om
Supabase is een service gebaseerd op PostgreSQL, maar bestaat in werkelijkheid uit meerdere functies naast de database: authenticatie, API, opslag en Edge Functions.
Een kenmerk hiervan is dat elk log vanuit het beheerpaneel kan worden gecontroleerd, waardoor het gemakkelijk is om de werking van de gehele applicatie te volgen.
Daarnaast zijn er ook logs met betrekking tot authenticatie en auditlogs voor het controleren van bewerkingen die in het Supabase-beheerpaneel worden uitgevoerd.
Maar ook hier moet je voorzichtig zijn: Supabase-beheerbewerkingen en bewerkingen binnen je eigen gemaakte applicatie zijn twee verschillende dingen.
Bijvoorbeeld: terwijl 'wie projectinstellingen in Supabase heeft gewijzigd' door de service kan worden geregistreerd, moet 'wie klantgegevens in ons beheerpaneel heeft gewijzigd' door de applicatie zelf worden geregistreerd.
Controleer ook de bewerkingsgeschiedenis van headless CMS
Headless CMS-platforms zoals microCMS, Kuroco en NILTO bieden updategeschiedenis van content en operationele logs van het beheerpaneel.
Wie een artikel heeft bijgewerkt, wanneer het is gepubliceerd, en of instellingen of machtigingen zijn gewijzigd — dergelijke registraties zijn belangrijk als auditlogboeken voor websitebeheer.
De geregistreerde bewerkingen, de periode waarin deze kunnen worden gecontroleerd en de beschikbare plannen verschillen echter per service.
Ook al kunt u de update-geschiedenis van inhoud controleren, niet alle beheerbewerkingen worden noodzakelijk als auditlogboeken vastgelegd.
Bovendien beschikt een CMS in principe alleen over bewerkingsregistraties binnen de CMS zelf. Toegang tot de gepubliceerde website en fouten die aan de frontend-kant optreden, moeten in de hostingomgeving worden gecontroleerd.
Bij headless CMS-projecten is het helderder om de CMS, frontend, hosting en API als één systeem te beschouwen.
Bij toevoeging van Datadog of Sentry
Wanneer logboeken over meerdere services zijn verdeeld, moet u elke keer dat er een storing optreedt, de verschillende beheerschermen openen om het te onderzoeken.
Wanneer u logboeken samenvat in een logbeheerservice zoals Datadog, kunt u logboeken van meerdere omgevingen gezamenlijk doorzoeken en afwijkingen detecteren om meldingen te verzenden.
Sentry wordt ook veel gebruikt, maar dit service is vooral geschikt voor het onderzoeken waar fouten zich voordoen en wat hun impact is.
Beide zijn handig, maar implementatie ervan betekent niet automatisch dat auditlogboeken volwaardig zijn.
De toepassing moet bepalen wat er moet worden uitgevoerd, en als u alle logboeken voor langere tijd opslaat, nemen de kosten toe naarmate de hoeveelheid gegevens groeit.
Opslagmethode | Geschikte gebruikssituaties | Kenmerken |
|---|---|---|
Beheerdashboard · Logbeheerservice | Dagelijkse foutopsporing | Snel doorzoekbaar, maar de kosten nemen toe naarmate de opslagcapaciteit groter wordt |
Opslag zoals R2 · S3 | Controle en lange termijn bewaring van audittrails | Goedkoop om op te slaan, maar moet worden opgehaald wanneer onderzoeken nodig zijn |
In de praktijk is het verstandig om logboeken die u regelmatig raadpleegt te scheiden van logboeken die u voor noodgevallen bewaart.
Welke service is het beste? Dat kun je niet zo bepalen.
Je kunt niet alleen logboeken vergelijken en zeggen dat AWS het beste is, of dat Cloudflare het beste is.
Wat belangrijk is, is wat je voor dit project moet registreren.
- Ik wil fouten in de service onderzoeken.
- Ik wil de handelingen van beheerders bijhouden.
- Ik wil de updategeschiedenis van de CMS controleren.
- Ik wil authenticatie en wijzigingen van machtigingen volgen.
- Ik wil lange tijd voor audit opslaan.
Wanneer je weet wat je nodig hebt, kun je zien welke delen je met de standaardfuncties van elke service kunt aanpakken en welke delen aanvullende maatregelen vereisen.
We stellen niet vanaf het begin een groot logboekingsysteem in, maar passen de configuratie aan op basis van de projectvereisten en het budget.
De volgende keer kijken we naar de praktische vraag: welke logboeken dient de applicatie uit te voeren en waar worden deze opgeslagen wanneer dergelijke services worden gecombineerd?
Tot ziens.
De ruggengraat van Liberogics technische afdeling. Als we horen 'ik wou dat we dit hadden, het zou erg handig zijn', voegt deze persoon met aangeboren slimheid direct meerwaarde toe en implementeert het in een mum van tijd. Met uitstekende communicatievaardigheden en veel fans onder onze klanten: de schat van ons bedrijf, en iemand die gek is op katten.
Shō Ōtsuka
Directeur CTO / Chief Engineer / Directeur van Nekoana LLC / Onredelijk jong uitziend