Coletar registros dos seus fluxos de trabalho

A coleta de registros no dispositivo com isolamento físico do Google Distributed Cloud (GDC) permite agregar eventos operacionais dos seus fluxos de trabalho para monitoramento e solução de problemas. Implante um recurso personalizado LoggingTarget no namespace do projeto no servidor da API Management para extrair, indexar e rotular registros dos componentes de serviço.

Depois de configurar a coleta de registros, é possível consultar e visualizar registros na interface do usuário do Grafana. Para recomendações de instrumentação, consulte as diretrizes de geração de registros do Kubernetes.

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ê um dos papéis do LoggingTarget associados.

Dependendo do nível de acesso e das permissões necessárias, é possível 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.

  • Operadores de aplicativos: para receber as permissões necessárias para gerenciar recursos personalizados do LoggingTarget em um projeto no servidor da API de gerenciamento, peça ao administrador do IAM do projeto para conceder a você um dos seguintes papéis no namespace do projeto:

    • Criador de LoggingTarget: cria recursos personalizados LoggingTarget. Solicite o papel de criador do LoggingTarget (loggingtarget-creator).
    • Editor do LoggingTarget: edita ou modifica recursos personalizados LoggingTarget. Solicite o papel de Editor do LoggingTarget (loggingtarget-editor).
    • Leitor de LoggingTarget: visualiza recursos personalizados LoggingTarget. Solicite o papel de Leitor do LoggingTarget (loggingtarget-viewer).

  • Administradores da plataforma: para receber as permissões necessárias para gerenciar recursos personalizados LoggingTarget no namespace platform-obs no servidor da API de gerenciamento, peça ao administrador do IAM da organização para conceder a você um dos seguintes papéis de cluster no namespace platform-obs:

    • Criador de PA LoggingTarget: cria recursos personalizados LoggingTarget. Solicite o papel de cluster de criador de PA do LoggingTarget (loggingtarget-pa-creator).
    • Editor de PA do LoggingTarget: edita ou modifica recursos personalizados LoggingTarget. Solicite o papel de cluster de editor de PA do LoggingTarget (loggingtarget-pa-editor).
    • Leitor de PA do LoggingTarget: visualiza recursos personalizados LoggingTarget. Solicite o papel de cluster de Leitor de PA do LoggingTarget (loggingtarget-pa-viewer).

Coletar registros operacionais

Os registros operacionais registram condições, mudanças e ações à medida que você gerencia as operações em andamento em aplicativos e serviços no GDC. Implante o recurso personalizado LoggingTarget no servidor de API Management para configurar o pipeline de geração de registros do sistema para coletar registros operacionais de serviços específicos no nível do projeto.

Siga estas etapas para coletar registros operacionais de um serviço:

  1. Configure o recurso personalizado LoggingTarget no servidor da API Management, especificando os pods selecionados para coletar os registros operacionais, o namespace do projeto e outras configurações. Para saber como o LoggingTarget precisa ser, consulte Configurar o recurso personalizado LoggingTarget.

  2. Implante o recurso personalizado LoggingTarget no namespace do projeto no servidor de API Management:

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f LOGGING_TARGET_NAME

    Substitua:

    • MANAGEMENT_API_SERVER: o caminho do kubeconfig do servidor de API Management zonal.
    • LOGGING_TARGET_NAME: o nome do recurso personalizado LoggingTarget, como my-service-logging-target.yaml.

    O pipeline começa a coletar registros dos componentes adicionais do projeto.

  3. Consulte os registros da instância do Grafana do seu projeto. Para mais informações, consulte Consultar e visualizar registros.

Use o recurso de codificação por cores integrado do Grafana para diferentes níveis de registro do serviço. Para mais informações sobre como definir valores de nível de registro, consulte https://grafana.com/docs/grafana/latest/explore/logs-integration/.

Configurar o recurso personalizado LoggingTarget

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

Esse recurso define as seguintes configurações:

  • Destinos: os critérios para selecionar os pods e contêineres de onde você quer coletar registros. É possível especificar nomes de clusters, prefixos de nomes de pods e prefixos de nomes de contêineres.
  • 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, que controla quem pode visualizar os registros coletados.

Ao configurar esses parâmetros no recurso personalizado LoggingTarget, é possível controlar com precisão a coleta e a organização dos registros dos seus serviços.

Siga estas etapas para coletar registros operacionais de um serviço:

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

  2. Na configuração do 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 de 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 a operadores de aplicativos (ao), o nome do serviço é my-service-name e o formato de 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-service-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 de API Management.
    • LOGGING_TARGET_NAME: o nome do arquivo de definição de LoggingTarget, como my-service-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 de codificação de cores integrado para diferentes níveis de registro do serviço. 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.