暂无图片
暂无图片
暂无图片
暂无图片
暂无图片

efk 使用心得之filebeat最佳实践

writeline 2021-04-19
2392

 先回顾下上一篇 安全性,简要的介绍了下各个组件与elasticsearch的交互。本文将在上两篇文章的基础上,继续介绍下如何用最佳的实践来收集日志。


前言


网上资料随便一搜,到处都能找到如何利用filebeat来收集日志的示例,可基本都是千篇一律,离实际运用差距有点大。诸如如何管理索引生命周期;日志如何统一收集并归类;如何在不停服的情况下,自动监听日志变更目录等等问题。本文将从实际业务使用出发,详细介绍如何解决这些问题。


01

索引生命周期管理


我的理解是一个索引从创建到最后被删除,这一个过程可以称之为一个“周期”。显然,这个很重要,为什么说它重要呢。就好比任何生物,从出生到最后的成才壮大,中间每一步都是充满曲折与波澜的。正因如此,更应该充分了解如何对它做管理,这样才能事半功倍。在扯了一堆无关的话语后,让我们来进入正题吧。在es的6.7版本后,正式引入了一个新功能”索引生命周期管理“,它把索引管理分为这么几个步骤 ”热“ ”温“ ”冷“ ”删除“,每个步骤里面又有细分要执行的一系列动作,具体可以到官网或网上查看。那我们怎么样运用它来管理我们的索引呢?可以在kibana里面用图形化界面创建一个索引生命周期策略,创建好之后,可以将策略应用到索引,同时还需要指定一个翻转别名,且每个策略只能有一个别名,在时序型日志中,每一天或每一小时都将会产生一个新索引的情况下,索引的写入依靠着别名在不断的做着滚动。然而当我有十个百个的服务需要做日志收集时,那对应着我将需要十个或百个这样的策略设置。在查阅了一些官网资料后,发现只能这么做,但这么做也没有问题,只是服务多的话,管理就不太方便了,这时可能需要一些工具来辅助。这里说到服务多的问题,那我要怎么对这些服务统一做约束管理呢?


02


服务统一管理


