Référence de configuration de l'agent

L'agent redirection.io est un logiciel qui s'exécute sur votre serveur et vous permet de synchroniser des données depuis et vers la plateforme redirection.io. Il est utilisé pour fournir un moyen efficace et performant d'appliquer les règles redirection.io sur votre infrastructure, et pour collecter les logs et les métriques de votre serveur.

Cette page fournit une référence de la configuration de l'agent, avec des explications sur les différentes options de configuration disponibles. Il est recommandé de lire cette page de documentation avant de configurer l'agent, afin de comprendre les différentes options et leurs implications.

Format et emplacement de la configuration

L'agent peut être configuré à l'aide d'un seul fichier de configuration, au format YAML, JSON ou TOML. Par défaut, l'agent recherche un fichier de configuration dans les emplacements suivants (par ordre de priorité) :

/etc/redirectionio/agent.yml
/etc/redirectionio/agent.yaml
/etc/redirectionio/agent.json
/etc/redirectionio/agent.toml

La configuration par défaut de l'agent se trouve dans le fichier /etc/redirectionio/agent.yml.

Recharger la configuration de l'agent

Lorsque vous modifiez le fichier de configuration de l'agent, vous devez recharger l'agent afin d'appliquer la nouvelle configuration. Cela peut être fait en utilisant le fichier de service systemctl :

$ sudo systemctl reload redirectionio-agent.service

Alternativement, vous pouvez également recharger l'agent en envoyant un signal SIGHUP au processus de l'agent :

$ sudo kill -SIGHUP $(pidof redirectionio-agent)

Utilisation de variables d'environnement dans le fichier de configuration

Il est possible d'utiliser des variables d'environnement dans le fichier de configuration, ce qui peut être utile dans des environnements dynamiques comme les déploiements basés sur le cloud :

Voir cet exemple :

instance:
    name: "${REDIRECTIONIO_INSTANCE_NAME}"
    persist: "${REDIRECTIONIO_APPLICATION_DIR}/rules"
log:
    -
        output: "file"
        level: "info"
        path: "${REDIRECTIONIO_APPLICATION_DIR}/log/agent.log"

Dans cet exemple, les variables d'environnement REDIRECTIONIO_INSTANCE_NAME et REDIRECTIONIO_APPLICATION_DIR doivent être définies lors du démarrage de l'agent (bien sûr, vous pouvez utiliser n'importe quel nom pour les variables d'environnement). Si elles ne sont pas définies, les variables ne seront pas remplacées, et vous obtiendrez évidemment une erreur :

$ redirectionio-agent

2026-09-26T16:07:17.753395Z ERROR cannot open file ${REDIRECTIONIO_APPLICATION_DIR}/log/agent.log: No such file or directory (os error 2)

Lorsque les variables d'environnement requises sont définies, elles sont interprétées lors du démarrage de l'agent.

Si elle est définie, la variable d'environnement spéciale HTTPS_PROXY sera utilisée par l'agent pour router les communications avec les API redirection.io via un proxy https.

Structure de la configuration

La configuration de l'agent est sémantiquement divisée en cinq sections principales :

La section instance : pour configurer l'agent sur la manière de synchroniser les données avec la plateforme redirection.io
La section server : un serveur tcp utilisé par les modules nginx et apache
La section reverse_proxy : pour configurer l'agent en tant que reverse proxy
La section metrics : pour configurer les métriques que vous pouvez collecter pour superviser l'agent
La section log : pour configurer les logs techniques et de trafic de l'agent

instance

La section instance est utilisée pour configurer l'agent sur la manière de synchroniser les données avec la plateforme redirection.io. Elle expose plusieurs options pour configurer le nom de l'instance, la persistance des données, le cache des règles et plus encore.

name

Type : string
Défaut : -
Cette directive est requise

La directive de configuration name permet de donner un nom à cette instance d'agent. Vous devez utiliser un nom unique pour ce paramètre parmi tous les agents s'exécutant pour votre projet. Sinon, l'agent apparaîtra comme "mal configuré" sur le tableau de bord du projet (son nom sera le hostname du serveur exécutant l'agent), et ses logs seront ignorés.

