AWS, Cloudflare, Vercel, Supabase, et CMS headless : qu'en est-il des journaux ?
Bonjour, je suis Otsuka, CTO chez Liberogic.
Précédemment, nous avons clarifié les différences entre les journaux d'accès, les journaux d'application et les journaux d'audit.
Cette fois, nous allons examiner plus précisément les types de journaux disponibles dans les services que nous utilisons habituellement : AWS, Cloudflare, Vercel, Supabase et CMS headless.
Cela dit, il ne s'agit pas de comparer en détail les tarifs et fonctionnalités de chaque service.
Les caractéristiques varient considérablement d'un service à l'autre en termes de « ce qui est conservé par défaut » et « jusqu'où on peut remonter après coup », nous allons donc les clarifier globalement.
Services | Journaux principalement disponibles | Approche de la conservation à long terme | Points à noter |
|---|---|---|---|
AWS | Exécution, accès et opérations de gestion | Combiner CloudWatch et S3 | Configuration requise par service |
Cloudflare | Exécution de Workers, exceptions, etc. | Transférer vers R2 ou des services externes | La diffusion statique est distincte des journaux d'exécution |
Vercel | Functions, déploiement, journaux d'exécution | Transférer vers l'extérieur via Log Drains, etc. | La plage de conservation dépend du plan |
Supabase | DB, API, authentification, opérations de gestion | Transférer vers l'extérieur via Log Drains, etc. | Les opérations spécifiques à l'application doivent être implémentées séparément |
Headless CMS | Mise à jour de contenu, opérations de gestion | Utiliser les fonctionnalités d'historique et d'audit du service | Les opérations et plans ciblés diffèrent |
Datadog／Sentry | Journaux agrégés, informations d'erreur | Conçu en fonction de l'utilisation et de la capacité de stockage | Le simple déploiement ne constitue pas un journal d'audit |
Même avec la même « fonction de journalisation », les opérations ciblées et les périodes de conservation diffèrent.
De plus, le fait que quelque chose soit affiché dans le panneau d'administration et le fait qu'il soit conservé à long terme à des fins d'audit sont deux choses différentes.
AWS offre une gamme complète, mais une configuration est nécessaire
AWS dispose d'une gamme très complète de services liés aux journaux.
Par exemple, l'exécution de Lambda ou API Gateway est collectée dans CloudWatch Logs. Les opérations effectuées via la console de gestion AWS ou l'API peuvent être enregistrées avec CloudTrail.
En résumé,
- CloudWatch Logs : visualiser le fonctionnement des applications et des services AWS
- CloudTrail : voir qui a fait quoi dans l'environnement AWS
- S3 : stocker les journaux à long terme
voilà le partage des rôles.
La recherche, la surveillance, les notifications et la conservation à long terme peuvent être configurées au sein d'AWS, ce qui en fait une architecture facile à adapter aux systèmes soumis à des exigences strictes d'audit.
Cependant, « utiliser AWS » ne signifie pas « tout est automatiquement conservé ».
Il est nécessaire de configurer la sortie des journaux pour chaque service utilisé, et de déterminer également la période de rétention et la destination de stockage. Puisque la flexibilité est élevée, une conception appropriée est un prérequis.
Cloudflare sépare les investigations à court terme de la conservation externe
Avec Cloudflare Workers, vous pouvez consulter dans Workers Logs le contenu affiché par console.log() et les erreurs.
C'est très pratique pour vérifier le développement en cours ou enquêter sur les défaillances récentes, mais pour conserver des traces d'audit à long terme, il est préférable de ne pas se limiter à l'écran de journal standard.
Pour les journaux qui nécessitent une conservation à long terme, envisagez une architecture qui envoie les données vers R2 ou un service de gestion des journaux externe via Logpush ou un outil similaire.
De plus, lorsqu'un site Web statique est distribué via Cloudflare Pages ou Workers, tous les accès ne sont pas nécessairement enregistrés dans les journaux d'exécution de Worker.
Le site s'affiche normalement, ce qui peut nous faire croire que « les journaux d'accès existent certainement », mais la distribution de fichiers statiques et l'exécution de Worker sont deux choses distinctes.
Bien que Cloudflare facilite la création d'architectures relativement compactes, il est nécessaire de comprendre quels traitements passent par quel chemin pour concevoir les journaux correctement.
Vercel simplifie la consultation des journaux Next.js
Chez Vercel, vous pouvez consulter les journaux produits par les Fonctions Next.js, les Server Actions et d'autres éléments via le tableau de bord d'administration.
Le déploiement et les journaux d'exécution se trouvant à proximité, cela offre aux développeurs une meilleure clarté et facilite l'enquête quotidienne sur les erreurs.
En revanche, la durée pendant laquelle les journaux peuvent être consultés et la portée des transferts externes varient selon le forfait choisi.
Si vous souhaitez conserver les journaux longtemps, vous devrez mettre en place un mécanisme alternatif, comme utiliser Drains pour envoyer les données vers une destination de stockage externe.
Chez Vercel comme ailleurs, l'affichage des journaux dans l'interface d'administration et leur conservation à long terme à des fins d'audit sont deux choses différentes.
Il est nécessaire de vérifier ces deux éléments séparément.
Supabase génère de nombreux journaux au-delà de la base de données
Supabase est un service centré sur PostgreSQL, mais il se compose en réalité de plusieurs fonctionnalités : base de données, authentification, API, stockage et Edge Functions.
Chaque journal peut être consulté depuis l'interface d'administration, ce qui facilite le suivi du comportement global de l'application.
Il existe également des journaux relatifs à l'authentification et des journaux d'audit pour vérifier les opérations effectuées dans l'interface d'administration de Supabase.
Cependant, il est important de noter ici que les opérations de gestion de Supabase et les opérations au sein de l'application que vous avez créée sont deux choses différentes.
Par exemple, bien que le service puisse enregistrer « qui a modifié les paramètres du projet Supabase », l'enregistrement de « qui a modifié les informations clients dans votre interface d'administration » doit être effectué au niveau de l'application.
Vérifiez également l'historique des opérations du headless CMS
Les headless CMS comme microCMS, Kuroco et NILTO proposent un historique des mises à jour de contenu et des journaux d'opérations de l'interface d'administration.
Les enregistrements tels que la personne qui a mis à jour un article, quand il a été publié, ou les modifications apportées aux paramètres et aux autorisations sont importants en tant que journaux d'audit pour la gestion d'un site web.
Cependant, les opérations enregistrées, la période que vous pouvez vérifier et le forfait disponible varient selon le service.
Même si vous pouvez vérifier l'historique des mises à jour de contenu, toutes les opérations de gestion ne sont pas nécessairement enregistrées dans le journal d'audit.
De plus, un CMS enregistre essentiellement les opérations effectuées au sein du CMS lui-même. Les accès au site web publié et les erreurs survenant côté frontend doivent être vérifiés dans l'environnement d'hébergement.
Dans les projets de headless CMS, il est plus facile de comprendre le système en considérant le CMS, le frontend, l'hébergement et l'API comme un seul système.
Lorsque vous ajoutez Datadog ou Sentry
Quand les journaux sont dispersés sur plusieurs services, vous devez ouvrir chaque tableau de bord d'administration et enquêter à chaque fois qu'une panne survient.
Lorsque vous agrégez les journaux dans un service de gestion de journaux comme Datadog, vous pouvez rechercher les journaux de plusieurs environnements ensemble et détecter les anomalies pour recevoir des notifications.
Sentry est également très utilisé, mais ce service excelle dans la détection du lieu d'occurrence des erreurs et de leur portée d'impact.
Les deux sont utiles, mais leur mise en œuvre n'aboutit pas automatiquement à un journal d'audit complet.
L'application doit décider ce qu'elle enregistre, et conserver tous les journaux pendant longtemps augmente les coûts proportionnellement au volume de données.
Méthode de stockage | Cas d'usage appropriés | Caractéristiques |
|---|---|---|
Service de gestion des journaux et tableau de bord d'administration | Enquêtes sur les incidents courants | Recherche immédiate possible, mais les coûts augmentent avec le volume de stockage |
Stockage R2, S3 et autres solutions similaires | Conservation à long terme des audits et pistes d'accès | Solution économique mais nécessite une extraction lors de l'investigation |
Il est réaliste de séparer les journaux que vous consultez régulièrement de ceux que vous conservez pour usage en cas de problème.
Impossible de déterminer quel service est le meilleur
On ne peut pas décider qu'AWS ou Cloudflare est le meilleur en comparant uniquement les journaux.
Ce qui importe, c'est de déterminer ce qu'il est nécessaire d'enregistrer pour votre projet.
- Je veux enquêter sur les erreurs de service
- Je veux conserver un historique des opérations des administrateurs
- Je veux vérifier l'historique des mises à jour du CMS
- Je veux suivre les modifications d'authentification et de droits d'accès
- Je veux conserver les journaux longtemps à des fins d'audit
Une fois que vous savez ce dont vous avez besoin, vous pouvez identifier les fonctionnalités standard de chaque service qui peuvent vous convenir et les parties qui nécessitent une mise en place supplémentaire.
Nous non plus, nous ne mettons pas en place une infrastructure de journalisation volumineuse dès le départ, mais nous adaptons la configuration selon les exigences et le budget du projet.
La prochaine fois, nous verrons comment, lorsque ces services sont combinés, l'application émet les journaux appropriés et où les stocker. Nous vous présenterons quelque chose de plus proche de la pratique réelle.
Bon, à bientôt.
Le pilier du département technique de Liberogic. Dès qu'il entend « J'aimerais bien avoir ça, ce serait pratique », il se met au travail avec sa créativité naturelle et ajoute de la valeur en un rien de temps. Avec ses excellentes compétences en communication et ses nombreux fans parmi nos clients, c'est un trésor de l'entreprise — et passionné par les chats.
Shō Ōtsuka
Directeur technique / Ingénieur en chef / Représentant de Neko-Ana LLC / Étonnamment jeune d'apparence