Questo documento fornisce dettagli sulle configurazioni predefinite e personalizzate di Ops Agent. Leggi questo documento se si applica una delle seguenti condizioni:
Vuoi modificare la configurazione di Ops Agent per raggiungere i seguenti obiettivi:
Disattiva l'inserimento di log o metriche integrato.
Per disattivare l'importazione dei log, vedi Esempio di configurazioni di
service
registrazione nel log.Per disattivare l'importazione delle metriche host, consulta Esempi di configurazioni delle metriche
service
.
Personalizza il percorso del file dei file di log da cui l'agente raccoglie i log. Consulta Ricevitori di log.
Personalizza il formato dei log strutturati che l'agente utilizza per elaborare le voci di log analizzando il JSON o utilizzando espressioni regolari; vedi Processori di logging.
Modifica la frequenza di campionamento per le metriche. Vedi Ricevitori di metriche.
Personalizza il gruppo o i gruppi di metriche da attivare. Per impostazione predefinita, l'agente raccoglie tutte le metriche di sistema, come
cpu
ememory
. Per maggiori dettagli, consulta la sezione Processori delle metriche.Personalizza la modalità di rotazione dei log dell'agente. Vedi Configurazione della rotazione dei log.
Raccogli metriche e log dalle applicazioni di terze parti supportate. Consulta la sezione Monitorare le applicazioni di terze parti per l'elenco delle applicazioni supportate.
Utilizza il ricevitore Prometheus per raccogliere metriche personalizzate.
Utilizza il ricevitore OpenTelemetry Protocol (OTLP) per raccogliere metriche e tracce personalizzate.
Ti interessa conoscere i dettagli tecnici della configurazione di Ops Agent.
Modello di configurazione
Ops Agent utilizza una configurazione predefinita integrata; non puoi modificare direttamente questa configurazione integrata. 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 cosa viene raccolto dall'agente.processors
: questo elemento descrive in che modo l'agente può modificare le informazioni raccolte.service
: questo elemento collega destinatari e responsabili del trattamento per creare flussi di dati, chiamati pipeline. L'elementoservice
contiene un elementopipelines
, che può contenere più pipeline.
La configurazione integrata è composta da questi elementi e utilizzi gli stessi elementi per ignorarla.
Configurazione integrata
La configurazione integrata per Ops Agent definisce la raccolta predefinita per log e metriche. Di seguito viene mostrata la configurazione integrata per Linux e Windows:
Linux
Per impostazione predefinita, Ops Agent raccoglie i log syslog
basati su file e le metriche
dell'host.
Per saperne di più sulle metriche raccolte, consulta Metriche importate dai destinatari.
Windows
Per impostazione predefinita, Ops Agent raccoglie i log eventi di Windows dai canali System
,
Application
e Security
, nonché le metriche host, le metriche IIS e le metriche SQL Server.
Per saperne di più sulle metriche raccolte, consulta Metriche importate dai destinatari.
Queste configurazioni sono descritte in dettaglio in Configurazione della registrazione nel log e Configurazione delle metriche.
Configurazione specificata dall'utente
Per eseguire l'override della configurazione integrata, aggiungi nuovi elementi di configurazione al file di configurazione utente. Inserisci la configurazione per Ops Agent 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 alla configurazione integrata al riavvio dell'agente.
Per eseguire l'override di un ricevitore, un processore o una pipeline integrati, ridefiniscili
nel file config.yaml
dichiarandoli con lo stesso identificatore.
A partire dalla versione 2.31.0 di Ops Agent, puoi anche configurare la funzionalità di rotazione dei log dell'agente. Per maggiori informazioni, consulta Configurare la rotazione dei log in Ops Agent.
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 delle metriche host a 30 secondi, includi un ricevitore di metriche chiamato hostmetrics
nel file config.yaml
che imposta il valore collection_interval
a 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 della registrazione nel log e
Configurazione delle metriche.
Puoi anche disattivare la raccolta dei dati di logging o delle metriche. Queste
modifiche sono descritte negli esempi di configurazioni di service
logging e di configurazioni di
service
metriche.
Puoi utilizzare questo file per impedire all'agente di raccogliere i log automatici e di inviarli a Cloud Logging. Per saperne di più, consulta la sezione Raccolta di log autonomi.
Puoi anche configurare la funzionalità di rotazione dei log dell'agente utilizzando questo file. Per maggiori informazioni, vedi Configurare la rotazione dei log in Ops Agent.
Non puoi configurare Ops Agent per esportare log o metriche in servizi diversi da Cloud Logging e Cloud Monitoring.
Configurazioni di logging
La configurazione logging
utilizza il modello di configurazione
descritto in precedenza:
receivers
: questo elemento descrive i dati da raccogliere dai file di log; questi dati vengono mappati in un modello <timestamp, record>.processors
: questo elemento facoltativo descrive in che modo l'agente può modificare le informazioni raccolte.service
: questo elemento collega destinatari e responsabili del trattamento 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.
Ops Agent invia i log a Cloud Logging. Non puoi configurarlo per esportare i log in altri servizi. Tuttavia, puoi configurare Cloud Logging per esportare i log. Per saperne di più, vedi Eseguire il routing dei log verso le destinazioni supportate.
Ricevitori di logging
L'elemento receivers
contiene un insieme di destinatari, ognuno identificato da
un RECEIVER_ID. Un ricevitore descrive come recuperare i log, ad esempio
tramite il monitoraggio dei 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 seguendo i file sul disco.fluent_forward
(Ops Agent versione 2.12.0 e successive): Raccogli i log inviati tramite il protocollo Fluent Forward su TCP.tcp
(versioni di Ops Agent 2.3.0 e successive): Raccogli i log in formato JSON ascoltando una porta TCP.- Solo per Linux:
syslog
: raccogli i messaggi Syslog tramite TCP o UDP.systemd_journald
(Ops Agent versione 2.4.0 e successive): raccogli i log del journal systemd dal servizio systemd-journald.
- Solo Windows:
windows_event_log
: raccogli i log eventi di Windows utilizzando l'API Windows Event Log.
- Destinatari dei log delle applicazioni di terze parti
La struttura di receivers
è la seguente:
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 segue:
files
ricevitori:include_paths
: obbligatorio. Un elenco di percorsi del file system da leggere seguendo 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 delle applicazioni Linux comuni, vedi File di log Linux comuni.
exclude_paths
: (Facoltativo). Un elenco di pattern di percorso del file system da escludere dall'insieme corrispondente ainclude_paths
.record_log_file_path
: (Facoltativo). Se impostato sutrue
, il percorso del file specifico da cui è stato ottenuto il record di log viene visualizzato nella voce di log di output come valore dell'etichettaagent.googleapis.com/log_file_path
. Quando si utilizza un carattere jolly, viene registrato solo il percorso del file da cui è stato ottenuto il record.wildcard_refresh_interval
: (Facoltativo). L'intervallo con cui vengono aggiornati i percorsi dei file con caratteri jolly ininclude_paths
. Indicato come durata di tempo, ad esempio30s
,2m
. Questa proprietà potrebbe essere utile in caso di velocità effettiva di logging elevata, in cui i file di log vengono ruotati più rapidamente dell'intervallo predefinito. Se non specificato, l'intervallo predefinito è di 60 secondi.
fluent_forward
ricevitori:listen_host
: (Facoltativo). Un indirizzo IP da ascoltare. Il valore predefinito è127.0.0.1
.listen_port
: (Facoltativo). Una porta su cui rimanere in ascolto. Il valore predefinito è24224
.
Ricevitori
syslog
(solo per Linux):transport_protocol
: valori supportati:tcp
,udp
.listen_host
: Un indirizzo IP su cui ascoltare.listen_port
: una porta su cui ascoltare.
tcp
ricevitori:format
: obbligatorio. Formato log. Valore supportato:json
.listen_host
: (Facoltativo). Un indirizzo IP da ascoltare. Il valore predefinito è127.0.0.1
.listen_port
: (Facoltativo). Una porta su cui rimanere in ascolto. Il valore predefinito è5170
.
Ricevitori
windows_event_log
(solo per Windows):channels
: obbligatorio. Un elenco di canali del log eventi di Windows da cui leggere i log.receiver_version
: (Facoltativo). Controlla quale API Windows Event Log utilizzare. I valori supportati sono1
e2
. Il valore predefinito è1
.render_as_xml
: (Facoltativo). Se impostato sutrue
, tutti i campi del log eventi, ad eccezione dijsonPayload.Message
ejsonPayload.StringInserts
, vengono visualizzati come documento XML in un campo stringa denominatojsonPayload.raw_xml
. Il valore predefinito èfalse
. Non può essere impostato sutrue
quandoreceiver_version
è1
.
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]
record_log_file_path: true
Esempio di ricevitore fluent_forward
:
receivers:
RECEIVER_ID:
type: fluent_forward
listen_host: 127.0.0.1
listen_port: 24224
Esempio di ricevitore syslog
(solo Linux):
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 windows_event_log
che esegue l'override del ricevitore integrato per utilizzare
la versione 2
:
receivers:
windows_event_log:
type: windows_event_log
channels: [System,Application,Security]
receiver_version: 2
Esempio di ricevitore systemd_journald
:
receivers:
RECEIVER_ID:
type: systemd_journald
Campi speciali nei payload strutturati
Per i processori e i ricevitori che possono importare dati strutturati (i ricevitori
fluent_forward
e tcp
e il processore parse_json
), puoi impostare campi speciali nell'input che verranno mappati a campi specifici nell'oggetto
LogEntry
che l'agente scrive nell'API Logging.
Quando Ops Agent riceve dati di log strutturati esterni, inserisce
i campi di primo livello nel campo jsonPayload
di LogEntry
, a meno che il nome del campo
non sia elencato nella tabella seguente:
Campo record | Campo LogEntry |
---|---|
Opzione 1
Opzione 2
|
timestamp |
receiver_id (non è un campo del record) | logName |
logging.googleapis.com/httpRequest (HttpRequest) |
httpRequest |
logging.googleapis.com/severity (stringa) |
severity |
logging.googleapis.com/labels (struct of string:string) |
labels |
logging.googleapis.com/operation (struct) |
operation |
logging.googleapis.com/sourceLocation (struct) |
sourceLocation |
logging.googleapis.com/trace (stringa) |
trace |
logging.googleapis.com/spanId (stringa) |
spanId |
I campi rimanenti del record strutturato rimangono parte della struttura jsonPayload
.
File di log Linux comuni
La seguente tabella 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, vedi Monitoraggio di applicazioni di terze parti: server web Apache. |
cassandra | Per informazioni sui file di log di Cassandra, vedi Monitoraggio delle applicazioni di terze parti: Cassandra. |
chef |
/var/log/chef-server/bookshelf/current
|
gitlab |
/home/git/gitlab/log/application.log
|
jenkins |
/var/log/jenkins/jenkins.log
|
jetty |
/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 di Memcached, vedi Monitoraggio delle applicazioni di terze parti: Memcached. |
mongodb | Per informazioni sui file di log di MongoDB, vedi Monitoraggio delle applicazioni di terze parti: MongoDB. |
mysql | Per informazioni sui file di log MySQL, consulta Monitoraggio delle applicazioni di terze parti: MySQL. |
nginx | Per informazioni sui file di log di nginx, vedi Monitoraggio delle applicazioni di terze parti: nginx. |
postgres | Per informazioni sui file di log di PostgreSQL, consulta Monitoraggio di applicazioni di terze parti: PostgreSQL. |
puppet |
/var/log/puppet/http.log
|
puppet-enterprise |
/var/log/pe-activemq/activemq.log
|
rabbitmq | Per informazioni sui file di log di RabbitMQ, vedi Monitoraggio di applicazioni di terze parti: RabbitMQ. |
redis | Per informazioni sui file di log di Redis, vedi Monitoraggio delle 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, vedi Monitoraggio delle applicazioni di terze parti: Apache Solr. |
sugarcrm |
/var/www/*/sugarcrm.log
|
syslog |
/var/log/syslog
|
tomcat | Per informazioni sui file di log di Apache Tomcat, vedi Monitoraggio delle applicazioni di terze parti: Apache Tomcat. |
zookeeper | Per informazioni sui file di log di Apache ZooKeeper, vedi Monitoraggio delle applicazioni di terze parti: Apache ZooKeeper. |
Etichette predefinite inserite
Per impostazione predefinita, i log possono contenere le seguenti etichette in LogEntry
:
Campo | Valore di esempio | Descrizione |
---|---|---|
labels."compute.googleapis.com/resource_name" |
test_vm |
Il nome della macchina virtuale da cui ha origine questo log. Scritto per tutti i log. |
labels."logging.googleapis.com/instrumentation_source" |
agent.googleapis.com/apache_access |
Il valore del destinatario type da cui ha origine questo log, con il prefisso agent.googleapis.com/ . Scritto solo dai destinatari delle integrazioni di terze parti. |
Processori di logging
L'elemento facoltativo processors
contiene un insieme di direttive di elaborazione, ognuna
identificata da un PROCESSOR_ID. Un processore descrive come manipolare le
informazioni raccolte da un ricevitore.
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_multiline
: analizza i log multiriga. (solo Linux)parse_regex
: analizza i log formattati in formato di testo tramite espressioni regolari per trasformarli in log strutturati formattati in formato JSON.exclude_logs
: escludi i log che corrispondono alle regole specificate (a partire dalla versione 2.9.0).modify_fields
: Imposta/trasforma i campi nelle voci di log (a partire dalla versione 2.14.0).
La struttura di processors
è la seguente:
processors: PROCESSOR_ID: type: parse_json ... PROCESSOR_ID_2: type: parse_regex ...
A seconda del valore dell'elemento type
, sono disponibili altre
opzioni di configurazione, come segue.
Processore parse_json
Struttura di configurazione
processors:
PROCESSOR_ID:
type: parse_json
time_key: <field name within jsonPayload>
time_format: <strptime format string>
Il processore parse_json
analizza il JSON di input nel campo jsonPayload
di LogEntry
. Altre parti di LogEntry
possono essere analizzate impostando
determinati campi speciali di primo livello.
time_key
: (Facoltativo). Se la voce di log fornisce un campo con un timestamp, questa opzione specifica il nome del campo. Il valore estratto viene utilizzato per impostare il campotimestamp
delLogEntry
risultante e viene rimosso dal payload.Se è 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 i dettagli del formato, consulta la guidastrptime(3)
.
Configurazione di esempio
processors:
PROCESSOR_ID:
type: parse_json
time_key: time
time_format: "%Y-%m-%dT%H:%M:%S.%L%Z"
Processore parse_multiline
Struttura di configurazione
processors:
PROCESSOR_ID:
type: parse_multiline
match_any:
- type: <type of the exceptions>
language: <language name>
match_any
: obbligatorio. Un elenco di una o più regole.type
: obbligatorio. È supportato un solo valore:language_exceptions
: consente al processore di concatenare le eccezioni in un unicoLogEntry
, in base al valore dell'opzionelanguage
.
language
: obbligatorio. È supportato un solo valore:java
: concatena le eccezioni Java comuni in un unicoLogEntry
.python
: concatena le eccezioni Python comuni in un unicoLogEntry
.go
: concatena le eccezioni Go comuni in un unicoLogEntry
.
Configurazione di esempio
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]
Nel processore extract_structure
, l'istruzione field: message
indica
che l'espressione regolare viene applicata al campo jsonPayload.message
della voce di log. Per impostazione predefinita, il destinatario dei file inserisce ogni riga del file di log in una
voce di log con un singolo campo payload chiamato jsonPayload.message
.
Il processore extract_structure
inserisce i campi estratti nei
sottocampi del campo LogEntry.jsonPayload
. Altre istruzioni nel file YAML
causano lo spostamento di due dei campi estratti, time
e severity
.
L'istruzione time_key: time
estrae il campo LogEntry.jsonPayload.time
,
analizza il timestamp e poi aggiunge il campo LogEntry.timestamp
.
Il processore move_severity
sposta il campo gravità dal campo
LogEntry.jsonPayload.severity
al campo LogEntry.severity
.
File di log di esempio:
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
L'agente importa ogni riga del file di log in Cloud Logging nel seguente formato:
{
"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"
}
Processore parse_regex
Struttura di configurazione
processors:
PROCESSOR_ID:
type: parse_regex
regex: <regular expression>
time_key: <field name within jsonPayload>
time_format: <format string>
time_key
: (Facoltativo). Se la voce di log fornisce un campo con un timestamp, questa opzione specifica il nome del campo. Il valore estratto viene utilizzato per impostare il campotimestamp
delLogEntry
risultante e viene rimosso dal payload.Se è 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 i dettagli del formato, consulta la guidastrptime(3)
.
regex
: obbligatorio. L'espressione regolare per l'analisi del campo. L'espressione deve includere i nomi delle chiavi per le sottoespressioni corrispondenti, ad esempio"^(?<time>[^ ]*) (?<severity>[^ ]*) (?<msg>.*)$"
.Il testo corrispondente ai gruppi di acquisizione denominati verrà inserito nei campi del campo
jsonPayload
diLogEntry
. Per aggiungere ulteriore struttura ai log, utilizza il processoremodify_fields
.Per un insieme di espressioni regolari per estrarre informazioni dai file di log delle applicazioni Linux comuni, vedi File di log Linux comuni.
Configurazione di esempio
processors:
PROCESSOR_ID:
type: parse_regex
regex: "^(?<time>[^ ]*) (?<severity>[^ ]*) (?<msg>.*)$"
time_key: time
time_format: "%Y-%m-%dT%H:%M:%S.%L%Z"
Processore exclude_logs
Struttura della configurazione:
type: exclude_logs
match_any:
- <filter>
- <filter>
La configurazione di primo livello per questo processore contiene un singolo campo,
match_any
, che contiene un elenco di regole di filtro.
match_any
: obbligatorio. Un elenco di una o più regole. Se una voce di log corrisponde a una regola, l'Ops Agent non la importa.I log inseriti da Ops Agent seguono la struttura
LogEntry
. I nomi dei campi sono sensibili alle maiuscole. Puoi specificare regole solo in base ai seguenti campi e ai relativi sottocampi:httpRequest
jsonPayload
labels
operation
severity
sourceLocation
trace
spanId
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 di stringhe. - Operatore di navigazione:
.
. Ad esempiojsonPayload.message
. - Operatori booleani:
AND
,OR
,NOT
. - Raggruppamento di espressioni con
(
)
.
Configurazione 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"'
modify_fields
Processore
Il processore modify_fields
consente di personalizzare la struttura e i contenuti delle voci di log.
Struttura di configurazione
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 configurazione di primo livello per questo processore contiene un singolo campo, fields
, che contiene una mappa dei nomi dei campi di output e delle traduzioni corrispondenti. Per ogni campo di output, vengono applicate un'origine facoltativa e zero o più operazioni di mutazione.
Tutti i nomi dei campi utilizzano la sintassi separata da punti del linguaggio di query di Cloud Logging. I filtri utilizzano il linguaggio di query di Cloud Logging.
Tutte le trasformazioni vengono applicate in parallelo, il che significa che le origini e i filtri operano sulla voce di log di input originale e pertanto non possono fare riferimento al nuovo valore di altri campi modificati dallo stesso processore.
Opzioni di origine: è consentita al massimo un'origine specificata.
Nessuna origine specificata
Se non viene specificato alcun valore di origine, il valore esistente nel campo di destinazione verrà modificato.
move_from: <source field>
Il valore di
<source field>
verrà utilizzato come origine per il campo di destinazione. Inoltre,<source field>
verrà rimosso dalla voce di log. Se viene fatto riferimento a un campo di origine sia damove_from
che dacopy_from
, il campo di origine verrà comunque rimosso.copy_from: <source field>
Il valore di
<source field>
verrà utilizzato come origine per il campo di destinazione.<source field>
non verrà rimosso dalla voce di log a meno che non venga fatto riferimento anche a un'operazionemove_from
o modificato in altro modo.static_value: <string>
La stringa statica
<string>
verrà utilizzata come origine per il campo di destinazione.
Opzioni di mutazione: è possibile applicare zero o più operatori di mutazione a un singolo campo. Se vengono forniti più operatori, questi verranno sempre applicati nel seguente ordine.
default_value: <string>
Se il campo di origine non esisteva, il valore di output verrà impostato su
<string>
. Se il campo di origine esiste già (anche se contiene una stringa vuota), il valore originale non viene modificato.map_values: <map>
Se il valore di input corrisponde a una delle chiavi in
<map>
, il valore di output verrà sostituito con il valore corrispondente della mappa.map_values_exclusive: {true|false}
Se il valore di
<source field>
non corrisponde a nessuna chiave specificata nelle coppiemap_values
, il campo di destinazione verrà annullato forzatamente semap_values_exclusive
è true o lasciato invariato semap_values_exclusive
è false.type: {integer|float}
Il valore di input verrà convertito in un numero intero o in virgola mobile. Se la stringa non può essere convertita in un numero, il valore di output non verrà impostato. Se la stringa contiene un numero decimale, ma il tipo è specificato come
integer
, il numero verrà troncato a un numero intero.Tieni presente che l'API Cloud Logging utilizza JSON e pertanto non supporta un numero intero a 64 bit completo; se è necessario un numero intero a 64 bit (o più grande), deve essere archiviato come stringa nella voce di log.
omit_if: <filter>
Se il filtro corrisponde al record di log di input, il campo di output verrà annullato. Può essere utilizzato per rimuovere i valori segnaposto, ad esempio:
httpRequest.referer: move_from: jsonPayload.referer omit_if: httpRequest.referer = "-"
Configurazioni di esempio
Il processore parse_json
trasformerebbe un file JSON contenente
{
"http_status": "400",
"path": "/index.html",
"referer": "-"
}
in una struttura LogEntry con il seguente aspetto:
{
"jsonPayload": {
"http_status": "400",
"path": "/index.html",
"referer": "-"
}
}
che potrebbe essere trasformato con modify_fields
in questo LogEntry
:
{
"httpRequest": {
"status": 400,
"requestUrl": "/index.html",
}
}
utilizzando questa configurazione di Ops Agent:
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]
Questa configurazione legge i log in formato JSON da /var/log/http.json
e
compila parte della struttura httpRequest
dai campi dei log.
Servizio di logging
Il servizio di logging personalizza il livello di dettaglio dei log di Ops Agent e
collega i ricevitori e i processori di logging in pipeline. La sezione service
contiene i seguenti elementi:
log_level
pipelines
Livello di verbosità del log
Il campo log_level
, disponibile con Ops Agent versione 2.6.0 e successive,
personalizza il livello di dettaglio dei log del sottomodulo di logging di Ops Agent. Il valore predefinito è info
. Le opzioni disponibili sono: error
, warn
, info
, debug
, trace
.
La seguente configurazione personalizza il livello di dettaglio dei log per il sottomodulo di logging
in modo che sia debug
:
logging:
service:
log_level: debug
Pipeline di logging
Il campo pipelines
può contenere più ID e definizioni di pipeline. Ogni valore
pipeline
è costituito dai seguenti elementi:
receivers
: obbligatorio per le nuove pipeline. Un elenco di ID ricevitore, come descritto in Registrazione dei ricevitori. L'ordine degli ID dei destinatari nell'elenco non è importante. La pipeline raccoglie i dati da tutti i ricevitori elencati.processors
: (Facoltativo). Un elenco di ID processore, come descritto in Processori di logging. L'ordine degli ID processore nell'elenco è importante. Ogni record viene elaborato dai processori nell'ordine elencato.
Esempio di configurazioni di logging 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 impedire all'agente di raccogliere e inviare voci /var/log/message
o /var/log/syslog
, ridefinisci la pipeline predefinita con un elenco receivers
vuoto e nessun processore. Questa configurazione non
interrompe il sottocomponente di logging dell'agente, perché l'agente deve essere in grado
di raccogliere i log per il sottocomponente di monitoraggio. L'intera configurazione del logging vuota
ha il seguente aspetto:
logging:
service:
pipelines:
default_pipeline:
receivers: []
La seguente configurazione service
definisce una pipeline con l'ID
custom_pipeline
:
logging:
service:
pipelines:
custom_pipeline:
receivers:
- RECEIVER_ID
processors:
- PROCESSOR_ID
Configurazioni delle metriche
La configurazione metrics
utilizza il modello di configurazione
descritto in precedenza:
receivers
: un elenco di definizioni di destinatari. Unreceiver
descrive l'origine delle metriche, ad esempio le metriche di sistema comecpu
omemory
. I destinatari di questo elenco possono essere condivisi tra più pipeline.processors
: un elenco di definizioni del processore. Unprocessor
descrive come modificare le metriche raccolte da un ricevitore.service
: contiene una sezionepipelines
che è un elenco di definizioni dipipeline
. Unpipeline
collega un elenco direceivers
e un elenco diprocessors
per formare il flusso di dati.
Le sezioni seguenti descrivono ciascuno di questi elementi.
Ops Agent invia le metriche a Cloud Monitoring. Non puoi configurarlo per esportare le metriche in altri servizi.
Destinatari delle metriche
L'elemento receivers
contiene un insieme di definizioni del destinatario. Un ricevitore
descrive da dove recuperare le metriche, ad esempio cpu
e memory
.
Un ricevitore può essere condiviso tra più pipeline.
Struttura dei ricevitori di metriche
Ogni destinatario deve avere un identificatore, RECEIVER_ID, e includere un elemento type
. I tipi integrati validi sono:
hostmetrics
iis
(solo Windows)mssql
(solo Windows)
Un ricevitore può anche specificare l'opzione collection_interval
. Il
valore è nel formato di una durata, ad esempio 30s
o 2m
. Il valore predefinito è 60s
.
Ciascuno di questi tipi di ricevitore raccoglie un insieme di metriche. Per informazioni sulle metriche specifiche incluse, consulta la sezione Metriche inserite dai ricevitori.
Puoi creare un solo destinatario per ogni tipo. Ad esempio, non puoi
definire due destinatari di tipo hostmetrics
.
Modifica dell'intervallo di raccolta nei ricevitori di metriche
Alcuni workload critici potrebbero richiedere avvisi rapidi. Se riduci l'intervallo di raccolta delle metriche, puoi configurare avvisi più sensibili. Per informazioni su come vengono valutati gli avvisi, consulta Comportamento dei criteri di avviso basati su metriche.
Ad esempio, il seguente ricevitore modifica l'intervallo di raccolta per le metriche
dell'host (l'ID ricevitore è hostmetrics
) dal valore predefinito di 60 secondi a 10
secondi:
metrics:
receivers:
hostmetrics:
type: hostmetrics
collection_interval: 10s
Puoi anche eseguire l'override dell'intervallo di raccolta per i ricevitori delle metriche Windows iis
e mssql
utilizzando la stessa tecnica.
Metriche importate dai ricevitori
Le metriche inserite da Ops Agent 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 ricevitore hostmetrics
Il ricevitore hostmetrics
acquisisce i seguenti gruppi di metriche. Per
maggiori informazioni, consulta la sezione collegata per ogni gruppo nella pagina
Metriche dell'agente operativo.
Gruppo | 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 il numero di CPU e lo stato della CPU Percentuale di utilizzo della CPU, con etichette per il numero di CPU e lo stato della CPU |
disk
|
Byte letti dal disco, con etichetta per il dispositivo Byte scritti sul disco, 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 in attesa del disco, con etichetta per il dispositivo Operazioni unite del disco, con etichette per dispositivo e direzione Operazioni del disco, con etichette per dispositivo e direzione Tempo di operazione del disco, con etichette per dispositivo e direzione Utilizzo del disco, con etichette per dispositivo e stato Utilizzo del disco, con etichette per dispositivo e stato |
gpu Solo Linux; per altre informazioni importanti, consulta Informazioni sulle metriche gpu .
|
Numero attuale di byte di memoria GPU utilizzati, per stato Quantità massima di memoria GPU, in byte, allocata dal processo Percentuale di tempo nella durata del processo in cui uno o più kernel sono stati eseguiti sulla GPU Percentuale di tempo, dall'ultimo campione, in cui la GPU è stata attiva |
interface Solo Linux |
Conteggio totale degli errori di rete Conteggio totale dei pacchetti inviati tramite la rete Numero totale di byte inviati tramite la rete |
memory
|
Utilizzo della memoria, con etichetta per lo stato (buffered, cached, free, slab, used) Percentuale di utilizzo della memoria, con etichetta per lo stato (buffered, cached, free, slab, used) |
network
|
Conteggio delle connessioni TCP, con etichette per porta e stato TCP |
swap
|
Scambia le operazioni di I/O, con l'etichetta per la direzione Scambia i byte utilizzati, con le etichette per dispositivo e stato Scambia la percentuale utilizzata, con le etichette per dispositivo e stato |
pagefile Solo Windows |
Percentuale attuale di file di paging utilizzato per stato |
processes
|
Conteggio processi, con etichetta per lo stato Conteggio processi fork I/O di lettura del disco per processo, con etichette per nome processo e altri I/O di scrittura del disco per processo, con etichette per nome processo e altri Utilizzo RSS per processo, con etichette per nome processo e altri Utilizzo VM per processo, con etichette per nome processo e altri |
Il ricevitore iis
(solo Windows)
Il ricevitore iis
(solo Windows) acquisisce le metriche del gruppo iis
.
Per ulteriori informazioni, consulta la pagina
Metriche dell'agente.
Gruppo | Metrica |
---|---|
iis Solo Windows |
Connessioni attualmente aperte a IIS Byte di rete trasferiti da IIS Connessioni aperte a IIS Richieste effettuate a IIS |
Il ricevitore mssql
(solo Windows)
Il ricevitore mssql
(solo Windows) acquisisce le metriche del gruppo mssql
. Per
maggiori informazioni, consulta la pagina
Metriche di Ops Agent.
Gruppo | Metrica |
---|---|
mssql Solo Windows |
Connessioni attualmente aperte a SQL Server Transazioni totali al secondo di SQL Server Transazioni di scrittura al secondo di SQL Server |
Processori delle metriche
L'elemento processor
contiene un insieme di definizioni del processore. Un processore
descrive le metriche del tipo di ricevitore da escludere. L'unico tipo supportato
è exclude_metrics
, che accetta un'opzione metrics_pattern
. Il valore è
un elenco di glob che corrispondono ai tipi di metriche dell'agente Ops
che vuoi escludere dal gruppo raccolto da un ricevitore. Ad esempio:
- Per escludere tutte le metriche della CPU dell'agente,
specifica
agent.googleapis.com/cpu/*
. - Per escludere la metrica di utilizzo della CPU dell'agente, specifica
agent.googleapis.com/cpu/utilization
. - Per escludere la metrica conteggio richieste lato client dall'integrazione di terze parti
Apache Cassandra, specifica
workloads.googleapis.com/cassandra.client.request.count
. - Per escludere tutte le metriche lato client dalle metriche
raccolte dall'integrazione di terze parti
Apache Cassandra, specifica
workloads.googleapis.com/cassandra.client.*
.
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 dei processi da parte dell'Ops Agent,
aggiungi quanto segue al file config.yaml
:
metrics: processors: metrics_filter: type: exclude_metrics metrics_pattern: - agent.googleapis.com/processes/*
Ciò esclude le metriche dei processi dalla raccolta nel metrics_filter
che si applica alla pipeline predefinita nel servizio metrics
.
Servizio di metriche
Il servizio di metriche personalizza il livello di dettaglio per i log del modulo di metriche di Ops Agent e collega i ricevitori e i processori di metriche in pipeline. La sezione
service
ha due elementi: log_level
e pipelines
.
Livello di dettaglio delle metriche
log_level
, disponibile con le versioni 2.6.0 e successive di Ops Agent, personalizza
il livello di dettaglio dei log del sottomodulo delle metriche di Ops Agent. Il valore predefinito è info
.
Le opzioni disponibili sono: error
, warn
, info
, debug
.
Pipeline delle metriche
La sezione service
ha un singolo elemento, pipelines
, che può contenere
più ID e definizioni di pipeline. Ogni definizione di pipeline
è costituita dai seguenti elementi:
receivers
: obbligatorio per le nuove pipeline. Un elenco di ID ricevitore, come descritto in Ricevitori di metriche. L'ordine degli ID dei destinatari nell'elenco non è importante. La pipeline raccoglie i dati da tutti i ricevitori elencati.processors
: (Facoltativo). Un elenco di ID processore, come descritto in Processori delle metriche. L'ordine degli ID processore nell'elenco è importante. Ogni punto della metrica viene elaborato dai processori nell'ordine elencato.
Esempi di configurazioni delle 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, ridefinisci la pipeline predefinita con un elenco receivers
vuoto e nessun processore. L'intera configurazione
delle metriche è la seguente:
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 il livello di dettaglio dei log per il sottomodulo delle metriche in modo che sia debug
:
metrics:
service:
log_level: debug
Raccolta dei log personali
Per impostazione predefinita, i self log di Fluent Bit di Ops Agent vengono inviati a Cloud Logging. Questi log possono includere molte informazioni e l'aumento del volume potrebbe aumentare i costi di utilizzo di Cloud Logging.
Puoi disattivare la raccolta di questi log automatici, a partire dalla versione 2.44.0 di Ops Agent, utilizzando l'opzione default_self_log_file_collection
.
Per disattivare la raccolta dei log automatici, aggiungi una sezione global
al file di configurazione specificato dall'utente e imposta l'opzione default_self_log_file_collection
sul valore false
:
logging: ... metrics: ... global: default_self_log_file_collection: false
Configurazione della rotazione dei log
A partire dalla versione 2.31.0 di Ops Agent, puoi anche configurare la funzionalità di rotazione dei log dell'agente utilizzando i file di configurazione. Per maggiori informazioni, vedi Configurare la rotazione dei log in Ops Agent.