阿里云日志服务SLS（阿里云日志服务SLa）

本文目录一览：

• 1、新功能：阿里云反爬虫管理利器！
• 2、分布式日志系统Graylog、Loki及ELK的分析和对比
• 3、阿里云日志服务查询记录

新功能：阿里云反爬虫管理利器！

背景

爬虫形势

Web安全形势一直不容乐观, 根据 Globaldots的2018年机器人报告 , 爬虫占据Web流量的42%左右.

为什么要反爬

防资源过度消耗

大量的机器人访问网站, 设想你的网站有42%的流量都不是真的人访问的. 相当一部分还会大量占用后台的网络带宽, 服务器计算, 存储资源.

防黄牛党

航空公司占座: 黄牛党利用恶意爬虫遍历航空公司的低价票，同时批量发起机器请求进行占座，导致航班座位资源被持续占用产生浪费，最终引发航班空座率高对航空公司造成业务损失，并且损害正常用户的利益。

防薅羊毛党

黄牛党在电商活动时针对有限的高价值商品的限时秒杀、优惠活动等可牟利场景，批量发起机器请求来模拟正常的交易，再将商品、资源进行倒卖从中赚取差价，导致电商企业的营销资源无法触达正常用户，而被黄牛牟取暴利。

防黑客

核心接口被刷: 登录、注册、短信等业务环节作为业务中的关键节点，相关接口往往会被黑客利用，为后续的欺诈行为作准备。

私信菜鸟007即可获取数十套PDF！

为什么需要日志分析

找出隐藏更深的机器人

爬虫与反爬虫是一个攻与防的过程, 根据前述报告, 高级机器人占据了74%的比例(剩余是比较简单的机器人), 而根据 FileEye M-Trends 2018报告 ，企业组织的攻击从发生到被发现，一般经过了多达101天，其中亚太地区问题更为严重，一般网络攻击被发现是在近498（超过16个月）之后。有了日志才能更好的找出隐藏很深的坏机器人.

了解机器人并区分对待

爬虫也分好与坏, 搜索引擎来查询, 才可以达到SEO效果并带来更多有价值的访问. 通过日志可以帮助管理员更好的区分哪些是好的机器人, 并依据做出更加适合自己的反爬配置.

保留报案证据

发现非法攻击的机器人, 可以保留攻击者信息与路径, 作为报警的重要证据.

增强运维效率

基于日志可以发现异常, 并能快速报警并采取行动.

更多附加功能

依托日志服务的其他功能, 可以发挥日志的更大价值.

阿里云反爬管理 - 实时日志分析概述

阿里云反爬管理

云盾Anti-Bot Service是一款网络应用安全防护产品，专业检测高级爬虫，降低爬虫、自动化工具对网站的业务影响。 产品提供从Web、App到API接口的一整套全面的恶意Bot防护解决方案，避免某一环节防护薄弱导致的安全短板。

阿里云日志服务

阿里云的日志服务（log service）是针对日志类数据的一站式服务，无需开发就能快捷完成海量日志数据的采集、消费、投递以及查询分析等功能，提升运维、运营效率。日志服务主要包括 实时采集与消费、数据投递、查询与实时分析 等功能，适用于从实时监控到数据仓库的各种开发、运维、运营与安全场景：

目前，阿里云WAF与日志服务打通，对外开发Web访问与攻击日志。提供近实时的网站具体的日志自动采集存储、并提供基于日志服务的查询分析、报表报警、下游计算对接与投递的能力。

发布地域

适用客户

功能优势

反爬日志实时查询分析服务具有以下功能优势：

开通前提

限制说明

反爬管理所存储的日志库属于专属的日志库，有如下限制：

使用场景

1.追踪机器人爬取与封禁日志，溯源安全威胁：

查看Top 100的爬取机器人列表:

2. 实时正常可信Web请求活动，洞察状态与趋势：

查看PV/UV访问趋势的SQL:

3. 快速了解安全运营效率，即时反馈处理：

查看有效请求与拦截率趋势的SQL:

4. 输出安全网络日志到自建数据与计算中心

进一步参考

我们会陆续发布WAF安全日志分析的最佳时间, 这里可以进一步参考相关用户手册：

分布式日志系统Graylog、Loki及ELK的分析和对比

日志系列：

企业级日志平台新秀Graylog，比ELK轻量多了

日志系统新贵Loki，比ELK轻量多了

1. 为什么需要集中的日志系统？

在分布式系统中，众多服务分散部署在数十台甚至是上百台不同的服务器上，要想快速方便的实现查找、分析和归档等功能，使用Linux命令等传统的方式查询到想要的日志就费时费力，更不要说对日志进行分析与归纳。

如果有一个集中的日志系统，便可以将各个不同的服务器上面的日志收集在一起，不仅能方便快速查找到相应的日志，还有可能在众多日志数据中挖掘到一些意想不到的关联关系。

作为DevOps工程师，会经常收到分析生产日志的需求。在机器规模较少、生产环境管理不规范时，可以通过分配系统账号，采用人肉的方式登录服务器查看日志。然而高可用架构中，日志通常分散在多节点，日志量也随着业务增长而增加。当业务达到一定规模、架构变得复杂，靠人肉登录主机查看日志的方式就会变得混乱和低效。解决这种问题的方法，需要构建一个日志管理平台：对日志进行汇聚和分析，并通过Web UI授权相关人员查看日志权限。

2. 日志系统选择与对比

关于企业级日志管理方案，比较主流的是ELK stack和Graylog。

