Questo documento fornisce dettagli sulle Ops Agent predefinite e configurazioni. Leggi questo documento se una delle seguenti condizioni si applica al tuo caso:
Vuoi modificare la configurazione di Ops Agent per ottenere seguenti obiettivi:
Disattiva il logging integrato o l'importazione delle metriche.
Per disattivare l'importazione del logging, consulta Esempio di logging
service
configurazioni.Per disattivare l'importazione delle metriche dell'host, consulta Metriche di esempio
service
configurazioni.
Personalizza il percorso dei file di log raccolti dall'agente da: consulta Ricevitori di Logging.
Personalizza il formato del log strutturato utilizzato dall'agente per l'elaborazione le voci di log, analizzando il JSON o utilizzando espressioni regolari; consulta Processori di logging.
Modificare la frequenza di campionamento delle metriche. consulta Metriche o ricevitori.
Personalizza il gruppo o i gruppi di metriche da abilitare. L'agente raccoglie tutte le metriche di sistema, come
cpu
ememory
, per impostazione predefinita; vedi Processori di metriche.personalizza il modo in cui l'agente ruota i log; consulta Rotazione log configurazione.
Raccogli metriche e log dalle applicazioni di terze parti supportate. Vedi Monitorare le applicazioni di terze parti. per l'elenco delle applicazioni supportate.
Utilizzare 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 del configurazione.
Modello di configurazione
Ops Agent utilizza una configurazione predefinita integrata; non puoi eseguire direttamente o modificare questa configurazione integrata. Crea invece un file di override che vengono uniti alla configurazione integrata al riavvio dell'agente.
Gli elementi di base della configurazione sono i seguenti:
receivers
: questo elemento descrive i dati raccolti dall'agente.processors
: questo elemento descrive in che modo l'agente può modificare i dati raccolti informazioni.service
: questo elemento collega ricevitori e processori per creare di dati chiamati pipeline. L'elementoservice
contiene un elementopipelines
che può contenere più pipeline.
La configurazione integrata è composta da questi elementi e puoi utilizzare gli stessi elementi per sostituire la configurazione integrata.
Configurazione integrata
La configurazione integrata per Ops Agent definisce l'impostazione predefinita per i log e le metriche. Di seguito vengono mostrate le funzionalità integrate per Linux e Windows:
Linux
Per impostazione predefinita, Ops Agent raccoglie i log syslog
basati su file e l'host
metrics.
Per ulteriori informazioni sulle metriche raccolte, consulta Metriche importate dai destinatari.
Windows
Per impostazione predefinita, Ops Agent raccoglie i log eventi di Windows da System
,
Application
e Security
, nonché le metriche host, IIS
e metriche di SQL Server.
Per ulteriori informazioni sulle metriche raccolte, consulta Metriche importate dai destinatari.
Queste configurazioni vengono discusse in modo più dettagliato 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 utente. Inserisci la tua 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, ridefiniscilo
nel tuo file config.yaml
dichiarandolo con lo stesso identificatore.
A partire da Ops Agent versione 2.31.0,
puoi anche configurare la funzionalità di rotazione log dell'agente; per ulteriori informazioni,
consulta Configurare la rotazione dei log nel
Ops Agent.
Ad esempio, la configurazione integrata per le metriche include un hostmetrics
che specifica un intervallo di raccolta di 60 secondi. Per modificare
intervallo di raccolta per le metriche host a 30 secondi, includi un ricevitore delle metriche
denominato hostmetrics
nel file config.yaml
che imposta
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 di Logging e
Configurazione delle metriche.
Puoi anche disattivare la raccolta dei dati di logging o delle metriche. Questi
le modifiche sono descritte nell'esempio di registrazione service
configurazioni e metriche
configurazioni di service
.
Puoi utilizzare questo file per impedire all'agente di raccogliere i self-log e l'invio di questi log a Cloud Logging. Per ulteriori informazioni, vedi Raccolta di autolog.
Puoi anche configurare la funzionalità di rotazione log dell'agente utilizzando questo file. per ulteriori informazioni, consulta Configurare la rotazione dei log nel Ops Agent.
Non puoi configurare Ops Agent per l'esportazione dei log o metriche a servizi diversi da Cloud Logging e Cloud Monitoring.
Configurazioni di logging
La configurazione logging
utilizza il modello di configurazione
descritti in precedenza:
receivers
: questo elemento descrive i dati da raccogliere dai file di log; questi dati sono mappati in un <timestamp, record> model.processors
: questo elemento facoltativo descrive in che modo l'agente può modificare le informazioni raccolte.service
: questo elemento collega ricevitori e processori per creare 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.
Ciascuno di questi elementi viene descritto nelle sezioni seguenti.
Ops Agent invia i log a Cloud Logging. Non puoi configurarlo per ed esportare i log in altri servizi. Tuttavia, puoi configurare Cloud Logging esportare i log; Per ulteriori informazioni, consulta Registri di routing supportati destinazioni.
Ricevitori Logging
L'elemento receivers
contiene un insieme di destinatari, ciascuno identificato da
un RECEIVER_ID. Un destinatario descrive come recuperare i log; ad esempio
accordando i file, usando 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 type
. I tipi validi sono:
files
: raccogli i log eseguendo il tailing dei file su disco.fluent_forward
(Ops Agent 2.12.0 e versioni successive): Raccogli i log inviati tramite il protocollo Fluent Forward su TCP.tcp
(Ops Agent 2.3.0 e versioni successive): Raccogli i log in formato JSON ascoltando una porta TCP.- Solo Linux:
syslog
: raccogli messaggi Syslog su TCP o UDP.systemd_journald
(Ops Agent versioni 2.4.0 e successive): raccolta I log del journal di sistema dal servizio systemd- journald.
- Solo Windows:
windows_event_log
: raccogli i registri eventi di Windows utilizzando il log eventi di Windows API.
- Ricevitori di log di applicazioni di terze parti
La struttura receivers
è simile alla seguente:
receivers: RECEIVER_ID: type: files ... RECEIVER_ID_2: type: syslog ...
A seconda del valore dell'elemento type
, potrebbero esserci altri
di configurazione di Google Cloud, come segue:
files
destinatari:include_paths
: campo obbligatorio. Un elenco di percorsi di file system da leggere tailing di ogni file. Nei percorsi è possibile utilizzare un carattere jolly (*
). della ad esempio/var/log/*.log
(Linux) oC:\logs\*.log
(Windows).Per un elenco dei file di log delle applicazioni Linux più comuni, vedi File di log comuni di Linux.
exclude_paths
: facoltativo. Un elenco di pattern di percorso di file system escludi dall'insieme corrispondente ainclude_paths
.record_log_file_path
: facoltativo. Se impostato sutrue
, il percorso del il file specifico da cui è stato ottenuto il record di log è voce di log come valore del parametroagent.googleapis.com/log_file_path
dell'etichetta. Quando utilizzi un carattere jolly, solo il percorso del file da cui il record ottenuto viene registrato.wildcard_refresh_interval
: facoltativo. L'intervallo al quale il carattere jolly i percorsi dei file ininclude_paths
vengono aggiornati. Dato come durata, ad esempio30s
,2m
. Questa proprietà potrebbe essere utile in condizioni velocità effettiva di logging in cui i file di log vengono ruotati più velocemente rispetto al valore predefinito intervallo di tempo. Se non specificato, l'intervallo predefinito è 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 su cui ascoltare. Il valore predefinito è24224
.
syslog
ricevitori (solo per Linux):transport_protocol
: facoltativo. Valori supportati:tcp
,udp
. Il valore predefinito ètcp
.listen_host
: facoltativo. Un indirizzo IP da ascoltare. Il valore predefinito è0.0.0.0
.listen_port
: facoltativo. Una porta su cui ascoltare. Il valore predefinito è5140
.
tcp
destinatari:format
: campo 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 ascoltare. Il valore predefinito è5170
.
windows_event_log
ricevitori (solo per Windows):channels
: campo obbligatorio. Un elenco dei canali del log eventi di Windows da che legge i log.receiver_version
: facoltativo. Consente di controllare l'API Event Log di Windows da 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
, sono visualizzati come documento XML in un campo stringa denominatojsonPayload.raw_xml
. Il valore predefinito èfalse
. Impossibile impostaretrue
sereceiver_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
Ricevitore syslog
di esempio (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 da utilizzare
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 destinatari che possono importare dati strutturati (il
fluent_forward
e tcp
e il processore parse_json
), puoi
imposta campi speciali nell'input che verranno mappati a campi specifici nel
Oggetto LogEntry
che l'agente scrive nell'API Logging.
Quando Ops Agent riceve dati di log strutturati esterni, inserisce
campi di primo livello nel campo jsonPayload
di LogEntry
, a meno che il campo
è riportato nella seguente tabella:
Campo record | Campo LogEntry |
---|---|
Opzione 1
Opzione 2
|
timestamp |
ricevitore_id (non un campo di record) | logName |
logging.googleapis.com/httpRequest (HttpRequest) |
httpRequest |
logging.googleapis.com/severity (stringa) |
severity |
logging.googleapis.com/labels (struct della stringa: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 |
Eventuali campi di record strutturati rimanenti rimangono parte di jsonPayload
alla struttura del centro di costo.
File di log comuni di Linux
La tabella seguente elenca i file di log comuni per l'ambiente Linux utilizzato di frequente applicazioni:
Applicazione | File di log comuni |
---|---|
Apache | Per informazioni sui file di log Apache, consulta Monitoraggio di applicazioni di terze parti: server web Apache. |
cassandra | Per informazioni sui file di log di Cassandra, consulta 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
|
molo |
/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 Monitoraggio delle applicazioni di terze parti: Memcached. |
mongodb | Per informazioni sui file di log MongoDB, Monitoraggio di applicazioni di terze parti: MongoDB. |
mysql | Per informazioni sui file di log MySQL, consulta Monitoraggio di applicazioni di terze parti: MySQL. |
nginx | Per informazioni sui file di log nginx, Monitoraggio delle applicazioni di terze parti: nginx. |
Postgres | Per informazioni sui file di log PostgreSQL, consulta Monitoraggio di applicazioni di terze parti: PostgreSQL. |
burattino |
/var/log/puppet/http.log
|
impresa-burattina |
/var/log/pe-activemq/activemq.log
|
Rabbitmq | Per informazioni sui file di log RabbitMQ, consulta Monitoraggio di applicazioni di terze parti: RabbitMQ. |
redis | Per informazioni sui file di log Redis, consulta 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 Monitoraggio di 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, consulta Monitoraggio di applicazioni di terze parti: Apache Tomcat. |
custode zoo | Per informazioni sui file di log di Apache ZooKeeper, consulta Monitoraggio delle applicazioni di terze parti: Apache ZooKeeper. |
Etichette importate predefinite
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 il log. Scritta per tutti i log. |
labels."logging.googleapis.com/instrumentation_source" |
agent.googleapis.com/apache_access |
Il valore del ricevitore type da cui ha origine il log, preceduto da agent.googleapis.com/ . Scritto solo da destinatari di integrazioni di terze parti. |
Processori di logging
L'elemento facoltativo processors
contiene un insieme di istruzioni di elaborazione, ciascuna
identificato da un PROCESSOR_ID. Un processore descrive come manipolare
informazioni raccolte da un ricevente.
Ogni processore deve avere un identificatore univoco e includere un elemento type
. La
tipi validi sono:
parse_json
: analizza i log strutturati in formato JSON.parse_multiline
: analizza i log multilinea. (Solo Linux)parse_regex
: analizza i log in formato testo tramite pattern regex per convertirli in Log strutturati 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 processors
è simile alla seguente:
processors: PROCESSOR_ID: type: parse_json ... PROCESSOR_ID_2: type: parse_regex ...
A seconda del valore dell'elemento type
, ci sono altri
di configurazione di rete, come mostrato di seguito.
Processore parse_json
Struttura della 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 tramite l'impostazione
alcuni 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
del risultatoLogEntry
per poi rimuoverlo dal payload.Se l'opzione
time_key
è specificata, devi specificare anche il campo seguenti:time_format
: obbligatorio se si utilizzatime_key
. Questa opzione specifica il formato del campotime_key
in modo che possa essere riconosciuti e analizzati correttamente. Per i dettagli sul formato, vedi ilstrptime(3)
guida.
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 della configurazione
processors:
PROCESSOR_ID:
type: parse_multiline
match_any:
- type: <type of the exceptions>
language: <language name>
match_any
: campo obbligatorio. Un elenco di una o più regole.type
: campo obbligatorio. È supportato un solo valore:language_exceptions
: consente al processore di concatenare le eccezioni in un'unicaLogEntry
, in base al valore dell'opzionelanguage
.
language
: campo obbligatorio. È supportato un solo valore:java
: Concatena le eccezioni Java comuni in un'unica istanzaLogEntry
.python
: Concatena le eccezioni comuni di Python in un'unica istanzaLogEntry
.go
: concatena le eccezioni comuni di Go in un'unica istanzaLogEntry
.
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]
Se utilizzi la configurazione precedente e hai un file di log con le seguenti contenuti:
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 i 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 della 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
del risultatoLogEntry
per poi rimuoverlo dal payload.Se l'opzione
time_key
è specificata, devi specificare anche il campo seguenti:time_format
: obbligatorio se si utilizzatime_key
. Questa opzione specifica il formato del campotime_key
in modo che possa essere riconosciuti e analizzati correttamente. Per i dettagli sul formato, vedi ilstrptime(3)
guida.
regex
: campo obbligatorio. L'espressione regolare per l'analisi del campo. La 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 della sezione Campo
jsonPayload
diLogEntry
. Per aggiungere una struttura aggiuntiva ai log, utilizzare il processoremodify_fields
.Per un insieme di espressioni regolari al fine di estrarre informazioni dai I file di log delle applicazioni Linux, consulta File di log comuni di Linux.
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
: campo obbligatorio. Un elenco di una o più regole. Se una voce di log corrisponde a una regola, Ops Agent non importa tale voce.I log importati da Ops Agent seguono le Struttura di
LogEntry
. I nomi dei campi sono sensibili alle maiuscole. Puoi specificare solo le regole basate seguenti campi e i relativi campi secondari: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 a livello di
DEBUG
eINFO
.Le regole seguono la query Cloud Logging lingua, ma solo supporta un sottoinsieme delle caratteristiche per le query di Logging lingue supportate:
- 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"'
Processore modify_fields
Il processore modify_fields
consente la personalizzazione della struttura e
dei contenuti delle voci di log.
Struttura della 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 dei corrispondenti
le traduzioni. Per ogni campo di output, 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 la query di Cloud Logging lingua.
Tutte le trasformazioni vengono applicate in parallelo, il che significa che origini e i filtri operano sulla voce di log di input originale e pertanto non possono fare riferimento il nuovo valore di qualsiasi altro campo modificato 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 nella destinazione verrà modificato.
move_from: <source field>
Il valore di
<source field>
verrà utilizzato come origine per campo destinazione. Inoltre, l'elemento<source field>
verrà rimosso da la voce di log. Se a un campo di origine fanno riferimento siamove_from
checopy_from
, il campo di origine continuerà a essere rimosso.copy_from: <source field>
Il valore di
<source field>
verrà utilizzato come origine per campo destinazione.<source field>
non verrà rimosso dal log a meno che non vi faccia riferimento anche da un'operazionemove_from
o modificato in altro modo.static_value: <string>
La stringa statica
<string>
verrà utilizzata come origine per campo destinazione.
Opzioni di mutazione: a un evento possono essere applicati zero o più operatori di mutazione in un singolo campo. Se vengono forniti più operatori, questi verranno sempre applicati nel seguente ordine.
default_value: <string>
Se il campo di origine non esiste, il valore di output verrà impostato su
<string>
. Se il campo di origine esiste già (anche se contiene un stringa vuota), il valore originale rimane invariato.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 dalla mappa.map_values_exclusive: {true|false}
Nel caso in cui il valore
<source field>
non corrisponda a nessuna chiave specificata nelmap_values
coppie, l'impostazione del campo di destinazione verrà annullata forzatamente semap_values_exclusive
è vero o non viene toccato semap_values_exclusive
è false.type: {integer|float}
Il valore di input verrà convertito in un numero intero o in un numero in virgola mobile. Se la stringa non può essere convertita in un numero, il valore di output verrà annullato. Se la stringa contiene un numero in virgola mobile ma il tipo è specificato come
integer
, il numero verrà troncato a un numero intero.Tieni presente che l'API Cloud Logging utilizza JSON, pertanto non supportare un numero intero a 64 bit; se un numero intero a 64 bit (o superiore) è necessario, 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à non impostato. 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 ha un aspetto simile a questo:
{
"jsonPayload": {
"http_status": "400",
"path": "/index.html",
"referer": "-"
}
}
Questo potrebbe quindi essere trasformato con modify_fields
in questo LogEntry
:
{
"httpRequest": {
"status": 400,
"requestUrl": "/index.html",
}
}
utilizzando questa configurazione 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 = "-"
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 per i log di Ops Agent.
collega i ricevitori e i processori di logging nelle pipeline. service
contiene i seguenti elementi:
log_level
pipelines
Registra livello di dettaglio
Il campo log_level
, disponibile con Ops Agent 2.6.0 e versioni successive,
personalizza il livello di dettaglio per i log del sottomodulo di logging di Ops Agent. Il valore predefinito
è info
. Le opzioni disponibili sono: error
, warn
, info
, debug
e trace
.
La configurazione seguente personalizza la livello di dettaglio dei log per il sottomodulo di logging
in debug
:
logging:
service:
log_level: debug
Logging delle pipeline
Il campo pipelines
può contenere più ID pipeline e definizioni. Ciascuna
Il valore pipeline
è costituito dai seguenti elementi:
receivers
: obbligatorio per le nuove pipeline. Un elenco di gli ID ricevitore, come descritto in Destinatari di Logging. L'ordine degli ID dei destinatari nell'elenco non è importante. La pipeline raccoglie 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 è importante. Ogni record viene eseguito attraverso i processori nell'ordine indicato.
Esempi di configurazioni di service
di logging
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 /var/log/message
o
/var/log/syslog
, ridefinire la pipeline predefinita con
un elenco receivers
vuoto e nessun processore. Questa configurazione non
interrompere il sottocomponente di logging dell'agente, poiché l'agente deve essere in grado di
per raccogliere i log per il sottocomponente Monitoring. L'intero logging vuoto
sarà simile alla seguente:
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
descritti in precedenza:
receivers
: un elenco di definizioni di destinatari. Unreceiver
descrive l'origine delle metriche; ad esempio metriche di sistema comecpu
omemory
. I destinatari in 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 dipipeline
le tue definizioni. Unpipeline
collega un elenco direceivers
e un elenco diprocessors
per formare il flusso di dati.
Ciascuno di questi elementi viene descritto nelle sezioni seguenti.
Ops Agent invia le metriche a Cloud Monitoring. Non puoi configurare per esportare le metriche in altri servizi.
Destinatari delle metriche
L'elemento receivers
contiene un insieme di definizioni di destinatari. Un destinatario
descrive da dove recuperare le metriche, ad esempio cpu
e memory
.
Un ricevitore può essere condiviso tra più pipeline.
Struttura dei ricevitori delle metriche
Ogni destinatario deve avere un identificatore, RECEIVER_ID e includere un type
. I tipi integrati validi sono:
hostmetrics
iis
(solo Windows)mssql
(solo Windows)
Un destinatario può anche specificare l'opzione collection_interval
per l'operazione. La
è 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 su le metriche specifiche incluse, consulta Metriche importate dai destinatari.
Puoi creare un solo ricevitore per ogni tipo. Ad esempio, non puoi
definisci due ricevitori di tipo hostmetrics
.
Modifica dell'intervallo di raccolta nei destinatari delle metriche
Alcuni carichi di lavoro critici potrebbero richiedere avvisi rapidi. Riduce il valore l'intervallo di raccolta delle metriche, puoi configurare avvisi. Per informazioni su come vengono valutati gli avvisi, consulta Comportamento dei criteri di avviso basati su metriche.
Ad esempio, il seguente destinatario modifica l'intervallo di raccolta per l'host
(l'ID destinatario è 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 l'elemento iis
di Windows
e mssql
di metriche che usano la stessa tecnica.
Metriche importate dai destinatari
Le metriche importate da Ops Agent hanno identificatori che iniziano con
il seguente pattern: agent.googleapis.com/GROUP
.
Il componente GROUP identifica un insieme di metriche correlate. questo elemento
ha valori come cpu
, network
e altri.
Il destinatario hostmetrics
Il ricevitore hostmetrics
importa i seguenti gruppi di metriche. Per
ulteriori informazioni, consulta la sezione collegata per ciascun gruppo
pagina Metriche di Ops Agent.
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 CPU, con etichette per numero di CPU e stato della CPU Percentuale di utilizzo della CPU, con etichette per il numero di CPU e lo stato della CPU |
disk
|
Byte del disco letti, con etichetta per il dispositivo Byte del disco scritti, con etichetta per il dispositivo Tempo I/O disco, con etichetta per il dispositivo Tempo di I/O ponderato su disco, con etichetta per il dispositivo Operazioni su disco in attesa, con etichetta per dispositivo Operazioni unite tra dischi, con etichette per dispositivo e direzione Operazioni su disco, con etichette per dispositivo e direzione Tempo di funzionamento del disco, con etichette per dispositivo e direzione Utilizzo del disco, con etichette per dispositivo e stato Utilizzo disco, con etichette per dispositivo e stato |
gpu Solo Linux; vedi Informazioni sulle gpu metriche per altre importanti
informazioni.
|
Numero attuale di byte di memoria GPU utilizzati, per stato Quantità massima di memoria GPU, in byte, che è stata allocata dal elaborazione Percentuale di tempo nel ciclo di vita del processo che uno o più kernel sia in esecuzione sulla GPU Percentuale di tempo dopo l'ultimo campione, la GPU è stata attiva |
interface Solo Linux |
Conteggio totale degli errori di rete Conteggio totale dei pacchetti inviati sulla rete Numero totale di byte inviati tramite la rete |
memory
|
Memoria utilizzata, con etichetta per lo stato (buffered, cache, free, slab, used) Percentuale di memoria utilizzata, con etichetta per lo stato (buffered, cache, free, slab, used) |
network
|
Conteggio connessioni TCP, con etichette per porta e stato TCP |
swap
|
Inverti le operazioni di I/O, con l'etichetta per la direzione Inverti i byte utilizzati, con le etichette per dispositivo e stato Percentuale di scambio utilizzata, con etichette per dispositivo e stato |
pagefile Solo Windows |
Percentuale attuale di file di paging utilizzata per stato |
processes
|
Conteggio dei processi, con etichetta per lo stato Conteggio dei processi creati con fork I/O di lettura del disco per processo, con etichette per il nome del processo e altri I/O di scrittura sul disco per processo, con etichette per il nome del processo e altri Utilizzo RSS per processo, con etichette per il nome del processo e altri Utilizzo delle VM per processo, con etichette per il nome del processo e altre |
Il ricevitore iis
(solo Windows)
Il ricevitore iis
(solo Windows) importa le metriche del gruppo iis
.
Per ulteriori informazioni, consulta
Pagina Metriche degli agenti.
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) importa le metriche del gruppo mssql
. Per
ulteriori informazioni, consulta
pagina Metriche di Ops Agent.
Gruppo | Metrica |
---|---|
mssql Solo Windows |
Connessioni attualmente aperte a SQL Server Transazioni totali di SQL Server al secondo Transazioni di scrittura SQL Server al secondo |
Processori delle metriche
L'elemento processor
contiene un insieme di definizioni del processore. Un processore
descrive le metriche del tipo di destinatario da escludere. L'unico tipo supportato
è exclude_metrics
, che richiede un'opzione metrics_pattern
. Il valore è
un elenco di glob corrispondenti ai tipi di metriche Ops Agent
da escludere dal gruppo raccolto da un destinatario. Ad esempio:
- Per escludere tutte le metriche CPU dell'agente,
specificare
agent.googleapis.com/cpu/*
. - Per escludere la metrica di utilizzo della CPU dell'agente, specifica
agent.googleapis.com/cpu/utilization
. - Per escludere la metrica del numero di richieste lato client dalle metriche
raccolte dalla terza parte di Apache Cassandra
integrazione, specifica
workloads.googleapis.com/cassandra.client.request.count
. - Per escludere tutte le metriche lato client dalle metriche
raccolte dalla terza parte di Apache Cassandra
integrazione, specifica
workloads.googleapis.com/cassandra.client.*
.
Processore metriche di esempio
L'esempio seguente mostra il processore exclude_metrics
fornito in
le configurazioni integrate. Questo processore fornisce un campo metrics_pattern
vuoto
senza escludere alcuna metrica.
processors:
metrics_filter:
type: exclude_metrics
metrics_pattern: []
Per disabilitare la raccolta di tutte le metriche di processo da parte di Ops Agent,
aggiungi quanto segue al tuo file config.yaml
:
metrics: processors: metrics_filter: type: exclude_metrics metrics_pattern: - agent.googleapis.com/processes/*
In questo modo le metriche di processo vengono escluse dalla raccolta in metrics_filter
di elaborazione applicabile alla pipeline predefinita nel servizio metrics
.
Servizio metriche
Il servizio metriche personalizza il livello di dettaglio per il modulo delle metriche di Ops Agent
e collega i ricevitori e i processori delle metriche nelle pipeline. La
La sezione service
contiene due elementi: log_level
e pipelines
.
Livello di dettaglio metriche
log_level
, disponibile con Ops Agent 2.6.0 e versioni successive, personalizza
livello di dettaglio per i log del sottomodulo delle metriche di Ops Agent. Il valore predefinito è info
.
Le opzioni disponibili sono: error
, warn
, info
e debug
.
Pipeline delle metriche
La sezione service
ha un singolo elemento, pipelines
, che può contenere
più ID pipeline e definizioni. Ogni pipeline
è costituita dai seguenti elementi:
receivers
: obbligatorio per le nuove pipeline. Un elenco di ID destinatario, come descritto in Ricevitori delle metriche. L'ordine degli ID riceventi nell'elenco non importa. La pipeline raccoglie i dati da tutti destinatari elencati.processors
: facoltativo. Un elenco di ID processore, come descritto in Processori di metriche. L'ordine degli ID processore nell'elenco è importante. Ogni punto della metrica viene eseguito attraverso i processori nell'ordine elencato.
Configurazioni di metriche di esempio 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 il valore predefinito
con un elenco receivers
vuoto e senza processori. Le metriche complete
sarà simile alla 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 le metriche
come debug
:
metrics:
service:
log_level: debug
Raccolta di autolog
Per impostazione predefinita, i log automatici dei bit fluidi di Ops Agent vengono inviati a Cloud Logging. Questi log possono includere molte informazioni e il volume aggiuntivo aumenta i costi per l'utilizzo di Cloud Logging.
Puoi disabilitare la raccolta di questi autolog, a partire da Ops Agent
alla versione 2.44.0, utilizzando
Opzione default_self_log_file_collection
.
Per disattivare la raccolta di autolog, aggiungi una sezione global
al file specificato dall'utente
di configurazione del file di configurazione e imposta l'opzione default_self_log_file_collection
al valore false
:
logging: ... metrics: ... global: default_self_log_file_collection: false
Configurazione della rotazione log
A partire da Ops Agent versione 2.31.0, puoi anche configurare la funzionalità di rotazione log dell'agente utilizzando il metodo di configurazione dei deployment. Per ulteriori informazioni, consulta Configurare la rotazione dei log in Ops Agent.