Si aucun nom d'instance n'est fourni dans la configuration, le hostname du serveur sera utilisé.

Une bonne idée peut être d'utiliser une combinaison du hostname et de l'environnement de déploiement pour instance.name. N'oubliez pas non plus que vous pouvez utiliser des variables d'environnement n'importe où dans le fichier de configuration.

cache

Type : integer
Défaut : 10000
Cette directive est facultative

Lors de l'utilisation de l'agent redirection.io, les règles sont stockées en mémoire et organisées à l'aide d'une structure de données spécifique qui permet d'optimiser les performances de matching des règles. Cette structure de données peut consommer beaucoup de mémoire lorsque le nombre d'expressions régulières dans les règles est élevé. Pour éviter de consommer trop de mémoire, seul un nombre limité d'expressions régulières compilées est stocké en mémoire, les autres sont compilées à la volée, si nécessaire. Cela peut entraîner une baisse de performance lorsque le nombre d'expressions régulières est élevé et que l'agent doit les compiler à la volée.

La directive de configuration cache définit combien de versions compilées des expressions régulières sont stockées en mémoire (RAM). Ce paramètre rend l'agent beaucoup plus rapide, mais peut consommer plus de mémoire sur des ensembles de règles très volumineux s'il est réglé à une valeur élevée.

La valeur par défaut est 10000, ce qui devrait utiliser environ 150-200 Mo de mémoire pour un ensemble de règles très volumineux. Il n'est pas nécessaire de régler cette valeur beaucoup plus haut, car l'agent mettra en cache en priorité les chemins les plus sollicités.

Vous pouvez désactiver complètement le cache mémoire des règles, afin de minimiser l'utilisation de la mémoire, en définissant cache: 0. Dans ce cas, l'agent compilera toutes les expressions régulières à la volée si nécessaire, ce qui peut entraîner une baisse de performance.

logging

Type : boolean
Défaut : undefined
Cette directive est facultative

Le paramètre logging permet de définir le comportement de logging pour cette instance. S'il est défini sur true, l'instance sera marquée comme autorisée à enregistrer le trafic. S'il est défini sur false, l'instance ne collectera pas de logs de trafic. Si ce paramètre n'est pas défini, il sera géré par la valeur définie dans l'interface graphique du manager.

Cette option doit être un booléen ; toute valeur non booléenne est considérée comme invalide et traitée comme si le paramètre n'était pas défini. Lorsqu'il est explicitement défini, ce paramètre prime sur le comportement de logging défini dans l'interface graphique du manager.

persist

Type : boolean ou string ou object
Défaut : /var/lib/redirectionio
Cette directive est facultative

La directive de configuration persist permet de définir s'il faut ou non stocker les données sur le disque. Par "données", nous entendons :

les règles téléchargées depuis la plateforme redirection.io, qui sont stockées dans un format compilé pour être utilisées par l'agent ;
les certificats SSL générés à l'aide d'ACME et utilisés par l'agent lorsqu'il est configuré en tant que reverse proxy.

Le stockage de ces données sur le disque permet de les conserver en cas de redémarrage de l'agent, et d'éviter d'appeler le backend de redirection.io pour obtenir les règles au démarrage. Cela peut être utile en cas de problèmes de réseau entre l'agent et le backend de redirection.io, ou pour accélérer le temps de démarrage de l'agent.

La directive persist peut être définie sur true, false, une chaîne de caractères ou un objet. Si elle est définie sur true, l'agent stockera les données persistantes dans le répertoire par défaut (/var/lib/redirectionio). Si elle est définie sur false, l'agent ne stockera pas de données sur le disque. Si elle est définie sur une chaîne de caractères, l'agent stockera les données persistantes dans le répertoire spécifié :

instance:
  persist: /tmp/redirectionio-rules

max_logs_buffer_size

Type : integer
Défaut : 100000
Cette directive est facultative