常见的分布式日志系统解决方案有经典的ELK和商业的splunk。为什么没有选择上面的两种方案呢，原因主要是如下两种：

ELK目前很多公司都在使用，是一种很不错的分布式日志解决方案，但是需要的组件多，部署和维护相对复杂，并且占用服务器资源多，此外kibana也在高版本中开始商业化。

splunk是收费的商业项目，不在考虑范围。

3. 认识graylog

3.1 简介

graylog是一个简单易用、功能较全面的日志管理工具，graylog也采用Elasticsearch作为存储和索引以保障性能，MongoDB用来存储少量的自身配置信息，master-node模式具有很好的扩展性，UI上自带的基础查询与分析功能比较实用且高效，支持LDAP、权限控制并有丰富的日志类型和标准（如syslog，GELF）并支持基于日志的报警。

在日志接收方面通常是网络传输，可以是TCP也可以是UDP，在实际生产环境量级较大多数采用UDP，也可以通过MQ来消费日志。

3.2 优势

部署维护简单

资源占用较少

查询语法简单易懂(对比ES的语法…)

内置简单的告警

可以将搜索结果导出为 json

UI 比较友好

3.3 graylog单机架构图

3.4 graylog集群架构

4、基于 GrayLog ELK 的日志监控

Collector

FileBeat：轻巧占用资源少，但是功能有点弱。「想起了一些东西，都是泪」

Fluentd：个人理解在Logstash与FileBeat中间，可以简单处理一些日志，插件丰富「要再研究下」

自己弄：架构图里面只是mysql调用了自己实现的解析工具，但是其实当日志大到一定的量的还是必须自己来的，类似日志抽样、降级、控制频率等功能，是要真真切切的花费大量时间精力下去的一个sidecar并非动动嘴巴就能搞定的。「都是泪」

Queue

Kafka：王者地位「量小的时候也可以不用这个直接朝后面输出，有很多中间方案大家自己脑补」，不同的日志分不同的topic，严格区分日志所属类型，为后续消费打下基础，比如A业务进入A Topic并在日志中打上所属语言类型的Tag。

Consumer

Logstash：其实这个东西也可以作为收集端来使用，就是比较耗费资源有点重，还会莫名其妙挂了「应该是我不会玩」

GrayLog：本人最喜欢的一个组件，集解析、报警、简单分析、Dashboard、日志TTL的综合体，有这个东西吧其实Kibana就没啥用了，毕竟谁没事天天去分析日志。

Storage

ElasticSearch：全文索引Engine，其实并没有官方说的那么牛，当到一定的并发写入、大量查询之后其实根本不是加机器能解决的，怎么分shard，是按照天保存还是按照条数保存「我比较喜欢按照条数保存，这样可以保证每个index都差不多大小，对于reblance是有好处的，重复利用多盘」如何保存是需要不断调整的。「我们这边不讨论MongoDB去存日志，看着都不靠谱」

规范

其实日志系统最关键的是怎么打、什么格式打、但是这个东西需要消耗大量的时间去定义与各个部门Pk，遇到过大量不讲理的输出，直接线上Debug，600k的并发写入，日志又大又臭谁能扛得住「阿里云的SLS是真的很牛」

卷起袖子加油干，少动嘴，多动手，日志很好玩。在容器化的大环境下也越发的重要。

Flunted + Elasticsearch + Kibana的方案，发现有几个缺点：

不能处理多行日志，比如Mysql慢查询，Tomcat/Jetty应用的Java异常打印

不能保留原始日志，只能把原始日志分字段保存，这样搜索日志结果是一堆Json格式文本，无法阅读。

不符合正则表达式匹配的日志行，被全部丢弃。

对比图

总结

虽然两种解决方案在功能上非常相似，但仍有一些差异需要考虑。

两者之间最重要的区别在于，从一开始，Graylog就定位为强大的日志解决方案，而ELK则是大数据解决方案。Graylog可以通过网络协议直接从应用程序接收结构化日志和标准syslog。相反，ELK是使用Logstash分析已收集的纯文本日志的解决方案，然后解析并将它们传递给ElasticSearch。

在ELK中，Kibana扮演仪表盘的角色并显示从Logstash收到的数据。Graylog在这点上更方便，因为它提供了单一应用程序解决方案（不包括ElasticSearch作为灵活的数据存储），具有几乎相同的功能。因此，部署所需的时间更短。此外，与ELK相比，Graylog开箱即用，且具有出色的权限系统，而Kibana则不具备此功能。作为Elasticsearch的粉丝，我更喜欢Graylog而不是ELK，因为它完全符合我在日志管理方面的需求。

Graylog具有直观的GUI，并提供警报、报告和自定义分析功能。最重要的是，它能在多个日志源和跨机房收集数TB的数据。基于这些优势，我更喜欢用Graylog而不是另一个具有类似功能的流行堆栈——ELK。

如果有需要领取免费资料的小伙伴们， 可以点击此处领取资料哦！

阿里云日志服务查询记录

*|

select

coalesce(max(data),0) as data

from (

select

date_trunc('minute', __time__) as dt, sum(request_length)/60.0 as data

from log

group by dt

order by data desc

limit 3)

取每秒data的最大值 无data值则默认取0

COALESCE表达式用于返回多个表达式中第一个非null的值。

*|select compare(data, 86400) as diff from (select coalesce(max(data),0) as data from (select date_trunc('minute', __time__) as dt, sum(request_length)/60.0 as data from log group by dt order by data desc limit 3))

[12657.483333333334,8549.75,1.4804506954394379]

compare函数用于对比当前时间周期内的计算结果与n秒之前时间周期内的计算结果