Configurazione dell'agente operativo

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Questo documento fornisce dettagli sulle configurazioni predefinite e personalizzate dell'agente Ops. Leggi questo documento se soddisfi i seguenti requisiti:

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

  • Ti interessano i dettagli tecnici sulla configurazione dell'agente operativo.

L'agente Ops fornisce anche istruzioni di configurazione per raccogliere metriche e log dalle applicazioni di terze parti supportate. Consulta l'elenco delle applicazioni supportate per monitorare le applicazioni di terze parti.

Modello di configurazione

L'agente operativo utilizza una configurazione predefinita integrata; non puoi modificare direttamente questa configurazione integrata. Crea invece un file di sostituzioni che vengono unite alla configurazione integrata quando l'agente viene riavviato.

Gli elementi fondamentali della configurazione sono i seguenti:

  • receivers: questo elemento descrive ciò che viene raccolto dall'agente.
  • processors: questo elemento descrive il modo in cui l'agente può modificare le informazioni raccolte.
  • service: questo elemento collega i ricevitori e i processori per creare flussi di dati, denominati pipeline. L'elemento service contiene un elemento pipelines, 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 l'agente Ops definisce la raccolta predefinita per i log e le metriche. Di seguito è riportata la configurazione integrata per Linux e Windows:

Linux

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

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

logging:
  receivers:
    syslog:
      type: files
      include_paths:
      - /var/log/messages
      - /var/log/syslog
  service:
    pipelines:
      default_pipeline:
        receivers: [syslog]
metrics:
  receivers:
    hostmetrics:
      type: hostmetrics
      collection_interval: 60s
  processors:
    metrics_filter:
      type: exclude_metrics
      metrics_pattern: []
  service:
    pipelines:
      default_pipeline:
        receivers: [hostmetrics]
        processors: [metrics_filter]

Windows

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

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

logging:
  receivers:
    windows_event_log:
      type: windows_event_log
      channels: [System, Application, Security]
  service:
    pipelines:
      default_pipeline:
        receivers: [windows_event_log]
metrics:
  receivers:
    hostmetrics:
      type: hostmetrics
      collection_interval: 60s
    iis:
      type: iis
      collection_interval: 60s
    mssql:
      type: mssql
      collection_interval: 60s
  processors:
    metrics_filter:
      type: exclude_metrics
      metrics_pattern: []
  service:
    pipelines:
      default_pipeline:
        receivers: [hostmetrics, iis, mssql]
        processors: [metrics_filter]

Queste configurazioni sono descritte in maggiore dettaglio in Configurazione di logging e Configurazione di 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 tua configurazione per l'agente Ops nei file seguenti:

  • 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 sostituire un ricevitore, un processore o una pipeline integrati, ridefiniscili nel file config.yaml dichiarandoli 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 destinatario delle metriche denominato 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, consulta Configurazione dei log e Configurazione delle metriche.

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

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 sono mappati in un modello <timestamp, record>.
  • processors: questo elemento facoltativo descrive il modo in cui l'agente può modificare le informazioni raccolte.
  • service: questo elemento collega i ricevitori e i processori per creare flussi di dati, denominati pipeline. L'elemento service contiene un elemento pipelines, che può includere più definizioni della pipeline.

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

Le sezioni seguenti descrivono ciascuno di questi elementi.

Logging ricevitori