La directive de configuration max_logs_buffer_size permet de définir le nombre maximum de logs pouvant être mis en mémoire tampon avant d'être envoyés à la plateforme redirection.io. Ce paramètre peut être utile pour éviter de consommer trop de mémoire lorsque le trafic est élevé et que l'agent n'est pas en mesure d'envoyer les logs à la plateforme redirection.io assez rapidement.

Si le buffer est plein, l'agent commencera à supprimer des logs et enregistrera un message d'avertissement.

La valeur par défaut est 100000, ce qui devrait être suffisant pour la plupart des cas d'utilisation. Vous pouvez augmenter cette valeur si vous avez un trafic très élevé et souhaitez éviter de perdre des logs, mais gardez à l'esprit que cela peut consommer plus de mémoire. N'oubliez pas que les logs sont envoyés périodiquement à la plateforme redirection.io, le buffer ne devrait donc pas rester plein pendant longtemps. De plus, bien que collecter et envoyer un très grand nombre de logs à la plateforme redirection.io ne soit pas un problème, votre projet doit être configuré pour accepter ce nombre élevé de logs, sinon ils seront supprimés par la plateforme. Vous pouvez vérifier les limites de logs pour votre projet dans les paramètres de projet de l'interface graphique du manager.

server

type : boolean ou object
défaut : false
cette directive est facultative

La section server est utilisée pour configurer le serveur TCP qui est utilisé par les modules nginx et apache pour communiquer avec l'agent. Par défaut, le serveur est désactivé, mais il peut être activé en définissant la directive server à true ou à un objet. Lorsqu'il est activé, le serveur écoute sur l'adresse listen (voir ci-dessous) et accepte les connexions des modules nginx et apache pour appliquer les règles redirection.io sur les requêtes entrantes.

La valeur true est un raccourci pour activer le serveur avec la configuration par défaut. Si vous souhaitez personnaliser la configuration du serveur, vous pouvez définir la directive server comme un objet, qui peut contenir les propriétés suivantes :

listen

Type : string
Défaut : 127.0.0.1:10301
Cette directive est facultative

La directive de configuration listen détermine sur quelle interface l'agent écoute. Elle est par défaut 127.0.0.1:10301 (port 10301 sur le localhost), mais peut prendre d'autres valeurs :

/var/run/redirectionio.sock : si vous préférez utiliser un fichier, assurez-vous que l'utilisateur exécutant l'agent (redirectionio, par défaut) a le droit de créer ce fichier
"" : une chaîne vide, si vous voulez que votre agent écoute sur toutes les interfaces réseau, sur le port 10301 (non conseillé)

project_keys

Type : list of strings
Défaut : []
Cette directive est facultative

Le paramètre project_keys permet de précharger l'agent avec les ensembles de règles de certains projets au démarrage. Si cette directive n'est pas définie, l'agent démarrera avec un ensemble de règles vide, et il ne chargera les règles pour votre ou vos projets que lors de l'arrivée de la première requête.

Afin d'éviter que les premières requêtes n'échouent (parce que l'ensemble de règles n'aurait pas été chargé à temps), vous pouvez utiliser cette directive de configuration pour définir une liste de project keys à charger au démarrage de l'agent.

reverse_proxy

La section reverse_proxy configure le reverse proxy HTTP intégré de l'agent redirection.io. Elle permet à l'agent d'agir comme un proxy autonome, recevant directement le trafic et servant soit des fichiers locaux, soit transmettant les requêtes à un backend tout en appliquant vos règles de redirection et de SEO. Voir la documentation détaillée sur l'utilisation de l'agent comme reverse proxy dans la page de documentation dédiée.

listen

Type : list of strings
Défaut : []
Cette directive est requise

La directive de configuration listen du reverse proxy permet de lister les adresses et les protocoles sur lesquels le reverse proxy va écouter le trafic. Les schémas supportés incluent :

tcp://<ip>:<port> : HTTP/1.1 standard
unix://<path> : HTTP/1.1 via des sockets de domaine Unix
tls://<ip>:<port> : HTTP sécurisé (HTTP/1.1 et HTTP/2)
quic://<ip>:<port> : HTTP/3 (protocole QUIC).

forward

