记一次日志系统异常问题排查

日志收集系统大致流程

flume收集业务日志(metaagent是辅助flume启动的) → 日志缓存到kafka → gosink消费缓存到kafka的日志 → 存储到elasticsearch

个人解决思路

1、日志系统搜索日志报错，查看业务日志，报错索引不存在

查看业务日志，找到报错索引不存在那段代码，可以说明两点

第一、可能是日志并没有被存储在ES，索引不存在
第二、日志被存储在ES，但是索引和查询索引不匹配

针对第一种可能来解决问题

1、到安装ES的机器看ES进程是否存在

systemctl status elasticsearch.service

ES正常启动

2、查看gosink日志，验证gosink是否正常消费kafka日志

# 找到gosink日志所在路径
[root@ceshigx2 var]# pwd
/home/footstone/gosink/var
[root@ceshigx2 var]# ls
app.log  app.pid
[root@ceshigx2 var]# 

# 查看gosink日志
less app.log

看到gosink日志报错，请求消费日志的路径（meta-agent），请求不通，联系测试以及实施人员，咨询他们是否安装日志系统，在执行以下命令IP是否填写正确

# 日志管理-->日志配置 新增meta-agent IP为某台要收集日志的机器如192.168.33.111，日志文件名称要填绝对路径 /home/footstone/meta-agent/var/logs/meta-agent.log
# 用footstone用户登录111机器，指定IP安装meta-agent 
LOCALIP=192.168.33.111 bash -c "$(curl http://192.168.33.112:10024/api/install/flume_install_for_linux.sh)"

沟通之后发现，实施人员在执行此条命令错误，后测试人员调整更改之后，我发现gosink日志可以正常消费了，但是，监控大屏日志系统依然报错

针对第二种可能来解决问题

查看ES系统是否存在此索引（索引拼接方式log-yyyyMMdd）,执行以下命令查看索引是否存在

curl http://账号名:密码@IP:端口/log-yyyyMMdd

执行命令发现索引存在，啊哈，这就很奇怪了，为什么感觉奇怪，因为这套部署系统都是测试部署几十遍之后，才交付实施的，之前真没遇到过这种问题，找大佬去沟通，查询问题出在哪里。
大佬一顿查找，执行以下命令(查看ES某个索引下是否存在日志)发现，ES中并不存在日志，怪不得日志系统搜不到日志

curl -H "Content-Type: application/json" -XGET http://账号名:密码@IP:端口/log-yyyyMMdd/_search -d '{"query":{"match_all":{}}}'

有可能是flume没有收集到日志，然后，就去查看flume是否采集日志配置的地址是否正确

# 查找到flume安装路径
[root@ceshigx1 var]# ls
app.log  app.pid
[root@ceshigx1 var]# pwd
/home/footstone/meta-agent/flume/1.8.0/var
[root@ceshigx1 var]#

查看flume配置的采集日志路径

# 配置的meta-aget采集日志路径
flume2KafkaAgent.sources.r0.filegroups.f1.parentDir=/home/footstone/meta-agent/var/logs/
# 配置的采集日志文件
flume2KafkaAgent.sources.r0.filegroups.f1.filePattern=meta-agent.log

发现采集日志的路径和文件都不正确，这两个路径也是按照一键部署的路径可变，为什么会出错呢，暂时怀疑点就是实施在安装过程中没有严格安装文档安装导致的错误。

更改重启之后发现ES已经可以正常采集日志，但是日志系统查询日志，还是报错索引不存在，那么此时问题就很明白了，业务访问ES配置有问题。

想到会不会是这块日志配置有问题，找来之前负责这块业务的同事，到部署业务的服务器查看配置之后，发现请求ES的地址不对，我们使用一键部署，按道理来说应用的地址应该随着我们配置的中间件地址而改变，但是这块就很奇怪了，地址更改之后，
日志系统查询日志已经可以查询出日志，但是监控大屏依旧日志系统异常，不会吧，日志都能正常搜集查询日志为啥还是异常。

