性能监控

Perfmon简介Perfmon(Performance Monitor)是一款Windows自带的性能监控工具，提供了图表化的零碎性能实时监视器、性能日志和警报治理。通过增加性能计数器(Performance Counter)能够实现对CPU、内存、网络、磁盘、过程等多类对象的上百个指标的监控。其中，性能日志可定义输入格局为二进制文件、文本文件、SQLSERVER记录等，以不便后续应用第三方工具进行剖析。 Perfmon数据收集器应用Perfmon反对选择性的监控感兴趣的数据收集器，指标范围广、粒度细，而且反对将监控数据长久化。应用办法：　Win+r关上运行窗口，输出 perfmon 后回车关上perfmon.exe。　开展“数据收集器集”，右键单击“用户定义”，指向“新建”，而后单击“数据收集器集”，将启动“创立新数据收集器集”向导。依照向导一步步创立新的数据收集器。举荐手动创立，抉择本人感兴趣的指标监控。创立好后，通过工具栏的启动按钮能够启动数据收集器。点击工具栏上的进行按钮就能够进行数据收集器。之后，能够在右侧导航栏抉择”报告”，开展“用户定义”，查看报告。报告也能够另存为csv文件做进一步剖析。Perfmon对过程的监控指标一般来说，咱们次要关注本人过程的CPU、内存等性能数据。Perfmon设置了过程监控罕用指标，这些指标比拟直观地体现了过程的运行状况，是进行利用系统监控或利用零碎跟踪调优的根据。先监控这些指标须要在创立数据收集器的时候抉择监控process对象，并且选定对象的实例为想要监控的过程。 上面表格列出了Process对象的次要指标： 性能对象计数器提供的信息Process% Privileged Time% Privileged Time 是在特权模式下解决线程执行代码所花工夫的百分比。当调用 Windows 零碎服务时，此服务常常在特权模式运行，以便获取对系统专有数据的拜访。在用户模式执行的线程无法访问这些数据。对系统的调用能够是间接的(explicit)或间接的(implicit)，例如页面谬误或距离。Process% Processor Time% Processor Time 是所有过程线程应用处理器执行指令所花的工夫百分比。指令是计算机执行的根底单位。线程是执行指令的对象，过程是程序运行时创立的对象。此计数包含解决某些硬件距离和陷阱条件所执行的代码。Process% User Time% User Time 指解决线程用于执行应用用户模式的代码的工夫的百分比。应用程序、环境分系统和汇合分系统是以用户模式执行的。Windows 的可执行程序、内核和设施驱动程序不会被以用户模式执行的代码损坏。ProcessCreating Process ID valueCreating Process ID value 指创立该过程的父过程号。ProcessElapsed Time该过程运行的总工夫(用秒计算)。ProcessHandle Count这个解决当初关上的句柄总数。这个数字等于这个解决中每个线程以后关上的句柄的总数。ProcessID ProcessID Process 指这个解决的特地的辨认符。ID Process 号可重复使用，所以这些 ID Process 号只能在一个解决的寿命期内辨认那个解决。ProcessIO Data Bytes/sec解决从 I/O 操作读取/写入字节的速度。这个计数器为所有由本解决产生的包含文件、网络和设施 I/O 的流动计数。ProcessIO Data Operations/sec本解决进行读取/写入 I/O 操作的速率。这个计数器为所有由本解决产生的包含文件、网络和设施 I/O 的流动计数。ProcessIO Other Bytes/sec解决给不包含数据的 I/O 操作(如管制操作)字节的速率。这个计数器为所有由本解决产生的包含文件、网络和设施 I/O 的流动计数。ProcessIO Other Operations/sec本解决进行非读取/写入 I/O 操作的速率。例如，管制性能。这个计数器为所有由本解决产生的包含文件、网络和设施 I/O 的流动计数。ProcessIO Read Bytes/sec解决从 I/O 操作读取字节的速度。这个计数器为所有由本解决产生的包含文件、网络和设施 I/O 的流动计数。ProcessIO Read Operations/sec本解决进行读取 I/O 操作的速率。这个计数器为所有由本解决产生的包含文件、网络和设施 I/O 的流动计数。ProcessIO Write Bytes/sec解决从 I/O 操作写入字节的速度。这个计数器为所有由本解决产生的包含文件、网络和设施。ProcessIO Write Operations/sec本解决进行写入 I/O 操作的速率。这个计数器为所有由本解决产生的包含文件、网络和设施 I/O 的流动计数。ProcessPage Faults/secPage Faults/sec 指在这个过程中执行线程造成的页面谬误呈现的速度。当线程援用了不在主内存工作集中的虚拟内存页即会呈现 Page Fault。如果它在备用表中(即曾经在主内存中)或另一个共享页的解决正在应用它，就会引起无奈从磁盘中获取页。ProcessPage File BytesPage File Bytes 指这个解决在 Paging file 中应用的最大字节数。Paging File 用于存储不蕴含在其余文件中的由解决应用的内存页。Paging File 由所有解决共享，并且 Paging File 空间有余会避免其余解决分配内存。ProcessPage File Bytes PeakPage File Bytes Peak 指这个解决在 Paging files 中应用的最大数量的字节。ProcessPool Nonpaged BytesPool Nonpaged Bytes 指在非分页池中的字节数，非分页池是指零碎内存(操作系统应用的物理内存)中可供对象(指那些在不处于应用时不能够写入磁盘上而且只有分派过就必须保留在物理内存中的对象)应用的一个区域。这个计数器仅显示上一次察看的值；而不是一个平均值。ProcessPool Paged BytesPool Paged Bytes 指在分页池中的字节数，分页池是零碎内存(操作系统应用的物理内存)中可供对象(在不处于应用时能够写入磁盘的)应用的一个区域。这个计数器仅显示上一次察看的值；而不是一个平均值。ProcessPriority Base这次解决的以后根本优先权。在一个解决中的线程能够依据解决的根本优先权进步或升高本人的根本优先权。ProcessPrivate BytesPrivate Bytes 指这个解决不能与其余解决共享的、已调配的以后字节数。ProcessThread Count在这次解决中正在流动的线程数目。指令是在一台处理器中根本的执行单位，线程是指执行指令的对象。每个运行解决至多有一个线程。ProcessVirtual BytesVirtual Bytes 指解决应用的虚拟地址空间的以字节数显示的以后大小。应用虚拟地址空间不肯定是指对磁盘或主内存页的相应的应用。虚拟空间是无限的，可能会限度解决加载数据库的能力。ProcessVirtual Bytes PeakVirtual Bytes Peak 指在任何工夫内该解决应用的虚拟地址空间字节的最大数。ProcessWorking SetWorking Set 指这个解决的 Working Set 中的以后字节数。Working Set 是在解决中被线程最近触到的那个内存页集。如果计算机上的可用内存处于阈值以上，即便页不在应用中，也会留在一个解决的 Working Set中。当可用内存降到阈值以下，将从 Working Set 中删除页。如果须要页时，它会在来到主内存前软故障返回到 Working Set 中。ProcessWorking Set PeakWorking Set Peak 指在任何工夫这个在解决的 Working Set 的最大字节数。监控CPU利用Perfmon监控过程的% Processor Time和% User Time这2个计数器能够监控其CPU应用，剖析CPU应用是否存在异样。% Processor Time记录了过程中应用CPU的百分比；% User Time记录了过程用户模式应用CPU的百分比；如果这2个值始终较大，或者继续升高，则可能存在CPU应用异样的问题。 ...

