应用监控预警&服务链路跟踪-Pinpoint介绍

需求背景

1，在分布式环境中，服务调用服务愈来愈频繁，当你想跟踪一次请求错误来源或者哪一个api步骤缓慢时，估计你想到的是，每一个服务里面打印日志，并且带上本应用里面的先后耗时，全局惟一的跟踪id，而后把这个全局跟踪Id传递到下一个被调用的应用中去，这样才能根据这个全局跟踪Id，查询从网关开始到多个交易系统的服务器上的日志。看起来是否是很繁琐？有没有工具帮你搞定？

2，生产上常常出现JVM 内存溢出OOM的状况或者链接池不够用致使接口缓慢，有没有想过监控你的应用jvm的内存和数据库链接数，并且当他们的值超过必定阈值的时候进行告警，发送短信给你，让你提早处理这些危机？而不是过后被客户反映出问题？有没有工具帮你搞定这个事情？

3，应用这么多？我如何知道当前哪些应用之间存在调用关系？最好是来个拓扑图来展现！

4，个人应用有多个实例部署，能不能把这个应用几个实例的监控数据归集起来，让我对整个应用的综合状况（接口响应时间，数据库链接数使用状况，内存使用，目前活动的调用事务数等）有个全局的了解？

 

分布式系统和监控告警系统发展到目前，已经有不少大公司走在了前面，并且为咱们这些中小公司贡献了大量的开源系统，pinpoint是一款很是优秀的应用性能监控工具，对比skywalking和cat,zipkin等，综合功能上更胜一筹，系统性能，可用性，扩展性，易用性，维护性方面都很是棒。

 

pinpoint部署架构

 

 

 

pinpoint1.7.3重要特性

易用性

a,无需应用修改任何应用代码，轻松集成。采用Java字节码加强技术，自动注入跟踪代码到你的应用中。

zipkin和cat都是须要本身配置插件到你的代码中，有的须要本身写跟踪代码。skywalking采用字节码加强技术。

b,支持众多框架，中间件的跟踪

• JDK 6+
• Tomcat 6/7/8, Jetty 8/9, JBoss EAP 6, Resin 4, Websphere 6/7/8, Vertx 3.3/3.4/3.5
• Spring, Spring Boot (Embedded Tomcat, Jetty)
• Apache HTTP Client 3.x/4.x, JDK HttpConnector, GoogleHttpClient, OkHttpClient, NingAsyncHttpClient
• Thrift Client, Thrift Service, DUBBO PROVIDER, DUBBO CONSUMER
• ActiveMQ, RabbitMQ
• MySQL, Oracle, MSSQL, CUBRID, POSTGRESQL, MARIA
• Arcus, Memcached, Redis, CASSANDRA
• iBATIS, MyBatis
• DBCP, DBCP2, HIKARICP
• gson, Jackson, Json Lib
• log4j, Logback

只须要修改pinpontagent配置文件，便可实现上面这些框架的方法跟踪，zipkin跟spring cloud整合只能跟踪到不多部分方法的耗时，cat须要本身写跟踪代码。skywalking支持上述框架跟踪，这点作的比pinpoint还多。

c，强大的应用拓扑图，监控数据走势图（包括单jvm和应用集群走势），调用链路展现图（包括你的sql,调用者Ip,每一个函数的耗时），告警规则配置。

skywaling5目前不支持告警，集群监控数据走势图；zipkin只有调用链路展现；cat展现图标听说丰富，没具体使用过。

 

高性能（从设计上对比）

传输：pinpoint使用udp,tcp上送数据，采用thirft序列化数据，性能作了优化；skywalking采用grpc和rest两种方式上送数据，本质上是http协议；zipkin使用Http发送数据。udp和tcp性能优于http实现。

