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 la section Collecte des journaux d'auto-enregistrement.

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 des 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,
}

Tout champ d'enregistrement structuré restant fait partie de la structure jsonPayload.

Fichiers journaux Linux courants

Le tableau suivant répertorie les fichiers journaux courants des applications Linux fréquemment utilisées :

Libellés ingérés par défaut

Les journaux peuvent contenir les libellés suivants par défaut dans le LogEntry :

Processeurs de journalisation

L'élément processors facultatif contient un ensemble d'instructions de traitement, chacune identifiée par un PROCESSOR_ID. Un processeur explique comment manipuler les informations collectées par un récepteur.

Chaque processeur doit avoir un identifiant unique et inclure un élément type. Les types valides sont les suivants :

• parse_json : analyse des journaux structurés au format JSON.
• parse_multiline : analyse des journaux multilignes. (Linux uniquement)
• parse_regex : analyse des journaux au format texte à l'aide de modèles d'expression régulière pour les convertir en journaux structurés au format JSON.
• exclude_logs : exclusion des journaux correspondant aux règles spécifiées (à partir de la version 2.9.0).
• modify_fields : définition/transformation de champs dans les entrées de journal (à partir de la version 2.14.0).

La structure processors se présente comme suit :

processors:
  PROCESSOR_ID:
    type: parse_json
    ...
  PROCESSOR_ID_2:
    type: parse_regex
    ...

En fonction de la valeur de l'élément type, d'autres options de configuration sont disponibles, comme suit.

Processeur parse_json

Structure de la configuration

processors:
  PROCESSOR_ID:
    type: parse_json

    time_key:    <field name within jsonPayload>
    time_format: <strptime format string>

Le processeur parse_json analyse l'entrée JSON dans le champ jsonPayload de LogEntry. Vous pouvez analyser d'autres parties du fichier LogEntry en définissant certains champs de premier niveau spéciaux.

• time_key : facultatif. Si l'entrée de journal fournit un champ avec un horodatage, cette option spécifie le nom de ce champ. La valeur extraite est utilisée pour définir le champ timestamp du LogEntry résultant et est supprimée de la charge utile.

  Si l'option time_key est spécifiée, vous devez également spécifier les éléments suivants :

  • time_format : obligatoire si time_key est utilisé. Cette option spécifie le format du champ time_key afin qu'il puisse être reconnu et analysé correctement. Pour plus d'informations sur le format, consultez le guide strptime(3).

Exemple de configuration

processors:
  PROCESSOR_ID:
    type: parse_json

    time_key:    time
    time_format: "%Y-%m-%dT%H:%M:%S.%L%Z"

Processeur parse_multiline

Structure de la configuration

processors:
  PROCESSOR_ID:
    type: parse_multiline

    match_any:
    - type: <type of the exceptions>
      language: <language name>

• match_any : valeur obligatoire. Liste contenant une ou plusieurs règles.

  • type : valeur obligatoire. Une seule valeur est acceptée :

    • language_exceptions : permet au processeur de concaténer les exceptions dans une LogEntry, en fonction de la valeur de l'option language.

  • language : valeur obligatoire. Une seule valeur est acceptée :

    • java : concatène les exceptions Java courantes dans une LogEntry.
    • python : concatène les exceptions Python courantes dans une LogEntry.
    • go : concatène les exceptions Go courantes dans une LogEntry.

Exemple de configuration

logging:
  receivers:
    custom_file1:
      type: files
      include_paths:
      - /tmp/test-multiline28
  processors:
    parse_java_multiline:
      type: parse_multiline
      match_any:
      - type: language_exceptions
        language: java
    extract_structure:
      type: parse_regex
      field: message
      regex: "^(?<time>[\d-]*T[\d:.Z]*) (?<severity>[^ ]*) (?<file>[^ :]*):(?<line>[\d]*) - (?<message>(.|\\n)*)$"
      time_key: time
      time_format: "%Y-%m-%dT%H:%M:%S.%L"
    move_severity:
      type: modify_fields
      fields:
        severity:
          move_from: jsonPayload.severity
  service:
    pipelines:
      pipeline1:
        receivers: [custom_file1]
        processors: [parse_java_multiline, extract_structure, move_severity]

