IoT日志利器:嵌入式日志客户端(C Producer)发布

2017年12月19日至20日,2017云栖大会·北京峰会在国家会议中心召开,飞天智能是贯穿云栖大会不变的主题,云计算、大数据、人工智能、物联网等热门话题备受各方关注。其中阿里云日志服务发布的嵌入式日志采集客户端(C Producer Library) 就是其中解决物联网日志采集、分析难的利器。

背景

IoT(Internet of Things)正在高速增长,越来越多设备开始逐步走进日常生活(例如智能路由器、各种电视棒、天猫精灵、扫地机器人),让我们体验到智能领域的便利。距Gartner预测,到2020年末预计会有200亿智能设备,可见该领域的巨大市场。

作为IoT/嵌入式工程师,除了需要深厚的开发功底外,面对海量的设备,如何有能力管理、监控、诊断这些“黑盒”设备至关重要。我们总结了嵌入式开发需求,主要有以下几点:

  • 数据采集:如何实时采集分散在全球各地的百万/千万级设备上的数据?
  • 调试:如何使用一套方案既满足线上数据采集以及开发时的实时调试?
  • 线上诊断:某个线上设备出现错误,如何快速定位设备,查看引起该设备出错的上下文是什么?
  • 监控:当前有多少个设备在线?工作状态分布如何?地理位置分布如何?出错设备如何实时告警?
  • 数据实时分析:设备产生数据如何与实时计算、大数据仓库对接,构建用户画像?

思考以上问题的解决方案,我们发现在传统软件领域那一套手段面临IoT领域基本全部失效,主要挑战来自于IoT设备这些特点:

  • 数目多:在传统运维领域管理1W台服务器属于一家大公司了,但10W在线对于IoT设备而言只是一个小门槛
  • 分布广:硬件一旦部署后,往往会部署在全国、甚至全球各地
  • 黑盒:难以登陆并调试,大部分情况属于不可知状态
  • 资源受限:出于成本考虑,IoT设备硬件较为受限(例如总共只有32MB内存),传统PC领域手段往往失效

针对不同端的数据采集

日志服务(原SLS) 客户端Logtail在X86服务器上有百万级部署,可以参见文章:Logtail技术分享 : 多租户隔离技术+双十一实战效果,Polling + Inotify 组合下的日志保序采集方案。除此之外我们还有以下几种方式:

  • 移动端SDK:Android/IOS平台数据采集,一天已有千万级DAU
  • Web Tracking(JS):类似百度统计,Google Analytics 轻量级采集方式,无需签名

在IoT领域,我们从多年Logtail的开发经验中,汲取其中精华的部分,并结合IoT设备针对CPU、内存、磁盘、网络、应用方式等特点,开发出一套专为IoT定制的日志数据采集方案:C Producer

C Producer特点

C Producer Library 继承Logtail稳定、边界特点,可以定位是一个“轻量级Logtail”,虽没有Logtail实时配置管理机制,但具备除此之外70%功能,包括:

  • 提供多租户概念:可以对多种日志(例如Metric,DebugLog,ErrorLog)进行优先级分级处理,同时配置多个客户端,每个客户端可独立配置采集优先级、目的project/logstore等
  • 支持上下文查询:同一个客户端产生的日志在同一上下文中,支持查看某条日志前后相关日志
  • 并发发送,断点续传:支持缓存上线可设置,超过上限后日志写入失败

还有一些专门为IoT准备功能,例如:

  • 本地调试:支持将日志内容输出到本地,并支持轮转、日志数、轮转大小设置
  • 细粒度资源控制:支持针对不同类型数据/日志设置不同的缓存上线、聚合方式
  • 日志压缩缓存:支持将未发送成功的数据压缩缓存,减少设备内存占用

功能优势

C-Producer是量身为IoT定制的方案,因此会有一些特定考虑:

  • 客户端高并发写入:可配置的发送线程池,支持每秒数十万条日志写入,详情参见性能测试
  • 低资源消耗:每秒20W日志写入只消耗70% CPU;同时在低性能硬件(例如树莓派)上,每秒产生100条日志对资源基本无影响
  • 客户端日志不落盘:既数据产生后直接通过网络发往服务端
  • 客户端计算与 I/O 逻辑分离:日志异步输出,不阻塞工作线程
  • 支持多优先级:不通客户端可配置不同的优先级,保证高优先级日志最先发送。
  • 本地调试:支持设置本地调试,便于您在网络不通的情况下本地测试应用程序。

