Architecture de la plateforme Datadog

1. Vue d'ensemble #

Une plateforme SaaS, plusieurs produits.

Architecture #

Datadog est une plateforme SaaS : il n'y a rien à héberger côté serveur. Les données arrivent par l'agent (installé sur les hôtes et les nœuds Kubernetes), par les intégrations cloud (lecture des API AWS, Azure, GCP), par les SDK (APM, RUM, mobile) ou par OpenTelemetry. Tous les produits partagent le même modèle : des données horodatées et des tags.

2. Sites et organisations #

Où vivent les données.

Sites #

Erreur Courante : Le site se choisit à la création de l'organisation et ne se change pas ensuite. Pour des données soumises au RGPD, choisissez EU1 dès le départ, et configurez DD_SITE=datadoghq.eu partout : un agent configuré sur le mauvais site envoie ses données dans le vide.

Une organisation regroupe utilisateurs, données et facturation. Les grandes entreprises utilisent des organisations enfants par entité, rattachées à une organisation parente pour la facturation.

3. Les clés #

Sécuriser l'accès.

Clés et jetons #

• Une clé d'API par usage (production, préproduction, CI), pour pouvoir en révoquer une sans tout casser.
• Les clés d'application héritent des droits de leur utilisateur : préférez des service accounts pour l'automatisation, avec des scopes limités.
• Le client token est public par nature (il est dans le code JavaScript) : il ne permet que l'envoi de données RUM et logs navigateur.

4. Le modèle de données #

Tout passe par les tags.

Tagging unifié #

Le tagging de service unifié repose sur trois tags réservés, posés partout de la même façon : env, service, version. Ce sont eux qui relient une métrique, un log, une trace et une session RUM du même service.

À savoir : Chaque produit a son modèle de facturation : l'article « Coûts et gouvernance » de cette formation détaille comment suivre et maîtriser la consommation.