Ops-Agent konfigurieren

Dieses Dokument enthält Details zu den standardmäßigen und benutzerdefinierten Konfigurationen des Ops-Agents. Lesen Sie dieses Dokument, wenn einer der folgenden Punkte auf Sie zutrifft:

  • Sie möchten die Konfiguration des Ops-Agents ändern, um folgende Ziele zu erreichen:

    • Integrierte Aufnahme von Logging oder Messwerten deaktivieren.

    • Passen Sie den Dateipfad der Logdateien an, aus denen der Agent Logs erfasst. Siehe Logging-Empfänger.

    • Passen Sie das strukturierte Logformat an, das der Agent zum Verarbeiten der Logeinträge verwendet. Parsen Sie dazu das JSON-Format oder verwenden Sie reguläre Ausdrücke. Siehe Logging-Prozessoren.

    • Weitere Informationen zum Ändern der Sampling-Rate für Messwerte ändern finden Sie unter Messwertempfänger.

    • Legen Sie fest, welche Gruppe oder Gruppen von Messwerten aktiviert werden sollen. Der Agent erfasst standardmäßig alle Systemmesswerte, wie cpu und memory. Siehe Messwertprozessoren.

  • Sie interessieren sich für die technischen Details der Konfiguration des Ops-Agents.

Der Ops-Agent bietet auch Konfigurationsanweisungen zum Erfassen von Messwerten und Logs aus unterstützten Drittanbieteranwendungen. Eine Liste der unterstützten Anwendungen finden Sie unter Anwendungen von Drittanbietern beobachten.

Konfigurationsmodell

Der Ops-Agent verwendet eine integrierte Standardkonfiguration. Sie können diese integrierte Konfiguration nicht direkt ändern. Stattdessen erstellen Sie eine Datei mit Überschreibungen, die bei einem Neustart des Agents mit der integrierten Konfiguration zusammengeführt werden.

Die Konfiguration hat folgende Bausteine:

  • receivers: Dieses Element beschreibt, was der Agent erfasst.
  • processors: Dieses Element beschreibt, wie der Agent die erfassten Informationen ändern kann.
  • service: Dieses Element verknüpft Empfänger und Prozessoren zu Datenflüssen, die als Pipelines bezeichnet werden. Das service-Element enthält ein pipelines-Element, das mehrere Pipelines enthalten kann.

Die integrierte Konfiguration besteht aus diesen Elementen. Sie verwenden dieselben Elemente, um diese integrierte Konfiguration zu überschreiben.

Integrierte Konfiguration

Die integrierte Konfiguration für den Ops-Agent definiert die Standardsammlung für Logs und Messwerte. Im Folgenden sehen Sie die integrierte Konfiguration für Linux und Windows:

Linux

Der Ops-Agent erfasst standardmäßig dateibasierte syslog-Logs und Hostmesswerte.

Weitere Informationen zu den erfassten Messwerten finden Sie unter Von den Empfängertypen aufgenommene Messwerte.

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

Der Ops-Agent erfasst standardmäßig Windows-Ereignislogs von den Kanälen System, Application und Security sowie Hostmesswerte, IIS-Messwerte und SQL Server-Messwerte.

Weitere Informationen zu den erfassten Messwerten finden Sie unter Von den Empfängertypen aufgenommene Messwerte.

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]

Diese Konfigurationen werden in der Logging-Konfiguration und der Messwertkonfiguration ausführlicher erläutert.

Vom Nutzer angegeben Konfiguration

Wenn Sie die integrierte Konfiguration überschreiben möchten, fügen Sie der Nutzerkonfigurationsdatei neue Konfigurationselemente hinzu. Fügen Sie Ihre Konfiguration für den Ops-Agent in die folgenden Dateien ein:

  • Für Linux: /etc/google-cloud-ops-agent/config.yaml.

  • Für Windows: C:\Program Files\Google\Cloud Operations\Ops Agent\config\config.yaml.

