Apm

Tideways PHP 性能监控工具1.简介php性能监控平台， 目前抉择的是tideways_xhprof扩大， xhgui UI展现界面, 应用mongoDb存储收集的日志数据具体版本，环境如下：Centos 7php7.4tideways_hprof 5.0 开源xghui 开源， 汉化版mongodb4， 存储日志2.装置a. 装置mongodb数据库yum install mongodb-server版本要大于3.6b. php mongodb 扩大1) pecl装置： pecl install mongodb 2) 安装包编译： mongodb下载地址 抉择适合版本，顺次执行以下命令编译装置wget -c https://pecl.php.net/get/mongodb-xxx.tgztar -zxvf mongodb-xxx.tgzcd mongodb-xxxphpize./configuremake && make install 3) yum 装置 以上办法三选一，轻易一个都能够。然而要留神php版本 4) 在php.ini中增加 extension=mongodb.so php.ini地位能够通过命令 php --ini 查看c. 装置tideways 扩大1) 执行以下命令，通过编译装置 git clone https://github.com/tideways/php-xhprof-extension.gitcd /path/php-xhprof-extensionphpize./configuremake && make install2) 在php.ini中增加 extension=tideways_xhprof.so 3) 重启php-fpm， 而后查看phpinfo(), 或php -m 看有没有胜利c. 装置xhgui UI1) 执行以下命令git clone https://github.com/laynefyc/xhgui-branch.git cd xhgui-branch php install.php // 初始化，装置依赖2) 批改配置文件 config/config.default.phpreturn array( ... 'extension' => 'tideways_xhprof', ... 'save.handler' => 'mongodb', 'db.host' => 'mongodb://127.0.0.1:27017', 'db.db' => 'xhprof', ...);d. 配置xhgui虚拟主机 nginxserver { listen 8081; server_name _; root /Users/yaozm/Documents/wwwroot/xhgui-branch/webroot; # access_log /usr/local/var/log/nginx/access.log; error_log /usr/local/var/log/nginx/error.log; location / { try_files $uri $uri/ /index.php?$query_string; index index.php index.html index.htm; }}e. mongodb加索引，进步查问速度$ mongo> use xhprof> db.results.ensureIndex( { 'meta.SERVER.REQUEST_TIME' : -1 } )> db.results.ensureIndex( { 'profile.main().wt' : -1 } )> db.results.ensureIndex( { 'profile.main().mu' : -1 } )> db.results.ensureIndex( { 'profile.main().cpu' : -1 } )> db.results.ensureIndex( { 'meta.url' : 1 } )f. 在须要监控的我的项目nginx配置文件中退出探针$ fastcgi_param PHP_VALUE "auto_prepend_file=/path/xhgui-branch/external/header.php";示例(这是被监控的我的项目的config)server { listen XXXx; server_name XXXXX; root /Users/yaozm/Documents/wwwroot/laravel/public; # access_log /usr/local/var/log/nginx/access.log; error_log /usr/local/var/log/nginx/error.log; location / { try_files $uri $uri/ /index.php?$query_string; index index.php index.html index.htm; } # **增加 PHP_VALUE，通知 PHP 程序在执行前要调用的服务** fastcgi_param PHP_VALUE "auto_prepend_file=/path/wwwroot/xhgui-branch/external/header.php";}G. 测试环境搭建胜利的示例猛戳这里

前言随着AI、大数据技术在IT运维畛域的落地，AIOps成为传统运维厂商、新兴APM/NPM厂商和云服务商追捧的焦点，越来越多的用户开始理解、尝试和利用AIOps。然而，因为不同厂商的AIOps倒退门路和本身产品技术实力的不同，对于AIOps的定义和宣传有很大的差别，而用户面对嘈杂的市场声音往往就像雾里看花，显得莫衷一是。 美国驰名IT钻研机构Enterprise Management Associates(EMA)副总裁Dennis Drogseth在《AIOps and IT Analytics at the Crossroads》网络研讨会上，同样被欧美用户屡次问及AIOps和传统监控工具之间界线的问题，特地是AIOps和APM产品的性能差别，如：它们到底有何不同？如果曾经有了APM，还须要AIOps吗？企业为什么要同时购买APM和AIOps产品？ 依据Gartner在2019年7月公布的IT性能剖析技术成熟度曲线显示，AIOps正在从科技诞生的促动期 (Technology Trigger)进入过高冀望的峰值（Peak of Inflated Expectations），而APM/NPM等技术曾经进入稳步俯冲的光明期 (Slope of Enlightenment)，为什么还会呈现AIOps和APM/NPM概念混同？这里既有两种产品互相穿插造成的误会的因素，也有市场炒作和竞争的起因。Dennis Drogseth将在本文中为咱们理清AIOps和APM的异同。 APM和AIOps的本质区别APM的实质是监控工具。顾名思义，Application Performance Monitoring（Gartner对APM的定义）次要关注应用程序的性能，包含一些应用程序/基础架构的互相依赖性（利用拓扑）。诚然，随着APM逐步向智能化倒退，越来越多的APM产品开始在某种程度上提供故障预测能力，让APM和AIOps的边界变得有些含糊，但在更宽泛的IT运维治理与剖析场景中，APM的重点仍是监控，同时也是AIOps平台的最重要数据起源。 AIOps是笼罩全副7层IT技术栈的平台解决方案。AIOps作为一种运维策略，能够与企业现有的ITOM工具、基础设施监控（ITIM）、网络性能监控（NPM）、利用性能监控（APM）和数字性能监控（DPM）工具进行整合，同时AIOps的数据源还包含了IoT、配置数据、日志文件，甚至电子表格等文档信息。 此外，从大数据分析到故障预测，AIOps解决方案可利用超过13种不同的剖析摸索办法，用于标准和if / then格调的机器学习。EMA钻研表明，目前市场上风行的AIOps平台，有超过50%能接入23种以上不同监测零碎和ITOM工具。最重要的是，AIOps解决方案可能反对变更治理、容量预测、平安及SecOps、老本优化、云迁徙以及DevOps和终端用户体验剖析，这些是远远超出APM能力范畴的。 因而，咱们可能得出一个根本论断：AIOps是一种涵盖了APM、网络管理、系统管理、数据库治理和多云治理的对立管控技术，可能关联整合和被动剖析来自不同数据源的数据。AIOps比APM在范畴、用例和价值上更宽泛，实质上与EMA定义的高级自动化剖析（AIA）的指标是统一的。 APM和AIOps的相似之处然而，如果咱们把AIOps看做能够替换APM/NPM/DPM的监控工具，同样有失偏颇。事实上，APM的利用为AIOps能力的欠缺提供了微小帮忙。 Dennis Drogseth总结出以下四个方面： APM通过基础设施依赖性进行应用程序治理的价值越来越高，因而APM也就成为自上而下评估服务治理和服务交付有效性的重要依据。APM的外围能力之一是发现利用/基础架构拓扑，而利用发现和依赖关系映射（ADTD）提供了更多动静性能，这些性能同样是AIOps解决方案的根底，能够间接集成或借助APM的发现性能进行实现。APM越来越关注终端用户体验治理（DEM），这也是谋求与业务价值保持一致的AIOps解决方案一直加强的能力之一。业务绩效指标是抉择APM解决方案的重要依据，这同样是用户抉择AIOps解决方案的要害参数。当然AIOps平台领有更全面的根底指标数据，能够更加全面的评估业务价值，剖析容量、老本、平安/合规性问题和其余指标。AIOps如何实现IT对立管控AIOps作为一种笼罩全副技术栈的对立管控技术，可能帮忙企业外部所有与IT相干部门进行改革，而不仅局限于运维部门。EMA间断两年的钻研显示，AIOps可能在所有造成数据孤岛的IT工具整合中施展微小价值。此外，AIOps与IT服务治理（ITSM）的集成也至关重要，因为这样能力帮忙开发、平安团队和经营部门更无效地协同工作。 然而，企业外部应该正确认知AIOps并就指标和价值达成共识，能力实现IT的对立管控。而要施展对立平台的最大价值，须要把AIOps的领导力、创造力和灵活性利用在IT思维和工作形式中。与CMDB/CMS打算并行，AIOps打算须要各部门被动共享数据，摸索新的流程效率程度，同时进步自动化程度。此外，AIOps须要更具凝聚力和更积极主动的心态，去摸索遇到的新问题。当然，最佳实际依然实用于AIOps，与数字化转型打算保持一致，这些打算为IT转型提供了额定的砝码和价值。 尽管咱们经常在市场上听到对于AIOps的谬误概念，或从字面上把AIOps误会为Ops专用的运维工具平台，但心愿大家通过本文分明意识到：AIOps是激发所有IT零碎价值的根底。因为AIOps在产品设计和价值输入是十分多样化的，所以它不仅是一个市场概念，更是一个翻新的IT环境。因而，咱们须要依据现阶段的IT成熟度和业务需要，依照优先级抉择适宜的场景、用例，逐步推进AIOps的落地。 开源福利云智慧已开源数据可视化编排平台 FlyFish 。通过配置数据模型为用户提供上百种可视化图形组件，零编码即可实现合乎本人业务需要的炫酷可视化大屏。 同时，飞鱼也提供了灵便的拓展能力，反对组件开发、自定义函数与全局事件等配置， 面向简单需要场景可能保障高效开发与交付。 点击下方地址链接，欢送大家给 FlyFish 点赞送 Star。参加组件开发，更有万元现金等你来拿。 GitHub 地址： https://github.com/CloudWise-... Gitee 地址：https://gitee.com/CloudWise/f... 超级体验官流动： http://bbs.aiops.cloudwise.co... 万元现金流动： http://bbs.aiops.cloudwise.co... 微信扫描辨认下方二维码，备注【飞鱼】退出AIOps社区飞鱼开发者交换群，与 FlyFish 我的项目 PMC 面对面交换～ 作者：Dennis Drogseth 出处：https://www.apmdigest.com/apm...

