背景 最近在全面接手估计有1k+的生产日志的运维工作，每天面临着大量的投诉，大部分的诉求都是日志突然没了，为了对生产故障进行排查要紧急查看日志，由于应用系统数量和种类繁多，以及所有日志系统的网络架构的复杂性导致出现这种问题有时并不能快速解决，与其每天被动的的接受开发的投诉，还不如主动的对这1K+应用产生的Elasticsearch索引进行运维治理。 其实应用突然没日志无外乎下面几种： k8s pod里面的log挂载点发生了变化 log4j里面的日志路径发生了变化 应用上云后log4j里面的路径没有进行同步变更 还有…
Linux机器: 这里有两个地方需要注意，否者会有严重问题： 1、要先到这里把第一种模式的restart脚本放到saltmaster上，然后在下发完filebeat配置之后把restart脚本也下发一下再执行重启filebeat命令，否者salt会卡住， 这种场景主要是因为某些情况下为了排障生产的filebeat启用了这里提到的中的第二种简单排错模式，这种模式会导致salt命令卡住 2. salt的重启filebeat命令一定要用"cd /data/filebeat/ && sh rest…
1. 用于saltstack自动化部署模式：所有输出全部定向到/dev/null，可以实现在自动化下发配置的时候salt命令全程不卡住 2、简单排错模式：把debug输出重定向追加到文件，适用于判断与ES VIP后端节点的通信情况判断，以及简单的判断filebeat是否启动harvester组件采集某个路径下的日志 3、全部 debug selector都开启模式：适用于分析filebeat全部采集链路，非特殊情况慎用，用完及时关闭，否者短时间内日志暴涨几十G
背景 完整的报错内容如下： filebeat failed to publish events 413 request entity too large 遇到此种报错将会导致es中没有数据 解决方法 找到filebeat的主配置filebeat.yml，在output中加入 bulk_max_size: 20，这个值默认是50，我们要改小一点，改成10或者20都行，由于yaml这种格式极易出错引起不适，我把相关的部分摘录如下：
背景 在实际的生产中的大量实践后我们会发现即使Elasticsearch官方宣称filebeat为轻量级采集agent，但是如果一个性能较好的机器上同时部署几十个应用，也就意味着有几十个应用在源源不断的产生大量日志，这种情况下无论filebeat再怎么轻量也会不堪重负，从而成为cpu负载的No.1。 解决 解决起来很简单，只要在主配置filebeat.yml中加入 max_procs: 2即可(这里假定机器是4核的)，由于yaml这种文件格式极易出错引起不适，我就把完整的配置贴出来一下，供大家参阅！
背景 经过在生产环境的大规模使用之后发现如果使用Elasticsearch 6.x的一些默认配置的话，尤其是number_of_shards默认为5，如果索引按照天生成，日积月累到几万后，集群就会频繁GC，最终导致ES的某些REST接口不可用。 最新的ES 7.x已经将number_of_shards默认为1了，所以如果你们的生产环境如果全面升级到了7.x的话则可以忽略本篇博客，但是如果因为各种原因你们的es集群还在使用6.x的话，那么就要做一些优化了。 优化 我们打开Kibana的面板后，来到Management…
背景 我们都知道filebeat在采集的时候可以在主配置里面进行设置后就会采集上主机上的hostname作为一个字段，可是实际生产环境经常会遇到一个集群中的节点的hostname都是一样的，如果恰巧不方便修改hostname或者就想知道具体是哪个ip的机器采集上来的日志该怎么办呢，其实很好办我们只需要在每个应用的filebeat配置中写死一个额外的变量如hostip即可。 添加额外的变量有两种方式，其中一种方式经常会导致elasticsearch采集上来的每个hit里面的字段缺少你要额外加的这个变量，但是又不是每条…
子舒博客