存储：pinpoint使用hbase写入，作了分区和数据老化设置，能充分享受hbase分布式写入并发的能力。skywalking使用elasticsearch存储，zipkin支持Cassandra,MySQL，写入性能上hbase介于Cassandra和elasticsearch之间，hbase跟cassandra相差不大，二者比elasticsearch写入快不少倍；查询上elasticsearch要优于hbase。

pinpoint使用flink预统计数据来优化查询性能，flink做为目前最早进的流式处理框架，性能优秀，一致性保证，轻量级容错。

skywalking使用storm/spark stream来作统计，不过此功能在5版本中拿掉了。

综合对比，pinpoint的写入性能优秀，查询性能尚可。

 

扩展性

从设计上能够看出，部署多个collector是能够线性扩容的，存储方面Hbase的扩展性很是好，并且hbase本身作数据清理。

 

维护性

pinpoint提供完整的数据库维护脚本，包括建立hbase表和清除hbase表。发现数据空间不够使用了，可随时使用清除Hbase表的脚本进行清理，再使用建立脚本进行恢复表结构。

 

可用性

在任何状况下，你关闭collector或者hbase，都不影响咱们的业务应用的正常使用。

 

Pinpoint WEB UI操做指南

若是你们英文ok，请直接访问http://naver.github.io/pinpoint/1.7.3/main.html；不须要听我继续了

若是不是很好，下面会对UI上的经常使用功能作介绍。

首页操做

 

首页上面能够选择一个应用进行查看拓扑图，拓扑的深度，时间范围过滤，只有在特色时间范围的应用之间发生调用了，才会出如今应用拓扑图中。

 

在拓扑图中点击一个应用，在右边会显示这个应用的api调用响应时间状况，使用鼠标点击，画出一个方框，就能够把方框里面rpc的链路展现在新的页面中。

 

 

 

链路展现，能够查看到调用链上的耗时，调用的api，Ip地址，执行的sql语句等。

 

应用监控

从首页点击Inspector进去，展现当前应用集群的监控走势图，也能够单独看一个实例的走势。

 

应用告警设置

在首页拓扑图，或者应用监控页面，点击右上角的齿轮图标，便可打开告警设置界面

设置告警消息发送的用户：

 

设置告警规则，监控的应用，监控的指标超过某个阈值，发送什么类型的消息，发送给哪一个用户组

 

 

 

告警规则

• SLOW COUNT / 慢请求数

  当应用发出的慢请求数量超过配置阈值时触发。

• SLOW RATE / 慢请求比例

  当应用发出的慢请求百分比超过配置阈值时触发。

• ERROR COUNT / 请求失败数

  当应用发出的失败请求数量超过配置阈值时触发。

• ERROR RATE / 请求失败率

  当应用发出的失败请求百分比超过配置阈值时触发。

• TOTAL COUNT / 总数量

  当应用发出的全部请求数量超过配置阈值时触发。

以上规则中，请求是当前应用发送出去的，当前应用是请求的发起者。 如下规则中，请求是发送给当前应用的，当前应用是请求的接收者。

• SLOW COUNT TO CALLEE / 被调用的慢请求数量

  当发送给应用的慢请求数量超过配置阈值时触发。

• SLOW RATE TO CALLEE / 被调用的慢请求比例

  当发送给应用的慢请求百分比超过配置阈值时触发。

• ERROR COUNT TO CALLEE / 被调用的请求错误数

  当发送给应用的请求失败数量超过配置阈值时触发。

• ERROR RATE TO CALLEE / 被调用的请求错误率

  当发送给应用的请求失败百分比超过配置阈值时触发。

• TOTAL COUNT TO CALLEE / 被调用的总数量

  当发送给应用的全部请求数量超过配置阈值时触发。

下面两条规则和请求无关，只涉及到应用的状态

• HEAP USAGE RATE / 堆内存使用率

  当应用的堆内存使用率超过配置阈值时触发。

• JVM CPU USAGE RATE / JVM CPU使用率

  当应用的CPU使用率超过配置阈值时触发。