简志
2017-07-11
2775浏览量
使用云服务最大好处是按量付费,无需预留资源,因此各云产品都有计量计费需求。这里我们介绍一种基于日志服务计量计费方案,该方案每天处理千亿级计量日志,被众多云产品使用:
计量日志记录了用户涉及计费的项目,后台计费模块根据计费项和规则进行运算,产生最后账单。例如如下原始访问日志记录了项目(Project)使用情况:
microtime:1457517269818107 Method:PostLogStoreLogs Status:200 Source:10.145.6.81 ClientIP:112.124.143.241 Latency:1968 InFlow:1409 NetFlow:474 OutFlow:0 UserId:44 AliUid:1264425845278179 ProjectName:app-myapplication ProjectId:573 LogStore:perf UserAgent:ali-sls-logtail APIVersion:0.5.0 RequestId:56DFF2D58B3D939D691323C7
计量计费程序读取原始日志,根据规则生成用户在各维度使用数据(包括流量、使用次数、出流量等):
让我们看下几个计量日志计费场景:
既要算对,又要算准是一件要求很高的事情,系统要求如下:
其他需求(Plus):
现实中还有两类不小的挑战:
这里我们讨论一种阿里云基于日志服务开发计量计费方案,该方案已在线上稳定运行多年,从未出现过一粒算错,延迟等情况,供单价参考
以阿里云日志服务的LogHub功能为例:
实时计量程序内部结构:
(我们可以以此类推,把选择时间计算逻辑修改为1分钟,10秒钟等)
性能分析:
在一些计费场景下(例如运营商、IoT等)计量日志量会很大(例如十万亿,数据量为2PB/Day),折算压缩数据后一小时有16TB,以万兆网络读取需要1600秒,已不能满足快速出账单需求。
这里一般使用2种手段:
我们对于产生计量日志程序进行改造(例如Nginx),先在内存中做了聚合,每隔1分钟Dump一次该时间段聚合的汇总计量日志结果。这样数据量就和总体的用户数相关了:假设Nginx该时间段内有1000个用户,一个小时数据点也才1000 200 60 = 12GB(压缩后为 240 MB)
LogHub下每个日志库可以分配不同Shard(分区),我们可以分配3个分区,3个计量消费程序。为了保证一个用户计量数据总是由一个消费程序处理,我们可以根据用户ID Hash到固定Shard中。例如杭州市西湖区用户写在1号Shard,杭州上城区用户数据写在2号Shard,这样后台计量程序就可水平扩展。
LogHub 下每个Logstore可以设置生命周期(1-365天),如果计费程序需要重新消费数据,在生命周期内可以任意根据时间段进行计算。
对LogHub中数据可以创建索引,支持实时查询与统计分析,例如我们想调查有一些特别大的计量日志:
Inflow>300000 and Method=Post* and Status in [200 300]
在对Loghub中数据打开索引后,即可实时实时查询与分析
也可以在查询后加上统计分析:
Inflow>300000 and Method=Post* and Status in [200 300] | select max(Inflow) as s, ProjectName group by ProjectName order by s desc
日志服务提供LogHub中数据投递功能,支持自定义分区、自定义存储格式等将日志存储在OSS/MaxCompute上,利用E-MapReduce、MaxCompute、HybridDB、Hadoop、Hive、Presto、Spark等进行计算。
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。
阿里云存储基于飞天盘古2.0分布式存储系统,产品多种多样,充分满足用户数据存储和迁移上云需求。