Si vous utilisez la configuration précédente et que vous disposez d'un fichier journal avec le contenu suivant :

2022-10-17T22:00:00.187512963Z ERROR HelloWorld:16 - javax.servlet.ServletException: Something bad happened
    at com.example.myproject.OpenSessionInViewFilter.doFilter(OpenSessionInViewFilter.java:60)
    at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
    at com.example.myproject.ExceptionHandlerFilter.doFilter(ExceptionHandlerFilter.java:28)
    at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
    at com.example.myproject.OutputBufferFilter.doFilter(OutputBufferFilter.java:33)
Caused by: com.example.myproject.MyProjectServletException
    at com.example.myproject.MyServlet.doPost(MyServlet.java:169)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
    at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
    at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1166)
    at com.example.myproject.OpenSessionInViewFilter.doFilter(OpenSessionInViewFilter.java:30)
    ... 27 common frames omitted

Ensuite, l'agent ingère les journaux dans Cloud Logging au format suivant :

{
  "insertId": "...",
  "jsonPayload": {
    "line": "16",
    "message": "javax.servlet.ServletException: Something bad happened\n    at com.example.myproject.OpenSessionInViewFilter.doFilter(OpenSessionInViewFilter.java:60)\n    at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)\n    at com.example.myproject.ExceptionHandlerFilter.doFilter(ExceptionHandlerFilter.java:28)\n    at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)\n    at com.example.myproject.OutputBufferFilter.doFilter(OutputBufferFilter.java:33)\nCaused by: com.example.myproject.MyProjectServletException\n    at com.example.myproject.MyServlet.doPost(MyServlet.java:169)\n    at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)\n    at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)\n    at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)\n    at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1166)\n    at com.example.myproject.OpenSessionInViewFilter.doFilter(OpenSessionInViewFilter.java:30)\n    ... 27 common frames omitted\n",
    "file": "HelloWorld"
  },
  "resource": {
    "type": "gce_instance",
    "labels": {
      "instance_id": "...",
      "project_id": "...",
      "zone": "..."
    }
  },
  "timestamp": "2022-10-17T22:00:00.187512963Z",
  "severity": "ERROR",
  "labels": {
    "compute.googleapis.com/resource_name": "..."
  },
  "logName": "projects/.../logs/custom_file",
  "receiveTimestamp": "2022-10-18T03:12:38.430364391Z"
}

Processeur parse_regex

Structure de la configuration

processors:
  PROCESSOR_ID:
    type: parse_regex

    regex: <regular expression>

    time_key:    <field name within jsonPayload>
    time_format: <format string>

• time_key : facultatif. Si l'entrée de journal fournit un champ avec un horodatage, cette option spécifie le nom de ce champ. La valeur extraite est utilisée pour définir le champ timestamp du LogEntry résultant et est supprimée de la charge utile.

  Si l'option time_key est spécifiée, vous devez également spécifier les éléments suivants :

  • time_format : obligatoire si time_key est utilisé. Cette option spécifie le format du champ time_key afin qu'il puisse être reconnu et analysé correctement. Pour plus d'informations sur le format, consultez le guide strptime(3).

• regex : valeur obligatoire. L'expression régulière utilisée pour analyser le champ. L'expression doit inclure des noms de clés pour les sous-expressions correspondantes, par exemple, "^(?<time>[^ ]*) (?<severity>[^ ]*) (?<msg>.*)$".

  Le texte correspondant aux groupes de capture nommés est placé dans des champs dans le champ jsonPayload de LogEntry. Pour ajouter une structure à vos journaux, utilisez le processeur modify_fields.

  Pour obtenir un ensemble d'expressions régulières permettant d'extraire des informations des fichiers journaux d'application Linux courants, consultez la section Fichiers journaux Linux courants.

Exemple de configuration

processors:
  PROCESSOR_ID:
    type: parse_regex

    regex:       "^(?<time>[^ ]*) (?<severity>[^ ]*) (?<msg>.*)$"
    time_key:    time
    time_format: "%Y-%m-%dT%H:%M:%S.%L%Z"

Processeur exclude_logs

Structure de la configuration :

type: exclude_logs
match_any:
  - <filter>
  - <filter>

La configuration de premier niveau pour ce processeur contient un seul champ, match_any, qui contient une liste de règles de filtre.

