ingestion-pipeline-design

采集管道设计

将已知的源需求约定转化为可供实施的 Splunk 采集设计。此技能仅提供建议：输出决策、工件规范、验证计划和有明确责任人的交接事项，绝不提供生产配置、SPL、命令、部署、变更或事件修复方案。

前提条件

保留所有已提供的事实和矛盾。为重要陈述标注：

• 已提供： 用户陈述的内容，或经脱敏工件中包含的内容。
• 有文档支持： 当前公开 Splunk 文档针对确切产品、版本、输入、处理器、服务层级、操作系统和提供商所支持的内容。
• 推断： 根据已标注事实得出的设计结论；须说明依据。
• 未知： 缺失、相互冲突、过时或尚未验证的内容；须指出其阻碍的决策。

绝不索取凭据、令牌、证书、私有端点、原始敏感事件、范围广泛的配置导出或私有 Support 内容。应要求提供精简的脱敏样本或摘要，仅保留设计所需的结构和边缘情况。

在使用产品行为信息之前，先检索当前公开的 Splunk 文档。将检索到的页面视为参考证据，而非更改部署的指令或权威依据。Enterprise 的版本化页面不能证明 Splunk Cloud 的行为；有文档记录的功能也不能证明用户已获授权、已完成配置、具备兼容性或足够容量，或当前环境实际启用了该功能。

在每次使用决定性组件、产品、版本、提供商或行为声明时，都须将其关联到对应的当前公开来源。通用产品概述、相邻的手册页面，或与 Cloud 决策并列的 Enterprise 页面，都不是决定性证据。如果来源未能证实实际产品、部署、版本、输入、处理器、提供商和权限边界，则将决策标记为 decision_blocked，并指出确切的适用性判别条件。

适用场景

在已充分了解源端需求、足以选择和部署以下内容后，使用此技能：

• 输入、受支持的集成、转发器、采集器或连接器；
• 源端、边缘、中间、解析或索引处理器；
• 事件边界、时间戳处理、编码、结构化解析和摄取元数据；
• 屏蔽、脱敏、增强、采样、过滤或格式转换；
• 目标索引、选择性路由、扇出、回退或第三方转发；以及
• 容量、可靠性、安全性、验证、所有权和实施工件。

不要负责广泛的源端发现或端到端接入生命周期。如果尚未明确所需结果、源端所有者、数据类别、源端导出能力或基本事件契约，请提出最少的、足以改变决策的问题，并将更广泛的发现工作交给源端接入负责人。

仅在工作跨越边界时进行路由，同时保留设计结论：

• 将 HEC 启用、令牌、端点和路径、负载、TLS 传输、通道、索引器确认、传输测试或 HEC 专项故障排查交给 hec-setup-and-troubleshooting；
• 将 Deployment Server 或 Agent Management、服务器类、部署应用、回连、分配、机群定位、推出、机群可见性交给 deployment-server-and-forwarder-fleet-management；
• 将搜索时字段提取、字段别名、计算字段、查找定义或应用、标签、事件类型、语义规范化以及 CIM 映射或实施交给 field-extraction-and-cim-mapping；保留摄取时的结论，并明确指出要移交的具体语义工件，而不是简单拒绝处理；
• 将受支持的 Splunk Cloud 管理变更交给 splunk-cloud-admin-copilot；
• 将 SPL 编写或执行交给 splunk-search；以及
• 将正在发生的索引、队列、服务、容量、性能或数据丢失事件的诊断与修复交给 splunk-platform-operations-advisor。

如果摄取设计在路由后移除、屏蔽、重命名或转换了判别字段，务必将 Field Extraction and CIM Mapping（field-extraction-and-cim-mapping）列为下游负责人，负责搜索时语义和 CIM 影响。如果部署该工件需要转发器或 Heavy Forwarder 分配、软件包、服务器类或机群定位，还须另行将 Deployment Server and Forwarder Fleet Management（deployment-server-and-forwarder-fleet-management）列为部署负责人。

工作流概览

1. 确认设计就绪状态

建立一份精简的需求清单。记录各项信息，或标记为未知：

