Nginx : supervision et alertes utiles avec exemples pratiques

Introduction

Nginx est souvent la porte d’entrée de votre application. Quand il ralentit ou tombe, tout paraît en panne. Ce guide, écrit comme un mode d’emploi opérationnel, montre quoi surveiller, comment instrumenter proprement, quelles alertes déclencher et comment réagir sous pression. Vous y trouverez :

• une séparation claire entre disponibilité, débit, latence, erreurs, saturation, santé des upstreams, certificats TLS, files d’attente, connexions et signaux issus des journaux ;
• l’explication des sources de vérité (stub_status, exporter Prometheus, journaux d’accès/erreurs, sondes externes) avec limites et précautions ;
• une méthode pour choisir des seuils à partir d’une ligne de base et d’objectifs de service réalistes ;
• des exemples de requêtes et d’alertes prudents, des conseils anti-bruit, un mini-runbook d’incident ;
• un plan pilote local et une check-list de déploiement progressif.

KPI (Key Performance Indicator) : indicateur clé de performance suivi dans le temps pour piloter l’exploitation. SLI (Service Level Indicator) : mesure observable qui reflète l’expérience réelle (ex. taux de 5xx, latence p95). SLO (Service Level Objective) : objectif chiffré sur un SLI (ex. p95 < X ms sur 30 jours). SLA (Service Level Agreement) : engagement contractuel associé au service.

Table des matières

