【基于AWS，日志回收，分析查询】

前提摘要：

业务在美国aws部署，当服务遇到问题时，如何根据服务日志进行debug。

涉及到服务日志如何收集以及检索，查询。满足典型的日志查询分析场景。

ELK参考：

对比业内标准流程，ELK（Elasticsearch , Logstash, Kibana）：日志采集，日志检索，检索展示，这些要在aws上找到相同功能或自建。

1 - 业务概览

部署在美国的业务有web端，app端后端服务等。

整体部署在aws 的 k8s集群上，如何对k8s集群里的这些服务进行日志检索呢？

我们先看下服务部署架构图，

通过业务架构图，可以看到，多个服务被部署，每个服务里面又有多个Pod，Pod里面的业务应用将日志输出到文件里。我们参照ELK流程考虑，

如何把日志采集回来。
如何存储到检索引擎里。
如何根据关键字进行日志查询，并进行展示。

2 - 方案制定

我们依次介绍下方案的概览，流程，最后描述下细节，对应操作的原因。

2.1 方案概览

a) 开启aws eks集群日志输出插件，采集标准输出。

(refs: https://docs.aws.amazon.com/zh_cn/eks/latest/userguide/fargate-logging.html)

b) 采集的数据回传到openSearch，并构建查询索引。

c) 使用kibana配合openSearch进行查询结果展示。

2.2 流程图

2.3 具体操作以及原因

2.3.1 日志采集

首先，由于aws上k8s服务的限制，（aws上的k8s服务为EKS，限制为：EKS无额外挂载实体机器，纯serverless fargate模式下，无法对Pod中的文件直接进行采集，只能采集Pod中的标准输出），所以需要一个地方将文件转为标准输出。

此处采取的是side-car思路，同一个Pod内开一个container用于把文件中的内容输出到标准输出。这样做的好处是，外挂一个container采集，侵入性是最小的，对原container的服务应用无论是服务本身，还是资源上都是没有额外影响。

其次，考虑到日志本身的维护，日志被回传回去以后，长时间的老旧日志无需一直存在Pod中，这样会把磁盘打爆，需要定期切割然后删除老旧日志。还是side-car思路，再开一个container，用于日志的切割，定期删除，做log rotate。

这样整体有3个container，1个跑业务应用，1个跑日志切分删除，1个跑文件转标准输出，对应具体 k8s yaml配置：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sample-app
  namespace: ${namespace}
  labels:
    app: sample-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: sample-app-pod
  template:
    metadata:
      name: sample-app-pod
      labels:
        app: sample-app-pod
        fargate: "yes"
      annotations:
        logs_enable: "true"
    spec:
      containers:
        # container1: 业务程序
        - name: nginx
          image: nginx:latest
          ports:
            - name: http
              containerPort: 80
          env:
            - name: LOG_DIR
              value: /logs
          volumeMounts:
            - name: log-volume
              mountPath: /logs
        # container2: 日志切分，定期删除
        - name: logrotate-es
          image: blacklabelops/logrotate:1.3
          imagePullPolicy: IfNotPresent
          env:
            - name: LOGS_DIRECTORIES
              value: /logs/*.log
            - name: LOGROTATE_COPIES
              value: "5"
            - name: LOGROTATE_SIZE
              value: 50M
            - name: LOGROTATE_CRONSCHEDULE
              value: 0 0 0 * * *
            - name: LOGROTATE_PARAMETERS
              value: f
            - name: LOGROTATE_DATEFORMAT
              value: .%Y%m%d-%H:%M:%S
          resources:
            requests:
              cpu: "1"
              memory: 1Gi
          volumeMounts:
          - mountPath: /logs
            name: log-volume
        # container3: 日志文件转为标准输出
        - name: fluent-bit
          image: fluent/fluent-bit:latest
          volumeMounts:
            - name: log-volume
              mountPath: /logs
          command: [ "/fluent-bit/bin/fluent-bit" ]
          args: [ "-i", "tail", "-p", "path=/logs/*.log", "-o", "stdout" ]

      volumes:
        - name: log-volume
          emptyDir: {}

2.3.2 检索引擎

常见的检索引擎有elasticsearch 和 openSearch，而在aws上其包含cloudwatch 和 openSearch。这里选择开一个openSearch实例，作为检索引擎。

日志数据流入前，先创建下相关field的index索引，这样才能检索到相关field的内容。

2.3.3 检索展示

用了openSearch 配套搭配的 Kibana。这里当然也可以根据我们的使用场景，预置一些语句，比如根据服务名称或者标签，加filter，做一些group分组，debug某个服务，先进入到对应分组，然后再进一步进行检索。

（dql语句参考：https://opensearch.org/docs/2.11/dashboards/dql）

最后让我们看下检索效果，我们检索一个加了索引的kubernetes.pod_name字段，检索查询词"nginx"：

至此，参照着ELK流程，我们在aws上完成了业务日志的检索。

标签：aws，云服务，ELK，elasticsearch，open search，kibana