For AI agents: the complete documentation index is available at https://docs.ovhcloud.com/fr/llms.txt, the full documentation bundle is available at https://docs.ovhcloud.com/fr/llms-full.txt, and this page is available as Markdown at https://docs.ovhcloud.com/fr/guides/manage-and-operate/observability/logs-data-platform/haproxy.md.

Superviser votre déploiement HAProxy avec Logs Data Platform

Voir en Markdown

Surveillez et analysez vos applications web avec HAProxy et Logs Data Platform.

Objectif

HAProxy est le load balancer de facto pour vos applications basées sur TCP et HTTP. Ce logiciel français fournit une haute disponibilité, un équilibrage de charge et un proxying avec des performances élevées, une fiabilité inégalée et un prix très raisonnable (il est totalement gratuit et open source). Il est utilisé par les sites web les plus visités au monde et est également largement utilisé en interne chez OVHcloud et dans certains de nos produits.

HAProxy dispose de nombreuses fonctionnalités et, comme il se situe entre votre infrastructure et vos clients, il peut vous fournir de nombreuses informations sur les deux. Logs Data Platform vous aide à exploiter ces données et peut répondre à un grand nombre de vos questions :

  • Quelle est la page web la plus visitée ?
  • Quel est l'appel API le plus lent ?
  • Quand votre trafic atteint-il son pic ?
  • Quel volume de données sort de votre infrastructure ?
  • D'où viennent vos clients ?
  • Combien de temps vos clients restent-ils sur vos sites web ?
  • Tous vos serveurs back-end sont-ils en bonne santé ?

Ce guide vous montre deux façons d'envoyer vos logs HAProxy vers Logs Data Platform. Les deux méthodes utilisent rsyslog pour envoyer les logs. La première configuration s'appuie sur les capacités de parsing de Logstash, et la seconde utilise la fonctionnalité de format de log personnalisé d'HAProxy pour envoyer les logs au format LTSV.

Prérequis

Pour ce tutoriel, vous devriez avoir lu les guides suivants afin de bien comprendre la suite :

En pratique

HAProxy

HAProxy est un logiciel puissant disposant de nombreuses options de configuration. Heureusement, la documentation de configuration est très complète et couvre tout ce dont vous avez besoin pour ce tutoriel. Ce tutoriel n'est pas un tutoriel HAProxy et ne couvre donc pas l'installation, la configuration et le déploiement d'HAProxy, mais vous trouverez de la documentation à ce sujet sur le site officiel. Selon votre backend, vous avez le choix entre plusieurs formats pour vos logs :

  • Format par défaut : bien qu'il donne certaines informations sur le client et la destination, ce format n'est pas très verbeux et ne peut pas vraiment être utilisé pour une analyse approfondie.
  • Format Tcp Log : ce format vous donne beaucoup plus d'informations pour dépanner vos connexions tcp et c'est celui que vous devriez utiliser lorsque vous ne savez pas quel type d'application est démarré derrière votre backend.
  • Format Http Log : comme son nom l'indique, ce format est l'option la plus adaptée pour analyser le protocole HTTP. Bien entendu, il n'a de sens que lorsque votre HAProxy agit en tant que proxy HTTP. Il donne encore plus d'informations que le log tcp, comme par exemple le code de statut HTTP.
  • Format de log personnalisé : celui-ci vous permet de personnaliser entièrement le format de log à l'aide de flags. Vous contrôlez entièrement les informations que vous journalisez.

Voici un exemple de ligne de log au format HTTP log :

 haproxy[14389]: 5.196.2.38:39527 [03/Nov/2015:06:25:25.105] services~ api/api 4599/0/0/428/5027 304 320 - - ---- 1/1/0/1/0 0/0 "GET /v1/service HTTP/1.1"

Chaque bloc de cette ligne (y compris les caractères tirets) donne une information sur la connexion terminée. Sur cette seule ligne, vous avez des informations sur le processus, son pid, l'adresse IP du client, le port du client, la date d'ouverture de la connexion, les noms du frontend, du backend et du serveur, des timers en millisecondes d'attente pour le client, les buffers du processus et du serveur, le code de statut, le nombre d'octets lus, les informations de cookies, l'état de terminaison, le nombre de connexions concurrentes respectivement sur le processus, le frontend, le backend et les serveurs, le nombre de tentatives, le numéro de file d'attente du backend et enfin la requête elle-même. Vous pouvez consulter le chapitre 8 de la documentation HAProxy pour une description détaillée de tous ces formats et des champs disponibles.

