Esta página foi traduzida pela API Cloud Translation.

Recolha registos dos seus fluxos de trabalho

Esta página descreve o processo de recolha de registos dos seus fluxos de trabalho em ambientes de appliance isolados do Google Distributed Cloud (GDC) para facilitar o registo e a observabilidade dos dados.

Os registos registam as condições e as ações à medida que gere as operações dos seus serviços na GDC. Pode extrair registos que os seus componentes geram para registar eventos e atividades. A plataforma de registo oferece uma API personalizada para recolher registos ao nível do projeto gerados pelos seus fluxos de trabalho através de destinos de registo.

Para começar a recolher dados de registo, implemente um recurso personalizado no espaço de nomes do projeto no servidor da API Management.LoggingTarget Depois de o coletor de registos extrair dados dos seus fluxos de trabalho, a plataforma de registo agrega registos de todas as origens de registos, adiciona índices e associa registos a etiquetas de acordo com a configuração do recurso personalizado LoggingTarget.

Aceda aos registos recolhidos através da interface do utilizador do Grafana, conforme detalhado em Consultar e ver registos.

Para ver as práticas recomendadas sobre a implementação do registo para a observabilidade de dados, consulte as diretrizes da comunidade do Kubernetes:

https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md.

Antes de começar

Para obter as autorizações de que precisa para gerir LoggingTarget recursos personalizados, peça ao administrador de IAM da organização ou ao administrador de IAM do projeto que lhe conceda uma das LoggingTarget funções associadas.

Consoante o nível de acesso e as autorizações de que precisa, pode obter funções de criador, editor ou leitor para este recurso numa organização ou num projeto. Para mais informações, consulte o artigo Prepare as autorizações de IAM.

Operadores de aplicações: para receber as autorizações de que precisa para gerir LoggingTarget recursos personalizados num projeto no servidor da API de gestão, peça ao administrador de IAM do projeto que lhe conceda uma das seguintes funções no espaço de nomes do projeto:
- LoggingTarget Creator: cria recursos personalizados LoggingTarget. Peça a função de criador de LoggingTarget (loggingtarget-creator).
- LoggingTarget Editor: edita ou modifica LoggingTarget recursos personalizados. Peça a função Editor de LoggingTarget (loggingtarget-editor).
- LoggingTarget Viewer: visualiza recursos personalizados.LoggingTarget Peça a função de visitante do LoggingTarget (loggingtarget-viewer).
Administradores da plataforma: para obter as autorizações necessárias para gerir LoggingTarget recursos personalizados no espaço de nomes platform-obs no servidor da API de gestão, peça ao administrador de IAM da organização que lhe conceda uma das seguintes funções de cluster no espaço de nomes platform-obs:
- LoggingTarget PA Creator: cria LoggingTarget recursos personalizados. Peça a função de cluster de criador de PA LoggingTarget (loggingtarget-pa-creator).
- LoggingTarget PA Editor: edita ou modifica LoggingTarget recursos personalizados. Peça a função de cluster de editor de PA do LoggingTarget (loggingtarget-pa-editor).
- LoggingTarget PA Viewer: visualiza LoggingTarget recursos personalizados. Peça a função de cluster LoggingTarget PA Viewer (loggingtarget-pa-viewer).

Recolha registos operacionais

Os registos operacionais registam condições, alterações e ações à medida que gere as operações em curso em aplicações e serviços no GDC. Implemente o recurso personalizado LoggingTarget no servidor da API Management para configurar o pipeline de registo do sistema para recolher registos operacionais de serviços específicos ao nível do projeto.

Conclua os passos seguintes para recolher registos operacionais de um serviço:

Configure o recurso personalizado LoggingTarget no servidor da API Management, especificando os pods selecionados para recolher os seus registos operacionais, o espaço de nomes do projeto e quaisquer definições adicionais. Para saber qual deve ser o aspeto do LoggingTarget, consulte o artigo Configure o recurso personalizado LoggingTarget.
Implemente o recurso personalizado LoggingTarget no espaço de nomes do projeto no servidor da API Management:
```
kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f LOGGING_TARGET_NAME
```
Substitua o seguinte:
- MANAGEMENT_API_SERVER: o caminho kubeconfig do servidor da API de gestão zonal.
- LOGGING_TARGET_NAME: o nome do recurso personalizado LoggingTarget, como my-service-logging-target.yaml.
O pipeline começa a recolher registos dos componentes adicionais do seu projeto.
Consulte os seus registos a partir da instância do Grafana do seu projeto. Para mais informações, consulte o artigo Consulte e veja registos.

Use a funcionalidade de código de cores integrada do Grafana para diferentes níveis de registo do serviço. Para mais informações sobre a definição de valores de nível de registo, consulte https://grafana.com/docs/grafana/latest/explore/logs-integration/.

Configure o `LoggingTarget` recurso personalizado

O recurso personalizado LoggingTarget indica ao pipeline de registo que recolha registos de serviços específicos no seu projeto do GDC. Pode especificar os alvos para os quais está a recolher registos, um analisador de registos, níveis de acesso e quaisquer definições adicionais.

Este recurso define as seguintes configurações:

