15 | 高可用架构案例（三）：如何打造一体化的监控系统？
节点信息采集
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
本文详细介绍了如何打造一体化监控系统，包括节点信息采集、节点接入、数据上报和前端展示四大部分。节点信息采集涵盖了对Redis、MQ、数据库和Web应用的监控方式，节点接入需要提供配置信息并进行代码改造，监控系统开发团队提供了SDK来简化接入过程。前端展示通过动态布局设计，灵活地展示系统的节点以及依赖关系，实现了大盘监控和系统级别监控。此外，文章还介绍了监控系统的数据库表设计，包括系统信息表、节点信息表和节点监控状态表。整体而言，该监控系统实现了大盘级别监控到节点级别监控的一体化，强调了系统的全面检查和直观结果报告。文章通过分享具体设计细节，强调了架构设计要考虑全面深入，简化开发对接和用户使用，以实现预期的价值。
《架构实战案例解析》，新⼈⾸单¥59
全部留言(24)
- 最新
- 精选
- Geek_c19d96老师您好，想问下这个系统服务间的依赖关系是通过手动维护的还是通过中间件的数据自动绘制的呢？
作者回复: 子系统的上下游依赖关系事先就知道，通过布局来体现关系，布局是手工定的
2020-04-103 
camel老师你好，我的理解“最近3s”应该是个滑动窗口，而hashmap记录的是每个接口的总时间、总次数等聚合的值，那么下一秒的“最近3s”统计值是怎么根据当前的“最近3s”计算的呢？作者回复: 你看得很仔细，能够提出疑问，赞一个。 每次agent大约3秒，通过http接口读取节点数据时，hashmap数据会清空，从0开始重新计算总时间，总次数等。
2021-08-2822- Geek_fd81b3有个疑问请教一下哈：一整个链路下来，某个服务往外提供的接口肯定会有很多，那我根据这个服务的哪个接口来判断我这个服务是否正常呢？举个例子，订单服务可能提供了下单接口，按用户查订单接口，按id查订单接口，订单修改接口等等……老师上边提到提供一个接口，返回这个服务的健康状态，那是否我这个接口里要去通过大量的逻辑，来判断我这个服务是否正常呢？
作者回复: 这是个好问题，一般是在你认为重要的接口里埋点，比如选择10个重要接口，每个接口是单独评估它的性能和出错情况，根据单个接口给出监控状况，然后服务的健康状况是根据最差的接口得出，比如A接口是警告，B接口是错误，那么服务的健康状况就是错误状态。
2020-05-282 
Geek_kevin请教老师,那个页面的动态布局设计,避免了前端的定制化,这里有没有再具体一点的信息可供参考的?作者回复: 这个说起来有点话长，你可以参考下HTML的table语法。在table里的每个cell单元，它的rowspan表明跨多少行，colspan表明跨多少列。 每个cell里放一个应用，包括它的各个app节点，redis节点，db节点等。 如果两个应用是并列关系，我们把它放同一水平位置（或者说同一行），如果是上下游调用关系，把应用上下放置。 这里，布局在后台指定，前端负责统一解释布局，并按照cell的定义，把应用放在table里的相应位置。 如果你想落类似的监控系统，前端一开始可以定制化。
2020-03-3022
夜空中最亮的星这个是自己开发的？有开源软件的参考吗？作者回复: 自己开发
2020-03-2522
兔子先生请教老师，所有节点的配置信息存储在数据库，会不会有安全问题。一旦监控系统被黑，所有节点的账号密码全部暴露。 另外，监控设计应该尽量少侵入应用系统，您讲的“SDK 在 HashMap 内部，不会记录每个接口调用的详细日志，而是只维护几个简单的总数值，因此 SDK 对应用的内存和 CPU 影响，都可以忽略不计”具体在落地时候该用什么样的量化指标考虑对系统的侵入程度呢。作者回复: 1. 对代码的影响，比如能够配置下就可以相比手动写代码侵入性低 2. 对应用性能的影响，占用cpu比例和内存量
2021-09-201
冬天的树
老师你好，有几个问题请教一下 1.wen应用中是不是需要每一个接口都要调用sdk的logHeahthInfo？这个作用是啥？ 2.既然我们有提供一个sdk了，为什么不把这个额外接口直接封装在sdk中呢？这样业务系统就无需在实现了，我理解的是agent调用http是调用这个额外的接口去采集数据 3.监控db的时候，实现简单的插入，那么垃圾出来怎么处理？如果插入验证后就删除，那每次就需要执行2次SQL,那性能如何保证？作者回复: 1. 重要的接口才调用logHeahthInfo，表示要监控这个接口的功能和性能。 2. agent调用目标应用的http接口获取信息，目标应用通过sdk收集监控信息，这样简化目标应用开发。 3. db的监控，一般是通过查询验证db的联通性即可。
2021-07-2731
蓝天1，最大的挑战是过度设计，总觉得流量要大到不行，其实并没有 2，我们还在使用rmi调用，虽然性能够用，但扩展性差，个人感觉不适合微服务治理等，但在公司使用较长，有些根深蒂固的，架构师们也不推，不知道是否我的看法不对，老师有啥好的建议呢？作者回复: rmi确实有点老，netty,dubbo,spring cloud都可以试试，找1-2个非核心系统试试，感觉早晚要升级
2020-03-261
Better me老师这里对应用的监控是通过agent每3s请求接口得到相关信息，然后取最差接口，这里是否会影响到接口的性能，应该如何平衡作者回复: 性能不会有问题，3秒调用一次，每次耗时不到1ms
2020-03-251- 吴雪峰请教老师， “具体包括最近 3s 的接口调用次数、接口平均响应时间、接口出错次数” 这是对agent的响应的统计吗？还是对正常业务响应的统计。如果是前者，是否有代表性? 如果是后者，不是对每次业务响应都要有所记录？
作者回复: agent每3s访问应用，获取该应用最近3s的系统运行情况，取3s这个时间是因为监控性的需要，太长达不到实时的目的，太短调用太频繁，对应用本身有一定干扰。
2020-11-26
