自动化监控报警系统
# Prometheus
- 对比zabbix和其他易于开发扩展，同时原生支持的插件也比较多。
- 它不仅仅只能用于k8s，再裸机或者单机也可以。
# 特点
基于http的pull、服务发现/静态配置发现目标，2重大特性。
- 多维数据模型：由度量名称和键值对标识的时间序列数据
- PromSQL: — 种灵活的查询语言，可以利用多维数据完成复杂的查询
- 不依赖分布式存储，单个服务器节点可直接工作
- 基于 HTTP 的 pull 方式釆集时间序列数据
- 推送时间序列数据通过 PushGateway 组件支持
- 通过服务发现或静态配罝发现目标
- 多种图形模式及仪表盘支持 (grafana)
# 整合
- spring-boot项目， 引用spring-boot-starter-actuator和micrometer-registry-prometheus依赖，开启admin监控，配置actuator/prometheus接口到Prometheus
- 监控Mysql性能指标 ： 获得mysqld-exporter镜像，配置监控的mysql地址，在Prometheus中配置target地址
- 监控Redis性能指标 ： 获得redis_exporter镜像，配置监控的redis地址，在Prometheus中配置target地址
- 监控Linux服务器性能指标 ： 获得linux-exporter镜像，配置监控的linux地址，在Prometheus中配置target地址
- 等等，都是启动对应exporter出口商，配置对应中间件的地址，再到Prometheus中配置target地址
# 埋点
在业务层用作埋点系统:
利用spring-admin和Micrometer 做jvm埋点、 还有API做业务埋点。
# Grafana
# 安装部署
# 设置指标
登录后，进入导入页面选择Prometheus，导入对应的展示的指标json文件
# 监控指标报警
- 进入Errors指标的详细面板
- 新增报警渠道：邮件报警、webhook
- 配置指标: 多久统计一次、报错出现几次开始触发
- 配置邮件内容。
# 整合业务
主要采用原生支持的数据源，其他业务只要把数据写到他支持的数据源就行了，剩下报警展示就是Grafana的事了。
业务平台 -> Grafana支持的数据源 -> Grafana设置展示、监控、报警。
可以参考jmeter的整合报告。
#
# jmeter压测报告
步骤: Jmeter 配置 InfluxDB，grafana配置InfluxDB(jmeter的源)，造测试数据，开始压测，看grafana上的监控测试报告。
# 全链路优化
Jmeter 配置 InfluxDB，grafana配置InfluxDB(jmeter的源)、网关jvm、mysql、Prometheus中监控的节点。 编写压测计划，造测试数据，开始压测，看测试报告、skywalking(springmvc/fegin/mysql)和grafana上的监控。
mysql 优化中: 为了减少出现间隙锁，采用delete_status，但是这个字段不走索引就特别慢，又应为delete_status字段的值大多数都是1，而我们查询的sql更多是用0来过滤的，所以理论上建完索引，会大大减少。
# 优化总结
我们发现大多数时候我们系统的瓶颈往往出现在数据库上，所以我们秒杀课里的优化方案是尽可能的让各种操作 被缓存以及其它各种中间件拦截，让他们尽量少的到达mysql数据库。 2、我们之前在mysql系列课里讲过的尽量不要搞太多表关联的sql查询，因为不好优化索引，所以我们建议对于一些 多表的操作能用java做的可以尽量用java做，哪怕java实现可能费时间更多点，但是java应用扩容是很方便的，数据 库扩容是比较麻烦的。
# APISIX整合Grafana (opens new window)
apisix的prometheus插件 -> prometheus -> Grafana -> 配置到APISIX的仪表盘
# 可有的指标
Status codes: upstream 服务返回的 HTTP 状态码，每个服务返回状态码的次数或者所有服务的状态码次数总和都可以统计到。Bandwidth: 流经apisix的总带宽(可分出口带宽和入口带宽). 每个服务指标或者是所有服务指标的总和都可以统计到。etcd reachability: apisix 连接 etcd 的可用性，用 0 和 1来表示。Connections: 各种的 Nginx 连接指标，如 active（正处理的活动连接数），reading（nginx 读取到客户端的 Header 信息数），writing（nginx 返回给客户端的 Header 信息数），已建立的连接数。
# QPS如何统计
Connections 不准确，可以有长连接。
就看Status codes 有多大就行了。
# 精确的Nginx分析QPS
可以用Ngxtop，分析nginx的日志，做脚本再发到给influxdb的http-api，再Grafana展示
# 思考
监控报警，日志采集、索引和可视化、 对系统进行进程级别的监控、对系统内部的操作进行策略性报警。 报警风暴。
# 参考资料
通过埋点实现代码层面上报Prometheus (opens new window)
java和go的思路，
Metrics指标规格，就行了。
Spring Boot 使用 Micrometer 集成 Prometheus 监控 Java 应用性能 (opens new window)
Micrometer为 Java 平台上的性能数据收集提供了一个通用的 API，可以再应用中调用API做业务指标采集。
同时支持接入不同的监控系统，例如 Influxdb、Graphite、Prometheus 等。
微服务框架（二十四）Prometheus 监控埋点 (opens new window)
Web埋点、Log4j2 Metrics、Dubbo埋点、Docker埋点、Kong网关埋点、Elasticsearch埋点
Prometheus（普罗米修斯）——适合k8s和docker的监控系统 (opens new window)
在业务层用作埋点系统 Prometheus支持各个主流开发语言（Go，java，python，ruby官方提供客户端，其他语言有第三方开源客户端）。我们可以通过客户端方面的对核心业务进行埋点，如下单流程、添加购物车流程。
在应用层用作应用监控系统 一些主流应用可以通过官方或第三方的导出器，来对这些应用做核心指标的收集。如redis,mysql。
在系统层用作系统监控 除了常用软件， prometheus也有相关系统层和网络层exporter,用以监控服务器或网络。
集成其他的监控 prometheus还可以通过各种exporte，集成其他的监控系统，收集监控数据，如AWS CloudWatch,JMX，Pingdom等等。
不要用Prometheus做什么?? 日志系统
prometheus也提供了Grok exporter等工具可以用来读取日志，但是prometheus是监控系统，不是日志系统。应用的日志还是应该走ELK等工具栈。
Prometheus 的局限 这 30 个坑点不要踩 (opens new window)
Prometheus 是基于 Metric 的监控，不适用于日志(Logs)、事件(Event)、调用链(Tracing)。
Prometheus 默认是 Pull 模型，合理规划你的网络，尽量不要转发。
对于集群化和水平扩展，官方和社区都没有银弹，需要合理选择 Federate、Cortex、Thanos 等方案。
监控系统一般情况下可用性大于一致性，容忍部分副本数据丢失，保证查询请求成功。
一文搞懂Prometheus、Grafana（含腾讯云上实战） (opens new window) Grafana数据可视化 (opens new window)
入门介绍
在自己的应用里集成grafana (opens new window)
grafana 配置数据源 (opens new window) 
grafana使用MYSQL数据源展示 (opens new window)
jmeter+influxdb+Grafana (opens new window)
jmeter > influxdb > Grafana
基于Ngxtop的QPS监控 (opens new window)
云平台的LB再将请求转发到后方的多台Nginx，Nginx上再做反向代理到后方的服务器。
为了获取系统的QPS，我们在Nginx服务器上写了个定时任务脚本，定期采集并发量，然后汇总。
编写并发量采集脚本 -> 用python-fab保证采集脚本在数台nginx服务器上并发执行 -> 再数据展示。