Segmentos: os critérios para selecionar os pods e os contentores a partir dos quais quer recolher registos. Pode especificar nomes de clusters, prefixos de nomes de pods e prefixos de nomes de contentores.
Analisador de registos: um analisador predefinido para interpretar entradas de registos, mapear resultados de registos para etiquetas e extrair campos relevantes.
Identificação do serviço: o nome do serviço aplicado como uma etiqueta às entradas do registo para facilitar a identificação e a filtragem.
Autorização: o nível de acesso para entradas de registo, que controla quem pode ver os registos recolhidos.

Nota: por predefinição, todas as entradas do registo operacional são guardadas para o ID do inquilino do espaço de nomes do projeto. Para substituir este comportamento, indique um valor logAccessLevel
no recurso personalizado LoggingTarget.

Ao configurar estes parâmetros no recurso personalizado LoggingTarget, pode controlar com precisão a recolha e a organização dos registos dos seus serviços.

Siga estes passos para recolher registos operacionais de um serviço:

Determine o projeto do GDC a partir do qual quer recolher registos.
Na sua configuração do LoggingTarget, especifique os pods para recolher os registos operacionais, o espaço de nomes do projeto e quaisquer definições adicionais.

O ficheiro YAML seguinte mostra um exemplo de uma configuração LoggingTarget em my-project-namespace, em que o prefixo do nome do pod para recolher registos é my-pod-prefix, o nível de acesso para entradas de registo é concedido aos operadores de aplicações (ao), o nome do serviço é my-service-name e o formato de registo é JSON:
```
# Configures a log scraping job
apiVersion: logging.gdc.goog/v1
kind: LoggingTarget
metadata:
  # Choose a namespace that matches the namespace of the workload pods.
  namespace: my-project-namespace
  name: my-service-logging-target
spec:
  selector:
    matchPodNames:
      - my-pod-prefix
  parser: json
  logAccessLevel: ao
  serviceName: my-service-name
```
Consulte a especificação LoggingTarget completa e a documentação de referência da API para ver campos e opções adicionais.
Aplique a configuração LoggingTarget ao servidor da API Management no mesmo espaço de nomes que os seus pods de destino:
```
kubectl --kubeconfig KUBECONFIG_PATH apply -f LOGGING_TARGET_NAME.yaml
```
Substitua o seguinte:
- KUBECONFIG_PATH: o caminho para o ficheiro kubeconfig para o servidor da API Management.
- LOGGING_TARGET_NAME: o nome do ficheiro de definição LoggingTarget, como my-service-logging-target.
O pipeline de registo começa a recolher registos dos componentes adicionais do seu projeto.

Pode consultar os registos recolhidos através da interface do utilizador do Grafana ou da API Log Query. Para mais informações, consulte o artigo Consulte e veja registos.

Se usar o Grafana para consultar os seus registos, pode usar a funcionalidade de código de cores incorporada para diferentes níveis de registo do serviço. Para mais informações sobre a definição de valores de nível de registo, consulte https://grafana.com/docs/grafana/latest/explore/logs-integration/.

Preencha a especificação de `LoggingTarget`

O ficheiro YAML seguinte mostra um exemplo da especificação completa do recurso personalizado LoggingTarget. Para mais informações e uma descrição completa dos campos, consulte a documentação de referência da API.

# Configures a log scraping job
apiVersion: logging.gdc.goog/v1
kind: LoggingTarget
metadata:
  # Choose a namespace that matches the namespace of the workload pods.
  namespace: PROJECT_NAMESPACE
  name: LOGGING_TARGET_NAME
spec:
  # Choose a matching pattern that identifies the pods for this job.
  # Optional.
  # Relationship between different selectors: 'AND'
  selector:
    # The clusters to collect logs from.
    # The default configuration is to collect logs from all clusters.
    # The relationship between different clusters is an 'OR' relationship.
    # Optional
    matchClusters:
    - my-cluster
    - another-cluster

    # The pod name prefixes to collect logs from.
    # The logging platform scrapes all pods with names
    # that start with the specified prefixes.
    # The values must contain '[a-z0-9-]' characters only.
    # The relationship between different list elements is an 'OR' relationship.
    # Optional.
    matchPodNames:
      - my-pod-prefix
      - another-pod-prefix

    # The container name prefixes to collect logs from.
    # The logging platform scrapes all containers with names
    # that start with the specified prefixes.
    # The values must contain '[a-z0-9-]' characters only.
    # The relationship between different list elements is an 'OR' relationship.
    # Optional.
    matchContainerNames:
      - my-container-prefix
      - another-container-prefix

  # Choose the predefined parser for log entries.
  # Use parsers to map the log output to labels and extract fields.
  # Specify the log format.
  # Optional.
  # Options: klog_text, klog_json, klogr, gdch_json, json
  parser: klog_text

  # Specify an access level for log entries.
  # The default value is 'ao'.
  # Optional.
  # Options: ao, pa, io
  logAccessLevel: ao

  # Specify a service name to be applied as a label.
  # For user workloads consider this field as a workload name.
  # Required.
  serviceName: my-service-name

  # The additional static fields to apply to log entries.
  # The field is a key-value pair, where the field name is the key and
  # the field value is the value.
  # Optional.
  additionalFields:
    app: workload2
    key: value

Substitua o seguinte:

PROJECT_NAMESPACE: o espaço de nomes do seu projeto.
LOGGING_TARGET_NAME: o nome do LoggingTarget ficheiro de definição.