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

L'app QuickStart de Dynatrace : obtenir ses premières données en quelques minutes

Découvrir l'app QuickStart : ajouter des données avec Auto Discovery ou une tuile dédiée, lire les Findings, …

L'app Investigations de Dynatrace : mener une enquête sur les données de Grail

Découvrir l'app Investigations : requêtes DQL, extraction avec DPL Architect, enrichissement, arbre de requêt…

Site Reliability Guardian dans Dynatrace

Valider automatiquement une mise en production avec des objectifs de disponibilité, de performance et de capa…

Pour aller plus loin

Soutenir

♥ SOUTENIR

Soutenez RousselTM Learning

Les formations, articles, TP et attestations restent gratuits et sans publicité intrusive. Une contribution libre, du montant de votre choix, finance l’hébergement, les environnements de TP et l’écriture de nouveaux contenus.

Contribuer avec PayPal Montant libre · carte bancaire ou compte PayPalEn savoir plus
QR code PayPal
Ou scannez ce QR code avec votre téléphone

Merci, chaque contribution compte !