这篇文章主要讲解了“Kubernetes日志采集与监控告警知识点有哪些”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“Kubernetes日志采集与监控告警知识点有哪些”吧！
日志采集场景
日志采集场景主要分为以下四种：
集群核心组件日志：
审计需要 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 等成熟日志收集组件可使用。
选型推荐
监控场景
从监控类型划分，可分为以下几个场景:
资源监控：
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 的运维实现自动化。
感谢各位的阅读，以上就是“Kubernetes日志采集与监控告警知识点有哪些”的内容了，经过本文的学习后，相信大家对Kubernetes日志采集与监控告警知识点有哪些这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是亿速云，小编将为大家推送更多相关知识点的文章，欢迎关注！
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
