Puit de logs Azure : de la collecte à la création de tickets

azure
devops
monitoring
terraform
retour-experience
Author

Sylvain Pham

Published

February 17, 2026

Azure a tous les outils pour collecter des logs. Diagnostic Settings, Azure Monitor Agent, Log Analytics Workspace, KQL… la plomberie est solide. Mais quand il s’agit d’agir sur ces logs, il n’y a rien de simple. Pas de bouton “créer un ticket” à côté d’une ligne d’erreur. Pas d’interface qui combine la consultation et l’action sans friction.

On m’a demandé de mettre en place un puit de logs centralisé sur Azure, dimensionné pour une centaine de ressources (App Services, VMs, outils tiers). L’idée n’était pas juste de collecter : c’était de montrer que les logs peuvent déclencher des actions concrètes, sans naviguer entre 3 portails.

Pas de Datadog. Pas de Splunk. Juste Azure Monitor, un Log Analytics Workspace, et un dashboard Express.js sur un App Service F1 gratuit.

Le dashboard : logs centralisés, graphique d’activité et bouton Ticket par ligne

Le contexte

Une centaine de ressources Azure (App Services, VMs, outils DevSecOps), des logs éparpillés partout, et personne pour les consulter au quotidien. Les erreurs passent inaperçues.

L’objectif : montrer que centraliser les logs ne sert pas qu’à cocher une case conformité. Ça peut déclencher des actions opérationnelles automatiquement.

L’architecture : trois sources, un puit

flowchart TD
    subgraph Sources["Sources de logs"]
        S1["App Service<br/>(stdout/stderr)"]
        S2["VM Linux<br/>(syslog)"]
        S3["Outil tiers<br/>(syslog)"]
    end

    subgraph LAW["Log Analytics Workspace"]
        L1["AppServiceConsoleLogs"]
        L2["Syslog"]
    end

    S1 -->|Diagnostic Settings| L1
    S2 -->|AMA + DCR| L2
    S3 -->|AMA + DCR| L2

    subgraph Dashboard["Dashboard Express.js"]
        D1["Consultation des logs"]
        D2["Bouton Ticket"]
    end

    LAW --> D1
    D2 --> ADO["Azure DevOps<br/>Work Item"]

Deux mécanismes de collecte natifs Azure :

Source Méthode Table KQL
App Service (PaaS) Diagnostic Settings AppServiceConsoleLogs
VM Linux (IaaS) Azure Monitor Agent + Data Collection Rule Syslog
Outil tiers sur VM Même AMA, même DCR Syslog (filtré par hostname)

Zéro agent custom. Tout passe par les mécanismes natifs Azure. La VM reçoit l’Azure Monitor Agent via Ansible, piloté par une Data Collection Rule Terraform.

Le dashboard : voir les logs sans toucher au portail Azure

Le portail Azure est puissant mais pas fait pour le monitoring quotidien par des équipes non-Azure. J’ai donc construit un dashboard web léger (Express.js, Node 20) déployé sur un App Service F1 gratuit.

Ce qu’il fait :

  • Affiche les logs des 3 sources dans des onglets séparés
  • Requête le LAW directement via managed identity (RBAC Log Analytics Reader)
  • Graphique d’activité en temps réel
  • Bouton “Ticket” sur chaque ligne de log → création d’un Bug dans Azure DevOps

C’est ce dernier point qui a rendu le POC intéressant pour le client.

La partie qui a rendu le POC intéressant : log → ticket en un clic

Le problème

Sans notre dashboard, créer un ticket à partir d’un log demande :

  1. Aller dans le portail Azure, ouvrir le LAW, écrire une requête KQL
  2. Trouver le log, copier le timestamp, le message, la source
  3. Aller dans Azure DevOps, créer un Bug, coller les infos manuellement

~3 minutes, 2 portails, plusieurs copier-coller. Personne ne le fait.

La solution : deux modes

Mode manuel : l’opérateur survole un log dans le dashboard, clique “Ticket”, un Bug est créé dans Azure DevOps avec toutes les infos pré-remplies. 2 secondes.

sequenceDiagram
    actor Op as Opérateur
    participant Dash as Dashboard
    participant Srv as Express.js
    participant ADO as Azure DevOps

    Op->>Dash: Survole un log
    Op->>Dash: Clic sur Ticket
    Dash->>Srv: POST /api/workitem
    Srv->>ADO: POST workitems/$Bug
    ADO-->>Srv: 200 OK
    Dash->>Op: Toast "Ticket créé"

Mode automatique : Azure Monitor exécute une requête KQL toutes les 5 minutes. Si des erreurs sont détectées, un webhook appelle le dashboard qui crée le ticket automatiquement.

sequenceDiagram
    participant App as App Service
    participant LAW as LAW
    participant Alert as Alert Rule
    participant AG as Action Group
    participant Srv as Express.js
    participant ADO as Azure DevOps

    App->>LAW: Log erreur
    Note over LAW: Ingestion 5-10 min
    Alert->>LAW: KQL toutes les 5 min
    LAW-->>Alert: Erreur trouvée
    Alert->>AG: Alerte Sev 2
    AG->>Srv: POST /api/alert-webhook
    Srv->>ADO: POST workitems/$Bug
    Note over ADO: Bug auto-created