Type : object
Défaut : null

Le nœud de configuration reverse_proxy.forward définit comment le proxy gère la requête après l'exécution de la règle. Il peut soit servir des fichiers locaux, soit transmettre les requêtes à un backend.

Transfert vers un proxy backend (forward "address")

Dans cette configuration, l'agent transmet la requête à un serveur backend, qui peut être votre serveur d'application ou tout autre serveur HTTP. L'agent applique les règles redirection.io avant de transmettre la requête, et peut modifier la requête et la réponse selon les besoins.

Pour cette configuration, la directive forward doit être définie comme un objet contenant les propriétés suivantes :

address : (chaîne, requise) l'adresse du serveur backend. Il peut s'agir d'un hostname ou d'une adresse IP, et doit inclure un port (par exemple, 127.0.0.1:8080 ou backend-server:8080).
max_http_version : (chaîne) l'une des valeurs h1, h2 ou h3 pour indiquer la version HTTP maximale à utiliser lors de la communication avec le backend
request_host : (chaîne) pour surcharger le header Host envoyé au backend.
forwarded_for : (chaîne) la stratégie à utiliser pour les headers de transfert (auto, false, none, legacy, rfc7239).
allow_ipv6 : (booléen, défaut false) pour activer ou désactiver l'IPv6 pour les connexions backend.
tls : (booléen ou objet) Active le TLS vers le backend.
- sni : (chaîne) Server Name Indication à utiliser.
- allow_invalid_certificates : (booléen, défaut false) Autorise les certificats auto-signés.
keep_alive : (booléen ou objet, défaut false)
- idle_timeout : (durée, par exemple, 30s) définit le temps pendant lequel une connexion inactive reste ouverte.
- born_timeout : (durée, par exemple, 1h) définit la durée de vie maximale d'une connexion keepalive.
- max_requests : (entier) limite le nombre de requêtes par connexion unique.
timeout : (objet)
- resolve : (durée, par exemple, 100ms) le temps maximum d'attente pour la résolution du hostname du serveur backend (si l'adresse de forward est définie comme un hostname)
- connect : (durée, par exemple, 100ms) le temps maximum d'attente pour que la connexion au serveur backend soit établie
- tls_handshake : (durée, par exemple, 100ms) le temps maximum d'attente pour que le handshake TLS soit terminé (lors de la connexion à un serveur backend TLS)
- request : (durée, par exemple, 1s) le temps maximum d'attente pour que la requête soit envoyée au serveur backend. Le timeout est réinitialisé chaque fois que de nouvelles données sont envoyées.
- response : (durée, par exemple, 1s) le temps maximum d'attente pour que la réponse soit reçue du serveur backend. Le timeout est réinitialisé chaque fois que de nouvelles données sont reçues.

Fichiers statiques (forward "directory")

Comme alternative au proxying backend, la stratégie forward: directory permet d'exposer un répertoire local.

directory : (chaîne, requise) le chemin local d'où servir les fichiers statiques

agent

Type : object
Défaut : null

Le nœud de configuration reverse_proxy.agent contrôle le comportement du moteur redirection.io pour cette instance. Il contient plusieurs directives :

project_key

Type : string
Défaut : -
Cette directive est requise

Il s'agit de la project key à utiliser pour ce proxy HTTP. Les requêtes HTTP reçues par ce proxy seront comparées à l'ensemble de règles du projet redirection.io associé à la project key, et les transformations définies dans les règles (redirections, etc.) seront exécutées directement au niveau du proxy.

override_request_host

Type : string
Défaut : -
Cette directive est facultative

Cette directive permet de forcer le hostname à utiliser lors du matching de la requête. Ceci est utile si vous avez défini des règles utilisant des déclencheurs URL avec des valeurs d'URL absolues (contenant un schéma, un nom de domaine, etc.), alors que le proxy reçoit les requêtes en utilisant un autre hostname.

Veuillez noter que, la plupart du temps, vous devriez préférer l'utilisation de la directive trusted_proxies avec le header de requête X-Forwarded-Host correct.

override_request_scheme