一般地,日志收集的需求并不只是存在于生产环境,测试预发布都会有,为了规范每一类环境,必须有一些约束在里面,比如相同的命名风格,相同的管理策略等。那这时候就可以使用模板来进行管理了,如下,这是一个通用的管理模板

    {
    "order": 0,
    "index_patterns": [
    "prod-*",
    "pre-*",
    "dev-*"
    ],
    "settings": {
    "index": {
    "routing": {
    "allocation": {
    "require": {
    "box_type": "hot"
    }
    }
    },
    "search": {
    "slowlog": {
    "level": "info",
    "threshold": {
    "fetch": {
    "warn": "1s",
    "trace": "200ms",
    "debug": "500ms",
    "info": "800ms"
    },
    "query": {
    "warn": "5s",
    "trace": "400ms",
    "debug": "1s",
    "info": "2s"
    }
    }
    }
    },
    "refresh_interval": "30s",
    "indexing": {
    "slowlog": {
    "level": "info",
    "source": "1000",
    "threshold": {
    "index": {
    "warn": "5s",
    "trace": "400ms",
    "debug": "1s",
    "info": "2s"
    }
    }
    }
    },
    "number_of_shards": "2",
    "translog": {
    "flush_threshold_size": "1gb",
    "sync_interval": "120s",
    "durability": "async"
    },
    "number_of_replicas": "0"
    }
    },
    "mappings": {
    "dynamic_templates": [
    {
    "message_field": {
    "path_match": "message",
    "mapping": {
    "norms": false,
    "type": "text"
    },
    "match_mapping_type": "string"
    }
    },
    {
    "exception_field": {
    "path_match": "exception",
    "mapping": {
    "norms": false,
    "type": "text"
    },
    "match_mapping_type": "string"
    }
    },
    {
    "string_fields": {
    "match_pattern": "regex",
    "mapping": {
    "norms": false,
    "fields": {
    "keyword": {
    "ignore_above": 256,
    "type": "keyword"
    }
    },
    "type": "text"
    },
    "match_mapping_type": "string",
    "match": "^Level$|^log_type$|^source$|^tags$|^logger$"
    }
    }
    ],
    "properties": {
    "log_type": {
    "type": "keyword"
    },
    "@timestamp": {
    "type": "date"
    },
    "geoip": {
    "dynamic": true,
    "type": "object",
    "properties": {
    "ip": {
    "type": "ip"
    },
    "latitude": {
    "type": "half_float"
    },
    "location": {
    "type": "geo_point"
    },
    "longitude": {
    "type": "half_float"
    }
    }
    },
    "logger": {
    "type": "keyword"
    },
    "@version": {
    "type": "keyword"
    },
    "Level": {
    "type": "keyword"
    },
    "source": {
    "type": "keyword"
    },
    "tags": {
    "type": "keyword"
    }
    }
    },
    "aliases": {}
    }

    这里将order设置为0,因为在es里面是允许多个同名规则的模板进行覆盖的。通过这样的一个模板,就实现了我们说的命名风格的统一,但是要实现统一的索引管理还是做不到,这在第一部分讲到了”必须要为每个索引单独指定别名“,而统一模板是做不到的,我们必须为每个索引单独进行设置,那这时候我们就可以利用模板来做。如下,这是一个具体索引的模板

      {
      "order": 1,
      "index_patterns": [
      "dev-promotioncenter-adminapi-*"
      ],
      "settings": {
      "index": {
      "lifecycle": {
      "name": "dev-promotioncenter-adminapi-policy",
      "rollover_alias": "dev-promotioncenter-adminapi-alias"
      }
      }
      },
      "mappings": {},
      "aliases": {}
      }

      这里将order设置为1,而index-patterns符合通用模板的命名,因此会应用通用模板中的设置,同时在settings里我们单独为这个索引设置了索引生命周期策略的名称和要翻转的别名。只要为每个服务创建类似的模板,就能达到统一管理的目的了。


      03


      整理下思路


      1. 创建一个通用的索引模板,order设置为0

      2. 创建一个具体服务的索引生命周期策略

      3. 创建一个具体服务的索引模板,index-patterns要符合通用模板的规则,order大于通用模板的order,同时设置索引生命周期策略的名称为第2步创建出来的名称和一个自定义的翻转别名

      4. 创建一个时序型或数字型索引,并设置写索引别名为第3步指定的翻转别名

      5. 利用filebeat收集日志时,索引设置成翻转别名

      6. 经过这五个步骤后,就能达到统一的管理了。既然管理统一了,那日志该怎么统一并归类收集呢?


      04


      日志统一归类收集


      想要实现统一归类收集,其实也不难,如下

        output.elasticsearch:
          enabled: true
          hosts: "${elasticsearch_url}"
        indices:
        - index: "${environment}-%{[log_type]}-alias"
        when:
                  has_fields: ['source']
        protocol: "https"
        username: "${elasticsearch_username}"
          password: "${elasticsearch_password}"
          ssl.certificate_authorities: ["${path.home}/certs/ca.crt"]

        这个配置里面有三个主要的变量,分别是source、environment、log_type,举个例子,比如”dev-promotioncenter-adminapi-alias“这个索引,source变量为promotioncenter,environment为dev,log_type为promotioncenter-adminapi。其中environment建议在服务启动进行设置,而source、log_type则是在对某个目录进行监听时设置的,如下

          - type: log
          enabled: true
          paths:
              - /var/logs/promotioncenter.adminapi/*.log
          fields_under_root: true
          fields:
          log_type: promotioncenter-adminapi
               source: promotioncenter
          json.keys_under_root: true
          json.overwrite_keys: true
          json.add_error_key: false
            json.message_key: 'message'
          multiline.pattern: '^\{"date":"\d{4}-\d{1,2}-\d{1,2}'
          multiline.negate: true
          multiline.match: after

          这样就能对日志统一做归类收集了。但是每新加一个监听目录都要先停止服务在启动,有没有什么办法能不停服也能收集的吗?


          05


          filebeat不停服收集日志


          实际上这个功能filebeat也已提供,我们只要设置下就可以了,如下

            filebeat.config.inputs:
              enabled: true
              path: ${path.config}/input.d/*.yml
              reload.enabled: true
              reload.period: 60s

            我们只需要将原有的input调整到yml文件即可,是不是很简单。


            写在最后

            通过这些操作后,一个最佳的索引管理方式已呼之欲出。这也是目前笔者探索到的,如果您知道有更好的方式,欢迎随时和我交流。下一篇我将会讲讲如何编写一个比较自动化的工具来实现智能化的日志运维。



            如有收获,点个在看,诚挚感



            文章转载自writeline,如果涉嫌侵权,请发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

            评论