阿里云日志服务最佳实践手册D.docx
《阿里云日志服务最佳实践手册D.docx》由会员分享，可在线阅读，更多相关《阿里云日志服务最佳实践手册D.docx（16页珍藏版）》请在冰豆网上搜索。
阿里云日志服务最佳实践手册D
最佳实践
基于日志服务解决方案
日志服务与多个云产品、以及第三方开源生态进行对接，最大程度上降低用户使用门槛：
例如流计算、数据仓库、监控等，除此之外在安全等领域引入ISV，可以通过安全云市场享受日志分析专家的服务。
一些典型场景
日志、大数据分析
-通过Agent、API实时收集系统产生事件，例如访问、点击等
-通过LogHub接口进行流计算，例如分析用户最喜爱的节目，当前观看最高的频道，各个省市点播率等，精确运营
i.对日志进行数仓离线归档，每天、每周出详细的运营数据、账单等
ii.适合领域：
流媒体、电子商务、移动分析、游戏运营等。
例如网站运营CNZZ也是日志服务的用户
日志审计
-通过Agent实时收集日志至日志服务，在此过程中无需担心误删、或被黑客删除
i.通过日志查询功能，快速分析访问行为，例如查询某个账户、某个对象、某个操作的操作记录
ii.通过日志投递OSS、ODPS对日志进行长时间存储，满足合规审计需求
iii.适合领域：
电子商务、政府平台、网站等。
阿里云官网产品：
ActionTrail，日志审计等就是基于日志服务开发
问题诊断
-开发过程中，对客户端、移动设备、服务端、模块等加入日志、并通过ID进行关联
i.收集各个模块日志，通过云监控、流计算等实时获得访问情况
ii.当请求或订单发生错误时，开发无需登录服务器，直接通过日志查询功能对错误关键词、次数、关联影响等进行查询，快速定位问题，减少影响覆盖面
iii.适合领域：
交易系统、订单系统、移动网络等
运维管理
i.收集上百台、上千台机器上不同应用日志日志（包括错误、访问日志、操作日志等）
ii.通过不同的日志库、机器组对应用程序进行集中式管理
iii.对不同日志进行处理：
例如访问日志进行流计算做实时监控；对操作日志进行索引、实时查询；对重要日志进行离线存档
iv.日志服务提供全套API进行配置管理和集成
v.适合领域：
有较多服务器需要管理的用户
其它：
-计量计费、业务系统监控、漏洞检测、运营分析、移动客户端分析等。
在阿里云内部，日志服务无处不在，几乎所有云产品都在使用日志服务解决日志处理、分析等问题
第一步：
创建VPC与ECS实例
参考专有网络VPC用户文档操作，创建vpc与ECS实例如下：
第二步：
在ECS机器上安装Logtail
wgethttp:
//logtail-release.vpc100-oss-cn-chmod755logtail.sh
./logtail.shinstallcn_shenzhen_vpc
登陆机器192.168.1.2，安装Logtail，选择写数据到日志服务深圳Region：
详细请参考日志服务安装Logtail。
第三步：
到日志服务控制台进行配置
创建Logstore及Logtail收集配置：
填写文件目录、名称以及日志样例：
创建机器组，将192.168.1.2加入机器组：
将配置应用到机器组，等待约3分钟后开始验证。
第四步：
Logtail心跳状态验证
打开机器组，查看心跳状态：
如心跳异常，请参考日志服务为什么我的Logtail心跳状态不正常排查原因。
第五步：
数据收集验证
当日志文件在持续追加产生时，查看Logstore，预览Logtail收集到的日志数据如下：
基于日志服务如何实现ActionTrail
ActionTrail是一款用于记录用户账号各类API调用操作的产品。
ActionTrail记录了每次API调用的重要信息
，如操作者、操作时间、对象、动作类型、来源等详尽的信息，这些调用记录，可以精确追踪、还原用户行为
，对于安全分析，资源变更追查，合规审查有非常重要的作用。
ActionTrail需要考虑的问题
ActionTrail这样一款有价值的产品是如何实现的，有哪些问题需要考虑？
首先，由于各类API调用的日志分散在各处，怎么去收集散落在各地的日志呢？
之后，各应用的行为不尽相同，日志内容、格式也比如有区别，如何提供一个统一的方式来处理差异的日志？
最后，对于用户来说，如何能够方便地获取ActionTrail提供的调用日志，来进行后续的追踪、分析呢
？
ActionTrail架构
在清楚了ActionTrail的问题和处理流程之后，我们看看ActionTrail是如何实现的。
下面是ActionTrail的框架
ActionTrail如何解决这些问题
对于第一个问题，ActionTrail自己去解析应用记录在本地的日志显然成本太高，这要求ActionTrail完全理解应用日志格式，并侵入应用机器，耦合度实在是太高，那有没有一个更好的方式来处理呢？
其实，基于日志服务，就能很容易解决这个问题。
应用的日志，应用最熟悉，应用各自通过logtail，将每条日志解析成key:
value这样半结构化形式，上传至日志服务应用各自的Project，再通过RAM授权ActionTrail读取这部分日志。
只要事先约定ActionTrail需要的key，ActionTrail就可以直接从日志服务消费各应用的API调用日志了。
由于日志格式是半结构化的，ActionTrail可以使用同样的方式来处理、分析，那第二个问题也解决了。
ActionTrail实时地从日志服务中抓取各应用的日志，提取必要的字段，并将剩余的字段统一打包在一起。
清洗完毕的数据，ActionTrail也记录在本地，通过logtail实时上传至日志服务中ActionTrail的Project中。
下图就是经过清洗处理后的一条日志，该日志记录了一个用户在17:
53的时候重启了一个虚拟机。
最后，如果将ActionTrail处理后的日志交到用户，让用户方便地处理呢？
放到用户的Ossbucket中是一个不错的选择。
ActionTrail定期从日志服务中批量读取处理后的日志，根据用户账号和应用类型进行分类，上传至用户授权的bucket中，这样用户就可以直接从自己的ossbucket中读取这部分日志了。
基于日志服务的监控系统
日志服务简介
日志服务是阿里云一个重要的基础设施，支撑着阿里云所有集群日志数据的收集和分发。
众多应用比如OTS、ODPS、CNZZ等利用日志服务logtail收集日志数据，利用API消费数据，导入下游实时统计系统或者离线系统做分析统计。
作为一个基础设施，日志服务具备：
1.可靠性：
经过多年阿里集团内部用户的检验，经历多年双十一考验，保证数据的可靠、不丢失。
2.可扩展性：
数据流量上升，通过增加shard个数快速动态扩容处理能力。
3.便捷性：
一键式管理包括上万台机器的日志收集。
日志服务帮用户完成了日志收集，统一了日志格式，提供API用于下游消费。
下游系统可以接入多重系统重复消费，比如导入Spark、Storm做实时计算，也可以导入elasticsearch做搜索，真正做到了一次收集，多次消费
。
在众多数据消费场景中，监控是最常见的一种场景。
本文介绍阿里云基于日志服务的监控系统。
日志服务把所有集群的监控数据作为日志收集到服务端，解决了多集群管理和异构系统日志收集的问题，监控数据统一成格式化的日志发送到日志服务.
日志服务为监控系统提供了
1.统一的机器管理：
安装一次logtail，所有的后续操作在日志服务端进行。
2.统一的配置管理：
需要收集哪些日志文件，只要在服务端配置一次，配置会自动下发到所有机器。
3.结构化的数据：
所有数据格式化成日志服务的数据模型，方便下游消费。
4.弹性的服务能力：
处理大规模数据写入和读取的能力。
监控系统架构
如何搭建监控系统
1.收集监控数据：
1.参考快速入门了解如何配置SLS的日志收集，确保日志收集到了日志服务。
2.中间件使用API消费数据
可以参考SDK使用方法，选择适合你的SDK版本。
通过SDK的PullLog接口从日志服务批量消费日志数据，并且把数据同步到下游实时计算系统。
3.搭建storm实时计算系统
选择storm或者其他的类型的实时计算系统，配置计算规则，选择要计算的监控指标，计算结果写入到OTS中
。
4.展示监控信息
通过读取保存在OTS中的监控数据，在前端展示；或者读取数据，根据数据结果做报警。
网站访问日志统计分析介绍
场景
用户使用ECS搭建网站，网站的访问日志（Nginx,Apache访问日志）收集到阿里云日志服务中供查询。
为了从访问日志中挖掘出更多价值，日志服务提供了一个docker镜像，用于实时统计和展示网站访问的一系列指标,例如PV，UV，延时，地理，状态码，爬虫，网络流量等指标。
日志字段
192.168.1.101--[17/Mar/2016:
10:
28:
30+0800]"GET/fonts/fontawesome-webfont.woff?
v=4.2.0HTTP/1.1"0.02112073040""Mozilla/5.0（Macintosh;IntelMacOSX10_11_3）AppleWebKit/537.36（KHTML,likeGecko）Chrome/49.0.2623.87Safari/537.36"
以上述日志为例，分别提取的字段包括
字段名
字段样例
ip
192.168.1.101
method
GET
path
/fonts/fontawesome-webfont.woff?
v=4.2.0
latency
0.021
request_length
1207
status
304
response_length
0
referer
user_agent
Mozilla/5.0（Macintosh;IntelMacOSX10_11_3）AppleWebKit/537.36（KHTML,likeGecko）Chrome/49.0.2623.87Safari/537.36
指标
PV
分别以5分钟、1小时、1天为统计周期，统计每个周期内的日志总数。
UV
分别以1小时、1天为统计周期，统计每个周期内的IP总数。
页面
以天为统计周期，统计访问最多的页面路径，以及访问最多的参数。
例如请求/fonts/fontawesome-webfont.woff?
v=4.2.0,提取出页面/fonts/fontawesome-webfont.woff和参数v=4.2.0
方法
方法指的是HTTP方法，包括GET，POST，DELETE，PUT等。
以小时和天为统计周期，统计每个周期内每个方法的日志条数。
地理
统计每个IP所属的省份，展示所选时间段内每个省份的分布图。
状态码
状态码指的是HTTP状态码，包括200，401，403，500等常见状态码。
以小时和天为统计周期，统计每个周期内的状态码次数。
浏览器
浏览器分为多个子指标，分别统计每一个子指标出现的PV、UV。
包括
-终端类型
●移动终端
●非移动终端浏览器类型
●chrome
●safari
●IE
●firefox
操作系统
●mac
●window
●linux
浏览器内核
●webkit
●gecko
爬虫
统计常见的爬虫访问量，常见爬虫包括XX、Google、360、今日头条。
来源页
根据referer统计的来源域名，统计来源最高的20个域名。
延时
-统计每5分钟内的网络请求的延时的平均值和最大值。
-统计每天分布最多的延时的分布情况。
出现次数较少的延时区间不会加入统计，比如一天内只有一次延时为8s，大部分的延时都在0.3s到0.5s之间，那么只会统计0.3->0.4,0.4->0.5的延时分布。
-统计每个小时延时最大的日志。
流量
以小时为单位，根据request_length字段和response_length字段，统计访问的入网流量和出网流量的大小。
和GoogleAnalytics的比较
GoogleAnalytics
基于日志服务的访问统计
实现方式
在浏览器端加JS，用户访问时触发统计
根据服务端访问日志统计
是否能看到爬虫信息
否
是
能否看到请求延时
否
是
开始使用
请参考使用文档。
网站访问日志统计分析
使用视频
如何使用网站访问日志分析请参照视频。
Demo地址
必要条件
Nginx/Apache访问日志必须接入到阿里云日志服务开通日志服务
开通容器服务
有阿里云AccessKey可以访问日志服务（可以是子帐号）
子帐号权限
如果您使用子帐号授权，请参考下边的权限配置，将${your_project}替换成你的Project名称
{
"Version":
"1","Statement":
[
{
"Action":
[
"log:
Get*","log:
List*"
，${your_logstore}替换成您的访问日志所在的Logstore。
],
"Resource":
"acs:
log:
*:
*:
project/${your_project}/logstore/${your_logstore}","Effect":
"Allow"
},
{
"Action":
["log:
CreateConsumerGroup","log:
ListConsumerGroup",
"log:
ConsumerGroupUpdateCheckPoint","log:
ConsumerGroupHeartBeat","log:
GetConsumerGroupCheckPoint"
],
"Resource":
"acs:
log:
*:
*:
project/${your_project}/logstore/${your_logstore}/consumergroup/*","Effect":
"Allow"
}
]
}
非必要条件
-自建mysql或者RDS（默认使用docker镜像内的mysql）
实施步骤
实施步骤以ubuntu系统为例，其他系统请以本文档做参考
访问日志接入到阿里云日志服务，具体接入方法请参考阿里云日志服务文档。
开通容器服务。
在容器服务中创建集群，操作系统选择ubuntu。
在容器服务中创建应用。
i.应用名称输入dashboard（或自定义）。
ii.部署集群选择刚刚创建的集群。
iii.点击"使用镜像创建"。
iv.点击选择镜像，选择阿里云镜像，access_log_stat_dashboard镜像。
选中出现的aliyunlog/access_log_stat_dashboard镜像。
v.在【web路由规则】中，容器端口输入80，域名输入dashboard，点击"添加"。
vi.点击确定。
在【服务】中，找到刚刚创建的服务（dashboard，或自定义服务名称），点击服务名称，在出现的基本信息中找到访问端点，例如访问端点。
6.在浏览器中打开上述URL，开始使用。
7.首次打开dashboard，需要使用日志服务的帐号信息登录，包括包括region,project,AccessId,AccessKey。
8.登录完成后，首次使用dashboard要求配置：
i.日志信息。
包括region,project,AccessId,AccessKey，LogStore。
比登录信息多了一个LogStore。
ii.日志内容字段映射，docker镜像为使用一些默认的名称来描述访问日志的一些字段，如果您在接入日志服务时使用不同的字段名称，请在这里做字段映射，保证您的字段的含义能够被分析程序识别。
例如latency字段，假如您接入日志服务时配置该字段的名称为request_time，那么需要在这里填写request_time。
一段日志样例：
192.168.1.101--[17/Mar/2016:
10:
28:
30+0800]"GET/fonts/fontawesome-webfont.woff?
v=4.2.0HTTP/1.1"0.02112073040""Mozilla/5.0（Macintosh;IntelMacOSX10_11_3）AppleWebKit/537.36（KHTML,likeGecko）Chrome/49.0.2623.87Safari/537.36"
后台处理key
字段样例
ip
192.168.1.101
method
GET
path
/fonts/fontawesome-webfont.woff?
v=4.2.0
latency
0.021
request_length
1207
status
304
response_length
0
referer
user_agent
Mozilla/5.0（Macintosh;IntelMacOSX10_11_3）AppleWebKit/537.36（KHTML,likeGecko）Chrome/49.0.2623.87Safari/537.36
高级选项
镜像计算结果的数据保存在镜像的mysql中,如果您释放您的容器，那么历史计算结果会丢失，为了保证所有的历史结果，请您使用自己的mysql：
grantallprivilegeson*.*tologuser@'%'identifiedby'123456789';flushprivileges;
创建一个mysql用户，允许这个用户从docker中访问这个mysql
上述用户名和密码根据自己的需求自定义
-
sudoservicemysqlrestart
修改/etc/mysql/my.conf,注释掉bind-address0.0.0.0这一行重启mysql
点击dashboard页面上方的『计算结果临时保存在docker容器中，若需永久保存，请更改数据库』
，进入配置mysql。
填写mysql的地址和账户信息，点击【迁移】。
使用ECS启动docker
pull
dockerrun--dns223.5.5.5-p80:
80-d
上文讲述了如何使用容器服务来启动Docker，对于购买了ECS的用户而言，可以使用自己的虚拟机来启动Docker。
在ECS上启动镜像，请执行下边的命令：
阿里云消息服务（MNS）开通将日志推送日志服务功能，这里我们介绍下如何利用这部分日志。
消息服务日志格式参见队列消息操作日志、以及主题消息操作日志两个章节，其中日志包含了消息生命周期的所有内容，时间、地点、操作和上下文等。
我们可以通过三种方法对日志进行分析：
实时查询
选定时间内，发了多少条消息
或指定Queue，以及Action:
SendMessage，既可以看到该时间段内有2条消息被发出
某一条消息的生命周期如何？
通过在Query中输入MessageId既可以快速检索到
某个服务器向消息队列发布了多少条消息？
输入该服务器IP即可，也可以通过IP+DeleteMessage等组合查询该时间段行为
实时计算&离线计算
-实时计算：
使用Spark、Storm或StreamCompute，ConsumerLibrary等方式可以实时对消息服务日志进行分析。
例如：
●对一个队列而言，Top10消息的产生者、消费者分别是谁哪些IP？
●生产和消费的速度是否均衡？
某些消费者在处理延时上是否有瓶颈？
-离线：
使用MaxCompute或E-MapReduce/Hive进行大时间跨度的计算
●最近一周内，消息从发布到被消费平均延迟是什么？
●对比升级前和升级后两个时间段内性能变化如何？
全文完
升级会员 