Type : string
Défaut : -
Valeurs possibles : http ou https
Cette directive est facultative

Cette directive permet de forcer le schéma à utiliser lors du matching de la requête. Ceci est utile si vous avez défini des règles utilisant un déclencheur URL avec une valeur d'URL absolue (contenant un schéma, un nom de domaine, etc.), mais que vous souhaitez utiliser les mêmes règles dans une définition de proxy avec un autre schéma.

Imaginez, par exemple, une définition de proxy écoutant uniquement le trafic https, utilisant un projet dans lequel les règles sont définies en utilisant le schéma http:// : les URL ne correspondraient jamais, car aucune règle n'utilise le schéma https://. Dans ce cas, régler la valeur de override_request_scheme sur http forcera le matching à être effectué avec ce schéma, et non le schéma réel de la requête.

Veuillez noter que, la plupart du temps, vous devriez préférer l'utilisation de la directive trusted_proxies avec le header de requête X-Forwarded-Scheme correct.

add_rule_ids_header

Type : boolean
Défaut : false
Cette directive est facultative

Si ce paramètre est activé (valeur true), un header de réponse nommé X-RedirectionIo-RuleIds sera ajouté à la réponse. Sa valeur contiendra la liste des identifiants de règles redirection.io appliquées à cette réponse, séparés par le caractère ;.

trusted_proxies

Ce nœud de configuration définit quels proxies amont sont autorisés à transmettre des informations client, et quels headers ils sont autorisés à définir.

ips : (liste de chaînes, requise) définit la liste des adresses IP ou des plages CIDR de confiance.
forwarded : (booléen, défaut true) définit s'il faut ou non faire confiance au header standard Forwarded.
x_forwarded_for : (booléen, défaut true) définit s'il faut ou non faire confiance au header X-Forwarded-For.
x_forwarded_host : (booléen, défaut false) définit s'il faut ou non faire confiance au header X-Forwarded-Host pour l'hôte original.
x_forwarded_proto : (booléen, défaut false) définit s'il faut ou non faire confiance au header X-Forwarded-Proto pour le schéma original.

http

Le nœud de configuration reverse_proxy.http permet de configurer plusieurs aspects de la gestion des requêtes.

cache

Type : boolean
Défaut : false
Cette directive est facultative

Même si ce n'est pas son but premier, l'agent redirection.io peut être utilisé comme reverse proxy de mise en cache. Il respecte les headers de cache http standard et stocke en mémoire les réponses autorisées à être stockées dans des caches partagés. L'agent utilisera au maximum 1 Go de mémoire pour ce cache de réponses.

compress

Type : boolean
Défaut : false
Cette directive est facultative

La directive de configuration reverse_proxy.http.compress peut être utilisée pour que l'agent compresse les réponses en utilisant gzip ou brotli, ce qui peut réduire la taille des réponses et améliorer les performances réseau de votre site web.

geo_ip

Type : object
Défaut : null
Cette directive est facultative

Cette directive peut être utilisée pour configurer une base de données MaxMind (.mmdb) au niveau de l'agent, afin qu'il puisse ajouter des headers de géolocalisation personnalisés aux requêtes entrantes. Voir la documentation détaillée sur la configuration d'une base de données GeoIP.

Le nœud geo_ip, s'il est configuré, doit avoir des sous-propriétés :

path : (chaîne, requise) le chemin vers une base de données MaxMind .mmdb
headers : une correspondance de noms de headers et de chemins JSON dans la base de données (sous la forme X-Country: "$.country.iso_code")

access_log

Les nœuds de configuration reverse_proxy.access_log permettent de configurer la collecte des logs de trafic au niveau du reverse proxy.

output

Type : string
Valeurs possibles : stdout, stderr, file ou syslog
Cette directive est requise si access_log est défini

Définit la sortie des logs d'accès. La valeur file permet de logger dans un fichier, les valeurs stdout et stderr permettent de logger sur les flux de sortie standard et d'erreur standard, et la valeur syslog permet de logger dans le syslog du système.

Lors du logging vers un fichier, la directive path doit être définie (voir ci-dessous). Lors du logging vers syslog, la directive address doit être définie.

