ELK 线上事故处理：Filebeat 如何跳过积压日志
引言在维护 ELK (Elasticsearch, Logstash, Kibana) 日志系统时，一个常见的线上事故是下游的 Elasticsearch 因磁盘空间耗尽而无法接收新的日志。这会导致上游的 Filebeat 和 Logstash 出现数据积压。当磁盘问题解决后，我们通常不希望重新处理这些积压的、可能已经失去时效性的日志，而是希望从当前时间点开始恢复日志采集。本文将详细介绍如何处理此类事故，核心在于让 Filebeat 跳过积压的日志。 事故场景：Elasticsearch 磁盘写满导致日志积压问题描述： 日志系统链路为 Filebeat -> Logstash -> Elasticsearch。Elasticsearch 因磁盘满了，导致服务中断两小时。现在磁盘空间已清理，服务恢复，但 Filebeat 开始从两小时前中断的位置重新发送日志。我们希望丢弃这两个小时的积压日志，直接从当前时间开始采集。 核心解决方案：重置 Filebeat 的读取位置问题的关键在于 Filebeat 会持久化记录每个日志文件的读取进度（offset）。即使下游服务中断，F...
Node.js 整合 ELK + Zipkin，输出日志到 Logstash
依赖Web 框架（要求 2.7+）1"koa": "^2.13.1" 日志（基于 TCP 协议）参考：log4js-logstash-tcp 12"log4js": "^3.0.5","log4js-logstash-tcp": "^2.0.0" Zipkin参考：zipkin-instrumentation-koa 12"zipkin-instrumentation-koa": "^0.22.0","zipkin-transport-http": "^0.22.0" 代码（Zipkin 部分）123456789101112// 下游（上游略，上游改 localServiceName 即可）const { Tracer, BatchRecorder, ExplicitContext } = require('zipkin');const ...
公告