Recolha registos dos seus fluxos de trabalho

Esta página descreve o processo de recolha de registos dos seus fluxos de trabalho em ambientes 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 no GDC. Pode extrair registos produzidos pelos seus componentes 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 ou da API Log Query, 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 receber as autorizações necessárias para gerir recursos personalizados, peça ao administrador de IAM da organização ou ao administrador de IAM do projeto que lhe conceda uma das funções associadas.LoggingTargetLoggingTarget

Consoante o nível de acesso e as autorizações de que precisa, pode obter as 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.

Configure o LoggingTarget recurso personalizado

O recurso personalizado LoggingTarget indica ao pipeline de registo que recolha registos 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.

    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.

Siga estes passos para recolher registos operacionais:

  1. Determine o projeto do GDC a partir do qual quer recolher registos.
  2. 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-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.

  3. 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-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. Para mais informações sobre como definir 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.