文档

消费-按量计费日志

更新时间:

使用云服务最大好处是按量付费,无需预留资源,因此各云产品都有计量计费需求。本文介绍一种基于日志服务按量计费方案,该方案每天处理千亿级计量日志,被众多云产品使用。

按量计费日志

使用场景

  • 电力公司:每10秒会收到一条日志,记录该10秒内每个用户ID下该周期内功耗、峰值、均值等,每天、每小时和每月给用户提供账单。

  • 运营商:每隔10秒从基站收到时间段内某个手机号码的动作(上网、电话、短信、VoIP)、使用量(流量)、时长等信息,后端计费服务统计出该区间内消耗资费。

  • 天气预测API服务:根据用户调用接口类型、城市、查询类型、结果大小等对用户请求进行收费。

要求与挑战

既要算对,又要算准是一件要求很高的事情,系统要求如下:

  • 准确可靠:既不可多算,也不能少算。

  • 灵活:支持补数据等场景,例如一部分数据没有推送过来,当需要修正时可以重新计算。

  • 实时性强:能够做到秒级计费,对于欠费场景快速切断。

其他需求(Plus):

  • 账单修正功能:在实时计费失败时,我们可以通过理想计费进行对账。

  • 查询明细:支持查看自己消费明细。

现实中还有两类挑战:

  • 不断增长的数据量:随着用户以及调用上升,数据规模会越来越大,如何保持架构的弹性伸缩。

  • 容错处理:计费程序可能有Bug,如何确保计量数据与计费程序独立。

本文介绍一种基于日志服务按量计费方案,该方案已在线上稳定运行多年,从未出现过一例算错、延迟等情况,供大家参考。

工作原理

以日志服务LogHub功能为例:

  1. 使用LogHub进行计量日志实时采集与计量程序对接:LogHub支持的50+种接入手段。

  2. 计量程序每隔固定时间消费LogHub中步长数据,在内存中计算生成计费数据结果。

  3. (附加)对明细数据查询需求,可以将计量日志配置索引查询。

  4. (附加)将计量日志推送至OSS、MaxCompute进行离线存储,进行T+1等对账与统计。

架构

实时计量程序内部结构:

  1. 根据LogHub读取接口GetCursor功能,选定某个时间段日志(例如10:00-11:00)Cursor。

  2. 通过PullLogs接口消费该时间段内数据。

  3. 在内存中进行数据统计与计算,拿到结果,生成计费数据。

    我们可以以此类推,把选择时间计算逻辑修改为1分钟,10秒钟等。

结构

性能分析:

  • 假设每天有10亿条计量日志,每条长度为200字节,数据量为200GB。

  • LogHub默认SDK或Agent都带压缩功能,实际存储数据量为40GB(一般至少有5倍压缩率),一个小时数据量为1.6GB。

  • LogHub读取接口一次最大支持读1000个包(每个包最大为5MB),在千兆网条件下2秒内即可读完。

  • 加上内存中数据累计与计算时间,对1小时计量日志进行汇总,不超过5秒。

计量日志生成计费结果过程

计量日志记录了您所涉及计费的项目,后端计费模块根据计费项和规则进行运算,产生最后账单。例如如下原始访问日志记录了项目(Project)使用情况:

microtime:1457517269818107 Method:PostLogStoreLogs Status:200 Source:203.0.113.10 ClientIP:198.51.100.10 Latency:1968 InFlow:1409 NetFlow:474 OutFlow:0 UserId:44 AliUid:1264425845****** ProjectName:app-myapplication ProjectId:573 LogStore:perf UserAgent:ali-sls-logtail APIVersion:0.5.0 RequestId:56DFF2D58B3D939D691323C7
            

计量计费程序读取原始日志,根据规则生成用户在各维度使用数据(包括流量、使用次数、出流量等):数据1

数据量大应如何解决

在一些计费场景下(例如运营商、IoT等),计量日志量会很大(例如十万亿,数据量为每天2PB),折算压缩数据后一小时有16TB,以万兆网络读取需要1600秒,已不能满足快速出账单需求。

  • 控制产生的计费数据量

    对于产生计量日志程序进行改造(例如Nginx),先在内存中做聚合,每隔1分钟转储一次该时间段聚合的汇总计量日志结果。这样数据量就和总体的用户数相关了。假设Nginx该时间段内有1000个用户,一个小时数据量为1000*200*60=12GB(压缩后为240MB)。

  • 将计量日志处理并行化

    LogHub下每个日志库可以分配不同Shard(分区),我们可以分配3个分区,3个计量消费程序。为了保证一个用户计量数据总是由一个消费程序处理,我们可以根据用户ID Hash到固定Shard中。例如杭州市西湖区用户写在1号Shard,杭州上城区用户数据写在2号Shard,这样后台计量程序就可水平扩展。

    并行

其他问题

  • 补数据怎么办?

    LogHub下每个Logstore可以设置生命周期(1~365天),如果计费程序需要重新消费数据,在生命周期内可以根据任意时间段进行计算。

  • 计量日志散落在很多服务器中怎么办?

    1. 使用Logtail Agent实时采集。

    2. 使用自定义用户标识定义一套动态机器组弹性伸缩。

  • 查询明细需求如何满足?

    对LogHub中的数据创建索引,支持实时查询与统计分析。

    Inflow>300000 and Method=Post* and Status in [200 300]

    您也可以在查询后加上统计分析:

    Inflow>300000 and Method=Post* and Status in [200 300] | select max(Inflow) as s, ProjectName group by ProjectName order by s desc            
  • 存储日志并进行T+1对账。

    日志服务提供LogHub中数据投递功能,其支持自定义分区、自定义存储格式等配置。将日志存储在OSS、MaxCompute上,利用E-MapReduce、MaxCompute、Hadoop、Hive、Presto、Spark等进行计算。投递