性能监控软件APMApplication Performance Management（简称APM）是一款业余的性能监控工具，能够对全链路如Web服务器、应用服务器、数据库服务器等进行实时监控，并以图表化的模式直观地出现监控数据，为零碎性能优化和定位问题提供精确的数据根据。 APM性能监控软件产品包含哪些方面性能一、监控类型全面 提供如下类型的系统监控服务，蕴含：JVM监控，JMX监控，服务器监控，MySQL慢日志监控，Oracle监控，Redis监控，Nginx监控，docker监控，链路跟踪监控。 二、操作简略 在被监控的服务器中启动监控客户端，配置相干的数据链接并点击启用，APM监控工具会主动获取监控数据并实时展现。 三、监控数据实时显示 APM监控工具能够实时监控被监控服务器的CPU信息，磁盘信息，内存信息，日志信息等，并以图表的模式直观动静地进行展现。 四、反对交互式剖析 APM监控工具提供实时、交互式剖析，可能展示利用零碎的各种信息，如线程、程序代码、锁、sql语句等，不便剖析性能计数器和性能指标， 定位确定性能瓶颈，精确定位问题。 五、性能预警 在告警配置页面能够自主设置监控数据预警值，当被监控数据达到设定的预警时，会通过邮箱和手机短信两种模式告诉预警信息。 APM性能监控软件监控流程有哪些1、启动监控器 2、登录APM零碎3、Web端 4、增加数据 5、启用数据6、剖析数据

