1.场景

容器化+K8s编排已经是现在进行时
把网站的多个项目设计为云原生(Cloud Native)或老项改造为云原生可以获得诸多能力
例如无云绑定、弹性、部署环境一致性、微服务、DevOps、持续交付
同时下一代微服务框架 服务网格(ServiceMesh) 也能无痛接入

博主现有项目后端开发语言为 PHP、Golang
Golang做一些基础公共服务(短信、消息、搜索等)
这些公共服务化的项目已经容器化
PHP的项目做应用逻辑层,会调用Golang写的一些公共基础服务
PHP项目中直接通过服务名调用服务

需求: PHP项目A 依赖 短信、消息、搜索这3个服务,开发人员无需在本机启动依赖的服务,通过服务直接名透明的调用开发环境dev下的服务,开发人员只需要关注PHP项目A的开发。

☆本文的方案完成了开发人员开发机透明的直接访问K8s服务,从而满足了本需求☆

需要开发机透明访的直接问Kubernetes群集内的服务本文讲的方案都适用

开发机直接访问Kubernetes群集内的服务 示意图

2.基本信息和完成的目标

2.1基本信息

开发办公内网 192.168.1.0/24
开发机2 192.168.1.2

运行K8s群集的Node网络 10.2.0.0/16
Node1 10.2.1.4
Node2 10.2.1.8
K8s 群集网络 10.3.0.0/16

部署deployment whoami服务用于测试
命名空间 default (这里可以用命名空间来区分环境例如dev为开发环境)
镜像 wwek/whoami
服务名 whoami

Pod ip
10.3.0.8在node1 10.2.1.4
10.3.0.70在node2 10.2.1.8

2.3完成的目标

开发机2 192.168.1.2 可以直接访问 whoami服务
也就是可以直接 curl http://whomai 就可以访问服务
本目标即完成需求

3.网络互通1 开发办公内网 <==> 公有云VPC(私有云内网)基础互通

开发办公内网 和 公有云VPC、私有云内网 网络互通

和公有云互通的方案
公有云VPN
专线(SDWAN)

私有云互通就不多讲了,很多公司内网的K8s开发测试群集和开发网络本身就是互通的

各家网络情况各有各的不同,相同的是这些有用的Tips
无论是在公有云VPC、私有云、K8s群集非常关键的一点,子网网段不要冲突不要冲突、子网网段不要冲突、子网网段不要冲突
做基础互通的时候善用公有云的VPC和路由配置功能
甚至你可以不用买公有云自带的VPN网关服务,直接配合VPC路由表用一台VM充当路由器网关、VPN网关
开发测试环境下用zerotier来打通各个内网性价比极高

最终要完成是 开发办公内网 和 公有云VPC(私有云内网) 基础互通

4.网络互通2 开发办公内网 <==> K8s群集内部Pod和Service网络

☆☆☆ K8s Node本身是直接可以访问K8s群集内部Pod网络的!☆☆☆
在Node1上用ping/curl测试 whoami服务 分布在2个Node的2个Pod

可以看到,whoami的2个pod ip都能ping通,用curl测试也能访问到

通过Edge Node互通K8s群集和开发办公之间的网络
那么用Node1作为 开发办公内网 和 K8s群集内部网络的“连接”点我们把这个Node1节点叫做 边缘节点(Edge Node)
边缘节点(Edge Node)可以在运行K8s群集中Node中随便选一个
这里选择Node1,他的网卡信息如下
eth0 vm网卡 ip 10.2.1.4
cbr0 K8s群集创建的网卡 ip 10.3.0.1

可以有2种方式
方式1 在 Edge Node eth0 上启用NAT 这样其他的子网的访问在K8s群集中看到的IP是 10.2.1.4
方式2 K8s群集子网和开发办公内网完全对等互通(公有云VPC路由表、开发办公网络路由表配合做)

完成后
开发办公网络中 在开发机2 192.168.1.2 ping/curl K8s群集中的pod ip

可ping/curl 属于whoami的2个Pod ip

㊗️网络搞通了,那么再解决DNS解析的问题就可以了

