一、为什么要把面板站点日志汇入 ELK

使用宝塔面板或 1Panel 管理服务器的用户，往往会在一台机器上跑多个站点。站点日志默认按域名分散在各自目录中，排查问题时需要在多台服务器、多个文件之间来回切换，既无法做跨站点的关联分析，也难以长期留存。把这些日志统一采集到 ELK（Elasticsearch、Logstash、Kibana）平台后，可以在一个界面里按域名、服务器、状态码、请求路径等维度检索全站访问与错误记录，同时借助索引生命周期管理控制磁盘占用。

需要强调的是，ELK 本身不改变 Web 服务器的工作方式，它只是把已经写好的日志文件搬运、解析并建立索引。因此接入的前提是站点日志保持正常写入、可被采集进程读取。

二、整体架构与组件分工

• Filebeat：部署在每台 Web 服务器上，负责读取宝塔或 1Panel 的站点日志文件，并推送到下游。资源占用低，适合与面板共存。
• Logstash：接收 Filebeat 数据，完成字段解析、字段补充、清洗与格式化，再写入 Elasticsearch。也可以由 Elasticsearch 的 Ingest Pipeline 承担部分解析工作。
• Elasticsearch：存储并建立倒排索引，支撑全文检索与聚合统计。
• Kibana：提供检索界面、可视化图表与仪表盘。

如果规模较小，也可以省略 Logstash，直接用 Filebeat 加 Ingest Pipeline，减少一层组件和运维成本。

三、日志来源梳理：宝塔与 1Panel 的日志位置

3.1 宝塔面板

宝塔的站点访问日志通常存放在站点日志目录下，按域名区分，一般同时存在访问日志与错误日志两类文件。面板自身的操作日志、计划任务日志则位于面板安装目录的日志路径中。接入前建议在面板文件管理器中确认实际路径，并以服务器上的真实路径为准。

3.2 1Panel

1Panel 的站点由 OpenResty 提供服务，站点日志一般位于 OpenResty 应用的站点目录下，同样按域名划分 access 与 error 日志。1Panel 自身的运行日志位于面板安装目录的日志文件夹中。不同安装方式与版本可能存在路径差异，配置采集前需实际核对。

除站点日志外，还可以按需接入 PHP 慢日志、MySQL 慢查询日志等，但建议分索引存放，避免与访问日志混在一起影响检索效率。

四、用 Filebeat 采集面板日志

在每台 Web 服务器上安装 Filebeat，配置一个或多个输入源，指向站点日志目录下的通配路径。多站点场景下，通配符可以一次性覆盖全部域名日志，省去逐个站点配置的麻烦。

配置时重点处理以下几件事：

1. 按站点打标：利用文件名或路径信息，为每条日志附加域名标识，便于后续按站点过滤。
2. 区分主机：开启主机名、IP 字段，多机部署时才能定位日志来源。
3. 处理日志轮转：宝塔与 1Panel 都可能按天切割日志，需确认切割后的历史文件是否仍被采集，必要时在输入路径中显式包含压缩文件。
4. 读取权限：Filebeat 进程需要具备读取日志文件的权限。以普通用户运行更安全，但需确保该用户对日志目录有读权限。
5. 断点续传：保持注册表文件持久化，避免重启后重复采集或漏采。

五、Logstash 解析与字段标准化

Nginx 与 OpenResty 的默认访问日志通常包含客户端 IP、时间、请求方法、URL、状态码、响应体大小、Referer、User-Agent 等字段。可以在 Logstash 中通过 grok 或 dissect 过滤器将其拆分为独立字段，这样在 Kibana 里就能直接按状态码聚合、按响应大小排序，而不只是做字符串匹配。

常见的处理动作包括：

• 将时间字段替换为日志中的真实时间，保证时间轴准确；
• 把状态码、响应时间、字节数转换为数值类型，便于做范围查询与统计；
• 从 URL 中提取路径部分，去掉查询字符串或将其单独保留；
• 统一补充站点域名、服务器标识、环境标签等元数据；
• 对无法解析的行保留原始内容，避免日志丢失。

错误日志的结构与访问日志差异较大，建议使用独立的解析规则与索引，避免规则互相干扰。

六、索引设计与保留策略

建议按用途拆分索引，例如访问日志、错误日志、面板操作日志各自独立。命名上采用带日期的方式，配合索引生命周期策略实现自动滚动与过期删除，防止磁盘被长期占满。分片数量不宜过多，小规模日志量使用默认设置即可，分片过碎反而增加集群负担。

如果对成本敏感，可以调整副本数、压缩存储，或对历史数据降低刷新频率。

七、在 Kibana 中做全站检索

索引接入后，常见的检索场景包括：

• 按域名或服务器筛选，查看某个站点的全部请求；
• 按状态码聚合，快速发现 4xx、5xx 的异常波动；
• 按 URL 路径检索，定位某个接口或页面的访问情况；
• 按客户端 IP 检索，排查异常来源；
• 跨站点搜索同一类错误关键词，例如数据库连接失败、上游超时等。

把这些查询保存为可视化面板，可以形成站点健康度总览，日常巡检时无须逐台登录服务器。

八、常见问题与注意事项

• 路径写错：面板版本或安装方式不同会导致日志路径不同，务必先在服务器上确认。
• 时间不一致：服务器时区与日志时间格式需要统一处理，否则时间轴会出现偏移。
• 权限不足：采集进程无法读取日志是接入失败最常见的原因之一。
• 日志量过大：静态资源、健康检查与爬虫请求会显著放大日志体积，可在采集或写入阶段做过滤。
• 敏感信息：URL 中可能携带令牌、手机号等信息，入库前应考虑脱敏。
• 面板性能：采集进程应限制资源占用，避免与站点争抢 CPU 和磁盘 IO。

九、上线建议

建议先在单台服务器、单个站点上完成采集、解析、检索的完整链路验证，确认字段与时间无误后，再通过统一模板批量推广到其余服务器与站点。推广过程中保持配置一致，便于后续维护。日志接入是一项持续性工作，字段规范和索引策略一旦确定，应形成文档并定期复盘，避免随着站点增加而逐渐失控。