验证 Splunk 企业级架构设计能力,涵盖索引器集群、搜索头集群、分布式部署与容量规划,是 Splunk 最高级别的架构师认证。
Splunk Enterprise Certified Architect 是 Splunk shop 里高级架构师的官方盖章,唯一认可"能拍板 indexer/search head 集群方案"的证书 — 但不做 Splunk 自管部署的公司考了等于白考。
Unlock all certifications, courses & tools at a fraction of the cost
This page is structured for quick scanning first: exam format, fit, prep time, and the actual study scope.
Splunk Enterprise Certified Architect(SPLK-2002)是 Splunk 认证体系顶端的架构级证书,定位是"能为大型 Splunk Enterprise 部署做容量规划、集群拓扑设计、性能调优"的高级工程师。和 SPLK-1003(Admin,日常运维)不同,2002 考的不是"怎么改 inputs.conf",而是"10 TB/day、100 个 forwarder、SLA 要求 RPO < 5 分钟时应该用多少 indexer、RF/SF 定多少、search head 要不要 clustering、license 怎么分配"这类方案设计题。
硬性前置:必须先通过 SPLK-1003(Admin)才能报考 SPLK-2002,这是 Splunk 官方在 schedule 系统里强制检查的规则,不是建议。如果你连 1003 都没过,Pearson VUE 直接拒绝约考。考试形式:85 道题,90 分钟,70% 通过,费用 130 USD(Pearson VUE,可线上监考),有效期 3 年。题目以场景题为主,一道题经常给你一段 300 字的部署现状描述,让你选最合适的架构调整方案。
考点核心 5 大领域:(1) 容量规划(Indexer sizing — CPU cores × 100GB/day/core 经验公式,磁盘 IOPS 要求 800+ random read/write,memory 12 GB base + 300 MB/concurrent search);(2) Indexer Cluster 设计(Replication Factor、Search Factor、Multisite Cluster 的 site_replication_factor 和 site_search_factor,Cluster Master 故障切换);(3) Search Head Cluster(captain 选举、KV Store replication、deployer 和 cluster 的区别、SHC 最少 3 节点原因);(4) Distributed Search & Forwarder 架构(intermediate forwarder、load balancing、indexer discovery 通过 cluster master 自动发现 peer);(5) 性能调优与监控(Monitoring Console、DMC 配置、bucket rolling 瓶颈排查、search concurrency limits)。
Cisco 在 2024 年完成 280 亿美元收购 Splunk 后,大型企业客户(四大行、电信、国防、政府)的自管 Splunk Enterprise 部署继续扩容,而不是迁 SaaS — 这些客户的合规和数据主权要求决定了他们未来 3-5 年内不可能搬到 Splunk Cloud。这意味着 SPLK-2002 对大型 Splunk 合作伙伴(Partner)和企业内部 Splunk Platform Team的架构师仍然是硬通货。但 Cisco 本身在主推 Splunk Cloud + Cisco XDR,新客户走 SaaS 的比例越来越高,纯自管架构师的岗位长期会收缩。
一句话:你做大型 Splunk Enterprise 自管部署的架构设计工作 — 考;在 Splunk Partner 做交付方案 — 考;其他所有场景 — 别浪费 130 美元。
Salary ranges, target job titles, and the real career impact of holding Splunk SPLK-2002.
Splunk Architect 是 Observability 赛道里最稀缺的角色之一
在美国和澳洲市场,能独立做 "10 TB/day、multisite cluster、跨 region DR" 级别 Splunk 架构方案的人非常少。原因很简单:这个技能需要同时懂 Splunk 内部机制(bucket lifecycle、replication 算法)+ Linux 存储(NVMe IOPS、ZFS/XFS 选型)+ 分布式系统理论(CAP、quorum、split-brain)。市场上有 Splunk 证书的工程师不少,但能做架构级决策的人凤毛麟角。LinkedIn 上搜 "Splunk Architect" 的美国岗位中位 base 在 170-200k USD,大型 Partner(Accenture Federal、Deloitte、Kyndryl)的 Principal Splunk Consultant 可以到 230k+ base。澳洲四大行和 DXC、Kyndryl 的 Splunk Architect 岗位普遍在 170-200k AUD base。
谁最该考
谁不应该考
Cisco 收购后的趋势观察:2024-2025 年 Cisco 把部分 Splunk Professional Services 并入 Cisco Customer Experience(CX)组织,这部分 Splunk Architect 的薪资体系向 Cisco 高级工程师靠拢,普遍涨 5-10%。另一方面 Cisco 在主推 "Full-Stack Observability" 战略,未来 Splunk Architect 如果同时懂 Cisco AppDynamics + ThousandEyes + Splunk 的集成设计,会比纯 Splunk 背景的人值钱一档。但短期内纯 Splunk Enterprise 自管架构师的需求没有明显下滑。
A concrete week-by-week plan from past test-takers — not generic advice.
1003 是硬性前置,没过的话 Pearson VUE 约考直接被拒。第一件事下载并精读 Splunk 官方的《Splunk Validated Architectures》(简称 SVA)白皮书 — 这是 2002 考试最重要的单一资料,考试至少 15-20 道题直接来自这份文档里的 9 种参考架构(S1/S2/M1/M2/M3/M4/L1/L2/L3,按数据量和 HA 要求分层)。SVA 里明确列出每种架构对应的 "单日数据量区间 + indexer 数量 + search head 数量 + 是否需要 clustering + RF/SF 推荐值",这些是考试场景题判断 "应该推荐哪种架构" 的依据。看完 SVA 做一个自己的速查表,把 9 种架构画在一张 A4 纸上,考前一小时复习一遍。
这两门课是 Splunk 官方唯一对应 2002 考纲的培训,每门约 12-16 小时。Architecting 课重点:容量规划公式(reference hardware、indexer sizing、search head sizing、forwarder throughput)、multisite indexer cluster 的 site_replication_factor 写法(比如 "origin:2, total:3" 的意思)、search head cluster 的 captain 选举算法(Raft)、KV Store replication、deployer 和 cluster 的职责边界。Troubleshooting 课重点:Monitoring Console(MC)的配置和使用、DMC alerts、常见性能瓶颈模式(skipped searches、bucket rolling stall、replication queue 堵塞)、`splunk diag` 命令收集诊断包的方法。这两门课的实验很重要,必须在自己的实验环境里跑一遍,尤其是 multisite cluster 的搭建 — 考试至少 5-6 道题和 multisite 相关。
这是 2002 备考最关键的动手环节。最低配置:6 台 Linux VM(每台 4-8 GB 内存)。拓扑:Site1 = 3 indexer + 1 SHC member + 1 cluster master;Site2 = 2 indexer + 2 SHC member + 1 SHC deployer。配 site_replication_factor = "origin:2, total:3",site_search_factor = "origin:1, total:2",启动后用 `splunk show cluster-bundle-status` 和 `splunk show shcluster-status` 观察状态。然后故意做破坏性实验:(1) 停掉 Site1 的 cluster master,观察 indexer 是否还能 replicate;(2) 停掉 SHC captain,看新 captain 选举过程;(3) 模拟磁盘满,观察 bucket rolling 行为;(4) 跑一个高并发搜索,观察 Monitoring Console 里的 search scheduler skipped searches 指标。每种破坏性场景做完都记录一次现象 — 考试里 60% 的场景题就是在问这些故障模式该怎么处理。
容量规划必须背下来的公式和数字:(1) Indexer sizing — "reference hardware" 为 12 CPU cores、12 GB RAM、800 IOPS,单台 indexer 在 reference hardware 下可处理 ~300 GB/day indexing + 少量 search 负载;(2) Search Head sizing — 16 cores 能支持 ~25 concurrent searches,每个搜索平均消耗 300 MB 内存;(3) Forwarder throughput — Universal Forwarder 在默认 maxKBps 下限速 256 KB/s,生产环境应该改成 0(无限制);(4) License volume 按 indexed volume 计算(不是 raw data),压缩比约 50%。故障场景题必练类型:RF=3/SF=2 的 3 节点 cluster 挂一台会怎样(仍可搜索、仍可 replicate,但无法维持 RF 所以会 fix-up);RF=3/SF=2 的 3 节点 cluster 挂两台会怎样(部分 bucket 不可搜索,cluster 进入 degraded);multisite cluster 整个 site 断网时 cluster master 如何处理(site_mappings 决定故障行为)。
最后一周每天一套模考。JR Academy 题库 + Splunk 官方 sample test 各刷 2 遍。错题重点回顾的题型:(1) "给你现状 X TB/day,用户要求 Y 天 retention + Z 小时 RPO,应该选哪种架构" — 答案永远看 SVA 分层;(2) "现有集群 skipped searches 过高怎么办" — 优先考虑加 search head 而不是加 indexer;(3) "bucket rolling 慢怎么排查" — 查 IOPS 而不是 CPU;(4) "deployer 和 cluster master 能不能放一台" — 可以但生产环境不推荐;(5) "SHC 最少几个节点" — 3 个(Raft quorum 要求)。考前一晚把 SVA 的 9 种架构速查表再过一遍,考试稳定 78-80% 以上再约考试。
What it actually took for real candidates to pass — prep time, scores, and lessons learned.
我之前做了 3 年 Splunk Admin,2002 是从 Admin 升架构师的必考证。考试比 1003 难一个量级 — 题目都是大段场景描述,没有 "定义题"。最重要的备考资料是 Splunk Validated Architectures 白皮书,我打印出来放在床头每晚翻。考试里至少 20 道题是在问 "给定数据量和 HA 要求,从 SVA 的 9 种架构里选一个" — 你必须把 S1/S2/M1/M4/L3 这些编号和对应的 indexer 数量背熟。另外 multisite cluster 的 site_replication_factor 写法 "origin:2, total:3" 这种语法一定要动手配过一次,看文档记不住。
我负责一个 18 节点 indexer cluster + 4 节点 SHC 的生产环境,以为日常运维就够了,结果考试差点挂。最大的坑是 SHC captain 选举 — 考试里至少 3 道题深入问 captain 失联时的行为(dynamic captain 会重新选举,static captain 配置不能再用需要手动干预)。另一个重灾区是 KV Store — 我之前从来没关注过 KV Store 的 replication 机制,结果考试有 4-5 道 KV Store 题,包括 `mongod` 进程崩溃怎么处理、KV Store 和 indexer cluster 的关系(KV Store 只存在于 search head,不复制到 indexer)。建议备考时一定要把 Splunk docs 里 "About the captain" 和 "KV Store troubleshooting" 两页读透。
我做 Splunk 实施 5 年,2002 算是日常工作的总结。最容易错的题不是技术题而是 "方案推荐题" — 比如 "客户现状 2 TB/day、3 年 retention、要求 99.9% 可用性,推荐哪种架构",这种题必须严格按 SVA 白皮书的分层逻辑答,不能按自己的经验拍。我一开始凭经验答错了好几道。另一个坑是 license master 的架构题 — license master 本身不是 HA 组件(它挂了 72 小时内 indexer 继续工作,超过 72 小时 search 被禁用),所以 license master 不需要配 cluster。考试会给你一个 "license master 挂了怎么办" 的场景,正确答案不是 "搭 HA license master"(Splunk 不支持),而是 "恢复 license master 服务"。
| Splunk SPLK-2002 | Splunk SPLK-1001 | Splunk SPLK-1002 | |
|---|---|---|---|
| Provider | 其他 | 其他 | 其他 |
| Level | 助理级 | 助理级 | 助理级 |
| Fee | $0 | $0 | $0 |
| Duration | 90 min | 90 min | 90 min |
| Question count | 65 | 65 | 65 |
| Validity | 3 yrs | 3 yrs | 3 yrs |
**85 题 / 90 分钟,平均 63 秒一题** — 但场景题本身很长(经常 200-300 字背景描述),时间其实相当紧。看到长题目先跳过细节读问题本身,带着问题回头扫背景找关键数据点(数据量、节点数、RF/SF、延迟要求)。
**Splunk Validated Architectures 白皮书是最重要的单一资料** — 至少 15-20 道题直接对应 SVA 的 9 种参考架构(S1/S2/M1-M4/L1-L3)。考前必须能 30 秒内说出每种架构对应的数据量区间和节点数。
**容量规划题先算数据量,再选架构** — 看到 "客户 X TB/day、Y 年 retention、Z 并发搜索" 这类题,先算总存储(TB/day × 365 × years × 0.5 压缩比),然后按 SVA 表格选架构层级,永远不要凭直觉。
**RF/SF 相关题目记住硬约束 SF <= RF** — 任何 SF > RF 的配置都是非法的,cluster master 不会启动。Multisite 场景用 site_replication_factor 语法(origin/total)。
**故障场景题优先排查磁盘 IOPS** — Indexer 性能问题 80% 是 IOPS 瓶颈,不是 CPU/内存。看到 "搜索慢、CPU 30%、内存充足" 的场景,答案永远是 IOPS。
**三个角色别搞混:Deployment Server / SHC Deployer / Cluster Master** — 分别管 Forwarder、SHC members、Indexer peers。任何 "用 Deployment Server 管 Cluster peer" 的选项都是错的。
**License Master 不是 HA 组件** — 挂 72 小时内不影响 indexing,超过 72 小时 search 被禁用但 indexing 继续。Splunk 不支持 License Master cluster。
**费用和约考**:130 USD(Pearson VUE 线上监考或线下考点)。必须**先过 SPLK-1003** 才能 schedule 2002,系统强制检查。挂了 7 天内不能重考,重考全价。考完立即出结果(Pass/Fail + 各 domain 百分比)。
**混淆 Indexer Cluster 的 Replication Factor 和 Search Factor** — Replication Factor(RF)= 数据在 cluster 里保留多少份副本,Search Factor(SF)= 这些副本里有多少份是 "searchable"(即 index 文件完整,可以被搜索)。**硬约束 SF <= RF**。默认 RF=3, SF=2 表示每份数据存 3 份副本,其中 2 份是 searchable、1 份只是 raw data(需要时会被重建为 searchable)。考题陷阱:(1) 配置 RF=2, SF=3 是**非法**的,cluster master 会拒绝启动;(2) RF=3 的 3 节点 cluster 挂 1 台还能继续 indexing 吗?能 —— 但不能再维持 RF,进入 fix-up 状态;(3) Multisite cluster 里 RF/SF 要用 site_replication_factor 和 site_search_factor 语法(如 "origin:2, total:3"),不能用单数字。
**Search Head Cluster 的 captain 选举机制理解错误** — SHC 用 Raft 算法选举 captain,**最少需要 3 个节点**(Raft quorum = (N/2) + 1,2 节点无法容错)。只有 captain 能做 artifact 管理和 scheduled search 调度,member 只负责处理用户搜索。常见错误:(1) 以为 2 节点 SHC 可以跑 —— 不行,Raft 要求多数派投票;(2) 以为可以手动指定哪个节点是 captain —— 只有 static captain 模式可以,但 static captain 挂了集群无法自动恢复,生产环境**绝不使用**;(3) 以为 deployer 是 SHC 的一员 —— **不是**,deployer 是独立节点,负责给 SHC 推送 app 和配置,不参与 captain 选举,也不处理搜索。
**搞混 Deployment Server 和 SHC Deployer 和 Cluster Master 三个角色** — 这三个都是 "推送配置的东西" 但管的对象完全不同:(1) **Deployment Server** 通过 serverclass.conf 给 Universal Forwarder / Heavy Forwarder / 独立 Splunk 实例推送 deployment app;(2) **SHC Deployer** 专门给 Search Head Cluster 的 members 推送 SHC app bundle(通过 `splunk apply shcluster-bundle` 命令);(3) **Cluster Master**(Indexer Cluster Manager)给 Indexer Cluster 的 peer nodes 推送 indexer cluster bundle(通过 `splunk apply cluster-bundle`)。**绝对禁止**的组合:用 Deployment Server 管 SHC members 或 Indexer Cluster peers —— 配置文件冲突会导致 SHC / cluster 进入异常状态。考试经常出 "以下哪种配置推送方式是错误的" 这类题,答案永远是 "用 Deployment Server 管理 Cluster peer"。
**License Master 的架构角色和故障影响判断错误** — License Master(在 Splunk 9.x 改名为 License Manager)**不是 HA 组件** —— Splunk 官方明确不支持 License Master 集群。License Master 挂了之后,license slave(其他所有 Splunk 实例)仍然可以继续 indexing 数据 **72 小时**,这段时间内没有任何影响;超过 72 小时后,search 功能会被禁用,但 indexing **继续工作不会丢数据**。考题陷阱:(1) 以为 License Master 挂了数据会丢失 —— 错,indexing 继续;(2) 以为应该配 License Master HA —— 错,官方不支持;(3) 以为 License Master 应该和 Cluster Master 分开 —— 对的,生产环境推荐分开部署避免单点压力。正确处理方式是给 License Master 做 VM snapshot 和备份 license 文件,挂了快速恢复即可。
**KV Store 的 replication 机制和故障处理不清楚** — KV Store 是 Splunk 内置的 MongoDB(`mongod` 进程),**只运行在 Search Head**(standalone SH 或 SHC members),**不**存在于 Indexer 或 Forwarder 上。在 SHC 环境里,KV Store 数据会自动在 SHC members 之间 replicate,replication 由 SHC captain 协调。常见错误:(1) 以为 KV Store 数据会复制到 indexer —— 错,indexer 上没有 `mongod`;(2) 以为 indexer cluster 的 RF/SF 控制 KV Store —— 错,KV Store 有自己独立的 replication 机制;(3) `mongod` 进程崩溃后以为要手动 restore —— SHC 环境下会从其他 member 自动同步,standalone SH 则需要从备份恢复。考试会问 "SHC 里一个 member 的 KV Store 损坏怎么处理",答案是用 `splunk clean kvstore --local` 然后 restart,让它从 captain 重新同步。
**容量规划时忽略 IOPS 要求,只看 CPU 和内存** — Splunk 官方 reference hardware 明确要求 indexer 磁盘的 **800+ IOPS**(random read + write),这是 bucket 写入和搜索的瓶颈。新手最常犯的错是用大容量低速 SATA HDD(100 IOPS)做 indexer 存储,结果数据量稍微一大就出现 bucket rolling 停滞、search 大量 skipped。考题会给你一个 "indexer CPU 使用率只有 30%、内存充足,但搜索延迟严重" 的场景,正确答案永远是 "检查磁盘 IOPS / 升级到 NVMe SSD",而不是 "加 CPU" 或 "加内存"。容量规划公式:单 indexer 处理能力约等于 `min(CPU_cores × 25 GB/day, disk_IOPS / 3)` — 磁盘经常是瓶颈。
**Multisite Cluster 的 site affinity 和 search affinity 概念错位** — Multisite cluster 有两个关键配置:(1) `site_replication_factor` 控制数据在不同 site 的副本分布(如 "origin:2, total:3" 表示原始 site 保留 2 份、全 cluster 共 3 份);(2) `site_search_factor` 控制哪些 site 有 searchable copy。**search affinity** 让 search head 优先从本 site 的 indexer 搜索数据(减少跨 site 网络流量),在 `server.conf` 里用 `[clustering]` stanza 的 `multisite = true` 启用。常见错误:(1) 以为 multisite = 双活数据中心 —— 实际上 multisite 主要目的是 DR 和 search affinity,不等于 active-active;(2) 配错 site_replication_factor 导致某个 site 故障时数据不可用 —— 比如 "origin:3, total:3" 在 origin site 挂了之后其他 site 没有副本。
**Monitoring Console(MC)的部署模式选错** — Monitoring Console 是 Splunk 内置的监控工具,有两种部署模式:(1) **Standalone MC** —— MC 作为独立 Splunk 实例或共用 search head 角色,用于小型部署;(2) **Distributed MC** —— MC 作为专门的 search head 连接所有 indexer 和 search head 作为 search peer,用于大型 cluster 部署。常见错误:(1) 把 MC 配在 Cluster Master 上 —— Splunk 官方**不推荐**,因为 Cluster Master 本身负载高;(2) 把 MC 配在 SHC member 上 —— MC 不能运行在 SHC member 上,会导致 SHC 配置冲突;(3) 忘记在 MC 上做 "General Setup" 给各节点分配角色标签(Indexer / Search Head / License Master),导致 dashboard 不显示数据。
90+ questions, chapter-by-chapter learning, mock exams, wrong-question review, and AI tutor support live in the exam page.
Go to exam prepFrom $29 · 2 free chapters