文档教程云原生【免费下载链接】docsUser documentation for Knative components.项目地址https://gitcode.com/gh_mirrors/docs1/docs点击查看免费下载本文面向 Knative 集群管理员系统讲解 Knative 所有组件的日志设置机制日志配置统一由各命名空间下的config-loggingConfigMap 承载底层基于 Uber 开源的 zap 日志库实现。读完本文你将掌握config-logging中zap-logger-config与loglevel.component等核心键的含义与写法能够熟练修改日志级别、切换 JSON/console 编码格式并理解组件级日志级别覆盖、Kafka 数据面日志等扩展场景。日志配置的核心机制config-logging ConfigMapKnative 的所有组件Serving 的 controller、activator、autoscaler、queue-proxyEventing 的 controller、broker、trigger 相关组件等均通过名为config-logging的 ConfigMap 管理日志设置。该 ConfigMap 位于对应组件所在的命名空间Serving 组件knative-serving命名空间下的config-loggingConfigMapEventing 组件knative-eventing命名空间下的config-loggingConfigMap其他组件同理各自使用所在命名空间的config-logging。也就是说日志配置是按命名空间隔离的修改knative-serving/config-logging只影响 Serving 控制面组件不会波及 Eventing 或其他命名空间中的组件。从仓库文档的结构可以看到本主题内容配置日志设置由多个页面以 include 方式复用Serving 与 Eventing 的配置日志设置、收集日志等页面均引用同一份 snippets 片段因此下文描述对所有 Knative 组件普遍适用。底层日志库zapKnative 组件使用的日志库是 Uber 开源的 zap一个高性能的结构化日志库。zap 的配置模型是 JSON 对象这与config-logging中zap-logger-config键直接对应该键的值就是一个完整的 zap logger 配置 JSON 对象Knative 组件启动时会读取并解析它来初始化各自的 logger。zap 的配置能力非常丰富config-logging中只暴露了其中与运维最相关的一部分字段详见下文。由于 zap 的日志级别遵循达到或超过该严重级别才输出的过滤规则正确设置level字段即可控制日志量例如排查问题时临时调低为debug生产环境保持info以减少噪音。config-logging 配置键详解config-loggingConfigMap 支持以下键这些键全部定义在data字段下ConfigMap 键说明zap-logger-config一个 zap logger 配置的 JSON 对象容器核心字段见下几行zap-logger-config.level组件的默认日志级别。只有达到或高于该严重级别的消息才会被记录zap-logger-config.encoding组件日志的编码格式默认是jsonzap-logger-config.encoderConfigzap 的EncoderConfig用于定制每条日志记录的内容字段loglevel.component仅针对指定组件的日志级别覆盖达到或高于该级别的消息才会被记录其中zap-logger-config作为全局键对命名空间内所有组件生效而loglevel.component键则允许对单个组件做精细覆盖二者可以同时使用。zap-logger-config全局日志配置zap-logger-config是一个 JSON 字符串承载 zap 的核心配置。一个典型且可落地的配置如下可保存为 YAML 应用到集群apiVersion: v1 kind: ConfigMap metadata: name: config-logging namespace: knative-serving data: zap-logger-config: | { level: info, development: false, outputPaths: [stdout], errorOutputPaths: [stderr], encoding: json, encoderConfig: { timeKey: ts, levelKey: level, nameKey: logger, callerKey: caller, messageKey: msg, stacktraceKey: stacktrace, lineEnding: , levelEncoder: , timeEncoder: iso8601, durationEncoder: , callerEncoder: } }各字段的作用level默认日志级别例如info、debug、warn可写为字符串或对象如{level: info}encoding输出编码json为 JSON 结构化格式默认console为人类可读的彩色文本格式encoderConfig控制单条记录输出哪些字段及字段名例如messageKey决定消息字段的键名默认msg、timeEncoder决定时间戳格式如iso8601、epochoutputPaths/errorOutputPaths普通日志与错误日志的输出位置Knative 组件通常输出到stdout/stderr便于被容器运行时收集development开发模式开关为true时输出堆栈信息更详细生产环境建议为false。需要说明的是除文档明确列出的level、encoding、encoderConfig三个键外其余字段如outputPaths、development是 zap 配置模型自带的通用字段语义可参考 zap 项目对配置的说明。loglevel. 组件级覆盖当需要单独调高或调低某个组件的日志级别时使用loglevel.component键其中component为组件名。例如apiVersion: v1 kind: ConfigMap metadata: name: config-logging namespace: knative-serving data: zap-logger-config: | { level: info, encoding: json, outputPaths: [stdout], errorOutputPaths: [stderr], encoderConfig: { timeKey: ts, levelKey: level, messageKey: msg } } loglevel.controller: debug loglevel.webhook: debug上述配置表示命名空间内组件默认日志级别为info但名为controller和webhook的组件被单独覆盖为debug。这种全局默认 局部覆盖的设计使管理员既能控制整体日志量又能在排查特定组件问题时精准放大日志无需改动其他组件。Zap 支持的日志级别config-logging中的level与loglevel.component取值来自 zap 定义的 7 个级别从低到高依次为级别含义debug细粒度调试信息通常只在排查问题时启用info正常运行时的一般日志是生产环境的常见默认值warn意外但非致命的问题程序仍可继续运行error严重错误正常操作中不应出现dpanic开发模式下会触发 panic崩溃非开发模式行为同 errorpanic立即触发 panic崩溃并打印堆栈fatal立即以退出码 1 退出进程失败zap 的过滤规则是只有达到或高于配置级别的消息才会被输出。因此设为debug会输出全部 7 个级别的日志日志量最大适合临时排查设为info会输出info及以上即warn、error、dpanic、panic、fatal忽略debug是大多数生产环境的推荐配置设为error则只输出error及以上的关键信息日志量最小。实战修改 Serving 组件的日志级别以将knative-serving命名空间下组件日志级别从默认info调低到debug为例完整操作步骤如下。第 1 步查看当前配置kubectl get configmap config-logging -n knative-serving -o yaml第 2 步应用新配置将上文示例中的zap-logger-config.level改为debug或直接创建如下 ConfigMap 并应用apiVersion: v1 kind: ConfigMap metadata: name: config-logging namespace: knative-serving data: zap-logger-config: | { level: debug, encoding: json, outputPaths: [stdout], errorOutputPaths: [stderr] }kubectl apply -f config-logging-debug.yaml第 3 步重启组件使配置生效ConfigMap 的变更需要对应组件重新加载配置才会生效可滚动重启目标 Deploymentkubectl rollout restart deployment -n knative-serving component-deployment第 4 步验证查看组件日志确认出现debug级别记录kubectl logs -n knative-serving deployment/component-deployment提示排查完问题后请将级别恢复为info避免 debug 级别日志长期占用存储与 IO。扩展Kafka 数据面组件的日志配置需要特别说明的是Knative 生态中部分数据面组件不走config-logging机制而是使用独立的 ConfigMap。以 Kafka Broker 数据面kafka-broker-receiver、kafka-broker-dispatcher为例其日志配置位于knative-eventing命名空间的kafka-config-loggingConfigMap且采用 logback XML 格式而非 zap JSON。安装时创建的默认配置如下见 Kafka 安装文档apiVersion: v1 kind: ConfigMap metadata: name: kafka-config-logging namespace: knative-eventing data: config.xml: | configuration appender namejsonConsoleAppender classch.qos.logback.core.ConsoleAppender encoder classnet.logstash.logback.encoder.LogstashEncoder/ /appender root levelINFO appender-ref refjsonConsoleAppender/ /root /configuration要将数据面日志级别改为DEBUG将上述config.xml中root levelINFO改为root levelDEBUG重新应用 ConfigMap滚动重启两个 Deploymentkubectl rollout restart deployment -n knative-eventing kafka-broker-receiver kubectl rollout restart deployment -n knative-eventing kafka-broker-dispatcher此外在 Kafka Broker 的部署形态中config-tracing与kafka-config-logging等 ConfigMap 是从安装时整体下发的因此这类数据面组件的日志无法按命名空间粒度单独配置参见 Kafka Broker 说明。与日志收集的衔接config-logging解决的是组件输出哪些日志的问题而如何把日志集中起来则属于日志收集环节。Knative 官方推荐使用 Fluent Bit 作为日志处理器与转发器在每个节点上运行转发 DaemonSet并在集群内运行一个 collector收集日志、Eventing 收集日志。仓库提供了开箱即用的清单文件fluent-bit-collector.yaml定义 collector StatefulSet 与访问日志的 Service会将日志按 Knative 服务、带app标签的 Pod、Pod 名三类规则分拣fluent-bit-configmap.yaml定义转发端 Fluent Bit 的 input/filter/output 配置其中output-forward.conf将日志通过 forward 协议发送到log-collector.logging:24224。典型的集中收集操作# 部署 collector默认创建在 logging 命名空间 kubectl apply -f docs/versioned/serving/observability/logging/fluent-bit-collector.yaml # 通过端口转发在浏览器中查看日志 kubectl port-forward --namespace logging service/log-collector 8080:80如果 Fluent Bit 配置有变更需要删除 collector Pod 让其被 StatefulSet 重建以重新加载 ConfigMap。其他相关日志配置除了控制面组件的config-loggingKnative Serving 还提供了请求级日志request logs的独立配置它由knative-serving命名空间的config-observabilityConfigMap 管理并由 queue-proxy 边车输出支持logging.enable-request-log、logging.enable-probe-request-log、logging.request-log-template三个键分别控制请求日志开关、探针请求日志开关以及请求日志模板必须是单行的 Go text/template多行会被大多数采集代理拆分成多条记录。详见 配置请求日志设置。另外从仓库的发布记录可以看到config-loggingConfigMap 在后续版本中持续演进例如 v1.23 版本为config-logging新增了klog-verbosity标志使运维人员无需重新部署即可更精细地控制日志详细程度见 v1.23 发布说明。这说明config-logging是 Knative 日志运维的长期核心入口值得管理员重点掌握。小结Knative 的日志配置体系可以归纳为三点统一入口控制面组件日志统一由命名空间级config-loggingConfigMap 管理Serving 与 Eventing 各管各的zap 驱动配置核心是zap-logger-configJSON 对象通过level、encoding、encoderConfig控制日志级别、输出格式与记录字段精细控制loglevel.component支持按组件覆盖级别配合达到或超过该级别才输出的 zap 过滤规则可灵活平衡日志详略Kafka 数据面等特殊组件则使用独立的kafka-config-loggingConfigMap。掌握这些配置键与操作流程即可对 Knative 集群的日志输出进行精准、可控的运维管理。赞分享文档教程云原生【免费下载链接】docsUser documentation for Knative components.项目地址https://gitcode.com/gh_mirrors/docs1/docs点击查看免费下载相关推荐Knative 组件日志配置完全指南深入解析 config-logging ConfigMap 与 zap 日志体系Knative 组件日志配置完全指南深入解析 config logging ConfigMap 与 zap 日志体系 Knative Serving 与 Ev文档教程云原生OctoPrint Logging 插件深度指南日志文件管理 API、日志级别动态配置与源码剖析OctoPrint Logging 插件深度指南日志文件管理 API、日志级别动态配置与源码剖析 导读 本文以 OctoPrint 内置 Logging 插件物联网后端TDengine 日志系统深度解析普通日志、慢日志与日志级别配置指南TDengine 日志系统深度解析普通日志、慢日志与日志级别配置指南 导读 TDengine 通过日志文件记录系统运行状态是日常运维监控与问题排查的第一手依数据库时序数据库物联网大数据实时分析云原生上一篇如何5分钟内用resnet18.a3_in1k实现精准图像分类完整实战教程下一篇Terraform AWS Provider 数据源 aws_ec2_hosts 完全指南按条件批量查询 EC2 Dedicated Hosts创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考