Jede benutzerdefinierte Konfiguration wird beim Neustart des Agents mit der integrierten Konfiguration zusammengeführt.

Wenn Sie einen integrierten Empfänger, Prozessor oder Pipeline überschreiben möchten, definieren Sie sie in Ihrer config.yaml-Datei neu, indem Sie sie mit derselben Kennzeichnung deklarieren.

Die integrierte Konfiguration für Messwerte enthält beispielsweise einen hostmetrics-Empfänger, der ein Erfassungsintervall von 60 Sekunden angibt. So ändern Sie das Erfassungsintervall für Hostmesswerte in 30 Sekunden: Fügen Sie der Datei config.yaml einen Messwertempfänger mit dem Namen hostmetrics hinzu, der den Wert collection_interval auf 30 Sekunden festlegt. Beispiel:

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

Weitere Beispiele zum Ändern der integrierten Konfigurationen finden Sie unter Logging-Konfiguration und Messwertkonfiguration.

Sie können auch die Erfassung von Logging- oder Messwertdaten deaktivieren. Diese Änderungen werden in den Beispielen für Logging-service-Konfigurationen und Messwert-service-Konfigurationen beschrieben.

Logging-Konfigurationen

Die logging-Konfiguration verwendet das zuvor beschriebene Konfigurationsmodell:

  • receivers: Dieses Element beschreibt die aus Logdateien zu erfassenden Daten. Diese Daten werden einem <timestamp, record>-Modell zugeordnet.
  • processors: Dieses optionale Element beschreibt, wie der Agent die erfassten Informationen ändern kann.
  • service: Dieses Element verknüpft Empfänger und Prozessoren zu Datenflüssen, die als Pipelines bezeichnet werden. Das service-Element enthält ein pipelines-Element, das mehrere Pipelinedefinitionen enthalten kann.

Jeder Empfänger und jeder Prozessor kann in mehreren Pipelines verwendet werden.

In den folgenden Abschnitten werden die einzelnen Elemente beschrieben.

Logging-Empfänger

Das receivers-Element enthält eine Reihe von Empfängern, die jeweils durch ein RECEIVER_ID identifiziert werden. Ein Empfänger beschreibt, wie die Logs abgerufen werden, beispielsweise durch Tailing von Dateien, mithilfe eines TCP-Ports oder aus dem Windows-Ereignislog.

Struktur von Logging-Empfängern

Jeder Empfänger muss die Kennzeichnung RECEIVER_ID haben und ein type-Element enthalten. Gültige Typen:

  • files: Logs durch Tailing von Dateien auf dem Laufwerk erfassen.
  • syslog: Syslog über TCP oder UDP erfassen.
  • tcp (verfügbar mit Ops-Agent-Versionen ab 2.3.0): JSON-Formatlogs durch Überwachen eines TCP-Ports erfassen.
  • windows_event_log (nur Windows): Windows-Ereignislogs erfassen.
  • systemd_journald (verfügbar mit Ops-Agent-Versionen ab 2.4.0 unter Linux): Logs vom systemd-journald-Dienst erfassen.

Die receivers-Struktur sieht so aus:

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