近日，首届“寰球信息系统稳定性峰会”在京举办。此次大会由中国信息通信研究院和中国通信标准化协会领导，中国通信标准化协会大数据技术标准推动委员会和分布式稳定性实验室联结主办。当天，中国信通院也对《信息系统稳定性保障能力建设指南》作了解读。博睿数据作为《信息系统稳定性保障能力建设指南》的次要编撰者之一也缺席了峰会。 作为《建设指南》的次要编撰者之一，博睿数据为本次《建设指南》提供了规范制订、工具制订、能力要求制订等监控、告警、巡检以及拨测畛域的内容撑持，同时参加了信通院分布式系统稳定性实验室组织的行程卡稳定性保障工作，帮忙中国信通院总结稳定性保障相干实践经验、方法论的研究成果。 博睿数据高级金融总监刘颢示意：“在各行业数字化转型减速的背景下，时代呐喊新的零碎稳定性保障体系，2021年9月1日正式施行的《要害信息基础设施平安爱护条例》中对我国要害信息基础设施的稳定性保障工作提出了明确要求。技术方面，AIOps、混沌工程、全链路压测等新技术的呈现也为稳定性保障工作提供了新的思路。博睿数据十分荣幸参加由信通院主导的《信息系统稳定性保障能力建设指南》编写工作，助力信息系统稳定性的保障工作，助力数字化转型‘又快又稳’。” 同时，博睿数据也取得了分布式系统稳定性实验室成员单位证书。 博睿数据作为智能运维的领军者，自成立之初就致力于利用数据赋能IT运维，实现全业务链性能一体化治理，帮忙企业数字化业务高效衰弱倒退，有效应对企业采纳大规模简单分布式系统时传统运维伎俩有余等问题，显著进步IT零碎稳定性，助力企业数字化转型。 峰会现场，博睿数据北区技术总监张俊峰发表了题为《服务可达，体验为先—用户体验建设监控分享》的主题演讲，就博睿数据构建从代码到用户的性能管理体系方面的建设教训进行分享。 以后，随同着云计算、物联网、大数据、人工智能、5G等新兴技术的疾速倒退，数字经济正在减速到来。与此同时，数字化利用的爆发性增长，用户对利用体验提出了更高要求，新兴技术对市场的推动正在粗浅扭转着各行各业与数字经济的互动形式。同时，在疫情常态化的背景下，数字经济曾经成为我国国民经济倒退的要害组成部分，也是国家"十四五"布局中的重要一环。 张俊峰指出，“用户体验作为业务稳定性的要害一环起着无足轻重的作用。” 据统计机构 Statista的数据显示，寰球在客户体验治理中的相干技术投入逐年回升，企业的相干破费将会由2020年的4710 亿美元，攀升到2022年6410亿美元。 此外，在另一项数据考察中，这一趋势则更为显著：假如页面关上工夫慢1秒，那么就将导致用户量降落16%，访问量降落11%，整体转化率升高7%，页面超过3秒无响应，那么就有57%的用户放弃浏览。 从以上两组数据不难看出，用户体验是评判业务稳定性的重要指标。 2021年，博睿数据创新性的提出了数据链DNA概念，将DEM监控数据、NPM网络流量数据以及APM利用性能数据进行整合与剖析，通过前后贯通的TraceID，买通从客户端到主干网，到IDC网络，再到应用服务器之间的整个链路，构建从利用拓扑到网络拓扑的完满交融，打造欠缺的监控体系，确保服务可达和良好的用户体验。博睿数据数字体验治理（DEM），蕴含STM和RUM两种监控状态，涵盖了如PC、手机、WEB/WAP、APP、小程序等一系列利用。STM是无侵入的监测形式，或者说是模仿监测的模式。它次要依赖博睿数据的手机/PC终端监测网络而构建的模仿监测能力，也称拨测。它是非嵌码模式，主动式模仿用户申请，以工作配置的形式，随时随地进行相干利用的测试。同时通过监测，把握理解业务的可用性，理解企业在整个行业当中的位置，与竞品之间的差别等。 RUM是通过SDK/Js代码注入的形式，获取用户的实在体验数据，把握客户在WEB/WAP页面、手机APP以及小程序等业务拜访过程中的真实性能体验。博睿RUM产品通过用户会话性能，从用户应用业务的体验旅程登程，全面剖析各类性能指标对用户应用业务的影响。 同时，通过数据中台买通“云-管-边-端”，构建全面的监控体系，整合调用链（Traces）、指标（Metrics）、日志（Logs）数据，晋升云/云原生中的零碎可观测性，并联合数据的信息特色与业务流程、零碎体现、用户体验各环节的特点进行特色关联，实现全零碎观测、实时预警、分布式追踪以及代码级问题预警&解决。同时，利用机器学习、人工智能等技术一直晋升剖析预测的准确度，提供更具业务价值的智能告警能力，从而晋升用户业务在各个系统、各个阶段和各个区域的连续性，助力云原生时代服务可达。 将来，博睿数据也将继续打磨产品实力，同业界一道助力我国数字经济倒退“又快又稳”，推动寰球数据系统稳定性迈上新台阶。

