SpringBootは軽量分散ログフレームワーク（GrayLog）にアクセスします

00.なぜ分散ログコンポーネントが必要なのですか？

Java学習資料のフルセットを入手するためのリンク：wpa.qq.com/msgrd?v=3&u…

記事が正式に始まる前に、私が以前担当していたシステムを共有します。そのアーキテクチャは次のとおりです。

問題をチェックするたびに、最初はロジックレイヤーで問題を特定できますが、ビジネス側に説明するには、ビジネス側に証拠をます（ログ情報は反駁できない証拠です）。

リクエストはこれらの8台のマシンのいずれかで処理する必要がありますが、どちらが正確かはわかりません。したがって、各マシンでログをgrepする必要があります。そうすれば、分析を証明するために対応するログを見つけることができます。

場合によっては、アクセスレイヤーも一緒に参加する必要があり、人々は問題を調査するのに愚かです（ログを読み取るのに時間がかかりすぎます）。

後で、同僚の操作を確認しました（item2にスクリプトを記述します：要塞マシンにすばやくログインし（アカウントとパスワードの情報を入力する必要はありません）、アプリケーションサーバーの数に応じてウィンドウを切り取り、対応するログディレクトリに切り替えます） 。率直に言って、複数のアプリケーションサーバーへのワンクリックログインです。さて、ログをチェックする速度は以前よりはるかに速くなっています。

その後、同社の運用・保守側は、主にWebページのアプリケーションサーバーへのログイン（要塞マシンへの自動ログイン）を推進し、スクリプト作成の手間を省くことができました（バッチ操作をサポート）。しかし、当時の経験から、item2がスムーズにアクセスすることに問題はありませんでした（常にスタックしているように感じました）。

ただし、どのファイル情報/警告/エラーが発生しているかわからないことが多いため、まだ問題があります。多くの場合、一度にチェックできるファイルは1つだけです。ワイルドカードますが、ログが大きすぎると、一時停止時間をもたらすのが面倒になります。

システムにビジネス上の質問が行われると、ログをチェックする頻度が高すぎます。そこで、あるQを計画しているときに、自分で検索エンジンにログ情報を書き込んで、検索エンジンの知識を学びたいと思いました。それから、この計画はグループの大きな男によって見られました、そして、彼は一番下でコメントしました：なぜあなたはGraylogを試してみませんか？

グループ自体がログわかりましたが、わかりません...そこでGraylogログを接続し、作業効率が向上し、この件についてQを吹きました。

接続してから、アプリケーションサーバーにログインしておらず、grepを1回も書き込むことがほとんどできませんでした。

01.軽量ELK（グレーログ）

ELKといえば、使ったことがなくても聞いたことがあるはずで、バックエンドで大人気です。今回、オースティンは比較的軽量のELKフレームワークにアクセスします：Graylog

このフレームワークは非常に使いやすく、ユーザーとして接続するのも非常に簡単だと思います（操作と保守は非常に簡単なはずです。多くの場合、エージェントをインストールしなくても、Graylogを使用してUDPをサーバーに直接送信します。ログを収集するためのマシン上）

写真は10語の価値があります：

公式ドキュメント：**
docs.graylog.org/docs **

私の知る限り、かなりの数の企業がログやビジネス監視アラートを表示。この記事では、それを直接体験させます。

02、部署Graylog

老样子，直接上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设置就完成了。

03、SpringBoot使用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 的地址，到这里接入就完毕了，我们再打开控制台，就能看到日志的信息啦。

04、懂点GrayLog

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

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

详细资料：**
docs.graylog.org/docs/gelf**

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

05 、番外：Swagger

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

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

在初次的体验感觉是不错的：它能把项目的所有接口的 文档信息 都能在一个页面上 统一管理 ，并且就能直接通过 样例参数 直接发送请求。通过注解的方式来进行编写文档，也不用担心代码改了然后忘了更新文档这事。

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

Swaggerにはいくつかの競合製品がありますが、UIはSwaggerよりも見栄えが良いと思います。ただし、オースティンプロジェクトのメイン熟練したマークダウンエンジニアとして、ドキュメント作業を簡単に行うことができるため、他の競合製品を引き続き体験することはありません。