1、日志文件采集端我们使用filebeat,运维通过我们的后台管理界面化配置，每个机器对应一个filebeat，每个filebeat日志对应的topic可以是一对一、多对一，根据日常的日志量配置不同的策略。

除了采集业务服务日志外，我们还收集了mysql的慢查询日志和错误日志,还有别的第三方服务日志，如:nginx等。最后结合我们的自动化发布平台，自动发布并启动每一个filebeat进程。

2、调用栈、链路、进程监控指标我们使用的代理方式：Elastic APM，这样对于业务侧的程序无需任何改动。对于已经在运营中的业务系统来说，为了加入监控而需要改动代码，那是不可取的，也是无法接受的。Elastic APM可以帮我们收集http接口的调用链路、内部方法调用栈、使用的sql、进程的cpu、内存使用指标等。

可能有人会有疑问，用了Elastic APM，其它日志基本都可以不用采集了。还要用filebeat干嘛？

是的，Elastic APM采集的信息确实能帮我们定位80%以上的问题，但是它不是所有的语言都支持的比如：C。

其二、它无法帮你采集你想要的非error日志和所谓的关键日志，比如：某个接口调用时出了错，你想看出错时间点的前后日志；还有打印业务相关方便做分析的日志。

其三、自定义的业务异常，该异常属于非系统异常，属于业务范畴，APM会把这类异常当成系统异常上报，如果你后面对系统异常做告警，那这些异常将会干扰告警的准确度，你也不能去过滤业务异常，因为自定义的业务异常种类也不少。

3、同时我们对agent进行了二开。采集更详细的gc、堆栈、内存、线程信息。

4、服务器采集我们采用普罗米修斯。

5、由于我们是saas服务化，服务N多，很多的服务日志做不到统一规范化，这也跟历史遗留问题有关，一个与业务系统无关的系统去间接或直接地去对接已有的业务系统，为了适配自己而让其更改代码，那是推不动的。牛逼的设计是让自己去兼容别人，把对方当成攻击自己的对象。