Configurazione dell'agente operativo

Questo documento fornisce dettagli sulle configurazioni predefinite e personalizzate dell'agente operativo. Leggi questo documento se si applica una delle seguenti condizioni:

  • Vuoi modificare la configurazione dell'agente operativo per raggiungere i seguenti obiettivi:

  • Ti interessa conoscere i dettagli tecnici della configurazione dell'agente operativo.

L'agente operativo fornisce anche istruzioni di configurazione per la raccolta di metriche e log da applicazioni di terze parti supportate. Consulta Monitoraggio delle applicazioni di terze parti per l'elenco delle applicazioni supportate.

Modello di configurazione

L'agente operativo utilizza una configurazione predefinita integrata; non puoi modificarla direttamente. Crea invece un file di override che vengono uniti alla configurazione integrata al riavvio dell'agente.

I componenti di base della configurazione sono i seguenti:

  • receivers: questo elemento descrive ciò che viene raccolto dall'agente.
  • processors: questo elemento descrive in che modo l'agente può modificare le informazioni raccolte.
  • service: questo elemento collega i destinatari e i processori per creare flussi di dati, chiamati pipeline. L'elemento service contiene un elemento pipelines, che può contenere più pipeline.

La configurazione integrata è costituita da questi elementi e utilizzi gli stessi elementi per eseguire l'override della configurazione integrata.

Configurazione integrata

La configurazione integrata per l'agente operativo definisce la raccolta predefinita per i log e le metriche. Di seguito è riportata la configurazione integrata per Linux e per Windows:

Linux

Per impostazione predefinita, l'agente operativo raccoglie i log syslog e le metriche degli host basati su file.

Per ulteriori informazioni sulle metriche raccolte, consulta Metriche importate dai tipi di destinatario.

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

Per impostazione predefinita, l'agente operativo raccoglie i log eventi di Windows da System, Application e i canali Security, nonché le metriche host, le metriche IIS e le metriche di SQL Server.

Per ulteriori informazioni sulle metriche raccolte, consulta Metriche importate dai tipi di destinatario.

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]

Queste configurazioni sono trattate in dettaglio nella sezione Configurazione di Logging e Configurazione delle metriche.

Configurazione specificata dall'utente

Per eseguire l'override della configurazione integrata, aggiungi nuovi elementi di configurazione al file di configurazione dell'utente. Inserisci la configurazione per l'agente operativo nei seguenti file:

  • Per Linux: /etc/google-cloud-ops-agent/config.yaml.

  • Per Windows: C:\Program Files\Google\Cloud Operations\Ops Agent\config\config.yaml.

Qualsiasi configurazione specificata dall'utente viene unita a quella integrata al riavvio dell'agente.

Per eseguire l'override di un ricevitore, un processore o una pipeline integrati, ridefiniscilo nel file config.yaml dichiarandolo con lo stesso identificatore.

Ad esempio, la configurazione integrata per le metriche include un ricevitore hostmetrics che specifica un intervallo di raccolta di 60 secondi. Per modificare l'intervallo di raccolta per le metriche host su 30 secondi, includi un ricevitore di metriche chiamato hostmetrics nel file config.yaml che imposta il valore collection_interval su 30 secondi, come mostrato nell'esempio seguente:

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

Per altri esempi di modifica delle configurazioni integrate, vedi Configurazione dei log e Configurazione delle metriche.

Puoi anche disattivare la raccolta dei dati di log o delle metriche. Queste modifiche sono descritte nell'esempio sulla registrazione delle configurazioni service e nelle configurazioni servicedelle metriche.

Configurazioni di logging

La configurazione di logging utilizza il modello di configurazione descritto in precedenza:

  • receivers: questo elemento descrive i dati da raccogliere dai file di log; questi dati sono mappati in un modello <timestamp, record>
  • processors: questo elemento facoltativo descrive le modalità con cui l'agente può modificare le informazioni raccolte.
  • service: questo elemento collega i destinatari e i processori per creare flussi di dati, chiamati pipeline. L'elemento service contiene un elemento pipelines, che può includere più definizioni di pipeline.

Ogni ricevitore e ogni processore possono essere utilizzati in più pipeline.