火山引擎 APMPlus 是火山引擎利用开发套件 MARS 下的性能监控产品。咱们通过先进的数据采集与监控技术，为企业提供全链路的利用性能监控服务，助力企业晋升异样问题排查与解决的效率。 12月30日，咱们特地推出「APMPlus 企业助力口头」，为中小企业提供利用性能监控免费资源包。当初申请，有机会取得60天收费性能监控服务，最高可享6000万条事件量。 1.搀扶资源详情 助力资源包 —— 中小企业0元申请APMPlus资源包 APMPLus新用户可取得60天收费服务助力资源蕴含 App 监控、Web 监控各4000万条事件量Server 监控探针个数不限小程序监控、网络拨测不限量业余工程师在线答疑 邀请升级包 —— 邀请好友，最高减少两千万事件量 已申请技术助力资源包的用户，可通过邀请其余企业用户申请「APMPlus企业助力口头」，取得额定事件量；每胜利邀请一位新用户申请「助力资源包」，邀请人原账户可在 App 监控/Web 监控任一监控对象的事件量中新增500万条；每位用户最多可取得2000万条事件量升级包；*失效账户以新用户申请表单中「推荐人」栏填写信息为准 更多助力权利 可获火山引擎年度大会及企业&技术峰会邀约资格有机会携手火山引擎 MARS 独特打造行业案例火山引擎 MARS 下其余产品性能享优先体验资格火山引擎 MARS 行业沙龙席位邀请*如对本次流动有疑难或倡议，欢送私信「MARS小助手」交换 2.申请流程1、注册登录火山引擎 APMPlus 控制台； 2、实现认证并创立利用，点击控制台banner 申请资源包；申请用户需为火山引擎中小企业用户，提交表单后 工作人员会在1-3个工作日内实现审核，并开明对应账户资源包。 开明胜利后，咱们会通过微信/短信等模式告知您，请留神查收。 ✨ 分享流动，降级资源包

