コンテンツにスキップ

Migration from Splunk

This guide helps Splunk users move to CSIRT-Pro. It maps familiar SPL concepts to their PRQL equivalents, compares the architectural building blocks, and lays out a practical migration workflow.

Concept Mapping

Most Splunk concepts have a direct counterpart in CSIRT-Pro. The largest difference is the query language: SPL becomes PRQL.

Splunk Concept CSIRT-Pro Equivalent Notes
Index Pipeline Each Pipeline maps to its own log store
Source / Sourcetype Pipeline name + parse settings Parse rules are per-pipeline
Search (SPL) Search (PRQL) Pipelined syntax, different keywords
Dashboard Dashboard 12-column grid layout, PDF export
Alert Playbook trigger + Case Playbooks open cases on detection
Saved Search Saved Visualization Query and chart config are persisted
Lookup Table Pipeline (reference data) Ingest reference data as a pipeline
App / Add-on Integration Enable from the integration catalog
Heavy Forwarder High-performance ingestion API High-throughput REST endpoint
Universal Forwarder API client / log shipper Any HTTP-capable agent works
Knowledge Objects Pipeline parse settings Regex and field-name extraction
Role-Based Access Organization + SharedAccess Multi-tenant with cross-org sharing
Phantom (SOAR) Playbook Visual flow editor with Python/JS nodes
Enterprise Security Built-in (UEBA, threat intelligence, cases) No separate product required

SPL to PRQL Mapping

index=firewall action=DENY

from `firewall_logs`
filter action == "DENY"

Time Range

index=firewall earliest=-24h latest=now

from `firewall_logs`
filter __time > @2025-01-14
filter __time < @2025-01-15

Time Range Selector

In the CSIRT-Pro UI, you usually set the time range with the time picker rather than in the query itself.

Wildcard / Partial Match

index=auth "failed login"

from `auth_logs`
filter message ~= "failed login"

Field Selection

index=firewall | fields src_ip, dst_ip, action, bytes

from `firewall_logs`
select {src_ip, dst_ip, action, bytes}

Sorting

index=firewall | sort -_time

from `firewall_logs`
sort {-__time}

Limiting Results

index=firewall | head 100

from `firewall_logs`
take 100

Aggregation: Count by Field

index=firewall action=DENY | stats count by src_ip | sort -count | head 10

from `firewall_logs`
filter action == "DENY"
group {src_ip} (
  aggregate {count = count this}
)
sort {-count}
take 10

Aggregation: Sum

index=firewall | stats sum(bytes) as total_bytes by src_ip

from `firewall_logs`
group {src_ip} (
  aggregate {total_bytes = sum bytes}
)

Aggregation: Average

index=web | stats avg(response_time) by path

from `web_access`
group {path} (
  aggregate {avg_time = avg response_time}
)

Multiple Conditions

index=firewall action=DENY src_ip=192.168.1.100 bytes>1000

from `firewall_logs`
filter action == "DENY"
filter src_ip == "192.168.1.100"
filter bytes > 1000

Operator Reference

SPL Operator PRQL Equivalent Example
search / implicit from + filter from \pipeline` filter field == "value"`
where filter filter status >= 400
fields select select {field1, field2}
sort sort sort {-__time}
head / tail take take 100
stats count aggregate {count = count this} See examples above
stats sum() aggregate {total = sum field} See examples above
stats avg() aggregate {avg = avg field} See examples above
stats min() aggregate {min = min field}
stats max() aggregate {max = max field}
by group {field} (...) Wraps the aggregation
eval derive derive {new_field = field1 + field2}
rex / regex filter ~= filter message ~= "pattern"
dedup group + take 1 Group then take the first row
table select Same effect
rename select {new_name = old_name} Rename via select

A Note on Query Performance

CSIRT-Pro stores raw events in a single messages column and extracts fields at query time (schema-on-read). This keeps ingestion fast and parse rules flexible, which is the same model Splunk uses.

The trade-off shows up in different query shapes. Point lookups against the primary key are fast, typically well under a second. Large GROUP BY aggregations scan the messages column, so on the order of a hundred million rows they take tens of seconds. Plan migrated dashboards and scheduled detections with this profile in mind, and prefer time-bounded queries for heavy aggregations.1

Data Migration Workflow

Phase 1: Set Up Pipelines

  1. Map each Splunk index to a CSIRT-Pro Pipeline.
  2. Configure parse settings to match your existing props.conf / transforms.conf rules.
  3. Use AI Parse Generation to draft rules faster: paste a sample log line and the assistant suggests a regex and field names. You review and apply the result.

Phase 2: Parallel Ingestion

  1. Configure your log sources to send data to both Splunk and CSIRT-Pro at the same time.
  2. Confirm that data appears correctly in the CSIRT-Pro Search screen.
  3. Compare record counts between the two systems.

Phase 3: Historical Data Import

  1. Export historical data from Splunk using | outputcsv or the REST API.
  2. Convert it to JSON or NDJSON.
  3. Upload it to CSIRT-Pro with the batch ingestion API:
curl -X POST "https://<domain>/api/v2/ingest/batch" \
  -H "Content-Type: application/json" \
  -H "X-API-Key: <api_key>" \
  -d '{
    "pipeline_id": "<pipeline_id>",
    "records": [ ... ]
  }'

Phase 4: Migrate Dashboards and Alerts

  1. Recreate Splunk dashboards in CSIRT-Pro by converting SPL queries to PRQL with the mapping table above.
  2. Convert Splunk alerts to CSIRT-Pro Playbooks with schedule triggers.
  3. Migrate Phantom playbooks to CSIRT-Pro visual Playbooks with Python/JS nodes.

Phase 5: Cutover

  1. Redirect all log sources to CSIRT-Pro only.
  2. Decommission the Splunk forwarders.
  3. Keep Splunk in read-only mode until the CSIRT-Pro retention window covers your compliance requirements.

Common Questions

Can I use Sigma rules?

Yes. CSIRT-Pro provides a Sigma rule conversion endpoint that translates Sigma YAML rules into PRQL queries.

POST /api/sigma

What about saved searches and reports?

Convert your SPL saved searches to PRQL and save them as Visualizations in CSIRT-Pro. Saved Visualizations can be placed on Dashboards.

How does licensing differ?

CSIRT-Pro uses predictable pricing rather than volume-based (GB/day) licensing. This removes the cost pressure that discourages broad log collection.

  1. Measured on roughly 110M rows: compression about 9.3x, point lookups 0.2 to 1 second, and large aggregations a median of about 23 seconds. The fair comparison is schema-on-read against schema-on-read (CSIRT-Pro against Splunk), not against typed-column engines. ↩