📚 课程目录第3章创建第一个定时搜索

第3章：创建第一个定时搜索

好了，上一章聊了定时任务的基础概念和调度原理。这一章咱们直接动手，创建一个真正的定时搜索。

说实话，我第一次在生产环境配定时搜索时，差点把整个索引给炸了。嗯，别紧张，只要你跟着我一步步来，保证稳稳当当。

3.1 定时搜索的完整结构

我们先看一张图，搞清楚定时搜索的各个组成部分和流转关系。这样你心里就有谱了。

整个流程其实不复杂。你定义好搜索语句，设置好什么时候跑，再告诉 Splunk 结果怎么处理，剩下的就是调度器的事了。

3.2 通过 UI 创建定时搜索

大部分人第一次接触定时搜索都是从 UI 开始的。我个人也建议你先把 UI 流程走一遍，能帮助你理解各个参数的含义。

3.2.1 进入定时搜索管理页面

登录 Splunk Web，点击顶部设置 → 搜索、报表和告警。
在列表中你会看到已保存的搜索。点击右侧新建按钮。
或者你也可以从「搜索」应用界面保存一个临时搜索为定时任务。

嗯，这里要提醒一下：如果你已经打开了搜索页面，直接在搜索结果上方点击「另存为」→「定时搜索」，也能快速创建。省去跳转的麻烦。

3.2.2 填写搜索语句与调度参数

新建页面大概长这样（我把关键字段列出来）：

字段	说明	示例
标题	定时搜索的名称，用于识别	每日错误日志统计
搜索	完整的 SPL 语句	`index=main status=404 \| stats count by request`
时间范围	每次调度时搜索的数据时间窗口	上一周（相对时间）
调度	cron 表达式或简单周期	`0 6 * * *` (每天早上6点)
过期时间	结果保留多久	30 天

我习惯把搜索语句写得尽量精准，减少不必要的数据扫描。举个例子，如果你只关心前一天的日志，时间范围就设「昨天」，别用「过去7天」去浪费计算资源。

3.2.3 配置输出动作

调度跑完了，结果去哪儿？几个常见选项：

汇总索引：将结果存入一个专门的索引，方便后续查询。
发送通知：通过邮件、Webhook 或者脚本通知你。
触发告警：当条件满足时生成告警事件。

我的经验：刚开始做监控时，我习惯把结果同时写到汇总索引并发送邮件。后来发现邮件太多反而淹没了重要信息。建议你先用汇总索引保存历史，只对关键阈值发告警。

3.3 用命令行创建定时搜索

UI 适合单次配置，但如果你是运维几十台 Splunk 环境，或者想批量部署，命令行才是王道。

Splunk 提供 splunk add oneshot 和 splunk add savedsearch 两组命令。前者是一次性调度，后者是持久定时任务。我们重点用 splunk add savedsearch。

# 创建一个定时搜索，每天早上8点运行
splunk add savedsearch \
  "每日活跃用户统计" \
  "index=main source=access | stats dc(client_ip) by date_mday" \
  -auth admin:password \
  -dispatch.earliest_time "-1d@d" \
  -dispatch.latest_time "@d" \
  -cron "0 8 * * *" \
  -action.email.to "ops@example.com" \
  -action.email.subject "每日活跃用户报告"

参数说明：

-dispatch.earliest_time / -dispatch.latest_time：每次调度时搜索的时间窗口。
-cron：cron 表达式，0 8 * * * 表示每天早上8点整。
-action.email.*：配置邮件通知动作。你也可以用 action.summary_index.* 存到汇总索引。

注意：如果你在分布式环境中使用命令行，必须确保 CLI 连接到部署服务器（Deployment Server）或直接操作搜索头（Search Head）。我曾经因为路径没指定对，结果任务配到了索引器上，导致调度死循环。检查 /opt/splunk/etc/system/local/savedsearches.conf 文件是在哪个节点上生成的。

3.4 通过 savedsearches.conf 编辑

这是最底层的方式，也是我推荐给进阶同学的。直接编辑配置文件，没有 UI 校验，但灵活度最高。

配置文件路径：$SPLUNK_HOME/etc/system/local/savedsearches.conf（或 apps 下的同名文件）。

# savedsearches.conf 示例
[每日API错误监控]
search = index=main sourcetype=api_log status=5* 
  | stats count by endpoint, status
earliest_time = -1h
latest_time = now
cron_schedule = */15 * * * *
dispatch.earliest_time = -15m
dispatch.latest_time = now
action.email.to = alert@example.com
action.email.subject = API错误告警
alert.severity = high
is_scheduled = 1

字段对应关系：

search：SPL 语句，可以换行写，但要注意缩进。
cron_schedule：调度周期。
earliest_time / latest_time：搜索的数据窗口（UI 里的「时间范围」）。
action.xxx：动作配置，邮件、脚本、Webhook 都支持。

  重要：编辑完配置文件后，需要重启 Splunk 或者执行 splunk reload saved-searches 来重新加载。不重启的话，配置不会生效。我当初就在这上面栽过跟头，折腾了半小时。

3.5 验证定时搜索是否成功

创建完后，怎么知道任务跑没跑？

回到 UI → 设置 → 搜索、报表和告警，看看状态是不是「已启用」。
点进该定时搜索，查看「调度历史」，会列出每一次运行的开始时间、完成状态、耗时。
如果配置了邮件通知，收件箱里应该能收到测试邮件（首次配置建议手动点「运行测试」）。

要是发现任务没执行，先检查几个东西：

Splunk 调度器是否正常？运行 | rest /services/saved/searches 看返回是否正确。
搜索语句是否在实时搜索中能跑通？有时 SPL 语法在 UI 上没问题，但调度时因为权限或索引变更会失败。
许可证是否足够？定时搜索会消耗许可证，如果你的日索引量接近上限，调度可能被延迟。

曾经踩坑：我遇到过定时搜索经常跳过某个时间点不执行，后来发现是因为那一刻 Splunk 正在做索引滚动，调度队列被卡住了。解决方案是把调度时间错开整点（比如 0 8 * * * 改成 30 8 * * *）或者增加调度器的最大并行任务数。

3.6 最佳实践：起步时的参数推荐

如果你是第一次创建，我建议按这套参数来：

参数	推荐值	理由
调度频次	每15分钟或每小时	避免太频繁导致性能抖动
数据窗口	最近1小时	保证实时性，同时降低扫描量
过期时间	7天	便于调试，又不占太多磁盘
输出方式	汇总索引（summary index）	比直接发送邮件更灵活，方便再查询
是否启用	先禁用，测试通过后再启用	免得一开始就跑起来，发现问题来不及改

等你熟悉了，再根据业务需求调整。记住一句话：定时搜索不是越多越好，而是越准越好。我在一个项目里见过有人配了50多个定时搜索，结果调度器内存爆了……后来我帮他们合并成5个，每天跑一次，反而更稳定。