咨询负责这块一键部署的大佬之后，说是ES状态只有绿色（green）才不会异常，赶紧到服务器查看ES状态，执行以下命令：

# 如果配置了ES加密访问 访问格式如下  http://账户:密码@ES装机IP:9200/_cluster/health?pretty
[root@ceshigx1 conf]# curl -XGET 'http://账户:密码@ES装机IP:9200/_cluster/health?pretty'
{
"cluster_name" : "custom-cluster",
"status" : "yellow",
"timed_out" : false,
"number_of_nodes" : 1,
"number_of_data_nodes" : 1,
"active_primary_shards" : 0,
"active_shards" : 0,
"relocating_shards" : 0,
"initializing_shards" : 0,
"unassigned_shards" : 20,
"delayed_unassigned_shards" : 0,
"number_of_pending_tasks" : 0,
"number_of_in_flight_fetch" : 0,
"task_max_waiting_in_queue_millis" : 0,
"active_shards_percent_as_number" : 86.3013698630137
}

发现ES的状态是yellow状态，怪不得监控大屏现实的异常的，剩下就是如何解决ES的状态问题了，网上查阅资料可知：

单点单节点部署Elasticsearch, 集群状态可能为yellow, 因为单点部署Elasticsearch, 默认的分片副本数目配置为1，而相同的分片不能在一个节点上，所以就存在副本分片指定不明确的问题，所以显示为yellow，可以通过在Elasticsearch集群上添加一个节点来解决问题，如果不想这么做，可以删除那些指定不明确的副本分片（当然这不是一个好办法）但是作为测试和解决办法还是可以尝试的.

因为我们就是单机部署的，所以只能删除解决了，执行以下命令即可：

curl -XPUT "http://localhost:9200/_settings" -d' {  "number_of_replicas" : 0 } '

但是，执行以上命令报错

{"error":"Content-Type header [application/x-www-form-urlencoded] is not supported","status":406}

查阅资料可知，是ES的版本问题

从 Elasticsearch 5.3 开始，通过 http.content_type.required 配置设置就存在这种强制执行严格内容类型检查的能力。在 5.x 中它是可选的，并且默认为 false，在 Elasticsearch 6.0 中，该设置默认为 true，并且无法禁用它。

查看ES版本：

[root@ceshigx1 conf]# curl -XGET 账号:密码@IP:端口
{
  "name" : "middleware",
  "cluster_name" : "custom-cluster",
  "cluster_uuid" : "Tn3iom-6SCSyk5S8jd2UhA",
  "version" : {
    "number" : "6.8.5",
    "build_flavor" : "default",
    "build_type" : "rpm",
    "build_hash" : "78990e9",
    "build_date" : "2019-11-13T20:04:24.100411Z",
    "build_snapshot" : false,
    "lucene_version" : "7.7.2",
    "minimum_wire_compatibility_version" : "5.6.0",
    "minimum_index_compatibility_version" : "5.0.0"
  },
  "tagline" : "You Know, for Search"
}

根据ES官网要求，请求ES需要添加正确的请求类型，更改如下请求即可：

curl -XPUT -H'Content-Type: application/json' "http://用户:密码@ES装机IP:端口/_settings" -d' {  "number_of_replicas" : 0 }'

执行结束查询ES状态，已经更改为绿色，但是回到监控大屏日志系统的状态好还是异常，后来和同事沟通下，去查看监控大屏的日志，果然报错了，
在一个定时任务业务中，处理获取ES状态的代码中，String截取数组越界异常，嗨，找了一大圈最后最后竟然是因为这块，其实，经过这一圈下来，之前没有接触过日志系统的我，现在对整个日志系统也有了一个初步的认识了，所以，遇到困难多和同事大佬沟通不仅事半功倍还能让多学习大佬解决问题的思路。

记一次日志系统异常问题排查