2019独角兽企业重金招聘Python工程师标准>>> 
需求背景
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使用率超过配置阈值时触发。