Le sezioni seguenti descrivono ciascuno di questi elementi.

Logging dei ricevitori

L'elemento receivers contiene un insieme di destinatari, ciascuno identificato da un RECEIVER_ID. Un ricevitore descrive come recuperare i log, ad esempio, mettendo in coda i file, utilizzando una porta TCP o dal log eventi di Windows.

Struttura dei ricevitori di logging

Ogni destinatario deve avere un identificatore, RECEIVER_ID, e includere un elemento type. I tipi validi sono:

  • files: raccogli i log accodando i file su disco.
  • fluent_forward (disponibile con Ops Agent 2.12.0 e versioni successive): raccogli i log inviati tramite il protocollo Fluent Forward su TCP.
  • syslog: raccogli il log di sistema tramite TCP o UDP.
  • tcp (disponibile con Ops Agent 2.3.0 e versioni successive): raccogli i log in formato JSON ascoltando una porta TCP.
  • windows_event_log (solo Windows): raccogli i log eventi di Windows.
  • systemd_journald (disponibile con Ops Agent 2.4.0 e versioni successive su Linux): raccogli i log dal servizio inserito nel journal del sistema.

La struttura receivers ha il seguente aspetto:

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

A seconda del valore dell'elemento type, potrebbero essere disponibili altre opzioni di configurazione, come indicato di seguito:

  • files destinatari:

    • include_paths: obbligatorio. Un elenco di percorsi del filesystem da leggere mettendo in coda ogni file. Nei percorsi è possibile utilizzare un carattere jolly (*), ad esempio /var/log/*.log (Linux) o C:\logs\*.log (Windows).

      Per un elenco dei file di log comuni delle applicazioni Linux, vedi File di log comuni di Linux.

    • exclude_paths: facoltativo. Un elenco di pattern di filesystem da escludere dal set corrispondente in include_paths.

    • wildcard_refresh_interval: facoltativo. L'intervallo a cui vengono aggiornati i percorsi dei file con caratteri jolly in include_paths. Dato il tempo, ad esempio 30s, 2m. Questa proprietà potrebbe essere utile in presenza di velocità effettiva di logging elevate, in cui i file di log vengono ruotati più rapidamente dell'intervallo predefinito. Se non viene specificato, l'intervallo predefinito è di 60 secondi.

  • fluent_forward destinatari:

    • listen_host: facoltativo. Un indirizzo IP da ascoltare. Il valore predefinito è 127.0.0.1.

    • listen_port: facoltativo. Una porta per ascoltare. Il valore predefinito è 24224.

  • syslog destinatari:

    • transport_protocol: facoltativo. Valori supportati: tcp, udp. Il valore predefinito è tcp.

      Puoi utilizzare le seguenti opzioni aggiuntive:

      • listen_host: facoltativo. Un indirizzo IP da ascoltare. Il valore predefinito è 0.0.0.0.

      • listen_port: facoltativo. Una porta per ascoltare. Il valore predefinito è 5140.

  • tcp destinatari:

    • format: obbligatorio. Formato di log. Valore supportato: json.

    • listen_host: facoltativo. Un indirizzo IP da ascoltare. Il valore predefinito è 127.0.0.1.

    • listen_port: facoltativo. Una porta per ascoltare. Il valore predefinito è 5170.

  • windows_event_log ricevitori (solo per Windows):

    • channels: obbligatorio. Un elenco di canali di log eventi di Windows da cui leggere i log.

Esempi di ricevitori di logging

Esempio di ricevitore files:

receivers:
  RECEIVER_ID:
    type: files

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

Esempio di ricevitore fluent_forward:

receivers:
  RECEIVER_ID:
    type: fluent_forward

    listen_host: 127.0.0.1
    listen_port: 24224

Esempio di ricevitore syslog:

receivers:
  RECEIVER_ID:
    type: syslog

    transport_protocol: tcp
    listen_host: 0.0.0.0
    listen_port: 5140

Esempio di ricevitore tcp:

receivers:
  RECEIVER_ID:
    type: tcp

    format: json
    listen_host: 127.0.0.1
    listen_port: 5170

Esempio di ricevitore windows_event_log (solo Windows):

receivers:
  RECEIVER_ID:
    type: windows_event_log

    channels: [System,Application,Security]

Esempio di ricevitore systemd_journald:

receivers:
  RECEIVER_ID:
    type: systemd_journald

Processori di logging

L'elemento facoltativo processors contiene un insieme di istruzioni di elaborazione, ciascuna identificata da un PROCESSOR_ID. Un processore descrive come manipolare le informazioni raccolte da un destinatario.

Struttura dei processori di logging

Ogni processore deve avere un identificatore univoco e includere un elemento type. I tipi validi sono:

  • parse_json: analizza i log strutturati in formato JSON.
  • parse_regex: analizza i log in formato testo tramite pattern regex per convertirli in log strutturati in formato JSON.
  • exclude_logs: esclude i log corrispondenti alle regole specificate.

La struttura processors ha il seguente aspetto:

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

A seconda del valore dell'elemento type, sono disponibili altre opzioni di configurazione, come indicato di seguito:

  • Processori parse_json e parse_regex:

    • field: facoltativo. Il nome del campo nel record da analizzare. Se l'opzione field non è specificata, il processore analizza il campo message.

    • time_key: facoltativo. Se la voce di log fornisce un campo con un timestamp, questa opzione specifica il nome di tale campo. Il valore estratto viene utilizzato per impostare il campo timestamp dell'elemento LogEntry risultante e viene rimosso dal payload.

      Se viene specificata l'opzione time_key, devi specificare anche quanto segue:

      • time_format: obbligatorio se viene utilizzato time_key. Questa opzione specifica il formato del campo time_key in modo che possa essere riconosciuto e analizzato correttamente. Per informazioni dettagliate sul formato, consulta la guida strptime(3).

  • Processori di parse_regex:

    • regex: obbligatorio. L'espressione regolare per l'analisi del campo. L'espressione deve includere nomi di chiavi per le sottoespressioni corrispondenti, ad esempio "^(?<time>[^ ]*) (?<severity>[^ ]*) (?<msg>.*)$".

      Per un insieme di espressioni regolari per l'estrazione di informazioni dai file di log più comuni delle applicazioni Linux, consulta File di log comuni di Linux.

  • Processori di exclude_logs:

    • match_any: obbligatorio. Un elenco di una o più regole. Se una voce di log corrisponde a una qualsiasi regola, l'agente operativo non importa quella voce.

      I log che vengono importati dall'agente operativo seguono la struttura LogEntry. I nomi dei campi sono sensibili alle maiuscole. Puoi specificare le regole solo in base ai seguenti campi e ai relativi sottocampi:

      • httpRequest
      • jsonPayload
      • labels
      • operation
      • severity
      • sourceLocation

      La seguente regola di esempio

      severity =~ "(DEBUG|INFO)"

      utilizza un'espressione regolare per escludere tutti i log di livello DEBUG e INFO.

      Le regole seguono la sintassi del linguaggio di query di Cloud Logging, ma supportano solo un sottoinsieme delle funzionalità supportate dal linguaggio di query di Logging:

      • Operatori di confronto: =, !=, :, =~, !~. Sono supportati solo i confronti delle stringhe.
      • Operatore di navigazione: .. Ad esempio jsonPayload.message.
      • Operatori booleani: AND, OR, NOT.
      • Raggruppare espressioni con ( ).

Esempi di processori di log

Processore parse_json di esempio:

processors:
  PROCESSOR_ID:
    type: parse_json

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

Processore parse_regex di esempio:

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"

Processore exclude_logs di esempio:

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"'

Campi speciali nei payload strutturati

Puoi impostare campi specifici nell'oggetto LogEntry che l'agente scrive nell'API Logging. Per i record di log strutturati, l'agente operativo elimina i campi elencati nella seguente tabella dalla struttura jsonPayload:

Campo di registrazione Campo LogEntry (Campo voce voce)

Opzione 1



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

Opzione 2



{
  "timestampSeconds": CURRENT_SECONDS,
  "timestampNanos": CURRENT_NANOS,
}
 timestamp
destinatario_id (non un campo record) logName
logging.googleapis.com/severity severity
logging.googleapis.com/labels labels
logging.googleapis.com/operation operation
logging.googleapis.com/sourceLocation sourceLocation

Tutti gli altri campi del record strutturato rimangono parte della struttura jsonPayload.

Servizio di logging

Il servizio di logging personalizza le preferenze per i log dell'agente operativo e collega i ricevitori e i processori di logging alle pipeline. La sezione service ha due elementi: log_level e pipelines.

Livello di Preferenze di lettura del log

log_level, disponibile con Ops Agent 2.6.0 e versioni successive, personalizza la Preferenze per i log del sottomodulo di logging dell'Agente operativo. Il valore predefinito è info. Le opzioni disponibili sono: error, warn, info, debug e trace.

Pipeline di logging

pipelines può contenere più ID pipeline e definizioni. Ogni definizione pipeline è composta dai seguenti elementi:

  • receivers: obbligatorio per le nuove pipeline. Un elenco di ID destinatario, come descritto in Destinatari dei log. L'ordine degli ID destinatari nell'elenco non è importante. La pipeline raccoglie i dati da tutti i destinatari elencati.

  • processors: facoltativo. Un elenco di ID processore, come descritto in Processori di logging. L'ordine degli ID processore nell'elenco è rilevante. Ogni record viene eseguito attraverso i processori nell'ordine indicato.

Esempi di configurazioni di service log

Una configurazione service ha la seguente struttura:

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

Per disattivare l'importazione integrata di log, ridefinire la pipeline predefinita con un elenco receivers vuoto e senza processori. L'intera configurazione di logging è simile alla seguente:

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

La seguente configurazione di service definisce una pipeline con ID custom_pipeline:

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

La seguente configurazione di service personalizza le Preferenze di lettura del log per il sottomodulo di logging: debug

logging:
  service:
    log_level: debug

File di log Linux comuni

La tabella seguente elenca i file di log comuni per le applicazioni Linux utilizzate di frequente:

Applicazione File di log comuni
Apache Per informazioni sui file di log di Apache, consulta la pagina Monitoraggio delle applicazioni di terze parti: Apache Web Server.
cassandra Per informazioni sui file di log di Cassandra, consulta Monitoraggio di applicazioni di terze parti: 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
jenkin /var/log/jenkins/jenkins.log
pontile /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 Per informazioni sui file di log Memcached, consulta la pagina Monitoraggio di applicazioni di terze parti: Memcached.
mongodb Per informazioni sui file di log di MongoDB, vedi Monitoraggio di applicazioni di terze parti: MongoDB.
mysql Per informazioni sui file di log di MySQL, consulta la pagina Monitoraggio di applicazioni di terze parti: MySQL.
nginx Per informazioni sui file di log nginx, consulta Monitoraggio delle applicazioni di terze parti: nginx.
Postgres Per informazioni sui file di log PostgreSQL, consulta la pagina Monitoraggio di applicazioni di terze parti: PostgreSQL.
burattino /var/log/puppet/http.log
/var/log/puppet/masterhttp.log
pupazzo /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 Per informazioni sui file di log RabbitMQ, consulta Monitoraggio delle applicazioni di terze parti: RabbitMQ.
redis Per informazioni sui file di log Redis, consulta la pagina Monitoraggio di applicazioni di terze parti: Redis.
redmine /var/log/redmine/*.log
sale /var/log/salt/key
/var/log/salt/master
/var/log/salt/minion
/var/log/salt/syndic.loc
Solr Per informazioni sui file di log di Apache Solr, consulta la pagina Monitoraggio di applicazioni di terze parti: Apache Solr.
Sugarcrm /var/www/*/sugarcrm.log
Ssyslog /var/log/syslog/var/log/messages
Tomcat Per informazioni sui file di log di Apache Tomcat, consulta Monitoraggio delle applicazioni di terze parti: Apache Tomcat.
guardia zoo Per informazioni sui file di log di Apache ZooKeeper, consulta la pagina Monitoraggio di applicazioni di terze parti: Apache ZooKeeper.

