主要针对7.6版本的测试用例及文档说明

资料 https://www.elastic.co/guide/index.html

最好官网看对应版本的英文版，避免版本问题（中文版存在更新不及时的问题）

注意elk需要版本配套使用！

适合单纯的文件收集，go编写，轻量级不怎么影响主服务。

1. harvester 日志收集者
   1. 主要由收集端和发送端组成
   2. 一个文件一个harvester监控，并保持文件打开的状态，防止文件移动、重命名问题
   3. 有一个master统一管理调度（猜测），每隔一段时间会重新检查下是否有新文件
   4. 如果有一个文件超过一定时间没有更新（默认5分钟），harvester将会被回收
   5. harvester记录每个文件的最后的读取位置、最后成功发送位置，万一发送端出问题再恢复，可以从上一次发送成功的位置继续处理。
   6. harvester运行时信息存在内存里，保证并定时刷新到磁盘
   7. 至少一次发送，保证数据不会丢失
2. 配置
   1. name 默认是主机名，只是作为一个来源标志
   2. tags 标签，可以把几个分为一类
3. 注意点
   1. 发送端异常：由于记录的是发送位置，存储消耗低，对机器本身影响不大。
   2. elk只是个组合案例，实际可以直接发es，甚至直接接kibana都OK
   3. 只会采集换行符前的内容：即最后一行不会被采集。

作为信息过滤、格式化工具。java，内存消耗高

1. 原理
   1. input → filter → output
   2. 存储
      1. 默认情况下，Logstash使用内存有限队列在管道阶段之间（输入→过滤器和过滤器→输出）来缓冲事件，如果Logstash不安全的终止，则存储在内存中的任何事件都将丢失。
      2. logstash持久化队列：持久化到磁盘上
         1. 开启持久化队列的数据流：input → queue → filter + output
         2. 异常情况：磁盘异常、机器故障
         3. 输入端需要支持发送确认机制，才能保证数据无丢失，如各种beat；而 tcp, udp, zeromq push+pull 等则不支持
         4. 至少一次发送，保证数据不会丢失。直到output完成，才会标志成功。
      3. 队列满的时候，不再接受数据：每一个输入都有一个任务单独处理，此时不再接受新的连接，以阻止流入Logstash的数据。 这种机制有助于Logstash在输入阶段控制数据流速率，而不会像Elasticsearch这样压倒性的输出。
      4. 存储由一系列页组成，一页为一个文件。当页中的所有消息都被回应（标志为ACKed），才能被删除。
   3. 死信队列
      1. 针对es, 还可以设置死信队列，专门针对400/404返回的情况（无法重试）
      2. 默认
2. 配置

queue.type: persisted
queue.max_bytes: 4gb

3. 注意点
   1. 发送端异常：内存存储会丢数据，磁盘应该也有个上限。
   2. elk只是个组合案例，实际可以发给db等
4. 疑问
   1. 不考虑过滤数据，如果filebeat直接发给es，感觉也可以？

搜索引擎，基于lucene。 java，内存大户

1. 原理 1. 2.
2. 注意点
   1. 每个pipeline 处理的数据来源最好是不一样的
   2. 配置多个插件有先后顺序，前一个失败或卡住，就不会走到下一个
   3. 通常的用法就物理内存的一半，且不超过32G，具体原因参考
      • https://elasticsearch.cn/question/3995
      • https://www.elastic.co/cn/blog/a-heap-of-trouble
3. 疑问 1.

可视化工具

组合案例 https://www.cnblogs.com/qingqing74647464/p/9378385.html

filebeat打到redis为队列

如何知道 logstash 有没有接收到输入