5.打通K8s群集中的DNS (开发办公内网的DNS,设置K8s中KubeDns为上游DNS)

在Edge Node1上可以直接访问到KubeDns

kubectl get svc -n kube-system
#kube-dns ip 10.3.254.107

那么在Edge Node1上面装一个DNS Server做个中间转发(使用CoreDNS)
开发网络中的电脑无法直接使用kube-dns,非Edge Node解析结果为空
所以需要在Edge Node1上转一个 DNS Server 做一个Proxy
CoreDNS的安装使用参考我的另外一篇文章
使用CoreDNS作为你的内网DNS服务器
可用CoreDNS配置文件参考
/etc/coredns/Corefile

# kubernetes设置
cluster.local:53 {
  # kube-dns
  forward . 10.3.254.107:53
  log
  errors
  #debug
}

# 默认设置
.:53 {
  # 先走本机的hosts
  # https://coredns.io/plugins/hosts/
  hosts {
    # 自定义sms.service search.service 的解析
    # 因为解析的域名少我们这里直接用hosts插件即可完成需求
    # 如果有大量自定义域名解析那么建议用file插件使用 符合RFC 1035规范的DNS解析配置文件
    #10.6.6.2 servicename
    # ttl
    ttl 60
    # 重载hosts配置
    reload 1m
    # 继续执行
    fallthrough
  }

  # file enables serving zone data from an RFC 1035-style master file.
  # https://coredns.io/plugins/file/
  # file service.signed service
  # 最后所有的都转发到系统配置的上游dns服务器去解析
  forward . /etc/resolv.conf

  # 缓存时间ttl  s
  #cache 6
  # 自动重新加载配置文件的间隔时间
  reload 6s
  # 输出日志
  log
  # 输出错误
  errors
  #debug
}

启动CoreDNS

dig @10.2.1.4 whoami.default.svc.cluster.local
# 测试下确保可以解析

在 开发机2
配置DNS为 Edge Node1 IP 10.2.1.4
配置搜索域为 default.svc.cluster.local

这个2个配置可以在开发办公网络中的DHCP服务器上统一配置

-w564

来测试下DNS解析 curl访问

6.关键实现总结

  • 网络互通1 开发办公内网 <==> 公有云VPC(私有云内网)基础互通
  • 网络互通2 开发办公内网 <==> K8s群集内部Pod和Service网络(通过Edge Node)
  • 打通K8s群集中的DNS (开发办公内网的DNS,设置K8s中KubeDns为上游DNS)
  • 开发机DNS配置 Edge Node DNS 和 搜索域设置default.svc.cluster.local

7.QA

问1:这也太复杂了吧,有没有简单点的?
答:
解决的目标不同

如果只是单纯的能访问k8s中的服务有以下的方式
访问K8s中的服务还有这些方式
telepresence (快速,本地开发面向k8s的微服务)
K8s中装个openvpn 拨入群集内网络
K8s自带的服务暴露方式 NodePort Ingress

这些方法在一个应用有多个服务依赖的时候无法做到让所有开发人员透明的直接通过服务名调用

为了做到对多个开发人员透明,所有人都不需要安装项目依赖的服务,只需要运行项目本身,本项目透明的调用依赖的服务。
所以才有了本文的“复杂”方案

问2:这样直通了暴露K8s群集后岂不是不安全?
答:
是的,但是可以解决,我是这么解决的
K8s群集分为线上和线下实现了隔离
线上为准生产、生产,线下为开发、测试
k8s中可以用命名空间(namespace)来做环境的区分
dev、testing、staging、prod

问题3:开发机中DNS用K8s的DNS作为上游后网站的CDN乱解析了!
答:
开发办公网络和公有云的网络运营商和地理位置都不同,
也就是如果网络出口不一样这会导致CDN解析的IP是错的

需要在开发办公网络也部署一个DNS Server成为二级DNS
开发办公网络 开发机设置DNS为这个二级DNS
cluster.local转发到 Edge Node DNS上
其他的走本地默认的DNS
同样采用CoreDNS,配置文件参考