Configurazioni delle metriche

La configurazione di metrics utilizza il modello di configurazione descritto in precedenza:

  • receivers: un elenco di definizioni del destinatario. Un receiver descrive l'origine delle metriche, ad esempio, metriche di sistema come cpu o memory. I destinatari di questo elenco possono essere condivisi tra più pipeline.
  • processors: un elenco di definizioni di processore. Un processor descrive come modificare le metriche raccolte da un destinatario.
  • service: contiene una sezione pipelines che è un elenco di pipeline definizioni. Un pipeline collega un elenco di receivers e un elenco di processors per formare il flusso di dati.

Le sezioni seguenti descrivono ciascuno di questi elementi.

Destinatari delle metriche

L'elemento receivers contiene una serie di definizioni di destinatario. Un destinatario descrive da dove recuperare le metriche, come cpu e memory. Un destinatario può essere condiviso tra più pipeline.

Struttura dei ricevitori delle metriche

Ogni destinatario deve avere un identificatore, RECEIVER_ID, e includere un elemento type. I tipi validi sono:

  • hostmetrics
  • iis (solo Windows)
  • mssql (solo Windows)

Un destinatario può anche specificare l'opzione collection_interval di operazione. Il valore è nel formato di una durata, ad esempio 30s o 2m. Il valore predefinito è 60s.

