#ELK #ElasticSearch #Kibana

本文不是Step by Step教程文章，是我个人在搭建大型elk系统中遇到的一些问题，只建议相关从业者参阅。

问题一、Logstash 配置后疑似日志疑似没有向ElasticSearch推送

在使用

curl http://192.168.60.3:9200/_cat/indices?v 
注：如果es集群有用户身份认证，应该加上 -u uid:password 参数，如果启用了SSL，原则上应该再带上 -k 参数
以下同。

查看ElasticSearch中存在的索引时，发现相关的索引数据量一直没有增长，怀疑是Logstash没有往ElasticSearch推送数据。

经查为索引没刷新，可以通过

curl http://192.168.60.3:9200/_all/_flush 

刷新相关索引后重新关注数据量增长情况。发现 Logstash 在稳定推送数据。

问题二、Elastic 数据量不断增大，可能占满服务器磁盘空间

使用

curl -XDELETE http://192.168.60.3:9200/firewall-v4-2021.10.19 

形式的命令可以删除创建时间较久的索引。

注：ILM也可以实现索引的生命周期管理，具体参阅问题11

问题三、数据推送到 Elastic 后，在 Kibana 的 Discovery 与 Dashboard 界面无法看到相关索引

7.15.1 版本 Kibana，需要在
Manage/Kibana/IndexPattern 下添加数据索引模式。之后可以在 Analytics/Discover 以及
Analytics/Dashboard/CreateVisualization 调用索引模式

问题四、关于KQL指令

多条件连接： and, or

在指定字段中搜索： fieldname: search-pattern

举例：以下指令搜索device字段包含4J-3，Action字段为Permit的文档数据： device: 4J-3 and Action: Permit

注：在elastic search中，分词可能会有一定规则，比如某条日志中包含以下文本：10NAT/6/NAT_FLOW，那么要检索出该条日志，使用NAT这一关键字可能无法准确选取出该日志，应该该日志可能按照斜杆分词，却可能不会按照下划线分词，因此：你使用10NAT, NAT_FLOW 可以检索，单纯使用NAT作为关键字却无法检出该日志。另外，在KQL中可以在关键字首尾使用*通配符号。而多个关键字用空格分隔时，其关系为 或

问题五、ETL的系统架构模式

Logstash: 收取并清洗日志，向Elastic推送日志，其中，需要在Logstash配置文件中的 output 节设置相关的推送参数。

Elastic: 需要设置一系列参数

- 如 sysctl -w vm.max_map_count=262144 增大系统资源，调增docker的CPU及内存数量（如果有限制的话）

- 系统启动后，如果Elastic为单机模式，需要设置以下参数：1)设置副本数量为0，否则系统上所有索引会显示为Yellow状态。相关命令：

curl -XPUT "http://192.168.60.3:9200/_settings" -d "{\"number_of_replicas\":0}" -H "content-type:application/json"

Kibana: 需要设置ElasticSearch节点或者集群相关信息。配置：kibana.yml 文件

问题六、ELK时间戳问题

在 logastash 与 ElasticSearch 中，时间戳所在的时区均为UTC时区，而在Kibana默认使用用户浏览器时区，也就是说：

- Logastash 在生成日志时间戳时，无论你服务器所在的时区是什么，它均为转换为UTC时区。如日志默认的 "@timestamp" 时间戳。

- ElasticSearch 如果收到的时间戳类型的数据如果没带时区，其会直接转换为距离1970年1月1日0时0分的毫秒数存储到数据库中，如果带了时区，其会转换为UTC后，再按照距离1970年1月1日的毫秒数存储到数据库中，也就是说，如果我们在Logstash中对时间戳进行了处理，比如增加了8个小时，并保存在"cstts"这个字段中，这条日志传输到Elastic后，由于没带时区，cstts 这个字段的时间戳不会被修改，但到Kibana后，系统会按照你浏览器的时区对时间戳进行调整，也就是说：你没有做处理的"@timestamp"时间戳反而是对的，经处理的cstts这个时间戳反而快了8个小时。因此，在纯粹的ELK系统中，无须对时间戳做特别处理，由系统内部处理，时间就是会是正常的。

我个人的实践是在LOGSTASH特定增加两个字段，用于保存UTC及CST时间戳，以便ES及本地保存时无视日志中包含的时间戳，这样虽然存储日志的时间可能与日志事件发生的时间有所不同，但能够确保文件在保存时的时间保持一致性。使用Ruby处理，相关代码