• match_any : valeur obligatoire. Liste contenant une ou plusieurs règles. Si une entrée de journal correspond à une règle, l'agent Ops n'ingère pas cette entrée.

  Les journaux ingérés par l'agent Ops suivent la structure LogEntry. Les noms de champs sont sensibles à la casse. Vous ne pouvez spécifier des règles qu'en fonction des champs suivants et de leurs sous-champs :

  • httpRequest
  • jsonPayload
  • labels
  • operation
  • severity
  • sourceLocation
  • trace
  • spanId

  L'exemple de règle suivant

  severity =~ "(DEBUG|INFO)"
  

  utilise une expression régulière pour exclure tous les journaux de niveau DEBUG et INFO.

  Les règles suivent la syntaxe du langage de requête Cloud Logging, mais n'acceptent qu'un sous-ensemble des fonctionnalités compatibles avec le langage de requête Logging :

  • Opérateurs de comparaison : =, !=, :, =~, !~. Seules les comparaisons de chaînes sont acceptées.
  • Opérateur de navigation : .. Par exemple, jsonPayload.message.
  • Opérateurs booléens : AND, OR, NOT.
  • Expressions de regroupement avec ( )

Exemple de configuration

processors:
  PROCESSOR_ID:
    type: exclude_logs
    match_any:
    - '(jsonPayload.message =~ "log spam 1" OR jsonPayload.message =~ "log spam 2") AND severity = "ERROR"'
    - 'jsonPayload.application = "foo" AND severity = "INFO"'

Processeur modify_fields

Le processeur modify_fields permet de personnaliser la structure et le contenu des entrées de journal.

Structure de la configuration

type: modify_fields
fields:
  <destination field>:
    # Source
    move_from: <source field>
    copy_from: <source field>
    static_value: <string>
    
    # Mutation
    default_value: <string>
    map_values:
      <old value>: <new value>
    type: {integer|float}
    omit_if: <filter>

La configuration de premier niveau de ce processeur contient un seul champ, fields, qui contient un mappage des noms de champs de sortie et des traductions correspondantes. Pour chaque champ de sortie, une source facultative et zéro ou plusieurs opérations de mutation sont appliquées.

Tous les noms de champs utilisent la syntaxe séparée par des points du langage de requête Cloud Logging. Les filtres utilisent le langage de requête Cloud Logging.

Toutes les transformations sont appliquées en parallèle, ce qui signifie que les sources et les filtres fonctionnent sur l'entrée de journal d'origine et ne peuvent donc pas référencer la nouvelle valeur d'autres champs modifiés par le même processeur.

Options de source : une source spécifiée au maximum est autorisée.

• Aucune source spécifiée

  Si aucune valeur source n'est spécifiée, la valeur existante du champ de destination est modifiée.

• move_from: <source field>

  La valeur de <source field> sera utilisée comme source pour le champ de destination. De plus, <source field> sera supprimé de l'entrée de journal. Si un champ source est référencé par move_from et copy_from, le champ source sera toujours supprimé.

• copy_from: <source field>

  La valeur de <source field> sera utilisée comme source pour le champ de destination. <source field> ne sera pas supprimé de l'entrée de journal, sauf s'il est référencé par une opération move_from ou modifié.

• static_value: <string>

  La chaîne statique <string> sera utilisée comme source pour le champ de destination.

Options de mutation : zéro ou plusieurs opérateurs de mutation peuvent être appliqués à un seul champ. Si plusieurs opérateurs sont fournis, ils seront toujours appliqués dans l'ordre suivant.

1. default_value: <string>

   Si le champ source n'existait pas, la valeur de sortie sera définie sur <string>. Si le champ source existe déjà (même s'il contient une chaîne vide), la valeur d'origine n'est pas modifiée.

2. map_values: <map>

   Si la valeur d'entrée correspond à l'une des clés de <map>, la valeur de sortie sera remplacée par la valeur correspondante du mappage.

3. map_values_exclusive: {true|false}

   Dans le cas où <source field> ne correspond à aucune clé spécifiée dans les paires map_values, la définition du champ de destination sera forcée simap_values_exclusive est défini sur "true", ou reste intacte si map_values_exclusive est défini sur "false".