Ciascuno di questi tipi di destinatari raccoglie un insieme di metriche; per informazioni sulle metriche specifiche incluse, consulta Metriche importate dai tipi di destinatario.

Puoi creare un solo ricevitore per ogni tipo. Ad esempio, non puoi definire due ricevitori di tipo hostmetrics.

Modifica dell'intervallo di raccolta nei destinatari delle metriche

Alcuni carichi di lavoro critici potrebbero richiedere avvisi rapidi. Se riduci l'intervallo di raccolta per le metriche, puoi configurare avvisi più sensibili. Per informazioni sulla modalità di valutazione degli avvisi, consulta Comportamento dei criteri di avviso basati sulle metriche.

Ad esempio, il seguente destinatario modifica l'intervallo di raccolta per le metriche dell'host (l'ID destinatario è hostmetrics) da 60 secondi a 10 secondi predefinito:

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

Puoi anche eseguire l'override dell'intervallo di raccolta per i ricevitori di metriche iis e mssql di Windows utilizzando la stessa tecnica.

Metriche importate dai destinatari

Le metriche importate dall'agente operativo hanno identificatori che iniziano con il seguente pattern: agent.googleapis.com/GROUP. Il componente GROUP identifica un insieme di metriche correlate; ha valori come cpu, network e altri.

Il destinatario hostmetrics importa i seguenti gruppi di metriche. Per ulteriori informazioni, consulta la sezione collegata per ogni gruppo nella pagina Metriche dell'agente operativo.

Group Metrica
cpu Carico della CPU a intervalli di 1 minuto
Carico della CPU a intervalli di 5 minuti
Carico della CPU a intervalli di 15 minuti
Utilizzo della CPU, con etichette per numero di CPU e stato della CPU
Percentuale di utilizzo della CPU, con etichette per numero di CPU e stato della CPU
disk Byte del disco letti, con etichetta per il dispositivo
Byte del disco scritti, con etichetta per il dispositivo
Tempo di I/O del disco, con etichetta per il dispositivo
Tempo di I/O ponderato del disco, con etichetta per il dispositivo
Operazioni del disco in attesa, con etichetta per dispositivo e direzione
Operazioni sul disco, con etichette per dispositivo e direzione
Tempo di funzionamento del disco, con etichette per stato del dispositivo e etichette, per etichette e utilizzo del dispositivo con etichette
interface
Solo Linux 		Conteggio totale degli errori di rete
Conteggio totale dei pacchetti inviati sulla rete
Numero totale di byte inviati sulla rete
memory Utilizzo della memoria, con etichetta per lo stato (bufferizzato, memorizzato nella cache, gratuito, slab, used)
Percentuale di utilizzo della memoria, con etichetta per lo stato (buffered, memorizzato nella cache, gratuito, lastre, utilizzato)
network Conteggio connessioni TCP, con etichette per stato porta e TCP
swap Scambia operazioni I/O, con etichetta per direzione
Scambia byte utilizzati, con etichette per dispositivo e stato
Scambia percentuale utilizzata, con etichette per dispositivo e stato
pagefile
Solo Windows 		Percentuale attuale di file di pagina utilizzata dallo stato
processes Conteggio dei processi, con etichetta per lo stato
Conteggio dei fork di processi
I/O di lettura per disco, con etichette per nome di processo e altri
I/O di scrittura per disco per processo, con etichette per nome di processo + altri
Utilizzo di RSS per processo, con etichette per nome di processo e altri
Utilizzo di VM per processo, con etichette per nome di processo e altri

Il destinatario iis (solo Windows) importa le metriche del gruppo iis. Per ulteriori informazioni, consulta la pagina relativa alle metriche degli agenti.

Group Metrica
iis
Solo Windows 		Connessioni attualmente aperte a IIS
Byte di rete trasferiti da IIS
Connessioni aperte a IIS
Richieste effettuate a IIS

Il destinatario mssql (solo Windows) importa le metriche del gruppo mssql. Per ulteriori informazioni, consulta la pagina Metriche dell'agente operativo.

Group Metrica
mssql
Solo Windows 		Connessioni attualmente aperte a SQL Server
Transazioni totali al server SQL al secondo
Transazioni di scrittura da SQL Server al secondo

Processori di metriche

L'elemento processor contiene una serie di definizioni di processore. Un processore descrive le metriche del tipo di destinatario da escludere. L'unico tipo supportato è exclude_metrics, che accetta un'opzione metrics_pattern. Il valore è un elenco di globi che corrispondono ai tipi di metrica che vuoi escludere dal gruppo raccolto da un ricevitore, ad esempio agent.googleapis.com/cpu/* o agent.googleapis.com/processes/*. Per trovare i nomi completi delle singole metriche, consulta la tabella del gruppo nella pagina Metriche dell'agente operativo.

Processore di metriche di esempio

L'esempio seguente mostra il processore exclude_metrics fornito nelle configurazioni integrate. Questo processore fornisce un valore metrics_pattern vuoto, quindi non esclude alcuna metrica.

processors:
  metrics_filter:
    type: exclude_metrics
    metrics_pattern: []

Per disattivare la raccolta di tutte le metriche di processo da parte dell'agente operativo, aggiungi quanto segue al file config.yaml:

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

Ciò esclude le metriche di processo dalla raccolta nel processore metrics_filter che si applica alla pipeline predefinita nel servizio metrics.

Servizio metriche

Il servizio delle metriche personalizza le Preferenze utente per i log dei moduli delle metriche dell'agente operativo e collega i ricevitori delle metriche e i processori alle pipeline. La sezione service ha due elementi: log_level e pipelines.

Livello di Preferenze di lettura delle metriche

log_level, disponibile con Ops Agent 2.6.0 e versioni successive, personalizza la Preferenze di lettura per i log dei sottomoduli delle metriche di Ops Agent. Il valore predefinito è info. Le opzioni disponibili sono: error, warn, info e debug.

Pipeline di metriche

La sezione service ha un singolo elemento, pipelines, che può contenere più ID pipeline e definizioni. Ogni definizione pipeline è composta dai seguenti elementi:

  • receivers: obbligatorio per le nuove pipeline. Un elenco di ID destinatario, come descritto in Destinatari dei parametri. L'ordine degli ID destinatari nell'elenco non è importante. La pipeline raccoglie i dati da tutti i destinatari elencati.

  • processors: facoltativo. Un elenco di ID processore, come descritto in Processori metriche. L'ordine degli ID processore nell'elenco è rilevante. Ogni punto metrica viene eseguito attraverso i processori nell'ordine indicato.

Esempi di configurazioni di metriche service

Una configurazione service ha la seguente struttura:

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

Per disattivare l'importazione integrata delle metriche host, ridefinire la pipeline predefinita con un elenco receivers vuoto e nessun processore. L'intera configurazione delle metriche si presenta come segue:

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

L'esempio seguente mostra la configurazione service integrata per Windows:

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

La seguente configurazione di service personalizza le Preferenze di lettura dei log del sottomodulo delle metriche in modo che siano debug:

metrics:
  service:
    log_level: debug