Je nach Wert des Elements type gibt es möglicherweise weitere Konfigurationsoptionen:

  • files Empfänger:

    • include_paths: erforderlich. Eine Liste mit Dateisystempfaden, die durch Tailing jeder Datei gelesen werden sollen. In den Pfaden kann ein Platzhalter (*) verwendet werden. Beispiel: /var/log/*.log.

      Eine Liste gängiger Anwendungslogdateien finden Sie unter Allgemeine Logdateien.

    • exclude_paths: Optional. Eine Liste von Dateisystempfadmustern, die aus dem mit include_paths übereinstimmenden Satz ausgeschlossen werden sollen.

    • wildcard_refresh_interval: Optional. Das Intervall, in dem Platzhalterdateipfade in include_paths aktualisiert werden. Wird als Zeitdauer angegeben, z. B. 30s, 2m. Dieses Attribut kann bei hohen Logging-Durchsätzen nützlich sein, wenn Logdateien schneller als das Standardintervall rotiert werden. Wenn keine Angabe erfolgt, beträgt das Standardintervall 60 Sekunden.

  • syslog Empfänger:

    • transport_protocol: Optional. Unterstützte Werte: tcp; udp. Der Standardwert ist tcp.

      Wenn transport_protocol auf tcp gesetzt ist, können die folgenden zusätzlichen Optionen verwendet werden:

      • listen_host: Optional. Eine IP-Adresse, die überwacht werden soll. Der Standardwert ist 0.0.0.0.

      • listen_port: Optional. Ein Port, der überwacht werden soll. Der Standardwert ist 5140.

  • tcp Empfänger:

    • format: erforderlich. Logformat Unterstützter Wert: json.

    • listen_host: Optional. Eine IP-Adresse, die überwacht werden soll. Der Standardwert ist 127.0.0.1.

    • listen_port: Optional. Ein Port, der überwacht werden soll. Der Standardwert ist 5170.

  • windows_event_log-Empfänger (nur für Windows):

    • channels: erforderlich. Eine Liste der Windows-Ereignis-Log-Kanäle, aus denen Logs gelesen werden sollen.

Beispiele für Logging-Empfänger

Beispiel-files-Empfänger:

receivers:
  RECEIVER_ID:
    type: files

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

Beispiel-syslog-Empfänger:

receivers:
  RECEIVER_ID:
    type: syslog

    transport_protocol: tcp
    listen_host: 0.0.0.0
    listen_port: 5140

Beispiel-tcp-Empfänger:

receivers:
  RECEIVER_ID:
    type: tcp

    format: json
    listen_host: 127.0.0.1
    listen_port: 5170

Beispiel-windows_event_log-Empfänger (nur Windows):

receivers:
  RECEIVER_ID:
    type: windows_event_log

    channels: [System,Application,Security]

Beispiel-systemd_journald-Empfänger:

receivers:
  RECEIVER_ID:
    type: systemd_journald

Logging-Prozessoren

Das optionale Element processors enthält eine Reihe von Verarbeitungsanweisungen, die jeweils durch eine PROCESSOR_ID identifiziert werden. Ein Prozessor beschreibt, wie die von einem Empfänger erfassten Informationen bearbeitet werden.

Struktur von Logging-Prozessoren

Jeder Prozessor muss eine eindeutige Kennzeichnung haben und ein type-Element enthalten. Gültige Typen:

  • parse_json
  • parse_regex

Die processors-Struktur sieht so aus:

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

Je nach Wert des Elements type gibt es weitere Konfigurationsoptionen:

  • Sowohl parse_json- als auch parse_regex-Prozessoren:

    • field: Optional. Der Name des Feldes im Eintrag, der geparst werden soll. Wenn die Option field nicht angegeben ist, parst der Prozessor das Feld message.

    • time_key: Optional. Wenn der Logeintrag ein Feld mit einem Zeitstempel bereitstellt, gibt diese Option den Namen dieses Feldes an. Der extrahierte Wert wird zum Festlegen des Felds timestamp des resultierenden LogEntry verwendet und aus der Nutzlast entfernt.

      Wenn die Option time_key angegeben ist, müssen Sie auch Folgendes angeben:

      • time_format: Erforderlich, wenn time_key verwendet wird. Mit dieser Option wird das Format des Feldes time_key angegeben, damit es erkannt und richtig analysiert werden kann. Weitere Informationen zum Format finden Sie im Leitfaden strptime(3).
  • parse_regex Prozessoren:

    • regex: erforderlich. Der reguläre Ausdruck zum Parsen des Feldes. Der Ausdruck muss Schlüsselnamen für die übereinstimmenden Unterausdrücke enthalten, z. B. "^(?<time>[^ ]*) (?<severity>[^ ]*) (?<msg>.*)$".

      Eine Reihe regulärer Ausdrücke zum Extrahieren von Informationen aus Logdateien finden Sie unter Allgemeine Logdateien.

Beispiele für Logging-Prozessoren

Beispiel parse_json Prozessor:

processors:
  PROCESSOR_ID:
    type: parse_json

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

Beispiel parse_regex Prozessor:

processors:
  PROCESSOR_ID:
    type: parse_regex

    field:       message
    regex:       "^(?<time>[^ ]*) (?<severity>[^ ]*) (?<msg>.*)$"
    time_key:    time
    time_format: "%Y-%m-%dT%H:%M:%S.%L%Z"

Spezielle Felder in strukturierten Nutzlasten

Sie können im Objekt LogEntry bestimmte Felder festlegen, die der Agent in die Logging API schreibt. Bei strukturierten Logeinträgen entfernt der Ops-Agent die Struktur jsonPayload aus den in der folgenden Tabelle aufgeführten Feldern:

Eintragsfeld LogEntry-Feld

Option 1



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

Option 2



{
  "timestampSeconds": CURRENT_SECONDS,
  "timestampNanos": CURRENT_NANOS,
}
timestamp
receiver_id (kein Eintragsfeld) logName
logging.googleapis.com/severity severity
logging.googleapis.com/labels labels
logging.googleapis.com/operation operation
logging.googleapis.com/sourceLocation sourceLocation

Alle verbleibenden strukturierten Eintragsfelder bleiben Teil der jsonPayload-Struktur.

Logging-Dienst

Der Logging-Dienst passt die Ausführlichkeit für die eigenen Logs des Ops-Agents an und verknüpft Logging-Empfänger und -Prozessoren zu Pipelines. Der Abschnitt service enthält zwei Elemente: log_level und pipelines.

Ausführlichkeitsstufe für Logs

log_level ist ab Ops-Agent-Version 2.6.0 verfügbar und passt die Ausführlichkeit für die eigenen Logs des Logging-Submoduls des Ops-Agents an. Der Standardwert ist info. Folgende Optionen sind verfügbar: error, warn, info, debug, trace.

Logging-Pipelines

pipelines kann mehrere Pipeline-IDs und Definitionen enthalten. Jede pipeline-Definition besteht aus den folgenden Elementen:

  • receivers: Für neue Pipelines erforderlich. Eine Liste von Empfänger-IDs, wie unter Logging-Empfänger beschrieben. Die Reihenfolge der Empfänger-IDs in der Liste spielt keine Rolle. Die Pipeline erfasst Daten von allen aufgelisteten Empfängern.

  • processors: Optional. Eine Liste von Prozessor-IDs, wie unter Logging-Prozessoren beschrieben. Die Reihenfolge der Prozessor-IDs in der Liste ist wichtig. Jeder Eintrag wird von den Prozessoren in der aufgeführten Reihenfolge ausgeführt.

Beispiele für Logging-service-Konfigurationen

Eine service-Konfiguration hat die folgende Struktur:

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

Wenn Sie die integrierte Logging-Aufnahme deaktivieren möchten, definieren Sie die Standardpipeline mit einer leeren receivers-Liste ohne Prozessoren neu. Die gesamte Logging-Konfiguration sieht so aus:

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

Die folgende service-Konfiguration definiert eine Pipeline mit der ID custom_pipeline:

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

Die folgende service-Konfiguration passt die Log-Ausführlichkeit für das Logging-Untermodul stattdessen auf debug an:

logging:
  service:
    log_level: debug

Häufig verwendete Logdateien

In der folgenden Tabelle sind häufig verwendete Logdateien für häufig verwendete Anwendungen aufgeführt:

Anwendung Häufig verwendete Logdateien
apache Informationen zu Apache-Logdateien finden Sie unter Anwendungen von Drittanbietern beobachten: Apache-Webserver.
cassandra Informationen zu Cassandra-Logdateien finden Sie unter Anwendungen von Drittanbietern beobachten: 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
jetty /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 /var/log/memcached.log
mongodb /var/log/mongodb/*.log
mysql Informationen zu MySQL-Logdateien finden Sie unter Anwendungen von Drittanbietern beobachten: MySQL.
nginx Weitere Informationen zu nginx-Logdateien finden Sie unter Anwendungen von Drittanbietern überwachen: nginx.
postgres /var/log/postgres*/*.log
/var/log/pgsql/*.log
puppet /var/log/puppet/http.log
/var/log/puppet/masterhttp.log
puppet-enterprise /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 /var/log/rabbitmq/*.log
/var/log/rabbitmq/*-sasl.log
/var/log/rabbitmq/startup_err
/var/log/rabbitmq/startup_log
redis Informationen zu Redis-Logdateien finden Sie unter Anwendungen von Drittanbietern beobachten: Redis.
redmine /var/log/redmine/*.log
salt /var/log/salt/key
/var/log/salt/master
/var/log/salt/minion
/var/log/salt/syndic.loc
solr /var/log/solr/*.log
sugarcrm /var/www/*/sugarcrm.log
syslog /var/log/syslog/var/log/messages
tomcat /var/log/tomcat*/catalina.out
/var/log/tomcat*/localhost.*.log
/var/log/tomcat*/localhost_access_log.%Y-%m-%d.txt
zookeeper /var/log/zookeeper/zookeeper.log
/var/log/zookeeper/zookeeper_trace.log

