背景
众所周知，一个系统的运作，不免会发生异常。异常的种类参差不齐，发现异常的途径也繁多不一。其最后都会归于告警系统，通知到系统运维人员。
在很多成熟的云平台中，异常来源一般被归为两类：基于度量（metrics）的异常以及基于日志（log）的异常。前者通常以数值型表示，通过明确的指标高低，设定阈值，以达到告警的目的。
后者通常以字符串的形式表示，需要通过将字符串转换成有意义的数值，并设定阈值，以达到告警的目的。
在实际运维过程中，日志的数据可能会因为数量庞大、服务器负载陡增造成日志会延迟一定时间然后进入告警分析系统。因此针对日志告警通常会考虑加入一个时间窗口，对日志进行查询。
解决方案
鸿鹄提供了两种不同的视角，进行时间窗口的设定。我称之为“向前考虑法”和“向后考虑法”。
情景分析
假设有如下情况，有一个数据集app_log1，在系统发生异常时会向其插入一条日志。当这条日志发生在15:01:59，而数据集的插入在15:02:01s才完成。此时每分钟执行一次检查的告警就会把这条日志忽略。从而没达到告警的目的。
处理方式1：迨其吉兮 向前考虑法
所谓“迨其吉兮”就是等待良辰吉日到了，去查询并告警，即站在数据已经完整的情况下，以数据完整的时刻为基准，考虑倒推多少时间进行查询、告警。
这种思考方式要求告警是延迟的，延迟时间取决于告警检查的频率。如每分钟一次的告警，15:03:00查询15:01:00到15:02:00之间的数据。此时数据已完整，因此不会忽略延迟进入数据集的数据。
参考示例如下图所示：
处理方式2：迨其今兮 向后考虑法
所谓“迨其今兮”就是现在数据还不完整，只要数据完整了就查询并报警，即以当前时间为基准，推算数据多少时间内可以完整，等待这么多时间，然后进行查询并告警。
这种思考方式要求告警也是延迟的，延迟时间取决于用户对实际情况的判断。假设15s，数据就能够达到完整的状态，在指定的查询触发时间之后等待（即延迟）15s，然后以指定的查询触发时间为基准查询过去1分钟内的数据。
此时数据已完整，因此不会忽略延迟进入数据集的数据。例如一个告警指定15:02:00进行查询，在配置了延迟查询15秒后，会在15:02:15执行查询，而查询的时间范围为15:01:00到15:02:00。
参考示例如下图所示：
对比
总结
在考虑创建告警时，需要考虑支撑告警的数据是否会有延迟。如果有延迟，可以针对延迟使用“向前考虑法”和“向后考虑法”对于延迟进行处理。如果延迟只限于几秒的时间范围，建议使用“向后考虑法”。
如果延迟比较大，建议考虑“向前考虑法”，并将查询时间范围放大，加入一定的容错机制。