1. Qu’est-ce que Grail ? #
Un lakehouse pour toutes les données.
Le principe #
Un data lakehouse combine le stockage peu coûteux d'un data lake et les requêtes rapides d'un entrepôt de données. Grail est celui de Dynatrace : les données sont stockées sans schéma imposé ni index préparé à l'avance, et leur structure est interprétée au moment de la requête (schema on read).
| Type de données | Exemples | Commande DQL |
|---|---|---|
| Logs | journaux applicatifs, système, conteneurs | fetch logs |
| Métriques | CPU, temps de réponse, métriques personnalisées | timeseries |
| Traces (spans) | requêtes distribuées, appels de base de données | fetch spans |
| Événements | problèmes Davis, déploiements, événements métier, facturation | fetch events, fetch bizevents, fetch dt.system.events |
| Entités | hôtes, services, process groups (topologie) | fetch dt.entity.host |
Selon la version : Grail est disponible sur Dynatrace SaaS (nouvelle plateforme), pas sur Dynatrace Managed. Les environnements SaaS les plus anciens peuvent encore utiliser la gestion des logs classique tant qu'ils n'ont pas migré.
2. Collecte, buckets et rétention #
Où vont les données.
De la collecte au stockage #
Les données arrivent par le OneAgent, OpenTelemetry (OTLP), l'API d'ingestion, les extensions et les intégrations cloud. OpenPipeline les traite avant stockage : analyse des champs, masquage des données sensibles, extraction de métriques, routage vers un bucket (voir Logs avancés avec OpenPipeline).
Les buckets #
Grail range les données dans des buckets, chacun avec sa durée de rétention. Les buckets par défaut (par exemple default_logs) peuvent être complétés par des buckets dédiés : logs d'audit conservés un an, logs de debug conservés quelques jours.
Bonne pratique : Créez des buckets selon la durée de conservation et le public (équipe, sensibilité) : la rétention, les droits et le coût se pilotent alors par bucket. Détails dans La rétention des données dans Dynatrace.
3. Le langage DQL #
Des commandes enchaînées.
La syntaxe #
Une requête DQL est une suite de commandes séparées par une barre verticale | : chaque commande reçoit le résultat de la précédente. On commence par une source (fetch, timeseries), on filtre tôt, puis on transforme et on agrège.
fetch logs, from: -2h
| filter k8s.namespace.name == "boutique" and loglevel == "ERROR"
| parse content, "LD 'status=' INT:status"
| summarize erreurs = count(), by: { dt.entity.service, status }
| sort erreurs desc
| limit 10Cette requête lit deux heures de logs, garde les erreurs du namespace boutique, extrait le code de statut avec parse (motif DPL), compte les erreurs par service et par statut, puis garde les dix plus fréquentes.
timeseries cpu = avg(dt.host.cpu.usage), by: { dt.entity.host }, from: -24h
| fieldsAdd hote = entityName(dt.entity.host)
| sort arrayAvg(cpu) desc
| limit 5timeseries interroge les métriques ; entityName() remplace l'identifiant de l'hôte par son nom.
Commandes à connaître #
| Commande | Rôle |
|---|---|
fetch | lire une source : logs, spans, events, bizevents, entités |
timeseries | interroger des métriques sous forme de séries temporelles |
filter / filterOut | garder ou exclure des enregistrements |
parse | extraire des champs d’un texte (motifs DPL) |
fields / fieldsAdd / fieldsRemove | choisir, calculer ou retirer des champs |
summarize | agréger : count(), avg(), percentile()… avec by: {} |
makeTimeseries | transformer des enregistrements (logs, événements) en série temporelle |
lookup / join | enrichir avec une autre requête |
sort / limit | trier et limiter le résultat |
Pour aller plus loin : DQL en pratique et Grail et DQL avancés.
4. Exploiter les données #
Notebooks, tableaux de bord, applications, workflows.
Où utiliser une requête DQL #
| Application | Usage |
|---|---|
| Notebooks | explorer, documenter une analyse, partager une enquête |
| Dashboards | suivre des indicateurs dans des tuiles alimentées par DQL |
| Applications (Logs, Services, Kubernetes…) | analyses prêtes à l’emploi, chacune s’appuyant sur Grail |
| Workflows | exécuter une requête planifiée ou déclenchée par un événement, puis agir (notification, ticket, API) |
Exemple FinOps : un workflow hebdomadaire calcule l'utilisation moyenne du CPU et de la mémoire des machines virtuelles sur 30 jours et ouvre une demande de réduction de taille pour celles qui restent sous 30 % (voir Workflows et AutomationEngine).
5. Droits d’accès et coûts #
Gouverner Grail.
Qui voit quoi #
L'accès aux données de Grail se règle avec des politiques IAM (par exemple lecture des logs, lecture de certains buckets), éventuellement restreintes par des conditions ou des limites de politique (policy boundaries). Les segments, eux, servent à filtrer les vues, pas à donner des droits (voir Gérer les permissions).
Ce qui est facturé #
Avec la licence DPS, Grail est facturé à l'ingestion, à la rétention et aux requêtes (volume de données lu). Une requête mal ciblée sur des mois de logs coûte cher (voir Licences Dynatrace).
Erreur courante : Lancer fetch logs sans filtre de temps ni filtre précoce sur toute la rétention : le résultat est lent et la requête lit inutilement des volumes importants. Réduisez la période, filtrez dès la deuxième ligne et ciblez le bucket.