In der folgenden Tabelle sind einige reguläre Ausdrücke aufgeführt, die zum Parsen von Logs nützlich sind:

Anwendung Regulärer Ausdruck
mongodb ^(?<time>[^ ]*)\s+(?<severity>\w)\s+(?<component>[^ ]+)\s+\[(?<context>[^\]]+)]\s+(?<message>.*?) *(?<ms>(\d+))?(:?ms)?$

Messwertkonfigurationen

Die metrics-Konfiguration verwendet das zuvor beschriebene Konfigurationsmodell:

  • receivers: Eine Liste der Empfängerdefinitionen. Ein receiver beschreibt die Quelle der Messwerte, beispielsweise die Systemmesswerte cpu oder memory. Die Empfänger in dieser Liste können von mehreren Pipelines gemeinsam genutzt werden.
  • processors: Eine Liste von Prozessordefinitionen. Ein processor beschreibt, wie die von einem Empfänger erfassten Messwerte geändert werden.
  • service: Enthält einen pipelines-Abschnitt, der eine Liste von pipeline-Definitionen enthält. Eine pipeline verbindet für einen Datenfluss eine Liste von receivers mit einer Liste von processors, um den Datenfluss zu bilden.

In den folgenden Abschnitten werden die einzelnen Elemente beschrieben.