Pour activer la journalisation sur HAProxy, vous devez définir une option log globale dans /etc/haproxy/haproxy.cfg.

 global
     log /dev/log    local0
     log /dev/log    local1 notice
     chroot /var/lib/haproxy
     stats socket /run/haproxy/admin.sock mode 660 level admin
     stats timeout 30s
     user haproxy
     group haproxy
     daemon

Cette option indique à HAProxy d'envoyer les logs vers le socket /dev/log avec différentes facilités syslog : la facilité local0 par défaut et local1 pour les messages de niveau notice. Pour préciser le type de journalisation d'un backend, d'un frontend ou d'une directive listen, vous utilisez une option simple :

 listen my_tcp_application
   bind 172.XXX.XXX.XXX:53100
   mode tcp
   option  tcplog
   option  tcpka
   timeout client  1h
   timeout server  1h
   maxconn 64510
   bind-process 2
   server lb-cloud-1 192.168.XXX.XXX:53100 check port 53100 weight 1 backup
   server lb-cloud-2 192.168.XXX.XXX:53100 check port 53100 weight 10

Nous pouvons envoyer les logs vers Logs Data Platform en utilisant plusieurs logiciels. L'un d'eux est Rsyslog, l'autre est Filebeat. Vous êtes libre d'utiliser la méthode qui vous semble la plus familière.

Rsyslog

Rsyslog est un processeur de logs rapide, entièrement compatible avec le protocole syslog. Il a évolué vers un collecteur générique capable d'accepter des entrées provenant de nombreux inputs différents, de les transformer et de les envoyer finalement vers diverses destinations. La documentation d'installation et de configuration se trouve sur le site officiel. Rendez-vous sur https://www.rsyslog.com/doc/ pour des informations détaillées.

Pour envoyer les logs HAProxy avec RSyslog, nous utiliserons plusieurs méthodes : un collecteur Logstash dédié et le simple format LTSV. La première méthode est la moins intrusive et peut être utilisée lorsque vous avez besoin d'un traitement Logstash de vos logs (par exemple pour anonymiser certains logs sous certaines conditions). La seconde méthode doit être privilégiée lorsque vous avez un site web à fort trafic (au moins 1000 requêtes par seconde).

Pour les deux méthodes, vous aurez besoin de notre certificat SSL pour activer la communication TLS. Certaines distributions Linux Debian nécessitent d'installer le paquet rsyslog-gnutls pour activer SSL.

Exploiter un outil de collecte Logstash dédié

Une fois que vous avez activé les logs tcp ou http de votre instance HAProxy, vous devez ensuite les envoyer et les transformer. Pour cette partie du tutoriel, vous aurez besoin de votre propre collecteur Logstash dédié. Logstash est l'un des outils les plus puissants pour transformer les logs. Créez un outil de collecte Logstash comme décrit dans le tutoriel Logstash, et configurez le port 1514 (ou le port de votre choix) comme port exposé.

edit\_logstash

Configuration du collecteur Logstash

Comme vous pouvez l'imaginer, nous devons configurer le collecteur Logstash avec des filtres Grok astucieux pour que le collecteur prenne en compte notre convention de nommage des champs. Le collecteur accepte les logs via un input TCP générique et utilise des filtres grok pour extraire les informations. Grâce à la fonctionnalité d'assistant, vous n'aurez même pas besoin de copier-coller les extraits de configuration suivants, mais ils sont tout de même fournis à titre de référence.

Voici la configuration de l'input Logstash :

tcp {
  port => 1514
  type => haproxy
  ssl_enable => true
  ssl_verify => false
  ssl_extra_chain_certs => ["/etc/ssl/private/ca.crt"]
  ssl_cert => "/etc/ssl/private/server.crt"
  ssl_key => "/etc/ssl/private/server.key"
}

