Skip to main content

 

Splunk Lantern

Onboarding and promoting data with Cisco Data Fabric powered by the Splunk platform

Cisco Data Fabric powered by the Splunk platform supports a repeatable path from retained data to operational action: onboard and land data, discover it with context, and promote it selectively as workloads mature.

You are currently at Phase 2 in the Cisco Data Fabric getting started guide. Navigate to Phase 1 for an overview of getting started with Cisco Data Fabric.

Step 1: Onboard and prepare the data

Cisco Data Fabric supports familiar Splunk platform collection methods via its Data Management capabilities to introduce data into Machine Data Lake, Splunk platform indexes, or both. These methods include S2S, HEC, Universal and Heavy Forwarders, modular inputs, data inputs, and OpenTelemetry. This allows you to retain complete raw data in Machine Data Lake while continuing to populate indexes for active workloads.

Choose where processing should occur:

  • Splunk Edge Processor runs close to on-premises or edge sources, making it useful when data must be filtered, masked, enriched, or routed before it leaves the environment.
  • Splunk Ingest Processor is the cloud-managed processing tier. It can transform, filter, enrich, and route events after they reach the Splunk Cloud Platform boundary.

Processing is optional for a clean direct route to Machine Data Lake, but Ingest Processor becomes the routing control plane when you want to preserve upstream configurations.

Use transformations intentionally. Remove data only when policy permits it, mask sensitive fields before they travel beyond the required boundary, and add metadata that will make the dataset easier to find later. Good source, source type, host, ownership, and tagging choices pay dividends in the Catalog.

Step 2: Configure data routing to Machine Data Lake

Use Machine Data Lake as the complete raw source of truth for supported machine data, retaining the full raw history without indexing it all upfront. Keep only the active window required for Splunk Enterprise Security content, dashboards, alerts, correlation, or repeated low-latency search in a Splunk platform index.

There are two primary ingestion patterns:

Direct routing

Direct routing into Machine Data Lake is the lowest-friction choice for a new customer or a new data source with no existing pipeline to preserve, in order to capture data at low cost, or handle ad-hoc search patterns.

For a direct route, use the current procedure for the selected input to target the Machine Data Lake raw-table resource name. For events that already reach Splunk Cloud Platform, define the supported landing conditions on the raw table. If the same matching events must remain in an existing Splunk platform index, follow the dual-routing procedure and the raw table and index independently.

For HEC traffic, use a token configured with the Machine Data Lake dataset or raw-table destination. In both cases, the destination information tells the platform to land the data in Machine Data raw storage. Ingest Processor can still be inserted when transformations are needed, but it is not required solely to route the data.

Pipeline routing

Pipeline routing is designed for established Splunk Cloud Platform environments where data needs to be retained for the long term, while also keeping a copy (or subset) in an index for real-time access for a shorter retention period. Existing forwarders can continue to use their standard S2S endpoint, and producers can retain their standard HEC tokens. Instead of changing every upstream configuration, create the Machine Data Lake raw table and its data partition, then use Ingest Processor to select and route matching events into that partition.

This pattern supports incremental adoption – for example, an organization can begin with DNS, proxy, and cloud-audit logs while leaving current security pipelines untouched. It can also maintain an existing index flow while adding Machine Data Lake as a second destination. The important design goal is to preserve working operational content while expanding long-term coverage.

Step 3: Land the data in Machine Data Lake

Machine Data Lake is the preferred landing zone for data whose future value or search pattern is not fully known. It is Splunk-managed, uses compressed Parquet storage, and separates economical retention from the decision to create an always-active index.

Data first lands in a Machine Data Lake raw table, which uses a Splunk-managed landing schema that preserves the raw event with limited metadata. It is suitable for broad retention, compliance, forensic context, and data that might become important later. Raw data remains searchable in place for bounded, infrequent exploration, but it is not intended for repeated, highly interactive investigations.

Step 4: Discover the dataset in the Catalog

Catalog elevates storage into a usable data estate. Its background services inventory Machine Data Lake raw tables, analytics tables, Splunk platform indexes, and supported federated datasets. The resulting metadata can include dataset statistics to understand data coverage, and field schema to understand dataset structure.

Open the Catalog and locate the dataset using what you know – even a simple keyword search to begin with. Filter more deeply to discover Machine Data Lake data (and other datasets) by source, source type, host, owner, or time coverage. Browse fields and preview the relevant slice to verify that it contains the events needed for the use case.

This is a critical checkpoint. A security analyst investigating a two-week period should confirm that the dataset covers the correct hosts and dates before paying to scan a much larger range or creating a promoted copy. The Catalog is also the control plane for initiating promotion, so the discovery work naturally becomes the scope of the next step.

Step 5: Promote data when the use case matures

Not every dataset needs promotion. Leave data in the Machine Data Lake raw tier when access is rare, the workload is unproven, or a bounded search can answer the question. Raw is an intentional long-term home for compliance records, long-tail sources, full-fidelity forensic context, and new data whose future value is credible but not yet established.

Promote when the use case becomes repeated, interactive, structured, or continuous. Promotion is additive: it creates an activated representation while the original raw data remains in Machine Data Lake. Choose one of two destinations:

  • Splunk platform index: Promote to an index when the workload needs low-latency, high-frequency search, full raw-event retrieval, schema-on-read flexibility, existing SPL knowledge objects, correlation searches, data-model acceleration, dashboards, or alerting. Size the promoted retention window carefully because the copy consumes index storage entitlement while it exists.
  • Machine Data Lake analytics table: Promote to a Machine Data Lake analytics table when the workload is structured and repeatable: aggregations, trend analysis, scheduled threat hunting, compliance reporting, AI/ML training, or queries that touch a subset of columns across many events. Analytics tables use a customer-defined schema and a columnar Iceberg representation. Where the dataset, stack, permissions, and client are supported, OpenSharing can provide authorized read-only external access with expiration and revocation controls.

Then select a promotion method. Promotion creates a new destination while the source raw data remains under its raw table retention policy. Use static promotion for a selected historical time range; it can create either a new Splunk platform index or a new analytics table. Use streaming promotion only when future matching events must continue into a new index. Streaming starts after the job becomes active and does not backfill history, so pair it with a separate static promotion when the job also needs earlier data.

Check current release notes before you promote. Promotion behavior and supported destinations can change between releases – for example, the August 2026 release does not promote to an existing index or existing analytics table.

Next steps

Click the Next step button below to learn how to search across your data estate and optimize investigations with agentic search.