sofa-dashboard
sofa-dashboard copied to clipboard
sofastack
完善应用面板展示信息
1、查看应用内存状态数据 2、健康检查状态信息 3、Info 信息 4、线程数量信息 5、mappings 6、线程状态 7、loggers 8、Environment
应用面板相关功能的思考：
-
对于 spring boot actuator 提供的基于 server 端 主动 pull 的模式，优势在于这种模式可以使得 server 端能够及时的获取到目标实例的状态数据，并且不用引入任何缓存来存储获取到的实例状态。但是 pull 模式在一定程度上依赖各个client 端的状态，除此之外也不得不考虑网络的影响（如 server 端无法直接访问 client），使得 server 端运行状态会直接或者间接收到 client的影响（超时、500等）。因此，出于一种对于对 server 端的保护考虑，且在管控的应用状态数据允许一定延迟的情况下，引入缓存来解耦 dasboard client 和 server 之间的关系，并且使得 client 以主动 push 的方式向缓存空间推送 自身应用状态信息
- 基于 Redis
- 基于 Elasticsearch
- 基于 DB
- 基于 Memory
-
应用面板展示逻辑在第一个 SNAPSHOT 版本中并没有考虑将应用与应用实例进行维度划分，使得在应用列表中在应用较多的情况下显得非常的不友好，即使我们提供了搜索的功能，但是还是会给使用者一种视觉凌乱的感觉。在下面的版本中，SOFADashboard 将在首页面板中仅以应用维度展示，如下：
当单机详情时，才进入应用实例列表页：
-
提供查看应用 Metrics 信息、traces 信息、应用本身静态状态数据信息等能力，提供基于 IP 维度查询的能力
-
提供应用启停能力；在某些场景下，如应用某些监控指标出现异常，允许具有操作权限的操作者进行应用停机操作以进行相关运维操作，并且待达到期望结果时予以重启
-
提供基于应用维度、IP 维度查看应用配置的入口；
-
提供基于应用维度、IP 维度查看服务信息的入口；
挺不错的，但是建议和zk一样，上报和读取逻辑就规划到client项目里面吧。届时在client项目里面规划出一个dashboard-support模块和client模块，分别供dashboard使用和应用使用
不过redis场景下如何设计ip维度和应用两个维度的查询方案还需要考虑一下怎么设计。
应用状态数据上报不基于应用维度，只有IP 维度，每个应用实例是一个独立的监控单元。应用层面仅是对于应用实例统计、健康检查状态统计这些。所以基于 prefix_ip_ suffix 这种就能隔离。另外你如果有什么更合理的想法，可以回复到下面
还有那个启停能力的功能，是指RPC在registry上下线，还是说控制网关啊。
这块是应用面板部分，应用启停针对的是应用本身。比如重启应用、下线应用