00. ¿Por qué necesita un componente de registro distribuido?
El enlace para obtener un conjunto completo de materiales de aprendizaje de Java: wpa.qq.com/msgrd?v=3&u…
Antes del inicio oficial del artículo, compartiré un sistema del que fui responsable anteriormente, su arquitectura es la siguiente:
Cada vez que verifico un problema, inicialmente puedo ubicar el problema en la capa lógica , pero para explicarlo al lado comercial, necesito proporcionar evidencia al lado comercial (la información de registro es una evidencia irrefutable).
Una solicitud debe ser procesada por una de estas 8 máquinas, pero cuál es exactamente, no lo sé. Entonces, necesito grep un registro en cada máquina, y luego puedo encontrar el registro correspondiente para probar mi análisis.
A veces, es posible que la capa de acceso también deba participar en conjunto, y las personas son estúpidas al investigar un problema (se tarda demasiado en leer el registro).
Más tarde, vi la operación de mi colega (escriba un script en el elemento 2: inicie sesión rápidamente en la máquina bastión (no es necesario ingresar información de cuenta y contraseña), corte la ventana de acuerdo con la cantidad de servidores de aplicaciones y cambie al directorio de registro correspondiente) . Para decirlo sin rodeos, es un inicio de sesión con un solo clic en varios servidores de aplicaciones. Bueno, la velocidad de verificación de registros es mucho más rápida que antes.
Más tarde, el lado de operación y mantenimiento de la empresa empujó principalmente para iniciar sesión en el servidor de aplicaciones en la página web ( iniciar sesión automáticamente en la máquina bastión ), lo que puede evitar la necesidad de escribir scripts ( operaciones por lotes de soporte ). Pero según la experiencia en ese momento, no hubo ningún problema con el acceso sin problemas de item2 (siempre se sentía atascado).
Pero todavía hay problemas, porque a menudo no sabemos en qué archivo se encuentra la información/advertencia/error. En muchos casos, solo puede verificar un archivo a la vez. Aunque puede verificar directamente los comodines , si el registro es demasiado grande, será molesto traer tiempo de pausa.
Una vez que se le hacen preguntas comerciales al sistema, la frecuencia de verificación de registros es demasiado alta. Entonces, cuando estaba planeando cierta Q, quería escribir yo mismo la información de registro en el motor de búsqueda y, de paso, aprender el conocimiento del motor de búsqueda. Luego, este plan fue visto por un tipo grande en el grupo, y comentó en la parte inferior: ¿Por qué no pruebas con Graylog ?
Resulta que el grupo en sí está manteniendo un marco de registro , pero no sé... Así que conecté el registro de Graylog, y la eficiencia del trabajo mejoró, y saqué una Q por este asunto .
Desde que me conecté, no he iniciado sesión en el servidor de aplicaciones y casi ni siquiera pude escribir grep una vez.
01. ALCE ligero (Graylog)
Hablando de ELK, incluso si no lo ha usado, debe haber oído hablar de él, y es muy popular en el back-end. Esta vez austin accede a un framework ELK relativamente ligero: Graylog
Siento que este marco es bastante fácil de usar, y es muy simple conectarse como usuario (supongo que la operación y el mantenimiento deberían ser bastante simples, muchos usan Graylog para enviar UDP directamente al servidor, sin tener que instalar un agente en la máquina para recopilar registros)
Una imagen vale más que diez palabras:
Documentación oficial: **
docs.graylog.org /docs **
Hasta donde yo sé, muchas empresas lo usan para ver registros y alertas de monitoreo comercial . En este artículo, te dejaré experimentarlo directamente.
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 我还是阶段性放弃吧。
Hay varios productos que compiten con Swagger. Creo que la interfaz de usuario se ve mejor que Swagger. Sin embargo, solo hay una interfaz principal Como ingeniero de rebajas competente, puedo hacer fácilmente el trabajo de documentación, por lo que no seguiré experimentando con otros productos de la competencia.