背景

在云原生的趋势下，越来越多的程序开始跑在容器上，而这就绕不开构建镜像这个操作，而镜像的大小又会关系到这个镜像的拉取时间、网络开销、磁盘占用等问题。因此如何能够更好的构建镜像就变得越来越重要了。

之前blog一直是通过hexo+GitHub page部署的，那是还没有GitHub actions，每次操作都无比复杂，最近有时间就做个小更新，记录下更改点。

前言

说完了filebeat的基础架构和相关设计后，我们就来看下filebeat是如何来实现这些功能的。这里只对几个相对来说比较重要的几个流程进行讨论。其余的设计会在之后的文章中进行阐述。几个流程为：

• 启动过程
• harvester 监听过程（以log为例）
• outputs 处理流程（以kafka为例）

简介

Filebeat is a lightweight shipper for forwarding and centralizing log data. Installed as an agent on your servers, Filebeat monitors the log files or locations that you specify, collects log events, and forwards them either to Elasticsearch or Logstash for indexing.

这是elastic对于filebeat的官方描述，翻译过来就是filebeat是一个轻量级的用来采集和转发日志数据的组件。将采集的日志封装成event转发给下游的组件，例如elasticsearch、logstash或者kafka。

背景

​ 我们都知道日志至于任何系统、软件都是十分重要的组成部分，通过日志我们可以方便地了解到现在系统运行是否正常、是否有异常情况。但有时候日志太多了也会有幸福地烦恼，发生异常想通过日志进行排查，可是满屏地日志都是不那么重要地内容，像心跳日志、debug日志等等。

​ 这在java应用尤为严重，你每引入地一个jar都有可能引入一堆打印的日志，这样一来要从日志中找到你所需要的内容将是一件极其困难的事情。当然，你会说，java拥有这么多优秀的日志框架系统，可以简单地通过相应地配置文件将这些内容根据不同的输出级别输出到不同的目录文件，可是如果将这件事情都交给终端用户去处理，那将会是一件极其复杂的工程，他得明白哪些是他需要的、哪些是他不需要的，而这些信息应该是对应的开发人员最清楚不过的，因此让开发人员提前将这些日志进行归类，输出到指定的文件，那对应使用者来说将会变得很简单。

问题描述

1

在我们中应用有一个使用到`Http Long Poll`的场景，它需要一个http请求保持最长30秒，用于即使获取到最新的数据。在k8s环境下，发现应该存在偶发的异常，表现为长连接没有正常关闭，抛出异常：

1

java.net.SocketException: Unexpected end of file from server

接着上篇文章，现在开始部署Redis集群，采用方案为四主四从，暂时不考虑搭建哨兵，因此需要八台机器，以下是部署过程中的一些记录。

接着上篇文章，现在开始部署RocketMQ集群，采用的部署方案是阿里推荐的两主两从异步刷盘的模式，因此准备了四台服务器来进行MQ集群的部署，以下是部署过程中的一些记录，

​ 最近由于公司要切换IDC机房，新机房的服务器集群需要重新部署生产环境，于是又趁着这次机会把一些常用的中间件又重新部署了一次，版本有更新，部署方式也会有小变动，于是就有了这一系列的文档。整个系列主要是java运行环境下的中间件部署，也含有少量其他中间件的部署，像 Redis、 TiDB 等。

异常场景

最近一段时间时不时就有开发人员向我反应：redis的key有点问题，帮我删个key值、怎么key没有过期，我明明设了过期时间的。一开始没有放心上，以为只是程序逻辑处理不当或者redis偶尔抽风，不用在意。可是渐渐反应的人多了，觉得可能不是这么简单了，于是就和相关的开发人员讨论了下，发现会出现异常的基本是以下两种场景：