网络安全检测|网络安全服务|网络安全扫描-香港墨客投资移动版

指标的采集主要涉及两个问题，一个是如何规范 metric 日志，便于在不同系统间传递，一个是如何传输的问题，有多种途径如 scirbe、kafka、udp 等。为了解决第一个问题，我们制定了规范的 profile 日志格式，各种 metric 信息均以标准的格式记录，如下图 7 所示。为了简化系统和传输效率，我们通过 udp 方式将各种 metric 信息传递给监控系统。

图 7. Profile 标准日志格式

实时监控系统

有了关键业务指标的 Profile 日志，就可以对它们进行实时监控，其工作原理如图 8 所示。

图 8. 实时监控系统架构图

从上图可以看出，实时监控系统的核心就是 Graphite。它主要包含两方面的功能：

将实时传输的 profile 日志进行聚合计算，产生各种维度的数据存储到时序数据库中。

还需要提供 API 接口，以提供 dashboard 展示，压测系统以及智能调度系统调用以用于扩缩容决策。下面将对 Graphite 进行详细介绍，其架构如图 9 所示。

图 9. Graphite 架构图

为了减少延迟，我们对 graphite 系统中的关键模块进行了优化，主要包括两个方面：

用 go 重写了 statsd-proxy 和 statsd 模块

carbon 中添加缓存，7 天的数据存储在缓存中，7 天以外的数据存到 SSD。

在线容量评估系统

有了关键业务指标的实时监控，就可以对系统进行压测，以评估系统的最大支撑能力。而如何对系统进行压测，以合理评估系统的承载能力主要取决于两个方面：

合理选择业务指标来衡量系统健康度；

精确定位性能拐点以确定系统临界值。

下面分别就上面两个问题进行阐述。

合理选择业务指标来衡量系统健康度

常见的可作为衡量系统健康度的指标有 avgTime、load、5xx、连接数等，对于单一业务模型的系统来说，选取其中一个指标即可。但对于复杂的业务系统，以微博 web 系统为例，既包含了 CPU 和带宽消耗较高的 feed 接口，又包含了低延迟和高并发的计数器接口，单一接口健康并不能代表整个系统健康。除此之外，单一指标正常也不能代表系统正常，比如我们经常遇到 feed 接口 avgTime 正常，但延迟大于 1s 的比率超过了 1%，这时候会直接造成 1% 用户刷新失败，影响了用户体验。

为此，我们建立了多接口多指标的健康度评估模型。

多接口，是指选取服务池中多个具有代表性的接口，并且还会考虑整体服务池中接口的情况，比如我们在微博 web 系统中不仅选取了 feed 接口，还选取了计数器接口等。

多指标，是指不仅仅选取单一指标作为参照，比如我们在实际压测过程中，会考虑接口的平均耗时、5XX 以及慢速比（延迟超过 1s 的比率）。

精确定位性能拐点以确定系统临界值

常用的系统压测方案主要包括两种：

在线缩减机器数量以增加单机承载量，从而压测到单机承载能力的最大值。

模拟洪峰，对服务池进行全链路压测，以模拟出峰值流量下系统的承载能力。

目前，我们主要采用方案 1 进行压测。通过减少在线机器数，以增加单机承载量来压测，直到服务池的健康度到达临界点时暂停压测，待系统恢复后，继续缩减在线机器数，否则则停止压测并记录服务池的临界值。

智能弹性调度系统

有了系统的最大承载能力，就可以根据实时监控系统中服务池当前的流量，来决定是否需要扩缩容以及扩容机器数。智能弹性调度的智能主要体现在两个方面：

快。

智能弹性调度并不等到系统的承载量已经濒临临界值时才进行扩容，因为此时可能流量很快上涨超过水位线，在扩容完成之前就已经把系统压垮了。为此，我们给系统设置了三条线：致命线、警戒线、安全线，如图 10 所示。

图 10. 智能弹性调度系统水位线

(责任编辑：admin)