记录日志系统的安装-部署-配置-使用文档(5)
ELK-ALERTING - 告警功能前提：使用告警功能必须配置 SSL，配置安全性可以站内搜索 [记录日志系统的安装-部署-配置-使用文档(4)] Kibana 本身提供了告警功能，左菜单位位置（7.14.0），但是免费支持的告警操作只有写入索引和写入 Kibana 日志，其他功能需要收费（19 美元一个月）。网上提到一个方案 sentinl，但是似乎截止到 2021-08-20 仅支持到 Kibana 7.6.1 的版本。 创建连接器（以邮件和 webhook 举例）邮件 企业微信邮箱发送方主机： IP：smtp.exmail.qq.com Port：465 QQ 邮箱发送方主机： IP：smtp.qq.com Port：465 / 587 记得在账户那里开启 SMTP，然后密码是授权码 测试，可以有多个接收方 Webhook 飞书 webhook 企业微信群机器人 发个测试 123456789{ "msg_type": "text", "content&qu...
记录下 Logstash 的配置加解释
Logstash 配置说明logstash.conf（完整配置加注释）12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182838485868788899091input { beats { port => 5044 #ssl => true #ssl_certificate => "/etc/logstash/logstash.crt" #ssl_key => "/etc/logstash/logstash.key" # 1. SSL 详情可参考相关文档 }}# filter 模块主要是数据预处理，提取一些信息，方便 Elasticsearch 好归类存储。# 2. grok 正则捕获# 3...
日志系统 - 背景
背景目前项目查看日志的方式较为朴素，人工线上查看 log 的方式也较为麻烦。一套能查看全链路日志的系统，对每位开发来说无疑是雪中送炭的。 其次，目前的业务日志中的数据是可供二次利用和开发的，而非目前仅是排查问题使用。 目标 打造全员可实时查看生产日志，并能提取调用链日志 应用到后续的业务发展中（BI） APM 价值为 BI 业务（other/计算）做准备 夯实服务架构 便利开发查看日志，不仅是业务日志，Filebeat 提供了各种 module 以支持监控各种中间件的日志 初步设想架构图 改动点 服务 保持原有日志格式 各日志加字段 ['traceId', 'localIp', 'module'] - 以便有问题可以确定到某台机器上的某个服务 各模块 traceId 通过 REST 接口传递 header（Rest 插件改造） 由（网关生成 traceid）orange 向下传递 traceId（uuid/snowflake） ELK（单点） Filebeat 和服务部署在同台机器上 ES index 格...
Koa + CLS + Log4js 实现全链路日志系统
什么是全链路日志在线上项目运行期间，经常会出现各种莫名其妙的 bug，而且一个请求往往会经过多个项目的接口调用。比如电商中的下订单，可能会调用到商品服务、优惠券满减服务、会员服务之类的。假如某一时刻下单失败，前端报了个系统异常，怎么样快速定位到底是哪个服务发生了异常，以及定位发生异常的服务具体是报了什么异常日志呢。 这就是全链路日志要做的事情，它把这个请求内调用到的所有请求通过全局 ID 串起来，通过全局 ID 可以把所有涉及到的系统日志都快速地定位出来。 日志开发架构图 之后 Logstash 后可能需要加 Queue 为后续大数据做准备 技术栈 功能 技术栈 日志 Log4js 异步资源追踪 cls-hooked Web 框架 Koa Node 12 REST - 传递 header[trace-id] Axios 思路 请求打进来，由网关下发全局唯一 ID Koa 框架可以获取同步请求的上下文，但在异步中需要上下文持久的问题（比如 async_hook） 需要保证当前项目所有 category 的 log 可用，且打印 trace-id ...
Filebeat 采集 JSON 日志到 ES
需求描述使用 Filebeat 从 log 文件中采集 JSON 格式的日志，发送到 ES 中，并在 ES 中显示 JSON 日志的各字段和数据。 问题一：如何采集 JSON 格式的日志在 filebeat.yml 文件中进行相应的配置： 12345678910111213141516171819202122232425262728293031323334- type: log enabled: true paths: - E:\testjson.log processors: - script: lang: javascript source: > function process(event) { var message = event.Get("message"); message = message.replace(/\\x22/g,'"'); message = message.replace...
ELK 常用架构及使用场景
ELK 常用架构及使用场景 摘自创始人 最简单架构在这种架构中，只有一个 Logstash、Elasticsearch 和 Kibana 实例。Logstash 通过输入插件从多种数据源（比如日志文件、标准输入 Stdin 等）获取数据，再经过滤插件加工数据，然后经 Elasticsearch 输出插件输出到 Elasticsearch，通过 Kibana 展示。 Logstash 作为日志搜集器这种架构是对上面架构的扩展，把一个 Logstash 数据搜集节点扩展到多个，分布于多台机器，将解析好的数据发送到 Elasticsearch server 进行存储，最后在 Kibana 查询、生成日志报表等。 这种结构因为需要在各个服务器上部署 Logstash，而它比较消耗 CPU 和内存资源，所以比较适合计算资源丰富的服务器，否则容易造成服务器性能下降，甚至可能导致无法正常工作。 Beats 作为日志搜集器这种架构引入 Beats 作为日志搜集器。目前 Beats 包括四种： Packetbeat：搜集网络流量数据 Topbeat：搜集系统、进程和文件系统级别的 CP...
公告