Neste documento, fornecemos detalhes sobre as configurações padrão e personalizadas do agente de operações. Leia este documento se alguma das seguintes situações se aplicar a você:
Você quer alterar a configuração do agente de operações para alcançar os objetivos a seguir:
Desative a geração de registros ou a ingestão de métricas integradas.
Para desativar o processamento de registros, consulte Exemplos de configurações de
service
de geração de registros.Para desativar a ingestão de métricas do host, consulte Exemplos de configurações de
service
métricas.
Personalize o caminho dos arquivos de registros de onde o agente coleta registros; consulte Receptores de geração de registros.
Personalize o formato de registro estruturado que o agente usa para processar as entradas de registro. Para isso, analise o JSON ou use expressões regulares. Consulte Processadores de geração de registros.
Altere a taxa de amostragem das métricas. Consulte Receptores de métricas.
Personalize quais grupos de métricas serão ativados. O agente coleta todas as métricas do sistema, como
cpu
ememory
, por padrão. Consulte Processadores de métricas.Personalize como o agente alterna os registros. Consulte Configuração de rotação de registro.
Colete métricas e registros de aplicativos de terceiros compatíveis. Consulte Monitorar aplicativos de terceiros para ver a lista de aplicativos compatíveis.
Use o receptor do Prometheus para coletar métricas personalizadas.
Use o receptor do OpenTelemetry Protocol (OTLP) para coletar métricas e traces personalizados.
Você tem interesse em aprender os detalhes técnicos da configuração do agente de operações.
Modelo de configuração
O agente de operações usa uma configuração padrão integrada. Não é possível modificar diretamente essa configuração integrada. Em vez disso, você cria um arquivo de modificações mescladas com a configuração integrada quando o agente é reiniciado.
Os elementos básicos da configuração são os seguintes:
receivers
: esse elemento descreve o que é coletado pelo agente.processors
: esse elemento descreve como o agente pode modificar as informações coletadas.service
: esse elemento vincula receptores e processadores para criar fluxos de dados, chamados de pipelines. O elementoservice
contém um elementopipelines
, que pode conter vários pipelines.
A configuração integrada é composta desses elementos, e você usa os mesmos elementos para modificar essa configuração integrada.
Configuração integrada
A configuração integrada do agente de operações define a coleção padrão para registros e métricas. Veja a seguir a configuração integrada para Linux e Windows:
Linux
Por padrão, o agente de operações coleta registros syslog
baseados em arquivos e métricas de host.
Para mais informações sobre as métricas coletadas, consulte Métricas ingeridas pelos receptores.
Windows
Por padrão, o agente de operações coleta logs de eventos do Windows dos canais System
, Application
e Security
, além de métricas de host, métricas de IIS e métricas do SQL Server.
Para mais informações sobre as métricas coletadas, consulte Métricas ingeridas pelos receptores.
Essas configurações são discutidas em mais detalhes em Configuração do Logging e Configuração de métricas.
Configuração especificada pelo usuário
Para modificar a configuração integrada, adicione novos elementos ao arquivo de configuração do usuário. Coloque a configuração no agente de operações nos seguintes arquivos:
- No Linux:
/etc/google-cloud-ops-agent/config.yaml
- No Windows:
C:\Program Files\Google\Cloud Operations\Ops Agent\config\config.yaml
Qualquer configuração especificada pelo usuário é mesclada com a configuração integrada quando o agente é reiniciado.
Para modificar um receptor, processador ou pipeline integrado, redefina-o
no arquivo config.yaml
declarando-o com o mesmo identificador.
A partir da versão 2.31.0 do Agente de operações, também é possível configurar o recurso de rotação de registros do agente. Para mais informações, consulte Configurar a rotação de registros no agente de operações.
Por exemplo, a configuração integrada de métricas inclui um receptor hostmetrics
que especifica um intervalo de coleta de 60 segundos. Para alterar o intervalo de coleta de métricas do host para 30 segundos, inclua um receptor de métricas chamado hostmetrics
no arquivo config.yaml
que define o valor collection_interval
como 30 segundos, como mostrado no exemplo a seguir:
metrics:
receivers:
hostmetrics:
type: hostmetrics
collection_interval: 30s
Para outros exemplos de como alterar as configurações integradas, consulte
Configuração do Logging e
Configuração de métricas.
Também é possível desativar a coleta de dados de geração de registros ou métricas. Essas
alterações são descritas no exemplo de configurações de service
de geração de registros e configurações de
métricas service
.
É possível usar esse arquivo para impedir que o agente colete autoregistros e envie esses registros para o Cloud Logging. Para mais informações, consulte Coleta de registros próprios.
Você também configura o recurso de rotação de registros do agente usando esse arquivo. Para mais informações, consulte Configurar a rotação de registros no Agente de operações.
Não é possível configurar o Agente de operações a fim de exportar registros ou métricas para serviços diferentes do Cloud Logging e do Cloud Monitoring.
Configurações de geração de registros
A configuração logging
usa o modelo de configuração descrito anteriormente:
receivers
: esse elemento descreve os dados a serem coletados dos arquivos de registros. Esses dados são mapeados em um modelo de <timestamp, record>.processors
: esse elemento opcional descreve como o agente pode modificar as informações coletadas.service
: esse elemento vincula receptores e processadores para criar fluxos de dados, chamados de pipelines. O elementoservice
contém um elementopipelines
, que pode incluir várias definições de pipeline.
Cada receptor e cada processador podem ser usados em vários pipelines.
As seções a seguir descrevem cada uma desses elementos.
O Agente de operações envia registros para o Cloud Logging. Não é possível configurá-lo a fim de exportar registros para outros serviços. No entanto, é possível configurar o Cloud Logging para exportar registros. Para mais informações, consulte Rotear registros para destinos compatíveis.
Receptores de geração de registro
O elemento receivers
contém um conjunto de receptores, cada um identificado por um RECEIVER_ID. Um receptor descreve como recuperar os registros. Por exemplo, fazendo o acompanhamento de arquivos com uma porta TCP ou do log de eventos do Windows.
Estrutura de receptores de registro
Cada receptor precisa ter um identificador RECEIVER_ID e incluir um elemento type
. Os tipos válidos são:
files
: coleta registros fazendo o acompanhamento de arquivos no disco.fluent_forward
(versões 2.12.0 e posteriores do agente de operações): coletar registros enviados pelo protocolo Fluent Forward via TCP.tcp
(agente de operações versão 2.3.0 e mais recentes): colete registros no formato JSON detectando uma porta TCP.- Somente no Linux:
syslog
: colete mensagens Syslog por TCP ou UDP.systemd_journald
(Agente de operações versão 2.4.0 e mais recentes): colete registros de diário do systemd do serviço systemd-journald.
- somente no Windows:
windows_event_log
: colete logs de eventos do Windows usando a API Event Log do Windows.
- Receptores de registros de aplicativos de terceiros
A estrutura receivers
tem a seguinte aparência:
receivers: RECEIVER_ID: type: files ... RECEIVER_ID_2: type: syslog ...
Dependendo do valor do elemento type
, pode haver outras
opções de configuração, da seguinte maneira:
Recebedores
files
:include_paths
: obrigatório. Uma lista de caminhos do sistema de arquivos a serem lidos acompanhando cada arquivo. Um caractere curinga (*
) pode ser usado nos caminhos. por exemplo,/var/log/*.log
(Linux) ouC:\logs\*.log
(Windows).Para ver uma lista comum de arquivos de registros de aplicativos, consulte Arquivos de registros comuns do Linux.
exclude_paths
: opcional. Uma lista de padrões de caminho do sistema de arquivos a serem excluídos do conjunto correspondente ainclude_paths
.record_log_file_path
: opcional. Se definido comotrue
, o caminho para o arquivo específico de que o registro de registro foi recebido aparecerá na entrada de registro de saída como o valor do identificadoragent.googleapis.com/log_file_path
. Ao usar um caractere curinga, apenas o caminho do arquivo de que o registro foi recebido é gravado.wildcard_refresh_interval
: opcional. O intervalo em que os caminhos de arquivo curinga eminclude_paths
são atualizados. Dada como duração, por exemplo,30s
,2m
. Essa propriedade pode ser útil com capacidades de registro altas em que os arquivos de registro são alternados mais rapidamente do que o intervalo padrão. Se não for especificado, o intervalo padrão será de 60 segundos.
Recebedores
fluent_forward
:listen_host
: opcional. Um endereço IP para detectar. O valor padrão é127.0.0.1
.listen_port
: opcional. Uma porta a ser detectada. O valor padrão é24224
.
Receptores
syslog
(apenas para Linux):transport_protocol
: valores aceitos:tcp
,udp
.listen_host
: um endereço IP a ser detectado.listen_port
: uma porta a ser detectada.
Recebedores
tcp
:format
: obrigatório. Formato do registro. Valor compatível:json
.listen_host
: opcional. Um endereço IP para detectar. O valor padrão é127.0.0.1
.listen_port
: opcional. Uma porta a ser detectada. O valor padrão é5170
.
Receptores
windows_event_log
(somente para Windows):channels
: obrigatório. Uma lista de canais do log de eventos do Windows em que os registros são lidos.receiver_version
: opcional. Controla qual API do log de eventos do Windows será usada. Os valores aceitos são1
e2
. O valor padrão é1
.render_as_xml
: opcional. Se definido comotrue
, todos os campos do log de eventos, excetojsonPayload.Message
ejsonPayload.StringInserts
, são renderizados como um documento XML em um campo de string chamadojsonPayload.raw_xml
. O valor padrão éfalse
. Isso não pode ser definido comotrue
quandoreceiver_version
é1
.
Exemplos de receptores de registro
Amostra de receptor files
:
receivers:
RECEIVER_ID:
type: files
include_paths: [/var/log/*.log]
exclude_paths: [/var/log/not-this-one.log]
record_log_file_path: true
Amostra de receptor fluent_forward
:
receivers:
RECEIVER_ID:
type: fluent_forward
listen_host: 127.0.0.1
listen_port: 24224
Exemplo de receptor syslog
(somente Linux):
receivers:
RECEIVER_ID:
type: syslog
transport_protocol: tcp
listen_host: 0.0.0.0
listen_port: 5140
Amostra de receptor tcp
:
receivers:
RECEIVER_ID:
type: tcp
format: json
listen_host: 127.0.0.1
listen_port: 5170
Amostra de receptor windows_event_log
(somente Windows):
receivers:
RECEIVER_ID:
type: windows_event_log
channels: [System,Application,Security]
Exemplo de receptor windows_event_log
que substitui o receptor integrado para usar a
versão 2
:
receivers:
windows_event_log:
type: windows_event_log
channels: [System,Application,Security]
receiver_version: 2
Amostra de receptor systemd_journald
:
receivers:
RECEIVER_ID:
type: systemd_journald
Campos especiais em payloads estruturados
Para processadores e receptores que podem ingerir dados estruturados (os receptores
fluent_forward
e tcp
e o processador parse_json
), é possível
definir campos especiais na entrada que serão mapeados para campos específicos. no
objeto LogEntry
que o agente grava na API Logging.
Quando o agente de operações recebe dados de registro estruturados externos, ele coloca
campos de nível superior no campo jsonPayload
do LogEntry
, a menos que o nome
do campo esteja listado na tabela a seguir:
Campo de registro | Campo LogEntry |
---|---|
Opção 1
Opção 2
|
timestamp |
receiver_id (não é um campo de registro) | logName |
logging.googleapis.com/httpRequest (HttpRequest) |
httpRequest |
logging.googleapis.com/severity (string) |
severity |
logging.googleapis.com/labels (struct de string:string) |
labels |
logging.googleapis.com/operation (struct) |
operation |
logging.googleapis.com/sourceLocation (struct) |
sourceLocation |
logging.googleapis.com/trace (string) |
trace |
logging.googleapis.com/spanId (string) |
spanId |
Todos os campos de registros estruturados restantes permanecem como parte da estrutura
jsonPayload
.
Arquivos de registros comuns do Linux
A tabela a seguir lista arquivos de registros comuns de aplicativos do Linux usados com frequência:
Aplicativo | Arquivos de registros comuns |
---|---|
apache | Para informações sobre arquivos de registros do Apache, consulte Como monitorar aplicativos de terceiros: Apache Web Server. |
cassandra | Para mais informações sobre os arquivos de registros do Cassandra, consulte Como monitorar aplicativos de terceiros: Cassandra. |
chef |
/var/log/chef-server/bookshelf/current
|
gitlab |
/home/git/gitlab/log/application.log
|
jenkins |
/var/log/jenkins/jenkins.log
|
jetty |
/var/log/jetty/out.log
|
joomla |
/var/www/joomla/logs/*.log
|
magento |
/var/www/magento/var/log/exception.log
|
mediawiki |
/var/log/mediawiki/*.log
|
memcached | Para informações sobre os arquivos de registros do Memcached, consulte Como monitorar aplicativos de terceiros: Memcached. |
mongodb | Para mais informações sobre os arquivos de registros do MongoDB, consulte Como monitorar aplicativos de terceiros: MongoDB. |
mysql | Para informações sobre arquivos de registros do MySQL, consulte Como monitorar aplicativos de terceiros: MySQL. |
nginx | Para informações sobre arquivos de registros nginx, consulte Como monitorar aplicativos de terceiros: nginx. |
postgres | Para mais informações sobre os arquivos de registro do PostgreSQL, consulte Como monitorar aplicativos de terceiros: PostgreSQL. |
puppet |
/var/log/puppet/http.log
|
puppet-enterprise |
/var/log/pe-activemq/activemq.log
|
rabbitmq | Para informações sobre os arquivos de registros do RabbitMQ, consulte Como monitorar aplicativos de terceiros: RabbitMQ. |
redis | Para mais informações sobre arquivos de registros do Redis, consulte Como monitorar aplicativos de terceiros: Redis. |
redmine |
/var/log/redmine/*.log
|
salt |
/var/log/salt/key
|
solr | Para mais informações sobre os arquivos de registros do Apache Solr, consulte Como monitorar aplicativos de terceiros: Apache Solr. |
sugarcrm |
/var/www/*/sugarcrm.log
|
syslog |
/var/log/syslog
|
tomcat | Para informações sobre os arquivos de registros do Apache Tomcat, consulte Como monitorar aplicativos de terceiros: Apache Tomcat. |
zookeeper | Para mais informações sobre os arquivos de registros do Apache ZooKeeper, consulte Como monitorar aplicativos de terceiros: Apache ZooKeeper. |
Rótulos ingeridos padrão
Por padrão, os registros podem conter os seguintes identificadores em LogEntry
:
Campo | Valor de amostra | Descrição |
---|---|---|
labels."compute.googleapis.com/resource_name" |
test_vm |
O nome da máquina virtual de origem do registro. Escrito para todos os registros. |
labels."logging.googleapis.com/instrumentation_source" |
agent.googleapis.com/apache_access |
Valor do receptor type do qual se origina o registro, com prefixo agent.googleapis.com/ . Escrito apenas pelos destinatários das integrações de terceiros. |
Processadores de geração de registros
O elemento opcional processors
contém um conjunto de diretivas de processamento, cada uma identificada por um PROCESSOR_ID. Um processador descreve como manipular as informações coletadas por um receptor.
Cada processador precisa ter um identificador exclusivo e incluir um elemento type
. Os
tipos válidos são:
parse_json
: analisa registros estruturados em formato JSON.parse_multiline
: analisa registros de várias linhas. Somente no Linuxparse_regex
: analisa registros em formato de texto por meio de padrões regex para transformá-los em registros estruturados em formato JSON.exclude_logs
: exclui os registros que correspondem às regras especificadas (a partir da versão 2.9.0).modify_fields
: define/transforma campos em entradas de registro (a partir da versão 2.14.0).
A estrutura processors
tem a seguinte aparência:
processors: PROCESSOR_ID: type: parse_json ... PROCESSOR_ID_2: type: parse_regex ...
Dependendo do valor do elemento type
, há outras
opções de configuração, da seguinte maneira:
Processador parse_json
Estrutura da configuração
processors:
PROCESSOR_ID:
type: parse_json
time_key: <field name within jsonPayload>
time_format: <strptime format string>
O processador parse_json
analisa o JSON de entrada no campo
jsonPayload
de LogEntry
. Outras partes de LogEntry
podem ser analisadas configurando
determinados campos especiais de nível superior.
time_key
: opcional. Se a entrada de registro fornecer um campo com um carimbo de data/hora, essa opção especificará o nome desse campo. O valor extraído é usado para definir o campotimestamp
doLogEntry
resultante e é removido do payload.Se a opção
time_key
for especificada, você também precisará especificar o seguinte:time_format
: obrigatório setime_key
for usado. Essa opção especifica o formato do campotime_key
para que ele possa ser reconhecido e analisado adequadamente. Para detalhes sobre o formato, consulte o guiastrptime(3)
.
Exemplo de configuração
processors:
PROCESSOR_ID:
type: parse_json
time_key: time
time_format: "%Y-%m-%dT%H:%M:%S.%L%Z"
Processador parse_multiline
Estrutura da configuração
processors:
PROCESSOR_ID:
type: parse_multiline
match_any:
- type: <type of the exceptions>
language: <language name>
match_any
: obrigatório. Uma lista de uma ou mais regrastype
: obrigatório. Somente um valor é compatível:language_exceptions
: permite que o processador concatene exceções em umLogEntry
, com base no valor da opçãolanguage
.
language
: obrigatório. Somente um valor é compatível:java
: concatena exceções comuns do Java em umaLogEntry
.python
: agrupa exceções comuns do Python em umLogEntry
.go
: agrupa exceções comuns do Go em umLogEntry
.
Exemplo de configuração
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 você usar a configuração anterior e tiver um arquivo de registro com o seguinte conteúdo:
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
o agente ingere os registros no Cloud Logging no seguinte 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"
}
Processador parse_regex
Estrutura da configuração
processors:
PROCESSOR_ID:
type: parse_regex
regex: <regular expression>
time_key: <field name within jsonPayload>
time_format: <format string>
time_key
: opcional. Se a entrada de registro fornecer um campo com um carimbo de data/hora, essa opção especificará o nome desse campo. O valor extraído é usado para definir o campotimestamp
doLogEntry
resultante e é removido do payload.Se a opção
time_key
for especificada, você também precisará especificar o seguinte:time_format
: obrigatório setime_key
for usado. Essa opção especifica o formato do campotime_key
para que ele possa ser reconhecido e analisado adequadamente. Para detalhes sobre o formato, consulte o guiastrptime(3)
.
regex
: obrigatório. A expressão regular para analisar o campo. A expressão precisa incluir nomes de chave para as subexpressões correspondentes. Por exemplo,"^(?<time>[^ ]*) (?<severity>[^ ]*) (?<msg>.*)$"
.O texto correspondente aos grupos de captura nomeados será colocado em campos no campo
jsonPayload
doLogEntry
. Para adicionar mais estrutura aos registros, use o processadormodify_fields
.Para um conjunto de expressões regulares para extrair informações de arquivos de registros comuns de aplicativos do Linux, consulte Arquivos de registros comuns do Linux.
Exemplo de configuração
processors:
PROCESSOR_ID:
type: parse_regex
regex: "^(?<time>[^ ]*) (?<severity>[^ ]*) (?<msg>.*)$"
time_key: time
time_format: "%Y-%m-%dT%H:%M:%S.%L%Z"
Processador exclude_logs
Estrutura da configuração:
type: exclude_logs
match_any:
- <filter>
- <filter>
A configuração de nível superior desse processador contém um único campo,
match_any
, que contém uma lista de regras de filtro.
match_any
: obrigatório. Uma lista de uma ou mais regras Se uma entrada de registro corresponder a qualquer regra, o agente de operações não ingerirá essa entrada.Os registros ingeridos pelo agente de operações seguem a estrutura
LogEntry
. Os nomes dos campos diferenciam maiúsculas de minúsculas. Só é possível especificar regras com base nos seguintes campos e nos respectivos subcampos:httpRequest
jsonPayload
labels
operation
severity
sourceLocation
trace
spanId
O exemplo de regra a seguir
severity =~ "(DEBUG|INFO)"
usa uma expressão regular para excluir todos os registros no nível
DEBUG
eINFO
.As regras seguem a sintaxe da linguagem de consulta do Cloud Logging, mas são compatíveis apenas com um subconjunto de recursos compatíveis com essa linguagem:
- Operadores de comparação:
=
,!=
,:
,=~
,!~
. Somente comparações de string são compatíveis. - Operador de navegação:
.
. Por exemplo,jsonPayload.message
. - Operadores booleanos:
AND
,OR
,NOT
. - Agrupar expressões com
)
(
.
Exemplo de configuração
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"'
Processador modify_fields
O processador modify_fields
permite a personalização da estrutura e
do conteúdo de entradas de registro.
Estrutura da configuração
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>
A configuração de nível superior desse processador contém um
único campo, fields
, que contém um mapa de nomes de campo de saída e traduções
correspondentes. Para cada campo de saída, uma origem opcional e nenhuma ou mais
operações de mutação são aplicadas.
Todos os nomes de campo usam a sintaxe separada por pontos da linguagem de consulta do Cloud Logging. Os filtros usam a linguagem de consulta do Cloud Logging.
Todas as transformações são aplicadas em paralelo, o que significa que as origens e os filtros operam na entrada de registro de entrada original e, portanto, não podem fazer referência ao novo valor de nenhum outro campo que esteja sendo modificado pelo mesmo processador.
Opções de origem: é permitida, no máximo, uma origem especificada.
Nenhuma origem especificada
Se nenhum valor de origem for especificado, o valor existente no campo de destino será modificado.
move_from: <source field>
O valor de
<source field>
será usado como origem para o campo de destino. Além disso,<source field>
será removido da entrada de registro. Se um campo de origem for referenciado pormove_from
ecopy_from
, o campo de origem ainda será removido.copy_from: <source field>
O valor de
<source field>
será usado como origem para o campo de destino.<source field>
não será removido da entrada de registro, a menos que também seja referenciado por uma operaçãomove_from
ou modificado.static_value: <string>
A string estática
<string>
será usada como origem para o campo de destino.
Opções de mutação: zero ou mais operadores de mutação podem ser aplicados a um único campo. Se forem fornecidos vários operadores, eles sempre serão aplicados na seguinte ordem.
default_value: <string>
Se o campo de origem não existir, o valor de saída será definido como
<string>
. Se o campo de origem já existir, mesmo que contenha uma string vazia, o valor original não será modificado.map_values: <map>
Se o valor de entrada corresponder a uma das chaves em
<map>
, o valor de saída será substituído pelo valor correspondente do mapa.map_values_exclusive: {true|false}
Caso
<source field>
não corresponda a nenhuma chave especificada nos paresmap_values
, o campo de destino será forçado a ser desativado semap_values_exclusive
for verdadeiro ou permanece inalterado semap_values_exclusive
é falso.type: {integer|float}
O valor de entrada será convertido em um número inteiro ou um ponto flutuante. Se não for possível converter a string em um número, o valor de saída não será configurado. Se a string contiver um ponto flutuante, mas o tipo for especificado como
integer
, o número será truncado para um número inteiro.A API Cloud Logging usa JSON e, portanto, não é compatível com um número inteiro completo de 64 bits. Se um número inteiro de 64 bits (ou maior) for necessário, ele precisará ser armazenado como uma string na entrada de registro.
omit_if: <filter>
Se o filtro corresponder ao registro de entrada, o campo de saída será desativado. Isso pode ser usado para remover valores de marcador, como:
httpRequest.referer: move_from: jsonPayload.referer omit_if: httpRequest.referer = "-"
Configurações de amostra
O processador parse_json
transformaria um arquivo JSON com
{
"http_status": "400",
"path": "/index.html",
"referer": "-"
}
em uma estrutura LogEntry com a seguinte aparência:
{
"jsonPayload": {
"http_status": "400",
"path": "/index.html",
"referer": "-"
}
}
Isso poderia ser transformado com modify_fields
neste LogEntry
:
{
"httpRequest": {
"status": 400,
"requestUrl": "/index.html",
}
}
usando esta configuração do Agente de operações:
logging:
receivers:
in:
type: files
include_paths:
- /var/log/http.json
processors:
parse_json:
type: parse_json
set_http_request:
type: modify_fields
fields:
httpRequest.status:
move_from: jsonPayload.http_status
type: integer
httpRequest.requestUrl:
move_from: jsonPayload.path
httpRequest.referer:
move_from: jsonPayload.referer
omit_if: jsonPayload.referer = "-"
service:
pipelines:
pipeline:
receivers: [in]
processors: [parse_json, set_http_request]
Essa configuração lê os registros formatados em JSON de /var/log/http.json
e
preenche parte da estrutura httpRequest
dos campos nos registros.
Serviço da geração de registros
O serviço de geração de registros personaliza o detalhamento dos registros do agente de operações e vincula os receptores e processadores de geração de registros aos pipelines. A seção service
tem estes elementos:
log_level
pipelines
Nível de detalhamento do registro
O campo log_level
, disponível nas versões 2.6.0 e posteriores do agente de operações, personaliza
o verbosidade dos registros do submódulo de geração de registros do agente de operações. O padrão é info
. As opções disponíveis são: error
, warn
, info
, debug
, trace
.
A seguinte configuração de a seguir personaliza o nível de detalhes de registro para que o submódulo de geração de registros seja debug
:
logging:
service:
log_level: debug
Pipelines de geração de registros
O campo pipelines
pode conter vários IDs e definições de pipeline. Cada definição de pipeline
consiste nos seguintes elementos:
receivers
: obrigatório para novos pipelines. Uma lista de IDs de receptor, conforme descrito em Receptores de geração de registros. A ordem dos IDs dos receptores na lista não importa. O pipeline coleta dados de todos os receptores listados.processors
: opcional. Uma lista de IDs de processador, conforme descrito em Processadores de registro. A ordem dos IDs do processador na lista é importante. Cada registro é executado pelos processadores na ordem listada.
Exemplo de configurações da geração de registros do service
Uma configuração service
tem a seguinte estrutura:
service: log_level: CUSTOM_LOG_LEVEL pipelines: PIPELINE_ID: receivers: [...] processors: [...] PIPELINE_ID_2: receivers: [...] processors: [...]
Para impedir que o agente colete e envie entradas /var/log/message
ou
/var/log/syslog
, redefina o pipeline padrão com
uma lista receivers
vazia e sem processadores. Essa configuração não
interrompe o subcomponente de geração de registros do agente, porque ele precisa
coletar registros do subcomponente de monitoramento. Toda a configuração de geração
de registros tem esta aparência:
logging:
service:
pipelines:
default_pipeline:
receivers: []
A configuração a seguir service
define um pipeline com o ID
custom_pipeline
:
logging:
service:
pipelines:
custom_pipeline:
receivers:
- RECEIVER_ID
processors:
- PROCESSOR_ID
Configurações das métricas
A configuração metrics
usa o modelo de configuração descrito anteriormente:
receivers
: uma lista de definições de receptor. Umreceiver
descreve a origem das métricas; por exemplo, métricas do sistema, comocpu
oumemory
. Os receptores nesta lista podem ser compartilhados entre vários pipelines.processors
: uma lista de definições de processador. Umprocessor
descreve como modificar as métricas coletadas por um receptor.service
: contém uma seção depipelines
que é uma lista de definições depipeline
. Umpipeline
conecta uma lista dereceivers
a uma lista deprocessors
para formar o fluxo de dados.
As seções a seguir descrevem cada uma desses elementos.
O Agente de operações envia métricas para o Cloud Monitoring. Não é possível configurá-lo a fim de exportar métricas para outros serviços.
Receptores de métricas
O elemento receivers
contém um conjunto de definições de receptor. Um receptor
descreve de onde recuperar as métricas, como cpu
e memory
.
Um receptor pode ser compartilhado entre vários pipelines.
Estrutura de receptores de métricas
Cada receptor precisa ter um identificador RECEIVER_ID e incluir um elemento type
. Os tipos integrados válidos são:
hostmetrics
iis
(Somente no Windows)mssql
(Somente no Windows)
Um receptor também pode especificar a opção collection_interval
da operação. O
valor está no formato de duração, por exemplo, 30s
ou 2m
. O valor
padrão é 60s
.
Cada um desses tipos de receptor coleta um conjunto de métricas. Para informações sobre as métricas específicas incluídas, consulte Métricas ingeridas pelos receptores.
É possível criar apenas um receptor para cada tipo. Por exemplo, não é possível definir dois receptores do tipo hostmetrics
.
Como alterar o intervalo de coleta nos receptores de métricas
Algumas cargas de trabalho críticas podem exigir alertas rápidos. Ao reduzir o intervalo de coleta das métricas, é possível configurar alertas mais confidenciais. Para mais informações sobre como os alertas são avaliados, consulte Comportamento das políticas de alertas com base em métricas.
Por exemplo, o receptor a seguir altera o intervalo de coleta de métricas do host (o ID do receptor é hostmetrics
) do padrão de 60 segundos para 10
segundos:
metrics:
receivers:
hostmetrics:
type: hostmetrics
collection_interval: 10s
Você também pode modificar o intervalo de coleta para receptores de métricas iis
e mssql
do Windows usando a mesma técnica.
Métricas ingeridas pelos receptores
As métricas ingeridas pelo agente de operações têm identificadores que começam com o
seguinte padrão: agent.googleapis.com/GROUP
.
O componente GROUP identifica um conjunto de métricas relacionadas; tem valores como cpu
, network
e outros.
Destinatário hostmetrics
O receptor hostmetrics
processa os seguintes grupos de métricas. Para
mais informações, consulte a seção vinculada para cada grupo na página
Métricas do agente de operações.
Grupo | Métrica |
---|---|
cpu
|
Carga da CPU em intervalos de 1 minuto. Carga da CPU em intervalos de 5 minutos. Carga da CPU em intervalos de 15 minutos. Uso da CPU, com rótulos para o número da CPU e o estado da CPU. Porcentagem de uso da CPU, com rótulos para o número da CPU e o estado da CPU. |
disk
|
Bytes de disco lidos, com rótulo para o dispositivo. Bytes de disco gravados, com rótulo para o dispositivo. Tempo de E/S de disco, com rótulo para o dispositivo. Tempo de E/S medido do disco, com rótulo para o dispositivo. Operações de disco pendentes, com rótulo para o dispositivo. Operações de disco mescladas, com rótulos para o dispositivo e a direção. Operações de disco, com rótulos para o dispositivo e a direção. Tempo de operação do disco, com rótulos para o dispositivo e a direção. Uso do disco, com rótulos para o dispositivo e o estado. Utilização do disco, com rótulos para o dispositivo e o estado. |
gpu Somente Linux, consulte Sobre as métricas gpu para outras informações
importantes.
|
Número atual de bytes de memória da GPU usados, por estado Quantidade máxima de memória da GPU, em bytes, que foi alocada pelo processo Porcentagem de tempo da vida útil do processo se um ou mais kernels estão sendo executados na GPU. Porcentagem de tempo, desde a última amostra, a GPU está ativa. |
interface Somente no Linux |
Contagem total de erros de rede Contagem total de pacotes enviados pela rede Número total de bytes enviados pela rede |
memory
|
Uso de memória, com rótulo para o estado (armazenado em buffer, armazenado em cache, disponível, slab, usado). Porcentagem de uso de memória, com rótulo para o estado (armazenado em buffer, armazenado em cache, disponível, slab, usado). |
network
|
Contagem de conexão TCP, com rótulos de porta e estado TCP. |
swap
|
Operações de E/S de troca, com o rótulo para a direção. Bytes de troca usados, com rótulos para o dispositivo e o estado. Porcentagem de troca usada, com rótulos para o dispositivo e o estado. |
pagefile Somente no Windows |
Porcentagem atual do arquivo de paginação usado pelo estado |
processes
|
Contagem de processos, com rótulo para o estado. Contagem de processos bifurcados. E/S de leitura de disco por processo, com rótulos para o nome do processo + outros Por processo E/S de gravação de disco, com rótulos para o nome do processo + outros Uso de RSS por processo, com rótulos para o nome do processo + outros Uso de VM por processo, com rótulos para o processo nome + outros |
O receptor iis
(somente para Windows)
O receptor iis
(somente para Windows) ingere métricas do grupo iis
.
Para mais informações, consulte a página
Métricas do agente.
Grupo | Métrica |
---|---|
iis Somente no Windows |
Atualmente, conexões abertas para IIS Bytes de rede transferidos por IIS Conexões abertas ao IIS Solicitações feitas ao IIS |
O receptor mssql
(somente para Windows)
O receptor mssql
(somente para Windows) ingere métricas do grupo mssql
. Para
mais informações, consulte a página
Métricas do agente de operações.
Grupo | Métrica |
---|---|
mssql Somente no Windows |
Atualmente, conexões abertas para o SQL Server Total de transações por segundo do SQL Server Transações de gravação por segundo do SQL Server |
Operadores de métricas
O elemento processor
contém um conjunto de definições de processador. Um processador
descreve as métricas do tipo receptor a serem excluídas. O único tipo
compatível é exclude_metrics
, que usa uma opção metrics_pattern
. O valor é
uma lista de globs que correspondem aos tipos de métricas do Agente de operações
que você quer excluir do grupo coletado por um receptor. Exemplo:
- Para excluir todas as métricas de CPU do agente,
especifique
agent.googleapis.com/cpu/*
. - Para excluir a métrica de utilização da CPU do agente, especifique
agent.googleapis.com/cpu/utilization
. - Para excluir a métrica de contagem de solicitações do lado do cliente das métricas coletadas pela integração de terceiros do Apache Cassandra, especifique
workloads.googleapis.com/cassandra.client.request.count
. - Para excluir todas as métricas do lado do cliente das métricas coletadas pela integração de terceiros do Apache Cassandra, especifique
workloads.googleapis.com/cassandra.client.*
.
Exemplo de processador de métricas
O exemplo a seguir mostra o processador exclude_metrics
fornecido nas
configurações integradas. Esse processador fornece um valor metrics_pattern
vazio para que ele não exclua nenhuma métrica.
processors:
metrics_filter:
type: exclude_metrics
metrics_pattern: []
Para desativar a coleta de todas as métricas de processo pelo agente de operações,
adicione o seguinte ao arquivo config.yaml
:
metrics: processors: metrics_filter: type: exclude_metrics metrics_pattern: - agent.googleapis.com/processes/*
Isso exclui as métricas de processo da coleta no processador
metrics_filter
que se aplica ao pipeline padrão no serviço metrics
.
Serviço de métricas
O serviço de métricas personaliza o detalhamento dos registros do módulo de métricas do agente de operações e vincula receptores e processadores de métricas a pipelines. A seção service
tem dois elementos: log_level
e pipelines
.
Nível de detalhamento de métricas
log_level
, disponível nas versões 2.6.0 e posteriores do agente de operações, personaliza
o verbosidade dos registros do submódulo de métricas do agente de operações. O padrão é info
.
As opções disponíveis são: error
, warn
, info
, debug
.
Pipelines de métricas
A seção service
tem um único elemento, pipelines
, que pode conter vários
IDs e definições de pipeline. Cada definição de pipeline
consiste nos seguintes elementos:
receivers
: obrigatório para novos pipelines. Uma lista de IDs de receptor, conforme descrito em Receptores de métricas. A ordem dos IDs dos receptores na lista não importa. O pipeline coleta dados de todos os receptores listados.processors
: opcional. Uma lista de IDs de processador, conforme descrito em Processadores de métricas. A ordem dos IDs do processador na lista importa. Cada ponto de métrica é executado pelos processadores na ordem listada.
Exemplo de configurações service
de métricas
Uma configuração service
tem a seguinte estrutura:
service: log_level: CUSTOM_LOG_LEVEL pipelines: PIPELINE_ID: receivers: [...] processors: [...] PIPELINE_ID_2: receivers: [...] processors: [...]
Para desativar a ingestão integrada de métricas do host, redefina o pipeline padrão com uma lista receivers
vazia e sem processadores. Toda a configuração de métricas é semelhante a esta:
metrics:
service:
pipelines:
default_pipeline:
receivers: []
O exemplo a seguir mostra a configuração integrada service
para
Windows:
metrics:
service:
pipelines:
default_pipeline:
receivers:
- hostmetrics
- iis
- mssql
processors:
- metrics_filter
A seguinte configuração de service
personaliza o detalhamento de registro para o submódulo de métricas
como debug
:
metrics:
service:
log_level: debug
Coleção de registros próprios
Por padrão, os registros próprios do Fluent Bit do Agente de operações são enviados para o Cloud Logging. Esses registros podem incluir muitas informações, e o volume extra pode aumentar os custos de uso do Cloud Logging.
É possível desativar a coleta desses registros próprios a partir da versão 2.44.0
do Agente de operações usando a
opção default_self_log_file_collection
.
Para desativar a coleta de registros próprios, adicione uma seção global
ao arquivo de configuração
especificado pelo usuário e defina a opção default_self_log_file_collection
como o valor false
:
logging: ... metrics: ... global: default_self_log_file_collection: false
Configuração da rotação de registro
A partir do Agente de operações versão 2.31.0, também é possível configurar o recurso de rotação de registros do agente usando os arquivos de configuração. Para mais informações, consulte Configurar a rotação de registros no Agente de operações.