cluster.local:53 {
  # Edge Node DNS
  forward . 10.2.1.4:53
  log
  errors
  #debug
}
.:53 {
   ....
}

私有云或者自己在开发办公网络部署的K8s群集,因为是同一个网络出口那么网站的DNS解析应该不会有问题

Istio

Istio官网
Istio中文官网
Istio开源
无需太多介绍Service Mesh明日之星,扛把子,截止2019.11还有太多问题没解决
复杂性,性能让人望而却步,能上生产的是真要技术厉害,还得内心强大,项目允许

Linkerd

Linkerd官网
Linkerd中文官网

A service mesh for Kubernetes and beyond. Main repo for Linkerd 2.x.
Linkerd is a service mesh, designed to give platform-wide observability, reliability, and security without requiring configuration or code changes.

Linkerd is a Cloud Native Computing Foundation (CNCF) project.

Maesh

Maesh官网
Maesh开源

Containous(Traefik 团队)推出了全新设计的轻量级 service mesh(服务网格)工具:Maesh,Maesh 允许对 Kubernetes 集群内流动的流量进行管理,这与入流量和出流量同样很重要。
Maesh 构建在 Traefk 之上,是一个简单但功能齐全的服务网格,支持最新的服务网格接口规范 SMI,有助于与现有的一些解决方案进行集成。此外,Maesh 默认是需要开启使用的,这意味着在你决定将它们添加到网格之前,你的现有服务不会受到影响。

比较喜欢用go语言编写的东西,毕竟CNCF中绝大多数项目都是go语言编写的,看后续走向

Consul

Consul官网
Consul开源

Secure Service Networking
Consul is a service networking solution to connect and secure services across any runtime platform and public or private cloud

consul原本是个分布式kv,可以用来做配置中心,注册中心,现在官方默认的宣传语都改成了连接和保护服务

定位服务发现(Service discovery)和 服务网格(Service Mesh)

Envoy

Envoy官网
Envoy开源
ENVOY IS AN OPEN SOURCE EDGE AND SERVICE PROXY, DESIGNED FOR CLOUD-NATIVE APPLICATIONS
ENVOY是开放源代码边缘和服务代理,专为云应用程序而设计

envoy作为服务网格中的通用数据平面, xDS API 已经成为数据平面API接口的实施标准
就好像AWS的OSS对象存储中的S3一样,成了事实标准

SOFAMson

SOFAMson官网
SOFAMson开源

SOFAMson 是一款使用 Go 语言开发的 Service Mesh 数据平面代理,旨在为服务提供分布式、模块化、可观察和智能化的代理能力。SOFAMosn 是 SOFAStack 中的一个项目,其中 MOSN 是 Modular Observable Smart Network 的简称。SOFAMosn 可以与任何支持 xDS API 的 Service Mesh 集成,亦可以作为独立的四、七层负载均衡使用。未来 SOFAMosn 将支持更多云原生场景,并支持 Nginx 的核心转发功能。

目前蚂蚁金服有大规模落地,2019年的双十一已经做了生产实践
API接口方面也是兼容Envoy的 xDS API 标准

1. 单机运行的Docker

容器化部署是现在进行时,开源应用大多数支持容器化部署
在少量机器的场景下往往采用docker cli 和 docker-compose管理,进行“单机式管理”
机器稍多点会采用Docker Swarm群集的方式,毕竟k8s稍重
如果有更多的机器情况下一般会采用k8s的方式
在个人、创业公司、小团队的场景下我们往往在多个云、家里、vps上拥有少量虚拟机服务器,这些服务器上都运行了docker实例
虽然我们也可以用公网vpn、zerotier等方式打通各个地域的机器形成一个内网,从而构建“群集”,但实际情况是没那么多带宽,从而无法“负载均衡”,所以实际的实际还是独立使用
受限制于公网带宽很小,只能独立使用
我们也拥有一些4G移动流量接入这种EDGE边缘场景的情况,这些IoT上也运行着Docker实例
那么这些NAT内网环境下的Docker实例,公网IP环境下的Docker实例,是否能集中管理?
当然可以,用Portainer就挺方便