Cette configuration devrait vous être familière, nous définissons le port, le paramètre ssl et la configuration ssl avec nos certificats fournis. Poursuivons avec la partie filtre. Le grok personnalisé utilisé est décrit ci-après :

 if [type] == "haproxy" {
   grok {
     match => [ "message", "%{OVHHAPROXYHTTP}" ]
     patterns_dir => "/opt/logstash/patterns"
     named_captures_only => true
   }
   if ("_grokparsefailure" in [tags]) {
     mutate {
       remove_tag => [ "_grokparsefailure" ]
     }
     grok {
       match => [ "message", "%{OVHHAPROXYTCP}" ]
       patterns_dir => "/opt/logstash/patterns"
       named_captures_only => true
     }
   }
   if ("_grokparsefailure" in [tags]) {
     mutate {
       remove_tag => [ "_grokparsefailure" ]
     }
     grok {
       match => [ "message", "%{OVHHAPROXYERROR}" ]
       patterns_dir => "/opt/logstash/patterns"
       named_captures_only => true
     }
   }
   if !("_grokparsefailure" in [tags]) {
     date {
       locale => "en"
       match => [ "accept_date", "dd/MMM/YYYY:HH:mm:ss.SSS", "ISO8601"]
       timezone => "Europe/Paris"
       target => "accept_date"
     }
     date {
       match => [ "timestamp8601_date", "ISO8601" ]
       timezone => "Europe/Paris"
       target => "@timestamp"
     }
   }
 }

Le filtre est divisé en 3+1 parties. Les 3 premières parties sont des filtres grok qui tentent de parser les différents formats. En cas d'échec (avec un tag _grokparsefailure), il essaie un autre format de log. HTTP, TCP et le format de log d'erreur sont ceux essayés. La dernière partie est un filtre de date. Ce filtre sert à traduire les dates au format ISO 8601 correct que nous utilisons pour le parsing des dates. Ce filtre n'est exécuté que lorsque l'un des filtres précédents a réussi.

 ### HA PROXY ###
 ## Documentation of the haproxy log formats can be found at the following link:
 ## www.haproxy.org/download/1.6/doc/configuration.txt

 OVHHAPROXYTIME (?!<[0-9])%{HOUR:haproxy_hour_int:int}:%{MINUTE:haproxy_minute_int:int}(?::%{SECOND:haproxy_second_int:int})(?![0-9])
 OVHHAPROXYDATE %{MONTHDAY:haproxy_monthday_int:int}/%{MONTH:haproxy_month}/%{YEAR:haproxy_year_int:int}:%{OVHHAPROXYTIME:haproxy_time}.%{INT:haproxy_milliseconds:int}
 OVHSYSLOGHEAD <%{NONNEGINT:facility:int}.%{NONNEGINT:severity:int}>

 OVHHAPROXYHEAD (?:%{SYSLOGTIMESTAMP:syslog_timestamp}|%{TIMESTAMP_ISO8601:timestamp8601_date}) %{IPORHOST:syslog_server} %{SYSLOGPROG}:

 # parse a haproxy 'httplog' line
 OVHHAPROXYHTTPBASE %{IP:client_ip}:%{INT:client_port_int:int} \[%{OVHHAPROXYDATE:accept_date}\] %{NOTSPACE:frontend_name} %{NOTSPACE:backend_name}/%{NOTSPACE:server_name} %{INT:time_request_int:int}/%{INT:time_queue_int:int}/%{INT:time_backend_connect_int:int}/%{INT:time_backend_response_int:int}/%{NOTSPACE:time_duration_int:int} %{INT:http_status_code_int:int} %{NOTSPACE:bytes_read_int:int} %{DATA:captured_request_cookie} %{DATA:captured_response_cookie} %{NOTSPACE:termination_state} %{INT:actconn_int:int}/%{INT:feconn_int:int}/%{INT:beconn_int:int}/%{INT:srvconn_int:int}/%{NOTSPACE:retries_int:int} %{INT:srv_queue_int:int}/%{INT:backend_queue_int:int} (\{%{HAPROXYCAPTUREDREQUESTHEADERS}\})?( )?(\{%{HAPROXYCAPTUREDRESPONSEHEADERS}\})?( )?"(`<BADREQ>`|(%{WORD:http_verb} (%{URIPROTO:http_proto}://)?(?:%{USER:http_user}(?::[^@]*)?@)?(?:%{URIHOST:http_host})?(?:%{URIPATHPARAM:http_request})?( HTTP/%{NUMBER:http_version})?))?"
 OVHHAPROXYHTTP %{OVHHAPROXYHEAD} %{OVHHAPROXYHTTPBASE}

 # parse a haproxy 'tcplog' line
 OVHHAPROXYTCP %{OVHHAPROXYHEAD} %{IP:client_ip}:%{INT:client_port_int:int} \[%{OVHHAPROXYDATE:accept_date}\] %{NOTSPACE:frontend_name} %{NOTSPACE:backend_name}/%{NOTSPACE:server_name} %{INT:time_queue_int:int}/%{INT:time_backend_connect_int:int}/%{NOTSPACE:time_duration_int:int} %{NOTSPACE:bytes_read_int:int} %{NOTSPACE:termination_state} %{INT:actconn_int:int}/%{INT:feconn_int:int}/%{INT:beconn_int:int}/%{INT:srvconn_int:int}/%{NOTSPACE:retries_int:int} %{INT:srv_queue_int:int}/%{INT:backend_queue_int:int}

 # parse a haproxy 'error' line
 OVHHAPROXYERROR %{OVHHAPROXYHEAD} %{IP:client_ip}:%{INT:client_port_int:int} \[%{OVHHAPROXYDATE:accept_date}\] %{NOTSPACE:frontend_name}/%{NOTSPACE:bind_name}: %{GREEDYDATA:error_message}

