负载均衡访问日志（7层）功能现已全地域上线，详情见产品帮助文档
1. Greetings :)
很高兴的告诉大家，阿里云负载均衡即将支持访问日志功能（7层），而令人激动的是，我们认为这可能是这个星球上最好用的访问日志的功能，没有之一。
2. 什么是负载均衡访问日志
众所周知，负载均衡作为公网访问入口，承载着海量的访问请求，这些请求可能来自全球各个地域，分布于不同的客户端，每个请求访问的web服务中的资源也不尽相同，所有这些请求的详细信息即负载均衡的访问日志，通常包括收到请求的时间、客户端的 IP 地址、延迟、请求路径和服务器响应等。
3. 负载均衡访问日志有什么作用
通过访问日志可以了解您的用户所在的地域分布
通过访问日志可以了解您的用户使用的客户端类型
通过访问日志可以知道您的WEB应用在哪些地域有着最低的访问延迟和最佳的服务体验（当然也容易知道访问延迟最高的地方）
...
当然，作为大型WEB应用的运维工程师，日常问题的定位分析肯定也离不开访问日志
4. 如何使用负载均衡访问日志功能
我们将首先介绍如何通过控制台来开通访问日志、查询访问日志以及如何使用访问日志仪表盘；随后我们将使用三个案例来展示负载均衡访问日志功能是如何借助于阿里云日志服务SLS的强大分析能力成为（可能是）这个星球上最好用的访问日志功能。
4.1. 开通访问日志
在负载均衡SLB控制台中点击日志管理下的访问日志菜单项，首次访问会需要提示授权
授权完成后，在访问日志页面就可以看到待开通访问日志功能的SLB实例列表，点击右侧的设置
在弹出的对话中选择存储日志的LogProject和LogStore ，这里我们没有提前创建好LogProject和LogStore，因此系统提示我们需要去创建一个
在SLS控制台点击创建Project后会弹出对话框，输入Project名称并选择地域，注意地域需要和SLB所在地域一致
当我们创建好之后，回到负载均衡访问日志设置界面，选择所创建的LogProject和LogStore,点击确定即完成开通
开通完成后，会提示开通成功。如果您第一次使用该LogStore来存储负载均衡访问日志，建议通过点击向导链接，快速针对负载均衡访问日志的相关字段设置索引并创建仪表板，所有过程只需要点下一步即可；如果之前已经对该LogStore配置过向导，则可以忽略此此步骤
4.2. 查询访问日志
点击SLB实例对应的SLS日志存储路径，本例中是slb-l7-accesslog/test-test-test,即可跳转到日志查询界面
查询负载均衡访问日志页面
4.3. 查看日志仪表盘
点击左上方返回箭头，退回到上一级界面
点击左侧仪表盘,即可看到之前通过向导默认创建好的Dashboard，点击查看
仪表板中有非常丰富的信息可供用户查看
如：TOP客户端IP(由于是测试访问，所以只有一个源IP)
返回状态码分布，右侧显示的是SLB的返回状态码，右侧是后端服务器返回的状态码
TOP访问URI即相关信息
负载均衡返回状态码在时间段上的分布和走势
负载均衡以及后端服务器的相应时间分布
等等等等，这里不再一一列举，还有更多非常直观、有用的图表期待您自己去发现！：）
接下来..
4.4. 日志实时分析案例一：使用访问日志快速找到异常访问
某天运维工程师王大锤在查看实时日志dashboard时发现，某段时间非200的错误占比很高
通过点击报表右上角箭头深钻（drill-down）到日志库中查看细节,深钻日志查看。
通过使用类SQL的查询语言，大锤非常快速写出一段查询语句，查看404请求ip的来源（地理信息）以及PV情况：
status = 404 | select client_ip, ip_to_province(client_ip) as province, ip_to_city(client_ip) as city, ip_to_provider(client_ip) as provider, count(*) as pv group by client_ip order by pv desc limit 20大锤随手点了一下添加到仪表盘，便将该图表保存到了dashboard中，方便下次查看
他发现来自北京和广东的错误码非常高，于是很快便有了查找问题的具体方向...
...此处省略1万字...
...此处省略2万字...
...此处省略3万字...
很快王大锤就找到了问题的根本所在，修改了代码，重新部署了版本，解决了线上问题。
经过这次线上问题的快速处理，老板记住了王大锤这个名字。
4.5. 日志实时分析案例二：使用访问日志快速定位异常后端服务器
某日王大锤又在做仪表盘巡检时发现，某段时间客户端访问的延迟非常高。并且SLB的响应时间和后端服务器的响应时间均很高，马上他判断出，这一定是某个后端服务器出了问题。
大锤快速的写下了如下的查询语句，查询后端响应时间超过1s以上的服务器
upstream_response_time > 1.0 | select upstream_addr, count(*) as pv group by upstream_addr order by pv desc limit 10
很快他发现了这台出问题的后端服务器，SSH上去后发现，果然CPU持续高位运行，接下来针对高负载做处理了...
王大锤很快解决了问题，又一次得到BOSS的首肯。
4.6. 日志实时分析案例三：分析访问来源辅助商业决策
这是一个大数据的时代，数据的价值无所不在！访问日志中所蕴藏的信息，不仅仅用来trouble-shooting，更有着可以深度挖掘的商业价值！请看下面的案例：
话说马上就要到春节了，老板提出希望搞一次红包活动，提升产品的曝光率和活跃度，可是经费有限，怎样把钱花到刀刃上？是针对APP用户还是PC端用户效果好更好？那些地域的用户又对他们的产品更加青睐？这些数据没有，运营同学一筹莫展...
恰巧王大锤路过，看到运营妹子一脸苦恼，便上前询问原由......听完妹子诉苦，他潇洒的扔了一句：包在我身上了，转身大步来到电脑前...
王大锤先写了一段查询语句，查询TOP20的访问User-Agent
* | select http_user_agent, count(*) as pv group by http_user_agent order by pv desc limit 20User-Agent是用户所使用客户端的标识，通过上面图表，一眼就就能看出哪些客户端访问量最大，那些客户端的用户较少，较少的这些便是他们接下来重点要去提升活跃度的重点客户群了。
接着，王大锤又写了一段简单的查询语句，查询他们的网站，在那些地域的活跃度最高，那些地域访问量最少，并且一键生成了地域分布地图。
* | select ip_to_province(client_ip) as client_ip_province, count(*) as pv group by client_ip_province order by pv desc limit 50不到五分钟，王大锤就将这些数据和图表交给了运营妹子，运营妹子投来了无比崇拜的目光...
很快红包方案就出来了并且快速投放线上，效果非常好。
而老板听说这次运营方案是王大锤给予的数据支撑，再一次微笑着点了点头...
过完春节，由于王大锤多次的出色表现，老板给他升职加薪了；运营妹妹也因为大锤的帮助获得骄人战绩，成为了王大锤的女朋友。
王大锤距离他的人生目标“升任CEO，赢取白富美”又进了一步了！
5. 总结
通过上面的介绍，相信大家对负载均衡访问日志是什么，能做什么，以及阿里云日志服务强大的分析能力有了一个比较全面的了解，相比业界其他使用静态存储的方案而言，阿里云负载均衡访问日志功能有如下几大特点：
- 简单：将开发、运维人员从日志处理的繁琐耗时中解放出来，将更多的精力集中到业务开发和技术探索上去。
- 海量：负载均衡的访问日志数据规模通常很大，处理访问日志需要考虑性能和成本问题。日志服务可以1秒钟分析一亿条日志，且相较于自建开源方案有明显成本优势和性能优势。
- 实时：DevOps、监控、报警等场景要求日志数据的实时性。传统手段无法满足这一需求，例如将数据ETL到Hive等工具分析耗时很长，其中大量的工作花费在数据集成阶段。负载均衡访问日志结合阿里云日志服务强大的大数据计算能力，秒级分析处理实时产生的日志。
- 弹性：可按负载均衡实例级别来开通或关闭访问日志功能，对开通的日志设置1~365天任意存储周期，日志存储Logstore容量可以动态伸缩满足业务增长需求。
6. 预告
最后，预告一下，访问日志功能(7层)2018年春节前即将在新加坡、香港、美东、美西、日本、法兰克福、澳大利亚、迪拜、马来西亚、呼和浩特、张家口等地域上线，随后也将会快速覆盖国内五大地域（北京、上海、杭州、深圳、青岛），请大家持续关注，敬请期待！