2. 用Portainer作为Docker实例管理平台实战步骤

2.1 主节点-Portainer server主控安装

选一个7×24小时且有公网IP的节点运行Portainer server主控

docker run -d -p 8000:8000 -p 9000:9000 --name portainer --restart always -v /var/run/docker.sock:/var/run/docker.sock -v /data/appdata/portainer:/data portainer/portainer

9000端口为web管理界面端口
8000端口为Agent接入端口
这2个端口公网IP防火墙都必须放行

浏览器打开web管理界面
http://Portainer server主控公网IP:9000

初次访问设置一个密码,设置密码后需要选择连接docker的方式
选第一个Local 然后点击Connect
默认进入Home菜单,点击这个Local本地docker实例进入其他管理

Portainer官方安装手册参考

2.2 配置https nginx代理(可选)

如果不配置https可跳过本节
http://你的公网IP:9000 默认没有https不安全
规划一个域名用于https访问例如https://portainer.iamle.com
用nginx作为接入反向代理到 http://portainerip:9000
下面为示例nginx portainer配置(其中包含需要的websocket proxy)

# portainer.iamle.com.conf
map $http_upgrade $connection_upgrade {
    default Upgrade;
    ''      close;
}
upstream portainer {
    server 127.0.0.1:9000;
}
server {
        listen       80;
        server_name portainer.iamle.com;
        return      301 https://$server_name$request_uri;
}
server {

                listen 443 ssl http2;
        server_name portainer.iamle.com;

                ssl_certificate         ssl/iamle.com.cer;
                ssl_certificate_key     ssl/iamle.com.key;
                #ssl_session_cache           shared:SSL:10m;
                #ssl_session_timeout         10m;
                #ssl_session_tickets         off;

                ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
                ssl_ciphers         HIGH:!aNULL:!MD5:!EXPORT56:!EXP;
                ssl_prefer_server_ciphers on;

        location / {
                    proxy_set_header Host              $host;
                    proxy_set_header X-Forwarded-Proto $scheme;
                    proxy_set_header X-Forwarded-Port  $server_port;
                    proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
                    proxy_set_header X-Real-IP         $remote_addr;
                    proxy_set_header X-Request-Id $request_id;
                    proxy_set_header Upgrade           $http_upgrade;
                    proxy_set_header Connection        $connection_upgrade;
                    proxy_read_timeout 60m;
                    proxy_send_timeout 60m;
                    proxy_http_version 1.1;
                    proxy_pass http://portainer;
                    break;
        }


        error_log   /data/logs/portainer.iamle.com-error.log;
        access_log  /data/logs/portainer.iamle.com.log access;

}

2.3 主节点-配置一个在NAT内网Agent客户端

前面我们已经配置好一个具有公网IP的Portainer管理控制节点
那么现在把内网(NAT、IoT)、公有云、vps等运行的Docker实例来接入控制节点管理

一图胜千言,官方介绍图

图中这个Portainer管理了2个内网的Agent
其中一个是个Swarm群集,另外一个是个单机

Portainer server上增加一个Edge Agent
Endpoints菜单 》 Add endpoint 》 Edge Agent

Name:为自定义
Portainer server URL:默认为当前Portainer server ip (如果用nginx配置了https可以使用https不加端口号)
》 Add endpoint

增加端点后出现

部署客户端agent 有2种选择 Standalone 和 Swarm
如果已经组过Swarm那么选Swarm,默认就是Standalone
先点击 “Copy command” 复制命令,在Agent客户端去执行
Public IP: 如果有可以设置,这样在以后部署了docker容器暴露的端口可以自动生成url

2.4 被管理节点-需要被管理的Docker实例客户端机

在被管理的客户端终端上执行(内网(NAT、IOT)、公网环境都可以,只要能连接上我们的Portainer server)
本例内网1台ip为 192.168.0.8的机器