Les tickets manuels portent le tag manuel, les automatiques auto-created. Ça permet de tracer qui a déclenché quoi.

Les alternatives natives que j’ai évaluées

Avant de coder un dashboard custom, j’ai regardé les options natives Azure :

Approche Affiche les logs Bouton par ligne Code custom
Azure Workbooks + Logic App Oui (KQL natif) Lien possible Non
Grafana + plugin Azure Oui Non Config
Power BI + Power Automate Oui Bouton possible Non
Dashboard custom (notre choix) Oui Oui Oui

Le combo Workbooks + Logic App est le plus proche en natif : le Workbook affiche les résultats KQL dans le portail Azure, et un Logic App avec HTTP trigger peut créer un Work Item via le connecteur DevOps natif (pas besoin de PAT ni d’API REST).

Pourquoi le dashboard custom pour le POC :

  • Accessible sans compte Azure AD (Basic Auth suffit)
  • Plus impactant en démo : on voit le log et on clique au même endroit
  • Combine logs locaux, logs LAW, graphique et tickets dans une seule page
  • Le F1 est gratuit, ça coûte 0€

En production, je recommanderais de garder le dashboard pour le mode manuel et de basculer le mode auto sur un Logic App pour bénéficier du retry natif et du monitoring intégré.

L’IaC : Terraform pour tout sauf le code applicatif

Tout est dans Terraform :

  • App Service Plan + Web App + Diagnostic Settings
  • Alert Rule (KQL scheduled query)
  • Action Group (webhook)
  • App Settings (dont le PAT Azure DevOps en variable sensible)

Et pour la VM de démo : Terraform pour le provisionning, Ansible pour l’installation de l’AMA.

Piège rencontré : terraform apply sans terraform.tfvars remet le PAT à vide (valeur par défaut ““). Le dashboard affiche”PAT non configuré” et plus rien ne marche. Toujours avoir le .tfvars avec les secrets, et le .gitignore avec *.tfvars.

Les galères

RBAC : Contributor ne suffit pas

La managed identity de l’App Service a besoin du rôle Log Analytics Reader pour requêter le LAW. Mon compte (Contributor) ne peut pas attribuer de rôles RBAC. Il faut Owner ou User Access Administrator.

Workaround temporaire : un script qui exécute la requête KQL via az CLI et pousse les résultats dans un cache sur le dashboard. Ça a permis de continuer à développer en attendant qu’un admin attribue le rôle.

Le PAT écrasé par Terraform

Je configure le PAT manuellement via az webapp config appsettings set. Ça marche. Puis je fais un terraform apply pour autre chose. Terraform remet le PAT à “” parce que la variable a une valeur par défaut vide.

Le pattern “variable sensible avec default vide” est un piège classique. Soit on force un terraform.tfvars, soit on accepte que chaque apply puisse casser quelque chose silencieusement.

La latence LAW : 5-10 minutes incompressibles

Entre le moment où l’app écrit un log et le moment où il est requêtable en KQL : 5 à 10 minutes. C’est documenté par Microsoft, mais en pratique ça rend le debugging frustrant. On génère une erreur, on attend, on recharge, rien… puis 7 minutes plus tard, tout apparaît d’un coup.

Pour le mode automatique, ça signifie un délai total de 10-15 minutes entre l’erreur et la création du ticket.

Les chiffres

Métrique Valeur
Sources de logs 3
Dashboard Express.js sur App Service F1 gratuit
Temps log → ticket (manuel) 2 secondes
Temps log → ticket (auto) 10-15 minutes
Coût infra supplémentaire ~0€
Documentation 6 pages MkDocs
IaC Terraform + Ansible

Ce que j’en retiens

Le LAW est sous-estimé

La plupart des équipes Azure ont un Log Analytics Workspace qui collecte des logs… que personne ne consulte. Ajouter un dashboard simple et un mécanisme de ticket transforme un outil passif en outil actionnable.

F1 gratuit, c’est suffisant pour un POC

Un App Service F1 Linux avec Express.js fait le job pour un dashboard de monitoring. Les limitations (cold start, 60 min CPU/jour) n’ont pas été un problème.

Le vrai ROI d’un puit de logs, c’est l’action

Collecter des logs, c’est nécessaire. Les rendre consultables, c’est bien. Les transformer en tickets, c’est ce qui justifie le projet auprès du métier. “On détecte les erreurs ET on crée des tickets automatiquement”. Ça parle à tout le monde.

Il manque une couche UX dans l’écosystème Azure

Azure Monitor est excellent pour la plomberie : collecter, stocker, requêter. Mais entre “je vois un log d’erreur” et “un ticket existe dans mon backlog”, il y a un trou. Aucun outil natif ne propose une interface sans friction pour transformer un log en action. On est obligé soit de naviguer entre portails, soit de coder un dashboard custom. C’est un vrai manque dans l’écosystème, et c’est ce qui rend ce type de POC utile : montrer ce que l’UX pourrait être si Azure le proposait nativement.

Implémenté en février 2026. Stack Azure native (LAW, App Service, Azure Monitor, Terraform). Noms anonymisés.