Elasticsearch : la première requête utile sur des logs

Beaucoup d’équipes « ont Elasticsearch ». Peu s’en servent sous pression. La différence n’est pas le cluster : c’est de savoir formuler trois questions avant que l’incident n’attende.

1. Combien d’erreurs, et depuis quand ?

http

GET logs-app/_search
{
  "size": 0,
  "query": {
    "bool": {
      "filter": [
        { "term": { "level": "ERROR" } },
        { "range": { "@timestamp": { "gte": "now-15m" } } }
      ]
    }
  },
  "aggs": {
    "par_minute": {
      "date_histogram": {
        "field": "@timestamp",
        "fixed_interval": "1m"
      }
    }
  }
}

size: 0 : on veut la tendance, pas dix mille documents. Le filtre (pas must) évite de scorer inutilement.

2. Quel service crie le plus fort ?

http

GET logs-app/_search
{
  "size": 0,
  "query": {
    "bool": {
      "filter": [
        { "term": { "level": "ERROR" } },
        { "range": { "@timestamp": { "gte": "now-1h" } } }
      ]
    }
  },
  "aggs": {
    "services": {
      "terms": { "field": "service.keyword", "size": 10 }
    }
  }
}

Le .keyword compte. Si service est mappé en text analysé, l’agrégation terms se comporte mal ou échoue. C’est le premier piège classique.

3. Retrouver l’erreur exacte d’un utilisateur

http

GET logs-app/_search
{
  "size": 50,
  "sort": [{ "@timestamp": "desc" }],
  "query": {
    "bool": {
      "filter": [
        { "term": { "request_id.keyword": "8f3c2a1e-…" } }
      ]
    }
  }
}

Sans request_id (ou trace id) propagé dans les logs, vous cherchez une aiguille dans un champ message. Instrumentez d’abord ; indexez ensuite.

Mapping : text vs keyword, en une phrase

text : pour la recherche plein texte (match sur un message)
keyword : pour les filtres exacts et les agrégations (term, terms)

Beaucoup de champs doivent être les deux (fields.keyword). Un jeu de données annoté avec les bons mappings évite d’apprendre ça en production.

Ce qu’il faut retenir

Elasticsearch n’est utile que si vos questions d’incident sont déjà des requêtes. Commencez par le volume d’erreurs, le top des services, puis le fil d’un request_id. Le reste — dashboards jolis, anomaly detection — vient après que ces trois réflexes sont automatiques.