Kubernetes 稳定性保障手册 — 日志专题【图文】_程序员小虎

Kubernetes 稳定性保障手册 -- 日志专题【图文】_程序员小虎

从长期角度来看,交互环节出问题的概率会比自身逻辑出问题的概率高,因此要重点关注交互环节的日志逻辑。

同时,对日志的管理需要意识到 _谁会使用这些日志,_通常有 4 类角色:

  • 用户

  • 维护者

  • 安全人员

  • 审计人员

用户从黑盒角度使用软件,通过日志了解软件当前的运行状态,关注重点是软件正常的状态。

维护者从白盒角度使用软件,开发角色通过日志调试软件,SRE 角色通过日志及时感知软件的异常状态,并通过日志上下文分析异常原因。

安全人员通过分析日志,了解恶意登录、异常删除等风险。

审计人员通过审计日志、应用日志,确认业务、架构的合规性。

根据上述不同的使用场景,我们可以梳理出几类日志类别,进一步增强开发和运行阶段对日志的理解:

Kubernetes 稳定性保障手册 -- 日志专题【图文】_程序员小虎

[](

)开发阶段


[](

)最佳实践

理解了日志使用者关注的重点后,开发阶段写日志时,推荐使用如下最佳实践:

  • 使用 structured logs

    • 不使用 format strings
  • 使用 info 和 error 表征日志级别

    • info 又可细化为多个级别,0~10,信息的重要性依次降低 (也可以参考[《Kubernetes: sig-instrumentation/logging.md》](

)

    *   0:用户想要看到的信息      *   1:维护者关注的白盒行为信息      *   10: 维护者调试用的信息
  • 使用具有过滤器能力的 log lib,通过 logger 自动过滤敏感信息

    • 参见 [《KEP: Kubernetes system components logs sanitization》](

)

  • 日志通过 stdout/stderr 输出,关闭不必要的文本日志

    • 避免额外的磁盘占用、IO 消耗、日志清理任务的维护等

对于 golang,可以考虑使用 [klog](

) 作为 logger 实现。

[](

)FAQ

[](

)为什么使用 structured logs?

structured logs 是一种结构化的日志格式,结构如下,其中 msg 表征通用的事件,多对的 k=v 用来具化事件:

msg k=v k=v … k=v

示例:

“Pod status updated” pod=“kube-system/kubedns” status=“ready”

对于开发阶段,structured logs 通过固化的结构和字段语义,协助开发者思考程序逻辑状态,有助于进一步控制程序复杂度和理解程序逻辑。

对于运行阶段,structured logs 中的 k 天然具备索引的属性,便于进行查询和分析。也可以考虑将 msg 规范化,增加 事件 语义,通过限制 msg 语义来增强 msg 的作用。

[](

)为什么不使用 debug/warning/critical/fatal?

通过减少日志类型,降低使用和维护负担。

debug 可以融入到 info 级别。

warning/critical 对于用户和维护者都是模糊的词,对于要采取的行动通常不具备指导意义。warning/critical 和 error 类似,表征程序运行过程中出现了预期外的现象,此时程序要么自动处理,要么交由外部人工介入判断。若由程序自动处理,那么用户和维护者感知到这类现象即可,info 可以满足。若需要交由外部人工介入,那么 error 就可以满足。对于问题的严重性,可放在运行阶段,通过异常具体的信息来表征,如 ServiceUnavailable、Unauthorized 等。

fatal 是将 error 和 panic 两类逻辑封装了起来,在开发过程中可能会带来执行逻辑上的不清晰,如决定是否 panic 的逻辑需要放在最顶层逻辑中,若在顶层逻辑之下调用 fatal,可能会带来资源泄露、程序运行复杂度增加等问题。

[](

)为什么不使用 format strings?

format strings 是形如如下的结构:

klog.V(4).Infof(“Got a Retry-After %ds response for attempt %d to %v”, seconds, retries, url)

这种结构将 通用事件具体内容 耦合在一起,不利于开发阶段降低理解程序逻辑的成本,也不便于使用阶段通过标准化的方式进行查询、分析,增加日志的使用成本。

一种改善方式:

klog.V(4).InfoS(“got a retry-after response when requesting url”, “attempt”, retries, “after seconds”, seconds, “url”, url)

[](

)为什么要使用具有过滤器能力的 log lib?

开发过程中,可能会由于疏忽而将敏感信息输出到日志中,如密码、token 等信息。为了避免敏感信息泄露,需要加强 code review,同时也可以考虑在 logger 中配置过滤器,自动进行敏感信息的过滤,参见 [《KEP: Kubernetes system components logs sanitization》](

) 。

对于 golang,可以考虑使用 [klog](

) 作为 logger 实现,并配合 [Kubernetes/component-base: sanitization](

) 进行使用。

[](

)运行阶段


[](

)最佳实践

运行阶段是对日志的使用,包括如下 4 个阶段:

  1. 采集

  2. 查询

  3. 分析

  4. 告警

由于日志服务对程序的运行以及后续的运营极为重要,建议采用托管型的日志产品来满足运行阶段对日志的使用需求,如[阿里云的 SLS 产品](

)。

若在多个 region 部署集群,且集群的组件相同,在使用日志产品时,需要确保每个 region 中日志项目名称规则的一致性。以阿里云 SLS 产品为例,若需要分别收集多个 region 的日志,则 project、logstore 的名称需要在多个 region 中保持相同的规则,目的是便于通过统一的方法对不同集群的日志做查询和分析。

通常情况下,日志产品会提供上述 4 个阶段的服务,具体的使用方法可以参见对应日志产品的文档,下述针对告警做重点分析。

[](

)告警

如何快速更新自己的技术积累?

  • 在现有的项目里,深挖技术,比如用到netty可以把相关底层代码和要点都看起来。
  • 如果不知道目前的努力方向,就看自己的领导或公司里技术强的人在学什么。
  • 知道努力方向后不知道该怎么学,就到处去找相关资料然后练习。
  • 学习以后不知道有没有学成,则可以通过面试去检验。

我个人觉得面试也像是一场全新的征程,失败和胜利都是平常之事。所以,劝各位不要因为面试失败而灰心、丧失斗志。也不要因为面试通过而沾沾自喜,等待你的将是更美好的未来,继续加油!

以上面试专题的答小编案整理成面试文档了,文档里有答案详解,以及其他一些大厂面试题目

CodeChina开源项目:【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频】

Kubernetes 稳定性保障手册 -- 日志专题【图文】_程序员小虎

Kubernetes 稳定性保障手册 -- 日志专题【图文】_程序员小虎

本站由小牛团队全力维护,小牛十年了,大家已经步入中年 。本站源码全部经过团队成员测试并调试,价格可能比其它网站略贵几元钱,不解释!
小牛资源 » Kubernetes 稳定性保障手册 — 日志专题【图文】_程序员小虎

发表评论

全站资源亲测可用,价格略高几元,不解释

立即查看 了解详情