在以上场景中,C Producer Library 会简化您程序开发的步骤,您无需关心日志采集细节实现、也不用担心日志采集会影响您的业务正常运行,大大降低数据采集门槛。

为了有一个感性认识,我们对C-Producer 方案与其他嵌入式采集方案做了一个对比,如下:

整体解决方案

C-Producer + 日志服务可以给IoT带来什么?答案是:IoT日志解决方案:

  • 规模大

    • 支持亿级别客户端实时写入
    • 支持 PB/Day 数据量
  • 速度快
    • 采集快:0延迟:写入0延迟,写入即可消费

      • 查询快:一秒内,复杂查询(5个条件)可处理10亿级数据
      • 分析快:一秒内,复杂分析(5个维度聚合+GroupBy)可聚合亿级别数据
  • 对接广
    • 与阿里云各类产品无缝打通
    • 各种开源格式存储、计算、可视化系统完美兼容

如何使用

一个应用可创建多个producer,每个producer可包含多个client,每个client可单独配置目的地址、日志level、是否本地调试、缓存大小、自定义标识、topic等信息。

性能测试

环境配置:传统X86服务器,树莓派(低功耗环境),配置分别如下:

C-Producer配置

  • ARM(树莓派)

    • 缓存:10MB
    • 聚合时间:3秒 (聚合时间、聚合数据包大小、聚合日志数任一满足即打包发送)
    • 聚合数据包大小:1MB
    • 聚合日志数:1000
    • 发送线程:1
    • 自定义tag : 5
  • X86
    • 缓存:10MB
    • 聚合时间:3秒 (聚合时间、聚合数据包大小、聚合日志数任一满足即打包发送)
    • 聚合数据包大小:3MB
    • 聚合日志数:4096
    • 发送线程:4
    • 自定义tag : 5

日志样例

  1. 10个键值对,总数据量约为600字节
  2. 9个键值对,数据量约为350字节
__source__:  11.164.233.187
__tag__:1:  2
__tag__:5:  6
__tag__:a:  b
__tag__:c:  d
__tag__:tag_key:  tag_value
__topic__:  topic_test
_file_:  /disk1/workspace/tools/aliyun-log-c-sdk/sample/log_producer_sample.c
_function_:  log_producer_post_logs
_level_:  LOG_PRODUCER_LEVEL_WARN
_line_:  248
_thread_:  40978304
LogHub:  Real-time log collection and consumption
Search/Analytics:  Query and real-time analysis
Interconnection:  Grafana and JDBC/SQL92
Visualized:  dashboard and report functions  

测试结果

X86平台结果

  • C Producer可以轻松到达90M/s的发送速度,每秒上传日志20W,占用CPU只有70%,内存140M
  • 服务器在200条/s,发送数据对于cpu基本无影响(降低到0.01%以内)
  • 客户线程发送一条数据(输出一条log)的平均耗时为:1.2us

树莓派平台结果

  • 在树莓派的测试中,由于CPU的频率只有600MHz,性能差不多是服务器的1/10左右,最高每秒可发送2W条日志
  • 树莓派在20条/s的时候,发送数据对于cpu基本无影响(降低到0.01%以内)
  • 客户线程发送一条数据(输出一条log)的平均耗时为:12us左右(树莓派通过USB连接到PC共享网络)

一些典型场景可以参见云栖论坛 和最佳实践。

时间: 2024-10-27 22:45:22

IoT日志利器:嵌入式日志客户端(C Producer)发布的相关文章

日志服务接入方式之log producer library

日志服务(原SLS)团队提供LogHub Producer Library方便客户端接入日志,Producer Library和Consumer Library是对LogHub功能的包装,降低数据收集与消费的门槛. Producer Library解决的问题: 客户端日志不落盘:既数据产生后直接通过网络发往服务端. 客户端高并发写入:例如一秒钟会有百次以上写操作. 客户端计算与IO逻辑分离:打日志不影响计算耗时. 在以上场景中,Producer Library会简化你程序开发的代价,帮助你批量聚