4月8日，神州数码携手多领域专家及生态搭档，围绕数字经济的产业翻新、技术创新开展深入探讨。同期，云科透明湖生态联盟也正式成立，博睿数据首批退出。 信息技术利用翻新减速倒退，迎来新机遇期 数字经济时代，信息技术利用翻新作为数字“新基建”的重要组成部分，已成为推动我国经济数字化转型的要害力量。在政策反对和市场需求逐渐开释的双重驱动下，信创产业减速倒退，迎来新机遇期。 以后，随着技术栈的继续迭代，信创产业逐渐走入深水区，在国内根底软硬件等畛域，国内根底软硬件厂商在一直推动产品性能优化和晋升的同时，也在一直拓展新的产品状态。 此外，随同着云计算、物联网、大数据、人工智能、5G等新兴技术的疾速倒退，数字经济正在减速到来。据权威调查报告显示，目前69%的企业正在进行数字化转型，并且着重开掘利用数据的价值。与此同时，数字化利用的爆发性增长、用户对于利用体验的更高要求、新兴技术对市场的推动正在粗浅扭转各行各业与数字经济的互动形式。 众行方能致远，博睿数据赋能联盟服务价值体现 众行方能致远，云科透明湖生态联盟首批共有七家生态搭档独特参加，波及产业上下游各方企业。 云科透明湖总经理吴若松指出，“联盟将以数字化中国为使命，致力于推动信息技术利用翻新、建设促成核心技术孵化与倒退的产业联盟、构建全新生态体系，建设产品、技术、解决方案资源池，与场景端、需要端的紧密结合将与产品技术的利用翻新造成良性的可继续倒退，独特推动自主翻新产品和技术在各行各业的扎根与赋能，推动自主翻新、技术提高和社会倒退。” 正文：云科透明湖生态联盟正式成立典礼 谈及“云科透明湖”为何与博睿数据强强联手时，吴若松示意，“任何一家企业都不可能一家独大，肯定须要个人的力量。云科透明湖的利用交付要做的不仅仅是数据分析，更多的是危险监控以及更为全面的监控。从代码到用户的全链路监控能力是博睿数据的劣势所在。” 博睿数据首批退出云科透明湖联盟，博睿数据COO吴静涛示意，“基于单方对于利用交付将来的统一认识，无边界利用架构的将来, 须要买通云管边端, 实现代码到用户的全数据链过程的实时数据采集、缝合、可视化以及业务和运维方向的风控等, 从传统的利用交付网关负载平衡的能力变成一个可观测性的利用交付的能力量化，而博睿数据可提供落地计划, 减速客户在联盟服务上的价值体现”。 吴静涛强调，“2021年，博睿数据翻新的提出了数据链DNA的概念，基于博睿数据已有的产品跟技术再降级，买通从代码到用户全门路，通过数据链DNA，来真正实现利用可用到服务可达的过渡，建设以用户为核心的服务可达能力的监控和评估体系，晋升自动化运维能力，全面提高用户体验，放慢数字化转型。” 由此可见，博睿数据退出云科透明湖生态联盟，事实上是将单方劣势进一步放大的过程，一方面，“云科透明湖”可借助博睿数据实现优化高可用和平安的零碎，通过数字化的语言表述IT经营；另一方面，博睿数据的产品和解决方案能帮忙“云科透明湖”做辅助决策，以实现最优解决方案。

一款监控子线程操纵 UI 的能力，也能够增加自定义的 API 进行监控（实现在子线程监控某些 API 的时候捕捉具体堆栈信息，帮忙定位问题） 背景介绍可能有些人始终没有遇到过因为在子线程操作 UI，导致在开发阶段 Xcode console 输入了一堆日志，大体如下 其实咱们能够给 Xcode 打个 Runtime Issue Breakpoint ，type 抉择 Main Thread Checker， 在产生子线程操作 UI 的时候就会被零碎检测到并触发断点，同时能够看到堆栈状况 成果如下 问题及解决方案上述的性能是在 Xcode 自带的，连贯 Xcode 做调试才具备的性能，线上包无奈检测到。 通过摸索 Xcode 实现该性能是依赖于设施上的 libMainThreadChecker.dylib 库，咱们能够通过 dlopen 办法强制加载该库让非 Xcode 环境下也领有监测性能。 另外在监控到子线程调用 UI 调用时，在 Xcode 环境下，会将调用栈输入到控制台，通过测试，libMainThreadChecker.dylib 应用的是进行输入的，因为 NSLog 是将信息输入到 STDERR中，咱们能够通过 NSPipe 与 dup2 将 STDERR 输入拦挡，通过对信息的文案的判断，进而获取监测到的 UI 调用，最初能够通过堆栈打印进去，就能够帮忙定位到具体问题。 libMainThreadChecker.dylib 库具备局限性，仅仅对系统提供的一些特定类的特定 API 在子线程调用会被监控到（例如 UIKit 框架中 UIView 类）。然而某些类有些 API 咱们也不心愿在子线程被调用，这时候 libMainThreadChecker.dylib是无奈满足的。 ...

最近有小伙伴私信我，如何在本人的业务零碎嵌入WGCLOUD 我联合咱们我的项目的教训给大家说一下：1、在本人零碎加一个菜单或按钮，命名就依据本人自定义了，当点击时候，跳转到WGCLOUD页面，这个方法是最简略的了。惟一不足之处是须要登录，不过咱们能够抉择浏览器记住明码就行了。 2、深度嵌入集成，比方咱们须要开发一个模块，须要调用到WGCLOUD的数据。这个能够的，WGCLOUD有现成的数据凋谢接口，齐全能够满足场景须要，如下链接https://www.wgstart.com/help/... 3、WGCLOUD目前版本还没有免登录和单点登录机制，若须要此种集成，也能够分割他们，做一个定制批改

导言 博睿数据（股票代码688229）十余年专一APM畛域，已为超过2000余家大型企业提供业余数据服务。依靠先进的测评技术及丰盛的行业教训，博睿数据倾力打造了一个公开通明的性能测评栏目——【Bonree指数】。该栏目致力于出现各行业的整体性能详情，为宽广运营商及网民决策提供重要参考根据。目前，测评内容蕴含云主机性能、云短信达到率及整体性能、券商App行情刷新及交易体验等。 随着挪动金融服务的流行，手机App炒股成为宽广股民广泛的抉择。股市行情变幻莫测，行情推送速度会影响到投资者的交易决策，委托下单与撤单等要害操作环节的响应性能又会极大影响投资者的收益。由此，行情数据的推送实时性和交易的快捷性成为考验各大券商App性能的两大外围场景。 博睿数据每月继续公布《券商App行情刷新及交易体验评测报告》，此报告不以排名为目标，重在以主观公正的技术数据量化券商App性能指标，帮忙券商做到知己知彼，优化用户体验，晋升整体竞争力。评测阐明：理论来看，App行情刷新速度及交易体验会受到所在地各种因素影响，博睿数据选取为北京、上海、深圳三地作为评测地点，本报告仅出现三地综合评测后果，欲了解北京、上海及深圳各地分榜单，请与咱们联系。 分割邮箱：market@bonree.com点击文末“浏览原文”，查看更多私有云、云短信、银行等性能测试报告及排名。 评测指标：A股上市券商37家测试周期：2021.12.01-2021.12.31测试场景：行情刷新速度及交易性能评测工具：博睿数据独家产品Bonree Stock，测试北京、上海、深圳雷同环境中不同股票交易App大盘和个股数据，量化券商行情和交易数据，实在反馈用户体验。 2021年12月 上市券商App行情刷新速度评测综合榜 在2021年12月行情刷新速度综合评测中，国君泰安再次霸榜，值得一提的是，除10月外，国君泰安曾经11次摘得第一。东兴证券及兴业证券位列第二、三名。 备注：App测试名称、版本等详情信息，可分割咱们获取。分割邮箱：market@bonree.com。 总结 1、国君泰安再登榜首 在2021年12月行情刷新速度综合评测榜单中，37家上市券商整体体现稳固。其中，国君泰安再登榜首，东兴证券及兴业证券位列第二、第三名。 2、37家上市券商整体体现稳固，三家排名小幅晋升 在2021年12月行情刷新速度综合评测榜单中，37家上市券商整体体现稳固，其中华安证券优化显著，从上月的第15名胜利跻身前十，位列第10名，另外国金证券及国元证券排名均有不同幅度的晋升。 2021年12月上市券商App交易性能评测综合榜 在2021年12月上市券商App交易性能综合评测中，兴业证券再登榜首，国元证券及长江证券位列第二、第三名。此外，本月A级券商共计19家，B级券商9家，D级券商2家。 备注：App测试名称、版本等详情信息，可分割咱们获取。分割邮箱：market@bonree.com。 总结 1、A级券商共计19家，兴业证券再夺榜首 本月A级券商共计19家，其中，兴业证券蝉联榜首，国元证券和长江证券位列第二、三名。 19家A级券商别离为：兴业证券、国元证券、长江证券、华安证券、中泰证券、国泰君安证券、国金证券、国信证券、财通证券、方正证券、光大证券、中信建设、东吴证券、华西证券、东兴证券、浙商证券、安信证券、西方证券、中国河汉。 2、整体体现安稳，4家券商评级回升： B级到A级：西方证券 B级到A级：中国河汉 C级到B级：东北证券 E级到D级：华泰证券 3、1家券商评级降落： A级到B级：山西证券 指标阐明：行情刷新速度行情刷新速度依据SQE指数来进行排序，SQE指数也即行情体验指数（Stock Quotations Experience Index），是掂量各券商的行情数据推送实时性的指标，行情体验指数大的券商（该指数在0-1之间），数据时效性高。SQE指数的计算形式为：按肯定周期（默认为1s）内各家券商最新行情，以【成交额】指标进行从大到小排序，如果同一次数据比照成交额雷同，则依据【规范工夫】进行二次比照，失去相应的权值T，排最前者本周期权值为1，其余顺次递加0.01，即SQE=T*T，即取T的平方作为本周期的SQE。三个因素影响券商App行情刷新速度：1.券商行情机与行情源同步是否足够及时，外部加工解决行情的效率是否高效；2.各券商应用的接入线路品质的差别，如各地区运营商下的终端用户到券商行情机之间网络链路品质状况的好坏，高时延和丢包等状况都间接影响行情数据到客户手机的提早；3.App端行情拉取机制的差别。交易性能交易性能测试遵循“四同”准则，即同款手机设施、同接入网络、同工夫基准、同测试标的（同指数或同股票）。在每日固定的三个工夫点（9:30、10:00及13:00），在北京、上海、深圳三地的实验室中的大量实在手机设施上，同时发动委托、撤单等交易要害操作，并通过对本地网络报文数据及App内存数据的联合剖析，精确获取撤单上报耗时、撤单成功率等指标，通过事后设计的抛物线模型打分公式对三个工夫点交易性能进行综合评分，依照分值划分A\B\C\D\E五个交易性能等级，A级最佳。单工夫点得分满分200分，全天三次总分数超过590分，即为A级。交易性能的优劣次要从两方面进行考量，即交易操作的响应时延和交易操作的成功率。因而，咱们目前参考的权重指标即撤单上报耗时、交易操作是否胜利两项。撤单上报耗时越小，撤单成功率越高，则用户体验越佳，性能得分也越高。 四大时刻影响交易性能：T1：用户点击撤单弹框确认按钮的时刻；T2：App网络层实在收回撤单上报申请的时刻；T3：App网络层接管到响应报文首包的时刻；T4：App本地接管完响应报文并将其结构为程序中对应对象的时刻。每两个相邻时刻相减失去的阶段耗时代表不同影响因素，这四个关键时刻的明细数据能够为券商优化交易操作相应性能指明方向，是各大券商IT技术团队进行用户体验优化的重要依据之一。 版权申明： 1、本报告版权归北京博睿宏远数据科技股份有限公司（股票简称：博睿数据，股票代码：688229）所有。报告中所蕴含的文字、图片及数据内容均受无关著作权法律爱护，转载摘录必须注明出处。未经许可，企业或集体不得用于商业用途。任何未经受权应用本报告的行为都将违反《中华人民共和国著作权法》和其余法律法规以及无关国际公约的规定。 2、本报告因为数据样本选取及评测形式限度，其数据后果会受到样本的影响。因为钻研办法及样本限度，钻研材料收集范畴限度，局部数据不可能齐全反馈实在市场状况。本报告内容及观点仅供参考，不形成任何投资倡议。本报告对所提供的内容力求精确、残缺和及时，但不对其准确性、完整性和及时性承当任何法律责任。 北京博睿宏远数据科技股份有限公司 Bonree数据钻研核心 2022.01.13