4. type: {integer|float}

   La valeur d'entrée sera convertie en entier ou en valeur à virgule flottante. Si la chaîne ne peut pas être convertie en nombre, la valeur de sortie n'est pas définie. Si la chaîne contient une valeur flottante, mais que le type est spécifié en tant que integer, le nombre est tronqué à un entier.

   Notez que l'API Cloud Logging utilise JSON et n'est donc pas compatible avec un entier de 64 bits. Si un entier de 64 bits (ou plus) est nécessaire, il doit être stocké sous forme de chaîne dans l'entrée de journal.

5. omit_if: <filter>

   Si le filtre correspond à l'enregistrement du journal d'entrée, le champ de sortie n'est pas défini. Il permet de supprimer des valeurs d'espaces réservés, par exemple :

   httpRequest.referer:
     move_from: jsonPayload.referer
     omit_if: httpRequest.referer = "-"
   

Exemples de configurations

Le processeur parse_json transforme un fichier JSON contenant

{
  "http_status": "400",
  "path": "/index.html",
  "referer": "-"
}

dans une structure LogEntry semblable à celle-ci :

{
  "jsonPayload": {
    "http_status": "400",
    "path": "/index.html",
    "referer": "-"
  }
}

Celle-ci peut ensuite être transformée avec modify_fields dans cette LogEntry :

{
  "httpRequest": {
    "status": 400,
    "requestUrl": "/index.html",
  }
}

à l'aide de la configuration de l'agent Ops suivante:

logging:
  receivers:
    in:
      type: files
      include_paths:
      - /var/log/http.json
  processors:
    parse_json:
      type: parse_json
    set_http_request:
      type: modify_fields
      fields:
        httpRequest.status:
          move_from: jsonPayload.http_status
          type: integer
        httpRequest.requestUrl:
          move_from: jsonPayload.path
        httpRequest.referer:
          move_from: jsonPayload.referer
          omit_if: jsonPayload.referer = "-"
  service:
    pipelines:
      pipeline:
        receivers: [in]
        processors: [parse_json, set_http_request]

Cette configuration lit les journaux au format JSON à partir de /var/log/http.json et renseigne une partie de la structure httpRequest à partir des champs des journaux.

Service de journalisation

Le service de journalisation personnalise la verbosité pour les propres journaux de l'agent Ops et associe les récepteurs et les processeurs de journalisation aux pipelines. La section service comporte les éléments suivants :

• log_level
• pipelines

Niveau de verbosité du journal

Le champ log_level, disponible avec les versions 2.6.0 et ultérieures de l'agent Ops, personnalise la verbosité des journaux propres au sous-module de journalisation de l'agent Ops. La valeur par défaut est info. Les options disponibles sont : error, warn, info, debug, trace.

La configuration suivante personnalise la verbosité du journal pour le sous-module de journalisation en debug à la place :

logging:
  service:
    log_level: debug

Pipelines de journalisation

Le champ pipelines peut contenir plusieurs ID et définitions de pipeline. Chaque valeur pipeline comprend les éléments suivants :

• receivers : obligatoire pour les nouveaux pipelines. Liste des ID de récepteur, comme décrit dans la section Récepteurs de journalisation. L'ordre des ID de récepteurs dans la liste n'a pas d'importance. Le pipeline collecte des données à partir de tous les récepteurs répertoriés.

• processors : facultatif. Liste des ID de processeur, comme décrit dans la section Processeurs de journalisation. L'ordre des ID de processeur dans la liste est important. Chaque enregistrement est traité par les processeurs dans l'ordre indiqué.

Exemples de configurations service de journalisation

Une configuration service présente la structure suivante :

service:
  log_level: CUSTOM_LOG_LEVEL
  pipelines:
    PIPELINE_ID:
      receivers:  [...]
      processors: [...]
    PIPELINE_ID_2:
      receivers:  [...]
      processors: [...]

Pour empêcher l'agent de collecter et d'envoyer des entrées /var/log/message ou /var/log/syslog, redéfinissez le pipeline par défaut avec une liste receivers vide et sans processeur. Cette configuration n'arrête pas le sous-composant de journalisation de l'agent, car celui-ci doit pouvoir collecter les journaux du sous-composant de surveillance. L'ensemble de la configuration de journalisation vide se présente comme suit :

