php探针怎么绑定服务器，有没有快速服务器环境的方法？
推荐一款神器应该可以帮到你，云帮手是一款功能强大的全面集中化管理云主机软件。不仅是兼容Linux系统，Windows也是可以用的。实际上使用功能还是挺不错的，因为功能全面且安装简单，基本都是傻瓜式一键搞定，中间添加云主机的话，首次要添加探针，以后就基本可以在面板上操作了，这个是挺方便的。主流云那几个基本我都试过没问题，系统也没有问题，这个倒是挺省心的，不会说存在什么云商的或者系统的就用不了，又要另外找软件。大致功能如下：
1.批量管理多台云主机；
2.兼容性强大，兼容市面基本所有的云商云主机，兼容操作系统；
3.操作简单，可视化界面预览资源、一键修复、一键部署；
4. 可以远程登录云主机FTP桌面，处理云主机上的文件；
5.监控和，资源还有告警功能，这个是挺好的，不用盯着看；
6.系统修复功能，这个是挺实用也比较必须的；
7.免费使用。总得来说功能还是挺全的，不存在需要又要另外找软件的尴尬，一个云帮手软件基本满足了所有需求。
还是免费使用，上官网下载注册就可以用了，下载地址：https://www.cloudx.cn/?utm_source=wk-xie
pinpoint和skywalking区别？
skywalking与pinpoint全链路追踪方案对比
由于公司目前有200多微服务,微服务之间的调用关系错综复杂,调用关系人工维护基本不可能实现,需要调研一套全链路追踪方案,初步调研之后选取了skywalking和pinpoint进行对比;
选取skywalking和pinpoint对比的原因是:两者都使用探针(agent)技术进行信息采集,集成到项目内时不用修改业务代码,避免造成后期难以推进的问题;
以下是进行的一些维度的对比,主要从功能性需求和非功能性需求方面做参考:
功能性需求对比
skywalking pinpoint 备注
支持协议
Java, C#, PHP, Node.js
java,php
ui
两种ui相类似,sw服务信息加载速度会快一些
扩展性
都可自定义plugin,使用探针,都可以进行扩展,据说sk扩展性更好
存储
支持各种类型存储,es,mysql,h2等
只支持hbase
警告
config/alarm-settings.xml设置警告规则
需要额外引入mysql发送警告
jvm监控
都包含,pinpoint相对更全面一些,从页面查看比较类似
跟踪粒度
需要使用对应的插件,可以到方法级,展示sql,每个方法调用的时间
服务监控
skywalking支持的维度有：CPU使用率，SLA，RT，CPM（Call Per Minutes）
Pinpoint支持的维度有：CPU使用率，Open File Descriptor，数据源，活动线程数，RT，TPS。
pinpoint更多
过滤追踪
都是用ant风格,sw有对应的插件,更灵活
性能损耗
性能损耗sw少于pinpoint
支持中间件
1.支持开源web容器
2.RPC框架支持更多
3.mq,多支持rocketMQ
4.不支持mssql和mariadb
5.redis支持Jedis，Redisson，Lettuce
1.支持几乎所有web容器,
2.少于sw
4.RDBMS/nosql,好于sw
5.不支持redisson
6.不支持log4j2
公司当前使用的resin
和karaf容器两个是否支持
对代码的侵入性
无侵入
无侵入
非功能性需求对比
skywalking
pinpoint
是否需要修改代码
不需要
不需要
相关文档
官网文档比较全,支持中文,apache支持
英文文档
社区
社区活跃,发起人是中国人
韩国人开发,活跃程度类似
发布方式
使用jar包,start.sh脚本启动
使用war包,依赖web容器
github start 数 9.1k 8.8k
skywalking对国产软件的支持好于Pinpoint;
Pinpoint的优势在于：追踪数据粒度非常细、功能强大的用户界面，以及使用HBase作为存储带来的海量存储能力。
skywalking的优势在于：非常活跃的中文社区，支持多种语言的探针，对国产开源软件非常全面的支持，以及使用es作为底层存储带来的强大的检索能力，并且skywalking的扩展性以及定制化要更优于Pinpoint
从整体上来讲,在进行演示和讨论的时候,大家普遍认为,skywalking的界面比较现代化一些,pinpoint的功能更为强大;
其他一些方面提出的问题,待近期补充:
后边需要继续调研的点:
1.对公司现有技术栈,两种方案的支持情况;
2.扩展性及如何进行扩展,扩展之后可以做哪些内容;
3.采样率如何配置
4.保存时间
5.采样的策略
6.agent开发方法
7.数据是否有遵循标准
8.nginx是否支持
另外,再讨论的过程中,提到了一些问题,
有同事提出是否可以用这个工具定位线上的具体都某一次请求的问题?
答案是否定的,因为全链路追踪的定位是展示整体服务调用的拓扑图,能够从宏观描述服务请求链路中哪个环节比较慢,给开发者提供优化程序的一个方向;
对于性能消耗,大家也有一些不同的看法,有的业务方,对于20%的性能损耗是不敏感的,但是对于当前线上已经负载比较高,且经常有线上问题的系统,还需要性能消耗方面的调研;