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 :

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

L'agent Ops fournit également des instructions de configuration pour la collecte de métriques et de journaux à partir d'applications tierces compatibles. Pour obtenir la liste des applications compatibles, consultez la section Surveiller des applications tierces.

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 :

Linux

Par défaut, l'agent Ops collecte les journaux syslog et les métriques d'hôte basés sur des fichiers.

Pour plus d'informations sur les métriques collectées, consultez la section Métriques ingérées par les types de récepteurs.

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]

Windows

Par défaut, l'agent Ops collecte les journaux d'événements Windows à partir des canaux System, Application et Security, ainsi que des métriques d'hôte, des métriques IIS et des métriques SQL Server.

Pour plus d'informations sur les métriques collectées, consultez la section Métriques ingérées par les types de récepteurs.

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.

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.

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.

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.
  • syslog : collecter syslog via TCP ou UDP.
  • tcp (disponible avec les versions 2.3.0 et ultérieures de l'agent Ops) : collecter les journaux au format JSON en écoutant un port TCP.
  • windows_event_log (Windows uniquement) : collecter les journaux d'événements Windows.
  • systemd_journald (disponible avec les versions 2.4.0 et ultérieures de l'agent Ops sous Linux): collecter des journaux à partir du service systemd-journald.

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. Exemple : /var/log/*.log.

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

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

    • 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 syslog :

    • transport_protocol : facultatif. Valeurs autorisées : tcp, udp. La valeur par défaut est tcp.

      Vous pouvez utiliser les options supplémentaires suivantes:

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

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

  • 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.

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]

Exemple de récepteur syslog :

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 systemd_journald :

receivers:
  RECEIVER_ID:
    type: systemd_journald

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.

Structure des processeurs de journalisation

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

  • parse_json
  • parse_regex

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 :

  • Processeurs parse_json et parse_regex :

    • field : facultatif. Nom du champ dans l'enregistrement à analyser. Si l'option field n'est pas spécifiée, le processeur analyse le champ message.

    • 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).
  • Processeurs parse_regex :

    • 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>.*)$".

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

Exemples de processeurs de journalisation

Exemple de processeur parse_json :

processors:
  PROCESSOR_ID:
    type: parse_json

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

Exemple de processeur parse_regex :

processors:
  PROCESSOR_ID:
    type: parse_regex

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

Champs spéciaux dans les charges utiles structurées

Vous pouvez définir des champs spécifiques dans l'objet LogEntry que l'agent écrit dans l'API Logging. Pour les enregistrements de journaux structurés, l'agent Ops supprime les champs répertoriés dans le tableau suivant de la structure jsonPayload :

Champ d'enregistrement Champ de LogEntry

Option 1



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

Option 2



{
  "timestampSeconds": CURRENT_SECONDS,
  "timestampNanos": CURRENT_NANOS,
}
timestamp
recipient_id (pas un champ d'enregistrement) logName
logging.googleapis.com/severity severity
logging.googleapis.com/labels labels
logging.googleapis.com/operation operation
logging.googleapis.com/sourceLocation sourceLocation

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

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 deux éléments : log_level et pipelines.

Niveau de verbosité du journal

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.

Pipelines de journalisation

pipelines 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 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 désactiver l'ingestion de journalisation intégrée, redéfinissez le pipeline par défaut avec une liste receivers vide et sans processeurs. L'ensemble de la configuration de journalisation 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

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

logging:
  service:
    log_level: debug

Fichiers journaux courants

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

Application Fichiers journaux courants
apache Pour plus d'informations sur les fichiers journaux Apache, consultez la section Surveiller des applications tierces : Apache Web Server.
cassandra Pour plus d'informations sur les fichiers journaux Cassandra, consultez la section Surveiller des applications tierces : Cassandra.
chef /var/log/chef-server/bookshelf/current
/var/log/chef-server/chef-expander/current
/var/log/chef-server/chef-pedant/http-traffic.log
/var/log/chef-server/chef-server-webui/current
/var/log/chef-server/chef-solr/current
/var/log/chef-server/erchef/current
/var/log/chef-server/erchef/erchef.log.1
/var/log/chef-server/nginx/access.log
/var/log/chef-server/nginx/error.log
/var/log/chef-server/nginx/rewrite-port-80.log
/var/log/chef-server/postgresql/current
gitlab /home/git/gitlab/log/application.log
/home/git/gitlab/log/githost.log
/home/git/gitlab/log/production.log
/home/git/gitlab/log/satellites.log
/home/git/gitlab/log/sidekiq.log
/home/git/gitlab/log/unicorn.stderr.log
/home/git/gitlab/log/unicorn.stdout.log
/home/git/gitlab-shell/gitlab-shell.log
jenkins /var/log/jenkins/jenkins.log
jetty /var/log/jetty/out.log
/var/log/jetty/*.request.log
/var/log/jetty/*.stderrout.log
joomla /var/www/joomla/logs/*.log
magento /var/www/magento/var/log/exception.log
/var/www/magento/var/log/system.log
/var/www/magento/var/report/*
mediawiki /var/log/mediawiki/*.log
memcached /var/log/memcached.log
mongodb /var/log/mongodb/*.log
mysql Pour plus d'informations sur les fichiers journaux MySQL, consultez la section Surveiller des applications tierces : MySQL.
nginx Pour plus d'informations sur les fichiers journaux nginx, consultez la section Surveiller des applications tierces : nginx.
postgres /var/log/postgres*/*.log
/var/log/pgsql/*.log
puppet /var/log/puppet/http.log
/var/log/puppet/masterhttp.log
puppet-enterprise /var/log/pe-activemq/activemq.log
/var/log/pe-activemq/wrapper.log
/var/log/pe-console-auth/auth.log
/var/log/pe-console-auth/cas_client.log
/var/log/pe-console-auth/cas.log
/var/log/pe-httpd/access.log
/var/log/pe-httpd/error.log
/var/log/pe-httpd/other_vhosts_access.log
/var/log/pe-httpd/puppetdashboard.access.log
/var/log/pe-httpd/puppetdashboard.error.log
/var/log/pe-httpd/puppetmasteraccess.log
/var/log/pe-mcollective/mcollective_audit.log
/var/log/pe-mcollective/mcollective.log
/var/log/pe-puppet-dashboard/certificate_manager.log
/var/log/pe-puppet-dashboard/event-inspector.log
/var/log/pe-puppet-dashboard/failed_reports.log
/var/log/pe-puppet-dashboard/live-management.log
/var/log/pe-puppet-dashboard/mcollective_client.log
/var/log/pe-puppet-dashboard/production.log
/var/log/pe-puppetdb/pe-puppetdb.log
/var/log/pe-puppet/masterhttp.log
/var/log/pe-puppet/rails.log
rabbitmq /var/log/rabbitmq/*.log
/var/log/rabbitmq/*-sasl.log
/var/log/rabbitmq/startup_err
/var/log/rabbitmq/startup_log
redis Pour plus d'informations sur les fichiers journaux Redis, consultez la section Surveiller des applications tierces : Redis.
redmine /var/log/redmine/*.log
salt /var/log/salt/key
/var/log/salt/master
/var/log/salt/minion
/var/log/salt/syndic.loc
solr /var/log/solr/*.log
sugarcrm /var/www/*/sugarcrm.log
syslog /var/log/syslog/var/log/messages
tomcat /var/log/tomcat*/catalina.out
/var/log/tomcat*/localhost.*.log
/var/log/tomcat*/localhost_access_log.%Y-%m-%d.txt
zookeeper /var/log/zookeeper/zookeeper.log
/var/log/zookeeper/zookeeper_trace.log

Le tableau suivant répertorie certaines expressions régulières utiles pour l'analyse des journaux :

Application Expression régulière
mongodb ^(?<time>[^ ]*)\s+(?<severity>\w)\s+(?<component>[^ ]+)\s+\[(?<context>[^\]]+)]\s+(?<message>.*?) *(?<ms>(\d+))?(:?ms)?$

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.

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 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 types de récepteur.

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.

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.

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.

Groupe Métrique
cpu Charge du processeur à intervalles d'une minute
Charge du processeur à intervalles de cinq minutes
Charge du processeur à intervalles de 15 minutes
Utilisation du processeur, avec des libellés pour le numéro et l'état du processeur
Pourcentage d'utilisation du processeur, avec des libellés pour le numéro et l'état du processeur
disk Octets lus sur le disque, avec libellé pour l'appareil
Octets écrits sur le disque, avec libellé pour l'appareil
Heure d'E/S du disque, avec libellé pour l'appareil
Durée pondérée d'E/S du disque, avec libellé pour l'appareil
Opérations en attente sur le disque, avec libellé pour l'appareil
Opérations fusionnées sur le disque, avec libellés pour l'appareil et la direction
Opérations sur le disque, avec libellés pour l'appareil et la direction
Durée des opérations sur le disque, avec libellés pour l'appareil et l'état
Usage du disque, avec libellés pour l'appareil et l'état
Utilisation du disque, avec libellés pour l'appareil et l'état
interface
Linux uniquement
Nombre total d'erreurs réseau
Nombre total de paquets envoyés sur le réseau
Nombre total d'octets envoyés sur le réseau
memory Utilisation de la mémoire, avec libellé pour l'état (mise en tampon, mise en cache, gratuite, dalle, utilisée)
Pourcentage d'utilisation de la mémoire, avec libellé pour l'état (mise en tampon, mise en cache, gratuite, dalle, utilisée)
network Nombre de connexions TCP, avec des libellés pour le port et l'état TCP
swap Opérations de pagination d'E/S, avec un libellé pour la direction
Octets de pagination utilisés, avec des libellés pour l'appareil et l'état
Pourcentage de pagination utilisé, avec des libellés pour l'appareil et l'état
pagefile
Windows uniquement
Pourcentage actuel de fichier d'échange utilisé par état.
processes Nombre de processus, avec libellé pour l'état
Nombre de processus dupliqués
E/S en lecture de disque par processus, avec libellés pour le nom du processus + autres
E/S en écriture de disque par processus, avec libellés pour le nom du processus + autres
Utilisation de RSS par processus, avec libellés pour le nom du processus + autres
Utilisation de VM par processus, avec libellés pour le nom du processus + autres

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

Groupe Métrique
iis
Windows uniquement
Connexions actuellement ouvertes à IIS
Octets de réseau transférés par IIS
Connexions ouvertes vers IIS
Requêtes effectuées vers IIS

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.

Groupe Métrique
mssql
Windows uniquement
Connexions actuellement ouvertes vers serveur SQL
Nombre total de transactions par serveur SQL par seconde
Transactions en écriture vers serveur SQL par seconde

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 fichiers glob correspondant aux types de métrique que vous souhaitez exclure du groupe collecté par un récepteur. Par exemple, agent.googleapis.com/cpu/* ou agent.googleapis.com/processes/*. Pour connaître le nom complet des métriques individuelles, consultez le tableau du groupe sur la page Métriques de l'agent Ops.

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