logging:
  service:
    pipelines:
      default_pipeline:
        receivers: []

La configuration service suivante définit un pipeline avec l'identifiant custom_pipeline :

logging:
  service:
    pipelines:
      custom_pipeline:
        receivers:
        - RECEIVER_ID
        processors:
        - PROCESSOR_ID

Configuration des métriques

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

• receivers : liste de définitions des récepteurs. receiver décrit la source des métriques (par exemple, des métriques système telles que cpu ou memory). Les récepteurs de cette liste peuvent être partagés sur plusieurs pipelines.
• processors : liste de définitions des processeurs. Un processor décrit comment modifier les métriques collectées par un récepteur.
• service : contient une section pipelines qui est une liste de définitions des pipeline. Un pipeline connecte une liste de receivers et une liste de processors pour former le flux de données.

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

L'Agent Ops envoie des métriques à Cloud Monitoring. Vous ne pouvez pas le configurer pour exporter des métriques vers d'autres services.

Destinataires des métriques

L'élément receivers contient un ensemble de définitions de récepteur. Un récepteur désigne où extraire les métriques, par exemple cpu et memory. Un récepteur peut être partagé entre plusieurs pipelines.

Structure des récepteurs de métriques

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

• hostmetrics
• iis (Windows uniquement)
• mssql (Windows uniquement)

Un récepteur peut également spécifier l'option collection_interval de l'opération. Le format de cette valeur est une durée, par exemple 30s ou 2m. La valeur par défaut est 60s.

Chacun de ces types de récepteurs collecte un ensemble de métriques. Pour en savoir plus sur les métriques spécifiques incluses, consultez la section Métriques ingérées par les récepteurs.

Vous ne pouvez créer qu'un seul récepteur pour chaque type. Par exemple, vous ne pouvez pas définir deux récepteurs de type hostmetrics.

Modifier l'intervalle de collecte dans les récepteurs de métriques

Certaines charges de travail critiques peuvent nécessiter des alertes rapides. En réduisant l'intervalle de collecte des métriques, vous pouvez configurer des alertes plus sensibles. Pour en savoir plus sur l'évaluation des alertes, consultez la page Comportement des règles d'alerte basées sur les métriques.

