高途业务监控系统建设

业务监控是指对企业业务流程进行实时监控和分析的一套系统。通过业务监控，企业可以实时了解业务的运行情况，及时发现异常情况并采取相应措施，避免因业务问题造成的损失和影响。业务监控主要包括监控指标的设定、监控方式的选择、监控结果的分析和决策等环节。监控指标的设定应根据企业的业务流程和关键业务指标进行确定，监控方式可以采用日志监控、告警监控、流量监控等方式进行实时监控。监控结果的分析和决策则需要结合业务流程和数据分析等手段，对监控结果进行综合分析，提供决策支持。通过业务监控，企业可以实时了解业务的运行情况，及时发现异常情况并采取相应措施，保障业务运营的稳定性和高效性。

业务监控由数据收集、存储、展示和告警四个主要组成部分构成。数据收集负责采集来自各个业务环节的数据，包括日志、性能指标、用户行为等，以建立全面的数据集。数据存储环节将采集到的数据保存在可靠的存储系统中，如数据库或大数据存储解决方案。展示阶段通过可视化方式将数据呈现，如仪表盘、报表或图表，以便用户直观理解业务状况。告警是监控系统的重要部分，通过监测数据变化和异常情况，及时触发告警通知相关人员，以便快速响应和解决问题。

高途的业务监控经历了三个阶段的演进，分别是业务监控1.0、2.0和当前阶段。在1.0阶段，业务指标通过SDK上报至Kafka，随后存储在ES供数据查询和告警处理。然而，随着指标接入量的增加，ES容量和成本劣势逐渐凸显，于是2.0阶段应运而生。在2.0阶段，数据改由SDK上报至Prometheus供数据查询和告警处理。值得注意的是，无论是1.0还是2.0阶段，数据都需要用户手动引入SDK上报，这种方式对代码进行侵入性修改，影响了用户的接入意愿。因此，在当前阶段，我们增加了主动抓取的方式获取业务指标，用户只需在平台进行指标抓取和告警逻辑的配置。大大降低了用户的接入门槛，显著提升了业务监控的覆盖范围。

业务监控的建设面临一系列挑战与难点。首先，业务监控所涉及的数据多样性是一大挑战。它需要处理来自不同业务环节的数据，包括日志、指标、性能数据等多种形式的信息，这些数据可能来自不同的系统和平台，因此需要整合这些异构数据，并确保其完整性和准确性。

其次，大规模数据的处理和实时性要求也是业务监控面临的难点之一。随着业务规模的不断扩大，监控的数据量也呈现出爆炸式增长，处理这些海量数据所需的技术和资源投入愈发凸显，同时部分监控需求对数据的实时性有较高要求，需要及时发现和处理异常情况。

最后，有效的告警与异常识别是业务监控的关键。要设定有效的告警规则并准确识别异常情况是一个挑战，需要避免误报和漏报，确保告警的精准度和实效性。

为了应对业务监控中多样且异构的数据源，我们采取了适配处理的策略，将这些数据源转换成了统一的数据模型，并存储于一致的数据层。这一层为我们构建上层的展示和告警应用提供了基础。原始数据源通过适配层转发至Kafka，在此进行高峰期的流量削峰，随后写入Lindorm时序引擎，确保数据的高效存储和管理。这种处理方式不仅实现了数据的整合和统一，还提升了对数据的管理和利用效率，为业务监控体系的搭建提供了可靠的基础。

另外，为了实现主动抓取的目标，我们将在用户配置完指标后，平台将自动生成相应的抓取任务，依据用户的设置进行数据源的主动抓取工作。当数据抓取至存储层后，用户可在平台上预览历史数据的趋势图表，以便进行告警参数的配置。一旦用户完成告警设置，平台同样会自动生成告警任务，根据设定对数据进行分析和告警。这些告警能力基于轻舟平台已有的天眼告警能力，旨在确保系统能够及时发现并响应潜在问题。这种智能化的配置和任务自动生成，为用户提供了便捷的监控接入方式。

由于Kafka数据源的实时性，为了对Kafka数据进行抓取，我们的抓取任务首先会将每条Kafka消息明细抓取到一个存储系统，这里我们同样选择了Lindorm来存储Kafka明细数据。相当于我们会有一个实时任务，不停地消费Kafka，写入到Lindorm（该Lindorm只存储Kafka消息）。然后我们会根据配置的聚合逻辑，对这些消息明细进行聚合查询和二次抓取，然后存入上面提到的统一存储层Lindorm中。

性能优化