Messwertempfänger

Das receivers-Element enthält eine Reihe von Empfängerdefinitionen. Ein Empfänger beschreibt, wo die Messwerte abgerufen werden, z. B. cpu und memory. Ein Empfänger kann von mehreren Pipelines gemeinsam genutzt werden.

Struktur von Messwertempfängern

Jeder Empfänger muss die Kennzeichnung RECEIVER_ID haben und ein type-Element enthalten. Gültige Typen sind:

  • hostmetrics
  • iis (Nur Windows)
  • mssql (Nur Windows)

Ein Empfänger kann auch die Option collection_interval angeben. Der Wert hat das Format einer Dauer, z .B. 30s oder 2m. Der Standardwert ist 60s.

Jeder dieser Empfängertypen erfasst eine Reihe von Messwerten. Informationen zu den jeweiligen Messwerten finden Sie unter Von den Empfängertypen aufgenommene Messwerte.

Sie können nur einen Empfänger pro Typ erstellen. Beispielsweise können Sie nicht zwei Empfänger vom Typ hostmetrics definieren.

Erfassungsintervall in den Messwertempfängern ändern

Einige kritische Arbeitslasten erfordern möglicherweise eine schnelle Benachrichtigung. Durch Reduzierung des Erfassungsintervalls für die Messwerte können Sie sensiblere Benachrichtigungen konfigurieren. Informationen zum Auswerten von Benachrichtigungen finden Sie unter Benachrichtigungsverhalten.

