开发者学堂课程【DevOps 日志分析实战：容器监控与分析实践】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/302/detail/3519
容器监控与分析实践
内容介绍：
一、怎样构建全方位 Kubernetes 监控
二、如何构建 Prometheus 监控、开发的实践中心包括 Ingress 还有业务
三、部署Prometheus 监控
四、手动开始事件中心
五、分析 Ingress 日志
一、怎样构建全方位 Kubernetes 监控
Kubernetes 给我们带来了很多的好处，比如：容器的编排、弹性的伸缩、负载均衡等；对于开发运维人员：快速构建、监控、无人值守、高可靠、异常自动恢复、高效运维等等。
1、使用的场景上使用 kubernetes 会遇到的问题
因为 kubernetes 并不是去帮我们把所有的包括监控、运维、各种异常恢复全部都做。更多是提供一个平台，这个平台帮我们更快的去做发布、更快的做弹性。然后让我们更好的、更容易去做可观察性。
（1）开发遇到的各种问题
（2）构建全方位的监控、知道什么地方挂了、为什么挂了，之后怎么去恢复。
（3）第一部分：Kubernetes 监控架构分成好几个层次。
①基础设施/事件主要包括几部分：
一部分包括机器的一些CPU、内存这些机器指标、容器指标、容器的内存消耗、容器的重启、容器的网络磁盘、IO等等。
还有一部分就是 Event 信息，开发已经做好的开发 Events ，开发自带的功能，开发的功能发生了重要的事件、主要依赖于 Metrics 监控：比如CPU曲线、内存曲线等等。
Metrics 主要依赖于 Prometheus 来做监控。
②ServiceMesh*: 分布式链入、业务追踪等数据。
③接入层：主要是用开发的 Ingress ,作为整个开发的流量入口，这部分监控也非常重要。一般情况都是采用 Ingress/Nginx ，更多基于 Nginx 的访问日志去做各种各样的监控，包括监控各种监控的站点、后端的响应延迟。
④业务层：业务的监控更多的是依赖业务日志、包括业务日志中的错误信息、以及从业务日志中提取一些关键性的指标去做异常的检测、判断。
从业务价值来说：归于业务监控最有效的、从覆盖面来说：从基础设施相对来说会更广，所以从底层到上开始做。
二、如何构建 Prometheus 监控、开发的实践中心包括 Ingress 还有业务
1、DevOps数据中台架构
从 DevOps 数据中台建构的角度，扮演的一个数据中台的架构，这个数据中台的概念就是支持从各种各样的地方把各种类型的 DevOps 需要用到的一些数据，包括日志、链入追踪的数据、指标数据，从各种各样的数据源比如说：容器、移动端、 IOT 把数据采集上来，进行各种数据分析的方式、SQL 92的语法等等都可以支持，而且还能够支持一些智能的算法，比如：智能聚类、智能预测等等。向上提供可视化的组件，然后帮助我们把数据展现出来、提供一些告警通知、 Webhook 去做一些辅助。
2、基础指标监控- Prometheus 的前世今生
（1）2012年成立，初始成员 Matt、Julius
（2）受谷歌监控系统启发（Borg 监控系统）
（3）主要目标
①监控动态的云上环境
②对现有的监控数据模型、查询、效率等不满意
（4）Prometheus 是CNCF第二大Project
（5）Kubernetes标准化监控方案
（6）开源首选监控方案之一prometheus 架构
3、Prometheus 架构
通过Pull metrics 方式从各个地方去拉数据，相对来说更加的简洁，只需要对应被监控的系统提供一个 HTTP 的端口就能拉取数据，内部就是一个单机的架构，包括数据的接收里面有个服务发现，服务发现里有个重要的模块就是开发的服务发现，能够动态监控一些 Pull metrics 、Server等等。存储依赖于内部的单机的 HDD/SSD 的存储。
PromQL 就是一个查询引擎，后面会对接 Alertmanager 用来做告警，
还有一部分使用来做 UI 的。
（1）Prometheus 架构的特点：
Pull模型、非常强的服务发现、单机的架构、存储依赖的 SSD （HDD标准机械硬盘性能比较差）、Grafana 可视化提供的功能非常少、Alertmanager 用来做告警。
4、Prometheus 应用过程中发现的问题：
（1）内存占用：近两小时数据保存内存，时间线膨胀
（2）异常恢复：binlog replay 时间过长，无限OOM
（3）不支持长期存储：单机存储受限，无法长期对比指标
（4）单机问题：抓取太慢、计算单点执行，很难大规模扩展
（5）Pull模型：很难覆盖实时场景
（6）PromQL ：内部查询引擎，不支持与外部维表关联
5、SLS时序存储-兼容 Prometheus 方案
其中对于时序数据的存储做了一个非常强的扩展，从单机的模式扩展到一个纯分布式的架构，而且提供了默认的 PromQL 执行引擎而且也是分布式的，同时还对时序数据进行 SQL 执行引擎的查询，能够支持对接各种各样的外部的数据语言，关联的分析，也提供一些智能分析的算法，能够帮助我们去做一些智能巡检等等场景。
特点：
（1）丰富上下游：数十种接入方式对接各类下游。
（2）高性能：纯分布是架构存储计算完全分离。
（3）开源友好：对接 Prometheus 、HTTP 、SQL 、Grafana。
（4）智能：时序异常检测根因分析。
6、充分发挥 Prometheus 数据的价值
Prometheus 默认在单机里面其实是一个死的系统，不支持和外部数据语言做对接或者是进行实时的计算。
进行扩展：能够支持各种各样的数据通过 Prometheus 进来，通过Open Telemetry (未来可观察性、大的Project)支持进入，对接三个不同的引擎，SQL 执行引擎、智能分析引擎、默认的PromQL执行引擎，
还有一个功能数据队列，能够支持用实施计算的方式去订阅做一些实施的分析。
7、Prometheus 接入方式
在开发S 的 Prometheus Operator 配一些 Remote Write 的一些写入方式，然后去配一个 basicAuth 去做鉴权，在写入 SIS 就可以了。
整体五个步骤：
（1）创建Namespace
（2）配置保密字典
（3）修改安装包参数
（4）配置 Grafana 可视化
（5）配置警告
8、Kubernetes 事件监控中心
在开发 kubernetes 里面会产生各种各样的事件，能够支持包括宿主机、kube-system、应用 pod 产生的事件都能实时采集到日服务，会提供一整套包括实时告警、事件的查询、自定义分析、可视化报表等等。而且方案开通的成本非常低，只需要在创建机群的时候勾选一下就可以开通。
9、接入层监控- Kuberneies Ingress监控
支持直接去 Ingress 这边，把 Ingress 的访问日志拿到，拿到之后会去提取各种各样的指标，包括 PV同比/环比下跌、TOP延迟、失败延迟等。
10、中间件/ ServiceMesh 监控- Istio 访问日志监控
ServiceMesh 监控主要以 Istio 为代表，主要是兼容 Istio 这边的，访问日志是可以直接对接过来的，如果用 ServiceMesh 可以非常方便把数据接过来，做一些可视化。
11、业务监控- Kubernetes 标准日志监控
业务监控是需要依赖于我们自己去做日志的产生，日志的采集的配置，定义几个环境变量或者部署一个 crd , 就可以去完成，包括容器文件、标准输出，如果文件数据存在数组集藏都可以支持实施采集上来，采集上来之后可以去做日志查看/ Live Tail、日志查询/上下文、关键词监控、交互式分析/可视化、业务指标监控等。
三、部署 Prometheus 监控
1、在阿里云 Kubernetes 上安装 Prometheus
（1）登录容器服务控制台
（2）创建命名空间。
①在左侧导航栏中，单击命名空间。
②单击创建
③配置名称为 monitoring ，并单击确定
（3） 创建保密字典。
①在左侧导航栏中，选择应用配置 > 保密字典
②单击创建
③选择 monitoring 这个命名空间，然后创建一个保密字典，名称为：sis-sk。
④配置如下参数，单击确定。
（4） 创建Project
①project 名称：k8s-prom-bj
②所属地址：华北2（北京）
③点击进去，在时序库里创建 Metricstore 。
④Metricstore 名称：prom 。
⑤调整 prometheusSpec 下的 retention ,建议修改为1d 或12h。
⑥将 tsdb 下的enable 设置为 true,并增加 remoteWrite 配置。
⑦remoteWrite 配置中的 uri 为日志服务 Metricstore 的URI，请根据实际值替换。
⑧如果是在内网：
uri:https://k8s-prom-bj.cn-beijing-intranet.log.aliyuncs.com/prometheus/k8s-prom-bj/prom/api/vi/write
然后拷贝过来，贴在参数中就可以创建。
2、使用 Grafana 访问 Prometheus 数据
（1）登录 Grafana
（2）在左侧导航栏，点击设置 > Data Sources。
（3）在 Data Sources 页签，点击 Add data source。
（4）单击 Prometheus区域中的Select。
（5）Name:Prometheus-test-bj
（6）URL：
https://k8s-prom-bj.cn-beijing.log.aliyuncs.com/prometheus/k8s-prom-bj/prom
（7）打开 Baslc auth 开关
（8）User为阿里云账号的AccessKeyID。
（9）Password为阿里云账号AccessKeySecret。
（10）建议使用仅具备日志服务Project 只读权限的RAM用户的Accesskey。
（11）点击 Save & Test 。
3、导入 Grafana Dashboard 模板
（1）直接去搜索 Grafana Dashoard 的模板
（2）然后再Grafana Dashoard 的左侧直接搜索Kubernetes
（3）选择模板，复制ID
（4）点击Grafana 左侧加号，把ID粘进去，鼠标脱离控制。
①Name:1. Kubernetes ceployment Statefulset Deemorset metrics bj
②Folder:General
③选择prometheus 的数据源 :prometheus-test-bj
④点击 inport
4、开通事件中心
（1）点击左侧容器服务 > 集群
（2）创建集群
①集群名称
②虚拟交换机勾选
③点击下一步：Worker 配置
④实例规格 勾选
⑤设置登录密码和确认密码
⑥下一步：确认配置
⑦组件配置默认就已经把日志服务、node-probem-detector 勾选了，也可以去勾选 Ingress Dashboard，可以自己去部署。
⑧不勾选不装也可以去组建管理开启
四、手动开启事件中心
1、点击左侧导航栏里的集群 > 运维管理 > 组件管理
2、搜索 node-probem-detector
3、没有安装就点击安装
4、安装好之后就会把事件中心开启
五、分析 Ingress 日志
1、在容器控制服务台找到节点池 > 集群 > 连接信息
2、点击通过CloudShell管理集群
3、登录 CloudShell 用命令行进行操作
4、创建 vim ingress-monitoring.yaml ,然后贴上去
5、在保存Kubectl apply -f ingress-monitoring.yaml
之前创建集群都会有默认的ingress ，现在里面是没有什么数据，大盘里面创建各种ingress监控的大盘，ingress里面有各种类型的指标，左侧可以点一些快速的分析，比如有哪些host、client_ip，当然这些分布都比较均匀，还可以去做一些指定的查询比如说：method : Get、not methed:Get ,可以去分析一些状态码的分布Get | SELECT status，count(1) as tatal graup by statud 。
默认会有一个可视化，一个表个的形式，可以自己选择饼状图、树状图、条形图的形式等等。
（1）比较高级的用法：IP的函数：
not methed : Get | SELECT ip_to_province(x_forward_for) as p, count(1) as total group by p order by total desc
就可以查到各个省份分布的信息，点击中国地图就会帮你按照中国地图上的省份自动可视化，数量越高的省份颜色越深。
（2）世界地图：
not methed : Get | SELECT ip_to_country(x_forward_for) as p, count(1) as total group by p order by total desc 就可以查到国家的分布。
（3）经纬度热地图或高德地图：
not methed : Get | SELECT ip_to_city_geo(x_forward_for) as p, count(1) as total group by p order by total desc。
默认做了很多现有的分析，进去之后就会展示出有哪些访问的PV、流量、移动端iOS的占比、平均的延迟、top的一些指标、延迟、错误等等。可以根据不同的纬度去做过滤，还有其他很多的包括监控中心等等。
监控中心里面的指标会更加的丰富，包括访问PV、出流量比列、各种延迟等等，还有一些统计类型的，会让我们更加的方便的从图层拿到各种各样的指标，这些指标都是基于访问日志去分析的基础来的。
也可以跳转到查询分析、原始数据这边。之前创建的事件中心也可以去查看，它可以帮你把各种各样的告警纬度都列在那里，里面的告警都可以进行配置，各种告警只需要去添加通知方式就可以，可以通知到短信、邮件、语音、钉钉机器人，而且可以多个通道并行通知，配置之后去勾选就可以。
默认事件也非常多也列出来了，有哪些非常重要的事件需要去关注，比如：Pod OOM事件、Pod驱逐事件这些关键性的事件都会帮你列出一些详细的信息，详情查询里面可以只关心Warning 等级的事件查询、过滤某一种类型的事件，然后去看这些信息的详细信息，这些信息是帮助我们去做查询，但是他背后也是日志的查询方式。
整体上来说就是基于SIS去构建开发S 的监控，包括我们的Grafana 一些基础的指标、平均CPU的使用率、内存使用率等等。也能够拿到系统内部的一些事件、开发S 的一些事件，比如节点被删除了或者Pod被丢掉了、Pod被销毁了等等这些事件会告诉你方便你直接去做告警。
Ingress 可以根据访问日志去做分析各种各样的服务的指标，自己的业务日志的监控，需要自己去配置一些采集策略。
