一、Portal功能对象
Skywalking（简称SW）有如下菜单和功能：
Dashboard（仪表界面）
监控实例的数量信息
请求热力图（反映：请求数量和响应时间）
应用平均告警数量
应用吞吐量（cpm，每分钟调用次数）
最慢的服务Top10
Topology（拓扑界面）
用户、应用、各种中间件的调用关系图
应用之间的调用吞吐量(cpm)和平均响应时间(rt)
应用的服务可用率（SLA）
Application（应用界面）
应用基本信息（ip、host等）
应用调用关系图
历史实例进程列表
实例进程的平均吞吐量
实例进程的平均响应时间
实例进程的CPU、内存、JVM情况
实例进程的请求量走势图
应用的慢服务Top10
Service（服务界面）
服务平均吞吐量（cpm）、平均响应时间（RT）、可用率（SLA）
服务依赖关系图以及调用的平均吞吐量和响应时间
Alarm（告警界面）
显示服务器、应用、服务的告警信息
Trace（链路追踪界面）
支持按各种条件查询调用
查看调用的span链路信息（时序图）
可以看到各span的耗时、异常和其他信息（不同的span支持不同的信息，例如DB类型的，可以打印出sql）
部分截图
sw-portal
sw-trace
sw-app
Pinpoint（简称PP）有如下菜单和功能：
主仪表界面
应用调用关系图
请求热力点图和柱状图（反映：请求数量和响应时间）
时间段内总的调用成功、失败次数
响应时间统计图
支持按时间选择查看调用列表（跳到链路追踪页面）
链路追踪界面
查看调用的span链路信息（时序图）
可以看到各span的耗时和类名、方法名（如果DB操作，可以打印出sql和参数）
检阅界面（inspector）
看不太懂，只知道有非常详细的JVM监控信息
部分截图
pp-portal
pp-trace
二、个人使用感受和优缺点对比
Skywalking的不足：
1、针对单个应用的请求热力图，只能看到请求数量，看不到响应时间分布。
2、应用界面，不能直观看到时间段内的请求总数量及错误数量。
3、JVM的监控信息，SW没有PP全面。
4、调用链信息，SW默认只显示入口和组件(如MySQL)调用处的信息，而PP还会显示SpringBean方法的调用信息，更丰富实用，当然SW也可以开启更详细的信息，但是会显示Bean内部方法的所有调用，显得冗余（例如 A调B调C，显示B和C被调用的入口方法就可以了，不用显示B调用自己内部方法的过程）。
5、SW更新快，BUG较多，值得优化和改进的地方也很多，虽然功能强，但是用起来不一定顺手和实用，还需要时间斟酌和打磨。相对而言，PP功能成熟，功能虽然少，但是都比较经典，用起来比较顺手。
6、SW调用链里面DB类型只能看到SQL，看不到参数化SQL的传值，而PP可以。
7、PP支持实时监控、页面实时刷新，而SW不支持。
Pinpoint的不足：
1、不支持异步执行的调用链追踪（比如多线程、MQ），而SW通过注解可以支持。
2、功能比较少，例如缺少平均响应、平均吞吐量等数据，缺少慢服务的统计。
3、调用链信息，可以扩展和丰富的程度，要低于SW（SW可以通过注解扩展）。
另外：
对应用性能的影响，实测两者差不多，SW稍微好一些（吞吐量比PP大概高5%——我们做过单个span的性能测试，具体数据就不贴出来了）。
实时告警通知，暂未测试，我个人希望有 服务异常、JVM异常、慢服务、高负载等的订阅和通知功能，然而貌似这两个APM都没有很直观的展示出有这方面的能力。
总的来说：
PP相比后起之秀SW，要更稳定、易用，而且并没有明显短处；
SW号称的异步调用链追踪（是有代码侵入性的），我认为PP只要稍加改进也可以支持；
小公司，推荐用PP，等SW成熟之后再说吧；
有二次开发实力的公司，需进一步对比两者的可扩展性、二次开发效率，选择一个更能满足自己定制需求的APM。