自从实现微服务化后，我们碰到了很多问题。其中最大的问题就是如何排查故障，服务化后的接口通常会依赖多个服务，依赖接口的缓慢会直接影响接口的服务质量。
这种依赖导致的缓慢情况在线上很常见，但是并不好排查，究其原因是线上都是通过日志进行跟踪的大量的日志开发人员并不是很直观，且有的公司开发人员是看不到线上具体执行情况。一般来说线上这些小概率故障代表着系统的隐患，当流量增大后这些隐患会被放大甚至直接导致线上大规模故障，为了避免类似的事情我们需要做很多事情，最直观的就是用分布式跟踪系统去统计分析。
我们常见到大牛在讲线上性能怎么优化，怎么提高性能，其实有个重要的还环节他们并没有提及，他们是如何发现低概率故障？分布式跟踪系统在大型互联网公司是很常见，但是中小型公司是没有技术实力去实现这个系统的。而从我们角度来看即使流量很小但是对于公司仍旧很重要的系统是我们需要强化的，能够发现问题才能解决问题这是我一直贯彻的宗旨。
分布式跟踪系统具体的实现是有一定技术难度的，要实现性能的捕捉、日志写入、日志收集整理、日志传输、日志存储、日志索引、日志实时分析、最后合并展示，要求系统能够应对大流量系统的冲击。如每次请求每个接口产生1k的日志，那么QPS
2000 的服务器就会产生2M的日志，如果是一次请求依赖5个接口那么就是每秒10M的日志，当线上业务更复杂流量更大的时候，这个数值还会增加。
大型互联网公司有很多分布式跟踪系统，能够承受几十亿流量，但是对于小公司来说这种架构负担很大，其中很多环节如依赖分布式消息系统、分布式存储、分布式计算，光这几个至少会使用6台以上服务器，对于一般小型公司性价比不高。
这次我们开源的分布式跟踪是有两款，一款是给中小型互联网公司使用的单机版他可以支撑PV
2000w的业务系统（如支付系统）。另外还有一款支持分布式几十亿PV的分布式跟踪系统。目前刚刚开放Fiery单机版（https://github.com/weiboad/fiery）这个版本是针对中小型企业使用而设计的，整个项目就是一个Jar包开箱即用，只要有Java8
runtime即可直接使用，当然系统需要简单的做一个埋点工作。而C++分布式版本依赖东西较多对运维人员有一定能力要求，后续看单机版情况后续放出。这些完全开源内部有敏感数据的核心交易系统也完全可以使用。
目前市面上是存在着多个方式的分布式跟踪，有的是公司自己内部使用，有的是小规模免费大规模付费的服务。常见的分布式跟踪是通过统计方式去记录每一个Block的性能情况。目前我们提供的方式和市面的方式并不完全一样，我们通过不断的实验做了大量的简化，只保留我们认为真正实用的功能，我们将系统设计为关键系统分布式监控。如支付系统、交易系统。
我们记录了每个请求的具体情况、返回值、具体的性能等信息，通过表格分析可以快速的发现线上依赖接口性能（第三方或者未埋点的接口性能统计）、做埋点的接口也独立做了性能排行分析。通过查看分析表格后我们可以快速的找到最慢的接口请求回放，以此分析线上性能缓慢的原因。通过实践我们发现很多情况下都是PHP依赖的数据资源缓慢导致了php接口性能不佳。所以埋点的重点都是在依赖资源上。其他信息用户可以根据自己需要增加，这样可以减少大量无用日志，可以更节俭一些。
这次开源的Fiery主要有三个部分、PHP侵入式埋点库、精简的日志监控推送模块、服务端。这三个就实现了一个PV2000w以下的网站分布式跟踪。
埋点库会在入口产生Traceid（UUID）这个Traceid内隐藏着入口服务器的IP地址，请求时间，所有后续产生的日志都会用这个UUID作为标示。在日志收集后所有相关日志都会按这个UUID进行存储。埋点库会在运行时负责接收其他请求发来的Traceid和发送产生维护RPCID，RPCID是一个有层级的计数器，通过它我们可以将调用关系次序及层级直接进行还原展示给开发人员。另外在PHP运行过程中如果产生Exception也会被埋点库捕获记录下来，供服务端进行去重统计。最后会将这些日志落地到服务器本地磁盘，由于一些原因多个PHP进程同时写一个文件的时候偶尔会出现乱序情况，我们现在是按进程ID加上项目名称作为文件名进行落地的。
Fiery日志抓取传输我们实现了一个简单的版本，这么做是为了简化使用运维人员的工作，目前确实有很多开源提供类似的功能、但是需要依赖其他环境，这对于运维来说有一定负担。我们还有个实验性的PHP的日志抓取传输服务，但是还是实验的功能，预计会有一定的缺陷各位用户可以参与调试改进。
Fiery的服务端我们做了很多工作，内置了Lucene和Rocksdb，分别对请求进行索引和存储。并且做了一些内存统计的工作，目前我们的统计维度是固定的，只针对本地接口，依赖接口，MySQL、Curl的响应情况进行统计、另外提供调用关系回放、错误日志警报去重统计。通过这些功能可以快速的发现线上关键点的性能故障，系统异常。目前只是单机版，后续需要我可以将它进一步扩展成更简单的分布式方式。
以上这些服务并不仅仅服务于线上，目前我们内部还用他做了很多有意思的尝试，如QA测试的环境接入一套，测试完毕后把故障接口产生的Traceid直接发给开发，开发能够通过Traceid找到此次请求所有调用经过、参数、返回情况、性能都可以直观看到方便分析.上线之前的单元测试也可以这么做。前段时间我发微博推广Fiery的时候有人还提到可以用它做蜜罐，查看黑客入侵的过程，具体细节。后续功能还待大家继续发掘和改进，这个系统就是为了填补PHP生态空缺而做的。