Beispielsweise ändert der folgende Empfänger das Erfassungsintervall für Hostmesswerte (die Empfänger-ID lautet hostmetrics) vom Standardwert von 60 Sekunden in 10 Sekunden:

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

Mit derselben Technik können Sie auch das Erfassungsintervall für die Messwertempfänger in Windows namens iis und mssql überschreiben.

Von den Empfängern aufgenommene Messwerte

Die vom Ops-Agent aufgenommenen Messwerte haben Kennzeichnungen, die mit dem folgenden Muster beginnen: agent.googleapis.com/GROUP. Die Komponente GROUP identifiziert eine Reihe zusammenhängender Messwerte; sie hat Werte wie cpu, network und weitere.

Der hostmetrics-Empfänger nimmt die folgenden Messwertgruppen auf. Weitere Informationen finden Sie im verknüpften Abschnitt für jede Gruppe auf der Seite Ops-Agent-Messwerte.

Gruppe Messwert
cpu CPU-Auslastung in 1-Minuten-Intervallen
CPU-Auslastung in 5-Minuten-Intervallen
CPU-Auslastung in 15-Minuten-Intervallen
CPU-Auslastung mit Labels für CPU-Anzahl und CPU-Status
Prozentuale CPU-Auslastung mit Labels für CPU-Anzahl und CPU-Status
disk Gelesene Laufwerk-Byte mit Label für Gerät
Geschriebene Laufwerk-Byte mit Label für Gerät
Laufwerk-E/A-Zeit mit Label für Gerät
Gewichtete Laufwerk-E/A-Zeit mit Label für Gerät
Ausstehende Laufwerkvorgänge mit Label für Gerät
Zusammengeführte Laufwerkvorgänge mit Labels für Gerät und Richtung
Laufwerkvorgänge mit Labels für Gerät und Richtung
Zeit der Laufwerkvorgänge mit Labels für Gerät und Richtung
Laufwerknutzung mit Labels für Gerät und Status
Laufwerkauslastung mit Labels für Gerät und Status
interface
Nur Linux
Gesamtzahl der Netzwerkfehler
Gesamtzahl der über das Netzwerk gesendeten Pakete
Gesamtzahl der über das Netzwerk gesendeten Byte
memory Speichernutzung mit Label für Status (buffered, cached, free, slab, used)
Prozentuale Speichernutzung mit Label für Status (buffered, cached, free, slab, used)
network Anzahl der TCP-Verbindungen mit Labels für Port und TCP-Status
swap E/A-Vorgänge für den Austausch mit Label für Richtung
Verwendete Byte für den Austausch mit Labels für Gerät und Status
Verwendeter Prozentsatz für den Austausch mit Labels für Gerät und Status
pagefile
Nur Windows
Aktueller Prozentsatz der verwendeten Auslagerungsdatei nach Status.
processes Anzahl der Vorgänge mit Labels für Status
Anzahl der verzweigten Vorgänge
E/A-Laufwerklesevorgang pro Prozess mit Labels für Prozessname und andere
E/A-Laufwerkschreibvorgang pro Prozess mit Labels für Prozessname und andere
RSS-Nutzung pro Prozess mit Labels für Prozessname und andere
VM-Nutzung pro Prozess mit Labels für Prozessname und andere

Der Empfänger iis (nur Windows) nimmt die Messwerte der Gruppe iis auf. Weitere Informationen finden Sie auf der Seite Agent-Messwerte.

Gruppe Messwert
iis
Nur Windows
Derzeit offene Verbindungen zu IIS
Netzwerkbyte, die von IIS übertragen werden
Verbindungen geöffnet zu IIS
Anfragen gestellt an IIS