Par exemple, le récepteur suivant modifie l'intervalle de collecte des métriques d'hôte (l'identifiant de récepteur est hostmetrics) en remplaçant la valeur par défaut de 60 secondes par 10 secondes :

metrics:
  receivers:
    hostmetrics:
      type: hostmetrics
      collection_interval: 10s

Vous pouvez également remplacer l'intervalle de collecte des récepteurs de métriques Windows iis et mssql à l'aide de la même technique.

Métriques ingérées par les récepteurs

Les métriques ingérées par l'agent Ops comportent des identifiants commençant par le format suivant : agent.googleapis.com/GROUP. Le composant GROUP identifie un ensemble de métriques associées. Celui-ci comporte des valeurs telles que cpu, network, etc.

Récepteur hostmetrics

Le récepteur hostmetrics ingère les groupes de métriques suivants. Pour en savoir plus, consultez la section liée à chaque groupe sur la page Métriques de l'agent Ops.

Récepteur iis (Windows uniquement)

Le récepteur iis (Windows uniquement) ingère des métriques du groupe iis. Pour en savoir plus, consultez la page Métriques d'agent.

Récepteur mssql (Windows uniquement)

Le récepteur mssql (Windows uniquement) ingère des métriques du groupe mssql. Pour en savoir plus, consultez la page Métriques de l'agent Ops.

Processeurs de métriques

L'élément processor contient un ensemble de définitions de processeur. Un processeur décrit les métriques du type de récepteur à exclure. Le seul type compatible est exclude_metrics, qui prend l'option metrics_pattern. La valeur est une liste de globs correspondant aux types de métriques de l'agent Ops que vous souhaitez exclure du groupe collecté par un récepteur. Exemple :

• Pour exclure toutes les métriques de processeur de l'agent, spécifiez agent.googleapis.com/cpu/*.
• Pour exclure la métrique d'utilisation du processeur de l'agent, spécifiez agent.googleapis.com/cpu/utilization.
• Pour exclure la métrique du nombre de requêtes côté client des métriques collectées par l'intégration tierce Apache Cassandra, spécifiez workloads.googleapis.com/cassandra.client.request.count.
• Pour exclure toutes les métriques côté client des métriques collectées par l'intégration tierce Apache Cassandra, spécifiez workloads.googleapis.com/cassandra.client.*.

Exemple de processeur de métriques

L'exemple suivant présente le processeur exclude_metrics fourni dans les configurations intégrées. Ce processeur fournit une valeur metrics_pattern vide. Il n'exclut donc aucune métrique.

processors:
  metrics_filter:
    type: exclude_metrics
    metrics_pattern: []

Pour désactiver la collecte de toutes les métriques de processus par l'agent Ops, ajoutez les éléments suivants à votre fichier config.yaml :

metrics:
  processors:
    metrics_filter:
      type: exclude_metrics
      metrics_pattern:
      - agent.googleapis.com/processes/*

Cela exclut les métriques de processus de la collecte dans le processeur metrics_filter qui s'applique au pipeline par défaut du service metrics.

Service des métriques

Le service de métriques personnalise la verbosité pour les propres journaux du module de métriques de l'agent Ops et associe les destinataires et les processeurs de métriques aux pipelines. La section service comporte deux éléments : log_level et pipelines.

Niveau de verbosité des métriques

log_level, disponible avec les versions 2.6.0 et ultérieures de l'agent Ops, personnalise la verbosité des journaux propres au sous-module de métriques de l'agent Ops. La valeur par défaut est info. Les options disponibles sont : error, warn, info, debug.

Pipelines de métriques

La section service comporte un seul élément, pipelines, qui peut contenir plusieurs ID et définitions de pipeline. Chaque définition pipeline comprend les éléments suivants :

• receivers : obligatoire pour les nouveaux pipelines. Liste des ID de récepteur, comme décrit dans la section Récepteurs de métriques. L'ordre des ID de récepteurs dans la liste n'a pas d'importance. Le pipeline collecte des données à partir de tous les récepteurs répertoriés.

• processors : facultatif. Liste des ID de processeur, comme décrit dans la section Processeurs de métriques. L'ordre des ID de processeur dans la liste est important. Chaque point de métrique est traité par les processeurs dans l'ordre indiqué.

Exemples de configurations service de métriques

Une configuration service présente la structure suivante :

service:
  log_level: CUSTOM_LOG_LEVEL
  pipelines:
    PIPELINE_ID:
      receivers:  [...]
      processors: [...]
    PIPELINE_ID_2:
      receivers:  [...]
      processors: [...]

Pour désactiver l'ingestion intégrée des métriques d'hôte, redéfinissez le pipeline par défaut avec une liste receivers vide et sans processeur. L'ensemble de la configuration de métriques se présente comme suit :

metrics:
  service:
    pipelines:
      default_pipeline:
        receivers: []

L'exemple suivant montre la configuration intégrée service pour Windows :

metrics:
  service:
    pipelines:
      default_pipeline:
        receivers:
        - hostmetrics
        - iis
        - mssql
        processors:
        - metrics_filter

La configuration service suivante personnalise la verbosité du journal pour le sous-module des métriques sur debug à la place :

metrics:
  service:
    log_level: debug

Collecte de journaux automatiques

Par défaut, les journaux automatiques Fluent Bit de l'agent Ops sont envoyés à Cloud Logging. Ces journaux peuvent contenir de nombreuses informations, et le volume supplémentaire peut augmenter vos coûts d'utilisation de Cloud Logging.

Vous pouvez désactiver la collecte de ces journaux automatiques, à partir de la version 2.44.0 de l'agent Ops, à l'aide de l'option default_self_log_file_collection.

Pour désactiver la collecte des journaux automatiques, ajoutez une section global au fichier de configuration spécifié par l'utilisateur et définissez l'option default_self_log_file_collection sur la valeur false:

logging:  ...
metrics:  ...
global:
  default_self_log_file_collection: false

Configuration de la rotation des journaux

À partir de la version 2.31.0 de l'agent Ops, vous pouvez également configurer la fonctionnalité de rotation des journaux de l'agent à l'aide des fichiers de configuration. Pour en savoir plus, consultez la section Configurer la rotation des journaux dans l'agent Ops.