ELFKELFK几个常见问题记录持续更新

前言

主要记录一些使用ELFK过程遇到的问题以及相关解决方案

logstash报错maximum normal shards open-2022年06月23日更新

故障现象

发现部分收集项未创建当日索引。查看logstash日志发现上述报错

故障原因

这是因为集群最大shard(分片)数不足引起的，从Elasticsearch v7.0 开始，集群中的每个节点默认限制1000个分片。我这边用的8.0的提示是4000个分片。

故障处理

方案1、在elasticsearch.yml中定义

cluster.max_shards_per_node: 10000

方案2、在kibana控制台开发者执行（我采用了这个在线更新方式）：

PUT /_cluster/settings
{
  "transient": {
    "cluster": {
      "max_shards_per_node":10000
    }
  }
}

方案3、在linux控制台执行：

curl -XPUT http://localhost:9200/_cluster/settings \
-u elastic:password \
-H "Content-Type: application/json" \
-d '{"transient":{"cluster":{"max_shards_per_node":10000}}}' 

elasticsearch升级要求

es最近从7.16.3更新至8.0.0.0，记录一些常见的问题以及解决方案。
参考官网

To upgrade to 8.0.0 from 7.16 or earlier, you must first upgrade to 7.17. This enables you to use the Upgrade Assistant to identify and resolve issues, reindex indices created before 7.0, and then perform a rolling upgrade.
Upgrading to 7.17 before upgrading to 8.0 or later is required even if you opt to do a full-cluster restart of your Elasticsearch cluster. Alternatively, you can create a new 8.0.0 deployment and reindex from remote. For more information, see Reindex to upgrade.
Beats and Logstash 7.n are compatible with Elasticsearch 8.0.0 to give you flexibility in scheduling the upgrade.

es要求先升级到7.17再升级到8.0, logstash|kibana|filebeat直接更新到最新版本没有问题。

elasticsearch io变高，报错SearchPhaseExecutionException: all shards failed

故障现象

测试环境es切流过程中，想导出历史index数据，发现导出的过程中hang住，以及随着时间流逝，elasticsarch的io持续增加，查看es日志有大量错误日志 ，过滤后主要为SearchPhaseExecutionException: all shards failed

故障原因

自行排查后无果，网上看到一则相关案例处理
实际为有部分索引的数据损坏了，es自检一直往日志文件中写导致io过高

故障处理

# 查看索引数据正常率，发现正常率 竟高达16%，直接BBQ好吧
curl -u elastic:changeme  -XGET 'http://172.25.0.2:9200/_cluster/health?pretty=true' |grep active_shards_percent_as_number
# 查看所有索引状态
curl -u elastic:changeme "http://172.25.0.2:9200/_cat/indices?v"
# 状态介绍
## 响应信息中最重要的一块就是 status 字段。状态可能是下列三个值之一：
## green
## 所有的主分片和副本分片都已分配。你的集群是 100% 可用的。
## yellow
## 所有的主分片已经分片了，但至少还有一个副本是缺失的。不会有数据丢失，所以搜索结果依然是完整的。不过，你的高可用性在某种程度上被弱化。如果 更多的 分片消失，你就会丢数据了。把 yellow 想象成一个需要及时调查的警告。
## red
## 至少一个主分片（以及它的全部副本）都在缺失中。这意味着你在缺少数据：搜索只能返回部分数据，而分配到这个分片上的写入请求会返回一个异常。
# 于是写了个脚本，删除所有状态为red的索引
user=elastic
auth=changeme
es_post=172.25.0.2:9200
list=`curl -u $user:$auth "http://$es_post/_cat/indices?v" |grep red |awk '{print $3}'`
for index in $list ;do
        echo $index
        #确认没问题后取消注释删除状态为red的索引
        #curl -u $user:$auth -XDELETE http://$es_post/$index
done

改进措施 （衍生）

1.需要增加对index状态监测告警
2.定时删除历史index日志

elasticsearch初始化内置用户密码

# 通过交互式自定义密码
/usr/share/elasticsearch/bin/elasticsearch-setup-passwords interactive
# 随机生成用户名密码，若为集群，其他节点的密码也同步更新
/usr/share/elasticsearch/bin/elasticsearch-setup-passwords auto --batch > pass.txt

elasticsearch SSL加密

#创建密钥库 回车默认生成elastic-stack-ca.p12，再回车自定义密码
/usr/share/elasticsearch/bin/elasticsearch-certutil ca 
#根据密钥库创建私钥，回车默认生成elastic-certificates.p12  再回车自定义密码
/usr/share/elasticsearch/bin/elasticsearch-certutil cert --ca elastic-stack-ca.p12
#如果elasticsearch为集群，则需要将elastic-certificates.p12传到集群中的每一个节点的/etc/elasticsearch/下
#并在每一个节点配置中添加下列信息，
xpack.security.transport.ssl.enabled: true
xpack.security.transport.ssl.verification_mode: certificate
xpack.security.transport.ssl.keystore.path: elastic-certificates.p12
xpack.security.transport.ssl.truststore.path: elastic-certificates.p12

kibana

注意：可以在 Kibana 中配置基于角色的访问控制,即创建角色和用户后，使用不同的用户登录只能看到自己被授权的部分；

kibana用户密码加密

采用密文的方式进行认证，认证之前，需要首先将用户名密码保存到内置的ketstore里。

/usr/share/kibana/bin/kibana-keystore create
#执行后输入用户名
/usr/share/kibana/bin/kibana-keystore add elasticsearch.username
#执行后输入密码
/usr/share/kibana/bin/kibana-keystore add elasticsearch.password
#添加后则需要在配置文件中注释下列参数，并且用户名不能为elastic
#elasticsearch.username: "kibana"
#elasticsearch.password: "asdsaccc"

kibana xpack加密

/usr/share/kibana/bin/kibana-encryption-keys generate

xpack.encryptedSavedObjects.encryptionKey
    Used to encrypt stored objects such as dashboards and visualizations
    https://www.elastic.co/guide/en/kibana/current/xpack-security-secure-saved-objects.html#xpack-security-secure-saved-objects

xpack.reporting.encryptionKey
    Used to encrypt saved reports
    https://www.elastic.co/guide/en/kibana/current/reporting-settings-kb.html#general-reporting-settings

xpack.security.encryptionKey
    Used to encrypt session information
    https://www.elastic.co/guide/en/kibana/current/security-settings-kb.html#security-session-and-cookie-settings

Already defined settings are ignored and can be regenerated using the --force flag.  Check the documentation links for instructions on how to rotate encryption keys.
Definitions should be set in the kibana.yml used configure Kibana.

Settings: 
# kibana.yml配置中添加下列信息
xpack.encryptedSavedObjects.encryptionKey: 9dc6a8d1b3a266ffeaae796b11e7067e
xpack.reporting.encryptionKey: 759d1ef3231e0e141b24b00d20d962df
xpack.security.encryptionKey: ff3c97233e6962a85aa5768b0b16f875

这篇好文章是转载于：学新通技术网