随着云服务技术越来越成熟，作为一枚运维，不得不感慨云计算的发展对我的职业生涯起了积极推动的作用，一方面我可以通过云服务来提高我的工作效率，另一方面我节省了更多时间来学习，在提高我专业度的同时，个人能力也越来越强，在此我就以阿里云日志服务，给我带来的便利给大家做一个分享：
一，在使用阿里云的日志服务之前，我分析日志的方法是这样婶儿的，如下图。
通过rsyslog把服务器上的日志汇总到另外一台机器上，然后使用脚本来处理文本，获取所需的数据。
这种方式在日志分析上效率挺低的，还要耗费经历去维护rsyslog服务。
自从使用了阿里云的日志服务后就省心多了。借助阿里云的日志服务构造出来的一整套日志分析系统是这样婶儿的，如下图。
这里主要用到阿里云的三个服务，下面来挨个介绍一下我是怎么使用的。
日志服务（Log Service，简称Log）
这个是整个架构的核心点，我目前主要用它来实现的是日志采集、日志投递以及日志查询分析。
1. 日志采集
目前是在每台机器上安装logtail Agent，来采集日志。在ECS上直接三条命令就安装了，不需要做任何的配置就可以使用了，非常省力。
2. 日志投递
如上图所示，可以把采集强调文字后的日志投递到OSS和ODPS中，这个稍后再说。
3. 日志查询分析
这里是借助于日志服务中的日志索引功能，通过控制台来查询日志，我一般是用这个来跟踪一些用户的访问行为，这里查询速度是非常快的，基本上都是一秒钟内出结果。
当然还可以根据日志服务的API来实现更多的查询，我这里就先不介绍了。
OSS
我会把日志投递到OSS中，主要是因为两个需求。
1. 日志归档存储
把一些历史日志都存放到OSS中，以减少服务器上占用的空间。当然也不是所有历史的日志都存放到OSS中的，通过OSS中的生命周期功能来把更古老的日志删除就可以了。
2. 离线日志分析
因为我也是刚刚把日志分析这事迁移到阿里云不久，有一些古老的脚本需要通过文件来处理日志（这个需要点时间才能干掉这些脚本），目前我的做法是通过API把OSS中的日志下载到ECS中，然后再让那些古老的脚本工作（要知道，ECS通过内网访问OSS是免流量费的啦）
ODPS
ODPS中文名称叫做大数据计算服务，不过刚刚看了一下它的控制台，这个产品要下线了，取而代之的是一个叫数加的产品，其实就是再ODPS中套了一层壳，然后加了额外的一些功能。
数加这个产品暂时我还没完全研究明白，还是接着说一下我最早使用ODPS分析日志的事情吧。
把日志投递到ODPS中，是为了实现把数据更加统一的进行分析，出报表，据说使用Quick BI做报表是非常容易的，不过说来惭愧我一直都是拿ODPS单纯的当个数据库来使用的，还没有用到Quick BI（不过我当时用ODPS的时候好像Quick Bi还没有完善吧，哈哈）
二，这里就举一个简单的例子吧：
通过ODPS的API，来统计周期时间内耗时最长的URL，然后生成报表通过邮件通知（自己生成的表格确实很丑）
比如我这里刚刚统计到一些处理时间将近10秒的URL，通过排查发现都是因为调用了第三方的API，第三方的API接口耗时过长导致，猪一样的队友啊。
OK，以上就是我借助阿里云的日志服务、OSS、ODPS（数加）来处理分析日志的一些事儿。
三，总结受益
在把日志分析切换完全切换到阿里云之前，需要查询东西都需要跑个脚本来完成，查询结果要等个十几分钟才能出来。（不知为何，当时还会归集日志还会产生重复日志的情况，还得先做一遍去重，简直就是噩梦）
现在完全利用了阿里云的日志服务之后，再有同事跑过来让我跟踪某个用户的行为日志，直接给他丢一个阿里云日志服务器的控制台链接，再加一个子账号，让他自己去查了；再有同事跑过来让我查某个接口的使用情况，直接在ODPS上执行一条SQL语句就行了；当然很多事情都做成了自动化的，比如周期内定时捕获日志中的异常，然后发送到相关负责人的邮箱中，我都不用参与了，之前的噩梦就这样变成了春梦，哈哈。
