SLS机器学习介绍：时序补点和版本比较

本次给大家介绍两个实用的函数：时序补点函数、异常对比函数；

一、时序补点函数

• 上图的中的指标说明

  • 日志事件事件 T0 ：日志产生的最早事件
  • 日志事件事件 T1 ：日志产生的最晚事件
  • 实际点数据：在某个时刻有确定的数据
  • 缺失点数据：在某个时刻缺失数据点
  • 补点数据：在不同算法执行结果中，补出的数据

1. time_series

• 函数的使用说明文档：https://help.aliyun.com/document_detail/63451.html
• 说明：该函数必须和group by time order by time 一起使用，且order by不支持desc排序方式
• 数据补全的时间范围是：用户查询的时间窗

2. series_padding

• 函数的使用说明文档：https://help.aliyun.com/document_detail/160983.html
• 说明：该函数是将缺失的内部点数据按照一定的策略进行补点；支持group by模式

二、版本对比函数

• 文档地址：https://help.aliyun.com/document_detail/160982.html

2. 使用场景

2.1 某个服务升级

• 该场景可以总结为是单个观测对象，在比较升级前后某个观测指标的变化异常情况
• 需要提供的数据如下：
• 某个指标的时序观测数据
• 某服务变更时的时间点

例子如下：某个服务复杂在某个集群做了一次变更，变更时间是 2020-04-20 07:59:00，在这个时间点后，我们发现该集群的请求延时升高很多，相关研发同学也许就要紧急处理。那么是否有办法可以通过一个函数自动的帮我帮我判别变更前后，观测对象的指标是否发生变化。

• 先通过SQL整理出观察数据，观察出设定的异常点数值

* |
SELECT date_trunc('minute', __time__ - __time__ % 60) AS TIME,
       avg(Latency) AS Latency
FROM log
GROUP BY TIME
ORDER BY TIME
LIMIT 10000

我们使用对应的函数进行检测：

* |
SELECT anomaly_compare(TIME, array[ Latency ], 1587340740, 60)
FROM
  (SELECT __time__ - __time__ % 60 AS TIME,
          avg(Latency) / 1000.0 AS Latency
   FROM log
   GROUP BY TIME
   ORDER BY TIME)

{
  "results": [{
    "attribute": "column_0",
    "score": 0.9999840724556095,
    "details": {
      "left": [{
        "key": "mean",
        "value": 248.79610181477835
      }, {
        "key": "std",
        "value": 41.9981113960846
      }, {
        "key": "median",
        "value": 236.34852017385737
      }, {
        "key": "variance",
        "value": 1763.8413608379317
      }],
      "right": [{
        "key": "mean",
        "value": 294.9041720361495
      }, {
        "key": "std",
        "value": 47.074409675083004
      }, {
        "key": "median",
        "value": 299.6439639513877
      }, {
        "key": "variance",
        "value": 2216.0000462575485
      }]
    }
  }]
}

2.2 灰度发布升级

• 该场景可以总结为在集群中灰度服务时，观察不通灰度对象之间的异常差别

• 需要提供的数据如下：

  • 可以标示具体机器的发布状态的标签字段
  • 相同观测指标
    例子如下：某基础的存储服务在做版本升级时，往往会进行逐步的灰度操作，在选择几台机器先进行灰度，然后观察后在进行整体的升级发布，在做这个操作前是需要将对发布机器的指标状态做相关的判别，确定是否已经符合预期？是否同其它相同服务的机器的指标有较大差异？或者是否这个版本在线上是有有明显的性能提升？

这时我们把问题转换成部分的观测对象之间的相同观测指标数据之间的比较问题。

• 针对这个场景，我们先想数据进行达标（这里我模拟一个打标的场景，通过请求延时的大小来确定标签）

* |
SELECT date_trunc('minute', __time__ - __time__ % 60) AS TIME,
       avg(Latency) / 100000.0 AS Latency,
       label
FROM
  (SELECT __time__,
          Latency,
          CASE
              WHEN Latency > 1500000.0 THEN 1
              ELSE 0
          END AS label
   FROM log)
GROUP BY TIME,
         label
ORDER BY TIME
LIMIT 10000

* |
SELECT anomaly_compare(TIME, array[ Latency ], array[ 'Latency' ], label)
FROM
  (SELECT __time__ - __time__ % 60 AS TIME,
          avg(Latency) / 100000.0 AS Latency,
          label
   FROM
     (SELECT __time__,
             Latency,
             CASE
                 WHEN Latency > 1500000.0 THEN 1
                 ELSE 0
             END AS label
      FROM log)
   GROUP BY TIME,
            label
   ORDER BY TIME)

{
  "results": [{
    "attribute": "Latency",
    "score": 0.981385450748068,
    "details": {
      "left": [{
        "key": "mean",
        "value": 2.083975172731342
      }, {
        "key": "std",
        "value": 0.26912348059219504
      }, {
        "key": "median",
        "value": 2.0386681871982004
      }, {
        "key": "variance",
        "value": 0.07242744780605757
      }],
      "right": [{
        "key": "mean",
        "value": 36.19678922429
      }, {
        "key": "std",
        "value": 6.139164754357247
      }, {
        "key": "median",
        "value": 37.03196953882403
      }, {
        "key": "variance",
        "value": 37.68934388114228
      }]
    }
  }]
}