关于java:分布式日志组件GrayLog入门

我是 3y，一年 CRUD 教训用十年的 markdown 程序员👨🏻‍💻长年被誉为优质八股文选手

前两天我不是发了一篇数据链路追踪的文章嘛，在开端也遗留了 TODO： 运行利用的服务器个别是集群，日志数据会记录到不同的机器上，排查和定位问题只能登录各个服务器查看。

明天来聊聊这个话题。

在文章正式开始之前，我分享下我以前负责过的一个零碎，它的架构如下：

每次当我查问题的时候，我可能能把问题初步定位在 逻辑层 ，但为了能给业务方交代，我须要 给证据 业务方看（日志信息就是铁证）。

一个申请必定是被这 8 台机器内的某一台解决，但具体是哪一台，我不晓得。所以，我须要上每台机器上 grep 一把日志，而后能力找出对应的日志证实我的剖析。

有的时候，可能 接入层 也须要一起参加进去，就排查一个问题，人都傻了了（翻看日志的工夫占用了太久了）。

起初啊，看了共事的骚操作（在 item2 编写脚本： 疾速登录堡垒机 （免去输出账号和明码信息），依据应用服务器数量来切割窗口并且切换到对应的日志目录）。说白了就是 一键登录 多台应用服务器。嗯，这查日志的速度比起以前又快了好多。

再起初，公司运维侧又主力推在 Web 页面 上登录应用服务器（主动登录堡垒机 ），这能省去编写脚本（ 反对批量操作 ）。但从过后的体验上，没有用item2 拜访得晦涩（总感觉卡卡的）。

不过还有问题，因为咱们在很多时候是不晓得在 info/warn/error 哪个文件下。很多时候只能一个一个文件去查，尽管说能够间接 通配符 一把查，如果日志过大，带来进展工夫也挺烦的。

零碎一旦被问到业务问题，查日志的频率切实是太高了。于是我在某个 Q 布局的时候是想本人把日志信息写入到 搜索引擎 ，顺便学习下搜索引擎的常识。而后这个布局被组内的某个大佬看到了，在底下评论： 要不来试试 Graylog？

原来组内自身就在保护了一个 日志框架 ，只是我不晓得 … 于是我接入了Graylog 日志，工作效率杠杠进步了，凭借这个事件吹了一个 Q 。

自从接入了之后，我就没登录过应用服务器了，有次差点连 grep 都不会写了。

说起 ELK，即使没用过必定也据说过这玩意了，在后端是真的风行。这次 austin 接入一个比拟轻量级的 ELK 框架：Graylog

这个框架我感觉蛮好用的，作为 应用方 接入起来 异样简略（我估摸运维应该也挺简略的，很多用 Graylog 是间接发 UDP 到 Server，不必在机器上装 agent 收集日志）

一图胜十言：

官网文档：https://docs.graylog.org/docs

据我理解，有相当多的企业应用它来 查看日志和业务监控告警，这篇文章我就间接让你们体验体验吧。

老样子，间接上 docker-compose，如果始终跟着我的步调，应该对着不生疏了。docker-compose.yml的内容其实我也是抄官网的，这里还是贴下吧（就不必你们翻了）

version: '3'
services:
    mongo:
      image: mongo:4.2
      networks:
        - graylog
    elasticsearch:
      image: docker.elastic.co/elasticsearch/elasticsearch-oss:7.10.2
      environment:
        - http.host=0.0.0.0
        - transport.host=localhost
        - network.host=0.0.0.0
        - "ES_JAVA_OPTS=-Dlog4j2.formatMsgNoLookups=true -Xms512m -Xmx512m"
      ulimits:
        memlock:
          soft: -1
          hard: -1
      deploy:
        resources:
          limits:
            memory: 1g
      networks:
        - graylog
    graylog:
      image: graylog/graylog:4.2
      environment:
        - GRAYLOG_PASSWORD_SECRET=somepasswordpepper
        - GRAYLOG_ROOT_PASSWORD_SHA2=8c6976e5b5410415bde908bd4dee15dfb167a9c873fc4bb8a81f6f2ab448a918
        - GRAYLOG_HTTP_EXTERNAL_URI=http://ip:9009/ # 这里留神要改 ip
      entrypoint: /usr/bin/tini -- wait-for-it elasticsearch:9200 --  /docker-entrypoint.sh
      networks:
        - graylog
      restart: always
      depends_on:
        - mongo
        - elasticsearch
      ports:
        - 9009:9000
        - 1514:1514
        - 1514:1514/udp
        - 12201:12201
        - 12201:12201/udp
networks:
    graylog:
      driver: bridg

这个文件里惟一须要改变的就是 ip（原本的端口是9000 的，我因为曾经占用了 9000 端口了，所以我这里把端口改成了9009，你们能够随便）

嗯，写完 docker-compose.yml 文件，间接 docker-compose up -d 它就启动起来咯。

启动当前，咱们就能够通过 ip:port 拜访对应的 Graylog 后盾地址了，默认的账号和明码是admin/admin

随后，咱们配置下 inputs 的配置，找到 GELF UDP，而后点击Launch new input，只须要填写Title 字段，保留就完事了（其余不必动）。

嗯，到这里，咱们的 GrayLog 设置就实现了。

还记得咱们 austin 我的项目应用的日志框架吗？没错，就是 logback。咱们要把日志数据写入 Graylog 很简略，只须要两步：