Chaque motif grok se charge d'analyser une partie dédiée de la ligne de log.

  • OVHHAPROXYTIME : ce motif parse l'heure pour en extraire l'heure, les minutes et les secondes de la connexion.
  • OVHHAPROXYDATE : ce motif parse la date pour en extraire le jour du mois, le mois, l'année et les millisecondes en s'appuyant sur le motif précédent.
  • OVHSYSLOGHEAD : ce motif peut parser un éventuel en-tête syslog. Nous ne l'utiliserons pas, mais il peut être utile avec certaines variantes de syslog.
  • OVHHAPROXYHEAD : ce motif parse l'en-tête rsyslog et l'heure de réception du log.
  • OVHHAPROXYHTTPBASE : c'est le motif grok principal extrayant toutes les informations incluses dans une ligne de log HTTP. Il utilise la convention de nommage des champs.
  • OVHHAPROXYHTTP : en combinant un motif d'en-tête précédent avec OVHHAPROXYHTTPBASE, ce motif est celui utilisé dans le filtre grok.
  • OVHHAPROXYTCP : ce motif est le motif principal utilisé pour parser les logs TCP. Il utilise également la convention de nommage des champs.
  • OVHHAPROXYERROR : ce motif parse tout log d'erreur de connexion.

Vous pouvez ensuite cliquer sur Tester la configuration pour la valider.

Configuration de base de Rsyslog

Rsyslog sera configuré pour effectuer 2 actions :

  • Envoyer les logs vers Logs Data Platform
  • Conserver les logs dans un fichier dédié

Pour la première action, vous aurez besoin du certificat du collecteur et de son nom d'hôte, que vous trouverez tous deux dans le menu de votre collecteur.

collector\_menu

Copiez le certificat dans un fichier logstash.pem et copiez le nom d'hôte ainsi que votre port. Selon votre variante de rsyslog et d'HAProxy, votre fichier de configuration peut déjà être présent à un emplacement particulier. Si vous n'avez aucun fichier lié à HAProxy dans le répertoire /etc/rsyslog.d/, créez un nouveau fichier dans ce répertoire. Si le répertoire n'existe pas, éditez simplement le fichier /etc/rsyslog.conf. N'hésitez pas à consulter la documentation rsyslog pour plus d'informations. Sur les variantes Debian par exemple, si vous avez utilisé les paquets rsyslog et HAProxy, vous pouvez avoir un fichier situé dans /etc/rsyslog.d/46-haproxy.conf. Dans ce cas, il est préférable d'éditer ce fichier.

 $AddUnixListenSocket /var/lib/haproxy/dev/log
 $template haproxy,"%timestamp:::date-rfc3339% %HOSTNAME% %syslogtag%%msg%\n"

 $DefaultNetstreamDriverCAFile /etc/ssl/certs/logstash.pem
 $DefaultNetstreamDriver gtls # use gtls netstream driver
 $ActionSendStreamDriverMode 1 # require TLS for the connection
 $ActionSendStreamDriverAuthMode anon # server is NOT authenticated

 # Envoyer les messages HAProxy vers votre conteneur
 if $programname startswith 'haproxy' then @@gra1-XXXXXXXXXXXXXXXXXXXXXXXXX.gra1.logs.ovh.com:1514;haproxy

 # Envoyer les messages HAProxy vers un fichier de log dédié
 if $programname startswith 'haproxy' then /var/log/haproxy.log;haproxy
 &~

Les paramètres importants ici sont l'emplacement du chemin logstash.pem, l'activation de gtls et la configuration du nom d'hôte du collecteur. Notez que cette configuration conserve les logs dans un fichier dédié /var/log/haproxy.log.

Utiliser le format LTSV haute performance