日前，我公司北京博睿宏远数据科技股份有限公司（公司简称/股票简称：博睿数据，股票代码：688229）获悉，有不法分子冒用“博睿数据”的名义，伪造虚伪网站、以设立网上赌场的模式进行欺骗，并以博睿数据或以博睿数据法人李凯先生的名义公布虚伪信息，希图以此获得宽广网友的信赖。 为此，博睿数据在此郑重声明： 一、博睿数据素来没有从事或受权其余机构从事任何非法交易。 二、博睿数据素来没有以任何名义要求集体向公司领取任何钱款。 截至本申明收回之日，博睿数据已就此向属地公安部门报案，对于任何冒用、假借博睿数据名义进行的守法和犯罪活动，对于任何伪造我公司文件的单位和集体，博睿数据将保留追究其相干法律责任的权力。 同时，博睿数据请宽广公众审慎辨认各类网络社交媒体公布的虚伪信息、审慎辨认虚伪网站，也请宽广公众依法保护本身的合法权益。 北京博睿宏远数据科技股份有限公司 2021年12月23日

导言 博睿数据（股票代码688229）十余年专一APM畛域，已为超过2000余家大型企业提供业余数据服务。依靠先进的测评技术及丰盛的行业教训，博睿数据倾力打造了一个公开通明的性能测评栏目——【Bonree指数】。该栏目致力于出现各行业的整体性能详情，为宽广运营商及网民决策提供重要参考根据。目前，测评内容蕴含云主机性能、云短信达到率及整体性能、券商App行情刷新及交易体验等。 随着挪动金融服务的流行，手机App炒股成为宽广股民广泛的抉择。股市行情变幻莫测，行情推送速度会影响到投资者的交易决策，委托下单与撤单等要害操作环节的响应性能又会极大影响投资者的收益。由此，行情数据的推送实时性和交易的快捷性成为考验各大券商App性能的两大外围场景。 博睿数据每月继续公布《券商App行情刷新及交易体验评测报告》，此报告不以排名为目标，重在以主观公正的技术数据量化券商App性能指标，帮忙券商做到知己知彼，优化用户体验，晋升整体竞争力。 评测阐明：理论来看，App行情刷新速度及交易体验会受到所在地各种因素影响，博睿数据选取为北京、上海、深圳三地作为评测地点，本报告仅出现三地综合评测后果，欲了解北京、上海及深圳各地分榜单，请与咱们联系。 分割邮箱：market@bonree.com 评测指标：A股上市券商37家测试周期：2021.11.01-2021.11.30测试场景：行情刷新速度及交易性能评测工具：博睿数据独家产品Bonree Stock，测试北京、上海、深圳雷同环境中不同股票交易App大盘和个股数据，量化券商行情和交易数据，实在反馈用户体验。 2021年11月 上市券商App行情刷新速度评测综合榜 在2021年11月行情刷新速度综合评测榜单中，37家上市券商整体体现稳固。其中，国君泰安重返第一，此前，国君泰安间断10个月位列第一，东兴证券及兴业证券位列第二、三名。 备注：App测试名称、版本等详情信息，可分割咱们获取。分割邮箱：market@bonree.com。 总结 1、国君泰安荣登榜首 在2021年11月行情刷新速度综合评测榜单中，37家上市券商整体体现稳固。其中，国君泰安荣登榜首，东兴证券及兴业证券位列第二、第三名。 2、一家券商排名大幅回升 在2021年11月行情刷新速度综合评测榜单中，一家券商排名大幅回升：国元证券从上月的第37名回升到本月第24名。 2021年11月上市券商App交易性能评测综合榜 在2021年11月上市券商App交易性能综合评测中，兴业证券再登榜首，国元证券及长江证券位列第二、第三名。此外，本月A级券商共计18家，较上月减少2家，B级券商9家，C级券商1家，D级券商1家，E级券商1家。 备注：App测试名称、版本等详情信息，可分割咱们获取。分割邮箱：market@bonree.com。 总结 1、A级券商共计18家，兴业证券再夺榜首 本月A级券商共计18家，较上月减少2家。其中，兴业证券蝉联榜首，国元证券和长江证券位列第二、三名。 18家A级券商别离为：兴业证券、国元证券、长江证券、华安证券、中泰证券、国泰君安证券、国金证券、国信证券、方正证券、中信建设、华西证券、财通证券、光大证券、东兴证券、安信证券、浙商证券、山西证券、东吴证券。 2、整体体现安稳，2家券商评级回升： B级到A级：浙商证券 B级到A级：东吴证券 3、2家券商评级降落： B级到C级：东北证券 C级到D级：太平洋证券 指标阐明：行情刷新速度行情刷新速度依据SQE指数来进行排序，SQE指数也即行情体验指数（Stock Quotations Experience Index），是掂量各券商的行情数据推送实时性的指标，行情体验指数大的券商（该指数在0-1之间），数据时效性高。 SQE指数的计算形式为：按肯定周期（默认为1s）内各家券商最新行情，以【成交额】指标进行从大到小排序，如果同一次数据比照成交额雷同，则依据【规范工夫】进行二次比照，失去相应的权值T，排最前者本周期权值为1，其余顺次递加0.01，即SQE=T*T，即取T的平方作为本周期的SQE。 三个因素影响券商App行情刷新速度：1.券商行情机与行情源同步是否足够及时，外部加工解决行情的效率是否高效；2.各券商应用的接入线路品质的差别，如各地区运营商下的终端用户到券商行情机之间网络链路品质状况的好坏，高时延和丢包等状况都间接影响行情数据到客户手机的提早；3.App端行情拉取机制的差别。 交易性能交易性能测试遵循“四同”准则，即同款手机设施、同接入网络、同工夫基准、同测试标的（同指数或同股票）。在每日固定的三个工夫点（9:30、10:00及13:00），在北京、上海、深圳三地的实验室中的大量实在手机设施上，同时发动委托、撤单等交易要害操作，并通过对本地网络报文数据及App内存数据的联合剖析，精确获取撤单上报耗时、撤单成功率等指标，通过事后设计的抛物线模型打分公式对三个工夫点交易性能进行综合评分，依照分值划分A\B\C\D\E五个交易性能等级，A级最佳。单工夫点得分满分200分，全天三次总分数超过590分，即为A级。 交易性能的优劣次要从两方面进行考量，即交易操作的响应时延和交易操作的成功率。因而，咱们目前参考的权重指标即撤单上报耗时、交易操作是否胜利两项。撤单上报耗时越小，撤单成功率越高，则用户体验越佳，性能得分也越高。 四大时刻影响交易性能：T1：用户点击撤单弹框确认按钮的时刻；T2：App网络层实在收回撤单上报申请的时刻；T3：App网络层接管到响应报文首包的时刻；T4：App本地接管完响应报文并将其结构为程序中对应对象的时刻。每两个相邻时刻相减失去的阶段耗时代表不同影响因素，这四个关键时刻的明细数据能够为券商优化交易操作相应性能指明方向，是各大券商IT技术团队进行用户体验优化的重要依据之一。 版权申明： 1、本报告版权归北京博睿宏远数据科技股份有限公司（股票简称：博睿数据，股票代码：688229）所有。报告中所蕴含的文字、图片及数据内容均受无关著作权法律爱护，转载摘录必须注明出处。未经许可，企业或集体不得用于商业用途。任何未经受权应用本报告的行为都将违反《中华人民共和国著作权法》和其余法律法规以及无关国际公约的规定。 2、本报告因为数据样本选取及评测形式限度，其数据后果会受到样本的影响。因为钻研办法及样本限度，钻研材料收集范畴限度，局部数据不可能齐全反馈实在市场状况。本报告内容及观点仅供参考，不形成任何投资倡议。本报告对所提供的内容力求精确、残缺和及时，但不对其准确性、完整性和及时性承当任何法律责任。 北京博睿宏远数据科技股份有限公司 Bonree数据钻研核心 2021.12.16

