Configurer l'agent Ops

Ce document fournit des détails sur les configurations par défaut et personnalisées de l'agent Ops. Lisez ce document si vous répondez à l'un des cas suivants :

• Vous souhaitez modifier la configuration de l'agent Ops pour atteindre les objectifs suivants :

  • Désactiver l'ingestion de métriques ou de journalisation intégrée.

    • Pour désactiver l'ingestion de journaux, consultez la section Exemples de configurations service de journalisation.

    • Pour désactiver l'ingestion des métriques d'hôte, consultez la section Exemples de configurations service de métriques.

  • Personnaliser le chemin d'accès aux fichiers journaux à partir desquels l'agent collecte les journaux. Consultez la section Récepteurs de journalisation.

  • Personnaliser le format du journal structuré que l'agent utilise pour traiter les entrées de journal, en analysant les données JSON ou en utilisant des expressions régulières. Consultez la section Processeurs de journalisation.

  • Modifier le taux d'échantillonnage des métriques consultez la section Récepteurs des métriques.

  • Personnaliser le ou les groupes de métriques à activer. Par défaut, l'agent collecte toutes les métriques système, telles que cpu et memory. Consultez la section Processeurs de métriques.

  • Personnaliser la rotation des journaux par l'agent ; consultez la section Configuration de la rotation des journaux.

  • Collectez les métriques et les journaux des applications tierces compatibles. Pour obtenir la liste des applications compatibles, consultez la section Surveiller des applications tierces.

  • Utilisez le récepteur Prometheus pour collecter des métriques personnalisées.

  • Utiliser le récepteur OTLP (protocole OpenTelemetry) pour collecter des métriques et des traces personnalisées.

• Vous souhaitez découvrir les détails techniques de la configuration de l'agent Ops.

Modèle de configuration

L'agent Ops utilise une configuration par défaut intégrée. Vous ne pouvez pas modifier directement cette configuration intégrée. À la place, vous créez un fichier de remplacements qui sont fusionnés avec la configuration intégrée au redémarrage de l'agent.

Les composants de la configuration sont les suivants :

• receivers : cet élément décrit ce qui est collecté par l'agent.
• processors : cet élément décrit comment l'agent peut modifier les informations collectées.
• service : cet élément associe les récepteurs et les processeurs pour créer des flux de données, appelés pipelines. L'élément service comporte un élément pipelines, qui peut contenir plusieurs pipelines.

La configuration intégrée est composée de ces éléments, et vous utilisez les mêmes éléments pour remplacer cette configuration intégrée.

Configuration intégrée

La configuration intégrée de l'agent Ops définit la collection par défaut pour les journaux et les métriques. L'exemple suivant montre la configuration intégrée pour Linux et Windows :

logging:
  receivers:
    syslog:
      type: files
      include_paths:
      - /var/log/messages
      - /var/log/syslog
  service:
    pipelines:
      default_pipeline:
        receivers: [syslog]
metrics:
  receivers:
    hostmetrics:
      type: hostmetrics
      collection_interval: 60s
  processors:
    metrics_filter:
      type: exclude_metrics
      metrics_pattern: []
  service:
    pipelines:
      default_pipeline:
        receivers: [hostmetrics]
        processors: [metrics_filter]

logging:
  receivers:
    windows_event_log:
      type: windows_event_log
      channels: [System, Application, Security]
  service:
    pipelines:
      default_pipeline:
        receivers: [windows_event_log]
metrics:
  receivers:
    hostmetrics:
      type: hostmetrics
      collection_interval: 60s
    iis:
      type: iis
      collection_interval: 60s
    mssql:
      type: mssql
      collection_interval: 60s
  processors:
    metrics_filter:
      type: exclude_metrics
      metrics_pattern: []
  service:
    pipelines:
      default_pipeline:
        receivers: [hostmetrics, iis, mssql]
        processors: [metrics_filter]

Ces configurations sont décrites plus en détail dans les sections Configuration de journalisation et Configuration de métriques.

Configuration spécifiée par l'utilisateur

Pour remplacer la configuration intégrée, vous ajoutez de nouveaux éléments de configuration au fichier de configuration utilisateur. Placez votre configuration pour l'agent Ops dans les fichiers suivants :

• Pour Linux : /etc/google-cloud-ops-agent/config.yaml
• Pour Windows : C:\Program Files\Google\Cloud Operations\Ops Agent\config\config.yaml

Toute configuration spécifiée par l'utilisateur est fusionnée avec la configuration intégrée au redémarrage de l'agent.

