数据中心的可用性指标、数据中心的可用性指标有哪些

服务的质量最简单的度量指标就是可用性，所谓的可用性有很多定义，例如来自百度、维基等的定义等，也有同学将这个定义为可靠性，相关定义如下：

https://baike.baidu.com/item/%E9%AB%98%E5%8F%AF%E7%94%A8%E6%80%A7/909038?fr=aladdin

https://en.jinzhao.wiki/wiki/Availability

https://wiki.mbalib.com/wiki/%E5%8F%AF%E9%9D%A0%E6%80%A7

这里使用这个公式来定义服务的可用性度量指标：

参考值表格

如何准确客观的定义这两个时间，并让服务与使用者都接受，时常会有一些争议，因为应该服务时间要不要直接按自然时间如年、季度、月，要不要排出一些非工作时间，法定可不服务时间，以及挂免战牌的时间；实际可服务时间，要不要就按有无客户反馈而来，还是应该有不间断的巡查来保障，或者要不要增加一些权重，毕竟忙闲不一样。

也正基于此，我们定义了一个简单的模式，避免发散，其余结合业务再去组合。

观察者模式用来评价服务可用性是成立的，所谓我见故我在，我之所见故而其在！当一物不为所有存在所感受到时，此物就不存在！有点啰嗦了，其实就是下图标注【不对外服务的服务，不应该存在】

服务犹若星辰，不对外服务的就不应该存在

另外我们简单抽象下模型，如下图，调用者到服务者都可以简单看作客户与服务两个角色，中间有连接通道。

基本调用关系模型

不管多么复杂的系统，最基本的组合单元就是Client-Cloud-Server。从Client调用Server，什么时间，调用耗时多少，成功与否......

基本的要素就是此五项，每一次调用都会生成此明细数据，然后基于此数据进行组合汇总，形成需要的报表。例如某服务的可用性，某调用关系的可用性，流量波动，调用链路错误原因汇总，故障服务错误原因汇总，耗时超过阀值的调用链路列表等。全景图如下，结合阀值对链路标记出状态，并结合链路对服务进行状态标记。

基本模型调用组合集群

考虑到数据分析对业务的影响要小，并确保一定的准实时性（分钟级别），所以每个节点会进行分钟级别的统计，然后结合节点的多寡进行分级逐层统计。

Agent按照机器节点分层部署，对每分钟产生的明细数据，做简单的汇总，形成如下记录：

黑体部分为索引，计算步骤如下：

GridV分为统计节点与中心，统计节点为分层计算提供分布式能力支持，中心进行数据的最后存储。中心还会基于服务的属性，进一步分发计算。随着对服务单元本身的定义逐渐清晰（服务归属关系，服务所在机器等），关于服务的定义属性会更多，更具体。数据也会按此进一步梳理汇总。

关于服务的定义如下：

动态的数据，动态的呈现，动态的策略，无为而为不为，迅乎其所不滞，天网恢恢！

方案的设计需要每个节点支持每秒几十万次的上报，并对这些上报数据按照时间维度进行统计，一种开源的解决方案如下，可以相对比较广泛的支持各类终端的可用性上报，服务侧的上报。内部系统使用日志记录在本地，然后通过filebeat上报到kafka；远程系统则使用http协议上报给nginx，nginx记录日志，filebeat上报到kafka；然后kylin分析流式数据，按照设定的cube统计，最后通过superset呈现出报表。

一种开源实现