提前认识软件开发(15) 程序调试的利器:日志

如果世界上有一个人能够保证一次写出来的代码是百分之百正确的,那么毫无疑问,他一定是世界上最优秀的程序员,没有之一.为什么要求代码写好过后要进行充分的自测(包括单元测试和集成测试)?就因为是人皆会犯错,是程序就会有bug.作为一名软件开发人员,必须要学会对程序进行测试,也就是要学会程序的调试. 一般而言,对代码的调试有以下几种方法: 第一,凭肉眼看.在开发阶段,我们编写的每一行代码都需要用我们的"火眼金睛"多审查几遍.如果要问,最好的代码调试工具是什么?我认为是人眼.不管是代码还是文档,

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

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

Mysql日志文件和日志类型介绍_Mysql

日志文件类型 MySQL有几个不同的日志文件,可以帮助你找出mysqld内部发生的事情: 日志文件 记入文件中的信息类型 错误日志 记录启动.运行或停止mysqld时出现的问题. 查询日志 记录建立的客户端连接和执行的语句. 更新日志 记录更改数据的语句.不赞成使用该日志. 二进制日志 记录所有更改数据的语句.还用于复制. 慢日志 记录所有执行时间超过long_query_time秒的所有查询或不使用索引的查询. 默认情况下,所有日志创建于mysqld数据目录中.通过刷新日志,你可以强制 mys

Apache日志查看与日志格式配置参数详解

一.定义日志格式 很久以前,日志文件只有一种格式,这就是"公共格式",许多人已经习惯于使用这种格式.随后出现了定制日志格式,而且看起来定制日志格式更很受欢迎,即使公共日志格式本身也重新用定制日志格式定义.本文介绍的就是如何随心所欲地定制日志文件的格式.如何让日志文件记录自己想要的信息. 定制日志文件的格式涉及到两个指令,即LogFormat指令和CustomLog指令,默认httpd.conf文件提供了关于这两个指令的几个示例. LogFormat指令定义格式并为格式指定一个名字,以后

探索Eclipse的嵌入式富客户端平台:移动设备需要Eclipse

简介:本文介绍了嵌入式富客户端平台(embedded Rich Client Platform,eRCP).将学习构成 eRCP 的各种组件,并得到在应用程序中使用它们的一些示例. 背景 嵌入式富客户端平台 (eRCP)的目的是把 Eclipse 的富客户端平台(RCP)带到嵌入式领域. eRCP 由以下组件构成: 标准部件工具包(eSWT)-- 核心,扩展和移动扩展 eJFace eWorkbench eUpdate 我们将讨论每个组件,并在合适的地方使用代 码示例. eSWT 嵌入式标准部件

MYSQL启用日志,查看日志,利用Mysqlbinlog工具恢复MySQL数据库

MYSQL启用日志 [root@jianshe99]# whereis my.ini [root@jianshe99]# vi /etc/my.cnf [mysqld] datadir=/var/lib/mysql socket=/var/lib/mysql/mysql.sock user=mysql # Default to using old password format for compatibility with mysql 3.x # clients (those using the

.NET Core的日志[3]:将日志写入Debug窗口

定义在NuGet包"Microsoft.Extensions.Logging.Debug"中的DebugLogger会直接调用Debug的WriteLine方法来写入分发给它的日志消息.如果需要使用DebugLogger来写日志,我们需要将它的提供者DebugLoggerProvider注册到LoggerFactory上.由于定义在Debug类型中的所有方法都是针对Debug编译模式的,所以在只有针对Debug模式编译的应用中使用DebugLogger才有意义.这里将的"De

.NET Core的日志[2]:将日志输出到控制台

对于一个控制台应用,比如采用控制台应用作为宿主的ASP.NET Core应用,我们可以将记录的日志直接输出到控制台上.针对控制台的Logger是一个类型为ConsoleLogger的对象,ConsoleLogger对应的LoggerProvider类型为ConsoleLoggerProvider,这两个类型都定义在 NuGet包"Microsoft.Extensions.Logging.Console"之中. 本文已经同步到<ASP.NET Core框架揭秘>之中] 目录