国内日志监控分析王者之sls
要论国内做日志监控分析的王者(没有之一)，那非阿里云日志服务(后文简称sls)莫属了。
在19年匆匆写了几篇关于分布式日志的文章，又过去了2年，再来分析下阿里云的日志服务，过去了2年，sls是否有一些新的变化呢。
相较于19年，当前sls在功能和业务上，也推出了不少新功能以及旧功能的优化与完善。
1、对于metrics数据比较完善的支持，不管是采集，还是数据存储，数据加工与查询，到最后的数据应用。
2、对于trace数据的支持。
3、重新优化了智能告警。
4、支持了promql和sql的融合
到目前为止，sls基本把运维监控的方方面面的能力，至少从面上补全了，而且部分功能还做出了自己的特色与优势。
同时我们也再来盘点下，目前市面上还在做日志与智能运维监控的公司与产品有哪些，画一张表格大致比较下?
| 功能比较/公司产品 | 阿里云日志服务(sls) | 云智慧 | 七牛 | 日志易 |
|---|---|---|---|---|
| 产品部署形态与模式 | 目前主要依托阿里公有云上的SaaS模式，专有云偶有输出 | 企业独立部署 | SaaS与企业独立部署 | 企业独立部署，SaaS目测是Poc环境 |
| 产品成熟度 | 比较成熟，从初期阿里云飞天内部开始孵化 | 一般 | 一般 | 成熟 |
| 是否支持metric/log/trace | 全方面支持，其中以日志最为成熟 | 支持 | 优先支持日志，其余支持比较弱 | 以日志最为成熟，其余从对外资料和行业了解到支持metric |
| 是否支持计算分析 | 支持比较好 | 一般 | 一般 | 一般 |
| 开放sdk | 支持的很好，sdk比较齐全，甚至可以基于sdk开发自定义场景的产品，包括对于移动端的支持 | 从对外资料看不支持 | 不支持 | 从对外资料来看，支持一般 |
| 对第三方框架支持程度 | 支持，不管是采集端，还是数据计算与处理端，比如对于opentelemetry的采集集成，还是计算层flink/kafka等等 | 不甚了解 | 不甚了解 | 不甚了解 |
| 技术创新方面 | 不管是底层存储，还是采集，计算，分析，智能ai等很多层面，都有自己很多创新，即时计算层采用了prestodb+promql，当然还有更详细的信息可参考其对外的资料，干货较多。 | 一般，基本技术栈以开源框架elk+clickhouse为主 | 一般，以开源框架为主，在计算层融合了spark的计算能力 | 一般，采用了自研的搜索引擎与SPL |
| 数据量支持 | PB级别，但不要一味追求规模，对于性能和数据量的极致追求，是功能和成本的妥协，而且也无太多实质性的意义，空间和时间的置换原理在哪里都有效 | -- | -- | -- |
| 功能比较 | 功能总体比较全面，其中对于可视化，告警，搜索等体验上还是给了我很多惊喜，很多细节处理比较到位，整体UI设计也比较清新简单 | -- | -- | -- |
当然还有其它维度的比较，这里就不一一去比较列举了
当然除了以上公司和产品，市场上还有一些做日志和运维产品的，但声音太小，这里就不一一列举了。
其实对于日志的监控分析，从技术侧，最大的难度，就是数据非结构化采集，数据规模，以及分析实时性的能力，通过以上的表格，大家
可能有了一个比较清晰的认识了，通过自己多年的行业经验来看，规模化的日志分析监控场景，还是有诸多挑战的。
在很多方面，其实是秒杀所谓的大数据领域的，当然其实分布式日志监控场景，也是大数据的一个领域，
现在大数据行业，特别是传统数仓方向的，到最近的一些数据湖概念，其实很多企业，真心没有那么多数据，本来一个oracle能搞定的数据，硬是要搞数据中台架构，各种大数据框架往上堆砌，结果成本直线上升，而创造的价值和效果却一般，当然这又是另一个故事了。
好了，今天只是一个比较粗粒度的日志产品比较，不涉及到具体的深层技术分析。
对于监控产品，我有一点感悟，数据之下，没有秘密，没有做不好的监控，只是没有足够的数据，什么是可观察性，唯数据而已。