format

Type : string
Valeurs possibles : text ou json
Défaut :
- text pour file, stdout et stderr
- rfc5424 pour syslog
Cette directive est facultative

Définit le format des logs d'accès. La valeur json permet de logger au format JSON, la valeur text permet de logger dans un format lisible par l'homme, les valeurs rfc5424 et rfc3164 permettent de logger dans les formats syslog correspondants.

path

Type : string
Défaut : -
Cette directive est requise si output est réglé sur file

Définit le chemin du fichier de log lorsque la directive output est réglée sur file. L'agent doit avoir le droit de créer ce fichier et d'y écrire.

address

Type : string
Défaut : -
Cette directive est requise si output est réglé sur syslog

Définit l'adresse du serveur syslog lorsque la directive output est réglée sur syslog.

certificate

Les nœuds de configuration reverse_proxy.certificate permettent de configurer les certificats TLS pour les connexions chiffrées. Ce nœud de configuration est requis si vous souhaitez utiliser les schémas tls:// ou quic:// dans la directive reverse_proxy.listen, et il est ignoré sinon.

acme

Définir le nœud reverse_proxy.certificate.acme permet à l'agent de gérer automatiquement les certificats TLS pour vos domaines en utilisant le protocole ACME (par exemple, via Let's Encrypt). L'agent demandera et renouvellera automatiquement les certificats pour les domaines définis dans la section virtual_hosts. Si le répertoire instance.persist est défini, les certificats seront stockés de manière persistante, ils seront donc conservés en cas de redémarrage de l'agent.

Le nœud acme doit contenir les propriétés suivantes :

