公网数据采集比较(LogHub vs 自建前端机)

对一些应用场景而言,需要实时收集公网数据,例如移动端,HTML网页,PC、服务器、硬件设备、摄像头等实时数据进行处理。

在传统的架构中,一般通过前端服务器+Kafka这样的搭配来实现如上的功能。现在日志服务的LogHub功能能够代替这类架构,并提供更稳定、低成本、弹性、安全的解决方案。我们来比较下:

场景

公网有移动端、外部服务器、网页和设备数据进行采集。采集完成后需要进行实时计算、数据仓库等数据应用。

方案1:前端服务器+Kafka

由Kafka不提供Resful协议,更多是在集群内使用。因此一般需要架设Nginx服务器做公网代理,再通过Logstash、或API通过Nginx写Kafka等消息中间件。

需要设施为:

设施 数目 配置 作用 价格
ECS服务器 2台 1核2GB 前端机、负载均衡,互备 108 元/台*M
SLB 1台 标准 按量计费实例 14.4 元/Month (租赁) + 0.8元/GB (流量)
Kafka / ZK 3台 1核2GB 数据写入并处理 108 元/台*M

方案2:使用LogHub

通过Mobile SDK、Logtail、Web Tracking JS直接写入LogHub EndPoint。

需要设施为:

设施 作用 价格
LogHub 实时数据采集 <0.2元/GB,参见计费规则

场景对比

场景1:一天10GB数据采集,大约一百万次写请求。( 这里10GB是压缩后,实际前数据大小一般为50GB-100GB左右)

方案1
--------------
SLB 租赁:0.02  24  30 = 14.4 元
SLB 流量:100.830  = 240 元
ECS 费用:108 * 2 = 216
Kafka ECS: 免费,假设与其他服务公用
共计:484.8 元 / 月

方案2:
--------------
LogHub流量:10  0.2  3- = 60 元
LogHub请求次数:0.12 (假设一天100W请求)* 30 = 3.6 元
共计:63.6 元

场景2:一天1TB数据采集,大约一亿次写请求

方案1
--------------
SLB 租赁:0.02  24  30 = 14.4 元
SLB 流量:1000  0.8 30  = 24000 元
ECS 费用:108 * 2 = 216
Kafka ECS: 免费,假设与其他服务公用
共计:24230.4 元 / 月

方案2:
--------------
LogHub流量:1000  0.15  30 = 4500 元 (阶梯计价)
LogHub请求次数:0.12  100(假设一天1亿请求) 30 = 360 元
共计:4860 元 / 月

方案比较

从以上两个场景可以看到,使用Loghub进行公网数据采集成本是非常有竞争力的。除此之外,和方案1相比还有其他优势:

  • 弹性伸缩:MB-PB/Day 间流量随意控制
  • 丰富权限控制:通过ACL控制读写权限
  • 支持HTTPS:传输加密
  • 日志投递免费:不需要额外开发就能与数据仓库对接
  • 详尽监控数据:让你清楚业务情况
  • 丰富SDK与上下游对接:和Kafka一样拥有完整的下游对接能力,和阿里云及开源产品深度整合

有兴趣可以参见日志服务主页体验该服务。

时间: 2024-09-08 11:17:09

公网数据采集比较(LogHub vs 自建前端机)的相关文章

juno采用nova-network,建虚机报错!

问题描述 我在一台DELLR710服务器上部署了vsphere,这台服务器只启用了一块网卡,我已经开启了混杂模式.然后在它上面建了3个虚机部署juno,网络用的是nova-network.opst-01为controller,一块网卡eth0.opst-02为网络节点+计算节点,opst-03为计算节点.这俩都有两块网卡,其中eth1为虚机提供通信.用的是nova-network的vlan模式.新建虚机出错,如图: 解决方案

关于前端的思考与感悟

万事开头难. 当我想要认真写一篇文章向大家分享我对前端的认识与感悟的时候,突然就深刻的体会到了这句话确实太有道理了. 最近几年对于web前端的传闻很多,比如人才稀缺,简单易学,待遇丰厚,整体势头发展良好等等.遇到过一个不太熟搞后台开发的同事跑来问我学习前端 需要掌握哪些内容,也听说过一个搞IOS开发准备自学前端半个月然后要去找前端工作,也曾看到过有人对前端市场人才的稀缺这样吹捧过: 现在,几乎整个互联网行业都缺前端工程师,不仅在刚起步的创业公司,对上市公司乃至巨头这个问题也一样存在.没错,优秀的

