【公开课】Kubernetes 日志采集与监控告警
【百度云原生导读】本节课是 Kubernetes 入门课程的最后一课,关注『云原生计算』公众号,回复"k8s",获取课程配套pdf。
本节课主要分为以下四个部分:
1. 容器日志采集与管理
Kubernetes 日志处理方案
2. 容器监控指标的采集与管理
以Prometheus 为核心的统一监控方案
3. Demo
演示云原生环境日志采集与指标监控
4. 总结
总结日志采集与指标监控要点
1. 容器日志采集与管理
日志采集场景
日志采集场景主要分为以下四种:
集群核心组件日志:
审计需要 kube-apiserver 日志,诊断调度需要 kube-scheduler 日志,接入层流量分析需要 Ingress 日志。
主机内核日志:
内核日志可以用于帮助开发及运维同学诊断影响节点稳定的异常,如:文件系统异常,网络栈异常,设备驱动异常等。
应用运行时日志:
Docker 是最常见的容器运行时,可以利用 Docker 和 Kubelet 日志排查 Pod 创建和启动失败等问题。
业务应用日志:
通过分析业务的运行日志分析和观察业务状态,诊断异常。
日志采集指标
Kubernetes 对容器日志的期望处理方式为:集群级日志处理(cluster-level-logging)
即:与容器、Pod、节点生命周期完全无关。
对于一个容器,当应用将日志输出到 stdout 和 stderr 后,docker 默认将这些日志输出到宿主机上一个 JSON 文件中。
日志采集方式
Kubernetes 本身并不会对用户进行任何的日志搜集工作。为了实现集群级日志处理,需要在集群前,提前对日志采集管理进行方案规划。
Kubernetes 本身推荐3种日志方案。
日志采集方式1:使用节点级日志代理
核心是 logging-agent (fluentd,etc );
Logging-agent 以 DaemonSet 方式运行在节点上;
挂载宿主机上的容器日志目录;
转发日志至后端存储(ElasticSearch, etc);
优点:对应用和Pod完全无侵入,一个节点仅需部署一个 agent。
缺点:要求应用日志直接输出至容器的 stdout 和 stderr。
日志采集方式2:使用 sidecar 容器和日志代理
容器全部或部分日志输出到文件
一个或多个 sidecar 容器将应用程序日志传送到自己的 stdout 和 stderr。
优点:能够继续使用日志采集方式1。
缺点:成倍增加磁盘占用,造成浪费。(应用和sidecar容器写入两份相同日志文件)
日志采集方式3:使用具有日志代理功能的 sidecar 容器
相当于将 logging-agent 直接集成进 Pod。
应用和输出日志至 stdout&stderr 或文件。
Logging-agent 的输入源为应用日志文件。
优点:部署简单,对宿主机友好。
缺点:1. Sidecar 容器可能消耗较多资源,甚至拖挂应用容器。
2. 无法使用 kubectl logs 命令查看容器日志。
总结:
实现集群级日志采集的三种方式:
-
使用节点级日志代理。
-
使用 sidecar 容器和日志代理。
-
使用具有日志代理功能的 sidecar 容器。
建议:使用方案1,将应用日志输出到 stdout&stderr,通过宿主机上直接部署logging-agent 的方式集中处理日志。
-
管理简单。
-
可以使用 kubectl logs 命令查看日志。
-
宿主机本身可能已有 rstlogd 等成熟日志收集组件可使用。
选型推荐
2. 容器监控指标的采集与管理
监控场景
从监控类型划分,可分为以下几个场景:
资源监控:
CPU,内存,网络等资源类指标,常以数值,百分比为单位进行统计,是最常见的资源监控方式。
性能监控:
应用的内部监控。通常是 Hock 机制在虚拟机层,字节码执行层隐式回调,或者在应用层显式注入,获取更深层次的监控指标,常用来应用诊断与调优。
比如 Jvm 通过 Hock 机制,拿到类似 Jvm 里面的垃圾回收的次数,各种内存带的分布以及网络连接数的一些指标。通过这样的方式来进行应用的诊断与调优。
安全监控:
针对安全进行一系列监控策略,例如越权管理,安全漏洞扫描等。
事件监控:
Kubernetes 中特有的监控方式,贴合 Kubernetes 设计理念,作为常规监控方案的补充。
为什么说事件监控贴合 Kubernetes 设计理念呢?这是因为 Kubernetes 其中一个设计理念就是基于状态机的状态转换。从正常状态转换成另一个状态的时候,会发生一个 Normal 级别的事件(也就是正常的事件)而从一个正常状态转换成异常状态时,平台会触发一个 Warning 级别(也就是警告级别的事件)通常,Warning 级别的事件是我们关心的事件。
而事件监控就可以把 Normal 级别的事件或 Warning 级别的事件离线存储到数据中心,然后通过数据中心的分析与报警,将相应的异常通过短信,邮件的方式暴露,弥补常规监控的弊端。
Prometheus 的起源及现状
Prometheus 与 Kubernetes 一样,来自于 Borg 体系。原型叫做 BorgMon,是与Borg同时诞生的内部监控系统。而Prometheus项目发起的原因也与Kubernetes 类似,希望通过对用户更友好的方式,将 Google 内部系统的设计理念传递给开发者和用户。
Kubernetes 监控体系曾经非常繁杂,但今天已经演变成了以 Prometheus 为核心的一套统一的方案。
Prometheus 的架构与工作方式
Prometheus 指标来源
-
宿主机的监控数据:需要借助 Node Exporter 向外暴露; Exporter 代替被监控对象来向 Prometheus 暴露可以被抓取的指标信息。
-
Kubernetes 组件如 APIServer, kubelet 等的/metrics AP:除CPU,内存外,还包括各个组件的核心监控指标。
-
Kubernetes 核心的监控数据:包括Pod、Node、容器、Service等主要核心概念的 metrics,其中容器相关的指标来源于 kubectl 内置的 cAdvisor 服务。
Prometheus 特点
-
简洁强大的接入标准。只要实现 Promethus Client 接口,就可以直接实现数据的采集。
-
多种数据采集方式。包括:在线,离线,push, pull 联邦的方式进行数据采集。
-
和 Kubernetes完 全兼容。
-
丰富的插件机制和生态。
-
Prometheus Operator 助力。使 Prometheus 的运维实现自动化。
3. Demo 演示
讲师最后演示了 Kubernetes 环境下日志采集与指标监控的一个 Demo。感兴趣的同学可以点击视频观看。https://cloud.baidu.com/video-center/video.html?id=610
相关阅读:
【公开课】Kubernetes 入门——深入浅出讲 Docker
重磅!云原生计算交流群成立
扫码添加小助手即可申请加入,一定要备注:名字-公司/学校-地区,根据格式备注,才能通过且邀请进群。
了解更多微服务、云原生技术的相关信息,请关注我们的微信公众号【云原生计算】!

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
Furion 让开发者重新认识了 .NET,v2.4.0 发布
让 .NET 开发更简单,更通用,更流行。 庆祝 5K 说点 自 2020年09月01日 发布以来,Furion 一直高速发展,Stars 趋势图也勾勒出了指数增长的线条美,截至今日,诞生 7个月12天。 今天,Furion 项目在 Gitee 平台突破了 5K Stars,QQ 交流群成员达 6200 +,Nuget 下载破 260K。或许5K Stars 对 Java 项目来说只是个小目标,但对国内.NET 开源项目来说,无疑是梦想中的目标。 当然 Stars 的多少并不能决定项目优秀与否,但是从侧面也能反映出 .NET 正在崛起。 作者贡献度: https://gitee.com/monksoul 项目概况图: https://gitee.com/dotnetchina/Furion Stars 趋势图: https://whnb.wang/dotnetchina/Furion?e=43200 贡献者画像: https://giteye.net/chart/ZS49EPL6 框架文档: https://dotnetchina.gitee.io/furion/ 本期更新 新特性 [...
- 下一篇
聊聊各端手势体系以及对 Web 标准手势的思考
「北海 Kraken」是一款基于 Flutter 的 Web 渲染引擎,通过基于 W3C 标准来开发实现前端开发者常用的能力。 Kraken 团队也积极探索定义新的问题以及能力,期望通过参推动标准定制的方式让 Web 技术变得更好。 欢迎大家关注 「北海 Kraken」: http://openkraken.com/ 在过去,早期的 Web 更多用做内容展示的页面,最早从后端框架中直出,再配上各种 CSS 以及 JS 的交互内容,以完成最终对页面内容的展示,那时候的 Web 更多属于 【内容开发】,做内容的直出与展示。而如今现代 Web 开发体系已经有了翻天覆地的变化,早已超出了【内容开发】的范畴,在各个领域都有 JavaScript 的身影。同样,Web 也已经脱离了客户端以及浏览器的限制,各式各样基于 Web 标准或者私有标准的 Web runtime 层出不穷。【Web 应用开发】区别于传统的【内容开发】,它对开发者提出了更高的要求,也对 Web 的能力提出了更高的要求,无论是基于标准化方面的考量,还是基于对易用性的考虑,我们都期望 Web 开发者可以获得通过更高级的封装的标准的...
相关文章
文章评论
共有0条评论来说两句吧...