L'elemento receivers contiene un insieme di ricevitori, ciascuno identificato da un RECEIVER_ID. Un destinatario descrive come recuperare i log; ad esempio, mediante l' coda dei file, l'utilizzo di 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 inserendo i file in coda su disco.
  • fluent_forward (disponibile con la versione 2.12.0 e versioni successive dell'agente Ops): raccogli i log inviati tramite il protocollo Fluent Forward su TCP.
  • syslog: raccogli i log di sistema tramite TCP o UDP.
  • tcp (disponibile con la versione 2.3.0 o versioni successive dell'agente Ops): raccogli i log in formato JSON ascoltando una porta TCP.
  • windows_event_log (solo Windows): consente di raccogliere i log eventi di Windows.
  • systemd_journald (disponibile con la versione 2.4.0 e successive dell'agente Ops su Linux): raccogli i log dal servizio journald dal sistema.
  • Ricevitori di log di applicazioni di terze parti

La struttura di receivers è simile alla seguente:

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

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

  • files destinatari:

    • include_paths: obbligatorio. Un elenco di percorsi di filesystem da leggere aggiungendo ogni file. È possibile utilizzare un carattere jolly (*) nei percorsi, ad esempio /var/log/*.log (Linux) o C:\logs\*.log (Windows).

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

    • exclude_paths: facoltativo. Un elenco di pattern di percorsi del file system da escludere dal set corrispondente a include_paths.

    • record_log_file_path: facoltativo. Se è impostato su true, il percorso del file specifico da cui è stato ottenuto il record di log viene visualizzato nella voce di log di output come valore dell'etichetta agent.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 di aggiornamento dei percorsi dei file con caratteri jolly in include_paths. Dato come durata, ad esempio 30s, 2m. Questa proprietà potrebbe essere utile in velocità effettiva di logging elevata in cui i file di log vengono ruotati più velocemente dell'intervallo predefinito. Se non specificato, l'intervallo predefinito è 60 secondi.

  • fluent_forward destinatari:

    • listen_host: facoltativo. Un indirizzo IP su cui rimanere in ascolto. Il valore predefinito è 127.0.0.1.

    • listen_port: facoltativo. Una porta su cui rimanere in ascolto. Il valore predefinito è 24224.

  • syslog destinatari:

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

    • listen_host: facoltativo. Un indirizzo IP su cui rimanere in ascolto. Il valore predefinito è 0.0.0.0.

    • listen_port: facoltativo. Una porta su cui rimanere in ascolto. Il valore predefinito è 5140.

  • tcp destinatari:

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

    • listen_host: facoltativo. Un indirizzo IP su cui rimanere in ascolto. Il valore predefinito è 127.0.0.1.

    • listen_port: facoltativo. Una porta su cui rimanere in ascolto. Il valore predefinito è 5170.

  • windows_event_log ricevitori (solo per Windows):

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

Esempi di ricevitori Logging

Esempio di destinatario 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 destinatario fluent_forward:

receivers:
  RECEIVER_ID:
    type: fluent_forward

    listen_host: 127.0.0.1
    listen_port: 24224

Esempio di destinatario syslog:

receivers:
  RECEIVER_ID:
    type: syslog

    transport_protocol: tcp
    listen_host: 0.0.0.0
    listen_port: 5140

Esempio di destinatario 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 destinatario 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 l'agente operativo riceve i dati di log strutturati esterni, i campi di primo livello vengono inseriti nel campo jsonPayload di LogEntry, a meno che il nome del campo non venga elencato nella tabella seguente:

Campo di registrazione Campo LogEntry

Opzione 1



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

Opzione 2



{
  "timestampSeconds": CURRENT_SECONDS,
  "timestampNanos": CURRENT_NANOS,
}
 timestamp
receive_id (non un campo di registrazione) logName
logging.googleapis.com/httpRequest([stringa](/logging/docs/reference/v2/rest/v2/LogEntry#httprequest)) httpRequest
logging.googleapis.com/severity ([stringa](/logging/docs/reference/v2/rest/v2/LogEntry#logentrysourcelocation)) severity
logging.googleapis.com/labels (struttura di string:string) labels
logging.googleapis.com/operation ([struttura](/logging/docs/reference/v2/rest/v2/LogEntry#logentryoperation)) operation
logging.googleapis.com/sourceLocation ([struttura](/logging/docs/reference/v2/rest/v2/LogEntry#logentrysourcelocation)) sourceLocation

Tutti i campi dei record strutturati rimanenti restano parte della struttura jsonPayload.

File di log comuni di Linux

Nella seguente tabella sono elencati i file di log comuni delle applicazioni Linux di uso frequente:

Applicazione File di log comuni
Apache Per informazioni sui file di log Apache, consulta Monitoraggio delle applicazioni di terze parti: Apache Web Server.
cassandra Per informazioni sui file di log di Cassandra, consulta Monitoraggio delle applicazioni di terze parti: Cassandra.
chef /var/log/chef-server/bookshelf/current
/var/log/chef-server/chef-expander/current
/var/log/chef-server/chef-pedant/http-traffic.log
/var/log/chef-server/chef-server-webui/current
/var/log/chef-server/chef-solr/current
/var/log/chef-server/erchef/current
/var/log/chef-server/erchef/erchef.log.1
/var/log/chef-server/nginx/access.log
/var/log/chef-server/nginx/error.log
/var/log/chef-server/nginx/rewrite-port-80.log
/var/log/chef-server/postgresql/current
Gitlab /home/git/gitlab/log/application.log
/home/git/gitlab/log/githost.log
/home/git/gitlab/log/production.log
/home/git/gitlab/log/satellites.log
/home/git/gitlab/log/sidekiq.log
/home/git/gitlab/log/unicorn.stderr.log
/home/git/gitlab/log/unicorn.stdout.log
/home/git/gitlab-shell/gitlab-shell.log
jenkins /var/log/jenkins/jenkins.log
molo /var/log/jetty/out.log
/var/log/jetty/*.request.log
/var/log/jetty/*.stderrout.log
Joomla /var/www/joomla/logs/*.log
Magento /var/www/magento/var/log/exception.log
/var/www/magento/var/log/system.log
/var/www/magento/var/report/*
mediawiki /var/log/mediawiki/*.log
memcached Per informazioni sui file di log Memcached, consulta Monitoraggio delle applicazioni di terze parti: Memcached.
mongodb Per informazioni sui file di log MongoDB, consulta Monitoraggio delle applicazioni di terze parti: MongoDB.
mysql Per informazioni sui file di log di MySQL, consulta Monitoraggio delle 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 Monitoraggio delle applicazioni di terze parti: PostgreSQL.
marionette /var/log/puppet/http.log
/var/log/puppet/masterhttp.log
impresa-burattino /var/log/pe-activemq/activemq.log
/var/log/pe-activemq/wrapper.log
/var/log/pe-console-auth/auth.log
/var/log/pe-console-auth/cas_client.log
/var/log/pe-console-auth/cas.log
/var/log/pe-httpd/access.log
/var/log/pe-httpd/error.log
/var/log/pe-httpd/other_vhosts_access.log
/var/log/pe-httpd/puppetdashboard.access.log
/var/log/pe-httpd/puppetdashboard.error.log
/var/log/pe-httpd/puppetmasteraccess.log
/var/log/pe-mcollective/mcollective_audit.log
/var/log/pe-mcollective/mcollective.log
/var/log/pe-puppet-dashboard/certificate_manager.log
/var/log/pe-puppet-dashboard/event-inspector.log
/var/log/pe-puppet-dashboard/failed_reports.log
/var/log/pe-puppet-dashboard/live-management.log
/var/log/pe-puppet-dashboard/mcollective_client.log
/var/log/pe-puppet-dashboard/production.log
/var/log/pe-puppetdb/pe-puppetdb.log
/var/log/pe-puppet/masterhttp.log
/var/log/pe-puppet/rails.log
Rabbitmq Per informazioni sui file di log RabbitMQ, consulta Monitoraggio delle applicazioni di terze parti: RabbitMQ.
redis Per informazioni sui file di log Redis, consulta Monitoraggio delle applicazioni di terze parti: Redis.
Redmine /var/log/redmine/*.log
sale /var/log/salt/key
/var/log/salt/master
/var/log/salt/minion
/var/log/salt/syndic.loc
solr Per informazioni sui file di log di Apache Solr, consulta Monitoraggio delle applicazioni di terze parti: Apache Solr.
zuccheroma /var/www/*/sugarcrm.log
syslog /var/log/syslog
/var/log/messages
Tomcat Per informazioni sui file di log di Apache Tomcat, consulta la pagina Monitoraggio delle applicazioni di terze parti: Apache Tomcat.
custode dello 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 destinatario 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 identificata da un PROCESSOR_ID. Un processore descrive come manipolare le informazioni raccolte da un destinatario.

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 multilinea. (Solo Linux)
  • parse_regex: analizza i log in formato di testo tramite pattern regex per trasformarli in log strutturati in formato JSON.
  • exclude_logs: escludi i log che corrispondono a regole specificate (a partire dalla 2.9.0).
  • modify_fields: imposta/trasforma i campi nelle voci di log (a partire dalla 2.14.0).

La struttura di processors è simile alla seguente:

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

A seconda del valore dell'elemento type, esistono altre opzioni di configurazione, come mostrato di seguito.

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 del LogEntry possono essere analizzate impostando alcuni campi di primo livello speciali.

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

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

    • time_format: elemento obbligatorio se viene utilizzato time_key. Questa opzione specifica il formato del campo time_key in modo che possa essere riconosciuto e analizzato correttamente. Per i dettagli del formato, consulta la guida strptime(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 LogEntry, in base al valore dell'opzione language.

    • language: obbligatorio. È supportato un solo valore:

      • java: concatena le eccezioni Java comuni in un LogEntry.
      • python: concatena le eccezioni Python comuni in un LogEntry.
      • go: concatena le eccezioni di Go più comuni in una LogEntry.
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:
        jsonPayload."logging.googleapis.com/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 il seguente contenuto:

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

quindi 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 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 di quel campo. Il valore estratto viene utilizzato per impostare il campo timestamp dell'istruzione LogEntry risultante e viene rimosso dal payload.

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

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

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

    Il testo corrispondente ai gruppi Capture acquisiti verrà inserito nei campi del campo jsonPayload di LogEntry. Per aggiungere ulteriore struttura ai log, utilizza il processore modify_fields.

    Per un insieme di espressioni regolari per l'estrazione di informazioni dai file di log comuni dell'applicazione 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 di 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'agente operativo non la importa.

    I log importati dall'agente Ops seguono la struttura di 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

    La seguente regola di esempio

    severity =~ "(DEBUG|INFO)"

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

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

    • Operatori di confronto: =, !=, :, =~ e !~. Sono supportati solo i confronti tra stringhe.
    • Operatore di navigazione: .. Ad esempio: jsonPayload.message.
    • Operatori booleani: AND, OR, NOT.
    • Raggruppa le 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 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 di 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 nessuna o più operazioni di modifica.

Tutti i nomi dei campi utilizzano la sintassi separata dai punti dal linguaggio delle query di Cloud Logging. I filtri utilizzano il linguaggio delle 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 eventuali altri campi modificati dallo stesso processore.

Opzioni di origine: è consentita al massimo un'origine specificata.

  • Nessuna origine specificata

    Se non viene specificato un valore di origine, verrà modificato il valore esistente nel campo di destinazione.

  • 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 un campo di origine fa riferimento sia a move_from che a copy_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 vi sia fatto riferimento anche da un'operazione move_from o altrimenti modificato.

  • static_value: <string>

    La stringa statica <string> verrà utilizzata come origine per il campo di destinazione.

Opzioni di modifica: zero o più operatori di mutazione possono essere applicati a un singolo campo. Se vengono forniti più operatori, verranno sempre applicati nel seguente ordine.

  1. 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 una stringa vuota), il valore originale non viene modificato.

  2. map_values: <map>

    Se il valore di input corrisponde a una delle chiavi in <map>, verrà sostituito con il valore corrispondente dalla mappa.

  3. map_values_exclusive: {true|false}

    Nel caso in cui il valore <source field> non corrisponda a nessuna chiave specificata nelle coppie map_values, il campo di destinazione verrà forzato non impostato se map_values_exclusive è vero o non viene toccato se map_values_exclusive è falso.

  4. type: {integer|float}

    Il valore di input verrà convertito in un numero intero o in virgola mobile. Se non è possibile convertire la stringa 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 e pertanto non supporta un numero intero completo a 64 bit. Se è necessario un numero intero a 64 bit (o superiore), deve essere archiviato come stringa nella voce di log.

  5. omit_if: <filter>

    Se il filtro corrisponde al record del 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 simile alla seguente:

{
  "jsonPayload": {
    "http_status": "400",
    "path": "/index.html",
    "referer": "-"
  }
}

Questo potrebbe essere quindi trasformato con modify_fields in questo LogEntry:

{
  "httpRequest": {
    "status": 400,
    "requestUrl": "/index.html",
  }
}

con questa configurazione dell'agente Ops:

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 completa parte della struttura httpRequest dai campi dei log.

Servizio di logging

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

Livello di dettaglio dei log

log_level, disponibile con la versione 2.6.0 e le versioni successive dell'agente Ops, personalizza il livello di dettaglio per i log del modulo secondario di logging dell'agente Ops. Il valore predefinito è info. Le opzioni disponibili sono: error, warn, info, debug e trace.

La seguente configurazione personalizza invece il livello di dettaglio dei log per il modulo secondario di logging debug:

logging:
  service:
    log_level: debug

Pipeline di logging

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

  • receivers: obbligatorio per le nuove pipeline. Un elenco degli ID ricevitore, come descritto nella sezione Ricezione dei log. L'ordine degli ID ricevitori nell'elenco non è importante. La pipeline raccoglie i dati da tutti i ricevitori elencati.

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

Esempio di configurazione di service 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 le voci /var/log/message o /var/log/syslog, ridefinisci la pipeline predefinita con un elenco receivers vuoto e senza processori. Questa configurazione non arresta il sottocomponente di logging dell'agente, poiché l'agente deve essere in grado di raccogliere i log per il sottocomponente di monitoraggio. L'intera configurazione di logging vuota ha il seguente aspetto:

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

La seguente configurazione service definisce una pipeline con 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: elenco di definizioni dei destinatari. receiver descrive l'origine delle metriche, ad esempio metriche di sistema come cpu o memory. I destinatari in questo elenco possono essere condivisi tra più pipeline.
  • processors: un elenco di definizioni di processori. Un processor descrive come modificare le metriche raccolte da un destinatario.
  • service: contiene una sezione pipelines che è un elenco di pipelinedefinizioni. pipeline collega un elenco di receivers e un elenco di processors per formare il flusso di dati.

Le sezioni seguenti descrivono ciascuno di questi elementi.

Destinatari e 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 destinatario può essere condiviso tra più pipeline.

Struttura dei destinatari 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. 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 la sezione Metriche importate dai tipi di ricevitore.

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

Modifica dell'intervallo di raccolta nei destinatari delle metriche

Alcuni carichi di lavoro critici potrebbero richiedere avvisi rapidi. Riducendo 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 destinatario modifica l'intervallo di raccolta per le metriche dell'host (l'ID destinatario è hostmetrics) dal valore predefinito di 60 secondi a 10 secondi:

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

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

Metriche importate dai destinatari

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

Il destinatario hostmetrics importa i seguenti gruppi di metriche. Per saperne di più, consulta la sezione collegata a ciascun gruppo nella pagina Metriche agente operativo.

Gruppo Metrica
cpu Carico CPU a intervalli di 1 minuto
Carico CPU a intervalli di 5 minuti
Carico CPU a intervalli di 15 minuti
Utilizzo CPU, con etichette per numero CPU e stato CPU
Percentuale utilizzo CPU, con etichette per numero CPU e stato 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 sul disco, con etichetta per il dispositivo
Operazioni del disco in attesa, con etichetta per il dispositivo
Operazioni del disco unite, con etichette per il dispositivo e direzione
Operazioni del disco, con etichette per il dispositivo e la direzione
Tempo di funzionamento del disco, con etichette per il dispositivo e la direzione
Utilizzo del disco, con etichette per il dispositivo e lo stato
interface
Solo Linux 		Conteggio totale degli errori di rete
Conteggio totale dei pacchetti inviati sulla rete
Numero totale di byte inviati attraverso la rete
memory Utilizzo della memoria, con etichetta per lo stato (buffered, cache, free, slab, utilizzato)
Percentuale di utilizzo della memoria, con etichetta per lo stato (buffered, cache, free, slab, used)
network Conteggio connessioni TCP, con etichette per porta e stato TCP
swap Scambia le operazioni di I/O, con 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 corrente di file di pagina utilizzata dallo stato
processes Conteggio processi, con etichetta per lo stato
Conteggio fork dei processi
I/O del disco per processo, con etichette per il nome del processo e altri
I/O per scrittura del disco per processo, con etichette per il nome del processo e altri
Utilizzo RSS per processo, con etichette per il nome del processo + altri
Utilizzo della VM per processo, con etichette per il nome del processo e altri

Il ricevitore iis (solo Windows) importa le metriche del gruppo iis. Per ulteriori informazioni, consulta la pagina Metriche 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 destinatario mssql (solo Windows) importa le metriche del gruppo mssql. Per ulteriori informazioni, consulta la pagina Metriche dell'agente Ops.

Gruppo Metrica
mssql
Solo Windows 		Connessioni attualmente aperte a SQL Server
Transazioni totali in SQL Server al secondo
Transazioni di scrittura in SQL Server al secondo

Processori delle metriche

L'elemento processor contiene un insieme di definizioni di processori. Un processore descrive le metriche del tipo di destinatario da escludere. L'unico tipo supportato è exclude_metrics, che utilizza un'opzione metrics_pattern. Il valore è un elenco di globi che corrispondono ai tipi di metriche che vuoi escludere dal gruppo raccolto da un destinatario, 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 agente operativo.

Elaboratore delle metriche di esempio

L'esempio seguente mostra il processore exclude_metrics fornito nelle configurazioni integrate. Questo processore fornisce un valore metrics_pattern vuoto, perciò 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 Ops, aggiungi quanto segue al file config.yaml:

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

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

Servizio metriche

Il servizio Metrics personalizza la precisione per i log delle metriche dell'agente operativo e collega i ricevitori e i processori delle metriche alle pipeline. La sezione service ha due elementi: log_level e pipelines.

Livello di dettaglio delle metriche

log_level, disponibile con la versione 2.6.0 e le versioni successive dell'agente Ops, personalizza il livello di dettaglio per i log del sottomodulo delle metriche dell'agente Ops. 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 di pipeline è costituita dai seguenti elementi:

  • receivers: obbligatorio per le nuove pipeline. Un elenco degli ID destinatari, come descritto nella sezione Destinatari delle metriche. L'ordine degli ID ricevitori nell'elenco non è importante. La pipeline raccoglie i dati da tutti i ricevitori elencati.

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

Esempi di configurazioni di service metriche

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 senza processori. L'intera configurazione delle metriche ha il seguente aspetto:

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 service personalizza invece il livello di dettaglio dei log per il sottomodulo Metriche: debug:

metrics:
  service:
    log_level: debug