为了应对不断增长的数据量，我们实施了一系列优化措施。首先，我们采用了“预聚合”的策略，对数据进行聚合处理，以减少存储压力并提高查询效率。一般的做法是按时间段对业务指标进行聚合处理。为了平衡实时性和存储容量的需求，我们提供了从1分钟到1小时的不同采样间隔选项。对于类似SQL的数据源，我们为用户提供了SQL填写方式，方便配置聚合逻辑。而对于非SQL类的数据源，例如Kafka，我们也提供了简单的聚合逻辑勾选配置，平台会自动实施聚合处理。这些措施旨在优化数据处理方式，提高效率，满足不同数据源的需求。

在优化Kafka类指标方面，我们进行了大量工作。对于来自相同Topic的不同指标，我们会对多个抓取任务进行整合。不同的抓取任务会生成不同的处理器，消息只会被消费一次，然后交给这些处理器并行处理，避免大量的重复消费。为了减少数据量，处理器会按照消息批次进行预预聚合，并根据预设配置进行过滤，同时只保留必要的字段。

最后，尽管数据支持多Tag，但每个指标只能按照特定的Tag组合进行告警。如果用户需要针对不同的Tag组合告警，就需要配置重复的指标，这会导致存储冗余。为了解决这个问题，我们引入了Lindorm类型的数据源，支持直接在已有指标上进行告警配置，避免重复抓取数据的情况。

功能优化

为了提升问题的主动发现率，我们支持了异常检测类型的告警机制。目前，我们已经支持了4种基于统计方法的异常检测算法，分别是适用于非周期信号的ESD算法和NSigma算法和适用于周期信号的ISTL-ESD算法和ISTL-NSigma算法。异常检测有助于及时发现潜在的问题或异常情况。通过实时监测和数据分析，我们可以在问题扩大之前识别并定位异常，有助于提前干预和处理，防止问题进一步恶化。这些算法的使用能够有效地提高问题检测的准确性和实时性。

在业务监控系统的建设过程中，我们也遇到了一些挑战，其中一个是关于 Lindorm 时序引擎的使用。Lindorm 时序引擎与其他时序引擎类似，由 Tags 和 Timestamp 组成不同的时间线，而时间线的数量对引擎的性能影响很大。

在一次帮助业务排查数据延时问题的过程中，我们在每条 Kafka 消息中记录了处理时间作为 Tag。然而，大约一个星期后，Lindorm 的写入和查询频繁报超时错误。经过排查发现，问题出在引入时间字段作为 Tag 上。由于时间无法被有效地聚合，时间线的数量随着时间的推移呈指数增长，最终影响了引擎的读写性能。为解决此问题，我们将处理时间改为 Field 类型存储，有效减少了时间线的数量，从而恢复了系统的性能。

对于Lindorm的使用，我们可以得出经验，如果字段的区分度特别大，则建议将字段设置为Field类型。另外，对于做聚合计算的的字段，则必须将字段类型设置为Tag，不然会导致数据覆盖丢失的问题。

在数据源支持方面，业务监控目前支持6种类型的数据源，包括MySQL、Elasticsearch、Prometheus、JSON API、Lindorm和Kafka，完全兼容1.0和2.0时代的数据源类型，覆盖电商、用户、教研、市场和直播五大业务域，累计接入335个业务指标。

指标抓取

除了单个指标的抓取，同时支持多个指标按照Tag进行复合抓取。

指标展示

支持业务大盘和电视大屏等展示方式。

指标告警

支持阈值条件、数据中断、同比环比和智能检测等4种告警类型。除此之外，提供了丰富的告警配置能力：支持按照时段进行告警、支持按照Tag进行告警、支持对过去一段时间的指标进行聚合告警、支持对延迟数据进行告警、告警预览、历史告警信息查询等。

现阶段AI发展火爆，我们未来可以基于机器学习和人工智能技术，让监控系统将能够预测潜在的问题，并提供预警，使企业能够在问题发生前采取相应的措施。主要分为两方面，一方面是智能化监控。智能化监控利用机器学习和数据挖掘技术，从大规模的监控数据中提取模式、识别规律，并根据这些模式和规律进行智能判断。例如，基于历史数据的模式识别，系统能够自动学习正常运行状态并识别异常行为。另一方面是预测性监控。预测性监控通过对历史数据的分析，结合预测模型和算法，预测未来可能出现的问题或趋势。这种监控能力可以帮助企业预测系统故障、资源瓶颈或异常行为的发生，并提前预警，从而减少潜在的损失和风险。