Pour remplacer un récepteur, un processeur ou un pipeline intégré, redéfinissez-le dans votre fichier config.yaml en le déclarant avec le même identifiant. À partir de la version 2.31.0 de l'agent Ops, vous pouvez également configurer la fonctionnalité de rotation des journaux de l'agent. Pour en savoir plus, consultez la section Configurer la rotation des journaux dans l'agent Ops.

Par exemple, la configuration intégrée des métriques inclut un récepteur hostmetrics qui spécifie un intervalle de collecte de 60 secondes. Pour définir l'intervalle de collecte des métriques d'hôte sur 30 secondes, incluez un récepteur de métriques appelé hostmetrics dans votre fichier config.yaml qui définit la valeur collection_interval sur 30 secondes, comme illustré dans l'exemple suivant :

metrics:
  receivers:
    hostmetrics:
      type: hostmetrics
      collection_interval: 30s

Pour voir d'autres exemples de modification des configurations intégrées, consultez les pages Configuration de journalisation et Configuration des métriques. Vous pouvez également désactiver la collecte des données de journalisation ou de métriques. Ces modifications sont décrites dans les exemples de configurations de service de journalisation et de configurations de service de métriques.

Vous pouvez utiliser ce fichier pour empêcher l'agent de collecter les journaux automatiques et de les envoyer à Cloud Logging. Pour en savoir plus, consultez Collecter les journaux personnels.

Vous pouvez également configurer la fonctionnalité de rotation des journaux de l'agent à l'aide de ce fichier. Pour en savoir plus, consultez la section Configurer la rotation des journaux dans l'agent Ops.

Vous ne pouvez pas configurer l'Agent Ops pour exporter les journaux ou les métriques vers des services autres que Cloud Logging et Cloud Monitoring.

Configurations de journalisation

La configuration logging utilise le modèle de configuration décrit précédemment :

• receivers : cet élément décrit les données à collecter à partir de fichiers journaux. Ces données sont mappées dans un modèle <timestamp, record>.
• processors : cet élément facultatif décrit comment l'agent peut modifier les informations collectées.
• service : cet élément associe les récepteurs et les processeurs pour créer des flux de données, appelés pipelines. L'élément service contient un élément pipelines qui peut inclure plusieurs définitions de pipeline.

Chaque récepteur et chaque processeur peut être utilisé dans plusieurs pipelines.

Les sections suivantes décrivent chacun de ces éléments.

L'Agent Ops envoie des journaux à Cloud Logging. Vous ne pouvez pas le configurer pour exporter les journaux vers d'autres services. Vous pouvez toutefois configurer Cloud Logging pour l'exportation des journaux. Pour en savoir plus, consultez la section Acheminer les journaux vers des destinations compatibles.

Destinataires de journalisation

L'élément receivers contient un ensemble de récepteurs, chacun étant identifié par un RECEIVER_ID. Un récepteur décrit comment récupérer les journaux (par exemple, en affichant les dernières lignes des fichiers, via un port TCP, ou depuis le journal des événements Windows).

Structure des récepteurs de journalisation

Chaque récepteur doit avoir un identifiant, RECEIVER_ID, et inclure un élément type. Les types valides sont les suivants :