1、引入依赖：

<dependency>
  <groupId>de.siegmar</groupId>
  <artifactId>logback-gelf</artifactId>
  <version>3.0.0</version>
</dependency>

2、在 logback.xml 配置 graylog 相干的信息：

<appender name="GELF" class="de.siegmar.logbackgelf.GelfUdpAppender">
  <!-- Graylog 服务的地址 -->
  <graylogHost>ip</graylogHost>
  <!-- UDP Input 端口 -->
  <graylogPort>12201</graylogPort>
  <!-- 最大 GELF 数据块大小（单位：字节），508 为倡议最小值，最大值为 65467 -->
  <maxChunkSize>508</maxChunkSize>
  <!-- 是否应用压缩 -->
  <useCompression>true</useCompression>
  <encoder class="de.siegmar.logbackgelf.GelfEncoder">
    <!-- 是否发送原生的日志信息 -->
    <includeRawMessage>false</includeRawMessage>
    <includeMarker>true</includeMarker>
    <includeMdcData>true</includeMdcData>
    <includeCallerData>false</includeCallerData>
    <includeRootCauseData>false</includeRootCauseData>
    <!-- 是否发送日志级别的名称，否则默认以数字代表日志级别 -->
    <includeLevelName>true</includeLevelName>
    <shortPatternLayout class="ch.qos.logback.classic.PatternLayout">
      <pattern>%m%nopex</pattern>
    </shortPatternLayout>
    <fullPatternLayout class="ch.qos.logback.classic.PatternLayout">
      <pattern>%d - [%thread] %-5level %logger{35} - %msg%n</pattern>
    </fullPatternLayout>

    <!-- 配置利用名称（服务名称），通过 staticField 标签能够自定义一些固定的日志字段 -->
    <staticField>app_name:austin</staticField>
  </encoder>
</appender>

在这个配置信息里，惟一要改的也只是 ip 的地址，到这里接入就结束了，咱们再关上控制台，就能看到日志的信息啦。

懂点 GrayLog 查问语法：这块我日常来来去去其实就用几个，我来展现下我平时用的吧。如果感觉不够，再去官网文档捞一把就完事了：https://docs.graylog.org/docs/query-language

1、依据字段准确查问：full_message:"13788888888"

2、查问谬误日志信息：level_name:"ERROR"

3、组合多字段查问：level_name:"INFO" AND full_message:"13788888888"

在接入的时候，认真的小伙伴可能会发现我这边在 Input 的时候抉择的是 GELF，而后在引入 Maven 依赖的时候也有GELF 的字样。那 GELF 是啥意思呢？

这块在官网也有给出对应的解释：The Graylog Extended Log Format (GELF) is a log format that avoids the shortcomings of classic plain syslog

详细资料：https://docs.graylog.org/docs/gelf

GELF是一种日志格局，能防止传统意义上的 syslogs的一些问题，而咱们引入的 Maven 依赖则是把日志格式化成 GELF 格局而后 append 到 GrayLog 上。

前几天有个老哥在 GitHub 给我提了个 pull request 对于 swagger 的，我昨天把他 merge 了，也降级了下 swagger 的版本。

之前我没用过 swagger 相似的文档工具，就这次 pull request 我也去体验了下swagger。

在首次的体验感觉是不错的：它能把我的项目的所有接口的 文档信息 都能在一个页面上 对立治理 ，并且就能间接通过 样例参数 间接发送申请。通过注解的形式来进行编写文档，也不必放心代码改了而后忘了更新文档这事。

然而，起初我配置好对应的参数信息文档，再在 swagger-ui 体验了下，发现是真滴丑 ，看到这ui 我还是阶段性放弃吧。

swagger的竞品还有好几个，我看 ui 貌似都要比 swagger 难看。不过，austin 我的项目的 次要接口就只有一个 ，我作为熟练掌握的markdown 工程师能轻松胜任文档工作，就没再持续体验别的竞品了。

之前我如同是在知乎看到过相似的一段话：一个工具或框架应用优良，就取决于它的入门的难易。如果一个框架要花很长时间能力弄懂，那可能它做得并没那么好。

我其实不会常常去钻研各种应用的框架它的细节原理，也不会蒙头就去看源码，没什么必要，毕竟它没出问题啊。

像 GrayLog 这种工具类的框架，如果在公司不是次要的维护者，其实不用太过于纠结他的实现细节，能够从 总体上 把握他的设计思维。换我倡议，真要学习，还得是看它的具体存储（比方 Elasticsearch 的原理）

学习就要带有利益点（学了能提高效率，学了能当前在面试的时候吹牛逼进而涨工资，学了能使本人高兴，学了能装逼）

都看到这里了，点个赞一点都不过分吧？我是 3y，下期见。

关注我的微信公众号【Java3y】除了技术我还会聊点日常，有些话只能轻轻说~ 【对线面试官 + 从零编写 Java 我的项目】继续高强度更新中！求 star！！原创不易！！求三连！！

austin 我的项目源码 Gitee 链接：gitee.com/austin

austin 我的项目源码 GitHub 链接：github.com/austin

关于java:分布式日志组件GrayLog入门

00、为什么须要分布式日志组件？

01、轻量级 ELK（Graylog）

02、部署 Graylog

03、SpringBoot 应用 GrayLog

04、懂点 GrayLog

05、番外：Swagger

06、总结