Coletar registros operacionais do seu projeto do AO

Esta seção descreve como coletar registros operacionais de um serviço em um appliance isolado do Google Distributed Cloud (GDC) para geração de registros do sistema e observabilidade de dados.

A plataforma Logging fornece uma API Kubernetes personalizada para coletar registros no nível do projeto que seus serviços geram por meio de destinos de geração de registros do sistema. É preciso implantar um recurso personalizado LoggingTarget no namespace do projeto no cluster de administrador da organização. Com base nesse recurso, a plataforma Logging começa a coletar os dados de registro do sistema. Acesse esses registros usando a interface do usuário (UI) da ferramenta de monitoramento do sistema ou a API GDC Logging, seguindo as etapas de Consultar e visualizar registros.

Para informações sobre práticas recomendadas para implementar o registro em componentes do Kubernetes, consulte 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 coletar ou visualizar registros operacionais, peça ao administrador do IAM do projeto para conceder a você um dos seguintes papéis no namespace do projeto:

  • Criador de destino de geração de registros: cria recursos personalizados LoggingTarget. Solicite o papel de criador de destino do Logging (loggingtarget-creator).
  • Editor de destino do Logging: edita ou modifica recursos personalizados LoggingTarget. Solicite o papel de editor de destino do Logging (loggingtarget-editor).
  • Visualizador de destino do Logging: visualiza recursos personalizados LoggingTarget. Solicite o papel de visualizador de destino do Logging (loggingtarget-viewer).

Configurar a coleta de registros operacionais de um serviço

Os registros operacionais registram condições, mudanças e ações enquanto você gerencia operações em andamento em aplicativos e serviços no GDC. Implante o recurso personalizado LoggingTarget no cluster de administrador da organização para configurar o pipeline de geração de registros do sistema e 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 CR LoggingTarget, especificando os pods selecionados para coletar seus registros operacionais, o namespace do projeto e outras configurações. Para mais informações, consulte Configurar o recurso personalizado LoggingTarget.
  2. Implante o CR LoggingTarget no namespace do projeto no cluster de administrador da organização. O pipeline começa a coletar registros dos componentes extras do projeto.
  3. Consulte os registros na instância do Grafana do projeto, também chamada de instância de monitoramento do sistema. instância de monitoramento do sistema do seu projeto. Para mais informações, consulte Consultar e visualizar registros.

Use o recurso integrado de codificação por cores 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 do sistema a coletar registros de serviços específicos do seu projeto e fornecer capacidade de observação de dados. Implante esse recurso no namespace de onde você quer coletar registros.

O arquivo YAML a seguir mostra um exemplo de configuração LoggingTarget:

# 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: my-service-logging-target
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.
    # For example, the value '["admin", "system"]' indicates to consider
    # the admin cluster 'OR' the system cluster.
    # Optional
    matchClusters:
    - CLUSTER_NAME
    - CLUSTER_NAME

    # The pod name prefixes to collect logs from.
    # The Observability 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:
      - POD_NAME
      - POD_NAME

    # The container name prefixes to collect logs from.
    # The Observability 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:
      - CONTAINER_NAME
      - CONTAINER_NAME

  # 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: 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
  • CLUSTER_NAME: o nome do cluster.
  • POD_NAME: o prefixo do nome do pod
  • CONTAINER_NAME: o prefixo do nome do contêiner
  • SERVICE_NAME: o nome do serviço

Os campos parser, logAccessLevel e additionalFields contêm valores de exemplo que podem ser modificados.

Por padrão, todas as entradas de registro operacional são salvas para o ID do locatário do namespace do projeto. Para substituir esse comportamento, forneça um valor logAccessLevel no recurso personalizado LoggingTarget.