Neste docuento, 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.
Você tem interesse em aprender os detalhes técnicos da configuração do agente de operações.
O agente de operações também fornece instruções de configuração para coletar métricas e registros de aplicativos de terceiros compatíveis. Consulte Como monitorar aplicativos de terceiros para ver a lista de aplicativos compatíveis.
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 tipos de receptor.
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 tipos de receptor.
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
.Para 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.
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
.
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.
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
(disponível nas versões 2.12.0 e posteriores do agente de operações): coletar registros enviados pelo protocolo Fluent Forward via TCP.syslog
: colete o syslog por TCP ou UDP.tcp
(disponível na versão 2.3.0 e mais recentes do agente de operações): coletar registros no formato JSON ouvindo uma porta TCP.windows_event_log
(somente Windows): colete os registros de eventos do Windows.systemd_journald
(disponível com o agente do Ops versões 2.4.0 e posteriores no Linux): colete registros do serviço systemd-journald.- 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
.
Recebedores
syslog
:transport_protocol
: opcional. Valores aceitos:tcp
,udp
. O padrão étcp
.listen_host
: opcional. Um endereço IP para detectar. O valor padrão é0.0.0.0
.listen_port
: opcional. Uma porta a ser detectada. O valor padrão é5140
.
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.
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
Amostra de receptor syslog
:
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]
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 ([string](/logging/docs/reference/v2/rest/v2/LogEntry#httprequest)) |
httpRequest |
logging.googleapis.com/severity ([string](/logging/docs/reference/v2/rest/v2/LogEntry#logentrysourcelocation)) |
severity |
logging.googleapis.com/labels (estrutura de string:string) |
labels |
logging.googleapis.com/operation ([struct](/logging/docs/reference/v2/rest/v2/LogEntry#logentryoperation)) |
operation |
logging.googleapis.com/sourceLocation ([struct](/logging/docs/reference/v2/rest/v2/LogEntry#logentrysourcelocation)) |
sourceLocation |
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:
jsonPayload."logging.googleapis.com/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
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 de 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 = "-"
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 dois elementos: log_level
e pipelines
.
Nível de detalhamento do registro
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
pipelines
pode conter várias definições e IDs 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 importa. 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.
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 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 tipos de receptor.
É 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.
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. |
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) ingere as 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) 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 que você quer excluir do
grupo coletado por um receptor: por exemplo, agent.googleapis.com/cpu/*
ou
agent.googleapis.com/processes/*
. Para encontrar os nomes totalmente qualificados de métricas individuais, consulte a tabela do grupo na página Métricas do agente de operações.
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