流量不小心充了500还能退吗1771?

通过将阿里云日志服务与ELK Stack进行全面对比,帮助您更好的了解阿里云日志服务的主要功能和优势。

提到日志实时分析,很多人都会想到基于ELK Stack(Elastic/Logstash/Kibana)来搭建。ELK方案开源,在社区中有大量的内容和使用案例。

阿里云是阿里巴巴集团对日志场景的解决方案产品,前身是2012年初阿里云在研发飞天操作系统过程中用来监控和问题诊断的产物,但随着用户增长与产品发展,慢慢开始向面向Ops(DevOps,Market Ops,SecOps)日志分析领域发展,期间经历双十一、蚂蚁双十二、新春红包、国际业务等场景挑战,成为同时服务全球的产品。

Apache Lucene是Apache软件基金会一个开放源代码的全文检索引擎工具包,一个全文检索引擎的架构,提供了完整的查询引擎和索引引擎、部分文本分析引擎。2012年Elastic把Lucene基础库包成了一个更好用的软件,并且在2015年推出ELK Stack(Elastic Logstash Kibana)解决集中式日志采集、存储和查询问题。Lucene设计场景是Information Retrival,面对是Document类型,因此对于Log这种数据有一定限制,例如规模、查询能力、以及智能聚类LogReduce等定制化功能。

Log Service提供日志存储引擎是阿里内部自研究技术,经过3年万级应用锤炼,每日索引数据量达PB级,服务万级开发者每天亿次查询分析。在阿里集团内阿里云全站,SQL审计、鹰眼、蚂蚁云图、飞猪Tracing、阿里云谛听等都选择Log Service作为日志分析引擎。

而日志查询是DevOps最基础需求,业界的调研也验证了这一点,tar排名第一、Grep排名第二,由此可见日志查询对程序员的重要性。

在日志查询分析场景,以如下点对ELK与Log Service做一个全方位比较。

  • 易用:上手和使用的便利程度。
  • 功能:主要针对查询与分析。
  • 性能:对于单位大小数据量查询与分析需求,延时如何。
  • 规模:能够承担的数据量、扩展性等。
  • 成本:同样功能和性能,使用分别花多少钱。

对日志分析系统而言,有如下使用过程。

  • 采集:将数据稳定写入。
  • 配置:如何配置数据源。
  • 扩容:接入更多数据源,更多机器,对存储空间,机器进行扩容。
  • 使用:这部分在功能这一节介绍。
  • 导出:数据能否方便导出到其他系统,例如做流计算、放到对象存储中进行备份。
  • 多租户:如何将数据分享给其他人使用,使用是否安全等。
提供Index概念用以区分不同日志。

提供两层概念,Project相当于命名空间,可以在Project下建立多个Logstore。

  • 通过配管系统应用机器。
  • Logstash在Beta版本中已经提供中心化配置功能。
控制台或API操作,无需配管系统。
通过配管系统控制,将配置和Logstash安装到机器组。 控制台或API操作,无需配管系统。
原生提供账号与权限级管理。
  • ELK有非常多的生态和写入工具、安装、配置等都有较多工具可以使用。
  • Log Service是托管服务,从接入、配置、使用上集成度非常高,普通用户5分钟就可以接入。
  • Log Service是SaaS化服务,在过程中不需要担心容量、并发等问题。弹性伸缩,免运维。

查询主要是将符合条件的日志快速命中,分析功能是对数据进行统计与计算。

例如我们需要所有状态码大于200的读请求,根据IP统计次数和流量。这样的分析请求可以转化为两种操作。

  • 查询到指定结果,对结果进行统计分析。
  • 不进行查询,直接对所有日志进行分析。

针对IP地址、手机等内容,内置地理位置函数方便分析用户来源。

  • IP:国家、省市、城市、经纬度、运营商。
  • Mobile:运营商、省市。
  • 依托全球白帽子共享安全资产库,提供安全检测函数,您只需要将日志中任意的IP、域名或者URL传给安全检测函数,即可检测是否安全。

  • 新增机器学习与智能诊断系列函数。

    • 根据历史自动学习其中规律,并对未来的走势做出预测。
    • 实时发现不易察觉的异常变化,并通过分析函数组合推理导致异常的特征。
    • 结合环比、告警功能智能发现/巡检。该功能适用在智能运维、安全、运营等领域,帮助更快、更有效、更智能洞察数据。
    • 预测:根据历史数据拟合基线。
    • 异常检测、变点检测和折点检测:找到异常点。
    • 多周期检测:发现数据访问中的周期规律。
    • 时序聚类:找到形态不一样的时序。
  • 模式分析函数能够洞察数据中的特征与规律,帮助快速、准确推断问题。

    • 定位频繁集。例如:错误请求中90%由某个用户ID构成。
    • 定位两个集合中最大支持因素。
      • 延时>10S请求中某个ID构成比例远远大于其他维度组合。
      • 并且该ID在对比集合(B)中的比例较低。

