完善应用面板展示信息

[glmapper]

1、查看应用内存状态数据
2、健康检查状态信息
3、Info 信息
4、线程数量信息
5、mappings
6、线程状态
7、loggers
8、Environment

[glmapper]

应用面板相关功能的思考：

• 对于 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 维度查看服务信息的入口；

[chpengzh]

挺不错的，但是建议和zk一样，上报和读取逻辑就规划到client项目里面吧。届时在client项目里面规划出一个dashboard-support模块和client模块，分别供dashboard使用和应用使用

[chpengzh]

不过redis场景下如何设计ip维度和应用两个维度的查询方案还需要考虑一下怎么设计。

[glmapper]

不过redis场景下如何设计ip维度和应用两个维度的查询方案还需要考虑一下怎么设计。

应用状态数据上报不基于应用维度，只有IP 维度，每个应用实例是一个独立的监控单元。应用层面仅是对于应用实例统计、健康检查状态统计这些。所以基于 prefix_ip_ suffix 这种就能隔离。另外你如果有什么更合理的想法，可以回复到下面

[chpengzh]

统计数据也是靠dashboard定时任务去做的对吧，这种情况的话。

[chpengzh]

还有那个启停能力的功能，是指RPC在registry上下线，还是说控制网关啊。

[glmapper]

统计数据也是靠dashboard定时任务去做的对吧，这种情况的话。

其实不需要，应用实例还是注册到 zk 的，所以这里可以通过监听 ZK 来实现

[glmapper]

还有那个启停能力的功能，是指RPC在registry上下线，还是说控制网关啊。

这块是应用面板部分，应用启停针对的是应用本身。比如重启应用、下线应用