图片43

在相对复杂的业务场景下，一个“事件”除包含我们常用的“时间”（何时发生）、“地点”（哪个服务器/组件）、“内容”（包括错误码、状态值等）外，还应当包含地区、机房、服务池、业务线、服务、接口等，这就是多维度数据。

很多时候，数据分析人员可能要使用各种维度、组合各种指标来生成报告、Dashboard、告警规则等，所以是否支持多维度的数据存储和查询分析，是衡量一个系统是否具有灵活性的重要指标。

对多维度数据的处理，很多时候是一个协议/模型设计问题，甚至都不会牵扯具体的分析和处理框架，设计良好的协议和存储模型，能够兼顾简洁性和多维度。

不同的设计理念会对应不同的处理模型，没有优劣之分，只有哪个更合适的区别。

多数据源或者说异构数据源已经很普遍了，毕竟在复杂场景下并不总是只产生一种类型的数据，也不是所有数据都要用统一的方式处理和存储。

在具体的实践中，通常会混合使用多种存储介质和计算模型。

如何从异构的多数据源中获取数据，还要考虑当其中某个数据源失效、服务延迟时，能否不影响整个系统的稳定性。这考量的不仅仅是各种数据格式/API的适配能力，而且在多依赖系统中快速失败和SLA也是要涉及的点。

多数据源还有一个关键问题就是如何做到数据和展现分离。如果展现和数据的契合度太高，那么随便一点变更都会导致前端界面展现部分的更改，带来的工作量可能会非常大，很多烂尾的系统都有这个因素存在的可能性。

DDoS（分布式拒绝服务）攻击，指借助于客户/服务器技术，将多台计算机联合起来作为攻击平台，对一个或多个目标发动攻击。当我们的大脑在短时间内接收到大量的信息，达到了无法及时处理的程度时，实际上就处于“拒绝服务”的状态，尤其是当重大故障发生，各种信息、蜂拥而至的警报同时到达时。

典型的信息过载的场景就是“告警”应用，管理员几乎给所有需要的地方都加上了告警，以为这样即可高枕无忧了。

然而，接触过告警的人都知道，邮件、短信、手机推送、不同声音和颜色提醒等各种来源的信息可以轻松挤满你的空间，很多人一天要收上万条告警短信，手机都无法正常使用，更别谈关注故障了。

怎样从成千上万条信息中发现有用的，过滤掉重复的、抖动性的信息，或者从中找出问题根源，从来都不是一件容易的事情，所以业界流传着“监控容易做，告警很难报”的说法。

还有一个场景就是监控，当指标较少、只有数十张Dashboard时，尚且可以让服务台 24小时关注，但是当指标达到百万、千万，Dashboard达到数万张时（你没看错，是数万张图，得益于Grafana/Graphite的灵活性，Dashboard可以用程序自动产生，无须运维工程师手工配置），就已经无法用人力来解决Dashboard的巡检了。

历史的发展总是螺旋上升的，早期我们监控的指标少，对系统的了解不够全面，于是加大力度提高覆盖度，等实现了全面覆盖，又发现信息太多了，人工无法处理，又要想办法降噪、聚合、抽象，少→多→少这一过程看似简单，其实经过了多次迭代和长时间的演化。