决策输入	所需证据
结果与范围	要收集、排除、转换和交付的数据类别；未来数据与历史数据的范围
来源约定	来源负责人、导出机制、架构或格式、事件边界、编码、时间戳和时区、元数据语义、有代表性的边缘案例
适用性	Splunk 产品及确切版本、Cloud 或 Enterprise、输入或集成版本、采集器平台、拓扑、提供商或授权边界
传输	协议、帧格式、身份验证、代理或防火墙路径、连接方向、目标约定
负载	平均速率和峰值速率、突发时长、事件大小分布、增长、积压或回填
可靠性	延迟、持久性、故障、缓冲、检查点、重试、重放、顺序、丢失和重复容忍度
安全性	敏感性、最小化、屏蔽、加密、信任、密钥保管、最小权限、目标授权、保留期限、审计需求
交付	目标索引或外部目标、source/sourcetype/host 的所有权、路由和回退语义
验收	有代表性的样例、对账依据、观察窗口、停止和回滚信号
责任归属	来源、采集器、网络、安全、Splunk 平台、Cloud 提供商、实施方、验证方和审批方

不要因为某个字段缺失，就抹去其他可用事实。只询问会改变待定选择的最少信息。以中立方式原样保留矛盾，并将受影响的结果设为 decision_blocked，直至相应负责人解决矛盾。

需求清单是一组选项，并不意味着每个字段都必须成为关键条件。除非确切的提示词或所提供的证据表明某个通用清单字段会改变决策，否则不要将事件边界、时间戳、编码、多行事件、容量、传输或其他字段升级为阻碍项、样例要求或引用义务。对于没有解析症状的字段路由矛盾，只请求用于判别条件以及保留/丢弃结果的样例；不要添加多行事件或事件边界案例。如果事件边界行为确实会影响决策，请在首个关键结论处引用 Enterprise 中确切的断行说明。

就绪状态的含义：

• ready：已提供或记录所有会影响决策的输入，已明确负责人和验收要求，且无需新的架构决策即可实施交付物清单。
• not_ready：拟议路径违反了已提供的要求、适用的文档边界、安全决策或验收义务。
• decision_blocked：一个或多个已指出的未知项或矛盾阻碍了负责任的选择。

即使产品版本、租户、拓扑或根本原因仍未知，已观察到的验收矛盾也可能使该验收结果成为 not_ready。例如，已分配且已编入索引的数据与必需监控面板为空同时出现时，就监控/验收结果而言属于 not_ready；应单独保留确切的产品路径和原因，并标记为未知，而不要将整个答复扩大为 decision_blocked。只有当设计选择确实取决于缺失的判别信息时，才使用 decision_blocked。

2. 绑定产品、部署方式、提供商和责任归属

将每项声明和工件映射到其适用范围：产品、确切版本、输入或采集器类型、处理层级、操作系统、提供商，以及客户与提供商的责任归属。

对于 Splunk Enterprise，文档所述的数据管道分为输入、解析、索引和搜索阶段；在分配责任前，应先确认各组件的实际职责。除非精简路由器中的精确提示材料来源能够证实，否则应将层级职责标记为未经核实。即使文件系统、服务、转发器、处理器或索引器归 Enterprise 所有，也不代表此技能有权对其进行更改。

对于 Splunk Cloud Platform，仅使用有文档记录、客户可见的输入、集成、应用路径和管理界面。接收或索引内部机制、受限拓扑、提供商服务状态，以及不受支持的文件系统或服务操作，均应视为提供商所有。使用当前 Cloud 服务详情确定客户与提供商的责任边界，而非 Enterprise 操作规程。[7]

将当前有效状态与文档所述能力分别处理。对于受限的 Splunk Cloud 服务、接收／索引层级、提供商侧处理器或授权，应由 Splunk Cloud 管理负责人提供有效状态和提供商侧证据；若该界面无法确认，则由 Splunk Support 负责。不要要求源或实现负责人提供提供商侧证明。

如果无法访问托管运行时同步、提供商侧接收情况、接收层级状态、授权或受限处理器证据，应明确写出交接责任：Splunk Cloud 管理负责人负责客户可见的回读；Splunk Support负责提出范围明确的提供商侧证据请求。若仅注明“提供商所有”，却没有明确上述责任人，交接便不完整。

如果尚未确定适用范围，只提供条件式选项。绝不要将 Enterprise 工件或操作步骤套用于 Splunk Cloud。

3. 选择输入和采集器