docker run -d -v /var/run/docker.sock:/var/run/docker.sock -v /var/lib/docker/volumes:/var/lib/docker/volumes -v /:/host --restart always -e EDGE=1 -e EDGE_ID=6ad0f1ff-6fea-4710-97e2-513ef1066fd8 -e CAP_HOST_MANAGEMENT=1 -p 8000:80 -v portainer_agent_data:/data --name portainer_edge_agent portainer/agent:1.5.1

访问 http://192.168.0.8:8000(如果有公网ip用公网ip)
打开后会有个输入框
输入上一步获得的Join token
点击Submit 出现 Agent setup OK. You can close this page. 代表完成agent接入

回到 Portainer server管理界面等待上线

点击 iamle-lan-01 等待几秒钟

这样我们就可以管理多个docker实例了

3. 贴士

  • 如果agent运行不起来,无限重启
    需要根据docker logs portainer_edge_agent 获取到的错误信息排查, 官方github issue是个好去处
    另外发现2019年10月19日16:55:01 pull 下来的portainer/agent:latest 也运行不起来 改为 portainer/agent:1.5.1正常

  • Stacks粘贴docker-compose.yml进来后一直报version版本不对
    目前只支持version 2 改为2即可

4. 参考

Portainer Edge Agent 官方发布
Portainer内网边缘节点配置说明书PDF

副标
Dockerize your Golang Application
dockerfile Golang example
docker golang example
Go应用docker容器化打包

Dockerfile

基础镜像使用aline
使用docker的多阶段构建

Dockerfile

# 构建阶段 build stage
FROM golang:stretch AS build-env
ADD . /go/src
WORKDIR /go/src

ENV GO111MODULE=on
ENV APP_NAME="goappname"
RUN CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -mod=vendor -o ${APP_NAME}
RUN pwd && ls -lsa

# 构建物打包阶段 final stage
FROM alpine:latest

## 配置 apk包加速镜像为阿里
RUN sed -i 's/dl-cdn.alpinelinux.org/mirrors.aliyun.com/g' /etc/apk/repositories

