Kubernetes学习目录
1、监控基础
1.1、监控机制
1.1.1、数据层面
我们如果要监控数据，首先得有数据，也就是说，这些数据应该可以被记录下来，或者被暴露出来，数据常见的产生、直接或间接暴露方式的方式如下：
1、硬件本身的记录信息 - 以文件或者以内存属性的方式存在
2、应用业务的接口 - 主动暴露软件本身的运行状态，比如 redis info、各种status等
3、相关的信息采集工具 - 方便收集数据或者采集数据的 系统级别的命令等
注意：
这些数据在长时间的运行过程中，都是以固定的"属性指标"来描述他们，我们把这些称为 metric。我
们的监控系统就需要对每个环境的每一个指标都要进行数据的获取，并且按照用户需要的方式提供给用户来使用。
1.1.2、采集层面
对于上面所说的Metric指标数据，我们不是说只要一次就可以了，而是需要持续性、周期性的方式来采集。
我们根据数据采集方式的不同划分为了两个分类：
软件层面：
1、Agent: 专用的软件的一种应用机制。
2、SSH: 系统常见的一种应用通信机制，但是并非所有。
3、SNMP: 简单网络管理协议(Simple Network Management Protocol),是工作在各种网络设备中的一种机制。
硬件层面：
1、IPMI: 智慧平台管理接口(Intelligent Platform Management Interface)是一种工业标准用于采集硬件设备的各种物理健康状态数据，如温度、电压、风扇工作状态、电源状态等。
注意：
由于每个业务场景，我们需要采集的指标量不好评估，甚至一个业务场景，就需要采集数百个指标，如果按照上述所说的周期性采集的方式来说，数据的采集量是相当大的
1.1.3、存储层面
由于我们采集到的"样本数据"，不是一次性使用的，尤其是单个数据是没有意义的，我们需要将这些数据存储下来，他是在后续的工作场景中进行聚合操作，从而来满足我们的需求。所以这些数据的存储也是一个
非常重要的点。同时，我们在后续使用这些数据的时候，不仅仅要知道这些数据，还要知道这些数据的时间属性--什么时候的数据。所以这些数据在存储的时候，必须有一个重要的时间维度。
所以我们一般将这种用于监控场景的数据，称为时间序列数据 - TS(Time series data),专门用于存储这些数据的数据库，我们称其为时序数据库(TSDB Time series database)
时序列数据库是用来存储时序列（time-series）数据并以时间（点或区间）建立索引的软件。一般时序列数据都具备数据结构简单：某一度量指标在某一时间点只会有一个值，
没有复杂的结构（嵌套、层次等）和关系（关联、主外键等）。
数据量大：由于时序列数据由所监控的大量数据源来产生、收集和发送，比如主机、IoT设备、终端或App等
刚才我们说了，采集到的单条数据，本身没有太大的意义，我们需要对数据进行各种聚合操作才可以正常的用于工作分析场景。所以对于各种聚合操作之后的数据，我们也需要进行存储操作。
参考资料：https://db-engines.com/en/ranking/time+series+dbms
1.1.4、展示层面
无论是采集到的时序数据，还是经过聚合分析之后的统计数据，我们用眼睛看基本上很少人能够看得懂，尤其是通过表格来查看成千上万条数据，
来分析其内在的逻辑趋势关系。所以，对于监控系统来说，其本身的数据可视化功能是非常重要的，以各种图形演示的方式展示我们数据的发展趋势，方便我们进行分析。
作为人是有休息的时候，有打盹的时候，不可能时时刻刻处于精神紧张的状态，所以我们需要在某些特殊情况下，提醒我们去看相关的数据，所以我们就需要根据日常工作中采集到的数据，来分析出正常的状态值，
然后将其作为一个阈值指标。接下来在后续数据采集的时候，让实时的数据，与阈值进行比较，一旦超出我们的阈值判断机制，就通过告警机制通知给我们。提高我们的工作效率。
所以,一个监控系统需要包括如下的部分：采集、存储、展示等。
1.2、监控设施-实现方式
1.2.1、系统命令
1.2.2、开源软件
Cacti、nagios、zabbix、Prometheus等
1.2.3、监控平台
1.3、监控内容
1.3.1、资源数据
硬件设备：服务器、路由器、交换机、IO系统等
应用软件：OS、网络、应用软件、容器、VM实例等
1.3.2、业务服务监控
业务状态：服务通信、服务运行、服务下线、性能指标、QPS、DAU日活、转化率、业务接口等
一般故障：主机宕机、服务不可用、主机不可达
严重故障：存储空间不足，数据同步延迟，节点宕机
1.3.3、趋势分析
数据统计：时间序列数据展示历史数据等
数据预测：事件什么时候发生、持续时间、发生概率是多大等
1.4、总结
监控方法：agent|ssh|SNMP|IPMI。
实现方式：系统命令、开源软件、监控平台等。
监控内容：资源数据、业务服务、趋势分析等。
2、Prometheus-软件介绍
2.1、简介
2.1.1、软件简介
Prometheus 作为生态圈 Cloud Native Computing Foundation（CNCF）中的重要一员Prometheus 本身基于Go语言开发的一套开源的系统监控报警框架和时序列数据库(TSDB)。它启发于
Google 的 borgmon 监控系统，在一定程度上可以理解为，Google BorgMon监控系统的开源版本。
该软件由工作在 SoundCloud 的 google 前员工在 2012 年创建，作为社区开源项目进行开发，并于 2015 年正式发布。2016 年，Prometheus 正式加入 Cloud Native Computing Foundation，
随着容器技术的迅速发展，Kubernetes 已然成为大家追捧的容器集群管理系统。其活跃度仅次于Kubernetes的开源项目, 现已广泛用于容器集群的监控系统中，当然不仅限于容器集群。
Prometheus功能更完善、更全面，性能也足够支撑上万台规模的集群。
2.1.2、官方参考文档
网站：https://prometheus.io/
github：https://github.com/prometheus
最新版本：2.43.0 / 2023-03-21
2.1.3、软件特点
Dimensional data # 尺寸数据
Powerful queries # 强大的查询功能
Great visualization # 出色的可视化效果
Efficient storage # 高效的存储
Simple operation # 简单操作
Precise alerting # 精确报警
Many client libraries # 许多客户端库
Many integrations # 许多集成
2.1.4、数据特点
监控指标，采用独创的指标格式，我们称之为Prometheus格式，这个格式在监控场景中非常常见。
数据标签，支持多维度标签，每个独立的标签组合都代表一个独立的时间序列。
数据处理，prometheus内部支持多种数据的聚合、切割、切片等功能。
数据存储，prometheus支持双精度浮点型数据存储。
缺点：不能存储文本，所以对于日志的数据采集做不到，只不过它有替代产品软件叫loki。
2.1.5、适用场景
Prometheus非常适合记录任何纯数字时间序列。它既适合以机器为中心的监控场景，也适合于高度动态的面向服务的体系结构的监控场景。
尤其是在微服务世界中，它对多维数据收集和查询的支持是一种特别的优势。Prometheus的设计旨在提高可靠性，使其成为中断期间要使用的系统，以使您能够快速诊断问题。每个
Prometheus服务器都是独立的，而不依赖于网络存储或其他远程服务。当基础结构的其他部分故障时，您可以依靠它，并且无需设置广泛的基础结构即可使用它。
由于Prometheus重视可靠性。在故障情况下，我们可以查看有关系统的可用统计信息。但是如果您需要100％的准确性，则Prometheus并不是一个不错的选择，因为所收集的数据可能不会足够详细和完整。在这
种情况下，最好使用其他系统来收集和分析数据以进行计费，并使用Prometheus进行其余的监视。
2.2、实现原理
2.2.1、数据逻辑
Prometheus同其它TSDB相比有一个非常典型的特性：它主动从各Target上“拉取（pull)”数据，而非等待被监控端的“推送（push）”；
两个方式各有优劣，其中，Pull模型的优势在于：
集中控制：有利于将配置集在Prometheus Server上完成，包括指标及采取速率等；
Prometheus的根本目标在于收集在Target上预先完成聚合的聚合型数据，而非一款由事件驱动的存储系统；
2.2.2、prometheus架构图
从上图可以看出，Prometheus 的主要模块包括：Prometheus server, exporters, Pushgateway, PromQL, Alertmanager 以及图形界面。
2.2.3、工作流程
1、Prometheus server 定期从配置好的 jobs 或者 exporters 中拉 metrics，或者接收来自Pushgateway 发过来的 metrics，或者从其他的 Prometheus server 中拉 metrics。
2、Prometheus server 在本地存储收集到的 metrics，并运行已定义好的 alert.rules，记录新的时间序列或者向 Alertmanager 推送警报，实现一定程度上的完全冗余功能。
3、Alertmanager 根据配置文件，对接收到的警报进行去重分组，根据路由配置，向对应主机发出告警。
4、集成Grafana或其他API作为图形界面，用于可视化收集的数据。
2.3、Prometheus软件组件组成
2.3.1、Prometheus Server
彼此独立运行，仅依靠其本地存储来实现其核心功能：抓取时序数据，规则处理和警报等。
2.3.2、Client Library
客户端库，为需要监控的服务生成相应的 metrics 并暴露给 Prometheus
server。当 Prometheus server 来 pull 时，直接返回实时状态的 metrics。
2.3.3、Push Gateway
主要用于短期的 jobs。由于这类 jobs 存在时间较短，可能在 Prometheus 来pull 之前就消失了。
为此，这次 jobs 可以直接向 Prometheus server 端推送它们的 metrics。
这种方式主要用于服务层面的 metrics，对于机器层面的metrices，需要使用 node exporter。
2.3.4、Exporters
部署到第三方软件主机上，用于暴露已有的第三方服务的 metrics 给Prometheus。
2.3.5、Alertmanager
从 Prometheus server 端接收到 alerts 后，会进行去除重复数据，分组，并路由到对应的接受方式，以高效向用户完成告警信息发送。常见的接收方式有：
电子邮件，pagerduty，OpsGenie, webhook 等,一些其他的工具。
2.3.6、Data Visualization
Prometheus Web UI （Prometheus Server内建），及Grafana等
2.3.7、Service Discovery
动态发现待监控的Target，从而完成监控配置的重要组件，在容器化环境中尤为有用；该组件目前由Prometheus Server内建支持；
2.4、总结
Prometheus简介：
企业级开源运维平台、大数据量场景下监控、时序数据等
实现原理：
Prometheus server 通过多种方式获取数据，将数据处理后存储到本地
Prometheus server 根据预定义规则进行数据分析，直接处理或者通过Alertmanager 处理。
集成API形式的图形界面，并进行可视化收集的数据。
软件结构
Prometheus Server、Push Gateway、Alertmanager、Client Library、Exporters
3、Prometheus-基本概念
3.1、数据模型
3.1.1、介绍
Prometheus中存储的数据为时间序列，即基于同一度量标准或者同一时间维度的数据流。除了时间序列数据的正常存储之外，
Prometheus还会基于原始数据临时生成新的时间序列数据，用于后续查询的依据或结果。
每个时间序列都由metric名称和标签(可选键值对)组合成唯一标识。
3.1.2、metric名字
该名字必须有意义，用于表示 metric 的一般性功能，例如：http_requests_total, 表示 http 请求的总数。
metric 名字由 ASCII 字符，数字，下划线，以及冒号组成，且必须满足正则表达式 [a-zA-Z_:][azA-Z0-9_:]*的查询需求。
注意：冒号是为用户定义的记录规则保留的。
3.1.3、标签
标签是以键值对的样式而存在，不同的标签用于表示时间序列的不同维度标识。
基本格式：<metric name>{<label name>=<label value>, …}
简单样式：http_requests_total{method="POST",endpoint="/api/tracks"}
解析：
http_requests_total{method="POST"} 表示所有 http 请求中的 POST 请求，endpoint="/api/tracks"表示请求的url地址是/api/tracks。
当 method="GET" 时，则为新的一个metric。
标签中的键名由 ASCII 字符，数字，以及下划线组成，且必须满足正则表达式 [a-zA-Z_:][a-zA-Z0-9_:]*。以__开头的标签名称保留供内部使用。
标签值可以包含任何Unicode字符，标签值为空的标签被认为等同于不存在的标签。
3.2、数据特性
3.2.1、介绍
这些metric数据，是基于HTTP call方式来进行获取的，从对方的配置文件中指定的网络端点(endpoint)，上周期性获取指标数据。每一个端点上几乎不可能只有一个数据指标。
3.2.2、数据拉取流程图
3.3、数据获取
根据上面的了解，这些指标都必须以http的方式暴露出来，而这也是，prometheus无法直接获取内核等相关数据的原因，只能借助于其他的机制才可以。
3.3.1、数据获取-途径
方式 解析
Exporters 部署到对应节点上，负责从目标应用程序上采集和聚合原始格式的数据，并转换或聚合为Prometheus格式的指标，以http方式向外暴露本地节点数据后。
Instrumentation 指附加到应用程序中形成内建的检测系统，采集数据并暴露出来的客户端库，当然了，暴露的方式也是http方式。
Pushgateway 接收节点上的任务机制获取数据并转换成prometheus格式数据，然后推送给prometheus。
3.3.2、数据获取-流程图
3.4、指标类型
Prometheus客户端库提供了四种核心度量标准类型。这些仅在客户端库和有线协议中有所区别。
Prometheus服务器尚未使用类型信息，而是将所有数据展平为未键入的时间序列。 将来可能会改变。
3.4.1、Counter - 累计图
counter是一个累加的 metric，代表一个单调递增的计数器，其值只能在重新启动时增加或重置为零。典型的应用如：请求的个数，任务的完成数量或错误数量等。不要使用Counter来表示递减值。例如，当前正在运行的进程数。
3.4.2、Gauge - 量规图
Gauge是一种度量标准，代表可以任意metric的上下波动的数值。通常用于测量值，例如温度或当前的内存使用量，还用于可能上升和下降的“计数”，例如并发请求数。
3.4.3、Histogram - 直方图
每个存储桶都以"_BucketFuncName{...}" 样式来命名.例如 hist_sum、hist_count等
我们还可以基于histogram_quantile()函数对直方图甚至是直方图的聚合来进行各种分析计算。
我们还可以基于histogram_quantile()函数对直方图甚至是直方图的聚合来进行各种分析计算。
3.4.4、Summary - 摘要
类似于直方图，摘要会基于阶段性的采样观察结果进行信息描述。它还提供了观测值的累计计算、百分位计算等功能，每个摘要的命名与Histogram 类似，例如：summary_sum、summary_count等
3.5、任务实例-instance
3.5.1、instance术语介绍
用Prometheus术语来说，一个单独 scrape(<host>:<port>)的目标称为instance，通常对应于单个进程。 一组同种类型的 instances集合称为jobs，主要用于保证可扩展性和可靠性。
3.5.2、instance流程图
3.5.3、使用样式-示例
一个API服务job包含四个 instances:
job: api-server
instance 1: 1.2.3.4:5670
instance 2: 1.2.3.4:5671
instance 3: 5.6.7.8:5670
instance 4: 5.6.7.8:5671
对于任务实例来说，他们还可以借助于特殊的字符串来表示通用的功能，常见的使用样式如下：
判断任务是否健康，1代表正常，0代表不正常
up{job="<job-name>", instance="<instance-id>"}
获取任务的持续时间
scrape_duration_seconds{job="<job-name>", instance="<instance-id>"}
任务执行后剩余的样本数
scrape_samples_post_metric_relabeling{job="<job-name>", instance="<instanceid>"}
暴露的样本数量
scrape_samples_scraped{job="<job-name>", instance="<instance-id>"}
样本的大概数量
scrape_series_added{job="<job-name>", instance="<instance-id>"}
3.6、总结
数据模型：metric名称+标签
数据类型：Counter+Gauge+Histogram+Summary
任务：多个instances组成一个jobs
4、Prometheus-进阶-基本概念
4.1、数据处理
4.1.1、PromQL
Prometheus提供了内置的数据查询语言PromQL（全称为Prometheus Query Language），支持用户进行实时的数据查询及聚合操作；
PromQL支持处理两种向量，并内置提供了一组用于数据处理的函数
1)、即时向量：最近一次的时间戳上跟踪的数据指标；
2)、时间范围向量：指定时间范围内的所有时间戳上的数据指标；
4.1.2、示例图
4.2、数据告警
4.2.1、AlertManager
抓取到异常值后，Prometheus支持通过“告警（Alert）”机制向用户发送反馈或警示，以触发用户能够及时采取应对措施；
但是Prometheus Server仅负责生成告警指示，具体的告警行为由另一个独立的应用程序
AlertManager负责；
- 告警指示由Prometheus Server基于用户提供的“告警规则”周期性计算生成；
- Alertmanager接收到Prometheus Server 发来的告警指示后，基于用户定义的告警路由(route)向告警接收人发送告警信息；
4.2.2、AlertManager流程图