filter{  mutate{  }  ruby{
    code => "      event.set('utc', Time.now.getutc)      event.set('cst', Time.now.getutc + 8*60*60)      cst = Time.now.getutc + 8*60*60      pathstr = cst.strftime('%Y-%m-%d/%H')      indexstr = cst.strftime('%Y-%m-%d')      event.set('pathstr',pathstr)      event.set('indexstr',indexstr)    "  }
  date{    match => ["timestamp","MMM d HH:mm:ss", "MMM d HH:mm:ss YYYY", "ISO8601"]  }}

其中：pathstr为格式化的本地日期+小时，indexstr为本地化的日期，主要为了保持在ES与LS本地存储日志时间的统一性。在output节中相关代码如下：

output{  elasticsearch{    hosts => ["es1:9200"]    index => "raw-%{indexstr}"    ssl => true    cacert => "/usr/share/logstash/config/cert/elastic-stack-ca.pem"    user => "elastic"    password => "xxxxx"  }}

问题七、在Kibana的Dashboard中，索引模板的部分字段为空字段。

这个具体原因还没有找到，依据系统相关文档的解释，貌似如果索引中的前500个文档中未在该字段找到足够数据包含该字段的话，该字段就会被标记为空字段。但我在实测中，实际上每个字段都存在相关数据，但有的字段被标记为空字段。空字段无法在dashboard中引用及画图

问题八、Kibana Web端不停报警安全功能未启用：Warning299

有两种方法处理该问题，一是在Elastic的相关配置：elasticsearch.yml 中显示关闭xpack安全功能，二是对Elastic启用安全功能，如开启用户名和密码认证，SSL传输等。

方法一：在 ElasticSearch 配置文件：elasticsearch.yml 中添加如下指令：

x-pack.security.enabled = false ，并重启Elasic集群。不过需要注意确认Elastic启动时所用的配置文件，可能不是elasticsearch/config/下的配置文件，可通过： pe -ef | grep elastic 的命令行参数确认。

问题九、通过docker启动ELK系统

<pre> docker run -tid -p 5601:5601 -p 5044:5044 -p 9200:9200 -p 9300:9300 \    -v /root/data/es/conf/kibana.yml:/opt/kibana/config/kibana.yml \    -v /root/data/es/data:/var/lib/elasticsearch \    -v /root/data/logstash/config:/opt/logstash/config \    --restart=always --name elk sebp/elk</pre>

通过 -v 参数将ELK所需配置文件，数据目录投递到容器

P.S. 如果要启用安全功能，使用一键运行的elk就不太方便调试了，可以参考 [[DOCKER环境下ELK部署及安全设定]]这篇文章拉取Elastic官方docker镜像进行安装。

注：这篇文章不是 Step by Step 的教程文章，有些遗漏的地方，因此也只适合相关从业者参考。

问题十、Elastic 返回指定字段

<pre>curl http://url/index/_search?q=abc&_source=fieldA,fieldB,fieldC_search?q=keyword&filter_path=hits.hits._source&_source=fields_spec其中：filter_path为只返回指定路径</pre>

问题十一、关于ILM（索引生命周期管理）

顾名思义，索引生成周期管理是针对Elastic Search 索引的，主要功能是两项：数据的冷、温、热分离；数据的保存期限设置。注意：ILM的相关策略是在索引上生效，而不能在索引模板以及索引模式上生效。

索引模板主要用于控制索引在**创建时**的一些行为：主要作用有两项目，一是应用ILM策略，二是应用一些字段转化规则，比如某个字段转化为数字，某个字段进行分词诸如此类。索引模板只针对后面新建的索引生效。

索引模式用于概括名称符合一定规则的索引，比如在Kibana的Discover以及DASHBOARD中，需要创建索引模式，以告诉Kibana应该在哪些索引中搜索数据，在前述索引模板中，也需要创建索引模式以告诉Elastic哪些索引在创建时要套用模板中的规则。

在索引模板设置中引用ILM策略：

<pre>{  "index": {    "lifecycle": {      "name": "store-30d"    }  }}</pre>

问题十二、使用LOGSTASH自动创建索引时，自动生成的字段类型不匹配导致部分日志入库失败

在 logstash output 相关配置中指定 index 相关配置项后，如果相关索引不存在，系统会自动创建相关索引，而索引字段类型是通过首次推送的数据推断而来的，因此，如果LOGSTASH 系统从多个数据源获取日志时，可能导致部分日志的部分字段类型不统一，从而导致部分日志无法入库。解决办法：

在索引模板中约束相关字段的类型，而拒绝ES在创建索引时自动推断字段类型。在Kibana里面，通过 Management/Index Management/Index Templates/ 创建相关的索引模板，并在MAPPINGS 选项中，为容易出现问题的字段添加类型（最好为Text，这样兼容性更强一点），这样，系统在创建索引时，会自动以模板中的类型替代自动推断。

注：关于索引模板的相关使用，可以查看 **问题11** 中相关说明。