## 安装 一些基础包
RUN apk update \
    && apk upgrade \
    #&& apk add s6 \
    && apk add bash \
    #&& apk add nghttp2-dev \
    && apk add ca-certificates \
    && apk add wget \
    #&& apk add curl \
    #&& apk add tcpdump \
    && apk add iputils \
    && apk add iproute2 \
    && apk add libc6-compat \
    && apk add -U tzdata \
    && rm -rf /var/cache/apk/*

## 设置 操作系统时区
RUN rm -rf /etc/localtime \
 && ln -s /usr/share/zoneinfo/Asia/Shanghai /etc/localtime

## 打包 应用
ENV APP_NAME="goappname"
ENV APP_ROOT="/data/apps/"${APP_NAME}
RUN mkdir -p $APP_ROOT
WORKDIR $APP_ROOT

## 从构建阶段复制构建物
COPY --from=build-env /go/src/${APP_NAME}  $APP_ROOT/

## 增加 配置文件、其他依赖文件
COPY config/config.toml.tpl $APP_ROOT/config/
RUN  ls -lsah && pwd && mv ./config/config.toml.tpl ./config/config.toml && ls -lsah  $APP_ROOT/config && cat config/config.toml

## 配置 对外端口
EXPOSE 10000

# 设置启动时预期的命令参数, 可以被 docker run 的参数覆盖掉.
CMD $APP_ROOT/$APP_NAME

docker-compose.yml

version: "3.1"
services:
  goappname:
    build: ./
    image: registry.cn-shanghai.aliyuncs.com/goappname/goappname
    container_name: goappname
    deploy:
      restart_policy:
        condition: on-failure
    ports:
      - "0.0.0.0:10000:10000"
    volumes:
      - "/data/apps/goappname/config/:/data/apps/goappname/goappname/config/"

1. CoreDNS 是什么

img
CoreDNS官网
CoreDNS开源

CoreDNS是Golang编写的一个插件式DNS服务器,是Kubernetes 1.13 后所内置的默认DNS服务器
采用的开源协议为Apache License Version 2
CoreDNS也是CNCF孵化项目,目前已经从CNCF毕业。
CoreDNS 的目标是成为 Cloud Native(云原生)环境下的 DNS 服务器和服务发现解决方案。
你被爬虫啦,原文去https://www.iamle.com看
官方口号
CoreDNS: DNS and Service Discovery
DNS和服务发现

2. CoreDNS功能特性

2.1 插件化(Plugins)

CoreDNS插件链。 每个插件都执行DNS功能,例如Kubernetes服务发现,Prometheus指标或重写查询。
还有非常多的其他插件,插件是CoreDNS核心理念就是插件化

简单(Simplicity)

努力把配置文件变得简单
采用了Caddy中的DSL配置方案,即 Corefile 形式的配置文件
一个最简单的配置文件可以为:

.{}

2.2 服务发现 (Service Discovery)

核心域名系统通过Kubernetes插件与Kubernetes集成,或者通过etcd插件直接与etcd集成。
还有redis插件等

快速和弹性 ( Fast and Flexible)

我们的目标是使CoreDNS快速高效。 它的插件也很灵活。 您可以只使用所需的插件编译CoreDNS。

3. 配置一个内网自定义的服务化域名

假设需要在内网实现
sms.service A记录 10.6.6.2
search.service A记录 10.6.6.3
你被爬虫啦,原文去https://www.iamle.com看
我们为CoreDNS手动增加解析记录
那么Corefile配置文件为
/etc/coredns/Corefile

.:53 {
  # 绑定interface ip
  bind 127.0.0.1
  # 先走本机的hosts
  # https://coredns.io/plugins/hosts/
  hosts {
    # 自定义sms.service search.service 的解析
    # 因为解析的域名少我们这里直接用hosts插件即可完成需求
    # 如果有大量自定义域名解析那么建议用file插件使用 符合RFC 1035规范的DNS解析配置文件
    10.6.6.2 sms.service
    10.6.6.3 search.service
    # ttl
    ttl 60
    # 重载hosts配置
    reload 1m
    # 继续执行
    fallthrough
  }
  # file enables serving zone data from an RFC 1035-style master file.
  # https://coredns.io/plugins/file/
  # file service.signed service
  # 最后所有的都转发到系统配置的上游dns服务器去解析
  forward . /etc/resolv.conf
  # 缓存时间ttl
  cache 120
  # 自动加载配置文件的间隔时间
  reload 6s
  # 输出日志
  log
  # 输出错误
  errors
}

运行CoreDNS

coredns -conf ./Corefile

dig测试CoreDNS的自定义dns解析

dig @127.0.0.1  sms.service

; <<>> DiG 9.10.6 <<>> @127.0.0.1 sms.service
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18343
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;sms.service.           IN  A

;; ANSWER SECTION:
sms.service.        120 IN  A   10.6.6.2

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed May 01 22:23:51 CST 2019
;; MSG SIZE  rcvd: 67

可以看到 sms.service 的A记录已经为10.6.6.2

更多配置探索参考CoreDNS官方手册

4. 部署

这里可以找到基于k8s,基于systemd的部署文件参考
CoreDNS部署参考

安装

wget https://github.com/coredns/coredns/releases/download/v1.5.0/coredns_1.5.0_linux_amd64.tgz
tar zxf coredns_1.5.0_linux_amd64.tgz -C /usr/bin/

增加运行账户

useradd coredns -s /sbin/nologin

systemd的coredns配置文件
/usr/lib/systemd/system/coredns.service

[Unit]
Description=CoreDNS DNS server
Documentation=https://coredns.io
After=network.target

[Service]
PermissionsStartOnly=true
LimitNOFILE=1048576
LimitNPROC=512
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
AmbientCapabilities=CAP_NET_BIND_SERVICE
NoNewPrivileges=true
User=coredns
WorkingDirectory=~
ExecStart=/usr/bin/coredns -conf=/etc/coredns/Corefile
ExecReload=/bin/kill -SIGUSR1 $MAINPID
Restart=on-failure

[Install]
WantedBy=multi-user.target
systemctl enable coredns
systemctl start coredns
systemctl status coredns

实际上CoreDNS编译出来的是一个单二进制文件
二进制文件+配置文件就能跑了,部署起来非常简单

5. 参考

CoreDNS 使用与架构分析

前言

不管是PHP各种框架的日志
还是java的 Java Stack Traces
他们都是多行日志模式
这个时候如果使用
filebeat + elasticsearch + kibana 做日志的采集,存储,展示那么就需要用到
filebeat的 multiline 配置
一词日志是多行记录,其实这种多行的日志会有日志分段的分隔符
写出对于的分隔符正则即可解决filebeat采集一次日志记录为多行的情况

配置示例

例如我们有日志文件

/var/www/a.iamle.com/runtime/log/201904/01.log
/var/www/b.iamle.com/Application/Runtime/Logs/201904/02.log
/var/www/c.iamle.com/runtime/log/201905/03.log
/var/www/d.iamle.com/Application/Runtime/Logs/201906/04.log

分析日志后得出某一次日志通过什么标识作为分隔符

# 标识方式1 63个"-"作为分割符 正则为 ^\-{63}
# ...
---------------------------------------------------------------
2019-04-08T13:58:19+08:00 192.168.0.1 GET a.iamle.com/v1/1?type_id=1
[运行时间:0.582681s] [吞吐率:1.72req/s] [内存消耗:3,387.72kb] [文件加载:80]
[ err ] [ LANG ] /var/releases/balabala/20181227-101450/fw/lang/zh-cn.php
[ err ] [ ROUTE ] array (
  'rule' => 'v1',
  'route' => 'index/v1/1',
---------------------------------------------------------------
2019-04-08T13:58:19+08:00 192.168.0.1 GET b.iamle.com/v1/1?type_id=1
[运行时间:0.582681s] [吞吐率:1.72req/s] [内存消耗:3,387.72kb] [文件加载:80]
[ err ] [ LANG ] /var/releases/balabala/20181227-101450/fw/lang/zh-cn.php
[ err ] [ ROUTE ] array (
  'rule' => 'v1',
  'route' => 'index/v1/1',
---------------------------------------------------------------
# ...

# 标识方式2 "[ 2019 作为分隔符 正则为 ^\[\s{1}\d{4}
# ...

[ 2019-04-09T13:58:19+08:00 ] 192.168.0.1 GET a.iamle.com/v2
[运行时间:0.681s] [吞吐率:1.72req/s] [内存消耗:3,387.72kb] [文件加载:82]
[ err ] [ LANG ] /var/releases/balabala/20191227-101450/fw/lang/zh-cn.php
[ err ] [ ROUTE ] array (
  'rule' => 'v2',
  'route' => 'index/v2',

[ 2019-04-09T13:58:19+08:00 ] 192.168.0.1 GET b.iamle.com/v2/1
[运行时间:0.681s] [吞吐率:1.72req/s] [内存消耗:3,387.72kb] [文件加载:81]
[ err ] [ LANG ] /var/releases/balabala/20191227-101450/fw/lang/zh-cn.php
[ err ] [ ROUTE ] array (
  'rule' => 'v2',
  'route' => 'index/v2',
# ...

filebeat中配置文件
/etc/filebeat/filebeat.yml

# ...
- type: log
  enabled: true
  paths:
    - /var/www/*.iamle.com/runtime/log/*/*.log
    - /var/www/*.iamle.com/Application/Runtime/Logs/*/*.log
  # 正则需要支持2种不同的分隔符
  multiline.pattern: '^(\-{63}|\[\s{1}\d{4})'
  multiline.negate: true
  multiline.match: after

# ...
# 检查filebeat是否配置正确
 filebeat test config
# 重启filebeat
 systemctl restart filebeat

写正则的时候推荐用正则可视化工具检查正则
例如本文的正则

扩展

这种非自己能定义的日志,思路是寻找多行日志分段规律写出对于的正则即可
那么自己打日志的情况下,不太推荐这种多行日志了,采用结构化的json日志,一行一条是比较推荐的方式
这样在后期的处理分析中将会便利太多太多

参考

Filebeat Reference [7.0] » Configuring Filebeat » Manage multiline messages