背景性能问题通常状况下，App的性能问题并不会间接导致其不能应用，却会潜在的影响用户体验。在泛滥App"内卷"的当下，一个不好的体验甚至能导致用户的散失。比方： •启动速度过慢•CPU占用率高导致的手机发热、耗电快•不明起因的闪退•…等等 预防和查看当然，作为一名开发者，在编写代码时就要做到防止一些性能问题的呈现。比方： •优化计算的复杂度从而缩小CPU占用率•编写单元测试•...等等 当然，善用工具能够高效地去监控App的性能问题，帮忙开发者及时修复产品体验上的缺点。市面上APM工具很多，因为笔者曾在我的项目中应用过U-App进行过利用信息的统计，在此就友盟U-APM来说一些应用体验。 U-APM应用体检集成参照官网平台的集成阐明，以iOS为例，这里做一个简述1.在U-APM创立利用，生成一个Appkey2.举荐应用CocoaPods来接入SDK pod 'UMCommon'3.pod 'UMDevice'4.pod ‘UMAPM’ 在 AppDelegate.m 文件中，增加如下 - (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions { [UMConfigure initWithAppkey:@"61276660870a7a610a4f67f5" channel:@""]; // Appkey在步骤1中生成 // channel字段为自定义渠道辨别，不填写则被默认为是"App store" return YES; }剖析后果1.解体剖析我仅仅是在我的项目中的首页手写了一个可被动触发的闪退Bug。剖析后果图解如下： 解体的曲线图对于开发者来说，算是一个兼顾的展现。重要的是，在页面下方的谬误列表中，能够查看某个谬误产生的次数，类型，影响的用户数。这很不便作为开发者在批改Bug时能疾速精确的判断优先级。另外，谬误都有独自的谬误明细页，大部分的Bug都能够被精准定位。 起初因为U-APM启动解体剖析的启发，我在我的项目内的启动办法中 -(BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions 即配置Appkey的前后，都别离写了闪退Bug，并临时用渠道名做了辨别。结果显示，在配置Appkey前产生的闪退，并不能被捕捉。 有人会问：那这不是必然的么？你都还没配置呢... 这也正是我想说的问题。因为在许多时候，咱们去配置一些第三方库时，因为集成办法过于简略，总是会很随便的依据官网教程去增加一行代码，并不去讲究它在我的项目代码中该当所处的最佳地位。因为这并不影响我的项目运行，这种细节也很容易被疏忽。我心愿在任何时候，开发者们都应该养成每一行代码在敲下去之前都尝试去思考的习惯。 2.卡顿剖析 卡顿的列表与明细也是和解体一样，能够查问和定位。并且可能标记（未解决、修复中、已疏忽、已修复）4种状态。 我还另外增加了卡顿告警打算，只有卡顿用户数占比超过5%，就会发邮件告诉我。它胜利的在一小时内触发告警信息并在邮件中揭示了我。 3.启动剖析我在启动时采纳了随机数去随机加快该项目标启动速度。默认首次启动/冷启动超过3秒为慢启动，热启动超过1秒为。这里以冷启动为例： 在剖析柱状图里也很好的展现了失常启动与慢启动的占比 4.内存剖析在OOM的剖析上，貌似对Android的反对更甚iOS。因为iOS的Jetsam机制，这里只剖析当程序内存超出限度时造成的一种非凡的Crash。包含异样的捕捉也不是全都能检测。 5.散布剖析平台均能在以上四个模块（解体、卡顿、慢启动、OOM异样）剖析中提供散布情况，包含设施散布、零碎散布、运营商散布、版本散布、页面散布、渠道散布、地区散布。 6.自定义配置模块 U-APM还提供了采集开关，须要在初始化前就在代码中配置好。 以上就是我体验的U-APM的全副性能。 还有一些我来不及体验的性能期待更多开发者去应用，比方“云真机”，"API上传符号表页面整体加载速度渲染"等等。 一些倡议分享在卡顿剖析与解体剖析的运营商模块中，呈现了一个剖析谬误。我应用的是电信宽带与电信卡，剖析后果却展现出我应用的是中国移动的运营商。当然对于这种问题，平台有另外的客服工单能够去提出，这里也不再赘述。（从过来应用其余友盟的产品来看，客服工单的反馈效率还是挺不错的） 另外值得一提的是，因为笔者在我的项目中曾经将开发语言齐全过渡到Swift，但在集成时，官网提醒Swift以后仅反对U-App统计，其余业务暂不反对Swift。我也是连夜创立一个OC我的项目去体验，并没有尝试在Swift我的项目中接入。而现如今，Swift已成iOS开发支流语言，心愿U-APM能在将来能全面反对Swift更加便当开发者。 当然，这不障碍它目前能够满足开发者们在OC我的项目中对性能监控的根本需要： •集成办法简略、迅速•追踪解体、卡顿的详细信息，轻松定位本源问题•剖析图解清晰明了，多状态方便管理•辨认设施类型（iPhone/iPad/iPod、操作系统版本、运营商类型），分类设施性能** 最初，我还是心愿，适当应用工具能够晋升开发效率，但也请不要过分依赖而忘了思考。

工具C:\Program Files\Java\jdk1.8.0_172\binjconsole.exejvisualvm.exetomcat配置批改tomcat的/bin/catalina.sh文件在其中“Execute The Requested Command”之前插入配置，内容如下：JAVA_OPTS="$JAVA_OPTS -Djava.rmi.server.hostname=11.12.86.102 -Dcom.sun.management.jmxremote"JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote.rmi.port=1099"JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote.port=1099"JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote.authenticate=false"JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote.ssl=false"重启tomcat服务双击关上jconsole.exe新建连贯-近程过程输出11.12.86.102:12345，点击确定若重启tomcat，需从新连贯双击关上jvisualvm.exe文件-增加JMX连贯，输出11.12.86.102:12345，勾选不要求SSL连贯，点击确定若重启tomcat，需敞开再从新关上jvisualvm.exedocker配置批改docker-compose_ara-api.yml配置文件version: "3"services: ids-8423: image: docker.xdja.com/itsca/itsca-ids-web:2.0.5.4 restart: always ports: - 8123:8080 - 8423:8423 - 5008:5008 - 1099:1099 environment: - TZ=Asia/Shanghai volumes: - /etc/localtime:/etc/localtime - /home/logs/ids_tomcat/:/usr/local/tomcat/logs/ - /home/logs/ids/:/home/logs/ - /home/xdja/conf/ccsa/ids/:/home/xdja/conf/ccsa/ids/ - /home/xdja/conf/ccsa/ids/tomcat/conf/:/usr/local/tomcat/conf/ - /home/xdja/conf/ccsa/ids/tomcat/bin/:/usr/local/tomcat/bin/ - /usr/local/yunhsmsdk/conf/:/usr/local/yunhsmsdk/conf/批改/home/xdja/conf/ccsa/ids/tomcat/bin/catalina.sh文件在其中“Execute The Requested Command”之前插入配置，内容如下：JAVA_OPTS="$JAVA_OPTS -Djava.rmi.server.hostname=11.12.86.102 -Dcom.sun.management.jmxremote"JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote.rmi.port=1099"JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote.port=1099"JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote.authenticate=false"JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote.ssl=false"进行原有docker容器并删除原有容器并从新创立容器docker-compose -f docker-compose_ara-api.yml up -d连贯形式见tomcat配置

问题我的 MySQL CPU 高了，看了一下 processlist，切实有太多行了，我要不要筹备辞职？ 试验MySQL CPU 飚高的起因有很多种，咱们先剖析一种最简略常见的。 还是先建个数据库： 还是依照之前试验 11 的技巧，疾速造一些数据： 重复执行最初一句 SQL： 上面来执行一条比拟坑的 SQL，让 CPU high 起来： 当初咱们忘掉之前做了什么，就来解决这个 CPU 高的问题。 先用 top -H 找到 CPU 高的线程，这里能够看到 CPU 高的线程始终是 17967 （如果 CPU 高的线程号始终在变，那可能不是单个 SQL 引起的 CPU 耗费，须要用其余办法来辅助剖析，办法咱们当前会介绍） 找到这个线程的工作： 能够看到很多有用的信息： 1. 能够看到 processlist 中对应这根线程的信息 2. 能够找到其在 processlist 中的 ID，这样咱们就能够下 kill 命令来完结 SQL 小贴士：应用 performance_schema 时，须要大家留神 MySQL 应用了多个线程编号，源自于不同视角： 1. PROCESSLIST_ID：在 processlist 中的编号，是使用者视角的编号，使用者能够间接用 kill 命令。2. THREAD_ID：是 MySQL 外部应用的线程编号，是 MySQL 外部视角的编号。3. THREAD_OS_ID：是在操作系统上，对应的线程编号，是操作系统视角的编号。大家应用时须要辨别好，不要 kill 错了 SQL。 ...

【转载请注明出处】：https://segmentfault.com/a/1190000023089382 SkyWalking 是观察性分析平台和应用性能管理系统。提供分布式追踪、服务网格遥测分析、度量聚合和可视化一体化解决方案。 特性： 多种监控手段，语言探针和service mesh多语言自动探针，Java，.NET Core和Node.JS轻量高效，不需要大数据模块化，UI、存储、集群管理多种机制可选支持告警优秀的可视化方案Skywalking 技术架构 整个系统分为三部分： agent：采集tracing（调用链数据）和metric（指标）信息并上报OAP：收集tracing和metric信息通过analysis core模块将数据放入持久化容器中（ES，H2（内存数据库），mysql等等），并进行二次统计和监控告警webapp：前后端分离，前端负责呈现，并将查询请求封装为graphQL提交给后端，后端通过ribbon做负载均衡转发给OAP集群，再将查询结果渲染展示Skywalking也提供了其他的一些特性： 配置重载：支持通过jvm参数覆写默认配置，支持动态配置管理集群管理：这个主要体现在OAP，通过集群部署分担数据上报的流量压力和二次计算的计算压力，同时集群也可以通过配置切换角色，分别面向数据采集（collector）和计算（aggregator，alarm），需要注意的是agent目前不支持多collector负载均衡，而是随机从集群中选择一个实例进行数据上报支持k8s和mesh支持数据容器的扩展，例如官方主推是ES，通过扩展接口，也可以实现插件去- - 支持其他的数据容器支持数据上报receiver的扩展，例如目前主要是支持gRPC接受agent的上报，但是也可以实现插件支持其他类型的数据上报（官方默认实现了对Zipkin，telemetry和envoy的支持）支持客户端采样和服务端采样，不过服务端采样最有意义官方制定了一个数据查询脚本规范：OAL（Observability Analysis Language），语法类似Linq，以简化数据查询扩展的工作量支持监控预警，通过OAL获取数据指标和阈值进行对比来触发告警，支持webhook扩展告警方式，支持统计周期的自定义，以及告警静默防止重复告警数据容器由于Skywalking并没有自己定制的数据容器或者使用多种数据容器增加复杂度，而是主要使用ElasticSearch（当然开源的基本上都是这样来保持简洁，例如Pinpoint也只使用了HBase），所以数据容器的特性以及自己数据结构基本上就限制了业务的上限，以ES为例： ES查询功能异常强大，在数据筛选方面碾压其他所有容器，在数据筛选潜力巨大（Skywalking默认的查询维度就比使用HBase的Pinpoint强很多）支持sharding分片和replicas数据备份，在高可用/高性能/大数据支持都非常好支持批量插入，高并发下的插入性能大大增强数据密度低，源于ES会提前构建大量的索引来优化搜索查询，这是查询功能强大和性能好的代价，但是链路跟踪往往有非常多的上下文需要记录，所以Skywalking把这些上下文二进制化然后通过Base64编码放入data_binary字段并且将字段标记为not_analyzed来避免进行预处理建立查询索引总体来说，Skywalking尽量使用ES在大数据和查询方面的优势，同时尽量减少ES数据密度低的劣势带来的影响，从目前来看，ES在调用链跟踪方面是不二的数据容器，而在数据指标方面，ES也能中规中矩的完成业务，虽然和时序数据库相比要弱一些，但在PB级以下的数据支持也不会有太大问题。 数据结构如果说数据容器决定了上限，那么数据结构则决定了实际到达的高度。Skywalking的数据结构主要为： 数据维度（ES索引为skywalking_*_inventory) service：服务instance：实例endpoint：接口network_adress：外部依赖数据内容 原始数据 调用链跟踪数据（调用链的trace信息，ES索引为skywalking_segment，Skywalking主要的数据消耗都在这里）指标（主要是jvm或者envoy的运行时指标，例如ES索引skywalking_instance_jvm_cpu）二次统计指标 指标（按维度/时间二次统计出来的例如pxx、sla等指标，例如ES索引skywalking_database_access_p75_month）数据库慢查询记录（数据库索引：skywalking_top_n_database_statement）关联关系（维度/指标之间的关联关系，ES索引为skywalking_relation)特别记录 告警信息（ES索引为skywalking_alarm_record）并发控制（ES索引为skywalking_register_lock）其中数量占比最大的就是调用链跟踪数据和各种指标，而这些数据均可以通过OAP设置过期时间，以降低历史数据的对磁盘占用和查询效率的影响。 调用链跟踪数据作为Skywalking的核心数据，调用链跟踪数据（skywalking_segment）基本上奠定了整个系统的基础，而如果要详细的了解调用链跟踪的话，就不得不提到openTracing。 openTracing基本上是目前开源调用链跟踪系统的一个事实标准，它制定了调用链跟踪的基本流程和基本的数据结构，同时也提供了各个语言的实现。如果用一张图来表现openTracing，则是如下： 其中： SpanContext：一个类似于MDC（Slfj)或者ThreadLocal的组件，负责整个调用链数据采集过程中的上下文保持和传递Trace：一次调用的完整记录 Span：一次调用中的某个节点/步骤，类似于一层堆栈信息，Trace是由多个Span组成，Span和Span之间也有父子或者并列的关系来标志这个节点/步骤在整个调用中的位置 Tag：节点/步骤中的关键信息Log：节点/步骤中的详细记录，例如异常时的异常堆栈Baggage：和SpanContext一样并不属于数据结构而是一种机制，主要用于跨Span或者跨实例的上下文传递，Baggage的数据更多是用于运行时，而不会进行持久化以一个Trace为例： 首先是外部请求调用A，然后A依次同步调用了B和C，而B被调用时会去同步调用D，C被调用的时候会依次同步调用E和F，F被调用的时候会通过异步调用G，G则会异步调用H，最终完成一次调用。 上图是通过Span之间的依赖关系来表现一个Trace，而在时间线上，则可以有如下的表达： 当然，如果是同步调用的话，父Span的时间占用是包括子Span的时间消耗的。 而落地到Skywalking中，我们以一条skywalking_segment的记录为例： { "trace_id": "52.70.15530767312125341", "endpoint_name": "Mysql/JDBI/Connection/commit", "latency": 0, "end_time": 1553076731212, "endpoint_id": 96142, "service_instance_id": 52, "version": 2, "start_time": 1553076731212, "data_binary": "CgwKCjRGnPvp5eikyxsSXhD///////////8BGMz62NSZLSDM+tjUmS0wju8FQChQAVgBYCF6DgoHZGIudHlwZRIDc3FsehcKC2RiLmluc3RhbmNlEghyaXNrZGF0YXoOCgxkYi5zdGF0ZW1lbnQYAiA0", "service_id": 2, "time_bucket": 20190320181211, "is_error": 0, "segment_id": "52.70.15530767312125340"}其中： trace_id：本次调用的唯一id，通过snowflake模式生成endpoint_name：被调用的接口latency：耗时end_time：结束时间戳endpoint_id：被调用的接口的唯一idservice_instance_id：被调用的实例的唯一idversion：本数据结构的版本号start_time：开始时间戳data_binary：里面保存了本次调用的所有Span的数据，序列化并用Base64编码，不会进行分析和用于查询service_id：服务的唯一idtime_bucket：调用所处的时段is_error：是否失败segment_id：数据本身的唯一id，类似于主键，通过snowflake模式生成这里可以看到，目前Skywalking虽然相较于Pinpoint来说查询的维度要多一些，但是也很有限，而且除了endPoint，并没有和业务有关联的字段，只能通过时间/服务/实例/接口/成功标志/耗时来进行非业务相关的查询，如果后续要增强业务相关的搜索查询的话，应该还需要增加一些用于保存动态内容（如messageId，orderId等业务关键字）的字段用于快速定位 指标指标数据相对于Tracing则要简单得多了，一般来说就是指标标志、时间戳、指标值，而Skywalking中的指标有两种：一种是采集的原始指标值，例如jvm的各种运行时指标（例如cpu消耗、内存结构、GC信息等）；一种是各种二次统计指标（例如tp性能指标、SLA等，当然也有为了便于查询的更高时间维度的指标，例如基于分钟、小时、天、周、月） ...