• files : collecter des journaux en affichant les dernières lignes des fichiers sur le disque.
• fluent_forward (versions 2.12.0 et ultérieures de l'agent Ops) : collecter les journaux envoyés à l'aide du protocole Fluent Forward via TCP.
• tcp (versions 2.3.0 et ultérieures de l'agent Ops) : collecter les journaux au format JSON en écoutant un port TCP.
• Linux uniquement :
  • syslog : collecter des messages Syslog via TCP ou UDP
  • systemd_journald (versions 2.4.0 et ultérieures de l'agent Ops) : collecter les journaux de journal systemd à partir du service systemd-journald.
• Windows uniquement :
  • windows_event_log : collecter des journaux d'événements Windows à l'aide de l'API Windows Event Log.
• Récepteurs de journaux des applications tierces

La structure receivers se présente comme suit :

receivers:
  RECEIVER_ID:
    type: files
    ...
  RECEIVER_ID_2:
    type: syslog
    ...

En fonction de la valeur de l'élément type, d'autres options de configuration peuvent être définies, comme suit :

• Récepteurs files :

  • include_paths : valeur obligatoire. Liste des chemins d'accès du système de fichiers à lire en affichant chaque fichier. Un caractère générique (*) peut être utilisé dans les chemins d'accès. Par exemple, /var/log/*.log (Linux) ou C:\logs\*.log (Windows).

    Pour obtenir une liste des fichiers journaux d'application Linux courants, consultez la page Fichiers journaux Linux courants.

  • exclude_paths : facultatif. Liste des formats de chemin d'accès au système de fichiers à exclure de l'ensemble correspondant à include_paths.

  • record_log_file_path : facultatif. Si cette valeur est définie sur true, le chemin d'accès au fichier spécifique à partir duquel l'enregistrement de journal a été obtenu apparaît dans l'entrée de journal de sortie en tant que valeur du libellé agent.googleapis.com/log_file_path. Lorsque vous utilisez un caractère générique, seul le chemin du fichier à partir duquel l'enregistrement a été obtenu est enregistré.

  • wildcard_refresh_interval : facultatif. Intervalle d'actualisation pour les chemins d'accès de fichiers utilisant des caractères génériques dans include_paths. Renseigné sous la forme d'une durée, par exemple, 30s, 2m. Cette propriété peut s'avérer utile lorsque le débit de journalisation est élevé et que les fichiers journaux sont alternés plus rapidement que l'intervalle par défaut. Si cette option n'est pas spécifiée, l'intervalle par défaut est de 60 secondes.

• Récepteurs fluent_forward :

  • listen_host : facultatif. Adresse IP à écouter. La valeur par défaut est 127.0.0.1.

  • listen_port : facultatif. Un port pour écouter. La valeur par défaut est 24224.

• Récepteurs syslog (pour Linux seulement) :

  • transport_protocol : valeurs acceptées : tcp, udp.

  • listen_host : adresse IP à écouter.

  • listen_port : port à écouter.

• Récepteurs tcp :

  • format : valeur obligatoire. Format du journal. Valeur acceptée : json.

  • listen_host : facultatif. Adresse IP à écouter. La valeur par défaut est 127.0.0.1.

  • listen_port : facultatif. Un port pour écouter. La valeur par défaut est 5170.

• Récepteurs windows_event_log (pour Windows uniquement) :

  • channels : valeur obligatoire. Liste des canaux du journal des événements Windows à partir desquels lire les journaux.

  • receiver_version : facultatif. Contrôle l'API Event Log Windows à utiliser. Les valeurs acceptées sont 1 et 2. La valeur par défaut est 1.

  • render_as_xml : facultatif. S'il est défini sur true, tous les champs du journal des événements, à l'exception de jsonPayload.Message et jsonPayload.StringInserts, sont affichés sous forme de document XML dans un champ de chaîne nommé jsonPayload.raw_xml. La valeur par défaut est false. Ce paramètre ne peut pas être défini sur true lorsque la valeur de receiver_version est 1.

Exemples de récepteurs de journalisation

Exemple de récepteur files :

receivers:
  RECEIVER_ID:
    type: files

    include_paths: [/var/log/*.log]
    exclude_paths: [/var/log/not-this-one.log]
    record_log_file_path: true

Exemple de récepteur fluent_forward :

receivers:
  RECEIVER_ID:
    type: fluent_forward

    listen_host: 127.0.0.1
    listen_port: 24224

Exemple de récepteur syslog (Linux seulement) :

receivers:
  RECEIVER_ID:
    type: syslog

    transport_protocol: tcp
    listen_host: 0.0.0.0
    listen_port: 5140

Exemple de récepteur tcp :

receivers:
  RECEIVER_ID:
    type: tcp

    format: json
    listen_host: 127.0.0.1
    listen_port: 5170

Exemple de récepteur windows_event_log (Windows uniquement) :

receivers:
  RECEIVER_ID:
    type: windows_event_log

    channels: [System,Application,Security]

Exemple de récepteur windows_event_log qui remplace le récepteur intégré afin d'utiliser la version 2 :

receivers:
  windows_event_log:
    type: windows_event_log

    channels: [System,Application,Security]
    receiver_version: 2

Exemple de récepteur systemd_journald :

receivers:
  RECEIVER_ID:
    type: systemd_journald

Champs spéciaux dans les charges utiles structurées

Pour les processeurs et les récepteurs pouvant ingérer des données structurées (les récepteurs fluent_forward et tcp et le processeur parse_json), vous pouvez définir des champs spéciaux dans l'entrée, qui seront mappés à des champs spécifiques dans l'objet LogEntry que l'agent écrit dans l'API Logging.

Lorsque l'agent Ops reçoit des données de journaux structurés externes, il place les champs de premier niveau dans le champ jsonPayload de LogEntry, sauf si le nom du champ est répertorié dans le tableau suivant :

"timestamp": {
  "seconds": CURRENT_SECONDS,
  "nanos": CURRENT_NANOS,
}

{
  "timestampSeconds": CURRENT_SECONDS,
  "timestampNanos": CURRENT_NANOS,
}