Open mylamour opened 5 years ago
不算教程，只是随笔记下。
先说下SLS做的可视化报表和专有BI报表系统的区别（既然内部系统不具有普适性，所以先写个sls的吧）：
但同时sls拥有强大的实时检索能力，同时提供了大量的内置函数。作为监控报表（中的日志收集）可谓是不二之选。同时通过适当的运用嵌套，很快就能做出一个大盘分析以及针对对应条目的下钻分析（别问我啥叫下钻分析），这个可以说很实用了。
先看一个大图：
这个是waf的部分分析图表，可以看出waf的覆盖，每个域名面临的攻击，攻击的对应路径及对应方法，同时还有关于waf自身的心跳检测等。 当然这种属于大盘式的报表，还有针对特定用途的监控报表。再来看一个
（做监控只要自动刷新加全屏即可）
查询语法比较基础那么我们来看下简单的时序查询（注意日志量大的同时不适合横跨很多天数进行查询）
select time_series(__time__, '1h', '%H:%m', '0') as t, count(1) hit group by t order by t
time_series即是内置的时序函数，可以提供时间间隔不同的查询方式，可以是间隔1h也可以是1d
其实对于使用哪些函数来说，应该都不是重点，翻阅文档都可以做的事情，没有必要写在这里。 值得一说的就是，sls的报表提供了一些交互，当然不一定有专业的强，但是用在监控之中可以说十分方便的了。比如说上图中的最后一个报表就是按照下图的方式做出来的：
当你发现特定的监控目标发起的请求时，可以迅速的进行整个APM链路追踪。
总的来说数据可视化分析应该是：
说到输出给指定用户，分为两部分，一是推送报表，二是推送告警，即根据报表的指标数据进行告警推送。均可以推送到邮件和钉钉。这里踩过一个小坑，就是推送报表的地方，如果你的报表加载比较慢，比如你针对一个分析，选了横跨30天。由于数据量很大，导致查询需要一定的时间，而这个时间超出了推送所需要的时间，就会导致无法正常推送报表。
一点小小的心得，还有许多不足，仍待继续补充。
输入（不同数据源） -> 分析（业务场景下的专家经验） -> 输出(内容： 分析结果以及结果指标，目的地：邮件，钉钉等）
其实还有很多可以选(s3, elasticsearch, prometheus,greylog), (grafana, splunk, kibana)等
不算教程，只是随笔记下。
先说下SLS做的可视化报表和专有BI报表系统的区别（既然内部系统不具有普适性，所以先写个sls的吧）：
但同时sls拥有强大的实时检索能力，同时提供了大量的内置函数。作为监控报表（中的日志收集）可谓是不二之选。同时通过适当的运用嵌套，很快就能做出一个大盘分析以及针对对应条目的下钻分析（别问我啥叫下钻分析），这个可以说很实用了。
先看一个大图：
这个是waf的部分分析图表，可以看出waf的覆盖，每个域名面临的攻击，攻击的对应路径及对应方法，同时还有关于waf自身的心跳检测等。 当然这种属于大盘式的报表，还有针对特定用途的监控报表。再来看一个
（做监控只要自动刷新加全屏即可）
查询语法比较基础那么我们来看下简单的时序查询（注意日志量大的同时不适合横跨很多天数进行查询）
time_series即是内置的时序函数，可以提供时间间隔不同的查询方式，可以是间隔1h也可以是1d
其实对于使用哪些函数来说，应该都不是重点，翻阅文档都可以做的事情，没有必要写在这里。 值得一说的就是，sls的报表提供了一些交互，当然不一定有专业的强，但是用在监控之中可以说十分方便的了。比如说上图中的最后一个报表就是按照下图的方式做出来的：
当你发现特定的监控目标发起的请求时，可以迅速的进行整个APM链路追踪。
总的来说数据可视化分析应该是：
说到输出给指定用户，分为两部分，一是推送报表，二是推送告警，即根据报表的指标数据进行告警推送。均可以推送到邮件和钉钉。这里踩过一个小坑，就是推送报表的地方，如果你的报表加载比较慢，比如你针对一个分析，选了横跨30天。由于数据量很大，导致查询需要一定的时间，而这个时间超出了推送所需要的时间，就会导致无法正常推送报表。
一点小小的心得，还有许多不足，仍待继续补充。
输入（不同数据源） -> 分析（业务场景下的专家经验） -> 输出(内容： 分析结果以及结果指标，目的地：邮件，钉钉等）
其实还有很多可以选(s3, elasticsearch, prometheus,greylog), (grafana, splunk, kibana)等