如何打造一个TB级微服务海量日志监控平台.docxVIP

如何打造一个TB级微服务海量日志监控平台 在每个服务节点上埋点，实时采集相关日志。 统一日志收集服务、过滤、清洗日志后生成可视化界面、告警功能。 我们的架构 ①日志文件采集端我们使用 FileBeat，运维通过我们的后台管理界面化配置，每个机器对应一个 FileBeat，每个 FileBeat日志对应的 Topic 可以是一对一、多对一，依据日常的日志量配置不同的策略。 除了采集业务服务日志外，我们还收集了 MySQL 的慢查询日志和错误日志，还有别的第三方服务日志，如：Nginx 等。 最终结合我们的自动化发布平台，自动发布并启动每一个 FileBeat 进程。 ②调用栈、链路、进程监控目标我们使用的代理方式：Elastic APM，这样对于业务侧的程序无需任何改动。 对于已经在运营中的业务系统来说，为了加入监控而需要改动代码，那是不行取的，也是无法接受的。 Elastic APM 可以帮我们收集 HTTP 接口的调用链路、内部方法调用栈、使用的SQL、进程的 CPU、内存使用目标等。 可能有人会有疑问，用了 Elastic APM，其它日志基本都可以不用采集了。还要用 FileBeat 干嘛？ 是的，Elastic APM 采集的信息的确能帮我们定位 80% 以上的问题，但是它不是全部的言语都支持的比如：C。 其二、它无法帮你采集你想要的非 Error 日志和所谓的关键日志，比如：某个接口调用时出了错，你想看出错时间点的前后日志；还有打印业务相关便利做分析的日志。 其三、自定义的业务特别，该特别属于非系统特别，属于业务范畴，APM 会把这类特别当成系统特别上报。 假如你后面对系统特别做告警，那这些特别将会干扰告警的精确?????度，你也不能去过滤业务特别，由于自定义的业务特别品种也不少。 ③同时我们对 Agent 进行了二开。采集更具体的 GC、堆栈、内存、线程信息。 ④服务器采集我们接受普罗米修斯。 ⑤由于我们是 Saas 服务化，服务 N 多，很多的服务日志做不到统一规范化，这也跟历史遗留问题有关，一个与业务系统无关的系统去间接或直接地去对接已有的业务系统，为了适配本人而让其更改代码，那是推不动的。 牛逼的设计是让本人去兼容别人，把对方当成攻击本人的对象。很多日志是没有意义的，比如：开发过程中为了便利排查跟踪问题，在 if else 里打印只是有标志性的日志，代表是走了 if 代码块还是 else 代码块。 甚至有些服务还打印着 Debug 级别的日志。在成本、资源的有限条件下，全部全部的日志是不现实的，即便资源允许，一年下来将是一比很大的开销。 所以我们接受了过滤、清洗、动态调整日志优先级采集等方案。首先把日志全量采集到 Kafka 集群中，设定一个很短的有效期。 我们目前设置的是一个小时，一个小时的数据量，我们的资源临时还能接受。 ⑥Log Streams 是我们的日志过滤、清洗的流处理服务。为什么还要 ETL 过滤器呢？ 由于我们的日志服务资源有限，但不对啊，原来的日志分散在各各服务的本地存储介质上也是需要资源的哈。 现在我们也只是汇合而已哈，收集上来后，原来在各服务上的资源就可以释放掉日志占用的部分资源了呀。 没错，这样算的确是把原来在各服务上的资源化分到了日志服务资源上来而已，并没有添加资源。 不过这只是理论上的，在线上的服务，资源扩大简约，收缩就没那么简约了，实施起来极其困难。 所以短时间内是不行能在各服务上使用的日志资源化分到日志服务上来的。这样的话，日志服务的资源就是当前全部服务日志使用资源的量。 随存储的时间越长，资源消耗越大。假如处理一个非业务或非处理不行的问题，在短时间内需要投入的成本大于处理当前问题所带来收益的话，我想，在资金有限的情况下，没有哪个领导、公司情愿接受的方案。 所以从成本上考虑，我们在 Log Streams 服务引入了过滤器，过滤没有价值的日志数据，从而削减了日志服务使用的资源成本。 技术我们接受 Kafka Streams 作为 ETL 流处理。通过界面化配置实现动态过滤清洗的规章。 或许规章如下： 界面化配置日志采集。默认 Error 级别的日志全量采集。 以错误时间点为中心，在流处理中开窗，辐射上下可配的 N 时间点采集非 Error 级别日志，默认只采 info 级别。 每个服务可配 100 个关键日志，默认关键日志全量采集。 在慢 SQL 的基础上，按业务分类配置不同的耗时再次过滤。 按业务需求实时统计业务 SQL，比如：高峰期阶段，统计一小时内同类业务 SQL 的查询频率。可为 DBA 供应优化数据库的依据，如按查询的 SQL 创建索引。 高峰时段按业务类型的权重目标、日志等级目标、每个服务在一个时段内日志最大限制量目标、时间段目标等动态清洗过滤日志。 依据不同的时间