金服平台数据分析系统各类日志数据采集方案.docx

金服平台数据分析系统 各类日志数据采集系统总体方案修订记录日期修订版本修改描述作者2017-04-290.5.0开始写金服平台数据分析系统各类日志数据采集方案2017-05-90.7.0初步完成移动和Web页面非实时日志采用Countly实现日志采集与收集实现方案2017-05-180.8.0补充移动和Web页面实时日志采集部分内容2017-05-220.8.5初步设计拦截器实现移动和Web页面后端实时日志采集构架1.金服平台移动 App日志内容要求规范1.1 日志系统需收集更多数据时移动应用采用埋点上传日志技术与 App日志上传暂行规定很早之前，也就是当年的PC时代，由于受限于存储和计算能力，大家一般很少用日志来分析业务。而是在业务逻辑里，将业务需要分析的数据事先写入到库里，针对库的数据进行统计分析。所以之前做OLAP，需要很高级的硬件支持，大家都去IOE等买昂贵的服务器来做数据仓库以及进行数据分析。由于成本的问题，拿到的数据是很少的，所以进行统计分析和挖掘所得到的收益微乎其微。随着Hadoop的兴起，分布式文件系统和分布式计算大大降低了存储成本和计算成本， 使得现在用日志分析业务成为了可能。1.1.1 移动App分析的数据类型对于移动端的App来说，分析的数据大致上都可以分为俩种，一种是在线数据，一种是离线数据，还有 App业务需要的综合动态数据（简称动态数据）。 在线数据 在线数据，即App后端服务所产生的日志数据，例如服务接口的性能数据， 服务接口的调用及其参数等， 通过服务端的日志数据， 我们不但可以统计服务接口的性能指标，还可以针对具体的业务逻辑，做相关的分析，一些常见的App分析指标如新增，活跃，累计，留存等，也都可以通过服务日志来统计出来。因为 App嵌入了移动Web 的Html5 页面，故 App的在线数据包含了App原生应用后端服务接口性能数据和移动Web日志数据。 离线数据 对应的离线数据即是App客户端本身产生的数据， 这种情况一般是发生在客户端不调用底层服务的情况下，需要了解用户在客户端的行为，就需要用到离线数据。离线日志一般记录用户在客户端的具体行为，如用户在客户端的拖动，上下滚动，翻页等不涉及到后端服务的操作，以及App本身的崩溃行为产生的数据，都可以被记录，一般的，记录的内容包括事件类型，控件编号，控件属性及相关参数，事件时间等。因为Html5提供离线功能应用，故这里的离线数据也要考虑离线状态下Html5前端产生或者使用的数据。对于离线数据还要考虑原生与Html5 混搭Hybrid接口上原生到JS和JS到原生的数据调用情况。 动态数据 针对 App，为了统计和分析服务成功率、服务耗时、连接成功率和连接耗时等性能和质量，新增加除了上述在线数据和离线数据的第三种类型数据，暂时命名为综合动态数据(简称动态数据)，一个(综合)动态数据内容主要记录了用户开始操作一个App界面元素、发送Http请求、接收对应的Http响应、界面展现等时间点、过程中内存流量和处理失败原因，对(综合)动态数据和与之关联的在线数据进行关联分析，可以统计出服务成功率、服务耗时、连接成功率和连接耗时等性能和质量数据。1.1.2 在线日志 在线日志，一般来讲，有两种： web服务器的配置化log(如Nginx, apache等web服务器的access.log)这一类日志不需要用户自己做实现， 只需要开启web服务器的相关日志功能，即可完成日志记录。 应用服务器的log一般包括应用服务器的配置化log 以及 用户自定义的log。 用户自定义log包括用户通过相关日志组件自己的debug, waring ,error, info等级别的日志。 这一类日志没有固定的格式，完全有用户自行控制。在线日志一般会伴随业务直接产生在相关的业务服务器上(web服务器日志产生在web服务器上)，但是有的时候，为了将相关服务的监控日志与业务分析日志分离，会将业务日志直接记录在一台独立的日志服务器上。 这里， App的在线日志主要包含上述1.1.1 章节涉及的在线数据类型包含的App原生应用后端服务接口性能数据日志和Html5移动后端Web日志。1.1.3 离线日志离线日志（和离线数据有关的），一般也有两种： 客户端的(本地)行为日志：用户在操作App的时候(客户端不调用底层服务的情况下)产生的行为，都可以记录下来。行为日志一般是用来研究用户使用习惯，分析应用的使用热度的。 同时可以结合客户端异常日志来分析异常原因。 客户端的(本地)异常日志：用来监控客户端异常原因，帮助解决相关问题。针对 App的离线日志除了涉及到App客户端行为日志与异常日志，还要包含Html5离线状态数据日志和Hybrid接口数据日志。1.1.4 (综合)动态日志 (综合)动态日志是针对 App统计和分析服务成功率、服务耗时、连接成功率和连接耗时等性能和质量新增加的日志，该日志数据类型是上述1.1.1章节涉及的(综合)动态数据。1.1.5 埋点及上传不管是在线日志，还是离线日志，或者(综合)动态日志，首先都要确认在什么地方记录日志,于是就引入了埋点的概念。 通俗的讲，在正常业务代码逻辑上，添加记录日志的代码， 都叫做埋点。但是一般的，埋点只用来描述客户端日志记录。由于在线日志是直接产生在服务器端，日志采集工具可以直接从含有日志的服务器上采集日志数据到相应的文件系统，所以不存在日志上传的问题。但是对于离线日志和（综合）动态日志来说， 数据是产生在App客户端的， 所以上传机制必须考虑。1.1.6 离线日志和动态日志上传机制业界采用的离线日志上传机制如下:服务端提供日志记录接口，当客户端有事件时，直接调用日志记录接口将日志记录在服务器端。服务端提供日志上传接口，客户端先将日志暂存客户端本地，当达到一定的大小，网络环境允许的情况下，通过上传接口，将日志文件打包压缩后上传。第一种上传方式，时效性方面有一定的保障，在网络环境允许的情况下，能及时的将信息记录到服务器，但是当埋点较多时，记录日志产生的流量会很大，占据很大的带宽，给用户带来损失。同时，前端的某些行为，如在某个activity停留时间等也无法通过这种在线的方式捕获。还有一个重要的问题是，由于客户端数据没有暂存机制，当网络暂时无法使用时，日志记录接口无法正常调用，所有的日志也就随之丢失。 第二种方式，在时效性上较差，因为它需要等待数据累计到一定程度，或者网络允许的情况下，如在wifi情况下，才发送，但是占用的带宽相对较小，对客户端动作的捕获较为灵活。对于的离线日志和（综合）动态日志，建议采用第二种日志上传方式。App的实时日志和PC-web的页面实时日志在后台的Action或者Controller上处理，详细参见3.2 移动App和Web的实时业务日志采集方案。1.1.7 埋点的三种方案 传统埋点： 开发者直接在客户端埋点。 优点： 开发者可以随意的在任何地方添加埋点。 缺点： 成本高，每次埋点的增删改都需要发版，很难控制。启明星现在采用的就是传统的埋点方式， 由于之前没有统一的规划， 相关页面的同一个按钮，不同的版本功能不同， 但却埋了同一个点，造成统计比较混乱。之后引入了埋点下发平台，虽然一定程度上缓解了这种问题，但是由于其灵活性以及主观性，问题依然无法避免。 可视化埋点 由于传统埋点的一系列问题，自然而然的就产生了可视化埋点的方案， 用可视化交互的手段来代替写代码，将核心代码和配置，资源分开，在App启动时通过网络更新配置和资源来实现埋点功能。 可视化埋点的大体流程如下： 首先埋点服务平台与埋点客户机做关联， 包括客户机包含的埋点模块扫描当前整个客户端页面的控件，形成控件树，并将当前页面截图，发送给埋点服务端平台； 埋点服务端平台接收到截图和控件树数据后，在服务端重新绘制App界面，通过可视化交互的方式，给当前页面需要埋点的控件上添加事件，添加完毕后，形成配置文件， 并发布上线； 装有埋点模块的所有客户端，接收到配置文件并解析， 根据配置为页面中相关的控件添加监听事件， 当这些控件出发事件时记录日志。 其中有很多细节的地方需要注意： 可视化埋点也需要考虑不同版本之间埋点的差异； 可视化埋点在分发埋点配置文件的时候，会有延迟或者丢失的情况， 有的客户端有可能收不到或者很久才能收到配置文件，这样埋点的时效性会大打折扣。无埋点 所谓的无埋点，其实也就是全埋点，它和可视化埋点很像，可视化埋点是根据埋点配置来收集数据，而无埋点方案则是尽可能的收集所有控件的操作数据。实现原理也很简单， 客户端添加扫描代码，为每个扫描到的控件添加监听事件。当事件被触发后，记录日志。 其实，大家对此也不陌生，比如很早之前，对PC站点的统计，各大分析平台，都需要在网页之间添加一段js代码。 其实那段js代码，就是现在提到的无埋点的扫描代码。 这里强调一下，由于可视化埋点是在需要的时候才埋点，所以它并不能回溯事件，也就是说，只能统计需求提出后，埋点开始的所有的数据，埋点之前的数据是拿不到的。而无埋点方案，在开始埋点的时候，所有的数据已经都被记录了，所以它可以查看之前的数据 (这里的之前也是相对与提统计需求的时间，而不是相对于埋点的时间)，也就是说它可以做回溯。而这种回溯是建立在大量存储要求的基础上的。 App暂行采用传统埋点方案。1.2 移动App日志内容参考格式(具体根据需求确定)1.2.2 App客户端离线日志内容格式(参考或草拟)当前字段有(参考阿里巴巴移动数据日志分析数据字段)：字段名类型注释app_idstring当前统一为888888app_namestringapp_id对应的app中文名称app_versionstringapp的应用版本号channelstring应用分发渠道imeistring移动设备国际身份码的缩写imsistring国际移动用户识别码brandstring手机或终端的品牌device_modelstring手机或终端的机型resolutionstring手机或终端的屏幕分辨率osstring操作系统，如: Android、iPhone OSos_versionstring操作系统的版本carrierstring移动运营商，如：中国移动、中国联通、中国电信accessstring连接的网络，如：2G、3G、Wi-Fi、4Gaccess_subtypestring网络类型，如：HSPA、EVDO、EDGE、GPRS等network_typestring根据access,acess_subtype转化后的网络类型schoolstring根据client_ip如果为校园网解析出的学校(由服务器分析)client_ipstring客户端ip(是服务端获取到的外网IP，不是app上传的)longitudestring经度， latitudestring纬度， countrystring根据client_ip解析出的国家或地区(由服务器分析)provincestring根据client_ip解析出的省、直辖市、自治区(由服务器分析)citystring根据client_ip解析出的地级市(由服务器分析)districtstring根据client_ip解析出的区、县、县级市(由服务器分析)session_idstring用户的一次会话id，就是tokenreach_timestring到达日志服务器的时间，此时间可作为日志时间直接使用，格式为：yyyyMMddHHmmss（注意本字段在App上传时为空）event_idstring埋点的事件ID(或者用户行为的标识ID) last_pagestring当前页面来源页(上一页)的页面标题Last_urlstring当前页面来源页(上一页)的页面URL,可以是空start_nowpage_timestring用户最初进入当前页面的时间点(用于计算当前页面的停留时间)now_page_titlestring当前用户离线行为发生时的当前页面now_page_timestring当前用户离线行为发生时的时间now_page_area_idstring标记点击所在页面的栏位所属的区域，如首页的个性化栏位now_content_idstring表示业务内容的ID，例如栏目页的分类ID，搜词页的关键词，促销页的促销活动ID，详情页的商品ID，或者下单页的订单IDnext_pagestring当前用户行为导致的切换页面next_page_timesizestring切换页面后打开页面时间大小arg1string事件参数，当前页面更新时间点(不涉及页面切换)arg2string事件参数，内存流量峰值(参考/wuxuehong0306/article/details/50698298)arg3string事件参数,电池消耗下降峰值(参考/hyddd/p/4402621.html)arg4string保留事件参数1arg5string 保留事件参数2argsstring事件参数，00000表示事件成功，99999表示离线行为事件的结果为失败(arg1对应失败原因，如“sysexit”-异常退出；“actfail”-离线行为失败；“sysdie”-系统僵死)local_timestring终端时间(格式为yyyy-mm-dd hh24:mi:ss)，上报服务器时的时间local_timestampstring终端时间(格式为数字型的unix 时间,精确到毫秒,可通过from_unixtime函数转换成日期)utdidstring服务端生成的设备唯一标识符(设备出厂参数有关，与SIM卡无关)user_nickstring长登录会员名称，长登录是指只要登录一次就会记住该设备最近一次登录会员，即使该设备下一次打开App且没有登录，其日志也会记录该设备最近一次登录会员user_idstring长登录会员idshort_user_nickstring短登录会员名称，短登录是指当前处于登录状态的会员short_user_idstring短登录会员iddsstring分区字段，表示日期，一般格式为yyyymmddhourstring分区字段，表示小时，一般格式为hhabteststring用于AB测试的流量分组ID，例如a表示第一组，b表示第二组，c表示第三组,Z表示当前0组即没有分组事件ID（即event_id）类型如下：事件ID含义详解（后续由app主管负责根据实际情况补充事件ID），离线日志event_id范围是200000到299999，其中200000到249999是正常行为日志事件id范围，250000到259999是离线日志异常事件id(离线日志异常事件是App自身发生的，不是离线行为导致的)200000(本地行为日志)事件用户在客户端的拖动，200001(本地行为日志)事件上下滚动 200002(本地行为日志)事件翻页250000(本地异常日志)事件android手机java crash250001(本地异常日志)事件android手机native crash，iOS crash250002(本地异常日志)事件Android/ios 僵死260000(Hybrid接口数据)事件原生到JS260001(Hybrid接口数据)事件JS到原生260002(Hybrid接口数据)事件切换发生错误270000Html5离线状态数据日志事件写本地数据库270001Html5离线状态数据日志事件读本地数据库270002Html5离线状态数据日志事件1.2.3 App客户端(综合)动态日志内容格式(参考或草拟)当前字段有：字段名类型注释app_idstring当前统一为888888app_namestringapp_id对应的app中文名称app_versionstringapp的应用版本号channelstring应用分发渠道imeistring移动设备国际身份码的缩写imsistring国际移动用户识别码brandstring手机或终端的品牌device_modelstring手机或终端的机型resolutionstring手机或终端的屏幕分辨率osstring操作系统，如: Android、iPhone OSos_versionstring操作系统的版本carrierstring移动运营商，如：中国移动、中国联通、中国电信accessstring连接的网络，如：2G、3G、Wi-Fiaccess_subtypestring网络类型，如：HSPA、EVDO、EDGE、GPRS等network_typestring根据access,acess_subtype转化后的网络类型schoolstring根据client_ip如果为校园网解析出的学校(由服务器分析)client_ipstring客户端ip(是服务端获取到的外网IP，不是app上传的)longitudestring经度， latitudestring纬度， countrystring根据client_ip解析出的国家或地区(由服务器分析)provincestring根据client_ip解析出的省、直辖市、自治区(由服务器分析)citystring根据client_ip解析出的地级市(由服务器分析)districtstring根据client_ip解析出的区、县、县级市(由服务器分析)session_idstring用户的一次会话id，就是tokenreach_timestring到达日志服务器的时间，此时间可作为日志时间直接使用，格式为：yyyyMMddHHmmss（注意本字段在App上传时为空）event_idstring埋点的事件ID(或者用户行为的标识ID，例如点击商品详情为。)，和App访问服务器的原生接口方法名是一一对应的last_pagestring当前页面来源页(上一页)的页面标题Last_urlstring当前页面来源页(上一页)的页面URL,可以是空start_nowpage_timestring用户最初进入当前页面的时间点(用于计算当前页面的停留时间)now_page_titlestring当前用户行为发生时的页面now_page_area_idstring标记点击所在页面的栏位所属的区域，如首页的个性化栏位now_content_idstring表示业务内容的ID，例如栏目页的分类ID，搜词页的关键词，促销页的促销活动ID，详情页的商品ID，或者下单页的订单IDnow_page_timestring当前用户行为发生(或者触发click)时的时间（一般情况与arg4相同）next_page_titlestring当前用户行为导致的切换页面next_urlstring当前用户行为导致的切换页面URL,可以是空next_page_jumptimestring页面即将切换或者跳转的时间点arg1string事件参数，(不是页面变换的)当前页面更新时间点arg2string事件参数，内存流量峰值(参考/wuxuehong0306/article/details/50698298)arg3string事件参数, 电池消耗下降峰值(参考/hyddd/p/4402621.html)arg4string事件参数，发送http请求时间点arg5string事件参数，接收到http响应时间点arg6string保留事件参数1arg7string 保留事件参数2argsstring事件参数，00000表示事件成功，99999表示事件失败(argg1对应失败原因，如“timeout”-超时；“netexcept”-网络异常)local_timestring终端时间(格式为yyyy-mm-dd hh24:mi:ss)，上报服务器时的时间local_timestampstring终端时间(格式为数字型的unix 时间,精确到毫秒,可通过from_unixtime函数转换成日期)utdidstring服务端生成的设备唯一标识符(设备出厂参数有关，与SIM卡无关)user_nickstring长登录会员名称，长登录是指只要登录一次就会记住该设备最近一次登录会员，即使该设备下一次打开App且没有登录，其日志也会记录该设备最近一次登录会员user_idstring长登录会员idshort_user_nickstring短登录会员名称，短登录是指当前处于登录状态的会员short_user_idstring短登录会员iddsstring分区字段，表示日期，一般格式为yyyymmddhourstring分区字段，表示小时，一般格式为hhabteststring用于AB测试的流量分组ID，例如a表示第一组，b表示第二组，c表示第三组,Z表示当前0组即没有分组事件ID（即event_id）类型如下：事件ID含义详解-动态日志event_id范围100000到199999100000注册事件对应注册接口100001登录事件对应登录接口100002启动事件App启动，一般用于计算启动次数100003退出事件App退出，一般用于计算时长2. 金服平台业务系统Web日志内容要求规范2.1 网站Web收集数据常用方法简介 眼下网站分析数据主要有三种收集方式：Web日志、JavaScript标记和包嗅探器。2.1.1 以Web日志的方式Web日志收集数据的过程示意图如下： 从上图可以看出网站分析数据的收集从网站访问者输入URL向网站服务器发出http请求就开始了。网站服务器接收到请求后会在自己的Log文件中追加一条记录，记录内容包括：远程主机名（或者是IP地址）、登录名、登录全名、发请求的日期、发请求的时间、请求的详细（包括请求的方法、地址、协议）、请求返回的状态、请求文档的大小。随后网站服务器将页面返回到访问者的浏览器内得以展现。 一些专业的工具厂商会有专门的处理服务器对大量的Log数据进行处理，并将处理后的数据存放入自己的数据库中。网站经营人员通过访问分析报表系统查看网站的分析数据。也有一些中小网站主出于成本的考虑不会求助于专业的工具厂商，他们会借助简单的网站日志分析软件完成对Log数据的处理，当然处理后的数据会有一定的局限性。2.1.2以JavaScript标记的方式-又称“埋码技术”或者网络信标JavaScript标记收集数据的过程示意图如下： 上图所示JavaScript标记同Web日志收集数据一样，从网站访问者发出http请求开始。不同的是，JavaScript标记返回给访问者的网页代码中会包含一段特殊的JavaScript代码，当页面展示的同时这段代码也得以执行。这段代码会从访问者的Cookie中取得详细信息（访问时间、浏览器信息、工具厂商赋予当前访问者的userID等）并发送到工具商的数据收集服务器。数据收集服务器对收集到的数据处理后存入数据库中。网站经营人员通过访问分析报表系统查看这些数据。 网站统计中的JS方式的数据收集原理及实现，详 情 参 见 http: / /document /1089.html。JavaScript标记以其快捷性和精确性已经得到大多数工具厂商的青睐，已经发展成为当前最为流行的数据收集方式。2.1.3 包嗅探器的方式下图是包嗅探器收集数据过程的示意图。上图可以看出网站访问者发出的请求到达网站服务器之前，会先经过包嗅探器，然后包嗅探器才会将请求发送到网站服务器。包嗅探器收集到的数据经过工具厂商的处理服务器后存入数据库。随后网站经营人员就可以通过分析报表系统看到这些数据。2.1.4 数据收集方式的优劣比较没有一种数据收集方式是完美无缺的，不同数据收集方式也决定了各自的特性，了解不同收集方式的优劣所在，会对工具的选择也有一定的指导作用。下表是三种数据收集方式的优劣比较详细：Web日志JavaScript标记包嗅探器优点比较容易获取数据源方便对历史数据再处理可以记录搜索引擎爬虫的访问记录记录文件下载状况数据收集灵活，可定制性强可以记录缓存、代理服务器访问对访问者行动追踪更为准确对跨域访问的监测比较方便取得实时数据比较方便缺点无法记录缓存、代理服务器访问无法捕获自定义的业务信息对访问者的定位过于模糊对跨域访问的监测比较麻烦用户端的JS设置会影响数据收集记录下载和重定向数据比较困难会增加网站的JS脚本负荷初期导入费用较高无法记录缓存、代理服务器访问对用户数据隐私有安全隐患 决定选择采用哪种数据收集方式之前，你需要先了解自己的需求。如果你不想自己网站的流量数据被任何第三方获取，那么Web日志无疑是你的最佳选择了。但想得到更贴近网站访问者行为的精确数据，还是需要采用JavaScript标记收集数据。这种数据收集方式不仅可以对缓存访问、代理访问正确记录，而且可以通过Cookie对独立访问者进行更为精确的定位。 当然也有一些网站为了获得多方面的数据而同时采取多种数据收集方式。例如采用JavaScript标记收集精确数据的同时，为了搜索引擎优化对Web日志中的搜索引擎爬虫记录也进行分析。也有已经采用包嗅探器收集数据，但为获取缓存访问而同时进行JavaScript标记。 金服平台业务PC Web页面非实时日志采集方案采用JS标记(埋码或者网络信标)方式。金服平台业务PC Web页面实时日志采集方案，详细参见3.2 移动App和Web的实时业务日志采集方案。3. 业务系统移动App日志和Web页面非实时日志与实时采集与收集方案3.1 移动App和Web页面非实时日志采集与收集采用Countly框架3.1.1 Countly简介Countly是一站式的数据分析平台，可同时跟踪移动和网络用户，分为社区版、云版本和企业版，版本提供的功能对比表如下：Countly 是一款创新实时移动和 Web 分析软件，专注于易用性、扩展性和功能丰富程度。Countly 包括服务器、移动 SDK（适用于移动分析）或 Web SDK（适用于 Web 分析），所有组件均可根据许可条款在公司内应用程序中自由使用。Countly 服务器部分由在端口 80 运行的服务组成，允许系统管理员连接到用户界面并获取关于被跟踪应用程序的见解。移动部分包括适用于各种智能手机、平板电脑和桌面操作系统（Windows 和 Mac OS X）的 SDK。Web SDK 与之类似，用于跟踪整个站点的网页活动。3.1.2 Countly自定义事件自定义事件。它是一种可用于将任何类型的数据发送到 Countly 服务器的强大功能。基本结构最简单的事件对象的结构如下： JavaScriptkey: button_click,count: 1以下属性是事件的唯一强制属性： key识别事件 count是发生此事件的次数如果事件与全部数值数据（如购买）紧密相关，我们可以使用sum进行跟踪： JavaScriptkey: in_app_purchase,count: 1,sum: 0.99分段在基础部分中，我们会看到只有count和sum属性的示例in_app_purchase事件。能够跟踪购买总数和购买总金额非常好，但有时我们可能需要更详细的信息： 购买次数最多的是哪种商品？ 根据应用程序内购买哪个国家是顶级销售员？ 哪个应用程序版本销量更高？通过分段可以对事件进行归类/标记以回答所有这些问题和更多问题。通过简单地将分段键值对添加到事件便可以跟踪详细指标； JavaScriptkey: in_app_purchase,count: 1,sum: 0.99,segmentation: app_version: 1.0,country: Turkey,item: sword3.1.3 使用Countly常见技术问题请介绍Countly 平台如何操作。在应用程序中安装 Countly SDK 后，该应用程序用户开始将事件数据发送至 Countly 服务器。Countly 从这些事件中收集用户操作、行为、所使用电信公司等相关信息。Countly 使用哪种语言编写？正在使用Node.js和MongoDB.。后端和前端完全由 javascript 编写。您可以查看API 代码，该代码从客户端 SDK 收集数据并将此数据写入数据库。事件和会话数据如何发送至 Countly？随着用户打开应用程序，Countly SDK 将开始按您定义的方式收集数据。对事件和会话进行收集，随后每 60 秒使用 HTTPS 请求发送至 Countly（或您的）服务器。如果在应用内记录超过 10 个不同事件，甚至无需等到下次发送，将立即发送。Countly 是否实时显示我的数据？所有报告和图表均实时显示。后台中不运行批处理以可视化或收集数据，因此无需等待下次处理运行。Countly 是否会降低移动应用程序反应速度？轻型 SDK 异步工作，不会阻碍代码内任何函数调用。iOS 性能分析表明 SDK 只占用总 CPU 使用量的 2%。与发送应用内视频的高 CPU 和数据占用服务相比，我们明显具有优势。使用 Android 性能分析程序进行的测试表明，在 5 分钟会话，发送 5 个事件和 8 条请求的典型使用场景中，对于单核 CPU Countly 占用不到 0.1% 的 CPU 时间。对于多核 CPU，此数值将低于 0.1%。SDK 无法发送请求时会发生什么情况？如果移动程序无法发送事件信息（主要是由于设备未连接到互联网、用户乘坐飞机或地铁等事实），此时此信息将存储在非易失性存储器中。连接建立后，将立即发送至服务器并将数据从队列中移除。Countly 服务器能够处理多少用户？在测试中，高配置服务器每秒可以处理 700 个事件，约为 20，000 个并行移动用户。请参见实施和配置场景了解可选安装方案。但请勿将此数字作为参考，该数字在很大程度上依赖于事件数量、网络负载、配置、磁盘速度、RAM 大小和许多其他条件。请注意这些数字适用于 Countly 社区版。3.1.4使用Countly的用户3.1.5 移动和Web页面非实时日志采用Countly实现日志采集与收集实现方案 非实时日志收集与采集实现架构 Web页面定制/埋点JS(信标)实现采集非实时web日志1. npm install countly-sdk-web2. 设置异步使用Web SDK异步使用Web SDK，不阻止加载内容，并在它没加载统计脚本情况使用，通过Countly.q调用或同步允许脚本加载。在页面的关闭前标签插入异步代码，举例如下：Countly.init(/provide your app key that you retrieved from Countly dashboard app_key: YOUR_APP_KEY,/provide your server IP or name. Use try.count.ly for EE trial server./if you use your own server, make sure you have https enabled if you use/https below. url: );/track sessions automaticallyCountly.track_sessions();/track pageviews automaticallyCountly.track_pageview();3. 页面自定义事件/send event on button clickfunction clickEvent(ob)Countly.q.push(add_event,key:asyncButtonClick, segmentation: id: ob.id); 自定义事件可跟踪您的网站上的任何行为。也可提通过分段（segments）查看段值（segment values）以分解用户行为,举例如下：Countly.q.push(add_event,key: click, count: 1, sum: 1.5, dur: 30,segmentation: key1: value1, key2: value2);4. 采用辅助方法轻松地跟踪网络上最常见的行为 自动化跟踪用户会话 Countly.q.push(track_sessions); 跟踪页面浏览数(page views) 使用location.path为页面名称跟踪当前页面 Countly.q.push(track_pageview); Ajax web应用程序更新的内容和单页 传递页面名称以记录新页面浏览记录 Countly.q.push(track_pageview,pagename); 其他常见行为不一一列举。 这些辅助跟踪网络常见行为的事件记录结构，详解参见CountlyWebSDK里Countly.js。 5.修改CountlyWebSDK里Countly.js里sendXmlHttpRequest(params, callback) apiPath的值apiPath对应CountlyServer Web插件处理页面非实时web日志的URL路径后面部分。 CountlyServer Web插件定制Ajax get/post处理Web页面非实时web日志CountlyServer Web插件位置在countly-server-masterpluginsweb，需要处理前端页面非实时web日志的文件是webfrontendapp.js1. 解析页面自定义事件2. 解析网络常见行为(请求事件)3. 归纳综合自定义事件和请求事件为统一页面采集非实时业务字段存入Web业务log文本文件统一页面采集业务字段表格字段含义必须备注client_ip客户端IP在服务器获取的客户端网关入口地址referrer_url当前页的来源页(上一页)的URLrequest_url当前界面的URLforward_url 即将跳转页面的URLie_typeIE类型client_type访问web的终端类型，mobile or pcuser_id网站会员IDsession_id会话IDpage_area_id页面区域ID，标记点击所在页面的栏位所属的区域，如首页的个性化栏位in_action_array页面内部action（和后台有交互）系列事件有关数据结构(JSON格式)否如Ajax调用或者单页面，详解见本表格后in_nonaction_array页面内部非action（不和后台有交互）系列事件有关数据结构(JSON格式)否详解见本表格后event_id用户行为(导致页面跳转)的事件标识ID，例如点击商品详情为blueshirt_detailaction_id页面跳转的后台action相对路径action_time用户行为的客户端时刻用于对应web端后台实时日志记录page_dateWeb 页面打开的日期 YYYY-Month-Dayresponse_time页面的响应时长break_time用户停留时长content_id表示业务内容的ID，如类目页的分类ID、搜词页的关键词、促销页的促销活动ID、详情页的商品ID、下单页的订单IDreach_timeWeb页面日志采集请求到达日志服务器时间exception_type页面异常类型exception_desc页面异常说明in_action_array数据结构里每个action字段表格字段含义必须备注keyevent_idaction_id后台action相对路径count同一action发生次数dur1第一次事件时长action_time1第一次事件用户行为的客户端时刻用于对应web端后台实时日志记录response_time1第一次事件用户行为的响应时长dur2第二次事件时长否事件时长数量取决于countaction_time2第二次事件用户行为的客户端时刻response_time2第二次事件用户行为的响应时长in_nonaction_array数据结构每个action字段表格暂不设计。 安卓APP定制/埋点实现采集非实时app日志1. 基于countly-sdk-android实现采集安卓用户行为非实时日志的流程2. 下载安装并添加countly-sdk-android到安卓App项目工程3. 设置countly-sdk-android首先，您需要确定要使用的设备 ID 生成策略。 只需让该策略生效即可。在此情况下，最简单的方法最适用。切勿在服务器 URL 结尾放置后缀“/”，否则将失效。Countly.sharedInstance().init(this, ht