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:
Disattiva l'importazione delle metriche o il logging integrato.
Per disattivare l'importazione dei log, consulta le configurazioni di
service
esempio di logging.Per disattivare l'importazione delle metriche host, consulta le configurazioni di
service
per le metriche di esempio.
Personalizza il percorso dei file di log da cui l'agente raccoglie i log; consulta Destinatari dei log.
Personalizza il formato del log strutturato utilizzato dall'agente per elaborare le voci di log, analizzando il codice JSON o utilizzando espressioni regolari. Consulta Processori di logging.
Modificare la frequenza di campionamento per le metriche; consulta Destinatari delle metriche.
Personalizza il gruppo o i gruppi di metriche da attivare. L'agente raccoglie per impostazione predefinita tutte le metriche di sistema, come
cpu
ememory
; consulta la pagina relativa ai processori di metriche.
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'elementoservice
contiene un elementopipelines
, 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.
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.
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
service
delle 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'elementoservice
contiene un elementopipelines
, 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) oC:\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 ininclude_paths
.wildcard_refresh_interval
: facoltativo. L'intervallo a cui vengono aggiornati i percorsi dei file con caratteri jolly ininclude_paths
. Dato il tempo, ad esempio30s
,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
eparse_regex
:field
: facoltativo. Il nome del campo nel record da analizzare. Se l'opzionefield
non è specificata, il processore analizza il campomessage
.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 campotimestamp
dell'elementoLogEntry
risultante e viene rimosso dal payload.Se viene specificata l'opzione
time_key
, devi specificare anche quanto segue:time_format
: obbligatorio se viene utilizzatotime_key
. Questa opzione specifica il formato del campotime_key
in modo che possa essere riconosciuto e analizzato correttamente. Per informazioni dettagliate sul formato, consulta la guidastrptime(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
eINFO
.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 esempiojsonPayload.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
Opzione 2
|
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
|
GitLab |
/home/git/gitlab/log/application.log
|
jenkin |
/var/log/jenkins/jenkins.log
|
pontile |
/var/log/jetty/out.log
|
Joomla |
/var/www/joomla/logs/*.log
|
Magento |
/var/www/magento/var/log/exception.log
|
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
|
pupazzo |
/var/log/pe-activemq/activemq.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
|
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. Unreceiver
descrive l'origine delle metriche, ad esempio, metriche di sistema comecpu
omemory
. I destinatari di questo elenco possono essere condivisi tra più pipeline.processors
: un elenco di definizioni di processore. Unprocessor
descrive come modificare le metriche raccolte da un destinatario.service
: contiene una sezionepipelines
che è un elenco dipipeline
definizioni. Unpipeline
collega un elenco direceivers
e un elenco diprocessors
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