原始监控
追溯到监控不发达的时代，那时候 基本属于⼀个 出⾏基本靠⾛，安全基本靠狗，剩下的大家脑补就行了。
当然服务器少的时候，不会出什么问题。
每天上班 第⼀件事 就是⾛进去巡视⼀下，看看各种软件打印出来的输出信息 是否有报错 如果有 就拿个 Excel 记录⼀下，再发邮件给⽼板。。。。。
这样的生活是不是很轻松。
不过，问题马上就来了，如今的企业中 动不动运维就要负责 成百上千 甚⾄上万台机器。
没有⾼⼤上的⽅法 是绝对⽀撑不起来这种规模的 监控的。
分布式监控
CAT分布式监控系统
CAT（Central Application Tracking）是美团开源的基于Java开发的实时分布式应用监控平台，提供了全面的监控服务和业务决策支持。
CAT监控系统的定位：
cat本质上一个实时监控系统，主要体现在监控报表Transaction、event、problem、heartbeat等，cat系统定制的监控模型以及定制的实时分析报表也是cat系统核心优势。
logview是cat原始的log采集方式，cat的logview使用的技术是threadlocal，将一个thread里面的打点聚合上报，有一点弱化版本的链路功能，但是cat并不是一个标准的全链路系统，全链路系统参考dapper的论文，业内比较知名的鹰眼，zipkin等，其实经常拿cat和这类系统进行比较其实是不合适的。cat的logview在异步线程等等一些场景下，其实不合适，cat本身模型并不适合这个。在美团点评内部，有mtrace专门做全链路分析。
也就是说：CAT定义了一个基本的监控模型，可以用来实时监控，至于要监控些什么可以自己定义，比如要做分布式全链路跟踪监控，可以自己埋点获取监控信息；
另外，CAT倾向于指标、链路事件监控，不太适用于大量业务日志的场景，因为无法搜索、分析，CAT只看看到最新的样本数据和出问题的数据。大量业务日志的场景应该用ELK。
接入CAT客户端后，CAT客户端每分钟发送一次自身的状态信息。状态信息包括：服务器系统信息、JVM 内存/GC信息、线程信息、CAT监控使用信息等。详情如下图：
状态信息的原始数据可以查看“Transaction“中的System类型信息，如下图：
监控一段代码运行情况：运行时间统计、次数、错误次数等等。如下图：
Problem记录整个项目在运行过程中出现的问题，包括一些错误、访问较长的行为。Problem的类型如下：
SQL执行监控可以看到每个DAO方法执行解析的SQL语句、SQL语句执行时长、以及连接到哪个数据库（URL）执行；如果SQL执行出现异常，还会记录异常信息；另外还可以过滤出慢SQL。
SQL监控执行整体情况如下：
上面业务监控我们也说到业务指标也可以设置告警的，除此外，Transaction/Event/异常/心跳都可以设置告警，如下图所示：
skywalking
SkyWalking 是针对分布式系统的应用性能监控，天生吻合微服务、云原生和面向容器的分布式系统架构。PHP应用也可接入，但需以插件方式接入，偶尔也会有一些坑。
主要有以下特性：
- 服务、服务实例和endpoint(如：单个HTTP URI）的性能指标分析
- 根因分析
- 服务拓扑图
- 服务和Endpoint依赖分析
- 慢服务和慢Endpoint探查
- 性能优化
- 分布式追踪和追踪上下文传播
- 告警
SkyWalking支持从多种数据源，收集不同格式的遥感数据，包括
- Java, .NET Core, NodeJS, PHP 自动探针
- Istio 遥感数据
- Zipkin v1/v2
最新有8.x架构图如下，较复杂，但实际应用起来还算简单
搭建完成后，访问自己 http://localhost:8080 就能查看页面了。
也可以参考
skywalking
张锋，公众号：极客原创skywalking
zabbix
Zabbix可以获取cpu，内存，网卡，磁盘，日志等信息
1.Zabbix数据收集方式：
a.Agent客户端（Agent客户端支持多平台部署）
b.如果是无法安装客户端的设备，例如网络设备，则可以通过SNMP（简单网络管理协议）获取监控数据
c.支持通过IPMI获取硬件的温度，风扇，硬盘，电源等
d.通过Zabbix自带的检测进行监控
2.Zabbix支持自定义监控：
可以通过shell，python，ruby等可执行的脚本收集监控数据
3.Zabbix可以通过监控对象的趋向判断是否可能会发生异常，从而可以做到预告警功能。
4.Zabbix拥有告警关联功能（防止海量的告警难以排查，它可以迅速关联到核心问题所在）
5.Zabbix安全和认证，它可以设置用户的权限，安全方面通过TLS传输信息，防止信息被窃听（TLS是SSL的升级版）
6.Zabbix自动化：
a.网络自动发现
b.Agent自动注册
prometheus
Prometheus于2012年由SoundCloud创建，目前已经已发展为最热门的分布式监控系统。Prometheus完全开源的，被很多云厂商（架构）内置，在这些厂商（架构）中，可以简单部署Prometheus，用来监控整个云基础架构设施。比如DigitalOcean或Docker都是普罗米修斯作为基础监控。
Prometheus监控报警系统
三丰，公众号：soft张三丰Prometheus监控报警系统
理想的监控体系
⼀个最理想的 完整的 监控体系的搭建 有赖于如下这么⼏个⽅⾯的⼯作 以及流程
监控系统设计(架构师）
⾸当其冲 就是压在运维架构师的肩膀上的任务
设计如果都设计不好，那么后⾯的事⼉也是⽩⼲
设计部分包括如下的内容：
• 评估系统的业务流程 业务种类 架构体系
各个企业的产品不同，业务⽅向不同，程序代码不同，系统架构更不同
对于各个地⽅的细节 都需要有⼀定程度的认知 才可以开起设计的源头
• 分类出所需的监控项种类
⼀般可分为 ：业务级别监控 / 系统级别监控 / ⽹络监控 / 程序代码监控/ ⽇志监控 / ⽤户⾏为分析监控/ 其他种类监控
⼤的分类 还有更多的细⼩分类
这⾥给出⼏个例⼦
例如：
-
业务监控 可以包含 ⽤户访问QPS， DAU⽇活，访问状态（http code）， 业务接⼜(登陆，注
册，聊天，上传，留⾔，短信，搜索)，产品转化率，充值额度，⽤户投诉 等等这些很宏观的概
念（上层）
-
系统监控 主要是跟操作系统相关的 基本监控项 CPU/ 内存 / 硬盘 / IO / TCP链接 / 流量 等等
(Nagios - plugins, prometheus)
-
⽹络监控 （IDC）对⽹络状态的监控（交换机，路由器，防⽕墙， VPN） 互联⽹公司必不可
少 但是很多时候又被忽略 例如：内⽹之间（物理内⽹，逻辑内⽹ 可⽤区 创建虚拟机 内⽹IP ）
外⽹ 丢包率 延迟 等等
-
⽇志监控 监控中的重头戏（Splunk,ELK），往往单独设计和搭建， 全部种类的⽇志都有需要采
集 (syslog, soft, ⽹络设备，⽤户⾏为)
-
程序监控 ⼀般需要和开发⼈员配合，程序中嵌⼊各种接⼜ 直接获取数据 或者特质的⽇志格式
监控技术的⽅案/软件选取（主观因素）
各种监控软件层出不穷，开源的 商业的 ⾃⾏开发的 ⼏百种的可选⽅案
架构师凭借⼀些因素 开始选材.
针对企业的架构特点，⼤⼩，种类，⼈员多少 等等 选取合适的技术⽅案。
- 监控体系的⼈员安排
运维团队的任务划分，责任到⼈，分块进⾏
开发团队的配合⼈员选取，很多监控涉及的⼯作 都需要跟开发⼈员配合 才可以进⾏
IE浏览器正式退出历史舞台
三丰，公众号：soft张三丰20多年了，终于要说再见了
认识service mesh
三丰，公众号：soft张三丰一文看懂service mesh
微服务如何切分
三丰，公众号：soft张三丰微服务之划分原则
看懂k8s
三丰，公众号：soft张三丰一文看懂k8s
Prometheus监控系列
三丰，公众号：soft张三丰Prometheus监控（1）