1. 项目概述与整体方案设计
1.1 为什么要在Rocky 9.4上搭ELK
日志分析这件事，只要是跑业务的服务器，基本都绕不开。服务器一多，靠着tail -f逐个翻日志的日子就过不下去了。ELK这套组合——Elasticsearch负责存储和检索，Logstash负责采集和清洗，Kibana负责可视化展示，十多年来一直是日志管理领域的事实标准。
Rocky 9.4作为RHEL 9系的衍生版本，因为和上游完全二进制兼容，又是社区维护免费使用，这两年在中型互联网公司和传统企业的服务器环境里普及率相当高。用Rocky 9.4作为ELK的运行环境，一方面能享受到RHEL系生态的稳定性和长期维护周期，另一方面9.x内核和glibc版本对Java系的Elasticsearch支持也很好，不用像在老版本系统上那样为了兼容性折腾一堆依赖库。这套环境适配的是这类需求：你手上有若干台服务器，日志分散在各处，想要一个集中式的日志查询入口，同时希望保留原始日志的完整现场，保证排查问题时能翻到第一手资料。
1.2 整套方案的组件角色分工
ELK不是一个单一的软件，它是一套组合管线，每个环节各司其职。Elasticsearch是整个系统的核心，所有日志最终都会变成JSON文档存储在它的索引里，它负责倒排索引的构建和分布式检索，相当于整个系统的“数据库”。Logstash是数据管道，负责从各个来源把日志捞进来，做过滤、解析、格式化，再写入Elasticsearch，相当于“数据搬运工+清洗工”。Kibana是前端的可视化层，提供Web界面，让你能搜索日志、画图表、配告警，相当于“驾驶舱”。
在实际部署中，还有一个组件几乎成了标配——Filebeat或Beats家族。Logstash本身比较吃内存，每起一个实例都占不少资源，不适合直接跑在每台业务服务器上。Filebeat是一个轻量级的日志采集器，用Go写的，内存占用通常只有几十MB，它会监听日志文件的变化，把新增内容转发给Logstash做集中处理。这套经典架构里，Filebeat在业务端采集，Logstash做解析，Elasticsearch做存储检索，Kibana做展示，四层各司其职。
你也可能会问到Kafka在整套架构里的位置。当业务量极大时（比如每秒几十万条日志），Logstash的处理能力会成为瓶颈，此时会在Filebeat和Logstash之间加一层Kafka消息队列，做削峰填谷和数据缓冲。对于日志量在中小规模的环境，Kafka可以先不引入，单靠Filebeat + Logstash足够扛住日常负载了。
1.3 版本选型与依赖关系
版本搭配是这套部署里最容易踩坑的地方。我这次选择的是当前比较稳的组合：Elasticsearch 8.10.x + Logstash 8.10.x + Kibana 8.10.x + Filebeat 8.10.x。四个组件统一大版本号，这是Elastic官方给出的兼容性要求，混用不匹配的版本经常会出现字段映射错误或者数据写入失败。8.x版本自带安全认证功能，默认开启HTTPS和用户认证，这对现在的网络安全环境来说是个刚需，不像7.x时代需要额外装X-Pack插件。
依赖方面，Elasticsearch 8.x内置了JDK，不需要在系统里再装一套Java环境。但Logstash和Kibana还是会依赖系统中的Java运行环境。在Rocky 9.4上用dnf install java-11-openjdk安装OpenJDK 11即可，这个版本搭配ELK 8.10全家桶是经过验证的。有一点需要提醒，Rocky 9.4自带的JDK可能是17甚至21，虽然高版本JDK在某些情况下也能跑，但为了避免兼容问题，最好显式安装JDK 11。
环境规划也要提前考虑好：这套方案中Elasticsearch节点至少需要4GB可用内存，如果条件允许8GB更稳妥；Logstash分配2GB足够；Kibana 1GB即可；Filebeat内存占用极低，512MB都绰绰有余。如果是单机部署在同一个节点上，建议整机内存不低于8GB，这是底线。
2. 环境准备与基础配置
2.1 Rocky 9.4系统初始化
装ELK之前，系统的初始状态整理一定要做扎实。Rocky 9.4安装完成后，第一件事是更新系统补丁，dnf update -y把内核和基础软件全部升到最新，避免后续装软件时遇到依赖冲突。然后关闭SELinux，或者至少把SELinux设为permissive模式。ELK各组件的端口监听和数据读写方式比较多，SELinux的默认策略会对文件访问和端口监听做限制，如果不懂怎么为每个组件写SELinux策略，直接setenforce 0并修改/etc/selinux/config里有SELinux=disabled，能省掉大量排查时间。生产环境里如果你有安全合规要求，那就要花时间学一学如何为ELK写SELinux自定义策略，但对大多数场景来说，关闭SELinux是最务实的做法。
防火墙的放行规则也要提前想清楚。ELK这套组件涉及的端口主要有：Elasticsearch的9200端口（REST API）、9300端口（节点间通信）、Kibana的5601端口、Logstash的5044端口（接收Filebeat数据）。在Rocky 9.4上做实验时，如果只有一台服务器，也可以直接停掉firewalld，但如果是规范一点的环境，建议按需放行端口，用firewall-cmd --add-port=9200/tcp --permanent这种方式逐项加规则，然后把对公网暴露的端口限制在内网网段。
文件描述符的调整也是Elasticsearch启动前的必备项。ES在运行时会打开大量文件句柄（索引分片文件、日志文件、内存映射文件），系统默认的1024远远不够，直接改/etc/security/limits.conf，增大nofile和nproc的软硬限制。还有一点容易被忽略，ES对vm.max_map_count参数有硬性要求，默认值65530在ES启动时会被检查，低于262144会直接报错。用sysctl -w vm.max_map_count=262144临时修改，同时写入/etc/sysctl.conf让它永久生效。
2.2 JDK安装与相关系统参数
JDK的安装看似简单，但版本选择很关键。我之前在CentOS 7上用过OpenJDK 8跑ES 8.x，结果启动时报了UnsupportedClassVersionError，折腾了很久才反应过来是JDK版本不匹配。这次在Rocky 9.4上，方案是安装OpenJDK 11，命令如下：
dnf install -y java-11-openjdk java -version安装完成后用alternatives --config java确认默认Java版本已经切到11。有些服务器上可能已经装了新版JDK，alternatives命令可以让你在多版本之间切换默认值。这一步做完，顺便把JAVA_HOME写进/etc/profile文件，后面Logstash和Kibana启动时会用到。
内存参数方面，除了前面调整过的内核参数，还要注意swap的使用倾向。ES官方建议尽可能禁用swap，或者在系统层面降低swappiness值。修改/etc/sysctl.conf设置vm.swappiness=1，让内存在压力大时尽量不要用交换分区，因为swap的磁盘IO会成为性能瓶颈。这个参数在日志量大的场景下感受非常明显，开了swap和关掉swap，ES的查询响应时间能差一个数量级。
在8.x版本里，ELK安装包是不需要再单独去配置用户创建和目录权限的。无论是用rpm方式安装还是tar包方式解压安装，官方安装包都会自动创建elasticsearch用户和对应的数据目录。如果你是纯手工从官网下载tar包解压部署，那就要自己创建用户并授权目录。这里推荐直接用rpm方式安装，后续用systemd管理服务会省心很多。
3. ELK核心组件安装与配置
3.1 Elasticsearch的安装与调优
Elasticsearch的安装过程如果通过rpm包来做非常直接。先导入Elastic官方的签名密钥，再配置yum源。在Rocky 9.4上，创建一个/etc/yum.repos.d/elastic.repo文件，写入：
[elastic-8.x] name=Elastic repository for 8.x packages baseurl=https://artifacts.elastic.co/packages/8.x/yum gpgcheck=1 gpgkey=https://artifacts.elastic.co/GPG-KEY-elasticsearch enabled=1 autorefresh=1 type=rpm-md接着执行dnf install -y elasticsearch，安装完成后，主配置文件在/etc/elasticsearch/elasticsearch.yml。在这里设置几个关键参数。
cluster.name: elk-prod node.name: node-1 network.host: 0.0.0.0 http.port: 9200 discovery.seed_hosts: ["127.0.0.1"] cluster.initial_master_nodes: ["node-1"] xpack.security.enabled: true xpack.security.enrollment.enabled: truenetwork.host如果设置成0.0.0.0，表示监听所有网卡接口，这样才能让其他服务器上的Kibana和Logstash连过来。如果是纯本机测试环境，也可以用127.0.0.1。8.x版本默认启用了安全认证，首次启动时会自动生成elastic用户的初始密码，这个密码会打印在启动日志中，需要保存好。启动服务后第一件事就是用这个初始密码登录并修改密码，或者用elasticsearch-reset-password -u elastic重新生成一个。
内存调整是ES调优的核心。编辑/etc/elasticsearch/jvm.options文件，把-Xms和-Xmx都设为物理内存的一半左右，但注意最大不要超过32GB。ES使用堆内存和堆外内存的比例有个经验值：堆内存设4GB，堆外内存（用于Lucene的segment文件缓存）大概需要翻倍的空间，所以给ES节点的物理内存最好在堆内存的3倍左右。如果机器是16GB内存，堆内存给8GB是比较合的比例，剩下的留给系统页缓存和其他进程。
ES启动完成后，用curl -k https://localhost:9200加上用户名密码访问，能看到集群状态为green，说明ES核心已就绪。这里有个小细节：8.x默认启用了TLS加密通信，curl访问时要加-k参数跳过证书校验。
3.2 Logstash的管道配置
Logstash安装同样走yum源，dnf install -y logstash。它的配置文件放在/etc/logstash/conf.d/目录下，一个典型的管道由input、filter、output三个区块组成。以最常见的Filebeat输入、Elasticsearch输出为例：
input { beats { port => 5044 } } filter { grok { match => { "message" => "%{COMBINEDAPACHELOG}" } } date { match => [ "timestamp", "dd/MMM/yyyy:HH:mm:ss Z" ] target => "@timestamp" } } output { elasticsearch { hosts => ["https://localhost:9200"] user => "elastic" password => "yourpassword" index => "nginx-access-%{+YYYY.MM.dd}" ssl_certificate_verification => false } }这里面的设计思路值得展开说说。input区块用beats插件，监听5044端口接收Filebeat转发过来的数据。filter区块用grok插件做日志解析，COMBINEDAPACHELOG是Logstash内置的正则模板，能直接从一行Nginx或Apache访问日志里切出客户端IP、请求时间、请求方法、状态码、响应字节数这些字段。date插件把日志里原有的时间字符串转换成标准的@timestamp字段，这样做的好处是：日志入库后你可以按日志实际发生时间检索，而不是按ES接收到日志的时间。output区块指定ES的地址和索引名规则，按天分割索引的好处后面再细说。
启动方式和ES类似，用systemd管理：
systemctl start logstash systemctl enable logstash这里有一个我在实际配置过程中反复踩的坑：Logstash的配置文件如果写错，启动不会马上暴露问题，因为Logstash会等有数据流经管道时才报错。所以配置完先做语法检查，用/usr/share/logstash/bin/logstash --config.test_and_exit -f /etc/logstash/conf.d/，这条命令能帮你验证配置文件语法是否正确，不会真正启动服务。跑通了再正式启动。
3.3 Kibana的界面配置
Kibana安装和上面两个组件方式一致。关键配置在/etc/kibana/kibana.yml：
server.port: 5601 server.host: "0.0.0.0" elasticsearch.hosts: ["https://localhost:9200"] elasticsearch.username: "kibana_system" elasticsearch.password: "yourpassword"这里有个容易忽略的细节：Kibana连接ES用的是一个专用账号kibana_system，不是elastic超级用户。这个账号在ES启动初始化时已经创建好了，密码需要自己重置。如果你用elastic用户来连接，ES的安全审计日志里会给出警告，而且从最小权限原则来看，也不应该用超级账号跑前端连接。
启动Kibana后用浏览器访问http://服务器IP:5601，看到登录页输入之前设置的账号密码即可进入。
3.4 Filebeat轻量采集端部署
Filebeat的部署模式决定了整个方案的适用范围。我们要在每台需要采集日志的业务服务器上装Filebeat，它负责读日志文件然后转发到Logstash。安装方式还是rpm，但注意Filebeat的yum源和ELK其他组件是同一个源，版本要严格匹配。
Filebeat的核心配置在/etc/filebeat/filebeat.yml，这里以采集Nginx访问日志为例：
filebeat.inputs: - type: filestream id: nginx-access paths: - /var/log/nginx/access.log parsers: - ndjson: target: "" output.logstash: hosts: ["logstash服务器IP:5044"]用filestream类型替代旧的log类型，是8.x版本的新特性。filestream类型的管理状态是独立的，它维护了每个文件的读取位置，即使Filebeat重启或日志文件被rotate，也能从上次的位置继续读取，不会重复也不会漏。这个机制底层是记录每个文件的唯一标识符和当前偏移量到注册表文件里，比老版的log类型在文件轮转场景下可靠得多。
Filebeat配置完后需要filebeat test output测试一下到Logstash的网络连通性，filebeat test config验证配置文件语法。两个测试都通过后再启动服务。
到这里，整套链路已经形成：Filebeat读文件 → 转发到Logstash → 解析处理后写入ES → Kibana查询展示。下面进入实战验证和进阶部分。
4. 数据链路打通与实战验证
4.1 从启动到定位问题的全流程验证
整套环境装完，验证数据链路是否通畅是重中之重。我习惯的验证顺序是由后往前：先确认ES里有数据，再看Kibana能不能查到，最后才是前端写日志测试采集。
第一步，在ES里查看索引是否存在：
curl -k -u elastic:yourpassword https://localhost:9200/_cat/indices?v如果能看到类似nginx-access-2025.01.15这样的索引，说明Logstash已经成功写入数据了。接下来去Kibana操作，打开Management → Stack Management → Index Patterns，创建一个索引模式匹配nginx-access-*，然后在Discover页面查询。这里有件事必须讲清楚：ES里数据虽然已经存在，但Kibana查询时如果找不到索引模式，什么都看不到。
第二步，验证时间字段。ES中存储的数据默认有一个@timestamp字段，这是Kibana做时间筛选的依据。如果你在Logstash的filter中用date插件把日志里的原始时间字符串转换成了@timestamp，那么Kibana的时间轴就会按日志实际发生时间来展示；如果没有做这个转换，@timestamp会以ES接收到数据的时刻为准。这两者在日志延迟传输场景下差别很大，比如网络抖动导致Filebeat的数据延迟发送，日志原始时间和采集时间的差值可能就是几十分钟，排查问题时如果时间轴错位，会让你误解事件顺序。
第三步是端到端测试。在客户端上手动输出一条测试日志到日志文件里，比如echo 'test log entry' >> /var/log/nginx/access.log，然后在Kibana里立刻刷新，如果配置正确，这条日志会在几秒钟内出现在查询结果里。整个链路的延迟通常在1到3秒之间，如果超过5秒还没看到，就要逐步排查哪个环节出问题了。
4.2 Grok正则解析的进阶玩法
Grok是整个ELK里最有技术含量也最折磨人的部分。内置的COMBINEDAPACHELOG模板能覆盖大多数Nginx/Apache日志格式，但实际业务里的日志格式千奇百怪——应用的JSON日志、防火墙的syslog、各种中间件的自定义格式，都需要自己写Grok表达式。
Grok的原理本质上就是把多个命名的正则表达式组合起来。比如要解析下面这行日志：
2025-01-15T10:30:00Z ERROR UserService getUserInfo failed: userId=10023, err=database timeout可以写这样的Grok表达式：
filter { grok { match => { "message" => "%{TIMESTAMP_ISO8601:log_time} %{LOGLEVEL:level} %{WORD:service} %{NOTSPACE:method} failed: %{NOTSPACE:param}, %{GREEDYDATA:error_msg}" } } }拆分出来会得到log_time、level、service、method、param、error_msg这几个字段。写Grok表达式时有几个容易忽略的地方：GREEDYDATA匹配任意字符，它是贪婪的，会把剩余的所有内容都吞掉，所以一般情况下要放在表达式的最后面；NOTSPACE匹配不含空格的字符串，适合用来抓user id这种值；LOGLEVEL已经内置了debug/info/warn/error/fatal这些日志级别的正则，不用自己写。
调试Grok表达式不用一遍遍重启Logstash，直接在Kibana的Dev Tools里就能验证，或者用Elastic官网的Grok Debugger在线工具离线调试，效果一样。真实场景里我都是先在调试器里把表达式跑通，确认能提取出想要的字段，再贴回Logstash配置里，能省去大量重启服务的时间。
4.3 索引生命周期管理与性能优化
日志数据和业务数据不一样，它有很强的时效性。一周前的日志基本只有合规审计时才会去翻，半年后的日志几乎永远不会被查询。如果让索引无限增长，ES的查询性能和磁盘空间都会失控。所以生产环境的ELK一定需要配上索引生命周期管理（ILM）。
ILM的配置分为两个部分。一部分在ES侧，定义策略，比如：索引创建后，在30天时进入删除阶段；或者在热阶段保留7天，滚动到温阶段7天，最后冷阶段再存16天。另一部分在Logstash侧，output块里指定ilm_enabled => true和ilm_policy => "logs_30day_policy"，写完索引后ES会自动按策略执行rollover和删除。
PUT _ilm/policy/logs_30day_policy { "policy": { "phases": { "hot": { "actions": { "rollover": { "max_size": "50GB", "max_age": "7d" } } }, "delete": { "min_age": "30d", "actions": { "delete": {} } } } } }这个策略的含义是：索引在写入数据达到50GB或7天时触发rollover（新建一个索引承接后续写入），索引年龄达到30天后自动删除。这就能保证ES里只保留最近30天的日志，磁盘占用始终可控。
5. 常见问题排查与实战避坑
5.1 组件启动失败的高频原因
整套ELK部署下来，我遇到过的问题能列出一长串，最典型的是这几类。
端口被占用或未监听。ES启动后如果发现连接不上，先用ss -lntp | grep 9200看清端口是否在监听。Rocky 9.4的firewalld默认对很多端口是放行的，但如果你改过端口或者自定义过zone规则，很容易出现外部连不进来的情况。排查思路是：先在本机用curl -k https://localhost:9200测，通了说明ES没问题，再测远程，不通就是防火墙或网络层面的问题。
内存不足导致的两个组件互相挤压。如果你在同一台机器上跑ES和Logstash，它们默认都会申请较大内存。ES默认堆内存为物理内存的一半，Logstash默认是1GB。物理机内存16GB时没问题，如果你用虚拟机跑且分配内存只有8GB，ES就要4GB，Logstash 1GB，再算上Kibana和系统本身，内存压力非常大，系统会频繁使用swap，反应到现象上就是服务启动很慢、查询卡顿。所以单机部署ELK时，一定要在jvm.options里主动调小ES的堆内存，给其他组件留出余地。
5.2 数据采集断流与重复
Filebeat和Logstash之间的断流问题也经常遇到。表现是：日志文件里有新内容，但Kibana里长时间看不到。排查顺序是这样的：先看Filebeat的日志/var/log/filebeat/filebeat，如果出现connection refused，多半是Logstash没有监听5044端口或者防火墙挡了；再测试Logstash的pipeline配置，/usr/share/logstash/bin/logstash --config.test_and_exit确认语法没问题；最后看LS的日志/var/log/logstash/logstash-plain.log，有没有写入ES时报错。
重复采集的情况过去在老版本使用log类型时会遇到，8.x换成filestream类型之后基本绝迹了。但如果你是从老版本升级上来的，注意清理旧的注册表文件/var/lib/filebeat/registry，否则可能出现重复读取的问题。
5.3 时区问题导致的时间错乱
时区问题是我见过最多人踩坑的地方。EFK/ELK体系默认使用UTC时间存储日志。如果你在业务日志的原始时间里带的是中国标准时间（UTC+8），但Logstash解析时没有做时区转换，那么Kibana里看到的时间会比真实时间早8个小时。
解决方式有两种。第一种是在Logstash的date插件中显式指定时区：
date { match => [ "timestamp", "dd/MMM/yyyy:HH:mm:ss Z" ] timezone => "Asia/Shanghai" target => "@timestamp" }第二种比较取巧，在Kibana的Advanced Settings里修改dateFormat:tz为本地时区，但这只是改变了显示层的时间，底层存储仍是UTC。我建议做法是在Logstash层处理好时区，让@timestamp字段就是日志发生时的本地时间，这样后续做聚合分析时不会乱。
5.4 磁盘空间告警与容量规划
日志系统的磁盘消耗速度远超预期。按照经验，一个每秒产生100条日志的服务，每条日志按1KB计算（带完整字段的JSON格式很容易到这个体量），一天的日志量约8.6GB，ES存储需要加上倒排索引和分片副本的膨胀系数，一般是原始日志的1.2到1.5倍，也就是十几GB一天。一个月下来就是300到500GB。所以部署ELK之前，容量规划非常重要。
容量规划的两个关键决定：副本数的设置和保留天数。副本能保证数据安全，但副本会翻倍消耗磁盘。单机环境建议副本数设为0，写入性能还能提升。保留天数通过ILM策略来控制，30天是大多数业务场景的合理值。
磁盘监控也建议提前配置好。ES自带的cat API可以快速查看节点磁盘状态：
curl -k -u elastic:yourpassword https://localhost:9200/_cat/allocation?v如果发现磁盘超过85%使用率，ES会自动把索引设为只读模式来防止写入失败，这是8.x的自我保护机制。此时必须马上清理旧索引或扩容磁盘，否则整个日志采集链路会直接停摆。
6. 进阶优化：引入Kafka后的高吞吐架构
在日志量大、并发高的生产环境里，Filebeat直接对接Logstash的架构有一个天然的瓶颈：Logstash的处理能力决定了整个管道的吞吐上限，一旦Logstash出现GC卡顿或宕机，Filebeat本地的数据就会积压，严重时连业务服务写日志都会被拖慢。
解决方案是在Filebeat和Logstash之间加一层Kafka。架构变为：Filebeat → Kafka → Logstash → ES → Kibana。Kafka的引入主要解决三个问题：削峰填谷（日志产生的峰值流量可以暂存在Kafka里，Logstash按自己的处理能力消费，不会因为瞬时流量过大而崩溃）；解耦（Logstash升级或重启不影响Filebeat的正常采集）；扩展性（多个Logstash实例可以并行消费Kafka的多个分区，水平扩展吞吐）。
如果系统内存低于8GB，不建议在单机上强行加入Kafka。Kafka本身依赖ZooKeeper（或KRaft模式），又会占用1GB到2GB内存，单机资源容易捉襟见肘。但对于日志量达到日均百GB级别的场景，Kafka这一层基本是必须的。
配置上，Filebeat的output需要改成Kafka：
output.kafka: hosts: ["kafka服务器IP:9092"] topic: "nginx-access" partition.round_robin: reachable_only: trueLogstash的input则改成kafka消费模式：
input { kafka { bootstrap_servers => "kafka服务器IP:9092" topics => ["nginx-access"] group_id => "logstash-nginx" codec => json } }加完这一层之后，整套系统的吞吐量就不再受限于单一组件了。Filebeat采集能力、Kafka的磁盘吞吐、Logstash的消费能力、ES的索引吞吐，每一层都可以独立扩容。这也是为什么现在互联网公司的日志系统基本都是这种多层解耦架构。
7. 运维经验与日常保养
ELK接入业务之后，真正的挑战才开始。系统要稳定运行，日常运维方面有几个习惯我是坚持做的。
定期检查集群健康状态是基本功。用curl -k -u elastic:password https://localhost:9200/_cluster/health?pretty看status字段，green是正常，yellow说明有副本分片没分配，red说明有主分片丢失，后两种都需要立刻处理。ES集群的健康状态不像MySQL那样启动后就能长期稳定，它和磁盘空间、节点状态、分片数量都强相关，任何一环出问题都可能导致状态降级。
Kibana的告警功能也建议配置起来。在Stack Management → Alerting里，可以设置索引写入速率低于某个值时触发告警，也能设置磁盘使用率超过阈值时通知。这样不用人肉盯监控面板，ES自己就能报警。
还有一个我踩过的坑：Elasticsearch的默认配置里，字段映射是动态创建的。如果日志格式变化了（比如加了一个新字段），新字段会自动加入索引映射，但如果日志里出现了类型不一致（比如以前user_id是数字，后来变成了字符串），ES会拒绝写入该文档。这个问题在8.x里可以通过配置dynamic: false或者strict来避免，把索引映射固定住。建议在索引模板里把动态字段设为false，只显示你已经明确映射过的字段，这样日志格式变化产生的影响是可控的。
最后再分享一个小技巧：Kibana的Discover页面在应对千万级数据量时，查询响应变慢是很常见的事。如果确认不是ES节点性能问题，可以检查一下查询的filter里是否有对未映射字段的term查询。ES对keyword类型的字段做精确匹配要快很多，如果用text类型的字段做精确匹配，会走全文检索链路，性能差距能有十倍。日志业务里，凡是后续要用于筛选的字段（如日志级别、服务名、用户ID），在创建索引模板时统一用keyword或integer类型，几秒钟的响应时间能压到几百毫秒。
ELK这套系统，本质上是给你一个重新审视自身业务日志的机会。日志采集、清洗、展示这条链路打通之后，你要做的不是守着Kibana看曲线，而是能从海量日志中快速提取出业务问题的根因。部署只是第一步，把索引策略、字段映射、解析规则沉淀成一套标准，才算真正把ELK用好了。