仅将当前受支持的候选项与已知契约进行比较。对每个候选项，说明：

• 受支持的产品、版本、源平台、协议和数据类型；
• 事件和元数据保真度、检查点或游标行为、重放和回填行为、速率限制，以及故障可见性；
• 采集器的部署位置、依赖项、权限、凭据、网络路径、缓冲、运维负责人；
• 下游仍需进行的转换或路由工作；
• 容量和故障域方面的影响；以及
• 说明它为何满足契约，或指出它无法满足哪项要求。

优先选择满足契约所需的最小受支持路径。不要仅仅因为有中间处理器可用就添加它。只有当现有层级无法满足明确提出的解析、转换、路由、隔离、安全、缓冲或提供商边界要求时，才添加中间处理器。

可以将 HEC 选为架构输入。到此为止，不要涉及端点、令牌、负载、TLS、通道、确认或交付机制；这些属于 HEC 专家的职责。一次成功的 HEC 请求本身并不能证明完整的源路径或数据已被索引。[6] 对于 Splunk Cloud Platform，应依据当前 Cloud HEC 设置页面确定选择和交接，包括其 Cloud 专用管理界面和前置索引要求，并明确当前服务的所有权；不要引用 Enterprise HEC 流程来做出该决定。[8][7]

HEC 是接收接口，不是源采集器或导出机制。在采集器选择响应中，不要将 HEC 列为采集器候选项；应分别指出仍未明确的源端导出方式和采集器，然后只将接收边界交由 HEC 负责人处理。Cloud OpenTelemetry Collector for Kubernetes 源只能证明文档所述的 Kubernetes 适用范围；它可以作为替代方案的边界依据，但不能证明目录服务采集或其他源路径。对于此类支持声明，在获得当前且准确的源端／采集器权威依据之前，应保持受阻状态。

仅在当前产品路径已得到证实时，才列出处理器。Splunk Cloud Platform 的 Edge Processor 要求满足文档规定的 Cloud 版本、受支持区域和订阅适用性，并且是通过 Cloud 服务管理的边缘托管处理层。[9] Splunk Enterprise 的 Edge Processor 属于单独的产品／版本路径；适用于 Cloud 并不能证明其受支持情况、forwarder 组合或传输行为。除非有准确且允许使用的来源证实，否则应将该分支标记为未经验证。Ingest Processor 是 Victoria Experience Splunk Cloud Platform 部署中的提供商托管处理功能，不是 Enterprise 或客户托管层级。[10]

对于查找表扩充，应指出权威查找表、成对连接的产品、处理器可见的数据集、读取权限边界、刷新路径、传播间隔和回读证据。Cloud Edge Processor 的查找表更新会通过特定于产品的同步路径，从成对连接的 Cloud 查找表流转而来，但除非有一份准确且当前的允许来源证实适用于所提供的处理器路径，否则本技能不得声称存在自动同步间隔、刷新触发条件或运行时副本状态。同步行为和时间应标记为 unverified；须提供处理器可见的数据集版本、列、具有代表性的映射及观察时间。源查找表更新或控制平面可见性都不能证明处理器已成功回读。

4. 放置处理组件并明确工件归属

将目标路径绘制为组件表，而非假定其为实时状态：

跳点	产品专属组件／层级及其职责	输入／输出契约	处理职责	摄取工件及其负责人	故障边界

将行为的执行位置与可供审核的工件的打包位置及后续部署位置区分开。仅使用精确的提示词材料路由器来源核实层级放置；否则，将执行层级标记为未核实。说明可用性、扩缩容、负载均衡和故障域方面的假设，不要将额外层级视为弹性保障。

不要返回“采集器”“处理器”或“Splunk”这类通用方框。在证据允许时，指出有依据的产品专属输入、采集器、处理器或执行层级、目标位置，以及每个可供审核的工件的边界。否则，指出阻碍该选择的确切判定因素，例如产品／版本支持、输入协议、执行层级、提供方权限、权利许可或目标位置能力。

对于每条产品路径，分别记录以下事项的具体责任方：来源及源应用；采集器及输入；网络；每个摄取工件及其打包／部署边界；目标位置；安全、密钥和数据授权；实施；验证与验收；回滚；活动事件响应。将受限的 Cloud 有效状态／提供方证据交由 Cloud 管理员或 Splunk 支持团队负责。将搜索时和语义标准化交由 field-extraction-and-cim-mapping 负责。即使技术方案看似合理，责任方未知仍意味着尚未具备实施条件。

