Coletar registros dos seus fluxos de trabalho

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

Os registros gravam condições e ações enquanto você gerencia operações no GDC. É possível extrair os registros gerados pelos componentes para gravar eventos e atividades. A plataforma de geração de registros oferece uma API personalizada para coletar registros no nível do projeto gerados pelos fluxos de trabalho usando destinos de geração de registros.

Para começar a coletar dados de registros, implante um recurso personalizado LoggingTarget no namespace do projeto no servidor da API Management. Depois que o coletor de registros extrai dados dos seus fluxos de trabalho, a plataforma de geração de registros agrega registros de todas as fontes de registro, adiciona índices e associa registros a rótulos de acordo com a configuração do recurso personalizado LoggingTarget.

Acesse os registros coletados usando a interface do usuário do Grafana ou a API Log Query, conforme detalhado em Consultar e visualizar registros.

Para práticas recomendadas sobre a implementação da geração de registros para 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 receber as permissões necessárias para gerenciar recursos personalizados do LoggingTarget, peça ao administrador do IAM da organização ou do projeto para conceder a você uma das funções associadas do LoggingTarget.

Dependendo do nível de acesso e das permissões necessárias, você pode receber papéis de criador, editor ou leitor para esse recurso em uma organização ou um projeto. Para mais informações, consulte Preparar permissões do IAM.

Configurar o recurso personalizado LoggingTarget

O recurso personalizado LoggingTarget instrui o pipeline de geração de registros a coletar registros no seu projeto do GDC. É possível especificar os destinos para os quais você está coletando registros, um analisador de registros, níveis de acesso e quaisquer configurações adicionais.

Esse recurso define as seguintes configurações:

  • Destinos: os critérios para selecionar os pods e contêineres de que você quer coletar registros. É possível especificar nomes de cluster, prefixos de nome de pod e prefixos de nome de contêiner.
  • Analisador de registros: um analisador predefinido para interpretar entradas de registro, mapear saídas de registro para rótulos e extrair campos relevantes.
  • Identificação do serviço: o nome do serviço aplicado como um rótulo às entradas de registro para facilitar a identificação e a filtragem.

  • Autorização: o nível de acesso para entradas de registro, controlando quem pode visualizar os registros coletados.

Ao configurar esses parâmetros no recurso personalizado LoggingTarget, você pode controlar com precisão a coleta e a organização de registros.

Siga estas etapas para coletar registros operacionais:

  1. Determine o projeto do GDC de que você quer coletar registros.

  2. Na configuração LoggingTarget, especifique os pods para coletar os registros operacionais, o namespace do projeto e outras configurações.

    O arquivo YAML a seguir mostra um exemplo de configuração LoggingTarget em my-project-namespace, em que o prefixo do nome do pod para coletar registros é my-pod-prefix, o nível de acesso para entradas de registro é concedido aos operadores de aplicativos (ao), o nome do serviço é my-service-name e o formato do registro é 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-logging-target
spec:
  selector:
    matchPodNames:
      - my-pod-prefix
  parser: json
  logAccessLevel: ao
  serviceName: my-service-name

    Consulte a especificação completa de LoggingTarget e a documentação de referência da API para mais campos e opções.

  3. Aplique a configuração LoggingTarget ao servidor da API Management no mesmo namespace dos pods de destino:

    kubectl --kubeconfig KUBECONFIG_PATH apply -f LOGGING_TARGET_NAME.yaml

    Substitua:

    • KUBECONFIG_PATH: o caminho para o arquivo kubeconfig do servidor da API Management.
    • LOGGING_TARGET_NAME: o nome do arquivo de definição LoggingTarget, como my-logging-target.

    O pipeline de geração de registros começa a coletar registros dos componentes adicionais do projeto.

É possível consultar os registros coletados usando a interface do usuário do Grafana ou a API Log Query. Para mais informações, consulte Consultar e visualizar registros.

Se você usa o Grafana para consultar seus registros, pode usar o recurso integrado de codificação por cores para diferentes níveis de registro. Para mais informações sobre como definir valores de nível de registro, consulte https://grafana.com/docs/grafana/latest/explore/logs-integration/.

Especificação completa de LoggingTarget

O arquivo YAML a seguir 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:

  • PROJECT_NAMESPACE: o namespace do projeto.
  • LOGGING_TARGET_NAME: o nome do arquivo de definição LoggingTarget.