Vous pouvez utiliser le format LTSV haute performance avec HAProxy en utilisant un format personnalisé. Cette option est la plus adaptée aux sites web à fort trafic et est hautement personnalisable. Vous pouvez retirer les champs dont vous n'avez pas besoin dans vos logs ou en ajouter des optionnels (comme les chiffrements SSL et la version utilisés dans la connexion, le port client, le compteur de requêtes...). Pour la configurer, vous devrez préciser votre format dans le fichier de configuration HAProxy, puis configurer votre configuration rsyslog pour encapsuler la ligne de log dans une ligne de log LTSV compatible. Par ailleurs, vous pouvez déployer votre propre collecteur haute performance avec Flowgger sur Logs Data Platform pour encore plus de sécurité et de performance.

Configuration du format de log HAProxy

Les flags utilisés pour définir votre format de log sont décrits dans la documentation HAProxy (section 8.2.4 dans la version 1.8 d'HAProxy). Voici un exemple de format de log entièrement compatible avec notre convention de nommage des champs. À la place de votre option de log précédente, utilisez l'entrée suivante :

log-format client_ip:%ci\tclient_port_int:%cp\tdate_time:%t\tfrontend_name:%ft\tbackend_name:%b\tserver_name:%s\ttime_request_int:%Tq\ttime_queue_int:%Tw\ttime_backend_connect_int:%Tc\ttime_backend_response_int:%Tr\ttime_duration_int:%Tt\thttp_status_code_int:%ST\tbytes_read_int:%B\tcaptured_request_cookie:%CC\tcaptured_response_cookie:%CS\ttermination_state:%tsc\tactconn_int:%ac\tfeconn_int:%fc\tbeconn_int:%bc\tsrvconn_int:%sc\tretries_int:%rc\tsrv_queue_int:%sq\tbackend_queue_int:%bq\tcaptured_request_headers:%hr\tcaptured_response_headers:%hs\thttp_request:%r\tmessage:%ci:%cp\ [%t]\ %ft\ %b/%s\ %Tq/%Tw/%Tc/%Tr/%Tt\ %ST\ %B\ %CC\ \ %CS\ %tsc\ %ac/%fc/%bc/%sc/%rc\ %sq/%bq\ %hr\ %hs\ %{+Q}r

Ce format définit non seulement les valeurs journalisées, mais aussi le nom final des champs qui seront utilisés dans Logs Data Platform.

Configuration du template Rsyslog

La configuration de Rsyslog sera enrichie en utilisant un template LTSV au lieu de la configuration par défaut. Si vous avez configuré votre propre collecteur Flowgger sur Logs Data Platform, utilisez son certificat et son nom d'hôte. Si vous souhaitez utiliser l'input LTSV global de votre cluster, rendez-vous sur la page d'accueil pour copier le certificat de votre cluster et obtenir votre port endpoint LTSV. Vous devez choisir le port LTSV line pour ce cas d'usage. L'un des inconvénients de l'utilisation de l'input global est que vous devrez fournir le jeton de votre flux dans un champ X-OVH-TOKEN. Rendez-vous sur la page Flux de données de l'OVHcloud Manager pour récupérer votre jeton.

Voici la configuration rsyslog :

# Supprimer les caractères utf-8 invalides (nécessite rsyslog >=8.3.1, retirez cette partie pour les versions antérieures)
module(load="mmutf8fix")
action(type="mmutf8fix")

# Créer un socket supplémentaire dans le chroot de haproxy afin de permettre la journalisation via
# /dev/log to chroot'ed HAProxy processes
$MaxMessageSize 32k
$EscapeControlCharactersOnReceive off
$AddUnixListenSocket /var/lib/haproxy/dev/log

$DefaultNetstreamDriverCAFile /etc/ssl/certs/global.pem
$DefaultNetstreamDriver gtls # use gtls netstream driver
$ActionSendStreamDriverMode 1 # require TLS for the connection
$ActionSendStreamDriverAuthMode anon # server is NOT authenticated

$ModLoad imuxsock # local message reception
$WorkDirectory /var/spool/rsyslog # default location for work (spool) files
$ActionQueueType LinkedList # use asynchronous processing
$ActionQueueFileName srvrfwd # set file name, also enables disk mode
$ActionResumeRetryCount -1 # infinite retries on insert failure
$ActionQueueSaveOnShutdown on # save in-memory data if rsyslog shuts down

$template ltsv,"X-OVH-TOKEN:``<YOUR STREAM TOKEN><TAB>``time:%timestamp:::date-rfc3339%<TAB>host:%HOSTNAME%<TAB>level:%syslogseverity%<TAB>facility:%syslogfacility%<TAB>program:%app-name%<TAB>pid:%procid%`<TAB>`%msg:2:32768%\n"
$template ltsv_fix,"X-OVH-TOKEN:``<YOUR STREAM TOKEN><TAB>``time:%timestamp:::date-rfc3339%<TAB>host:%HOSTNAME%<TAB>level:%syslogseverity%<TAB>facility:%syslogfacility%<TAB>program:%app-name%<TAB>pid:%procid%`<TAB>`message:%msg:2:32768%\n"

# Envoyer les messages HAProxy vers LDP et un fichier de log dédié
if $programname startswith 'haproxy' then {
if $msg contains '`<TAB>`' then {
@@<your cluster>.logs.ovh.com:12201;ltsv
} else {
@@<your cluster>.logs.ovh.com:12201;ltsv_fix
}
}
if $programname startswith 'haproxy' then /var/log/haproxy.log
&~
Danger

<TAB> sont des placeholders ! Vous devez remplacer chaque <TAB> par de véritables caractères de tabulation.

Dans cette configuration, nous avons ajouté des directives $Action pour obtenir une configuration plus robuste et ne jamais perdre de messages en cas de problème réseau par exemple. Comme mentionné précédemment, vous devez remplacer le chemin $DefaultNetstreamDriverCAFile par le chemin du certificat de votre endpoint. Cette configuration utilise deux templates employés dans deux cas différents. Le premier est utilisé lorsque le message entrant est au format LTSV. Nous le détectons en recherchant des caractères de tabulation dans le message. S'il n'y a pas de tabulation, nous utilisons le second template : cela signifie qu'il s'agit d'un message inattendu et, pour ne pas le perdre, nous l'encapsulons dans un champ dédié message:. Ces templates ajoutent certaines informations comme le jeton. Vous devez placer votre propre jeton de flux dans les deux templates et vous pouvez également ajouter n'importe quel champ personnalisé.

Filebeat

Filebeat et son module HAProxy vous permettent de vous passer entièrement de l'étape de formatage des logs. Vous aurez tout de même besoin de RSyslog ou d'un équivalent pour récupérer les logs depuis HAProxy. Sur Debian/Ubuntu, le paquet HAProxy configure également le fichier de configuration rsyslog au chemin suivant /etc/rsyslog.d/49-haproxy.conf. Vous devrez peut-être redémarrer Rsyslog pour voir les logs apparaître dans le chemin par défaut /var/log/haproxy.log.

Après avoir téléchargé filebeat, vous devez activer le module HAProxy en exécutant la commande suivante :

sudo filebeat modules enable haproxy

Modifiez votre fichier de configuration filebeat.yml pour inclure l'extrait suivant afin d'activer la lecture des fichiers de log dans le module et de configurer filebeat avec notre input OpenSearch spécial.

filebeat.modules:
- module: haproxy
  log:
    enabled: true
    var.paths: ["/var/log/haproxy.log"]
    var.input: "file"

fields_under_root: true
fields:
  X-OVH-TOKEN: <your-stream-token>

setup.template.enabled: false

output.elasticsearch:
  # Array of hosts to connect to.
  hosts: ["<your-cluster>.logs.ovh.com:9200"]

  # Protocol - either `http` (default) or `https`.
  #protocol: "https"

  # Authentication credentials - either API key or username/password.
  username: "<your-ldp-username-or-your-token>"
  password: "<your-password-or-token>"
  index: "ldp-logs"

Dans cette configuration, vous devez remplacer le jeton par la valeur X-OVH-TOKEN de votre flux de destination. Notez que vous devez également indiquer le nom d'utilisateur et le mot de passe ou votre jeton. Ne modifiez pas l'index de destination ldp-logs. Démarrez votre filebeat et rendez-vous sur Logs Data Platform pour commencer à analyser vos logs.

$ sudo systemctl enable filebeat
$ sudo systemctl start filebeat

Tableau de bord et alertes

Voici un exemple de tableau de bord que vous pouvez créer à partir des logs HAProxy. Les logs HAProxy vous donnent de nombreuses informations sur votre application et votre infrastructure. C'est à vous de les exploiter de la manière qui vous convient le mieux. Vous pouvez également configurer des alertes pour être averti quand un backend est en panne ou ne répond pas correctement.

dashboard\_1 dashboard\_2 dashboard\_3

Aller plus loin

Cette page vous a-t-elle aidé ?