• [Vue d’ensemble du workflow](#vue-densemble-du-workflow)
• [Que surveiller dans Nginx](#que-surveiller-dans-nginx)
• [Sources de signaux et limites](#sources-de-signaux-et-limites)
• [Tableau de correspondance signaux → actions](#tableau-de-correspondance-signaux--actions)
• [Choisir des seuils à partir d’une ligne de base et des SLO](#choisir-des-seuils-a-partir-dune-ligne-de-base-et-des-slo)
• [Alerte : principes, multi-fenêtres et réduction du bruit](#alerte--principes-multi-fenetres-et-reduction-du-bruit)
• [Tableau des alertes, garde-fous et premières actions](#tableau-des-alertes-garde-fous-et-premieres-actions)
• [Exemples d’alertes et requêtes utiles](#exemples-dalertes-et-requetes-utiles)
• [Tableaux de bord qui aident en astreinte](#tableaux-de-bord-qui-aident-en-astreinte)
• [Workflow de réponse aux incidents (mini-runbook)](#workflow-de-reponse-aux-incidents-mini-runbook)
• [Plan pilote local](#plan-pilote-local)
• [Liste de contrôle de déploiement progressif](#liste-de-controle-de-deploiement-progressif)

Vue d’ensemble du workflow

Un workflow clair et répétable garde vos évolutions de monitoring sûres et focalisées :

<ol class="list-decimal pl-6 space-y-2 text-body-md text-on-surface-variant mb-6"> <li><strong>Objectifs et périmètre</strong></li> </ol> <ul class="list-disc pl-6 space-y-2 text-body-md text-on-surface-variant mb-6"> <li>Questions à trancher en minutes : Nginx est-il <em>up</em> ? Les clients échouent-ils (4xx/5xx) ? L’amont provoque-t-il des 502/504 ? Est-ce de la latence ou de la capacité ?</li> <li>Sélectionnez peu de signaux par question : métriques pour disponibilité/capacité, logs pour codes HTTP et latence.</li> </ul> <ol class="list-decimal pl-6 space-y-2 text-body-md text-on-surface-variant mb-6" start="2"> <li><strong>Instrumentation</strong></li> </ol> <ul class="list-disc pl-6 space-y-2 text-body-md text-on-surface-variant mb-6"> <li>Activez <code>stub_status</code> pour les métriques de connexions.</li> <li>Exposez les métriques vers Prometheus via <code>nginx-prometheus-exporter</code>.</li> <li>Expédiez et parsez les <em>access logs</em> (codes, latence) et les <em>error logs</em> (erreurs réseau, timeouts, upstream).</li> </ul> <ol class="list-decimal pl-6 space-y-2 text-body-md text-on-surface-variant mb-6" start="3"> <li><strong>Visualisation</strong></li> </ol> <ul class="list-disc pl-6 space-y-2 text-body-md text-on-surface-variant mb-6"> <li>Construisez un tableau de bord « Overview » pour l’astreinte : santé, connexions, débit, taux d’erreurs, latence et « top offenders ».</li> </ul> <ol class="list-decimal pl-6 space-y-2 text-body-md text-on-surface-variant mb-6" start="4"> <li><strong>Alerte</strong></li> </ol> <ul class="list-disc pl-6 space-y-2 text-body-md text-on-surface-variant mb-6"> <li>Pager sur les symptômes qui touchent l’utilisateur (taux de 5xx, Nginx down).</li> <li>Créer des tickets sur les tendances de capacité (connexions actives en hausse, proche des limites).</li> <li>Router vers les bons propriétaires avec du contexte et un lien vers le runbook.</li> </ul> <ol class="list-decimal pl-6 space-y-2 text-body-md text-on-surface-variant mb-6" start="5"> <li><strong>Réponse aux incidents</strong></li> </ol> <ul class="list-disc pl-6 space-y-2 text-body-md text-on-surface-variant mb-6"> <li>Utiliser un arbre de décision simple : erreurs côté client vs serveur vs amont vs problèmes TLS.</li> <li>Garder des étapes de rollback et de reload sûres, documentées et testées.</li> </ul>

Que surveiller dans Nginx

Santé et capacité cœur

<ul class="list-disc pl-6 space-y-2 text-body-md text-on-surface-variant mb-6"> <li><strong>Disponibilité</strong> : processus <em>up</em>, exporter <em>up</em>.</li> <li><strong>Connexions</strong> : <em>active</em>, <em>reading</em>, <em>writing</em>, <em>waiting</em>.</li> <li><strong>Débit</strong> : requêtes par seconde (approx. via deltas <code>accepted/handled</code>).</li> <li><strong>Succès des reloads</strong> de configuration et continuité d’uptime.</li> <li><strong>Files d’attente</strong> en amont (si visibles via l’application ou un proxy intermédiaire).</li> </ul> Qualité du trafic

<ul class="list-disc pl-6 space-y-2 text-body-md text-on-surface-variant mb-6"> <li><strong>Taux d’erreurs</strong> : 5xx et 4xx depuis les <em>access logs</em>.</li> <li><strong>Erreurs amont</strong> : 502, 503, 504.</li> <li><strong>Déconnexions client</strong> : 499.</li> <li><strong>Latence</strong> : <code>request_time</code>, <code>upstream_response_time</code> depuis les logs.</li> </ul> Sécurité et hygiène TLS

<ul class="list-disc pl-6 space-y-2 text-body-md text-on-surface-variant mb-6"> <li><strong>Expiration des certificats TLS</strong> pour les endpoints publics.</li> </ul> Contexte plateforme

<ul class="list-disc pl-6 space-y-2 text-body-md text-on-surface-variant mb-6"> <li><strong>Saturation hôte</strong> : CPU, mémoire, descripteurs de fichiers, réseau.</li> <li><strong>Dépendances</strong> : santé des upstreams (app, base de données, DNS), CDN, pare-feu.</li> </ul>

Sources de signaux et limites

• <strong>stub_status</strong> : surface des compteurs agrégés par instance (connexions <em>active/reading/writing/waiting</em>, cumul <em>accepted/handled/requests</em>). Avantages : très léger, sans échantillonnage. Limites : pas de détail par <em>vhost</em> ou URI, pas de latence, pas de codes HTTP.
• <strong>nginx-prometheus-exporter</strong> : traduit <code>stub_status</code> en métriques Prometheus (<code>nginx_connections_*</code>, <code>nginx_up</code>). Avantages : intégration directe Prometheus. Limites : toujours la granularité globale de <code>stub_status</code>.
• <strong>Access logs</strong> : source de vérité pour codes HTTP, latence totale (<code>request_time</code>) et amont (<code>upstream_response_time</code>). Avantages : visibilité par host/URI/méthode. Limites : risque de cardinalité élevée (URI dynamiques, <em>user-agent</em>), coûts d’ingestion.
• <strong>Error logs</strong> : indispensable pour qualifier les 5xx (timeouts, <em>upstream prematurely closed connection</em>, échecs TLS). Limites : bruit possible ; à parser avec parcimonie.
• <strong>Sondes externes</strong> (ex. Blackbox Exporter) : mesurent la disponibilité vue client (TCP, HTTP, TLS). Avantages : détectent les pannes réseau/anycast/CDN. Limites : moins de contexte interne.

Exemple de <code>stub_status</code> attendu :

Active connections: 12
server accepts handled requests
 1024 1024 2048
Reading: 1 Writing: 2 Waiting: 9

Précautions anti-cardinalité dans les logs :

• Normalisez l’URI (préfixe d’itinéraire au lieu de l’ID complet) ;
• Tronquez ou catégorisez les <em>user-agents</em> ;
• Limitez les labels aux dimensions utiles (ex. <code>host</code>, préfixe d’URI, classe de statut).

Tableau de correspondance signaux → actions

Choisir des seuils à partir d’une ligne de base et des SLO

Objectif : éviter les « valeurs universelles » non adaptées.

Méthode recommandée :

1. Établir une ligne de base par instance/ingress sur 2–4 semaines, en différenciant jours ouvrés/week-end et pointes horaires.
2. Définir vos SLI/SLO :

• SLI (Service Level Indicator) : ex. « taux de réponses HTTP 2xx/3xx », « p95 de <code>request_time</code> ».
• SLO (Service Level Objective) : ex. « ≥ 99,9 % de requêtes < p95=… sur 30 jours ».

1. Poser des seuils relatifs à la base :

• Alerte symptôme : déclencher si p95 > (base p95) × facteur pendant N minutes.
• Capacité : déclencher si connexions actives dépassent le 95e centile historique pendant M minutes.

1. Valider sur bac à sable et en production silencieuse : activer en « warning » sans pager, observer 1–2 semaines, ajuster et promouvoir.

Astuce : gardez des seuils par <em>service</em> (host/ingress) plutôt que globaux, et documentez l’origine des chiffres dans le runbook.

Alerte : principes, multi-fenêtres et réduction du bruit

• <strong>Sens utilisateur d’abord</strong> : alerter sur disponibilité et erreurs visibles côté client (5xx, <em>up</em>), pas sur chaque micro-variation.
• <strong>Multi-fenêtres</strong> : combiner une fenêtre courte (détection rapide) et une fenêtre longue (confiance) pour réduire le bruit.
• <strong>Dépendances</strong> : distinguer Nginx vs amont (502/504) et inhiber les doublons (une seule alerte principale).
• <strong>Contexte d’alerte</strong> : inclure host/ingress, codes dominants, liens dashboard et pas de debug en premier.
• <strong>Après-changement</strong> : passage en mode « silence » lors de déploiements planifiés, suivi de validation automatique post-release.

Exemple d’alerte « multi-fenêtres » (5xx) : courte + longue, déclenche si les deux sont vraies.

- alert: High5xxMultiWindow
  expr: |
    (
      sum by (instance) (rate(nginx_ingress_controller_requests{status=~"5.."}[5m]))
      /
      clamp_min(sum by (instance) (rate(nginx_ingress_controller_requests[5m])), 1)
    ) > 0.02
    and
    (
      sum by (instance) (rate(nginx_ingress_controller_requests{status=~"5.."}[30m]))
      /
      clamp_min(sum by (instance) (rate(nginx_ingress_controller_requests[30m])), 1)
    ) > 0.01
  for: 5m
  labels: {severity: "page"}
  annotations:
    summary: ">5xx persistants (fenêtres 5m et 30m) sur {{ $labels.instance }}"

Tableau des alertes, garde-fous et premières actions

Exemples d’alertes et requêtes utiles

Exemples Prometheus (exporter Nginx simple) :

# Processus Nginx ou exporter down
- alert: NginxDown
  expr: up{job="nginx"} == 0
  for: 1m
  labels:
    severity: page
  annotations:
    summary: Nginx down on {{ $labels.instance }}

- alert: NginxExporterDown
  expr: up{job="nginx-exporter"} == 0
  for: 2m
  labels:
    severity: ticket
  annotations:
    summary: Nginx exporter down on {{ $labels.instance }}

# Connexions actives au-dessus du niveau de base (ex. 95e centile historique)
- alert: NginxHighActiveConnections
  expr: nginx_connections_active > quantile_over_time(0.95, nginx_connections_active[30d])
  for: 5m
  labels:
    severity: ticket
  annotations:
    summary: Active connections unusually high on {{ $labels.instance }}

# Accepted moins handled indique des connexions perdues
- alert: NginxConnectionDrops
  expr: rate(nginx_connections_accepted[5m]) - rate(nginx_connections_handled[5m]) > 0
  for: 2m
  labels:
    severity: page
  annotations:
    summary: Connection drops on {{ $labels.instance }} increasing

Si vous utilisez Nginx Ingress Controller, vous pouvez aussi alerter sur les codes HTTP directement depuis les métriques :

- alert: IngressHigh5xxRate
  expr: sum by (ingress) (rate(nginx_ingress_controller_requests{status=~"5.."}[5m])) > 5
  for: 5m
  labels:
    severity: page
  annotations:
    summary: High 5xx rate on ingress {{ $labels.ingress }}

Exemple Loki Ruler (5xx basés logs pour Nginx simple) :

# En supposant que promtail extrait un label 'status' des access logs
- alert: NginxHigh5xxFromLogs
  expr: sum(rate({job="nginx_access", status=~"5.."}[5m])) > 5
  for: 5m
  labels:
    severity: page
  annotations:
    summary: High 5xx rate in Nginx logs

Expiration de certificat TLS avec Blackbox exporter :

- alert: TLSSoonToExpire
  expr: (probe_ssl_earliest_cert_expiry - time()) < 14 * 24 * 3600
  for: 0m
  labels:
    severity: ticket
  annotations:
    summary: TLS certificate expires soon on {{ $labels.instance }}

Pièges de cardinalité et bonnes pratiques PromQL :

• Évitez <code>by (uri)</code> sur des chemins dynamiques ; préférez un <em>prefix</em> d’URI ou un regroupement par <code>route</code> normalisée.
• Normalisez les codes en classes (<code>status_class</code> = 2xx/3xx/4xx/5xx) pour les agrégations.
• Posez un minimum de volume (<code>sum(rate(requests[5m])) &gt;= N</code>) pour éviter de sur-réagir à de faibles trafics.

Corrélation avec les déploiements : annotez vos graphiques (ex. Grafana annotations) lors des releases CI/CD, sinon vous confondrez un pic de 5xx « déploiement » avec un incident réel.

Tableaux de bord qui aident en astreinte

Aperçu (premier écran)

<ul class="list-disc pl-6 space-y-2 text-body-md text-on-surface-variant mb-6"> <li>Nginx up, exporter up</li> <li>Connexions actives par état : reading, writing, waiting</li> <li>Requêtes par seconde (dérivées des deltas accepted/handled)</li> <li>Taux d’erreurs : 5xx, 4xx depuis les logs</li> <li>Latence p50, p95 depuis les logs (<code>request_time</code>)</li> <li>Top URIs ou hosts par 5xx et latence</li> </ul> Capacité et santé

<ul class="list-disc pl-6 space-y-2 text-body-md text-on-surface-variant mb-6"> <li>Tendance connexions actives vs waiting</li> <li>CPU, mémoire, réseau (hôte)</li> <li>Connexions perdues (drops) dans le temps</li> </ul> Qualité du trafic

<ul class="list-disc pl-6 space-y-2 text-body-md text-on-surface-variant mb-6"> <li>499, 502, 504 dans le temps</li> <li>Latence amont vs latence totale</li> </ul> Chaque panneau doit inclure : unité, requête, et « pourquoi c’est utile ». Gardez des raccourcis de période 5m, 1h, 24h pour le triage.

Workflow de réponse aux incidents (mini-runbook)

Triage rapide

<ol class="list-decimal pl-6 space-y-2 text-body-md text-on-surface-variant mb-6"> <li>Nginx est-il <em>up</em> ? Si <em>down</em>, vérifier le service manager, les changements récents de config, et recharger en sécurité.</li> <li>Y a-t-il un pic de 5xx ? Si oui, inspecter 502/504 pour trancher entre échecs amont ou saturation Nginx.</li> <li>Latence élevée avec peu d’erreurs ? Enquêter côté amont (lenteurs) ou saturation réseau.</li> <li>499 élevés ? Les clients ferment tôt ; vérifier timeouts, comportement du CDN et endpoints longs.</li> </ol> Patrons de correction

<ul class="list-disc pl-6 space-y-2 text-body-md text-on-surface-variant mb-6"> <li><strong>Nginx down</strong> : valider la config, puis reload.<br><code>nginx -t</code><br><code>systemctl reload nginx</code> (ou <code>nginx -s reload</code>)</li> <li><strong>Connexions actives élevées</strong> : augmenter prudemment <code>worker_connections</code>, revoir <code>keepalive_timeout</code>, et vérifier la capacité amont.</li> <li><strong>502/504</strong> : contrôler la santé des upstreams, la résolution DNS, les timeouts <code>proxy_*</code> et les keepalives entre Nginx et amont.</li> <li><strong>5xx applicatifs</strong> : router aux propriétaires applicatifs avec les endpoints principaux issus des logs.</li> <li><strong>Expiration TLS</strong> : renouveler, déployer, et vérifier via une sonde blackbox.</li> </ul> Aftercare

<ul class="list-disc pl-6 space-y-2 text-body-md text-on-surface-variant mb-6"> <li>Documenter le déclencheur, le signal le plus probant et le changement unique qui a corrigé.</li> <li>Ajouter/affiner une alerte ou un panneau pour éviter la récidive.</li> <li>Critères d’escalade : si p95 > SLO pendant >30 min ou si indisponibilité frontale > seuil SLO, escalader vers l’équipe plateforme ; si 5xx applicatifs dominent, vers l’équipe applicative ; si TLS < 7 jours, vers l’équipe sécurité.</li> </ul>

Plan pilote local

Objectif : prouver que vous voyez la santé, les erreurs et la capacité en local. Restez étroit et mesurable.

Ce que vous allez lancer

<ul class="list-disc pl-6 space-y-2 text-body-md text-on-surface-variant mb-6"> <li>Nginx avec <code>stub_status</code> et un access log émettant <code>status</code> et latence</li> <li><code>nginx-prometheus-exporter</code> pour les métriques</li> <li>Prometheus pour scrapper l’exporter (et Blackbox en option)</li> <li>Grafana pour les dashboards</li> <li>Optionnel : Loki + Promtail pour 5xx et latence basés logs</li> </ul>

Configuration Nginx (local)

events { worker_connections 1024; }
http {
  log_format main 'remote=$remote_addr host=$host method=$request_method uri=$request_uri '
                  'status=$status bytes=$body_bytes_sent rt=$request_time urt=$upstream_response_time';
  access_log /var/log/nginx/access.log main;

  server {
    listen 80;
    location / {
      return 200 'ok';
    }
    location /nginx_status {
      stub_status;
      allow 127.0.0.1;
      deny all;
    }
  }
}

Docker Compose (labo local)

services:
  nginx:
    image: nginx:1.25
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf:ro
      - ./logs:/var/log/nginx
    ports:
      - '8080:80'

  exporter:
    image: nginxinc/nginx-prometheus-exporter:0.11.0
    command: ['-nginx.scrape-uri', 'http://nginx/nginx_status']
    ports:
      - '9113:9113'
    depends_on: [nginx]

  prometheus:
    image: prom/prometheus:v2.54.0
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml:ro
      - ./alerts.yml:/etc/prometheus/alerts.yml:ro
    command: ['--config.file=/etc/prometheus/prometheus.yml', '--web.enable-lifecycle']
    ports:
      - '9090:9090'
    depends_on: [exporter]

  grafana:
    image: grafana/grafana:11.0.0
    ports:
      - '3000:3000'
    depends_on: [prometheus]

  loki:
    image: grafana/loki:2.9.0
    command: ['-config.file=/etc/loki/local-config.yaml']
    volumes:
      - ./loki.yaml:/etc/loki/local-config.yaml:ro
    ports:
      - '3100:3100'

  promtail:
    image: grafana/promtail:2.9.0
    volumes:
      - ./promtail.yaml:/etc/promtail/config.yml:ro
      - ./logs:/var/log/nginx:ro
    command: ['--config.file=/etc/promtail/config.yml']
    depends_on: [loki]

<details> <summary>prometheus.yml</summary>

scrape_configs:
  - job_name: nginx
    static_configs:
      - targets: ['exporter:9113']

rule_files:
  - /etc/prometheus/alerts.yml

</details>

<details> <summary>alerts.yml</summary>

groups:
- name: nginx-basic
  rules:
  - alert: NginxDown
    expr: up{job='nginx'} == 0
    for: 1m
    labels: {severity: 'page'}
    annotations: {summary: 'Nginx down'}

  - alert: NginxHighActiveConnections
    expr: nginx_connections_active > 50
    for: 2m
    labels: {severity: 'ticket'}
    annotations: {summary: 'High active connections'}

  - alert: NginxConnectionDrops
    expr: rate(nginx_connections_accepted[5m]) - rate(nginx_connections_handled[5m]) > 0
    for: 2m
    labels: {severity: 'page'}
    annotations: {summary: 'Connection drops increasing'}

</details>

<details> <summary>promtail.yaml (extraire status et latence en labels/champs)</summary>

server:
  http_listen_port: 9080
positions:
  filename: /tmp/positions.yaml
clients:
  - url: http://loki:3100/loki/api/v1/push
scrape_configs:
  - job_name: nginx_access
    static_configs:
      - targets: ['localhost']
        labels:
          job: nginx_access
          __path__: /var/log/nginx/access.log
    pipeline_stages:
      - regex:
          expression: '.*status=(?P<status>\d{3}).*rt=(?P<rt>[0-9.]+).*urt=(?P<urt>[0-9.\-]+)'
      - labels:
          status:

</details>

<details> <summary>loki.yaml (config minimale monoproc)</summary>

server:
  http_listen_port: 3100
common:
  path_prefix: /tmp/loki
  storage:
    filesystem:
      chunks_directory: /tmp/loki/chunks
  rules_directory: /tmp/loki/rules
  replication_factor: 1
schema_config:
  configs:
    - from: 2020-10-24
      store: boltdb-shipper
      object_store: filesystem
      schema: v11
      index:
        prefix: index_
        period: 24h
ruler:
  alertmanager_url: http://alertmanager:9093

</details>

Smoke test

<ul class="list-disc pl-6 space-y-2 text-body-md text-on-surface-variant mb-6"> <li>Ouvrez Grafana sur <code>http://localhost:3000</code> et ajoutez Prometheus sur <code>http://prometheus:9090</code> comme source de données.</li> <li>Créez un panneau rapide avec <code>nginx_connections_active</code>.</li> <li>Générez de la charge : <code>while true; do curl -s http://localhost:8080/ >/dev/null; done</code></li> <li>Confirmez que les alertes se déclenchent dans Prometheus pour connexions actives élevées si vous augmentez la charge.</li> <li>Si vous utilisez Loki, créez un panneau avec la requête : <code>{job='nginx_access'}</code> et un Stat montrant le taux de 5xx : <code>sum(rate({job='nginx_access', status=~'5..'}[5m]))</code>.</li> </ul> Critères de sortie du pilote

<ul class="list-disc pl-6 space-y-2 text-body-md text-on-surface-variant mb-6"> <li>Vous voyez Nginx up, les connexions, et une tendance claire des requêtes.</li> <li>Un pic de 5xx issu des logs est visible en quelques minutes.</li> <li>Trois alertes se déclenchent en conditions contrôlées et s’arrêtent quand la condition disparaît.</li> </ul>

Métriques à collecter (Nginx simple)

Depuis <code>nginx-prometheus-exporter</code> (scrape sur <code>stub_status</code>) :

<ul class="list-disc pl-6 space-y-2 text-body-md text-on-surface-variant mb-6"> <li><code>nginx_connections_active</code></li> <li><code>nginx_connections_reading</code></li> <li><code>nginx_connections_writing</code></li> <li><code>nginx_connections_waiting</code></li> <li><code>nginx_connections_accepted</code></li> <li><code>nginx_connections_handled</code></li> <li><code>nginx_up</code></li> </ul> Métriques hôte (<code>node_exporter</code> ou équivalent) :

<ul class="list-disc pl-6 space-y-2 text-body-md text-on-surface-variant mb-6"> <li><code>node_filesystem_avail_bytes</code>, famille <code>node_network_</code> (débit), <code>node_load</code>, <code>node_cpu*</code>, usage des descripteurs de fichiers.</li> </ul> Note Kubernetes Ingress

<ul class="list-disc pl-6 space-y-2 text-body-md text-on-surface-variant mb-6"> <li>Si vous utilisez Nginx Ingress Controller, préférez ses métriques natives : <code>nginx_ingress_controller_requests</code>, <code>nginx_ingress_controller_nginx_process_connections</code> et, si disponibles, les histogrammes de latence.</li> </ul>

Logs à collecter et parser

Utilisez un format de log qui émet <code>status</code>, <code>request_time</code> et <code>upstream_response_time</code>. Exemple :

log_format main 'remote=$remote_addr host=$host method=$request_method uri=$request_uri '
                'status=$status bytes=$body_bytes_sent referer=$http_referer '
                'ua=$http_user_agent rt=$request_time urt=$upstream_response_time';
access_log /var/log/nginx/access.log main;

Parsez en labels et champs numériques :

<ul class="list-disc pl-6 space-y-2 text-body-md text-on-surface-variant mb-6"> <li><code>status</code> (ex. 200, 499, 502, 504)</li> <li><code>request_time</code> (secondes)</li> <li><code>upstream_response_time</code> (secondes ; peut être <code>-</code> si pas d’amont)</li> <li><code>host</code>, préfixe d’<code>uri</code>, <code>method</code> (pour les vues Top‑N)</li> </ul>

Validation après changement et dépendances amont

• Après tout <code>reload</code> Nginx : validez avec une sonde HTTP (réponses 2xx) et vérifiez l’absence de pics de 5xx/499.
• Après déploiement applicatif : surveillez 15–30 min les 5xx et la p95 de <code>request_time</code>. En cas de régression, envisagez un rollback.
• Dépendances : en cas de 502/504, testez directement l’upstream (<code>curl http://UPSTREAM/health</code>), la résolution DNS (<code>dig</code>) et les ACL réseau.

Liste de contrôle de déploiement progressif

<ul class="list-disc pl-6 space-y-2 text-body-md text-on-surface-variant mb-6"> <li>Activer <code>stub_status</code> et vérifier l’accès contrôlé (<code>allow/deny</code>).</li> <li>Déployer <code>nginx-prometheus-exporter</code> et confirmer <code>nginx_up</code> dans Prometheus.</li> <li>Configurer un format d’access log avec <code>status</code>, <code>request_time</code>, <code>upstream_response_time</code>.</li> <li>Ingestion logs (Loki/ELK) : limiter les labels, normaliser les URI.</li> <li>Tableau de bord « Overview » : up, connexions, RPS, 4xx/5xx, p50/p95, top routes.</li> <li>Alertes « silencieuses » 1–2 semaines ; ajuster les seuils relatifs à la base.</li> <li>Activer les pages sur symptômes (Nginx down, 5xx) avec multi‑fenêtres.</li> <li>Ajouter certificats TLS (30/14/7 jours) et surveillance hôte (CPU, mémoire, FD).</li> <li>Documenter un runbook bref, liens dashboard, commandes <code>nginx -t</code>/<code>reload</code>.</li> <li>Corréler avec le flux de déploiements (annotations Grafana/Alertmanager).</li> </ul>

<hr />

<div class="mt-8"> <a href="#contact" class="inline-block px-5 py-3 rounded-md font-semibold" style="background-color:#1e40af;color:#fff;">Contacter l’équipe de recherche</a> </div>