扩展汇总

ELK案例：

bash
# 1、ES故障及没有数据排查技巧
1、查看服务配置文件，所有服务都适用
   [root@elk01 ~]#systemctl cat elasticsearch.service  
   [root@elk01 ~]#egrep -v "^#|^$" /etc/elasticsearch/elasticsearch.yml
2、实时查看ElasticSearch服务的日志，所有服务都适用
   [root@elk01 ~]#journalctl -u elasticsearch.service -f
3、查看日志观察详细的日志信息
   [root@elk01 ~]#tail -f /var/log/elasticsearch/oldboyedu-linux98-single.log 
4、手动启动ES服务
   观察是否有错误信息输出，如果直接kill，则可能是内存不足导致。
   具体操作如下:
   [root@elk91 ~]# vim /etc/elasticsearch/jvm.options
   ...
   -Xms256m
   -Xmx256m
5、尝试清空数据
   [root@elk91 ~]# rm -rf /var/{log,lib}/elasticsearch/*


# 2、Kibana如果查询不到数据，排查方法
1、Filebeat端存在问题的可能性:
   - filebeat挂掉无法采集数据;             
   - 配置文件和实际采集的数据不对应;          # 看配置文件填写的路径
   - 源数据文件为空，未能写入;               # 查看采集的数据文件
   - 数据已经采集过了，本地缓存offset未清空;  # rm -rf /var/lib/filebeat
2、logstash和Filebeat同理，也会存在类似的问题。
3、ES集群挂掉，导致kibana无法查询数据;
4、kibana的时间选择有问题，也会查询不到数据;
5、kibana做了KQL数据过滤，也可能导致数据查询不到;
kibana的索引被删除，索引模式不生效;


# 3、Kibana登录出现Kibana server is not ready yet解决办法：
1、先做ES集群检查,看是否正常
   http配置检查curl http://10.0.0.91:9200/_cat/nodes,
   https检查curl https://43.139.47.66:9200/_cat/nodes?v  -u elastic:H6KrryuAfO03nP33NPVn -k
2、查看配置文件
   密码是否配置正确
   yml格式缩进
   配置内容问题


# 4、ELK之Kibana出图展示没有数据案例：
之前kibana在出图展示统计指标跟做map地图分布的时候，查询都是正常的，但是上图展示没有值，经过查阅资料发现ES是由数据类型的概念的
，原来这个存放数字的字段的数据类型是text的，还一个就是经纬度被解析到两个字段里面了，导致地图没有点位信息，需要创建个索引模板，
将原本数据类型映射成符合要求的数据类型，之后就可以顺利出图展示了

# 解决办法：
在kibana出图的时候要注意，如果是数字是字符串是不能进行运算的，需要在索引管理-索引模板中设置映射，将字符串转换成数值类型的
地图坐标点，需要geoip.location映射成地理左边点，要不自动默认经纬度分为两个字段
怎么看字段属于哪个类型？在索引管理节点，点索引名称，点映射可以看到

Es对比Kafka：

Kafka 术语	Elasticsearch 术语	相似点	关键差异点
Broker	Node	集群的基本工作单元/节点。	Kafka Broker 主要负责消息传递；ES Node 负责数据存储、索引和搜索。
Kafka Cluster	ES Cluster	多个节点组成的集合，共同工作。	目标不同：消息流处理 vs 数据检索。
Producer	(Indexing Client)	向系统写入数据的客户端。	ES 写入通常称为“索引文档”。
Consumer	(Search Client)	从系统读取数据的客户端。	ES 读取主要是搜索查询；Kafka 是顺序/实时消费消息流。
Topic	Index	数据的逻辑容器/分类单元。 生产者和消费者操作的核心入口点。	核心相似点！ Topic 是消息流；Index 是文档集合。Topic 本身不存储最终状态，只传递消息；Index 是持久化存储数据的最终目的地。
Partition	Shard (Primary)	数据水平拆分的基本单位。 实现并行处理、扩展性和负载均衡的关键。	核心相似点！ Kafka Partition 是消息流的有序子集；ES Shard 是索引的子集（Lucene 索引）。Topic 的 Partition 数影响并行消费能力；Index 的 Shard 数影响并行读写/搜索能力。
Offset	Document _id	唯一标识分区/分片内一条数据的机制。	核心相似点（定位数据）！ Offset 是分区内严格递增的序列号（位置），标识消息顺序；_id​ 是文档在分片内的唯一标识符（可以是任意值，不隐含顺序）。
Replica	Replica Shard	数据的冗余拷贝，提供高可用性和容错能力。	核心相似点！ 都用于故障转移。
Leader Replica	Primary Shard	处理读写请求的主副本。	Kafka Consumer只从 Leader Replica 读取；ES 读写请求可以发送给任何包含相关分片的节点，但最终由 Primary Shard 协调索引操作。
Follower Replica	Replica Shard	异步复制 Leader 的数据，作为热备份。 Leader 失效时提升为新 Leader。	Kafka Follower Replica不服务 Consumer 读请求；ES Replica Shard可以服务读请求（搜索）。

bash
# 5、企业级ELFK+KAFKA架构设计方案
公司已经部署好了浪潮品牌的11台Elasticsearch集群，当时版本是6.8(现在是7.17.28），当时网站经常会被盗链，有时周二，有时周五，
会定时的攻击我们，有时候会多出30多个T的流量，所以这时候要拿日志做日志分析，部署了2台logstash服务器，分别是32核，32GB内存，8T
*12的硬件配置，都是浪潮的牌子，前面是部署了18台WEB服务器，都部署了Nginx，在上面都部署了filebeat，然后部署了5台Kafka集群，也
都是是32核，32内存，8T*12的硬件配置，然后我们Web服务器的日志通过filebeat打到了kafka集群中，然后logstash去kafka集群采集数
据，做一个简单的日志分析，早期是没有部署kafka的，是由filebbeat直接打到logstash，直到发现logstash不够用，会经常崩掉，18台服务
器同时打的时候OOM了，32核根本扛不住，所以在前面又部署了kafka集群，然后部署kibana，通过ES集群采集日志，在上面做些IP、PV、带宽统
计、全球用户分布、用户设备类型的图，进行分析，然后开发感觉kibana难用，我又部署了Grafana去采集数据展示，我们的架构用的是GO语言，
从kafka集群消费数据后，交给ES集群，然后往ES集群去存，Kibana过ES集群去采集数据进行分析。ES集群的工作日每天的数据量是1.5TB，非工
作日的数据量是2.7TB，过滤出的有效数据，Nginx的LUA语言的鉴权日志，也可以打到ES集群；


还有一份数据，是我另外一个同事负责的架构，他是单独用flume单独用了一台机器，也是32核，32内存，8T*12的硬件配置去采集，是通过
flume去kafka集群采集WEB日志，然后写到HDFS集群，然后去做处理，开发人员通过跑MapReduce、Spark，黑名单的用户，禁止登录的，会
去HDFS采集日志，去分析黑名单用户日志，开发人员会去Kafka集群消费数据，通过Flink分析，将结果写入到分布式数据库集群，硬件配置是
64核心，256G内存，8T*12的硬件配置，ClichHouse，用的是Ubuntu系统，然后通过开源的图形化界面SuperSet去展示，做报表数据，十分
钟一次出一次报表；

‍