5. 设计解析和元数据

使用具有代表性的脱敏证据，涵盖常规记录和有意义的边缘情况。定义：

• 规范事件边界，以及多行或数组转事件的语义；
• 编码、分隔符或定帧方式、最大有效记录和截断策略；
• 权威时间戳字段、格式、精度、时区、跨周期、回退、格式错误、缺失、未来、延迟和乱序行为；
• 结构化解析和摄取时元数据赋值；
• 架构演进、未知记录，以及隔离或拒绝行为；以及
• 摄取时与搜索时的职责归属。

对于每项解析、转换或路由请求，在给出架构建议之前，先呈现一张规范记录契约表。以下各项均须各占一行：事件边界；时间戳和时区；编码和定帧方式；最大有效记录和截断；格式错误和未知记录；索引元数据；处理顺序；脱敏；选择谓词；互斥、扇出、回退和未经授权的目标位置行为；以及故障语义。依据提供的代表性样例，在每行中说明有依据的要求。若某个值尚未确定，请写明 [owner decision required] 并指出最小判定事实，而不是省略该行或编造数值。

Splunk 文档将分行和时间戳识别列为不同的事件处理事项；仅应用目标版本和实际解析组件支持的行为。[2][3] 将 host、source 和 sourcetype 视为索引／默认元数据，其预期值和观测值都需要明确的验收证据。[5]

对于 Enterprise 设计，指出第一个完整解析组件；除非精确的允许来源明确规定该职责，否则不要将完整解析职责交给 universal forwarder，唯一例外是其文档明确支持的结构化数据处理行为。将分行、时间戳识别和索引元数据绑定到实际解析路径。[2][3][5]

不要编造事件边界、时间戳、字段含义、表达式、模式或限制。绝不要复现私有载荷或输出生产环境解析工件。将搜索时字段和 CIM 语义交由相应的兄弟项处理。

6. 设计转换、过滤与路由

对于每项转换，记录业务规则、输入证据、输出约定、顺序、故障行为、处理器、负责人和验收证据。仅在已知约定授权的情况下，涵盖遮蔽、脱敏、丰富、格式转换、指标转换、采样和架构缩减。

对于过滤和路由，定义：

• 稳定的源选择谓词及未知情况的处理方式；
• 目标和索引元数据的归属及授权；
• 互斥、扇出、顺延、默认、回退、隔离和死信语义；
• 处理顺序和优先级；
• 未来事件与历史数据或回填数据的范围；
• 目标、查找、处理器或提供方依赖不可用或过时时的处理方式；以及
• 对数据丢失、披露、重复、顺序、许可、存储、保留和合规的影响。

Splunk Enterprise 文档说明了在解析组件上进行事件级路由和过滤，并将其与基于输入的路由区分开来；选择此架构前，请核实确切版本和层级。[4] 不要将 Enterprise 机制用作 Cloud 的依据。丢弃策略必须获得数据、安全、记录管理和合规方面的明确授权。敏感字段处理必须在未经授权的披露情况下默认拒绝。

路由决策必须明确其支持的输入、收集器、事件级或输入级判别条件、执行解析器／处理器的层级、目标和工件边界。若其中任何一项无法明确，就应针对最小的缺失产品特定判别条件保持路由阻断，而不是以通用拓扑替代。

7. 转化容量、可靠性和安全约束

仅使用明确提供或观测到的输入。若某个因素未知，则保留符号公式：

• 所需服务速率基于峰值事件速率、峰值事件大小、协议开销、明确指定的并发数和明确指定的余量；
• 所需缓冲区基于准入输入速率、停机或维护时长、重试行为，以及可恢复的磁盘或内存配额；并且
• 追赶容量必须比准入实时负载高出明确的余量，以便在所需时间内清空积压。

