本页概述了从 Google Distributed Cloud (GDC) 网闸隔离设备环境中的工作流收集日志的流程,以方便进行日志记录和数据可观测性分析。
日志会记录您在 GDC 中管理服务操作时的状况和操作。您可以抓取组件生成的日志,以记录事件和活动。日志记录平台提供了一个自定义 API,用于通过日志记录目标收集工作流生成的项目级日志。
如需开始收集日志数据,请在 Management API 服务器中将 LoggingTarget
自定义资源部署到项目命名空间。日志收集器从工作流中提取数据后,日志记录平台会汇总来自所有日志来源的日志,添加索引,并根据 LoggingTarget
自定义资源中的配置将日志与标签相关联。
使用 Grafana 界面访问收集的日志,详情请参阅查询和查看日志。
如需了解有关实现日志记录以实现数据可观测性的最佳实践,请参阅 Kubernetes 社区指南:
准备工作
如需获得管理 LoggingTarget
自定义资源所需的权限,请让组织 IAM 管理员或项目 IAM 管理员向您授予关联的 LoggingTarget
角色之一。
根据您需要的访问权限级别,您可以在组织或项目中获得此资源的创建者、编辑者或查看者角色。如需了解详情,请参阅准备 IAM 权限。
应用运算符:如需获得在管理 API 服务器中管理项目中的
LoggingTarget
自定义资源所需的权限,请让项目 IAM 管理员为您授予项目命名空间中的以下角色之一:- LoggingTarget Creator:创建
LoggingTarget
自定义资源。请求 LoggingTarget Creator (loggingtarget-creator
) 角色。 - LoggingTarget 编辑器:用于修改
LoggingTarget
自定义资源。请求 LoggingTarget Editor (loggingtarget-editor
) 角色。 - LoggingTarget Viewer:查看
LoggingTarget
自定义资源。请求 LoggingTarget Viewer (loggingtarget-viewer
) 角色。
- LoggingTarget Creator:创建
平台管理员:如需获得管理管理 API 服务器中
platform-obs
命名空间内的LoggingTarget
自定义资源所需的权限,请让组织 IAM 管理员为您授予platform-obs
命名空间中的以下集群角色之一:- LoggingTarget PA Creator:创建
LoggingTarget
自定义资源。请求 LoggingTarget PA Creator (loggingtarget-pa-creator
) 集群角色。 - LoggingTarget PA 编辑者:修改
LoggingTarget
自定义资源。请求 LoggingTarget PA Editor (loggingtarget-pa-editor
) 集群角色。 - LoggingTarget PA Viewer:查看
LoggingTarget
自定义资源。请求 LoggingTarget PA Viewer (loggingtarget-pa-viewer
) 集群角色。
- LoggingTarget PA Creator:创建
收集运维日志
运营日志会记录您在 GDC 上管理应用和服务中的持续运营时发生的状况、变更和操作。将 LoggingTarget
自定义资源部署到 Management API 服务器,以配置系统日志记录流水线,从而在项目级层从特定服务收集操作日志。
完成以下步骤可从服务中收集操作日志:
- 在 Management API 服务器中配置
LoggingTarget
自定义资源,指定用于收集运营日志的所选 pod、项目命名空间和任何其他设置。如需了解LoggingTarget
的外观,请参阅配置LoggingTarget
自定义资源。 将
LoggingTarget
自定义资源部署到 Management API 服务器中的项目命名空间:kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f LOGGING_TARGET_NAME
替换以下内容:
MANAGEMENT_API_SERVER
:区域管理 API 服务器的 kubeconfig 路径。LOGGING_TARGET_NAME
:LoggingTarget
自定义资源的名称,例如my-service-logging-target.yaml
。
流水线开始从项目的其他组件收集日志。
从项目的 Grafana 实例查询日志。 如需了解详情,请参阅查询和查看日志。
使用 Grafana 的内置颜色编码功能来表示服务的不同日志级别。如需详细了解如何设置日志级别值,请参阅 https://grafana.com/docs/grafana/latest/explore/logs-integration/。
配置 LoggingTarget
自定义资源
LoggingTarget
自定义资源会指示日志记录流水线从 GDC 项目中的特定服务收集日志。您可以指定要收集日志的目标、日志解析器、访问权限级别以及任何其他设置。
此资源定义了以下配置:
- 目标:用于选择要从中收集日志的 pod 和容器的条件。您可以指定集群名称、Pod 名称前缀和容器名称前缀。
- 日志分析器:一种预定义的解析器,用于解读日志条目、将日志输出映射到标签,以及提取相关字段。
- 服务标识:作为标签应用于日志条目的服务名称,以便更轻松地识别和过滤日志条目。
授权:日志条目的访问权限级别,用于控制哪些人可以查看收集的日志。
通过在 LoggingTarget
自定义资源中配置这些参数,您可以精确控制服务的日志收集和组织。
如需从服务中收集运营日志,请按以下步骤操作:
- 确定要从中收集日志的 GDC 项目。
在
LoggingTarget
配置中,指定用于收集操作日志的 pod、项目命名空间和任何其他设置。以下 YAML 文件展示了
my-project-namespace
中LoggingTarget
配置的示例,其中要收集日志的 pod 名称前缀为my-pod-prefix
,日志条目的访问权限授予了应用操作员 (ao
),服务名称为my-service-name
,日志格式为 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
如需了解其他字段和选项,请参阅完整的
LoggingTarget
规范和 API 参考文档。将
LoggingTarget
配置应用于与目标 pod 位于同一命名空间内的 Management API 服务器:kubectl --kubeconfig KUBECONFIG_PATH apply -f LOGGING_TARGET_NAME.yaml
替换以下内容:
KUBECONFIG_PATH
:管理 API 服务器的 kubeconfig 文件的路径。LOGGING_TARGET_NAME
:LoggingTarget
定义文件的名称,例如my-service-logging-target
。
日志记录流水线开始从项目的其他组件收集日志。
您可以使用 Grafana 界面或 Log Query API 查询收集的日志。如需了解详情,请参阅查询和查看日志。
如果您使用 Grafana 查询日志,则可以使用内置的颜色编码功能来区分服务的不同日志级别。如需详细了解如何设置日志级别值,请参阅 https://grafana.com/docs/grafana/latest/explore/logs-integration/。
完整 LoggingTarget
规范
以下 YAML 文件展示了如何完整指定 LoggingTarget
自定义资源。如需了解详情和字段的完整说明,请参阅 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
替换以下内容:
PROJECT_NAMESPACE
:您的项目命名空间。LOGGING_TARGET_NAME
:LoggingTarget
定义文件的名称。