Der Empfänger mssql (nur Windows) nimmt Messwerte der Gruppe mssql auf. Weitere Informationen finden Sie auf der Seite Ops-Agent-Messwerte.

Gruppe Messwert
mssql
Nur Windows
Derzeit offene Verbindungen zu SQL-Server
Gesamtanzahl der Transaktionen des SQL-Servers pro Sekunde
SQL Server-Schreibtransaktionen pro Sekunde

Messwertprozessoren

Das processor-Element enthält eine Reihe von Prozessordefinitionen. Ein Prozessor beschreibt Messwerte vom auszuschließenden Empfängertyp. Der einzige unterstützte Typ ist exclude_metrics, der die Option metrics_pattern verwendet. Der Wert ist eine Liste von Globs, die den Messwerttypen entsprechen, die Sie aus der von einem Empfänger erfassten Gruppe ausschließen möchten. Beispiel: agent.googleapis.com/cpu/* oder agent.googleapis.com/processes/*. Die vollständig qualifizierten Namen einzelner Messwerte finden Sie in der Tabelle der Gruppe auf der Seite Ops-Agent-Messwerte.

Beispiel für einen Messwertprozessor

Das folgende Beispiel zeigt den in den integrierten Konfigurationen bereitgestellten exclude_metrics-Prozessor. Dieser Prozessor gibt einen leeren metrics_pattern-Wert an, sodass keine Messwerte ausgeschlossen werden.

processors:
  metrics_filter:
    type: exclude_metrics
    metrics_pattern: []

Fügen Sie der Datei config.yaml Folgendes hinzu, um die Erfassung aller Prozessmesswerte durch den Ops-Agent zu deaktivieren:

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

Dies schließt Prozessmesswerte von der Erfassung im metrics_filter-Prozessor aus, die für die Standardpipeline im metrics-Dienst gilt.

Messwertdienst

Der Messwertdienst passt die Ausführlichkeit für die eigenen Logs des Ops-Agent-Messwertmoduls an und verknüpft Messwertempfänger und -prozessoren miteinander in Pipelines. Der Abschnitt service enthält zwei Elemente: log_level und pipelines.

Ausführlichkeitsstufe für Messwerte

log_level ist ab Ops-Agent-Version 2.6.0 verfügbar und passt die Ausführlichkeit für die eigenen Logs des Messwerte-Submoduls des Ops-Agent an. Der Standardwert ist info. Folgende Optionen sind verfügbar: error, warn, info, debug.

Messwertpipelines

Der Abschnitt service enthält ein einzelnes Element, pipelines, das mehrere Pipeline-IDs und Definitionen enthalten kann. Jede pipeline-Definition besteht aus den folgenden Elementen:

  • receivers: Für neue Pipelines erforderlich. Eine Liste der Empfänger-IDs, wie unter Messwertempfänger beschrieben. Die Reihenfolge der Empfänger-IDs in der Liste spielt keine Rolle. Die Pipeline erfasst Daten von allen aufgelisteten Empfängern.

  • processors: Optional. Eine Liste von Prozessor-IDs, wie unter Messwertprozessoren beschrieben. Die Reihenfolge der Prozessor-IDs in der Liste ist wichtig. Jeder Messwertpunkt wird in der aufgeführten Reihenfolge durch die Prozessoren ausgeführt.

Beispiel für service-Messwertkonfigurationen

Eine service-Konfiguration hat die folgende Struktur:

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

Wenn Sie die integrierte Aufnahme von Hostmesswerten deaktivieren möchten, definieren Sie die Standardpipeline mit einer leeren receivers-Liste ohne Prozessoren neu. Die gesamte Messwertkonfiguration sieht so aus:

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

Das folgende Beispiel zeigt die integrierte service-Konfiguration für Windows:

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

Die folgende service-Konfiguration passt die Log-Ausführlichkeit für das Messwerte-Untermodul stattdessen auf debug an:

metrics:
  service:
    log_level: debug