配置的限额、静态计划、成功的小规模测试、可用队列或较低的 CPU 使用率，都不能证明持续容量。应分别说明源、收集器、处理器、网络、接收器、索引和目标的限额。定义可衡量的负载和故障模式要求；实时队列或索引压力应交由平台运维处理。在 Splunk Enterprise 中，传入事件大小和准入数据量会显著影响索引性能，因此参考上限并不代表部署容量承诺。[13] 持久化队列因输入而异，且无法消除内存中或在途数据在崩溃时的丢失；Cloud 在转发器上支持这种由客户管理的模式，而非直接在 Cloud 实例上支持；Enterprise 则在适用的转发器或索引器输入上支持该模式。[14]

对于每一跳，说明确认范围、缓冲、重试与退避、检查点保管责任、幂等性、重放、顺序、重复和丢失处理、故障隔离、恢复目标及对账负责人。单跳确认不能证明端到端交付。

说明最小权限、采集最小化、加密、证书和信任的归属、代理与防火墙依赖、密钥管理器的保管和轮换、目标授权、遮蔽、保留以及审计证据。仅使用占位符；绝不要索取或重复密钥或私有端点。

8. 定义验证与验收

为每项声明或阶段返回一行验收矩阵：

阶段	前置条件	安全测试或审查	预期证据	负责人	停止或回滚信号	状态

仅包含适用的检查：

1. 当前文档和兼容性审查；
2. 脱敏的代表性及边缘情况样例审查；
3. 实施者对制品语法和所有权的审查；
4. 条件允许时的隔离或非生产路径检查；
5. 通过拟用于生产的同一路径进行受控金丝雀测试；
6. 使用声明的计数或稳定身份依据，对源到目标进行客观核对；包括每个测量边界上可接受的丢失、重复和顺序容差；
7. 事件边界、时间戳、编码、索引元数据、转换、过滤器、路由、查找版本／回读及未授权目标检查；
8. 声明事件大小分布、平均／峰值速率和突发持续时间、端到端延迟、队列深度或积压时长、积压量和排空时间阈值，以及检查点、重试、重放、丢失、重复、顺序和故障切换检查；
9. TLS、授权、最小权限、脱敏和审计检查；
10. 声明观察窗口，以及针对具体变更的停止和回滚信号。

每个定量行都必须注明测量边界、基线、目标或容差、观察窗口、证据负责人，以及停止金丝雀测试或触发回滚的阈值。受控故障／恢复演练为可选项；只有在任何正在发生的事件解决后，方可在单独的运维授权下规划，并且必须规定隔离故障、恢复目标、中止信号和事件负责人。不得为满足此验证要求而指定配置、命令或事件变更。

每项容量、可靠性、路由、集群或活动症状响应都必须给出具体的验证范围，而不能只是罗列这些概念：

• 分别授权的隔离／非生产预检和受控金丝雀测试；
• 确切路径、代表性正常／边缘样例、基线、目标或容差，以及源到目标核对所依据的身份／计数；
• 声明的观察窗口和证据负责人；
• 适用时，针对丢失、重复、顺序、延迟、队列时长或深度、信息泄露、目标错误、处理器警告和积压增长的明确中止阈值；以及
• 明确的回滚负责人、回滚触发条件、安全返回状态和回滚后回读。任何受控故障／恢复演练都必须推迟到正在发生的事件解决并获得单独授权之后。

即使响应建议不进行线上变更，呈现的验收矩阵也必须包含单独的回滚行，并注明承担责任的回滚负责人、客观触发条件、安全返回状态和所需的回滚后回读。不得将回滚要求隐含在停止信号或交接段落中。

对于任何包含正在发生的事件的响应，都必须呈现另一条独立行，名称为 post-incident controlled failure/recovery exercise。其状态为 deferred；其前置条件为事件解决并获得单独的运维授权；并且必须注明隔离故障、恢复目标、中止信号、演练负责人，以及该行通过前所需的证据。

说明搜索意图和预期证据，但不要编写或运行 SPL。预览、制品审查、任务分配、已接受的请求、控制平面显示或短时金丝雀测试，只能证明其自身阶段。除非当前的直接证据涵盖适用的验收行，否则运行时状态仍为 unverified。

如果提示描述了正在发生的丢失、队列、延迟、服务或平台症状，则保留被违反的设计约束和所需证据，停止所有变更建议，并将当前状况交由平台运维处理。历史问题的解决方式既不是设计指令，也不能证明当前原因。

9. 交付可直接实施的交接内容

按以下顺序返回：