Elastic APM , APM服务配置平安拜访, TSL/SSL下的accessToken模式 如何配置 accessToken 拜访 ，官网文档地址 在 apm-server 的配置文件apm-server.yaml 外面的 apm-server.auth.secret_token 自定义一个字符串，比方：`apm-server.auth.secret_token ：123456xxx` 而后在你的客户端Agent里配置：Node.js示例：源码Github地址 var apm = require('elastic-apm-node').start({ // Override service name from package.json // Allowed characters: a-z, A-Z, 0-9, -, _, and space serviceName: 'zipcode service', // Use if APM Server requires a token secretToken: '123456xxx', //注意这里 // Set custom APM Server URL (default: http://localhost:8200) serverUrl: 'https://localhost:8200', })而后重启apm-server，重启客户端，登录kibana,在APM控制台里就能够看到实例了，如果agent未配置secretToken拜访，则会报错。 上述过程是未配置apm-server的SSL/TSL拜访，这会带来一个平安问题，凭证通过http申请很容易被窃取，所以须要配置成https服务。这是官网举荐的做法。 官网SSL/TSL配置文档地址 这是英文的并且说的并不具体。举荐一个更具体的教程，地址 这个教程外面大部分的操作都是正确的，不过也有一些是谬误，比方上面的代码 ： var apm = require('elastic-apm-node').start({ // Override service name from package.json // Allowed characters: a-z, A-Z, 0-9, -, _, and space serviceName: 'zipcode service', // Use if APM Server requires a token secretToken: '1234561', //配置好 ca 当前 , 曾经是https服务器了 // Set custom APM Server URL (default: http://localhost:8200) serverUrl: 'http://localhost:8200' //这里是谬误的 serverUrl: 'https://localhost:8200' //这样才是正确的 verifyServerCert: true, serverCaCertFile: "ca.crt" })如果不改过，间接依照教程外面的代码，apm-server 会报 APM Server transport error (400): Unexpected APM Server response\nClient sent an HTTP request to an HTTPS server.\n"，意思是说客户端向HTTPS服务器发送了HTTP申请。 ...

Node.js利用接入Skywalking实现APM监控 1：笔者应用的windows，请先自行装置启动Skywalking，下载地址：,下载实现，解压启动Skywalking后，拜访http://localhost:8080/（默认配置），到此装置启动 Skywalking 胜利。 2：Node.js利用接入，Skywalking 官网提供新的库来接入，原来的模块是 SkyAPM-nodejs ,官网要求 SkyWalking backend (OAP) 8.0+ and NodeJS >= 10. 反对已下框架和模块，更多信息查看 README.md LibraryPlugin Namebuilt-in http and https modulehttp / httpsExpressexpressAxiosaxiosMySQLmysqlMySQLmysql2PostgreSQLpgpg-cursorpg-cursorMongoDBmongodbMongoosemongooseRabbitMQamqplibRedisioredis3:接入代码示例：残缺代码地址： require('make-promises-safe')const {default: agent} = require('skywalking-backend-js');agent.start({ //援用 serviceName: 'my-service-name', serviceInstance: 'my-service-instance-name', // collectorAddress: 'http://localhost:8080',})var express = require('express')var app = express();var port = process.env.PORT || 3001;var routes = require('./api/routes');routes(app);app.listen(port, function() { console.log('Server started on port: ' + port);});4：示例代码中定义了两个路由： http://localhost:3001/abouthttp://localhost:3001/distanc...运行启动，浏览器拜访你的服务路由，可多拜访几遍会多一些数据 ，而后刷新 http://localhost:8080/ ，数据可能会有提早，稍等一些[PS:如果等了很久还是没有数据，查看下你查看的工夫区间是否选对] 失常如下： ...

作者 ｜ 刘浩杨起源｜尔达 Erda 公众号 APM 的全称是 Application Performance Management（利用性能治理），早在 90 年代中期就有厂商提出性能治理的概念，到当初 APM 畛域曾经倒退了近 25 年。 通常而言，APM 的技术曾经倒退了 3 个阶段，在这里咱们能够通过前蓝海讯通（OneAPM）创始人何晓阳在 2014 年分享的《APM 利用性能治理的过来二十年》来回顾一下 APM 的倒退历史。 1995 年到 2000 年，正是第一代互联网浪潮衰亡的年代。过后，雅虎作为互联网公司的代表，引领一代潮流，美国人忙着铺光纤架网线，一个一个的站点被建设了起来。如果说网站的响应速度决定了用户体验的话，那么过后的网速就决定了网站的响应速度，因而，APM 1.0 时代的软件性能就是这么简略：治理网络系统的性能。 工夫倒退到 2000 年，看过《浪潮之巅》这本书的读者应该会对那个时代有一些印象，过后的 SUN 正处于巅峰期间，市值靠近 2000 亿美元，这些公司过后正在疯狂的建设数据中心，购买各种各样的硬件和软件。在这里，咱们用一个专业名词来称说他们，叫做根底组件（Infrastructure）。那么，过后的 APM 零碎曾经到了第二代，作用是监控和治理各种根底组件的性能。 2005 年当前，随着 Facebook，Twitter 这些利用提供商的衰亡，越来越多的 APP 被用来服务寰球客户；对于用户来说，他们拜访的应用服务可能分布式 的部署在寰球的多个数据中心上，尤其是 2010 年当前，新的挪动拜访形式的衰亡，让每一个人的生存形式更加严密的依赖于各种 Application。在这个时候，利用自身的性能越来越成为制约用户体验晋升的瓶颈。这就是第三代 APM 软件的用武之地：第一是治理实在用户的体验，第二是进行端到端的业务交易性能剖析。 能够看到，在过来很长一段时间，APM 的重心始终在关注用户体验性能和应用程序性能，随着近年来云计算的衰亡，和云原生所提倡的新范式，给传统的研发和运维模式带来了新的挑战：微服务、DevOps 等理念让研发变得更高效，但带来的却是海量微服务的问题排查、故障定位的难度变得更大；容器化、Kubernetes 等容器编排技术的逐步成熟让规模化软件交付变得容易，但带来的挑战是如何更精准地评估容量、调度资源，确保老本与稳定性的最好均衡。 监控到可察看性Apple 的工程师 Cindy Sridharan 的博文“监控与察看”（Monitoring and Oberservability）首次将 Oberservability 一词带入开发者的视线。然而，在谷歌，其驰名的 SRE 体系在此之前就曾经奠定了可察看性的实践根底，也就是说在微服务、可观测性等概念或者呈现以前，前辈们将这套实践称为监控，其中 Google SRE 特别强调白盒监控的重要性，而将过后技术圈罕用的黑盒监控放在了绝对主要的地位。而白盒监控正是应和了可察看性中“被动”的概念。 ...

作者：友盟+U-APM 项目组 挪动利用的稳定性、性能与体验非常重要，间接影响着用户对产品自身的体验。依据友盟+《2021年Q1挪动利用性能体验报告》显示，目前挪动利用整体解体率为 0.29%，其中 Android 端解体率为0.32%， iOS 端解体率为0.10%。当某款利用iOS的解体率超过0.8%、Android解体率超过0.4%时，沉闷用户将出现显著的降落态势。 页面加载速度也会对客户满意度带来影响。页面响应时长每减少一秒，用户满意度就将升高16%，而如果页面响应时长超过3秒，局部用户甚至会间接退出。 基于上述数据，对目前市面上的App而言，其解体率需低于0.10%，方能达到优良规范。 不同的行业基于产品状态、技术架构不同，其利用解体率也存在差别。以游戏行业为例，其行业性质非凡，加之游戏产品自身也较为简单，所以解体率远远高于其余行业。而新闻、影音、浏览等利用则绝对解体率较低。此外，不同日活量级的App，利用解体率也参差不齐。日均沉闷用户数量超500万的罕用App，解体率大多低于0.1%；而日均沉闷用户数量较低的C端App，基于各方面的起因，稳定性体现则绝对较差，某些App解体率甚至高达3%、4%。 但不管所处行业是否雷同，产品用户体量是否统一，保障产品稳定性都应以业务成果、业务数据为落脚点。想要有稳固的性能体验，就要将其退出到产品的研发阶段、测试阶段、灰度阶段以及全量阶段，并从中找到业务与利用性能稳定性的平衡点。 知之非艰，行之惟艰。选取正当的平衡点并非易事，在此过程中，我的项目团队既要保业务，又要保工夫，对团队来说，这是极大的挑战。 挪动利用的共性问题 要解决问题，首先要晓得问题所在。以后挪动利用面临着许多共性问题，例如Android市场的碎片化，以及解体问题的定位艰难，相似的共性问题尽管具体，却难以轻易解决。 以友盟+ U-APM已经服务过的客户为例，其App被用户反馈页面加载迟缓，但这并不属于解体，起因也难以定位。除此之外，由内存透露等起因造成的解体问题，测试阶段并不能全面笼罩和发现，这对上线后的实时采集和问题复现有着极高要求，其中波及多个技术难点，亟需高效便捷的应答解决。 首先是采集方面。一般来说，上线后的利用须要具备多种根底外围采集能力，以采集Android零碎中Java层的解体与Native层解体，以及iOS零碎中的Objective-C层或Swift层解体。除此之外，还需具备捕捉ANR、自定义异样、卡顿等的能力。 要想全面捕捉与采集品种繁多的问题并不容易，相似设施重启环境下的异样类型解体与设施兼容性所产生的解体问题，就难以被惯例形式所采集。同时，对于用户应用Android APP 过程中呈现的提醒利用无响应的ANR问题，传统读取零碎trace日志的形式，并不能将其全面捕捉。 其次是聚类方面。要将不同类别谬误、不同版本、新旧问题聚合到一起，两头还存在着重重困难。 另外，在解体等问题修复中存在这样的问题：利用解体往往会重复性呈现。老版本解决了的问题，却又在新版本呈现，在重复修复反复问题后，发现过往解体异样起因与最终解法可积淀继承比例，竟高达70%、80%。 上述情况的产生，次要源于团队外部的人员流动所导致的信息替换效率过低。某些研发人员面对问题时，很可能会认为该问题已被本人或别人解决，殊不知，问题仍然存在。 在采集与聚类之外，还有测试方面的问题。 目前，大部分研发测试团队存在有产品疾速适配特定设施的需要的同时，还会常常收到来自客户即时的App解体反馈，两者往往都须要调用真机参加测试。在挪动利用端，真机测试是许多测试人员应用最多的场景。但传统真机测试流程绝对繁琐，效率因而较低。 针对上述多种问题，友盟+整合了产研实际过程中利用性能问题的采集、监控、发现、流转、定位，以及测试环节，将其积淀输入为“U-APM利用性能监控平台”，以解决产研团队在整个开发周期与线上经营阶段所面临的诸多痛点。 U-APM：保障挪动利用稳定性的强力工具 U-APM 作为收费的一站式利用性能监控平台，集App稳定性监控、性能监控和云真机测试平台为一体，很大水平上能解决挪动利用的共性问题。 以采集为例，U-APM可能捕捉包含产品信息、设施层与环境层的运行状态等信息，从而疾速地剖析出导致App解体的次要起因。针对ANR，U-APM通过监控整个零碎信号，抓取事件并生成相应的日志信息之后，再吐还给信号，从而显著进步了零碎ANR的捕捉率，以疾速定位谬误本源。 而针对问题聚类和智能诊断，U-APM则是参考了阿里团体外部的聚合算法和过往教训，将所发现问题的积淀起因、已经的解法等相干信息汇聚为计划交由研发人员的思路，将谬误摘要雷同的谬误日志所聚合并展现其详细信息，以帮忙产研团队疾速定位问题、解决问题。 另外，面向测试环节，U-APM云真机在提供ADB调试、WEB近程调试、扫码、抓包等惯例测试性能之外，更是提供了海量 Android 、iOS 真机，以满足测试人员发版前测试、复现问题等真机测试需要。与此同时，真机如果在线上产生解体问题，U-APM会主动采集解体信息，提供详尽的解体报告帮助开发、测试人员筛查，从而帮忙他们找到测试阶段产生的解体起因，节约大量购机老本的同时，还显著晋升了效率，真正实现监控测试全流程深度买通。 基于保障业务的出发点，从始至终都应围绕议论效率，这种对效率的执着，也反映在了U-APM的外部流转机制下面。外部流转根本分为两层： 第一层是从问题辨认到监控流程的告诉到位。除钉钉外，U-APM还反对邮箱、企业微信、飞书等多种触达形式。 第二层则是以集成外部我的项目软件或API的形式，将具体的解体问题间接流转给相应的技术同学进行排查 值得一提的是，U-APM同时对阿里外部和内部凋谢，自U-APM平台落地以来，阿里外部的诸多产品都在应用。基于U-APM杰出的产品力，其反对的App整体解体率水准均可低于0.10%这一优良规范，在研发效力上也有晋升3倍（300%）成果。 自去年U-APM对所有开发者收费凋谢后，为开发者带来10%-40%的效率晋升。目前，U-APM已对外服务超2万款利用，以及利用背地的上万家客户。 埃利德·尤德考斯基（Eliezer Yudkowsky）曾说过：“任何能带来优于人类智能的货色，（其模式可能为人工智能，人脑-计算机交互界面，基于神经科学的人类智能晋升），都会在扭转世界的比赛中占据领先地位。再没有什么能与此等量齐观。”而在数智化突飞猛进的当下，U-APM更像是新时代的智能警察，为优质的用户体验保驾护航。 点击体验：友盟+U-APM：https://www.umeng.com/apm?&ut...

基于用户对于启动剖析指标的应用需要反馈，友盟+U-APM基于弱小的技术能力，正式上线【启动剖析】性能，旨在帮忙开发者监控Android和iOS利用的启动趋势，评估利用的性能状况。 利用性能监控平台U-APM正处于产品疾速迭代期，十分重视开发者的需要与倡议，咱们基于在挪动端的积淀，本次疾速上线可反对双端Android 和iOS采集的启动剖析性能。此次启动剖析性能上新，也扩宽了U-APM性能的相干性能边界，为开发者提供收费、简略、好用的线上利用性能监控工具。 启动剖析把控利用的启动性能状态，从源头缩小客户散失，帮忙开发者日常监控利用的启动性能，及时发现导致慢启动、启动解体问题的起因并提供解决方案。同时能够评估利用的启动性能， 测试慢启动、启动解体等问题。 一、性能亮点 启动耗时趋势： 监控各版本利用的首次启动、热启动、冷启动耗时状况，整体评估利用的启动耗时是否合乎预期； 启动性能拆解 通过U-APM预置或手动埋点的形式定义启动阶段拆解形式，监控各步骤的性能耗时； 慢启动设施剖析 采集全量设施的启动状况，灵便自定义慢启动阈值，设置后实时失效，跟踪慢启动设施详情； 启动解体监控跟踪 监测采集启动条件下的利用解体信息，观测启动阶段利用的用户散失状况。 启动耗时散布 启动时序 启动解体剖析 二、如何接入 对开发者来说，接入形式也是超简略，只需满足以下条件，即可实现Android 和iOS双端的接入： Android端：U-APM SDK版本 V1.3.0及以上；根底组件包commonV9.3.8及以上 1.在工程build.gradle配置脚本中buildscript和allprojects段中增加【友盟+】SDK新maven仓库地址。 （留神由原来的maven { url 'https://dl.bintray.com/umsdk/...' } 批改为：maven { url 'https://repo1.maven.org/maven2/' }） 2.隐衷合规监管力度加大，肯定要做好合规哦！ 3.实现初始化后，依照集成文档做启动剖析相干设置：https://developer.umeng.com/d... iOS端：•U-APM SDK版本 V1.3.0及以上；根底组件包commonV7.2.8及以上 1.实现初始化后，依照集成文档做启动剖析相干设置：https://developer.umeng.com/d... 更多启动剖析性能及操作，戳此理解 观看视频：https://info.umeng.com/live/d...后盾拜访：https://apm.umeng.com/platfor... 接入详情：https://developer.umeng.com/d... U-APM 利用性能监控平台是友盟+推出的集App稳定性监控、性能监控和云真机测试为一体的平台。通过轻量级的集成接入即可领有实时、牢靠、全面的利用解体、ANR、自定义异样等捕捉能力，及卡顿、启动剖析等性能能力，反对多场景、多通道智能告警监控，帮忙开发者高效还原异样、卡顿用户的拜访门路和业务现场，缩短故障排查工夫。 U-APM同时提供云真机测试能力，助力开发者从研发测试品质验收到线上问题复现排查，保障利用品质，晋升测试效率。在云真机测试期间主动采集解体信息，提供详尽的解体报告帮助筛查，真正实现监控测试全流程深度买通。 更多详情理解：https://www.umeng.com/apm?&ut...

APM简介 随着微服务架构的风行，一次申请往往须要波及到多个服务，因而服务性能监控和排查就变得更简单： 不同的服务可能由不同的团队开发、甚至可能应用不同的编程语言来实现 服务有可能布在了几千台服务器，横跨多个不同的数据中心 因而，就须要一些能够帮忙了解零碎行为、用于剖析性能问题的工具，以便产生故障的时候，可能疾速定位和解决问题，这就是APM零碎，全称是（Application Performance Monitor，当然也有叫 Application Performance Management tools） AMP最早是谷歌公开的论文提到的 Google Dapper。Dapper是Google生产环境下的分布式跟踪零碎，自从Dapper倒退成为一流的监控零碎之后，给google的开发者和运维团队帮了大忙，所以谷歌公开论文分享了Dapper。 谷歌Dapper介绍 在google的首页页面，提交一个查问申请后，会经验什么： •可能对上百台查问服务器发动了一个Web查问，每一个查问都有本人的Index•这个查问可能会被发送到多个的子系统，这些子系统别离用来解决广告、进行拼写查看或是查找一些像图片、视频或新闻这样的非凡后果•依据每个子系统的查问后果进行筛选，失去最终后果，最初汇总到页面上•总结一下：一次全局搜寻有可能调用上千台服务器，波及各种服务。用户对搜寻的耗时是很敏感的，而任何一个子系统的低效都导致导致最终的搜寻耗时 如果一次查问耗时不失常，工程师怎么来排查到底是由哪个服务调用造成的？ •首先，这个工程师可能无奈精确的定位到这次全局搜寻是调用了哪些服务，因为新的服务、乃至服务上的某个片段，都有可能在任何工夫上过线或批改过，有可能是面向用户性能，也有可能是一些例如针对性能或平安认证方面的性能改良•其次，你不能奢求这个工程师对所有参加这次全局搜寻的服务都一目了然，每一个服务都有可能是由不同的团队开发或保护的•再次，这些裸露进去的服务或服务器有可能同时还被其余客户端应用着，所以这次全局搜寻的性能问题甚至有可能是由其余利用造成的从下面能够看出Dapper须要： 无所不在的部署，无所不在的重要性显而易见，因为在应用跟踪零碎的进行监控时，即使只有一小部分没被监控到，那么人们对这个零碎是不是值得信赖都会产生微小的质疑 继续的监控 Dapper的三个具体设计指标 性能耗费低 APM组件服务的影响应该做到足够小。服务调用埋点自身会带来性能损耗，这就须要调用跟踪的低损耗，理论中还会通过配置采样率的形式，抉择一部分申请去剖析申请门路。在一些高度优化过的服务，即便一点点损耗也会很容易察觉到，而且有可能迫使在线服务的部署团队不得不将跟踪零碎关停。 利用通明，也就是代码的侵入性小 即也作为业务组件，该当尽可能少或者无其余业务零碎，对于应用方通明，缩小开发人员的累赘。 对于利用的程序员来说，是不须要晓得有跟踪零碎这回事的。如果一个跟踪零碎想失效，就必须须要依赖利用的开发者被动配合，那么这个跟踪零碎也太软弱了，往往因为跟踪零碎在利用中植入代码的bug或忽略导致利用出问题，这样才是无奈满足对跟踪零碎“无所不在的部署”这个需要。 可扩展性 一个优良的调用跟踪零碎必须反对分布式部署，具备良好的可扩展性。可能反对的组件越多当然越好。或者提供便捷的插件开发API，对于一些没有监控到的组件，利用开发者也能够自行扩大。 数据的剖析 数据的剖析要快 ，剖析的维度尽可能多。跟踪零碎能提供足够快的信息反馈，就能够对生产环境下的异样情况做出快速反应。剖析的全面，可能防止二次开发。 Dapper的分布式跟踪原理 根本办法 •黑盒计划：假设须要跟踪的除了上述信息之外没有额定的信息，这样应用统计回归技术来推断两者之间的关系。须要一些额定的数据来取得足够精度。•基于标注的计划：依赖于应用程序或中间件明确地标记一个全局ID，从而连贯每一条记录和发起者的申请。毛病是有代码*。 跟踪树和span 在Dapper跟踪树结构中，树节点是整个架构的根本单元，而每一个节点又是对span的援用。节点之间的连线示意的span和它的父span间接的关系。尽管span在日志文件中只是简略的代表span的开始和完结工夫，他们在整个树形构造中却是绝对独立的。这里span是跟踪术构造的根本单元，也示意一小段的工夫。 上图阐明了span在一个大的跟踪过程中是什么样的。Dapper记录了span名称，以及每个span的ID和父ID，以重建在一次追踪过程中不同span之间的关系。如果一个span没有父ID被称为root span。所有span都挂在一个特定的跟踪上，也共用一个跟踪id（在图中未示出）。所有这些ID用全局惟一的64位整数标示。在一个典型的Dapper跟踪中，咱们心愿为每一个RPC对应到一个繁多的span上，而且每一个额定的组件层都对应一个跟踪树型构造的层级。 上图给出了一个更具体的典型的Dapper跟踪span的记录点的视图。在图中这种某个span表述了两个“Helper.Call”的RPC(别离为server端和client端)。span的开始工夫和完结工夫，以及任何RPC的工夫信息都通过Dapper在RPC组件库的植入记录下来。如果应用程序开发者抉择在跟踪中减少他们本人的正文（如图中“foo”的正文）(业务数据)，这些信息也会和其余span信息一样记录下来。 埋点 1.追踪的上下文信息在ThreadLocal中进行存储。2.当计算过程是提早调用的或是异步的，google通过通用的控制流来回调，确保所有的回调能够存储这次跟踪的上下文信息。当回调函数被触发时，这次跟踪的上下文会与适当的线程关联上。在这种形式下，Dapper能够应用trace ID和span ID来辅助构建异步调用的门路。3.google的所有过程通信是建设在一个RPC框架上。在RPC框架自身中来埋点从而定义所有span。4.dapper容许用户在Dapper跟踪的过程中增加额定的信息，以监控更高级别的零碎行为，或帮忙调试问题。咱们容许用户通过一个简略的API定义带工夫戳的Annotation，外围的示例代码如下图所示。5.dapper反对如下图的文本annotation也反对key-value映射的Annotation。如继续的计数器，二进制音讯记录和在一个过程上跑着的任意的用户数据等。 跟踪收集由上图可知，Dapper的跟踪记录和收集管道的过程分为三个阶段: span数据写入本地日志文件中。而后Dapper的守护过程和收集组件把这些流量交易数据从生产环境的主机中拉进去 写到Dapper的Bigtable仓库中。一次跟踪被设计成Bigtable中的一行，每一列相当于一个span。Bigtable的反对稠密表格布局正适宜这种状况，因为每一次跟踪能够有任意多个span。Dapper还提供了一个API来简化拜访咱们仓库中的跟踪数据。Google的开发人员用这个API，以构建通用和特定应用程序的剖析工具。 APM组件选型 市面上的全链路监控实践模型大多都是借鉴Google Dapper论文，重点关注以下三种APM组件： •Zipkin：由Twitter公司开源，凋谢源代码分布式的跟踪零碎，用于收集服务的定时数据，以解决微服务架构中的提早问题，包含：数据的收集、存储、查找和展示。•Pinpoint：一款对Java编写的大规模分布式系统的APM工具，由韩国人开源的分布式跟踪组件。•Skywalking：国产的优良APM组件，是一个对JAVA分布式应用程序集群的业务运行状况进行追踪、告警和剖析的零碎。 比照项 次要比照项： 探针的性能 次要是agent对服务的吞吐量、CPU和内存的影响。微服务的规模和动态性使得数据收集的老本大幅度提高。 collector的可扩展性 可能程度扩大以便反对大规模服务器集群。 全面的调用链路数据分析 提供代码级别的可见性以便轻松定位失败点和瓶颈。 对于开发通明，容易开关 增加新性能而无需批改代码，容易启用或者禁用。 残缺的调用链利用拓扑 自动检测利用拓扑，帮忙你搞清楚利用的架构 如何采集数据 APM是通过采集探针采集利用数据的。采集探针是通过字节码加强技术进行埋点，生成调用数据。调用数据被采集代理ICAgent所获取并解决，而后上报并出现在界面中。关系如下图所示： 采集哪些数据 APM仅采集利用的业务调用链数据、资源信息、资源属性、内存检测信息、调用申请的KPI数据，不波及个人隐私数据。所采集的数据仅用于APM性能剖析和故障诊断，不会用于其余商业目标。下表为数据采集范畴和用处。 行业剖析 目前APM市场在海内次要有两类的外围企业。一类是四大传统IT巨头（IBM、HP、CATechnologies、BMC），另一类是ITOM市场新创企业，包含Dynatrace、NewRelic、AppDynamics、Splunk等。随着市场成熟度的一直进步，APM市场的市场格局与ITOM整体的市场格局一样，出现初创企业减速倒退，开始占据市场主导的市场趋势。 ...

1.挪动端监控体系之技术原理分析 2.阿里百川码力APP监控来了 重量级选手进入APM市场 3.微信iOS卡顿监控零碎 4.挪动端性能监控计划Hertz 5.谈谈iOS app的线上性能监测 6.iOS实时卡顿监控 7.微信读书 iOS 质量保证及性能监控

一个 App 一般会存在很多场景去上传 App 中产生的数据，比如 APM、埋点统计、开发者自定义的数据等等。所以本篇文章就讲讲如何设计一个通用的、可配置的、多句柄的数据上报 SDK。前置说明因为这篇文章和 APM 是属于姊妹篇，所以看这篇文章的时候有些东西不知道活着好奇的时候可以看带你打造一套 APM 监控系统。 另外看到我在下面的代码段，有些命名风格、简写、分类、方法的命名等，我简单做个说明。 数据上报 SDK 叫 PrismClient，我们规定类的命名一般用 SDK 的名字缩写，当前情况下缩写为 PCT给 Category 命名，规则为 类名 + SDK 前缀缩写的小写格式 + 下划线 + 驼峰命名格式的功能描述。比如给 NSDate 增加一个获取毫秒时间戳的分类，那么类名为 NSDate+pct_TimeStamp给 Category 的方法命名，规则为 SDK 前缀缩写的小写格式 + 下划线 + 驼峰命名格式的功能描述。比如给 NSDate 增加一个根据当前时间获取毫秒时间戳的方法，那么方法名为 + (long long)pct_currentTimestamp;一、 首先定义需要做什么我们要做的是「一个通用可配置、多句柄的数据上报 SDK」，也就是说这个 SDK 具有这么几个功能： 具有从服务端拉取配置信息的能力，这些配置用来控制 SDK 的上报行为（需不需要默认行为？）SDK 具有多句柄特性，也就是拥有多个对象，每个对象具有自己的控制行为，彼此之间的运行、操作互相隔离APM 监控作为非常特殊的能力存在，它也使用数据上报 SDK。它的能力是 App 质量监控的保障，所以针对 APM 的数据上报通道是需要特殊处理的。数据先根据配置决定要不要存，存下来之后再根据配置决定如何上报明白我们需要做什么，接下来的步骤就是分析设计怎么做。 二、 拉取配置信息1. 需要哪些配置信息首先明确几个原则： 因为监控数据上报作为数据上报的一个特殊 case，那么监控的配置信息也应该特殊处理。监控能力包含很多，比如卡顿、网络、奔溃、内存、电量、启动时间、CPU 使用率。每个监控能力都需要一份配置信息，比如监控类型、是否仅 WI-FI 环境下上报、是否实时上报、是否需要携带 Payload 数据。（注：Payload 其实就是经过 gZip 压缩、AES-CBC 加密后的数据）多句柄，所以需要一个字段标识每份配置信息，也就是一个 namespace 的概念每个 namespace 下都有自己的配置，比如数据上传后的服务器地址、上报开关、App 升级后是否需要清除掉之前版本保存的数据、单次上传数据包的最大体积限制、数据记录的最大条数、在非 WI-FI 环境下每天上报的最大流量、数据过期天数、上报开关等针对 APM 的数据配置，还需要一个是否需要采集的开关。所以数据字段基本如下 ...

【转载请注明出处】：https://segmentfault.com/a/1190000023079914 随着企业经营规模的扩大，以及对内快速诊断效率和对外SLA（服务品质协议，service-level agreement)的追求，对于业务系统的掌控度的要求越来越高，主要体现在： 对于第三方依赖的监控，实时/准实时了解第三方的健康状况/服务品质，降低第三方依赖对于自身系统的扰动（服务降级、故障转移）对于容器的监控，实时/准实时的了解应用部署环境（CPU、内存、进程、线程、网络、带宽）情况，以便快速扩容/缩容、流量控制、业务迁移业务方对于自己的调用情况，方便作容量规划，同时对于突发的请求也能进行异常告警和应急准备自己业务的健康、性能监控，实时/准实时的了解自身的业务运行情况，排查业务瓶颈，快速诊断和定位异常，增加对自己业务的掌控力同时，对于企业来说，能够更精确的了解资源的使用情况，对于成本核算和控制也有非常大的裨益。 在这种情况下，一般都会引入APM（Application Performance Management & Monitoring）系统，通过各种探针采集数据，收集关键指标，同时搭配数据呈现和监控告警，能够解决上述的大部分问题。 然而随着RPC框架、微服务、云计算、大数据的发展，同时业务的规模和深度相比过往也都增加了很多，一次业务可能横跨多个模块/服务/容器，依赖的中间件也越来越多，其中任何一个节点出现异常，都可能导致业务出现波动或者异常，这就导致服务质量监控和异常诊断/定位变得异常复杂，于是催生了新的业务监控模式：调用链跟踪--能够分布式的抓取多个节点的业务记录，并且通过统一的业务id（traceId，messageId，requestId等）将一次业务在各个节点的记录串联起来，方便排查业务的瓶颈或者异常点 产品对比APM和调用链跟踪均不是新诞生事务，很多公司已经有了大量的实践，不过开源的并且能够开箱即用的产品并不多，这里主要选取了Pinpoint，Skywalking，CAT来进行对比（当然也有其他的例如Zipkin，Jaeger等产品，不过总体来说不如前面选取的3个完成度高），了解一下APM和调用链跟踪在开源方面的发展状态。 PinpointPinpoint是一个比较早并且成熟度也非常高的APM+调用链监控的项目，在全世界范围内均有用户使用，支持Java和PHP的探针，数据容器为HBase，其界面参考： SkywalkingSkywalking是一个新晋的项目，最近一两年发展非常迅猛，本身支持OpenTracing规范，优秀的设计提供了良好的扩展性，支持Java、PHP、.Net、NodeJs探针，数据容器为ElasticSearch，其界面参考： CATCAT是由美团开源的一个APM项目，也历经了多年的迭代升级，拥有大量的企业级用户，对于监控和报警整合比较紧密，支持Java、C/C++、.Net、Python、Go、NodeJs，不过CAT目前主要通过侵入性的方式接入，数据容器包括HDFS（存储原始数据）和mysql（二次统计），其界面参考： 横向对比上面只是做了一个简介，那这三个项目各自有什么特色或者优势/劣势呢（三者的主要产品均针对Java，这里也主要针对Java的特性） Pinpoint优势： 大企业/长时间验证，稳定性和完成度高探针收集的数据粒度比较细HBase的数据密度较大，支持PB级别下的数据查询代码设计考虑的扩展性较弱，二次开发难度较大（探针为插件式，开发比较简单）拥有完整的APM和调用链跟踪功能劣势： 代码针对性强，扩展较难容器为HBase，查询功能较弱（主要为时间维度）探针的额外消耗较多（探针采集粒度细，大概10%~20%）项目趋于成熟，而扩展难度较大，目前社区活跃度偏低，基本只进行探针的增加或者升级缺少自定义指标的设计Skywalking优势： 数据容器为ES，查询支持的维度较多并且扩展潜力大项目设计采用微内核+插件，易读性和扩展性都比较强主要的研发人员为华人并且均比较活跃，能够进行更加直接的沟通拥有完整的APM和调用链跟踪功能劣势： 项目发展非常快，稳定性有待验证ES数据密度较小，在PB级别可能会有性能压力缺少自定义指标的设计CAT优势： 大企业/长时间验证，稳定性和完成度高采用手动数据埋点而不是探针，数据采集的灵活性更强支持自定义指标代码设计考虑的扩展性较弱，并且数据结构复杂，二次开发难度较大拥有完善的监控告警机制劣势： 代码针对性强，扩展较难需要手动接入埋点，代码侵入性强APM功能完善，但是不支持调用链跟踪基本组件如果分别去看Pinpoint/Skywalking/CAT的整体设计，我们会发现三者更像是一个规范的三种实现，虽然各自有不同的机制和特性，但是从模块划分和功能基本是一致的： 当然也有一些微小的区别： Pinpoint基本没有aggregator，同时query和alarm集成在了web中，只有agent，collector和webSkywalking则是把collector、aggregator、alarm集成为OAP（Observability Analysis Platform），并且可以通过集群部署，不同的实例可以分别承担collector或者aggregator+alarm的角色CAT则和Skywalking类似，把collector、aggregator、alarm集成为cat-consumer，而由于CAT有比较复杂的配置管理，所以query和配置一起集成为cat-home当然最大的区别是Pinpoint和Skywalking均是通过javaagent做字节码的扩展，通过切面编程采集数据，类似于探针，而CAT的agent则更像是一个工具集，用于手动埋点【转载请注明出处】：https://segmentfault.com/a/1190000023079914

当用户碰到问题时极少会选择反馈，沉默的是大多数，现在不少APP比如知乎都提供了摇一摇弹出用户反馈入口，减少进入功能模块的时间成本，不过遗憾的是，针对同一个问题一百个人有一百种描述方法，用户反馈的语法分析和文本分类是一个大工程。另外通过排查传统基础层的方法很难快速定位到问题，比如运营商光缆被挖断，导致某地区CDN图片异常告警居高不下，由于用户到后端资源的不透明性，问题可能出现在缓存配置可能是因为小运营商非法调度也可能出现在源站，当你排查一圈后突然恢复了，诸如此类问题，通过主动监测可以快速定位到问题 那么什么是主动监测呢？主动监测是使用SDK在APP编译或者运行时自动地对代码进行注入下发监测任务，模拟用户真实请求，然后动态采集上报数据的一种技术，主动监测可以根据需要均衡采集，避免全采样或者频繁上报数据导致用户移动数据流量的流失，它还支持ping、traceroute、nslookup、抓包等网络性能问题定位的手段，另外可以提供完整的访问瀑布图包括错误元素 主动监测可以用于大网波动感知、CDN监控、网络劫持监测 大网波动感知比较好理解，就是通过不同省份不同运营商的用户去探测访问节点，然后得到各地区到各运营商的平均延迟和丢包情况，从而判断区域间链路故障情况 通过主动监测可以让CDN服务更加透明，可以考核前期选型、后期质量达标情况，可以评估变更效果，比如回源使用https、调整加速资源、调整解析调度策略等变更对用户页面加载速度的影响，可以检测出现异常时是否由CDN引起的，我之前碰到过一起支付成功页证书连接不安全的问题，由于下发资源是千人千面的，同时JS回调中混着非京东域名图片连接，传统排查方法在较为低效。另外在大促高峰时期，可能需要借助第三方CDN提供商抗量，我们可以监测对比各三方的加速效果，包括但不限于可用率、下载速度、覆盖率、DNS解析时间、首包时间、建连时间，同时可以监测第三方证书配置情况 最后说说网络劫持监测,流量劫持一般是通过链路劫持插入特定报文或者抢答，另外一种是DNS劫持，它返回非真实网站IP地址，这两种都会使得客户端获取到错误数据，进而显示广告或者点击弹窗跳转，网上有一个前端神器Subresource Integrity,它是通过生成文件的唯一hash值进行对比校验的，但是对于大体量公司来说，涉及到多团队协作推进和后期新增模块约束保证，难度比较大，这个时候可以借助主动监测监控和处理劫持问题，劫持数据返回时间会比正常的时延低一个级别，TCP握手时候的TTL返回值会明显不一致，我们可以利用这些特点进行异常检测，另外可以利用白名单机制维护元素域名白名单、主机IP白名单、CNAME信息，但是会造成APP动态加载配置数据膨胀，需要一定的取舍，重点保障核心利益域名 DNS劫持涉及到买卖流量这个灰色产业链，想避免DNS劫持的话尽量不要使用运营商默认的DNS,可以使用移动解析(HttpDns)，它基于HTTP协议向公司的DNS服务发送域名解析请求，替代了基于DNS协议向运营商Local DNS发起解析请求的传统方式 BLOG连接：www.liangsonghua.me作者介绍：京东资深工程师-梁松华，长期关注稳定性保障、敏捷开发、微服务架构

为了方便测试，我们在一台机器上安装所需有的软件部署时间：2019-03-25需要的软件及版本软件名称版本号pinpoint系列(web, collector, agent)1.8.2(当前latest)tomcat7.0.93hbase2.1.3下载所需软件下载pinpointwget https://github.com/naver/pinpoint/releases/download/1.8.2/pinpoint-agent-1.8.2.tar.gzwget https://github.com/naver/pinpoint/releases/download/1.8.2/pinpoint-collector-1.8.2.warwget https://github.com/naver/pinpoint/releases/download/1.8.2/pinpoint-web-1.8.2.war下载pinpoint针对hbase数据库初始化文件wget https://raw.githubusercontent.com/naver/pinpoint/master/hbase/scripts/hbase-create.hbase安装基础软件安装tomcat详见https://qianmoq.com/tomcat/tomcat_an_zhuang_bu_shu.html安装HBase详见https://qianmoq.com/hbase/hbase_an_zhuang_bu_shu.html初始化ponpint数据库登录到hbase服务器中执行以下命令hbase-2.1.3/bin/hbase shell ./hbase-create.hbase安装pinpoint-collector修改pinpoint-collector.properties配置文件vim apache-tomcat-7.0.93/webapps/ROOT/WEB-INF/classes/pinpoint-collector.properties暂时修改cluster.enable配置为false修改hbase.properties配置文件vim apache-tomcat-7.0.93/webapps/ROOT/WEB-INF/classes/hbase.propertieshbase.client.host修改为hbase服务地址hbase.client.port修改为hbase的zk地址其他配置先不变使用默认即可重启tomcat服务apache-tomcat-7.0.93/bin/shutdown.shapache-tomcat-7.0.93/bin/startup.sh安装pinpoint-web修改apache-tomcat-7.0.93/webapps/ROOT/WEB-INF/classes/pinpoint-web.properties配置文件vim apache-tomcat-7.0.93/webapps/ROOT/WEB-INF/classes/pinpoint-web.properties暂时修改cluster.enable配置为false修改hbase.properties配置文件vim apache-tomcat-7.0.93/webapps/ROOT/WEB-INF/classes/hbase.propertieshbase.client.host修改为hbase服务地址hbase.client.port修改为hbase的zk地址其他配置先不变使用默认即可重启tomcat服务apache-tomcat-7.0.93/bin/shutdown.shapache-tomcat-7.0.93/bin/startup.sh部署pinpoint-agent解压pinpoint-agent-1.8.2.tar.gz文件tar -xvzf pinpoint-agent-1.8.2.tar.gz -C pinpoint-agent使用pinpoint监听collector,web的tomcat容器修改pinpoint.config配置文件vim pinpoint-agent/pinpoint.config修改profiler.collector.ip为collector服务的地址其他的配置暂时不修改配置tomcat使用pinpoint监听服务修改catalina.sh启动文件vim apache-tomcat-7.0.93/bin/catalina.sh在文件中增加以下配置CATALINA_OPTS="$CATALINA_OPTS -javaagent:/hadoop/dc/apm/pinpoint-agent/pinpoint-bootstrap-1.8.2.jar"CATALINA_OPTS="$CATALINA_OPTS -Dpinpoint.agentId=pinpoint-agent-001"CATALINA_OPTS="$CATALINA_OPTS -Dpinpoint.applicationName=PinpointWebServer"pinpoint.agentId: 只要保证每个应用不重复即可pinpoint.applicationName: 现在是pinpoint中的名称,能去分开即可重启tomcat服务apache-tomcat-7.0.93/bin/shutdown.shapache-tomcat-7.0.93/bin/startup.sh浏览器打开pinpoint的web页面即可看到监控信息

随着Skywalking 6.0 GA版本的发布，Skywalking终于支持Elasticsearch 6.x版本，本文作为搭建Skywalking 6.0集群系列文章的第一篇介绍下Elasticsearch 6.6集群的搭建。1. 准备1.1 节点规划IPcluster.namenode.name10.130.10.11es_loges_110.130.10.12es_loges_210.130.10.13es_loges_31.2 安装Java运行环境JREwget -c -P /tmp https://github.com/AdoptOpenJDK/openjdk8-binaries/releases/download/jdk8u202-b08/OpenJDK8U-jre_x64_linux_hotspot_8u202b08.tar.gzmkdir /usr/java;\tar xf /tmp/OpenJDK8U-jre_x64_linux_hotspot_8u202b08.tar.gz -C /usr/java;\rm -rf /usr/java/default;\ln -s /usr/java/jdk8u202-b08-jre /usr/java/default;\tee -a /etc/profile << ‘EOF’export JAVA_HOME=/usr/java/defaultexport PATH=$JAVA_HOME/bin:$PATHEOF2. 安装2.1 导入Elasticserach软件源rpm –import https://artifacts.elastic.co/GPG-KEY-elasticsearch;\tee /etc/yum.repos.d/elasticsearch.repo << ‘EOF’[elasticsearch-6.x]name=Elasticsearch repository for 6.x packagesbaseurl=https://artifacts.elastic.co/packages/6.x/yumgpgcheck=1gpgkey=https://artifacts.elastic.co/GPG-KEY-elasticsearchenabled=1autorefresh=1type=rpm-mdEOF2.2 安装软件yum install elasticsearch -y2.3 配置LimitLimitMEMLOCK开启内存锁定LimitNPROC最大进程数，系统支持的最大进程数：32768查看系统最大支持进程数：cat /proc/sys/kernel/pid_maxLimitNOFILE打开文件数,系统默认最大文件描述符：791020查看系统最大文件描述符：cat /proc/sys/fs/file-maxmkdir /etc/systemd/system/elasticsearch.service.d;\cat > /etc/systemd/system/elasticsearch.service.d/override.conf << ‘EOF’[Service]Environment=JAVA_HOME=/usr/java/default LimitMEMLOCK=infinityLimitNOFILE=204800LimitNPROC=4096EOF2.4 配置JVM(可选)默认是2G不要超过可用 RAM 的 50%Lucene 能很好利用文件系统的缓存，它是通过系统内核管理的。如果没有足够的文件系统缓存空间，性能会受到影响。 此外，专用于堆的内存越多意味着其他所有使用 doc values 的字段内存越少不要超过 32 GB如果堆大小小于 32 GB，JVM 可以利用指针压缩，这可以大大降低内存的使用：每个指针 4 字节而不是 8 字节sed -i ‘/-Xms2g/c-Xms3g’ /etc/elasticsearch/jvm.options;\sed -i ‘/-Xmx2g/c-Xmx3g’ /etc/elasticsearch/jvm.options2.5 配置elasticsearch.ymlcluster.name集群名称，默认是elasticsearch，建议修改为更明确的名称，比如es_lognode.name节点名，默认随机指定一个name列表中名字，建议修改为明确的名称，比如es_1,es_2,es_3network.host主机IPpath.data数据目录path.logs日志目录discovery.zen.ping.unicast.hosts节点发现2.5.1 所有节点执行相同的命令mkdir -p /home/elasticsearch/data /home/elasticsearch/logs;\chown -R elasticsearch. /home/elasticsearch;\sed -i ‘/cluster.name/c\cluster.name: es_log’ /etc/elasticsearch/elasticsearch.yml;\sed -i ‘/network.host/c\network.host: 0.0.0.0’ /etc/elasticsearch/elasticsearch.yml;\sed -i ‘/path.data/c\path.data: /home/elasticsearch/data’ /etc/elasticsearch/elasticsearch.yml;\sed -i ‘/path.logs/c\path.logs: /home/elasticsearch/logs’ /etc/elasticsearch/elasticsearch.yml;\sed -i ‘/discovery.zen.ping.unicast.hosts/c\discovery.zen.ping.unicast.hosts: [“10.130.10.11”,“10.130.10.12”,“10.130.10.13”]’ /etc/elasticsearch/elasticsearch.yml2.5.2 各个节点执行对应的命令#节点-1sed -i ‘/node.name/c\node.name: es_1’ /etc/elasticsearch/elasticsearch.yml#节点-2sed -i ‘/node.name/c\node.name: es_2’ /etc/elasticsearch/elasticsearch.yml#节点-3sed -i ‘/node.name/c\node.name: es_3’ /etc/elasticsearch/elasticsearch.yml2.6 启动systemctl enable elasticsearch;\systemctl daemon-reload;\systemctl start elasticsearch;\systemctl status elasticsearch2.7 配置防火墙firewall-cmd –add-port=9200/tcp –permanent;\firewall-cmd –add-port=9300/tcp –permanent;\firewall-cmd –reload3. 安装中文分词插件（可选）#查看已安装插件/usr/share/elasticsearch/bin/elasticsearch-plugin list#安装IK/usr/share/elasticsearch/bin/elasticsearch-plugin install https://github.com/medcl/elasticsearch-analysis-ik/releases/download/v6.6.0/elasticsearch-analysis-ik-6.6.0.zip4. 查询#查看节点信息curl -X GET http://localhost:9200/_nodes#打开文件数信息curl -X GET http://localhost:9200/_nodes/stats/process?filter_path=**.max_file_descriptors#集群健康状态curl -X GET http://localhost:9200/_cat/health?v#查看集群索引数curl -X GET http://localhost:9200/_cat/indices?v#查看磁盘分配情况curl -X GET http://localhost:9200/_cat/allocation?v#查看集群节点curl -X GET http://localhost:9200/_cat/nodes?v#查看集群其他信息curl -X GET http://localhost:9200/_cat ...

分布式追踪系统Dapper文档：http://bigbully.github.io/Dap…文档：http://opentracing.io/documen…中文版：https://wu-sheng.gitbooks.io/…名称来源备注DapperGoogle ZipkinTwitter MtraceMeituan eagle eye阿里 appdash开源 HTraceApache 孵化项目 OpenTracing Jaeger开源 X-Tracex-tracex-traceMagpie微软MagpiePinpoint应用性能监控工具PinpointSkyWalkingApache 孵化项目SkyWalkingCAT CAT