RousselTMLEARNING

Observabilité

DQL en pratique : explorer logs et événements, notebooks, tableaux de bord et performance

Utiliser le Dynatrace Query Language au quotidien : explorer logs et événements, enchaîner les commandes, analyser des champs, créer des séries temporelles, partager dans des notebooks et tableaux de bord, et écrire des requêtes performantes.

1. Explorer logs et événements #

Les premières requêtes.

Commandes de base #

Pipeline DQL
Chaque commande reçoit le résultat de la précédente.
fetch logs, from: now() - 2h
| filter loglevel == "ERROR" and k8s.namespace.name == "boutique"
| summarize erreurs = count(), by: {dt.entity.service}
| sort erreurs desc
| limit 10
fetch events, from: now() - 24h
| filter event.kind == "DAVIS_PROBLEM"
| fields timestamp, event.name, event.status, affected_entity_ids

Les sources courantes : logs, events, bizevents, spans, dt.entity.* (entités) et les séries temporelles avec timeseries.

2. Enrichir les requêtes #

Analyser et transformer.

Exemples #

// Extraire des champs d'un log texte (DPL)
fetch logs
| filter matchesPhrase(content, "paiement")
| parse content, "LD 'montant=' INT:montant LD 'client=' WORD:client"
| summarize total = sum(montant), by: {client}

// Transformer des logs en série temporelle
fetch logs
| filter loglevel == "ERROR"
| makeTimeseries erreurs = count(), by: {dt.entity.service}, interval: 5m

// Relier traces et logs
fetch spans
| filter duration > 2s and service.name == "checkout"
| fields trace.id, span.name, duration

Notebooks et tableaux de bord #

Un notebook enchaîne requêtes, graphes et texte : idéal pour une enquête ou un post-mortem partagé. Une requête validée se transforme en tuile de tableau de bord, éventuellement avec des variables (service, espace de noms).

Bonne Pratique : Davis CoPilot propose de générer une requête DQL à partir d'une question en langage naturel : un bon point de départ, à relire avant de l'enregistrer.

3. Écrire des requêtes performantes #

Lire moins de données.

Bonnes pratiques #

RèglePourquoi
Plage de temps courteLa quantité de données lues dépend d'abord de la période
Filtrer tôt, sur des champs indexés ou de bucketRéduit le volume analysé par les commandes suivantes
fields / fieldsKeep pour ne garder que l'utileMoins de données à transporter et afficher
summarize plutôt que lire des milliers de lignesLe calcul se fait côté Grail
limit en fin de requêteÉvite des résultats énormes
Préférer matchesPhrase à contains sur du texteUtilise mieux les index
Erreur Courante : Selon le modèle de licence, les requêtes sur les logs peuvent être facturées au volume lu : une requête sur 30 jours sans filtre, exécutée toutes les minutes par un tableau de bord, coûte cher. Voir aussi l'article « Grail : Dynatrace Data Lakehouse ».

Articles liés

ActiveGate et network zones : architecture, routage et haute disponibilité

Comprendre et déployer ActiveGate dans Dynatrace : rôles (routage, API, intégrations cloud, extensions, empla…

Dynatrace Operator sur Kubernetes : DynaKube, modes de supervision et dépannage

Superviser Kubernetes avec le Dynatrace Operator : installation Helm, ressource DynaKube, modes cloudNativeFu…

OpenTelemetry et Dynatrace : OTLP, collecteur et instrumentation

Intégrer OpenTelemetry à Dynatrace : endpoint OTLP et jetons, Dynatrace OTel Collector, traces, métriques (te…

Pour aller plus loin