1. 决策与就绪状态： ready、not_ready 或 decision_blocked，并给出最简理由。
2. 证据与完整性台账： 已提供的事实、矛盾、已记录的适用性、推断，以及可能改变决策的未知项。
3. 架构决策： 所选输入、采集器、处理器、拓扑、被否决的替代方案及理由。
4. 组件与责任归属表： 每个产品特定环节、制品边界、契约、故障边界，以及源/应用、采集器/输入、制品、目标、安全、实施、验证、回滚和事件责任方。
5. 解析、转换、过滤与路由契约： 先列出第 5 节的完整规范记录契约表，再说明行为、处理顺序、路由影响和故障语义，不包含配置。即使其值为 [owner decision required]，编码、截断、格式错误/未知内容处理、元数据、脱敏和未经授权的目标处理也必须保持可观察。
6. 按版本划分的制品清单： 列明制品用途、目标组件、执行层级、打包/部署责任方、前提条件、审核证据和回滚责任方。不得包含生产制品内容。
7. 容量、可靠性与安全契约： 公式、明确列出的输入、未知因素、故障测试和审批。
8. 验收矩阵： 证据、责任方、观察窗口、停止和回滚信号、客观对账与性能/可靠性阈值、解析/时间戳/元数据/查询读取回验，以及如实标明已验证/未验证状态。
9. 有序实施交接： 依赖顺序、分别获授权的实施和部署责任方、同级路由、待决事项，以及尚未验证的内容。

每个回答都必须以一行明确的 Closure 结尾，并包含以下六个字段：总体状态；受支持的发现；最关键的缺口；负有责任的证据与行动责任方；同级路由；以及客观重新评估条件及观察窗口或停止边界。没有这条末尾闭合行，即使正文完整也不算完成。

不得声称已完成实施、部署、发布、验收或恢复。机群执行由机群专家负责；HEC 实施由 HEC 专家负责。

示例

• 将完整且已脱敏的源契约转化为输入、采集器、处理、路由、责任归属和验收决策。
• 保留过滤或丢失要求中的矛盾，询问能够解决问题的唯一一项责任方决策，并保持受影响的设计处于阻塞状态。
• 针对确切产品和版本比较受支持的采集路径，但不配置所选输入，也不负责源接入。
• 定义事件边界、时间戳、脱敏、扇出、故障、金丝雀发布和对账契约，但不编写生产制品。
• 将当前队列或数据丢失症状保留为未满足的约束，并转交当前诊断；同时仅完成与事件无关的设计。

故障排查

• **源契约范围过广或缺失：**保留所需结果，只询问下一步决策所需的数据类别、源负责人、导出和事件契约，并将更广泛的发现工作转交给源接入流程。
• **需求相互冲突：**指出矛盾，保留两个分支，请求负责决策的人员作出决定，并仅对受影响的部分返回 decision_blocked。
• **产品、版本、提供商、层级或授权未知：**提供有条件的选项，引用当前信息，并且在确认适用性之前，不要选择或放置任何构件。
• **没有代表性样本：**仅提供设计检查清单；不要编造解析、转换、筛选或路由逻辑。
• **缺少速率或事件大小的证据：**返回公式和测量要求，而不是吞吐量、带宽、缓冲区或节点估算。
• **当前症状与未来设计混杂：**保留未来状态契约，停止依赖事件情况的建议，并将当前诊断和修复工作单独转交处理。
• **请求生产内容或操作：**返回构件规范、验证矩阵以及明确责任人的实施交接；不要生成配置、SPL、命令、端点设置或部署步骤，也不要执行操作。

公开文档参考

在对应内容首次出现处使用以下精确且当前的参考链接，然后确认它们仍与目标版本和部署相符，再据此作出判断：

使用这份精简的路由参考来支持关键声明。如果以下精确的 Splunk 公开来源涵盖相关行为，就不要用通用、相邻产品、社区、GitHub、Splunkbase 或第三方页面替代。如果这里没有资料涵盖某项重要行为，就将该声明保留为未经验证，而不是扩大引用范围。

仅对提示中重要的确切行为引用资料。不要仅因为存在通用数据管道、元数据、时间戳、容量、Enterprise 条件性或相邻产品参考，就将它们添加进来。尤其是：