针对相同数据集,分别对比写入数据及查询,和聚合计算能力。

      3(默认配置,对用户不可见)
      • 以上字段完全随机(测试日志样例如下)。
      • 原始数据大小:50 GB。
      • 日志行数: (约为1.6亿条)。

      以上字段完全随机,如下为一条测试日志样例:

    膨胀率:数据量/原始数据大小

    说明 日志服务产生计费的存储量包括压缩的原始数据写入量(23 GB)和索引流量27 GB,共50 GB存储费用。

    • 空间:原始数据50 GB,因为测试数据比较随机,所以存储空间会有膨胀(大部分真实场景下,存储因压缩会比原始数据小)。ES胀到86 GB,膨胀率为172%,在存储空间超出日志服务58%。这个数据与ES推荐的存储大小为原始大小2.2倍比较接近。
  • 读取(查询+分析)测试

      选取两种比较常见的场景:日志查询和聚合计算。分别统计并发度为1、5、10时,两种case的平均延时。

  • 针对全量数据,随机查询日志中的关键词,例如查询value_126,获取命中的日志数目与前100行。
  • 从结果看,对于1.6亿数据量这个规模,两者都达到了秒级查询与分析能力。
  • 针对统计类场景(case 1), ES和日志服务延时处同一量级。ES采用SSD云盘,在读取大量数据时IO优势比较高。
  • 针对查询类场景(case 2), LogAnalytics在延时明显优于ES。随着并发的增加,ELK延时对应增加,而LogAnalytics延时保持稳定甚至略有下降。

    • 日志服务一天可以索引PB级数据,一次查询可以在秒级过几十TB规模数据,在数据规模上可以做到弹性伸缩与水平扩展。
    • ES比较适合服务场景为:写入GB-TB/Day、存储在TB级。原因如下:
      • 单集群规模:比较理想为20台左右,据了解业界比较大为100节点一个集群,为了应对业务往往拆成多个集群。
      • 写入扩容:shard创建后便不可再修改,当吞吐率增加时,需要动态扩容节点,最多可使用的节点数便是shard的个数。
      • 存储扩容:主shard达到磁盘的上限时,要么迁移到更大的一块磁盘上,要么只能分配更多的shard。一般做法是创建一个新的索引,指定更多shard,并且rebuild旧的数据。

    用户案例(规模带来的问题)

    客户A是中国的最大资讯类网站之一,有数千台机器与百号开发人员。运维团队原先负责一套ELK集群用来处理Nginx日志,但始终处于无法大规模使用状态:

    • 一个大Query容易把集群打爆,导致其他用户无法使用。
    • 在业务高峰期间,采集与处理能力打满集群,造成数据丢失,查询结果不准确。
    • 业务增长到一定规模,因内存设置、心跳同步等节点经常内存失控导致OOM 不能保证可用性与准确性,开发最终没有使用起来,成为一个摆设。

    在2018年6月份,运维团队开始运行日志服务方案。

    1. 使用Logtail来采集线上日志,将采集配置、机器管理等通过API集成进客户自己运维与管控系统。
    2. 将日志服务查询页面嵌入统一登录与运维平台,进行业务与账户权限隔离。
    3. 通过控制台内嵌方案满足开发查询日志需求,通过Grafana插件调用日志服务统一业务监控,通过DataV连接日志服务进行大盘搭建。
    • 每天查询的调用量大幅上升,开发逐步开始习惯在运维平台进行日志查询与分析,提升了研发的效率,运维部门也回收了线上登录的权限。
    • 除Nginx日志外,把App日志、移动端日志、容器日志也进行接入,规模是之前10倍。
    • 除查询日志外,也衍生出很多新的玩法,例如通过Jaeger插件与控制台基于日志搭建了Trace系统,将线上错误配置成每天的告警与报表进行巡检。
    • 通过统一日志接入管理,规范了各平台对接总线,不再有一份数据同时被采集多次的情况,大数据部门Spark、Flink等平台可以直接去订阅实时日志数据进行处理。

    以上述测试数据为例,一天写入50 GB数据(其中23 GB为实际的内容),保存90天,平均一个月的耗费。

    • 日志服务(LogSearch/LogAnalytics)计费规则参见,包括读写流量、索引流量、存储空间等计费项,查询功能免费。
      存储空间(保存90天)
    • ES费用包括机器费用,及存储数据SSD云盘费用。
      • 云盘一般可以提供高可靠性,因此我们这里不计费副本存储量。
      • 存储盘一般需要预留15%剩余空间,防止空间写满,因此乘以一个1.15系数。

      同样性能,使用LogSearch/Analytics与ELK(SSD)费用比为13.6%。在测试过程中,我们也尝试把SSD换成SATA以节省费用(LogAnalytics与SATA版费用比为34%),但测试发现延时会从40 ms上升至150 ms,在长时间读写下,查询和读写延时变得很高,无法正常工作了。

    除硬件成本外,日志服务在新数据接入、搭建新业务、维护与资源扩容成本基本为0。

    • 支持各种日志处理生态,可以和Spark、Hadoop、Flink、Grafana等系统无缝对接。
    • 在全球化部署(有20+Region),方便拓展全球化业务。
    • 提供30+日志接入SDK,与阿里云产品无缝打通集成。

    日志服务采集和可视化可以参见如下文章,非核心功能不展开做比较。

ES支撑更新、查询、删除等更通用场景,在搜索、数据分析、应用开发等领域有广泛使用,ELK组合在日志分析场景上把ES灵活性与性能发挥到极致;日志服务是纯定位在日志类数据分析场景的服务,在该领域内做了很多定制化开发。一个服务更广,一个场景更具针对性。当然离开了场景纯数字的比较没有意义,找到适合自己场景的才重要。

我要回帖

更多关于 睫毛不小心被拔了还会长吗 的文章

 

随机推荐