共计 2493 个字符，预计需要花费 7 分钟才能阅读完成。
起源：_https://www.cnblogs.com/dengb…
本文次要介绍怎么应用 ELK Stack 帮忙咱们打造一个撑持起日产 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 创立索引。
- 顶峰时段按业务类型的权重指标、日志等级指标、每个服务在一个时段内日志最大限度量指标、时间段指标等动静荡涤过滤日志。
- 依据不同的时间段动静膨胀工夫窗口。
- 日志索引生成规定：按服务生成的日志文件规定生成对应的 index，比方：某个服务日志分为：debug、info、error、xx_keyword，那么生成的索引也是 debug、info、error、xx_keyword 加日期作后缀。这样做的目标是为研发以原习惯性地去应用日志。
⑦可视化界面咱们次要应用 Grafana，它反对的泛滥数据源中，其中就有普罗米修斯和 Elasticsearch，与普罗米修斯堪称是无缝对接。而 Kibana 咱们次要用于 APM 的可视剖析。
日志可视化