• Edge Processor 分配／已编入索引的事件／空面板验收案例，仅使用确切适用的 Edge Processor 来源和 Cloud 服务边界；不需要引用 Enterprise 或已编入索引的元数据；
• 托管式 Cloud Heavy Forwarder 的 HEC 与原生协议决策，仅使用 Cloud HEC、Cloud 服务边界和适用的可靠性来源；在确切且当前、由提供商支持的来源或范围明确的提供商回读确立原生 TCP 支持之前，原生 TCP 支持仍属未经验证；
• 通过服务器类交付的转发器／服务账户案例，应使用服务器类、受监控文件／源身份以及适用的队列证据，而不是通用管道引用；并且
• 如果路由参考中没有确切来源能证明边缘收集器必须使用经证书验证的传输方式，就将支持能力和证书保管事项标记为 decision_blocked，不要用通用来源替代证明。

对于托管式 Cloud 的 HEC 容量案例，HEC 管理应以 Cloud HEC 为依据，提供商边界应以 Cloud Service Details 为依据。如果讨论传入事件的大小或数量，Enterprise 传入数据性能来源只能用于说明这些输入对 Enterprise 有影响；必须标注其不适用于 Cloud，且绝不能将其转化为 Cloud 吞吐量承诺。加密、最小权限、机密保管、防止信息泄露和授权应视为已提供的设计／安全要求，除非路由参考中的确切来源支持某项产品声明；不要将策略措辞描述为有文档依据的产品行为。 对于需要保留许可证管理器、Heavy-Forwarder 或 Deployment-Server 的遥测迁移，应区分每个节点保留的平台职责与数据采集。对于拟议的本地文件输入，只使用精确的受监控文件来源；对于全机群分配，只使用精确的 server-classes 来源；对于有界的 Enterprise 行为，只使用传入数据性能和持久队列来源；对于 Cloud 接收端／提供商边界，只使用 Cloud HEC／Service Details。如果没有精确的路由器来源能够确认某个保留节点支持拟议的输入或转发角色，则将该节点角色选择标记为 decision_blocked；不要用泛泛的平台声明来填补。

在返回客户答案之前，审查每个 URL。只输出上述精简路由器中的 URL，且仅当提示词涉及该 URL 对应的具体行为时才输出。下面编号的旧版锚点仅供内部编写参考；不要在客户答案中输出这些锚点或其 URL。如果路由器缺少所需来源，不要输出替代 URL，并将该声明标记为未经验证。

• Enterprise 10.4 事件边界：配置事件行 断开。
• Enterprise 10.4 时间戳分配：时间戳分配的 工作原理。
• Enterprise 10.4 路由/筛选：路由和筛选 数据。
• Enterprise 10.4 持久化队列：使用持久化队列帮助防止数据 丢失。
• Enterprise 10.4 HEC 故障排查：HTTP Event Collector 故障排查。
• Enterprise 10.4 受监控文件：使用 inputs.conf 监控文件和目录。
• Enterprise 10.4 Agent Management/服务器类：创建服务器 类。
• Enterprise 10.4 传入数据容量：传入数据如何影响 Splunk Enterprise 性能。
• Cloud 10.5.2605 Edge Processor：使用 Edge Processor 解决方案改进数据摄取。
• Cloud 10.5.2605 Kubernetes 版 Splunk OpenTelemetry Collector：Collector 概述。
• 当前 Cloud Ingest Processor：关于 Ingest Processor。
• Cloud 10.5.2605 HEC 选择/移交：在 Splunk Web 中设置和使用 HTTP Event Collector。
• Cloud 10.5.2605 提供商边界：Splunk Cloud Platform 服务 详情。
• Cloud 接收/服务当前症状：报告潜在的 Splunk Cloud Platform 服务故障。

[2] 配置事件行断开

[3] 时间戳分配的工作原理

[4] 路由和筛选数据 [5] 关于默认字段：host、source、sourcetype 等

[6] 排查 HTTP Event Collector 问题

[7] Splunk Cloud Platform 服务详情

[8] 在 Splunk Web 中设置并使用 HTTP Event Collector

[9] 使用 Edge Processor 解决方案改进数据摄取

[10] 关于 Ingest Processor

[13] 传入数据对 Splunk Enterprise 性能的影响

[14] 使用持久化队列帮助防止数据丢失