contacts : (liste de chaînes) la liste des adresses e-mail pour les notifications d'expiration et de renouvellement de certificat
directory_url : (chaîne) l'endpoint de l'API ACME à utiliser (par exemple, https://acme-v02.api.letsencrypt.org/directory pour Let's Encrypt).

file

Ce nœud de configuration permet de définir manuellement les certificats TLS à utiliser pour les connexions chiffrées. Il doit contenir les propriétés suivantes :

certificates : (liste de chaînes) les chemins vers les chaînes de certificats
key : (chaîne) le chemin vers la clé privée

Il est possible de combiner les stratégies de gestion de certificats file et acme, afin que l'agent utilise les certificats définis manuellement au démarrage, puis passe automatiquement aux certificats gérés par ACME lorsqu'ils sont prêts.

virtual_hosts

Le concept de "virtual host" (ou "hôte virtuel") permet de définir des configurations spécifiques pour des domaines spécifiques, ce qui peut être utile si vous souhaitez appliquer des règles différentes ou utiliser des certificats différents pour différents domaines. Un virtual host est défini par une liste de domaines, et peut contenir des surcharges pour tous les autres nœuds de configuration reverse_proxy : agent, forward, http, access_log et certificate.

Les domaines listés dans la section virtual_hosts seront comparés au header Host des requêtes entrantes, et la configuration du virtual host correspondant sera appliquée si une correspondance est trouvée. Si aucune correspondance n'est trouvée, la configuration par défaut (définie à la racine de la section reverse_proxy) sera appliquée.

Le nœud de configuration reverse_proxy.virtual_hosts.*.domains doit être une liste de (sous-)domaines, et est requis pour chaque définition de virtual host.

Threading et performance

La section reverse_proxy permet également de configurer certaines valeurs liées aux performances :

server_threads : (entier) threads pour accepter les connexions. Par défaut 1.
worker_threads : (entier) threads pour traiter les requêtes. Par défaut, le nombre de cœurs CPU.
worker_max_blocking_threads : (entier) threads maximum par worker pour les opérations bloquantes.

Vous ne devriez normalement pas avoir besoin de modifier ces valeurs, car la configuration par défaut est conçue pour fournir de bonnes performances dans la plupart des cas. Cependant, dans certains cas spécifiques (par exemple, trafic très élevé ou temps de traitement très longs), vous pourriez vouloir ajuster le nombre de threads worker pour améliorer le débit du reverse proxy. Vous pouvez lire notre documentation détaillée sur l'ajustement des performances du reverse proxy pour plus d'informations et d'exemples.

metrics

Lors de l'exploitation d'une infrastructure, les ingénieurs plateforme et les ops ont souvent besoin de surveiller le fonctionnement des services et de pouvoir détecter si des problèmes sont sur le point de survenir. L'agent redirection.io expose un point de terminaison de surveillance optionnel au format compatible Prometheus, qui fournit plusieurs métriques destinées à être chargées par votre tableau de bord de surveillance préféré.

Lisez notre documentation détaillée sur la supervision de l'agent pour plus d'informations sur les métriques disponibles et comment les utiliser.

listen

Type : string
Défaut : -
Cette directive est facultative

L'adresse de l'interface de surveillance http à écouter, sous la forme adresse:port. Les valeurs valides sont, par exemple, 0.0.0.0:8080 (pour écouter sur toutes les interfaces réseau), 127.0.0.1:8080, etc.

log

Cette section facultative contient des directives pour configurer le logging technique de l'agent (redémarrages, erreurs, avertissements, etc.). Si cette section est absente du fichier de configuration, l'agent n'enregistrera pas les erreurs ou les avertissements.

output

Type : string
Valeurs possibles : file, stdout, stderr, syslog
Cette directive est requise

Définit où les logs de l'agent sont envoyés. La valeur file permet de logger dans un fichier, les valeurs stdout et stderr permettent de logger sur les flux de sortie standard et d'erreur standard, et la valeur syslog permet de logger dans le syslog du système.

Lors du logging vers un fichier, la directive path doit être définie (voir ci-dessous). Lors du logging vers syslog, la directive address doit être définie.

path

Type : string
Défaut : -
Cette directive est facultative

Définit le chemin du fichier de log lorsque la directive output est réglée sur file. L'agent doit avoir le droit de créer ce fichier et d'y écrire.

Si cette directive est définie alors que la directive output n'est pas réglée sur file, elle sera ignorée.

address

Type : string
Défaut : -
Cette directive est facultative

Définit l'adresse du serveur syslog lorsque la directive output est réglée sur syslog.

Si cette directive est définie alors que la directive output n'est pas réglée sur syslog, elle sera ignorée.

format

Type : string
Valeurs possibles : json, text, rfc5424, rfc3164
Défaut :
- text pour file, stdout et stderr
- rfc5424 pour syslog
Cette directive est facultative

Définit le format des logs. La valeur json permet de logger au format JSON, la valeur text permet de logger dans un format lisible par l'homme, les valeurs rfc5424 et rfc3164 permettent de logger dans les formats syslog correspondants.

Veuillez noter que :

les formats rfc5424 et rfc3164 sont uniquement disponibles lorsque la directive output est réglée sur syslog, et que le format par défaut pour syslog est rfc5424.
les formats text et json sont uniquement disponibles lorsque la directive output est réglée sur file, stdout ou stderr, et que le format par défaut pour ces sorties est text.

min_level

Type : string
Valeurs possibles : debug, info, warning, error
Défaut : -
Cette directive est facultative

Cette option permet de définir le niveau minimum des logs envoyés à la sortie. Par exemple, la valeur warning permet de logger uniquement les avertissements et les erreurs.

Si elle n'est pas définie, l'agent ne restreindra pas les logs à un niveau minimum.

max_level

Type : string
Valeurs possibles : debug, info, warning, error
Défaut : -
Cette directive est facultative

Cette option permet de définir le niveau maximum des logs envoyés à la sortie. Par exemple, la valeur warning permet de logger uniquement les logs de debug, d'info et d'avertissement.

Si elle n'est pas définie, l'agent ne restreindra pas les logs à un niveau maximum.

Exemples de configuration

Nous fournissons une liste d'exemples de configuration pour explorer toutes les possibilités de configuration. Consultez-la pour vous inspirer pour votre propre configuration !

Cette page a été mise à jour le 30 mars 2026

Vous ne trouvez pas votre réponse ?

Contactez notre support