大数据浪潮下,前端工程师眼中的完整数据链图

马云曾经说过『人类正从IT时代走向DT时代』.正如他说言,今天几乎所有的互联网公司背后都有一支规模庞大的数据团队和一整套数据解决方案作决策,这个时代已经不是只有硅谷巨头才玩数据的时代,是人人都在依赖着数据生存,可以说如今社会数据价值已经被推到前所未有的高度. 我作为一名前端工程师在阿里巴巴数据团队工作多年,深入了解数据生产加工链路与产品化.我们这群前端是与界面最近的工程师们,似乎与数据离得很远,对于我们来说与数据有些怎样连接呢. 完整数据链路 首先,我用直观的一张图绘制出数据采集到产出的流程,中

前端视角解密双十一晚会的魔术节目

       其实在今年8月份的云栖大会上,阿里云宣布推出人工智能ET,引起了业内的广泛关注.而在双十一晚会上,为了能够引出马总及后面的节目,ET也参与表演了一个魔术.        在视频中大家会发现,ET有一段时间的停顿,没有很快地进行回话.是什么原因导致了这样一个情况发生.答案在最后揭晓.        下面让我们来看一下前端在整个工程中我们都做了哪些事情,来保障整个双十一节目的一个顺利进行.这一张是双十一当晚,ET的整个架构图.        这张图里可以看到所有的东西可以说都是由我们小

日志系列--程序日志处理挑战与方案

程序日志(AppLog)有什么特点? 内容最全:程序日志是由程序员给出,在重要的地点.变量数值以及异常都会有记录,可以说线上90%以上Bug都是依靠程序日志输出定位到 格式比较随意:代码往往经过不同人开发,每个程序员都有自己爱好的格式,一般非常难进行统一,并且引入的一些第三方库的日志风格也不太一样 有一定共性:虽然格式随意,但一般都会有一些共性的地方,例如对Log4J日志而言,会有如下几个字段是必须的: 时间 级别(Level) 所在文件或类(file or class) 行数(Line Num

hbase+hive应用场景

一.Hive应用场景 本文主要讲述使用 Hive 的实践,业务不是关键,简要介绍业务场景,本次的任务是对搜索日志数据进行统计分析. 集团搜索刚上线不久,日志量并不大 .这些日志分布在 5 台前端机,按小时保存,并以小时为周期定时将上一小时产生的数据同步到日志分析机,统计数据要求按小时更新.这些统计项, 包括关键词搜索量 pv ,类别访问量,每秒访问量 tps 等等. 基于 Hive ,我们将这些数据按天为单位建表,每天一个表,后台脚本根据时间戳将每小时同步过来的 5 台前端机的日志数据合并成一个

Solaris 系统维护

 5 系统维护5.1 Solaris 系统   涉及的服务器 Account1(218.29.0.239), Account2(218.29.0.240), Oradb1(218.29.0.244) ,Oradb2(218.29.0.245)  5.1.1 系统概况1. 操作系统基本信息: uname -a 将依次显示 操作系统名称,hostname,操作系统大版本信息,操作系统小版本信息,硬件类型,cpu类型,平台信息.  2. 内核信息:修改/etc/system 文件更改缺省的内核参数,m

日志系列--计量日志处理方案

使用云服务最大好处是按量付费,无需预留资源,因此各云产品都有计量计费需求.这里我们介绍一种基于日志服务计量计费方案,该方案每天处理千亿级计量日志,被众多云产品使用: 计量日志生成计费结果过程 计量日志记录了用户涉及计费的项目,后台计费模块根据计费项和规则进行运算,产生最后账单.例如如下原始访问日志记录了项目(Project)使用情况: microtime:1457517269818107 Method:PostLogStoreLogs Status:200 Source:10.145.6.81

车牌识别智能停车场系统方案

1 概述 在现代化停车场管理中,涉及到各方面的管理,其中车辆的管理是一个重要的方面.尤其是对特殊停车场.大院而言,要求对各种车辆实时地进行严格的 管理,对其出入的时间进行严格的监视,并对各类车辆进行登记(包括内部车辆和外部车辆)和识别,如为内部车辆则正常放行,如外部车辆则需要进行记录.检查后做出放行或阻挡的处理,并将各种信息输入到数据库.对大规模的营区中,各种出入的车辆较多,如每辆车都要进行人工判断,既费时,又不利于管理和查询,保卫工作比较困难,效率低下.为了改善这种与现代化停车场.大院不相称的