LATCH — SIEM Onboarding & Assurance

SIEM onboarding and assurance

LATCH turns log onboarding into a governed decision path.

LATCH helps assess whether a data source is worth onboarding, technically ready, operationally supportable and aligned to SIEM detection value. Use it to move from initial viability through logging pattern selection, assurance checks, data source catalogue alignment and operational governance.

Release

What LATCH covers

Start here

Quick actions

What LATCH produces

Viability decisionProceed, proceed with conditions, investigate or block.

Security valueWhether the data source has a clear detection or assurance purpose.

Technical readinessWhether collection, auth, routing, schema and samples are ready.

Operational assuranceWhether ownership, support, monitoring and handover are defined.

Supportability riskCustom-solution, documentation and reverse-engineering risk.

Engineering complexityIngestion architecture, parsing, normalisation and technical debt.

Implementation effortDifficulty, complexity and expected time to implement.

Next actionThe recommended action before onboarding or detailed design.

The default path is intentionally decision-first: assess value and viability before committing engineering time to collection, parsing, dashboards or detections.

Log onboarding lifecycle

Onboarding flow, end to end

Every stage and decision below is a real taxonomy record, not an illustrative diagram — the Phase 1 viability gate, the pre-ingest cyber-value gates, the implementation acceptance gate, and the 90-day retain/filter/retire review that closes the loop back into sustainment.

TAX-07.01Log ViabilityIs onboarding feasible, supportable and proportionate?

TAX-07.02–03Worthiness & ImplementationIs it worth building, and was it built and accepted correctly?

TAX-06.05Cyber Value GatesDoes the parsed data clear the minimum bar to ingest?

TAX-07.04Log SustainmentDoes it stay healthy, used and worth keeping?

GATEDecision point PROCEEDContinues toward production HOLDLoops back for rework STOPReject, park or retire FEEDS INInput from outside the main path STATELifecycle state, TAX-06.04.01

Show: Select a stage or gate for its detail · step with ↑ ↓

Candidate log source identified PLANNED

A platform, application or data source is proposed for onboarding.

↓

Gate · Platform Registered? TAX-01.01 / TAX-01.02

HOLDNot registered → capture Platform & System Identity and Ownership & Accountability (owner, technical owner, security owner), then continue

PROCEEDAlready registered → continue to viability assessment

↓

Phase 1 — Viability Assessment TAX-06.01.02 / TAX-07.01 ONBOARDING

Scores security value, technical readiness and operational assurance. Custom-solution, reverse-engineering and discovery-gap modifiers adjust the result before a decision is reached.

↓

Gate · Viability Decision TAX-07.01.04

STOPNot Justified / Not Currently Viable → reject or park

HOLDFurther Investigation Required → back to viability scoring

PROCEEDViable / Viable with Conditions → continue

↓

Log Worthiness TAX-07.02

Is the security or operational value proportionate to the cost and volume of onboarding — independent of pure technical feasibility?

FEEDS IN

Named detection use cases When a source is proposed specifically to enable a known detection, its Threat Detection Use Case and Use Case–Data Source Mapping TAX-05.01 / TAX-05.02 weigh directly into the worthiness decision, not just raw security/operational value.

↓

Gate · Worthiness Decision

STOPNot worth building → reject or park

PROCEEDWorth building → select a logging pattern

↓

Select logging pattern & topology TAX-03.02 / TAX-03.05

Choose the governed collection pattern and record transport, Data Collection Authentication and firewall prerequisites.

FEEDS IN

Shared infrastructure dependencies If the topology relies on shared infrastructure — a syslog relay, forwarder pool or intermediary platform — that dependency is recorded via Dependency Mapping TAX-06.02.01 so its health and ownership stay traceable back to this source.

↓

Connectivity validation TAX-03.02.05

End-to-end transport is tested and confirmed secure — network path, TLS/certificate trust, and authentication all succeed — before parsing configuration begins.

↓

Gate · Connectivity Succeeded?

HOLDFirewall, TLS, authentication or routing failure → back to topology/collection component configuration

PROCEEDTransport succeeds securely → continue to engineering build

↓

Engineering build TAX-04.01–04.09

Datetime standards & parsing, line breaking, line length, log format detection & parsing, field extraction, field normalisation (CIM/ECS mapping), event volume profile, parsing performance — plus collection components (TAX-03) and sourcetype identity (TAX-04.11). A structural fingerprint count from the sample (distinct format/timestamp-format combinations) is the concrete signal for whether the source needs one sourcetype or several.

FEEDS IN

Naming & logging standards Index and sourcetype names, and the logging configuration itself, must comply with the approved Naming Convention and Logging Standard TAX-02.06.01 / TAX-02.06.03 before the build is considered complete.

FEEDS IN

Capacity & licensing check The forecasted Event Volume Profile from this build is checked against License Entitlement and Daily License Consumption TAX-01.06 before the source proceeds -- onboarding should not be the thing that pushes the deployment over its licensed daily volume.

↓

Ingestion check TAX-04.10.02 / TAX-04.10.03

Events are confirmed consistently searchable in the intended index, with the correct sourcetype — the same Presence & Timeliness and Volume/Gap/Duplicate checks that later back ongoing health monitoring, run here for the first time before deeper quality work begins.

↓

Gate · Ingestion Confirmed?

HOLDMissing events, wrong index or sourcetype → back to engineering build

PROCEEDConsistently searchable in the intended index → continue to data quality assessment

↓

Data quality assessment TAX-07.05–07.12 / 07.15 / 07.22–07.23 / TAX-04.07.07

Timestamp quality, log format quality, line length quality, event type coverage, required field coverage, event context completeness, data quality score, investigative context density, context dimension coverage, investigative noise percentage, volume predictability, and field normalisation / CIM mapping compliance.

↓

Gate · Quality gates pass?

HOLDNo → back to engineering build

PROCEEDYes → pre-ingest cyber-value gates

↓

Pre-ingest cyber-value gates TAX-06.05.02

Minimum parse rate, timestamp & timezone, and schema stability must all pass before any value scoring runs.

↓

Gate · Overall Gate Result TAX-06.05.02.04

HOLDFail → remediate, then back to engineering build

PROCEEDPass → cyber value scoring

↓

Cyber value scoring TAX-06.05.03–10 / TAX-07.16

Marginal novelty, pivot density & breadth (TAX-07.13/14), semantic value, entity coverage → log source value score → cyber value density → candidate rank. These roll up into the Cyber Value Index (CVI), one of the four indices behind the Cyber Monitoring Effectiveness Index.

↓

Gate · Ingestion Decision TAX-06.05.11

STOPReject → do not ingest

HOLDFilter → record a pre-ingest filtering recommendation (TAX-06.05.12), then continue

PROCEEDProceed → log implementation

↓

Log Implementation TAX-07.03

Tracks build & integration status through to a validation and acceptance result.

↓

Gate · Build & Acceptance Result

HOLDOutstanding actions → back to implementation

PROCEEDAccepted → governance approval

↓

Governance approval TAX-02.03

System Approval / Accreditation: a named approval authority records a decision, scope and expiry/review date before the source is allowed into production. Before that decision is recorded, this is also where Data Classification TAX-02.02.06, the Access Control model and authorised roles TAX-02.08, the Retention Policy TAX-02.06.05, and any Risk Assessment or Exception & Risk Acceptance TAX-02.04 are confirmed for the source -- an "Approved with conditions" outcome below is usually one or more of these still outstanding.

↓

Gate · Approval Decision TAX-02.03.03

STOPRejected → does not proceed to production

HOLDApproved with conditions → resolve conditions, then re-submit

PROCEEDApproved → operational readiness

↓

Operational readiness TAX-07.04.03 / TAX-07.04.04

Health monitoring, ownership, capacity and support are confirmed established before go-live — the same Operational Maturity and Health & Monitoring Coverage fields that Log Sustainment tracks going forward, checked here as a precondition rather than an ongoing state.

↓

Gate · Operational Readiness Confirmed?

HOLDNo monitoring, runbook or owner → back to implementation

PROCEEDEstablished → SOC readiness

↓

SOC readiness

Searches and the investigation workflow are tested against this source before go-live — confirming an analyst can actually find and use the data, distinct from the response documentation attached later in Response Readiness.

↓

Gate · SOC Ready?

HOLDDetection/investigation cannot reliably use the data → back to engineering build

PROCEEDInvestigation workflow succeeds → go live

↓

GO-LIVE Onboarding Record TAX-06.01.01 ACTIVE

Owner, phase, status and go-live date for the source, from request through to production.

↓

Log Sustainment TAX-07.04 / TAX-07.19

Operational maturity, health & monitoring coverage, and review/improvement actions — backed by reusable health checks (TAX-04.10) and assurance roll-ups (TAX-06.03). This is what the Operational Assurance Index (OAI) scores. A failing health check or assurance roll-up moves the lifecycle state to DEGRADED until remediated.

EXPIRED

Governance approval expiry When the Expiry / Review Date on the System Approval / Accreditation passes without renewal TAX-02.03.06, the lifecycle state moves to Expired and the source loops back to Governance Approval for re-authorisation.

⤷ Detection Engineering (parallel branch, once the source is live)

Detection Engineering TAX-05.03–05.05

Build the Detection Analytic & Rule against the now-live source, then run Detection Validation and record Detection Coverage — confirming the use case this source was meant to enable actually works in production.

FEEDS IN

Threat Detection Index Validated detection coverage against this source rolls up into the Threat Detection Index TAX-07.17 — how effectively detections actually use the logging data that was onboarded.

↓

Response readiness TAX-05.04 / TAX-02.07 / TAX-07.18

A validated detection isn't production-ready until someone knows what to do when it fires: attach its Response Action, Incident Response Plan, Runbook and Escalation Matrix references. This is what the Response Readiness Index (RRI) scores.

FEEDS IN

Cyber Monitoring Effectiveness Index By this point all four component indices exist for the source: Cyber Value Index TAX-07.16, Threat Detection Index TAX-07.17, Response Readiness Index TAX-07.18 and Operational Assurance Index TAX-07.19 — the four inputs that roll up into the overarching Cyber Monitoring Effectiveness Index TAX-07.20.

↓

90-day value review TAX-06.05.14

Investigations, detections, alerts and true positives against the source feed a realised-value rank, compared against the rank predicted at onboarding.

↓

Gate · Retain, Filter or Retire Decision

RETAINContinue in sustainment

FILTERAdjust pre-ingest filtering, then continue

RETIREOffboard the source RETIRED

This is a loop, not a one-way door. Further-investigation, quality-gate failures, filtering adjustments and the 90-day review all route back into an earlier stage rather than dead-ending — onboarding is treated as reversible until value is actually demonstrated in production.

Detection lifecycle

How one detection moves from use case to retirement, following the Detection & Response taxonomy: its states come from Detection Lifecycle State TAX-05.03.02 and it reaches production through the Detection Quality Gate TAX-05.03.12. It runs inside the Detection Engineering stage above, once per detection. The phases, and the gates other than the Detection Quality Gate, are a working model built from the taxonomy’s own items.

Threat detection use case TAX-05.01.01 PROPOSED

The security behaviour, threat scenario or control objective that needs detecting, written as a testable threat hypothesis: the attacker action expected, the evidence it should leave, and what would confirm or contradict it.

↓

Threat mapping & context TAX-05.01.02 / TAX-05.01.03

Map the use case to its MITRE ATT&CK tactic, technique and sub-technique, and link it to the threat actor, campaign, malware or tool and attack path it addresses.

↓

Gate · Hypothesis testable, value established? TAX-05.03.12

REJECTNo security value → reject the use case

HOLDHypothesis not testable → refine the use case

PROCEEDTestable, with clear security value → define data requirements

↓

Data & event requirements TAX-05.02.01 / TAX-05.02.02

Record the data sources and event types the use case needs, through the Use Case–Data Source and Use Case–Event mappings.

↓

Gate · Required sources & fields available? TAX-05.03.12

DATA GAPSource or fields missing → request log source onboarding, then reassess the data requirements

PROCEEDSources ACTIVE, fields present and timestamps trustworthy → build the analytic

LOG SOURCE JOURNEY

Data gap → request onboarding A missing source starts a new log source journey at Candidate log source identified.

LOG SOURCE JOURNEY

Source is live A detection passes data readiness only for sources that have reached GO-LIVE (ACTIVE) on the log source journey.

↓

Detection analytic & rule TAX-05.03.01 / TAX-05.03.03–05.03.06 DEVELOPMENT

Write the SPL, correlation search, risk rule, threshold or model, choosing its analytic type, correlation approach, risk-based detection settings and enrichment dependencies (identity, asset, vulnerability, threat intelligence).

LOG SOURCE JOURNEY

Built per detection This lifecycle is what the Detection Engineering stage of the log source journey runs, once for each detection against the source.

↓

Thresholds, exclusions & timing TAX-05.03.09–05.03.11

Calibrate thresholds and baselines, define allowlists, suppressions and exclusions, and set the time window, lookback and schedule.

↓

Detection-as-code TAX-05.08.01

Author and version-control the detection content as code, ready for peer review.

↓

Detection testing TAX-05.05.04 TESTING

Unit, positive, negative, boundary, missing-field, duplicate, late-event, replay, backfill, regression, performance and synthetic-event tests.

↓

Detection validation TAX-05.05.01 / TAX-05.05.05

Prove the use case and analytic work as intended with a test scenario and result. The enhanced tier adds adversarial validation: purple- or red-team engagements that test resistance to evasion.

↓

Peer review TAX-05.08.01 PEER REVIEW

Review the logic, thresholds, ATT&CK mapping and analyst guidance before the change is accepted.

↓

Gate · Detection Quality Gate TAX-05.03.12

HOLDAny checklist item failing → back to the analytic

PROMOTEAll items pass → deploy to production PRODUCTION

ENHANCEDEnhanced tier requested → adversarial validation first

Go / no-go checklist

Hypothesis defined
Security value established
Required sources and fields available
Timestamps trustworthy
Analytic logic and thresholds documented and justified
ATT&CK mapping correct
Positive, negative and boundary tests passing
Known false positives and negatives documented
Telemetry loss and duplicate or late events considered
Performance tested
Peer review passed
Analyst guidance complete
Health monitoring defined
Deployment reversible

Enhanced tier (optional)

Purple Team validation
Adversarial bypass testing
Alternate-implementation testing
Independent source-completeness validation
End-to-end behaviour validation

↓

CI/CD & deployment TAX-05.08.02 PRODUCTION

Promote the detection through environments with CI checks, a defined deployment mechanism and rollback, and watch for configuration drift between environments.

↓

Response action & triage TAX-05.04.01 / TAX-05.07.02

Attach the notable event, SOAR playbook, investigation guide and escalation action, and the analyst triage procedure for working the alert.

↓

Gate · Deployment verified? TAX-05.08.02

ROLL BACKErrors or excessive noise in production → roll back and fix

PROCEEDHealth monitoring live and analyst guidance published → operate

↓

Detection health TAX-05.03.07 MONITORING

Enabled state, last run and trigger time, runtime, search lag, skipped searches, input freshness, field completeness, result volume, and the health of the lookups, data models and dependencies it relies on.

LOG SOURCE JOURNEY

Source health A failing health check that moves the source to DEGRADED on the log source journey shows up here as input freshness and field completeness problems.

↓

Quality metrics & effectiveness TAX-05.05.06 / TAX-05.05.07

True, false and missed positives, precision, recall, fidelity and known blind spots, plus alert volume and value.

FEEDS IN

Threat Detection Index Quality metrics supply the Fidelity component of the Threat Detection Index TAX-07.17.

LOG SOURCE JOURNEY

True positives → 90-day value review Investigations, detections, alerts and true positives against the source feed its 90-day value review.

↓

Drift review TAX-05.03.13

Has the threat or normal behaviour changed, has the analytic been bypassed, and has ATT&CK, the platform or the source schema changed? Decide whether to retune or redesign.

↓

Gate · Keep, retune, revalidate or retire? TAX-05.03.02

KEEPHealthy and effective → keep monitoring

RETUNENoisy or drifting thresholds → tune TUNING

REVALIDATESchema, platform or technique changed → retest REVALIDATION

RETIREObsolete, or its source retired → deprecate, then retire DEPRECATED RETIRED

LOG SOURCE JOURNEY

Source retired Retiring a source at its 90-day review forces every detection built on it to revalidate or retire.

Framework reference

Concepts, methodologies and terminology

Use this area to understand how LATCH fits together, what specialised terms mean, and how each assessment reaches its score or decision. The taxonomy remains the canonical data model; this page explains the concepts behind it. Framework overview, Concepts & definitions, Assessment methodologies, Standards & references, Configuration file reference, Network reference, Roles, Splunk bin and Questions all live in the Reference group of the main menu.

← Back to References

References / Detailed reference

Event Context Completeness Score (ECCS)

ECCS measures how completely representative events answer the seven investigative questions needed for cyber investigations, detection engineering, threat hunting and incident response. It assesses the usefulness and richness of context, not merely whether fields exist.

Definition

ECCS measures the completeness and investigative usefulness of context within representative log events. It tests whether an analyst can establish when activity occurred, who performed it, where it happened, what occurred, whether it succeeded, why it matters and how it can be correlated. ECCS is one of four Cyber Value Index components because contextual completeness directly affects detection, triage, reconstruction and response.

Score each dimension from 0 to 4 and award points for usable context rather than field presence alone. A populated but ambiguous, inconsistent or operationally unusable field should not receive full credit.

ECCS (%) = (total score / 28) × 100Seven equally weighted dimensions × a maximum of 4 points = 28 points.

The seven investigative dimensions

Expand a dimension for its investigative question, assessment focus, example fields, full score scale, scoring guidance and common mistakes.

1When

Investigative question

When did the activity occur, and can its sequence and duration be reconstructed reliably?

What to assess

Event time, timezone or UTC offset, precision, duration, start/end time and multiple relevant timestamps.

Example fields

_timetimestampevent_timestart_timeend_timeduration

0–4 scoring

0: No meaningful timestamp.

1: Timestamp only.

2: Timestamp with limited precision.

3: Precise timestamp with timezone.

4: Precise timeline including duration or multiple relevant timestamps.

Scoring guidance

Confirm the value represents event time rather than ingest time and is consistently parseable across the sample.

Common mistakes

Awarding full credit to a timestamp with no timezone, assuming Splunk _time is source event time, or ignoring clock drift.

2Who

Investigative question

Who or what identity performed, requested or owned the activity?

What to assess

Username, account, service account, SID, principal, email, role, identity-provider ID and process owner.

Example fields

userusernameaccountsidprincipalactoremail

0–4 scoring

0: No identity.

1: Weak identity.

2: One usable identity.

3: Multiple identity attributes.

4: Complete identity context including account type or ownership.

Scoring guidance

Prefer stable identifiers plus a human-readable identity and clarify whether the actor is a person, workload or service.

Common mistakes

Treating a display name as unique, confusing subject and target identities, or counting an empty/default account value.

3Where

Investigative question

Where did the activity originate, execute and terminate?

What to assess

Hostname, device, source/destination IP, cloud resource, tenant, VM, container, node and region.

Example fields

hosthostnamesrc_ipdest_ipasset_idtenantcloud_resource

0–4 scoring

0: No location.

1: One location attribute.

2: Host or IP only.

3: Host plus network context.

4: Complete infrastructure context.

Scoring guidance

Assess whether infrastructure identifiers resolve to governed assets and distinguish source, destination and processing locations.

Common mistakes

Using a collector host as the event host, ignoring NAT or proxies, or assuming an IP uniquely identifies an asset.

4What

Investigative question

What activity, operation or state change occurred, and to which object?

What to assess

Event type, action, resource, object, process, command, API, file, registry key, service and operation.

Example fields

actionoperationprocesscommandobjectfileevent_type

0–4 scoring

0: Unclear activity.

1: Generic activity.

2: Identifiable action.

3: Detailed operation.

4: Complete operational context.

Scoring guidance

Require enough detail to distinguish the operation, target and relevant parameters without relying solely on vendor event codes.

Common mistakes

Giving full credit to an untranslated numeric ID, counting a category as an action, or omitting the affected object.

5Outcome

Investigative question

Did the activity succeed, fail or partially complete, and why?

What to assess

Result, success flag, status, return code, error, reason and authentication result.

Example fields

resultstatussuccessreasonstatus_codeerror

0–4 scoring

0: Unknown outcome.

1: Vague result.

2: Success or failure only.

3: Detailed result.

4: Complete outcome including reason or status code.

Scoring guidance

Verify that result values are normalised and distinguish attempted actions from completed actions.

Common mistakes

Inferring success from event presence, treating HTTP status alone as business outcome, or overlooking partial completion.

6Impact

Investigative question

Why does the activity matter, and how urgently should it be investigated?

What to assess

Severity, priority, risk, classification, confidence, alert level, policy and threat score.

Example fields

severitypriorityriskclassificationconfidencepolicy

0–4 scoring

0: No impact context.

1: Minimal impact context.

2: Severity only.

3: Meaningful impact information.

4: Comprehensive impact context.

Scoring guidance

Reward meaningful, calibrated risk context tied to the event, affected asset, policy or threat rather than generic source severity.

Common mistakes

Equating vendor severity with organisational impact, awarding points to a constant default, or ignoring asset criticality.

7Correlation

Investigative question

Can the event be joined to related activity across time, systems and data sources?

What to assess

Session, trace, correlation, transaction, process, parent-process, request and globally unique identifiers.

Example fields

session_idtrace_idcorrelation_idprocess_idparent_process_idrequest_id

0–4 scoring

0: No correlation identifiers.

1: One weak identifier.

2: One usable pivot.

3: Multiple pivot identifiers.

4: Rich correlation context across systems.

Scoring guidance

Test whether identifiers are stable, sufficiently unique and actually present in related sources.

Common mistakes

Counting a non-unique hostname as rich correlation, confusing event ID with correlation ID, or rewarding identifiers that cannot be searched elsewhere.

Complete 0–4 scoring matrix

Apply the best description supported by the sampled events. Consider consistency across the sample as well as the best individual event.

Score	Meaning	Guidance
0	Missing	No useful information.
1	Minimal	Basic context.
2	Partial	Useful but incomplete.
3	Good	Suitable for most investigations.
4	Complete	Rich investigative context.

Dimension	0 — Missing	1 — Minimal	2 — Basic	3 — Good	4 — Excellent
When	No meaningful timestamp.	Timestamp only.	Timestamp with limited precision.	Precise timestamp with timezone.	Precise timeline including duration or multiple relevant timestamps.
Who	No identity.	Weak identity.	One usable identity.	Multiple identity attributes.	Complete identity context including account type or ownership.
Where	No location.	One location attribute.	Host or IP only.	Host plus network context.	Complete infrastructure context.
What	Unclear activity.	Generic activity.	Identifiable action.	Detailed operation.	Complete operational context.
Outcome	Unknown outcome.	Vague result.	Success or failure only.	Detailed result.	Complete outcome including reason or status code.
Impact	No impact context.	Minimal impact context.	Severity only.	Meaningful impact information.	Comprehensive impact context.
Correlation	No correlation identifiers.	One weak identifier.	One usable pivot.	Multiple pivot identifiers.	Rich correlation context across systems.

Worked examples

The detailed event examples show how evidence supports each dimension score. The additional percentage profiles demonstrate the calculation across a wider range of completeness.

Worked Example 1 — Windows Logon Event: 75% (21 / 28)

{
  "Time": "2026-07-21T09:14:03.654Z",
  "User": "jsmith",
  "SID": "S-1-5-21...",
  "Host": "PC-123",
  "SourceIP": "10.1.5.25",
  "EventType": "4624",
  "Result": "Success",
  "LogonID": "0x6A41F",
  "Process": "winlogon.exe"
}

Dimension	Score	Reason
When	4	UTC timestamp with millisecond precision.
Who	4	Username plus stable SID.
Where	3	Host and source IP provide endpoint and network context.
What	3	Windows logon event and process are identified.
Outcome	3	Success is explicitly recorded.
Impact	1	Little risk, severity or policy context.
Correlation	3	Logon ID provides a strong session pivot.

Total = 21 / 28 | ECCS = 75% | Rating = Good

Worked Example 2 — Firewall Permit Event: 54% (15 / 28)

{
  "Time": "2026-07-21T09:18:41+10:00",
  "SourceIP": "10.1.5.25",
  "DestinationIP": "203.0.113.20",
  "SourcePort": 51542,
  "DestinationPort": 443,
  "Action": "permit",
  "Protocol": "tcp",
  "RuleID": "WEB-OUT-01",
  "SessionID": "987654321"
}

Dimension	Score	Reason
When	3	Precise timestamp with explicit UTC offset.
Who	0	No user, account or workload identity.
Where	3	Source and destination IP and port context are present.
What	3	Permit action, protocol and rule are identified.
Outcome	3	The permit decision is explicit.
Impact	0	No severity, risk, classification or asset criticality.
Correlation	3	Session ID and rule ID support useful pivots.

Total = 15 / 28 | ECCS = 53.6%, rounded to 54% | Worked-example rating = Weak; detailed interpretation below = Poor

Identity and impact are absent, so the event can explain a network decision but cannot attribute it or help an analyst prioritise its significance.

Worked Example 3 — Microsoft Entra ID Sign-in: 96% (27 / 28)

{
  "createdDateTime": "2026-07-21T09:22:16.481Z",
  "userPrincipalName": "jsmith@example.com",
  "userId": "7be2f28d-...",
  "ipAddress": "198.51.100.42",
  "resourceDisplayName": "Microsoft 365",
  "operation": "User sign-in",
  "result": "Success",
  "conditionalAccessStatus": "success",
  "riskLevelDuringSignIn": "low",
  "authenticationMethod": "FIDO2 security key",
  "correlationId": "b92e6cf4-..."
}

Dimension	Score	Reason
When	4	UTC timestamp with millisecond precision.
Who	4	User Principal Name plus immutable object ID.
Where	3	Source IP and cloud resource are present; fuller device/location context would complete it.
What	4	Sign-in operation, target resource and authentication method are explicit.
Outcome	4	Sign-in and Conditional Access results are recorded.
Impact	4	Risk and Conditional Access context support prioritisation.
Correlation	4	Correlation ID and user object ID support cross-service investigation.

Total = 27 / 28 | ECCS = 96.4%, rounded to 96% | Worked-example rating = Excellent; detailed interpretation below = Exceptional

85.7% — Excellent (24 / 28)

When 4Who 4Where 4What 4Outcome 3Impact 2Correlation 3

Calculation: (24 / 28) × 100 = 85.7%. Rich time, identity, infrastructure and activity context; impact and cross-system correlation still have room to improve.

75% — Good (21 / 28)

When 3Who 3Where 3What 4Outcome 3Impact 2Correlation 3

Calculation: (21 / 28) × 100 = 75%. The event is investigation-ready but lacks comprehensive impact and top-tier identity, location and timeline enrichment.

60.7% — Fair (17 / 28)

When 3Who 2Where 3What 3Outcome 2Impact 2Correlation 2

Calculation: (17 / 28) × 100 = 60.7%. Core activity can be understood, but pivots, identity, result detail and impact provide only basic support.

46.4% — Poor (13 / 28)

When 2Who 2Where 2What 3Outcome 2Impact 1Correlation 1

Calculation: (13 / 28) × 100 = 46.4%. The action is identifiable, but weak impact and correlation context will slow triage and reconstruction.

25% — Very Poor (7 / 28)

When 2Who 1Where 1What 2Outcome 1Impact 0Correlation 0

Calculation: (7 / 28) × 100 = 25%. Only basic time and action clues exist; the event does not explain significance or support reliable pivots.

7.1% — Minimal (2 / 28)

When 1Who 0Where 0What 1Outcome 0Impact 0Correlation 0

Calculation: (2 / 28) × 100 = 7.1%. A timestamp and generic activity are present, but the event has almost no investigative context.

Approximately 96.4% — Exceptional (27 / 28)

When 4Who 4Where 4What 4Outcome 4Impact 3Correlation 4

Calculation: (27 / 28) × 100 = 96.4% (rounded). Context is comprehensive across the investigative lifecycle; only impact context falls just short of the highest descriptor.

Investigation value

Every dimension removes a different investigative blind spot. Missing dimensions compound one another and can turn a technically valid event into unusable evidence.

Missing WhenPrevents reliable sequencing, scoping and timeline reconstruction.

Missing WhoMakes attribution to a person, account or workload difficult.

Missing WhereObscures the affected asset, origin, destination and infrastructure path.

Missing WhatLeaves the action or affected object ambiguous.

Missing OutcomeMakes it impossible to know whether an attempted action succeeded.

Missing ImpactMakes prioritisation and risk-based triage difficult.

Missing CorrelationCauses investigations to stop at one event instead of following related activity.

Interpretation

ECCS	Rating	Investigation capability
90–100	Exceptional	Complete Investigation Ready
80–89	Excellent	Investigation Ready
70–79	Good	Operationally Useful
60–69	Fair	Supporting Evidence
40–59	Poor	Limited Evidence
20–39	Very Poor	Requires Significant Enrichment
0–19	Minimal	Not Investigation Capable

Relationship to the Cyber Value Index (CVI)

ECCS contributes 25% of CVI. The complete CVI combines Event Type Coverage (30%), Required Field Coverage (25%), ECCS (25%) and Data Quality Score (20%): CVI = (ETC × 0.30) + (RFC × 0.25) + (ECCS × 0.25) + (DQS × 0.20). ECCS therefore measures contextual investigation readiness within CVI; it does not replace coverage or technical data-quality measures.

← Back to References

References / Detailed reference

Marginal Novelty

Marginal Novelty measures the useful security information a candidate log source adds beyond telemetry already available. It rewards genuinely incremental evidence, not duplicate volume, renamed fields or a second copy of the same underlying event.

Definition

Marginal Novelty is the percentage of useful information in a candidate source that cannot be reconstructed with acceptable fidelity from existing approved sources. The comparison must consider meaning, timing, identity, entities, relationships, outcome and investigation utility—not merely whether another source contains similarly named events.

Marginal Novelty (%) = 100 − Reconstructible PercentageEquivalent form: (novel useful information / total useful information assessed) × 100.

Example: if 30% of useful information can be reconstructed from existing telemetry, Marginal Novelty is 70%.

Assessment prerequisites

The local Log Source Cyber Value calculator produces a value score only after all three quality gates pass. Novelty evidence should also identify the comparison boundary and representative sample.

Parse-rate gateAt least 95% of the representative sample parses successfully.

Timestamp and timezone gateUsable event time and explicit or reliably derived timezone are present.

Schema-stability gateFields and structures are consistent enough for dependable comparison.

Comparison inventoryList every existing source, sample period, entity population and use case included or excluded.

Marginal Novelty assessment lenses

Use all six lenses to estimate the reconstructible percentage. They are evidence prompts, not separate scores to average.

1Comparison scope

Investigative question

Which existing sources and populations could reproduce the candidate evidence?

What to assess

Source inventory, coverage boundary, sample window, retention, entity population, event classes and collection gaps.

Evidence

source inventorysample periodentity scoperetentioncoverage gaps

Guidance

Compare like-for-like time periods and entities. Record exclusions and sources that are planned but not yet operational.

Common mistakes

Comparing only against the easiest source, treating unavailable future telemetry as current coverage, or ignoring retention differences.

2Event and behaviour novelty

Investigative question

Does the candidate reveal security-relevant actions or state changes not otherwise observable?

What to assess

Unique event types, operations, control-plane activity, failure modes, policy decisions and behaviours.

Evidence

event_typeactionoperationcategorypolicy_decision

Guidance

Test whether an analyst can infer the same behaviour from existing events with acceptable confidence and timeliness.

Common mistakes

Counting vendor-specific names as new behaviours or treating a more verbose duplicate event as fully novel.

3Field and context novelty

Investigative question

Which useful attributes does the candidate add to otherwise known activity?

What to assess

Identity, device, network, object, authentication, command, reason, risk, policy and outcome attributes.

Evidence

user_iddevice_idcommandreasonriskoutcome

Guidance

Weight fields by investigative utility and population coverage rather than counting every new key equally.

Common mistakes

Rewarding cosmetic fields, constants, aliases, duplicated raw/normalised values or identifiers that cannot be operationally used.

4Entity and relationship novelty

Investigative question

Does the source expose new entities, relationships or pivots?

What to assess

Users, workloads, assets, cloud resources, sessions, process trees, transactions and source-to-destination relationships.

Evidence

asset_idobject_idsession_idparent_processsrcdest

Guidance

Confirm new identifiers resolve to real entities and link to other telemetry rather than merely increasing cardinality.

Common mistakes

Counting random GUIDs as useful novelty or claiming new coverage where the same entity is already fully observable.

5Semantic and outcome novelty

Investigative question

Does the candidate explain meaning, result or significance that existing sources cannot?

What to assess

Success/failure, reason, enforcement decision, authentication method, confidence, severity, risk and business meaning.

Evidence

resultstatus_codereasonrisk_levelconfidenceauth_method

Guidance

Test whether existing telemetry supports the same conclusion without fragile inference or analyst guesswork.

Common mistakes

Equating richer prose with new meaning or treating a default severity as unique impact context.

6Operational utility novelty

Investigative question

Does the source improve detection, triage, correlation or response in a way existing telemetry cannot?

What to assess

Detection enablement, time-to-triage, false-positive reduction, investigation pivots, response decisions and evidence confidence.

Evidence

detection testscase replaypivot successtriage timeresponse action

Guidance

Use representative detection and investigation scenarios; document whether the candidate changes an analyst decision.

Common mistakes

Claiming novelty from hypothetical use cases without testing, or confusing convenience with otherwise unavailable evidence.

Calculation and local scoring matrix

Estimate the reconstructible share of useful information, subtract it from 100%, then apply the same band used by the embedded Log Source Cyber Value calculator. Marginal Novelty carries a weight of 2.0.

Score	Marginal Novelty	Reconstructible	Meaning	Weighted contribution
0	0–<10%	>90–100%	Negligible incremental information.	0 / 10
1	10–<25%	>75–90%	Low novelty; most useful evidence already exists.	2 / 10
2	25–<50%	>50–75%	Limited novelty with identifiable additions.	4 / 10
3	50–<75%	>25–50%	Moderate novelty; the source adds material evidence.	6 / 10
4	75–<90%	>10–25%	High novelty; little can be reproduced elsewhere.	8 / 10
5	90–100%	0–10%	Exceptional novelty; evidence is substantially unique.	10 / 10

Evidence rule: retain the sample, comparison searches, join keys, source inventory, assumptions and unresolved gaps. Do not assign a percentage from stakeholder opinion alone.

Worked examples

Worked Example 1 — Firewall traffic versus NetFlow, DNS and proxy: 30%

Evidence area	Comparison finding	Novel contribution
Network flow	NetFlow reconstructs source, destination, ports, protocol and timing.	Minimal.
Destination context	DNS and proxy reconstruct domain and web destination for most sessions.	Some non-web destinations remain unique.
Policy decision	Existing sources cannot reproduce firewall rule, zone and permit/deny reason.	Material policy evidence.
Identity and impact	No additional identity or risk context.	None.

Reconstructible = 70% | Marginal Novelty = 100 − 70 = 30% | Score = 2 | Weighted contribution = 4 / 10

The source is partly duplicative but adds policy-enforcement evidence that the flow, DNS and proxy sources cannot reliably reconstruct.

Worked Example 2 — Microsoft Entra sign-ins versus VPN and endpoint telemetry: 55%

Evidence area	Comparison finding	Novel contribution
User and source IP	VPN and endpoint sources reproduce many user/IP associations.	Limited for managed users.
Cloud authentication	Authentication method, token context and cloud application are absent elsewhere.	High.
Conditional Access	Policy result and failure reason cannot be reconstructed.	High.
Risk and correlation	Entra risk state, object ID and correlation ID add cloud-specific pivots.	High.

Reconstructible = 45% | Marginal Novelty = 100 − 45 = 55% | Score = 3 | Weighted contribution = 6 / 10

The candidate overlaps on basic identity and location but adds cloud-native authentication, risk and enforcement context.

Worked Example 3 — EDR process telemetry versus Windows process creation: 92%

Evidence area	Comparison finding	Novel contribution
Process start	Windows process creation reproduces basic image, command line, user and time for covered hosts.	Low.
Process relationships	EDR adds durable process GUIDs, ancestry and cross-event lineage.	High.
Security context	Behaviour classification, reputation, signer, prevalence and detection context are unique.	High.
Response context	Containment state and response actions cannot be reconstructed.	High.

Reconstructible = 8% | Marginal Novelty = 100 − 8 = 92% | Score = 5 | Weighted contribution = 10 / 10

Although basic process creation overlaps, nearly all higher-value lineage, detection and response evidence is unique.

Interpretation and decision use

Novelty	Rating	Decision implication
90–100%	Exceptional	Strong unique-evidence case, subject to gates, volume and mandatory requirements.
75–<90%	High	Substantial incremental evidence; prioritise value and coverage validation.
50–<75%	Moderate	Material addition; assess whether the unique portion justifies full ingestion.
25–<50%	Limited	Consider selective event classes or field-level filtering.
10–<25%	Low	Most value is duplicated; require a focused use case or mandatory driver.
0–<10%	Negligible	Prefer existing sources unless assurance, compliance or resilience requires duplication.

Novelty is not sufficient on its own. A highly novel source can still be low value if it lacks useful pivots, semantics, entity coverage or reliable quality. A low-novelty source may still be required for compliance, resilience or authoritative evidence.

Relationship to Log Source Cyber Value and CVI

Marginal Novelty is the highest-weighted component in the local Log Source Cyber Value model. Its 0–5 score is multiplied by 2.0, contributing up to 10 of the total 40 points. The other components are Pivot Density (×1.5), Semantics (×1.5), Pivot Breadth (×1.0), Entity Coverage (×1.0) and Detection Value (×1.0). Marginal Novelty is not a direct component of the separate Cyber Value Index formula, which combines ETC, RFC, ECCS and DQS.

← Back to References

References / Detailed reference

Investigative Context Density (ICD)

ICD measures the breadth of distinct investigative context types present in each event and across a representative file. It shows how much pivotable, explanatory context an analyst receives per event, while separating context-rich signal from events below an approved usefulness threshold.

Definition

Investigative Context Density is the number of distinct, usable context types represented in an event, optionally normalised against an approved context catalogue. A context type is a meaningful class of evidence—such as a stable user identifier, source network address, process lineage or correlation ID—not every populated field.

ICD measures breadth rather than mere field count. Aliases, repeated values, formatting fields, constants and multiple fields representing the same context type count once per event. The local calculator uses a 36-type catalogue and a minimum of 5 types by default; both values are configurable and must be governed with the assessment evidence.

Formulas

Event ICD (%) = (distinct context types / catalogue size) × 100Calculate separately for every valid event.

File-average ICD (%) = mean of all valid event ICD percentagesEquivalent to average context-type count divided by catalogue size.

Signal (%) = (events at or above minimum / valid events) × 100Default minimum: 5 distinct types.

Noise (%) = (events below minimum / valid events) × 100Signal plus noise equals 100% of valid events.

Default 36-type investigative context catalogue

The catalogue groups 36 locally defined types into six families. Expand each family to see the types and counting guidance. Organisations may version and tailor the catalogue, but comparisons are valid only when they use the same approved version.

1Identity context (6 types)

Catalogue types

user/account namestable user ID/SIDemail/UPNaccount type/service identityrole/grouptarget identity

Counting guidance

A username and account alias describing the same actor count as one type; a username plus a stable SID count as two because they provide different investigative utility.

Common mistakes

Counting subject and target fields without confirming their roles, or treating empty, anonymous and default identities as usable context.

2Asset and location context (6 types)

Catalogue types

hostname/deviceasset/endpoint IDsource network addressdestination network addresscloud resource/tenantregion/site/workload location

Counting guidance

Count source and destination separately when both support different pivots. A collector host does not count as the affected event host.

Common mistakes

Counting IP and translated IP as unrelated types, or rewarding infrastructure values that cannot be resolved to governed assets.

3Activity and object context (6 types)

Catalogue types

event type/categoryaction/operationprocess/imagecommand/parametersfile/configuration objectapplication/API/resource

Counting guidance

Count an event type and an action separately only when one classifies the event and the other describes the actual operation.

Common mistakes

Counting an untranslated vendor code as rich context or splitting file path, name and extension into three types.

4Time and outcome context (6 types)

Catalogue types

event time/timezonestart/end/durationsuccess/failurestatus/return codereason/errorauthentication/policy decision

Counting guidance

Event time and duration are distinct types. Result and status code may count separately when the code adds diagnostic meaning beyond the normalised result.

Common mistakes

Counting ingest time as event time, inferring success from event presence, or counting duplicate textual and numeric status aliases.

5Impact and security context (6 types)

Catalogue types

severity/priorityrisk/threat scoreclassificationconfidencepolicy/controlvulnerability/technique/indicator

Counting guidance

Only count values that are meaningful for the individual event and usable for triage, detection or response.

Common mistakes

Counting a source-wide default severity, confusing category with impact, or rewarding uncalibrated scores with no interpretation.

6Correlation and pivot context (6 types)

Catalogue types

session/logon IDcorrelation/request/trace IDprocess GUID/PIDparent process IDhash/certificate identifierURL/domain/object record ID

Counting guidance

Count distinct pivot classes, not every identifier field. Confirm identifiers are stable, sufficiently unique and searchable in related telemetry.

Common mistakes

Counting an event code as a correlation key, treating random unsearchable GUIDs as useful, or counting PID and process GUID as equivalent duplicates without testing.

Assessment method

1. Define the catalogueRecord catalogue version, owner, 36-type default or approved variation, and the minimum useful threshold.

2. Select a representative sampleInclude major event classes, normal and failure activity, relevant entities, and a documented time window.

3. Map and de-duplicateMap fields to context types and count each distinct type once per event, regardless of aliases or repeated fields.

4. Calculate event ICDDivide each event’s distinct type count by the catalogue size and retain the raw count alongside the percentage.

5. Calculate file resultsReport event count, average types, average ICD, full-catalogue events, signal/noise percentages and distribution.

6. Review the distributionDo not rely on the average alone; identify sparse event classes, outliers and context concentrated in rare events.

Calculator input rule: each non-blank line may be a numeric type count or a comma, pipe, semicolon or tab-delimited list. Values are trimmed, lower-cased and de-duplicated; counts are capped at the configured catalogue size.

Interpretation

File-average ICD	Rating	Meaning
81–100%	Very rich	Extensive investigative context breadth across assessed events.
61–<81%	Rich	High investigative context availability.
41–<61%	Moderate	Useful context with material enrichment opportunities.
21–<41%	Basic	Limited investigative context breadth.
0–<21%	Sparse	Very little investigative context is present.

Read density with threshold compliance. An average can hide a large sparse population. Always report the percentage and count of events below the configured minimum, plus the distribution by context-type count.

Worked examples

Worked Example 1 — Windows logon: 9 / 36 = 25% ICD

event timeuser accountuser SIDhostnamesource IPevent typeoutcomelogon IDprocess

Distinct types = 9 | Event ICD = (9 / 36) × 100 = 25% | Rating = Basic | Classification at minimum 5 = Signal

The event offers useful identity, location, activity and correlation breadth, but many catalogue types are irrelevant to a normal logon and should not be forced into the event.

Worked Example 2 — Firewall permit: 6 / 36 = 16.7% ICD

event timesource addressdestination addressactionpolicy/controlsession ID

Distinct types = 6 | Event ICD = (6 / 36) × 100 = 16.7% | Rating = Sparse | Classification at minimum 5 = Signal

A Sparse rating does not automatically mean useless: this event meets the local minimum and supplies the core network and policy context expected from its event class.

Worked Example 3 — Microsoft Entra sign-in: 12 / 36 = 33.3% ICD

event timeUPNobject IDsource IPcloud resourceoperationauthentication methodoutcomereason/statusriskpolicy decisioncorrelation ID

Distinct types = 12 | Event ICD = (12 / 36) × 100 = 33.3% | Rating = Basic | Classification at minimum 5 = Signal

The event carries broader identity, cloud, authentication, impact and correlation context than the firewall example.

Worked Example 4 — Five-event file result

Event	Distinct types	Event ICD	Minimum 5 classification
1	9	25.0%	Signal
2	6	16.7%	Signal
3	12	33.3%	Signal
4	4	11.1%	Noise
5	2	5.6%	Noise

Average types = 33 / 5 = 6.6 | File-average ICD = (6.6 / 36) × 100 = 18.3% (Sparse) | Signal = 60% | Noise = 40%

The file average is Sparse even though most events meet the minimum. The distribution shows that two low-context event classes materially reduce investigation value.

Worked Example 5 — Rich event: 24 / 36 = 66.7% ICD

identity 5asset/location 4activity/object 5time/outcome 4impact/security 3correlation/pivots 3

Distinct types = 24 | Event ICD = (24 / 36) × 100 = 66.7% | Rating = Rich | Classification at minimum 5 = Signal

This profile is typical of a high-quality security detection or enriched EDR event with context spanning all six catalogue families.

Investigation value and related measures

ICDMeasures granular context breadth: how many distinct catalogue types are present.

Context Dimension Coverage (CDC)Measures coverage of seven broad questions: When, Who, Where, What, Outcome, Impact and Correlation.

Investigative Noise Percentage (INP)Measures the percentage of valid events below an approved usefulness threshold; ICD can supply that threshold metric.

ECCSMeasures the quality and completeness of seven dimensions on a 0–4 scale, not the count of granular types.

Relationship to cyber value: ICD is not a direct component of the CVI formula. It provides supporting evidence for Required Field Coverage, ECCS, pivot breadth and broader Log Source Cyber Value decisions. Use ICD to identify enrichment opportunities—not as a reason to add irrelevant fields merely to increase a score.

← Back to References

References / Detailed reference

Pivot Density and Pivot Breadth

Pivot Density measures how consistently events contain at least one usable investigation key. Pivot Breadth measures how many different categories of usable keys occur across a meaningful share of the dataset. Together they show whether investigations can start reliably and continue across multiple independent paths.

Definitions and formulas

Pivot Density (%) = (events with one or more usable pivot keys / total valid events) × 100Each event counts once, regardless of how many pivots it contains.

Pivot Breadth = number of qualifying pivot categories presentQualifying coverage depends on the documented assessment mode.

Density answers: “How often can an analyst pivot from an event?” Breadth answers: “How many different investigative routes are available across the dataset?” A source can score highly on one and poorly on the other.

What makes a pivot usable?

Identifies something meaningfulThe value refers to a person, asset, session, process, object, resource, transaction or other investigation entity.

Sufficiently stable and uniqueThe value narrows related activity without producing an unmanageable number of unrelated matches.

Searchable in related evidenceAn analyst can use it in the same dataset or another available source to continue the investigation.

Correctly scopedThe field’s role is clear—for example source user versus target user, or process ID qualified by host and time.

Consistently populatedThe field is valid across the event classes and populations claimed by the assessment.

Operationally safeNormalisation, truncation, hashing, reuse and retention do not make the key misleading or unusable.

Do not count by default: timestamps, severity, generic event IDs, source-wide constants, empty/default values or static metadata. Count them only when they uniquely identify related activity and the evidence demonstrates that use.

Pivot categories

Group individual fields into logical categories so aliases do not inflate breadth. The categories below implement the existing Pivot Analysis prompt.

1Identity and host pivots

User identity

usernameuser_idemailSIDobject_id

Host identity

hostnamedevice_nameasset_idendpoint_idserial_number

Guidance

Stable IDs and readable names may coexist within one category. Do not count aliases as separate breadth categories.

2Network, URL and DNS pivots

Network identity

src_ipdest_ipMAC

URL / Web

urluri

DNS

domainFQDNdns_query

Guidance

IP addresses are useful only with appropriate time, direction and NAT/proxy context. Domains and URLs count as separate categories when both provide distinct pivot paths.

3Session and transaction pivots

Session

session_idlogon_idauthentication_token_id

Transaction

trace_idrequest_idcorrelation_idtransaction_id

Guidance

Verify scope and lifetime. A session ID reused by different tenants or a request ID truncated during ingestion may not be a safe pivot.

4Process and file pivots

Process

process_idprocess_guidparent_process_id

File

filenamefile_pathMD5SHA1SHA256

Certificate

thumbprintcertificate_subject

Guidance

Qualify short-lived identifiers such as PID by host and time. Prefer hashes or durable object identifiers for cross-system correlation.

5Cloud and workload pivots

Cloud resource

Azure resource IDAWS ARNGCP resource nameVM ID

Container

container_idpod_idKubernetes pod

Guidance

Use full resource identifiers where possible and preserve tenant, account, subscription or cluster scope.

6Application-object pivots

Application object

object_idrecord_idgroup_idAPI key IDcertificate subject

Guidance

Count this category when the identifier locates a durable business or application object and can be searched in relevant audit or transaction evidence.

Common mistakes

Counting random GUIDs without knowing what they identify, or counting an event record number that is unique only inside one file.

Assessment method

1. Define the sampleRecord source, time window, event classes, entities, exclusions and valid-event count.

2. Approve pivot mappingsMap source fields to categories and document validation, normalisation and scope rules.

3. Calculate densityClassify each valid event once as containing at least one usable pivot or containing none.

4. Calculate category coverageFor each category, report events containing it divided by total valid events.

5. Apply one breadth modeUse the exploratory 5% rule or the cyber-value calculator’s strict 50% rule; never combine them.

6. Test investigation pathsConfirm pivots actually retrieve related identity, endpoint, network, cloud or application evidence.

Mode	Qualifying category	Use
Exploratory Pivot Analysis	Present in a meaningful proportion of the sample—approximately 5% or more unless the sample is very small.	Describes available investigation routes, including important less-common pivots.
Log Source Cyber Value calculator	Join-key type present in at least 50% of valid event lines.	Provides a deliberately strict, comparable ingestion-decision input.

Interpretation and scoring

Exploratory Pivot Density rating

Density	Rating	Investigation meaning
95–100%	Excellent	Almost every event provides an investigation path.
80–<95%	Good	Most events are pivotable; review uncovered event classes.
60–<80%	Moderate	Useful overall, with material dead ends.
40–<60%	Poor	Many investigations stop at the source event.
0–<40%	Very Poor	Most events lack usable correlation keys.

Exploratory Pivot Breadth rating

Qualifying categories	Rating	Investigation meaning
10+	Excellent	Many independent paths across investigation domains.
8–9	Good	Broad multi-domain correlation.
6–7	Moderate	Several useful routes with notable gaps.
4–5	Limited	Investigations rely on a narrow set of pivots.
0–3	Poor	Very restricted correlation breadth.

Embedded cyber-value calculator bands

Density	Density score × 1.5	Strict breadth	Breadth score × 1.0
0–<30%	0	0 types at 50%+	0
30–<50%	1	1 type at 50%+	1
50–<70%	2	2 types at 50%+	2
70–<90%	3	3 types at 50%+	3
90–<100%	4	4 types at 50%+	4
100%	5	5+ types at 50%+	5

Worked examples

Worked Example 1 — Windows logons: 98% density, 5-category breadth

Measurement	Result	Reason
Valid events	1,000	Representative successful and failed logons.
Events with a pivot	980	User, host, IP, logon ID or process identifier.
Density	980 / 1,000 = 98%	Excellent.
Qualifying categories at 5%+	User, Host, Network, Session, Process	5 categories: Limited breadth.
Strict categories at 50%+	User, Host, Session	3 types: calculator breadth score 3.

High density means almost every event can start an investigation, but limited breadth means most investigations depend on the same identity, host and session paths.

Worked Example 2 — Firewall traffic: 89% density, 3-category breadth

Measurement	Result	Reason
Valid events	10,000	Permit and deny traffic events.
Events with a pivot	8,900	Source/destination IP or session ID.
Density	8,900 / 10,000 = 89%	Good.
Qualifying categories at 5%+	Network, Session, DNS	3 categories: Poor breadth.
Strict categories at 50%+	Network	1 type: calculator breadth score 1.

Events are usually pivotable, but correlation is concentrated in network identifiers and offers few independent routes into identity or endpoint evidence.

Worked Example 3 — Microsoft Entra sign-ins: 98.5% density, 7-category breadth

Measurement	Result	Reason
Valid events	5,000	Interactive and non-interactive sign-ins.
Events with a pivot	4,925	UPN/object ID, IP, session, cloud resource or correlation ID.
Density	4,925 / 5,000 = 98.5%	Excellent.
Qualifying categories at 5%+	User, Network, Session, Cloud Resource, Application Object, Transaction, Host	7 categories: Moderate breadth.
Strict categories at 50%+	User, Network, Cloud Resource, Transaction	4 types: calculator breadth score 4.

The source combines consistently populated identity pivots with several cloud-native and transaction paths.

Worked Example 4 — Mixed security dataset: 92.5% density, 9-category breadth

Measurement	Result
Valid events	20,000
Events with a pivot	18,500
Pivot Density	(18,500 / 20,000) × 100 = 92.5% (Good)
Qualifying categories at 5%+	User, Host, Network, Session, Process, File, URL, Cloud Resource, Transaction
Pivot Breadth	9 categories (Good)

Good density plus Good breadth provides resilient investigations: analysts can start from most events and switch between multiple independent paths when one pivot is absent or inconclusive.

Investigation value and model relationships

High density, low breadthInvestigations can start reliably but depend on a narrow set of identifiers and may fail when those identifiers are shared or missing elsewhere.

Low density, high breadthMany pivot types exist, but only in a minority of events; the average analyst experience remains inconsistent.

High density, high breadthMost events support multiple independent correlation routes across identity, endpoint, network, cloud and application data.

Low density, low breadthEvents frequently become investigation dead ends and require enrichment or source-side logging changes.

Relationship to Log Source Cyber Value: Pivot Density is weighted ×1.5 and Pivot Breadth ×1.0 in the embedded 40-point value model, after the quality gates pass. Neither is a direct component of the separate CVI formula, but both provide supporting evidence for ECCS Correlation, Required Field Coverage and overall investigation readiness.

← Back to References

References / Detailed reference

Semantic Value

Semantic Value measures whether an event clearly conveys the specific action that occurred and the result of that action, using dedicated fields rather than requiring an analyst to infer meaning from free text, an unexplained event code or tribal knowledge. It is a component of the local Log Source Cyber Value model, distinct from novelty, pivotability or population coverage.

Definition

Semantic Value is the combined percentage of a representative sample where an event explicitly states what action was performed and what result that action had, each in a dedicated, reliably populated field rather than something the analyst must reconstruct.

Semantic Value (%) = (Action Completeness % + Outcome Completeness %) / 2Action Completeness and Outcome Completeness are each measured independently across the sample, then averaged for the combined percentage and subscore.

Report the two components, not just the average: a source that is 100% action-complete but 0% outcome-complete is materially different from one that is 50%/50%, even though both average to 50%. Carry Action Completeness and Outcome Completeness alongside the combined percentage in the assessment evidence.

Assessment dimensions

Assess both dimensions on the same representative sample used for the other Log Source Cyber Value components.

1Action completeness

Investigative question

Does the event identify the specific action or operation that was performed?

What to assess

Presence of an explicit action or operation field, whether it names the actual operation rather than a generic category, and whether it is populated consistently across the event population rather than only for a subset of events.

Evidence

actionoperationchange_typecommandevent_type (only when it doubles as the action)

Guidance

Prefer a field naming the actual operation over a broad classification: "account disabled" is action-complete, "AccountManagement" is a category, not an action.

Common mistakes

Treating an unexplained event ID or code as the action when it must be looked up externally to know what happened; counting a category field as if it were the specific action.

2Outcome completeness

Investigative question

Does the event state the result of the action -- success, failure, reason or enforcement decision?

What to assess

Presence of an explicit result, status or decision field; whether failure events carry a reason or error code; whether the outcome is unambiguous without cross-referencing another source.

Evidence

resultstatusoutcomereasondecisionerror_code

Guidance

An outcome inferred only from the absence of a separate failure event is weaker evidence than an explicit success/failure field and should be scored lower than an explicit field.

Common mistakes

Assuming success because no failure event was observed; treating an undocumented numeric status code as an explicit, usable outcome.

Calculation and local scoring matrix

Average Action Completeness and Outcome Completeness to get the combined Semantic Value percentage, then apply the same 0–5 band used by the embedded Log Source Cyber Value calculator. Semantic Value carries a weight of 1.5.

Score	Semantic Value	Meaning	Weighted contribution
0	0–<10%	Action and outcome are essentially unexplained.	0 / 7.5
1	10–<25%	Action or outcome is rarely explicit; heavy reliance on inference.	1.5 / 7.5
2	25–<50%	Action or outcome is explicit for a minority of events.	3 / 7.5
3	50–<75%	Action and outcome are usually explicit but with material gaps.	4.5 / 7.5
4	75–<90%	Action and outcome are explicit for nearly all events.	6 / 7.5
5	90–100%	Action and outcome are explicit and unambiguous for virtually every event.	7.5 / 7.5

Evidence rule: retain the sample, the field-population counts behind each component, and any events where outcome had to be inferred rather than read directly. Do not assign a percentage from stakeholder opinion alone.

Worked examples

Worked Example 1 — Windows Security 4624 (successful logon): 80%

Component	Finding	Completeness
Action	`Logon_Type` and `Account_Name` identify the specific action for every sampled event.	100%
Outcome	Success is implied by the event code (4624 only fires on success); there is no explicit reason or sub-status field carried on this event class.	60%

Action Completeness = 100% | Outcome Completeness = 60% | Semantic Value = (100 + 60) / 2 = 80% | Score = 4 | Weighted contribution = 6 / 7.5

The action is unambiguous, but the outcome relies on knowing that this event code only fires on success rather than the event stating it directly.

Worked Example 2 — Unstructured application syslog message: 27.5%

Component	Finding	Completeness
Action	Free-text message occasionally names an operation, but there is no dedicated action field and wording varies by code path.	40%
Outcome	Result must be inferred from wording ("failed", "error", "unable to"); no structured status or result field exists.	15%

Action Completeness = 40% | Outcome Completeness = 15% | Semantic Value = (40 + 15) / 2 = 27.5% | Score = 2 | Weighted contribution = 3 / 7.5

Both components require analyst inference from free text; enrichment or a structured parser would materially improve this score.

Worked Example 3 — Firewall permit/deny event: 100%

Component	Finding	Completeness
Action	`action=permit\|deny` plus rule ID, protocol and ports identify the operation precisely for every event.	100%
Outcome	The permit/deny decision is itself the outcome -- action and result are the same explicit field.	100%

Action Completeness = 100% | Outcome Completeness = 100% | Semantic Value = 100% | Score = 5 | Weighted contribution = 7.5 / 7.5

Structured control-plane events where the decision field doubles as the outcome typically score highest on this dimension.

Interpretation and decision use

Semantic Value	Rating	Decision implication
90–100%	Excellent	Events are self-explanatory; minimal analyst inference required.
75–<90%	Strong	Minor gaps in outcome or action explanation; still highly usable as-is.
50–<75%	Moderate	Action or outcome sometimes requires inference; consider targeted enrichment.
25–<50%	Weak	Frequent inference needed; prioritise enrichment, lookups or a structured parser.
10–<25%	Poor	Action or outcome rarely explicit; heavy reliance on tribal knowledge to interpret events.
0–<10%	Negligible	Events do not reliably convey what happened or the result; treat as a data-quality finding, not only a value finding.

Low Semantic Value is often fixable. Unlike novelty or population coverage, a poor score here frequently points to a parsing, field-extraction or vendor-configuration gap (enable verbose logging, add a lookup, extract a status code) rather than an inherent limit of the source.

Relationship to Log Source Cyber Value and CVI

Semantic Value carries a weight of 1.5 in the local Log Source Cyber Value model. Its 0–5 score is multiplied by 1.5, contributing up to 7.5 of the total 40 points. The other components are Marginal Novelty (×2.0), Pivot Density (×1.5), Pivot Breadth (×1.0), Entity Coverage (×1.0) and Detection Value (×1.0). Semantic Value is not a direct component of the separate Cyber Value Index formula, which combines ETC, RFC, ECCS and DQS.

Not the same as Marginal Novelty's "semantic and outcome novelty" lens. That lens asks whether a candidate source explains meaning the organisation cannot already get elsewhere -- a novelty (comparison) question. Semantic Value asks whether this source's own events are self-explanatory at all, independent of whether any other source could also provide that meaning.

← Back to References

References / Detailed reference

Response Readiness Index (RRI)

RRI measures whether analysts and responders could actually act on a log source if it mattered right now -- not whether detections exist, but whether a runbook, a named owner, usable retained evidence, a current escalation path and a defined response action are all in place for it. RRI is one of the four component indices that roll up into the Cyber Monitoring Effectiveness Index (CMEI).

Definition

Response Readiness Index is the weighted percentage of five readiness dimensions -- Runbook Readiness, Ownership Readiness, Evidence Availability, Escalation Readiness and Response & Recovery Capability -- that are approved, current and specifically linked to the source or platform being assessed, not merely present somewhere in the organisation.

RRI (%) = weighted achieved points ÷ weighted possible points × 100Five dimensions, scored 0–4 each, equal weight by default (×1.0), for a possible 20 points.

Evidence Availability is a gate, not just a component. If Evidence Availability scores 0 -- retention isn't recorded or the data fails minimum quality gates -- cap the overall rating at Not response-ready regardless of the other four scores. A perfect runbook and escalation matrix are meaningless if the evidence will not exist when someone needs it.

Assessment dimensions

Score each dimension against this source or platform specifically -- a company-wide document that never names it does not count as readiness for it.

1Runbook Readiness

Readiness question

If this source fired a real alert tonight, is there an approved procedure telling a responder what to do with it?

What to assess

Whether an Incident Response Plan, Security Operations Runbook or SOP exists, is current, and is referenced against this specific source, platform or use case rather than written generically.

Evidence

TAX-02.07.01 Incident Response PlanTAX-02.07.02 Security Operations RunbookTAX-02.07.03 SOPTAX-05.04.02/.03 IR Plan / Runbook Reference

Guidance

A runbook reference (TAX-05.04.03) with a current last test date scores higher than a runbook that exists but has never been exercised against this source's failure modes.

Common mistakes

Crediting a generic, organisation-wide IR plan that never names this source or platform; ignoring an overdue review date.

2Ownership Readiness

Readiness question

Is there a specific, contactable person or team who can be pulled into an investigation involving this source?

What to assess

Whether Platform Owner, Technical Owner, Security Owner and Risk Owner (TAX-01.02.01–04) are populated with a name or team and a working contact, not a placeholder or a distribution list nobody monitors.

Evidence

Platform OwnerTechnical OwnerSecurity OwnerRisk Owner

Guidance

Score higher when multiple owner roles are populated and reachable; a single named owner covering all four roles is weaker than dedicated technical and security owners who can each act in their lane.

Common mistakes

Treating "Infrastructure" or "Platform Team" as a contactable owner when no individual or on-call rotation is actually reachable.

3Evidence Availability

Readiness question

When the investigation actually happens, will the evidence still exist and will it be usable?

What to assess

Whether Retention Policy (TAX-02.06.05) is recorded and meets the organisation's minimum investigation lookback, and whether the source clears the same minimum data-quality gates used for Log Source Cyber Value (parse rate, timestamp/timezone reliability, schema stability).

Evidence

Retention periodParse rateTimestamp / timezone reliabilitySchema stability

Guidance

Retained-but-unparseable data is not usable evidence; score this dimension on whether an analyst could actually retrieve and read the event, not just on whether storage exists.

Common mistakes

Assuming a default or platform-wide retention setting applies without confirming it against this specific index or source; crediting retention while ignoring parse or timestamp reliability.

4Escalation Readiness

Readiness question

Does a responder know exactly who to escalate to, at what severity, without guessing?

What to assess

Whether an Escalation Matrix (TAX-02.07.04) and Contact Register (TAX-02.07.05) exist, are current, and are referenced against this source's severity class via TAX-05.04.04.

Evidence

Escalation MatrixContact RegisterEscalation Matrix Reference

Guidance

An escalation matrix with an approved status and a recent review date scores higher than one that is approved but stale, since contacts and roles turn over.

Common mistakes

Treating an escalation matrix's mere existence as sufficient without checking its review date or whether it actually covers this source's severity levels.

5Response & Recovery Capability

Readiness question

Once escalated, is there a defined action to take, and can the organisation recover if the response requires it?

What to assess

Whether a Response Action (TAX-05.04.01), Shared Responsibility Matrix Reference (TAX-05.04.05) and, where relevant, Business Continuity Plan, Disaster Recovery Plan or Recovery Procedure (TAX-02.07.06–08) exist and are current; and whether Investigation Breadth Score (TAX-06.05.16) shows the source actually supports the investigation routes a responder would need.

Evidence

Response ActionShared Responsibility Matrix ReferenceBusiness Continuity PlanDisaster Recovery PlanInvestigation Breadth Score

Guidance

Score highest when the response action has been tested (a validation status or last test date is recorded), not merely documented.

Common mistakes

Counting a SOAR playbook that exists for a different use case as coverage for this one; ignoring recovery readiness because an incident "probably won't require it."

Calculation and local scoring matrix

Score each of the five dimensions from 0 to 4, sum the achieved points out of a possible 20, then convert to a percentage. Apply the Evidence Availability gate before reading the band.

Rating	Meaning
0 — Absent	Nothing exists for this source or platform specifically.
1 — Generic / unlinked	Something exists at an organisation-wide level but does not name this source, or its review date is overdue.
2 — Current, not tested	Exists, is current and is linked to this source, but has never been exercised.
3 — Current and linked	Exists, is current, is specifically linked, and is in a state a responder could use today.
4 — Tested and proven	All of the above, plus a recorded test, drill or real incident demonstrating it works.

Evidence rule: retain the specific document, reference ID, review date and test date behind every non-zero score. A rating without a citable reference should not be scored above 1.

Worked examples

Worked Example 1 — WEC Server / Windows Security Events: 15%, gated to Not response-ready

Dimension	Finding	Rating
Runbook Readiness	An organisation-wide IR plan exists, but no runbook names Windows Security Events or the WEC collection path specifically.	1
Ownership Readiness	Windows Eng is recorded as platform owner and is contactable; no dedicated security or risk owner is recorded.	2
Evidence Availability	Retention (RET-001) is currently Not Recorded for index=wineventlog.	0
Escalation Readiness	No escalation matrix reference is tied to this source.	0
Response & Recovery Capability	No Response Action record exists for detections against this source.	0

Raw = (1+2+0+0+0) / 20 = 15% | Evidence Availability = 0 → gate triggered | Rating = Not response-ready (gated, independent of the raw percentage)

The raw percentage already lands in the lowest band, but the gate matters here as a principle: even a source with strong runbooks and escalation would still be capped Not response-ready if its evidence will not exist when needed.

Worked Example 2 — Okta / SaaS Authentication Logs (VIA-001): 85%, Substantially ready

Dimension	Finding	Rating
Runbook Readiness	A current SaaS-authentication runbook names this source and was last tested this quarter.	4
Ownership Readiness	IAM is recorded as owner with a working on-call contact.	3
Evidence Availability	Retention is confirmed and meets the investigation lookback requirement; parse rate and timestamp reliability both pass gate.	4
Escalation Readiness	A current, approved escalation matrix covers identity-related severity classes.	3
Response & Recovery Capability	A response action is defined and was exercised in a recent tabletop.	3

Raw = (4+3+4+3+3) / 20 = 85% | Evidence Availability = 4 → gate not triggered | Rating = Substantially ready

No dimension is perfect, but every dimension is at least current and linked -- the profile of a source that could genuinely support an investigation today.

Worked Example 3 — Custom API Health Telemetry (VIA-002): 15%, Not response-ready

Dimension	Finding	Rating
Runbook Readiness	No runbook or procedure exists for this custom source.	0
Ownership Readiness	Integration team is recorded as owner, but only as a generic team mailbox.	2
Evidence Availability	Some retention is noted, but the source's own technical readiness score (38/100 on its viability assessment) reflects a weak, largely unvalidated schema.	1
Escalation Readiness	No escalation matrix reference exists for this source.	0
Response & Recovery Capability	No response action or recovery procedure exists.	0

Raw = (0+2+1+0+0) / 20 = 15% | Evidence Availability = 1 → gate not triggered on a technicality | Rating = Not response-ready (on the raw percentage alone)

This shows the gate is not the only path to a low rating -- a source can be broadly unprepared without any single dimension hitting zero.

Interpretation and decision use

RRI	Rating	Decision implication
90–100%	Ready	Analysts and responders can act on this source today; maintain currency through the normal review cadence.
75–<90%	Substantially ready	Usable now; close the remaining gaps at the next review rather than treating it as urgent.
50–<75%	Partially ready	A real incident would surface friction; prioritise the weakest dimension before relying on this source under pressure.
25–<50%	Weak	Significant gaps across multiple dimensions; do not assume this source can carry an investigation on its own.
0–<25%	Not response-ready	Treat detections from this source as informational only until readiness is established, or escalate remediation.

RRI is about preparedness, not detection quality. A source can have excellent Cyber Value and Threat Detection Index scores and still score poorly here if nobody has written down what to do when it fires. Read RRI alongside CVI and TDI, not as a substitute for either.

Relationship to the Cyber Monitoring Effectiveness Index (CMEI)

RRI is one of four component indices that roll up into CMEI (TAX-07.20), alongside the Cyber Value Index (data quality and usefulness), the Threat Detection Index (how effectively detections use the data) and the Operational Assurance Index (pipeline health and reliability). Where CVI asks "is the data valuable and investigation-ready" and TDI asks "are threats detected effectively," RRI asks the next question in the chain: "can analysts and responders actually act on it."

RRI is not a component of the Log Source Cyber Value model. That 40-point model (Marginal Novelty, Pivot Density/Breadth, Semantic Value, Entity Coverage, Detection Value) scores a candidate source's intrinsic value before onboarding; RRI scores operational preparedness for a source that is already onboarded and governed.

← Back to References

References / Detailed reference

Operational Assurance Index (OAI)

OAI measures whether the logging pipeline behind a source can be trusted to keep working -- not whether the data is valuable or whether anyone is ready to respond to it, but whether it stays up, arrives on time, is actually monitored, can be safely changed, and is being kept current. OAI is one of the four component indices that roll up into the Cyber Monitoring Effectiveness Index (CMEI).

Definition

Operational Assurance Index is the weighted percentage of five reliability dimensions -- Availability, Timeliness, Health Checks, Supportability and Maintenance -- that are actively confirmed for the collection path or platform, not merely assumed because nothing has broken recently.

OAI (%) = weighted achieved points ÷ weighted possible points × 100Five dimensions, scored 0–4 each, equal weight by default (×1.0), for a possible 20 points.

Health Checks is a gate, not just a component. If Health Checks scores 0 -- no health tests are defined, scheduled or run for this path -- cap the overall rating at Unverified regardless of the other four scores. Availability, Timeliness, Supportability and Maintenance claims cannot be trusted if nothing is actually monitoring them; an unmonitored pipeline that "seems fine" is not the same as an assured one.

Assessment dimensions

Score each dimension against this specific collection path or platform, using the reusable health-test catalogue (TAX-04.10.01) and the Assurance & Health roll-ups (TAX-06.03) as primary evidence.

1Availability

Readiness question

Is the collection path actually up, and would it stay up if one component failed?

What to assess

Service health, listener and pool/redundancy status for the collection tier, and cluster peer status where the platform is clustered.

Evidence

TC-HFP-001 splunkd Service HealthTC-HFP-003 Receiving Listener AvailabilityTC-HFP-013 Pool Membership and RedundancyTAX-06.03.04 Indexer / Search Head Cluster Health

Guidance

Redundant nodes existing is not the same as redundancy being proven; score highest only when failover has actually been exercised or observed during a real outage.

Common mistakes

Crediting availability because a second node exists on paper, without confirming it actually takes over traffic when the first one fails.

2Timeliness

Readiness question

Is data arriving within an acceptable and known latency, without silent backlog building up?

What to assess

Queue health, backpressure, throughput against expected volume, and source-to-destination reconciliation for event loss.

Evidence

TC-HFP-006 Persistent Queue HealthTC-HFP-007 Internal Queue and Backpressure HealthTC-HFP-014 Throughput and Load DistributionTC-HFP-015 Source-to-Destination Reconciliation and LossTC-AWS-002 Event Freshness

Guidance

A one-off informal check ("no blocked-queue incidents recorded") is weaker evidence than a scheduled, alerting test that would actually catch a future backlog before an analyst notices a gap.

Common mistakes

Treating "no complaints so far" as evidence of timeliness when no test actually measures latency or loss.

3Health Checks

Readiness question

Are the defined health tests for this source actually scheduled, running and passing -- not just theoretically available in the catalogue?

What to assess

Whether applicable tests from the reusable health-test catalogue are configured for this specific source, their current pass/fail state, and whether a failure would page someone.

Evidence

TAX-04.10.01 Health Test DefinitionsTAX-06.03.01 Platform Health Roll-upSource-level pass/fail record

Guidance

A source with 2 of 2 defined checks passing is verifiably healthy on those two dimensions -- but confirm those two checks actually cover availability, timeliness and the other dimensions before treating the pass rate as comprehensive.

Common mistakes

Counting the catalogue's existence as proof that checks are running against this source; assuming a passing result is current rather than checking when it was last run.

4Supportability

Readiness question

Can this collection path be changed, patched or fixed safely without an engineer's tribal knowledge?

What to assess

Whether the input is deployment-server managed rather than hand-configured, whether a configuration baseline and change history exist, and whether its dependencies are mapped.

Evidence

TAX-01.05.01 Deployment Server registrationTAX-02.06.04 Configuration BaselineTAX-06.02.01 Dependency MappingTAX-06.03.05 Configuration Change RecordTC-HFP-009 Deployment App and Add-on ComplianceTC-HFP-010 Configuration Drift

Guidance

Manual, GPO-driven or hand-edited configuration with no change history scores at the bottom of this dimension regardless of how well the source currently performs -- supportability is about what happens at the next change, not the current state.

Common mistakes

Crediting supportability because a platform team owns the source, without checking whether its configuration is actually centrally managed or version-controlled.

5Maintenance

Readiness question

Is this collection path being actively kept current, or is it running unattended until something breaks?

What to assess

Certificate and credential expiry tracking, app/add-on and platform version currency, licence and capacity headroom, and whether a review cadence exists.

Evidence

TC-HFP-012 TLS Certificate and Credential LifecycleTAX-01.06 Capacity & LicensingTAX-06.04.02 Review & ExpiryApp / TA version currency

Guidance

A current app version confirmed at the platform level is weaker evidence than a review specifically confirming this source's own hosts, certificates and capacity headroom.

Common mistakes

Assuming maintenance is covered because a platform-wide patching process exists somewhere, without confirming it actually reaches this collection path's specific hosts.

Calculation and local scoring matrix

Score each of the five dimensions from 0 to 4, sum the achieved points out of a possible 20, then convert to a percentage. Apply the Health Checks gate before reading the band.

Rating	Meaning
0 — Absent	Nothing exists or is confirmed for this collection path specifically.
1 — Generic / unconfirmed	A platform-wide mechanism may exist but is not confirmed against this specific path, or its evidence is stale.
2 — Current, not exercised	Confirmed and current for this path, but never actually tested under failure or load.
3 — Confirmed and scheduled	Confirmed, current, and running on a schedule a responder could rely on today.
4 — Tested and alerting	All of the above, plus a recorded test or real event proving it works, and a failure would actively page someone.

Evidence rule: retain the specific test ID, roll-up record, last-run date and pass/fail result behind every non-zero score. A rating without a citable, dated result should not be scored above 1.

Worked examples

Worked Example 1 — WEC Server / Windows Security Events: 40%, Weak

Dimension	Finding	Rating
Availability	Two WEC nodes provide collector redundancy, but failover behaviour under a single-node outage is undocumented and untested.	2
Timeliness	No blocked-queue incidents recorded and no measurable indexer load, confirmed once during the last validation window -- not via a scheduled test.	2
Health Checks	2 of 2 defined source-level health checks are currently passing.	3
Supportability	Configuration is manual, GPO-driven and not deployment-server managed; the Configuration Change Record for this path shows no tracked history.	0
Maintenance	The platform-wide Splunk_TA_windows version is current, but no certificate, credential or capacity review specific to the WEC hosts is recorded.	1

Raw = (2+2+3+0+1) / 20 = 40% | Health Checks = 3 → gate not triggered | Rating = Weak

The source is verifiably healthy on the two checks that exist, but that pass rate is carrying more weight than it should -- supportability and maintenance are effectively unmanaged.

Worked Example 2 — Okta / SaaS Authentication Logs (VIA-001): 85%, Substantially assured

Dimension	Finding	Rating
Availability	Vendor SLA-backed availability with published uptime reporting reviewed each period.	4
Timeliness	Event freshness is checked on a schedule, though the path has not been stress-tested under peak load.	3
Health Checks	All defined checks pass, and a failure pages the on-call rotation directly.	4
Supportability	Managed through the approved vendor API integration with a documented configuration baseline.	3
Maintenance	Vendor manages patching and certificate rotation; licence headroom is tracked quarterly.	3

Raw = (4+3+4+3+3) / 20 = 85% | Health Checks = 4 → gate not triggered | Rating = Substantially assured

No dimension is perfect, but every dimension is confirmed, current and scheduled -- the profile of a pipeline an engineer would trust without checking it manually first.

Worked Example 3 — Custom API Health Telemetry (VIA-002): 10%, gated to Unverified

Dimension	Finding	Rating
Availability	Custom on-premises polling script with no redundancy and no monitoring.	0
Timeliness	Volume and delivery reliability are recorded as unknown on the source's own viability assessment.	1
Health Checks	No health test is defined; the source is still flagged for discovery.	0
Supportability	Owned generically by the Integration team; the custom script and parser are explicitly noted as a high-risk, fragile dependency.	1
Maintenance	Nothing recorded.	0

Raw = (0+1+0+1+0) / 20 = 10% | Health Checks = 0 → gate triggered | Rating = Unverified (gated, independent of the raw percentage)

The raw percentage already sits in the lowest band, but the gate is the more important signal: without any health check, none of the other four ratings can actually be trusted, only asserted.

Interpretation and decision use

OAI	Rating	Decision implication
90–100%	Assured	The pipeline can be trusted to keep working; maintain currency through the normal review cadence.
75–<90%	Substantially assured	Reliable now; close the remaining gaps at the next review rather than treating them as urgent.
50–<75%	Partially assured	Likely to hold up under normal conditions but has not been proven under failure, load or change.
25–<50%	Weak	Real gaps in monitoring, support or maintenance; do not assume this pipeline will keep working unattended.
0–<25%	Not assured / Unverified	Treat continuity of this source as at risk; prioritise health-check coverage before anything else.

OAI is about pipeline reliability, not data value or response preparedness. A source can carry excellent Cyber Value and Response Readiness scores and still score poorly here if its collection path is fragile, unmonitored or hand-maintained. Read OAI alongside CVI and RRI, not as a substitute for either.

Relationship to the Cyber Monitoring Effectiveness Index (CMEI)

OAI is one of four component indices that roll up into CMEI (TAX-07.20), alongside the Cyber Value Index (data quality and usefulness), the Threat Detection Index (how effectively detections use the data) and the Response Readiness Index (whether responders can act on it). Where CVI, TDI and RRI all assume the pipeline keeps working, OAI is the one that actually checks that assumption: "is the monitoring pipeline itself reliable and supportable."

OAI's Health Checks gate is a different gate to RRI's Evidence Availability gate. RRI's gate asks whether evidence will still exist when an investigation needs it; OAI's gate asks whether anything is currently watching the pipeline at all. A source can pass one gate and fail the other -- retained, parseable data flowing through an unmonitored pipeline passes RRI's evidence gate but fails OAI's health-check gate.

← Back to References

References / Detailed reference

Threat Detection Index (TDI)

TDI measures how effectively detections actually use the logging data that was onboarded -- not whether the data could theoretically support detection (that is Technique Coverage inside CVI's ECCS), but whether a built, tested, accurate and timely detection rule exists for it. TDI is one of the four component indices that roll up into the Cyber Monitoring Effectiveness Index (CMEI).

Definition

Threat Detection Index is the weighted percentage of five dimensions -- Technique Coverage, Rule Coverage, Validation, Fidelity and Latency -- confirmed for the detections built against this source, not merely inferred because the data looks like it should support detection.

TDI (%) = weighted achieved points ÷ weighted possible points × 100Five dimensions, scored 0–4 each, equal weight by default (×1.0), for a possible 20 points.

Rule Coverage is a gate, not just a component. If Rule Coverage scores 0 -- no detection analytic or rule has actually been built against this source's mapped use cases -- cap the overall rating at Undetected regardless of the other four scores. Validation, Fidelity and Latency cannot be meaningfully assessed for a detection that does not exist.

Assessment dimensions

Score each dimension against the detections actually built for this source, using the Detection & Response records (TAX-05) and the source's 90-day value review (TAX-06.05.14) as primary evidence.

1Technique Coverage

Detection question

Does this source's data actually support the MITRE ATT&CK tactics and techniques it is supposed to?

What to assess

Assessed coverage status against mapped techniques, named gaps, and how recently coverage was last assessed rather than assumed from a general sourcetype profile.

Evidence

TAX-05.05.02 Detection CoverageTAX-05.01.02 Threat Mapping

Guidance

A high aggregate coverage percentage can still hide one or two tactics rated Partial or absent; report the weakest tactic alongside the average, not just the average.

Common mistakes

Treating a source's presence in the environment as coverage without an actual assessed coverage-status record; ignoring how stale the "last assessed" date is.

2Rule Coverage

Detection question

For each mapped use case, does a real, active detection analytic exist -- not just a documented intention to build one?

What to assess

Whether a Detection Analytic & Rule record exists with working SPL/correlation logic, an Active status and a defined schedule, and whether the Use Case–Data Source Mapping shows the requirement as actually met.

Evidence

TAX-05.03.01 Detection Analytic & RuleTAX-05.02.01 Use Case–Data Source Mapping

Guidance

A use case mapped as a requirement but with no corresponding analytic record is a gap, not partial coverage -- score it at the low end even if the source itself is otherwise well understood.

Common mistakes

Counting a planned or draft rule the same as an active one; crediting rule coverage from a use case that maps to a different source.

3Validation

Detection question

Has the rule actually been proven to fire correctly against expected events, and how recently?

What to assess

Whether a documented test scenario, method and result exist, and whether the last-validated date is within an acceptable cadence given how often the underlying data or logic changes.

Evidence

TAX-05.05.01 Detection Validation

Guidance

A rule that has never been deliberately tested against expected events -- only assumed to work because it has not thrown an error -- should not score above the low end of this dimension.

Common mistakes

Treating "no complaints" as validation; crediting a validation result that predates a since-changed field extraction or CIM mapping.

4Fidelity

Detection question

Of the alerts this source's detections generate, what proportion are confirmed true positives rather than noise?

What to assess

Alert volume, confirmed true-positive count and the resulting confirmed-use or true-positive rate over a defined review period.

Evidence

TAX-06.05.14.04 Alerts GeneratedTAX-06.05.14.05 True PositivesTAX-06.05.14.06 Confirmed Use Rate

Guidance

A detection with no recorded alert volume at all is not automatically low fidelity -- it is unmeasured, and should be scored as such (generic/unconfirmed) rather than assumed noisy or assumed clean.

Common mistakes

Inferring high fidelity from low alert volume without checking whether that reflects genuine precision or simply a rule that rarely fires at all, including on real activity.

5Latency

Detection question

Does the detection fire close enough to when the underlying activity actually happened to be operationally useful?

What to assess

End-to-end latency from event occurrence through ingestion, parsing and search schedule to alert, measured against an objective and breach rate -- not just whether the search is scheduled to run at all.

Evidence

TAX-07.12.03 Event Timeliness AssessmentTAX-04.09.04 Parsing LatencyTAX-05.03.01 Schedule

Guidance

A five-minute scheduled search behind a source with a two-hour collection lag is not a five-minute-latency detection; measure the whole chain, not just the search cadence.

Common mistakes

Reporting the search's cron interval as the detection latency while ignoring upstream collection and parsing delay.

Calculation and local scoring matrix

Score each of the five dimensions from 0 to 4, sum the achieved points out of a possible 20, then convert to a percentage. Apply the Rule Coverage gate before reading the band.

Rating	Meaning
0 — Absent	Nothing exists or is confirmed for this source's detections specifically.
1 — Generic / unconfirmed	Something is claimed or assumed but has no citable, dated evidence for this source.
2 — Current, not proven	Confirmed and current, but never actually tested or measured against real activity.
3 — Confirmed and measured	Confirmed, current, and backed by an actual measured or tested result.
4 — Proven and strong	All of the above, and the measured result itself is strong -- comprehensive coverage, high fidelity, or latency well within objective.

Evidence rule: retain the specific coverage assessment, rule ID, validation result, alert/true-positive counts and latency measurement behind every non-zero score. A rating without a citable, dated result should not be scored above 1.

Worked examples

Worked Example 1 — WEC Server / Windows Security Events: 40%, Weak

Dimension	Finding	Rating
Technique Coverage	Assessed ATT&CK coverage is 95.5% overall, but the Collection tactic is explicitly rated Partial.	3
Rule Coverage	The high assessed coverage implies active analytics exist, but no specific rule inventory is cited for this source.	3
Validation	No documented test scenario or last-validated date is recorded against this source's rules specifically.	1
Fidelity	No alert volume or true-positive data has been recorded for this source; governance status is itself Not Assessed.	0
Latency	No event timeliness assessment or measured search-to-alert latency is recorded for this source.	1

Raw = (3+3+1+0+1) / 20 = 40% | Rule Coverage = 3 → gate not triggered | Rating = Weak

A strong headline coverage percentage is carrying the score -- nothing confirms the rules built on top of that coverage are validated, precise or timely, which is exactly the blind spot TDI exists to surface.

Worked Example 2 — Okta / SaaS Authentication Logs (VIA-001): 85%, Substantially covered

Dimension	Finding	Rating
Technique Coverage	Identity-related tactics are comprehensively mapped and recently reassessed.	4
Rule Coverage	Every mapped use case has an active, scheduled correlation search.	4
Validation	Rules are validated against documented test scenarios on a quarterly cadence.	3
Fidelity	True-positive rate is tracked and confirmed regularly, though not perfect.	3
Latency	Ingestion latency and search cadence are both measured and within the stated objective.	3

Raw = (4+4+3+3+3) / 20 = 85% | Rule Coverage = 4 → gate not triggered | Rating = Substantially covered

Every dimension is confirmed and measured, not merely assumed -- the profile of detections a team would trust in a real incident.

Worked Example 3 — Custom API Health Telemetry (VIA-002): 0%, gated to Undetected

Dimension	Finding	Rating
Technique Coverage	The source is still flagged for discovery; no technique mapping exists.	0
Rule Coverage	No detection analytic has been built against this source.	0
Validation	Not applicable -- no rule exists to validate.	0
Fidelity	Not applicable -- no alerts have ever been generated.	0
Latency	Not applicable -- nothing to measure.	0

Raw = 0 / 20 = 0% | Rule Coverage = 0 → gate triggered | Rating = Undetected (gated)

This is the clearest illustration of the gate's purpose: with no rule built, the other four dimensions are not merely low, they are inapplicable.

Interpretation and decision use

TDI	Rating	Decision implication
90–100%	Strong detection	Detections are comprehensive, validated, accurate and timely; maintain currency through the normal review cadence.
75–<90%	Substantially covered	Detections are working and trustworthy; close remaining gaps at the next review.
50–<75%	Partially covered	Detections exist but at least one of validation, fidelity or latency is unconfirmed; do not treat this source as fully covered.
25–<50%	Weak	Coverage claims are not backed by validation, fidelity or latency evidence; prioritise proving the detections actually work.
0–<25%	Undetected / Minimal	Little to no working detection capability exists against this source regardless of how valuable the data itself is.

TDI is about whether detections work, not whether data is valuable or the team is ready to respond. A source can carry an excellent Cyber Value Index and still score poorly here if nobody has built, tested or measured a detection against it. Read TDI alongside CVI and RRI, not as a substitute for either.

Relationship to the Cyber Monitoring Effectiveness Index (CMEI)

TDI is one of four component indices that roll up into CMEI (TAX-07.20), alongside the Cyber Value Index (data quality and usefulness), the Response Readiness Index (whether responders can act on it) and the Operational Assurance Index (pipeline health and reliability). Where CVI asks "is the data valuable and investigation-ready," TDI asks the next question: "are threats actually detected effectively using that data."

TDI's Technique Coverage dimension is related to, but distinct from, ECCS's correlation dimension and the Log Source Cyber Value model's Detection Value component. Cyber Value's Detection Value scores a candidate source's intrinsic potential for detection use before onboarding; TDI scores whether detections against an already-onboarded, governed source are actually built, validated, accurate and timely.

← Back to References

References / Detailed reference

Implementation Complexity

Implementation Complexity is a computed measure of a logging pattern's one-time build effort: its architecture hop count plus its required network flows, with a fixed penalty added when the pattern requires writing and deploying custom code. It is computed directly from metrics that already exist on the pattern, not authored separately, so it can never drift from the architecture it describes.

Definition

Distinct from Configuration Footprint, which measures the ongoing operational burden of keeping a live pattern's configuration current. Implementation Complexity measures the one-time effort to build the pattern in the first place: how many discrete architecture hops the data crosses, how many distinct network flows must be opened and secured, and whether any of it requires writing and deploying custom code rather than configuring an existing component.

Why not just count checklist items? A raw count of a pattern's implementation-checklist items was tried first and rejected: it tracks how much optional descriptive data a pattern happens to have authored, not how much work it actually takes to implement. LP-016 (Direct HEC to Splunk Cloud) is one of the simplest architectures in the catalogue -- 3 hops, 1 network flow -- yet it has the second-highest checklist item count in the whole catalogue, purely because more of its optional fields happen to be filled in. Implementation Complexity is computed from the architecture itself instead, so it can't be inflated or understated by how thoroughly a pattern's other fields were authored.

How it's scored

Implementation Complexity Score = Architecture hop count + Network flow count + Custom code penalty

Input	What it counts
Architecture hop count	The number of discrete stages in the pattern's own architecture-flow diagram (source, each intermediary, destination).
Network flow count	The number of distinct required network flows for the pattern in the Flow Schema table -- each port/protocol path that must be opened and secured.
Custom code penalty	+3 if the pattern requires writing and deploying custom code (a runtime and implementation language are set), otherwise 0 -- writing and maintaining code is qualitatively different work from configuring an existing component, not just "one more hop."

Bands

Set from the real distribution across all 39 active pattern variants (range 4-11): a low cluster at 4, the bulk of patterns at 5-6, an elevated group at 7-8, and the custom-code/multi-hop patterns at 10-11 -- with a natural gap at 9 separating the top two bands.

Score	Tier	Active pattern variants at this tier
≤ 4	Low	7
5 - 6	Moderate	20
7 - 8	High	4
≥ 9	Very high	8

Pattern distribution

All 18 base patterns, highest complexity first. Destination-specific (-OP/-SC) and runtime (LP-017's Azure Function/AWS Lambda/on-premises script) variants of the same base pattern share the same hop and flow counts and so score identically.

Base pattern	Architecture hops	Network flows	Custom code	Score	Tier
LP-018 · Syslog server with forwarder collection	7	4	No	11	Very high
LP-017 · REST API polling (Azure Function / AWS Lambda / on-premises script)	5	2	Yes	10	Very high
LP-015 · No add-on: HEC collector via Heavy Forwarder	5	3	No	8	High
LP-007 · AWS S3 and SQS	3	4	No	7	High
LP-003 · Syslog via Heavy Forwarder	3	3	No	6	Moderate
LP-005 · REST API or modular input	3	3	No	6	Moderate
LP-006 · Azure Event Hub	3	3	No	6	Moderate
LP-008 · DB Connect	3	3	No	6	Moderate
LP-012 · On-premises app/add-on forwarding to Splunk Cloud	3	3	No	6	Moderate
LP-001 · Universal Forwarder file monitoring	3	2	No	5	Moderate
LP-002 · Syslog via SC4S	3	2	No	5	Moderate
LP-009 · Federated Search to S3	3	2	No	5	Moderate
LP-013 · Splunk Stream network traffic collection	3	2	No	5	Moderate
LP-014 · Heavy Forwarder intermediary	3	2	No	5	Moderate
LP-004 · HTTP Event Collector	3	1	No	4	Low
LP-010 · Edge or Ingest Processor routing	3	1	No	4	Low
LP-011 · Splunk Cloud supported app/add-on	3	1	No	4	Low
LP-016 · Direct HEC to Splunk Cloud	3	1	No	4	Low

Validation

Use the hop/flow/custom-code breakdown, not just the tier label, when comparing two patterns of the same tier -- LP-007 (7: 3 hops, 4 flows) and LP-015 (8: 5 hops, 3 flows) both land in the High band for different structural reasons.
The +3 custom-code penalty is fixed regardless of how much code is involved -- it marks a qualitative shift in the kind of work required (writing and deploying software, not just configuring a component), not a graduated estimate of coding effort.
Where two candidate patterns tie on Implementation Complexity, Configuration Footprint is often the more useful tiebreaker for long-term operational cost, since it captures ongoing burden rather than one-time build effort.
Naming collision to watch for: this is a different metric from the Viability Calculator's own "Engineering complexity" (a 1-4 rating derived from ingestion-architecture, parsing/normalisation and maintenance-debt answers, with its own separate "equivalent implementation rating"). Both describe complexity, but from different inputs and for different purposes -- this one scores an approved reference pattern's own architecture; that one scores a specific onboarding engagement's engineering effort.

← Back to References

References / Detailed reference

Configuration Footprint

Configuration Footprint is a computed, prospective measure of a logging pattern's ongoing operational burden: where its configuration actually lives, whether the Deployment Server can manage it, how many hosts, devices or cloud resources need their own configuration, and whether real work happens outside Splunk's configuration model entirely. It is scored per base pattern from four raw, authored facts rather than a single subjective rating, so the score can never drift from its own inputs.

Definition

Distinct from Implementation Complexity, which measures the one-time effort to build a pattern (architecture hops, network flows, custom code). Configuration Footprint measures the ongoing operational burden of keeping that pattern's configuration current once it is live -- across every host, device or cloud resource it touches, and however many of those configuration layers sit inside Splunk's own Deployment Server model versus entirely outside it.

Four raw facts are authored per base pattern -- Configuration Location, Deployment Server Manageable, Fleet Scope and External Configuration Required -- since none of them can be derived from any other field already on the pattern. The score, tier and breakdown text shown on the Logging Pattern Advisor are all computed from those four values, not authored separately, so the metric can't drift from its own inputs.

How it's scored

Configuration Footprint Score = Deployment Server points + Fleet Scope points + External Configuration points

Configuration Location is shown alongside every score as the fourth input -- it explains where the configuration actually lives, but doesn't itself contribute points, since "external" already gets captured by the External Configuration Required factor.

Deployment Server manageable	Points
Yes	0
No	2

Fleet scope	Points
Single instance	0
Small cluster	1
Fleet-wide	2
Per-device	3

External configuration required	Points
No	0
Yes	2

Bands

Set from the real distribution across all 18 base patterns (range 1-7): a low outlier at 1, the bulk of patterns at 2-3, an elevated group at 4-5, and the one pattern combining every risk factor (syslog via SC4S: not DS-manageable, per-device fleet scope, and external configuration required) at the top.

Score	Tier	Base patterns at this tier
1	Low	1
2 - 3	Moderate	10
4 - 5	High	5
6 - 7	Very high	1
n/a	Varies	1 (LP-011 -- properties depend on the specific app, not the architecture)

Pattern distribution

All 18 base patterns, highest footprint first. "Varies" patterns and destination-specific variants (-OP/-SC) of the same base pattern share the same four inputs and score.

Base pattern	Configuration location	DS manageable	Fleet scope	External config required	Score	Tier
LP-002 · Syslog via SC4S	External -- SC4S's own YAML config, plus each sending device's own vendor CLI/UI	No	Per-device	Yes	7	Very high
LP-003 · Syslog via Heavy Forwarder	Splunk conf files for the Heavy Forwarder listener; external for each sending device	Yes	Per-device	Yes	5	High
LP-018 · Syslog server with forwarder collection	Splunk conf files for the forwarder leg; external for the syslog server's own config and each sending device	Yes	Per-device	Yes	5	High
LP-006 · Azure Event Hub	Splunk conf files for the collector add-on; external Azure portal/ARM for diagnostic settings	Yes	Fleet-wide	Yes	4	High
LP-008 · DB Connect	DB Connect's own UI/REST API (not standard Splunk conf files)	No	Single instance	Yes	4	High
LP-017 · REST API polling via Azure Function	Cloud infrastructure-as-code/CI-CD for the function itself; a Splunk HEC token for delivery	No	Single instance	Yes	4	High
LP-013 · Splunk Stream network traffic collection	Splunk Stream's own configuration interface	No	Small cluster	No	3	Moderate
LP-001 · Universal Forwarder file monitoring	Splunk conf files (Deployment Server-pushable)	Yes	Fleet-wide	No	2	Moderate
LP-004 · HTTP Event Collector	Splunk conf files for the HEC token/input; external for the sending application's own client	Yes	Single instance	Yes	2	Moderate
LP-005 · REST API or modular input	Splunk conf files for the modular input; external for the vendor portal credentials	Yes	Single instance	Yes	2	Moderate
LP-007 · AWS S3 and SQS	Splunk conf files for the collector add-on; external AWS console/IaC for bucket and queue permissions	Yes	Single instance	Yes	2	Moderate
LP-009 · Federated Search to S3	Splunk's own admin interface/knowledge objects	Yes	Single instance	Yes	2	Moderate
LP-010 · Edge or Ingest Processor routing	The processor's own dedicated routing/transform interface	No	Single instance	No	2	Moderate
LP-012 · On-premises app/add-on forwarding to Splunk Cloud	Splunk conf files for the add-on; external vendor-side setup varies by app	Yes	Single instance	Yes	2	Moderate
LP-015 · No add-on: HEC collector via Heavy Forwarder	Splunk conf files for the HEC token/input; external for the sending application's own client	Yes	Single instance	Yes	2	Moderate
LP-016 · Direct HEC to Splunk Cloud	Splunk conf files (or Splunk Web/ACS) for the HEC token; external for the sending application's own client	Yes	Single instance	Yes	2	Moderate
LP-014 · Heavy Forwarder intermediary	Splunk conf files (Deployment Server-pushable)	Yes	Small cluster	No	1	Low
LP-011 · Splunk Cloud supported app/add-on	Varies	Varies	Varies	Varies	n/a	Varies

Relationship to OAI Supportability

Configuration Footprint predicts OAI's Supportability dimension without duplicating it -- Configuration Footprint is a prospective, architecture-level signal computed before a source goes live; OAI Supportability is an evidence-based score (dated test IDs, roll-up records) computed after onboarding, against a real deployed source. The relationship is one of prediction, not equivalence.

Tier	What it predicts for OAI Supportability
Low	Supports a strong OAI Supportability score once onboarded.
Moderate	Compatible with a solid OAI Supportability score, provided the Splunk-side configuration is actually pushed through the Deployment Server rather than hand-edited.
High	Typically caps OAI Supportability at a middling score, since at least one layer of configuration sits outside Splunk's Deployment Server model.
Very high	Commonly predicts a low OAI Supportability score at onboarding unless the external configuration surfaces are formally tracked and version-controlled.
Varies	Depends entirely on the specific app -- verify per app.

Validation

Treat a Very high footprint as a signal to formally track and version-control every external configuration surface before or at onboarding -- not as a reason to reject the pattern outright.
LP-011 ("Varies") has no fixed footprint: its properties are inherited entirely from whichever app or add-on implements it, so verify the specific app's own configuration model directly rather than reading a generic score.
Configuration Footprint is a prospective, architecture-level signal computed before a source goes live -- it predicts OAI Supportability, it does not replace OAI's own evidence-based score once the source is onboarded and evidence exists.
Where two candidate patterns tie on Implementation Complexity, Configuration Footprint is often the more useful tiebreaker for long-term operational cost, since it captures ongoing burden rather than one-time build effort.

← Back to References

References / Detailed reference

Ingestion Latency

Ingestion Latency is the end-to-end time from an event occurring at its source to that event becoming searchable or actionable in Splunk -- covering collection, transport, processing and indexing delay together, not any single stage in isolation. It is classified into six tiers by p95 end-to-end latency, each tied to which security use cases the resulting delay can still support.

Definition

Measured as the p95 (95th-percentile) end-to-end latency for a source -- from event occurrence to the event being searchable or actionable -- rather than a mean or best-case figure, so that a source's classification reflects its typical worst-case delay, not just its fastest deliveries. The six tiers below range from sub-second Immediate delivery through Critical, High and Standard near-real-time bands to Delayed and Batch/Historical, each paired with the security use cases the tier's delay still supports.

Latency tiers

Tier	P95 end-to-end latency	Real-time classification	Definition	Typical security use cases
Immediate	<1 second	Sub-second / effectively real-time	Events become searchable or actionable within one second.	Inline prevention, fraud controls, safety systems and specialised streaming analytics.
Critical	1 second to <1 minute	Near real-time	Events arrive with minimal collection, transport, processing and indexing delay.	Automated containment, high-priority detections and time-critical alerting.
High	1 minute to <5 minutes	Near real-time	Events arrive quickly enough to support rapid SOC detection and response.	Priority detections, SOC alerting, active incident response and operational monitoring.
Standard	5 minutes to <15 minutes	Operational real-time	Events support active security monitoring but not immediate intervention.	General SOC monitoring, incident triage, investigations and security dashboards.
Delayed	15 minutes to <4 hours	Delayed	Events arrive after material buffering, polling, throttling, backlog or processing delay.	Lower-priority monitoring, reporting, reconciliation and trend analysis.
Batch/Historical	≥4 hours	Batch / non-real-time	Events are delivered through scheduled batches, bulk exports or backfills, or arrive too late for active monitoring.	Compliance, audit, retrospective investigation, analytics and data warehousing.

← Back to References

References / Detailed reference

Mean Time to Detect (MTTD)

Mean Time to Detect is the average time it takes to identify that a security incident, anomaly, failure or other adverse event has occurred -- the elapsed time from when an event begins (or becomes detectable) until it is first recognized by people, process or technology.

Definition & formula

MTTD measures the elapsed time from the moment an event begins (or becomes detectable) until it is first recognized -- by an analyst, an automated detection, or another monitoring process.

MTTD = Σ (Detection time − Event start time) ÷ Number of incidents

MTTD can also be decomposed into two additive components, together commonly called end-to-end latency or event-to-alert latency:

MTTD = Ingestion Latency + Detection LatencyIngestion Latency: event occurrence to the data being available in the monitoring/security system. Detection Latency: data availability to the event actually being identified and an alert generated.

Two related framings on this page. The MTTD card above (Assurance) is scoped to confirmed security incidents specifically -- measured only against true positives, for SOC-metric reporting. This decomposition is the broader IT-operations/SRE framing of the same idea, and maps directly onto two other concepts already on this page: this app's own Ingestion Latency tier classification and the Detection Latency metric card are the two components this formula adds together.

Alternative terms

MTTD is also commonly known by these names, used interchangeably or as close equivalents across IT incident management, cybersecurity, observability and site reliability engineering (SRE):

Mean Time to Discover
Mean Time to Identify (MTTI)
Mean Time to Discovery
End-to-End Latency (from event occurrence to detection/alert)
Event-to-Alert Latency

Naming collision to watch for: this list's "Mean Time to Identify (MTTI)" is a different metric from the MTTI already defined elsewhere on this page (Mean Time to Identify / Investigate) -- there, MTTI is the analyst triage-and-diagnosis time after an alert fires, not a synonym for detection itself. Use context, not the acronym alone, to tell them apart.

Worked example

Incident	Event start	Data ingested	Detected	Ingestion latency	Detection latency	Total MTTD
1	10:00:00	10:02:30	10:05:00	2.5 min	2.5 min	5.0 min
2	11:15:00	11:16:00	11:22:00	1.0 min	6.0 min	7.0 min
3	14:30:00	14:33:00	14:36:00	3.0 min	3.0 min	6.0 min

Average MTTD = (5.0 + 7.0 + 6.0) / 3 = 6.0 minutes

Average Ingestion Latency = (2.5 + 1.0 + 3.0) / 3 = 2.2 minutes
Average Detection Latency = (2.5 + 6.0 + 3.0) / 3 = 3.8 minutes
Total average MTTD = 2.2 + 3.8 = 6.0 minutes

Key points & summary

Lower is better -- a shorter MTTD means threats or problems are found more quickly, reducing potential damage.
Commonly used alongside Mean Time to Contain / Respond (MTTC/MTTR) in cybersecurity, IT operations, SRE and incident management.
Detection can come from automated alerts, log analysis, user reports, threat intelligence, or manual investigation.
Factors that influence MTTD include the maturity of monitoring tools, alert quality, staff training, and visibility across systems.
Separating ingestion and detection latency helps pinpoint whether delays come from data-pipeline issues or from detection logic/process gaps.

MTTD answers: "How long does it take us, on average, to notice something is wrong?" -- the combined result of how quickly data reaches the system (ingestion latency) and how quickly that data is analyzed and flagged (detection latency).

← Back to References

References / Detailed reference

Business Impact Level (BIL)

BIL is the assessed impact of a confidentiality, integrity or availability compromise -- rated on a governed scale -- that provides the rationale and derivation for the classification recorded on the parent Data Classification record (TAX-02.02.06). BIL is the input to a classification decision, not a second classification system running alongside it.

Definition

Business Impact Level is a rating of the harm that would result if a specific data source or system were compromised on one of three dimensions -- Confidentiality, Integrity or Availability. The rating with the greatest assessed harm across those three dimensions drives the derived classification recorded against the source.

BIL answers "how bad would it be," not "how likely is it." Likelihood, existing controls and residual risk belong on the Risk Assessment record (TAX-02.04.01); BIL is a consequence rating, not a probability-weighted one, and the two should not be blended into a single number.

Assessment method

1. Assess Confidentiality impactWhat harm results if this data is disclosed to someone not authorised to see it -- exposed credentials, privileged-account activity, personal information, commercially sensitive detail?

2. Assess Integrity impactWhat harm results if this data is altered or fabricated without detection -- falsified audit evidence, tampered financial records, a masked security event?

3. Assess Availability impactWhat harm results if this data becomes inaccessible when needed -- a blocked investigation, a missed compliance deadline, an unrecoverable incident timeline?

4. Take the highestThe overall BIL rating is the highest (worst-case) rating across the three dimensions, not an average -- one severe dimension should not be diluted by two mild ones.

5. Record the driving dimensionAlways record which dimension produced the overall rating and why -- the rationale is what makes the rating defensible and repeatable, not the number alone.

6. Derive the classificationMap the overall BIL rating to a classification using the organisation's approved BIL table, and record that classification on the parent Data Classification record.

BIL scale reference

BIL	Harm level	Indicative classification
1	No or negligible harm	OFFICIAL
2	Limited damage	OFFICIAL: Sensitive
3	Damage	PROTECTED
4	Serious damage	PROTECTED (upper band)
5	Exceptionally grave damage	SECRET
6	Catastrophic / exceptional national-level damage	TOP SECRET

This mapping is illustrative, not an asserted external standard. Consistent with the local scoring rubrics used elsewhere in this framework, the organisation's own approved BIL-to-classification table (e.g. its PSPF/ISM instantiation) is the governing reference -- record its version, owner and approval status alongside any BIL result, and do not treat the table above as authoritative on its own.

Worked examples

Worked Example 1 — WEC Server / Windows Security Events: not yet assessed

Dimension	Finding
Confidentiality	Not currently assessed.
Integrity	Not currently assessed.
Availability	Not currently assessed.

Overall BIL = Not currently recorded | Derived classification = Not currently recorded

Consistent with this source's Not Assessed governance status elsewhere in the taxonomy -- the data is flowing and reasonably well covered by detections, but nobody has yet rated the impact of it being disclosed, altered or lost.

Worked Example 2 — Okta / SaaS Authentication Logs: BIL 3, PROTECTED

Dimension	Finding
Confidentiality	Exposure of authentication events and session context could reveal privileged-account activity and control effectiveness, materially aiding an adversary targeting privileged identities.
Integrity	Tampering would be difficult to achieve without also compromising the identity provider itself; assessed as lower relative impact.
Availability	Short-term unavailability delays investigation but does not block it, given overlapping telemetry from other sources.

Driving dimension = Confidentiality | Overall BIL = 3 | Derived classification = PROTECTED

Confidentiality is the clear driver here -- Integrity and Availability are both assessed lower, so the overall rating takes the Confidentiality result rather than averaging the three.

Worked Example 3 — AWS CloudTrail: BIL 5, SECRET

Dimension	Finding
Confidentiality	Reveals account structure and administrative activity across the cloud estate; a meaningful but recoverable exposure.
Integrity	Undetected tampering with the audit trail could mask an attacker's actions across every account in the estate, undermining every downstream investigation and compliance attestation that relies on it.
Availability	Gaps in the trail during an active incident would materially impair root-cause and scope determination.

Driving dimension = Integrity | Overall BIL = 5 | Derived classification = SECRET

Here the driving dimension flips to Integrity -- the source is a control record other systems and investigations depend on, so tampering has a much higher ceiling than disclosure alone.

Interpretation and decision use

BIL	Decision implication
1–2	Standard handling controls are typically sufficient; confirm classification is still recorded rather than left implicit.
3–4	Confirm access control, retention and audit-trail requirements match the PROTECTED-band handling requirements before treating the source as governed.
5–6	Treat as a priority governance item -- access, encryption, monitoring and incident-handling requirements at this level are rarely met by default configuration.
Not recorded	Treat as an open governance gap, not as an implicit low-impact source -- absence of a BIL rating is not evidence of low impact.

Do not let a missing rating default to "low impact." A source with no BIL assessment on record should be treated as unclassified and unmanaged, not assumed benign -- the WEC Server example above is exactly this case: broadly useful telemetry with no impact rating behind it yet.

Relationship to Data Classification and Risk Assessment

BIL is the input; Data Classification (TAX-02.02.06) is the record of the outcome. A Data Classification record's classification, handling requirements, owner and scope should trace back to a current BIL assessment -- do not set a classification value without a BIL (or equivalent governed rationale) behind it, and do not treat BIL as a substitute for actually recording the classification itself.

BIL is not Risk Assessment (TAX-02.04.01). Risk Assessment combines threat, vulnerability, existing controls and likelihood into a residual risk rating for a platform; BIL is a narrower, consequence-only rating of what a C/I/A compromise of a specific data source would mean, independent of how likely that compromise is or what controls currently exist.

← Back to References

References / Detailed reference

Cyber Value Index (CVI)

CVI is the single weighted score for whether an already-onboarded source's logging is investigation-ready -- combining Event Type Coverage, Required Field Coverage, Event Context Completeness and Data Quality into one number. It is the first of the four indices that roll up into CMEI.

Definition

Cyber Value Index combines four independent, already-scored measures of logging quality into a single weighted percentage: does the source capture the right event types, carry the right fields, answer the seven investigative questions completely, and hold up on technical quality.

Components and weights

Component	Weight	Source
Event Type Coverage (ETC)	30%	TAX-07.08 -- required event types captured ÷ required event types
Required Field Coverage (RFC)	25%	TAX-07.09 -- required fields present, populated and usable ÷ required fields
Event Context Completeness (ECCS)	25%	TAX-07.10 -- seven-dimension score ÷ 28
Data Quality Score (DQS)	20%	TAX-07.12 -- timestamp quality, parsing success, consistency, normalisation and completeness, each 0–4, ÷ 20

Calculation

CVI = (ETC × 0.30) + (RFC × 0.25) + (ECCS × 0.25) + (DQS × 0.20)All four inputs are already expressed as a percentage before weighting.

CVI is a blend, not a gate. Unlike RRI, OAI and TDI, none of the four inputs caps the others -- a weak component pulls the average down proportionally rather than capping the whole score. Read the lowest-scoring component alongside the total; a 68% CVI hiding a 20% DQS is a different problem to a 68% CVI with all four components clustered near 68%.

Worked examples

Worked Example 1 — WEC Server / Windows Security Events: not currently recorded

CIM compliance (100%) and MITRE ATT&CK detection coverage (95.5%) are recorded for this source, but those are different measures -- neither ETC, RFC, ECCS nor DQS has been separately assessed and scored for it. A high CIM percentage does not substitute for a CVI calculation.

CVI = Not currently recorded

Worked Example 2 — illustrative source: ETC 70%, RFC 75%, ECCS 64%, DQS 65% → 68.75%, Adequate

Component	Score	Weighted
ETC	70%	21.00
RFC	75%	18.75
ECCS	64%	16.00
DQS	65%	13.00

CVI = 21.00 + 18.75 + 16.00 + 13.00 = 68.75% | Rating = Adequate

Worked Example 3 — Custom API Health Telemetry (VIA-002): 27.25%, Poor

Component	Score	Weighted
ETC	30%	9.00
RFC	25%	6.25
ECCS	20%	5.00
DQS	35%	7.00

CVI = 9.00 + 6.25 + 5.00 + 7.00 = 27.25% | Rating = Poor

Consistent with this source's own viability record -- discovery required, weak schema availability -- every input component is low, not just one.

Interpretation and decision use

CVI	Rating	Decision implication
90–100%	Excellent	Data is investigation-ready across all four dimensions; maintain through the normal review cadence.
75–89%	Good	Reliable now; close remaining component gaps at the next review.
60–74%	Adequate	Usable but uneven; identify and prioritise the weakest component.
40–59%	Weak	Material gaps across multiple components; do not treat this source as fully investigation-ready.
0–39%	Poor	The source cannot be relied on for investigation without significant remediation.

Relationship to CMEI and the Log Source Cyber Value model

CVI is the "is the data valuable" leg of CMEI (TAX-07.20), alongside TDI (are threats detected effectively), RRI (can responders act on it) and OAI (is the pipeline reliable). Every RRI/OAI/TDI reference page in this framework refers back to CVI by name in its relationship section -- this is the page those references point to.

CVI is not the Log Source Cyber Value model. CVI scores an already-onboarded, governed source's data quality. Log Source Cyber Value scores a candidate source's intrinsic value before onboarding, using a different set of components (Marginal Novelty, Pivot Density/Breadth, Semantic Value, Entity Coverage, Detection Value). Do not use one calculator to answer the other's question.

← Back to References

References / Detailed reference

Log Source Cyber Value

The 40-point model used to score a candidate log source's intrinsic value before onboarding -- combining Marginal Novelty, Pivot Density, Semantic Value, Pivot Breadth, Entity Coverage and Detection Value. Each of those six components has its own detailed reference; this page is the hub that explains how they combine.

Definition

Log Source Cyber Value estimates the incremental security value a candidate source would add if onboarded, after minimum data-quality gates (parse rate, timestamp/timezone reliability, schema stability) pass. It is a pre-onboarding decision tool -- once a source is live and governed, use CVI instead.

Components and weights

Component	Weight	Max points	Detailed reference
Marginal Novelty	×2.0	10	Reconstructible percentage against existing sources
Pivot Density	×1.5	7.5	% of events with a usable pivot key
Semantic Value	×1.5	7.5	Action Completeness + Outcome Completeness
Pivot Breadth	×1.0	5	Distinct pivot-key types present
Entity Coverage	×1.0	5	Breadth and quality of represented entities
Detection Value	×1.0	5	Usefulness for correlation, alerting, hunting, triage

Each component is scored 0–5 independently (see its own detailed reference for the scoring rubric), then multiplied by its weight. Marginal Novelty carries the most weight because duplicated telemetry is the single biggest false-value risk in onboarding decisions.

Calculation

Log Source Cyber Value (%) = weighted achieved points ÷ 40 × 100Six components, 0–5 each, weighted sum out of a possible 40 points.

Gated, not blended. The three assessment gates (minimum parse rate, timestamp & timezone reliability, schema stability) must all pass before this score is considered reliable -- a candidate that fails a gate should not receive a value score at all, regardless of how the six components would otherwise weigh.

Worked examples

Worked Example 1 — Microsoft Entra sign-ins (candidate): 28/40 = 70%, Adequate

Component	Score (0–5)	Weighted
Marginal Novelty	3	6.0
Pivot Density	4	6.0
Semantic Value	4	6.0
Pivot Breadth	3	3.0
Entity Coverage	3	3.0
Detection Value	4	4.0

28.0 / 40 = 70% | Rating = Adequate

Marginal Novelty of 3 reflects this candidate's 55% reconstructible-information result from its own reference page -- cloud-native authentication, conditional access and risk context are the genuinely new evidence overlapping with VPN and endpoint sources.

Worked Example 2 — Custom API Health Telemetry (VIA-002, candidate): 6/40 = 15%, Poor

Component	Score (0–5)	Weighted
Marginal Novelty	1	2.0
Pivot Density	1	1.5
Semantic Value	1	1.5
Pivot Breadth	0	0.0
Entity Coverage	1	1.0
Detection Value	0	0.0

6.0 / 40 = 15% | Rating = Poor

Consistent with this candidate's own viability record: weak schema availability and discovery still required means every downstream value dimension is depressed, not just one.

Interpretation and decision use

Score	Rating	Decision implication
90–100%	Excellent	High-priority onboarding candidate.
75–89%	Good	Prioritise onboarding; validate coverage and volume before committing.
60–74%	Adequate	Onboard with targeted scope, or enrichment to lift the weakest component.
40–59%	Weak	Consider selective event classes or field-level filtering rather than full ingestion.
0–39%	Poor	Prefer existing sources unless assurance, compliance or resilience requires duplication.

Relationship to CVI and CMEI

Log Source Cyber Value is a pre-onboarding candidate-scoring model; CVI is a post-onboarding data-quality index. They share no formula overlap despite both producing a 0–100% cyber-value-style score -- Log Source Cyber Value answers "should we onboard this," CVI answers "how good is what we already onboarded." Neither substitutes for the other.

Its six components are individually detailed on their own reference pages: Marginal Novelty, Pivot Density & Breadth, Semantic Value, and Entity Coverage. This page exists specifically to show how those six add up, since every one of them refers back to "the Log Source Cyber Value model" without previously having a page of its own to point to.

← Back to References

References / Detailed reference

Entity Coverage

Entity Coverage measures the breadth and quality of security-relevant entities a source represents -- actors, assets, resources and objects -- without rewarding repetition of the same entity. It is one of six components of the Log Source Cyber Value model, weighted ×1.0.

Definition

Entity Coverage asks whether a source identifies the actors, assets, resources and objects needed to investigate and correlate activity -- not how many events it produces, and not how many times the same entity appears.

Entity classes

Entity class	Definition
Human and non-human identities	People, service accounts, and non-human actors (bots, applications) that can perform or be attributed with activity.
Hosts, endpoints and devices	Physical or virtual machines, workstations, servers and devices where activity occurs.
Source and destination network entities	Network-layer identifiers (IP addresses, network zones) describing where traffic originates and terminates.
Applications, services and workloads	Software applications, services or workloads that generate, receive or are acted upon by an event.
Cloud resources, accounts, subscriptions, projects and tenants	Cloud-provider scoping entities and the resources within them.
Processes, files, certificates and software objects	Executables, processes, files and certificates involved in an event.
Data, business or protected objects	Business records, protected data objects or other application-level objects an event acts on.
Sessions, requests, transactions and traces	Session, request, transaction or trace identifiers that scope related activity.
Security controls, policies, roles and groups	Security policies, controls, roles or group memberships referenced by an event.

Count a class only when at least one value is populated and usable -- reliably resolvable, not anonymous, generic, shared, truncated or unnormalised.

Calculation and local scoring matrix

Entity Coverage (%) = weighted achieved points ÷ weighted possible points × 100Score each applicable entity class 0–4; equal weights unless a supplied requirement defines priorities.

Rating	Meaning
0 — Absent	Class not represented at all.
1 — Rare / unreliable	Present but sparse or inconsistent.
2 — Partial	Present with material gaps.
3 — Strong	Consistently present and usable.
4 — Comprehensive	Consistently present, usable and resolvable across the sample.

Worked examples

Worked Example 1 — Microsoft Entra sign-ins: 18 of 24 applicable = 75%, High

Entity class	Score	Rationale
Human and non-human identities	4	UPN plus immutable object ID reliably resolve every actor.
Hosts, endpoints and devices	2	Device ID is present for managed devices only; unmanaged/BYOD sign-ins carry no device object.
Source and destination network entities	N/A -- excluded	A sign-in event carries a source IP, not a network entity pair; not a meaningful class for this event type.
Applications, services and workloads	3	Target application/resource is consistently identified; the requesting client application is not always resolved.
Cloud resources, accounts, subscriptions, projects and tenants	4	Tenant ID and resource display name are present and resolvable on every event.
Processes, files, certificates and software objects	N/A -- excluded	Not applicable to an identity-provider sign-in event.
Data, business or protected objects	N/A -- excluded	Sign-in events do not reference downstream data objects.
Sessions, requests, transactions and traces	3	Correlation ID supports session-level tracing; not a persistent, multi-request session object.
Security controls, policies, roles and groups	2	Conditional Access policy result is recorded; group/role membership is not carried on the event itself.

18 achieved ÷ (9 − 3 excluded) × 4 possible = 18 / 24 applicable = 75% | Rating = High

Worked Example 2 — WEC Server / Windows Security Events: 14 of 36 = 39%, Very Low

Entity class	Score	Rationale
Human and non-human identities	3	Username plus SID reliably resolve the actor; domain context is inconsistent.
Hosts, endpoints and devices	3	Computer/workstation name is consistently populated.
Source and destination network entities	1	Source IP only appears on network logon types (3, 10); most events carry none.
Applications, services and workloads	1	Process/service name occasionally identifies a workload; not a first-class field on this event set.
Cloud resources, accounts, subscriptions, projects and tenants	0	On-premises security events carry no cloud resource context.
Processes, files, certificates and software objects	2	Process name/ID is present on several event codes; parent/child lineage is not always populated.
Data, business or protected objects	0	The Security event log does not carry object- or data-level context.
Sessions, requests, transactions and traces	3	Logon ID is a strong, consistently populated session pivot.
Security controls, policies, roles and groups	1	Privilege/group membership appears only on specific event codes (4672, 4735).

Sum = 14 of 36 possible (9 classes, none excluded) = 39% | Rating = Very Low

No class is fully absent, but none is strong either -- consistent with this source's Data Source Assurance (37%) and RRI (15%) results, this is a source with real signal that has not been built out for investigation use.

Interpretation

Score	Rating
90–100%	Exceptional
75–89%	High
60–74%	Moderate
40–59%	Low
0–39%	Very Low

Relationship to Log Source Cyber Value

Entity Coverage is weighted ×1.0 in the Log Source Cyber Value model (contributing up to 5 of 40 points), alongside Marginal Novelty (×2.0), Pivot Density (×1.5), Semantic Value (×1.5), Pivot Breadth (×1.0) and Detection Value (×1.0). It is closely related to but distinct from Identity Diversity, which measures the quality and spread of identity entities specifically rather than breadth across all nine entity classes.

← Back to References

References / Detailed reference

Identity Diversity Score (IDS)

Measures whether a source shows a useful range of actors and identity types, or is dominated by one account, anonymous activity or a single service identity. A thousand events from the same machine account still represent low identity diversity.

Definition

Identity Diversity measures the breadth, quality, population spread and investigative usefulness of identities a source represents -- human, privileged, service, machine, application, API, federated and external -- without rewarding repeated activity from the same identity.

Scoring dimensions

Dimension	Weight	0 vs. 4
Identity-Type Breadth	25%	No usable identity → five or more security-relevant identity types
Distinct Identity Population	20%	All events from one identity → broad representative population, not artificially inflated
Privileged / High-Risk Visibility	20%	Cannot distinguish privilege → strong visibility of privilege level, role and elevation
Identity Quality & Resolution	20%	Anonymous or blank values → stable, normalised, correlation-ready identifiers
Distribution Balance	15%	One account dominates almost everything → representative distribution

Normalise DOMAIN\user, user@domain and equivalent forms before counting -- do not count aliases or case variations as different identities.

Calculation

IDS = ((Breadth × 0.25) + (Population × 0.20) + (Privileged Visibility × 0.20) + (Quality × 0.20) + (Balance × 0.15)) ÷ 4 × 100Each dimension scored 0–4; the weighted sum out of 4 is normalised to 0–100.

Worked examples

Worked Example 1 — Active Directory / IAM: 91, Exceptional

Dimension	Score
Identity-Type Breadth	4 (user, computer, service account, admin group)
Distinct Population	4
Privileged Visibility	3
Identity Quality	4
Distribution Balance	3

((4×.25)+(4×.20)+(3×.20)+(4×.20)+(3×.15)) = 3.65 ÷ 4 × 100 = 91.25%, rounded to 91 | Rating = Exceptional

Worked Example 2 — WEC Server / Windows Security Events: 65, Moderate

Dimension	Score
Identity-Type Breadth	2 (human and service accounts; machine identities weak)
Distinct Population	3
Privileged Visibility	3 (EventCode 4672 gives elevation context)
Identity Quality	3 (SID present but domain context inconsistent)
Distribution Balance	2 (service accounts dominate a large share of events)

((2×.25)+(3×.20)+(3×.20)+(3×.20)+(2×.15)) = 2.6 ÷ 4 × 100 = 65% | Rating = Moderate

Interpretation

IDS	Rating
90–100	Exceptional
75–89	High
60–74	Moderate
40–59	Low
0–39	Very Low

Relationship to Log Source Cyber Value

Identity Diversity complements Event Type Coverage, Pivot Breadth, Entity Coverage and ECCS rather than duplicating them -- it is specifically about the identity population's breadth and quality, not entity breadth generally (see Entity Coverage) or context completeness within a single event (see ECCS). It is not one of the six weighted Log Source Cyber Value components, but is listed alongside them on the Log Source Cyber Value method card as supporting evidence for the Semantic Value and Entity Coverage components.

← Back to References

References / Detailed reference

Investigation Breadth Score (IBS)

Measures how many different investigation routes a source can support across identity, asset, activity, timeline, outcome, impact and correlation -- not how many events it produces, and not repeated instances of one event type.

Definition

Investigation Breadth asks how many distinct investigative questions and routes a log source can support. A source with strong semantic clarity but only one repeated event type can still score low here -- breadth is about the range of enquiries the evidence supports, not how clearly any single event reads.

Scoring dimensions

Dimension	Weight	Investigative question
Identity Investigations	20%	Can an actor be attributed and traced across events?
Asset & Location Investigations	15%	Can a host, device, application, tenant or location be traced?
Activity & Behaviour Investigations	20%	Can distinct security-relevant behaviours be investigated?
Timeline Reconstruction	15%	Can sessions, sequences or related actions be reconstructed?
Outcome & Response Paths	10%	Do outcomes support escalation, containment or validation decisions?
Impact & Affected-Object	10%	Can scope or consequence be assessed?
Correlation & Pivot Routes	10%	Do reliable pivot identifiers support cross-event investigation?

Calculation

IBS = ((Identity×20) + (Asset×15) + (Activity×20) + (Timeline×15) + (Outcome×10) + (Impact×10) + (Correlation×10)) ÷ 4Each dimension scored 0–4; result normalised to 0–100.

Distinguish IBS from its neighbours. ECCS measures context completeness within an event; IBS measures the range of enquiries supported across the source. Pivot Breadth counts usable pivot-key types; IBS measures complete investigative routes built from those keys. ETC measures expected event-class coverage; IBS measures what those events actually let an analyst investigate.

Worked examples

Worked Example 1 — Okta / SaaS Authentication Logs: 78, High

Dimension	Score
Identity	4
Asset/Location	3
Activity/Behaviour	3
Timeline	3
Outcome/Response	3
Impact	2
Correlation/Pivot	3

((4×20)+(3×15)+(3×20)+(3×15)+(3×10)+(2×10)+(3×10)) ÷ 4 = 78 | Rating = High

Worked Example 2 — Firewall (allow/deny traffic only): 56, Limited

Dimension	Score
Identity	1 (no user identity in traffic events)
Asset/Location	4 (strong source/destination/zone tracing)
Activity/Behaviour	2 (allow/deny only, no richer behaviour classes)
Timeline	3
Outcome/Response	2
Impact	1
Correlation/Pivot	3

((1×20)+(4×15)+(2×20)+(3×15)+(2×10)+(1×10)+(3×10)) = 225 ÷ 4 = 56.25%, rounded to 56 | Rating = Limited

Strong network tracing, but no identity or impact evidence -- traffic-only firewall logs support far fewer investigation routes than the management-plane and threat-detection events from the same platform would.

Interpretation

IBS	Rating
90–100	Exceptional
75–89	High
60–74	Moderate
40–59	Limited
20–39	Poor
0–19	Minimal

Relationship to Log Source Cyber Value

Investigation Breadth is listed on the Log Source Cyber Value method card as supporting evidence for the model's Semantic Value and Entity Coverage components, alongside Identity Diversity -- it is not itself one of the six weighted components, but the range of investigation routes it documents is exactly the kind of evidence an assessor should cite when scoring Detection Value and Entity Coverage.

← Back to References

References / Detailed reference

Context Dimension Coverage (CDC)

CDC measures the percentage of events -- across the whole dataset -- that carry usable evidence for each of the seven investigative context dimensions. It surfaces systemic gaps that an average-looking event can hide.

Definition

CDC scores each of the seven dimensions -- When, Who, Where, What, Outcome, Impact, Correlation -- as the percentage of events in the dataset carrying usable evidence for it. Present means populated, correctly interpreted and usable; empty, null, placeholder, constant or malformed values count as absent.

Assessment method

1. Assess every event against every dimensionNot a per-event average -- each dimension gets its own dataset-wide percentage.

2. Count each event once per dimensionA dimension is either usable or not for that event; don't double count multiple fields supplying the same dimension.

3. Calculate per-dimension coverageEvents with usable dimension evidence ÷ total events × 100.

4. Average for the overall CDCEqual weighting across the seven dimensions unless a supplied policy states otherwise -- state any weighting used.

Calculation

Dimension Coverage (%) = events with usable evidence for that dimension ÷ total events × 100Overall CDC = average of the seven dimension percentages.

Worked examples

Worked Example 1 — Windows Security Events file (1,000 events): CDC 71%, High

Dimension	Coverage
When	100%
Who	96%
Where	62%
What	100%
Outcome	88%
Impact	34%
Correlation	18%

Average = (100+96+62+100+88+34+18)/7 = 71% | Rating = High

The average alone hides that Correlation is systemically weak -- only logon-type events carry a Logon ID, and most event classes in this source don't.

Worked Example 2 — Firewall traffic log: CDC 60%, Moderate

Dimension	Coverage
When	100%
Who	4%
Where	100%
What	90%
Outcome	85%
Impact	5%
Correlation	38%

Average = (100+4+100+90+85+5+38)/7 = 422/7 = 60.3%, rounded to 60% | Rating = Moderate

The average hides that Who and Impact are near-zero across the whole dataset, not just a few noisy events -- a systemic gap, not a sampling artefact, sitting underneath an otherwise Moderate-looking headline number.

Interpretation

CDC	Rating
90–100%	Exceptional
75–89%	High
60–74%	Moderate
40–59%	Limited
Below 40%	Poor

Related measures

CDCCoverage of seven broad questions across the whole dataset -- systemic, dataset-wide view.

ICDGranular context-type breadth per event, against a 36-type catalogue -- individual-event view.

INPThe percentage of events below a usefulness threshold -- CDC's per-dimension gaps are often the root cause of a high INP.

ECCSQuality and completeness of the same seven dimensions on a 0–4 scale per representative event, not a dataset-wide percentage.

← Back to References

References / Detailed reference

Investigative Noise Percentage (INP)

INP measures the percentage of valid events that fail an approved minimum investigative-context threshold -- events that individually carry insufficient standalone value for investigation, regardless of how many of them there are.

Definition

INP is a lower-is-better metric: the share of a valid, classified event population that fails the minimum bar for standalone investigative usefulness. It is not a measure of malicious versus benign activity -- a low-severity event can still be signal, and a high-severity event with no context is still noise by this definition.

Default threshold

An event is useful when at least 4 of the 7 context dimensions (When, Who, Where, What, Outcome, Impact, Correlation) are usable and What is present. Use a different threshold only when an approved assessment policy explicitly requires it -- and record which threshold was used alongside any INP result.

Do not classify by severity. A high-severity alert with no identity, location or outcome context is still noise under this definition; do not exempt it from the threshold just because it looks important.

Calculation

INP (%) = Noise Events ÷ Total Valid Events × 100Useful Percentage = 100 − INP.

Worked examples

Worked Example 1 — Okta / SaaS Authentication Logs: INP 8%, Excellent

920 of 1,000 valid events meet the 4-of-7 threshold | Noise = 80 events | INP = 8%

The small noise share is concentrated in low-context heartbeat and token-refresh events that carry only When and Correlation.

Worked Example 2 — Firewall traffic (allow/deny only): INP 61%, High noise

390 of 1,000 valid events meet the threshold | Noise = 610 events | INP = 61%

Most traffic events carry only When, Where and a coarse What (allow/deny) -- without Who, Impact or Correlation, the majority fail the 4-of-7 bar even though every event is individually well-formed.

Interpretation

INP	Rating	Decision implication
0–9%	Excellent	Most events are individually investigation-ready.
10–24%	Good	Minor noise; no action typically required.
25–39%	Moderate	Consider enrichment for the weakest event classes.
40–59%	High noise	A large share of ingest carries little standalone value; review filtering or enrichment.
60–100%	Severe	Most events fail the usefulness bar; reassess whether raw ingestion at this volume is justified.

High INP is not automatically a reason to drop a source. A source can be high-volume, high-noise and still required for compliance, resilience or as raw evidence that other, lower-volume sources reference. Read INP alongside Marginal Novelty and Detection Value before recommending filtering.

Related measures

INPPercentage of events below a usefulness threshold -- a noise measure.

ICDSupplies the per-event context-type count INP's threshold is built from.

CDCDataset-wide per-dimension coverage; a high INP is usually explained by one or two CDC dimensions being systemically weak.

← Back to References

References / Detailed reference

Data Source Assurance

Whether an already-onboarded source is reliably collected, monitored, governed and fit for sustained security use -- scored across 15 operational controls spanning ownership, collection security, monitoring, change management and retention.

Definition

Data Source Assurance is a maturity assessment, not a point-in-time health check -- it asks whether the operational practices around a source (not just its current data) are evidenced, sustained and would catch a failure before an analyst does. Score only from supplied evidence; a control claimed in design documentation but never operationally evidenced should be scored as ad hoc, not implemented.

Controls assessed

Control	Definition
Source ownership & accountability	A named, contactable owner is accountable for the source.
Collection-path documentation	The collection path (source to index) is documented.
Authentication & secret management	Credentials and secrets used for collection are managed and rotated securely.
Transport security	Data in transit is protected (e.g. TLS).
Availability & freshness monitoring	Automated checks confirm the source is up and data is current.
Volume/EPS baselines & anomaly detection	Expected volume/EPS is baselined and deviations are detected.
Parsing & schema monitoring	Parsing success and schema conformance are actively monitored, not just implied by a one-off check.
Completeness & gap detection	Missing or dropped events are detected.
Retry, checkpoint & recovery behaviour	The collection mechanism can resume cleanly after an interruption.
Duplicate prevention	Mechanisms exist to prevent or detect duplicate event ingestion.
Change management & version control	Changes to collection configuration are tracked and version-controlled.
Access control & segregation of duties	Access to the source and its configuration is controlled and appropriately segregated.
Retention & legal obligations	Retention meets defined operational and legal/compliance requirements.
Operational runbooks, alerting & escalation	Documented runbooks and alerting exist for collection failures.
Periodic validation & evidence retention	The source is periodically re-validated and evidence of that validation is retained.

15 controls in total. Mark a control unknown rather than 0 when evidence simply wasn't supplied for the assessment -- 0 means evidence shows the control is genuinely absent, which is a different finding to "not reviewed this time."

Calculation and local scoring matrix

Data Source Assurance (%) = weighted achieved points ÷ weighted possible points × 10015 controls, scored 0–4 each, equal weight by default unless supplied control weights apply.

Rating	Meaning
0 — Absent	Evidence shows the control does not exist.
1 — Ad hoc	Happens informally, undocumented, person-dependent.
2 — Partially implemented	Exists for some but not all of the source's scope.
3 — Implemented and evidenced	Consistently in place with a citable record.
4 — Measured, automated and regularly assured	Runs without manual intervention and is itself periodically reviewed.

Worked examples

Worked Example 1 — WEC Server / Windows Security Events: 37%, Developing

Control	Score
Ownership & accountability	3 — Windows Eng named and contactable
Availability & freshness monitoring	3 — 2 of 2 health checks passing
Periodic validation & evidence retention	2 — last-validated date recorded, no fixed cadence evidenced
Collection-path documentation	2
Authentication & secret management	2
Transport security	2
Parsing & schema monitoring	2 — implied by 100% CIM compliance, not independently monitored
Volume/EPS baselines	1
Completeness & gap detection	1
Retry / checkpoint / recovery	1
Duplicate prevention	1
Access control & segregation of duties	1
Operational runbooks & escalation	1
Change management & version control	0 — Configuration Change Record shows no tracked history
Retention & legal obligations	0 — retention Not Recorded

Sum = 22 of 60 possible | 22 / 60 = 37% | Rating = Developing

Collection and health monitoring are genuinely solid; almost every governance-adjacent control (change management, retention, access control, runbooks) is the weak half of this picture, consistent with every other assessment run against this source.

Worked Example 2 — Okta / SaaS Authentication Logs: 83%, Advanced

Control	Score
Ownership & accountability	4 — IAM team named, SLA-backed
Collection-path documentation	3 — documented vendor API integration
Authentication & secret management	4 — vendor-managed, rotated API tokens
Transport security	4 — vendor-managed TLS
Availability & freshness monitoring	4 — automated, alerts the on-call rotation
Volume/EPS baselines	2 — partially implemented
Parsing & schema monitoring	3 — implied by CIM mapping, not independently alerted
Completeness & gap detection	3
Retry / checkpoint / recovery	3 — vendor-managed, documented behaviour
Duplicate prevention	2 — partially implemented
Change management & version control	4 — documented, version-controlled configuration baseline
Access control & segregation of duties	3
Retention & legal obligations	4 — defined retention and review cadence
Operational runbooks & escalation	4
Periodic validation & evidence retention	3

Sum = 50 of 60 possible | 50 / 60 = 83% | Rating = Advanced

Vendor-managed transport, authentication and change control cover most of the highest-scoring controls; only volume/EPS anomaly detection and duplicate prevention remain partially implemented.

Interpretation and decision use

Score	Rating	Decision implication
90–100%	Optimised	Operational practices are automated and self-assuring; maintain through the normal review cadence.
75–89%	Advanced	Reliable now; close remaining control gaps at the next review.
50–74%	Managed	Core controls are in place but depend on manual effort; prioritise automation.
25–49%	Developing	Real gaps across multiple controls; treat as an open remediation programme, not a one-off fix.
0–24%	Ad hoc	The source's operational practices cannot be relied on without significant investment.

Identify mandatory control failures separately from the overall percentage. A 60% score built from consistent 3s and 4s reads very differently to a 60% score hiding one or two controls at 0 -- always report which controls, if any, are absent outright, not just the blended total.

Relationship to CVI, RRI, OAI and TDI

Data Source Assurance is the broadest of the related assurance measures -- it overlaps with OAI (availability and health monitoring), RRI (ownership, runbooks and escalation) and CVI (parsing and schema quality feed into data quality), but assesses the underlying operational practice maturity behind each of those, rather than a current-state score or gate. Where OAI asks "is the pipeline healthy right now," Data Source Assurance asks "would we actually catch it if it stopped being healthy."

← Back to References

References / Detailed reference

Event Type Coverage (ETC)

ETC measures whether the required security-relevant event types are represented in a source -- not how many events it produces. Event diversity is assessed within ETC rather than as a separate score: repeating one event class, or counting cosmetic message variations, does not raise coverage.

Definition

ETC asks whether the required security-relevant event types are present, not simply how many events were collected. Do not reward vendor-specific aliases, parameter changes or raw repetition as if they were behavioural diversity -- assess whether the underlying behaviour is actually represented.

Required event-type categories

Category	Definition
Authentication	Login, logout, MFA challenge and authentication-decision events.
Identity & Account Management	Account creation, deletion, modification and lifecycle events.
Authorization & Access	Access grants, denials, permission and entitlement changes.
Configuration Changes	Changes to system, application or policy configuration.
Administrative Activity	Privileged or administrative actions performed by operators.
Process Execution	Process creation, execution and termination events.
Network Activity	Network connections, traffic flows and network-layer events.
Data Access	Access to, or modification of, data objects and records.
Security Events	Security-specific alerts, detections or control events.
System Events	Operating-system or platform-level events (startup, shutdown, service state).
Availability	Health, uptime and service-availability events.
Cloud Activity	Cloud-provider control-plane and management events.
Detection Events	Events generated by detection or monitoring tooling.
Technology-specific event types	Event types unique to a particular vendor/technology, not covered by the generic categories above.

Unless a technology-specific event catalogue is supplied, assess against these 14 categories. Where a governed catalogue exists for the source family -- see the Required SIEM Event Type catalogue, TAX-03.01.01.01 -- use that instead of the generic list.

Calculation

ETC (%) = Required event types captured ÷ Total required event types × 100

Worked examples

Worked Example 1 — WEC Server / Windows Security Events: not currently recorded as ETC

MITRE ATT&CK detection coverage (95.5%) is a different measure -- technique-level, not required-event-type-level -- and CIM compliance (100%) confirms field normalisation, not category coverage. Windows now maps to the governed SRC-028 (Microsoft Windows Endpoint) catalogue in TAX-03.01.01.01, so this source should be scored against that 34-entry catalogue rather than the generic 14-category list; that assessment has not been run yet for this WEC Server feed, so ETC has not been separately scored for it.

ETC = Not currently recorded

Worked Example 2 — Okta / SaaS Authentication Logs: 10 of 12 applicable = 83%, Good

Category	Status	Evidence
Authentication	Present	Sign-in success/failure, MFA challenge and result
Identity & Account Management	Present	User/group lifecycle, password reset, profile change
Authorization & Access	Present	App assignment, policy evaluation, access grant/revoke
Configuration Changes	Present	Org, policy and rule configuration changes
Administrative Activity	Present	Admin console actions, delegated admin activity
Process Execution	N/A -- excluded	No host-level process visibility from an identity provider
Network Activity	Present	Source IP, device and network context on sign-in events
Data Access	Absent	Okta does not log access to downstream application data/objects
Security Events	Present	ThreatInsight events, suspicious-activity flags
System Events	Absent	No host/OS-level system events from a SaaS identity provider
Availability	Present	Service status and health events
Cloud Activity	N/A -- excluded	Infrastructure-level cloud activity is out of scope for an identity provider
Detection Events	Present	Okta risk scoring and anomaly-detection verdicts
Technology-specific event types	Present	Okta system-event catalogue (okta.system.*)

10 present ÷ (14 − 2 excluded) = 10 / 12 applicable = 83% | Rating = Good

Process Execution and Cloud Activity are excluded from the denominator as genuinely not applicable to a SaaS identity provider, not scored as gaps; Data Access and System Events are excluded from nothing -- they are real, addressable absences.

Worked Example 3 — Firewall, traffic-only feed, scored against the governed SRC-001 catalogue: 2 of 26 = 8%, Poor

Where a governed catalogue exists for the source family, use it instead of the generic 14-category list. SRC-001 (Firewall) in TAX-03.01.01.01 defines 26 required event types across 6 critical collection focus areas; a feed that forwards only allow/deny traffic logs and nothing from the management plane captures just one of those six areas.

Critical collection focus (TAX-03.01.01.01)	Required event types	Captured	Status
Network Traffic	2 -- allowed/denied connection events	2 of 2	Present
Policy Enforcement	5 -- rule, object, NAT, route, security-profile changes	0 of 5	Absent
Threat Prevention	6 -- IPS/IDS, malware, antivirus, URL/application-control, threat-signature matches	0 of 6	Absent
Administrative Access	5 -- admin login/logout/failed login, privilege escalation, command execution	0 of 5	Absent
Availability / Health	6 -- interface status, HA failover, VPN tunnel state, policy install/time-sync/log-forwarding failure	0 of 6	Absent
Configuration Management	2 -- configuration read/dump, system change event	0 of 2	Absent

2 / 26 required event types = 7.7%, rounded to 8% | Rating = Poor

Scoring against the real 26-entry catalogue rather than the generic 14-category list makes the gap concrete: the management-plane change, threat-prevention, admin-access, health and configuration-visibility events this platform is capable of producing are simply not being forwarded -- not a partial-credit shortfall, a wholesale collection gap across five of six focus areas.

Interpretation

ETC	Rating
90–100%	Excellent
75–89%	Good
60–74%	Adequate
40–59%	Weak
0–39%	Poor

Relationship to CVI

ETC carries the highest weight in the Cyber Value Index (×0.30 of 4 components, alongside RFC ×0.25, ECCS ×0.25 and DQS ×0.20) -- missing event-type categories is the single biggest driver of a low CVI, since no amount of field quality or timestamp precision compensates for a category of activity that was never captured at all.

← Back to References

References / Detailed reference

Required Field Coverage (RFC)

RFC measures whether mandatory investigative fields are present, consistently populated, correctly formatted and usable -- not just whether a field key exists somewhere in the schema.

Definition

RFC does not simply count field names. A field only counts as covered when it is present, consistently populated, correctly formatted, and actually usable for investigation, detection, correlation, threat hunting or incident response -- a field that is present but empty, null, placeholder or malformed does not count.

Required field groups

Time (event time, creation time, received time)Identity (user, account, service account, SID)Network (source/dest IP, source/dest port)Host / Asset (hostname, device, asset ID, cloud resource)Event Classification (event type, category, action, object, resource)Outcome (result, status, success/failure, status code, error reason)Severity (severity, risk, priority, classification)Correlation (session, transaction, trace, correlation, process ID)Additional Context (message, vendor, product, sourcetype, tenant, region, command, file, URL)

Calculation

RFC (%) = Fields present, correctly populated and usable ÷ Total required fields × 100

For each field, evaluate presence, population frequency (always/usually/sometimes/rarely/never), consistency (high/medium/low), format quality and investigation usefulness -- a field that's "present" but rarely populated or inconsistently formatted should not be counted as covered.

Worked examples

Worked Example 1 — WEC Server / Windows Security Events: not currently recorded as RFC

The Minimum Required Fields list is recorded per event type in the Required SIEM Event Type catalogue (TAX-03.01.01.01), but no assessment has scored actual presence, consistency and format quality against that list for this source.

RFC = Not currently recorded

Worked Example 2 — Okta / SaaS Authentication Logs: 26 of 34 applicable = 76%, Good

Field group	Present / applicable	Evidence
Time	3 / 3	Event time, creation time and received time all populated.
Identity	3 / 3	User, account and service-account identifiers resolve reliably; SID excluded as a Windows-specific concept.
Network	1 / 1	Source IP populated on every sign-in; destination IP/port excluded -- not a network flow record.
Host / Asset	2 / 2	Device ID and tenant (cloud resource) populated for managed devices; hostname and asset ID excluded.
Event Classification	5 / 5	Event type, category, action, object and resource are all explicit.
Outcome	4 / 5	Result, status, success/failure and error reason populated; no distinct status-code field exists.
Severity	1 / 4	Only risk level is populated; no severity, priority or classification field.
Correlation	2 / 4	Session and correlation IDs populated; no transaction or trace ID. Process ID excluded.
Additional Context	5 / 7	Message, vendor, product, sourcetype and tenant populated; no file or URL reference. Region and command excluded.

26 present ÷ 34 applicable = 76% | Rating = Good

Worked Example 3 — Custom API Health Telemetry (VIA-002): 5 of 31 applicable = 16%, Poor

Field group	Present / applicable	Evidence
Time	2 / 3	Event time and received time present; creation time is not tracked.
Identity	0 / 3	No user, account or service-account identity is captured. SID excluded.
Network	0 / 1	Client source IP is not consistently logged. Destination IP/port excluded.
Host / Asset	0 / 3	Hostname, asset ID and cloud resource are not captured. Device excluded.
Event Classification	1 / 3	Only a coarse event-type string; no category or action field. Object, resource excluded.
Outcome	0 / 5	No result, status or error-reason field exists.
Severity	0 / 4	No severity, risk, priority or classification field.
Correlation	0 / 4	No session, transaction, trace or correlation identifier. Process ID excluded.
Additional Context	2 / 5	Free-text message and a sourcetype label are present; no vendor or product field. Tenant, region, command, file excluded.

5 present ÷ 31 applicable = 16% | Rating = Poor

Consistent with this source's own record of weak schema availability and required discovery work -- Time is the only field group with meaningful coverage.

Interpretation

RFC	Rating
90–100%	Excellent
75–89%	Good
60–74%	Adequate
40–59%	Weak
0–39%	Poor

Relationship to CVI

RFC is weighted ×0.25 in the Cyber Value Index, alongside ETC (×0.30), ECCS (×0.25) and DQS (×0.20). RFC and ECCS overlap in spirit -- both assess whether an event carries enough usable detail -- but RFC checks a fixed, named field list against presence and format quality, while ECCS scores how completely seven investigative questions (When, Who, Where, What, Outcome, Impact, Correlation) are answered, on a 0–4 scale per dimension rather than a field checklist.

← Back to References

References / Detailed reference

Data Quality Score (DQS)

DQS measures the technical quality, reliability and usability of logging data -- timestamp quality, parsing success, consistency, normalisation and completeness -- independent of whether the right event types or fields are present.

Definition

DQS assesses the quality of the data, not merely whether fields exist -- ETC and RFC ask "is the right thing present," DQS asks "is what's present technically trustworthy." A source can score well on ETC and RFC while still scoring poorly here if timestamps drift, parsing silently fails, or naming is inconsistent across event classes.

Five dimensions

Dimension	Cyber-weighted	0 vs. 4
Timestamp Quality	30%	Missing/invalid timestamp → ISO 8601, UTC, millisecond precision, fully normalised
Parsing Success	25%	Most fields unavailable → complete parsing, no observed issues
Consistency	20%	Highly inconsistent naming/formats → completely consistent across events
Normalisation	15%	No normalisation → fully normalised to CIM/ECS/taxonomy standards
Completeness	10%	Large portions missing → complete with virtually no gaps

Calculation

Equal-weighted DQS (%) = (sum of five dimension scores ÷ 20) × 100Each dimension scored 0–4. Use the cyber-weighted formula below when an approved rubric requires it.

Cyber-weighted DQS (%) = Σ(dimension score × weight) × 100Weights: Timestamp Quality 30%, Parsing Success 25%, Consistency 20%, Normalisation 15%, Completeness 10%.

Worked examples

Worked Example 1 — WEC Server / Windows Security Events: not currently recorded as DQS

CIM compliance of 100% is evidence of strong normalisation specifically, but the other four dimensions -- timestamp quality, parsing success, consistency, completeness -- have not been independently scored for this source.

DQS = Not currently recorded

Worked Example 2 — Okta / SaaS Authentication Logs: 17/20 equal-weighted = 85%, Good

Dimension	Score
Timestamp Quality	4 -- ISO 8601, UTC, millisecond precision
Parsing Success	4 -- structured JSON, complete field extraction
Consistency	3
Normalisation	3 -- CIM-mapped
Completeness	3

(4+4+3+3+3) / 20 = 85% | Rating = Good

Worked Example 3 — Custom API Health Telemetry (VIA-002): 4/20 equal-weighted = 20%, Poor

Dimension	Score
Timestamp Quality	1 -- present, no timezone, inconsistent formatting
Parsing Success	1 -- only a few fields extracted
Consistency	0
Normalisation	0
Completeness	2

(1+1+0+0+2) / 20 = 20% | Rating = Poor

Interpretation

DQS	Rating
90–100%	Excellent
75–89%	Good
60–74%	Adequate
40–59%	Weak
0–39%	Poor

Relationship to CVI

DQS is weighted ×0.20 in the Cyber Value Index -- the lowest weight of the four components (ETC ×0.30, RFC ×0.25, ECCS ×0.25), but not because it matters less: DQS failures tend to be systemic rather than partial, since broken parsing or drifting timestamps degrade every event, not just some of them. Timestamp Quality and Log Format Quality (their own detailed references, TAX-07.05 and TAX-07.06) are the deep-dive assessments that typically feed the Timestamp Quality and Parsing Success dimensions here.

← Back to References

References / Splunk event sizing

Line Length Quality Score

Evaluates whether valid logical events are sized safely for Splunk ingestion and whether TRUNCATE is evidence-based, bounded and operationally appropriate.

Definition

The Line Length Quality Score measures whether event sizes are safe, consistent and appropriate for Splunk ingestion without truncation, accidental merging or excessive parsing overhead.

Calculate it from complete logical events after boundary reconstruction. Use UTF-8 byte size for TRUNCATE analysis.

Scoring dimensions

Dimension	Weight	Measure
Truncation Risk	35%	Valid events exceeding configured or default `TRUNCATE`.
Event Boundary Integrity	25%	Whether oversized records are genuine or incorrectly merged.
Size Consistency	15%	P95-to-median variation.
Maximum Event Suitability	15%	Operational reasonableness of the largest valid event.
Configuration Safety	10%	Whether `TRUNCATE` is measured, justified and bounded.

Truncation Risk — 35

0 events: 35; <0.1%: 30; 0.1–1%: 22; >1–5%: 12; >5%: 0.

Boundary Integrity — 25

All valid: 25; minor uncertainty: 18; some incorrect merging: 10; large-scale merging: 0.

Size Consistency — 15

P95 ÷ median: ≤3 = 15; >3–6 = 12; >6–10 = 8; >10–20 = 4; >20 = 0.

Maximum Event Suitability — 15

≤10 KB = 15; >10–50 KB = 12; >50–250 KB = 8; >250 KB–1 MB = 4; >1 MB = 0.

Configuration Safety — 10

Measured plus justified margin = 10; validated default = 8; high but bounded = 5; TRUNCATE=0 justified = 4; unjustified = 0.

Line Length Quality Score = Truncation Risk + Event Boundary Integrity + Size Consistency + Maximum Event Suitability + Configuration Safety

Score	Rating
90–100	Exceptional
75–89	Good
60–74	Fair
40–59	Poor
0–39	Fail

Worked example

Events analysed: 100,000
Configured TRUNCATE: 10,000 bytes
Events over TRUNCATE: 320
Median: 1,100 bytes
P95: 5,500 bytes
Maximum valid event: 18,420 bytes

Score: 71/100 — Fair

[example:sourcetype]
TRUNCATE = 25000

Calculator

Total eventsEvents above TRUNCATEMedian bytesP95 bytesMaximum valid bytesBoundary integrityConfiguration safety

TRUNCATE guidance

[example:large_json]
SHOULD_LINEMERGE = false
LINE_BREAKER = ([\r\n]+)
TRUNCATE = 50000

TRUNCATE = 0 disables truncation and should only be used with documented justification and testing. TRUNCATE = 999999 is a safer middle ground for the same intent: effectively unbounded for any realistic event, but still a finite limit, so Splunk won't hang indefinitely waiting for an event that never ends if the line breaker is lost on a corrupted or malicious file.

Check incorrect event merging before increasing the limit.
Measure UTF-8 bytes, not only characters.
Use a bounded value where practical.
Record the safety margin and test representative large events.

Finding your TRUNCATE value

Run this against a representative sample (two days' worth is often enough) to find the largest real event size, then apply a margin before setting TRUNCATE:

index="test" sourcetype="<your new sourcetype name>"
| eval event_size=len(_raw)
| stats max(event_size) as max_event_size
| eval "Recommended TRUNCATE Value"=(max_event_size * 1.10)
| fields - max_event_size

This measures characters via len(_raw), not UTF-8 bytes -- for multi-byte character sets, prefer a byte-accurate measurement (see Encoding & character set detection) before finalising the value.

← Back to References

References / Splunk sourcetype definition

Log Format Detection & Parsing

Defines how Splunk interprets the structural format of an event and makes fields available after line breaking and timestamp parsing.

Definition

The Log Format Detection & Parsing record documents the detected structure, extraction strategy, and effective props.conf and optional transforms.conf settings for a sourcetype.

Format matrix

Format	Typical approach	Key checks
CSV	`INDEXED_EXTRACTIONS = CSV`	Delimiter, quotes, headers, embedded commas.
TSV	`INDEXED_EXTRACTIONS = TSV`	Tabs, empty columns, trailing fields.
JSON	Indexed or search-time JSON extraction depending on collection path.	Nested arrays, duplicate keys, HEC metadata, double extraction.
XML	`KV_MODE = xml` at search time.	Namespaces, repeated nodes, multiline records.
Structured	`KV_MODE = auto` or explicit search-time extraction.	Quotes, escapes, duplicate keys.
Semi-structured	`REPORT-` or `EXTRACT-`.	Schema drift, optional labels, inconsistent syntax.
Unstructured	Targeted regex only.	False positives and maintenance cost.
Mixed	Separate sourcetypes or preprocess.	Conflicting schemas and unsafe universal parsing.

Key-value pair styles

Key-value formatted logs vary along two independent axes: the separator between a key and its value (key=value vs key: value), and the delimiter between pairs (space/logfmt-style, comma, or semicolon). This matters for Splunk config because KV_MODE = auto only extracts key=value pairs by default -- it does not extract key: value style pairs, which need an explicit EXTRACT statement instead. All six styles below funnel into the same "key-value formatted logs" classification; only the field-extraction guidance differs.

Detection logic. Separator is whichever of = or : (followed by whitespace) has more matches on the first line. Delimiter between pairs is inferred by checking, in order, for a comma, then a semicolon, then falling back to plain whitespace. Colon-style pairs require 2 or more pairs on the first line before being classified as key-value, so a single "Error: message" free-text line is not misread as key-value.

Style	Example	Separator	Delimiter	Extracted fields	Splunk config	Notes
Space-separated key=value (logfmt-style)	`time=2026-07-09T14:30:45Z level=info user=jsmith msg="user logged in"`	= (key=value)	Space-separated (logfmt-style)	time, level, user, msg	`KV_MODE = auto`	Covers most key=value pairs, including quoted values. For high-volume sourcetypes, replace with explicit EXTRACT statements per required field for better search performance (e.g. EXTRACT-level = level=(?<level>"[^"]*"\|\S+)); disable KV_MODE once every required field has its own EXTRACT, to avoid double extraction.
Comma-separated key=value	`user=jsmith, action=login, result=success`	= (key=value)	Comma-separated	user, action, result	`KV_MODE = auto`	Covers most key=value pairs, including quoted values. For high-volume sourcetypes, replace with explicit EXTRACT statements per required field for better search performance (e.g. EXTRACT-action = action=(?<action>"[^"]*"\|\S+)); disable KV_MODE once every required field has its own EXTRACT, to avoid double extraction.
Semicolon-separated key=value	`user=jsmith; action=login; result=success`	= (key=value)	Semicolon-separated	user, action, result	`KV_MODE = auto`	Covers most key=value pairs, including quoted values. For high-volume sourcetypes, replace with explicit EXTRACT statements per required field for better search performance (e.g. EXTRACT-action = action=(?<action>"[^"]*"\|\S+)); disable KV_MODE once every required field has its own EXTRACT, to avoid double extraction.
Space-separated key: value	`level: info user: jsmith action: login`	: (key: value)	Space-separated	level, user, action	`EXTRACT-action = action:\s+(?<action>"[^"]*"\|\S+)`	KV_MODE = auto only extracts key=value pairs by default and will not extract "action: value" style pairs -- use explicit EXTRACT statements per field instead. Repeat the pattern (distinct stanza name per field) for every required field, or write one REPORT-based transform with multiple named groups if the field order is stable.
Comma-separated key: value	`level: info, user: jsmith, action: login, result: success`	: (key: value)	Comma-separated	level, user, action, result	`EXTRACT-action = action:\s+(?<action>"[^"]*"\|\S+)`	KV_MODE = auto only extracts key=value pairs by default and will not extract "action: value" style pairs -- use explicit EXTRACT statements per field instead. Repeat the pattern (distinct stanza name per field) for every required field, or write one REPORT-based transform with multiple named groups if the field order is stable.
Semicolon-separated key: value	`level: info; user: jsmith; action: login`	: (key: value)	Semicolon-separated	level, user, action	`EXTRACT-action = action:\s+(?<action>"[^"]*"\|\S+)`	KV_MODE = auto only extracts key=value pairs by default and will not extract "action: value" style pairs -- use explicit EXTRACT statements per field instead. Repeat the pattern (distinct stanza name per field) for every required field, or write one REPORT-based transform with multiple named groups if the field order is stable.

Known limitation. Pipe-separated key=value pairs (e.g. user=jsmith|action=login) are intentionally not offered as a distinct style. The underlying value regex is shared with CEF extension-field parsing, which can legitimately contain pipe characters in a value, so narrowing it to stop at | would risk breaking CEF field extraction. A pipe-delimited sample is still detected as key-value formatted logs, but only the first pair is extracted reliably today.

Encoding & character set detection

Byte encoding sits ahead of line breaking, timestamp parsing and field extraction in the assessment sequence -- a file must be decoded to the right text before any of those can be evaluated meaningfully. Detection has two layers: a byte order mark (BOM), when present, gives an unambiguous signal at the start of the file; when no BOM is present, detection falls back to heuristics (byte-pattern and frequency analysis) that are probabilistic rather than certain, so an explicit, documented CHARSET is always preferable to relying on auto-detection once the true encoding is known.

Detection logic. Splunk's CHARSET setting is scoped per stanza under [<sourcetype>] or [source::<spec>] in props.conf (not [host::<spec>]). Its default is AUTO on Windows and UTF-8 on other platforms; AUTO auto-detects the source encoding (BOM sniffing plus heuristics) and transcodes to UTF-8 before indexing. Only encodings with a UTF-8 mapping are recognised -- any value listed by iconv -l on the indexer or forwarder doing the parsing -- and matching against the configured value is case- and punctuation-insensitive, so utf8, UTF-8 and utf_8 are all treated the same.

Byte order mark (BOM) signatures

Encoding	BOM (hex)	Splunk CHARSET	Notes
UTF-8	`EF BB BF`	`UTF-8`	Optional and not required for valid UTF-8; some tools (older Windows editors, some CSV exporters) add it, which can otherwise leak into the first field of the first event as a stray prefix.
UTF-16BE	`FE FF`	`UTF-16BE`	Big-endian 16-bit code units; rare from Unix/Linux sources, more common from mainframe or cross-platform export tooling.
UTF-16LE	`FF FE`	`UTF-16LE`	Native Windows wide-char encoding (e.g. PowerShell `Out-File` default, some Windows Event Log exports); the most commonly seen non-UTF-8 BOM in Windows-sourced logs.
UTF-32BE	`00 00 FE FF`	`UTF-32BE`	Rare in log data; mostly seen from tooling that defaults to UTF-32 for internal processing.
UTF-32LE	`FF FE 00 00`	`UTF-32LE`	Its first two bytes are identical to the UTF-16LE BOM followed by a null character -- check for the longer 4-byte pattern before falling back to the 2-byte UTF-16LE match, or UTF-32LE files will be misdetected.

Common non-UTF-8 encodings (no BOM)

Encoding	Typical source	Splunk CHARSET	Notes
Windows-1252 (CP1252)	Windows application logs, CSV exports from Windows tools	`windows-1252`	Superset of ISO-8859-1 that fills the 0x80-0x9F control range with printable characters (smart quotes, em-dash); a common source of mojibake when misread as Latin-1.
ISO-8859-1 (Latin-1)	Legacy Unix tooling, older network device logs	`ISO-8859-1`	Every byte value 0x00-0xFF maps to a character, so decoding never fails outright -- this makes it a poor signal for auto-detection and a likely false-positive fallback when the real encoding is something else.
ISO-8859-15	Western European sources needing the Euro sign	`ISO-8859-15`	Same layout as Latin-1 except several rarely used symbol positions are replaced, including €.
ISO-8859-7	Greek-language systems	`ISO-8859-7`	Splunk's own documented `CHARSET` worked example.
Shift-JIS	Japanese vendor appliances, legacy Japanese applications	`SHIFT-JIS`	Variable-width; single-byte and two-byte characters coexist, so naive byte-level truncation can split a multi-byte character.
GB18030	Chinese-market software (mandated encoding for PRC-market products)	`GB18030`	Superset of GBK/GB2312; ASCII-compatible for single-byte code points, variable-width above that.
KOI8-R	Legacy Russian Unix systems	`KOI8-R`	Single-byte Cyrillic encoding, still seen on older Russian-language infrastructure.
EBCDIC (e.g. IBM037)	Mainframe systems (z/OS, IBM i)	`IBM037` (or the applicable EBCDIC code page)	Not ASCII-compatible -- byte values that look like printable ASCII map to different characters entirely, so misdetected EBCDIC does not fail to parse, it silently produces garbage text instead of an error.

Known limitation. When a source's encoding is already known, prefer an explicit CHARSET over AUTO -- this is especially true for BOM-prefixed UTF-16LE sources, where the BOM bytes have been reported to leak into the first field of the first event instead of being stripped. Pair an explicit CHARSET with PREAMBLE_REGEX to strip leading BOM bytes from the raw stream if they are still visible in indexed events.

Example sourcetype definitions

CSV

[example:csv]
SHOULD_LINEMERGE = false
LINE_BREAKER = ([\r\n]+)
INDEXED_EXTRACTIONS = CSV
FIELD_DELIMITER = ,
FIELD_QUOTE = "
HEADER_FIELD_LINE_NUMBER = 1
TIMESTAMP_FIELDS = event_time

TSV

[example:tsv]
SHOULD_LINEMERGE = false
LINE_BREAKER = ([\r\n]+)
INDEXED_EXTRACTIONS = TSV
HEADER_FIELD_LINE_NUMBER = 1
TIMESTAMP_FIELDS = event_time

JSON

[example:json]
SHOULD_LINEMERGE = false
LINE_BREAKER = ([\r\n]+)
INDEXED_EXTRACTIONS = JSON
KV_MODE = none
TIMESTAMP_FIELDS = event_time

For HEC or another collector that already supplies structured metadata, omit settings that would duplicate extraction.

XML

[example:xml]
SHOULD_LINEMERGE = false
LINE_BREAKER = ([\r\n]+)(?=<event(?:\s|>))
KV_MODE = xml

Structured key-value

[example:key_value]
SHOULD_LINEMERGE = false
LINE_BREAKER = ([\r\n]+)
KV_MODE = auto

Semi-structured

[example:semi_structured]
SHOULD_LINEMERGE = false
LINE_BREAKER = ([\r\n]+)
KV_MODE = none
REPORT-fields = extract_example_fields

transforms.conf

[extract_example_fields]
REGEX = (\w+)=("[^"]*"|\S+)
FORMAT = $1::$2
MV_ADD = true

Validation

Separate format detection from format quality scoring.
Prefer search-time extraction unless indexed extraction is justified.
Do not mix incompatible formats in one sourcetype.
Test quoting, escaping, duplicate keys, headers, nested content and schema drift.
Validate line breaking and timestamp parsing first.
Record omitted settings and rationale.

← Back to References

References / Splunk sourcetype definition

Line Break

Line Break defines how Splunk separates the incoming data stream into individual logical events before timestamp recognition and field extraction.

Definition

The Line Break record belongs to the Splunk sourcetype definition and documents the effective index-time settings used to divide a raw stream into logical events. Correct boundaries are required before timestamp parsing, field extraction, event counting and detection logic can be trusted.

Splunk line-breaking settings

Setting	Scope	Definition
`SHOULD_LINEMERGE`	Indexer (parsing)	Controls whether Splunk attempts to merge multiple physical lines into a single logical event. A value of `false` is preferred when event boundaries can be expressed explicitly with `LINE_BREAKER`.
`LINE_BREAKER`	Indexer (parsing)	A regular expression defining the separator between events. The text matched by the first capturing group is discarded at the split point.
`EVENT_BREAKER_ENABLE`	Universal Forwarder only	Enables the lightweight `ChunkedLBProcessor` on a Universal Forwarder so it breaks the byte stream into events before forwarding, distributing events more evenly across multiple indexers instead of load-balancing whole raw chunks. Default `false`; only valid on Universal Forwarder instances -- indexers and Heavy Forwarders ignore it.
`EVENT_BREAKER`	Universal Forwarder only	The regular expression a Universal Forwarder uses to find event boundaries when `EVENT_BREAKER_ENABLE = true`. Default is empty. Must match the same pattern as the indexer-side `LINE_BREAKER` for the sourcetype -- if the indexer doesn't set `LINE_BREAKER`, `EVENT_BREAKER` isn't required either.

Relationship to LINE_BREAKER. EVENT_BREAKER doesn't replace LINE_BREAKER -- it solves a different problem, even distribution of events across the indexer tier from a Universal Forwarder, and only applies there. The indexer still performs its own LINE_BREAKER-based event breaking during parsing; keeping the two regexes in sync avoids the forwarder and indexer disagreeing about where one event ends and the next begins.

Examples

One complete event per physical line

[replace_with_sourcetype]
SHOULD_LINEMERGE = false
LINE_BREAKER = ([\r\n]+)

Use this baseline only when each physical line is independently complete.

Multiline events beginning with a timestamp

[replace_with_sourcetype]
SHOULD_LINEMERGE = false
LINE_BREAKER = ([\r\n]+)(?=\d{4}-\d{2}-\d{2}\s+\d{2}:\d{2}:\d{2})

The newline separator is removed while the timestamp remains at the start of the next event. Indented continuation lines remain attached to the preceding event.

Universal Forwarder event breaking (EVENT_BREAKER)

# Indexer-side props.conf:
[replace_with_sourcetype]
SHOULD_LINEMERGE = false
LINE_BREAKER = ([\r\n]+)(?=\d{4}-\d{2}-\d{2}\s+\d{2}:\d{2}:\d{2})

# Universal Forwarder-side props.conf:
[replace_with_sourcetype]
EVENT_BREAKER_ENABLE = true
EVENT_BREAKER = ([\r\n]+)(?=\d{4}-\d{2}-\d{2}\s+\d{2}:\d{2}:\d{2})

Only add EVENT_BREAKER when a high-volume sourcetype is forwarded through Universal Forwarders and events are landing unevenly across the indexer tier. Keep its regex identical to the indexer's LINE_BREAKER for the same sourcetype.

Implementation and validation notes

Verify whether one physical line equals one logical event before using a generic newline breaker.
Preserve continuation lines, stack traces, wrapped messages and pretty-printed structured content.
Test Windows \r\n, Unix \n and any legacy \r endings present in the source.
Confirm expected event counts and inspect the first and last characters of adjacent events.
Ensure the first capture group removes only the separator and does not consume useful event content.
Use separate sourcetypes when one stream contains incompatible boundary patterns.
For high-volume sourcetypes forwarded through Universal Forwarders, confirm EVENT_BREAKER (when enabled) matches LINE_BREAKER exactly -- a mismatch causes the forwarder and indexer to disagree about event boundaries.

← Back to References

References / Datetime reference

Datetime Format

Datetime Format records how event time is represented in the raw source data. It describes the source timestamp itself before Splunk parsing rules are applied.

Definition

A Datetime Format is the literal timestamp representation emitted by the source system. Record the exact value as observed, the recognised standard or vendor-specific format, precision, timezone handling and the equivalent Splunk strptime expression.

Required details

Attribute	Description
Raw timestamp example	An exact timestamp copied from the source event.
Format name	ISO 8601, IETF RFC 3339, IETF RFC 2822, Unix epoch, Windows File Time, vendor-defined or another recognised representation.
Precision	Seconds, milliseconds, microseconds, nanoseconds or another supported resolution.
Timezone expression	UTC marker, numeric offset, named zone, abbreviation or no timezone present.
Splunk pattern	The corresponding `strptime` pattern used in `TIME_FORMAT`.

Examples

Raw example	Format	Splunk pattern
`2026-07-21T08:00:11.902+10:00`	ISO 8601 / IETF RFC 3339 with milliseconds and offset	`%Y-%m-%dT%H:%M:%S.%3N%:z`
`2026-07-21 08:00:11`	Calendar datetime without timezone	`%Y-%m-%d %H:%M:%S`
`1773040800123`	Unix epoch milliseconds	Use epoch-aware parsing or preprocessing appropriate to the input.

Format catalogue

78 named formats across 15 categories, spanning ISO 8601/IETF RFC 3339 variants, internet-message and web-server/proxy conventions, syslog and system logs, Unix epoch variants, database defaults, language/framework defaults, human-readable/locale formats, compact/sortable forms, non-standard ISO 8601-style variants, and several platform-specific formats (Windows Event Log XML, Oracle DB default, vendor timestamps with a timezone abbreviation). Use this as a lookup when documenting a source's Datetime Format -- match the raw example, take the Splunk TIME_FORMAT pattern as a starting point, and confirm it against representative events before recording it on the Datetime Parse record.

ISO 8601 / IETF RFC 3339 (12)

Format	Example	Splunk TIME_FORMAT	Notes
Basic UTC (Zulu)	`2026-07-09T14:30:45Z`	`%Y-%m-%dT%H:%M:%SZ`	Timezone/UTC context is present; confirm precision and UTC normalisation.
With numeric offset	`2026-07-09T14:30:45+00:00`	`%Y-%m-%dT%H:%M:%S%:z`	Confirm parser supports the colon-separated offset (GNU %:z); abbreviated zone names elsewhere can be ambiguous.
Milliseconds	`2026-07-09T14:30:45.123Z`	`%Y-%m-%dT%H:%M:%S.%QZ`	strptime has no native ms field; framework-formatted. Good candidate when mapped to event time and normalised to UTC.
Microseconds	`2026-07-09T14:30:45.123456Z`	`%Y-%m-%dT%H:%M:%S.%fZ (Python %f = 6 digits)`	Good candidate when mapped to event time and normalised to UTC.
Nanoseconds	`2026-07-09T14:30:45.123456789Z`	`%Y-%m-%dT%H:%M:%S.%QZ`	Framework-specific (e.g. Go IETF RFC3339Nano). Good candidate when mapped to event time and normalised to UTC.
Space separator (IETF RFC 3339 §5.6)	`2026-07-09 14:30:45Z`	`%Y-%m-%d %H:%M:%SZ`	Timezone/UTC context is present; confirm precision and UTC normalisation.
Comma decimal sign	`2026-07-09T14:30:45,123Z`	`%Y-%m-%dT%H:%M:%S,%QZ`	ISO 8601 permits ',' as the decimal sign. Good candidate when mapped to event time and normalised to UTC.
Basic / compact (no delimiters)	`20260709T143045Z`	`%Y%m%dT%H%M%SZ`	Timezone/UTC context is present; confirm precision and UTC normalisation.
Date only	`2026-07-09`	`%Y-%m-%d`	Not suitable as the primary event timestamp unless combined with a reliable event time source.
Time only	`14:30:45.123`	`%H:%M:%S.%Q`	Not suitable as the primary event timestamp unless combined with a reliable event date source.
Week date	`2026-W28-4`	`%G-W%V-%u`	Not suitable as the primary event timestamp unless combined with a reliable event time source.
Ordinal (day-of-year) date	`2026-190`	`%Y-%j`	Not suitable as the primary event timestamp unless combined with a reliable event time source.

Internet message / RFC (5)

Format	Example	Splunk TIME_FORMAT	Notes
IETF RFC 5322 / 2822 (email)	`Thu, 09 Jul 2026 14:30:45 +0000`	`%a, %d %b %Y %H:%M:%S %z`	Confirm parser support and UTC normalisation.
IETF RFC 1123 (HTTP date)	`Thu, 09 Jul 2026 14:30:45 GMT`	`%a, %d %b %Y %H:%M:%S GMT`	Timezone/UTC context is present; confirm precision and UTC normalisation.
IETF RFC 822 (2-digit year)	`Thu, 09 Jul 26 14:30:45 +0000`	`%a, %d %b %y %H:%M:%S %z`	2-digit year; confirm windowing rule and UTC normalisation.
IETF RFC 850 (obsolete HTTP)	`Thursday, 09-Jul-26 14:30:45 GMT`	`%A, %d-%b-%y %H:%M:%S GMT`	Obsolete but still seen; 2-digit year.
ANSI C asctime()	`Thu Jul 9 14:30:45 2026`	`%a %b %e %H:%M:%S %Y`	No timezone; document source timezone separately.

Web server & proxy (7)

Format	Example	Splunk TIME_FORMAT	Notes
Apache Common Log Format	`09/Jul/2026:14:30:45 +0000`	`%d/%b/%Y:%H:%M:%S %z`	Timezone context present; confirm parser support and UTC normalisation.
Apache error log	`[Thu Jul 09 14:30:45.123456 2026]`	`[%a %b %d %H:%M:%S.%Q %Y]`	Bracketed, microsecond precision; source timezone must be documented separately.
Nginx access (default)	`09/Jul/2026:14:30:45 +0000`	`%d/%b/%Y:%H:%M:%S %z`	Same as Apache Common Log Format.
Nginx error log	`2026/07/09 14:30:45`	`%Y/%m/%d %H:%M:%S`	No timezone; document source timezone and parsing assumptions.
IIS W3C Extended	`2026-07-09 14:30:45`	`%Y-%m-%d %H:%M:%S`	Date and time in two separate fields; no timezone -- document assumptions.
HAProxy	`09/Jul/2026:14:30:45.123`	`%d/%b/%Y:%H:%M:%S.%Q`	Common Log Format plus milliseconds; source timezone must be documented separately.
Traefik / common JSON	`2026-07-09T14:30:45Z`	`IETF RFC 3339`	Timezone/UTC context present; confirm precision and UTC normalisation.

Syslog & system (7)

Format	Example	Splunk TIME_FORMAT	Notes
IETF RFC 3164 (BSD syslog)	`Jul 9 14:30:45`	`%b %e %H:%M:%S`	No year; timezone/UTC context assumed from platform, confirm precision and normalisation.
IETF RFC 5424 (modern syslog)	`2026-07-09T14:30:45.123456Z`	`%Y-%m-%dT%H:%M:%S.%QZ`	Full IETF RFC 3339; good candidate when mapped to event time and normalised to UTC.
systemd journal (short)	`Jul 09 14:30:45`	`%b %d %H:%M:%S`	No timezone; document source timezone and parsing assumptions.
systemd (short-iso)	`2026-07-09T14:30:45+0000`	`%Y-%m-%dT%H:%M:%S%z`	ISO 8601; timezone/UTC context present, confirm precision and normalisation.
systemd (short-precise)	`Jul 09 14:30:45.123456`	`%b %d %H:%M:%S.%Q`	Microsecond precision; source timezone must be documented separately.
dmesg (kernel, uptime)	`[ 1234.567890]`	`Custom uptime conversion required`	Seconds since boot, not wall clock -- not suitable as the primary event timestamp unless combined with a reliable event time source.
Windows Event Log	`7/9/2026 2:30:45 PM`	`%m/%d/%Y %I:%M:%S %p`	Locale-dependent; parseable only when locale, timezone and day/month ordering are documented and tested.

Unix epoch (7)

Format	Example	Splunk TIME_FORMAT	Notes
Seconds	`1783607445`	`%s`	Seconds since 1970-01-01 UTC; timezone/UTC context present, confirm precision and normalisation.
Milliseconds	`1783607445123`	`%s%Q`	Milliseconds since Unix epoch. Good candidate when mapped to event time and normalised to UTC.
Microseconds	`1783607445123456`	`Custom epoch microsecond conversion`	Good candidate when mapped to event time and normalised to UTC.
Nanoseconds	`1783607445123456000`	`ns since Unix epoch (micros-precision instant)`	Good candidate when mapped to event time and normalised to UTC.
Float seconds	`1783607445.123`	`%s.%Q`	Seconds.fraction. Good candidate when mapped to event time and normalised to UTC.
Windows FILETIME	`134280810451234560`	`Custom conversion required`	100-ns ticks since 1601-01-01 UTC; requires conversion before normal SIEM event-time parsing, confirm UTC mapping after conversion.
.NET DateTime.Ticks	`639192042451234560`	`Custom .NET ticks conversion`	100-ns ticks since 0001-01-01; requires conversion before normal SIEM event-time parsing, confirm UTC mapping after conversion.

Database (7)

Format	Example	Splunk TIME_FORMAT	Notes
MySQL DATETIME	`2026-07-09 14:30:45`	`%Y-%m-%d %H:%M:%S`	Second precision, no timezone; document source timezone and parsing assumptions.
MySQL DATETIME(6)	`2026-07-09 14:30:45.123456`	`%Y-%m-%d %H:%M:%S.%Q`	Microsecond precision; source timezone must be documented separately.
PostgreSQL timestamptz	`2026-07-09 14:30:45.123456+00`	`micros + offset`	Good candidate when mapped to event time and normalised to UTC.
SQL Server datetime2	`2026-07-09 14:30:45.1234567`	`%Y-%m-%d %H:%M:%S.%Q`	100-ns precision; source timezone must be documented separately.
Oracle TIMESTAMP	`09-JUL-26 02.30.45.123456 PM`	`%d-%b-%y %I.%M.%S.%Q %p`	Default NLS format; source timezone must be documented separately.
SQLite (text)	`2026-07-09 14:30:45`	`%Y-%m-%d %H:%M:%S`	Stored as ISO string, no timezone; document source timezone and parsing assumptions.
MongoDB ISODate	`2026-07-09T14:30:45.123Z`	`%Y-%m-%dT%H:%M:%S.%QZ`	BSON millisecond. Good candidate when mapped to event time and normalised to UTC.

Language / framework (12)

Format	Example	Splunk TIME_FORMAT	Notes
Python logging default	`2026-07-09 14:30:45,123`	`%Y-%m-%d %H:%M:%S,%Q`	Comma before ms; source timezone must be documented separately.
Python asctime()	`Thu Jul 9 14:30:45 2026`	`%a %b %e %H:%M:%S %Y`	No timezone; document source timezone and parsing assumptions.
Java Log4j / Logback default	`2026-07-09 14:30:45,123`	`%Y-%m-%d %H:%M:%S,%Q`	Comma before ms; source timezone must be documented separately.
Java Date.toString()	`Thu Jul 09 14:30:45 UTC 2026`	`%a %b %d %H:%M:%S %Z %Y`	Includes zone name; timezone/UTC context present, confirm precision and normalisation.
Go time.String()	`2026-07-09 14:30:45.123456789 +0000 UTC`	`%Y-%m-%d %H:%M:%S.%Q %z %Z`	Default String(); confirm parser support and UTC normalisation.
Go IETF RFC3339Nano	`2026-07-09T14:30:45.123456789Z`	`%Y-%m-%dT%H:%M:%S.%QZ`	Layout constant. Good candidate when mapped to event time and normalised to UTC.
JavaScript toISOString()	`2026-07-09T14:30:45.123Z`	`%Y-%m-%dT%H:%M:%S.%QZ`	Always UTC, ms precision. Good candidate when mapped to event time and normalised to UTC.
JavaScript toUTCString()	`Thu, 09 Jul 2026 14:30:45 GMT`	`%a, %d %b %Y %H:%M:%S GMT`	IETF RFC 1123 style; timezone/UTC context present, confirm precision and normalisation.
Rust chrono IETF RFC 3339	`2026-07-09T14:30:45.123456789+00:00`	`%Y-%m-%dT%H:%M:%S.%Q%:z`	to_rfc3339(). Good candidate when mapped to event time and normalised to UTC.
Ruby Time#to_s	`2026-07-09 14:30:45 +0000`	`%Y-%m-%d %H:%M:%S %z`	Default to_s; timezone/UTC context present, confirm precision and normalisation.
Rails log tag	`2026-07-09T14:30:45.123456Z`	`%Y-%m-%dT%H:%M:%S.%QZ`	Tagged logger. Good candidate when mapped to event time and normalised to UTC.
.NET "o" round-trip	`2026-07-09T14:30:45.1234560Z`	`%Y-%m-%dT%H:%M:%S.%QZ`	Round-trip specifier. Good candidate when mapped to event time and normalised to UTC.

Human-readable / locale (6)

Format	Example	Splunk TIME_FORMAT	Notes
US 12-hour	`07/09/2026 02:30:45 PM`	`%m/%d/%Y %I:%M:%S %p`	Parseable only when locale, timezone and day/month ordering are documented and tested.
US medium	`Jul 9, 2026 2:30:45 PM`	`%b %-d, %Y %-I:%M:%S %p`	Parseable only when locale, timezone and day/month ordering are documented and tested.
US long	`Thursday, July 9, 2026 at 2:30:45 PM`	`%A, %B %-d, %Y at %-I:%M:%S %p`	Parseable only when locale, timezone and day/month ordering are documented and tested.
European (DMY)	`09/07/2026 14:30:45`	`%d/%m/%Y %H:%M:%S`	Parseable only when locale, timezone and day/month ordering are documented and tested -- classic collision with US 12-hour.
German (dotted)	`09.07.2026 14:30:45`	`%d.%m.%Y %H:%M:%S`	Parseable only when locale, timezone and day/month ordering are documented and tested.
RFC-ish readable	`Thu 09 Jul 2026 14:30:45`	`%a %d %b %Y %H:%M:%S`	Parseable only when locale, timezone and day/month ordering are documented and tested.

Compact / sortable (5)

Format	Example	Splunk TIME_FORMAT	Notes
Compact timestamp	`20260709143045`	`%Y%m%d%H%M%S`	No timezone; document source timezone and parsing assumptions.
Compact + millis	`20260709143045123`	`%Y%m%d%H%M%S + ms`	No timezone; document source timezone and parsing assumptions.
Date-only compact	`20260709`	`%Y%m%d`	No timezone; document source timezone and parsing assumptions.
Reverse (log-file suffix)	`2026-07-09_14-30-45`	`%Y-%m-%d_%H-%M-%S`	No timezone; document source timezone and parsing assumptions.
Julian-style (YYDDD)	`26190`	`%y%j`	Not suitable as the primary event timestamp unless combined with a reliable event time source.

ISO 8601-style (non-standard) (5)

Format	Example	Splunk TIME_FORMAT	Notes
Space sep + zone in parens	`2026-07-09 14:30:45 (UTC)`	`%Y-%m-%d %H:%M:%S (%Z)`	Not IETF RFC 3339; zone is an abbreviation (e.g. (AEST)), which is region-ambiguous outside UTC/GMT.
Space sep + bare zone name	`2026-07-09 14:30:45 UTC`	`%Y-%m-%d %H:%M:%S %Z`	Abbreviated zone names are region-ambiguous (e.g. AEST); confirm parser support and UTC normalisation.
Space sep + zone in brackets	`2026-07-09 14:30:45 [UTC]`	`%Y-%m-%d %H:%M:%S [%Z]`	Non-standard bracketed zone; confirm parser support and UTC normalisation.
Space sep + ms + zone in parens	`2026-07-09 14:30:45.123 (UTC)`	`%Y-%m-%d %H:%M:%S.%3N (%Z)`	%3N=ms, %6N=micros, %9N=ns; confirm parser support and UTC normalisation.
Space sep + offset in parens	`2026-07-09 14:30:45 (+00:00)`	`%Y-%m-%d %H:%M:%S (%:z)`	Drop the parens for IETF RFC 3339 (space form); confirm parser support and UTC normalisation.

ISO 8601 (Extended) (1)

Format	Example	Splunk TIME_FORMAT	Notes
Offset with milliseconds	`2026-07-09T07:20:00.123+10:00`	`%Y-%m-%dT%H:%M:%S.%Q%:z`	Modern API/cloud timestamp with explicit UTC offset; preferred when the offset is parsed and normalised to UTC, has millisecond precision.

ISO 8601 (Basic / Compact) (1)

Format	Example	Splunk TIME_FORMAT	Notes
Offset with milliseconds	`20260709T072000.123+1000`	`%Y%m%dT%H%M%S.%Q%z`	Compact ISO 8601 with offset and milliseconds; acceptable if documented and parsed reliably, confirm UTC normalisation.

Windows Event Log XML SystemTime (1)

Format	Example	Splunk TIME_FORMAT	Notes
SystemTime	`2026-07-09T07:20:00.1230000Z`	`%Y-%m-%dT%H:%M:%S.%QZ`	Preferred over local Event Viewer display when available and mapped as event occurrence time.

Oracle DB Default (DD-MON-RR) with offset (1)

Format	Example	Splunk TIME_FORMAT	Notes
Default with offset	`09-JUL-26 07.20.00.123000 AM +10:00`	`%d-%b-%y %I.%M.%S.%Q %p %:z`	Offset and sub-second precision are present; confirm two-digit year handling and UTC conversion.

Vendor-specific timestamp with timezone abbreviation (1)

Format	Example	Splunk TIME_FORMAT	Notes
Vendor/platform/application	`Thu Jul 09 07:20:00 AEST 2026`	`%a %b %d %H:%M:%S %Z %Y`	Acceptable only if reliable, documented and tested; timezone abbreviations can be ambiguous.

Relationship to Splunk parsing

Datetime Format documents what the source emits. Datetime Parse documents how the associated Splunk sourcetype is configured to find and interpret that value. One format may require different parsing rules depending on its position within the raw event.

← Back to References

References / Splunk sourcetype definition

Datetime Parse

Datetime Parse is the Splunk timestamp definition associated with a sourcetype. It records how Splunk locates the timestamp, interprets its structure, limits the search window and assigns timezone context.

Definition

The Datetime Parse record belongs to the Splunk sourcetype definition and should reflect the effective parsing configuration used at index time. Record the deployed values and the raw event evidence used to validate them.

Splunk timestamp parsing settings

Setting	Definition
`TIME_PREFIX`	A regular expression identifying text just before the timestamp. This limits where Splunk searches for the date.
`TIME_FORMAT`	The pattern of the date using `strptime` syntax, for example `%Y-%m-%d %H:%M:%S`.
`MAX_TIMESTAMP_LOOKAHEAD`	The number of characters after `TIME_PREFIX` that Splunk evaluates to find the date. The default is typically 128 bytes.
`TZ`	The time zone of the incoming logs, for example `Australia/Sydney`, when it differs from the indexer's local time or when the raw timestamp does not carry an explicit zone.

Example sourcetype definition

[ibm:cognos:login]
TIME_PREFIX = ^
TIME_FORMAT = %Y-%m-%dT%H:%M:%S.%3N%:z
MAX_TIMESTAMP_LOOKAHEAD = 29
TZ = Australia/Sydney

Where the timestamp already includes an explicit UTC offset, TZ should not override that event-provided offset. Retain TZ only where required for timestamps without embedded timezone information.

Implementation notes

Calculate MAX_TIMESTAMP_LOOKAHEAD from the timestamp position and maximum timestamp length rather than leaving an unnecessarily broad search range.
Escape TIME_PREFIX as a valid regular expression and ensure it identifies the timestamp location without consuming the timestamp itself.
Validate parsing against representative normal, error, multiline and boundary events.
Confirm that Splunk _time matches the source event time and is not silently derived from receipt or index time.

← Back to References

References / Identity reference

Username / Principal Format

Catalogues how identity values appear across sources -- SAML NameIDs, cloud IAM identifiers, internet/messaging URIs, Windows/AD and Entra forms, database and directory identifiers, Kerberos principals, social/fediverse handles and generic opaque IDs -- so a raw username-shaped field can be classified and normalised consistently.

Definition

A Username / Principal Format record documents how an identity value is represented in the raw source event -- the recognised standard or protocol convention, the template shape, and (where the value alone is diagnostic) the regular expression used to detect it. Record the exact value as observed alongside the matched format, since several formats are genuinely indistinguishable by value alone and require source context (sourcetype, vendor, protocol) to disambiguate.

Format catalogue

37 named username/principal formats across 13 categories, spanning SAML protocol NameIDs, cloud IAM identifiers (AWS, GCP), internet/messaging URIs, consumer/phone identifiers, Windows/AD forms, Entra/Azure AD identifiers, database account strings, LDAP distinguished names, Kerberos principals, social/fediverse handles, network-auth identifiers, and generic opaque IDs. Several formats share an identical regex (UPN, Email address and NAI, for example) and genuinely cannot be told apart from the value alone -- use the source context (Splunk sourcetype, vendor, protocol) to disambiguate them, not the field format.

SAML protocol (7)

#	Format	Example	Template	Regex	Notes
1	SAML Persistent NameID	`urn:oasis:names:tc:SAML:2.0:nameid-format:persistent`	URN identifier -- value: opaque hash	`^urn:oasis:names:tc:SAML:2\.0:nameid-format:persistent$`	Matches the Format URN, not the value. Value is opaque; not recoverable from value alone.
2	SAML Email NameID	`urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress`	URN identifier -- value: user@domain.com	`^urn:oasis:names:tc:SAML:1\.1:nameid-format:emailAddress$`	Value aliases UPN / Email / NAI.
3	SAML Transient NameID	`urn:oasis:names:tc:SAML:2.0:nameid-format:transient`	URN identifier -- value: per-session string	`^urn:oasis:names:tc:SAML:2\.0:nameid-format:transient$`	Value is ephemeral/opaque; single login session.
4	SAML Unspecified NameID	`urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified`	URN identifier -- value: varies by claim	`^urn:oasis:names:tc:SAML:1\.1:nameid-format:unspecified$`	Value unconstrained by definition; cannot be detected from value.
5	SAML Windows Domain NameID	`urn:oasis:names:tc:SAML:1.1:nameid-format:WindowsDomainQualifiedName`	URN identifier -- value: DOMAIN\username	`^urn:oasis:names:tc:SAML:1\.1:nameid-format:WindowsDomainQualifiedName$`	Value aliases down-level NetBIOS.
6	SAML X509 Subject NameID	`urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName`	URN identifier -- value: CN=...,OU=... DN	`^urn:oasis:names:tc:SAML:1\.1:nameid-format:X509SubjectName$`	Value aliases LDAP DN.
7	SAML Kerberos NameID	`urn:oasis:names:tc:SAML:2.0:nameid-format:kerberos`	URN identifier -- value: username@REALM	`^urn:oasis:names:tc:SAML:2\.0:nameid-format:kerberos$`	Value aliases Kerberos user principal.

Cloud IAM (AWS) (3)

#	Format	Example	Template	Regex	Notes
8	AWS IAM ARN	`arn:aws:iam::123456789012:user/jsmith`	arn:aws:iam::account-id:user/username	`^arn:aws:iam::\d{12}:user\/[\w+=,.@\/-]+$`	Unique arn:aws:iam:: prefix; no collisions.
9	AWS STS assumed-role ARN	`arn:aws:sts::123456789012:assumed-role/Role/session`	arn:aws:sts::account-id:assumed-role/role/session	`^arn:aws:sts::\d{12}:assumed-role\/[\w+=,.@-]+\/[\w+=,.@-]+$`	Sibling of IAM ARN; sts + assumed-role.
13	AWS access key ID	`AKIAIOSFODNN7EXAMPLE`	AKIA/ASIA + 16 chars	`^(AKIA\|ASIA)[0-9A-Z]{16}$`	Credential, not a name. Case-sensitive prefix. Often pasted into programmatic login.

Internet / messaging (4)

#	Format	Example	Template	Regex	Notes
10	WebFinger acct URI	`acct:jsmith@example.com`	acct:username@domain	`^acct:[^@\s]+@[^@\s]+\.[^@\s]+$`	IETF RFC 7565; acct: scheme.
12	SIP URI	`sip:jsmith@company.com`	sip:username@domain.com	`^sips?:[^@\s]+@[^@\s\/]+\.[^@\s\/]+$`	sip: / sips: scheme.
24	XMPP / Jabber ID (JID)	`jsmith@company.com/laptop`	username@domain.com/resource	`^[^@\/\s]+@[^@\/\s]+\.[^@\/\s]+\/[^@\s]+$`	Trailing /resource distinguishes it from UPN. Resource-less JID = plain UPN.
33	Email address	`jsmith@company.com`	local-part@domain.com	`^[^@\s\\\/]+@[^@\s\\\/]+\.[^@\s\\\/]+$`	Alias of UPN / NAI.

Consumer / phone (2)

#	Format	Example	Template	Regex	Notes
11	Tel URI	`tel:+15551234567`	tel:+E.164number	`^tel:\+[1-9]\d{1,14}$`	IETF RFC 3966; tel: scheme.
26	E.164 phone number	`+15551234567`	+[country][number]	`^\+[1-9]\d{1,14}$`	Leading +, up to 15 digits.

Windows / AD (6)

#	Format	Example	Template	Regex	Notes
14	Security Identifier (SID)	`S-1-5-21-3623811015-3361044348-30300820-1013`	S-1-5-21-x-x-x-x	`^S-1-\d+(?:-\d+)+$`	For user/computer accounts tighten to ^S-1-5-21(?:-\d+){4}$.
18	Local Windows account	`.\Administrator`	.\username	`^\.\\[^\\\/@\s]+$`	Literal .\ = this machine. NOTE: MACHINE\user is NOT this -- identical to NetBIOS.
27	On-Premises UPN	`jsmith@company.local`	username@domain.local	`^[^@\s\\\/]+@[^@\s\\\/]+\.(?:local\|corp\|internal\|lan\|intranet)$`	Internal-TLD heuristic -- tune the TLD list. Otherwise identical to UPN/Email/NAI.
28	Down-level logon name (FQDN variant)	`company.com\jsmith`	domain.com\username	`^[^\\\/@\s]\.[^\\\/@\s]\\[^\\\/@\s]+$`	Backslash with a dotted left side.
29	Down-level logon name (NetBIOS)	`COMPANY\jsmith`	domain\username	`^[^\\\/@\s.]+\\[^\\\/@\s]+$`	Backslash, no-dot left side (short NetBIOS name).
37	SAMAccountName (bare)	`jsmith`	username	`^[A-Za-z0-9._-]+$`	Fallback -- matches many bare tokens. Keep numeric UID and GUID above it.

Entra / Azure AD (4)

#	Format	Example	Template	Regex	Notes
15	Object ID (GUID)	`a1b2c3d4-e5f6-7a8b-9c0d-1e2f3a4b5c6d`	8-4-4-4-12 hex digits	`^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$`	Case-agnostic on its own. Also covers on-prem objectGUID.
16	B2B guest (external)	`jsmith_partner.com#EXT#@company.onmicrosoft.com`	user_extdomain.com#EXT#@tenant.onmicrosoft.com	`^[^@\s]+#EXT#@[^@\s]+\.onmicrosoft\.com$`	#EXT#@ marker. MUST test before generic UPN (which would swallow it).
32	User Principal Name (UPN)	`jsmith@company.com`	username@domain.com	`^[^@\s\\\/]+@[^@\s\\\/]+\.[^@\s\\\/]+$`	Identical regex to Email and NAI -- unresolvable by pattern alone.
36	Entra ImmutableID / sourceAnchor	`qODJ8f2hK0mQ1pR3sT5uVw==`	base64 of on-prem objectGUID	`^[A-Za-z0-9+/]{22}==$`	Used by Entra Connect. == suffix keeps it out of the SAMAccountName fallback.

Cloud IAM (GCP) (1)

#	Format	Example	Template	Regex	Notes
17	GCP service account	`bot@my-project.iam.gserviceaccount.com`	name@project.iam.gserviceaccount.com	`^[^@\s]+@[^@\s]+\.iam\.gserviceaccount\.com$`	.gserviceaccount.com suffix. Test before generic UPN.

Database (1)

#	Format	Example	Template	Regex	Notes
19	MySQL account	`'jsmith'@'localhost'`	'username'@'host'	`^'[^']'@'[^']'$`	Identity tied to connecting host. Quotes make it distinctive.

Directory (LDAP) (1)

#	Format	Example	Template	Regex	Notes
20	LDAP Distinguished Name (DN)	`cn=jsmith,ou=People,dc=company,dc=com`	cn=username,ou=group,dc=domain,dc=com	`^(?:[A-Za-z][\w-]=[^,]+)(?:,\s[A-Za-z][\w-]*=[^,]+)+$`	key=value,... structure. Also the value form of X509SubjectName.

Kerberos (2)

#	Format	Example	Template	Regex	Notes
21	Kerberos service principal	`host/web.company.com@COMPANY.COM`	service/instance@REALM	`^[^\/@\s]+\/[^\/@\s]+@[^\/@\s]+$`	Forward-slash before @ separates it from user principal.
31	Kerberos user principal	`jsmith@COMPANY.COM`	username@REALM	`^[^@\s\\\/]+@[A-Z0-9.-]+\.[A-Z]{2,}$`	Uppercase-realm heuristic only. Lowercase realm falls through to UPN.

#	Format	Example	Template	Regex	Notes
22	Fediverse / Mastodon handle	`@jsmith@mastodon.social`	@username@server	`^@[^@\s]+@[^@\s]+\.[^@\s]+$`	Two @ signs. Test before Matrix and bare handle.
23	Matrix ID (MXID)	`@jsmith:matrix.org`	@username:server	`^@[^@:\s]+:[^@:\s]+\.[^@:\s]+$`	Leading @ plus colon-separated server.
25	Bare @-handle	`@jsmith`	@username	`^@[A-Za-z0-9._-]+$`	Leading @, no domain, no colon.

Network auth (2)

#	Format	Example	Template	Regex	Notes
30	NAI (legacy prefixed)	`company.com\jsmith`	realm\username (or realm/username)	`^[^\\\/@\s]+\\[^\\\/@\s]+$`	Same X\Y shape as rows 28-29; broad backslash pattern that overlaps both.
34	Network Access Identifier (NAI)	`jsmith@company.com`	username@realm	`^[^@\s\\\/]+@[^@\s\\\/]+\.[^@\s\\\/]+$`	IETF RFC 7542 (RADIUS/EAP/802.1X). Alias of UPN / Email.

Generic / opaque (1)

#	Format	Example	Template	Regex	Notes
35	Numeric UID / employee ID	`1001`	digits	`^\d+$`	Subset of SAMAccountName; test before it.

Detector precedence order

Test formats in this order and return the first match. Formats sharing an identical regex (e.g. UPN / Email / NAI) are genuinely ambiguous by value alone -- later entries only fire if every more-specific pattern above them has already failed.

#	Format	Category
1	SAML Persistent NameID	SAML protocol
2	SAML Email NameID	SAML protocol
3	SAML Transient NameID	SAML protocol
4	SAML Unspecified NameID	SAML protocol
5	SAML Windows Domain NameID	SAML protocol
6	SAML X509 Subject NameID	SAML protocol
7	SAML Kerberos NameID	SAML protocol
8	AWS IAM ARN	Cloud IAM (AWS)
9	AWS STS assumed-role ARN	Cloud IAM (AWS)
10	WebFinger acct URI	Internet / messaging
11	Tel URI	Consumer / phone
12	SIP URI	Internet / messaging
13	AWS access key ID	Cloud IAM (AWS)
14	Security Identifier (SID)	Windows / AD
15	Object ID (GUID)	Entra / Azure AD
16	B2B guest (external)	Entra / Azure AD
17	GCP service account	Cloud IAM (GCP)
18	Local Windows account	Windows / AD
19	MySQL account	Database
20	LDAP Distinguished Name (DN)	Directory (LDAP)
21	Kerberos service principal	Kerberos
22	Fediverse / Mastodon handle	Social / Fediverse
23	Matrix ID (MXID)	Social / Fediverse
24	XMPP / Jabber ID (JID)	Internet / messaging
25	Bare @-handle	Social / Fediverse
26	E.164 phone number	Consumer / phone
27	On-Premises UPN	Windows / AD
28	Down-level logon name (FQDN variant)	Windows / AD
29	Down-level logon name (NetBIOS)	Windows / AD
30	NAI (legacy prefixed)	Network auth
31	Kerberos user principal	Kerberos
32	User Principal Name (UPN)	Entra / Azure AD
33	Email address	Internet / messaging
34	Network Access Identifier (NAI)	Network auth
35	Numeric UID / employee ID	Generic / opaque
36	Entra ImmutableID / sourceAnchor	Entra / Azure AD
37	SAMAccountName (bare)	Windows / AD

← Back to References

References / Splunk sourcetype definition

Field Extraction

Field Extraction documents how a field is pulled from raw event data and, critically, at which pipeline stage -- search time or index time -- that extraction happens. The stage decision has real cost: index-time fields are the fastest to search but are permanently written into the indexed data, while search-time fields are cheap to add, change or delete but are computed fresh on every search.

Definition

An Extracted Fields record ties a field name to the sourcetype it belongs to and the mechanism used to populate it -- regex, delimiter, automatic key-value parsing, indexed structured extraction, or an ingest-time eval expression. Record the extraction method, the pipeline stage it runs at, and (for index-time methods specifically) the operational justification for paying the storage and immutability cost of writing the field into the index rather than computing it at search time.

Default fields

Before any extraction rule is configured, Splunk already assigns a set of default fields to every event -- these are the baseline against which custom extraction (the next section) adds value. Four are metadata fields assigned at index time and always present, regardless of sourcetype configuration:

Field	Definition	Override mechanism
`host`	The host value assigned to the event -- normally the hostname of the forwarder or source machine that produced it.	Per-input in `inputs.conf` (`host =`); `host_segment = <N>` on a `monitor://` stanza to derive it from the Nth `/`-separated segment of the file path instead (for example `/data/syslog/cisco_asa/<host>/<host>.log` with `host_segment = 4`); or a `TRANSFORMS-*` stanza with `DEST_KEY = MetaData:Host`.
`source`	The source value assigned to the event -- normally the full file path, or the name of the network port or script that produced it.	Per-input in `inputs.conf`, or a `TRANSFORMS-*` stanza with `DEST_KEY = MetaData:Source`.
`sourcetype`	The sourcetype value assigned to the event -- either auto-detected by Splunk's sourcetype-matching rules or explicitly set.	Inline `sourcetype =` on the input stanza, or a `TRANSFORMS-*` stanza with `DEST_KEY = MetaData:Sourcetype`.
`index`	The name of the index the event is stored in.	Inline `index =` on the input stanza, or an index-routing `TRANSFORMS-*` stanza with `DEST_KEY = _MetaData:Index`.

Other default fields

Field	Stage	Definition
`timestamp`	Search-time	The human-readable event time Splunk displays, rendered from the underlying `_time` value.
`linecount`	Index-time	The number of lines the event contained before indexing.
`punct`	Index-time	A punctuation-pattern fingerprint automatically extracted from the event, useful for grouping structurally similar events without a custom regex. Controlled by `ANNOTATE_PUNCT` in `props.conf` (default `true`) -- set `ANNOTATE_PUNCT = false` on high-volume sourcetypes that never search on it, to reduce indexing load and the per-event disk footprint.
`splunk_server`	Search-time	The name of the Splunk server instance that served the event to the search.
`eventtype`	Search-time	Not extracted from raw event data at all -- a saved-search-style knowledge object name applied to events matching a stored search definition, unlike every other field on this page.

Tags. Splunk lets you attach one or more tags to any specific field/value pair -- including an eventtype value -- via tags.conf: a stanza named [fieldname=value] containing one <tagname> = enabled line per tag. Once tagged, search with tag::<field>=<tagname> (or the shorthand tag=<tagname>) to retrieve every event sharing that tag across differently-named event types, without needing to remember or repeat every individual field value.

[eventtype=login_failure]
authentication = enabled
failure = enabled

date_* fields (timestamp-derived, index-time)

When Splunk successfully parses a timestamp from an event, it also writes the timestamp's individual components into indexed date_* fields. These are absent for events with no discoverable timestamp -- including sourcetypes configured with DATETIME_CONFIG = CURRENT or DATETIME_CONFIG = NONE -- which makes a missing date_* set a useful diagnostic signal when validating Datetime Parse.

Field	Definition
`date_year`	The year in which the event occurred, parsed from the raw timestamp at index time.
`date_month`	The month in which the event occurred, parsed from the raw timestamp at index time.
`date_mday`	The day of the month (1-31) on which the event occurred.
`date_wday`	The day of the week on which the event occurred.
`date_hour`	The hour (0-23) in which the event occurred.
`date_minute`	The minute in which the event occurred.
`date_second`	The second in which the event occurred.
`date_zone`	The timezone offset (in minutes from UTC) associated with the parsed timestamp.

Not the same as internal fields. Default fields are distinct from Splunk's underscore-prefixed internal fields (_raw, _time, _indextime and others), which are always present but not typically surfaced in the fields sidebar. _time is the parsed, epoch-based event time used internally for time-range filtering and sorting; timestamp above is the human-readable rendering of that same underlying value.

Extraction methods

Method	Stage	Definition
`EXTRACT-` / `REPORT-` (regex)	Search-time	Field defined by a regular expression -- inline via `EXTRACT-` in `props.conf`, or as a named `transforms.conf` stanza referenced by `REPORT-`. Computed fresh from raw text on every search; cheap to add, change or remove.
`KV_MODE`	Search-time	Automatic key-value pair extraction at search time (`none`, `auto`, `json`, `xml`, `multi`). See the Key-value pair styles reference for which pair styles `auto` does and does not cover.
`DELIMS`	Search-time (default)	Delimiter-based field extraction (CSV, TSV, pipe-delimited) as an alternative to regex; positional, so field order in the source must be stable.
`INDEXED_EXTRACTIONS`	Index-time	Structured formats (JSON, CSV, W3C, TSV) parsed and every resulting field written into the index at ingest, before any search runs. The built-in mechanism for index-time extraction of an entire structured event, rather than a single custom field.
Custom indexed field (`TRANSFORMS-*` with `WRITE_META`)	Index-time	A `transforms.conf` stanza with `WRITE_META = true` and `DEST_KEY = _meta`, referenced from a `props.conf` `TRANSFORMS-*` line, writes an arbitrary regex-derived `field::value` pair directly into the event's indexed metadata. This is the mechanism for promoting one specific field to index time without indexing the whole structured event.
`INGEST_EVAL`	Index-time (ingest pipeline)	An ingest-time eval expression, run at the Ingest Processor or indexer layer, that derives or transforms a field before the event is written to disk. The modern alternative to a hand-rolled `WRITE_META` stanza when the field is computed (lookups, conditionals, string functions) rather than a direct regex capture.

Index-time vs. search-time

Splunk field extraction happens at one of two pipeline stages, and the choice is a real design decision, not a style preference. Search-time (the default, and the preferred stage for the large majority of fields) computes the field from _raw at query time via EXTRACT-*, REPORT-* or KV_MODE -- nothing is written to disk beyond the raw event, so a wrong or missing extraction can be fixed retroactively for already-indexed data just by editing the config and re-running the search. Index-time extraction (INDEXED_EXTRACTIONS, a custom WRITE_META stanza, or INGEST_EVAL) writes the field's value into the event's indexed metadata at ingest -- it is available before any search runs, and is the fastest possible field to search against, but it permanently increases indexed volume (and therefore license usage and disk), and cannot be renamed, corrected or removed for events already on disk without re-indexing them.

When index-time is justified. Reach for it only for a specific operational reason: the field is needed for event routing or index/role-based access control decisions that must happen before search, or the field is used in such high-volume, latency-sensitive searches (dashboards refreshing constantly across huge data volumes) that repeated search-time computation is measurably too expensive. Absent one of those reasons, prefer search-time extraction -- it is both cheaper to get wrong and cheaper to fix.

Example

Custom index-time field via WRITE_META

[example:custom_field]
TRANSFORMS-add_region = extract_region

[extract_region]
REGEX = region=(\w+)
FORMAT = region::$1
WRITE_META = true
DEST_KEY = _meta

Equivalent via INGEST_EVAL

[example:custom_field]
INGEST_EVAL-set_region = region=coalesce(json_extract(_raw, "region"), "unknown")

INGEST_EVAL expressions run at the Ingest Processor or indexer layer and can use SPL2 eval functions (coalesce, json_extract, case, lookups), so they cover computed and conditional fields that a plain regex-based WRITE_META stanza cannot.

Validation

Default to search-time extraction; document the specific operational reason (routing, access control, extreme search-cost reduction) before promoting a field to index time.
Measure the indexed-volume and license impact of a new index-time field before deploying it broadly -- every event gains the field's stored bytes permanently.
Remember index-time fields are immutable for already-indexed events: a wrong regex or eval expression is only fixed for events indexed after the fix, not before.
Check new field names don't collide with reserved or default fields (host, source, sourcetype, index, _time, punct).
Confirm INDEXED_EXTRACTIONS or a WRITE_META field isn't duplicated by a later search-time EXTRACT-*/KV_MODE for the same field.
Test regex and eval expressions against representative normal, malformed and boundary events before deployment, since index-time mistakes are the most expensive kind to correct.

← Back to References

References / Splunk SPL reference

Types of Search Commands

Almost every SPL command -- built-in or a Custom Search Command -- falls into one or more of six broad categorisations: distributable streaming, centralized streaming, transforming, generating, orchestrating and dataset processing. These categorisations describe how a command participates in the distributed search pipeline, and understanding them is what lets you write searches that push as much work as possible onto the indexers instead of the search head.

Definition and why it matters

These categorisations are not mutually exclusive. Some commands fit only one -- stats, for example, is purely transforming -- while others fit several at once (a command can be both streaming and generating). Knowing which type a command is tells you where in the distributed deployment it can run, and therefore how much data movement a search actually requires.

Once search processing moves from the indexers to the search head, it can't move back. So the practical consequence of this categorisation is a rule of thumb: put non-streaming commands as late as possible in a search to keep as much of the pipeline distributable, and therefore fast, as it can be.

Streaming vs. non-streaming

A streaming command operates on each event as it's returned by a search -- one event in, one (or no) event out -- without needing to see any other event first. eval is a canonical example: ... | eval full_name = first_name." ".last_name evaluates each event independently of every other event.

A non-streaming command requires the entire set of events from every indexer before it can operate. Many transforming commands are non-streaming; there are also non-transforming, non-streaming commands -- these are most often dataset processing commands. sort is the clearest example: it cannot begin sorting until every event has arrived. Other non-streaming commands include dedup (in some modes), stats and top.

The cost of non-streaming. A non-streaming command forces the entire event set to the search head -- a lot of data movement, and a loss of the parallelism that made the earlier, distributable part of the search fast.

The six types

1Distributable streaming

Operates on each event returned by a search, and -- unlike centralized streaming -- the order of events doesn't matter. Because order is irrelevant, a distributable streaming command can run on the indexer itself, in parallel, before results ever reach the search head. Whether it actually does depends on every command earlier in the pipeline: if all of them can also run on the indexer, this command runs there too; the moment any earlier command must run on the search head, everything after it runs on the search head as well, with no way back.

evalfieldsmakemvrenameregexreplacestrcattyperwhererex

2Centralized streaming

Also processes one event at a time, but the order of events matters, so it can only run on the search head as a single stream -- sometimes called "stateful streaming." It's still streaming (it doesn't need the full set before starting), just not distributable across indexers.

headstreamstatsdedup (some modes)cluster (some modes)

3Transforming

Orders search results into a data table, converting event values into the numerical/tabular structures Splunk needs for statistics and visualizations (column, bar, line, area, pie). Transforming commands are not streaming, and critically they do not output events -- they output results. Once a transforming command has run, no later command in the search can expect events as input.

charttimechartstatstoprareaddtotals (column totals)

4Generating

Returns information or generates results, rather than transforming an existing pipeline of events. Generating commands are either event-generating (distributable or centralized) or report-generating (usually centralized), and don't expect or require input -- they're normally invoked at the very start of a search with a leading pipe, since a search can't be piped into a generating command. search is the exception: it's implicitly generating at the start of every search and needs no leading pipe.

dbinspectdatamodelinputcsvinputlookupmakeresultsmetadatapivotsearchtstats

Comment placement. A comment inserted immediately before a generating command causes the search to fail -- for example | ```This search returns an error``` | tstats count WHERE host=x BY source does not run.

5Orchestrating

Controls some aspect of how the search itself is processed, without directly affecting the final result set -- for example, enabling or disabling a search optimization to help the overall search complete faster.

redistributenooplocaloplookup (with local=t)

6Dataset processing

A handful of commands require the entire dataset before they can run at all, and are not transforming, not distributable, not streaming and not orchestrating -- these are dataset processing commands. Some can fit into other categorisations in specific situations or with specific arguments.

sorteventstatscluster (some modes)dedup (some modes)fillnull (some modes)

Processing attributes

Processing differences between the four "shapes" of command behaviour:

Attribute	Distributable streaming	Centralized streaming	Dataset processing (non-streaming)	Transforming
Can run on indexers	Y	N	N	N
Can output before final input	Y	Y	N	N
Outputs events if inputs are events	Y	Y	Y	N

A command's output is either events or results, depending on its type. sort takes events in and returns events out, in sorted order. A transforming command like stats never outputs events -- it outputs a table of calculated results, and the underlying events are no longer available to anything downstream.

Example: where processing actually happens

search... | lookup... | where... | eval... | sort... | where... |...

The first four commands (search through eval) are all distributable streaming, so they can be pushed down and run on the indexers in parallel -- that's exactly what the search head does when the search is dispatched. sort is not distributable and needs every event in one place, so the results of the first four commands are sent back to the search head for sorting. Because processing can't move back to the indexers once it's on the search head, everything after sort -- including the second where, even though where is itself distributable streaming -- also runs on the search head.

Validation

Identify the first non-distributable-streaming command in a search -- everything before it can run on the indexers; everything from it onward runs on the search head.
Put non-streaming (transforming, centralized streaming, dataset processing) commands as late in the pipeline as possible, since moving them earlier forces more of the search onto the search head for no benefit.
Remember a transforming command ends the events-in-events-out chain: no command expecting events as input can follow one.
Don't place a comment immediately before a generating command -- it breaks the search.
Check whether a command's behaviour (streaming vs. non-streaming, distributable vs. centralized) changes with the mode or arguments used -- dedup, cluster and fillnull all do.
Cross-reference Custom Search Command (SOT-01.05.02) in the Splunk Taxonomy for how a custom command declares its own type via commands.conf.

← Back to References

References / Splunk platform configuration

Forwarder Outputs Configuration

outputs.conf controls where a Universal or Heavy Forwarder sends the data it collects. It splits into four stanza shapes, each backing a distinct object in the Splunk Taxonomy: a global default stanza, one or more named target groups, the individual servers listed inside a group, and syslog-format output stanzas. This article documents the settings each stanza type accepts.

Definition

Every stanza in outputs.conf is one of four shapes, mapping directly onto four Splunk Taxonomy objects: [tcpout] (Default Forwarding Config, SOT-05.03.01) sets defaults inherited by every group; [tcpout:<target_group>] (Forwarding Group, SOT-05.03.02) defines a named, load-balanced destination; the server= list inside a group stanza (Forwarded Server, SOT-05.03.03) names the individual indexers in that group; and [syslog:<stanza_name>] (Syslog Output, SOT-05.03.04) sends data in standard syslog format instead of Splunk's native cooked protocol.

Settings reflect stable, long-documented outputs.conf behaviour current as of recent Splunk Enterprise/Cloud releases. Confirm exact default values against the installed version's outputs.conf.spec before relying on a specific default in production, rather than treating the values below as guaranteed for every release.

File locations

Configuration file: outputs.conf.

Scope	Path
System	`$SPLUNK_HOME/etc/system/{default,local}/outputs.conf`
App	`$SPLUNK_HOME/etc/apps/<app_name>/{default,local}/outputs.conf`

Global defaults -- `[tcpout]`

Settings placed directly under the bare [tcpout] stanza (no group name) apply to every target group unless a group-level stanza overrides them.

Setting	Description
`defaultGroup`	Comma-separated list of target group names to forward to when no other output-routing rule applies.
`indexAndForward`	Whether this forwarder also indexes the data locally as well as forwarding it -- normally only enabled on a Heavy Forwarder used as a lightweight local search point.
`compressed`	Compresses data sent over the wire; the receiving indexer must be configured to accept compressed input.
`useACK`	Enables indexer acknowledgement, so the forwarder can confirm data was actually received and indexed before considering it delivered -- reduces data loss risk during indexer outages, at some throughput cost.
`autoLBFrequency`	How often (seconds) the forwarder re-evaluates and potentially switches which server in a load-balanced group it's sending to.
`maxQueueSize`	Maximum size of the forwarder's output queue before it starts blocking or dropping, depending on other settings.
`heartbeatFrequency`	How often the forwarder sends a heartbeat to the receiver to confirm the connection is alive.
`sslVerifyServerCert` / `sslRootCAPath` / `sslCertPath`	TLS settings for encrypting forwarder-to-indexer traffic and verifying the receiving indexer's certificate.
`forwardedindex.<n>.whitelist` / `.blacklist`	Regex-based filtering of which indexes' data is eligible to be forwarded at all, evaluated in numbered rule order.

Forwarding groups -- `[tcpout:<target_group>]`

A named stanza defining one destination group. Any global-default setting can be overridden here for this specific group.

Setting	Description
`server`	Comma-separated list of `host:port` destinations (the Forwarded Server object) this group load-balances or fails over across -- for example `idx1.example.com:9997,idx2.example.com:9997`.
`autoLB`	Whether this group load-balances across its listed servers (the default forwarding behaviour) rather than always using the first one.
`indexerDiscovery`	Name of an `[indexer_discovery:<name>]` stanza in `server.conf`, used instead of a static `server=` list to dynamically discover peer indexers from the Cluster Manager.
`sendCookedData`	Whether events are sent in Splunk's parsed/"cooked" protocol (the default, required for a normal indexer destination) or as raw, unparsed data -- set to false only when forwarding to a non-Splunk raw-TCP receiver.
`dropEventsOnQueueFull`	Seconds the output queue can stay full before the forwarder starts dropping events for this group, rather than blocking indefinitely.
`compressed`, `useACK`, `autoLBFrequency`, `sslVerifyServerCert`, `sslCertPath`	Same meaning as the global default settings above, scoped to just this group when set here.

Syslog output -- `[syslog:<stanza_name>]`

Sends data onward in IETF RFC 3164/5424 syslog format rather than Splunk's cooked protocol, typically to feed a non-Splunk syslog receiver or SIEM.

Setting	Description
`server`	The `host:port` of the syslog receiver.
`type`	Transport protocol -- `tcp` or `udp`.
`priority`	The syslog PRI value to stamp on outgoing events, either a numeric priority or a `<FACILITY.SEVERITY>` pair.
`syslogSourceType`	Restricts this stanza to only forward events whose sourcetype matches, letting different sourcetypes route to different syslog destinations.
`timestampformat`	A `strftime`-style format string controlling how the timestamp is rendered in the outgoing syslog header, since syslog's expected timestamp format differs from Splunk's internal representation.
`maxEventSize`	Maximum size of a single forwarded event before it's truncated.

Syslog output does not carry Splunk metadata. Unlike cooked forwarding to another Splunk indexer, a syslog destination receives plain text -- host/source/sourcetype and other Splunk-internal fields are not transmitted unless embedded in the event text itself by the sending sourcetype's configuration.

All settings

Every stanza and setting in outputs.conf.spec from Splunk Enterprise 10.4.2: 260 settings across 12 stanzas. Descriptions use the spec's own wording -- the first line shows here and More opens the rest. The Default column is filled only where the spec gives a Default: line.

`[tcpout]`

Setting	Description	Default
`[tcpout]` `defaultGroup`	`<comma-separated list>`A comma-separated list of one or more target group names, specified later in [tcpout:<target_group>] stanzas. More The forwarder sends all data to the specified groups. If you don't want to forward data automatically, don't configure this setting. Can be overridden by the '_TCP_ROUTING' setting in the inputs.conf file, which in turn can be overridden by a props.conf or transforms.conf modifier. Starting with version 4.2, this setting is no longer required.
`[tcpout]` `indexAndForward`	`<boolean>`Set to "true" to index all data locally, in addition to forwarding it. More This is known as an "index-and-forward" configuration. This setting is only available for heavy forwarders. This setting is only available at the top level [tcpout] stanza. It cannot be overridden in a target group.	false
`[tcpout]` `enableOldS2SProtocol`	`<boolean>`Whether or not the forwarder enables use of versions 3 and lower of the Splunk-to-Splunk protocol, otherwise known as the "old" S2S protocol, to connect with other Splunk platform instances. More A value of "true" means the forwarder can use the old protocol, depending on other settings you configure. A value of "false" means the forwarder uses only version 4 of the S2S protocol, and does not use any of the old protocol versions. When you disable the use of old S2S protocols, forwarders always use the new protocol. Indexers that run a version of Splunk Enterprise below 6.0 only support the old protocol, and forwarders can't connect to those indexers over S2S. If you give 'negotiateProtocolLevel' a value of 0, or 'negotiateNewProtocol' a value of "false" in inputs.conf or outputs.conf to use the old S2S protocol, the forwarder will instead override these settings to use the lowest protocol version that all instances support. This setting is only available for configuration at the top level [tcpout] stanza. You can't override it in a target group with settings that force usage of the older protocol.	false
`[tcpout]` `certRotationCheckInterval`	`<positive integer>[s\|m\|h\|d]`The interval between attempts to rotate forwarder certificates automatically. More This setting is valid on forwarders only. It does not work with other Splunk platform instances.	1d

`[tcpout:<target_group>]`

Setting	Description	Default
`[tcpout:<target_group>]` `server`	`<comma-separated list>`A comma-separated list of one or more systems to send data to over a TCP socket. More You can specify each element as either an IP address or a hostname and a port number. For example: 192.168.1.10:9997, mysplunkserver.com:9997 Required if the 'indexerDiscovery' setting is not set. Typically used to specify receiving Splunk systems, although you can use it to send data to non-Splunk systems (see the 'sendCookedData' setting). For each system you list, the following information is required: The IP address or server name where one or more systems are listening. The port on which the syslog server is listening.
`[tcpout:<target_group>]` `blockWarnThreshold`	`<integer>`The output pipeline send failure count threshold after which a failure message appears as a banner in Splunk Web. More Optional. To disable Splunk Web warnings on blocked output queue conditions, set this to a large value (for example, 2000000).	100
`[tcpout:<target_group>]` `indexerDiscovery`	`<string>`The name of the manager node to use for indexer discovery. More Instructs the forwarder to fetch the list of indexers from the manager node specified in the corresponding [indexer_discovery:<name>] stanza.	No default
`[tcpout:<target_group>]` `token`	`<string>`The access token for receiving data. More If you configured an access token for receiving data from a forwarder, Splunk software populates that token here. If you configured a receiver with an access token and that token is not specified here, the receiver rejects all data sent to it. This setting is optional.	No default
`[tcpout:<target_group>]` `queueSize`	`<integer>[KB\|MB\|GB]`See the description of 'queueSize' in the inputs.conf specification file for details on this setting. More If you do not set a value for 'persistentQueueSize', splunkd ignores the value for 'queueSize'.	0 (no in-memory part of persistent queue)
`[tcpout:<target_group>]` `persistentQueueSize`	`<integer>[KB\|MB\|GB\|TB]`See the description of 'persistentQueueSize' in the inputs.conf specification file for details on this setting. More Splunkd applies this limit for each target group for each ingestion pipeline. If both the 'queueSize' and 'maxQueueSize' settings have values of 0, the tcpout persistent queue becomes a disk-only queue. The naming convention of the persistent queue file on disk is "pq_<group-name>_<pipeline number>". For example, if you set "parallelIngestionPipelines=2" in server.conf, with two target groups 'splunk-group1' and 'splunk-group2', the persistent queue files appear as follows: $SPLUNK_HOME/var/run/splunk/tcpout/pq_splunk-group1_0 $SPLUNK_HOME/var/run/splunk/tcpout/pq_splunk-group1_1 $SPLUNK_HOME/var/run/splunk/tcpout/pq_splunk-group2_0 $SPLUNK_HOME/var/run/splunk/tcpout/pq_splunk-group2_1	0 (no on-disk persistent queue)

`[tcpout-server://<ip address>:<port>]`

Optional. There is no requirement to have a [tcpout-server] stanzas.

`[tcpout<any of above>]`

Setting	Description	Default
`[tcpout<any of above>]` `disabled`	`<boolean>`Whether or not to disable forwarding to the receiver or output group, as defined by the forwarding stanza. More Set to true to disable forwarding to this receiver or output group.	false
`[tcpout<any of above>]` `sendCookedData`	`<boolean>`Whether or not to send processed or unprocessed data to the receiving server. More A value of "true" means Splunk software processes the events before sending them to the server, thus "cooking" them. A value of "false" means events are raw and untouched prior to sending. Set to "false" if you are sending events to a third-party system.	true
`[tcpout<any of above>]` `heartbeatFrequency`	`<integer>`How often, in seconds, to send a heartbeat packet to the receiving server. More This setting is a mechanism for the forwarder to know that the receiver (indexer) is alive. If the indexer does not send a return packet to the forwarder, the forwarder declares the receiver unreachable and does not forward data to it. The forwarder only sends heartbeats if the 'sendCookedData' setting is set to "true".	30
`[tcpout<any of above>]` `blockOnCloning`	`<boolean>`Whether or not the tcpout processor blocks, or stops processing events, in situations where they cannot be sent to cloned output target groups. More This setting only applies when you have defined multiple output target groups for a forwarder, and are thus cloning the data. It does not apply to single output groups. A value of "true" means that when a situation occurs where all target groups that you have defined are unable to receive events, then the tcpout processor waits for 'dropClonedEventsonQueueFull' seconds before it begins to drop events. If 'dropClonedEventsonQueueFull' has a value of "-1", then the tcpout processor stops processing events indefinitely. This prevents the tcpout processor from dropping events, but can cause further blocking up the processing chain. See the 'dropClonedEventsonQueueFull' setting description for additional information on the setting. A value of "false" means the tcpout processor drops events as soon as all cloned output groups are down and the queues for those groups fill up. If at least one output group is up and at least one queue for the group is not full, then the processor does not drop events.	true (stop processing events when an output group blockage occurs, but do not drop events for at least 'dropClonedEventsOnQueueFull' seconds)
`[tcpout<any of above>]` `blockWarnThreshold`	`<integer>`The output pipeline send failure count threshold, after which a failure message appears as a banner in Splunk Web. More To disable Splunk Web warnings on blocked output queue conditions, set this to a large value (for example, 2000000). This setting is optional.	100
`[tcpout<any of above>]` `compressed`	`<boolean>`Whether or not forwarders and receivers communicate with one another in compressed format. More A value of "true" means the receiver communicates with the forwarder in compressed format for forwarding that does not use TLS/SSL. A value of "true" means the receiver communicates with the forwarder in compressed format for TLS/SSL forwarding if either 'useClientSSLCompression' has a value of "false" or the TLS/SSL connection does not use 'zlib' compression. If set to "true", you do not need to set the 'compressed' setting to "true" in the inputs.conf file on the receiver for compression of data to occur. If you use this setting, the 'tcpout_connections' group in the metrics.log file shows throughput values after compression has occurred.	false
`[tcpout<any of above>]` `negotiateProtocolLevel`	`<unsigned integer>`When setting up a connection to an indexer, Splunk software tries to negotiate the use of the Splunk forwarder protocol with the specified feature level based on the value of this setting. More If set to a lower value than the default, this setting denies the use of newer forwarder protocol features when it negotiates a connection. This might impact indexer efficiency.	1 (if 'negotiateNewProtocol' is "true"); 0 (if 'negotiateNewProtocol' is not "true")
`[tcpout<any of above>]` `negotiateNewProtocol`	`<boolean>`The default value of the 'negotiateProtocolLevel' setting. More DEPRECATED. Set 'negotiateProtocolLevel' instead.	true
`[tcpout<any of above>]` `channelReapInterval`	`<integer>`How often, in milliseconds, that channel codes are reaped, or made available for re-use. More This value sets the minimum time between reapings. In practice, consecutive reapings might be separated by greater than the number of milliseconds specified here.	60000 (1 minute)
`[tcpout<any of above>]` `channelTTL`	`<integer>`How long, in milliseconds, a channel can remain "inactive" before it is reaped, or before its code is made available for reuse by a different channel.	300000 (5 minutes)
`[tcpout<any of above>]` `channelReapLowater`	`<integer>`This value essentially determines how many active-but-old channels Splunk software keeps "pinned" in memory on both sides of a Splunk-to-Splunk connection. More If the number of active channels is greater than 'channelReapLowater', Splunk software reaps old channels to make their channel codes available for re-use. If the number of active channels is less than 'channelReapLowater', Splunk software does not reap channels, no matter how old they are. A non-zero value helps ensure that Splunk software does not waste network resources by "thrashing" channels in the case of a forwarder sending a trickle of data.	10
`[tcpout<any of above>]` `socksServer`	`<string>`The IP address or server name of the Socket Secure version 5 (SOCKS5) server. More Required. Specify this value as either an IP address or hostname and port number, for example: 192.168.1.10:8080 or mysplunkserver.com:8080. This setting specifies the port on which the SOCKS5 server is listening. After you configure and restart the forwarder, it connects to the SOCKS5 proxy host, and optionally authenticates to the server on demand if you provide credentials. NOTE: Only SOCKS5 servers are supported.	No default
`[tcpout<any of above>]` `socksUsername`	`<string>`The SOCKS5 username to use when authenticating against the SOCKS5 server. More Optional.
`[tcpout<any of above>]` `socksPassword`	`<string>`The SOCKS5 password to use when authenticating against the SOCKS5 server. More Optional.
`[tcpout<any of above>]` `socksResolveDNS`	`<boolean>`Whether or not a forwarder should rely on the SOCKS5 proxy server Domain Name Server (DNS) to resolve hostnames of indexers in the output group to which the forwarder sends data. More A value of "true" means the forwarder sends the hostnames of the indexers to the SOCKS5 server, and lets the SOCKS5 server do the name resolution. It does not attempt to resolve the hostnames on its own. A value of "false" means the forwarder attempts to resolve the hostnames of the indexers through DNS on its own. Optional.	false
`[tcpout<any of above>]` `maxQueueSize`	`[<integer>\|<integer>[KB\|MB\|GB]\|auto]`The maximum size of the forwarder output queue. More The size can be limited based on the number of entries, or on the total memory used by the items in the queue. If specified as a lone integer (for example, "maxQueueSize=100"), the 'maxQueueSize' setting indicates the maximum count of queued items. If specified as an integer followed by KB, MB, or GB (for example, maxQueueSize=100MB), the 'maxQueueSize' setting indicates the maximum random access memory (RAM) size of all the items in the queue. If set to "auto", this setting configures a value for the output queue depending on the value of the 'useACK' setting: If 'useACK' is set to "false", the output queue uses 500KB. If 'useACK' is set to "true", the output queue uses 7MB. If you enable indexer acknowledgment by configuring the 'useACK' setting to "true", the forwarder creates a wait queue where it temporarily stores data blocks while it waits for indexers to acknowledge the receipt of data it previously sent. The forwarder sets the wait queue size to triple the value of what you set for 'maxQueueSize.' For example, if you set "maxQueueSize=1024KB" and "useACK=true", then the output queue is 1024KB and the wait queue is 3072KB. Although the wait queue and the output queue sizes are both controlled by this setting, they are separate. The wait queue only exists if 'useACK' is set to "true". Limiting the queue sizes by quantity is historical. However, if you configure queues based on quantity, keep the following in mind: Queued items can be events or blocks of data. Non-parsing forwarders, such as universal forwarders, send blocks, which can be up to 64KB. Parsing forwarders, such as heavy forwarders, send events, which are the size of the events. Some events are as small as a few hundred bytes. In unusual cases (data dependent), you might arrange to produce events that are multiple megabytes. if 'useACK' is set to "true" and this setting is set to "auto", then the output queue is 7MB and the wait queue is 21MB.	auto
`[tcpout<any of above>]` `dropEventsOnQueueFull`	`<integer>[ms\|s\|m]`The amount of time to wait before the output queue throws out all new events until it has space. More If set to 0ms(milliseconds), 0s(seconds), or 0m(minutes), the queue immediately throws out all new events until it has space. If set to a positive number, the queue waits the specified number of milliseconds, seconds, or minutes before throwing out all new events. If "ms", "s", or "m" is not specified, the default unit is seconds. If set to -1 or 0, the output queue is blocked because it is full, but events are not dropped. If any target group queue is blocked, no more data reaches any other target group. CAUTION: Do not set to a positive integer if you are monitoring files because the files will not be fully ingested if the queue remains blocked for the specified amount of time.	-1
`[tcpout<any of above>]` `dropClonedEventsOnQueueFull`	`<integer>[ms\|s\|m]`The amount of time to wait before dropping events from the group. More If set to 0ms(milliseconds), 0s(seconds), or 0m(minutes), the queue immediately throws out all new events until it has space. If set to a positive number, the queue does not block completely, but waits up to the specified number of milliseconds, seconds, or minutes to queue events to a group. If it cannot queue to a group for more than the specified amount of time, the queue begins dropping events from the group and makes sure that at least one group in the cloning configuration can receive events. The queue blocks if it cannot deliver events to any of the cloned groups. If set to -1, the TcpOutputProcessor ensures that each group receives all of the events. If one of the groups is down, the TcpOutputProcessor blocks everything.	5 seconds
`[tcpout<any of above>]` `maxFailuresPerInterval`	`<integer>`The maximum number of failures allowed per interval before a forwarder applies backoff (stops sending events to the indexer for a specified number of seconds). The interval is defined in the 'secsInFailureInterval' setting.	2
`[tcpout<any of above>]` `secsInFailureInterval`	`<integer>`The number of seconds contained in a failure interval. More If the number of write failures to the indexer exceeds 'maxFailuresPerInterval' in the specified 'secsInFailureInterval' seconds, the forwarder applies backoff. The backoff time period range is 1-10 * 'autoLBFrequency'.	1
`[tcpout<any of above>]` `backoffOnFailure`	`<positive integer>`The number of seconds a forwarder backs off, or stops sending events, before attempting to make another connection with the indexer.	30
`[tcpout<any of above>]` `maxConnectionsPerIndexer`	`<integer>`The maximum number of allowed connections per indexer. More In the presence of failures, the maximum number of connection attempts per indexer at any point in time.	2
`[tcpout<any of above>]` `connectionsPerTarget`	`[<integer>\|auto]`The maximum number of allowed outbound connections for each target IP address as resolved by DNS on the machine. More A value of "auto" or < 1 means splunkd configures a value for connections for each target IP address. Depending on the number of IP addresses that DNS resolves, splunkd sets 'connectionsPerTarget' as follows: If the number of resolved target IP addresses is greater than or equal to 10, 'connectionsPerTarget' gets a value of 1. If the number of resolved target IP addresses is greater than 5 and less than 10, 'connectionsPerTarget' gets a value of 2. If the number of resolved target IP addresses is greater than 3 or less than equal to 5, 'connectionsPerTarget' gets a value of 3. If the number of resolved target IP addresses is less than or equal to 3, 'connectionsPerTarget' gets a value of 4.	auto
`[tcpout<any of above>]` `connectionTimeout`	`<integer>`The time to wait, in seconds, for a forwarder to establish a connection with an indexer. More The connection times out if an attempt to establish a connection with an indexer does not complete in 'connectionTimeout' seconds.	20
`[tcpout<any of above>]` `readTimeout`	`<integer>`The time to wait, in seconds, for a forwarder to read from a socket it has created with an indexer. More The connection times out if a read from a socket does not complete in 'readTimeout' seconds. This timeout is used to read acknowledgment when indexer acknowledgment is enabled (when you set 'useACK' to "true").	300 seconds (5 minutes)
`[tcpout<any of above>]` `writeTimeout`	`<integer>`The time to wait, in seconds, for a forwarder to complete a write to a socket it has created with an indexer. More The connection times out if a write to a socket does not finish in 'writeTimeout' seconds.	300 seconds (5 minutes)
`[tcpout<any of above>]` `connectionTTL`	`<integer>`The time, in seconds, for a forwarder to keep a socket connection open with an existing indexer despite switching to a new indexer. More This setting reduces the time required for indexer switching. Useful during frequent indexer switching potentially caused by using the 'autoLBVolume' setting.	0 seconds
`[tcpout<any of above>]` `tcpSendBufSz`	`<integer>`The size of the TCP send buffer, in bytes. More Only use this setting if you are a TCP/IP expert. Useful to improve throughput with small events, like Windows events.	the system default
`[tcpout<any of above>]` `ackTimeoutOnShutdown`	`<integer>`The time to wait, in seconds, for the forwarder to receive indexer acknowledgments during a forwarder shutdown. More The connection times out if the forwarder does not receive indexer acknowledgements (ACKs) in 'ackTimeoutOnShutdown' seconds during forwarder shutdown.	30 seconds
`[tcpout<any of above>]` `polling_interval`	`<integer>`The initial time to wait upon splunk start, in seconds, for the forwarder to fetch the list of indexers from the indexer discovery server specified in the corresponding [indexer_discovery:<name>] stanza. Subsequently polling interval is set by indexer discovery server response.	5 seconds
`[tcpout<any of above>]` `dnsResolutionInterval`	`<integer>`The base time interval, in seconds, at which indexer Domain Name Server (DNS) names are resolved to IP addresses. More This is used to compute runtime dnsResolutionInterval as follows: Runtime interval = 'dnsResolutionInterval' + (number of indexers in server settings - 1) * 30. The DNS resolution interval is extended by 30 seconds for each additional indexer in the server setting.	300 seconds (5 minutes)
`[tcpout<any of above>]` `forceTimebasedAutoLB`	`<boolean>`Forces existing data streams to switch to a newly elected indexer every auto load balancing cycle. More On universal forwarders, use the 'EVENT_BREAKER_ENABLE' and 'EVENT_BREAKER' settings in props.conf rather than 'forceTimebasedAutoLB' for improved load balancing, line breaking, and distribution of events.	false
`[tcpout<any of above>]` `forwardedindex.<n>.whitelist`	`<regular expression>`These filters determine which events get forwarded to the index, based on the indexes the events are targeted to. More An ordered list of allow lists and deny lists, which together decide if events are forwarded to an index. The order is determined by <n>. <n> must start at 0 and continue with positive integers, in sequence. There cannot be any gaps in the sequence. For example: forwardedindex.0.whitelist, forwardedindex.1.blacklist, forwardedindex.2.whitelist, ... The filters can start from either whitelist or blacklist. They are tested from forwardedindex.0 to forwardedindex.<max>. If both 'forwardedindex.<n>.whitelist' and 'forwardedindex.<n>.blacklist' are present for the same value of n, then 'forwardedindex.<n>.whitelist' is honored. 'forwardedindex.<n>.blacklist' is ignored in this case. In general, you do not need to change these filters from their default settings in $SPLUNK_HOME/system/default/outputs.conf. Filtered out events are not indexed if you do not enable local indexing.
`[tcpout<any of above>]` `forwardedindex.<n>.blacklist`	`<regular expression>`These filters determine which events get forwarded to the index, based on the indexes the events are targeted to. More An ordered list of allow lists and deny lists, which together decide if events are forwarded to an index. The order is determined by <n>. <n> must start at 0 and continue with positive integers, in sequence. There cannot be any gaps in the sequence. For example: forwardedindex.0.whitelist, forwardedindex.1.blacklist, forwardedindex.2.whitelist, ... The filters can start from either whitelist or blacklist. They are tested from forwardedindex.0 to forwardedindex.<max>. If both 'forwardedindex.<n>.whitelist' and 'forwardedindex.<n>.blacklist' are present for the same value of n, then 'forwardedindex.<n>.whitelist' is honored. 'forwardedindex.<n>.blacklist' is ignored in this case. In general, you do not need to change these filters from their default settings in $SPLUNK_HOME/system/default/outputs.conf. Filtered out events are not indexed if you do not enable local indexing.
`[tcpout<any of above>]` `forwardedindex.filter.disable`	`<boolean>`Whether or not index filtering is active. More A value of "true" means index filtering is disabled. Events for all indexes are then forwarded.	false
`[tcpout<any of above>]` `autoLBFrequency`	`<integer>`The amount of time, in seconds, that a forwarder sends data to an indexer before redirecting outputs to another indexer in the pool. More Use this setting when you are using automatic load balancing of outputs from universal forwarders (UFs). Every 'autoLBFrequency' seconds, a new indexer is selected randomly from the list of indexers provided in the server setting of the target group stanza.	30
`[tcpout<any of above>]` `autoLBFrequencyIntervalOnGroupFailure`	`<integer>`When the entire target group is not reachable, 'autoLBFrequencyIntervalOnGroupFailure' is the amount of time, in seconds, that a forwarder waits before attempting to connect to a target host in the group. More While 'autoLBFrequencyIntervalOnGroupFailure' is in effect, 'autoLBFrequency' is ignored. Once first connection is established to a group, 'autoLBFrequency' comes into effect again. This setting is applied only when 'autoLBFrequencyIntervalOnGroupFailure' is less than 'autoLBFrequency'. Every 'autoLBFrequencyIntervalOnGroupFailure' seconds, a new indexer is selected randomly from the list of indexers provided in the server setting of the target group stanza. -1 means this setting is not active.	-1
`[tcpout<any of above>]` `autoLBVolume`	`<integer>`The volume of data, in bytes, to send to an indexer before a new indexer is randomly selected from the list of indexers provided in the server setting of the target group stanza. More This setting is closely related to the 'autoLBFrequency' setting. The forwarder first uses 'autoLBVolume' to determine if it needs to switch to another indexer. If the 'autoLBVolume' is not reached, but the 'autoLBFrequency' is, the forwarder switches to another indexer as the forwarding target. A non-zero value means that volume-based forwarding is active. 0 means the volume-based forwarding is not active.	0
`[tcpout<any of above>]` `maxSendQSize`	`<integer>`The size of the tcpout client send buffer, in bytes. If tcpout client(indexer/receiver connection) send buffer is full, a new indexer is randomly selected from the list of indexers provided in the server setting of the target group stanza. More This setting allows forwarder to switch to new indexer/receiver if current indexer/receiver is slow. A non-zero value means that max send buffer size is set. 0 means no limit on max send buffer size.	0
`[tcpout<any of above>]` `autoBatch`	`<boolean>`When set to 'true', the forwarder automatically sends chunks/events in batches to target receiving instance connection. The forwarder creates batches only if there are two or more chunks/events available in output connection queue. More When set to 'false', the forwarder sends one chunk/event to target receiving instance connection. This is old legacy behavior.	true
`[tcpout<any of above>]` `useSSL`	`<true\|false\|legacy>`Whether or not the forwarder uses SSL to connect to the receiver, or relies on the 'clientCert' setting to be active for SSL connections. More You do not need to set 'clientCert' if 'requireClientCert' is set to "false" on the receiver. A value of "true" means the forwarder uses SSL to connect to the receiver. A value of "false" means the forwarder does not use SSL to connect to the receiver. The special value "legacy" means the forwarder uses the 'clientCert' property to determine whether or not to use SSL to connect.	legacy
`[tcpout<any of above>]` `sslPassword`	`<password>`The password associated with the Certificate Authority certificate (CAcert). More The default Splunk CAcert uses the password "password".	No default
`[tcpout<any of above>]` `clientCert`	`<path>`The full path to the client SSL certificate in Privacy Enhanced Mail (PEM) format. More If you have not set 'useSSL', then this connection uses SSL if and only if you specify this setting with a valid client SSL certificate file.	No default
`[tcpout<any of above>]` `sslCertPath`	`<path>`DEPRECATED. More Use the 'clientCert' setting instead. The full path to the client SSL certificate.
`[tcpout<any of above>]` `cipherSuite`	`<string>`The specified cipher string for the input processors. More This setting ensures that the server does not accept connections using weak encryption protocols. The default can vary. See the 'cipherSuite' setting in $SPLUNK_HOME/etc/system/default/outputs.conf for the current default.
`[tcpout<any of above>]` `sslCipher`	`<string>`The specified cipher string for the input processors. More DEPRECATED. Use the 'cipherSuite' setting instead.
`[tcpout<any of above>]` `ecdhCurves`	`<comma-separated list>`A list of Elliptic Curve-Diffie-Hellmann curves to use for ECDH key negotiation. More The curves should be specified in the order of preference. The client sends these curves as a part of an SSL Client Hello. The server supports only the curves specified in the list. Splunk software only supports named curves that have been specified by their SHORT names. The list of valid named curves by their short and long names can be obtained by running this CLI command: $SPLUNK_HOME/bin/splunk cmd openssl ecparam -list_curves Example setting: "ecdhCurves = prime256v1,secp384r1,secp521r1" The default can vary. See the 'ecdhCurves' setting in $SPLUNK_HOME/etc/system/default/outputs.conf for the current default.
`[tcpout<any of above>]` `sslRootCAPath`	`<path>`The full path to the root Certificate Authority (CA) certificate store. More DEPRECATED. Use the 'server.conf/[sslConfig]/sslRootCAPath' setting instead. Used only if 'sslRootCAPath' in server.conf is not set. The <path> must refer to a PEM format file containing one or more root CA certificates concatenated together.	No default
`[tcpout<any of above>]` `sslVerifyServerCert`	`<boolean>`Serves as an additional step for authenticating your indexers. More A value of "true" ensures that the server you are connecting to has a valid SSL certificate. NOTE: Certificates with the same Common Name as the CA's certificate will fail this check. Both the common name and the alternate name of the server are then checked for a match.	false
`[tcpout<any of above>]` `tlsHostname`	`<string>`A Transport Layer Security (TLS) extension that allows sending an identifier with SSL Client Hello.	empty string
`[tcpout<any of above>]` `sslVerifyServerName`	`<boolean>`Whether or not splunkd, as a client, performs a TLS hostname validation check on an SSL certificate that it receives upon an initial connection to a server. More A TLS hostname validation check ensures that a client communicates with the correct server, and has not been redirected to another by a machine-in-the-middle attack, where a malicious party inserts themselves between the client and the target server, and impersonates that server during the session. Specifically, the validation check forces splunkd to verify that either the Common Name or the Subject Alternate Name in the certificate that the server presents to the client matches the host name portion of the URL that the client used to connect to the server. For this setting to have any effect, the 'sslVerifyServerCert' setting must have a value of "true". If it doesn't, TLS hostname validation is not possible because certificate verification is not on. A value of "true" for this setting means that splunkd performs a TLS hostname validation check, in effect, verifying the server's name in the certificate. If that check fails, splunkd terminates the SSL handshake immediately. This terminates the connection between the client and the server. Splunkd logs this failure at the ERROR logging level. A value of "false" means that splunkd does not perform the TLS hostname validation check. If the server presents an otherwise valid certificate, the client-to-server connection proceeds normally.	false
`[tcpout<any of above>]` `sslCommonNameToCheck`	`<comma-separated list>`Checks the Common Name of the server's certificate against one or more of the names you specify for this setting. More Separate multiple common names with commas. The Common Name identifies the host name associated with the certificate. For example, example www.example.com or example.com If there is no match, assume that Splunk software is not authenticated against this server. You must set the 'sslVerifyServerCert' setting to "true" for this setting to work. This setting is optional.	empty string (no common name checking).
`[tcpout<any of above>]` `sslAltNameToCheck`	`<comma-separated list>`Checks the alternate name of the server's certificate against one or more of the names you specify for this setting. More Separate multiple subject alternate names with commas. If there is no match, assume that Splunk software is not authenticated against this server. You must set the 'sslVerifyServerCert' setting to "true" for this setting to work. This setting is optional.	no alternate name checking
`[tcpout<any of above>]` `useClientSSLCompression`	`<boolean>`Whether or not compression on TLS/SSL connections is enabled. More Server-side compression in splunkd is on by default. Configuring this setting on the client side enables compression between both server and client. If server-side compression is off, this client-side setting has no effect. A value of "true" means compression on TLS/SSL is enabled. If you use this setting, the 'tcpout_connections' group in the metrics.log file shows throughput values before compression occurs. SSL compression is not supported for TLS 1.3.	true
`[tcpout<any of above>]` `sslQuietShutdown`	`<boolean>`DEPRECATED. More Whether or not quiet SSL shutdown mode is turned on. When a client is finished with a TLS connection, it can shut that connection down normally or quietly. A normal SSL shutdown between a local node, in this case the client, and a peer node, in this case the server, involves either node sending a message to the other to terminate the TLS/SSL connection. This message is called the "close_notify" message. When a local node sends this message, the peer node returns the same message upon receipt, then stops sending further messages over TLS. The TLS connection remains open until the peer also closes the connection on its side. A "quiet" SSL shutdown means that neither node sends this message when it terminates the TLS connection. Instead, the node sets the connection to the "shutdown" state immediately. A value of "true" means that the client uses quiet SSL shutdown mode to terminate TLS connections. A value of false means that the client shuts down TLS connections using the normal shutdown process.	false
`[tcpout<any of above>]` `sslVersions`	`<comma-separated list>`The list of TLS versions to support. More The versions available are "tls1.0", "tls1.1", "tls1.2", and "tls1.3". The special version "*" selects all supported versions. The version "tls" selects all versions tls1.0 or newer If you prefix a version with "-", it is removed from the list. SSL versions 2 and 3 are always disabled. "-ssl2" and "-ssl3" are accepted as values in the version list, but have no effect. The default can vary. See the 'sslVersions' setting in $SPLUNK_HOME/etc/system/default/outputs.conf for the current default.
`[tcpout<any of above>]` `autoCertRotation`	`<boolean>`Whether or not forwarders attempt to renew TLS certificates that they use before the certificates expire. More TLS certificates expire after a certain period of validity. When a forwarder has been configured to use a TLS certificate for network connections, it can attempt to renew the certificate automatically up to and including the certificate expiration time. Forwarder certificate renewal works with forwarders that connect to Splunk Cloud Platform instances only. A forwarder performs a check every 'certRotationCheckInterval' to determine if a forwarder certificate needs renewal. A TLS certificate meets renewal criteria when: It has been configured for the forwarder to use it It is within its validity window, which means the current date must be between its 'Not Before' and 'Not After' dates, inclusive The remaining validity is less than or equal to the 'certRotationThresholdPct'. For example, with the default threshold percentage of 15, a certificate with a validity period of 52 weeks becomes eligible for renewal at 7.8 weeks (15% of 52) remaining. A certificate that has not been renewed remains until it either expires or the forwarder successfully completes forwarder certificate renewal. After forwarder certificate renewal is complete, the renewed certificate replaces the existing one. A value of "true" means that the forwarder attempts to automatically perform forwarder certificate renewal check and attempts to renew the certificate until the certificate successfully renews. A value of "false" means that the forwarder does not attempt to perform forwarder certificate renewal.	false
`[tcpout<any of above>]` `certRotationThresholdPct`	`<integer>`The threshold, as a percentage of the total certificate lifetime, at or below which the forwarder attempts to renew its TLS certificate. More For this setting to work, the 'autoCertRotation' setting must have a value of "true". Valid values are from 0 to 100 inclusive. A lower value means that the forwarder attempts to renew closer to the expiration time. A higher value means that the forwarder attempts to renew closer to the validity start time. For example, a value of "15" means to renew when 15% or less of the lifetime remains.	15
`[tcpout<any of above>]` `useACK`	`<boolean>`Whether or not to use indexer acknowledgment. More Indexer acknowledgment is an optional capability on forwarders that helps prevent loss of data when sending data to an indexer. A value of "true" means the forwarder retains a copy of each sent event until the receiving system sends an acknowledgment. The receiver sends an acknowledgment when it has fully handled the event (typically when it has written it to disk in indexing). If the forwarder does not receive an acknowledgment, it resends the data to an alternative receiver. NOTE: The maximum memory used for the outbound data queues increases significantly by default (500KB -> 28MB) when the 'useACK' setting is enabled. This is intended for correctness and performance. A value of "false" means the forwarder considers the data fully processed when it finishes writing it to the network socket. You can configure this setting at the [tcpout] or [tcpout:<target_group>] stanza levels. You cannot set it for individual servers at the [tcpout-server: ...] stanza level.	false

`[httpout]`

Setting	Description	Default
`[httpout]` `httpEventCollectorToken`	`<string>`The value of the HEC token. More HEC uses this token to authenticate inbound connections.	No default
`[httpout]` `uri`	`<string>`The URI and management port of the Http Event Collector(HEC) end point. More For example, https://SplunkHEC01.example.com:8088	No default
`[httpout]` `batchSize`	`<integer>`The size, in bytes, of the HTTP OUT send buffer. More HTTP OUT batch pipeline data before sending out. If the current buffer size is greater than 'batchSize', HEC sends the data out immediately.	65536
`[httpout]` `batchTimeout`	`<integer>`How often, in seconds, to send out pipeline data. More HTTP OUT batch pipeline data before sending out. If the wait time is greater than 'batchTimeout', HEC sends the data out immediately.	30
`[httpout]` `clientCert`	`<path>`The full path to the location of the client TLS/SSL certificate. More The certificate file must be in Privacy Enhanced Mail (PEM) format.	No default
`[httpout]` `sslPassword`	`<string>`The password for the client certificate. More This setting is optional.	No default
`[httpout]` `cipherSuite`	`<string>`The cipher string to use for negotiating ciphers with the TLS server. More This setting ensures that the client does not accept connections using weak encryption protocols. The default can vary. See the 'cipherSuite' setting in $SPLUNK_HOME/etc/system/default/server.conf for the current default.
`[httpout]` `ecdhCurves`	`<comma-separated list>`A list of elliptic curves to use for the Elliptic-curve Diffie-Hellman (ECDH) key negotiation protocol. More The client sends elliptic curves as part of the Client Hello during a TLS handshake. Specify elliptic curves in the order that you prefer them. The server supports only the curves specified in the list. Splunk software only supports named curves that you specify by their short names. You can get the list of valid named curves by their short and long names by running this CLI command: $SPLUNK_HOME/bin/splunk cmd openssl ecparam -list_curves Example configuration: "ecdhCurves = prime256v1,secp384r1,secp521r1" See the 'ecdhCurves' setting in $SPLUNK_HOME/etc/system/default/server.conf for the current default.
`[httpout]` `sslVerifyServerCert`	`<boolean>`Whether or not splunkd, as a client, validates the TLS certificate that a server presents to it when it connects to a server. More This setting serves as an additional step for authenticating connections to indexers. A value of "true" means that the client inspects and validates the certificate that it receives from the server upon connecting to it. This ensures that the server you are connecting to has a valid TLS/SSL certificate. The client then checks both the Common Name and the Subject Alternative Name of the server in the certificate for a match. If the validation check does not pass, the client terminates the handshake between it and the server immediately, which terminates the connection. NOTE: Certificates that contain the same X.509 Common Name as a certificate authority (CA) certificate are not suitable for this validation check, even if the same CA issued the certificate. A value of "false" means that the client does not check the TLS certificate that it receives as part of the session negotiation. The client considers any valid TLS certificate as acceptable	false
`[httpout]` `tlsHostname`	`<string>`The host name of the server that the client is trying to reach when it initiates a TLS connection to that server. More As part of the TLS handshake, when a client connects to a server, the client can provide that server with the host name it was trying to reach when it initiated the connection. This prevents problems with mismatches of Common Names when the TLS connection begins. This is called Server Name Indication (SNI), and is an extension of the TLS protocol. The client performs SNI during the TLS Client Hello.	empty string
`[httpout]` `sslVerifyServerName`	`<boolean>`Whether or not splunkd, as a client, performs a TLS hostname validation check on a TLS certificate that it receives upon an initial connection to a server. More A TLS hostname validation check ensures that a client communicates with the correct server, and has not been redirected to another by a machine-in-the-middle attack, where a malicious party inserts themselves between the client and the target server, and impersonates that server during the session. Specifically, the validation check forces splunkd to verify that either the Common Name or the Subject Alternative Name in the certificate that the server presents to the client matches the host name portion of the URL that the client used to connect to the server. For this setting to have any effect, the 'sslVerifyServerCert' setting must have a value of "true". If it doesn't, TLS hostname validation is not possible because certificate verification is not on. A value of "true" for this setting means that splunkd performs a TLS hostname validation check, in effect, verifying the server's name in the certificate. If that check fails, splunkd terminates the TLS handshake immediately. This terminates the connection between the client and the server. Splunkd logs this failure at the ERROR logging level. A value of "false" means that splunkd does not perform the TLS hostname validation check. If the server presents an otherwise valid certificate, the client-to-server connection proceeds normally.	false
`[httpout]` `sslCommonNameToCheck`	`<comma-separated list>`One or more Common Names of the server certificate that the client checks against when it connects to a server using TLS. More The Common Name (CN) is an X.509 standard field in a certificate that identifies the host name that is associated with the certificate. The CN can be a short host name or a fully qualified domain name. For example, the CN can be one of "example", "www.example.com", or "example.com". If the client cannot match the CN in the certificate that the server presents, then the client cannot authenticate the server, and terminates the session negotiation immediately. For this setting to have any affect, the 'sslVerifyServerCert' setting must have a value of "true". This setting is optional.	empty string (no common name checking).
`[httpout]` `sslAltNameToCheck`	`<comma-separated list>`One or more Subject Alternative Names of the server certificate that the client checks against when it connects to a server using TLS. More The Subject Alternative Name (SAN) is an extension to the X.509 standard that lets you specify additional host names for a TLS certificate. The SAN can be a short host name or a fully qualified domain name. If the client cannot match the SAN in the certificate that the server presents, then the client cannot authenticate the server, and terminates the session negotiation immediately. For this setting to have any affect, the 'sslVerifyServerCert' setting must have a value of "true". This setting is optional.	empty string (no alternate name checking)
`[httpout]` `useClientSSLCompression`	`<boolean>`Whether or not compression of network traffic that passes through a TLS/SSL connection is turned on. More Server-side compression in splunkd is on by default. Configuring this setting on the client side enables compression between both server and client. If server-side compression is off, this client-side setting has no effect. A value of "true" means TLS/SSL compression is turned on. A value of "false" means TLS/SSL compression is turned off. If you use this setting, the 'tcpout_connections' group in the metrics.log file shows throughput values before compression occurs. SSL compression is not supported in TLS version 1.3.	true
`[httpout]` `sslQuietShutdown`	`<boolean>`DEPRECATED. More See the description of 'sslQuietShutdown' in the [default] section for details on this setting.	false
`[httpout]` `sslVersions`	`<comma-separated list>`The list of TLS versions to support for secure network connections. More The versions available are "tls1.0", "tls1.1", "tls1.2", and "tls1.3". The special version "*" selects all supported versions. The version "tls" selects all versions tls1.0 or newer If you prefix a version with "-", it is removed from the list. SSL versions 2 and 3 are always disabled. "-ssl2" and "-ssl3" are accepted as values in the version list, but have no effect. The default can vary. See the 'sslVersions' setting in $SPLUNK_HOME/etc/system/default/outputs.conf for the current default.

`[syslog]`

Setting	Description	Default
`[syslog]` `defaultGroup`	`<target_group>, <target_group>, ...`See 'dropEventsOnQueueFull' in the "[tcpout]" stanza for information on this setting.
`[syslog]` `dropEventsOnQueueFull`	`<integer>[ms\|s\|m]`See 'dropEventsOnQueueFull' in the "[tcpout]" stanza for information on this setting.
`[syslog]` `dropClonedEventsOnQueueFull`	`<integer>[ms\|s\|m]`See 'dropClonedEventsOnQueueFull' in the "[tcpout]" stanza for information on this setting.
`[syslog]` `type`	`[tcp\|udp]`No description in the spec.
`[syslog]` `priority`	`<<integer>> \| NO_PRI`No description in the spec.
`[syslog]` `maxEventSize`	`<integer>`No description in the spec.

`[syslog:<target_group>]`

Setting	Description	Default
`[syslog:<target_group>]` `server`	`[<ip>\|<servername>]:<port>`The IP address or server name and port where the syslog server is running. More Required. This setting specifies the port on which the syslog server listens.	514
`[syslog:<target_group>]` `type`	`[tcp\|udp]`The network protocol to use.	udp
`[syslog:<target_group>]` `priority`	`<<integer>>\|NO_PRI`The priority value included at the beginning of each syslog message. More The priority value ranges from 0 to 191 and is made up of a Facility value and a Level value. Enclose the priority value in "<>" delimeters. For example, specify a priority of 34 as follows: <34> The integer must be one to three digits in length. The value you enter appears in the syslog header. The value mimics the number passed by a syslog interface call. See the nix man page for syslog for more information. Calculate the priority value as follows: Facility 8 + Severity For example, if Facility is 4 (security/authorization messages) and Severity is 2 (critical conditions), the priority will be (4 * 8) + 2 = 34. Set the setting to <34>. If you do not want to add a priority value, set the priority to "<NO_PRI>". The table of facility and severity (and their values) is located in RFC3164. For example, http://www.ietf.org/rfc/rfc3164.txt section 4.1.1 The table is reproduced briefly below. Some values are outdated. Facility: 0 kernel messages 1 user-level messages 2 mail system 3 system daemons 4 security/authorization messages 5 messages generated internally by syslogd 6 line printer subsystem 7 network news subsystem 8 UUCP subsystem 9 clock daemon 10 security/authorization messages 11 FTP daemon 12 NTP subsystem 13 log audit 14 log alert 15 clock daemon 16 local use 0 (local0) 17 local use 1 (local1) 18 local use 2 (local2) 19 local use 3 (local3) 20 local use 4 (local4) 21 local use 5 (local5) 22 local use 6 (local6) 23 local use 7 (local7) Severity: 0 Emergency: system is unusable 1 Alert: action must be taken immediately 2 Critical: critical conditions 3 Error: error conditions 4 Warning: warning conditions 5 Notice: normal but significant condition 6 Informational: informational messages 7 Debug: debug-level messages	<13> (Facility of "user" and Severity of "Notice")
`[syslog:<target_group>]` `syslogSourceType`	`<string>`Specifies an additional rule for handling data, in addition to that provided by the 'syslog' source type. More This string is used as a substring match against the sourcetype key. For example, if the string is set to "syslog", then all sourcetypes containing the string 'syslog' receive this special treatment. To match a sourcetype explicitly, use the pattern "sourcetype::sourcetype_name". Example: syslogSourceType = sourcetype::apache_common Data that is "syslog" or matches this setting is assumed to already be in syslog format. Data that does not match the rules has a header, optionally a timestamp (if defined in 'timestampformat'), and a hostname added to the front of the event. This is how Splunk software causes arbitrary log data to match syslog expectations.	No default
`[syslog:<target_group>]` `timestampformat`	`<format>`If specified, Splunk software prepends formatted timestamps to events forwarded to syslog. More As above, this logic is only applied when the data is not syslog, or the type specified in the 'syslogSourceType' setting, because it is assumed to already be in syslog format. If the data is not in syslog-compliant format and you do not specify a 'timestampformat', the output will not be RFC3164-compliant. The format is a strftime (string format time)-style timestamp formatting string. This is the same implementation used in the 'eval' search command, Splunk logging, and other places in splunkd. For example: %b %e %H:%M:%S for RFC3164-compliant output %b - Abbreviated month name (Jan, Feb, ...) %e - Day of month %H - Hour %M - Minute %s - Second For a more exhaustive list of the formatting specifiers, refer to the online documentation. Do not put the string in quotes. No default. No timestamp is added to the front of events.
`[syslog:<target_group>]` `maxEventSize`	`<integer>`The maximum size of an event, in bytes, that Splunk software will transmit. More All events exceeding this size are truncated. Optional.	1024

`[indexAndForward]`

Setting	Description	Default
`[indexAndForward]` `index`	`<boolean>`Whether or not indexing is enabled on a Splunk platform instance. More A value of "true" means the Splunk platform instance indexes data. A value of "false" means the Splunk platform instance does not index data. The default can vary. It depends on whether the Splunk platform instance is configured as a forwarder, and whether it is modified by any value configured for the 'indexAndForward' setting in the [tcpout] stanza.
`[indexAndForward]` `selectiveIndexing`	`<boolean>`Whether or not to index specific events that have the '_INDEX_AND_FORWARD_ROUTING' setting configured. More A value of "true" means you can choose to index only specific events that have the '_INDEX_AND_FORWARD_ROUTING' setting configured. Configure the '_INDEX_AND_FORWARD_ROUTING' setting in inputs.conf as: [<input_stanza>] _INDEX_AND_FORWARD_ROUTING = local	false

`[indexer_discovery:<name>]`

Setting	Description	Default
`[indexer_discovery:<name>]` `pass4SymmKey`	`<string>`The security key used to communicate between the cluster manager and the forwarders. More This value must be the same for all forwarders and the manager node. You must explicitly set this value for each forwarder. If you specify a password here, you must also specify the same password on the manager node identified by the 'manager_uri' setting.
`[indexer_discovery:<name>]` `send_timeout`	`<decimal>`The low-level timeout, in seconds, for sending messages to the manager node. More Fractional seconds are allowed (for example, 60.95 seconds).	30
`[indexer_discovery:<name>]` `rcv_timeout`	`<decimal>`The low-level timeout, in seconds, for receiving messages from the manager node. More Fractional seconds are allowed (for example, 60.95 seconds).	30
`[indexer_discovery:<name>]` `cxn_timeout`	`<decimal>`The low-level timeout, in seconds, for connecting to the manager node. More Fractional seconds are allowed (for example, 60.95 seconds).	30
`[indexer_discovery:<name>]` `manager_uri`	`<string>`The URI and management port of the cluster manager used in indexer discovery. More For example, https://SplunkManager01.example.com:8089
`[indexer_discovery:<name>]` `master_uri`	`<string>`DEPRECATED. Use the 'manager_uri' setting instead.

`[remote_queue:<name>]`

This section explains possible settings for configuring a remote queue.
Each remote_queue stanza represents an individually configured remote queue output.
NOTE: Only ONE remote queue stanza is supported as an output queue.

Setting	Description	Default
`[remote_queue:<name>]` `remote_queue.*`	`<string>`Optional. More This section explains possible settings for configuring a remote queue. With remote queues, the splunk indexer might require additional configuration, specific to the type of remote queue. You can pass configuration information to the splunk indexer by specifying the settings through the following schema: remote_queue.<scheme>.<config-variable> = <value>. For example: remote_queue.sqs_smartbus.access_key = ACCESS_KEY This setting is optional.	No default
`[remote_queue:<name>]` `remote_queue.type`	`[sqs_smartbus\|asq\|gcs_smartbus]`The remote queue type. More This type can be one of the following: "sqs_smartbus" (Amazon Web Services (AWS) Simple Queue Service Smartbus) "asq" (Azure Storage Queue (ASQ)) "gcs_smartbus" (Google Publisher/Subscriber) If you specify this setting, you must configure it with a valid value. If you do not, the remote queue that is associated with the 'remote.queue.<name>' stanza in which this setting is configured will not start.	No default
`[remote_queue:<name>]` `compressed`	`<boolean>`See the description for TCPOUT SETTINGS in outputs.conf.spec.
`[remote_queue:<name>]` `negotiateProtocolLevel`	`<unsigned integer>`See the description for TCPOUT SETTINGS in outputs.conf.spec.
`[remote_queue:<name>]` `channelReapInterval`	`<integer>`See the description for TCPOUT SETTINGS in outputs.conf.spec.
`[remote_queue:<name>]` `channelTTL`	`<integer>`See the description for TCPOUT SETTINGS in outputs.conf.spec.
`[remote_queue:<name>]` `channelReapLowater`	`<integer>`See the description for TCPOUT SETTINGS in outputs.conf.spec.
`[remote_queue:<name>]` `concurrentChannelLimit`	`<unsigned integer>`See the description for [splunktcp] in inputs.conf.spec.
`[remote_queue:<name>]` `remote_queue.sqs_smartbus.encoding_format`	`protobuf\|s2s`Specifies the encoding format used to write data to the remote queue.	protobuf
`[remote_queue:<name>]` `remote_queue.sqs_smartbus.access_key`	`<string>`The access key to use when authenticating with the remote queue system that supports the SQS API. More If not specified, the splunk instance looks for the environment variables AWS_ACCESS_KEY_ID or AWS_ACCESS_KEY (in that order). If the environment variables are not set and the forwarder is running on EC2, the splunk instance attempts to use the secret key from the IAM (Identity and Access Management) role. Optional.	not set
`[remote_queue:<name>]` `remote_queue.sqs_smartbus.secret_key`	`<string>`Specifies the secret key to use when authenticating with the remote queue system supporting the SQS API. More If not specified, the splunk instance looks for the environment variables AWS_SECRET_ACCESS_KEY or AWS_SECRET_KEY (in that order). If the environment variables are not set and the forwarder is running on EC2, the splunk instance attempts to use the secret key from the IAM (Identity and Access Management) role. Optional.	not set
`[remote_queue:<name>]` `remote_queue.sqs_smartbus.auth_region`	`<string>`Optional. More The authentication region to use when signing the requests while interacting with the remote queue system supporting the Simple Queue Service (SQS) API. If not specified and the splunk instance is running on EC2, the auth_region is constructed automatically based on the EC2 region of the instance where the the splunk instance is running.	not set
`[remote_queue:<name>]` `remote_queue.sqs_smartbus.endpoint`	`<string>`The URL of the remote queue system supporting the Simple Queue Service (SQS) API. More Use the scheme, either http or https, to enable or disable SSL connectivity with the endpoint. If not specified, the endpoint is constructed automatically based on the auth_region as follows: https://sqs.<auth_region>.amazonaws.com If specified, the endpoint must match the effective auth_region, which is either a value specified via the 'remote_queue.sqs.auth_region' setting or a value constructed automatically based on the EC2 region of the running instance. Example: https://sqs.us-west-2.amazonaws.com/ Optional.
`[remote_queue:<name>]` `remote_queue.sqs_smartbus.message_group_id`	`<string>`Specifies the Message Group ID for Amazon Web Services Simple Queue Service (SQS) First-In, First-Out (FIFO) queues. More Setting a Message Group ID controls how messages within an AWS SQS queue are processed. For information on SQS FIFO queues and how messages in those queues are processed, see "Recommendations for FIFO queues" in the AWS SQS Developer Guide. If you configure this setting, Splunk software assumes that the SQS queue is a FIFO queue, and that messages in the queue should be processed first-in, first-out. Otherwise, Splunk software assumes that the SQS queue is a standard queue. Can be between 1-128 alphanumeric or punctuation characters. NOTE: FIFO queues must have Content-Based De-duplication enabled. Optional.	not set
`[remote_queue:<name>]` `remote_queue.sqs_smartbus.retry_policy`	`max_count\|none`Sets the retry policy to use for remote queue operations. More Optional. A retry policy specifies whether and how to retry file operations that fail for those failures that might be intermittent. Retry policies: + "max_count": Imposes a maximum number of times a queue operation is retried upon intermittent failure. Set max_count with the 'max_count.max_retries_per_part' setting. + "none": Do not retry file operations upon failure.	max_count
`[remote_queue:<name>]` `remote_queue.sqs_smartbus.max_count.max_retries_per_part`	`<unsigned integer>`When the 'remote_queue.sqs_smartbus.retry_policy' setting is "max_count", sets the maximum number of times a queue operation will be retried upon intermittent failure. More Optional.	3
`[remote_queue:<name>]` `remote_queue.sqs_smartbus.timeout.connect`	`<unsigned integer>`Sets the connection timeout, in milliseconds, to use when interacting with the SQS for this queue. More Optional.	5000
`[remote_queue:<name>]` `remote_queue.sqs_smartbus.timeout.read`	`<unsigned integer>`Sets the read timeout, in milliseconds, to use when interacting with the SQS for this queue. More Optional.	60000
`[remote_queue:<name>]` `remote_queue.sqs_smartbus.timeout.write`	`<unsigned integer>`Sets the write timeout, in milliseconds, to use when interacting with the SQS for this queue. More Optional.	60000
`[remote_queue:<name>]` `remote_queue.sqs_smartbus.large_message_store.endpoint`	`<string>`The URL of the remote storage system supporting the S3 API. More Use the scheme, either http or https, to enable or disable SSL connectivity with the endpoint. If not specified, the endpoint is constructed automatically based on the auth_region as follows: https://s3.<auth_region>.amazonaws.com If specified, the endpoint must match the effective auth_region, which is either a value specified via 'remote_queue.sqs_smartbus.auth_region' or a value constructed automatically based on the EC2 region of the running instance. Example: https://s3.us-west-2.amazonaws.com/ Optional.	not set
`[remote_queue:<name>]` `remote_queue.sqs_smartbus.large_message_store.path`	`<string>`The remote storage location where messages larger than the underlying queue's maximum message size will reside. More The format for this value is: <scheme>://<remote-location-specifier> The "scheme" identifies a supported external storage system type. The "remote-location-specifier" is an external system-specific string for identifying a location inside the storage system. The following external systems are supported: Object stores that support AWS's S3 protocol. These stores use the scheme "s3". For example, "path=s3://mybucket/some/path". If not specified, the queue drops messages exceeding the underlying queue's maximum message size. Optional.	not set
`[remote_queue:<name>]` `remote_queue.sqs_smartbus.large_message_store.sslVerifyServerCert`	`<boolean>`If set to true, the Splunk platform verifies the certificate presented by the S3 server and checks that the common name and alternative name match the ones specified in 'remote_queue.sqs_smartbus.large_message_store.sslCommonNameToCheck' and 'remote_queue.sqs_smartbus.large_message_store.sslAltNameToCheck'.	false
`[remote_queue:<name>]` `remote_queue.sqs_smartbus.large_message_store.sslVersions`	`<comma-separated list>`The list of TLS versions to use to connect to 'remote.sqs_smartbus.large_message_store.endpoint'. More The versions available are "tls1.0", "tls1.1", "tls1.2", and "tls1.3". The special version "*" selects all supported versions. The version "tls" selects all versions tls1.0 or newer. If a version is prefixed with "-" it is removed from the list. SSL versions 2 and 3 are always disabled. "-ssl2" and "-ssl3" are accepted as values in the version list, but have no effect.	tls1.2,tls1.3
`[remote_queue:<name>]` `remote_queue.sqs_smartbus.large_message_store.sslCommonNameToCheck`	If this value is set, and 'remote_queue.sqs_smartbus.large_message_store.sslVerifyServerCert' is set to true, the Splunk platform instance checks the common name of the certificate presented by the remote server (specified in 'remote_queue.sqs_smartbus.large_message_store.endpoint') against this list of common names.	not set
`[remote_queue:<name>]` `remote_queue.sqs_smartbus.large_message_store.sslAltNameToCheck`	`<comma-separated list>`If this value is set, and 'remote_queue.sqs_smartbus.large_message_store.sslVerifyServerCert' is set to true, the Splunk platform instance checks the alternate name(s) of the certificate presented by the remote server (specified in 'remote_queue.sqs_smartbus.large_message_store.endpoint') against this list of subject alternate names.	not set
`[remote_queue:<name>]` `remote_queue.sqs_smartbus.large_message_store.sslRootCAPath`	`<path>`Full path to the Certificate Authority (CA) certificate PEM format file containing one or more certificates concatenated together. S3 certificate will be validated against the CAs present in this file.	The value of [sslConfig]/'caCertFile' in server.conf
`[remote_queue:<name>]` `remote_queue.sqs_smartbus.large_message_store.cipherSuite`	`<cipher suite string>`If set, uses the specified cipher string for the SSL connection. More If not set, uses the default cipher string. Must specify 'dhFile' to enable any Diffie-Hellman ciphers.	TLSv1+HIGH:TLSv1.2+HIGH:@STRENGTH
`[remote_queue:<name>]` `remote_queue.sqs_smartbus.large_message_store.ecdhCurves`	`<comma-separated list>`ECDH curves to use for ECDH key negotiation. More Specify the curves in the order of preference. The client sends these curves as a part of Client Hello. Splunk software only supports named curves specified by their short names. The list of valid named curves by their short/long names can be obtained by executing this command: $SPLUNK_HOME/bin/splunk cmd openssl ecparam -list_curves e.g. ecdhCurves = prime256v1,secp384r1,secp521r1	not set
`[remote_queue:<name>]` `remote_queue.sqs_smartbus.large_message_store.dhFile`	`<string>`PEM format Diffie-Hellman parameter file name. More DH group size must be no less than 2048bits. This file is required in order to enable any Diffie-Hellman ciphers. Optional.	not set
`[remote_queue:<name>]` `remote_queue.sqs_smartbus.send_interval`	`<number><unit>`Optional. More The interval that the remote queue output processor waits for data to arrive before sending a partial batch to the remote queue. Examples: 100ms, 5s	4s
`[remote_queue:<name>]` `remote_queue.sqs_smartbus.consume_interval`	`<number><unit>`Optional. More The interval that the remote output worker consumes from data queue. Examples: 50ms, 1s	100ms
`[remote_queue:<name>]` `remote_queue.sqs_smartbus.max_queue_message_size`	`<integer>[KB\|MB\|GB]`The maximum message size for batched events for upload to the remote queue. More Queue messages contain a series of one or more events. When an event causes the message size to exceed this setting, the message is sent to the remote queue. Specify this value as an integer followed by KB, MB, or GB (for example, 10MB is 10 megabytes)	10MB
`[remote_queue:<name>]` `remote_queue.sqs_smartbus.enable_data_integrity_checks`	`<boolean>`If "true", Splunk software sets the data checksum in the metadata field of the HTTP header during upload operation to S3. More The checksum is used to verify the integrity of the data on uploads.	false
`[remote_queue:<name>]` `remote_queue.sqs_smartbus.enable_signed_payloads`	`<boolean>`If "true", Splunk software signs the payload during upload operation to S3. More This setting is valid only for remote.s3.signature_version = v4	true
`[remote_queue:<name>]` `remote_queue.sqs_smartbus.drop_data`	`<boolean>`Determines whether Splunk software drops the data from all Splunk managed internal indexes and indexes listed in 'remote_queue.sqs_smartbus.drop_data_index_list' More A value of "true" means that Splunk software drops the data.	false
`[remote_queue:<name>]` `remote_queue.sqs_smartbus.drop_data_index_list`	`<comma-separated list>`A comma-separated list of indexes for which you want to drop the data. For example: index_1, index_2, index_3. More If 'remote_queue.sqs_smartbus.drop_data' is set to "true" then Splunk software drops the data from 'drop_data_index_list'.	not set
`[remote_queue:<name>]` `remote_queue.sqs_smartbus.executor_max_workers_count`	`<positive integer>`The maximum number of worker threads available per pipeline set to execute SQS output worker tasks. More A value of 0 is equivalent to 1. The maximum value for this setting is 20.	10
`[remote_queue:<name>]` `remote_queue.sqs_smartbus.executor_max_jobs_count`	`<positive integer>`The maximum number of jobs that each worker thread per pipeline set can queue. More A value of 0 is equivalent to 1. The maximum value for this setting is 100.	50
`[remote_queue:<name>]` `remote_queue.sqs_smartbus.large_message_store.encryption_scheme`	`sse-s3 \| sse-c \| none`The encryption scheme used by remote storage.	none.
`[remote_queue:<name>]` `remote_queue.sqs_smartbus.large_message_store.kms_endpoint`	`<string>`The endpoint to connect to for generating KMS keys. More This setting is required if 'large_message_store.encryption_scheme' is set to sse-c. Examples: https://kms.us-east-2.amazonaws.com	No default
`[remote_queue:<name>]` `remote_queue.sqs_smartbus.large_message_store.key_id`	`<string>`The ID for the primary key that KMS uses to generate a data key pair. The primary key is stored in AWS. More This setting is required if 'large_message_store.encryption_scheme' is set to sse-c. Examples: alias/sqsssekeytrial, 23456789-abcd-1234-11aa-c50f99011223	No default
`[remote_queue:<name>]` `remote_queue.sqs_smartbus.large_message_store.key_refresh_interval`	`<string>`The time interval to refresh primary key.	24h
`[remote_queue:<name>]` `remote_queue.sqs_smartbus.enable_inline_data`	`<boolean>`Specifies whether to bypass S3 and use SQS directly to send events. More A value of "true" means that if the data packet is small enough to fit in SQS (256KB max), the Splunk Cloud Platform will use SQS to send event data. This setting only applies when remote_queue.sqs_smartbus.encoding_format=protobuf	false
`[remote_queue:<name>]` `remote_queue.sqs_smartbus.check_replication_enabled`	`<boolean>`Specifies whether to enable cross-region replication status checks of uploaded ingest blobs on remote storage.	false
`[remote_queue:<name>]` `remote_queue.sqs_smartbus.check_replication_interval`	`<number><unit>`Optional. More The interval that the remote queue output processor waits before checking the replication status of an uploaded ingest blob on remote storage. Examples: 100ms, 5s	60s
`[remote_queue:<name>]` `remote_queue.sqs_smartbus.check_replication_executor_max_workers_count`	`<positive integer>`The maximum number of worker threads available per pipeline set to execute SQS output replication related tasks such as replication status checks. More A value of 0 is equivalent to 5.	5
`[remote_queue:<name>]` `remote_queue.sqs_smartbus.check_replication_executor_max_jobs_count`	`<positive integer>`The maximum number of jobs that each replication executor worker thread per pipeline set can queue. More A value of 0 is equivalent to 1000.	1000
`[remote_queue:<name>]` `remote_queue.sqs_smartbus.enable_shared_receipts`	`<boolean>`If "true", receipts will be shared among ingest blobs.	false
`[remote_queue:<name>]` `remote_queue.asq.encoding_format`	`protobuf\|s2s`Specifies the encoding format used to write data to the remote queue.	s2s
`[remote_queue:<name>]` `remote_queue.asq.enable_inline_data`	`<boolean>`Specifies whether to use ASQ directly to send events. More A value of "true" means that if the data packet is small enough to fit in ASQ (64KB max), the Splunk Cloud Platform will use ASQ to send event data. This setting only applies when remote_queue.asq.encoding_format = protobuf	false
`[remote_queue:<name>]` `remote_queue.asq.access_key`	`<string>`The access key to use when authenticating with the remote queue system that supports the ASQ API.	not set
`[remote_queue:<name>]` `remote_queue.asq.secret_key`	`<string>`Specifies the secret key to use when authenticating with the remote queue system supporting the ASQ API.	not set
`[remote_queue:<name>]` `remote_queue.asq.endpoint`	`<string>`The URL of the remote queue system supporting the ASQ API. More Example: https://somestorage.queue.core.windows.net/	not set
`[remote_queue:<name>]` `remote_queue.asq.retry_policy`	`[max_count\|none]`The retry policy to use for remote queue operations. More A retry policy specifies whether and how to retry file operations that fail for those failures that might be intermittent. Retry policies: + "max_count": Imposes a maximum number of times a queue operation can be retried upon intermittent failure. Set max_count with the 'max_count.max_retries_in_total' setting. + "none": Do not retry file operations upon failure. This setting is optional.	"max_count"
`[remote_queue:<name>]` `remote_queue.asq.max_count.max_retries_in_total`	`<unsigned integer>`When 'remote_queue.asq.retry_policy' is set to "max_count", sets the maximum number of times a queue operation can be retried upon intermittent failure. More This setting is optional.	3
`[remote_queue:<name>]` `remote_queue.asq.timeout.connect`	`<unsigned integer>`The connection timeout, in seconds, when interacting with ASQ for this queue. More This setting is optional.	5
`[remote_queue:<name>]` `remote_queue.asq.timeout.read`	`<unsigned integer>`The read timeout, in seconds, when interacting with ASQ for this queue. More This setting is optional.	60
`[remote_queue:<name>]` `remote_queue.asq.timeout.write`	`<unsigned integer>`The write timeout, in seconds, when interacting with ASQ for this queue. More This setting is optional.	60
`[remote_queue:<name>]` `remote_queue.asq.large_message_store.endpoint`	`<string>`The URL of the remote storage system supporting the Azure API. More Example: https://somestorage.blob.core.windows.net/	not set
`[remote_queue:<name>]` `remote_queue.asq.large_message_store.path`	`<string>`The remote storage location where messages that are larger than the underlying queue maximum message size will reside. More If not specified, messages exceeding the underlying queue's maximum message size are dropped. For Microsoft Azure Blob storage, this is specified as "azure://<container-name>/path_to_blob" Note that "<container-name>" is needed here only if 'remote_queue.asq.large_message_store.container_name' is not set.	No default
`[remote_queue:<name>]` `remote_queue.asq.large_message_store.container_name`	`<string>`Specifies the Azure container to use complying with Microsoft Azure Storage Container naming convention. More This setting is optional.	No default
`[remote_queue:<name>]` `remote_queue.asq.large_message_store.sslVerifyServerCert`	`<boolean>`If set to true, the Splunk platform verifies the certificate presented by the Azure server.	false
`[remote_queue:<name>]` `remote_queue.asq.large_message_store.sslVersions`	`<comma-separated list>`The list of TLS versions to use to connect to 'remote.asq.large_message_store.endpoint'. More The versions available are "tls1.0", "tls1.1", "tls1.2", and "tls1.3". The special version "*" selects all supported versions. The version "tls" selects all versions tls1.0 or newer. If a version is prefixed with "-" it is removed from the list. SSL versions 2 and 3 are always disabled. "-ssl2" and "-ssl3" are accepted as values in the version list, but have no effect.	tls1.2,tls1.3
`[remote_queue:<name>]` `remote_queue.asq.large_message_store.sslRootCAPath`	`<path>`Full path to the Certificate Authority (CA) certificate PEM format file containing one or more certificates concatenated together. The S3 certificate will be validated against the CAs present in this file.	[sslConfig/caCertFile] in server.conf
`[remote_queue:<name>]` `remote_queue.asq.large_message_store.cipherSuite`	`<cipher suite string>`If set, uses the specified cipher string for the SSL connection. More If not set, uses the default cipher string.	TLSv1+HIGH:TLSv1.2+HIGH:@STRENGTH
`[remote_queue:<name>]` `remote_queue.asq.send_interval`	`<number><unit>`Optional. More The interval that the remote queue output processor waits for data to arrive before sending a partial batch to the remote queue. Examples: 100ms, 5s	4s
`[remote_queue:<name>]` `remote_queue.asq.max_queue_message_size`	`<integer>[KB\|MB\|GB]`The maximum message size for batched events for upload to the remote queue. More Queue messages contain a series of one or more events. When an event causes the message size to exceed this setting, the message is sent to the remote queue. Specify this value as an integer followed by KB, MB, or GB (for example, 10MB is 10 megabytes)	10MB
`[remote_queue:<name>]` `remote_queue.asq.drop_data`	`<boolean>`Determines whether Splunk software drops the data from all Splunk managed internal indexes and indexes listed in 'remote_queue.asq.drop_data_index_list' More A value of "true" means that Splunk software drops the data.	false
`[remote_queue:<name>]` `remote_queue.asq.drop_data_index_list`	`<comma-separated list>`A comma-separated list of indexes for which you want to drop the data. For example: index_1, index_2, index_3. More If 'remote_queue.asq.drop_data' is set to "true" then Splunk software drops the data from 'drop_data_index_list'.	not set
`[remote_queue:<name>]` `remote_queue.asq.executor_max_workers_count`	`<positive integer>`The maximum number of worker threads available per pipeline set to execute ASQ output worker tasks. More A value of 0 is equivalent to 1. The maximum value for this setting is 20.	10
`[remote_queue:<name>]` `remote_queue.asq.executor_max_jobs_count`	`<positive integer>`The maximum number of jobs that each worker thread per pipeline set can queue. More A value of 0 is equivalent to 1. The maximum value for this setting is 100.	50
`[remote_queue:<name>]` `remote_queue.asq.large_message_store.encryption_scheme`	`azure-sse-kv \| azure-sse-ms \| azure-sse-c`The encryption scheme to use for containers that are currently being stored. More azure-sse-kv: Maps to the Azure customer-managed keys in a key vault. See the Azure documentation for customer-managed keys for Azure Store encryption for details. azure-sse-ms: Maps to the Azure Microsoft-managed keys in Microsoft key store. See the Azure documentation for Azure Storage encryption for data at rest for details. azure-sse-c: Maps to the Azure customer-provided encryption keys in a Key Vault. See the Azure documentation for customer-provided keys for Azure Store encryption for details.	azure-sse-ms
`[remote_queue:<name>]` `remote_queue.asq.azure-sse-kv.encryptionScope`	`<string>`Required if remote_queue.asq.large_message_store.encryption_scheme = azure-sse-kv More Specifies the key used for encrypting blobs within the scope of this index.	No default
`[remote_queue:<name>]` `remote_queue.asq.large_message_store.azure-sse-c.key_type`	`azure_kv`The mechanism that a Splunk platform indexer uses to generate the key for sending data to Azure Storage. More Affects the 'azure-sse-c' encryption scheme only. The only valid value is "azure_kv", which indicates the Azure Key Vault Key Management Service (Azure KMS). You must also specify the required KMS settings: 'remote_queue.asq.large_message_store.azure-sse-c.azure_kv.key_name', 'remote_queue.asq.large_message_store.azure-sse-c.azure_kv.endpoint', 'remote_queue.asq.large_message_store.azure-sse-c.azure_kv.key_vault_tenant_id', 'remote_queue.asq.large_message_store.azure-sse-c.azure_kv.key_vault_client_id', and 'remote_queue.asq.large_message_store.azure-sse-c.azure_kv.key_vault_client_secret'. If you do not specify those settings, the indexer cannot start while the 'remote_queue.asq.large_message_store.encryption_scheme' setting has a value of "azure-sse-c".	azure_kv
`[remote_queue:<name>]` `remote_queue.asq.large_message_store.azure-sse-c.azure_kv.key_name`	`<string>`The Azure Key Vault key name for key encryption and decryption. More Required if 'remote_queue.asq.large_message_store.encryption_scheme' has a value of "azure-sse-c".	No default
`[remote_queue:<name>]` `remote_queue.asq.large_message_store.azure-sse-c.azure_kv.endpoint`	`<string>`The Azure Key Vault endpoint. More Required if 'remote_queue.asq.large_message_store.encryption_scheme' has a value of "azure-sse-c". Example: "https://<key-vault-name>.vault.azure.net/"	No default
`[remote_queue:<name>]` `remote_queue.asq.large_message_store.azure-sse-c.azure_kv.key_vault_tenant_id`	`<string>`The ID of the Azure Active Directory tenant for authenticating with the the Key Vault. More For more details about the tenant ID, check your Azure Active Directory subscription. Required only for client token-based authentication.	No default
`[remote_queue:<name>]` `remote_queue.asq.large_message_store.azure-sse-c.azure_kv.key_vault_client_id`	`<string>`Specifies the ID of the client, also called the application ID, which is the unique identifier that the Azure Active Directory issues to an application registration that identifies a specific application and the associated configurations. More You can obtain the client ID for an application from the Azure Portal in the Overview section for the registered application. Required only for client token-based authentication. Optional for managed identity authentication.	No default
`[remote_queue:<name>]` `remote_queue.asq.large_message_store.azure-sse-c.azure_kv.key_vault_client_secret`	`<string>`Specifies the secret key to use when authenticating the Key Vault using the client_id. More You generate the secret key through the Azure Portal. Required only for client token-based authentication.	No default
`[remote_queue:<name>]` `remote_queue.asq.large_message_store.enable_shared_receipts`	`<boolean>`If "true", receipts will be shared among ingest blobs.	false
`[remote_queue:<name>]` `remote_queue.gcs_smartbus.project_id`	`<string>`The Google Cloud project ID where the Pub/Sub topic resides and large message storage buckets are located. More This is required to authenticate and interact with the Pub/Sub API.	not set
`[remote_queue:<name>]` `remote_queue.gcs_smartbus.large_message_store.path`	`<string>`The path to the large message store.	not set
`[remote_queue:<name>]` `remote_queue.gcs_smartbus.pubsub_endpoint`	`<string>`The URL for the Publisher/Subscriber (Pub/Sub) Application Programming Interface (API) endpoint that the Splunk platform uses for connections. More You can use this setting to specify a custom endpoint for testing or for private Google Cloud environments. If you do not give this setting a value, the Splunk platform uses the standard Google Cloud Pub/Sub endpoint.	not set
`[remote_queue:<name>]` `remote_queue.gcs_smartbus.storage_endpoint`	`<string>`The URL for the Google Cloud Storage endpoint that the Splunk platform uses for large message storage. More You can use this setting to specify a custom endpoint for testing, using private endpoints, or connecting to compatible storage services. If you do not give this setting a value, the Splunk platform uses the standard Google Cloud Storage endpoint. Example: https://storage.googleapis.com	No default
`[remote_queue:<name>]` `remote_queue.gcs_smartbus.encoding_format`	`protobuf\|s2s`The encoding format that Google Cloud Services uses to write data to the remote queue.	s2s
`[remote_queue:<name>]` `remote_queue.gcs_smartbus.enable_inline_data`	`<boolean>`Whether or not to use gcs_smartbus directly to send events. More A value of "true" means that if the data packet is small enough to fit into gcs_smartbus, Splunk Cloud Platform uses gcs_smartbus to send event data, otherwise, it sends the packet to remote storage, as well as sending its URI to the gcs_smartbus remote queue. A value of "false" means that Splunk Cloud Platform always sends the data packet to remote storage, as well as sending the data packet URI to the gcs_smartbus remote queue. This setting only applies when 'remote_queue.gcs_smartbus.encoding_format' has a value of "protobuf".	false
`[remote_queue:<name>]` `remote_queue.gcs_smartbus.send_interval`	`<number><unit>`The interval that the remote queue output processor waits for data to arrive before sending a partial batch to the remote queue. More If you do not provide a <unit> for this setting value, the Splunk platform assumes that the value is in seconds. Examples: 100ms, 5s This setting is optional.	4
`[remote_queue:<name>]` `remote_queue.gcs_smartbus.credential_file`	`<string>`Specifies the credential file that is used for Pub/Sub and large message storage authentication. More This file contains the service account credentials in JSON format. The service account must have the following roles: Pub/Sub Publisher Pub/Sub Subscriber Storage Object Admin This file must be located in $SPLUNK_HOME/etc/auth/ Example: credentials.json	No default
`[remote_queue:<name>]` `remote_queue.gcs_smartbus.large_message_store.connectUsingIpVersion`	`auto\|4-only\|6-only`Controls whether Splunk software makes outbound connections to the storage service using IPv4 or IPv6. More Connections to literal IPv4 or IPv6 addresses are unaffected by this setting. A value of "4-only" means that splunkd only attempts to connect to the IPv4 address. A value of "6-only" means that splunkd only attempts to connect to the IPv6 address. A value of "auto" means: If '[general]/listenOnIPv6' in server.conf has a value of "only", this setting defaults to "6-only". Otherwise, this setting defaults to "4-only".	auto
`[remote_queue:<name>]` `remote_queue.gcs_smartbus.large_message_store.sslVersionsForClient`	`tls1.0\|tls1.1\|tls1.2\|tls1.3`Defines the minimum SSL/TLS version to use for outgoing connections.	tls1.2
`[remote_queue:<name>]` `remote_queue.gcs_smartbus.large_message_store.sslVerifyServerCert`	`<boolean>`A value of "true" means that splunkd authenticates the certificate of the services it connects to by using the configured Certificate Authority (CA).	false
`[remote_queue:<name>]` `remote_queue.gcs_smartbus.large_message_store.sslVerifyServerName`	`<boolean>`Controls whether splunkd, as a client, performs a TLS hostname validation check on an SSL certificate that it receives upon an initial connection to a server. More A TLS hostname validation check ensures that a client communicates with the correct server. This check prevents redirection to another server by a machine-in-the-middle attack, where a malicious party inserts themselves between the client and the target server and impersonates that server. Specifically, the validation check forces splunkd to verify that the certificate that the server presents to the client has a Common Name or Subject Alternate Name that matches the host name portion of the URL that the client used to connect to the server. For this setting to have any effect, the 'sslVerifyServerCert' setting must have a value of "true". If 'sslVerifyServerCert' is set to "false", TLS hostname validation is not possible because certificate verification is not turned on. A value of "true" for this setting means that splunkd performs a TLS hostname validation check, verifying the server's name in the certificate. If that check fails, Splunk software terminates the SSL handshake immediately, which terminates the connection. Splunkd logs this failure at the ERROR logging level. A value of "false" for this setting means that splunkd does not perform the TLS hostname validation check. If the server presents an otherwise valid certificate, the client-to-server connection proceeds normally.	false
`[remote_queue:<name>]` `remote_queue.gcs_smartbus.large_message_store.sslRootCAPath`	`<path>`Full path to the Certificate Authority (CA) certificate PEM format file that contains one or more certificates concatenated together. The server certificate will be validated against the CAs present in this file.	[sslConfig/caCertFile] in server.conf
`[remote_queue:<name>]` `remote_queue.gcs_smartbus.large_message_store.cipherSuite`	`<cipher suite string>`Uses the specified cipher string for the SSL connection. More If this setting is not configured, splunkd uses the default cipher string.	TLSv1+HIGH:TLSv1.2+HIGH:@STRENGTH
`[remote_queue:<name>]` `remote_queue.gcs_smartbus.large_message_store.encryption`	`gcp-sse-c\|gcp-sse-kms\|gcp-sse-gcp`The encryption scheme to use for index buckets while stored on Google Cloud Storage (data-at-rest). More A value of "gcp-sse-c" maps to Google Cloud Platform (GCP) customer-supplied encryption keys. A value of "gcp-sse-kms" maps to GCP customer-managed encryption keys. A value of "gcp-sse-gcp" maps to GCP Google-managed encryption keys. Google Cloud always encrypts the incoming data on the server side. For the "gcp-sse-kms" scheme, you must grant your Cloud Storage service account permission to use your Cloud KMS key. For more details, search for "Assigning a Cloud KMS key to a service account" on the Google Cloud documentation site. To find your Cloud Storage service account, search for "Getting the Cloud Storage service account".	gcp-sse-gcp
`[remote_queue:<name>]` `remote_queue.gcs_smartbus.large_message_store.gcp_kms.locations`	`<string>`Required if 'remote_queue.gcs_smartbus.large_message_store.encryption' has a value of "gcp-sse-c" or "gcp-sse-kms". More Specifies the geographical regions where Key Management Service (KMS) key rings and keys are stored for access. Google Cloud offers three types of locations: regional locations such as "us-central1", dual-regional locations such as "nam4", and multi-regional locations such as "global" and "us". Search for "Cloud KMS locations" on the Google Cloud documentation site for a complete list. For best performance, choose a key ring and a key in the same location as the cloud stack.	No default
`[remote_queue:<name>]` `remote_queue.gcs_smartbus.large_message_store.gcp_kms.key_ring`	`<string>`Required if 'remote_queue.gcs_smartbus.large_message_store.encryption' has a value of "gcp-sse-c" or "gcp-sse-kms". More Specifies the name of the key ring used for encryption when uploading data to Google Cloud Storage. In Google Cloud, a key ring is a grouping of keys for organizational purposes. A key ring belongs to a Google Cloud Project and resides in a specific location. Search for "key ring" on the Google Cloud documentation site for more details.	No default
`[remote_queue:<name>]` `remote_queue.gcs_smartbus.large_message_store.gcp_kms.key`	`<string>`Required if 'remote_queue.gcs_smartbus.large_message_store.encryption' has a value of "gcp-sse-c" or "gcp-sse-kms". More Specifies the name of the encryption key used for uploading data to Google Cloud Storage.	No default
`[remote_queue:<name>]` `remote_queue.gcs_smartbus.large_message_store.encryption.gcp-sse-c.key_type`	`gcp_kms`Affects only the "gcp-sse-c" encryption scheme. More Identifies the mechanism the indexer uses to generate the key for sending data to Google Cloud Storage. The only valid value is "gcp_kms", which indicates Google Cloud Key Management Service (GCP KMS). You must also specify the following required Key Management Service (KMS) settings: 'remote_queue.gcs_smartbus.large_message_store.gcp_kms.locations' 'remote_queue.gcs_smartbus.large_message_store.gcp_kms.key_ring' 'remote_queue.gcs_smartbus.large_message_store.gcp_kms.key' If you do not specify these settings, the indexer cannot start while it uses "gcp-sse-c" encryption.	gcp_kms
`[remote_queue:<name>]` `remote_queue.gcs_smartbus.large_message_store.encryption.gcp-sse-c.key_refresh_interval`	`<unsigned integer>`Specifies the interval, in seconds, for generating a new key that is used for encrypting data uploaded to Google Cloud Storage.	86400
`[remote_queue:<name>]` `remote_queue.gcs_smartbus.retry_policy_option`	`<number><unit>`The maximum amount of time that Pub/Sub will attempt to publish a message. More This setting determines how long the publisher retries message delivery. This is separate from the backoff, which configures how long the publisher waits between attempts. If you do not provide a <unit> for this setting value, the Splunk platform assumes that the value is in seconds. Example: 1m (1 minute), 30s (30 seconds), 50ms (50 milliseconds), 10 (10 seconds)	20
`[remote_queue:<name>]` `remote_queue.gcs_smartbus.back_off_policy_option.initial`	`<number><unit>`The initial backoff duration for Pub/Sub operations. More When a Pub/Sub operation results in a failure, this setting determines how long to initially wait before attempting the operation again. If you do not provide a <unit> for this setting value, the Splunk platform assumes that the value is in seconds. Example: 1m (1 minute), 30s (30 seconds), 50ms (50 milliseconds), 10 (10 seconds)	100ms
`[remote_queue:<name>]` `remote_queue.gcs_smartbus.back_off_policy_option.max`	`<number><unit>`The maximum backoff duration for Pub/Sub operations. More This is the longest amount of time that the publisher will back off, after scaling up its backoff time in the face of multiple Pub/Sub operation failures. If you do not provide a <unit> for this setting value, the Splunk platform assumes that the value is in seconds. Example: 1m (1 minute), 30s (30 seconds), 50ms (50 milliseconds), 10 (10 seconds)	60
`[remote_queue:<name>]` `remote_queue.gcs_smartbus.back_off_policy_option.scaling`	`<decimal>`The scaling to use for exponential backoff for Pub/Sub operations. More On each subsequent failure, the remote queue increases the backoff time by this multiplier. For example, 2.0 means the backoff is doubled after each failure.	1.3
`[remote_queue:<name>]` `remote_queue.gcs_smartbus.max_hold_time_option`	`<number><unit>`The maximum time that the publisher holds a message before it flushes the message as part of Pub/Sub operations. More If you do not provide a <unit> for this setting value, the Splunk platform assumes the value is in seconds. Example: 1m (1 minute), 30s (30 seconds), 50ms (50 milliseconds), 10 (10 seconds)	10ms
`[remote_queue:<name>]` `remote_queue.gcs_smartbus.max_pending_messages_option`	`<integer>`The maximum number of pending messages for Pub/Sub operations. More A value of "0" means to use server-side configurations.	0 (use server-side configurations)

`[rfs]`

Global settings that individual rfs output destinations can inherit.

Setting	Description	Default
`[rfs]` `partitionBy`	`legacy \| (year\|month\|day) [, sourcetype]`Specifies schema to partition and store events into seperate files on the rfsoutput destination(s). It affects the file storage location specified by the "path" for any given destination in the manner described below. More legacy - no partitioning and the events are batched together on the order of arrival. This appends path segments that encode the latest timestamp among all events in the batch similar to the strftime format "%Y/%m/%d". year\|month\|day - span of event timestamp to use as the primary partition key. This encodes primary field as multiple path segments and appends to the path in the decreasing order of significance. For example, "day" produces "year=%Y/month=%m/day=%d", "month" produces "year=%Y/month=%m" and "year" produces "year=%Y". sourcetype - optional secondary partition key applied over primary partition key. This appends a single path segment encoded in the form "sourcetype=<sourcetype>". Examples: Illustrated below is the set of possible settings and how they affect the file storage path, for events generated on August 15, 2022. partitionBy = day, sourcetype Results file path into "<path>/year=2022/month=08/day=15/sourcetype=<srctype>/" partitionBy = day Results file path into "<path>/year=2022/month=08/day=15/" partitionBy = month Results file path into "<path>/year=2022/month=08/" partitionBy = year Results file path into "<path>/year=2022/" partitionBy = legacy Results file path into "<path>/2022/08/15/"	legacy
`[rfs]` `dropEventsOnUploadError`	`<boolean>`Whether or not the ingest actions feature drops events if it encounters an error when uploading events to output destination. More A value of "true" means that, if there is an error writing to the destination, the error will be logged, and the events in that batch dropped. Ingest will not be blocked, but data might be lost. A value of "false" means, if there is an error writing to the destination, the error will be logged, and events will NOT be dropped. splunkd will continually attempt to write the batch. Because events are not dropped, this might cause queues to become blocked, and data ingestion to stop. This setting is optional.	false
`[rfs]` `batchSizeThresholdKB`	`<integer>`The size, in kilobytes, of the uncompressed events in the RfsOutputProcessor send buffer. RfsOutputProcessor batches events before writing them into files on the destination. If the current buffer size is greater than 'batchSizeThresholdKB' kilobytes, then the data will be written to the destination immediately. More This threshold may not be honored if the total memory usage for raw events exceeds limits.conf/[ingest_actions]/rfs.provider.rawdata_limit_mb for a storage provider. If you increase this setting, you may also want to increase the value of server.conf/[queue:rfsQueue]/maxSize. Not applicable if the rfs destination is a file system destination; that is, if the pathname starts with 'file://'. Max threshold value: 5242880 (5 GiB)	131072 (128 MiB)
`[rfs]` `batchTimeout`	`<integer>`RfsOutputProcessor batches events before flushing to the destination. More If a batch has not hit any other criteria for being flushed, and the batch is at least this many seconds old, flush the batch. This threshold may not be honored if the total memory usage for raw events exceeds limits.conf/[ingest_actions]/rfs.provider.rawdata_limit_mb for a storage provider. For an S3 destination, the maximum allowed 'batchTimeout' value is 1800 seconds (30 minutes). Default = 30
`[rfs]` `compression`	`none\|gzip\|lz4\|zstd`Sets the algorithm to use for compressing files before writing to the destination. More The RfsOutputProcessor writes files with the appropriate extension for the compression algorithm, for example, .zst for zstd, .gz for gzip and .lz4 for lz4. To change the compression setting, delete the destination and recreate again with desired compression type.	zstd
`[rfs]` `compressionLevel`	`<integer>`Sets compression level for the specified compression algorithm, when RfsOutputProcessor writes files. Must be between 0 and 10.	3
`[rfs]` `format`	`json\|ndjson\|raw`Specifies output format when RfsOutputProcessor writes events into files on the destination. More json: The file will include a JSON array. Each event will be element of the JSON array. ndjson: The file will include multiple JSON objects separated by a newline character. Each event is corresponding to one JSON object. raw: The file includes multiple raw events separated by a newline character.	json
`[rfs]` `format.json.index_time_fields`	`<boolean>`Specifies whether to include index-time fields when RfsOutputProcessor writes events to the destination in HEC JSON format.	true
`[rfs]` `format.ndjson.index_time_fields`	`<boolean>`Specifies whether to include index-time fields when RfsOutputProcessor writes events to the destination in new line delimited JSON format.	true
`[rfs]` `fs.appendToFileUntilSizeMB`	`<integer>`Applicable only if rfs destination is a file system (local or nfs) destination. More For file system, rfs output will create one active output file for each hour of that partition and will continuously append the events in its respective hourly output file. Note: For file system, only partitionBy = day[, sourcetype] is allowed. Once the size of the output file for the current hour exceeds fs.appendToFileUntilSizeMB, a new hourly output file with a new sequence number will be created. The recommended value for fs.appendToFileUntilSizeMB is the default value, 2048. Do not set the value below 250, otherwise this threshold might not be honored, causing file size to potentially be much larger. Output file size may not be precisely equal to fs.appendToFileUntilSizeMB, as it depends on how much data can be fetched from the pipeline. To ensure file size is similar to the given value for fs.appendToFileUntilSizeMB, set fs.appendToFileUntilSizeMB to 2048 or larger. Max threshold value: 17180 (16 GiB)	2048
`[rfs]` `fs.timeBeforeClosingFileSecs`	`<integer>`Applicable only if rfs destination is a file system (local or nfs) destination. More After every batchTimeout seconds, the instance checks whether an open file descriptor has not been used within the last fs.timeBeforeClosingFileSecs seconds. If so, the instance closes the file descriptor. Do not manually remove the destination files while the instance has the file descriptor opened. Doing so can result in data loss. A high value setting can result in less file descriptor availability for other system uses. The effective closing time for an open file descriptor can be in a range from batchTimeout to (batchTimeout + fs.timeBeforeClosingFileSecs) Must be set to a non-zero positive number. Otherwise, the value is overridden by the default value specified in the global [rfs] stanza.	30

`[rfs:<name>]`

This section explains the configuration settings for the ingest actions feature to send data to an external storage interface, such as AWS S3 or a file-system mount.
Each [rfs:<name>] stanza represents an individually configured location.
The "name" is a unique identifier for the storage destination, and is shown as a routing destination when using the ingest actions UI. For example: [rfs:syslog_filtered_events], [rfs:threat_detection_logs] etc.

Setting	Description	Default
`[rfs:<name>]` `path`	`<string>`Required. More This setting points to the storage location where files would be stored. The format for specifying storage location is: <scheme>://<storage-location-specifier> The "scheme" identifies the storage interface used. Currently "s3" and "file" are the only supported schemes. The "storage-location-specifier" is a system-specific string for identifying a location inside the storage system. For AWS S3, this is specified as "path=s3://mybucket/some/path" For filesystem interface, this is specified as "file://my/local/path"
`[rfs:<name>]` `description`	`<string>`Optional. More A general description to explain the configuration settings for the ingest actions feature to send data to a destination.	No default
`[rfs:<name>]` `remote.*`	`<string>`Optional. More This section explains possible settings for configuring a remote output. With remote outputs, the splunk indexer might require additional configuration, specific to the type of remote storage. You can pass configuration information to the splunk indexer by specifying the settings through the following schema: remote_queue.<scheme>.<config-variable> = <value>. For example: remote.s3.access_key = ACCESS_KEY Refer to "Volume settings" in indexes.conf for all settings. This setting is optional.	No default
`[rfs:<name>]` `remote.s3.access_key`	`<string>`Specifies the access key to use when authenticating with the remote storage system supporting the S3 API. More If not specified, the indexer will look for these environment variables: AWS_ACCESS_KEY_ID or AWS_ACCESS_KEY (in that order). If the environment variables are not set and the indexer is running on EC2, the indexer attempts to use the access key from the IAM role. Optional.	No default
`[rfs:<name>]` `remote.s3.secret_key`	`<string>`Specifies the secret key to use when authenticating with the remote storage system supporting the S3 API. More If not specified, the indexer will look for these environment variables: AWS_SECRET_ACCESS_KEY or AWS_SECRET_KEY (in that order). If the environment variables are not set and the indexer is running on EC2, the indexer attempts to use the secret key from the IAM role. Optional.	No default
`[rfs:<name>]` `remote.s3.signature_version`	`v2\|v4`The signature version to use when authenticating with the remote storage system supporting the S3 API. More For 'sse-kms' and 'sse-c' server-side encryption schemes, and for 'cse' client-side encryption scheme, you must use signature_version=v4. For signature_version=v2 you must set url_version=v1. Optional.	v4
`[rfs:<name>]` `remote.s3.url_version`	`v1\|v2`Specifies which url version to use, both for parsing the endpoint/path, and More for communicating with the remote storage. This value only needs to be specified when running on non-AWS S3-compatible storage that has been configured to use v2 urls. In v1 the bucket is the first element of the path. Example: mydomain.com/bucketname/rest/of/path In v2 the bucket is the outermost subdomain in the endpoint. Exmaple: bucketname.mydomain.com/rest/of/path	v1
`[rfs:<name>]` `remote.s3.supports_versioning`	`<boolean>`Specifies whether the remote storage supports versioning. More Versioning is a means of keeping multiple variants of an object in the same bucket on the remote storage. This setting determines how splunkd removes data from remote storage. If set to true, splunkd will delete all versions of objects at time of data removal. Otherwise, if set to false, splunkd will use a simple DELETE (See https://docs.aws.amazon.com/AmazonS3/latest/dev/DeletingObjectVersions.html). Optional.	true
`[rfs:<name>]` `remote.s3.endpoint`	`<URL>`The URL of the remote storage system supporting the S3 API. More The scheme, http or https, can be used to enable or disable SSL connectivity with the endpoint. If not specified and the indexer is running on EC2, the endpoint will be constructed automatically based on the EC2 region of the instance where the indexer is running, as follows: https://<bucketname>.s3.<region>.amazonaws.com Example: https://<bucketname>.s3.us-west-2.amazonaws.com Optional.
`[rfs:<name>]` `remote.s3.encryption`	`sse-s3 \| sse-kms \| none`The encryption scheme to use for output to remote storage for data stored (data at rest). More sse-s3: Search for "Protecting Data Using Server-Side Encryption with AWS S3-Managed Encryption Keys" on the Amazon Web Services documentation site. sse-kms: Search for "Protecting Data Using Server-Side Encryption with CMKs Stored in AWS Key Management Service (SSE-KMS)" on the Amazon Web Services documentation site. Note: sse-c is not supported for RfsOutputProcessor Optional.	No default
`[rfs:<name>]` `remote.s3.auth_region`	`<string>`The authentication region to use for signing requests when interacting with the remote storage system supporting the S3 API. More Used with v4 signatures only. If unset and the endpoint (either automatically constructed or explicitly set with remote.s3.endpoint setting) uses an AWS URL (for example, https://<bucketname>.s3.us-west-1.amazonaws.com), the instance attempts to extract the value from the endpoint URL (for example, "us-west-1"). See the description for the remote.s3.endpoint setting. If unset and an authentication region cannot be determined, the request will be signed with an empty region value. This can lead to rejected requests when using non-AWS S3-compatible storage. Optional.	No default
`[rfs:<name>]` `remote.s3.retry_policy`	`max_count`Sets the retry policy to use for remote file operations. More A retry policy specifies whether and how to retry file operations that fail for those failures that might be intermittent. Retry policies: + "max_count": Imposes a maximum number of times a file operation will be retried upon intermittent failure both for individual parts of a multipart download or upload and for files as a whole. Optional.	max_count
`[rfs:<name>]` `remote.s3.sslVerifyServerCert`	`<boolean>`If this is set to true, Splunk verifies certificate presented by S3 server and checks that the common name/alternate name matches the ones specified in 'remote.s3.sslCommonNameToCheck' and 'remote.s3.sslAltNameToCheck'. More Optional	false
`[rfs:<name>]` `remote.s3.sslVersions`	`<comma-separated list>`The list of TLS versions to use to connect to 'remote.s3.endpoint'. More The versions available are "tls1.0", "tls1.1", "tls1.2", and "tls1.3". The special version "*" selects all supported versions. The version "tls" selects all versions tls1.0 or newer. If a version is prefixed with "-" it is removed from the list. SSL versions 2 and 3 are always disabled. "-ssl2" and "-ssl3" are accepted as values in the version list, but have no effect. Optional.	tls1.2,tls1.3
`[rfs:<name>]` `remote.s3.sslCommonNameToCheck`	`<commonName1>, <commonName2>, ..`If this value is set, and 'remote.s3.sslVerifyServerCert' is set to true, splunkd checks the common name of the certificate presented by the remote server (specified in 'remote.s3.endpoint') against this list of common names.	not set
`[rfs:<name>]` `remote.s3.sslAltNameToCheck`	`<alternateName1>, <alternateName2>, ..`If this value is set, and 'remote.s3.sslVerifyServerCert' is set to true, splunkd checks the alternate name(s) of the certificate presented by the remote server (specified in 'remote.s3.endpoint') against this list of subject alternate names.	No default
`[rfs:<name>]` `remote.s3.sslRootCAPath`	`<path>`Full path to the Certificate Authority (CA) certificate PEM format file containing one or more certificates concatenated together. S3 certificate will be validated against the CAs present in this file. More Optional.	The value of '[sslConfig]/caCertFile' in server.conf
`[rfs:<name>]` `remote.s3.cipherSuite`	`<cipher suite string>`If set, uses the specified cipher string for the SSL connection. More If not set, uses the default cipher string. Must specify 'dhFile' to enable any Diffie-Hellman ciphers. Optional.	TLSv1+HIGH:TLSv1.2+HIGH:@STRENGTH
`[rfs:<name>]` `remote.s3.ecdhCurves`	`<comma-separated list>`ECDH curves to use for ECDH key negotiation. More The curves should be specified in the order of preference. The client sends these curves as a part of Client Hello. Splunk software only supports named curves specified by their SHORT names. The list of valid named curves by their short/long names can be obtained by executing this command: $SPLUNK_HOME/bin/splunk cmd openssl ecparam -list_curves e.g. ecdhCurves = prime256v1,secp384r1,secp521r1 Optional.	No default
`[rfs:<name>]` `remote.s3.kms.auth_region`	`<string>`Required if 'remote.s3.auth_region' is unset and Splunk can not automatically extract this information. More Similar to 'remote.s3.auth_region'. If not specified, KMS access uses 'remote.s3.auth_region'.	No default
`[rfs:<name>]` `remote.s3.kms.key_id`	`<string>`Required if remote.s3.encryption = sse-kms More Specifies the identifier for Customer Master Key (CMK) on KMS. It can be the unique key ID or the Amazon Resource Name (ARN) of the CMK or the alias name or ARN of an alias that refers to the CMK. Examples: Unique key ID: 1234abcd-12ab-34cd-56ef-1234567890ab CMK ARN: arn:aws:kms:us-east-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab Alias name: alias/ExampleAlias Alias ARN: arn:aws:kms:us-east-2:111122223333:alias/ExampleAlias	No default
`[rfs:<name>]` `remote.s3.kms.<ssl_settings>`	`<...>`Optional. More See the descriptions of the SSL settings for remote.s3.<ssl_settings> above. e.g. remote.s3.sslVerifyServerCert. Valid ssl_settings are sslVerifyServerCert, sslVersions, sslRootCAPath, sslAltNameToCheck, sslCommonNameToCheck, cipherSuite, ecdhCurves, and dhFile. All of these settings are optional. All of these settings have the same defaults as 'remote.s3.<ssl_settings>'.
`[rfs:<name>]` `remote.s3.metadata_max_attempts`	`<integer>`Imposes a maximum number of times an operation will be retried upon failing to retrieve credentials from EC2 metadata service endpoint. More This value must be between 1 and 10.	10
`[rfs:<name>]` `remote.sts.assume_role.role_arn`	`<string>`This feature is supported on Splunk Cloud only. More The Amazon Resource Name (ARN) of the role to assume. Normally, splunkd will use whatever credentials are available (i.e. access_key/secret_key, instance IAM roles, etc) to directly access AWS services, such as S3 and KMS. If this is set, instead of using those credentials directly, splunkd will contact the STS AssumeRole API to get credentials associated with the role here, and use that "assumed" role to access other services. Make sure only to specify this when need temporary security credentials to access AWS resources that you might not normally have access to. Example: arn:aws:iam::111122223333:role/SplunkIngestActions Only applicable when the rfs destination is an aws s3 destination (path starts with 's3://').	No default
`[rfs:<name>]` `remote.sts.assume_role.external_id`	`<string>`This feature is supported on Splunk Cloud only. More A unique identifier that might be required when you assume a role in another account. If the account to which the role belongs requires an external ID to assume, then must provide that value here.	No default
`[rfs:<name>]` `remote.sts.assume_role.duration_secs`	`<integer>`The duration, in seconds, of the role session. More The value specified can range from 900 seconds (15 minutes) up to the maximum session duration set for the role. If you specify a value higher than this setting or the administrator setting (whichever is lower), the operation fails. For example, if you specify a session duration of 12 hours, but your administrator set the maximum session duration to 6 hours, your operation fails.	3600
`[rfs:<name>]` `authMethod`	`<string>`The authentication method used to access the remote destination. More Optional. Do not configure this setting in outputs.conf. The system populates this setting when you choose an Authentication Method in the New or Edit Destination setup window in Splunk Web. Choosing “Access key and Secret key” in Splunk Web sets this setting to “basic”. Choosing “IAM role” in Splunk Web sets this setting to "iam".	No default
`[rfs:<name>]` `partitionBy`	`legacy \| (year\|month\|day) [, sourcetype]`Specifies schema to partition and store events forwarded to this destination. Any setting will override the global partitionBy settings of [rfs] stanza. Refer to the detailed description of this property under global [rfs] stanza and how it affects the file storage path.	Inherited partitionBy setting from the global [rfs] stanza.
`[rfs:<name>]` `dropEventsOnUploadError`	`<boolean>`Whether or not the ingest actions feature drops events if it encounters an error when uploading events to remote storage. More A value of "true" means that, if there is an error writing to a remote file system, the error will be logged, and the events in that batch dropped. Ingest will not be blocked, but data might be lost. A value of "false" means, if there is an error writing to a remote file system, the error will be logged, and events will NOT be dropped. splunkd will continually attempt to write the batch. Because events are not dropped, this might cause queues to become blocked, and data ingestion to stop. This setting is optional.	Inherited dropEventsOnUploadError setting from the global [rfs] stanza.
`[rfs:<name>]` `batchSizeThresholdKB`	`<integer>`The size, in kilobytes, of the uncompressed events in the RfsOutputProcessor send buffer. More RfsOutputProcessor batches events before flushing them to destination. If the current buffer size is greater than 'batchSizeThresholdKB' kilobytes, then the data will be written to the destination immediately. If you increase this setting, you may also want to increase the value of server.conf/[queue:rfsQueue]/maxSize. Not applicable if the rfs destination is a file system destination; that is, if the pathname starts with 'file://'	Inherited batchSizeThresholdKB setting from the global [rfs] stanza.
`[rfs:<name>]` `batchTimeout`	`<integer>`RfsOutputProcessor batches events before flushing to the destination. More If a batch has not hit any other criteria for being flushed, and the batch is at least this many seconds old, flush the batch. For an S3 destination, the maximum allowed 'batchTimeout' value is 1800 seconds (30 minutes).	Inherited batchTimeout setting from the global [rfs] stanza.
`[rfs:<name>]` `compression`	`none\|gzip\|lz4\|zstd`Sets the algorithm to use for compressing files before writing to the destination. More The RfsOutputProcessor writes files with the appropriate extension for the compression algorithm, for example, .zst for zstd, .gz for gzip and .lz4 for lz4.	Inherited compression setting from the global [rfs] stanza.
`[rfs:<name>]` `compressionLevel`	`<integer>`Sets compression level for the specified compression algorithm, when RfsOutputProcessor writes files. Must be between 0 and 10.	Inherited compressionLevel setting from the global [rfs] stanza.
`[rfs:<name>]` `format`	`json\|ndjson\|raw`Specifies output format when RfsOutputProcessor writes events into files on the destination. More json: The file will include a JSON array. Each event will be element of the JSON array. ndjson: The file will include multiple JSON objects separated by a newline character. Each event is corresponding to one JSON object. raw: The file includes multiple raw events separated by a newline character.	Inherited format setting from the global [rfs] stanza.
`[rfs:<name>]` `format.json.index_time_fields`	`<boolean>`Specifies whether to include index-time fields when RfsOutputProcessor writes events to the destination in HEC JSON format.	Inherited format.json.index_time_fields setting from the global [rfs] stanza.
`[rfs:<name>]` `format.ndjson.index_time_fields`	`<boolean>`Specifies whether to include index-time fields when RfsOutputProcessor writes events to the destination in new line delimited JSON format.	Inherited format.ndjson.index_time_fields setting from the global [rfs] stanza.
`[rfs:<name>]` `fs.appendToFileUntilSizeMB`	`<integer>`Applicable only if rfs destination is a file system (local or nfs) destination. More For file system, rfs output will create one active output file for each hour of that partition and will continuously append the events in its respective hourly output file. Note: For file system, only partitionBy = day[, sourcetype] is allowed. Once the size of the output file for the current hour exceeds fs.appendToFileUntilSizeMB, a new hourly output file with a new sequence number will be created. The recommended value for fs.appendToFileUntilSizeMB is the default value, 2048. Do not set the value below 250, otherwise this threshold might not be honored, causing file size to potentially be much larger. Output file size may not be precisely equal to fs.appendToFileUntilSizeMB, as it depends on how much data can be fetched from the pipeline. To ensure file size is similar to the given value for fs.appendToFileUntilSizeMB, set fs.appendToFileUntilSizeMB to 2048 or larger.	Inherited fs.appendToFileUntilSizeMB setting from the global [rfs] stanza.
`[rfs:<name>]` `fs.timeBeforeClosingFileSecs`	`<integer>`Applicable only if rfs destination is a file system (local or nfs) destination. More After every batchTimeout seconds, the instance checks whether an open file descriptor has not been used within the last fs.timeBeforeClosingFileSecs seconds. If so, the instance closes the file descriptor. Do not manually remove the destination files while the instance has the file descriptor opened. Doing so can result in data loss. A high value setting can result in less file descriptor availability for other system uses. The effective closing time for an open file descriptor can be in a range from batchTimeout to (batchTimeout + fs.timeBeforeClosingFileSecs) Must be set to a non-zero positive number. Otherwise, the value is overridden by the default value specified in the global [rfs] stanza.	Inherited fs.timeBeforeClosingFileSecs setting from the global [rfs] stanza.

Example

[tcpout]
defaultGroup = primary_indexers
autoLBFrequency = 30
useACK = true

[tcpout:primary_indexers]
server = idx1.example.com:9997, idx2.example.com:9997, idx3.example.com:9997
compressed = true
sslVerifyServerCert = true

[tcpout:dr_site]
server = idx-dr.example.com:9997
autoLB = false

[syslog:secops_siem]
server = siem.example.com:514
type = tcp
priority = <13>
syslogSourceType = cisco:asa

This forwarder sends most data, load-balanced and compressed, across three indexers in primary_indexers (the default group), while also maintaining a separate, non-load-balanced dr_site group for disaster-recovery routing, and forwards Cisco ASA events as plain syslog to a SIEM in parallel.

Validation

Confirm every group named in defaultGroup has a corresponding [tcpout:<group>] stanza -- a typo here silently sends no data anywhere.
Check compressed and TLS settings agree between the forwarder's outputs.conf and the receiving indexer's inputs.conf; a mismatch breaks the connection rather than degrading gracefully.
Decide on useACK deliberately -- it materially reduces data-loss risk during indexer outages but adds overhead, so weigh it against the source's actual loss tolerance.
Verify indexerDiscovery, if used, references a real [indexer_discovery:<name>] stanza in server.conf pointing at the correct Cluster Manager.
Remember sendCookedData = false is for non-Splunk raw-TCP receivers only -- setting it for a normal indexer destination breaks ingestion.
For syslog output, confirm the receiving SIEM's expected PRI/timestamp format matches priority/timestampformat, since syslog receivers are typically far stricter about format than a Splunk indexer.

← Back to References

References / Splunk platform configuration

Data Inputs Configuration

inputs.conf defines every way a Splunk instance collects raw data -- file/directory monitoring, network listeners, scripted and modular inputs, and HTTP Event Collector tokens. It has more stanza shapes than any other Splunk config file; this article covers the ones that back Splunk Taxonomy objects (Data Input, Modular Input, HTTP Event Collector Token, Threat Intelligence Framework, TI Feed, DB Connect), not the complete stanza catalogue.

Definition

An inputs.conf stanza tells a forwarder or indexer what to collect and how to label it. The stanza's URI-style prefix (monitor://, tcp://, script://, and so on) determines which collection mechanism handles it, and each mechanism accepts a different set of settings. The Splunk Taxonomy's generic Data Input object (SOT-05.01.01) represents this whole family; Modular Input and HTTP Event Collector Token are broken out separately because each has its own dedicated REST endpoint and a materially different configuration and delivery model.

Settings reflect stable, long-documented inputs.conf behaviour current as of recent Splunk Enterprise/Cloud releases. Confirm exact default values against the installed version's inputs.conf.spec before relying on a specific default in production.

File locations

Configuration file: inputs.conf.

Scope	Path
System	`$SPLUNK_HOME/etc/system/{default,local}/inputs.conf`
App	`$SPLUNK_HOME/etc/apps/<app_name>/{default,local}/inputs.conf`

A copy also stages on a Deployment Server at etc/deployment-apps/<app_name>/local before being pushed into clients' etc/apps.

Global defaults -- `[default]`

Settings placed under the bare [default] stanza apply to every other input stanza in the file unless that stanza sets its own value.

Setting	Description
`host`	Default host value assigned to events from any input stanza that doesn't set its own `host`.
`index`	Default index events are routed to when a stanza doesn't specify one.
`_TCP_ROUTING` / `_SYSLOG_ROUTING`	Names one or more `outputs.conf` target groups (Forwarding Group) this data should be routed to at index time, overriding `defaultGroup`.

File & directory inputs

Stanza	Purpose
`[monitor://<path>]`	Continuously tails a file or directory, indexing new data as it's appended.
`[batch://<path>]`	Reads a file once and then consumes it (moves or deletes the source) -- for one-shot drop-directory ingestion, not a continuously-written file.

Common settings

Setting	Applies to	Description
`disabled`	Both	Enables or disables the stanza without deleting it.
`sourcetype`	Both	Sourcetype assigned to events from this input.
`crcSalt`	Both	Adds a value (often `<SOURCE>`) into the CRC Splunk uses to detect already-indexed files -- needed when rotated files share identical leading content and would otherwise be seen as duplicates or skipped.
`ignoreOlderThan`	Both	Skips files whose modification time is older than the given time span, useful when pointing a new input at a directory with a large backlog.
`whitelist` / `blacklist`	Both	Regex filters on file name, restricting which files in a monitored directory are actually read.
`recursive`	monitor	Whether subdirectories under the monitored path are also watched.
`followTail`	monitor	For a brand-new input only: start reading from the end of existing files rather than from the beginning.
`host_segment`	monitor	Derives the `host` field from the Nth `/`-separated segment of the file path instead of a fixed value.
`move_policy`	batch	Must be set to `sinkhole` -- the only supported value, and what makes a batch input consume its source file.

Network inputs

Stanza	Purpose
`[tcp://<port>]`	Listens for raw, unparsed TCP data from an arbitrary sender (not another Splunk instance).
`[tcp-ssl://<port>]`	TLS-wrapped variant of a raw TCP input.
`[udp://<port>]`	Listens for UDP data -- the common choice for legacy syslog senders.
`[splunktcp://<port>]`	Receives cooked (parsed) data forwarded from another Splunk forwarder's `[tcpout]` output -- the receiving-side counterpart of Forwarding Group.

Common settings

Setting	Description
`connection_host`	How the `host` field is set from the connecting sender -- `ip`, `dns`, or `none` (use the configured default instead).
`sourcetype`	Sourcetype assigned to events received on this port.
`queueSize`	Size of the input's internal processing queue before it starts blocking.
`no_priority_stripping`	For UDP syslog senders: keep the leading `<priority>` value in the event text instead of stripping it.
`no_appending_timestamp`	For UDP syslog senders: don't append Splunk's own receipt timestamp to the event.
`requireClientCert`	For `tcp-ssl`: whether the connecting sender must present a valid client certificate.

Scripted & HTTP Event Collector inputs

Stanza	Purpose
`[script://<cmd>]`	Runs an external command or script on a schedule and indexes its output -- the mechanism a Modular Input is built on top of, with a standardised XML/REST configuration and validation contract layered over it.
`[http]`	Global HTTP Event Collector settings for the instance (port, SSL, default index/sourcetype for tokens that don't override them).
`[http://<token_name>]`	An individual HEC Token -- what Splunk Taxonomy's HTTP Event Collector (HEC) Token object represents.

Common settings

Setting	Applies to	Description
`interval`	script	How often the script runs -- a number of seconds, or a cron-style schedule expression.
`source`	script	Source value assigned to events the script produces.
`token`	http	The HEC token value clients present to authenticate; auto-generated when the token is created via Splunk Web or the REST API.
`useACK`	http	Enables indexer acknowledgement for events sent through this token, letting a sender confirm data was actually indexed.
`disabled`	Both	Enables or disables the stanza.
`index` / `sourcetype`	Both	Default index/sourcetype for data from this stanza, overridable per event in the HEC JSON envelope for `http://` tokens.

Windows inputs

A family of Windows-specific stanza types, most requiring the Splunk Universal Forwarder running on Windows.

Stanza	Purpose
`[WinEventLog://<name>]`	Monitors a Windows Event Log channel (Application, Security, System, or a custom channel).
`[perfmon://<name>]`	Polls Windows Performance Monitor counters.
`[admon://<name>]`	Monitors Active Directory for object changes.
`[WinRegMon://<name>]`	Monitors Windows Registry changes matching a configured regex.
`[WinNetMon://<name>]`	Monitors network connection events on the host.
`[WinHostMon://<name>]`	Polls host system information (installed applications, services, and similar).
`[WinPrintMon://<name>]`	Monitors print job and printer configuration events.

WMI and process monitoring have their own conf files. WMI-based remote polling (Splunk Taxonomy's WMI Collection Input) is configured in wmi.conf, and process start/stop filtering (Process Monitor Filter) in procmon-filters.conf -- both distinct from inputs.conf itself, even though they're conceptually part of the same Windows-input family.

All settings

Every stanza and setting in inputs.conf.spec from Splunk Enterprise 10.4.2: 500 settings across 35 stanzas. Descriptions use the spec's own wording -- the first line shows here and More opens the rest. The Default column is filled only where the spec gives a Default: line.

Settings outside any stanza

Setting	Description	Default
`host`	`<string>`Sets the host key/field to a static value for this input stanza. More The input uses this field during parsing and indexing. It also uses this field at search time. As a convenience, the input prepends the chosen string with 'host::'. When set to '$decideOnStartup', sets the field to the hostname of executing machine. The hostname is checked and the field set at every splunkd startup. If you run multiple instances of the software on the same machine (hardware or virtual machine), choose unique values for 'host' to differentiate your data, ex. myhost-sh-1 or myhost-idx-2. Do not put the <string> value in quotes. Use host=foo, not host="foo". When 'host' is set to "$decideOnStartup", you can further control how splunkd derives the hostname by using the 'hostnameOption' setting in server.conf. For example, if you want splunkd to use the fully qualified domain name for the machine, set "host = $decideOnStartup" in inputs.conf and "hostnameOption = fullyqualifiedname" in server.conf. More information on hostname options can be found in the server.conf specification file. If you remove the 'host' setting from $SPLUNK_HOME/etc/system/local/inputs.conf or remove $SPLUNK_HOME/etc/system/local/inputs.conf, the setting reverts to "$decideOnStartup". Apps that need a resolved host value should use the 'host_resolved' property in the response for the REST 'GET' call of the input source. This property is set to the hostname of the local Splunk instance. It is a read only property that is not written to inputs.conf.	"$decideOnStartup"
`run_only_one`	`<boolean>`Determines if a scripted or modular inputs runs on one search head in SHC. More Currently not supported. This setting is related to a feature that is still under development.	true
`index`	`<string>`Sets the index to store events from this input. More Primarily used to specify the index to store events that come in through this input stanza.	main (or whatever you have set as your default index)
`source`	`<string>`Sets the source key/field for events from this input. More Detail: Sets the source key initial value. The key is used during parsing/indexing, in particular to set the source field during indexing. It is also the source field used at search time. As a convenience, the chosen string is prepended with 'source::'. Avoid overriding the source key. The input layer provides a more accurate string to aid in problem analysis and investigation, recording the file from which the data was retrieved. Consider using source types, tagging, and search wildcards before overriding this value. Do not put the <string> value in quotes: Use source=foo, not source="foo".	the input file path
`sourcetype`	`<string>`Sets the sourcetype key/field for events from this input. More Explicitly declares the source type for this input instead of letting it be determined through automated methods. This is important for search and for applying the relevant configuration for this data type during parsing and indexing. Sets the sourcetype key initial value. The key is used during parsing or indexing to set the source type field during indexing. It is also the source type field used at search time. As a convenience, the chosen string is prepended with 'sourcetype::'. Do not put the <string> value in quotes: Use sourcetype=foo, not sourcetype="foo". If not set, the indexer analyzes the data and chooses a source type.	No default
`queue`	`[parsingQueue\|indexQueue]`Sets the queue where the input processor deposits the events it reads. More Set to "parsingQueue" to apply the props.conf file and other parsing rules to your data. For more information about the props.conf file and rules timestamps and linebreaks, see the props.conf file and the online documentation at http://docs.splunk.com/Documentation. Set to "indexQueue" to send your data directly into the index.	parsingQueue
`queue`	`<value>`Inputs have special support for mapping host, source, sourcetype, and index to their metadata names such as host -> Metadata:Host More Defaulting these values is not recommended, and is generally only useful as a workaround to other product issues. Defaulting these keys in most cases overrides the default behavior of input processors, but this behavior is not guaranteed in all cases. Values defaulted here, as with all values provided by inputs, can be altered by transforms at parse time.
`_raw`	`<value>`Inputs have special support for mapping host, source, sourcetype, and index to their metadata names such as host -> Metadata:Host More Defaulting these values is not recommended, and is generally only useful as a workaround to other product issues. Defaulting these keys in most cases overrides the default behavior of input processors, but this behavior is not guaranteed in all cases. Values defaulted here, as with all values provided by inputs, can be altered by transforms at parse time.
`_meta`	`<value>`Inputs have special support for mapping host, source, sourcetype, and index to their metadata names such as host -> Metadata:Host More Defaulting these values is not recommended, and is generally only useful as a workaround to other product issues. Defaulting these keys in most cases overrides the default behavior of input processors, but this behavior is not guaranteed in all cases. Values defaulted here, as with all values provided by inputs, can be altered by transforms at parse time.
`_time`	`<value>`Inputs have special support for mapping host, source, sourcetype, and index to their metadata names such as host -> Metadata:Host More Defaulting these values is not recommended, and is generally only useful as a workaround to other product issues. Defaulting these keys in most cases overrides the default behavior of input processors, but this behavior is not guaranteed in all cases. Values defaulted here, as with all values provided by inputs, can be altered by transforms at parse time.
`_TCP_ROUTING`	`<comma-separated list>`A comma-separated list of tcpout group names. More This setting lets you selectively forward data to one or more specific indexers. Specify the tcpout group that the forwarder uses when forwarding the data. The tcpout group names are defined in outputs.conf with [tcpout:<tcpout_group_name>]. To forward data to all tcpout group names that have been defined in outputs.conf, set to '' (asterisk). To forward data from the "_internal" index, you must explicitly set '_TCP_ROUTING' to either "" or a specific splunktcp target group.	The groups specified in 'defaultGroup' in [tcpout] stanza in the outputs.conf file
`_SYSLOG_ROUTING`	`<comma-separated list>`A comma-separated list of syslog group names. More Use this setting to selectively forward the data to specific destinations as syslog events. Specify the syslog group to use when forwarding the data. The syslog group names are defined in outputs.conf with [syslog:<syslog_group_name>]. The destination host must be configured in outputs.conf, using "server=[<ip>\|<servername>]:<port>". This setting does not work on a universal forwarder.	The groups specified in 'defaultGroup' in the [syslog] stanza in the outputs.conf file
`_INDEX_AND_FORWARD_ROUTING`	`<string>`If set for any input stanza, causes all data coming from that input stanza to be labeled with this setting. More When 'selectiveIndexing' is in use on a forwarder: Data without this label will not be indexed by that forwarder. Data with this label will be indexed in addition to any forwarding. This setting does not actually cause data to be forwarded or not forwarded in any way, nor does it control where the data is forwarded in multiple-forward path cases. Only has effect if you use the 'selectiveIndexing' feature in outputs.conf.	not set

`[blacklist:<path>]`

Protects files on the file system from being indexed or previewed through Splunk Web and REST API endpoints.
The input treats a file as denied if the file starts with any of the defined deny list <paths>.
Adding a file to the deny list with the specified path occurs even if a monitor stanza defines an allow list that matches the file path.
The preview endpoint returns an error when asked to preview an excluded file.
The 'oneshot' endpoint and command also return an error.
When a denied file is monitored, using monitor:// or batch://, the 'filestatus' endpoint shows an error.
For 'fschange' with the 'sendFullEvent' option enabled, contents of denied files are not indexed.
This stanza does not exclude file monitoring inputs. To protect files from being monitored, use the 'blacklist' setting inside the [monitor://<path>] stanza.

`[monitor://<path>]`

Configures a file monitor input to watch all files in the <path> you specify.
<path> can be an entire directory or a single file.
You must specify the input type and then the path, so put three slashes in your path if you are starting at the root on *nix systems (to include the slash that indicates an absolute path).

Setting	Description	Default
`[monitor://<path>]` `host_regex`	`<regular expression>`If specified, <regular expression> extracts host from the path to the file for each input file. More Detail: This feature examines the source key; if source is set explicitly in the stanza, that string is matched, not the original filename. Specifically, the first group of the regular expression (regex) is used as the host. If the regex fails to match, the input uses the default 'host' setting. If 'host_regex' and 'host_segment' are both set, the input ignores 'host_regex'.	No default
`[monitor://<path>]` `host_segment`	`<integer>`If set to N, the Splunk platform sets the Nth "/"-separated segment of the path as 'host'. More For example, if you set "host_segment = 3" and the path is /logs/servers/host08/abc.txt, the third segment, "host08", is used. If the value is not an integer or is less than 1, the default 'host' setting is used. On Windows machines, the drive letter and colon before the backslash does not count as one segment. For example, if you set "host_segment = 3" and the monitor path is D:\logs\servers\host01, Splunk software sets the host as "host01" because that is the third segment.	No default
`[monitor://<path>]` `whitelist`	`<regular expression>`If set, files from this input are monitored only if their path matches the specified regular expression. More Takes precedence over the deprecated '_whitelist' setting, which functions the same way.	No default
`[monitor://<path>]` `blacklist`	`<regular expression>`If set, files from this input are NOT monitored if their path matches the specified regex. More Takes precedence over the deprecated '_blacklist' setting, which functions the same way. If a file matches the regexes in both the deny list and allow list settings, the file is NOT monitored. Deny lists take precedence over allow lists. NOTE concerning wildcards and monitor: You can use wildcards to specify your input path for monitored inputs. Use "..." for recursive directory matching and "" for wildcard matching in a single directory segment. "..." searches recursively through one or more directories. This means that /foo/.../bar matches foo/1/bar, foo/1/2/bar, etc. You can use multiple "..." specifications in a single input path. For example: /foo/.../bar/... The asterisk () matches anything in a single path segment; unlike "...", it does not search recursively. For example, /foo//bar matches the files /foo/1/bar, /foo/2/bar, etc. However, it does not match /foo/bar or /foo/1/2/bar. A second example: /foo/mr/bar matches /foo/mr/bar, /foo/mir/bar, /foo/moor/bar, etc. It does not match /foo/mi/or/bar. You can combine "" and "..." as needed: foo/.../bar/ matches any file in the bar directory within the specified path. A monitor stanza path will interpret regular expression metacharacters as strings unless they are preceded by the wildcard values "*" or "..." in a prior segment of the path. In the case where multiple unique monitor inputs overlap through the use of wildcards or specific paths defined in the monitor stanza, the Splunk platform processes the files using the monitor stanza that is the closest specific match.	No default
`[monitor://<path>]` `crcSalt`	`<string>`Use this setting to force the input to consume files that have matching CRCs, or cyclic redundancy checks. More By default, the input only performs CRC checks against the first 256 bytes of a file. This behavior prevents the input from indexing the same file twice, even though you might have renamed it, as with rolling log files, for example. Because the CRC is based on only the first few lines of the file, it is possible for legitimately different files to have matching CRCs, particularly if they have identical headers. If set, <string> is added to the CRC. If set to the literal string "<SOURCE>" (including the angle brackets), the full directory path to the source file is added to the CRC. This ensures that each file being monitored has a unique CRC. When 'crcSalt' is invoked, it is usually set to <SOURCE>. Be cautious about using this setting with rolling log files; it could lead to the log file being re-indexed after it has rolled. In many situations, 'initCrcLength' can be used to achieve the same goals.	empty string
`[monitor://<path>]` `initCrcLength`	`<integer>`How much of a file, in bytes, that the input reads before trying to identify whether it has already seen the file. More You might want to adjust this if you have many files with common headers (comment headers, long CSV headers, etc) and recurring filenames. Cannot be less than 256 or more than 1048576. CAUTION: Improper use of this setting causes data to be re-indexed. You might want to consult with Splunk Support before adjusting this value - the default is fine for most installations.	256 (bytes)
`[monitor://<path>]` `ignoreOlderThan`	`<non-negative integer>[s\|m\|h\|d]`The monitor input compares the modification time on files it encounters with the current time. If the time elapsed since the modification time is greater than the value in this setting, Splunk software puts the file on the ignore list. More Files on the ignore list are not checked again until the Splunk platform restarts, or the file monitoring subsystem is reconfigured. This is true even if the file becomes newer again at a later time. Reconfigurations occur when changes are made to monitor or batch inputs through Splunk Web or the command line. Use 'ignoreOlderThan' to increase file monitoring performance when monitoring a directory hierarchy that contains many older, unchanging files, and when removing or adding a file to the deny list from the monitoring location is not a reasonable option. Do NOT select a time that files you want to read could reach in age, even temporarily. Take potential downtime into consideration! Suggested value: 14d, which means 2 weeks For example, a time window in significant numbers of days or small numbers of weeks are probably reasonable choices. If you need a time window in small numbers of days or hours, there are other approaches to consider for performant monitoring beyond the scope of this setting. NOTE: Most modern Windows file access APIs do not update file modification time while the file is open and being actively written to. Windows delays updating modification time until the file is closed. Therefore you might have to choose a larger time window on Windows hosts where files may be open for long time periods. Value must be: <number><unit>. For example, "7d" indicates one week. Valid units are "d" (days), "h" (hours), "m" (minutes), and "s" (seconds). No default, meaning there is no threshold and no files are ignored for modification time reasons
`[monitor://<path>]` `followTail`	`<boolean>`Whether or not the input should skip past current data in a monitored file for a given input stanza. More This setting lets you skip over data in files, and immediately begin indexing current data. If you set to "1", monitoring starts at the end of the file (like *nix 'tail -f'). The input does not read any data that exists in the file when it is first encountered. The input only reads data that arrives after the first encounter time. If you set to "0", monitoring starts at the beginning of the file. This is an advanced setting. Contact Splunk Support before using it. Best practice for using this setting: Enable this setting and start the Splunk instance. Wait enough time for the input to identify the related files. Disable the setting and restart the instance. Do not leave 'followTail' enabled in an ongoing fashion. Do not use 'followTail' for rolling log files (log files that get renamed as they age) or files whose names or paths vary.	0
`[monitor://<path>]` `alwaysOpenFile`	`<boolean>`Whether or not an input opens a file to check whether it has already been indexed, by skipping the modification time and size checks. More Only useful for files that do not update modification time or size. Only known to be needed when monitoring files on Windows, mostly for Internet Information Server logs. Configuring this setting to "1" can increase load and slow indexing. Use it only as a last resort.	0
`[monitor://<path>]` `time_before_close`	`<integer>`The amount of time, in seconds, that the file monitor must wait for modifications before closing a file after reaching an End-of-File (EOF) marker. More Tells the input not to close files that have been updated in the past 'time_before_close' seconds.	3
`[monitor://<path>]` `multiline_event_extra_waittime`	`<boolean>`Whether or not the file monitor input delays sending an event delimiter when it reads a file with multiple-line events, to account for the time it sometimes takes for lines of those events to arrive. More By default, the file monitor sends an event delimiter when: It reaches EOF of a file it monitors and The last character it reads is a newline. In some cases, it takes time for all lines of a multiple-line event to arrive. Set to "true" to delay sending an event delimiter until the time that the file monitor closes the file, as defined by the 'time_before_close' setting, to allow all event lines to arrive.	false
`[monitor://<path>]` `recursive`	`<boolean>`Whether or not the input monitors subdirectories that it finds within a monitored directory. More A value of "true" means the input monitors sub-directories. A value of "false" means the input does not monitor sub-directories.	true
`[monitor://<path>]` `followSymlink`	`<boolean>`Whether or not the input follows any symbolic links within a monitored directory. More A value of "true" means the input follows symbolic links and monitors files at the symbolic link destination. Additionally, any allow lists or deny lists that the input stanza defines also apply to files at the symbolic link destination. A value of "false" means the input ignores symbolic links that it finds within a monitored directory.	true
`[monitor://<path>]` `_whitelist`	`...`DEPRECATED. More This setting is valid unless the 'whitelist' setting also exists.
`[monitor://<path>]` `_blacklist`	`...`DEPRECATED. More This setting is valid unless the 'blacklist' setting also exists.

`[batch://<path>]`

A one-time, destructive input of files in <path>.
This stanza must include the 'move_policy = sinkhole' setting.
This input reads and indexes the files, then DELETES THEM IMMEDIATELY.
For continuous, non-destructive inputs of files, use 'monitor' instead.

Setting	Description	Default
`[batch://<path>]` `move_policy`	`sinkhole`This setting is required. You must include "move_policy = sinkhole" when you define batch inputs. More This setting causes the input to load the file destructively. CAUTION: Do not use the 'batch' input type for files you do not want to delete after indexing. The 'move_policy' setting exists for historical reasons, but remains as a safeguard. As an administrator, you must explicitly declare that you want the data in the monitored directory (and its sub-directories) to be deleted after being read and indexed.
`[batch://<path>]` `host_regex`	`see the definition in the MONITOR section.`Whether or not the Splunk platform writes an entry into the splunkd.log file when it indexes files with this input. More When set to "false", this setting prevents the Splunk platform from writing to splunkd.log when it indexes files with this input.	true
`[batch://<path>]` `host_segment`	`see the definition in the MONITOR section.`Whether or not the Splunk platform writes an entry into the splunkd.log file when it indexes files with this input. More When set to "false", this setting prevents the Splunk platform from writing to splunkd.log when it indexes files with this input.	true
`[batch://<path>]` `crcSalt`	`see the definition in the MONITOR section.`Whether or not the Splunk platform writes an entry into the splunkd.log file when it indexes files with this input. More When set to "false", this setting prevents the Splunk platform from writing to splunkd.log when it indexes files with this input.	true
`[batch://<path>]` `time_before_close`	`see the definition in the MONITOR section.`Whether or not the Splunk platform writes an entry into the splunkd.log file when it indexes files with this input. More When set to "false", this setting prevents the Splunk platform from writing to splunkd.log when it indexes files with this input.	true
`[batch://<path>]` `log_on_completion`	`<boolean>`Whether or not the Splunk platform writes an entry into the splunkd.log file when it indexes files with this input. More When set to "false", this setting prevents the Splunk platform from writing to splunkd.log when it indexes files with this input.	true
`[batch://<path>]` `followSymlink`	`<boolean>`Works similarly to the same setting for monitor, but does not delete files after following a symbolic link out of the monitored directory.
`[batch://<path>]` `host_regex`	`<regular expression>`No description in the spec.
`[batch://<path>]` `host_segment`	`<integer>`No description in the spec.
`[batch://<path>]` `crcSalt`	`<string>`No description in the spec.
`[batch://<path>]` `recursive`	`<boolean>`No description in the spec.
`[batch://<path>]` `whitelist`	`<regular expression>`No description in the spec.
`[batch://<path>]` `blacklist`	`<regular expression>`No description in the spec.
`[batch://<path>]` `initCrcLength`	`<integer>`No description in the spec.
`[batch://<path>]` `time_before_close`	`<integer>`No description in the spec.

`[tcp://<remote server>:<port>]`

Configures the input to listen on a specific TCP network port.
If a <remote server> makes a connection to this instance, the input uses this stanza to configure itself.
If you do not specify <remote server>, this stanza matches all connections on the specified network port.
Generates events with source set to "tcp:<port>", for example: tcp:514
If you do not specify a sourcetype, the input generates events with sourcetype set to "tcp-raw".

Setting	Description	Default
`[tcp://<remote server>:<port>]` `connection_host`	`[ip\|dns\|none]`How the network input sets the host field for the events it generates. More A value of "ip" sets the host to the IP address of the system sending the data. A value of "dns" sets the host to the reverse DNS entry for the IP address of the system that sends the data. For this to work correctly, set the forward DNS lookup to match the reverse DNS lookup in your DNS configuration. A value of "none" leaves the host as specified in inputs.conf, typically the hostname of the system running Splunk software.	dns
`[tcp://<remote server>:<port>]` `queueSize`	`<integer>[KB\|MB\|GB]`The maximum size of the in-memory input queue. More Configure this setting only if you have also configured 'persistentQueueSize'. If you configure multiple tcp inputs, and either set 'queueSize' or use its default value for each input, but do not also set 'persistentQueueSize', splunkd creates only one in-memory queue, and sets the size of that queue to the value it gets from a 'queueSize' setting in the first [tcp://] stanza it encounters after it sorts all [tcp://] stanza names in ascending alphanumeric order. In the case where none of the [tcp://] stanzas has an explicit 'queueSize' set, splunkd uses the default value. This logic applies to all inputs that use in-memory input queues. If you configure multiple [tcp://] stanzas, and do not want to set 'persistentQueueSize', then alternatively give 'maxSize' under the '[queue=tcpin_queue]' stanza a value in the server.conf configuration file.	500KB
`[tcp://<remote server>:<port>]` `persistentQueueSize`	`<integer>[KB\|MB\|GB\|TB]`The maximum size of the persistent queue file. More Persistent queues can help prevent loss of transient data. For information on persistent queues and how the 'queueSize' and 'persistentQueueSize' settings interact, search the online documentation for "persistent queues". If you set this to a value other than 0, then 'persistentQueueSize' must be larger than either the in-memory queue size (as defined by the 'queueSize' setting in inputs.conf or 'maxSize' settings in [queue] stanzas in server.conf).	0 (no persistent queue)
`[tcp://<remote server>:<port>]` `requireHeader`	`<boolean>`Whether or not to require a header be present at the beginning of every stream. More This header can be used to override indexing settings.	false
`[tcp://<remote server>:<port>]` `listenOnIPv6`	`[no\|yes\|only]`Whether or not the input listens on IPv4, IPv6, or both protocols. More Set to "yes" to listen on both IPv4 and IPv6 protocols. Set to "only" to listen on only the IPv6 protocol.	The setting in the [general] stanza of the server.conf file
`[tcp://<remote server>:<port>]` `acceptFrom`	`<comma- or space-separated list>`A list of TCP networks or addresses to accept connections from. More Use commas or spaces to separate multiple network rules. The accepted formats for network and address rules are: 1. A single IPv4 or IPv6 address (examples: "192.0.2.3", "2001:db8::2:1") 2. A Classless Inter-Domain Routing (CIDR) block of addresses (examples: "192.0.2/24", "2001:DB8::/32") 3. A DNS name. Use "" as a wildcard. (examples: "myhost.example.com", ".example.org") 4. The wildcard "" matches anything. A prefix of '!' for an entry sets a rule to deny and reject connections. The ACL applies rules in order, and uses the first matching rule. For example, the rules "!192.0.2/24, " prevents connections from the 192.0.2/24 network, but accepts all other connections.	* (accept from anywhere)
`[tcp://<remote server>:<port>]` `rawTcpDoneTimeout`	`<seconds>`The amount of time, in seconds, that a network connection can remain idle before Splunk software declares that the last event over that connection has been received. More If a connection over this port remains idle for more than 'rawTcpDoneTimeout' seconds after receiving data, it adds a Done-key. This declares that the last event has been completely received.	10

`[tcp:<port>]`

Configures the input listen on the specified TCP network port.
This stanza is similar to [tcp://<remote server>:<port>], but listens for connections to the specified port from any host.
Generates events with a source of tcp:<port>.
If you do not specify a sourcetype, generates events with a source type of tcp-raw.
This stanza supports the following settings:

Setting	Description	Default
`[tcp:<port>]` `connection_host`	`[ip\|dns\|none]`No description in the spec.
`[tcp:<port>]` `queueSize`	`<integer>[KB\|MB\|GB]`No description in the spec.
`[tcp:<port>]` `persistentQueueSize`	`<integer>[KB\|MB\|GB\|TB]`No description in the spec.
`[tcp:<port>]` `requireHeader`	`<boolean>`No description in the spec.
`[tcp:<port>]` `listenOnIPv6`	`[no\|yes\|only]`No description in the spec.
`[tcp:<port>]` `acceptFrom`	`<comma- or space-separated list>`No description in the spec.
`[tcp:<port>]` `rawTcpDoneTimeout`	`<integer>`No description in the spec.

`[splunktcp]`

Setting	Description	Default
`[splunktcp]` `route`	`[has_key\|absent_key:<key>:<queueName>;...]`Settings for the light forwarder. More The receiver sets these parameters automatically -- you do not need to set them yourself. The property route is composed of rules delimited by ';' (semicolon). The receiver checks each incoming data payload through the cooked TCP port against the route rules. If a matching rule is found, the receiver sends the payload to the specified <queueName>. If no matching rule is found, the receiver sends the payload to the default queue specified by any queue= for this stanza. If no queue= key is set in the stanza or globally, the receiver sends the events to the parsingQueue.
`[splunktcp]` `enableS2SHeartbeat`	`<boolean>`Specifies the global keepalive setting for all splunktcp ports. More This option is used to detect forwarders which might have become unavailable due to network, firewall, or other problems. The receiver monitors each connection for presence of a heartbeat, and if the heartbeat is not seen for 's2sHeartbeatTimeout' seconds, it closes the connection.	true (heartbeat monitoring enabled)
`[splunktcp]` `s2sHeartbeatTimeout`	`<integer>`The amount of time, in seconds, that a receiver waits for heartbeats from forwarders that connect to this instance. More The receiver closes a forwarder connection if it does not receive a heartbeat for 's2sHeartbeatTimeout' seconds.	600 (10 minutes)
`[splunktcp]` `inputShutdownTimeout`	`<integer>`The amount of time, in seconds, that a receiver waits before shutting down inbound TCP connections after it receives a signal to shut down. More Used during shutdown to minimize data loss when forwarders are connected to a receiver. During shutdown, the TCP input processor waits for 'inputShutdownTimeout' seconds and then closes any remaining open connections. If all connections close before the end of the timeout period, shutdown proceeds immediately, without waiting for the timeout.
`[splunktcp]` `stopAcceptorAfterQBlock`	`<integer>`The amount of time, in seconds, to wait before closing the splunktcp port. More If the receiver is unable to insert received data into the configured queue for more than the specified number of seconds, it closes the splunktcp port. This action prevents forwarders from establishing new connections to this receiver. Forwarders that have an existing connection will notice the port is closed upon test-connections and move to other receivers. After the queue unblocks, and the TCP input can continue processing data, the receiver starts listening on the port again. This setting should not be adjusted lightly as extreme values can interact poorly with other defaults. NOTE: If there are multiple tcp/splunktcp listener ports configured, all listening ports will be shut down regardless of whether other queues are blocked or not.	300 (5 minutes)
`[splunktcp]` `listenOnIPv6`	`no\|yes\|only`See the description for this setting in the [tcp://<remote server>:<port>] stanza.
`[splunktcp]` `acceptFrom`	`<comma- or space-separated list>`See the description for this setting in the [tcp://<remote server>:<port>] stanza.
`[splunktcp]` `negotiateProtocolLevel`	`<unsigned integer>`If set, lets forwarders that connect to this receiver (or specific port) send data using only up to the specified feature level of the Splunk forwarder protocol. More If set to a value that is lower than the default, denies the use of newer forwarder protocol features during connection negotiation. This might impact indexer efficiency.	1 (if 'negotiateNewProtocol' is "true"); 0 (if 'negotiateNewProtocol' is not "true")
`[splunktcp]` `negotiateNewProtocol`	`<boolean>`DEPRECATED. More Use the 'negotiateProtocolLevel' setting instead. Controls the default configuration of the 'negotiateProtocolLevel' setting.	true
`[splunktcp]` `concurrentChannelLimit`	`<unsigned integer>`The number of unique channel codes that are available for forwarders to use to communicate with an indexer. More Each forwarder that connects to this indexer may use up to 'concurrentChannelLimit' unique channel codes. In other words, each forwarder may have up to 'concurrentChannelLimit' channels in flight concurrently. The receiver closes a forwarder connection if a forwarder attempts to exceed this value. This setting only applies when the new forwarder protocol is in use.	300
`[splunktcp]` `logRetireOldS2S`	`<boolean>`Whether or not the Splunk platform logs the usage of old versions of Splunk-to-Splunk (S2S) protocol. More The old S2S protocol retirement logs provide visibility into customers' usage of the old S2S protocol version V3 which is less performant than the current version V4. A value of "true" means that splunkd generates warning logs for the old S2S protocol versions. See the 'logRetireOldS2SRepeatFrequency' setting for additional constraints on when the Splunk platform logs the use of old S2S protocol versions.	true
`[splunktcp]` `logRetireOldS2SMaxCache`	`<unsigned integer>`The size of the cache for tracking forwarders that use old S2S protocols. More The cache keeps track of unique forwarders that use the old S2S protocol. When a forwarder is in the cache, the Splunk platform doesn't log usage of the old protocol for that forwarder for a time period of 'logRetireOldS2SRepeatFrequency', to avoid generating duplicate logs. If the cache fills before the 'logRetireOldS2SRepeatFrequency' period elapses, the Splunk platform removes the forwarder that has been in the cache the longest from the cache to make space. Update this setting as per the number of forwarders that currently use the old S2S protocol to send data to indexers. If the number of forwarders that use old S2S protocols is larger than the cache size, some forwarders might generate duplicate logs even though the previous log was within the 'logRetireOldS2SRepeatFrequency' period. When you restart Splunk Enterprise, the cache resets and the timer starts over. This setting takes effect only when 'logRetireOldS2S' has a value of "true".	10000
`[splunktcp]` `logRetireOldS2SRepeatFrequency`	`<timespan>`The interval between writing repeat entries into the retire old S2S warning log for a certain forwarder. More This setting helps reduce retire old S2S log size by providing control over how often to log. When a forwarder uses the old S2S protocol version to communicate with splunkd, splunkd adds the forwarder to a cache. Subsequent communication with the same forwarder won't generate a new entry to the log until a period of 'logRetireOldS2SRepeatFrequency' has elapsed. Splunkd then resets the log timestamp and writes another "retire old S2S protocol" warning log entry. The Splunk platform enforces this setting as long as the size of the cache does not exceed 'logRetireOldS2SMaxCache' entries. When there are more than 'logRetireOldS2SMaxCache' entries, the cache removes the entry with the oldest access time to make space. When you restart Splunk Enterprise, the cache resets and the timer starts over. This setting takes effect only when 'logRetireOldS2S' has a value of "true". A value of "0" means that the platform logs old S2S protocol warning entries every time it receives a communication using the old S2S protocol version.	1d

`[splunktcp://[<remote server>]:<port>]`

Receivers use this input stanza.
This is the same as the [tcp://] stanza, except the remote server is assumed to be a Splunk instance, most likely a forwarder.
<remote server> is optional. If you specify it, the receiver listens only for data from <remote server>.
Use of <remote server> is not recommended. Use the 'acceptFrom' setting, which supersedes this setting.

Setting	Description	Default
`[splunktcp://[<remote server>]:<port>]` `connection_host`	`[ip\|dns\|none]`For splunktcp, the 'host' or 'connection_host' is be used if the remote Splunk instance does not set a host, or if the host is set to "<host>::<localhost>". More "ip" sets the host to the IP address of the system sending the data. "dns" sets the host to the reverse DNS entry for IP address of the system that sends the data. For this to work correctly, set the forward DNS lookup to match the reverse DNS lookup in your DNS configuration. "none" leaves the host as specified in inputs.conf, typically the Splunk system hostname.	ip
`[splunktcp://[<remote server>]:<port>]` `compressed`	`<boolean>`Whether or not the receiver communicates with the forwarder in compressed format. More Applies only to receiving data over standard network channels. There is no compression setting required for TLS. A value of "true" means the receiver communicates with the forwarder in compressed format. If set to "true", there is no longer a requirement to also set "compressed = true" in the outputs.conf file on the forwarder.	false
`[splunktcp://[<remote server>]:<port>]` `enableS2SHeartbeat`	`<boolean>`Specifies the keepalive setting for the splunktcp port. More This option is used to detect forwarders which might have become unavailable due to network, firewall, or other problems. The receiver monitors the connection for presence of a heartbeat, and if it does not see the heartbeat in 's2sHeartbeatTimeout' seconds, it closes the connection. This overrides the default value specified at the global [splunktcp] stanza.	true (heartbeat monitoring enabled)
`[splunktcp://[<remote server>]:<port>]` `s2sHeartbeatTimeout`	`<integer>`The amount of time, in seconds, that a receiver waits for heartbeats from forwarders that connect to this instance. More The receiver closes the forwarder connection if it does not see a heartbeat for 's2sHeartbeatTimeout' seconds. This overrides the default value specified at the global [splunktcp] stanza.	600 (10 minutes)
`[splunktcp://[<remote server>]:<port>]` `queueSize`	`<integer>[KB\|MB\|GB]`The maximum size of the in-memory input queue. More See the description of 'queueSize' under the [tcp://] stanza for details on this setting. If there are multiple [splunktcp://] stanzas, and you do not want to set 'persistentQueueSize', then alternatively give 'maxSize' under the '[queue=splunktcpin]' stanza a value in the server.conf configuration file.	500KB
`[splunktcp://[<remote server>]:<port>]` `negotiateProtocolLevel`	`<unsigned integer>`See the description for this setting in the [splunktcp] stanza.
`[splunktcp://[<remote server>]:<port>]` `negotiateNewProtocol`	`<boolean>`See the description for this setting in the [splunktcp] stanza.
`[splunktcp://[<remote server>]:<port>]` `concurrentChannelLimit`	`<unsigned integer>`See the description for this setting in the [splunktcp] stanza.

`[splunktcp:<port>]`

This input stanza is the same as [splunktcp://[<remote server>]:<port>], but the input accepts connections from any server.
See the online documentation for [splunktcp://[<remote server>]:<port>] for more information on the following supported settings:

Setting	Description	Default
`[splunktcp:<port>]` `connection_host`	`[ip\|dns\|none]`No description in the spec.
`[splunktcp:<port>]` `compressed`	`<boolean>`No description in the spec.
`[splunktcp:<port>]` `enableS2SHeartbeat`	`<boolean>`No description in the spec.
`[splunktcp:<port>]` `s2sHeartbeatTimeout`	`<integer>`No description in the spec.
`[splunktcp:<port>]` `queueSize`	`<integer>[KB\|MB\|GB]`No description in the spec.
`[splunktcp:<port>]` `persistentQueueSize`	`<integer>[KB\|MB\|GB\|TB]`No description in the spec.
`[splunktcp:<port>]` `negotiateProtocolLevel`	`<unsigned integer>`No description in the spec.
`[splunktcp:<port>]` `negotiateNewProtocol`	`<boolean>`No description in the spec.
`[splunktcp:<port>]` `concurrentChannelLimit`	`<unsigned integer>`No description in the spec.

`[splunktcptoken://<token name>]`

Use this stanza to specify forwarders from which to accept data.
You must configure a token on the receiver, then configure the same token on forwarders.
The receiver discards data from forwarders that do not have the token configured.
This setting is enabled for all receiving ports.
This setting is optional.
NOTE: When specifying a <token name>, you must use a specific format, as follows: NNNNNNNN-NNNN-NNNN-NNNN-NNNNNNNNNNNN. Failure to use this format results in the token being ignored.
For example, 'A843001F-B2B5-4F94-847D-D07802685BB2'

Setting	Description	Default
`[splunktcptoken://<token name>]` `token`	`<string>`The value of the token. More Must be in the format NNNNNNNN-NNNN-NNNN-NNNN-NNNNNNNNNNNN. Failure to use this string format results in the token being ignored.

`[splunktcp-ssl:<port>]`

Use this stanza type if your receivers receive encrypted, parsed data from a forwarder.
Set <port> to the port on which the forwarder sends the encrypted data.
Forwarder settings are set in outputs.conf on the forwarder.
Compression for TLS is enabled by default. On the forwarder you can still specify compression with the 'useClientSSLCompression' setting in outputs.conf.
The 'compressed' setting is used for non-TLS connections. However, if you still specify 'compressed' for TLS, ensure that the 'compressed' setting is the same as on the forwarder, as splunktcp protocol expects the same 'compressed' setting from forwarders.

Setting	Description	Default
`[splunktcp-ssl:<port>]` `connection_host`	`[ip\|dns\|none]`See the description for this setting in the [splunktcp:<port>] stanza.	ip
`[splunktcp-ssl:<port>]` `compressed`	`<boolean>`See the description for this setting in the [splunktcp:<port>] stanza.
`[splunktcp-ssl:<port>]` `enableS2SHeartbeat`	`<boolean>`See the description for this setting in the [splunktcp:<port>] stanza.
`[splunktcp-ssl:<port>]` `s2sHeartbeatTimeout`	`<seconds>`See the description for this setting in the [splunktcp:<port>] stanza.
`[splunktcp-ssl:<port>]` `listenOnIPv6`	`[no\|yes\|only]`Select whether this receiver listens on IPv4, IPv6, or both protocols. More Set to "yes" to listen on both IPv4 and IPv6 protocols. Set to "only" to listen on only the IPv6 protocol.	The setting in the [general] stanza of the server.conf file
`[splunktcp-ssl:<port>]` `acceptFrom`	`<comma- or space-separated list>`See the description for this setting in the [tcp://<remote server>:<port>] stanza.
`[splunktcp-ssl:<port>]` `negotiateProtocolLevel`	`<unsigned integer>`See the description for this setting in the [splunktcp] stanza.
`[splunktcp-ssl:<port>]` `negotiateNewProtocol`	`<boolean>`See the description for this setting in the [splunktcp] stanza.
`[splunktcp-ssl:<port>]` `concurrentChannelLimit`	`<unsigned integer>`See the description for this setting in the [splunktcp] stanza.
`[splunktcp-ssl:<port>]` `serverCert`	`<string>`No description in the spec.
`[splunktcp-ssl:<port>]` `sslPassword`	`<string>`No description in the spec.
`[splunktcp-ssl:<port>]` `requireClientCert`	`<boolean>`No description in the spec.
`[splunktcp-ssl:<port>]` `sslVersions`	`<string>`No description in the spec.
`[splunktcp-ssl:<port>]` `cipherSuite`	`<string>`No description in the spec.
`[splunktcp-ssl:<port>]` `ecdhCurves`	`<comma separated list>`No description in the spec.
`[splunktcp-ssl:<port>]` `dhFile`	`<string>`No description in the spec.
`[splunktcp-ssl:<port>]` `allowSslRenegotiation`	`<boolean>`No description in the spec.
`[splunktcp-ssl:<port>]` `sslQuietShutdown`	`<boolean>`No description in the spec.
`[splunktcp-ssl:<port>]` `sslCommonNameToCheck`	`<comma-separated list>`No description in the spec.
`[splunktcp-ssl:<port>]` `sslAltNameToCheck`	`<comma-separated list>`No description in the spec.
`[splunktcp-ssl:<port>]` `useSSLCompression`	`<boolean>`No description in the spec.

`[tcp-ssl:<port>]`

Use this stanza type if you are receiving encrypted, unparsed data from a forwarder or third-party system.
Set <port> to the port on which the forwarder/third-party system is sending unparsed, encrypted data.
To create multiple TLS inputs, you can add the following attributes to each [tcp-ssl:<port>] input stanza. If you do not configure a certificate in the port, the certificate information is pulled from the default [SSL] stanza:
serverCert = <path>
sslRootCAPath = <path>
Add this setting only if you have not configured the 'sslRootCAPath' setting in server.conf.
sslPassword = <string>

Setting	Description	Default
`[tcp-ssl:<port>]` `listenOnIPv6`	`[no\|yes\|only]`Select whether the receiver listens on IPv4, IPv6, or both protocols. More Set to "yes" to listen on both IPv4 and IPv6 protocols. Set to "only" to listen on only the IPv6 protocol. If not present, the receiver uses the setting in the [general] stanza of server.conf.
`[tcp-ssl:<port>]` `acceptFrom`	`<comma- or space-separated list>`See the description for this setting in the [tcp://<remote server>:<port>] stanza.	"*" (accept from anywhere)
`[tcp-ssl:<port>]` `serverCert`	`<string>`No description in the spec.
`[tcp-ssl:<port>]` `sslPassword`	`<string>`No description in the spec.
`[tcp-ssl:<port>]` `requireClientCert`	`<boolean>`No description in the spec.
`[tcp-ssl:<port>]` `sslVersions`	`<string>`No description in the spec.
`[tcp-ssl:<port>]` `cipherSuite`	`<string>`No description in the spec.
`[tcp-ssl:<port>]` `ecdhCurves`	`<comma separated list>`No description in the spec.
`[tcp-ssl:<port>]` `dhFile`	`<string>`No description in the spec.
`[tcp-ssl:<port>]` `allowSslRenegotiation`	`<boolean>`No description in the spec.
`[tcp-ssl:<port>]` `sslQuietShutdown`	`<boolean>`No description in the spec.
`[tcp-ssl:<port>]` `sslCommonNameToCheck`	`<comma-separated list>`No description in the spec.
`[tcp-ssl:<port>]` `sslAltNameToCheck`	`<comma-separated list>`No description in the spec.
`[tcp-ssl:<port>]` `useSSLCompression`	`<boolean>`No description in the spec.

`[SSL]`

Set the global specifications for receiving transport layer security (TLS) and Secure Sockets Layer (SSL) communication underneath this stanza name.

Setting	Description	Default
`[SSL]` `serverCert`	`<string>`The full path to the server certificate. More The Splunk daemon auto-generates certificates when you start Splunk Enterprise the first time. Where applicable, replace the default certificate with a certificate that you either create on your own or obtain from a third party. For more information about certificates, and how to obtain, create, and install them, search the Securing Splunk Enterprise Manual for "Introduction to Securing the Splunk Platform with TLS". The certificate must be in privacy-enhanced mail (PEM) format.	No default
`[SSL]` `sslPassword`	`<string>`The password for the server certificate, if you created one. More Configure this setting to a plain-text value initially. Upon first use, the input encrypts and rewrites the password to $SPLUNK_HOME/etc/system/local/inputs.conf.	No default
`[SSL]` `password`	`<string>`DEPRECATED. Use the 'sslPassword' setting instead.
`[SSL]` `rootCA`	`<string>`DEPRECATED. Use 'server.conf:[sslConfig]/sslRootCAPath' instead.
`[SSL]` `requireClientCert`	`<boolean>`Whether or not an HTTPS client which connects to a splunkd server must possess a certificate that a certificate authority signed to complete the connection. More Multiple services can use this setting, including but not limited to distributed search and distributed deployment clients. Splunk platform indexers must use this setting to connect to other Splunk platform indexers. Deployment clients must present certificates to deployment servers before they can poll the servers for new configurations or applications. A value of "true" means that a client can connect only if it has a certificate that was signed by a certificate authority that the splunkd server trusts. A value of "false" means that there is no certificate requirement to connect to services on another Splunk platform instance.	false (if using self-signed and third-party certificates); true (if using the default certificates; overrides the existing "false" setting)
`[SSL]` `sslVersions`	`<comma-separated list>`The list of TLS/SSL versions to support for incoming connections. More The versions available are "tls1.0", "tls1.1", "tls1.2", and "tls1.3". The special version "*" selects all supported versions. The version "tls" selects all versions tls1.0 or newer. If you prefix a version with "-", it means to exclude that version from the list. SSL versions 2 and 3 are always disabled. "-ssl2" and "-ssl3" are accepted as values in the version list, but have no effect. The default can vary. See the 'sslVersions' setting in $SPLUNK_HOME/etc/system/default/inputs.conf for the current default.
`[SSL]` `supportSSLV3Only`	`<boolean>`DEPRECATED. Use 'sslVersions' instead.
`[SSL]` `cipherSuite`	`<string>`A list of cipher suites for splunkd to use. More If set, the input processor uses the specified cipher string. If not set, the input process uses the default cipher string that the OpenSSL binary provides. If you want to use any Diffie-Hellman ciphers, you must use the 'dhFile' setting. The default can vary. See the 'cipherSuite' setting in the $SPLUNK_HOME/etc/system/default/inputs.conf file for the current default.
`[SSL]` `ecdhCurveName`	`<string>`DEPRECATED. Use the 'ecdhCurves' setting instead.	empty string
`[SSL]` `ecdhCurveName`	`<string>`DEPRECATED. Use the 'ecdhCurves' setting instead.	empty string
`[SSL]` `ecdhCurves`	`<comma-separated list>`A list of elliptic curves to use for the Elliptic-curve Diffie-Hellman (ECDH) key negotiation protocol. More The client sends elliptic curves as part of the Client Hello during a TLS handshake. Specify elliptic curves in the order that you prefer them. The server supports only the curves specified in the list. Splunk software only supports named curves that you specify by their short names. You can get the list of valid named curves by their short and long names by running this CLI command: $SPLUNK_HOME/bin/splunk cmd openssl ecparam -list_curves Example configuration: "ecdhCurves = prime256v1,secp384r1,secp521r1" The default can vary. See the 'ecdhCurves' setting in $SPLUNK_HOME/etc/system/default/inputs.conf for the current default.
`[SSL]` `dhFile`	`<string>`The location of the Diffie-Hellman (DH) parameter file. More This file must be in PEM format. The DH group size, which determines the strength of the key that the DH key exchange process uses, must not be fewer than 2048 bits. You must specify this file to enable any Diffie-Hellman ciphers. SSL compression is not supported in TLS 1.3.	No default
`[SSL]` `dhfile`	`<string>`DEPRECATED. Use the 'dhFile' setting (with a capital F) instead. More Yes, the setting name is case-sensitive.
`[SSL]` `allowSslRenegotiation`	`<boolean>`Whether or not the server lets clients request renegotiation of TLS connection settings. More In the TLS protocol, a client can request renegotiation of the connection settings from time to time. A value of "true" means that the server lets clients request the renegotiation of TLS connection settings. A value of "false" causes the server to reject all renegotiation attempts, which breaks the connection. This limits the amount of CPU a single TCP connection can use, but it can cause connectivity problems, especially for long-lived connections. Not supported when using TLS 1.3.	true
`[SSL]` `sslQuietShutdown`	`<boolean>`DEPRECATED. More Whether or not quiet SSL shutdown mode is turned on. When a client is finished with a TLS connection, it can shut that connection down normally or quietly. A normal SSL shutdown between a local node, in this case the client, and a peer node, in this case the server, involves either node sending a message to the other to terminate the TLS/SSL connection. This message is called the "close_notify" message. When a local node sends this message, the peer node returns the same message upon receipt, then stops sending further messages over TLS. The TLS connection remains open until the peer also closes the connection on its side. A "quiet" SSL shutdown means that neither node sends this message when it terminates the TLS connection. Instead, the node sets the connection to the "shutdown" state immediately. A value of "true" means that the client uses quiet SSL shutdown mode to terminate TLS connections. A value of "false" means that the client shuts down TLS connections using the normal shutdown process.	false
`[SSL]` `logCertificateData`	`<boolean>`Whether or not the Splunk platform logs certificate data for Transport Layer Security (TLS) certificates. More The certificate data logs provide visibility into the certificates in use for the Splunk-to-Splunk (S2S) channel. The logs collect data such as common name (CN), issuer name, SHA256 fingerprint, serial number, and validity dates. A value of "true" means that splunkd generates logs for TLS certificates. Refer to the 'certLogRepeatFrequency' setting for additional constraints on when the Splunk platform logs certificate data.	true
`[SSL]` `certLogMaxCacheEntries`	`<integer>`The size of the cache for tracking certificate entries. More The cache keeps track of the certificates for a time period of 'certLogRepeatFrequency' to avoid generating duplicate logs. If the cache fills before the 'certLogRepeatFrequency' period elapses, the cache removes the entry with the oldest access time to make space. Update this setting as per the number of forwarders that are sending data to indexers. If the number of forwarders is larger than the cache size, some of the certificates might generate duplicate logs even though the previous log was within the 'certLogRepeatFrequency' period. When you restart Splunk Enterprise, the cache resets and the timer starts over. This setting takes effect only when 'logCertificateData' has a value of 'true'.	10000
`[SSL]` `certLogRepeatFrequency`	`<timespan>`The interval between writing repeat entries into the certificate data log for a certain certificate. More This setting helps reduce certificate data log size by providing control over how often to log certificate data. When the Splunk platform receives a certificate the first time in a TLS connection, it adds the certificate to a cache. Subsequent connections with the same certificate won't generate a new entry to the log until a period of 'certLogRepeatFrequency' has passed. After this amount of time elapses, splunkd resets the log timestamp and writes another certificate log entry. The Splunk platform enforces this setting as long as the size of the cache does not reach 'certLogMaxCacheEntries'. When there are more than 'certLogMaxCacheEntries', the cache removes the entry with the oldest access time to make space. When you restart Splunk Enterprise, the cache resets and the timer starts over. This setting takes effect only when 'logCertificateData' has a value of 'true'. A value of "0" means that the platform logs certificate data every time it receives a certificate.	1d
`[SSL]` `sslCommonNameToCheck`	`<comma-separated list>`One or more X.509 standard Common Names of the server certificate which splunkd, as a client, checks against when it connects to a server using TLS. More The Common Name (CN) is an X.509 standard field in a certificate that identifies the host name that is associated with the certificate. The CN can be a short host name or a fully qualified domain name. For example, the CN can be one of "example", "www.example.com", or "example.com". If the client cannot match the CN in the certificate that the server presents, then the client cannot authenticate the server, and terminates the session negotiation immediately. For this setting to have any affect, the 'sslVerifyServerCert' setting must have a value of "true". This setting is optional. No default (no common name checking)
`[SSL]` `sslAltNameToCheck`	`<comma-separated list>`One or more Subject Alternative Names of the server certificate which splunkd, as a client, checks against when it connects to a server using TLS. More The Subject Alternative Name (SAN) is an extension to the X.509 standard that lets you specify additional host names for a TLS certificate. The SAN can be a short host name or a fully qualified domain name. If the client cannot match the SAN in the certificate that the server presents, then the client cannot authenticate the server, and terminates the session negotiation immediately. The client does not validate any names in this list against the Common Name. For this setting to have any affect, the 'sslVerifyServerCert' setting must have a value of "true". This setting is optional. No default (no alternative name checking).
`[SSL]` `useSSLCompression`	`<boolean>`Whether or not the server lets forwarders that connect to it negotiate TLS- layer data compression. More A value of "true" means the server lets forwarders negotiate TLS-layer data compression. SSL compression is not supported in TLS 1.3.	The value of 'server.conf:[sslConfig]/allowSslCompression'
`[SSL]` `sslServerHandshakeTimeout`	`<integer>`The timeout, in seconds, for a TLS handshake to complete between forwarder and the TCP input processor. More If the TCP input processor does not receive a "Client Hello" from the forwarder within 'sslServerHandshakeTimeout' seconds, the server terminates the connection.	60

`[udp://<remote server>:<port>]`

Similar to the [tcp://] stanza, except that this stanza causes the Splunk instance to listen on a UDP port.
Only 1 stanza per port number is currently supported.
Configures the instance to listen on a specific port.
If you specify <remote server>, the specified port only accepts data from that host.
If <remote server> is empty - [udp://<port>] - the port accepts data sent from any host.
The use of <remote server> is not recommended. Use the 'acceptFrom' setting, which supersedes this setting.
Generates events with source set to udp:portnumber, for example: udp:514
If you do not specify a sourcetype, generates events with sourcetype set to udp:portnumber.

Setting	Description	Default
`[udp://<remote server>:<port>]` `connection_host`	`[ip\|dns\|none]`"ip" sets the host to the IP address of the system sending the data. More "dns" sets the host to the reverse DNS entry for IP address of the system that sends the data. For this to work correctly, set the forward DNS lookup to match the reverse DNS lookup in your DNS configuration. "none" leaves the host as specified in inputs.conf, typically the Splunk system hostname. If the input is configured with a 'sourcetype' that has a transform that overrides the 'host' field e.g. 'sourcetype=syslog', that takes precedence over the host specified here.	ip
`[udp://<remote server>:<port>]` `_rcvbuf`	`<integer>`The receive buffer, in bytes, for the UDP port. More If you set the value to 0 or a negative number, the input ignores the value. If the default value is too large for an OS, the instance tries to set the value to 1572864/2. If that value is also too large, the instance retries with 1572864/(2*2). It continues to retry by halving the value until it succeeds.	1572864
`[udp://<remote server>:<port>]` `no_priority_stripping`	`<boolean>`Whether or not the input strips <priority> syslog fields from events it receives over the syslog input. More A value of "true" means the instance does NOT strip the <priority> syslog field from received events. NOTE: Do NOT set this setting if you want to strip <priority>.	false
`[udp://<remote server>:<port>]` `no_appending_timestamp`	`<boolean>`Whether or not to append a timestamp and host to received events. More A value of "true" means the instance does NOT append a timestamp and host to received events. NOTE: Do NOT set this setting if you want to append timestamp and host to received events.	false
`[udp://<remote server>:<port>]` `queueSize`	`<integer>[KB\|MB\|GB]`The maximum size of the in-memory input queue. More See the description of 'queueSize' under the [tcp://] stanza for details on this setting. If you configure multiple [udp://] stanzas, and do not want to set 'persistentQueueSize', then alternatively give 'maxSize' under the '[queue=UDP_queue]' stanza a value in the server.conf configuration file.	500KB
`[udp://<remote server>:<port>]` `persistentQueueSize`	`<integer>[KB\|MB\|GB\|TB]`The maximum size of the persistent queue file. More Persistent queues can help prevent loss of transient data. For information on persistent queues and how the 'queueSize' and 'persistentQueueSize' settings interact, search the online documentation for "persistent queues".. If you set this to a value other than 0, then 'persistentQueueSize' must be larger than either the in-memory queue size (as defined by the 'queueSize' setting in inputs.conf or 'maxSize' settings in [queue] stanzas in server.conf).	0 (no persistent queue)
`[udp://<remote server>:<port>]` `listenOnIPv6`	`[no\|yes\|only]`Select whether the instance listens on the IPv4, IPv6, or both protocols. More Set this to 'yes' to listen on both IPv4 and IPv6 protocols. Set to 'only' to listen on only the IPv6 protocol. If not present, the input uses the setting in the [general] stanza of server.conf.
`[udp://<remote server>:<port>]` `acceptFrom`	`<comma- or space-separated list>`See the description for this setting in the [tcp://<remote server>:<port>] stanza.	"*" (accept from anywhere)

`[udp:<port>]`

This input stanza is the same as [udp://<remote server>:<port>], but does not have a <remote server> restriction.
See the documentation for [udp://<remote server>:<port>] to configure supported settings:

Setting	Description	Default
`[udp:<port>]` `connection_host`	`[ip\|dns\|none]`No description in the spec.
`[udp:<port>]` `_rcvbuf`	`<integer>`No description in the spec.
`[udp:<port>]` `no_priority_stripping`	`<boolean>`No description in the spec.
`[udp:<port>]` `no_appending_timestamp`	`<boolean>`No description in the spec.
`[udp:<port>]` `queueSize`	`<integer>[KB\|MB\|GB]`No description in the spec.
`[udp:<port>]` `persistentQueueSize`	`<integer>[KB\|MB\|GB\|TB]`No description in the spec.
`[udp:<port>]` `listenOnIPv6`	`<no \| yes \| only>`No description in the spec.
`[udp:<port>]` `acceptFrom`	`<comma- or space-separated list>`No description in the spec.

`[fifo://<path>]`

This stanza configures the monitoring of a FIFO at the specified path.

Setting	Description	Default
`[fifo://<path>]` `queueSize`	`<integer>[KB\|MB\|GB]`The maximum size of the in-memory input queue. More If you configure multiple [fifo://] stanzas, and do not want to set 'persistentQueueSize', then alternatively give 'maxSize' under the '[queue=fifoInternalQ]' stanza a value in the server.conf configuration file.	500KB
`[fifo://<path>]` `persistentQueueSize`	`<integer>[KB\|MB\|GB\|TB]`Maximum size of the persistent queue file. More Persistent queues can help prevent loss of transient data. For information on persistent queues and how the 'queueSize' and 'persistentQueueSize' settings interact, search the online documentation for "persistent queues".. If you set this to a value other than 0, then 'persistentQueueSize' must be larger than either the in-memory queue size (as defined by the 'queueSize' setting in inputs.conf or 'maxSize' settings in [queue] stanzas in server.conf).	0 (no persistent queue)

`[script://<cmd>]`

Runs <cmd> at a configured interval and indexes the output that <cmd> returns.
To determine the interval at which the input runs <cmd>, use the 'interval' setting.
The <cmd> must reside in one of the following directories:
$SPLUNK_HOME/etc/system/bin/
$SPLUNK_HOME/etc/apps/$<APPNAME>/bin/
$SPLUNK_HOME/bin/scripts/
The path to <cmd> can be an absolute path, make use of an environment variable such as $SPLUNK_HOME, or use the special pattern of an initial '.' as the first directory to indicate a location inside the current app. For more scripted input examples, search the documentation for "Add a scripted input with inputs.conf."
<cmd> can also be a path to a file that ends with a ".path" suffix. A file with this suffix is a special type of pointer file that points to a command to be run. Although the pointer file is bound by the same location restrictions mentioned previously, the command referenced inside it can reside anywhere on the file system. The .path file must contain exactly one line: the path to the command to run, optionally followed by command-line arguments. The file can contain additional empty lines and lines that begin with '#'. The input ignores these lines.

Setting	Description	Default
`[script://<cmd>]` `interval`	`[<decimal>\|<cron schedule>]`How often, in seconds, to run the specified command, or a valid "cron" schedule. More If you specify the interval as a number, it may have a fractional component; for example, 3.14 To specify a cron schedule, use the following format: "<minute> <hour> <day of month> <month> <day of week>" Cron special characters are acceptable. You can use combinations of "*", ",", "/", and "-" to specify wildcards, separate values, specify ranges of values, and step values. The cron implementation for data inputs does not currently support names of months or days. The special value "0" forces this scripted input to be run continuously. As soon as the script exits, the input restarts it. The special value "-1" causes the scripted input to run once on start-up. NOTE: when you specify a cron schedule, the input does not run the script on start-up.	60.0
`[script://<cmd>]` `passAuth`	`<string>`The user to run the script as. More If you provide a username, the instance generates an auth token for that user and passes it to the script through the stdin data stream.	No default
`[script://<cmd>]` `python.version`	`[default\|python\|python2\|python3\|python3.7\|python3.9\|latest]`DEPRECATED. Use 'python.required' instead to specify which Python versions the script supports. More For Python scripts only, selects which Python version to use. Set to either "default" or "python" to use the system-wide default Python version. Set to "python3" or "python3.7" to use the Python 3.7 version. Set to "python3.9" to use the Python 3.9 version. In the context of configuring apps, the "latest" value is not currently supported. It is related to a feature that is still under development. Optional.	Not set; uses the system-wide Python version.
`[script://<cmd>]` `python.required`	`<comma-separated list>`For Python scripts only, the versions of Python that the script supports. More This setting takes precedence over the 'python.version' setting if both have values. The Splunk platform selects the highest version of Python that is available from the list that you provide. The following values are supported: "3.9": The script supports Python version 3.9. "3.13": The script supports Python version 3.13. "latest": The script uses the latest Python interpreter available. Where possible, use a specific version string rather than "latest". NOTE: The "latest" value is an internal value that is related to a feature that is still under development. NOTE: Use this setting instead of the deprecated 'python.version' setting. This setting is optional.	Not set; uses 'python.version' if that setting has a value.
`[script://<cmd>]` `queueSize`	`<integer>[KB\|MB\|GB]`The maximum size of the in-memory input queue. More See the description of 'queueSize' under the [tcp://] stanza for details on this setting. If you configure multiple [script://] stanzas, and do not want to set 'persistentQueueSize', then alternatively give 'maxSize' under the '[queue=execProcessorInternalQ]' stanza a value in the server.conf configuration file.	500KB
`[script://<cmd>]` `persistentQueueSize`	`<integer>[KB\|MB\|GB\|TB]`Maximum size of the persistent queue file. More Persistent queues can help prevent loss of transient data. For information on persistent queues and how the 'queueSize' and 'persistentQueueSize' settings interact, search the online documentation for "persistent queues".. If you set this to a value other than 0, then 'persistentQueueSize' must be larger than either the in-memory queue size (as defined by the 'queueSize' setting in inputs.conf or 'maxSize' settings in [queue] stanzas in server.conf).	0 (no persistent queue)
`[script://<cmd>]` `index`	`<string>`The index where the scripted input sends the data. More The script passes this parameter as a command-line argument to <cmd> in the format: -index <index name>. If the script does not need the index info, it can ignore this argument. If you do not specify an index, the script uses the default index.
`[script://<cmd>]` `send_index_as_argument_for_path`	`<boolean>`Whether or not to pass the index as an argument when specified for stanzas that begin with 'script://' More A value of "true" means the script passes the argument as '-index <index name>'. To avoid passing the index as a command line argument, set this to "false".	true
`[script://<cmd>]` `start_by_shell`	`<boolean>`Whether or not to run the specified command through the operating system shell or command prompt. More A value of "true" means the host operating system runs the specified command through the OS shell ("/bin/sh -c" on *NIX, "cmd.exe /c" on Windows.) A value of "false" means the input runs the program directly without attempting to expand shell metacharacters. You might want to explicitly set a value of "false" for scripts that you know do not need UNIX shell metacharacter expansion. This is a Splunk best practice.	true (on *nix machines); false (on Windows machines)

`[fschange:<path>]`

Monitors changes (such as additions, updates, and deletions) to this directory and any of its sub-directories.
<path> is the direct path. Do not preface it with '//' like with other inputs.
Sends an event for every change.

Setting	Description	Default
`[fschange:<path>]` `disabled`	`<boolean>`Whether or not the file system change monitor input is active. More Set a value of "true" to disable the input, and "false" to enable it.	false
`[fschange:<path>]` `index`	`<string>`The index where the input sends the data.	(if you either do not set 'signedaudit' or set 'signedaudit' to "false"): _audit; (in all other cases): the default index
`[fschange:<path>]` `signedaudit`	`<boolean>`Whether or not to send cryptographically signed add/update/delete events. More A value of "true" means the input does the following to events that it generates: Puts the events in the _audit index. Sets the event sourcetype to 'audittrail' A value of "false" means the input: Places events in the default index. Sets the sourcetype to whatever you specify (or "fs_notification" by default). You must set 'signedaudit' to "false" if you want to set the index for fschange events. You must also enable auditing by using the audit.conf file.	false
`[fschange:<path>]` `filters`	`<comma-separated list>`The fschange input applies each filter, left to right, for each file or directory found during the monitor poll cycle. More See the "File System Monitoring Filters" section later in this file for help on how to define a fschange filter.
`[fschange:<path>]` `recurse`	`<boolean>`Whether or not the fschange input should look through all sub-directories for changes to files in a directory. More A value of "true" means the input searches recursively through sub-directories within the directory specified in [fschange].	true
`[fschange:<path>]` `followLinks`	`<boolean>`Whether or not the fschange input follows any symbolic links it encounters. More A value of "true" means the input follows symbolic links. CAUTION: Do not set this setting to "true" unless you can confirm that doing so will not create a file system loop (For example, in Directory A, symbolic link B points back to Directory A.)	false
`[fschange:<path>]` `pollPeriod`	`<integer>`How often, in seconds, to check a directory for changes.	3600 (1 hour)
`[fschange:<path>]` `hashMaxSize`	`<integer>`The maximum size, in bytes, that a file can be for the fschange input to calculate a SHA256 hash for that file. More Tells the fschange input to calculate a SHA256 hash for every file that is this size or smaller, in bytes. The input uses this hash as an additional method for detecting changes to the file or directory.	-1 (disabled)
`[fschange:<path>]` `fullEvent`	`<boolean>`Whether or not to send the full event if the input detects an add or update change. More Set to "true" to send the full event if an add or update change is detected. Further qualified by the 'sendEventMaxSize' setting.	false
`[fschange:<path>]` `sendEventMaxSize`	`<integer>`The maximum size, in bytes, that an fschange event can be for the input to send the full event to be indexed. More Limits the size of event data that the fschange input sends. This also limits the size of indexed file data.	-1 (unlimited)
`[fschange:<path>]` `sourcetype`	`<string>`Sets the source type for events from this input. More The input automatically prepends "sourcetype=" to <string>.	audittrail (if you set the 'signedaudit' setting to "true"); fs_notification (if you set the 'signedaudit' setting to "false")
`[fschange:<path>]` `host`	`<string>`Sets the host name for events from this input.	whatever host sent the event
`[fschange:<path>]` `filesPerDelay`	`<integer>`The number of files that the fschange input processes between processing delays, as specified by the 'delayInMills' setting. More After a delay of 'delayInMills' milliseconds, the fschange input processes 'filesPerDelay' files, then waits 'delayInMills' milliseconds again before repeating this process. This setting helps throttle file system monitoring so it consumes less CPU.	10
`[fschange:<path>]` `delayInMills`	`<integer>`The delay, in milliseconds, that the fschange input waits between processing 'filesPerDelay' files. More After a delay of 'delayInMills' milliseconds, the fschange input processes 'filesPerDelay' files, then waits 'delayInMills' milliseconds again before repeating this process. This setting helps throttle file system monitoring so it consumes less CPU.	100

`[filter:<filtertype>:<filtername>]`

Defines a filter of type <filtertype> and names it <filtername>.
<filtertype>:
Filter types are either 'blacklist' or 'whitelist.' 'blacklist' is the deny list filter type and 'whitelist' is the allow list filter type.
An allow list filter processes all file names that match the regular expression list that you define within the stanza.
A deny list filter skips all file names that match the regular expression list.
<filtername>
The fschange input uses filter names that you specify with the 'filters' setting for a given fschange stanza.
You can specify multiple filters by separating them with commas.

Setting	Description	Default
`[filter:<filtertype>:<filtername>]` `regex<integer>`	`<regular expression>`Deny list and allow list filters can include a set of regular expressions. More The name of each regular expression MUST be 'regex<integer>', meaning the string "regex" and then an integer. <integer> starts at 1 and increments by 1. The input applies each regular expression in numeric order: regex1=<regular expression> regex2=<regular expression> ...

`[http]`

Setting	Description	Default
`[http]` `port`	`<positive integer>`The event collector data endpoint server port.	8088
`[http]` `disabled`	`<boolean>`Whether or not the event collector input is active. More Give this setting a value of "1" to disable the input, and "0" to enable it.	1 (disabled)
`[http]` `outputgroup`	`<string>`The name of the output group to which the event collector forwards data. More There is no support for using this setting to send data over HTTP with a heavy forwarder.	empty string
`[http]` `useDeploymentServer`	`<boolean>`Whether or not the HTTP event collector input writes its configuration to a deployment server repository. More When you enable this setting, the input writes its configuration to the directory that you specify with the 'repositoryLocation' setting in the serverclass.conf file. You must copy the full contents of the splunk_httpinput app directory to this directory for the configuration to work. When enabled, only the tokens defined in the splunk_httpinput app in this repository are viewable and editable through the API and Splunk Web. When disabled, the input writes its configuration to $SPLUNK_HOME/etc/apps by default.	0 (disabled)
`[http]` `index`	`<string>`The default index to use.	the "default" index
`[http]` `sourcetype`	`<string>`The default source type for the events that the input generates. More If you do not specify a sourcetype, the input does not set a sourcetype for events it generates.
`[http]` `enableSSL`	`<boolean>`Whether or not the HTTP Event Collector uses TLS. More HEC shares TLS settings with the Splunk management server and cannot have TLS turned on when the Splunk management server has TLS turned off.	true
`[http]` `jsonParser`	`[legacy\|vectorized]`The JSON parser implementation that the HTTP Event Collector uses. More A value of "legacy" sets the original JSON parser. A value of "vectorized" sets an optimized JSON parser, which improves parsing speed and efficiency. CAUTION: Contact Splunk Support first before configuring this setting.	legacy
`[http]` `jsonParserMaxEventSize`	`<positive integer>[KiB\|MiB]`The maximum size of a single JSON event that the vectorized JSON parser can process. More If an individual JSON event in the HEC payload exceeds this size, parsing stops and the request returns an error. Events that appear before the oversized event in the payload are still ingested, but the oversized event and any subsequent events are dropped. This setting only applies in instances where 'jsonParser' has a value of "vectorized". CAUTION: Contact Splunk Support first before configuring this setting.	8MiB
`[http]` `backpressureState`	`[disabled\|warn_at_80]`The level of backpressuring for the HTTP Event Collector (HEC) and HEC indexer acknowledgment (ACK) services. More Backpressuring is the adding of notifications to HTTP responses that HEC and HEC ACK send to incoming HTTP requests. This notification process includes the following changes in how HEC and HEC ACK respond to these requests: Sending a warning with the HTTP response when HEC queues exceed 80% of capacity. Sending warnings when HEC ACK channels exceed 80% of capacity. Sending the "HTTP 429 Too Many Requests" instead of the "HTTP 503 Server Unavailable" error code as a response when HEC and HEC ACK are too busy to accept new requests. The HEC ACK Health Check now fails when all channels are full, instead of when at least one channel is full. Currently, HEC and HEC ACK backpressuring can be turned off with a value of "disabled", or turned on to warn when HEC queues and HEC ACK channels exceed eighty (80) percent of capacity, with a value of "warn_at_80". These are the only valid values for this setting. When you configure this setting, do not put its value within quotation marks. CAUTION: Do not configure this setting without first contacting Splunk Support.	disabled
`[http]` `ackExpiryMode`	`[off\|expire_at_90]`Controls whether the HTTP Event Collector (HEC) periodically evicts the oldest pending indexer acknowledgment (ACK) entries from channels that approach their per-channel ACK queue limit. More A value of "off" means no automatic eviction occurs. Channels that fill to capacity block new events until clients poll for their ACK IDs. A value of "expire_at_90" turns on a periodic sweep that inspects each ACK channel. When a channel exceeds 90% of its per-channel ACK queue limit, the sweep evicts the oldest entries (lowest ACK IDs) to reduce the channel to 85% of capacity. Evicted ACK IDs are reported as unacknowledged to clients that subsequently poll for them. This can cause clients to re-send events that were already indexed, potentially resulting in duplicate events. This setting can only be configured in the global [http] stanza.	off
`[http]` `headerEnforcementMode`	`[off\|warn\|block]`How an HTTP Event Collector (HEC) input enforces load balancer cookie markers for HEC indexer acknowledgment (ACK) enabled token requests. More The 'ackRequiredAnyCookie' setting defines the cookie markers that the input looks for as part of enforcement. A value of "off" means the input performs no enforcement. A value of "warn" means that if the expected cookie markers are missing, the input logs a warning, but still allows the request. A value of "block" means that if the expected cookie markers are missing, the input responds with an HTTP 400 (bad request) status code. NOTE: Do not change this setting unless instructed to do so by Splunk Support.	off
`[http]` `ackRequiredAnyCookie`	`<comma-separated list>`The cookie markers to search for in the "Cookie" request header when validating acknowledgment (ACK)-enabled tokens. More Values for this setting are not case-sensitive. If this setting has no value, the Splunk platform performs no enforcement, which is equivalent to the behavior when 'headerEnforcementMode' has a value of "off". Example: AWSELB,AWSALB,AWSALBCORS,AWSELBCORS	AWSELB,AWSALB,AWSALBCORS,AWSELBCORS
`[http]` `dedicatedIoThreads`	`<non-negative integer>`The number of dedicated input/output threads in the event collector input.	0 (The input uses a single thread)
`[http]` `replyHeader.<name>`	`<string>`Adds a static header to all HTTP responses that this server generates. More For example, "replyHeader.My-Header = value" causes the response header "My-Header: value" to be included in the reply to every HTTP request made to the event collector endpoint server.	No default
`[http]` `maxSockets`	`<integer>`The number of HTTP connections that the HTTP event collector input accepts simultaneously. More Set this setting to constrain resource usage. If you set this setting to 0, the input automatically sets it to one third of the maximum allowable open files on the host. If this value is less than 50, the input sets it to 50. If this value is greater than 400000, the input sets it to 400000. If set to a negative value, the input does not enforce a limit on connections.	0
`[http]` `maxThreads`	`<integer>`The number of threads that can be used by active HTTP transactions. More Set this to constrain resource usage. If you set this setting to 0, the input automatically sets the limit to one third of the maximum allowable threads on the host. If this value is less than 20, the input sets it to 20. If this value is greater than 150000, the input sets it to 150000. If the 'maxSockets' setting has a positive value and 'maxThreads' is greater than 'maxSockets', then the input sets 'maxThreads' to be equal to 'maxSockets'. If set to a negative value, the input does not enforce a limit on threads.	0
`[http]` `rollingRestartReturnServerBusy`	`<boolean>`Whether or not HTTP Event Collector endpoints return HTTP errors 404 (not found) or 503 (server busy) when a client connects to an indexer that is currently shutting down during a rolling restart. More This setting applies to instances on the Classic Experience only. NOTE: Do not change this setting unless instructed to do so by Splunk Support.	true
`[http]` `keepAliveIdleTimeout`	`<integer>`How long, in seconds, that the HTTP Event Collector input lets a keep-alive connection remain idle before forcibly disconnecting it. More If this value is less than 7200, the input sets it to 7200.	7200
`[http]` `busyKeepAliveIdleTimeout`	`<integer>`How long, in seconds, that the HTTP Event Collector lets a keep-alive connection remain idle while in a busy state before forcibly disconnecting it. More CAUTION: Setting this to a value that is too large can result in file descriptor exhaustion due to idling connections. If this value is less than 12, the input sets it to 12.	12
`[http]` `serverCert`	`<string>`See the description of 'serverCert' under the [SSL] stanza for details on this setting.	$SPLUNK_HOME/etc/auth/server.pem
`[http]` `sslKeysfile`	`<string>`DEPRECATED. Use the 'serverCert' setting instead.	server.pem
`[http]` `sslPassword`	`<string>`See the description of 'sslPassword' under the [SSL] stanza for details on this setting.	password
`[http]` `sslKeysfilePassword`	`<string>`DEPRECATED. More Use the 'sslPassword' setting instead.
`[http]` `caCertFile`	`<string>`DEPRECATED. Use the 'server.conf:[sslConfig]/sslRootCAPath' setting instead. More If you have not given the 'sslRootCAPath' setting a value, then Splunk Enterprise attempts to locate a CA certificate using this setting.	cacert.pem
`[http]` `caPath`	`<string>`DEPRECATED. Use absolute paths for all certificate files. More If you do not specify absolute paths for certificate files in other settings in this stanza, then they are relative to path you specify in this setting.	$SPLUNK_HOME/etc/auth
`[http]` `sslVersions`	`<comma-separated list>`The list of TLS versions to support. More The versions available are "tls1.0", "tls1.1", "tls1.2", and "tls1.3". The special version "*" selects all supported versions. The version "tls" selects all versions tls1.0 or newer. If you prefix a version with "-", it means to exclude that version from the list. SSL versions 2 and 3 are always disabled. "-ssl2" and "-ssl3" are accepted as values in the version list, but have no effect.	tls1.2, tls1.3
`[http]` `cipherSuite`	`<string>`The cipher string to use for the HTTP Event Collector input. More Use this setting to ensure that the server does not accept connections using weak encryption protocols. If you configure this setting, the input uses the specified cipher string for the HTTP server. The default can vary. See the 'cipherSuite' setting in the $SPLUNK_HOME/etc/system/default/server.conf file for the current default.
`[http]` `sslServerHandshakeTimeout`	`<integer>`The timeout, in seconds, for an SSL handshake to complete between an HEC client and the Splunk HEC server. More If the HEC server does not receive a "Client Hello" from the HEC client within 'sslServerHandshakeTimeout' seconds, the server terminates the connection.	60
`[http]` `listenOnIPv6`	`[no\|yes\|only]`Whether or not this input listens on IPv4, IPv6, or both. More Set to "no" to make the input listen only on the IPv4 protocol. Set to "yes" to make the input listen on both IPv4 and IPv6 protocols. Set to "only" to make the input listen on only the IPv6 protocol.	The setting in the [general] stanza of the server.conf file
`[http]` `acceptFrom`	`<comma- or space-separated list>`See the description for this setting in the [tcp://<remote server>:<port>] stanza.	"*" (accept from anywhere)
`[http]` `requireClientCert`	`<boolean>`Whether or not a client which connects to the HEC network port must possess a certificate that a certificate authority signed to complete the connection. More HEC uses the certificate that you specify in the 'server.conf:[sslConfig]/sslRootCAPath' setting to validate incoming client certificates. If you do not specify a certificate with that setting, it uses the certificate you specify with the DEPRECATED 'caCertFile' setting. A value of "true" means that a client can connect to HEC only if it has a certificate that was signed by a certificate authority that the splunkd server trusts. A value of "false" means that there is no certificate requirement to connect to HEC.	false
`[http]` `ecdhCurveName`	`<string>`DEPRECATED. Use the 'ecdhCurves' setting instead.	empty string
`[http]` `ecdhCurves`	`<comma-separated list>`A list of elliptic curves to use for the Elliptic-curve Diffie-Hellman (ECDH) key negotiation protocol. More The client sends elliptic curves as part of the Client Hello during a TLS handshake. Specify elliptic curves in the order that you prefer them. The server supports only the curves specified in the list. Splunk software only supports named curves that you specify by their short names. You can get the list of valid named curves by their short and long names by running this CLI command: $SPLUNK_HOME/bin/splunk cmd openssl ecparam -list_curves Example configuration: "ecdhCurves = prime256v1,secp384r1,secp521r1"	empty string
`[http]` `crossOriginSharingPolicy`	`<origin_acl> ...`A list of the HTTP Origins for which to return Access-Control-Allow-* Cross-origin Resource Sharing (CORS) headers. More These headers tell browsers that web applications at those sites can be trusted to make requests to the REST interface. The origin is passed as a URL without a path component (for example "https://app.example.com:8000"). This setting can take a list of acceptable origins, separated by spaces and/or commas. Each origin can also contain wildcards for any part. Examples: ://app.example.com: (either HTTP or HTTPS on any port) https://.example.com (any host under example.com, including example.com itself). An address can be prefixed with a '!' to negate the match, with the first matching origin taking precedence. Example: "!://evil.example.com:* ://.example.com:" to not avoid matching one host in a domain. "" matches all origins.	empty string
`[http]` `crossOriginSharingHeaders`	`<string>`A list of the HTTP headers to which splunkd sets "Access-Control-Allow-Headers" when replying to Cross-Origin Resource Sharing (CORS) preflight requests. More The "Access-Control-Allow-Headers" header is used in response to a CORS preflight request to tell browsers which HTTP headers can be used during the actual request. A CORS preflight request is a CORS request that checks to see if the CORS protocol is understood and a server is aware of using specific methods and headers. This setting can take a list of acceptable HTTP headers, separated by commas. A single "*" can also be used to match all headers.	empty string
`[http]` `forceHttp10`	`[auto\|never\|always]`Whether or not the REST HTTP server forces clients that connect to it to use the HTTP 1.0 specification for web communications. More When set to "always", the REST HTTP server does not use some HTTP 1.1 features such as persistent connections or chunked transfer encoding. When set to "auto", it does this only if the client did not send a User-Agent header, or if the user agent is known to have bugs in its support of HTTP/1.1. When set to "never" it always allows HTTP 1.1, even to clients it suspects might be buggy.	auto
`[http]` `sslCommonNameToCheck`	`<comma-separated list>`One or more X.509 standard Common Names of the server certificate which splunkd, as a client, checks against when it connects to a server using TLS. More The Common Name (CN) is an X.509 standard field in a certificate that identifies the host name that is associated with the certificate. The CN can be a short host name or a fully qualified domain name. For example, the CN can be one of "example", "www.example.com", or "example.com". If the client cannot match the CN in the certificate that the server presents, then the client cannot authenticate the server, and terminates the session negotiation immediately. For this setting to have any affect, the 'sslVerifyServerCert' setting must have a value of "true". The most important scenario to use this setting is distributed search. This feature does not work with the deployment server and client communication over TLS. This setting is optional.	empty string (no common name checking)
`[http]` `sslAltNameToCheck`	`<comma-separated list>`One or more Subject Alternative Names of the server certificate which splunkd, as a client, checks against when it connects to a server using TLS. More The Subject Alternative Name (SAN) is an extension to the X.509 standard that lets you specify additional host names for a TLS certificate. The SAN can be a short host name or a fully qualified domain name. Subject Alternative Names are effectively extended descriptive fields in TLS certificates beyond the Common Name. A common practice for HTTPS certificates is to use these values to store additional valid hostnames or domains where the cert should be considered valid. If the client cannot match the SAN in the certificate that the server presents, then the client cannot authenticate the server, and terminates the session negotiation immediately. The client does not validate any names in this list against the Common Name. For this setting to have any affect, the 'sslVerifyServerCert' setting must have a value of "true". This feature does not work with the deployment server and client communication over TLS. This setting is optional.	empty string (no alternate name checking)
`[http]` `sendStrictTransportSecurityHeader`	`<boolean>`Whether or not the REST interface sends a "Strict-Transport-Security" header with all responses to requests made over TLS. More A value of "true" means the REST interface sends a "Strict-Transport- Security" header with its responses. This can help to avoid a client being tricked later by a machine-in-the-middle attack to accept a non-TLS request. However, this requires a commitment that no non-TLS web hosts ever run on this hostname on any port. For example, if Splunk Web is in its default non-TLS mode, this can prevent a web browser from connecting to it. A value of "false" means the REST interface does not send a "Strict-Transport-Security" header with its responses.	false
`[http]` `allowSslCompression`	`<boolean>`Whether or not the server lets clients negotiate compression at the TLS layer. More A value of "true" means the server lets clients negotiate TLS-layer data compression. A value of "false" means the server does not let clients negotiate TLS-layer data compression. SSL compression is not supported in TLS 1.3.	true
`[http]` `allowSslRenegotiation`	`<boolean>`Whether or not the server lets clients request renegotiation of TLS connection settings. More In the TLS protocol, a client can request renegotiation of the connection settings from time to time. A value of "true" means that the server lets clients request the renegotiation of TLS connection settings. A value of "false" causes the server to reject all renegotiation attempts, which breaks the connection. This limits the amount of CPU a single TCP connection can use, but it can cause connectivity problems, especially for long-lived connections. This setting is not supported when using TLS 1.3	true
`[http]` `ackIdleCleanup`	`<boolean>`Whether or not to remove ACK channels that have been idle after a period of time, as defined by the 'maxIdleTime' setting. More A value of "true" means the server removes the ACK channels that are idle for 'maxIdleTime' seconds.	true
`[http]` `maxIdleTime`	`<integer>`The maximum amount of time, in seconds, that ACK channels can be idle before they are removed. More If 'ackIdleCleanup' is "true", the system removes ACK channels that have been idle for 'maxIdleTime' seconds.	600 (10 minutes)
`[http]` `channel_cookie`	`<string>`The name of the cookie to use when sending data with a specified channel ID. More The value of the cookie is the channel sent. For example, if you have set 'channel_cookie=foo' and sent a request with channel ID set to 'bar', then you will have a cookie in the response with the value 'foo=bar'. If no channel ID is present in the request, then no cookie is returned. This setting is to be used for load balancers (for example, AWS ELB) that can only provide sticky sessions on cookie values and not general header values. If no value is set (the default), then no cookie is returned.	empty string (no cookie)
`[http]` `maxEventSize`	`<positive integer>[KB\|MB\|GB]`The maximum size of a single HEC (HTTP Event Collector) event. More HEC disregards and triggers a parsing error for events whose size is greater than 'maxEventSize'.	5MB
`[http]` `maxMemoryUsagePct`	`<positive integer>`The maximum percentage of memory that the Splunk platform instance can use to process HTTP inputs. More When the host-wide memory usage surpasses this threshold, the instance rejects HTTP inputs with an HTTP error 503 Service Unavailable code. The maximum legal value is 100.	100
`[http]` `route`	`[has_key\|absent_key:<key>:<queueName>;...]`See 'route' in the "[splunktcp]" stanza for information on this setting.
`[http]` `hecCacheCapacity`	`<positive integer>`The maximum number of unique entries that the HTTP Event Collector (HEC) stores in its cache. More Each entry consists of a source IP and a timestamp of the last incoming event.	1000

`[http://name]`

Setting	Description	Default
`[http://name]` `token`	`<string>`The value of the HEC token. More HEC uses this token to authenticate inbound connections. Your application or web client must present this token when attempting to connect to HEC.	No default
`[http://name]` `disabled`	`<boolean>`Whether or not this token is active.	0 (enabled)
`[http://name]` `description`	`<string>`A human-readable description of this token.	empty string
`[http://name]` `indexes`	`<comma-separated list>`The indexes that events for this token can go to. More If you do not specify this value, the index list is empty, and any index can be used. Separate multiple indexes with commas. The Splunk platform accepts and indexes events without a specified index to a default index.	No default
`[http://name]` `s2s_indexes_validation`	`[ disabled \| disabled_for_internal \| enabled_for_all ]`The method of index validation for Splunk-to-Splunk (S2S) events for this token. More A value of "disabled" means the Splunk platform doesn't validate the event's index and the "indexes" setting has no effect for the S2S events. A value of "disabled_for_internal" means the Splunk platform doesn't validate internal indexes and allows all S2S events destined for them. The platform validates other indexes according to the "indexes" setting. A value of "enabled_for_all" means the platform validates all indexes according to the "indexes" setting. The platform silently drops rejected events.	disabled_for_internal
`[http://name]` `index`	`<string>`The default index to use for this token.	the default index
`[http://name]` `sourcetype`	`<string>`The default sourcetype to use if it is not specified in an event.	empty string
`[http://name]` `outputgroup`	`<string>`The name of the forwarding output group to send data to. More There is no support for using this setting to send data over HTTP with a heavy forwarder.	empty string
`[http://name]` `queueSize`	`<integer>[KB\|MB\|GB]`The maximum size of the in-memory input queue. More See the description of 'queueSize' under the [tcp://] stanza for details on this setting. Unlike with other inputs that use in-memory queues, the logic for determining the size of the HEC input queue differs. Splunkd still sorts all HEC input stanzas in alphanumeric order. The first HEC input stanza that defines the token contained within the first HEC event that splunkd receives determines the size of the HEC input queue. Splunkd uses the value defined for 'queueSize' in that stanza. If you have not set 'queueSize', then splunkd uses the default value. If you configure multiple [http://] stanzas, and do not want to set 'persistentQueueSize', then alternatively give 'maxSize' under the '[queue=httpInputQ]' stanza a value in the server.conf configuration file.	500KB
`[http://name]` `persistentQueueSize`	`<integer>[KB\|MB\|GB\|TB]`Maximum size of the persistent queue file. More Persistent queues can help prevent loss of transient data. For information on persistent queues and how the 'queueSize' and 'persistentQueueSize' settings interact, search the online documentation for "persistent queues".. If you set this to a value other than 0, then 'persistentQueueSize' must be larger than either the in-memory queue size (as defined by the 'queueSize' setting in inputs.conf or 'maxSize' settings in [queue] stanzas in server.conf).	0 (no persistent queue)
`[http://name]` `connection_host`	`[ip\|dns\|proxied_ip\|none]`Specifies the host if an event doesn't have a host set. More "ip" sets the host to the IP address of the system sending the data. "dns" sets the host to the reverse DNS entry for IP address of the system that sends the data. For this to work correctly, set the forward DNS lookup to match the reverse DNS lookup in your DNS configuration. "proxied_ip" checks whether an X-Forwarded-For header was sent (presumably by a proxy server) and if so, sets the host to that value. Otherwise, the IP address of the system sending the data is used. "none" leaves the host as specified in the HTTP header.	No default
`[http://name]` `useACK`	`<boolean>`When set to "true", acknowledgment (ACK) is enabled. Events in a request are tracked until they are indexed. An events status (indexed or not) can be queried from the ACK endpoint with the ID for the request. More When set to false, acknowledgment is not enabled. This setting can be set at the stanza level.	false
`[http://name]` `customMetadataMode`	`[disabled\|query_string]`Specifies the mode for adding custom metadata fields to events when you use this token to send HEC requests to the /raw endpoint. More The following modes are supported: "disabled": Custom metadata injection is not allowed. Any custom metadata fields included in the request are ignored. "query_string": Allows custom metadata injection through query string parameters. When 'customMetadataMode' is set to "query_string", the following behavior applies: You can add a metadata field to an event by specifying a query string parameter in the HEC request using the format "fields_<fieldname>=<value>". You can also use an ampersand ( & ) to append additional field-value pairs. For example, the query string "?fields_env=prod&fields_region=us-east" adds the metadata fields "env" and "region" to the event. Field names and values must be URL-encoded if they contain characters other than a-z, A-Z, 0-9, hyphens ( - ), periods ( . ), underscores ( _ ), or tildes ( ~ ). To add an internal metadata field where the name is prefixed by an underscore ( _ ), use two underscores to separate the parameter name from the field name. For example, "fields__my_field" creates an internal field named "_my_field".	disabled
`[http://name]` `allowQueryStringAuth`	`<boolean>`Enables or disables sending authorization tokens with a query string. More This is a token level configuration. It may only be set for a particular token. To use this feature, set to "true" and configure the client application to include the token in the query string portion of the URL they use to send data to HEC in the following format: "https://<URL>?<your=query-string>&token=<your-token>" or "https://<URL>?token=<your-token>" if the token is the first element in the query string. If a token is sent in both the query string and an HTTP header, the token in the query string takes precedence, even if this feature is disabled. In other words, if a token is present in the query string, any token in the header for that request is not used. NOTE: Query strings may be observed in transit and/or logged in cleartext. There is no confidentiality protection for the transmitted tokens. Before using this in production, consult security personnel in your organization to understand and plan to mitigate the risks. At a minimum, always use HTTPS when you enable this feature. Check your client application, proxy, and logging configurations to confirm that the token is not logged in clear text. Give minimal access permissions to the token in HEC and restrict the use of the token only to trusted client applications.	false

`[perfmon://<name>]`

This section explains possible settings for configuring the Windows Performance Monitor input.
Each perfmon:// stanza represents an individually configured performance monitoring input. If you configure the input through Splunk Web, then the value of "<NAME>" matches what was specified there. While you can add performance monitor inputs manually, it is a best practice to use Splunk Web to configure them, because it is easy to mistype the values for Performance Monitor objects, counters, and instances.
NOTE: The perfmon stanza is for local systems ONLY. To define performance monitor inputs for remote machines, use wmi.conf.

Setting	Description	Default
`[perfmon://<name>]` `object`	`<string>`A valid Performance Monitor object as defined within Performance Monitor (for example, "Process," "Server," "PhysicalDisk"). More You can specify a single valid Performance Monitor object or use a regular expression (regex) to specify multiple objects. This setting is required, and the input does not run if the setting is not present.	No default
`[perfmon://<name>]` `counters`	`<semicolon-separated list>`This can be a single counter, or multiple valid Performance Monitor counters. More This setting is required, and the input does not run if the setting is not present. "*" is equivalent to all available counters for a given Performance Monitor object.	No default
`[perfmon://<name>]` `nonmetric_counters`	`<semicolon-separated list>`A list of performance counters on which the performance monitor input must not perform sampling. More When the input retrieves the value for a counter that is in this list, it returns the latest value it retrieves, rather than an average of the values that it got over the sampling interval, as defined by the 'samplingInterval' setting. Add counters to this setting in cases where the values that the input returns for a setting would be incorrect if it were averaged over a 'samplingInterval', or where average, minimum, or maximum values for a counter would not be of any interest. As an example, the "ID Process" counter works better as a non metric counter because the most recent measurement of the counter is more relevant than the average of any measurements of that counter.	No default
`[perfmon://<name>]` `instances`	`<semicolon-separated list>`One or more multiple valid Performance Monitor instances. More "" is equivalent to all available instances for a given Performance Monitor counter. If applicable instances are available for a counter and this setting is not present, then the input logs data for all available instances (this is the same as setting "instances = "). If there are no applicable instances for a counter, then you can omit this setting.	No default
`[perfmon://<name>]` `interval`	`<integer>`How often, in seconds, to poll for new data. More This setting is required, and the input does not run if the setting is not present. The recommended setting depends on the Performance Monitor object, counter(s), and instance(s) that you define in the input, and how much performance data you need. Objects with numerous instantaneous or per-second counters, such as "Memory", "Processor", and "PhysicalDisk" should have shorter interval times specified (anywhere from 1-3 seconds). Less volatile counters such as "Terminal Services", "Paging File", and "Print Queue" can have longer intervals configured.	300
`[perfmon://<name>]` `mode`	`[single\|multikv]`Specifies how the performance monitor input generates events. More Set to "single" to print each event individually. Set to "multikv" to print events in multikv (formatted multiple key-value pair) format.	single
`[perfmon://<name>]` `samplingInterval`	`<positive integer>`How often, in milliseconds, to poll for new data. More This is an advanced setting. Enables high-frequency performance sampling. The input collects performance data every sampling interval. It then reports averaged data and other statistics at every interval. The minimum legal value is 100, and the maximum legal value must be less than the 'interval' setting. If not set, high-frequency sampling does not occur. No default (disabled).
`[perfmon://<name>]` `stats`	`<average;count;dev;min;max>`Reports statistics for high-frequency performance sampling. More This is an advanced setting. Setting a 'samplingInterval' is required to use 'stats'. Acceptable values are: average, count, dev, min, max. You can specify multiple values by separating them with semicolons. Adds new fields that append the stats function name. Setting 'average' replaces the stats displayed in the default field. No default. (disabled)
`[perfmon://<name>]` `disabled`	`<boolean>`Specifies whether or not the input is enabled. More Set to 1 to disable the input, and 0 to enable it.	0 (enabled)
`[perfmon://<name>]` `showZeroValue`	`<boolean>`Specifies whether or not the input collects zero-value event data. More Set to 1 to capture zero value event data, and 0 to ignore such data.	0 (ignore zero value event data)
`[perfmon://<name>]` `useEnglishOnly`	`<boolean>`Controls which Windows Performance Monitor API the input uses. More If set to "true", the input uses PdhAddEnglishCounter() to add the counter string. This ensures that counters display in English regardless of the Windows machine locale. If set to "false", the input uses PdhAddCounter() to add the counter string. NOTE: if you set this setting to true, the 'object' setting does not accept a regular expression as a value on machines that have a non-English locale.	false
`[perfmon://<name>]` `useWinApiProcStats`	`<boolean>`Whether or not the Performance Monitor input uses process kernel mode and user mode times to calculate CPU usage for a process, rather than using the standard Performance Data Helper (PDH) APIs to calculate those values. More A problem was found in the PDH APIs that causes Performance Monitor inputs to show maximum values of 100% usage for a process on multicore Windows machines, even when the process uses more than 1 core at a time. When you configure this setting to "true", the input uses the GetProcessTime() function in the core Windows API to calculate CPU usage for a process, for the following Performance Monitor counters, only: * Processor Time * User Time * Privileged Time This means that, if a process uses 5 of 8 cores on an 8-core machine, that the input should return a value of around 500, rather than the incorrect 100. When you configure the setting to "false", the input uses the standard PDH APIs to calculate CPU usage for a process. On multicore systems, the maximum value that PDH APIs return is 100, regardless of the number of cores in the machine that the process uses. Performance monitor inputs use the PDH APIs for all other Performance Monitor counters. Configuring this setting has no effect on those counters. NOTE: If the Windows machine uses a non-English system locale, and you have set 'useWinApiProcStats' to "true" for a Performance Monitor input, then you must also set 'useEnglishOnly' to "true" for that input.	false
`[perfmon://<name>]` `formatString`	`<string>`Controls the print format for double-precision statistic counters. More Do not use quotes when specifying this string.	%.20g
`[perfmon://<name>]` `usePDHFmtNoCap100`	`<boolean>`Whether or not performance counter values that are greater than 100 (for example, counter values that measure the processor load on computers with multiple processors) are reset to 100. More If set to "true", the counter values can exceed 100. If set to "false", the input resets counter values to 100 if the processor load on multiprocessor computers exceeds 100.	true

`[MonitorNoHandle://<path>]`

This input intercepts file writes to the specific file.
<path> must be a fully qualified path name to a specific file. Wildcards and directories are not accepted.
This input type does not function on *nix machines.
You can specify more than one stanza of this type.

Setting	Description	Default
`[MonitorNoHandle://<path>]` `disabled`	`<boolean>`Whether or not the input is enabled.	0 (enabled)
`[MonitorNoHandle://<path>]` `index`	`<string>`Specifies the index where this input sends the data. More This setting is optional.	the default index

`[WinEventLog://<name>]`

This section explains possible settings for configuring the Windows Event Log monitor.
Each WinEventLog:// stanza represents an individually configured WinEventLog monitoring input. If you you configure the input through Splunk Web, the value of "<NAME>" matches what was specified there. While you can add event log monitor inputs manually, it is best practice to use Splunk Web to configure Windows event log monitor inputs because it is easy to mistype the values for event log channels.
NOTE: The WinEventLog stanza is for local systems ONLY. To define event log monitor inputs for remote machines, use wmi.conf.

Setting	Description	Default
`[WinEventLog://<name>]` `start_from`	`<string>`How the Event Log input is to chronologically read the Event Log channels. More A value of "oldest" means that the input reads Windows event logs from the oldest to the most recent. A value of "newest" means that the input reads Windows event logs in reverse, from the most recent to the oldest. After the input consumes the backlog of events, it stops. If you set this setting to "newest", and at the same time give the 'current_only' setting a value of "false", the combination can result in the input indexing duplicate events. Do not set this setting to "newest" and at the same time give the 'current_only' setting a value of "true". This results in the input not collecting any events because you told it to read existing events from newest to oldest and read only incoming events concurrently, which is a logically impossible combination.	oldest
`[WinEventLog://<name>]` `use_old_eventlog_api`	`<boolean>`Whether or not to read Event Log events with the Event Logging API. More This is an advanced setting. Contact Splunk Support before you change it. A value of "true" means the input uses the Event Logging API (instead of the Windows Event Log API) to read from the Event Log on Windows Server 2008, Windows Vista, and later installations.	false (Use the API that is specific to the OS)
`[WinEventLog://<name>]` `use_threads`	`<integer>`Specifies the number of threads, in addition to the default writer thread, that can be created to filter events with the deny list/allow list regular expression. More This is an advanced setting. Contact Splunk Support before you change it. The maximum number of threads is 15.	0
`[WinEventLog://<name>]` `thread_wait_time_msec`	`<integer>`The interval, in milliseconds, between attempts to re-read Event Log files when a read error occurs. More This is an advanced setting. Contact Splunk Support before you change it.	5000
`[WinEventLog://<name>]` `suppress_checkpoint`	`<boolean>`Whether or not the Event Log strictly follows the 'checkpointInterval' setting when it saves a checkpoint. More This is an advanced setting. Contact Splunk Support before you change it. By default, the Event Log input saves a checkpoint from between zero and 'checkpointInterval' seconds, depending on incoming event volume. If you set this setting to "true", that does not happen.	false
`[WinEventLog://<name>]` `suppress_sourcename`	`<boolean>`Whether or not to exclude the 'sourcename' field from events. More This is an advanced setting. Contact Splunk Support before you change it. When set to true, the input excludes the 'sourcename' field from events and thruput performance (the number of events processed per second) improves.	false
`[WinEventLog://<name>]` `suppress_keywords`	`<boolean>`Whether or not to exclude the 'keywords' field from events. More This is an advanced setting. Contact Splunk Support before you change it. When set to true, the input excludes the 'keywords' field from events and thruput performance (the number of events processed per second) improves.	false
`[WinEventLog://<name>]` `suppress_type`	`<boolean>`Whether or not to exclude the 'type' field from events. More This is an advanced setting. Contact Splunk Support before you change it. When set to true, the input excludes the 'type' field from events and thruput performance (the number of events processed per second) improves.	false
`[WinEventLog://<name>]` `suppress_task`	`<boolean>`Whether or not to exclude the 'task' field from events. More This is an advanced setting. Contact Splunk Support before you change it. When set to true, the input excludes the 'task' field from events and thruput performance (the number of events processed per second) improves.	false
`[WinEventLog://<name>]` `suppress_opcode`	`<boolean>`Whether or not to exclude the 'opcode' field from events. When set to true, the input excludes the 'opcode' field from events and thruput performance (the number of events processed per second) improves. More This is an advanced setting. Contact Splunk Support before you change it.	false
`[WinEventLog://<name>]` `current_only`	`<boolean>`Whether or not to acquire only events that arrive while the instance is running. More A value of "true" means the input only acquires events that arrive while the instance runs and the input is on. The input does not read data which was stored in the Windows Event Log while the instance was not running. This means that there will be gaps in the data if you restart the instance or experiences downtime. A value of "false" means the input first gets all existing events that are stored in the log which have higher event IDs (have arrived more recently) than the most recent events acquired. The input then monitors events that arrive in real time. If you set this setting to "false", and at the same time set the 'start_from' setting to "newest", the combination can result in the indexing of duplicate events. Do not set this setting to "true" and at the same time set the 'start_from' setting to "newest". This results in the input not collecting any events because you told it to read existing events from newest to oldest and read only incoming events concurrently, which is a logically impossible combination.	false (Gather stored events with higher event IDs first before monitoring live events)
`[WinEventLog://<name>]` `batch_size`	`<integer>`How many Windows Event Log items to read per request. More If troubleshooting identifies that the Event Log input is a bottleneck in acquiring data, increasing this value can help. NOTE: Splunk Support has seen cases where large values can result in a stall in the Event Log subsystem. If you increase this value significantly, monitor closely for trouble. In local and customer acceptance testing, a value of 10 was acceptable for both throughput and reliability.	10
`[WinEventLog://<name>]` `checkpointInterval`	`<integer>`How often, in seconds, that the Windows Event Log input saves a checkpoint. More Checkpoints store the eventID of acquired events. This lets the input continue monitoring at the correct event after a shutdown or outage.	0
`[WinEventLog://<name>]` `checkpointSync`	`<boolean>`Determines whether the input processor forces writing a checkpoint file to disk immediately or lets the operating system handle when writing of the file to disk occurs. More A value of "true" means the input processor triggers writing of a checkpoint file to disk immediately. It also saves the file to a temporary location and renames it instead of overwriting the existing file.	false
`[WinEventLog://<name>]` `channel_wait_time`	`<integer>`How long, in seconds, that the Windows Event Log input waits for an Event Log channel that is not available to become available again. More Some Event Log channels, like the Windows Defender channel, become unavailable during a Windows Defender Platform update and it takes some time to become available again. If the Event Log input is unable to collect event logs from a certain Event Log channel, change this setting to an appropriate value. For example, if the input does not collect Windows Defender event logs after a Windows Defender Platform update, increase this value. The maximum wait time is 180 (3 minutes).	0
`[WinEventLog://<name>]` `disabled`	`<boolean>`Whether or not the input is enabled. More Set to 1 to disable the input, and 0 to enable it.	0 (enabled)
`[WinEventLog://<name>]` `evt_resolve_ad_obj`	`<boolean>`How the input should interact with Active Directory while indexing Windows Event Log events. More If you set this setting to true, the input resolves the Active Directory Security IDentifier (SID) objects to their canonical names for a specific Windows Event Log channel. If you enable the setting, the rate at which the input reads events on high-traffic Event Log channels can decrease. Latency can also increase during event acquisition. This is due to the overhead involved in performing AD translations. When you set this setting to true, you can optionally specify the domain controller name or dns name of the domain to bind to with the 'evt_dc_name' setting. The input connects to that domain controller to resolve the AD objects. If you set this setting to false, the input does not attempt any resolution.	false (disabled) for all channels
`[WinEventLog://<name>]` `evt_skip_GUID_resolution`	`<comma-separated list>`A list of Windows Event Codes for which the Splunk platform does not contact the domain controller to resolve global unique identifiers (GUIDs) that are withing the event. More Separate multiple event IDs or event ID ranges with commas. If the event code matches an event, The Splunk platform does not contact the DC to resolve any GUIDs in this event. This setting only takes effect if 'evt_resolve_ad_obj' has a value of "true". If 'evt_resolve_ad_obj' has a value of "false", this setting has no effect. This setting has no effect on SID resolution. See 'Event ID list format' later in this file for the proper formatting of the event list.	none
`[WinEventLog://<name>]` `evt_dc_name`	`<string>`Which Active Directory domain controller to bind to for AD object resolution. More If you prefix a dollar sign to a value (for example, $my_domain_controller), the input interprets the value as an environment variable. If the environment variable has not been defined on the host, it is the same as if the value is blank. This setting is optional. This setting can be set to the NetBIOS name of the domain controller or the fully-qualified DNS name of the domain controller. Either name type can, optionally, be preceded by two backslash characters. The following examples represent correctly formatted domain controller names: "FTW-DC-01" "\\FTW-DC-01" "FTW-DC-01.splunk.com" "\\FTW-DC-01.splunk.com" $my_domain_controller
`[WinEventLog://<name>]` `evt_dns_name`	`<string>`The fully-qualified DNS name of the domain that the input should bind to for AD object resolution. More This setting is optional.
`[WinEventLog://<name>]` `evt_resolve_ad_ds`	`[auto\|PDC]`How the input should choose the domain controller to bind for AD resolution. More This setting is optional. If set to PDC, the input only contacts the primary domain controller to resolve AD objects. If set to auto, the input lets Windows chose the best domain controller. If you set the 'evt_dc_name' setting, the input ignores this setting.	auto (let Windows determine the domain controller to use)
`[WinEventLog://<name>]` `evt_ad_cache_disabled`	`<boolean>`Enables or disables the AD object cache.	false (enabled)
`[WinEventLog://<name>]` `evt_ad_cache_exp`	`<integer>`The expiration time, in seconds, for AD object cache entries. More This setting is optional.	3600 (1 hour)
`[WinEventLog://<name>]` `evt_ad_cache_exp_neg`	`<integer>`The expiration time, in seconds, for negative AD object cache entries. More This setting is optional.	10
`[WinEventLog://<name>]` `evt_ad_cache_max_entries`	`<integer>`The maximum number of AD object cache entries. More This setting is optional.	1000
`[WinEventLog://<name>]` `evt_exclude_fields`	`<comma-separated list>`A list of valid Windows Event Log fields to exclude from Windows Event Log events. More Specify fields that you want excluded from each event report. Do not exclude fields that you have also added to allow lists or deny lists. If fields are present in both, then 'evt_exclude_fields' excludes those fields, regardless of their presence in the allow list or deny list and the allow list or deny list will not behave as expected. The input logs an error to splunkd.log in this case. This setting is similar to, but operates differently than, the 'suppress_' settings. The 'suppress_' settings avoid using the Windows API to gather Windows events that match the available fields, which helps with CPU performance. The 'evt_exclude_fields' is valid for all Windows Event Log fields, and while it does use the Windows API for all transactions, it discards the fields in each event that match, which helps reduce total data ingestion. Does not effect event report if 'renderXML' is set to "true". The 'evt_exclude_fields' setting is valid for all Windows Event Log fields.	No default
`[WinEventLog://<name>]` `evt_sid_cache_disabled`	`<boolean>`Enables or disables account Security IDentifier (SID) cache. More This setting is global. It affects all Windows Event Log stanzas.	0
`[WinEventLog://<name>]` `evt_sid_cache_exp`	`<unsigned integer>`The expiration time, in seconds, for account SID cache entries. More This setting is global. It affects all Windows Event Log stanzas. This setting is optional.	3600
`[WinEventLog://<name>]` `evt_sid_cache_exp_neg`	`<unsigned integer>`The expiration time, in seconds, for negative account SID cache entries. More This setting is optional. This setting is global. It affects all Windows Event Log stanzas.	10
`[WinEventLog://<name>]` `evt_sid_cache_max_entries`	`<unsigned integer>`The maximum number of account SID cache entries. More This setting is global. It affects all Windows Event Log stanzas. This setting is optional.	10
`[WinEventLog://<name>]` `wec_event_format`	`[raw_event\|rendered_event]`The content format of the events that the Splunk platform expects to receive from a Windows Event Collector (WEC) subscription, before WEC sends the events to their destination log, for example, a Windows Event Log channel. More This setting helps associate incoming WEC event formats with the Splunk platform internal interpretation before the platform looks up pre-rendered messages in Windows event logs. If the WEC subscription that targets this channel has its 'content Format' set to "Events", then set 'wec_event_format' to "raw_event". If the WEC subscription that targets this channel has its 'content Format' set to "RenderedText", then set 'wec_event_format' to "rendered_event". If multiple WEC subscriptions share the same value for the 'destination log' setting, but have different 'content Format' values, you have two options: You can update the WEC subscriptions so that they share the same values for 'content format'. Or you can create custom ForwardedEvents channels for each WEC subscription, point each WEC subscription to a custom ForwardedEvents channel, and set equivalent values for 'wec_event_format' as described previously. If Windows Event Collector does not forward these events, this setting is optional. NOTE: You must restart the Splunk platform when you update WEC subscriptions, to synchronize with the new subscription configuration.	rendered_event (for 'ForwardedEvents' and custom channels named 'ForwardedEvents-1', 'ForwardedEvents-2', etc.); raw_event (for all other channels)
`[WinEventLog://<name>]` `index`	`<string>`Specifies the index that this input should send the data to. More This setting is optional.	The default index
`[WinEventLog://<name>]` `whitelist`	`<comma-separated list> \| key=regex [key=regex]`These settings are optional. More Both numbered and unnumbered allow lists and deny lists support two formats: A comma-separated list of event IDs. A list of key=regular expression pairs. You cannot combine these formats. You can use either format on a specific line. Numbered allow list settings are permitted from 1 to 9, so whitelist1 through whitelist9 and blacklist1 through blacklist9 are supported. If no allow list or deny list rules are present, the input reads all events.
`[WinEventLog://<name>]` `blacklist`	`<comma-separated list> \| key=regex [key=regex]`These settings are optional. More Both numbered and unnumbered allow lists and deny lists support two formats: A comma-separated list of event IDs. A list of key=regular expression pairs. You cannot combine these formats. You can use either format on a specific line. Numbered allow list settings are permitted from 1 to 9, so whitelist1 through whitelist9 and blacklist1 through blacklist9 are supported. If no allow list or deny list rules are present, the input reads all events.
`[WinEventLog://<name>]` `whitelist1`	`<comma-separated list> \| key=regex [key=regex]`These settings are optional. More Both numbered and unnumbered allow lists and deny lists support two formats: A comma-separated list of event IDs. A list of key=regular expression pairs. You cannot combine these formats. You can use either format on a specific line. Numbered allow list settings are permitted from 1 to 9, so whitelist1 through whitelist9 and blacklist1 through blacklist9 are supported. If no allow list or deny list rules are present, the input reads all events.
`[WinEventLog://<name>]` `whitelist2`	`<comma-separated list> \| key=regex [key=regex]`These settings are optional. More Both numbered and unnumbered allow lists and deny lists support two formats: A comma-separated list of event IDs. A list of key=regular expression pairs. You cannot combine these formats. You can use either format on a specific line. Numbered allow list settings are permitted from 1 to 9, so whitelist1 through whitelist9 and blacklist1 through blacklist9 are supported. If no allow list or deny list rules are present, the input reads all events.
`[WinEventLog://<name>]` `whitelist3`	`<comma-separated list> \| key=regex [key=regex]`These settings are optional. More Both numbered and unnumbered allow lists and deny lists support two formats: A comma-separated list of event IDs. A list of key=regular expression pairs. You cannot combine these formats. You can use either format on a specific line. Numbered allow list settings are permitted from 1 to 9, so whitelist1 through whitelist9 and blacklist1 through blacklist9 are supported. If no allow list or deny list rules are present, the input reads all events.
`[WinEventLog://<name>]` `whitelist4`	`<comma-separated list> \| key=regex [key=regex]`These settings are optional. More Both numbered and unnumbered allow lists and deny lists support two formats: A comma-separated list of event IDs. A list of key=regular expression pairs. You cannot combine these formats. You can use either format on a specific line. Numbered allow list settings are permitted from 1 to 9, so whitelist1 through whitelist9 and blacklist1 through blacklist9 are supported. If no allow list or deny list rules are present, the input reads all events.
`[WinEventLog://<name>]` `whitelist5`	`<comma-separated list> \| key=regex [key=regex]`These settings are optional. More Both numbered and unnumbered allow lists and deny lists support two formats: A comma-separated list of event IDs. A list of key=regular expression pairs. You cannot combine these formats. You can use either format on a specific line. Numbered allow list settings are permitted from 1 to 9, so whitelist1 through whitelist9 and blacklist1 through blacklist9 are supported. If no allow list or deny list rules are present, the input reads all events.
`[WinEventLog://<name>]` `whitelist6`	`<comma-separated list> \| key=regex [key=regex]`These settings are optional. More Both numbered and unnumbered allow lists and deny lists support two formats: A comma-separated list of event IDs. A list of key=regular expression pairs. You cannot combine these formats. You can use either format on a specific line. Numbered allow list settings are permitted from 1 to 9, so whitelist1 through whitelist9 and blacklist1 through blacklist9 are supported. If no allow list or deny list rules are present, the input reads all events.
`[WinEventLog://<name>]` `whitelist7`	`<comma-separated list> \| key=regex [key=regex]`These settings are optional. More Both numbered and unnumbered allow lists and deny lists support two formats: A comma-separated list of event IDs. A list of key=regular expression pairs. You cannot combine these formats. You can use either format on a specific line. Numbered allow list settings are permitted from 1 to 9, so whitelist1 through whitelist9 and blacklist1 through blacklist9 are supported. If no allow list or deny list rules are present, the input reads all events.
`[WinEventLog://<name>]` `whitelist8`	`<comma-separated list> \| key=regex [key=regex]`These settings are optional. More Both numbered and unnumbered allow lists and deny lists support two formats: A comma-separated list of event IDs. A list of key=regular expression pairs. You cannot combine these formats. You can use either format on a specific line. Numbered allow list settings are permitted from 1 to 9, so whitelist1 through whitelist9 and blacklist1 through blacklist9 are supported. If no allow list or deny list rules are present, the input reads all events.
`[WinEventLog://<name>]` `whitelist9`	`<comma-separated list> \| key=regex [key=regex]`These settings are optional. More Both numbered and unnumbered allow lists and deny lists support two formats: A comma-separated list of event IDs. A list of key=regular expression pairs. You cannot combine these formats. You can use either format on a specific line. Numbered allow list settings are permitted from 1 to 9, so whitelist1 through whitelist9 and blacklist1 through blacklist9 are supported. If no allow list or deny list rules are present, the input reads all events.
`[WinEventLog://<name>]` `blacklist1`	`<comma-separated list> \| key=regex [key=regex]`These settings are optional. More Both numbered and unnumbered allow lists and deny lists support two formats: A comma-separated list of event IDs. A list of key=regular expression pairs. You cannot combine these formats. You can use either format on a specific line. Numbered allow list settings are permitted from 1 to 9, so whitelist1 through whitelist9 and blacklist1 through blacklist9 are supported. If no allow list or deny list rules are present, the input reads all events.
`[WinEventLog://<name>]` `blacklist2`	`<comma-separated list> \| key=regex [key=regex]`These settings are optional. More Both numbered and unnumbered allow lists and deny lists support two formats: A comma-separated list of event IDs. A list of key=regular expression pairs. You cannot combine these formats. You can use either format on a specific line. Numbered allow list settings are permitted from 1 to 9, so whitelist1 through whitelist9 and blacklist1 through blacklist9 are supported. If no allow list or deny list rules are present, the input reads all events.
`[WinEventLog://<name>]` `blacklist3`	`<comma-separated list> \| key=regex [key=regex]`These settings are optional. More Both numbered and unnumbered allow lists and deny lists support two formats: A comma-separated list of event IDs. A list of key=regular expression pairs. You cannot combine these formats. You can use either format on a specific line. Numbered allow list settings are permitted from 1 to 9, so whitelist1 through whitelist9 and blacklist1 through blacklist9 are supported. If no allow list or deny list rules are present, the input reads all events.
`[WinEventLog://<name>]` `blacklist4`	`<comma-separated list> \| key=regex [key=regex]`These settings are optional. More Both numbered and unnumbered allow lists and deny lists support two formats: A comma-separated list of event IDs. A list of key=regular expression pairs. You cannot combine these formats. You can use either format on a specific line. Numbered allow list settings are permitted from 1 to 9, so whitelist1 through whitelist9 and blacklist1 through blacklist9 are supported. If no allow list or deny list rules are present, the input reads all events.
`[WinEventLog://<name>]` `blacklist5`	`<comma-separated list> \| key=regex [key=regex]`These settings are optional. More Both numbered and unnumbered allow lists and deny lists support two formats: A comma-separated list of event IDs. A list of key=regular expression pairs. You cannot combine these formats. You can use either format on a specific line. Numbered allow list settings are permitted from 1 to 9, so whitelist1 through whitelist9 and blacklist1 through blacklist9 are supported. If no allow list or deny list rules are present, the input reads all events.
`[WinEventLog://<name>]` `blacklist6`	`<comma-separated list> \| key=regex [key=regex]`These settings are optional. More Both numbered and unnumbered allow lists and deny lists support two formats: A comma-separated list of event IDs. A list of key=regular expression pairs. You cannot combine these formats. You can use either format on a specific line. Numbered allow list settings are permitted from 1 to 9, so whitelist1 through whitelist9 and blacklist1 through blacklist9 are supported. If no allow list or deny list rules are present, the input reads all events.
`[WinEventLog://<name>]` `blacklist7`	`<comma-separated list> \| key=regex [key=regex]`These settings are optional. More Both numbered and unnumbered allow lists and deny lists support two formats: A comma-separated list of event IDs. A list of key=regular expression pairs. You cannot combine these formats. You can use either format on a specific line. Numbered allow list settings are permitted from 1 to 9, so whitelist1 through whitelist9 and blacklist1 through blacklist9 are supported. If no allow list or deny list rules are present, the input reads all events.
`[WinEventLog://<name>]` `blacklist8`	`<comma-separated list> \| key=regex [key=regex]`These settings are optional. More Both numbered and unnumbered allow lists and deny lists support two formats: A comma-separated list of event IDs. A list of key=regular expression pairs. You cannot combine these formats. You can use either format on a specific line. Numbered allow list settings are permitted from 1 to 9, so whitelist1 through whitelist9 and blacklist1 through blacklist9 are supported. If no allow list or deny list rules are present, the input reads all events.
`[WinEventLog://<name>]` `blacklist9`	`<comma-separated list> \| key=regex [key=regex]`These settings are optional. More Both numbered and unnumbered allow lists and deny lists support two formats: A comma-separated list of event IDs. A list of key=regular expression pairs. You cannot combine these formats. You can use either format on a specific line. Numbered allow list settings are permitted from 1 to 9, so whitelist1 through whitelist9 and blacklist1 through blacklist9 are supported. If no allow list or deny list rules are present, the input reads all events.
`[WinEventLog://<name>]` `suppress_text`	`<boolean>`Whether or not to include the description of the event text for a given Event Log event. More This setting is optional. Set this setting to true to suppress the inclusion of the event text description. Set this value to false to include the event text description.	false
`[WinEventLog://<name>]` `renderXml`	`<boolean>`Whether or not the input returns the event data in XML (eXtensible Markup Language) format or in plain text. More A value of "true" means that the input renders events in XML format. A value of "false" means that the input renders events in plain text. If you give this setting a value of "true", you should also give the 'suppress_text', 'suppress_sourcename', 'suppress_keywords', 'suppress_task', and 'suppress_opcode' settings a value of "true" to improve thruput performance. A value of "true" also changes the method by which you create allow- and deny lists to filter events. For these kinds of lists to work, you must use the '$xmlRegex' special key and assign regular expression values to use those lists. Search the Splunk platform Getting Data In Manual for "Filter data in XML format with the XmlRegex Key" for details.	false

`[admon://<name>]`

This section explains possible settings for configuring the Active Directory monitor input.
Each admon:// stanza represents an individually configured Active Directory monitoring input. If you configure the input with Splunk Web, then the value of "<NAME>" matches what was specified there. While you can add Active Directory monitor inputs manually, it is best practice to use Splunk Web to configure Active Directory monitor inputs because it is easy to mistype the values for Active Directory monitor objects.

Setting	Description	Default
`[admon://<name>]` `targetDc`	`<string>`The fully qualified domain name of a valid, network-accessible Active Directory domain controller (DC). More This setting is case sensitive. Do not use 'targetdc' or 'targetDC', but rather 'targetDc'.	The DC that the local host used to connect to AD. The input binds to its root Distinguished Name (DN).
`[admon://<name>]` `adsUseSSL`	`<boolean>`Whether or not the Splunk platform instance uses TLS to connect and bind to an Active Directory object for authentication. More A value of "true" means that the instance uses the ADS_USE_SSL flag when it attempts to bind to AD objects. NOTE: For encrypted connections to work, you must have the appropriate certificates in place. See the chapter "Introduction to securing The Splunk Platform with TLS" in the Securing Splunk Enterprise Manual in the Splunk documentation for more information. A value of "false" means that the instance does not attempt to encrypt connections to bind to AD objects over TLS.	false
`[admon://<name>]` `startingNode`	`<string>`Where in the Active Directory directory tree to start monitoring. More The user that you configure Splunk software to run as at installation determines where the input starts monitoring.	the root of the directory tree
`[admon://<name>]` `monitorSubtree`	`<boolean>`Whether or not to monitor the subtree(s) of a given Active Directory tree path. More Set this to 1 to monitor subtrees of a given directory tree path and 0 to monitor only the path itself.	1 (monitor subtrees of a given directory tree path)
`[admon://<name>]` `disabled`	`<boolean>`Whether or not the input is enabled. More Set this to 1 to disable the input and 0 to enable it.	0 (enabled)
`[admon://<name>]` `index`	`<string>`The index to store incoming data into for this input. More This setting is optional.	the default index
`[admon://<name>]` `printSchema`	`<boolean>`Whether or not to print the Active Directory schema. More Set this to 1 to print the schema and 0 to not print the schema.	1 (print the Active Directory schema)
`[admon://<name>]` `baseline`	`<boolean>`Whether or not to query baseline objects. More Baseline objects are objects which currently reside in Active Directory. Baseline objects also include previously deleted objects. Set this to 1 to query baseline objects, and 0 to not query baseline objects.	0 (do not query baseline objects)

`[WinRegMon://<name>]`

This section explains possible settings for configuring the Windows Registry Monitor input.
Each WinRegMon:// stanza represents an individually configured WinRegMon monitoring input.
If you configure the inputs with Splunk Web, the value of "<NAME>" matches what was specified there. While you can add event log monitor inputs manually, it is best practice to use Splunk Web to configure Windows registry monitor inputs because it is easy to mistype the values for Registry hives and keys.
The WinRegMon input is for local systems only. You cannot monitor the Registry remotely.

Setting	Description	Default
`[WinRegMon://<name>]` `proc`	`<string>`The processes this input should monitor for Registry access. More If set, matches against the process name which performed the Registry access. The input includes events from processes that match the regular expression that you specify here. The input filters out events for processes that do not match the regular expression.	.* (match all processes)
`[WinRegMon://<name>]` `hive`	`<string>`The Registry hive(s) that this input should monitor for Registry access. More If set, matches against the Registry key that was accessed. The input includes events from Registry hives that match the regular expression that you specify here. The input filters out events for Registry hives that do not match the regular expression.	No default
`[WinRegMon://<name>]` `type`	`<string>`A regular expression that specifies the type(s) of Registry event(s) that you want the input to monitor.	No default
`[WinRegMon://<name>]` `baseline`	`<boolean>`Whether or not the input should get a baseline of Registry events when it starts. More If you set this to 1, the input captures a baseline for the specified hive when it starts for the first time. It then monitors live events.	0 (do not capture a baseline for the specified hive first before monitoring live events)
`[WinRegMon://<name>]` `baseline_interval`	`<integer>`Selects how much downtime in continuous registry monitoring should trigger a new baseline for the monitored hive and/or key. More In detail: Sets the minimum time interval, in seconds, between baselines. At startup, a WinRegMon input does not generate a baseline if less time has passed since the last checkpoint than baseline_interval chooses. In normal operation, checkpoints are updated frequently as data is acquired, so this will cause baselines to occur only when monitoring was not operating for a period of time. If baseline is set to 0 (disabled), the setting has no effect.	86400 (1 day)
`[WinRegMon://<name>]` `disabled`	`<boolean>`Whether or not the input is enabled. More Set this to 1 to disable the input, or 0 to enable it.	0 (enabled)
`[WinRegMon://<name>]` `index`	`<string>`The index that this input should send the data to. More This setting is optional.	the default index

`[WinHostMon://<name>]`

This section explains possible settings for configuring the Windows host monitor input.
Gathers status information from the local Windows system components as per the 'type' field, described after this section.
Each WinHostMon:// stanza represents an WinHostMon monitoring input.
The "<name>" component of the stanza name is used as the source field on generated events, unless an explicit source setting is added to the stanza. It does not affect what data is collected (see type setting for that).
If you configure the input in Splunk Web, the value of "<name>" matches what was specified there.
NOTE: The WinHostMon input is for local Windows systems only. You cannot monitor Windows host information remotely.

Setting	Description	Default
`[WinHostMon://<name>]` `type`	`<semicolon-separated list>`An expression that specifies the type(s) of host inputs that you want the input to monitor. More Type can be (case insensitive): Computer;Process;Processor;NetworkAdapter;Service;OperatingSystem;Disk;Driver;Roles	No default
`[WinHostMon://<name>]` `interval`	`<integer>`The interval, in seconds, between when the input runs to gather Windows host information and generate events. More See 'interval' in the Scripted input section for more information.
`[WinHostMon://<name>]` `disabled`	`<boolean>`Whether or not the input is enabled. More Set this to 1 to disable the input, or 0 to enable it.	0 (enabled)
`[WinHostMon://<name>]` `index`	`<string>`The index that this input should send the data to. More This setting is optional.	the default index

`[WinPrintMon://<name>]`

This section explains possible settings for configuring the Windows print monitor input.
Each WinPrintMon:// stanza represents an WinPrintMon monitoring input. The value of "<name>" matches what was specified in Splunk Web.
NOTE: The WinPrintMon input is for local Windows systems only.
The "<name>" component of the stanza name is used as the source field on generated events, unless an explicit source setting is added to the stanza. It does not affect what data is collected (see type setting for that).

Setting	Description	Default
`[WinPrintMon://<name>]` `type`	`<semicolon-separated list>`An expression that specifies the type(s) of print inputs that you want the input to monitor. More Type can be (case insensitive): Printer;Job;Driver;Port	No default
`[WinPrintMon://<name>]` `interval`	`<integer>`The interval, in seconds, between when the input runs to gather Windows host information and generate events. More See 'interval' in the Scripted input section for more information.
`[WinPrintMon://<name>]` `baseline`	`<boolean>`Whether or not to capture a baseline of print objects when the input starts for the first time. More If you set this setting to 1, the input captures a baseline of the current print objects when the input starts for the first time.	0 (do not capture a baseline)
`[WinPrintMon://<name>]` `disabled`	`<boolean>`Whether or not the input is enabled. More Set to 1 to disable the input, or 0 to enable it.	0 (enabled)
`[WinPrintMon://<name>]` `index`	`<string>`The index that this input should send the data to. More This setting is optional.	the default index

`[WinNetMon://<name>]`

This section explains possible settings for configuring a Network Monitor input.
Each WinNetMon:// stanza represents an individually configured network monitoring input. The value of "<name>" matches what was specified in Splunk Web. It is best practice to use Splunk Web to configure Network Monitor inputs because it is easy to mistype the values for Network Monitor objects.

Setting	Description	Default
`[WinNetMon://<name>]` `remoteAddress`	`<regular expression>`A regular expression that represents the remote IP address of a host that is involved in network communication. More This setting accepts a regular expression that matches against IP addresses only, not host names. For example: 192\.168\..* The input includes events for remote IP addresses that match the regular expression that you specify here. The input filters out events for remote IP addresses that do not match the regular expression. No default (include all remote address events).
`[WinNetMon://<name>]` `process`	`<regular expression>`A regular expression that represents the process or application that performed a network access. More The input includes events for processes that match the regular expression that you specify here. The input filters out events for processes that do not match the regular expression. No default (include all processes and application events).
`[WinNetMon://<name>]` `user`	`<regular expression>`A regular expression that represents the Windows user name that performed a network access. More The input includes events for user names that match the regular expression that you specify here. The input filters out events for user names that do not match the regular expression. No default (include all user name events).
`[WinNetMon://<name>]` `addressFamily`	`[ipv4];[ipv6]`Determines the events to include by network address family. More Setting "ipv4" alone includes only IPv4 packets, while "ipv6" alone includes only IPv6 packets. To specify both families, separate them with a semicolon. For example: ipv4;ipv6 No default (include events with both address families).
`[WinNetMon://<name>]` `packetType`	`[connect];[accept];[transport]`Determines the events to include by network packet type. More To specify multiple packet types, separate them with a semicolon. For example: connect;transport No default (include events with any packet type).
`[WinNetMon://<name>]` `direction`	`[inbound];[outbound]`Determines the events to include by network transport direction. More To specify multiple directions, separate them with a semicolon. For example: inbound;outbound No default (include events with any direction).
`[WinNetMon://<name>]` `protocol`	`[tcp];[udp]`Determines the events to include by network protocol. More To specify multiple protocols, separate them with a semicolon. For example: tcp;udp For more information about protocols, see http://www.ietf.org/rfc/rfc1700.txt No default (include events with all protocols)
`[WinNetMon://<name>]` `readInterval`	`<integer>`How often, in milliseconds, that the input should read the network kernel driver for events. More Advanced option. Use the default value unless there is a problem with input performance. Set this to adjust the frequency of calls into the network kernel driver. Choosing lower values (higher frequencies) can reduce network performance, while higher numbers (lower frequencies) can cause event loss. The minimum allowed value is 10 and the maximum allowed value is 1000.	100
`[WinNetMon://<name>]` `driverBufferSize`	`<integer>`The maximum number of packets that the network kernel driver retains for retrieval by the input. More Set to adjust the maximum number of network packets retained in the network driver buffer. Advanced option. Use the default value unless there is a problem with input performance. Configuring this setting to lower values can result in event loss, while higher values can increase the size of non-paged memory on the host. The minimum allowed value is 128 and the maximum allowed value is 32768.	32768
`[WinNetMon://<name>]` `userBufferSize`	`<integer>`The maximum size, in megabytes, of the user mode event buffer. More Controls amount of packets cached in the the user mode. Advanced option. Use the default value unless there is a problem with input performance. Configuring this setting to lower values can result in event loss, while higher values can increase the amount of memory that the network monitor uses. The minimum allowed value is 20 and the maximum allowed value is 500.	20
`[WinNetMon://<name>]` `mode`	`[single\|multikv]`Specifies how the network monitor input generates events. More Set to "single" to generate one event per packet. Set to "multikv" to generate combined events of many packets in multikv format (many packets described in a single table as one event).	single
`[WinNetMon://<name>]` `multikvMaxEventCount`	`<integer>`The maximum number of packets to combine in multikv format when you set the 'mode' setting to "multikv". More Has no effect when 'mode' is set to "single". Advanced option. The minimum allowed value is 10 and the maximum allowed value is 500.	100
`[WinNetMon://<name>]` `multikvMaxTimeMs`	`<integer>`The maximum amount of time, in milliseconds, to accumulate packet data to combine into a large tabular event in multikv format. More Has no effect when 'mode' is set to 'single'. Advanced option. The minimum allowed value is 100 and the maximum allowed value is 5000.	1000
`[WinNetMon://<name>]` `sid_cache_disabled`	`[0\|1]`Enables or disables account Security IDentifier (SID) cache. More This setting is global. It affects all Windows Network Monitor stanzas.	0
`[WinNetMon://<name>]` `sid_cache_exp`	`<integer>`The expiration time, in seconds, for account SID cache entries. More Optional. This setting is global. It affects all Windows Network Monitor stanzas.	3600
`[WinNetMon://<name>]` `sid_cache_exp_neg`	`<integer>`The expiration time, in seconds, for negative account SID cache entries. More Optional. This setting is global. It affects all Windows Network Monitor stanzas.	10
`[WinNetMon://<name>]` `sid_cache_max_entries`	`<integer>`The maximum number of account SID cache entries. More Optional. This setting is global. It affects all Windows Network Monitor stanzas.	10
`[WinNetMon://<name>]` `disabled`	`<boolean>`Whether or not the input is enabled. More Set to 1 to disable the input, and 0 to enable it.	0 (enabled)
`[WinNetMon://<name>]` `index`	`<string>`The index where this input sends the data. More Optional.	the default index

`[powershell]`

Setting	Description	Default
`[powershell]` `io_threads`	`<integer>`The number of threads that Splunk software spawns to run PowerShell scripts that have been configured in the inputs.conf file. More If you specify a value that is less than or equal to 0, Splunk software autotunes this setting. The default can vary. Splunk software autotunes the number of threads based on the availability of CPU resources on the machine.
`[powershell]` `serialization_threads`	`<integer>`The number of threads that Splunk software spawns for serialization of PowerShell objects that it has collected into XML strings. More This serialization, or conversion of objects, occurs according to the Modular Input XML protocol. If you specify a value that is less than or equal to 0, Splunk software autotunes this setting. The default can vary. Splunk software autotunes the number of threads based on available CPU resources on the machine.
`[powershell]` `event_serialization_format`	`[kv\|json]`The event format into which Powershell objects are serialized. More The supported event formats are "kv" and "json". For example, given the following PowerShell object: $psObj = @{ A: "a string" B: 18 C: "a log line" } If you set 'event_serialization_format' to "kv", the Splunk platform indexes the event as follows: A="a string" B=18 C="a log line" If you set 'event_serialization_format' to "json", the Splunk platform indexes the event as follows: { "A": "a string", "B": 18, "C": "a log line" }	kv
`[powershell]` `process_completion_check_interval`	`<integer>`The interval, in milliseconds, between which the Splunk platform checks whether a PowerShell process has completed running.	200

`[powershell://<name>]`

Runs Windows PowerShell version 3 commands or scripts.

Setting	Description	Default
`[powershell://<name>]` `script`	`<string>`A PowerShell command-line script or .ps1 script file that the input should run.	No default
`[powershell://<name>]` `schedule`	`[<positive integer>\|<cron schedule>]`How often to run the specified PowerShell command or script. More There are two options available for how to run the command or script: You can specify a number, which represents how often, in seconds, to run the command or script after the instance starts. You can specify a "cron" style schedule, which lets you determine the days, hours, minutes, and seconds when the script or command runs. An example cron schedule is "30 * * * *", which means to run the script at 30 minutes past the hour, every hour of every day. Regardless of which option you choose, the command or script always runs once when the instance starts.	The command or script runs once, when the instance starts.

`[powershell2]`

Setting	Description	Default
`[powershell2]` `io_threads`	`<integer>`The number of threads that Splunk software spawns to run PowerShell scripts that have been configured in inputs.conf. More If you specify a value that is less than or equal to 0, Splunk software autotunes this setting. The default can vary. Splunk software autotunes the number of threads based on the availability of CPU resources on the machine.
`[powershell2]` `event_serialization_format`	`[ kv \| json ]`The event format into which Powershell objects are serialized. More The supported event formats are "kv" and "json". For example, given the following PowerShell object: $psObj = @{ A: "a string" B: 18 C: "a log line" } If you set 'event_serialization_format' to "kv", the Splunk platform indexes the event as follows: A="a string" B=18 C="a log line" If you set 'event_serialization_format' to "json", the Splunk platform indexes the event as follows: { "A": "a string", "B": 18, "C": "a log line" }	kv
`[powershell2]` `process_completion_check_interval`	`<integer>`The interval, in milliseconds, between which the Splunk platform checks whether a PowerShell process has completed running. More Default = 200

`[powershell2://<name>]`

Runs Windows PowerShell version 2 commands or scripts.

Setting	Description	Default
`[powershell2://<name>]` `script`	`<string>`A PowerShell command-line script or .ps1 script file that the input should run.	No default
`[powershell2://<name>]` `schedule`	`<string>`How often to run the specified PowerShell command or script. More You can provide a valid cron schedule.	Runs the command or script once, at startup.

`[remote_queue:<name>]`

This section explains possible settings for configuring a remote queue.
Each remote_queue: stanza represents an individually configured remote queue monitoring input.
Note that only 1 remote queue stanza is supported as an input queue.

Setting	Description	Default
`[remote_queue:<name>]` `remote_queue.*`	`<string>`Optional. More This section explains possible settings for configuring a remote queue. With remote queues, the splunk indexer might require additional configuration, specific to the type of remote queue. You can pass configuration information to the splunk indexer by specifying the settings through the following schema: remote_queue.<scheme>.<config-variable> = <value>. For example: remote_queue.sqs_smartbus.access_key = ACCESS_KEY This setting is optional.	No default
`[remote_queue:<name>]` `disabled`	`<boolean>`Whether the remote queue input is active. More A value of "true" means the remote queue input is inactive. A value of "false" means the remote queue input is active.	false
`[remote_queue:<name>]` `remote_queue.type`	`[sqs_smartbus\|asq\|gcs_smartbus]`The remote queue type. More This type can be one of the following: "sqs_smartbus" (Amazon Web Services (AWS) Simple Queue Service Smartbus) "asq" (Azure Storage Queue (ASQ)) "gcs_smartbus" (Google Publisher/Subscriber) If you specify this setting, you must configure it with a valid value. If you do not, the remote queue that is associated with the 'remote.queue.<name>' stanza in which this setting is configured will not start. This setting is only applicable if Splunk indexer clustering is turned on and the instance is running as a cluster peer.	No default
`[remote_queue:<name>]` `remote_queue.large_message_store.supports_versioning`	`<boolean>`Specifies whether or not the remote storage supports versioning. More Versioning is a means of keeping multiple variants of an object in the same bucket on the remote storage. This setting is optional.	true
`[remote_queue:<name>]` `compressed`	`<boolean>`See the description for TCPOUT ATTRIBUTES in outputs.conf.spec.
`[remote_queue:<name>]` `negotiateProtocolLevel`	`<unsigned integer>`See the description for TCPOUT ATTRIBUTES in outputs.conf.spec.
`[remote_queue:<name>]` `channelReapInterval`	`<integer>`See the description for TCPOUT ATTRIBUTES in outputs.conf.spec.
`[remote_queue:<name>]` `channelTTL`	`<integer>`See the description for TCPOUT ATTRIBUTES in outputs.conf.spec.
`[remote_queue:<name>]` `channelReapLowater`	`<integer>`See the description for TCPOUT ATTRIBUTES in outputs.conf.spec.
`[remote_queue:<name>]` `concurrentChannelLimit`	`<unsigned integer>`See the description for [splunktcp].
`[remote_queue:<name>]` `remote_queue.sqs_smartbus.access_key`	`<string>`The access key to use when authenticating with the remote queue system supporting the SQS API. More If not specified, the indexer looks for these environment variables: 'AWS_ACCESS_KEY_ID' or 'AWS_ACCESS_KEY' (in that order). If the environment variables are not set and the indexer is running on Elastic Compute Cloud (EC2), the indexer attempts to use the secret key from the Identity and Access Management (IAM) role. This setting is optional.	No default
`[remote_queue:<name>]` `remote_queue.sqs_smartbus.secret_key`	`<string>`The secret key to use when authenticating with the remote queue system supporting the SQS API. More If not specified, the indexer looks for these environment variables: AWS_SECRET_ACCESS_KEY or AWS_SECRET_KEY (in that order). If the environment variables are not set and the indexer is running on EC2, the indexer attempts to use the secret key from the IAM role. This setting is optional.	No default
`[remote_queue:<name>]` `remote_queue.sqs_smartbus.auth_region`	`<string>`The authentication region to use when signing the requests when interacting with the remote queue system supporting the SQS API. More If not specified and the indexer is running on EC2, the auth_region is constructed automatically based on the EC2 region of the instance where the the indexer is running. This setting is optional.	No default
`[remote_queue:<name>]` `remote_queue.sqs_smartbus.endpoint`	`<string>`The URL of the remote queue system supporting the SQS API. More The scheme, http or https, can be used to enable or disable SSL connectivity with the endpoint. If not specified, the endpoint is constructed automatically based on the auth_region as follows: https://sqs.<auth_region>.amazonaws.com If specified, the endpoint must match the effective auth_region, which is either a value specified in 'remote_queue.sqs.auth_region' or a value constructed automatically based on the EC2 region of the running instance. Example: https://sqs.us-west-2.amazonaws.com/ This setting is optional.	No default
`[remote_queue:<name>]` `remote_queue.sqs_smartbus.max_connections`	`<unsigned integer>`The maximum number of HTTP connections that can be simultaneously in progress for certain queue operations. More A value of 0 means unlimited.	8
`[remote_queue:<name>]` `remote_queue.sqs_smartbus.message_group_id`	`<string>`Currently not supported. This setting is related to a feature that is still under development. More The Message Group ID for Amazon Web Services Simple Queue Service (SQS) First-In, First-Out (FIFO) queues. Setting a Message Group ID controls how messages within an AWS SQS queue are processed. For information on SQS FIFO queues and how messages in those queues are processed, see "Recommendations for FIFO queues" in the AWS SQS Developer Guide. If you configure this setting, Splunk software assumes that the SQS queue is a FIFO queue, and that messages in the queue should be processed first-in, first-out. Otherwise, Splunk software assumes that the SQS queue is a standard queue. Can be between 1-128 alphanumeric or punctuation characters. NOTE: FIFO queues must have Content-Based Deduplication enabled. This setting is optional.	No default
`[remote_queue:<name>]` `remote_queue.sqs_smartbus.retry_policy`	`[max_count\|none]`The retry policy to use for remote queue operations. More A retry policy specifies whether and how to retry file operations that fail for those failures that might be intermittent. Retry policies: + "max_count": Imposes a maximum number of times a queue operation can be retried upon intermittent failure. + "none": Do not retry file operations upon failure. This setting is optional.	"max_count"
`[remote_queue:<name>]` `remote_queue.sqs_smartbus.max_count.max_retries_per_part`	`<unsigned integer>`When 'remote_queue.sqs_smartbus.retry_policy' is set to "max_count", sets the maximum number of times a queue operation can be retried upon intermittent failure. More This setting is optional.	3
`[remote_queue:<name>]` `remote_queue.sqs_smartbus.timeout.connect`	`<unsigned integer>`The connection timeout, in seconds, when interacting with SQS for this queue. More This setting is optional.	5
`[remote_queue:<name>]` `remote_queue.sqs_smartbus.timeout.read`	`<unsigned integer>`The read timeout, in seconds, when interacting with SQS for this queue. More This setting is optional.	60
`[remote_queue:<name>]` `remote_queue.sqs_smartbus.timeout.write`	`<unsigned integer>`The write timeout, in seconds, when interacting with SQS for this queue. More This setting is optional.	60
`[remote_queue:<name>]` `remote_queue.sqs_smartbus.timeout.receive_message`	`<unsigned integer>`The receive message wait time, in seconds, when interacting with SQS for this queue. More When set to greater than 0, enables "long polling." If there are no messages immediately available, the queue waits at most 'remote_queue.sqs.timeout.receive_message' seconds for a message to become available. When 0, disables long polling. When not set, uses the value configured for the queue via the AWS SQS console. Maximum value: 20 This setting is optional.	20
`[remote_queue:<name>]` `remote_queue.sqs_smartbus.timeout.visibility`	`<unsigned integer>`The default "visibility timeout," in seconds, to use when explicitly changing the visibility of specific messages in the queue. More NOTE: Changing the value of 'remote_queue.sqs.timeout.visibility' does not change the implicit visibility timeout configured for the queue in the AWS SQS console. This setting is optional.	300
`[remote_queue:<name>]` `remote_queue.sqs_smartbus.buffer.visibility`	`<unsigned integer>`The default time, in seconds, before 'remote_queue.sqs.timeout.visibility' at which visibility of specific messages in the queue needs to be changed. More This setting is optional.	15
`[remote_queue:<name>]` `remote_queue.sqs_smartbus.executor_max_workers_count`	`<positive integer>`The maximum number of worker threads that can be used by indexer per pipeline set to execute SQS tasks. More A value of 0 is equivalent to 1.	4
`[remote_queue:<name>]` `remote_queue.sqs_smartbus.min_pending_messages`	`<unsigned integer>`The default "minimum number of pending messages" to use before receiving messages off remote queue. Messages are only received when the sum of internal queue message count and pending object GET (from large messages storage) count is below the set value. More This setting is optional.	10
`[remote_queue:<name>]` `remote_queue.sqs_smartbus.renew_retries`	`<unsigned integer>`The number of retries for a particular message on a given indexer after being received from the remote queue, before it is proactively moved to the DLQ folder.	50
`[remote_queue:<name>]` `remote_queue.sqs_smartbus.large_message_store.endpoint`	`<string>`The URL of the remote storage system supporting the S3 API. More The scheme, http or https, can be used to enable or disable SSL connectivity with the endpoint. If not specified, the endpoint is constructed automatically based on the auth_region as follows: https://s3.<auth_region>.amazonaws.com If specified, the endpoint must match the effective auth_region, which is either a value specified via 'remote_queue.sqs_smartbus.auth_region' or a value constructed automatically based on the EC2 region of the running instance. Example: https://s3.us-west-2.amazonaws.com/ This setting is optional.	No default
`[remote_queue:<name>]` `remote_queue.sqs_smartbus.large_message_store.path`	`<string>`The remote storage location where messages that are larger than the underlying queue maximum message size will reside. More The format for this attribute is: <scheme>://<remote-location-specifier> The "scheme" identifies a supported external storage system type. The "remote-location-specifier" is an external system-specific string for identifying a location inside the storage system. These external systems are supported: - Object stores that support the AWS S3 protocol. These use the scheme "s3". For example, "path=s3://mybucket/some/path". If not specified, messages exceeding the underlying queue's maximum message size are dropped. This setting is optional.	No default
`[remote_queue:<name>]` `remote_queue.sqs_smartbus.large_message_store.sslVerifyServerCert`	`<boolean>`If set to true, the Splunk platform verifies the certificate presented by the S3 server and checks that the common name and alternate name match the ones specified in 'remote_queue.sqs_smartbus.large_message_store.sslCommonNameToCheck' and 'remote_queue.sqs_smartbus.large_message_store.sslAltNameToCheck'.	false
`[remote_queue:<name>]` `remote_queue.sqs_smartbus.large_message_store.sslVersions`	`<comma-separated list>`The list of TLS versions to use to connect to 'remote.sqs_smartbus.large_message_store.endpoint'. More The versions available are "tls1.0", "tls1.1", "tls1.2", and "tls1.3". The special version "*" selects all supported versions. The version "tls" selects all versions tls1.0 or newer. If a version is prefixed with "-" it is removed from the list. SSL versions 2 and 3 are always disabled. "-ssl2" and "-ssl3" are accepted as values in the version list, but have no effect.	tls1.2,tls1.3
`[remote_queue:<name>]` `remote_queue.sqs_smartbus.large_message_store.sslCommonNameToCheck`	`<commonName1>, <commonName2>, ..`If this value is set, and 'remote_queue.sqs_smartbus.large_message_store.sslVerifyServerCert' is set to true, the Splunk platform instance checks the common name of the certificate presented by the remote server (specified in 'remote_queue.sqs_smartbus.large_message_store.endpoint') against this list of common names.	not set
`[remote_queue:<name>]` `remote_queue.sqs_smartbus.large_message_store.sslAltNameToCheck`	`<alternateName1>, <alternateName2>, ..`If this value is set, and 'remote_queue.sqs_smartbus.large_message_store.sslVerifyServerCert' is set to true, the Splunk platform instance checks the alternate name(s) of the certificate presented by the remote server (specified in 'remote_queue.sqs_smartbus.large_message_store.endpoint') against this list of subject alternate names.	not set
`[remote_queue:<name>]` `remote_queue.sqs_smartbus.large_message_store.sslRootCAPath`	`<path>`Full path to the Certificate Authority (CA) certificate PEM format file containing one or more certificates concatenated together. The S3 certificate will be validated against the CAs present in this file.	[sslConfig/caCertFile] in server.conf
`[remote_queue:<name>]` `remote_queue.sqs_smartbus.large_message_store.cipherSuite`	`<cipher suite string>`If set, uses the specified cipher string for the SSL connection. More If not set, uses the default cipher string. Must specify 'dhFile' to enable any Diffie-Hellman ciphers.	TLSv1+HIGH:TLSv1.2+HIGH:@STRENGTH
`[remote_queue:<name>]` `remote_queue.sqs_smartbus.large_message_store.ecdhCurves`	`<comma-separated list>`ECDH curves to use for ECDH key negotiation. More Specify the curves in the order of preference. The client sends these curves as a part of Client Hello. Splunk software only supports named curves specified by their short names. The list of valid named curves by their short/long names can be obtained by executing this command: $SPLUNK_HOME/bin/splunk cmd openssl ecparam -list_curves e.g. ecdhCurves = prime256v1,secp384r1,secp521r1	not set
`[remote_queue:<name>]` `remote_queue.sqs_smartbus.large_message_store.dhFile`	`<path>`PEM format Diffie-Hellman parameter file name. More DH group size must be no less than 2048bits. This file is required in order to enable any Diffie-Hellman ciphers. Optional	not set
`[remote_queue:<name>]` `remote_queue.sqs_smartbus.dead_letter_queue.name`	`<string>`The name of the dead letter queue.
`[remote_queue:<name>]` `remote_queue.sqs_smartbus.dead_letter_queue.process_interval`	`<number><unit>`The frequency of processing messages that have landed in the dead letter queue. More Examples: 30s, 6h	1d
`[remote_queue:<name>]` `remote_queue.sqs_smartbus.large_message_store.encryption_scheme`	`[sse-s3\|sse-c\|none]`The encryption scheme used by remote storage	none.
`[remote_queue:<name>]` `remote_queue.sqs_smartbus.large_message_store.kms_endpoint`	`<string>`The endpoint to connect to for generating KMS keys. More This setting is required if 'large_message_store.encryption_scheme' is set to sse-c. Examples: https://kms.us-east-2.amazonaws.com	No default
`[remote_queue:<name>]` `remote_queue.sqs_smartbus.large_message_store.key_id`	`<string>`The ID for the primary key that KMS uses to generate a data key pair. The primary key is stored in AWS. More This setting is required if 'large_message_store.encryption_scheme' is set to sse-c. Examples: alias/sqsssekeytrial, 23456789-abcd-1234-11aa-c50f99011223	No default
`[remote_queue:<name>]` `remote_queue.sqs_smartbus.large_message_store.key_refresh_interval`	`<string>`The time interval to refresh primary key.	24h
`[remote_queue:<name>]` `remote_queue.asq.access_key`	`<string>`The access key to use when authenticating with the remote queue system supporting the ASQ API.	No default
`[remote_queue:<name>]` `remote_queue.asq.secret_key`	`<string>`The secret key to use when authenticating with the remote queue system supporting the ASQ API.	No default
`[remote_queue:<name>]` `remote_queue.asq.endpoint`	`<string>`The URL of the remote queue system supporting the ASQ API. More Example: https://somestorage.queue.core.windows.net/	No default
`[remote_queue:<name>]` `remote_queue.asq.retry_policy`	`[max_count\|none]`The retry policy to use for remote queue operations. More A retry policy specifies whether and how to retry file operations that fail for those failures that might be intermittent. Retry policies: + "max_count": Imposes a maximum number of times a queue operation can be retried upon intermittent failure. Set max_count with the 'max_count.max_retries_in_total' setting. + "none": Do not retry file operations upon failure. This setting is optional.	"max_count"
`[remote_queue:<name>]` `remote_queue.asq.max_count.max_retries_in_total`	`<unsigned integer>`When 'remote_queue.asq.retry_policy' is set to "max_count", sets the maximum number of times a queue operation can be retried upon intermittent failure. More This setting is optional.	3
`[remote_queue:<name>]` `remote_queue.asq.renew_retries`	`<unsigned integer>`The number of retries for a particular message on a given indexer after being received from the remote queue, before it is proactively moved to the DLQ folder.	50
`[remote_queue:<name>]` `remote.asq.backoff.initial_delay`	`<unsigned integer><unit>`Currently not supported. This setting is related to a feature that is still under development. More If retries are enabled, a backoff interval is used to perform the retries. This interval is doubled on each retry up to the limit set in remote.asq.backoff.max_retry_delay. This setting specifies the delay between each retry. If "ms", "s", or "m" is not specified, the default unit is seconds.	4000ms (4s)
`[remote_queue:<name>]` `remote.asq.backoff.max_retry_delay`	`<unsigned integer><unit>`Currently not supported. This setting is related to a feature that is still under development. More If retries are enabled, a backoff interval is used to perform the retries. This setting specifies the maximum delay before the next retry. If "ms", "s", or "m" is not specified, the default unit is seconds.	2601000ms (120s)
`[remote_queue:<name>]` `remote_queue.asq.message_receive_max_count`	`<unsigned integer>`The maximum number of messages, that are received from the 'remote_queue' endpoint, to store in the Azure in-memory message queue. More This setting is optional.	32
`[remote_queue:<name>]` `remote_queue.asq.timeout.connect`	`<unsigned integer>`The connection timeout, in seconds, when interacting with ASQ for this queue. More This setting is optional.	5
`[remote_queue:<name>]` `remote_queue.asq.timeout.read`	`<unsigned integer>`Currently not supported. This setting is related to a feature that is still under development. More The read timeout, in seconds, when interacting with ASQ for this queue. This setting is optional.	60
`[remote_queue:<name>]` `remote_queue.asq.timeout.write`	`<unsigned integer>`The write timeout, in seconds, when interacting with ASQ for this queue. More This setting is optional.	60
`[remote_queue:<name>]` `remote_queue.asq.timeout.visibility`	`<unsigned integer>`The timeout, in seconds, to use when explicitly changing the visibility of specific messages in the Azure in-memory queue. More This setting is optional.	60
`[remote_queue:<name>]` `remote_queue.asq.executor_max_workers_count`	`<positive integer>`The maximum number of worker threads that can be used by indexer per pipeline set to execute ASQ tasks. More A value of 0 is equivalent to 1.	4
`[remote_queue:<name>]` `remote_queue.asq.large_message_store.endpoint`	`<string>`The URL of the remote storage system supporting the Azure API. More Example: https://somestorage.blob.core.windows.net/	No default
`[remote_queue:<name>]` `remote_queue.asq.large_message_store.path`	`<string>`The remote storage location where messages that are larger than the underlying queue maximum message size will reside. More If not specified, messages exceeding the underlying queue's maximum message size are dropped. For Microsoft Azure Blob storage, this is specified as "azure://<container-name>/path_to_blob" Note that "<container-name>" is needed here only if 'remote_queue.asq.large_message_store.container_name' is not set.	No default
`[remote_queue:<name>]` `remote_queue.asq.large_message_store.container_name`	`<string>`Specifies the Azure container to use complying with Microsoft Azure Storage Container naming convention. More This setting is optional.	No default
`[remote_queue:<name>]` `remote_queue.asq.large_message_store.sslVerifyServerCert`	`<boolean>`If set to true, the Splunk platform verifies the certificate presented by the Azure server.	false
`[remote_queue:<name>]` `remote_queue.asq.large_message_store.sslVersions`	`<comma-separated list>`The list of TLS versions to use to connect to 'remote.asq.large_message_store.endpoint'. More The versions available are "tls1.0", "tls1.1", "tls1.2", and "tls1.3". The special version "*" selects all supported versions. The version "tls" selects all versions tls1.0 or newer. If a version is prefixed with "-" it is removed from the list. SSL versions 2 and 3 are always disabled. "-ssl2" and "-ssl3" are accepted as values in the version list, but have no effect.	tls1.2,tls1.3
`[remote_queue:<name>]` `remote_queue.asq.large_message_store.sslRootCAPath`	`<path>`Full path to the Certificate Authority (CA) certificate PEM format file containing one or more certificates concatenated together. The S3 certificate will be validated against the CAs present in this file.	[sslConfig/caCertFile] in server.conf
`[remote_queue:<name>]` `remote_queue.asq.large_message_store.cipherSuite`	`<cipher suite string>`If set, uses the specified cipher string for the SSL connection. More If not set, uses the default cipher string.	TLSv1+HIGH:TLSv1.2+HIGH:@STRENGTH
`[remote_queue:<name>]` `remote_queue.asq.large_message_store.encryption_scheme`	`azure-sse-kv \| azure-sse-ms \| azure-sse-c`The encryption scheme to use for containers that are currently being stored. More azure-sse-kv: Maps to the Azure customer-managed keys in a key vault. See the Azure documentation for customer-managed keys for Azure Store encryption for details. azure-sse-ms: Maps to the Azure Microsoft-managed keys in Microsoft key store. See the Azure documentation for Azure Storage encryption for data at rest for details. azure-sse-c: Maps to the Azure customer-provided encryption keys in a Key Vault. See the Azure documentation for customer-provided keys for Azure Store encryption for details.	azure-sse-ms
`[remote_queue:<name>]` `remote_queue.asq.large_message_store.azure-sse-kv.encryptionScope`	`<string>`Required if remote_queue.asq.large_message_store.encryption_scheme = azure-sse-kv More Specifies the key used for encrypting blobs within the scope of this index.	No default
`[remote_queue:<name>]` `remote_queue.asq.large_message_store.azure-sse-c.key_type`	`azure_kv`The mechanism that a Splunk platform indexer uses to generate the key for sending data to Azure Storage. More Affects the 'azure-sse-c' encryption scheme only. The only valid value is "azure_kv", which indicates the Azure Key Vault Key Management Service (Azure KMS). You must also specify the required KMS settings: 'remote_queue.asq.large_message_store.azure-sse-c.azure_kv.key_name', 'remote_queue.asq.large_message_store.azure-sse-c.azure_kv.endpoint', 'remote_queue.asq.large_message_store.azure-sse-c.azure_kv.key_vault_tenant_id', 'remote_queue.asq.large_message_store.azure-sse-c.azure_kv.key_vault_client_id', and 'remote_queue.asq.large_message_store.azure-sse-c.azure_kv.key_vault_client_secret'. If you do not specify those settings, the indexer cannot start while the 'remote_queue.asq.large_message_store.encryption_scheme' setting has a value of "azure-sse-c".	azure_kv
`[remote_queue:<name>]` `remote_queue.asq.large_message_store.azure-sse-c.azure_kv.key_name`	`<string>`The Azure Key Vault key name for key encryption and decryption. More Required if 'remote_queue.asq.large_message_store.encryption_scheme' has a value of "azure-sse-c".	No default
`[remote_queue:<name>]` `remote_queue.asq.large_message_store.azure-sse-c.azure_kv.endpoint`	`<string>`The Azure Key Vault endpoint. More Required if 'remote_queue.asq.large_message_store.encryption_scheme' has a value of "azure-sse-c". Example: "https://<key-vault-name>.vault.azure.net/"	No default
`[remote_queue:<name>]` `remote_queue.asq.large_message_store.azure-sse-c.azure_kv.key_vault_tenant_id`	`<string>`The ID of the Azure Active Directory tenant for authenticating with the the Key Vault. More For more details about the tenant ID, check your Azure Active Directory subscription. Required only for client token-based authentication.	No default
`[remote_queue:<name>]` `remote_queue.asq.large_message_store.azure-sse-c.azure_kv.key_vault_client_id`	`<string>`Specifies the ID of the client, also called the application ID, which is the unique identifier that the Azure Active Directory issues to an application registration that identifies a specific application and the associated configurations. More You can obtain the client ID for an application from the Azure Portal in the Overview section for the registered application. Required only for client token-based authentication. Optional for managed identity authentication.	No default
`[remote_queue:<name>]` `remote_queue.asq.large_message_store.azure-sse-c.azure_kv.key_vault_client_secret`	`<string>`Specifies the secret key to use when authenticating the Key Vault using the client_id. More You generate the secret key through the Azure Portal. Required only for client token-based authentication.	No default
`[remote_queue:<name>]` `remote_queue.asq.fail_threshold_for_dlq`	`<unsigned integer>`This number denotes the number of times a message has to fail in processing after downloading / dequeueing, before the message is backed up in the dead letter queue smart store path.	5
`[remote_queue:<name>]` `remote_queue.gcs_smartbus.project_id`	`<string>`The Google Cloud project ID where the Pub/Sub topic resides and large message storage buckets are located. More This is required to authenticate and interact with the Pub/Sub API.	not set
`[remote_queue:<name>]` `remote_queue.gcs_smartbus.large_message_store.path`	`<string>`The path to the large message store.	not set
`[remote_queue:<name>]` `remote_queue.gcs_smartbus.pubsub_endpoint`	`<string>`The URL for the Publisher/Subscriber (Pub/Sub) Application Programming Interface (API) endpoint that the Splunk platform uses for connections. More You can use this setting to specify a custom endpoint for testing or for private Google Cloud environments. If you do not give this setting a value, the Splunk platform uses the standard Google Cloud Pub/Sub endpoint.	not set
`[remote_queue:<name>]` `remote_queue.gcs_smartbus.storage_endpoint`	`<string>`The URL for the Google Cloud Storage endpoint that the Splunk platform uses for large message storage. More You can use this setting to specify a custom endpoint for testing, using private endpoints, or connecting to compatible storage services. If you do not give this setting a value, the Splunk platform uses the standard Google Cloud Storage endpoint. Example: https://storage.googleapis.com	No default
`[remote_queue:<name>]` `remote_queue.gcs_smartbus.credential_file`	`<string>`Specifies the credential file that is used for Pub/Sub and large message storage authentication. More This file contains the service account credentials in JSON format. The service account must have the following roles: Pub/Sub Publisher Pub/Sub Subscriber Storage Object Admin This file must be located in $SPLUNK_HOME/etc/auth/ Example: credentials.json	No default
`[remote_queue:<name>]` `remote_queue.gcs_smartbus.large_message_store.connectUsingIpVersion`	`auto\|4-only\|6-only`Controls whether Splunk software makes outbound connections to the storage service using IPv4 or IPv6. More Connections to literal IPv4 or IPv6 addresses are unaffected by this setting. A value of "4-only" means that splunkd only attempts to connect to the IPv4 address. A value of "6-only" means that splunkd only attempts to connect to the IPv6 address. A value of "auto" means: If '[general]/listenOnIPv6' in server.conf has a value of "only", this setting defaults to "6-only". Otherwise, this setting defaults to "4-only".	auto
`[remote_queue:<name>]` `remote_queue.gcs_smartbus.large_message_store.sslVersionsForClient`	`tls1.0\|tls1.1\|tls1.2\|tls1.3`Defines the minimum SSL/TLS version to use for outgoing connections.	tls1.2
`[remote_queue:<name>]` `remote_queue.gcs_smartbus.large_message_store.sslVersionsForClient`	`tls1.0\|tls1.1\|tls1.2\|tls1.3`Defines the minimum SSL/TLS version to use for outgoing connections.	tls1.2
`[remote_queue:<name>]` `remote_queue.gcs_smartbus.large_message_store.sslVerifyServerCert`	`<boolean>`A value of "true" means that splunkd authenticates the certificate of the services it connects to by using the configured Certificate Authority (CA).	false
`[remote_queue:<name>]` `remote_queue.gcs_smartbus.large_message_store.sslVerifyServerName`	`<boolean>`Controls whether splunkd, as a client, performs a TLS hostname validation check on an SSL certificate that it receives upon an initial connection to a server. More A TLS hostname validation check ensures that a client communicates with the correct server. This check prevents redirection to another server by a machine-in-the-middle attack, where a malicious party inserts themselves between the client and the target server and impersonates that server. Specifically, the validation check forces splunkd to verify that the certificate that the server presents to the client has a Common Name or Subject Alternate Name that matches the host name portion of the URL that the client used to connect to the server. For this setting to have any effect, the 'sslVerifyServerCert' setting must have a value of "true". If 'sslVerifyServerCert' is set to "false", TLS hostname validation is not possible because certificate verification is not turned on. A value of "true" for this setting means that splunkd performs a TLS hostname validation check, verifying the server's name in the certificate. If that check fails, Splunk software terminates the SSL handshake immediately, which terminates the connection. Splunkd logs this failure at the ERROR logging level. A value of "false" for this setting means that splunkd does not perform the TLS hostname validation check. If the server presents an otherwise valid certificate, the client-to-server connection proceeds normally.	false
`[remote_queue:<name>]` `remote_queue.gcs_smartbus.large_message_store.sslRootCAPath`	`<path>`Full path to the Certificate Authority (CA) certificate PEM format file that contains one or more certificates concatenated together. The server certificate will be validated against the CAs present in this file.	[sslConfig/caCertFile] in server.conf
`[remote_queue:<name>]` `remote_queue.gcs_smartbus.large_message_store.cipherSuite`	`<cipher suite string>`Uses the specified cipher string for the SSL connection. More If this setting is not configured, splunkd uses the default cipher string.	TLSv1+HIGH:TLSv1.2+HIGH:@STRENGTH
`[remote_queue:<name>]` `remote_queue.gcs_smartbus.large_message_store.encryption`	`gcp-sse-c\|gcp-sse-kms\|gcp-sse-gcp`The encryption scheme to use for index buckets while stored on Google Cloud Storage (data-at-rest). More A value of "gcp-sse-c" maps to Google Cloud Platform (GCP) customer-supplied encryption keys. A value of "gcp-sse-kms" maps to GCP customer-managed encryption keys. A value of "gcp-sse-gcp" maps to GCP Google-managed encryption keys. Google Cloud always encrypts the incoming data on the server side. For the "gcp-sse-kms" scheme, you must grant your Cloud Storage service account permission to use your Cloud KMS key. For more details, search for "Assigning a Cloud KMS key to a service account" on the Google Cloud documentation site. To find your Cloud Storage service account, search for "Getting the Cloud Storage service account".	gcp-sse-gcp
`[remote_queue:<name>]` `remote_queue.gcs_smartbus.large_message_store.gcp_kms.locations`	`<string>`Required if 'remote_queue.gcs_smartbus.large_message_store.encryption' has a value of "gcp-sse-c" or "gcp-sse-kms". More Specifies the geographical regions where Key Management Service (KMS) key rings and keys are stored for access. Google Cloud offers three types of locations: regional locations such as "us-central1", dual-regional locations such as "nam4", and multi-regional locations such as "global" and "us". Search for "Cloud KMS locations" on the Google Cloud documentation site for a complete list. For best performance, choose a key ring and a key in the same location as the cloud stack.	No default
`[remote_queue:<name>]` `remote_queue.gcs_smartbus.large_message_store.gcp_kms.key_ring`	`<string>`Required if 'remote_queue.gcs_smartbus.large_message_store.encryption' has a value of "gcp-sse-c" or "gcp-sse-kms". More Specifies the name of the key ring used for encryption when uploading data to Google Cloud Storage. In Google Cloud, a key ring is a grouping of keys for organizational purposes. A key ring belongs to a Google Cloud Project and resides in a specific location. Search for "key ring" on the Google Cloud documentation site for more details.	No default
`[remote_queue:<name>]` `remote_queue.gcs_smartbus.large_message_store.gcp_kms.key`	`<string>`Required if 'remote_queue.gcs_smartbus.large_message_store.encryption' has a value of "gcp-sse-c" or "gcp-sse-kms". More Specifies the name of the encryption key used for uploading data to Google Cloud Storage.	No default
`[remote_queue:<name>]` `remote_queue.gcs_smartbus.large_message_store.encryption.gcp-sse-c.key_type`	`gcp_kms`Affects only the "gcp-sse-c" encryption scheme. More Identifies the mechanism the indexer uses to generate the key for sending data to Google Cloud Storage. The only valid value is "gcp_kms", which indicates Google Cloud Key Management Service (GCP KMS). You must also specify the following required Key Management Service (KMS) settings: 'remote_queue.gcs_smartbus.large_message_store.gcp_kms.locations' 'remote_queue.gcs_smartbus.large_message_store.gcp_kms.key_ring' 'remote_queue.gcs_smartbus.large_message_store.gcp_kms.key' If you do not specify these settings, the indexer cannot start while it uses "gcp-sse-c" encryption.	gcp_kms
`[remote_queue:<name>]` `remote_queue.gcs_smartbus.large_message_store.encryption.gcp-sse-c.key_refresh_interval`	`<unsigned integer>`Specifies the interval, in seconds, for generating a new key that is used for encrypting data uploaded to Google Cloud Storage.	86400
`[remote_queue:<name>]` `remote_queue.gcs_smartbus.max_hold_time_option`	`<number><unit>`The maximum time that the publisher holds a message before it flushes the message as part of Pub/Sub operations. More If you do not provide a <unit> for this setting value, the Splunk platform assumes that the value is in seconds. Example: 1m (1 minute), 30s (30 seconds), 50ms (50 milliseconds), 10 (10 seconds)	10ms
`[remote_queue:<name>]` `remote_queue.gcs_smartbus.max_deadline_time_option`	`<number><unit>`The maximum amount of time that the subscriber can take to acknowledge a message. More If the subscriber does not acknowledge the message before this time, the message becomes eligible for redelivery. If you do not provide a <unit> for this setting value, the Splunk platform assumes that the value is in seconds. Example: 1m (1 minute), 30s (30 seconds), 50ms (50 milliseconds), 10 (10 seconds)	600
`[remote_queue:<name>]` `remote_queue.gcs_smartbus.max_outstanding_messages_option`	`<integer>`The maximum number of outstanding messages for the subscriber.	0 (unlimited)
`[remote_queue:<name>]` `remote_queue.gcs_smartbus.max_concurrency_option`	`<integer>`The maximum number of gcs_smartbus Pub/Sub operations that can occur at the same time.	4
`[remote_queue:<name>]` `remote_queue.gcs_smartbus.dead_letter_queue.name`	`<string>`The name of the subscription to the dead letter queue. More Google Cloud Services Pub/Sub delivers messages that subscribers can't acknowledge after multiple attempts to the dead-letter queue.
`[remote_queue:<name>]` `remote_queue.gcs_smartbus.dead_letter_queue.process_interval`	`<number><unit>`The interval between processing of messages that have landed in the dead letter queue. More If you do not provide a <unit> for this setting value, the Splunk platform assumes that the value is in seconds. Examples: 30s, 6h	1d
`[remote_queue:<name>]` `python.version`	`[default\|python\|python2\|python3\|python3.7\|python3.9\|latest]`DEPRECATED. Use 'python.required' instead to specify which Python versions the script supports. More For Python scripts only, selects which Python version to use. Either "default" or "python" select the system-wide default Python version. Set to "python3" or "python3.7" to use the Python 3.7 version. Set to "python3.9" to use the Python 3.9 version. In the context of configuring apps, the "latest" value is not currently supported. It is related to a feature that is still under development. Optional.	Not set; uses the system-wide Python version.
`[remote_queue:<name>]` `python.required`	`<comma-separated list>`For Python scripts only, the versions of Python that the script supports. More This setting takes precedence over the 'python.version' setting if both have values. The Splunk platform selects the highest version of Python that is available from the list that you provide. The following values are supported: "3.9": The script supports Python version 3.9. "3.13": The script supports Python version 3.13. "latest": The script uses the latest Python interpreter available. NOTE: The "latest" value is an internal value that is related to a feature that is still under development. Where possible, use a specific version string rather than "latest". Splunk software runs modular input scripts in two phases: introspection and runtime. It uses the following algorithm to select which interpreter to use. During the introspection phase: If the stanza that defines the scheme of the input also defines 'python.required', Splunk software uses that version of the interpreter for introspection. Otherwise, it evaluates configuration stanzas for the input that have been turned on. It ignores any configuration stanzas that have been turned off with 'disabled = true'. For stanzas that are turned on, the software chooses the highest version of the interpreter that any of the stanzas define with 'python.required'. Turning stanzas on and off can potentially change which interpreter Splunk software uses if they define 'python.required'. If neither stanza class defines 'python.required', then Splunk software uses 'python.version' if those stanza classes define it, or the default for 'python.version' if they do not. During the runtime phase: If the modular input runs as one script instance per stanza, Splunk software uses the following logic to determine the interpreter to use. If the configuration stanza defines 'python.required', Splunk software uses the interpreter version specified by the configuration stanza. If the configuration stanza does not define 'python.required' but its scheme stanza does, Splunk software uses the interpreter version specified by the scheme stanza. If neither the configuration stanza nor the scheme stanza defines 'python.required', Splunk software uses the 'python.version' value. If the modular input runs as a single script instance for all stanzas, Splunk software selects the interpreter version from the scheme stanza only. As there is only one process, there is no support for per-stanza overrides. If the scheme stanza defines 'python.required', Splunk software uses the interpreter version specified by the scheme stanza. If the scheme stanza does not define 'python.required', Splunk software uses the 'python.version' value. Best practice: Configure a single 'python.required' value for a modular input scheme. If different stanzas for the input specify different Python requirements, the interpreter Splunk software uses for the introspection and runtime phases might be inconsistent. NOTE: Use this setting instead of the deprecated 'python.version' setting. This setting is optional.	Not set.
`[remote_queue:<name>]` `run_introspection`	`<boolean>`Whether or not Splunk software runs introspection on a modular input scheme when you have disabled all of its associated scripts by using the 'disabled = 1' setting. More This setting applies only for modular inputs. It takes effect only if you specify it under a default stanza of a modular input scheme. A default stanza of a modular input scheme begins with the notation [<scheme name>] If set to "true", Splunk software runs introspection on a modular input scheme even when you have disabled all the input scripts for the scheme. If set to "false", Splunk software does not run introspection on a modular input scheme where you have disabled all scripts for the scheme. If introspection does not run for a scheme, then Splunk software does not register the modular input scripts that are associated with the scheme for execution and it is disabled completely. Use the 'disabled' setting to enable or disable individual modular input scripts. For example, to turn introspection off for the modular input scheme "myScheme": [myScheme] run_introspection = false	true

`[logd://<name>]`

This is the macOS logd input component for the Splunk platform.

Setting	Description	Default
`[logd://<name>]` `logd-backtrace`	`<boolean>`Whether or not the logd input includes backtraces. More A value of “true” means that the logd input includes backtraces in its events.	false
`[logd://<name>]` `logd-debug`	`<boolean>`Whether or not the logd input includes "Debug" events. More A value of “true” means that the logd input includes “Debug” level events.	false
`[logd://<name>]` `logd-info`	`<boolean>`Whether or not the logd input includes "Info" events. More A value of “true” means that the logd input includes “Info” level events.	true
`[logd://<name>]` `logd-loss`	`<boolean>`Whether or not the logd input includes message loss events. More A value of “true” means that the logd input includes message loss events.	false
`[logd://<name>]` `logd-signpost`	`<boolean>`Whether or not the logd input includes signposts. More A value of “true” means that the logd input includes signpost events.	false
`[logd://<name>]` `logd-predicate`	`<string>`Filters messages using the provided predicate, or filter expression, that is based on the NSPredicate definition. More The input supports a single predicate, but the predicate can be a compound one.	none
`[logd://<name>]` `logd-process`	`<comma-separated list>`The process ID on which to operate. More You can supply multiple process IDs with commas, for example "220,221,223".	none
`[logd://<name>]` `logd-source`	`<boolean>`Whether or not to include symbol names and source line numbers for messages, if available.	false
`[logd://<name>]` `logd-include-fields`	`<comma-separated list>`The fields to retrieve from a logD record.	all
`[logd://<name>]` `logd-exclude-fields`	`<comma-separated list>`The fields to ignore when parsing a logD record More Example setting: logd-exclude-fields = bootUUID,formatString	formatString,timestamp,timezoneName
`[logd://<name>]` `logd-interval`	`<unsigned integer>`How often, in seconds, that the input is to query logd for events,	30
`[logd://<name>]` `logd-starttime`	`<string>`The earliest acceptable time for the input to query logd for events. More Use the format "YYYY-MM-DD HH:MM:SS" to specify the timestamp.	No default
`[logd://<name>]` `logd-freetext`	`<string>`reserved for future use

`[journald://<name>]`

This is the systemd-journald input component for Splunk

Setting	Description	Default
`[journald://<name>]` `journalctl-include-fields`	`<string>`This setting and the "journalctl-exclude-fields" setting control the fields that the journald input retrieves. More The input selects most of the fields if they are in "one of "journalctl-include-fields" and not in 'journalctl-exclude-fields'. The exceptions are MESSAGE, CURSOR, and _REALTIME_TIMESTAMP. The system treats these fields specially. An empty 'journalctl-include-fields' value means to output all fields. If you want all fields except XYZ, leave 'journalctl-include-fields' empty, and set "journalctl-exclude-fields=XYZ". The input always retrieves the MESSAGE, __REALTIME_TIMESTAMP, and __CURSOR fields, but uses the __REALTIME_TIMESTAMP and __CURSOR fields internally and does not send them to the Splunk platform. Fields __MONOTONIC_TIMESTAMP and __SOURCE_REALTIME_TIMESTAMP should always be suppressed to decrease cardinality of data. Use Splunk event time instead.	PRIORITY,_SYSTEMD_UNIT,_SYSTEMD_CGROUP,_TRANSPORT,_PID,_UID, _MACHINE_ID,_GID,_COMM,_EXE
`[journald://<name>]` `journalctl-exclude-fields`	`<comma-separated list>`The fields to exclude. use this setting to filter which fields to send to the Splunk platform. More This filter is more computationally expensive than journalctl-output-fields, as it is not natively supported by API and requires post-processing	__MONOTONIC_TIMESTAMP,__SOURCE_REALTIME_TIMESTAMP
`[journald://<name>]` `journalctl-filter`	`<string>`These settings map directly to the arguments for the journalctl command. See the documentation for journalctl.	none
`[journald://<name>]` `journalctl-unit`	`<string>`Equivalent to ‘-u’ parameter of journalctl; show messages for the specified systemd unit	none
`[journald://<name>]` `journalctl-identifier`	`<string>`Equivalent to ‘-t’ parameter of journalctl; show messages for the specified syslog identifier SYSLOG_IDENTIFIER	none
`[journald://<name>]` `journalctl-priority`	`<string>`equivalent to ‘-p’ parameter of journalctl; filter output by message priorities or priority ranges.	7
`[journald://<name>]` `journalctl-boot`	`<string>`Equivalent to ‘-b’ parameter of journalctl; messages from a specific boot	none
`[journald://<name>]` `journalctl-facility`	`<string>`Equivalent to ‘--facility’ parameter of journalctl, syslog facility	none
`[journald://<name>]` `journalctl-grep`	`<string>`Equivalent to ‘-g’ parameter of journalctl; filter output to entries where the MESSAGE= field matches the specified regular expression. PERL-compatible regular expressions are used	none
`[journald://<name>]` `journalctl-user-unit`	`<string>`Equivalent to ‘--user-unit’ parameter of journalctl; show messages for the specified user session unit.	none
`[journald://<name>]` `journalctl-dmesg`	`<boolean>`Equivalent to ‘-k’ parameter of journalctl; show only kernel messages.	false
`[journald://<name>]` `journalctl-quiet`	`<boolean>`Equivalent to ‘-q’ parameter of journalctl; suppress all informational messages	false
`[journald://<name>]` `journalctl-freetext`	`<string>`reserved for future use

Example

[default]
host = collector01

[monitor:///var/log/app/current.log]
sourcetype = app:current
crcSalt = <SOURCE>
index = app_logs

[batch:///data/dropzone/*.csv]
move_policy = sinkhole
sourcetype = app:batch_export

[tcp://9514]
sourcetype = syslog
connection_host = dns

[script://./bin/get_metrics.py]
interval = 300
sourcetype = app:metrics

[http://ingest_pipeline_token]
disabled = 0
index = app_logs
sourcetype = app:hec

This forwarder tails a continuously-written log with a CRC salt to survive rotation, sinks a batch-dropped CSV export, listens for raw syslog on TCP 9514, runs a metrics-collection script every 5 minutes, and accepts HEC-posted events under one named token.

Validation

Set crcSalt on any monitor input where rotated files can share identical leading bytes -- otherwise Splunk may treat a genuinely new file as already indexed and skip it.
Confirm move_policy = sinkhole is intentional before deploying a batch:// input -- the source file is consumed, not just read.
Check whitelist/blacklist regexes against real file names in the target directory; an over-broad or mistyped pattern silently drops files from collection.
Verify a script:// input's interval matches the operational need -- too frequent wastes resources, too infrequent creates collection gaps.
Confirm HEC tokens have useACK set deliberately, matching the same acknowledgement decision made on the sending side's Forwarder Outputs.
Remember WMI and process-monitor inputs live in wmi.conf/procmon-filters.conf, not inputs.conf -- don't look for their settings here.

← Back to References

References / Splunk platform configuration

DB Connect Database Inputs Configuration

db_inputs.conf is a Splunk DB Connect app-specific configuration file, distinct from the platform's core inputs.conf even though it plays the same role: each stanza defines a scheduled SQL query against a Database Connection and how its result rows become indexed events. This article covers the settings that back the Splunk Taxonomy's DB Connect object (SOT-05.07.02).

Definition

Each [<name>] stanza in db_inputs.conf is one Database Input: a scheduled SQL query, run against a named Database Connection, whose result rows are converted into Splunk events (or metrics) on a fixed interval or cron schedule. It sits alongside db_connections.conf (which defines the JDBC connections themselves) inside the Splunk DB Connect add-on, and is what Splunk Taxonomy's DB Connect object represents in aggregate.

Not the same file as inputs.conf. db_inputs.conf is defined and owned by the Splunk DB Connect app, has its own spec, and is not part of the platform's core input mechanism documented in the Data Inputs Configuration reference -- despite the naming similarity and the shared "scheduled input" concept.

File locations

Configuration file: db_inputs.conf.

Scope	Path
App	`$SPLUNK_HOME/etc/apps/splunk_app_db_connect/{default,local}/db_inputs.conf`

Distinct from core inputs.conf -- can't be pushed by a Deployment Server; DB Connect manages it directly.

Identification & scheduling

Setting	Required?	Description
`description`	Optional	Free-text description of the input.
`interval`	Required	How often the input fetches data -- a number of seconds, or a cron expression.
`run_only_one`	Optional	Whether a scripted/modular input runs on only one search head in a Search Head Cluster. Not currently supported -- tied to a feature still under development. Default `true`.
`index`	Optional	Index events are stored in. Defaults to `default` if not specified.
`source`	Optional	Source assigned to indexed events; defaults to the stanza name.
`sourcetype`	Required	Sourcetype assigned to indexed events.
`host`	Optional	Host assigned to indexed events.
`input_type`	Optional	`event` or `metric` -- which kind of data this input produces. Defaults to `event`.
`template_name`	Optional	If the input was created from a template, names that template.

Connection & query

Setting	Required?	Description
`connection`	Required	Names the Database Connection (from `db_connections.conf`) this input runs against.
`mode`	Required	`batch`, `rising`, or `advanced` (deprecated since DBX v3.1 -- use `rising` instead). Determines whether the full query result is re-collected each run (batch) or only rows newer than a tracked checkpoint column (rising).
`query`	Required	The SQL statement retrieving data from the remote database.
`query_timeout`	Optional	Max execution time of the SQL, in seconds. Default 30.
`max_rows`	Optional	Max rows retrieved per run. Default 0 (unlimited).
`fetch_size`	Optional	Number of rows returned at a time from the database (JDBC fetch size). Default 300.
`batch_upload_size`	Optional	Number of rows uploaded to HEC per batch. Default 1000.

Rising-mode checkpointing

In rising mode, a designated column must always increase (a timestamp or auto-increment key); DB Connect tracks the last-seen value as a checkpoint so each run only pulls newer rows.

Setting	Description
`tail_rising_column_name`	Name of the rising checkpoint column, required unless in batch mode. When both this and `tail_rising_column_number` are set, the name takes priority unless it can't be resolved, in which case the code falls back to the column number.
`tail_rising_column_number`	1-based position of the rising column in the result set. Required for `advanced` mode.
`tail_rising_column_fullname`	Deprecated since DBX v3.1.0 in favour of `tail_rising_column_number`; retained only for front-end display.
`tail_rising_column_init_ckpt_value`	Internal use only (JSON). Do not edit manually.
`checkpoint_key`	Supported from DBX v3.10.0. References the KV Store document holding this input's checkpoint state.
`max_single_checkpoint_file_size`	Max checkpoint file size, in bytes, before it's archived. Default 10MB, max 100MB.

Timestamp handling

Setting	Description
`index_time_mode`	Required. `current` uses the collection time as the event's index time; `dbColumn` uses a database column instead.
`input_timestamp_column_number`	1-based column number supplying the event timestamp, used when `index_time_mode = dbColumn`.
`input_timestamp_format`	Java `SimpleDateFormat` pattern for parsing the timestamp column. If set, DB Connect reads the column as a string and parses it with this format; if not set, it reads the column as a native timestamp via JDBC instead.
`input_timestamp_column_name`	Deprecated since DBX v3.1.0 in favour of `input_timestamp_column_number`.
`input_timestamp_column_fullname`	Deprecated since DBX v3.1.0; retained only for front-end display.

If neither index_time_mode setting is resolvable, DB Connect uses the current time as each event's index time by default.

Legacy & deprecated settings

Retained by DB Connect for backward compatibility; ignored by the current UI.

Setting	Description
`ui_query_mode`	`simple` or `advanced` -- which query-building mode the UI used. Deprecated since DBX v3.1.0.
`ui_query_catalog`	Pre-populated catalog value for simple-mode query building. Deprecated since DBX v3.1.0.
`ui_query_schema`	Pre-populated schema value for simple-mode query building. Deprecated since DBX v3.1.0.
`ui_query_table`	Pre-populated table value for simple-mode query building. Deprecated since DBX v3.1.0.

Example

[orders_rising_feed]
description = Incremental pull of new order rows
connection = prod_orders_db
mode = rising
query = SELECT order_id, customer_id, order_total, updated_at FROM orders
tail_rising_column_name = updated_at
index_time_mode = dbColumn
input_timestamp_column_number = 4
input_timestamp_format = yyyy-MM-dd HH:mm:ss
interval = 300
index = db_orders
sourcetype = db:orders
fetch_size = 500
batch_upload_size = 1000

This input polls a production orders table every 5 minutes, pulling only rows whose updated_at value has advanced since the last checkpoint, and uses that same column as each event's index-time timestamp.

Validation

Confirm mode is rising rather than the deprecated advanced for any new input -- advanced is retained only for existing configurations.
Verify the rising column named in tail_rising_column_name is genuinely monotonically increasing -- a column that can decrease or repeat will cause rows to be re-collected or skipped.
Check query_timeout and fetch_size against the actual query cost -- an unbounded or slow query can exhaust the timeout before results return.
Confirm index_time_mode and, if dbColumn, that input_timestamp_format matches the real format of the source column -- a mismatch causes parse failures or misdated events.
Don't hand-edit tail_rising_column_init_ckpt_value or the checkpoint state directly -- treat it as internal to DB Connect.
Remember this file is DB Connect app-specific -- don't confuse its settings with the platform's core inputs.conf.

← Back to References

References / Splunk platform configuration

DB Connect Database Outputs Configuration

db_outputs.conf is the Splunk DB Connect app-specific configuration file for the reverse direction of data flow: each stanza runs a scheduled Splunk search and writes its results into a database table via a Database Connection. It is distinct both from db_inputs.conf (which pulls data from a database) and from the platform's core outputs.conf (which forwards raw events to another Splunk instance or syslog receiver). This article covers the settings that back the Splunk Taxonomy's DB Connect object (SOT-05.07.02).

Definition

Each [<name>] stanza in db_outputs.conf is one Database Output: a Splunk search (ad hoc SPL or a named saved search) that runs on a schedule, with its result rows written into a target table through a named Database Connection -- optionally as an upsert against a unique key rather than a plain insert.

Two different things share the word "output." A Database Output writes search results into a database table and is configured entirely inside the DB Connect app via this file. The platform's core outputs.conf (see the Forwarder Outputs Configuration reference) instead forwards raw event data over the network to another Splunk indexer or a syslog receiver -- an unrelated mechanism that happens to share the "output" name.

File locations

Configuration file: db_outputs.conf.

Scope	Path
App	`$SPLUNK_HOME/etc/apps/splunk_app_db_connect/{default,local}/db_outputs.conf`

Distinct from core outputs.conf forwarding.

Identification, scheduling & connection

Setting	Required?	Description
`description`	Optional	Free-text description of the output.
`scheduled`	Required	Whether this output runs on a schedule. An unscheduled output is used only in the context of the `dbxoutput` search command instead.
`interval`	Required	How often the output runs -- a number of seconds, or a cron expression. Only meaningful when `scheduled` is enabled.
`connection`	Required	Names the Database Connection (from `db_connections.conf`) this output writes through.

Search source

Setting	Required?	Description
`search`	Required	The Splunk search supplying rows to export. Either an inline SPL string, or -- when `is_saved_search` is enabled -- the name of a saved search.
`is_saved_search`	Optional	Boolean. When `true`, `search` is treated as the name of an existing saved search rather than an inline SPL string.
`query_earliest_time`	Optional	Earliest time bound applied to the search, using Splunk time-modifier syntax. Unset means no lower bound.
`query_latest_time`	Optional	Latest time bound applied to the search, using Splunk time-modifier syntax. Unset means no upper bound.
`search_timeout`	Optional	Max time, in seconds, the search job is allowed to run. If exceeded, the job is finalised early and only the partial results collected so far are exported. Default 0 (unlimited).

Correction to the source spec's is_saved_search description: Splunk's own db_outputs.conf.spec text under is_saved_search actually describes search_timeout ("specify the max time... a search job can run") -- an apparent copy/paste duplication in the source documentation. The description above is derived instead from the field's name and from how search's own spec entry describes the relationship ("If is_saved_search is enabled then this value specifies the saved search name").

Target table & write behaviour

Setting	Required?	Description
`table_name`	Required	Target table the output writes into.
`using_upsert`	Optional	Whether rows are upserted (inserted or updated) rather than always inserted.
`unique_key`	Required if upsert enabled	Column used to decide whether an incoming row should insert a new record or update an existing one.
`batch_size`	Optional	Number of rows per batch insert/update. 0 or a negative value disables batching -- every event is committed to the database individually. Default 0.
`customized_mappings`	Required	Maps search result fields onto database columns: `field1:column1:type1,field2:column2:type2,...`. A deprecated two-part form (`field1:column1,field2:column2,...`, no type) is still accepted for compatibility.

Timeouts & retry

Setting	Description
`query_timeout`	Timeout, in seconds, for the SQL insert/update statement(s) while exporting. Whether this applies to the whole batch or to each individual statement depends on the JDBC driver's own handling of `Statement#setQueryTimeout`. Default 30, 0 means unlimited.
`time_out`	Deprecated since DBX v3.1 -- use `search_timeout` and `query_timeout` instead.
`retry_attempts`	How many times a failed output write is retried. 0 means no retry is attempted. Default 2.
`retry_delay`	Seconds to wait between retry attempts. Default 300.

Legacy & deprecated settings

Unlike db_inputs.conf, where all four ui_query_* settings are deprecated, db_outputs.conf draws the line differently: the storage-only UI fields are deprecated, but the three ui_query_* fields remain live inputs the current UI editor reads from.

Deprecated -- ignored by the current UI

Setting	Description
`ui_mappings`	JSON field-to-column mappings, kept only for storage. Deprecated since DBX v3.1.0.
`ui_selected_fields`	JSON array of selected fields, kept only for storage. Deprecated since DBX v3.1.0.
`ui_saved_search_str`	String form of the current saved search. Deprecated since DBX v3.1.0.
`ui_query_sql`	Deprecated since DBX v3.1.0.
`ui_query_mode`	`simple` or `advanced` -- which query-building mode the UI used. Deprecated since DBX v3.1.0.

Still read by the UI editor

Setting	Description
`ui_query_catalog`	Table used to initialise the UI editor.
`ui_query_schema`	Schema used to initialise the UI editor.
`ui_query_table`	Table used to initialise the UI editor.

Example

[nightly_error_export]
description = Export daily error events to reporting DB
connection = prod_reporting_db
scheduled = true
interval = 0 2 * * *
search = index=app_logs level=error | table _time, host, error_code, message
table_name = daily_error_events
using_upsert = false
customized_mappings = _time:event_time:timestamp,host:host_name:varchar,error_code:error_code:int,message:message:varchar
batch_size = 500
query_timeout = 30
retry_attempts = 3
retry_delay = 300

This output runs nightly at 2am, pulls error events from the previous period, and inserts them in batches of 500 rows into a reporting database table, retrying up to 3 times on failure.

Validation

Confirm unique_key is set whenever using_upsert is enabled -- without it, upsert has no way to detect existing rows.
Check customized_mappings covers every field the search actually emits, with types matching the target column definitions -- unmapped fields are silently dropped, not exported.
Use query_earliest_time/query_latest_time to bound each scheduled run's search window -- an unbounded search re-scans the same historical data on every interval.
Set retry_attempts/retry_delay deliberately for outputs writing to a database with variable availability, rather than relying on the defaults.
Don't confuse this file's outputs with the platform's core outputs.conf forwarding mechanism -- they solve different problems and are configured completely independently.
Treat the deprecated time_out setting as already migrated -- new configurations should set search_timeout and query_timeout directly instead.

← Back to References

References / Splunk platform configuration

DB Connect Identities Configuration

identities.conf is the Splunk DB Connect app-specific credential-storage file: each stanza is a named identity (username/password, or a reference into an external secrets manager) that a Database Connection points at, kept encrypted and managed separately from Splunk's own core passwords.conf mechanism. This article covers the settings that back the credential-management side of the Splunk Taxonomy's DB Connect object (SOT-05.07.02).

Definition

Each [<name>] stanza in identities.conf is one Identity: a credential a Database Connection authenticates with. An identity's identity_type determines where the actual secret lives -- stored directly and encrypted in this file (normal), fetched at connection time from a CyberArk vault (cyberark), fetched from a HashiCorp Vault (hashicorp), or presented as a bearer token (token).

This file stores credentials for the DB Connect app specifically, separately from Splunk's own core passwords.conf credential store -- the two are not interchangeable and are managed through different UI surfaces.

File locations

Configuration file: identities.conf.

Scope	Path
App	`$SPLUNK_HOME/etc/apps/splunk_app_db_connect/{default,local}/identities.conf`

Kept separately from Splunk's core passwords.conf on purpose.

Core identity settings

Setting	Required?	Description
`username`	Required	Username for this connection identity.
`password`	Required	Encrypted password value for this identity.
`token`	Optional	Encrypted token value, used when `identity_type = token`.
`domain_name`	Optional	Windows domain the username belongs to.
`use_win_auth`	Optional	Whether Windows Authentication (domain-based auth) is used for this identity.
`identity_type`	Optional	`normal` (default), `cyberark`, `hashicorp`, or `token` -- selects where the real credential is sourced from.

CyberArk integration

Applies when identity_type = cyberark -- the password is fetched at connection time from a CyberArk Central Credential Provider rather than stored locally.

Setting	Description
`protocol_type`	`http` (default, unsecured) or `https` (secured, requires a certificate) connection to CyberArk.
`appId`	Application ID needed to retrieve credentials from CyberArk. Required for CyberArk identities.
`safe`	CyberArk Safe where the password is stored. Required for CyberArk identities.
`object`	Object name within the CyberArk Safe where the password is stored. Required for CyberArk identities.
`url`	Domain where the CyberArk Central Credential Provider is hosted. Required for CyberArk identities.
`port`	Port the CyberArk Central Credential Provider is available on. Required for CyberArk identities.
`certificate`	Encrypted certificate value for the CyberArk connection. Required when `protocol_type = https`.

HashiCorp Vault integration

Applies when identity_type = hashicorp -- the password is fetched at connection time from a HashiCorp Vault secrets engine.

Setting	Description
`hashicorp_secrets_engine`	`KEY_VALUE_V1`, `KEY_VALUE_V2`, or `DATABASES` -- which Vault secrets engine holds the credential. Required for HashiCorp identities.
`hashicorp_secrets_engine_path`	Path to the secrets engine. Required for HashiCorp identities.
`hashicorp_secret_path`	Path to the secret. Required when the engine is `KEY_VALUE_V1` or `KEY_VALUE_V2`.
`hashicorp_key_name`	Key name within the secret. Required when the engine is `KEY_VALUE_V1` or `KEY_VALUE_V2`.
`hashicorp_role_name`	Role name used to generate dynamic database credentials. Required when the engine is `DATABASES`.
`hashicorp_auth_method_path`	Path to the Vault auth method used to authenticate DB Connect itself to Vault. Required for HashiCorp identities.
`hashicorp_role_id`	Role ID for Vault AppRole authentication. Required for HashiCorp identities.
`hashicorp_secret_id`	Secret ID for Vault AppRole authentication. Required for HashiCorp identities.
`sync_frequency`	How often the credential is re-synced from CyberArk or HashiCorp Vault.

Example

[svc_reporting_normal]
username = svc_reporting
password = <encrypted>
identity_type = normal

[svc_reporting_vault]
username = svc_reporting_vault
identity_type = hashicorp
hashicorp_secrets_engine = DATABASES
hashicorp_secrets_engine_path = database
hashicorp_role_name = reporting-readonly
hashicorp_auth_method_path = approle
hashicorp_role_id = <role-id>
hashicorp_secret_id = <encrypted>
sync_frequency = 3600

One identity stores a locally-encrypted username/password directly; the other authenticates entirely through HashiCorp Vault's database secrets engine, re-syncing dynamic credentials hourly.

Validation

Confirm every setting marked "required when identity_type = cyberark" or "hashicorp" is actually present for identities using that type -- DB Connect won't resolve the credential without them.
Set protocol_type = https and provide certificate for any CyberArk identity handling production credentials -- http sends the retrieved secret unencrypted.
Match hashicorp_secrets_engine to the actual engine type configured in Vault -- the required companion settings differ between KEY_VALUE_V1/KEY_VALUE_V2 and DATABASES.
Don't confuse this file's identities with Splunk's core passwords.conf -- they're stored, encrypted, and managed independently.

← Back to References

References / Splunk platform configuration

DB Connect Settings Configuration

dbx_settings.conf holds Splunk DB Connect's instance-wide operational settings -- Java runtime location, per-component log levels, HEC delivery tuning, an IP/domain denylist, and KV Store synchronization -- for the Splunk Taxonomy's DB Connect object (SOT-05.07.02).

Definition

Unlike the other DB Connect configuration files, dbx_settings.conf holds instance-wide operational settings for the app itself rather than any particular connection, input, or output.

Not meant to be hand-edited. Per DB Connect's own documentation for this file: it must not be edited manually, because other files (server.vmopts, commands.conf) need to be updated in step to apply the changes. It is written by dbx_settings.py; use the DB Connect UI or its REST API to change these settings instead. The tables below are for understanding what each stanza controls, not as an editing guide.

File locations

Configuration file: dbx_settings.conf.

Scope	Path
App	`$SPLUNK_HOME/etc/apps/splunk_app_db_connect/{default,local}/dbx_settings.conf`

Generated by DB Connect itself -- not meant for direct hand-editing.

Java runtime -- `[java]`

Setting	Description
`javaHome`	Path to the Java home DB Connect resolves its `java` command from (appending `/bin/java` or `\bin\java.exe`). Falls back to the `JAVA_HOME` environment variable if unset, and finally to a bare `java` command resolved via `PATH` if that's unset too.

Log levels -- `[loglevel]`

Each setting accepts TRACE, DEBUG, INFO, WARN, or ERROR and controls one DB Connect component independently.

Setting	Controls logging for
`dbxquery`	The `dbxquery` search command.
`dbxoutput`	The `dbxoutput` search command.
`dbxlookup`	The `dbxlookup` search command.
`dbinput`	Database Inputs (`db_inputs.conf` stanzas).
`dboutput`	Database Outputs (`db_outputs.conf` stanzas).
`connector`	All interactions with the underlying databases.
`processor`	All interactions involving HEC.

HEC delivery -- `[hec]`

Setting	Description
`maxRetryWhenHecUnavailable`	How many times DB Connect retries (with exponential backoff) when HEC returns a 503 while forwarding data. Default 3.
`maxHecContentLength`	Max event size sent to HEC. Default 10MB.
`hecUris`	Comma-separated HEC URIs to forward to, e.g. `https://idx-host1:8088,https://idx-host2:8088`.
`hecToken`	Comma-separated HEC token(s), matched to `hecUris` by position. A single token is reused across all URIs if only one is given.
`hecFieldNameLowerCase`	Lower-cases HEC field names, kept for backward compatibility with DB Connect 1.x. Default `false`.

Security & synchronization

Stanza	Setting	Description
`[security]`	`denylist`	Comma-separated IP addresses or domain names denied when configuring HEC URIs or other endpoints.
`[synchronizer]`	`enabled`	Enables/disables synchronization between the KV Store and local configuration files. Default `true`.

Example

[java]
javaHome = /opt/java/openjdk-17

[loglevel]
connector = INFO
dbinput = INFO
dboutput = INFO
processor = WARN

[hec]
maxRetryWhenHecUnavailable = 3
maxHecContentLength = 10485760
hecUris = https://idx01.internal:8088,https://idx02.internal:8088
hecFieldNameLowerCase = false

[security]
denylist = untrusted.example.com

[synchronizer]
enabled = true

Shown for reference only, reflecting typical values -- as noted above, this file is not intended to be hand-edited; the equivalent state is set through the DB Connect UI or API.

Validation

Change these settings through the DB Connect UI or REST API, not by editing this file directly -- related files (server.vmopts, commands.conf) won't be kept in sync otherwise.
Set [loglevel] settings to DEBUG or TRACE only temporarily for troubleshooting -- they're verbose and meant to be reverted afterward.
Confirm every host in hecUris has a matching token in hecToken, or that a single shared token is intentional.
Review [security] denylist whenever new HEC URIs or endpoints are added, so it stays an accurate block list.

← Back to References

References / Splunk platform configuration

DB Connect Connection Types Configuration

db_connection_types.conf defines the catalogue of database engine "connection types" -- JDBC driver templates -- that an actual named Database Connection (in db_connections.conf) selects from. It's a template/catalogue file, not a list of live connections, for the Splunk Taxonomy's DB Connect object (SOT-05.07.02).

Definition

Each [<name>] stanza in db_connection_types.conf defines one database engine type DB Connect knows how to connect to -- its JDBC driver class, connection URL template, and default pooling behaviour. A Database Connection doesn't restate any of this; it just names a connection type and supplies the connection-specific values (host, database, credentials).

This is the least frequently edited of the DB Connect configuration files -- most deployments use the connection types Splunk ships out of the box, and only add or modify a stanza here to support a database engine that isn't already covered.

File locations

Configuration file: db_connection_types.conf.

Scope	Path
App	`$SPLUNK_HOME/etc/apps/splunk_app_db_connect/{default,local}/db_connection_types.conf`

App name is fixed -- DB Connect ships as splunk_app_db_connect, not a variable app folder.

Driver & JDBC settings

Setting	Required?	Description
`serviceClass`	Required	Splunk Java class providing JDBC support for this connection type.
`jdbcDriverClass`	Optional	Driver vendor's own JDBC class.
`supportedVersions`	Optional	Comma-separated list of supported JDBC driver versions (`majorVersion.minorVersion`). An installed driver is considered supported when its major version matches and minor version is greater than or equal.
`jdbcUrlFormat`	Required	JDBC connection URL template. Supports `host`, `port`, `database`, `informixserver` variables.
`jdbcUrlSSLFormat`	Optional	JDBC connection URL template used instead when `jdbcUseSSL` is enabled. Same supported variables as `jdbcUrlFormat`.
`jdbcUseSSL`	Optional	Whether this connection type uses SSL. Default `false`.
`testQuery`	Optional	Simple SQL statement used to validate a connection. Not needed for JDBC 4-compliant drivers.
`displayName`	Optional	Human-readable name shown to end users.
`database`	Required if referenced in a URL format	Default database/schema variable value for the URL templates.
`port`	Required if referenced in a URL format	Default network port variable value for the URL templates.
`database_engine`	Required	Names the underlying database engine -- distinguishes multiple connection types that target the same engine.

Connection pooling

Pooling is based on HikariCP and controlled by useConnectionPool (default true); the remaining settings only take effect when pooling is enabled.

Setting	Description
`useConnectionPool`	Whether connections for this type are pooled. Default `true`.
`maxConnLifetimeMillis`	Max lifetime, in milliseconds, of a pooled connection before retirement; an in-use connection is only retired once closed. 0 means infinite lifetime. Default 120000 (120s).
`maxWaitMillis`	Max time, in milliseconds, the pool waits for a connection to become available before throwing an exception. A reasonable range is 250-300000ms. Default 30000 (30s).
`maxTotalConn`	Max number of active connections the pool allocates simultaneously, or negative for no limit. Default 8.

Advanced & legacy settings

Setting	Description
`connection_properties`	Additional JDBC variables for this connection type, e.g. `{"useLegacyDatetimeCode": false}`.
`connection_properties_format`	Format for the connection properties, e.g. `{"privateKey":"ENCRYPTED"}`.
`ui_default_catalog`	Ignored since DB Connect 3.0.
`ui_default_schema`	Ignored since DB Connect 3.0.
`deprecated`	Marks the connection type deprecated: still supported for existing connections, but unavailable when creating a new one.
`deprecatedSince`	Version in which the connection type was deprecated.

Example

[postgresql]
database_engine = postgresql
serviceClass = com.splunk.dbx2.PostgresqlDBConnection
displayName = PostgreSQL
jdbcUrlFormat = jdbc:postgresql://<host>:<port>/<database>
jdbcUrlSSLFormat = jdbc:postgresql://<host>:<port>/<database>?ssl=true
jdbcUseSSL = false
port = 5432
useConnectionPool = true
maxTotalConn = 8
maxConnLifetimeMillis = 120000

A single connection type stanza supplies everything an actual named PostgreSQL Database Connection needs beyond the specific host, database name, and credentials.

Validation

Confirm database and port are set whenever jdbcUrlFormat/jdbcUrlSSLFormat actually reference those variables -- an unset referenced variable breaks the resulting JDBC URL.
Set jdbcUrlSSLFormat whenever jdbcUseSSL may be enabled on a connection of this type -- without it, enabling SSL has nothing to switch to.
Don't add new connections using a stanza marked deprecated = true -- it's kept only for connections that already exist.
Tune maxTotalConn/maxConnLifetimeMillis/maxWaitMillis against the target database's own connection limits, not just DB Connect's defaults.

← Back to References

References / Splunk platform configuration

Server Class Configuration

serverclass.conf defines the server classes a Deployment Server uses to decide which deployment clients receive which apps. It uses a three-level, general-to-specific stanza hierarchy with an inheritance and filter-override model that is easy to get subtly wrong -- most of this article is about that model, not just the individual settings. Backs the Splunk Taxonomy's Server Class object (SOT-08.04.03).

Definition & three-level hierarchy

serverclass.conf stanzas go from general to specific: [global] → [serverClass:<name>] → [serverClass:<name>:app:<appName>]. Each level plays a distinct role in matching a deployment client (an "agent") to the apps it should receive.

Level	Stanza	Role
1	`[global]`	Template only -- performs no agent matching itself. Provides defaults every `[serverClass:<name>]` stanza inherits, all overridable by child stanzas.
2	`[serverClass:<name>]`	Performs primary agent matching. If an agent doesn't match here, it receives no apps from this server class at all, regardless of any app-level filter.
3	`[serverClass:<name>:app:<appName>]`	Performs secondary filtering within the already-matched agent set. Can only further restrict which of the serverClass's matched agents receive this specific app -- it cannot add agents the serverClass level didn't already match.

Only [global] is supported as the top-level stanza name. Don't use [default] in serverclass.conf, even though other Splunk config files use that convention -- it produces an error and incorrect matching behaviour here.

File locations

Configuration file: serverclass.conf.

Scope	Path
Deployment Server	`$SPLUNK_HOME/etc/system/local/serverclass.conf`

Lives only on the Deployment Server -- it is never pushed to, or present on, a deployment client.

Global settings -- `[global]`

Setting	Description
`disabled`	Whether the deployment server is inactive (`true`) or operating normally (`false`). Default `false`.
`crossServerChecksum`	Whether multiple deployment servers behind a load balancer generate the same app checksum, so clients see consistent versions regardless of which one they hit. Default `false`.
`excludeFromUpdate`	Paths (prefixed `$app_root$/`) excluded from being touched during app updates. Overridable at serverClass and app level.
`repositoryLocation`	Path to the app repository on the deployment server. Default `$SPLUNK_HOME/etc/deployment-apps`. Overridable at serverClass level.
`syncMode`	`none` (this server's apps aren't shared) or `sharedDir` (multiple deployment servers share the same app directory and sync `serverclass.conf`). Default `none`.
`maxConcurrentDownloads`	Max clients that may simultaneously download a bundle; a client that can't due to this limit retries on its next phonehome. 0 means unlimited. Default 0.
`reloadCheckInterval`	Seconds between reload checks when `syncMode = sharedDir`. Default 60.
`targetRepositoryLocation`	Path on the deployment client where apps are installed. Defaults to `repositoryLocation` if unset; default `$SPLUNK_HOME/etc/apps`. Useful mainly for tiered deployment strategies. Overridable at serverClass level.
`tmpFolder`	Deployment server's working folder. Default `$SPLUNK_HOME/var/run/tmp`.
`endpoint`	URL template clients use to download content. Default `$deploymentServerUri$/services/streams/deployment?name=$tenantName$:$serverClassName$:$appName$`. Overridable at serverClass level.
`restartSplunkWeb` / `restartSplunkd`	Whether Splunk Web / splunkd restarts on the client after an app update. Both default `false`. Overridable at serverClass and app level.
`issueReload`	Whether the client reloads internal processors after an app update (app isn't active until this happens if `false`). Default `false`.
`restartIfNeeded`	Forwarders newer than 6.4 only: when `issueReload = true` and a reload fails, whether the client restarts automatically instead. Default `false`.
`stateOnClient`	`enabled`, `disabled`, or `noop` (mirror the deployment-server-side state). Default `enabled`. Overridable at serverClass and app level.
`precompressBundles`	Whether the deployment server pre-generates `.bundle.gz` alongside `.bundle`, trading disk for avoiding on-the-fly compression. Only beneficial without SSL compression, with HTTP compression enabled on both sides. Inherited down to serverClass level only, not app level. Default `true`.
`cronSchedule`	Cron expression controlling automatic reload of this serverclass. Available only at the serverClass level (not global or app). No default -- without it, reload is manual only.
`applicationMatchingCacheDisabled`	Whether matching runs fresh per request (`true`) instead of once per reload with cached results (`false`). Enabling the cache trades memory for response time. Default `false`.
`continueMatching`	Removed -- has no effect if still present in an existing file.

`[serverClass:<name>]` stanza

Defines one server class -- a named, filterable collection of apps. The name can contain letters, numbers, spaces, underscores, dashes, dots, tildes and @, and is case-sensitive.

Setting	Description
`machineTypesFilter`	Filters clients by host hardware/platform type (e.g. `linux-x86_64`, `windows-intel`), matched with boolean OR across the list and boolean AND against the whitelist/blacklist result. See the atomic-override section below for its level-dependent side effects.
`packageTypesFilter`	Deprecated, will be removed.
`updaterRunningFilter`	Deprecated, will be removed.

All other inheritable global settings -- endpoint, excludeFromUpdate, filterType, whitelist.<n>/blacklist.<n>, restartSplunkWeb, restartSplunkd, issueReload, restartIfNeeded, stateOnClient, repositoryLocation, targetRepositoryLocation, cronSchedule -- can be restated here to override the global default for this server class specifically.

`[serverClass:<name>:app:<appName>]` stanza

Maps one app (already present in repositoryLocation) onto a server class. appName is either the name of an app (matching its folder name, by convention) or * to add every app in the repository to this server class -- * cannot be mixed with named app stanzas within the same server class.

Setting	Description
`appFile`	Overrides the file/directory name to use when it differs from the app name. Supports directories, `.tar`, and `.tgz`. No default.

issueReload, restartIfNeeded, excludeFromUpdate, filterType, whitelist.<n>/blacklist.<n>, machineTypesFilter, and stateOnClient can all be restated here to override the serverClass-level (or global) value for this specific app.

Splunk Enterprise 9.4.3 changed the app-level filterType default from blacklist (default-allow) to whitelist (default-deny). A pre-9.4.3 app stanza that set only blacklist entries, with no explicit filterType or whitelist, now matches no agents on 9.4.3+ -- an empty implicit whitelist matches nothing. Migrating: add whitelist.0=* or filterType=blacklist to any such stanza.

Filtering & `filterType`

filterType (whitelist default, or blacklist) sets which of the two truth tables below governs matching, and is inherited down the hierarchy unless explicitly overridden.

filterType = whitelist (default-deny)
Blacklist match	Whitelist match	Agent matched?
No	No	No
Yes	No	No
No	Yes	Yes
Yes	Yes	No

Rule: agent must be whitelisted and not blacklisted. (in whitelist) AND (not in blacklist)

filterType = blacklist (default-allow)
Blacklist match	Whitelist match	Agent matched?
No	No	Yes
Yes	No	No
No	Yes	Yes
Yes	Yes	Yes

Rule: matches everyone unless blacklisted -- but whitelist always wins, acting as a "VIP pass" even against a blanket blacklist.0=*. (in whitelist) OR (not in blacklist)

The two tables only disagree on rows 1 (neither list matches) and 4 (both lists match) -- whitelist mode denies in both cases, blacklist mode allows in both.

Setting	Description
`whitelist.<n>` / `blacklist.<n>`	Matched in order against the client's `deploymentclient.conf` clientName, IP, reverse-DNS hostname, client-provided hostname, and (6.4+) instanceId GUID. PCRE regex, with `` meaning `.` and unescaped `.` meaning a literal dot; always case-insensitive. No default entries. Overridable at serverClass and app level.
`machineTypesFilter`	Used only when whitelist/blacklist alone can't decide a match. Matches host hardware/platform strings such as `linux-x86_64`, `windows-intel` -- discover a connected client's value via `splunk list deploy-clients` (the `utsname` field).
`filterType`	`whitelist` (default): clients don't match unless they match a whitelist entry and no blacklist entry. `blacklist`: clients match unless they match a blacklist entry and no whitelist entry. Set at `[global]` and inherited by server classes and apps unless overridden. From 9.4.3 the implicit app-level default changed from `blacklist` to `whitelist`, which changes matching where it isn't set explicitly.

Atomic override behaviour

This is the part of serverclass.conf most likely to cause a silent misconfiguration -- overriding one setting at a child level can implicitly clear another, inherited one.

whitelist/blacklist are an atomic pair. Overriding either at a child level (serverClass or app) without also restating the other clears the inherited one. Setting only whitelist.0=*.ops.example.com under a serverClass whose global stanza also had blacklist.0=maintenance.ops.example.com silently drops that blacklist entry -- the maintenance host is now included. Always restate both together when overriding either.

machineTypesFilter is level-dependent and stronger. At the app level, defining it clears both inherited whitelist and blacklist from the parent serverClass -- if you don't also explicitly define whitelist/blacklist at the app level, no agents match (an empty implicit whitelist matches nothing). At the serverClass level, defining it does not clear whitelist/blacklist inherited from global. At the global level, it has no effect at all -- it's only operational at serverClass or app scope.

Three ways to correctly combine machineTypesFilter with an app-level override, given a serverClass that already set whitelist.0=*:

Restate the whitelist explicitly alongside it: whitelist.0=* plus machineTypesFilter=linux-x86_64.
Switch to filterType=blacklist at the app level, which is default-allow and doesn't depend on an inherited whitelist.
Accept the narrower app-level match only if that's actually the intent -- an app stanza with only machineTypesFilter and no whitelist/blacklist restated deploys to nobody.

Allow/deny list import from a file

As an alternative to a series of whitelist.<n>/blacklist.<n> entries, a list can be imported from a plain-text or CSV file.

Setting	Description
`whitelist.from_pathname` / `blacklist.from_pathname`	Path (relative to `$SPLUNK_HOME`) to a plain-text file (one value per line) or, combined with the three settings below, a CSV file. At most one per stanza.
`whitelist.select_field` / `blacklist.select_field`	Which CSV column holds the values -- by header name (case-sensitive) or 1-based column number. Requires `from_pathname`.
`whitelist.where_field` / `blacklist.where_field`	Which CSV column to filter rows by, matched by name or number consistently with `select_field`. Requires `select_field` and `where_equals`.
`whitelist.where_equals` / `blacklist.where_equals`	Comma-separated PCRE values `where_field` must match (any one) for that row to be selected.

Can be combined with ordinary whitelist.<n>/blacklist.<n> entries in the same stanza; the two sources are simply additive.

Example

[global]
whitelist.0=*
restartSplunkd=false
restartSplunkWeb=true

[serverClass:AppsForOps]
whitelist.0=*.ops.yourcompany.com
[serverClass:AppsForOps:app:unix]
[serverClass:AppsForOps:app:SplunkLightForwarder]

[serverClass:AppsByMachineType]
whitelist.0=*
[serverClass:AppsByMachineType:app:SplunkDesktop]
# Correct: whitelist restated because machineTypesFilter is set here
whitelist.0=*
machineTypesFilter=windows-*

[serverClass:AppsByMachineType:app:unix]
whitelist.0=*
machineTypesFilter=linux-i686, linux-x86_64

Two server classes: one matches every *.ops.yourcompany.com host and deploys the unix and SplunkLightForwarder apps to all of them; the other matches every host (whitelist.0=*) but then narrows by hardware platform per app, correctly restating whitelist.0=* alongside each app-level machineTypesFilter so the atomic-override rule doesn't leave either app stanza matching nobody.

Validation

When overriding whitelist or blacklist at a serverClass or app level, restate both even if only one is changing -- otherwise the inherited other is silently cleared.
When adding machineTypesFilter at the app level, explicitly restate whitelist/blacklist in the same stanza, or switch to filterType=blacklist -- otherwise the app deploys to nobody.
On Splunk Enterprise 9.4.3+, audit existing app-level stanzas that rely on a bare blacklist with no explicit filterType/whitelist -- they now match zero agents under the new default-deny app-level default.
Confirm a server class's primary whitelist/blacklist is set at the [serverClass:<name>] level, not left solely to app-level filters -- an agent that doesn't match at the serverClass level receives nothing from it regardless of app-level configuration.
Don't use [default] as a stanza name in this file -- only [global] is recognised at the top level.
Set cronSchedule deliberately if automatic reload is required -- without it, reload is a manual/CLI/REST-triggered action only.

← Back to References

References / Splunk platform configuration

Transforms Configuration

transforms.conf is one of the most multi-purpose Splunk config files: named stanzas here back index-time and search-time field extraction, host/source/index routing, sensitive-data masking, lookup table definitions, and log-to-metrics conversion -- almost always invoked by a matching setting in props.conf. Backs the Splunk Taxonomy's Transforms Stanza, Field Transform, Lookup Definition, and Ingest-Time Eval objects.

Definition

A [<unique_transform_stanza_name>] stanza almost never does anything by itself -- it's referenced by name from props.conf (REPORT-<class>, TRANSFORMS-<class>, LOOKUP-<class>) or, for index-time work, matched automatically against every event. What the stanza settings mean depends heavily on whether the transform runs at index time (once, permanently, as data is written) or search time (every search, computed fresh, cheap to fix retroactively).

Stanza pattern	Purpose
`[<name>]`	An ordinary field-extraction/routing/masking/lookup transform, referenced from `props.conf` or matched at index time.
`[statsd-dims:<name>]`	Extracts dimensions from statsd dotted-name segments for metrics data.
`[metric-schema:<name>]`	Converts index-time-extracted log fields into a metrics data point (log-to-metrics).
`[accepted_keys]`	Extends the list of valid `SOURCE_KEY`/`DEST_KEY` values Splunk accepts.
`[_ruleset:global_settings]` `metrics.disabled` / `metrics.report_interval` / `metrics.rule_filter`	Controls per-transform-rule metrics collection (to `metrics.log`): whether it's off (default `true`), how often it reports (rounded to the `[metrics]` interval in `limits.conf`; default `30s`), and which rule names to collect for (comma-separated, wildcards allowed; default empty, meaning all rules).

[default] is not a stanza name here -- define global settings either outside any stanza at the top of the file, or don't rely on cross-stanza defaults at all; each setting not explicitly set in a stanza uses its own individual default.

File locations

Configuration file: transforms.conf.

Scope	Path
System	`$SPLUNK_HOME/etc/system/{default,local}/transforms.conf`
App	`$SPLUNK_HOME/etc/apps/<app_name>/{default,local}/transforms.conf`
User	`$SPLUNK_HOME/etc/users/<user_name>/<app_name>/local/transforms.conf`

Same index-time caveat as props.conf -- routing/masking stanzas need the system or app copy to matter on an indexer.

Core: `REGEX` & `FORMAT`

Valid for both index-time and search-time transforms, though their exact requirements differ between the two.

Setting	Description
`REGEX`	Required for every index-time transform, and for every search-time transform except an ASCII delimiter-based one using `DELIMS`. Must have at least one capturing group. Named capturing groups `_KEY_<string>`/`_VAL_<string>` can extract a field name and value pair directly without needing `FORMAT` at search time.
`FORMAT`	Required for index-time extractions (`$1`, `$2`... reference capture groups; `$0` is the DEST_KEY value before the REGEX ran). Optional at search time, where it defaults to `<field-name>::<field-value>` pairs; a variable field name (e.g. `$1::$2`) makes the regex re-apply repeatedly to extract all pairs in the event. Concatenated-field construction with `$n` tokens works only at index time.
`MATCH_LIMIT`	Set only in `transforms.conf` (for `EXTRACT`, set the equivalent in `props.conf` instead). Upper bound on PCRE's internal match-attempt calls, guarding against runaway non-matching patterns. Default 100000.
`DEPTH_LIMIT`	Same scope restriction as `MATCH_LIMIT`. Limits nested backtracking depth in PCRE. Default 1000.

Index-time-only settings

Setting	Description
`DEST_KEY`	Where the expanded `FORMAT` result is stored (see the KEYS table below). Required unless `WRITE_META = true`.
`WRITE_META`	Writes REGEX matches to the `_meta` DEST_KEY, becoming an index-time field extraction -- the recommended way to do this instead of setting `DEST_KEY = _meta` directly. Default `false`.
`DEFAULT_VALUE`	Value written to `DEST_KEY` if the REGEX fails to match. Default empty.
`SOURCE_KEY`	Valid at both index and search time. The KEY the REGEX is applied to; defaults to `_raw`. A value prefixed `field:`/`fields:` matches against one or more already-extracted field values instead of a KEY.
`LOOKAHEAD`	How many characters into the event to search. Default 4096 -- raise it if event lines routinely exceed that length.
`REPEAT_MATCH`	Re-runs REGEX repeatedly from where the last match ended, for an unknown number of matches per event. Ignored if `DEST_KEY = _raw`. Default `false`.
`CLONE_SOURCETYPE`	Despite the name, clones the entire event (near-exact duplicate) and assigns the copy this new sourcetype, leaving the original untouched -- used to retain both a sensitive and a masked/reduced copy under different retention or access policies. The new sourcetype must differ from the original or the setting is silently ignored. The clone is then reprocessed by every index-time transform matching its new host/source/sourcetype, including ones that shouldn't normally re-fire.
`INGEST_EVAL`	Declares an evaluator-based (not regex-based) index-time transform using `\|eval`-style syntax, e.g. `queue=if(length(_raw)>500,"nullQueue","indexQueue")`. Overrides every other index-time setting except `STOP_PROCESSING_IF`. `_time` here includes subsecond precision, unlike regex-based extraction. Prefix a variable with `pd:` to force direct-KEY treatment, `field:` to force `_meta`-field treatment, or `mv:` to read all values of a multivalued index-time field; use `:=` instead of `=` to replace rather than add a field (slower, use only when needed).
`STOP_PROCESSING_IF`	An evaluator expression; when true, stops further regexreplacement-processor handling of the event. Overrides every other index-time setting except `INGEST_EVAL`, and runs after it. Across multiple rules, evaluation order is: all TRANSFORMS alphabetically, then all RULESETs alphabetically, then rule order within a ruleset.

Search-time-only settings

Setting	Description
`DELIMS`	Use instead of REGEX for ASCII-only delimiter-based extraction (e.g. `DELIMS = "\|", "="` for pipe-separated key=value pairs). Not for values containing an unescaped embedded double quote or non-ASCII delimiters -- use REGEX there instead. One quoted set splits pairs; a second quoted set (optional) splits field from value.
`FIELDS`	Used with a single-set `DELIMS` (values only, no field names) to name the extracted values in order, e.g. `FIELDS = field1, field2, field3`.
`MV_ADD`	When a field already exists, `true` turns it multivalued and appends the new value; `false` discards the new value. Default `false`.
`CLEAN_KEYS`	Whether non-alphanumeric characters in extracted field names are replaced with underscores and leading underscores/digits stripped. Set `false` to preserve field names that need those characters. Default `true`.
`KEEP_EMPTY_VALS`	Whether field/value pairs with an empty value are kept (doesn't apply to Splunk's own autokv extraction, which always drops them). Default `false`.
`CAN_OPTIMIZE`	Whether Splunk may skip this extraction entirely when it can prove none of its fields will ever be needed for a search. Rarely needs to be `false`. Default `true`.
`CAN_OPTIMIZE_IE`	Skip this search-time extraction if the same field was already populated at index time. Set `true` only when the output field is confirmed already present from index-time extraction and `SOURCE_KEY` isn't `_raw`/empty. Default `false`.

KEYS & `[accepted_keys]`

Case-sensitive values valid for SOURCE_KEY/DEST_KEY in index-time transforms.

KEY	Meaning
`queue`	`indexQueue` (normal) or `nullQueue` (drop the event entirely).
`_raw`	The event's raw text.
`_meta`	Space-separated list of metadata for the event -- the destination `WRITE_META` writes to.
`_time`	Event timestamp, seconds since 1970-01-01 UTC.
`MetaData:Host`	Event host; value must be prefixed `host::`.
`_MetaData:Index`	The index the event is stored in -- what an index-routing transform writes to.
`MetaData:Source`	Event source; value must be prefixed `source::`.
`MetaData:Sourcetype`	Event sourcetype; value must be prefixed `sourcetype::`.
`_TCP_ROUTING`	Comma-separated `outputs.conf` `[tcpout]` group names; defaults to `defaultGroup`.
`_SYSLOG_ROUTING`	Comma-separated `outputs.conf` `[syslog]` stanza names; defaults to `defaultGroup`.

[accepted_keys] extends this list with environment/app-specific valid keys, in the form <name> = <key> -- not present by default, meaning any key not in the table above is flagged.

Lookup table settings

Lookup-table stanzas are used only at search time. Applies to CSV/KV Store/external/geospatial lookups referenced by Lookup Definition.

Setting	Description
`filename` / `collection`	CSV lookup file name (in a `lookups/` directory) or KV Store collection name (defined in `collections.conf`). Path components in `filename` are stripped -- only the base name is used.
`max_matches` / `min_matches` / `default_match`	Bounds on matches per input value (1-1000). Default 100 (non-temporal) or 1 (temporal). Below `min_matches`, `default_match` fills the gap.
`max_duplicates`	Memory-management cap on duplicate values retrieved before `max_matches`/`min_matches` filtering, for large file-based or replicated lookups. Change only under Splunk Support guidance. Default 0 (no effect).
`case_sensitive_match`	Case-sensitive (`true`, default) or case-insensitive field matching. For KV Store, case-insensitive matching only works if the stored data is already lower case.
`reverse_lookup_honor_case_sensitive_match`	Whether a reverse lookup's case sensitivity follows `case_sensitive_match` (default `true`) or is always case-insensitive. Doesn't apply to KV Store lookups.
`match_type`	Comma-separated `WILDCARD(<field>)`/`CIDR(<field>)` overrides for non-exact matching; unlisted fields default to `EXACT`.
`external_cmd` / `external_type`	Scripted lookup: a shell-parsed command whose first argument is a script in the app's `bin/`. `external_type` is `python` (default), `executable`, `kvstore`, `geo`, or `geo_hex`.
`fields_list` / `index_fields_list`	Fields the external command supports; for CSV lookups, which fields to actually index (improves performance by excluding the rest from search).
`python.required` / `python.version`	Comma-separated supported Python versions (e.g. `3.9`, `3.13`); Splunk picks the highest available. Supersedes the deprecated `python.version`.
`time_field` / `time_format` / `max_offset_secs` / `min_offset_secs`	Makes a lookup temporal: the timestamp column, its `strptime` format (default `%s.%Q`), and the allowed time window (in seconds) between an event and a matching lookup entry.
`batch_index_query`	Whether large file-based lookup queries are grouped for performance. Global default (in `limits.conf`) is `true`.
`allow_caching` / `cache_size`	Whether lookup-script output is cached, and how many input values' outputs to cache. Default `true` / 10000.
`max_ext_batch`	Max external batch size (1-1000), KV Store lookups only. Default 300.
`filter`	Boolean-expression filter applied before returning lookup data -- at retrieval time for KV Store, in memory for CSV.
`feature_id_element`	For a `.kmz` geospatial lookup, the XML path from placemark down to its name. Default `/Placemark/name`.
`check_permission`	CSV lookups only. Whether write permission is verified before `outputlookup` can modify the file -- only takes effect when `outputlookup_check_permission = true` in `limits.conf`. Default `false`.
`replicate`	CSV lookups only. `true` replicates to indexers and search heads; `false` replicates only to search head cluster members. Requires `replicationAllowlist` in `distsearch.conf` to actually take effect. Default `true`.

Statsd dimensions & log-to-metrics

[statsd-dims:<name>] extracts dimensions from statsd metric-name segments via REGEX with named capturing groups, controlled by REMOVE_DIMS_FROM_METRIC_NAME (default true -- matched segments are excluded from the remaining metric name).

[metric-schema:<name>] converts index-time-extracted log fields into metrics data points. Requires one of two measures settings:

Setting	Description
`METRIC-SCHEMA-MEASURES-<prefix>`	Fields to treat as measures when the event's `metric_name` extraction matches `<prefix>`. `_ALLNUMS_` treats every numeric field as a measure; `_NUMS_EXCEPT_ <field>...` treats all but the named fields; otherwise an explicit (wildcard-capable) field list. Remaining fields become dimensions.
`METRIC-SCHEMA-MEASURES` (no prefix)	Lower precedence than the prefixed form; active only when no prefix match is found.
`METRIC-SCHEMA-BLACKLIST-DIMS[-<prefix>]`	Dimensions to omit from generated metrics, wildcard-capable.
`METRIC-SCHEMA-WHITELIST-DIMS[-<prefix>]`	Dimensions to include; an empty list behaves as "all fields." When both allow and deny lists are set, deny always wins for a field present in both.
`[statsd-dims:<name>] REMOVE_DIMS_FROM_METRIC_NAME`	Whether metric-name segments matched by the stanza's `REGEX` are removed from the remaining metric name. Default `true`.

Example

# Indexed field extraction
[netscreen-error]
REGEX = device_id=\[w+\](?<err_code>[^:]+)
FORMAT = err_code::$1
WRITE_META = true

# Mask sensitive data, keep a full copy under a different sourcetype
[session-anonymizer]
REGEX = (?m)^(.*)SessionId=\w+(\w{4}[&"].*)$
FORMAT = $1SessionId=########$2
DEST_KEY = _raw

# Index-time eval: route oversized events to nullQueue
[discard-long-lines]
INGEST_EVAL = queue=if(length(_raw) > 500, "nullQueue", "indexQueue")

# Delimiter-based search-time extraction
[pipe_eq]
DELIMS = "|", "="

# Temporal static lookup table
[staticwtime]
filename = mytable.csv
time_field = timestamp
time_format = %d/%m/%y %H:%M:%S

Five independent stanzas: an index-time field write, a raw-text masking transform, a modern eval-based routing rule, a delimiter-based search-time extraction, and a time-bound CSV lookup -- each referenced by name from the appropriate props.conf setting (or, for the lookup, from a Lookup Definition/Automatic Lookup) rather than doing anything on their own.

Validation

Confirm FORMAT is set for every index-time transform -- it's required there, unlike at search time where name-capturing groups can substitute for it.
Prefer WRITE_META = true over DEST_KEY = _meta directly, and remember $0 (not a captured group) if you do set DEST_KEY = _meta explicitly.
Verify a CLONE_SOURCETYPE target genuinely differs from the source's original sourcetype -- an identical value causes the setting to be silently ignored at runtime.
Check that a cloned event's new sourcetype doesn't unintentionally re-trigger host/source-matching transforms a second time.
Remember INGEST_EVAL and STOP_PROCESSING_IF override essentially every other index-time setting in the same stanza -- don't mix them with REGEX/DEST_KEY expecting both to apply.
For lookups, confirm min_matches/default_match are set deliberately if a guaranteed one-to-one output is required -- the default is to output nothing on no match.
Set CLEAN_KEYS = false only when field names genuinely need non-alphanumeric characters or a leading underscore/digit -- it disables a safety default.

← Back to References

References / Splunk platform configuration

Tags Configuration

tags.conf is one of the simplest Splunk config files -- a two-level structure with a single setting form -- letting you attach one or more named tags to a specific field=value pair, searchable with tag=<name> regardless of which differently-named field/value combinations share it. Backs the Splunk Taxonomy's Tag object (SOT-02.04.02).

Definition

Each stanza names exactly one field/value pair; every setting line inside it enables or disables one tag against that pair. There's no tags.conf shipped in $SPLUNK_HOME/etc/system/default/ -- tags exist only where an admin or app has explicitly defined them in etc/system/local/ or an app's local/ directory.

A restart is required to enable changes to this file -- unlike many other knowledge-object conf files, there's no equivalent to | extract reload=t for tags.

File locations

Configuration file: tags.conf.

Scope	Path
System	`$SPLUNK_HOME/etc/system/{default,local}/tags.conf`
App	`$SPLUNK_HOME/etc/apps/<app_name>/{default,local}/tags.conf`
User	`$SPLUNK_HOME/etc/users/<user_name>/<app_name>/local/tags.conf`

Stanza & setting

Line	Description
`[<fieldname>=<value>]`	Names the single field/value pair the stanza's tags apply to, e.g. `[host=localhost]`. One field/value pair per stanza -- to tag a different pair, add another stanza. URL-encoding the value is recommended if it may contain `\n`, `=`, or `[]`, which would otherwise break config-file parsing.
`<tag> = enabled\|disabled`	Enables or disables one named tag for this stanza's field/value pair. A stanza can hold any number of these lines (multiple tags on the same field/value pair), but each line names exactly one tag -- tags cannot be listed comma-separated on a single line. Don't quote the tag value: `foo=enabled`, not `"foo"=enabled`.

CIM tags

The Splunk Common Information Model (CIM) extends tags.conf with the tag names its data models look for. A tag is applied in tags.conf as <tag> = enabled under a [<field>=<value>] stanza -- usually an event type -- and each CIM data model selects events by its tags. The list below is tags.conf.cim.spec, grouped by data model as the spec groups it; every tag is enabled or disabled. Some constraint tags, such as change, network and endpoint, are used by several models and are listed once at the end.

Config

CIM tag names by data model

Every stanza and setting in tags.conf.cim.spec from Splunk's VS Code extension (spec version 9.0): 81 settings in 25 sections. Descriptions use the spec's own wording -- the first line shows here and More opens the rest. The Default column is filled only where the spec gives a Default: line.

Alerts data model

Setting	Description	Default
`alert`	`<enabled\|disabled>`Enable or disable CIM tagging for the Alerts data model. More Events in the Alerts data model are vendor agnostic, which means that they are not specific to a vendor. The events in the Alerts data model are higher level event constructs or metadata events that carry new knowledge based on multiple basic events. However, an event that pertains to multiple lower basic level is not always mapped to the Alerts data model.

Authentication data model

Setting	Description	Default
`authentication`	`<enabled\|disabled>`Enable or disable CIM tagging for the Authentication data model. More The fields and tags in the Authentication data model describe login activities from any data source.
`cleartext`	`<enabled\|disabled>`Enable or disable CIM tagging for the Insecure_Authentication constraint in the Authentication data model.
`insecure`	`<enabled\|disabled>`Enable or disable CIM tagging for the Insecure_Authentication constraint in the Authentication data model.
`privileged`	`<enabled\|disabled>`Enable or disable CIM tagging for the Privileged_Authentication constraint in the Authentication data model.

Certificates data model

Setting	Description	Default
`certificate`	`<enabled\|disabled>`Enable or disable CIM tagging for the Certificates data model. More The fields and tags in the Certificates data model describe key and certificate management events from a variety of secure servers and IAM systems.
`ssl`	`<enabled\|disabled>`Enable or disable CIM tagging for the SSL constraint in the Certificates data model.
`tls`	`<enabled\|disabled>`Enable or disable CIM tagging for the SSL constraint in the Certificates data model.

Change data model

change is reused in other constraints (see below)

Setting	Description	Default
`audit`	`<enabled\|disabled>`Enable or disable CIM tagging for the Auditing_Changes constraint in the Change data model.
`account`	`<enabled\|disabled>`Enable or disable CIM tagging for the Account_Management constraint in the Change data model.

Data Access data model

Setting	Description	Default
`data`	`<enabled\|disabled>`Enable or disable CIM tagging for the Data Access data model. More The Data Access data model is for monitoring shared data access user activity. It helps you detect a user's unauthorized data access, misuse, exfiltration, and more. It applies to events about users accessing data on servers that are shared by many other users, such as: The "file abc" on the "server xyz" was accessed (read, created, modified, shared, and so on) by a "user Bob".
`access`	`<enabled\|disabled>`Enable or disable CIM tagging for the Data Access data model. More The Data Access data model is for monitoring shared data access user activity. It helps you detect a user's unauthorized data access, misuse, exfiltration, and more. It applies to events about users accessing data on servers that are shared by many other users, such as: The "file abc" on the "server xyz" was accessed (read, created, modified, shared, and so on) by a "user Bob".

Databases data model

Setting	Description	Default
`database`	`<enabled\|disabled>`Enable or disable CIM tagging for the Databases data model. More The fields and tags in the Databases data model describe events that pertain to structured and semi-structured data storage.
`lock`	`<enabled\|disabled>`Enable or disable CIM tagging for the Lock_Info constraint in the Databases data model.
`query`	`<enabled\|disabled>`Enable or disable CIM tagging for the Database_Query constraint in the Databases data model.
`tablespace`	`<enabled\|disabled>`Enable or disable CIM tagging for the Tablespace constraint in the Databases data model.

Data Loss Prevention data model

Setting	Description	Default
`dlp`	`<enabled\|disabled>`Enable or disable CIM tagging for the Data Loss Prevention data model. More The fields in the Data Loss Prevention (DLP) data model describe events gathered from DLP tools used to identify, monitor and protect data.

Email data model

Setting	Description	Default
`email`	`<enabled\|disabled>`Enable or disable CIM tagging for the Email data model. More The fields and tags in the Email data model describe email traffic, whether server:server or client:server.
`delivery`	`<enabled\|disabled>`Enable or disable CIM tagging for the Delivery constraint in the Email data model.
`content`	`<enabled\|disabled>`Enable or disable CIM tagging for the Content constraint in the Email data model.
`filter`	`<enabled\|disabled>`Enable or disable CIM tagging for the Filtering constraint in the Email data model.

Endpoint data model

Setting	Description	Default
`listening`	`<enabled\|disabled>`Enable or disable CIM tagging for the Ports constraint in the Endpoint data model.
`port`	`<enabled\|disabled>`Enable or disable CIM tagging for the Ports constraint in the Endpoint data model.
`process`	`<enabled\|disabled>`Enable or disable CIM tagging for the Processes constraint in the Endpoint data model.
`service`	`<enabled\|disabled>`Enable or disable CIM tagging for the Services constraint in the Endpoint data model.
`filesystem`	`<enabled\|disabled>`Enable or disable CIM tagging for the Filesystem constraint in the Endpoint data model.
`registry`	`<enabled\|disabled>`Enable or disable CIM tagging for the Registry constraint in the Endpoint data model.

Event Signatures data model

Setting	Description	Default
`track_event_signatures`	`<enabled\|disabled>`Enable or disable CIM tagging for the Event Signatures data model. More Event Signatures is a standard location to store Windows EventID. This data model is searchable as DataModel.DataSet. It is not accelerated by default, but the appropriate acceleration settings have been defined.

Interprocess Messaging data model

Setting	Description	Default
`messaging`	`<enabled\|disabled>`Enable or disable CIM tagging for the Interprocess Messaging data model. More The fields in the Interprocess Messaging data model describe transactional requests in programmatic interfaces. This enables you to establish the data requirements for a domain and create apps that support each other.

Intrusion Detection data model

Setting	Description	Default
`ids`	`<enabled\|disabled>`Enable or disable CIM tagging for the Intrusion Detection data model. More The fields in the Intrusion Detection data model describe attack detection events gathered by network monitoring devices and apps.

Inventory data model

Setting	Description	Default
`inventory`	`<enabled\|disabled>`Enable or disable CIM tagging for the Inventory data model. More The fields and tags in the Inventory data model describe common computer infrastructure components from any data source, along with network infrastructure inventory and topology.
`system`	`<enabled\|disabled>`Enable or disable CIM tagging for the OS constraint in the Inventory data model.
`version`	`<enabled\|disabled>`Enable or disable CIM tagging for the OS constraint in the Inventory data model.
`user`	`<enabled\|disabled>`Enable or disable CIM tagging for the User constraint in the Inventory data model.
`password`	`* = <enabled\|disabled>`Enable or disable CIM tagging for the Cleartext_Passwords constraint in the Inventory data model.
`virtual`	`<enabled\|disabled>`Enable or disable CIM tagging for the Virtual_OS constraint in the Inventory data model.
`snapshot`	`<enabled\|disabled>`Enable or disable CIM tagging for the Snapshot constraint in the Inventory data model.
`tools`	`<enabled\|disabled>`Enable or disable CIM tagging for the Tools constraint in the Inventory data model.

JVM data model

Setting	Description	Default
`jvm`	`<enabled\|disabled>`Enable or disable CIM tagging for the JVM data model. More The fields in the JVM data model describe generic Java server platforms.
`threading`	`<enabled\|disabled>`Enable or disable CIM tagging for the Threading constraint in the JVM data model.
`runtime`	`<enabled\|disabled>`Enable or disable CIM tagging for the Runtime constraint in the JVM data model.
`compilation`	`<enabled\|disabled>`Enable or disable CIM tagging for the Compilation constraint in the JVM data model.
`classloading`	`<enabled\|disabled>`Enable or disable CIM tagging for the Classloading constraint in the JVM data model.

Malware data model

Setting	Description	Default
`malware`	`<enabled\|disabled>`Enable or disable CIM tagging for the Malware data model. More The fields in the Malware data model describe malware detection and endpoint protection management activity. The Malware data model is often used for endpoint antivirus product related events.
`operations`	`<enabled\|disabled>`Enable or disable CIM tagging for the Malware_Operations constraint in the Malware data model.

DNS data model

Setting	Description	Default
`dns`	`<enabled\|disabled>`Enable or disable CIM tagging for the DNS data model. More The fields and tags in the Network Resolution (DNS) data model describe DNS traffic, both server:server and client:server.
`resolution`	`<enabled\|disabled>`Enable or disable CIM tagging for the DNS data model.

Network Sessions data model

Setting	Description	Default
`start`	`<enabled\|disabled>`Enable or disable CIM tagging for the Session_Start constraint in the Network Sessions data model.
`end`	`<enabled\|disabled>`Enable or disable CIM tagging for the Session_End constraint in the Network Sessions data model.
`dhcp`	`<enabled\|disabled>`Enable or disable CIM tagging for the DHCP constraint in the Network Sessions data model.
`vpn`	`<enabled\|disabled>`Enable or disable CIM tagging for the VPN constraint in the Network Sessions data model.

Network Traffic data model

Setting	Description	Default
`communicate`	`<enabled\|disabled>`Enable or disable CIM tagging for the Network Traffic data model. More The fields and tags in the Network Traffic data model describe flows of data across network infrastructure components.

Performance data model

Setting	Description	Default
`performance`	`<enabled\|disabled>`Enable or disable CIM tagging for the Performance data model. More The fields in the Performance data model describe performance tracking data.
`facilities`	`<enabled\|disabled>`Enable or disable CIM tagging for the Facilities constraint in the Performance data model.
`uptime`	`<enabled\|disabled>`Enable or disable CIM tagging for the Uptime constraint in the Performance data model.
`time`	`<enabled\|disabled>`Enable or disable CIM tagging for the Timesync constraint in the Performance data model.
`synchronize`	`<enabled\|disabled>`Enable or disable CIM tagging for the Timesync constraint in the Performance data model.

Splunk Audit Logs data model

Setting	Description	Default
`modaction`	`<enabled\|disabled>`Enable or disable CIM tagging for the Modular Alerts Actions dataset in the Splunk Audit Logs data model. More The fields in the Splunk Audit Logs data model describe audit information for systems producing event logs.
`invocation`	`<enabled\|disabled>`Enable or disable CIM tagging for the Modular Action Invocations dataset in the Splunk Audit Logs data model. More The fields in the Splunk Audit Logs data model describe audit information for systems producing event logs.

Ticket Management data model

Setting	Description	Default
`ticketing`	`<enabled\|disabled>`Enable or disable CIM tagging for the Ticket Management data model. More The fields and tags in the Ticket Management data model describe service requests and their states in ITIL-influenced service desks, bug trackers, simple ticket systems, or GRC systems.
`problem`	`<enabled\|disabled>`Enable or disable CIM tagging for the Problem constraint in the Ticket Management data model.

Updates data model

Setting	Description	Default
`update`	`<enabled\|disabled>`Enable or disable CIM tagging for the Updates data model. More The fields in the Updates data model describe patch management events from individual systems or central management tools.
`status`	`<enabled\|disabled>`Enable or disable CIM tagging for the Status constraint in the Updates data model.
`error`	`<enabled\|disabled>`Enable or disable CIM tagging for the Error constraint in the Updates data model.

Vulnerabilities data model

Setting	Description	Default
`vulnerability`	`<enabled\|disabled>`Enable or disable CIM tagging for the Vulnerabilities data model. More The fields in the Vulnerabilities data model describe vulnerability detection data.

Web data model

Setting	Description	Default
`web`	`<enabled\|disabled>`Enable or disable CIM tagging for the Web data model. More The fields in the Web data model describe web server and/or proxy server data in a security or operational context.
`proxy`	`<enabled\|disabled>`Enable or disable CIM tagging for the Proxy constraint in the Web data model.

Constraint tags used in multiple models

Setting	Description	Default
`attack`	`<enabled\|disabled>`Enable or disable CIM tagging for the Attack constraint in a data model.
`change`	`<enabled\|disabled>`Enable or disable CIM tagging for the Change constraint in a data model.
`cpu`	`<enabled\|disabled>`Enable or disable CIM tagging for the CPU constraint in a data model.
`default`	`<enabled\|disabled>`Enable or disable CIM tagging for the default constraint in a data model.
`incident`	`<enabled\|disabled>`Enable or disable CIM tagging for the Incident constraint in a data model.
`instance`	`<enabled\|disabled>`Enable or disable CIM tagging for the Instance constraint in a data model.
`network`	`<enabled\|disabled>`Enable or disable CIM tagging for the Network constraint in a data model.
`endpoint`	`<enabled\|disabled>`Enable or disable CIM tagging for the Endpoint constraint in a data model.
`memory`	`<enabled\|disabled>`Enable or disable CIM tagging for the Memory constraint in a data model.
`os`	`<enabled\|disabled>`Enable or disable CIM tagging for the OS constraint in a data model.
`stats`	`<enabled\|disabled>`Enable or disable CIM tagging for the Stats constraint in a data model.
`report`	`<enabled\|disabled>`Enable or disable CIM tagging for the Report constraint in a data model.
`session`	`<enabled\|disabled>`Enable or disable CIM tagging for the Session constraint in a data model.
`storage`	`<enabled\|disabled>`Enable or disable CIM tagging for the Storage constraint in a data model.

Example

[host=hostswitch]
pci = enabled
cardholder-dest = enabled

[host=emailbox]
email = enabled
building1 = enabled

[host=devmachine]
development = enabled
building1 = enabled

[src_ip=192.168.1.1]
firewall = enabled

[seekPtr=1cb58000]
EOF = enabled
NOT_EOF = disabled

Three hosts each carry two tags (note building1 applied independently to both emailbox and devmachine -- tags aren't unique to one field/value pair), one IP address carries a single tag, and one stanza demonstrates explicitly disabling a tag (NOT_EOF) rather than only ever enabling them.

Validation

Confirm each stanza names exactly one field/value pair -- a second pair needs its own stanza, not a combined key.
URL-encode field values containing \n, =, or [] to avoid parse errors.
Don't quote tag names -- "foo"=enabled is invalid; use foo=enabled.
Remember a restart is required after editing this file -- there's no live-reload search command for tags.
Use <tag> = disabled deliberately to override an inherited/default-config tag for a specific field/value pair, rather than just omitting the line and assuming that disables it.

← Back to References

References / Splunk platform configuration

Sourcetype Classification Models

sourcetypes.conf is a machine-generated file storing the statistical document models Splunk's file classifier uses to automatically recognize and sourcetype files it hasn't seen before, based on structural similarity to files it has already learned from. Backs the Splunk Taxonomy's Sourcetype Classification Model object (SOT-02.01.03).

Definition

Each stanza is one learning example: a per-file "document model" the classifier built when a sourcetype was assigned (manually or automatically) to a specific source. The stanza name itself is machine-generated, typically embedding the original source path, a timestamp, and a hash. Most of a stanza's attributes are opaque statistical feature weights that only the classifier itself should ever write.

Don't hand-edit this file in general. Splunk's own guidance is explicit: almost every attribute here is machine-generated, and only two are meant to be changed by a person -- covered below. Everything else exists purely to support the file classifier's pattern matching.

File locations

Configuration file: sourcetypes.conf.

Scope	Path
Learned app	`$SPLUNK_HOME/etc/apps/learned/local/sourcetypes.conf`
Any app	`$SPLUNK_HOME/etc/apps/<app_name>/{default,local}/sourcetypes.conf`

Conventionally written to the bundled "learned" app; only the _sourcetype and _source attributes inside it are safe to hand-edit anywhere else.

Editable attributes

Setting	Description
`_sourcetype`	The sourcetype this model assigns. Changing it changes what sourcetype future structurally-similar files receive -- effectively renaming/retargeting the model without needing to retrain it.
`_source`	The source (filename) the model was originally learned from.

Every other attribute in a stanza -- the numeric feature-weight settings like L----------- or L-t<_EQ> in the example below -- is a machine-generated statistical parameter of the classification model and isn't documented as an individually meaningful, hand-settable value.

Example

[/Users/bob/logs/bnf.x5_Thu_Dec_13_15:59:06_2007_171714722]
_source = /Users/bob/logs/bnf.x5
_sourcetype = cadcamlog
L----------- = 0.096899
L-t<_EQ> = 0.016473

A machine-generated model learned from /Users/bob/logs/bnf.x5, teaching the classifier to recognize structurally similar files as sourcetype cadcamlog. The stanza name embeds the source path, learning timestamp, and a hash; the two L... lines are opaque statistical weights the classifier itself produced and consumes.

Validation

Only edit _sourcetype or _source in an existing stanza -- leave every other attribute exactly as the classifier generated it.
Don't hand-write new stanzas expecting them to behave like a genuine trained model -- the feature-weight attributes aren't a documented, human-authorable format.
Remember a restart is required to apply any change to this file.
Don't confuse this file with the technical sourcetype definition itself (props.conf) -- this file only affects automatic classification of new, unseen sources, not how an already-assigned sourcetype's events are parsed.

← Back to References

References / Splunk platform configuration

Props Configuration

props.conf is the central per-sourcetype/source/host processing-properties file: line breaking, character encoding, timestamp extraction, structured-data header parsing, index-time and search-time field extraction, data masking, segmentation, binary/checksum handling, and sourcetype classification learning all live here. Almost every other data-onboarding conf file (transforms.conf, segmenters.conf, datetime.xml) is invoked from a props.conf stanza. Backs the Splunk Taxonomy's Props Stanza, Source Type, Field Alias, Calculated Field, Automatic Lookup, Indexed Extractions, and SEDCMD objects.

Definition & `[<spec>]` matching

A [<spec>] stanza can key on a <sourcetype>, host::<host>, source::<source>, rule::<rulename>, or delayedrule::<rulename> (the last two are source type classification rules, considered only as a last resort before a genuinely new sourcetype is generated).

Rule	Description
Type precedence / `priority`	`[source::<source>]` beats `[host::<host>]`, which beats `[<sourcetype>]` -- for any setting specified in more than one matching stanza type. The `priority` key never changes this ordering.
Pattern syntax	`...` matches any number of any characters (recurses through directories); `*` matches anything but the path separator; `\|` is "or"; `()` scopes it; `\\` is a literal backslash. Windows paths in `[source::...]` need their backslashes escaped, e.g. `[source::c:\\path_to\\file.txt]`.
Match scope	Match expressions must match the entire name, not a substring -- full PCRE with `...`/`*`/`.` translated as above.
Collisions between literal-vs-pattern stanzas	Default priority is 0 for pattern-matching stanzas and 100 for literal-matching stanzas -- literal wins by default. Setting `priority` above 100 flips that, letting a pattern-matched stanza override a literal one.
Collisions between same-type pattern stanzas	When two `[source::...]` patterns both match and both set the same setting, Splunk resolves by ASCII order of the pattern text unless `priority` is set explicitly (higher wins).
Case sensitivity	`[source::...]` and `[<sourcetype>]` match case-sensitively by default; `[host::...]` matches case-insensitively by default (convenient since DNS names are case-insensitive). Force case-sensitive host matching with the `(?-i)` inline flag, e.g. `[host::(?-i)bar]`.

[<spec>] stanzas are layered, not exclusive. If a source matches multiple non-colliding stanzas, Splunk applies all of the distinct settings from each. Only an actual setting collision invokes the precedence rules above.

File locations

Configuration file: props.conf.

Scope	Path
System	`$SPLUNK_HOME/etc/system/{default,local}/props.conf`
App	`$SPLUNK_HOME/etc/apps/<app_name>/{default,local}/props.conf`
User	`$SPLUNK_HOME/etc/users/<user_name>/<app_name>/local/props.conf`

Index-time stanzas (TRANSFORMS, line breaking) only take effect from system/app copies on an indexer -- the user-level copy only reaches search-time settings.

Encoding & line breaking

Setting	Description
`CHARSET`	Input-time character encoding, or `AUTO` to auto-detect. Valid only for `[<sourcetype>]`/`[source::...]`, not `[host::...]`. Default `AUTO` (Windows) or `UTF-8` (otherwise).
`TRUNCATE`	Max line length in bytes before truncation; 0 disables truncation. Default 10000.
`LINE_BREAKER`	Regex (must have a capturing group) marking where the raw stream splits into initial events -- much faster than reassembling with `SHOULD_LINEMERGE`. Set `SHOULD_LINEMERGE = false` alongside it to prevent re-merging. Branched (`\|`-separated) patterns follow special first-matched-capturing-group rules -- prefer a single leftmost group that always matches. Default `([\r\n]+)`.
`LINE_BREAKER_LOOKBEHIND`	Bytes before the end of a raw chunk where `LINE_BREAKER` is applied against leftover+new data. Raise for large/multi-line events. Default 100.
`SHOULD_LINEMERGE`	Whether multiple lines are combined into one multi-line event using the `BREAK_ONLY_`/`MUST_` settings below. Default `true`.
`BREAK_ONLY_BEFORE_DATE` / `BREAK_ONLY_BEFORE`	New event only starts at a line containing a date (default `true`), or matching a given regex.
`MUST_BREAK_AFTER` / `MUST_NOT_BREAK_AFTER` / `MUST_NOT_BREAK_BEFORE`	Force or suppress a break relative to a line matching the given regex.
`MAX_EVENTS`	Max input lines per event before a forced break. Default 256.
`ROUTE_EVENTS_OLDER_THAN`	Routes events older than the given duration to `nullQueue` after timestamp extraction, via the AggregatorProcessor.
`EVENT_BREAKER_ENABLE` / `EVENT_BREAKER`	Universal Forwarder only. Splits data on event boundaries (via a light-weight `ChunkedLBProcessor`) so events distribute more evenly across indexers, instead of standard byte-based load balancing. Default disabled / `([\r\n]+)`.
`LB_CHUNK_BREAKER`	Deprecated -- use `EVENT_BREAKER` instead. Only relevant with an `[httpout]` stanza in `outputs.conf`.
`LB_CHUNK_BREAKER_TRUNCATE`	Maximum bytes per chunk a forwarder sends over HTTP (rounded down to avoid splitting a multibyte character). Only with an `[httpout]` stanza in `outputs.conf`. Default `2000000`.
`MAX_EXPECTED_EVENT_LINES`	Average input lines per event, used to size memory allocation. Default `7`; don't change it without Splunk Support.

Timestamp extraction

Setting	Description
`DATETIME_CONFIG`	Path to the `datetime.xml`-style file configuring the timestamp extractor, or `CURRENT` (use aggregator-processor time) or `NONE` (use input-layer time). Either non-file value disables per-text timestamp detection, so line-merging must be controlled via `SHOULD_LINEMERGE`/`BREAK_ONLY_*` instead. Default `/etc/datetime.xml`.
`TIME_PREFIX`	Regex whose first match's end marks where timestamp scanning begins; if not found, no timestamp is extracted.
`MAX_TIMESTAMP_LOOKAHEAD`	Characters (from `TIME_PREFIX`'s position) to search for a timestamp. 0 or -1 disables the limit, at a performance cost that scales with line length. Default 128.
`TIME_FORMAT`	A `strptime`-style format, read starting right after `TIME_PREFIX`'s match.
`DETERMINE_TIMESTAMP_DATE_WITH_SYSTEM_TIME`	For a dateless timestamp, use system time (with a 3-hour future-tolerance before assuming yesterday's date) instead of the last successfully-parsed timestamp. Default `false`.
`TZ` / `TZ_ALIAS`	Fallback timezone (used only if the event carries none and the forwarder didn't supply one), and a comma-separated `ABBREV=offset` list to disambiguate ambiguous timezone abbreviations extracted from event text (e.g. `EST=GMT+10:00` for Australian Eastern rather than US Eastern). `TZ_ALIAS` never affects the `TZ` setting itself.
`MAX_DAYS_AGO` / `MAX_DAYS_HENCE`	How far in the past/future an extracted date can be before Splunk substitutes the last acceptable timestamp (or current time, if none exists). Defaults 2000 days / 2 days.
`MAX_DIFF_SECS_AGO` / `MAX_DIFF_SECS_HENCE`	How far a timestamp can jump from the previous one (in a different format than the source's majority) before Splunk warns, and potentially rejects the event if no timestamp could be assigned at all. Defaults 3600s / 604800s.
`ADD_EXTRA_TIME_FIELDS`	`none`/`false` strips all indextime timestamp metadata (including subsecond precision); `subseconds` strips the `date_*` fields but keeps subsecond precision; `all`/`true` keeps everything. Default `true`.

Structured data header extraction

Applies at input time. Most of these settings' actual defaults shift once INDEXED_EXTRACTIONS is set.

Setting	Description
`INDEXED_EXTRACTIONS`	`CSV`/`TSV`/`PSV`/`W3C`/`JSON`/`HEC`/`XML`/`XMLKV`/`XMLKV-WINEVT` -- parses the whole structured format at index time. Don't pair `JSON`/`XML`-family values with the equivalent `KV_MODE` setting on the same sourcetype, or fields get extracted twice.
`METRICS_PROTOCOL`	`STATSD` or `COLLECTD_HTTP` -- interprets the source as metrics data in that wire format.
`STATSD-DIM-TRANSFORMS`	Comma-separated list of `transforms.conf` `[statsd-dims:...]` stanzas used to extract dimensions from statsd data.
`STATSD_EMIT_SINGLE_MEASUREMENT_FORMAT`	Whether the statsd processor emits one measurement per data point (recommended, default `true`) or multiple.
`METRIC-SCHEMA-TRANSFORMS`	Comma-separated `[metric-schema:...]` stanza names (from `transforms.conf`) that convert index-time-extracted log fields into metrics data points, applied after ordinary index-time extraction.
`PREAMBLE_REGEX`	Ignores matching "preamble" lines that precede structured data.
`FIELD_HEADER_REGEX` / `HEADER_FIELD_LINE_NUMBER`	Locates the header: either a regex whose match precedes the actual header text, or an explicit line number (0 = auto-locate).
`FIELD_DELIMITER` / `HEADER_FIELD_DELIMITER` / `FIELD_QUOTE` / `HEADER_FIELD_QUOTE`	Single-character delimiter/quote settings, accepting the special names `space`, `tab`/`\t`, `fs`/`gs`/`rs`/`us` (ASCII separators), `\xHH`, `none` (quote settings only), or `whitespace`/`ws` (delimiter settings only).
`HEADER_FIELD_ACCEPTABLE_SPECIAL_CHARACTERS`	Special characters allowed unmangled in header field names (by default, anything non-alphanumeric/non-space is replaced with an underscore). ASCII <128 only; avoid characters like `=` that could produce an invalid search query.
`TIMESTAMP_FIELDS` / `FIELD_NAMES` / `MISSING_VALUE_REGEX`	Names the field(s) making up a split timestamp; supplies header field names when the file has none; sets the placeholder used for absent values.
`JSON_TRIM_BRACES_IN_ARRAY_NAMES`	Strips the trailing `{}` JSON array-field indicator (e.g. `data.mount_point{}` → `data.mount_point`) -- makes index-time and `spath` search-time array field names inconsistent if enabled. Default `false`.
`XML_INDEXED_EXTRACTIONS_PIPELINE`	`typing` (not on a UF), `structuredparsing`, `exec`, or `wineventlog` -- the pipeline used for XML index-time extraction; only active alongside `INDEXED_EXTRACTIONS`.
`extraction_cutoff`	Max bytes of an XML event that index-time extraction processes. Default 10000.
`XML_IE_INCLUDE` / `XML_IE_EXCLUDE`	Wildcard-capable allow/deny lists of metadata fields to extract from XML data.
`OPTIMIZE_IE_EXTRACT`	Skips search-time extraction when index-time extraction already covers every field a search needs. Default `false`.

Field extraction configuration

Three extraction types, differing in when they run and whether they reference a separate transforms.conf stanza.

Type	When	References transforms.conf?
`TRANSFORMS-<class>`	Index time	Yes, required
`REPORT-<class>`	Search time	Yes, required
`EXTRACT-<class>`	Search time	No -- fully "inline" in props.conf

Prefer EXTRACT unless you need REPORT's extra capability: reusing one regex across multiple sources/sourcetypes/hosts, applying more than one regex to the same spec, delimiter-based extraction, multivalued-field extraction, field names starting with a digit/underscore, or precise formatting control -- all of which require the referenced transforms.conf stanza.

Setting	Description
`RULESET-<class>` / `RULESET_DESC-<class>`	Modern equivalent of `TRANSFORMS-<class>` for filtering/routing/masking, configured via `/services/data/ingest/rulesets`. Unlike TRANSFORMS, a RULESET re-runs on the indexer even if already applied on a heavy forwarder upstream. When both match, TRANSFORMS applies first.
`KV_MODE`	`none`/`auto`/`auto_escaped`/`multi`/`multi:<stanza>`/`json`/`xml` -- the automatic field/value extraction mode. Don't pair `json` with `INDEXED_EXTRACTIONS = JSON` on the same sourcetype (double extraction). Default `auto`.
`MATCH_LIMIT` / `DEPTH_LIMIT`	PCRE resource bounds for `EXTRACT` only (set the equivalents in `transforms.conf` for REPORT/TRANSFORMS). Defaults 100000 / 1000.
`AUTO_KV_JSON`	Whether JSON is auto-extracted alongside `auto`/`auto_escaped` KV_MODE. Default `true`.
`KV_TRIM_SPACES`	Whether leading/trailing spaces are stripped from automatically-extracted field values. Default `true`.
`CHECK_FOR_HEADER`	Index-time only. Auto-detects a suitable header line for field naming on files that list column values without names; appends a numeral to the resulting sourcetype (e.g. `-2`). Disabled when `LEARN_SOURCETYPE = false`; doesn't work well with forwarded data since learned names are written locally. Default `false`.
`SEDCMD-<class>`	Index-time-only sed-style find/replace against `_raw`, commonly used to mask sensitive data before it's ever written to disk. Supports `s/regex/replacement/flags` and `y/string1/string2/`.
`FIELDALIAS-<class>`	Search time, after extraction. `(orig AS new)+` or `ASNEW` (keeps an existing value rather than overwriting). One alias maps to exactly one source field -- mapping two sources onto the same alias silently applies only one.
`EVAL-<fieldname>`	Search time, after extraction/aliasing, before lookups. Runs as if in parallel -- multiple EVALs referencing each other see original, not updated, values.
`LOOKUP-<class>`	Search time, after extraction/aliasing/calculated fields. `$TRANSFORM (match_field (AS event_field)?)+ (OUTPUT\|OUTPUTNEW ...)?` -- `OUTPUTNEW` only writes fields that don't already exist; unmatched match fields clear all output fields.

Binary, checksum & segmentation

Setting	Description
`NO_BINARY_CHECK`	Process binary files instead of ignoring them. Valid only for `[<sourcetype>]`/`[source::...]`. Default `false`.
`detect_trailing_nulls`	`auto`/`true`/`false` -- avoids reading trailing null bytes (a workaround for apps like IIS that preallocate log files with nulls). Set `false` for encodings like UTF-16 where nulls are legitimate character bytes. Default `false` (*nix), `true` (Windows).
`SEGMENTATION` / `SEGMENTATION-<selection>`	Names the `segmenters.conf` segmenter used at index time (default `indexing`), or per Splunk Web display-selection (`all`/`inner`/`outer`/`raw`).
`CHECK_METHOD`	`endpoint_md5` (first/last 256 bytes, default), `entire_md5`, or `modtime` -- how a file's already-indexed status is determined. Valid only for `[source::...]`.
`PREFIX_SOURCETYPE`	For the special `too_small` sourcetype only (files under 100 lines). `true` produces `<name>-too_small` instead of a flat `too_small`, keeping wildcard searches like `sourcetype=access*` effective. Default `true`.
`initCrcLength`	Same as `inputs.conf`'s setting: how many bytes of a file are read before deciding whether it's already been seen (256-1048576; default 256). Raising it can cause re-indexing.
`is_valid`	Set automatically with `invalid_cause`, at input time. Don't set it. Default `true`.

Sourcetype configuration & classification learning

Setting	Description
`sourcetype`	`[source::...]` only. Assigns the given sourcetype to matching input, at input time (not applied to already-forwarded data on the receiving side).
`rename`	`[<sourcetype>]` only. Renames the sourcetype at search time; the renamed target's field extractions apply, not the original's. The original remains queryable via `_sourcetype`.
`invalid_cause` / `unarchive_cmd` / `unarchive_cmd_start_mode` / `unarchive_sourcetype`	Hands a file off instead of tailing it normally -- `archive` (runs `unarchive_cmd`, or `_auto` for built-in tar/gz/zip handling) or `winevt` (hands to the Event Log input). `unarchive_cmd_start_mode` is `direct` (no shell, first token is the command) or `shell` (default, supports pipelines).
`SOURCETYPE_NAME_RESTRICTED_CHARACTERS`	Characters disallowed in a sourcetype name, quoted comma-separated. Default `"#,&,>,<,?,::"`.
`force_local_processing`	UF only. Forces linebreaking/aggregation/SEDCMD to run locally before forwarding, at extra CPU/memory cost. Default `false`.
`LEARN_SOURCETYPE` / `LEARN_MODEL`	Whether the file classifier learns new/known sourcetypes at all, and whether it writes a model file to the learned directory for known ones. Setting `LEARN_SOURCETYPE = false` also disables `CHECK_FOR_HEADER`. Both default `true`.
`termFrequencyWeightedDist`	Uses term-frequency-weighted distance (more accurate) rather than shared-unique-term-count distance (legacy) when the classifier compares files. Default `false`.
`maxDist`	How much a file may differ from a sourcetype model and still match -- lower is stricter. Adjust in ~100 steps if a model over- or under-matches. Default 300.
`trackPipelineLatency`	Logs average/max per-host/sourcetype/source/index pipeline latency to `metrics.log`. Default `true`.
`MORE_THAN_<n>` / `LESS_THAN_<n>`	`[rule::...]`/`[delayedrule::...]` only. A regex whose match-line proportion must exceed/stay under n% for the rule to fire; a rule needs every one of its MORE_THAN/LESS_THAN conditions to match.
`ANNOTATE_PUNCT`	Indexes a `punct::` token capturing an event's punctuation shape, useful for finding similar events. Default `true`.
`HEADER_MODE`	`always`/`firstline`/`none` -- whether an inline `*SPLUNK*` directive can rewrite index-time fields. Empty default resolves to `always` for scripted inputs, `none` for file inputs.
`description` / `category`	Purely presentational -- sourcetype description and front-end grouping category. No effect on indexing.
`_actions` / `pulldown_type` / `given_type`	Internal -- do not set. Used by Splunk Web and the `CHECK_FOR_HEADER` feature; the spec marks them "NOT YOURS."

Example

# Line merging + truncation tuning
[apache_error]
SHOULD_LINEMERGE = true

[host::small_events]
TRUNCATE = 256

# Disable per-event timestamping for a log path, single-line events only
[source::.../mylogs/*.log]
DATETIME_CONFIG = NONE
SHOULD_LINEMERGE = false

# Timezone by host pattern
[host::nyc*]
TZ = US/Eastern

# Inline search-time extraction
[my_sourcetype]
EXTRACT-extract_ip = (?<ip>\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})

# Automatic lookup
[my_lookuptype]
LOOKUP-foo = mylookuptable userid AS myuserid OUTPUT username AS myusername

# Sourcetype assignment for a Windows path (note the escaped backslashes)
[source::...\\iis\\iis6.log]
sourcetype = iis_access

Six independent stanzas spanning line merging, truncation, timestamp disabling, timezone assignment, inline field extraction, lookup enrichment, and Windows-path sourcetype assignment -- illustrating how differently-scoped [<spec>] stanzas each contribute settings without needing to repeat unrelated ones.

Validation

Confirm which [<spec>] type actually wins for a given setting -- source:: beats host:: beats plain sourcetype, regardless of priority.
Set SHOULD_LINEMERGE = false whenever LINE_BREAKER already delimits events -- leaving it true risks re-merging already-split events and costs performance.
Don't pair INDEXED_EXTRACTIONS = JSON/XML-family values with the matching KV_MODE on the same sourcetype -- fields get extracted twice.
Prefer EXTRACT over REPORT unless you genuinely need reuse across stanzas, multiple regexes, delimiter-based extraction, or multivalued fields -- REPORT's added transforms.conf indirection isn't free complexity.
Escape backslashes in any Windows [source::...] stanza -- an unescaped path silently fails to match.
Remember SEDCMD runs at index time only -- masking applied here can't be un-applied at search time.
Use | extract reload=t in Splunk Web to apply changes without a full restart.

← Back to References

References / Splunk platform configuration

App Configuration

app.conf maintains one app's state and metadata -- identity, launcher/Splunkbase presentation, install/upgrade behaviour, custom-conf-file reload triggers, UI visibility, search head cluster deployment behaviour, and legacy credential verification. Every app has its own copy; there is no shipped default app.conf. Backs the Splunk Taxonomy's App and App Configuration objects (SOT-09.01.01 / SOT-09.02.01).

Definition

Each app on the platform carries its own app.conf, layered the normal way across default/ and local/. It has no equivalent of | extract reload=t -- manual edits require a full restart, though the [triggers] stanza can avoid that requirement for an app's own custom conf files.

There is no default app.conf shipped with Splunk -- each app's copy is created when the app is built or installed.

File locations

Configuration file: app.conf.

Scope	Path
App	`$SPLUNK_HOME/etc/apps/<app_name>/{default,local}/app.conf`

One per app, describing that app to itself -- there's no system-wide app.conf.

Identity & launcher metadata

Stanza / Setting	Description
`[author=<name>]`: `email`, `company`	Author contact metadata, keyed by author name.
`[id]`: `group`, `name`, `version`	Legacy identity stanza, largely superseded by `[launcher]`/`[package]`.
`[launcher] remote_tab`	Whether the Launcher interface connects to Splunkbase -- applies only to the Launcher app itself. Default `true`.
`[launcher] version`	Three-digit `Major.Minor.Revision` is best practice; a pre-release suffix like `-beta`/`+alpha` is allowed. No spaces.
`[launcher] description`	Short explanatory text shown under the app title in Launcher. Keep to 200 characters or fewer.
`[launcher] author`	Splunkbase username (for apps intended for upload) or a full name/contact for internal-only apps.

Icons and screenshots aren't set in this file. Place a 36x36px PNG named <app_name>Icon.png (capital I required) and/or a 623x350px screenshot PNG directly in <app_name>/static/ -- Launcher and Splunkbase detect them automatically.

Package & install

Setting	Description
`[package] id`	Required for any app uploaded to Splunkbase (omit for internal-only apps); must match the app's folder name and follow cross-platform folder-name restrictions (letters/digits/`.`/`_` only, no trailing dot, no reserved Windows device names like `CON`/`PRN`).
`[package] check_for_updates` / `show_upgrade_notification`	Whether Splunk checks Splunkbase for updates, and whether an upgrade notification is shown in Splunk Web. Defaults `true` / `false`.
`[install] state`	`enabled` or `disabled` -- a disabled app's configuration is entirely ignored. Default `enabled`.
`[install] state_change_requires_restart`	Whether enabling/disabling the app always forces a restart (`true`), or might not depending on the app's contents (`false` -- doesn't guarantee no restart is ever needed). Default `false`.
`[install] build`	Required positive integer, incremented whenever `static/` files change, alongside every `version` bump -- forces browsers to bypass cached static assets.
`[install] allows_disable`	Whether the app permits itself to be disabled. Default `true`.
`[install] install_source_checksum` / `install_source_local_checksum`	Auto-populated by Splunk on install -- checksums of the source tarball and its local-config layer. Do not set these explicitly.
`[install] python.required` / `python.version`	Comma-separated supported Python versions for `installit.py`, superseding the deprecated `python.version`.
`[install] is_configured`	Whether the app's custom setup has been performed. Default `false`.

Triggers (custom conf reload)

Only needed if the app ships a custom (non-Splunk-native) conf file and you want state changes (install/update/enable/disable) to avoid a full restart.

Setting Description

reload.<conf_file_name> Conf-level trigger (name excludes the .conf extension). simple takes no special action; access_endpoints <url> calls that REST endpoint's _reload(); http_get/http_post <url> simulates that HTTP verb against the URL; never forces a restart on every state change. rest_endpoints is reserved for Splunk's own restmap.conf reload.

reload.<conf_file_name>.<conf_stanza_prefix> Stanza-level trigger, giving indexer-cluster peers granular control over which reload handler fires for which changed stanza prefix in a newly pushed cluster bundle. Same value vocabulary as the conf-level trigger (minus rest_endpoints). Stanzas without a matching stanza-level trigger fall back to a rolling restart. Only used by indexer-cluster peers, and only supported for inputs.conf and server.conf.

If an app has no custom conf file, it needs no [triggers] stanza at all -- the system default app.conf already auto-reloads Splunk-native config files.

UI settings -- `[ui]`

Setting	Description
`is_visible`	Whether the app is navigable in Splunk Web -- requires at least one view.
`show_in_nav`	Whether the app appears in the global app dropdown.
`is_manageable`	Removed -- no longer has any effect.
`label`	Required. Display name in Splunk Web/Launcher, recommended 5-80 characters, must not include a "Splunk For" prefix.
`docs_section_override`	Overrides the auto-generated documentation link section (default is `[<app-name>:<app-version>]`).
`attribution_link`	Third-party credits/attribution URL. Must start with `http://`/`https://` or it's interpreted as an internal Quickdraw documentation reference instead.
`setup_view`	Optional custom setup view, found via the `/data/ui/views` REST endpoint.
`supported_themes`	Comma-separated theme list; if set, must include `light`.

Search head cluster deployment -- `[shclustering]`

Setting Description

deployer_lookups_push_mode preserve_lookups (honours the -preserve-lookups CLI flag), always_preserve, always_overwrite, or overwrite_on_change -- controls whether splunk apply shcluster-bundle overwrites this app's lookup tables on members. Default always_preserve.

deployer_push_mode full (overwrites non-local/non-user content, merges local/user -- avoid for built-in apps), merge_to_default (merges local into default, overwrites member's default -- the pre-7.2 behaviour), local_only (pushes only local/, merged with member precedence -- for built-in apps like search), or default_only (overwrites default, skips local/users). Default merge_to_default for ordinary apps, local_only for built-in apps.

Credentials, diag & data management

Stanza / Setting	Description
`[credentials_settings] verify_script`	Command line (interpreter + script, quoted if it contains variable expansion or spaces) invoked to verify this app's credentials, communicating over stdin/stdout like scripted auth. Superseded by `passwords.conf` from 6.3 onward, though still honoured if present.
`[credential:<realm>:<username>] password`	Password for the given username/realm; stored encrypted once saved by splunkd, even if entered in clear text.
`[diag] extension_script` / `data_limit`	A Python script (simple filename, in the app's `bin/`) that contributes extra data to `splunk diag` output, and a soft ceiling (default 100MB) on how much uncompressed data it may add.
`[diag] default_gather_lookups`	Filenames of lookups diag should always gather by default -- only for lookups guaranteed not to contain sensitive user data.
`[data_management] plugin_enabled`	Whether this app contributes a Data Management navigation plugin item. Default `false`.

Example

[launcher]
author = Jane Smith
description = Monitors and correlates firewall traffic logs
version = 1.4.0

[triggers]
# Custom conf file: no restart needed, no special reload handler
reload.myconffile = simple

# Custom conf file: no restart, but calls a custom EAI reload endpoint
reload.myotherconffile = access_endpoints /admin/myendpoint

# Stanza-level triggers for indexer-cluster peers: only monitor-prefixed
# inputs.conf stanzas invoke this specific reload handler
reload.inputs.monitor = access_endpoints /data/inputs/monitor
reload.inputs.script  = access_endpoints /data/inputs/script
reload.inputs.http    = access_endpoints /data/inputs/http

Launcher metadata for a firewall-monitoring app, plus conf-level triggers avoiding a restart for two custom config files, and stanza-level triggers giving indexer-cluster peers granular reload behaviour per inputs.conf stanza prefix rather than one blanket handler.

Validation

Bump both version and build together on every release that touches static/ -- build alone is what busts browser caching.
Never hand-set install_source_checksum/install_source_local_checksum -- Splunk populates these automatically on install.
Add a [triggers] stanza for any app shipping a custom conf file if you want to avoid a full restart on every state change -- without it, Splunk requires one.
Remember stanza-level reload.<conf>.<prefix> triggers only work for inputs.conf and server.conf, and only for indexer-cluster peers.
Choose deployer_push_mode deliberately for built-in apps -- full can overwrite a member's built-in app content in ways that cause adverse behaviour; prefer local_only there.
Set label -- it's required, and don't include a "Splunk For" prefix.
Prefer passwords.conf over [credential:...] stanzas here for new credential storage; the app.conf mechanism is honoured but superseded.

← Back to References

References / Splunk platform configuration

Authentication Configuration

authentication.conf configures every authentication mechanism the platform supports -- native Splunk password policy, LDAP, scripted auth, SAML SSO, ProxySSO, Duo/RSA multifactor authentication, OAuth2 token validation, and platform secret storage -- selected via the top-level authType setting and detailed in per-mechanism stanzas. It is one of the largest and most security-sensitive config files on the platform. Backs the Splunk Taxonomy's User, LDAP Strategy, SAML Strategy, OAuth2 Provider, Duo MFA Config, RSA MFA Config, and ProxySSO Config objects.

Definition & global settings -- `[authentication]`

Setting	Description
`authType`	`Splunk` (default), `LDAP`, `Scripted`, `SAML`, or `ProxySSO` -- selects the primary authentication system.
`authSettings`	Names the stanza(s) holding the chosen system's detailed configuration. For LDAP, a comma-separated list of strategy names queried in order; for scripted auth, a single stanza name; for SAML/ProxySSO, the relevant stanza.
`passwordHashAlgorithm`	`SHA512-crypt` (default), `SHA256-crypt`, either with a `-<num_rounds>` suffix (minimum 1000 rounds; very high values can make splunkd unresponsive), or `MD5-crypt` (legacy, not FIPS-compatible). Only affects newly-set/changed passwords -- existing hashes keep their original algorithm.
`defaultRoleIfMissing`	LDAP only. Role applied when the LDAP server returns no groups, or none map to a Splunk role.
`externalTwoFactorAuthVendor` / `externalTwoFactorAuthSettings`	Enables MFA (currently Duo or RSA) and names the stanza with that vendor's settings. Empty vendor string disables MFA.
`scimSupportedDomains`	Allowed network domains for SCIM integration; not meant to be modified. Default `.okta.com, .oktapreview.com, *.okta-emea.com`.

File locations

Configuration file: authentication.conf.

Scope	Path
System	`$SPLUNK_HOME/etc/system/{default,local}/authentication.conf`
App	`$SPLUNK_HOME/etc/apps/<app_name>/{default,local}/authentication.conf`

LDAP authentication -- `[<authSettings-key>]`

One stanza per LDAP strategy, named in authSettings.

Setting	Description
`host` / `port` / `SSLEnabled`	LDAP server address. Ports default 389 (non-SSL) / 636 (SSL).
`bindDN` / `bindDNpassword`	Credentials for the account that reads LDAP entries. Leave both blank for anonymous bind (if the server supports it).
`userBaseDN` / `userBaseFilter`	Where users live (semicolon-delimited for multiple trees) and an optional filter that significantly speeds up queries on large directories.
`userNameAttribute` / `realNameAttribute` / `emailAttribute`	Which LDAP attributes map to Splunk username (typically `sAMAccountName` on AD, `uid` elsewhere), display name (typically `cn`), and email (default `mail`).
`groupBaseDN` / `groupBaseFilter`	Where groups live (semicolon-delimited) and an optional filter. To skip real groups and treat each user as its own group, point this at `userBaseDN` and align the mapping attributes below with `userNameAttribute`.
`groupMappingAttribute` / `groupMemberAttribute` / `groupNameAttribute`	How group membership is declared (default `dn`; often `uid` on OpenLDAP), which group attribute lists members (typically `member` or `memberUid`), and which holds the group's name (typically `cn`).
`dynamicGroupFilter` / `dynamicMemberAttribute`	Only for retrieving dynamic (URL-defined) groups, e.g. `(objectclass=groupOfURLs)` / `memberURL`.
`nestedGroups`	Expands nested groups via the `memberof` LDAP extension, if the server supports it.
`charset`	Only for a server that incorrectly returns non-UTF-8 data (LDAP is supposed to always return UTF-8) -- same format as `CHARSET` in props.conf.
`anonymous_referrals`	Chases LDAP referrals anonymously (Splunk never rebinds with credentials for this). Default enabled (`1`).
`sizelimit` / `pagelimit` / `enableRangeRetrieval`	Max entries requested per search (default 1000, still bounded by the server's own limit), max entries per page (`-1` disables paging, the default), and whether oversized single-attribute value sets (e.g. huge groups) are fetched via range retrieval (default `false`).
`timelimit` / `network_timeout`	Max seconds to wait for a search to complete (default 15, max 30) and for the underlying socket to see any activity (default 20, must exceed `timelimit` or searches can be cut off mid-flight).
`ldap_negative_cache_timeout`	How long a confirmed-nonexistent LDAP user is remembered as such, avoiding repeat queries. Doesn't skip the login-time existence check itself. Default 86400s.

[roleMap_<authSettings-key>] maps <Splunk role> = <semicolon-separated LDAP groups>, scoped to that one strategy -- importing groups for the same user from multiple strategies isn't supported.

Scripted authentication

Setting	Description
`python.required` / `python.version`	Comma-separated supported Python versions for the auth script, superseding the deprecated `python.version`.
`scriptSearchFilters`	Whether the script is called to add search filters. Default `0`.
`[cacheTiming]` `userLoginTTL`	Per-user cache timeout for the `userLogin` script function. Default 0 (no caching).
`[cacheTiming]` `userInfoTTL` / `getUserInfoTTL` / `getUsersTTL`	Per-user cache timeout for `getUserInfo`/`getUsers`, superseding the deprecated `getUserInfoTTL`/`getUsersTTL`. Default 10s (or the larger of the deprecated settings if either is set).

Cache timing is a latency-vs-performance tradeoff: high values reduce script invocation overhead but delay picking up external changes; low values do the opposite. Setting a TTL to 0 disables caching for that function entirely, which can hurt performance under heavy script invocation.

Splunk native password policy -- `[splunk_auth]`

Setting	Description
`minPasswordLength` / `minPasswordUppercase` / `minPasswordLowercase` / `minPasswordDigit` / `minPasswordSpecial`	Composition requirements enforced on password set/change. Default length 8; the four character-class minimums default to 0 (not enforced).
`expirePasswordDays` / `expireAlertDays` / `expireUserAccounts`	Days until a password expires after reset (default 90, max 3650), days of advance warning logged to splunkd.log (default 15, max 120), and whether expiration is enforced at all (default `false`).
`forceWeakPasswordChange`	Forces users with a weak password to change it. Default `false`.
`lockoutUsers` / `lockoutAttempts` / `lockoutThresholdMins` / `lockoutMins`	Whether account lockout is enabled (default `true`), how many failed attempts within the threshold window trigger it (default 5, max 64), the window itself (default 5min, max 120), and the lockout duration (default 30min, max 1440). On a search head cluster, lockout state is per-member, not cluster-wide.
`enablePasswordHistory` / `passwordHistoryCount`	Whether reuse of a past password is blocked (default `false`), and how many past passwords are remembered (default 24, max 128).
`constantLoginTime`	Minimum guaranteed response time (seconds, up to 5.0) for any login attempt, mitigating timing-based user-enumeration attacks. Default 0 (disabled).
`verboseLoginFailMsg`	Whether a login failure explains the specific reason (default `true`) or shows a generic message.
`scsSyncUserDeletes`	Whether deleting a local user also de-provisions them in Splunk Cloud Services (only for instances converged with SCS; doesn't apply to SAML users). Default `true`.

SAML: connection, signing & security -- `[<saml-authSettings-key>]`

Setting	Description
`fqdn` / `redirectPort`	This instance's FQDN (used to populate the assertion consumer URL; defaults to `server.conf`'s value) and the port SAML responses are sent to (0 to omit port info entirely; defaults to `web.conf`'s `httpport`).
`idpSSOUrl` (required)	The IdP endpoint AuthNRequests are sent to.
`idpAttributeQueryUrl`	IdP endpoint for attribute queries (fetching current role info); if unset, role info from the assertion is cached instead.
`idpCertPath`	Relative to `etc/auth/idpCerts`; a single self-signed cert filename, or a subdirectory of an ordered (root-first) certificate chain. Required if `signedAssertion = true`.
`idpCertExpirationWarningDays` / `idpCertExpirationCheckInterval`	Days before expiry to start logging a warning on login (default 90, max 365) and the minimum interval between repeat warnings for the same cached certificate fingerprint (default 1d).
`entityId` (required) / `issuerId` (required)	SP entity ID as configured on the IdP, and the IdP's own unique identifier -- must exactly match the `Issuer` field of every SAML response or validation fails.
`signAuthnRequest` / `signatureAlgorithm`	Whether outbound AuthNRequests are signed (default `true`) and which algorithm to use -- `RSA-SHA256` (default), `RSA-SHA384`, or `RSA-SHA512` (SHA1 has been removed).
`signedAssertion`	Whether the IdP signs assertions (default `true`); if `false`, Splunk doesn't verify the signature (encrypted assertions are unaffected).
`inboundSignatureAlgorithm` / `inboundDigestMethod`	Semicolon-separated lists of algorithms/digests Splunk will accept on inbound SAML responses -- anything signed/hashed outside these lists is rejected. Defaults include all of SHA256/384/512 tiers.
`partialChainCertVerification`	Allows SAML cert-chain verification to succeed without a full path back to a self-signed root (treats intermediate certs as trust anchors). Default `false`.
`allowPartialSignatures` / `allowEntities`	Whether only the assertion block (not the whole response) needs signing (default `true`), and whether XML entity references in an assertion are accepted -- changing the latter's default is a security risk and shouldn't be done without Splunk Support guidance. Default `false`.
`ssoBinding` / `sloBinding`	`HTTPPost` (default) or `HTTPRedirect` for SP-initiated login/logout -- must match the IdP's own configuration.
`includeAssertionConsumerServiceURL` / `includeDestination`	Whether these fields are included in the SAML request; both are forced on when `signAuthnRequest = true` regardless of their own value. Default `false`.
`idpSLOUrl`	The IdP endpoint that service-provider-initiated single logout requests go to. Optional.
`redirectAfterLogoutToUrl`	Where users are sent after logging out. If neither this nor an IdP single-logout URL is set, they go to splunk.com. Optional.
`errorUrl` / `errorUrlLabel`	A URL shown on SAML errors -- absolute, or relative starting with `/` -- and the label for that link. Optional.
`nameIdFormat`	The Subject format to request in SAML authentication requests, if the IdP supports it. Optional.
`signatureRawPubKey`	Whether signatures that Splunk sends to the IdP include a KeyValue element with the raw public key. Leave `false` unless the IdP requires it. Default `false`.
`sslKeysfile` / `sslKeysfilePassword` / `caPath`	Deprecated -- use `clientCert`, `sslPassword` and absolute certificate paths instead.
`blacklistedAutoMappedRoles` / `blacklistedUsers`	Deprecated -- renamed `excludedAutoMappedRoles` and `excludedUsers`.
`allowSslCompression` / `cipherSuite` / `sslVersions` / `sslCommonNameToCheck` / `sslAltNameToCheck` / `ecdhCurves` / `ecdhCurveName` / `clientCert` / `sslPassword` / `caCertFile` / `sslVerifyServerCert` / `sslVerifyServerName`	SSL/TLS settings for the SAML stanza. Each falls back to the equivalent `server.conf` setting when unset. `ecdhCurves` supersedes the deprecated `ecdhCurveName`.

SAML: role mapping & attribute queries

Setting	Description
`enableAutoMappedRoles` / `excludedAutoMappedRoles`	Whether IdP groups auto-map to same-named local roles (default `true`), and which roles are excluded from that auto-mapping (default `admin, power`).
`defaultRoleIfMissing`	Fallback role when the IdP returns no groups; required if `skipAttributeQueryRequestForUsers` is set, ignored if `enableAutoMappedRoles = false`.
`excludedUsers` / `skipAttributeQueryRequestForUsers`	Users excluded from the IdP response entirely, and users for whom attribute-query requests are skipped (local users are skipped by default).
`lockRoleToFullDN`	When a `[roleMap_SAML]` entry maps a bare CN and the IdP returns a full DN, this locks the first-matching user's full DN into `[lockedRoleToFullDNMap_SAML]` and rejects subsequent logins from users sharing that CN but a different DN -- a meaningful behavioural gotcha for CN-based role maps. Default `true`.
`maxAttributeQueryThreads` / `maxAttributeQueryQueueSize` / `attributeQueryTTL`	Concurrency (default 2, max 10) and queue depth (default 10000, 0 = unlimited) for attribute query requests, and how long the resulting role info is cached (default 21600s).
`attributeQuerySoapUsername` / `attributeQuerySoapPassword`	Basic-auth credentials for attribute query SOAP requests; required if `idpAttributeQueryUrl` is set. Password is obfuscated on startup.
`scriptPath` / `scriptFunctions` / `scriptTimeout`	Python 3 authentication-extension script (in `etc/auth/scripts`), which of `getUsers`/`getUserInfo`/`login` it implements (`getUsers` requires `getUserInfo`), and its max runtime (default 10s, minimum enforced 500ms).
`useAuthExtForTokenAuthOnly`	Restricts the extension script to token-based auth only; other calls use the persistent `[userToRoleMap_SAML]` cache instead. Default `true`.
`cacheSAMLUserInfotoDisk`	Whether SAML user-mapping info is persisted into `authentication.conf`'s `[userToRoleMap_SAML]` stanza (useful for SHC consistency) or kept in memory only. Default `false`, but auto-enabled in one specific IdP-without-AQR + extension-script combination.
`getUserInfoTtl` / `saml_negative_cache_timeout`	Cache duration for extension-script-retrieved user info (default 21600s, takes precedence over `attributeQueryTTL` if both are set), and how long a confirmed-nonexistent SAML user is remembered (default 3600s).
`replicateCertificates` / `assertionTimeSkew`	Whether IdP certs auto-replicate across a search head cluster (default `true`; otherwise manual replication is required), and the allowed clock-skew tolerance in seconds for assertion validity windows (default 120 -- raising it materially increases replay-attack risk).
`attributeQueryRequestSigned` / `attributeQueryResponseSigned`	Whether attribute query requests are signed, and whether responses are signed (`false` skips verifying the response signature against the IdP certificate). Default `true` each.
`saml_negative_cache_max_entries` / `preserveNegativeCache`	Size of the in-memory SAML negative cache (least-recently-used entries are evicted when it's full), and whether it survives authentication reloads. Defaults `1000` / `true`.
`getUsersPrecacheLimit`	How many users to pre-cache at startup from the `getUsers` script function; `0` caches all of them. Default `1000`.
`scriptSecureArguments`	`key:value;` pairs passed to the user-information script -- for credentials the script needs. They're encrypted at startup. Optional.

Four supporting stanzas: [roleMap_<saml-authSettings-key>] (role → semicolon-delimited SAML groups), [userToRoleMap_<saml-authSettings-key>] (user = Roles::Realname::Email, used only when the IdP supports neither attribute queries nor extension scripts, or when useAuthExtForTokenAuthOnly = true), [lockedRoleToFullDNMap_<saml-authSettings-key>] (auto-generated output when lockRoleToFullDN = true -- not meant to be hand-authored beyond resolving conflicting DNs), and [authenticationResponseAttrMap_SAML] (renames the expected role/realName/mail assertion attribute names for IdPs using different claim names).

ProxySSO

Stanza / Setting	Description
`[roleMap_proxySSO]`	`<Splunk role> = <semicolon-separated groups>`, from headers the proxy passes. A group matching a role name auto-maps even without an explicit entry.
`[userToRoleMap_proxySSO]`	`<ProxySSO user> = <semicolon-separated roles>`.
`[<proxysso-authsettings-key>] defaultRoleIfMissing`	Fallback role when no mapping resolves.
`excludedAutoMappedRoles` / `excludedUsers`	Roles/users excluded from proxy-header auto-mapping (the deprecated `blacklisted...` equivalents still work but should be migrated).

Secret storage -- `[secrets]`

Setting	Description
`disabled`	Toggles integration with a platform-provided secret store (e.g. GNOME keyring). Default `true` unless Common Criteria mode is enabled, in which case `false`.
`filename`	Basename (no path separators, must end `.py`) of a script in an app's `bin/` or `etc/system/bin` that integrates with the secret store.
`namespace`	Instance-specific namespace within the secret store (e.g. the GNOME keyring name) -- customize per instance if multiple Splunk instances share one backend. Default `splunk`.

Multifactor authentication (Duo & RSA)

Activated by externalTwoFactorAuthVendor/externalTwoFactorAuthSettings in [authentication]. Both vendors follow the same shared-SSL-fallback pattern as the SAML stanza (sslVersions, cipherSuite, ecdhCurves, sslVerifyServerCert/sslVerifyServerName, sslCommonNameToCheck/sslAltNameToCheck).

Duo setting	Description
`universalPrompt`	Uses Duo's Universal Prompt (default `true`) rather than the Traditional Prompt, which Duo has announced deprecating.
`apiHostname` / `integrationKey` / `secretKey`	Required, Duo-provided values identifying the Splunk integration (integration key must be 20 chars, secret key 40; both obfuscated on save).
`appSecretKey`	Locally-generated (not shared with Duo), at least 40 chars. Required if `universalPrompt = false`.
`failOpen`	Bypasses Duo MFA if the service is unreachable. Default `false`.
`enableMfaAuthRest`	Requires Duo MFA for REST endpoint access too, not just Splunk Web login. Default `false`.
`sslRootCAPath` / `useClientSSLCompression`	A PEM file of root CA certificates that must match the Duo server's certificate chain, and whether TLS compression is used with Duo (falls back to `server.conf` when unset; default `false`).

RSA setting	Description
`authManagerUrl` / `accessKey` / `clientId`	Required. HTTPS URL of the RSA Authentication Manager REST endpoint, plus the access key and agent-name client ID from RSA Authentication Manager 8.2 SP1.
`failOpen` / `timeout` / `messageOnError`	Whether login is allowed if the RSA server is unreachable (default `false`), connection timeout in seconds (default 5), and a custom failure message shown to the user.
`replicateCertificates` / `enableMfaAuthRest`	Auto-replicates RSA certs across an SHC (default `true` -- required, or MFA verification fails on other members), and requires RSA MFA for REST endpoints too. Default `false`.
`sslVersionsForClient`	TLS versions for outgoing connections to RSA; falls back to `server.conf`'s `sslVersionsForClient` when unset.

OAuth2 token validation

Stanza / Setting	Description
`[oauth2_settings] issuer_uri` / `certFile` / `sslPassword`	The search head cluster load balancer's FQDN and the PEM certificate (plus its password) used to sign OAuth2 tokens Splunk itself issues.
`[oauth2_external_config_<issuer_url>]` / `audience` / `clientIdClaim` / `groupsClaim` / `issuer` / `jwks_uri` / `disable` / `friendlyName`	One stanza per external OAuth2 IdP, keyed by that IdP's trailing-slash issuer URL. Settings: `audience` (expected `aud` claim), `clientIdClaim`/`groupsClaim` (JWT claim field names for client ID and group membership), `issuer` (must match the stanza-name URL and the token's `iss` claim), `jwks_uri` (public HTTPS endpoint for the IdP's signing keys), `disable` (rejects tokens from this IdP when `true`), `friendlyName` (optional display name claim). All except `friendlyName` are required.
`[oauth2_external_role_mapping_<issuer_url>]`	`<idp_group> = <semicolon-separated Splunk roles>`, scoped per IdP.
`[oauth2_external_app_client_<client_name>]` / `appClient` / `oAuth2Config` / `roles` / `createdAt` / `modifiedAt`	Records a specific OAuth client: `appClient` (must match the stanza suffix), `oAuth2Config` (linking issuer URL), `roles`, and `createdAt`/`modifiedAt` Unix timestamps -- all required.
`[oauth2_restricted_endpoints]` / `ipv4_cidrs` / `ipv6_cidrs` / `hostnames`	SSRF hardening: `ipv4_cidrs`/`ipv6_cidrs` (CIDR-notation networks disallowed as JWKS endpoints, defaulting to private/loopback/link-local ranges) and `hostnames` (exact, case-insensitive matches, defaulting to `localhost`/`localhost.localdomain`/`local`).
`[auth-tokens] maxRequestAge`	Max age (seconds) of a `services/admin/auth-tokens` request before it's rejected. Default 3600. Requires a restart to change.
`[auth-tokens] strictPeerNameValidation`	Whether `services/admin/auth-tokens` rejects requests without a `peername` that has a peer-specific distributed search public key (`true`), or keeps the legacy behavior that may fall back to localhost key material (`false`). Must match on every node, and needs a restart. Default `false`.
`[splunk_token_settings] use_cloudconnect` / `cloudconnect_tenant`	Whether Splunk-issued authorization tokens carry Cloud Connect-specific claims, and the SCS tenant name to embed when they do.

Example

# Active Directory via LDAP
[authentication]
authType = LDAP
authSettings = AD

[AD]
host = ADbogus.splunksupport.kom
port = 636
SSLEnabled = 1
bindDN = ldap_bind@splunksupport.kom
bindDNpassword = ldap_bind_user_password
userBaseDN = CN=Users,DC=splunksupport,DC=kom
userNameAttribute = sAMAccountName
realNameAttribute = cn
groupBaseDN = CN=Groups,DC=splunksupport,DC=kom
groupMappingAttribute = dn
groupMemberAttribute = member
groupNameAttribute = cn
timelimit = 15
network_timeout = 20

[roleMap_AD]
admin = SplunkAdmins
power = SplunkPowerUsers
user = SplunkUsers

# Duo multifactor authentication, layered on top
[authentication]
externalTwoFactorAuthVendor = duo
externalTwoFactorAuthSettings = duo-mfa

[duo-mfa]
universalPrompt = true
apiHostname = api-xyz.duosecurity.com
appSecretKey = mustBeARandomStringOfSize40OrLonger
integrationKey = mustBeADuoProvidedStringOfSize20
secretKey = mustBeADuoProvidedStringOfSize40
enableMfaAuthRest = true

# Splunk native password policy
[splunk_auth]
minPasswordLength = 8
minPasswordUppercase = 1
minPasswordSpecial = 1
expirePasswordDays = 90
lockoutUsers = true
lockoutAttempts = 5

An Active Directory LDAP strategy mapping three AD groups to Splunk roles, Duo MFA layered on top (REST endpoints included), and a native password policy that would apply if authType were switched back to Splunk -- illustrating how these mechanisms are independently configured, in stanzas that coexist in the same file even when only one authType is actually active.

Validation

Confirm every LDAP strategy named in authSettings has its own complete stanza -- a missing one silently drops that strategy from the query order.
Set userBaseFilter/groupBaseFilter on any LDAP directory with a large number of entries -- unfiltered searches can be materially slower.
Verify idpCertPath is set whenever signedAssertion = true -- it's required in that case, not merely recommended.
Understand lockRoleToFullDN's locking behaviour before relying on a CN-based [roleMap_SAML] entry -- the first successful login locks that CN to one specific DN, and subsequent logins with the same CN but a different DN are rejected until an admin adds the new DN explicitly.
Disable any existing SSO configuration (e.g. SAML) before enabling Duo MFA for the first time -- it requires local auth to already be in effect.
Set replicateCertificates = true (SAML and RSA both default to this) on a search head cluster, or manually replicate IdP/RSA certificates to every member -- otherwise verification fails on members that don't have them.
Keep oauth2_restricted_endpoints at its default private/loopback-blocking ranges unless there's a specific, reviewed reason to narrow it -- it exists specifically to prevent SSRF via a malicious JWKS URL.

← Back to References

References / Splunk platform configuration

Deployment Client Configuration

deploymentclient.conf is the client-side counterpart to serverclass.conf -- it points a Splunk instance at a Deployment Server and controls how it polls for and installs app content. The client always initiates: it phones home on an interval rather than the server pushing to it unprompted. Backs the Splunk Taxonomy's Deployment Client object (SOT-08.04.02).

Definition

Two stanzas: [deployment-client] (required at minimum to enable a deployment client at all) and [target-broker:deploymentServer] (the actual server connection). Splunk's own guidance is explicit: never edit the shipped default file directly -- place overrides in etc/system/local/deploymentclient.conf instead, and restart to apply them.

File locations

Configuration file: deploymentclient.conf.

Scope	Path
System	`$SPLUNK_HOME/etc/system/{default,local}/deploymentclient.conf`
App	`$SPLUNK_HOME/etc/apps/<app_name>/{default,local}/deploymentclient.conf`

Lives on the deployment client, never on the deployment server itself.

Identity & content location

Setting	Description
`disabled`	Whether this instance acts as a deployment client at all. Default `false`.
`clientName`	A name the Deployment Server can filter `serverclass.conf` whitelist/blacklist entries on, independent of (and taking precedence over) IP/DNS-based matching. Default `deploymentClient`.
`workingDir`	Temp folder used while downloading apps/content. Default `$SPLUNK_HOME/var/run`.
`repositoryLocation`	Where downloaded content is installed locally. For the instance to actually recognize an app, it must land at `$SPLUNK_HOME/etc/apps` -- content deployed anywhere else on the client is silently not run. Default `$SPLUNK_HOME/etc/apps`.
`serverRepositoryLocationPolicy`	Whether the client trusts a `repositoryLocation` value supplied by the server: `acceptSplunkHome` (default -- only if it begins with `$SPLUNK_HOME`), `acceptAlways`, or `rejectAlways` (always use the local file's own value instead).

Endpoint & delivery policy

Setting	Description
`endpoint`	The HTTP (or `file:`) URL content downloads from. Default `$deploymentServerUri$/services/streams/deployment?name=$serverClassName$:$appName$`, where $deploymentServerUri$ resolves from `[target-broker:deploymentServer]`'s `targetUri`.
`serverEndpointPolicy`	`acceptAlways` (default -- use whatever endpoint the server supplies) or `rejectAlways` (always use the locally-defined `endpoint` instead, e.g. to pull from a different HTTP server or a filesystem mount).

Phone-home & handshake timing

Setting	Description
`phoneHomeIntervalInSecs`	How often (fractional seconds allowed) the client checks for new content. Default 60.
`handshakeRetryIntervalInSecs`	Handshake retry frequency -- useful for tuning the initial connection rate against a new server. Default `phoneHomeIntervalInSecs` / 5.
`handshakeReplySubscriptionRetry`	Handshake attempts before re-subscribing to the handshake channel, if the handshake can't complete. Default 10.
`appEventsResyncIntervalInSecs`	How often the client reports its app state back to the server. Default 10× `phoneHomeIntervalInSecs`.
`reloadDSOnAppInstall`	Reloads this instance's own Deployment Server after an app install -- only relevant for a hierarchical deployment server (an instance that is simultaneously a client and a server). Default `false`.

Avoid hierarchical deployment servers. The spec explicitly warns against this topology "unless you have no other alternative," citing unresolved field-reported problems.

SSL/TLS & connection settings

Setting	Description
`[target-broker:deploymentServer] targetUri`	The Deployment Server's URI, e.g. `https://deploymentserver.example.com:8089`.
`sslVersions` / `sslVerifyServerCert` / `sslVerifyServerName` / `caCertFile` / `sslCommonNameToCheck` / `sslAltNameToCheck` / `cipherSuite` / `ecdhCurves`	Standard SSL/TLS settings, each falling back to the equivalent `server.conf` `[sslConfig]` value when unset (except `sslVerifyServerName`, which defaults `false` here regardless, and `cipherSuite`/`ecdhCurves`, which have no default at all rather than inheriting).
`connect_timeout` / `send_timeout` / `recv_timeout`	Connection, send, and receive timeouts in seconds against the Deployment Server -- settable in both `[deployment-client]` and (identically) `[target-broker:deploymentServer]`. All default 60.

Example

# Reject the server-supplied content location; always install
# to the standard client-side apps directory
[deployment-client]
serverRepositoryLocationPolicy = rejectAlways
repositoryLocation = $SPLUNK_HOME/etc/apps
phoneHomeIntervalInSecs = 30
appEventsResyncIntervalInSecs = 86400
connect_timeout = 60
send_timeout = 60
recv_timeout = 60

[target-broker:deploymentServer]
targetUri = https://deploymentserver.splunk.buttercupgames.com:8089

A deployment client that always installs to the standard $SPLUNK_HOME/etc/apps location regardless of what the server suggests, checks for new content every 30 seconds, but only reports its own app state back to the server once a day -- and applies a uniform 60-second timeout across connect/send/receive.

Validation

Confirm repositoryLocation resolves to $SPLUNK_HOME/etc/apps one way or another -- content installed elsewhere on the client is silently never recognized or run.
Set both serverRepositoryLocationPolicy and repositoryLocation explicitly if the server's own app repository lives somewhere non-standard -- don't rely on the client-side default alone to reconcile a mismatch.
Avoid reloadDSOnAppInstall = true and hierarchical deployment server topologies generally, per Splunk's own guidance, unless there is genuinely no alternative.
Never edit the shipped default deploymentclient.conf directly -- place all overrides in etc/system/local/.
Confirm [target-broker:deploymentServer] targetUri is set -- without it, the client has no server to phone home to at all.

← Back to References

References / Splunk platform configuration

Event Types Configuration

eventtypes.conf defines named search-based event classifications, applied to every event in a result set at search time rather than run as an independent search. Event types created in Splunk Web land automatically in a user's own local conf file. Backs the Splunk Taxonomy's Event Type object (SOT-02.04.01).

Definition

Each [<$EVENTTYPE>] stanza names one event type. A stanza name containing a field name wrapped in %...% (e.g. [cisco-%code%]) is a template -- the field's actual value is substituted per-event, so an event with code=432 is labeled cisco-432.

Event types created through Splunk Web are written to that user's own $SPLUNK_HOME/etc/users/$user/$app/local/eventtypes.conf, not the app-level file.

File locations

Configuration file: eventtypes.conf.

Scope	Path
System	`$SPLUNK_HOME/etc/system/{default,local}/eventtypes.conf`
App	`$SPLUNK_HOME/etc/apps/<app_name>/{default,local}/eventtypes.conf`
User	`$SPLUNK_HOME/etc/users/<user_name>/<app_name>/local/eventtypes.conf`

Settings

Setting	Description
`disabled`	`1` to disable the event type.
`search`	The search terms defining this event type, e.g. `error OR warn`. Cannot include a pipe operator, a subsearch, or a reference to a report -- the last is a best practice as much as a rule, since a report can later be edited (e.g. to add transforming commands) in a way that breaks it as an event type definition; define the event type with the same search string instead of referencing the report.
`priority`	1 (highest) through 10 (lowest) -- determines display order when multiple event types match the same event.
`description`	Optional human-readable description.
`tags`	Deprecated -- see `tags.conf` instead.
`color`	One of a fixed palette: `none`, `et_blue`, `et_green`, `et_magenta`, `et_orange`, `et_purple`, `et_red`, `et_sky`, `et_teal`, `et_yellow`.

Example

[error]
search = error OR fatal

[cisco-%code%]
search = cisco

A straightforward event type matching either keyword, and a template event type that labels each matching event cisco-<code> using that event's own code field value.

Validation

Don't reference a report's name in search -- copy the report's search string directly instead, so a later edit to the report can't silently break the event type.
Confirm search has no pipe operator or subsearch -- both are unsupported for event type definitions.
Use tags.conf for tagging, not the deprecated tags setting here.
Set priority deliberately when multiple event types are expected to match the same events -- the default ordering may not reflect the intended display priority.

← Back to References

References / Splunk platform configuration

Fields Configuration

fields.conf declares field-level behaviour that extraction itself doesn't cover: multivalue tokenization, and whether a field's value is expected to appear in the raw event text (affecting how a search for that field expands into an index-time term search). Backs the Splunk Taxonomy's Field Settings object (SOT-02.03.03).

Definition

A stanza is either a plain [<field name>] (letters, digits, ., :, _ only; can't start with a digit or underscore) or a metadata-scoped wildcard, [<sourcetype|source|host>::<metadata_name>::<wildcard expression>], which applies its settings to every indexed field matching the wildcard within that one metadata value -- for example [sourcetype::splunk_resource_usage::data*] scopes to every field starting with data on that one sourcetype.

Sourcetype-scoped wildcard expressions are processed before sourcetype aliases/expansions, and require indexed_fields_expansion = t in limits.conf to take effect. Best applied to a metadata value that is entirely one structured format (e.g. all-JSON) -- not to a sourcetype mixing structured and unstructured data.

File locations

Configuration file: fields.conf.

Scope	Path
System	`$SPLUNK_HOME/etc/system/{default,local}/fields.conf`
App	`$SPLUNK_HOME/etc/apps/<app_name>/{default,local}/fields.conf`
User	`$SPLUNK_HOME/etc/users/<user_name>/<app_name>/local/fields.conf`

Settings

Setting	Description
`TOKENIZER`	Regex whose first capturing group's matches become the field's multiple values -- e.g. splitting a combined value into a genuine multivalue field. Used by `search`/`where`, the async search API's summary/XML output, and `top`/`timeline`/`stats`. Ignored if `INDEXED = true` -- tokenization of indexed fields isn't supported. Empty means single-valued only.
`INDEXED`	Whether the field is created at index time (`true`) or search time (`false`, the default and the case for most fields).
`INDEXED_VALUE`	Only meaningful when `INDEXED = false`. Whether the field's value literally appears in the raw event text: `true` (default) expands a `key=value` search into `value AND key=value` since the value itself is indexed; `false` means the value isn't in the raw text at all. Also accepts a `sed`-style substitution (`s/foo/bar/g`) or a `<VALUE>`-token substitution string (e.g. `source::<VALUE>`) to transform the searched value; if the resulting string starts with `[`, it's interpreted as a raw Splunk LISPY expression instead.

Example

[To]
TOKENIZER = (\w[\w\.\-]*@[\w\.\-]*\w)

[From]
TOKENIZER = (\w[\w\.\-]*@[\w\.\-]*\w)

[sourcetype::splunk_resource_usage::data*]
INDEXED = True

[source::.../introspection/disk_objects.log(.\d+)?::data.*]
INDEXED = True
INDEXED_VALUE = False

Email-header fields tokenized into multivalue address lists, plus two metadata-scoped wildcard stanzas marking every data*-prefixed field on a given sourcetype/source as indexed -- with the source-scoped one additionally declaring those values aren't present in the raw text.

Validation

Don't set TOKENIZER on a field that also has INDEXED = true -- it's silently ignored there.
Confirm indexed_fields_expansion = t is set in limits.conf before relying on a metadata-scoped wildcard stanza -- without it, the wildcard expression has no effect.
Scope a metadata wildcard stanza to a genuinely homogeneous metadata value (all-JSON, all-CSV) -- applying it to a mixed structured/unstructured sourcetype is explicitly discouraged.
Set INDEXED_VALUE only when INDEXED = false -- it has no defined effect otherwise.
Avoid creating an indexed field whose name collides with a search-time-extracted field of the same name.

← Back to References

References / Splunk platform configuration

Saved Searches Configuration

savedsearches.conf stores every report and alert as a named stanza -- the same file backs both; the only difference is whether trigger-condition and alert.* settings are present. It's one of the largest Splunk config files by setting count, spanning scheduling, workload management, five distinct alert-action namespaces, dispatch/durable-search options, auto-summarization, alert suppression, and an extensive UI display-formatting namespace. Backs the Splunk Taxonomy's Report, Alert, and Summary Index objects.

Definition

Each [<stanza name>] is one saved search, identified by that name. A Report has no trigger condition or alert action configured; an Alert is the exact same stanza shape with alert.*/trigger settings added.

Setting	Description
`disabled`	Prevents the search from running (including on its schedule) without deleting the stanza. Default `false`.
`search`	The SPL string itself. Can include macro searches. Multi-line search strings have limitations, e.g. incompatibility with `\|savedsearch`.
`dispatchAs`	`owner` (default -- always runs with the owner's privileges) or `user` (runs with the requesting user's privileges when dispatched via the REST endpoint) -- only applies to shared searches. `force_saved_search_dispatch_as_user` in `limits.conf` can force `user` regardless. Setting this to `user` needs care -- it runs with the requester's own privileges.
`federated_providers`	Comma-separated, wildcard-capable list of `federated.conf` provider names this search runs against (deactivated/deleted providers are skipped).

File locations

Configuration file: savedsearches.conf.

Scope	Path
System	`$SPLUNK_HOME/etc/system/{default,local}/savedsearches.conf`
App	`$SPLUNK_HOME/etc/apps/<app_name>/{default,local}/savedsearches.conf`
User	`$SPLUNK_HOME/etc/users/<user_name>/<app_name>/local/savedsearches.conf`

Scheduling & workload management

Setting	Description
`enableSched` / `cron_schedule`	Enables cron-based scheduling and defines the cron string (no month/day names supported). The deprecated `schedule` setting predates this.
`allow_skew`	Randomly distributes a search's actual run time within a window (percentage or duration, e.g. `50%`/`5m`) to avoid every scheduled search launching at the exact same instant. The skew amount is stable across edits. Default 0 (no skew).
`allow_data_time_skew`	Whether the search's own time range shifts by the calculated skew too (prioritizing low latency over an exact time range) rather than just the launch time shifting. Set `false` for durable searches. Default `false`.
`max_concurrent`	Max concurrent instances of this search the scheduler allows. Default 1.
`realtime_schedule`	`true` (default): next-run time is based on current time, and the scheduler may skip missed periods to stay current. `false` (continuous scheduling): based on the last run time, never skips periods but can fall behind -- required when summary indexing.
`schedule_priority`	`default`/`higher`/`highest`, honored only if the owner has the `edit_search_schedule_priority` capability. Mutually exclusive with a non-zero `schedule_window` (priority wins if both are set and the capability is present). Overuse impedes scheduler fairness -- reserve for mission-critical searches.
`schedule_window`	Minutes of flexibility in start time (must be shorter than the search's own period; not recommended for every-minute searches), or `auto` to let the scheduler compute it. Default 0 for owners with `edit_search_schedule_window`, otherwise forced to `auto`.
`schedule_as`	`auto` (default, may or may not use parallel reduce processing per `parallelreduce`'s `autoAppliedPercentage`), `classic` (never), or `prjob` (always).
`workload_pool`	Names a pool from `workload_pools.conf` the search process launches into; falls back to `default_pool` if workload management is enabled but this is unset.

Notification & alert triggering

Setting	Description
`counttype` / `relation` / `quantity`	Together form a sentence: `<counttype> <relation> <quantity>`, e.g. "number of events greater than 10". `counttype` is events/hosts/sources/custom/`always` (default) -- don't set `relation`/`quantity` when using `always`.
`alert_condition`	A conditional search evaluated against the saved search's own results; a non-empty result list from this triggers the alert.
`action.<name>` / `action.<name>.<parameter>`	Enables an action (`email`/`populate_lookup`/`script`/`summary_index`, or any custom action defined in `alert_actions.conf`) and overrides one of its parameters for this search only.

Alert actions

Five built-in action namespaces, each with settings specific to that action; all default to disabled (action.<name> = false) unless noted. Unset per-action settings fall back to alert_actions.conf's defaults.

Email setting	Description
`action.email.to`	Required (not in `alert_actions.conf`). Comma-delimited recipient list.
`action.email.from` / `.subject` / `.mailserver`	Sender address, subject line, and MTA server -- fall back to `alert_actions.conf`'s `[email]` stanza.
`action.email.maxresults`	Caps results included by any inclusion method (inline/CSV/PDF). Default 10000, also globally bounded by `alert_actions.conf`'s `[email] maxresults`.
`action.email.include.results_link` / `.search` / `.trigger` / `.trigger_time` / `.view_link`	What context is included in the notification: a results link (default on), the query itself, trigger condition, trigger time, and a saved-search edit link (default on) -- the rest default off.
`action.email.inline` / `.sendcsv` / `.sendpdf` / `.sendpng` / `.sendresults` / `.allow_empty_attachment`	Whether results/PNG appear inline in the email body, and whether CSV/PDF/PNG attachments (or a raw results attachment) are sent even when the triggering search returned nothing.

Action	Settings
Script	`action.script.filename` -- a script in `$SPLUNK_HOME/bin/scripts/`; non-shell scripts need a `#!` interpreter line.
Lookup	`action.lookup.filename` (CSV lookup name or KV Store collection, no path) and `action.lookup.append` (append vs. overwrite, default `false`).
Summary index	`action.summary_index._name` (target index, default `summary`), `._type` (`event`/`metric`), `._metric_dims` (numeric fields to treat as dimensions rather than measures), `.inline` (run as part of the scheduled search, default `true`, only considered when `counttype = always`), `.<field>` (a static field/value pair added to every summarized event), `.force_realtime_schedule` (overrides the summary-indexing default of continuous scheduling -- caution: can create gaps in summary data).
Populate lookup	`action.populate_lookup.dest` -- either a non-KV-Store `transforms.conf` lookup name, or a `.csv` path relative to `$SPLUNK_HOME` under an existing `etc/system/lookups/` or `etc/apps/<app>/lookups/` directory.

Dispatch search options

Setting	Description
`dispatch.ttl`	Artifact time-to-live in seconds, or `<n>p` for a multiple of the search's own execution period. If an action fires, the largest of the action-level TTLs applies instead. An alert needs at least `1p` (or `2p` if using "rises by"/"drops by"). Default `2p`.
`dispatch.max_count` / `.max_time` / `.buckets`	Result-count and time-based finalization limits, and max timeline buckets. Defaults 500000 / 0 (unlimited) / 0.
`dispatch.lookups`	Enables/disables lookups for this search. Default 1 (enabled).
`dispatch.earliest_time` / `.latest_time` / `.index_earliest` / `.index_latest` / `.time_format`	Search-time and index-time range bounds (relative or absolute, using `time_format` for absolute values, default `%FT%T.%Q%:z`).
`dispatch.spawn_process`	Whether a new search process is spawned. Default 1 (true).
`dispatch.auto_cancel` / `.auto_pause`	Seconds of inactivity before the job is auto-cancelled/auto-paused (0 = never). Auto-pause only fires once per job; unpausing doesn't re-arm it.
`dispatch.reduce_freq`	How often (in result chunks) the MapReduce reduce phase runs. Default 10.
`dispatch.allow_partial_results`	Whether the job can return partial results if a search peer fails, rather than failing outright. Default `true`.
`dispatch.rt_backfill` / `.indexedRealtime` / `.indexedRealtimeOffset` / `.indexedRealtimeMinSpan` / `.rt_maximum_span`	Real-time search tuning -- window backfill on schedule, indexed-realtime mode and its disk-sync delay/minimum span, and how far behind realtime a search is allowed to fall before catching up. Each overrides the equivalent `limits.conf` `[realtime]` setting for this one job.
`dispatch.sample_ratio`	1-in-N sampling ratio (e.g. 500 = 1/500 chance per event). Default 1 (no sampling).
`dispatch.rate_limit_retry`	SHC only. Re-runs the job if it failed due to peer-side request throttling; overrides `allow_partial_results` when triggered. Default `false`.
`restart_on_searchpeer_add`	Restarts a scheduler-managed real-time search when a peer becomes available (new or recovered). Default 1 (true).
`run_on_startup` / `run_n_times`	Runs the search as soon as possible on startup/relevant edit (useful for lookup-populating or dashboard-feeding searches) rather than waiting for the next scheduled time, and/or limits total lifetime runs before requiring a restart to resume (0 = infinite).

Durable search & auto-summarization

A durable search retries/backfills to guard against lost results during rolling restarts or network issues; not usable for real-time or ad hoc searches.

Setting	Description
`durable.track_time_type`	`_time` (original event timestamp), `_indextime` (indexing time -- metric-data searches must use this), or unset/`none` (not durable).
`durable.lag_time`	Seconds of delay tolerance for late-arriving/indexed events. ~60s is typical for `_indextime` tracking. Default 0.
`durable.backfill_type`	`time_whole` (one combined backfill job spanning all failures -- streaming searches only), `time_interval` (one backfill job per failure, works for both streaming and non-streaming), or `auto` (default, picks based on whether the search is streaming).
`durable.max_backfill_intervals`	Max cron intervals eligible for backfill (0 = unlimited). Default 0.

auto_summarize (default false) turns on scheduler-managed automatic summarization, tuned by auto_summarize.timespan (comma-delimited granularities, e.g. 1h,1d; no 1w support), .cron_schedule, .dispatch.<arg> overrides, .suspend_period (default 24h, pauses summarization deemed unhelpful), .max_summary_size/.max_summary_ratio (helpfulness test thresholds, defaults 5MB / 0.1), .max_disabled_buckets (default 2), .max_time (default 3600s), .max_concurrent (default 1), and .workload_pool. .command, .hash, and .normalized_hash are auto-generated -- don't hand-edit .command unless you're certain what you're doing.

Alert suppression, severity & tracking

Setting	Description
`alert.suppress` / `.period` / `.fields`	Enables per-condition throttling for a suppression window, and (required if digest mode is off) which result fields distinguish independently-suppressible alerts.
`alert.suppress.group_name`	Groups multiple similar alerts (same owner only) so that one firing suppresses the whole group for that trigger's `alert.suppress.period` -- only the triggering alert's actions actually run.
`alert.severity`	1 (debug) through 6 (fatal). Default 3 (warn).
`alert.expires`	How long the alert remains on the Triggered Alerts page; cleared on restart regardless. Only honored when `alert.track = true`. Default 24h.
`alert.digest_mode`	Whether actions apply to the whole result set (`true`, default) or per individual result (`false`).
`alert.track`	`auto` (default -- tracks based on each action's own tracking setting, skips always-triggering searches), `true`, or `false`.
`alert.display_view` / `.managedBy`	UI view for emailed per-result alert links (falls back to `request.ui_dispatch_app`, then "search"), and which feature/component created the alert.

UI & display formatting

Setting	Description
`displayview` / `vsid`	Default UI view to load results in, and the matching `viewstates.conf` view-state ID.
`is_visible`	Whether the search appears in an app's visible saved-search list (it's always reachable from the "Searches, reports, and alerts" page regardless). Default `true`.
`description`	Human-readable description.
`request.ui_dispatch_app` / `.ui_dispatch_view`	App/view context the Splunk UI dispatches this search in.

A large display.* namespace (general, events, statistics, visualizations, table-format) controls how results render in Splunk Web -- well over a hundred individual leaf settings. These are almost always written by Splunk Web itself when a user customizes a report's look, rather than hand-authored. The groups:

Group	Representative settings
`display.general.*`	`type` (events/statistics/visualizations), `enablePreview`, `timeRangePicker.show`.
`display.events.*`	`type` (raw/list/table), `fields`, `maxLines`, per-format `drilldown`/`wrap` settings.
`display.statistics.*`	`drilldown`, `totalsRow`/`percentagesRow`, plus the nested `display.statistics.format.<index>.*` per-column color/number formatting rules (scale type, color palette, precision, units).
`display.visualizations.*`	`type` (charting/singlevalue/mapping/custom) and then an entire sub-namespace per visualization type -- chart type/stacking/axes/legend for charting, range colors/trend indicators for singlevalue, tile/marker/choropleth layer settings for mapping, trellis layout settings shared across types.
`display.page.search.*`	`mode` (UI-only, has no effect on scheduler-dispatched runs), `timeline.format`/`.scale`, `tab`.

Other & deprecated settings

Setting	Description
`embed.enabled`	Allows guestpass access to this search's existing scheduled artifacts (never dispatches a live search) -- requires a generated token, a non-disabled/non-real-time/non-alert scheduled search, and view permission.
`defer_scheduled_searchable_idxc` / `skip_scheduled_realtime_idxc`	Whether a continuous saved search defers, or a continuous saved real-time search skips, during an indexer cluster's searchable rolling restart/upgrade -- leaving either disabled risks partial results. Both default `false`.
`precalculate_required_fields_for_alerts` / `calculate_alert_required_fields_in_search`	Performance-tuning flags for how alert condition/action required fields are calculated (main scheduler process vs. within the search process itself); the spec advises not changing either without Splunk Support guidance.

Deprecated setting	Use instead
`sendresults`	`action.email.sendresults`
`action_rss`	`action.rss`
`action_email`	`action.email` / `action.email.to`
`role` / `userid`	Saved search permissions (ACL) instead
`query`	`search`
`nextrun` / `qualifiedSearch`	No longer used -- computed internally at runtime

All settings

Every stanza and setting in savedsearches.conf.spec from Splunk Enterprise 10.4.2: 275 settings across 1 stanza. Descriptions use the spec's own wording -- the first line shows here and More opens the rest. The Default column is filled only where the spec gives a Default: line.

`[<stanza name>]`

Create a unique stanza name for each saved search.
Follow the stanza name with any number of the following settings.
If you do not specify a setting, Splunk software uses the default.

Setting	Description	Default
`[<stanza name>]` `disabled`	`<boolean>`Disable your search by setting 'disabled=true'. More You cannot run a disabled search. This setting is typically used to prevent a scheduled search from running on its schedule, without deleting the stanza for the search in the savedsearches.conf file.	false
`[<stanza name>]` `search`	`<string>`The actual search string for the saved search. More For example, 'search = index::sampledata http NOT 500'. Your search can include macro searches for substitution. To learn more about creating a macro search, search the documentation for "macro search." Multi-line search strings currently have some limitations. For example, use with the search command '\|savedsearch' does not currently work with multi-line search strings.	No default
`[<stanza name>]` `dispatchAs`	`[user\|owner]`Determines which user a saved search is dispatched as, when a search is dispatched using the "saved/searches/{name}/dispatch" endpoint. More This setting only applies to shared saved searches. When dispatched as "user", the search is run as if the requesting user owned the search. When dispatched as "owner", the search is run as if the owner of the search dispatched the search, no matter which user requested it. If the 'force_saved_search_dispatch_as_user' setting in limits.conf is set to "true", then the 'dispatchAs' setting is reset to "user" while the saved search is dispatching. CAUTION: Be cautious when setting a report to run as "User", as the search will run using the privileges of the user that initiates the search.	owner
`[<stanza name>]` `federated_providers`	`<string>`Specifies a comma-separated list of federated provider names that this saved search is run against. More Supports exact provider names as well as the use of wildcards () to capture groups of providers. Examples: "rsh1,rsh2" or "rsh,provider_test" or "*_prod" Provider names must match those configured in 'federated.conf' for this Splunk platform deployment. NOTE: Searches are not run against deactivated or deleted federated providers.	No default
`[<stanza name>]` `enableSched`	`[0 \| 1]`Specifies whether or not to run the search on a schedule. More The only acceptable values for this setting are 0 and 1. Set this to 1 (true) to run your search on a schedule.	0
`[<stanza name>]` `cron_schedule`	`<cron string>`The cron schedule that is used to run this search. More For example: /5 * * * causes the search to run every 5 minutes. You can use standard cron notation to define your scheduled search interval. In particular, cron can accept this type of notation: 00,20,40 * * * , which runs the search every hour at hh:00, hh:20, hh:40. A cron of 03,23,43 * * * runs the search every hour at hh:03, hh:23, hh:43. To reduce system load, schedule your searches so that they are staggered over time. Running all of the saved searches every 20 minutes (*/20) means all of the searches would launch at hh:00 (20, 40) and might slow your system every 20 minutes. The Splunk cron implementation does not currently support names of months or days.	No default
`[<stanza name>]` `schedule`	`<cron-style string>`This setting is DEPRECATED as of version 4.0. More For more information, see the pre-4.0 spec file. Use 'cron_schedule' to define your scheduled search interval.
`[<stanza name>]` `allow_skew`	`<percentage>\|<duration-specifier>`Lets the search scheduler randomly distribute scheduled searches more evenly over the scheduled time periods. More When set to non-zero for searches with the following cron_schedule values, the search scheduler randomly "skews" the second, minute, and hour that the search actually runs on: * * * * Every minute. /M * * * Every M minutes (M > 0). 0 * * * * Every hour. 0 /H * * Every H hours (H > 0). 0 0 * * * Every day (at midnight). When set to non-zero for a search that has any other 'cron_schedule' setting, the search scheduler can only randomly skew the second that the search runs on. The amount of skew for a specific search remains constant between edits of the search. To specify a percentage: Use an integer value followed by the percent '%' symbol. This specifies the maximum amount of time to skew, as a percentage of the scheduled search period. To specify a duration: Use <integer><timescale> to specify a maximum duration. Supported units are: m, min, minute, mins, minutes h, hr, hour, hrs, hours d, day, days The <timescale> is required. Skew examples: 100% (For an every-5-minute search = 5 minutes maximum) 50% (For an every-1-minute search = 30 seconds maximum) 5m = 5 minutes maximum 1h = 1 hour maximum A value of 0 does not allow a skew to occur.	0
`[<stanza name>]` `allow_data_time_skew`	`<boolean>`Whether or not a search can dynamically adjust its time range based on the amount of allowed time skew, as configured by the 'allow_skew' setting. More A value of "true" means that a search can dynamically adjust its time range for the amount of allowed time skew. It offsets its earliest and latest time modifiers by the amount of time that 'allow_skew' calculates. A value of "false" or no value means that the search does not adjust its time range for the allowed time skew. Use this setting to prioritize low search latencies over specifying an explicit search time range. For example, if this setting has a value of "true", a search with a scheduled time of 1:30am and with 'earliest=-5m' and 'latest=now' as search parameters, and a calculated skew of 3 minutes results in a search that runs in the time range of 1:28am to 1:33am. A value of "false" means that the search would search in the time range of 1:25am to 1:30am, but would only be eligible for dispatch at 1:33am, which causes lag in receiving search results. For durable searches, give this setting a value of "false".	false
`[<stanza name>]` `max_concurrent`	`<unsigned integer>`The maximum number of concurrent instances of this search that the scheduler is allowed to run.	1
`[<stanza name>]` `realtime_schedule`	`<boolean>`Controls the way the scheduler computes the next run time of a scheduled search. More When set to 'true', the scheduler determines the next scheduled search run time based on the current time. NOTE: When set to 'true', the scheduler might skip some execution periods to make sure that the scheduler is executing the searches that are running over the most recent time range. When set to 'false', the scheduler determines the next scheduled search run time based on the last run time for the search. This is called continuous scheduling. NOTE: When set to 'false', the scheduler never skips scheduled execution periods. However, the execution of the saved search might fall behind depending on the scheduler's load. Use continuous scheduling whenever you enable the 'summary index' option. The scheduler tries to run searches that have 'realtime_schedule' set to true before it runs searches that have continuous scheduling (realtime_schedule = false).	true
`[<stanza name>]` `schedule_priority`	`[default \| higher \| highest]`Raises the scheduling priority of a search: More When set to "default", this setting specifies that there is no increase to the scheduling priority. When set to "higher", this setting specifies that the scheduling priority is higher than other searches of the same scheduling tier. While there are four tiers of priority for scheduled searches, only the following are affected by this setting: 1. Real-Time-Scheduled (realtime_schedule=1). 2. Continuous-Scheduled (realtime_schedule=0). When set to "highest", this setting specifies that the scheduling priority is higher than other searches regardless of scheduling tier. However, real-time-scheduled searches with 'schedule_priority = highest' always have priority over continuous scheduled searches with 'schedule_priority = highest'. The high-to-low order is: RTSS(H) > CSS(H) > RTSS(h) > RTSS(d) > CSS(h) > CSS(d) Where: RTSS = real-time-scheduled search CSS = continuous-scheduled search d = default h = higher H = highest The scheduler honors a non-default priority only when the search owner has the 'edit_search_schedule_priority' capability. A non-default priority is mutually exclusive with a non-zero 'schedule_window' (see below). If a user specifies both for a scheduled search, the scheduler honors the priority only. However, if a user specifies both settings for a search, but the search owner does not have the 'edit_search_scheduler_priority' capability, then the scheduler ignores the priority setting and honors the 'schedule_window'. CAUTION: Having too many searches with a non-default priority impedes the ability of the scheduler to minimize search starvation. Use this setting only for mission-critical searches.	default
`[<stanza name>]` `schedule_window`	`<unsigned integer> \| auto`When 'schedule_window' is non-zero, it indicates to the scheduler that the search does not require a precise start time. This gives the scheduler greater flexibility when it prioritizes searches. More When 'schedule_window' is set to an integer greater than 0, it specifies the "window" of time (in minutes) that a search may start within. The 'schedule_window' must be shorter than the period of the search. Schedule windows are not recommended for searches that run every minute. When set to 0, there is no schedule window. The scheduler starts the search as close to its scheduled time as possible. When set to "auto," the scheduler calculates the 'schedule_window' value automatically. For more information about this calculation, see the search scheduler documentation. A non-zero 'schedule_window' is mutually exclusive with a non-default 'schedule_priority'. See 'schedule_priority' for details.	0 for searches that are owned by users with the 'edit_search_schedule_window' capability. For these searches, this value can be changed.; auto for searches that are owned by users that do not have the 'edit_search_schedule_window' capability. For these searches, this setting cannot be changed.
`[<stanza name>]` `schedule_as`	`[auto\|classic\|prjob]`Specifies whether a scheduled search should use parallel reduce search processing each time it runs. More When set to 'auto', the Splunk software determines automatically whether this scheduled search should use parallel reduce search processing, each time it runs. This means it might not use parallel reduce processing some of the time or all of the time. For details, please check 'autoAppliedPercentage' in 'parallelreduce' stanza. When set to 'classic', the Splunk software is forced to NOT use parallel reduce search processing for this scheduled search, each time it runs. When set to 'prjob', the Splunk software is forced to use parallel reduce search processing for this scheduled search, each time it runs.	'auto'
`[<stanza name>]` `workload_pool`	`<name of workload pool>`Specifies the name of the workload pool to be used by this search. More There are multiple workload pools defined in the workload_pools.conf file. Each workload pool has different resource limits associated with it, for example, CPU, Memory, etc. The search process of this search is launched into the 'workload_pool' specified above. The 'workload_pool' used should be defined in the workload_pools.conf file. If workload management is enabled and a explicit 'workload_pool' is not specified, the 'default_pool' defined in the workload_pools.conf file is used.
`[<stanza name>]` `counttype`	`number of events \| number of hosts \| number of sources \| custom \| always`Set the type of count for alerting. More Used with the 'relation' and 'quantity' settings. NOTE: If you specify "always," do not set 'relation' or 'quantity'.	always
`[<stanza name>]` `relation`	`greater than \| less than \| equal to \| not equal to \| drops by \| rises by`Specifies how to compare against 'counttype'.	empty string
`[<stanza name>]` `quantity`	`<integer>`Specifies a value for the 'counttype' and 'relation' settings, to determine the condition under which an alert is triggered by a saved search. More Think of it as a sentence constructed like this: <counttype> <relation> <quantity>. For example, "number of events [is] greater than 10" sends an alert when the count of events is larger than by 10. For example, "number of events drops by 10%" sends an alert when the count of events drops by 10%.	empty string
`[<stanza name>]` `alert_condition`	`<search string>`Contains a conditional search that is evaluated against the results of the saved search. Alerts are triggered if the specified search yields a non-empty search result list.	empty string
`[<stanza name>]` `action.<action_name>`	`<boolean>`Indicates whether the action is enabled for a particular saved search. More The 'action_name' can be: email \| populate_lookup \| script \| summary_index For more about your defined alert actions see the alert_actions.conf file.	empty string
`[<stanza name>]` `action.<action_name>.<parameter>`	`<value>`Overrides an action's <parameter> as defined in the alert_actions.conf file, with a new <value> for this saved search only.	empty string
`[<stanza name>]` `action.email`	`<boolean>`Specifies whether the email action is enabled for this search.	false
`[<stanza name>]` `action.email.to`	`<email list>`REQUIRED. This setting is not defined in the alert_actions.conf file. More Set a comma-delimited list of recipient email addresses. NOTE: When configured in Splunk Web, the following email settings are written to this conf file only if their values differ from the settings in the alert_actions.conf file.	empty string
`[<stanza name>]` `action.email.from`	`<email address>`Set an email address to use as the sender's address.	splunk@<LOCALHOST> (or the 'from' setting in the alert_actions.conf file)
`[<stanza name>]` `action.email.subject`	`<string>`Set the subject of the email delivered to recipients.	SplunkAlert-<savedsearchname> (or the 'subject' setting in the alert_actions.conf file)
`[<stanza name>]` `action.email.mailserver`	`<string>`Set the address of the MTA server to be used to send the emails.	<LOCALHOST> (or the 'mailserver' setting in alert_actions.conf file)
`[<stanza name>]` `action.email.maxresults`	`<integer>`Set the maximum number of results to email. More Any alert-level results threshold greater than this number is capped at this level. This value affects all methods of result inclusion by email alert: inline, CSV, and PDF. NOTE: This setting is affected globally by the 'maxresults' setting in the [email] stanza of the alert_actions.conf file.	10000
`[<stanza name>]` `action.email.include.results_link`	`[1\|0]`Specify whether to include a link to search results in the alert notification email.	1 (true) (or the 'include.result.link' setting in the alert_actions.conf file)
`[<stanza name>]` `action.email.include.search`	`[1\|0]`Specify whether to include the query whose results triggered the email.	0 (false) (or the 'include.search' setting in the alert_actions.conf file)
`[<stanza name>]` `action.email.include.trigger`	`[1\|0]`Specify whether to include the alert trigger condition.	0 (false) (or the 'include.trigger' setting in the alert_actions.conf file)
`[<stanza name>]` `action.email.include.trigger_time`	`[1\|0]`Specify whether to include the alert trigger time.	0 (false) or whatever is set in the alert_actions.conf file
`[<stanza name>]` `action.email.include.view_link`	`[1\|0]`Specify whether to include saved search title and a link for editing the saved search.	1 (true) (or the 'include.view_link' setting in the alert_actions.conf file)
`[<stanza name>]` `action.email.inline`	`[1\|0]`Specify whether to include search results or PNG exports in the body of the alert notification email.	0 (false) (or the 'inline' setting in the alert_actions.conf file)
`[<stanza name>]` `action.email.sendcsv`	`[1\|0]`Specify whether to send results as a CSV file.	0 (or the 'sendcsv' setting in the alert_actions.conf file)
`[<stanza name>]` `action.email.allow_empty_attachment`	`<boolean>`Specifies whether the Splunk software attaches a CSV or PDF file to an alert email even when the triggering alert search does not have results. More Use this setting to override for specific alerts the default set for email alert actions in 'alert_actions.conf'.	set by the 'allow_empty_attachment' setting in 'alert_actions.conf'
`[<stanza name>]` `action.email.sendpdf`	`[1\|0]`Specify whether to send results as a PDF file.	0 (false) (or the 'sendpdf' setting in the alert_actions.conf file)
`[<stanza name>]` `action.email.sendpng`	`[1\|0]`Specify whether to send Dashboard Studio results as a PNG file.	0 (false) (or the 'sendpng' setting in the alert_actions.conf file)
`[<stanza name>]` `action.email.sendresults`	`[1\|0]`Specify whether to include search results in the alert notification email.	0 (false) (or the 'sendresults' setting in the alert_actions.conf file)
`[<stanza name>]` `action.script`	`<boolean>`Specifies whether the script action is enabled for this search.	false
`[<stanza name>]` `action.script.filename`	`<script filename>`The filename, with no path, of the shell script to run. More The script should be located in: $SPLUNK_HOME/bin/scripts/ For system shell scripts on UNIX, or .bat or .cmd file on Windows, there are no further requirements. For other types of scripts, the first line should begin with a #! marker, followed by a path to the interpreter that will run the script. Example: #!C:\Python27\python.exe	empty string
`[<stanza name>]` `action.lookup`	`<boolean>`Specifies whether the lookup action is enabled for this search.	false
`[<stanza name>]` `action.lookup.filename`	`<lookup name>`Specifies either the name of a CSV lookup file or a KV store collection to write search results to. More For CSV lookup files, enter the file name only. Do not enter the file path.
`[<stanza name>]` `action.lookup.append`	`<boolean>`Specifies whether to append results to the lookup file defined for the 'action.lookup.filename' setting.	false
`[<stanza name>]` `action.summary_index`	`<boolean>`Specifies whether the summary index action is enabled for this search.	false.
`[<stanza name>]` `action.summary_index._name`	`<index>`Specifies the name of the summary index where the results of the scheduled search are saved.	summary
`[<stanza name>]` `action.summary_index._type`	`[event \| metric]`Specifies the data type of the summary index where the Splunk software saves the results of the scheduled search.	event
`[<stanza name>]` `action.summary_index._metric_dims`	`<comma-delimited-field-list>`Optional More Identify one or more fields with numeric values that the Splunk software should convert into dimensions during the summary indexing process. The Splunk software converts all fields with numeric values that are not in this list into measures. If you provide a list of fields, separate them with commas.	empty string
`[<stanza name>]` `action.summary_index.inline`	`<boolean>`Specify whether to run the summary indexing action as part of the scheduled search. More NOTE: This option is considered only if the summary index action is enabled and is always run (in other words, if 'counttype = always').	1 (true)
`[<stanza name>]` `action.summary_index.<field>`	`<string>`Specifies a field/value pair to add to every event that gets summary indexed by this search. More You can define multiple field/value pairs for a single summary index search.
`[<stanza name>]` `action.summary_index.force_realtime_schedule`	`<boolean>`By default 'realtime_schedule' is false for a report configured for summary indexing. Set this attribute to 'true' or '1' to override the default behavior. More CAUTION: Setting this to 'true' can cause gaps in summary data as a realtime_schedule search is skipped if search concurrency limits are violated.	0 (false)
`[<stanza name>]` `action.populate_lookup`	`<boolean>`Specifies whether the lookup population action is enabled for this search.	false
`[<stanza name>]` `action.populate_lookup.dest`	`<string>`Can be one of the following two options: More A lookup name from transforms.conf. The lookup name cannot be associated with KV store. A path to a lookup .csv file that the search results should be copied to, relative to $SPLUNK_HOME. NOTE: This path must point to a .csv file in either of the following directories: etc/system/lookups/ etc/apps/<app-name>/lookups NOTE: the destination directories of the above files must already exist.	empty string
`[<stanza name>]` `run_on_startup`	`<boolean>`Specifies whether this search runs when the Splunk platform starts or any edit that changes search related arguments happen. This includes search and dispatch.* arguments. More If set to "true", the search is run as soon as possible during startup or after edit. Otherwise the search is run at the next scheduled time. Set 'run_on_startup' to "true" for scheduled searches that populate lookup tables or generate artifacts used by dashboards.	false
`[<stanza name>]` `run_n_times`	`<unsigned integer>`Runs this search exactly the specified number of times. The search is not run again until the Splunk platform is restarted.	0 (infinite)
`[<stanza name>]` `dispatch.ttl`	`<integer>[p]`Indicates the time to live (ttl), in seconds, for the search job artifacts produced by the scheduled search, if no actions are triggered. More If the integer is followed by the letter 'p', the ttl is calculated as a multiple of the execution period for the scheduled search. For example, if the search is scheduled to run hourly and ttl is set to 2p, the ttl of the artifacts is set to 2 hours. If an action is triggered for the scheduled search, the ttl changes to the ttl for the action. If multiple actions are triggered, the action with the largest ttl is applied to the artifacts. To set the ttl for an action, refer to the alert_actions.conf.spec file. If the scheduled search is configured as an alert, the alert must have a minimum ttl of 1p. At all times an alert must have an artifact accessible within its cron schedule. If the alert has "rises by" or "drops by" in its trigger condition, the alert must have a minimum ttl of 2p to make this trigger condition possible. The "rises by" and "drops by" trigger condition elements require that at any given point in time the most recent two artifacts of the alert are available. For more information on the ttl for a search, see the limits.conf.spec file [search] stanza ttl setting.	2p
`[<stanza name>]` `dispatch.buckets`	`<integer>`The maximum number of timeline buckets.	0
`[<stanza name>]` `dispatch.max_count`	`<integer>`The maximum number of results before finalizing the search.	500000
`[<stanza name>]` `dispatch.max_time`	`<integer>`The maximum amount of time, in seconds, before finalizing the search.	0
`[<stanza name>]` `dispatch.lookups`	`1\| 0`Enables or disables lookups for this search. More Specify 1 to enable, 0 to disable.	1
`[<stanza name>]` `dispatch.earliest_time`	`<time-str>`Specifies the earliest time for this search. Can be a relative or absolute time. More If this value is an absolute time, use the 'dispatch.time_format' setting to format the value.	empty string
`[<stanza name>]` `dispatch.latest_time`	`<time-str>`Specifies the latest time for this saved search. Can be a relative or absolute time. More If this value is an absolute time, use the 'dispatch.time_format' setting to format the value.	empty string
`[<stanza name>]` `dispatch.index_earliest`	`<time-str>`Specifies the earliest index time for this search. Can be a relative or absolute time. More If this value is an absolute time, use the 'dispatch.time_format' setting to format the value.	empty string
`[<stanza name>]` `dispatch.index_latest`	`<time-str>`Specifies the latest index time for this saved search. Can be a relative or absolute time. More If this value is an absolute time, use the 'dispatch.time_format' setting to format the value.	empty string
`[<stanza name>]` `dispatch.time_format`	`<time format str>`Defines the time format that is used to specify the earliest and latest time.	%FT%T.%Q%:z
`[<stanza name>]` `dispatch.spawn_process`	`1 \| 0`Specifies whether a new search process is started when this saved search is run.	1 (true)
`[<stanza name>]` `dispatch.auto_cancel`	`<integer>`Specifies the amount of inactive time, in seconds, after which the job is automatically canceled. More 0 means to never auto-cancel the job.	0
`[<stanza name>]` `dispatch.auto_pause`	`<integer>`Specifies the amount of inactive time, in seconds, after which the search job is automatically paused. More 0 means to never auto-pause the job. To restart a paused search job, specify 'unpause' as an action to POST search/jobs/{search_id}/control. auto_pause only goes into effect once. Unpausing after auto_pause does not put auto_pause into effect again.	0
`[<stanza name>]` `dispatch.reduce_freq`	`<integer>`Specifies the frequency, in number of intermediary results chunks, that the MapReduce reduce phase should run on the accumulated map values.	10
`[<stanza name>]` `dispatch.allow_partial_results`	`<boolean>`Specifies whether the search job can proceed to provide partial results if a search peer fails. When set to false, the search job fails if a search peer providing results for the search job fails.	true
`[<stanza name>]` `dispatch.rt_backfill`	`<boolean>`Specifies whether to do real-time window backfilling for scheduled real-time searches.	false
`[<stanza name>]` `dispatch.indexedRealtime`	`<boolean>`Specifies whether to use 'indexed-realtime' mode when doing real-time searches. More Overrides the setting in the limits.conf file for the 'indexed_realtime_use_by_default' setting in the [realtime] stanza. This setting applies to each job. See the [realtime] stanza in the limits.conf.spec file for more information.	The value for 'indexed_realtime_use_by_default' in the limits.conf file.
`[<stanza name>]` `dispatch.indexedRealtimeOffset`	`<integer>`Controls the number of seconds to wait for disk flushes to finish. More Overrides the setting in the limits.conf file for the 'indexed_realtime_disk_sync_delay' setting in the [realtime] stanza. This setting applies to each job. See the [realtime] stanza in the limits.conf.spec file for more information.	The value for 'indexed_realtime_disk_sync_delay' in the limits.conf file.
`[<stanza name>]` `dispatch.indexedRealtimeMinSpan`	`<integer>`Minimum seconds to wait between component index searches. More Overrides the setting in the limits.conf file for the 'indexed_realtime_default_span' setting in the [realtime] stanza. This setting applies to each job. See the [realtime] stanza in the limits.conf.spec file for more information.	The value for 'indexed_realtime_default_span' in the limits.conf file.
`[<stanza name>]` `dispatch.rt_maximum_span`	`<integer>`The max seconds allowed to search data which falls behind realtime. More Use this setting to set a limit, after which events are not longer considered for the result set. The search catches back up to the specified delay from realtime and uses the default span. Overrides the setting in the limits.conf file for the 'indexed_realtime_maximum_span' setting in the [realtime] stanza. This setting applies to each job. See the [realtime] stanza in the limits.conf.spec file for more information.	the value for 'indexed_realtime_maximum_span' in the limits.conf file.
`[<stanza name>]` `dispatch.sample_ratio`	`<integer>`The integer value used to calculate the sample ratio. The formula is 1 / <integer>. More The sample ratio specifies the likelihood of any event being included in the sample. For example, if sample_ratio = 500, each event has a 1/500 chance of being included in the sample result set.	1
`[<stanza name>]` `dispatch.rate_limit_retry`	`<boolean>`Specifies whether the search job will be re-run in case of failure caused by search requests throttling on remote peers. More Currently this setting only applies when used in SHC. Overrides value of 'allow_partial_results'. Does not apply to real time searches.	false
`[<stanza name>]` `restart_on_searchpeer_add`	`1 \| 0`Specifies whether to restart a real-time search managed by the scheduler when a search peer becomes available for this saved search. More NOTE: The peer can be a newly added peer or a peer that has been down and has become available.	1 (true)
`[<stanza name>]` `durable.track_time_type`	`[ _time \| _indextime \| none ]`Indicates that a scheduled search is durable and specifies how the search tracks events. More A durable search is a search that tries to ensure the delivery of all results, even when the search process is slowed or stopped by runtime issues like rolling restarts, network bottlenecks, and even downed servers. When durable searches encounter search errors that they cannot recover from, they do not return any results. When a durable scheduled search job fails in this manner, the Splunk software reschedules a new run of the durable search over the same period of time to backfill the missing data. See the 'durable.backfill_type' and 'durable.max_backfill_intervals' settings for more information. This setting cannot be applied to real-time and ad hoc searches. For searches of metric data, only the '_time' setting is available. If set to '_time', the durable search tracks each event by its original timestamp. If set to '_indextime', the durable search tracks each event by the the time that it is indexed. If this setting is set to 'none' or not set, the search is not durable.	Not set
`[<stanza name>]` `durable.lag_time`	`<unsigned integer>`Specifies the search time delay, in seconds, that a durable search uses to catch events that are ingested or indexed late. More This setting takes effect only for searches that have a setting for 'durable.track_time_type'. In most cases, '60' (1 minute) is a good 'lag_time' for durable searches that track '_indextime'. If your durable search tracks '_time', check to see how long the events for the search are delayed at indexing before setting a 'lag_time' for it.	0
`[<stanza name>]` `durable.backfill_type`	`[ auto \| time_interval \| time_whole ]`Specifies how the Splunk software backfills the lost search results of failed scheduled search jobs. More When set to 'time_whole', the Splunk software schedules a single backfill search job with a time range that spans the combined time ranges of all failed scheduled search jobs. The 'time_whole' setting can be applied only to searches that are streaming, where the results are raw events without additional aggregation. When set to 'time_interval', the Splunk software schedules multiple backfill search jobs, one for each failed scheduled search job. The backfill jobs have time ranges that match those of the failed jobs. The 'time_interval' setting can be applied to both streaming and non-streaming searches, When set to 'auto', the Splunk software decides the backfill type by checking whether the search is streaming or not. If the search is streaming, the Splunk software uses the 'time_whole' backfill type. Otherwise, it uses the 'time_interval' backfill type. This setting takes effect only for searches that have a setting for 'durable.track_time_type'.	auto
`[<stanza name>]` `durable.max_backfill_intervals`	`<unsigned integer>`Specifies the maximum number of cron intervals (previous scheduled search jobs) that the Splunk software can attempt to backfill for this search, when those jobs have incomplete events. More This setting takes effect only for searches that have a setting for 'durable.track_time_type'. For example, if 'durable.max_backfill_intervals' is set to '100', the maximum backfill time range for a search is 100 multiplied by the cron interval for the scheduled search.	0 (unlimited)
`[<stanza name>]` `auto_summarize`	`<boolean>`Specifies if the scheduler should ensure that the data for this search is automatically summarized.	false
`[<stanza name>]` `auto_summarize.command`	`<string>`A search template to use to construct the auto summarization for this search. More DO NOT change this setting unless you know what you're doing.
`[<stanza name>]` `auto_summarize.timespan`	`<time-specifier> (, <time-specifier>)*`Comma-delimited list of time ranges that each summarized chunk should span. This comprises the list of available granularity levels for which summaries would be available. For example, a timechart over the last month whose granularity is at the day level should set this to "1d". If you need the same data summarized at the hour level because you need to have weekly charts then use: "1h,1d". More This setting does not support "1w" timespans.
`[<stanza name>]` `auto_summarize.cron_schedule`	`<cron-string>`Cron schedule to use to probe or generate the summaries for this search.
`[<stanza name>]` `auto_summarize.dispatch.<arg-name>`	`<string>`Any dispatch.* options that need to be overridden when running the summary search.
`[<stanza name>]` `auto_summarize.suspend_period`	`<time-specifier>`The amount of time to suspend summarization of this search if the summarization is deemed unhelpful.	24h
`[<stanza name>]` `auto_summarize.max_summary_size`	`<unsigned integer>`The minimum summary size when to start testing its helpfulness.	52428800 (5MB)
`[<stanza name>]` `auto_summarize.max_summary_ratio`	`<positive decimal>`The maximum ratio of summary_size/bucket_size when to stop summarization and deem it unhelpful for a bucket. More NOTE: The test is only performed if the summary size is larger than the 'auto_summarize.max_summary_size' setting.	0.1
`[<stanza name>]` `auto_summarize.max_disabled_buckets`	`<unsigned integer>`The maximum number of buckets with the suspended summarization before the summarization search is completely stopped and the summarization of the search is suspended for the value specified in the 'auto_summarize.suspend_period' setting.	2
`[<stanza name>]` `auto_summarize.max_time`	`<unsigned integer>`The maximum amount of time that the summary search is allowed to run. More NOTE: This is an approximate time and the summarize search will be stopped at clean bucket boundaries.	3600
`[<stanza name>]` `auto_summarize.hash`	`<string>`An auto generated setting.
`[<stanza name>]` `auto_summarize.normalized_hash`	`<string>`An auto generated setting.
`[<stanza name>]` `auto_summarize.max_concurrent`	`<unsigned integer>`The maximum number of concurrent instances of this auto summarizing search, that the scheduler is allowed to run.	1
`[<stanza name>]` `auto_summarize.workload_pool`	`<name of workload pool>`Sets the name of the workload pool that is used by this auto summarization. More There are multiple workload pools defined in workload_pools.conf. Each workload pool has different resource limits associated with it, for example, CPU, Memory, etc. The search process of this auto summarization are launched into the workload_pool specified above. The workload_pool used should be defined in workload_pools.conf. If workload management is enabled and an explicit workload_pool is not specified, the workload rules defined in workload_rules.conf try to put the search into a proper pool as specified in some rule. If there is no rule defined for this search, the default_pool defined in workload_pools.conf is used.
`[<stanza name>]` `alert.suppress`	`<boolean>`Specifies whether alert suppression is enabled for this scheduled search.	false
`[<stanza name>]` `alert.suppress.period`	`<time-specifier>`Sets the suppression period. Use [number][time-unit] to specify a time. More For example: 60 = 60 seconds, 1m = 1 minute, 1h = 60 minutes. Honored if and only if 'alert.suppress = 1'.	empty string
`[<stanza name>]` `alert.suppress.fields`	`<comma-delimited-field-list>`List of fields to use when suppressing per-result alerts. This field must be specified if the digest mode is disabled and suppression is enabled.	empty string.
`[<stanza name>]` `alert.suppress.group_name`	`<string>`Optional. More Use this setting to define an alert suppression group for a set of alerts that are running over the same or very similar datasets. Do this to avoid getting multiple triggered alert notifications for the same data. All alerts with the same 'alert.suppress.group_name' value are in the same alert suppression group, as long as they are all owned by the same user. Alerts belonging to different users cannot be included in the same suppression group, even if they all have the same 'group_name'. When an alert within an alert suppression group is triggered, all of the alerts in the group are suppressed for a period of time defined by the 'alert.suppress.period' of the triggered alert. The triggered alert performs its alert actions, if it has any. The other alerts in the group do not perform their alert actions. For example, say you have an alert suppression group with five alerts. Each of these alerts has a different 'alert.suppress.period' and a different alert action. If one alert from the group with an 'alert.suppress.period' of 5m and an email alert action is triggered, all of the alerts in the group are suppressed for 5m. However, only one alert action happens: the email for the triggering alert.	empty string.
`[<stanza name>]` `alert.severity`	`<integer>`Sets the alert severity level. More Valid values are: 1-debug, 2-info, 3-warn, 4-error, 5-severe, 6-fatal	3
`[<stanza name>]` `alert.expires`	`<time-specifier>`Sets the period of time to show the alert on the Triggered Alerts page. More Use [number][time-unit] to specify a time. For example: 60s = 60 seconds, 1m = 1 minute, 1h = 60 minutes = 1 hour etc This setting is only honored when 'alert.track = true' (when the "Add to Triggered Alerts" action is selected for the alert in Splunk Web). This property is valid until splunkd restarts. Restart clears the listing of triggered alerts.	24h
`[<stanza name>]` `alert.digest_mode`	`<boolean>`Whether or not the Splunk platform applies the alert actions to the entire result set or to each individual result. More A value of "true" means that the Splunk platform applies the alert actions to the entire result set. A value of "false" means that the Splunk platform applies the alert actions to each individual result.	true
`[<stanza name>]` `alert.track`	`<boolean> \| auto`Specifies whether to track the actions triggered by this scheduled search. More auto - determine whether to track or not based on the tracking setting of each action, do not track scheduled searches that always trigger actions. true - force alert tracking. false - disable alert tracking for this search.	auto
`[<stanza name>]` `alert.display_view`	`<string>`Name of the UI view where the emailed link for each result alerts should point to. More If not specified, the value of the 'request.ui_dispatch_app' setting is used. If the 'request.ui_dispatch_app' setting is missing then "search" is used.	empty string
`[<stanza name>]` `alert.managedBy`	`<string>`Specifies the feature or component that created the alert.	empty string
`[<stanza name>]` `displayview`	`<string>`Defines the default UI view name (not label) in which to load the results. More Accessibility is subject to the user having sufficient permissions.	empty string
`[<stanza name>]` `vsid`	`<string>`Defines the view state ID associated with the UI view listed in the 'displayview' setting. More Must match up to a stanza in the viewstates.conf file.	empty string
`[<stanza name>]` `is_visible`	`<boolean>`Specifies whether this saved search should be listed in the visible saved search list within apps. More Saved searches are still visible when accessing the "Searches, reports, and alerts" page in Splunk Web.	true
`[<stanza name>]` `description`	`<string>`Human-readable description of this saved search.	empty string
`[<stanza name>]` `request.ui_dispatch_app`	`<string>`Specifies a field used by Splunk UI to denote the app that this search should be dispatched in.	empty string
`[<stanza name>]` `request.ui_dispatch_view`	`<string>`Specifies a field used by Splunk UI to denote the view this search should be displayed in.	empty string
`[<stanza name>]` `display.general.enablePreview`	`[0 \| 1]`No description in the spec.
`[<stanza name>]` `display.general.type`	`[events\|statistics\|visualizations]`No description in the spec.
`[<stanza name>]` `display.general.timeRangePicker.show`	`[0 \| 1]`No description in the spec.
`[<stanza name>]` `display.general.migratedFromViewState`	`[0 \| 1]`No description in the spec.
`[<stanza name>]` `display.general.locale`	`<string>`No description in the spec.
`[<stanza name>]` `display.events.fields`	`[<string>(, <string>)*]`No description in the spec.
`[<stanza name>]` `display.events.type`	`[raw\|list\|table]`No description in the spec.
`[<stanza name>]` `display.events.rowNumbers`	`[0 \| 1]`No description in the spec.
`[<stanza name>]` `display.events.maxLines`	`<integer>`No description in the spec.
`[<stanza name>]` `display.events.raw.drilldown`	`[inner\|outer\|full\|none]`No description in the spec.
`[<stanza name>]` `display.events.list.drilldown`	`[inner\|outer\|full\|none]`No description in the spec.
`[<stanza name>]` `display.events.list.wrap`	`[0 \| 1]`No description in the spec.
`[<stanza name>]` `display.events.table.drilldown`	`[0 \| 1]`No description in the spec.
`[<stanza name>]` `display.events.table.wrap`	`[0 \| 1]`No description in the spec.
`[<stanza name>]` `display.statistics.rowNumbers`	`[0 \| 1]`No description in the spec.
`[<stanza name>]` `display.statistics.wrap`	`[0 \| 1]`No description in the spec.
`[<stanza name>]` `display.statistics.overlay`	`[none\|heatmap\|highlow]`No description in the spec.
`[<stanza name>]` `display.statistics.drilldown`	`[row\|cell\|none]`No description in the spec.
`[<stanza name>]` `display.statistics.totalsRow`	`[0 \| 1]`No description in the spec.
`[<stanza name>]` `display.statistics.percentagesRow`	`[0 \| 1]`No description in the spec.
`[<stanza name>]` `display.statistics.show`	`[0 \| 1]`No description in the spec.
`[<stanza name>]` `display.visualizations.trellis.enabled`	`[0 \| 1]`No description in the spec.
`[<stanza name>]` `display.visualizations.trellis.scales.shared`	`[0 \| 1]`No description in the spec.
`[<stanza name>]` `display.visualizations.trellis.size`	`[small\|medium\|large]`No description in the spec.
`[<stanza name>]` `display.visualizations.trellis.splitBy`	`<string>`No description in the spec.
`[<stanza name>]` `display.visualizations.show`	`[0 \| 1]`No description in the spec.
`[<stanza name>]` `display.visualizations.type`	`[charting\|singlevalue\|mapping\|custom]`No description in the spec.
`[<stanza name>]` `display.visualizations.chartHeight`	`<integer>`No description in the spec.
`[<stanza name>]` `display.visualizations.charting.chart`	`[line\|area\|column\|bar\|pie\|scatter\|bubble\|radialGauge\|fillerGauge\|markerGauge]`No description in the spec.
`[<stanza name>]` `display.visualizations.charting.chart.stackMode`	`[default\|stacked\|stacked100]`No description in the spec.
`[<stanza name>]` `display.visualizations.charting.chart.nullValueMode`	`[gaps\|zero\|connect]`No description in the spec.
`[<stanza name>]` `display.visualizations.charting.chart.overlayFields`	`<string>`No description in the spec.
`[<stanza name>]` `display.visualizations.charting.drilldown`	`[all\|none]`No description in the spec.
`[<stanza name>]` `display.visualizations.charting.chart.style`	`[minimal\|shiny]`No description in the spec.
`[<stanza name>]` `display.visualizations.charting.layout.splitSeries`	`[0 \| 1]`No description in the spec.
`[<stanza name>]` `display.visualizations.charting.layout.splitSeries.allowIndependentYRanges`	`[0 \| 1]`No description in the spec.
`[<stanza name>]` `display.visualizations.charting.legend.mode`	`[standard\|seriesCompare]`No description in the spec.
`[<stanza name>]` `display.visualizations.charting.legend.placement`	`[right\|bottom\|top\|left\|none]`No description in the spec.
`[<stanza name>]` `display.visualizations.charting.legend.labelStyle.overflowMode`	`[ellipsisEnd\|ellipsisMiddle\|ellipsisStart]`No description in the spec.
`[<stanza name>]` `display.visualizations.charting.axisTitleX.text`	`<string>`No description in the spec.
`[<stanza name>]` `display.visualizations.charting.axisTitleY.text`	`<string>`No description in the spec.
`[<stanza name>]` `display.visualizations.charting.axisTitleY2.text`	`<string>`No description in the spec.
`[<stanza name>]` `display.visualizations.charting.axisTitleX.visibility`	`[visible\|collapsed]`No description in the spec.
`[<stanza name>]` `display.visualizations.charting.axisTitleY.visibility`	`[visible\|collapsed]`No description in the spec.
`[<stanza name>]` `display.visualizations.charting.axisTitleY2.visibility`	`[visible\|collapsed]`No description in the spec.
`[<stanza name>]` `display.visualizations.charting.axisX.scale`	`linear\|log`No description in the spec.
`[<stanza name>]` `display.visualizations.charting.axisY.scale`	`linear\|log`No description in the spec.
`[<stanza name>]` `display.visualizations.charting.axisY2.scale`	`linear\|log\|inherit`No description in the spec.
`[<stanza name>]` `display.visualizations.charting.axisX.abbreviation`	`none\|auto`No description in the spec.
`[<stanza name>]` `display.visualizations.charting.axisY.abbreviation`	`none\|auto`No description in the spec.
`[<stanza name>]` `display.visualizations.charting.axisY2.abbreviation`	`none\|auto`No description in the spec.
`[<stanza name>]` `display.visualizations.charting.axisLabelsX.majorLabelStyle.overflowMode`	`[ellipsisMiddle\|ellipsisNone]`No description in the spec.
`[<stanza name>]` `display.visualizations.charting.axisLabelsX.majorLabelStyle.rotation`	`[-90\|-45\|0\|45\|90]`No description in the spec.
`[<stanza name>]` `display.visualizations.charting.axisLabelsX.majorUnit`	`<decimal> \| auto`No description in the spec.
`[<stanza name>]` `display.visualizations.charting.axisLabelsY.majorUnit`	`<decimal> \| auto`No description in the spec.
`[<stanza name>]` `display.visualizations.charting.axisLabelsY2.majorUnit`	`<decimal> \| auto`No description in the spec.
`[<stanza name>]` `display.visualizations.charting.axisX.minimumNumber`	`<decimal> \| auto`No description in the spec.
`[<stanza name>]` `display.visualizations.charting.axisY.minimumNumber`	`<decimal> \| auto`No description in the spec.
`[<stanza name>]` `display.visualizations.charting.axisY2.minimumNumber`	`<decimal> \| auto`No description in the spec.
`[<stanza name>]` `display.visualizations.charting.axisX.maximumNumber`	`<decimal> \| auto`No description in the spec.
`[<stanza name>]` `display.visualizations.charting.axisY.maximumNumber`	`<decimal> \| auto`No description in the spec.
`[<stanza name>]` `display.visualizations.charting.axisY2.maximumNumber`	`<decimal> \| auto`No description in the spec.
`[<stanza name>]` `display.visualizations.charting.axisY2.enabled`	`[0 \| 1]`No description in the spec.
`[<stanza name>]` `display.visualizations.charting.chart.sliceCollapsingThreshold`	`<decimal>`No description in the spec.
`[<stanza name>]` `display.visualizations.charting.chart.showDataLabels`	`[all\|none\|minmax]`No description in the spec.
`[<stanza name>]` `display.visualizations.charting.gaugeColors`	`[<hex>(, <hex>)*]`No description in the spec.
`[<stanza name>]` `display.visualizations.charting.chart.rangeValues`	`[<string>(, <string>)*]`No description in the spec.
`[<stanza name>]` `display.visualizations.charting.chart.bubbleMaximumSize`	`<integer>`No description in the spec.
`[<stanza name>]` `display.visualizations.charting.chart.bubbleMinimumSize`	`<integer>`No description in the spec.
`[<stanza name>]` `display.visualizations.charting.chart.bubbleSizeBy`	`[area\|diameter]`No description in the spec.
`[<stanza name>]` `display.visualizations.charting.fieldColors`	`<string>`No description in the spec.
`[<stanza name>]` `display.visualizations.charting.fieldDashStyles`	`<string>`No description in the spec.
`[<stanza name>]` `display.visualizations.charting.lineWidth`	`<decimal>`No description in the spec.
`[<stanza name>]` `display.visualizations.custom.drilldown`	`[all\|none]`No description in the spec.
`[<stanza name>]` `display.visualizations.custom.height`	`<integer>`No description in the spec.
`[<stanza name>]` `display.visualizations.custom.type`	`<string>`No description in the spec.
`[<stanza name>]` `display.visualizations.singlevalueHeight`	`<integer>`No description in the spec.
`[<stanza name>]` `display.visualizations.singlevalue.beforeLabel`	`<string>`No description in the spec.
`[<stanza name>]` `display.visualizations.singlevalue.afterLabel`	`<string>`No description in the spec.
`[<stanza name>]` `display.visualizations.singlevalue.underLabel`	`<string>`No description in the spec.
`[<stanza name>]` `display.visualizations.singlevalue.unit`	`<string>`No description in the spec.
`[<stanza name>]` `display.visualizations.singlevalue.unitPosition`	`[before\|after]`No description in the spec.
`[<stanza name>]` `display.visualizations.singlevalue.drilldown`	`[all\|none]`No description in the spec.
`[<stanza name>]` `display.visualizations.singlevalue.colorMode`	`[block\|none]`No description in the spec.
`[<stanza name>]` `display.visualizations.singlevalue.rangeValues`	`[<string>(, <string>)*]`No description in the spec.
`[<stanza name>]` `display.visualizations.singlevalue.rangeColors`	`[<string>(, <string>)*]`No description in the spec.
`[<stanza name>]` `display.visualizations.singlevalue.trendInterval`	`<string>`No description in the spec.
`[<stanza name>]` `display.visualizations.singlevalue.trendColorInterpretation`	`[standard\|inverse]`No description in the spec.
`[<stanza name>]` `display.visualizations.singlevalue.showTrendIndicator`	`[0 \| 1]`No description in the spec.
`[<stanza name>]` `display.visualizations.singlevalue.showSparkline`	`[0 \| 1]`No description in the spec.
`[<stanza name>]` `display.visualizations.singlevalue.trendDisplayMode`	`[percent\|absolute]`No description in the spec.
`[<stanza name>]` `display.visualizations.singlevalue.colorBy`	`[value\|trend]`No description in the spec.
`[<stanza name>]` `display.visualizations.singlevalue.useColors`	`[0 \| 1]`No description in the spec.
`[<stanza name>]` `display.visualizations.singlevalue.numberPrecision`	`[0\|0.0\|0.00\|0.000\|0.0000]`No description in the spec.
`[<stanza name>]` `display.visualizations.singlevalue.useThousandSeparators`	`[0 \| 1]`No description in the spec.
`[<stanza name>]` `display.visualizations.mapHeight`	`<integer>`No description in the spec.
`[<stanza name>]` `display.visualizations.mapping.type`	`[marker\|choropleth]`No description in the spec.
`[<stanza name>]` `display.visualizations.mapping.drilldown`	`[all\|none]`No description in the spec.
`[<stanza name>]` `display.visualizations.mapping.map.center`	`(<decimal>,<decimal>)`No description in the spec.
`[<stanza name>]` `display.visualizations.mapping.map.zoom`	`<integer>`No description in the spec.
`[<stanza name>]` `display.visualizations.mapping.map.scrollZoom`	`[0 \| 1]`No description in the spec.
`[<stanza name>]` `display.visualizations.mapping.map.panning`	`[0 \| 1]`No description in the spec.
`[<stanza name>]` `display.visualizations.mapping.choroplethLayer.colorMode`	`[auto\|sequential\|divergent\|categorical]`No description in the spec.
`[<stanza name>]` `display.visualizations.mapping.choroplethLayer.maximumColor`	`<string>`No description in the spec.
`[<stanza name>]` `display.visualizations.mapping.choroplethLayer.minimumColor`	`<string>`No description in the spec.
`[<stanza name>]` `display.visualizations.mapping.choroplethLayer.colorBins`	`<integer>`No description in the spec.
`[<stanza name>]` `display.visualizations.mapping.choroplethLayer.neutralPoint`	`<decimal>`No description in the spec.
`[<stanza name>]` `display.visualizations.mapping.choroplethLayer.shapeOpacity`	`<decimal>`No description in the spec.
`[<stanza name>]` `display.visualizations.mapping.choroplethLayer.showBorder`	`[0 \| 1]`No description in the spec.
`[<stanza name>]` `display.visualizations.mapping.markerLayer.markerOpacity`	`<decimal>`No description in the spec.
`[<stanza name>]` `display.visualizations.mapping.markerLayer.markerMinSize`	`<integer>`No description in the spec.
`[<stanza name>]` `display.visualizations.mapping.markerLayer.markerMaxSize`	`<integer>`No description in the spec.
`[<stanza name>]` `display.visualizations.mapping.legend.placement`	`[bottomright\|none]`No description in the spec.
`[<stanza name>]` `display.visualizations.mapping.data.maxClusters`	`<integer>`No description in the spec.
`[<stanza name>]` `display.visualizations.mapping.showTiles`	`[0 \| 1]`No description in the spec.
`[<stanza name>]` `display.visualizations.mapping.tileLayer.tileOpacity`	`<decimal>`No description in the spec.
`[<stanza name>]` `display.visualizations.mapping.tileLayer.url`	`<string>`No description in the spec.
`[<stanza name>]` `display.visualizations.mapping.tileLayer.minZoom`	`<integer>`No description in the spec.
`[<stanza name>]` `display.visualizations.mapping.tileLayer.maxZoom`	`<integer>`No description in the spec.
`[<stanza name>]` `display.page.search.patterns.sensitivity`	`<decimal>`No description in the spec.
`[<stanza name>]` `display.page.search.mode`	`[fast\|smart\|verbose]`This setting has no effect on saved search execution when dispatched by the scheduler. It only comes into effect when the search is opened in the UI and run manually.
`[<stanza name>]` `display.page.search.timeline.format`	`[hidden\|compact\|full]`No description in the spec.
`[<stanza name>]` `display.page.search.timeline.scale`	`[linear\|log]`No description in the spec.
`[<stanza name>]` `display.page.search.showFields`	`[0 \| 1]`No description in the spec.
`[<stanza name>]` `display.page.search.tab`	`[events\|statistics\|visualizations\|patterns]`No description in the spec.
`[<stanza name>]` `display.page.pivot.dataModel`	`<string>`No description in the spec.
`[<stanza name>]` `display.statistics.format.<index>`	`[color\|number]`No description in the spec.
`[<stanza name>]` `display.statistics.format.<index>.field`	`<string>`No description in the spec.
`[<stanza name>]` `display.statistics.format.<index>.fields`	`[<string>(, <string>)*]`No description in the spec.
`[<stanza name>]` `display.statistics.format.<index>.scale`	`[category\|linear\|log\|minMidMax\|sharedCategory\|threshold]`No description in the spec.
`[<stanza name>]` `display.statistics.format.<index>.colorPalette`	`[expression\|list\|map\|minMidMax\|sharedList]`No description in the spec.
`[<stanza name>]` `display.statistics.format.<index>.precision`	`<integer>`No description in the spec.
`[<stanza name>]` `display.statistics.format.<index>.useThousandSeparators`	`<boolean>`No description in the spec.
`[<stanza name>]` `display.statistics.format.<index>.unit`	`<string>`No description in the spec.
`[<stanza name>]` `display.statistics.format.<index>.unitPosition`	`[before\|after]`No description in the spec.
`[<stanza name>]` `display.statistics.format.<index>.scale.categories`	`[<string>(, <string>)*]`No description in the spec.
`[<stanza name>]` `display.statistics.format.<index>.scale.base`	`<integer>`No description in the spec.
`[<stanza name>]` `display.statistics.format.<index>.scale.minType`	`[number\|percent\|percentile]`No description in the spec.
`[<stanza name>]` `display.statistics.format.<index>.scale.minValue`	`<decimal>`No description in the spec.
`[<stanza name>]` `display.statistics.format.<index>.scale.midType`	`[number\|percent\|percentile]`No description in the spec.
`[<stanza name>]` `display.statistics.format.<index>.scale.midValue`	`<decimal>`No description in the spec.
`[<stanza name>]` `display.statistics.format.<index>.scale.maxType`	`[number\|percent\|percentile]`No description in the spec.
`[<stanza name>]` `display.statistics.format.<index>.scale.maxValue`	`<decimal>`No description in the spec.
`[<stanza name>]` `display.statistics.format.<index>.scale.thresholds`	`[<decimal>(, <decimal>)*]`No description in the spec.
`[<stanza name>]` `display.statistics.format.<index>.colorPalette.rule`	`<string>`No description in the spec.
`[<stanza name>]` `display.statistics.format.<index>.colorPalette.colors`	`[<hex>(, <hex>)*]`No description in the spec.
`[<stanza name>]` `display.statistics.format.<index>.colorPalette.interpolate`	`<boolean>`No description in the spec.
`[<stanza name>]` `display.statistics.format.<index>.colorPalette.colors`	`{<string>:<hex>(, <string>:<hex>)*}`No description in the spec.
`[<stanza name>]` `display.statistics.format.<index>.colorPalette.minColor`	`<hex>`No description in the spec.
`[<stanza name>]` `display.statistics.format.<index>.colorPalette.midColor`	`<hex>`No description in the spec.
`[<stanza name>]` `display.statistics.format.<index>.colorPalette.maxColor`	`<hex>`No description in the spec.
`[<stanza name>]` `embed.enabled`	`[0 \| 1]`Specifies whether a saved search is shared for access with a guestpass. More The only acceptable values for this setting are 0 and 1. Search artifacts of a search can be viewed using a guestpass only if: A token has been generated that is associated with this saved search. The token is associated with a particular user and app context. The user to whom the token belongs has permissions to view that search. The saved search has been scheduled and there are artifacts available. Only artifacts are available using guestpass. A search is never dispatched. The saved search is not disabled, it is scheduled. The saved search is not real-time. The saved search is not an alert.
`[<stanza name>]` `defer_scheduled_searchable_idxc`	`<boolean>`Specifies whether to defer a continuous saved search during a searchable rolling restart or searchable rolling upgrade of an indexer cluster. More Note: When disabled, a continuous saved search might return partial results.	false (disabled)
`[<stanza name>]` `skip_scheduled_realtime_idxc`	`<boolean>`Specifies whether to skip a continuous saved realtime search during a searchable rolling restart or searchable rolling upgrade of an indexer cluster. More Note: When set to false, a continuous saved search might return partial results.	false (does not skip)
`[<stanza name>]` `precalculate_required_fields_for_alerts`	`<boolean>`Whether or not the search scheduler pre-calculates the required fields from the alert condition search and uses the results in the main search. More Pre-calculation of the required fields occurs within the main splunkd process and can decrease search scheduler performance. A value of "true" means that the search scheduler pre-calculates the required fields from the alert condition search. A value of "false" means that the search scheduler does not pre-calculate the required fields. This might free up the search scheduler and improve performance, but can potentially increase the amount of work performed in the main search. NOTE: Do not change unless instructed to do so by Splunk Support.	true
`[<stanza name>]` `calculate_alert_required_fields_in_search`	`<boolean>`Whether or not alert search processes calculate the required fields of alert condition and alert action searches. More Alert search processes calculate the set of fields required by alert condition and alert actions and use the calculations to limit the set of fields that the main search generates, which improves search performance. A value of "true" means that alert searches perform calculations of alert condition search and alert action required fields within search processes. A value of "false" means that the search scheduler pre-calculates the required fields from the alert condition search, as described in the `precalculate_required_fields_for_alerts` setting. If this setting has a value of "true", it takes precedence over the 'precalculate_required_fields_for_alerts' setting.	false
`[<stanza name>]` `sendresults`	`<boolean>`Use the 'action.email.sendresult' setting.
`[<stanza name>]` `action_rss`	`<boolean>`Use the 'action.rss' setting.
`[<stanza name>]` `action_email`	`<string>`Use the 'action.email' and 'action.email.to' settings.
`[<stanza name>]` `role`	`<string>`See saved search permissions.
`[<stanza name>]` `userid`	`<string>`See saved search permissions.
`[<stanza name>]` `query`	`<string>`Use the 'search' setting.
`[<stanza name>]` `nextrun`	`<integer>`Not used anymore. The scheduler maintains this info internally.
`[<stanza name>]` `qualifiedSearch`	`<string>`Not used anymore. Splunk software computes this value during runtime.

Example

[Errors in the last 24 hours]
search = error OR failed OR severe OR ( sourcetype=access_* ( 404 OR 500 OR 503 ) )
dispatch.earliest_time = -1d

[stats with durable search]
search = index=_internal eps | stats avg(eps) as avg, max(eps) as max, min(eps) as min
dispatch.index_earliest = -30m
dispatch.index_latest   = now

durable.track_time_type   = _indextime
durable.lag_time          = 60
durable.backfill_type     = time_interval
durable.max_backfill_intervals = 100

An ad-hoc-style Report scoped to the last 24 hours (no schedule, no alert settings -- it's a plain Report until those are added), and a durable scheduled search that tracks events by index time with a 60-second lag tolerance, backfilling up to 100 missed cron intervals individually if a run fails partway through.

Validation

Don't reference a report by name from another saved search's search -- copy the search string directly, for the same reason event types shouldn't reference reports.
Set durable.lag_time based on real observed indexing delay for the source, not a guess -- too low a value defeats the purpose of durability.
Confirm dispatch.ttl is at least 1p (2p for "rises by"/"drops by" conditions) for any alert -- an artifact must remain available across the cron interval.
Set schedule_priority sparingly -- it's mutually exclusive with schedule_window, and overuse defeats the scheduler's fairness model.
Use alert.suppress.group_name deliberately when several alerts watch overlapping data, to avoid duplicate notifications for what is effectively the same triggering condition.
Treat the display.* namespace as Splunk-Web-generated in most cases -- hand-editing it risks drifting out of sync with what the UI itself would produce.
Migrate any deprecated setting (query, action_email, sendresults, etc.) found in an inherited conf file to its replacement.

← Back to References

References / Splunk platform configuration

Passwords Configuration

passwords.conf is one of the simplest Splunk config files, and unlike almost every other conf file, it has no shipped default at all -- it doesn't exist until the first credential is stored via the REST storage endpoint. Backs the Splunk Taxonomy's Stored Credential object (SOT-07.04.01).

Definition

This file is app-scoped and created the first time a credential is stored for that app via the storage/passwords REST endpoint (introduced in 6.3.0) -- never hand-created ahead of time. In a search head cluster, it replicates like any other app-local config file.

A restart is required to reload manual edits, though the normal and expected workflow is to manage credentials through the REST endpoint (or Splunk Web) rather than editing this file directly.

File locations

Configuration file: passwords.conf.

Scope	Path
System	`$SPLUNK_HOME/etc/system/local/passwords.conf`
App	`$SPLUNK_HOME/etc/apps/<app_name>/local/passwords.conf`

No shipped default, and no default/ copy either -- the file doesn't exist until the storage/passwords REST endpoint writes the first credential, always into local.

Stanza & setting

Line	Description
`[credential:<realm>:<username>:]`	One stanza per stored credential. `<realm>` is optional (can be empty, i.e. `[credential::<username>:]`) -- used to scope credentials sharing a username across different systems, e.g. separate DB Connect connections.
`password`	The credential value. Can be entered in clear text, but splunkd always encrypts it once saved -- the on-disk value is never left in plain text after that point.

Example

# Stored via the REST endpoint, not hand-authored:
# curl -k -u admin:changeme https://localhost:8089/servicesNS/nobody/search/storage/passwords \
#   -d name=user1 -d password=changeme2

[credential::testuser:]
password = changeme

The realistic way to populate this file is a POST to storage/passwords (or the equivalent Splunk Web credential-manager UI); the resulting stanza -- realm-less here, with the username as the only key -- is what ends up on disk.

Validation

Manage credentials through the storage/passwords REST endpoint or Splunk Web, not by hand-editing this file, even though clear-text entry is technically accepted.
Don't expect this file to exist ahead of the first credential being stored for an app -- there is no shipped default to fall back on.
Use the realm portion of the stanza name to disambiguate credentials that share a username across different target systems.
Remember a restart is required to pick up any manual edit to this file.

← Back to References

References / Splunk platform configuration

Workflow Actions Configuration

workflow_actions.conf defines clickable actions attached to a field value or an entire event in search results -- an external link, a follow-up search, or a custom GET/POST request -- each built using a field-value substitution syntax. Backs the Splunk Taxonomy's Workflow Action object (SOT-02.07.01).

Definition

Each [<name>] stanza is one workflow action. The shipped default lives in the Search app (etc/apps/search/default/), unlike most conf files' system-level default. A restart is required for manual edits, unless the change is made through Splunk Web's manager UI.

File locations

Configuration file: workflow_actions.conf.

Scope	Path
System	`$SPLUNK_HOME/etc/system/{default,local}/workflow_actions.conf`
App	`$SPLUNK_HOME/etc/apps/<app_name>/{default,local}/workflow_actions.conf`
User	`$SPLUNK_HOME/etc/users/<user_name>/<app_name>/local/workflow_actions.conf`

General settings

Setting	Description
`type` (required)	`link` or `search` -- selects which action-type settings apply. Missing entirely, the whole action is skipped.
`label` (required)	Text shown in the workflow action menu. Missing entirely, the action is skipped. Accepts field-value substitution.
`fields`	Comma/space-separated field names (globbable with ``, e.g. `host`) the event must have for the action to appear; governs which field menus it's offered in when `display_location` includes field menus. Default `*` (all field menus).
`eventtypes`	Comma/space-separated eventtype names (globbable) the event must match.
`display_location`	`field_menu`, `event_menu`, or `both` (default).
`disabled`	Turns the action off without removing the stanza. Default `False`.

Field-value substitution syntax

Several settings (label, link.uri, link.postargs, search.search_string) accept any field's value inserted via $<field name>$ , e.g. link.uri = http://www.google.com/search?q=$error_msg$.

Variable	Description
$@field_name$ / $@field_value$	The name/value of whichever field was actually clicked -- lets one action definition apply generically across many fields. Not available for event-menu actions, only field-menu ones.
$@sid$ / $@offset$	The current search job's ID, and the clicked event's offset within the result list.
$@namespace$	The app the search was run from.
$@latest_time$	The event's latest time, used to disambiguate similar events -- not always available for every field.

Link action type

Constructs a GET or POST request to an external resource. Used when type = link.

Setting	Description
`link.uri` (required)	Target URI; accepts field substitution, with all inserted values URI-encoded.
`link.target`	`blank` (new window/tab, default) or `self` (same window).
`link.method`	`get` (default) or `post`.
`link.postargs.<int>.key` / `.value`	Only with `link.method = post`. Numbered key/value pairs (allowing repeated keys, e.g. two entries both keyed `foo` with different values) since a bare conf file can't otherwise represent that. Values are HTML form-encoded.

Search action type

Constructs and runs a new search in a specified view. Used when type = search.

Setting	Description
`search.search_string` (required)	The search to construct, with field substitution -- does not check whether an inserted value could break search-language quoting/escaping.
`search.app` / `search.view`	App/view to run the search in. Default to the current app/view.
`search.target`	`blank` or `self`, same semantics as `link.target`.
`search.earliest` / `search.latest`	Absolute or relative (e.g. `-10h`) time bounds for the constructed search.
`search.preserve_timerange`	Reuses the original search's time range instead. Ignored if `earliest`/`latest` is set. Default `false`.

Example

[whois]
display_location = field_menu
fields = clientip
label = Whois: $clientip$
link.method = get
link.target = blank
link.uri = http://ws.arin.net/whois/?queryinput=$clientip$
type = link

[Google]
display_location = field_menu
fields = *
label = Google $@field_name$
link.method = get
link.uri = http://www.google.com/search?q=$@field_value$
type = link

[Controller req over time]
display_location = event_menu
fields = controller
label = Requests over last day for $controller$
search.earliest = -3d
search.search_string = sourcetype=rails_app controller=$controller$ | timechart span=1h count
search.target = blank
search.view = charting
type = search

A field-specific whois lookup, a generic Google-search action offered on every field via $@field_name$ / $@field_value$ , and an event-menu search action that only appears when the event has a controller field, jumping into a charting view scoped to the last 3 days.

Validation

Confirm both type and label are set -- either missing silently skips the entire action.
Don't use $@field_name$ / $@field_value$ in an event_menu-only action -- they're field-menu-only variables.
Scope fields deliberately rather than leaving the default * when an action only makes sense for specific fields (e.g. an IP-lookup action showing up on every field menu is noise).
Remember search.search_string does no quoting/escaping safety checks on substituted field values -- a field value containing quotes or pipes can break the constructed search.
Use numbered link.postargs.<n>.key/.value pairs, not a single combined setting, when POSTing more than one form field -- including repeated keys.

← Back to References

References / Splunk platform configuration

Splunk Web Configuration

web.conf configures the Splunk Web application server process itself -- listen port and management-port proxying, HTTPS/TLS for the browser-facing UI, host/origin validation, session timeout, SSO header-based authentication, CORS, dashboard HTML sandboxing and PDF generation, login-page branding, and custom REST-to-UI endpoint registration. Most changes require a Splunk Web restart. Backs the Splunk Taxonomy's Splunk Web Configuration object (SOT-11.05.04), and is one of two conf files -- alongside authentication.conf -- behind ProxySSO Config (SOT-07.03.10).

Definition

Everything lives in a single [settings] stanza (plus a handful of narrow auxiliary stanzas covering custom endpoints and the bundled proxy). web.conf governs the Splunk Web process -- distinct from server.conf's [httpServer]/[sslConfig] stanzas, which govern splunkd's own management-port REST API rather than the browser-facing UI.

File locations

Configuration file: web.conf.

Scope	Path
System	`$SPLUNK_HOME/etc/system/{default,local}/web.conf`
App	`$SPLUNK_HOME/etc/apps/<app_name>/{default,local}/web.conf`

Nearly always set at system/local -- most admins never touch an app-level copy.

General & listen settings

Setting	Description
`startwebserver`	Whether Splunk Web starts at all. `0` disables the UI entirely (splunkd/REST is unaffected). Default `1`.
`httpport`	Port Splunk Web listens on for browser connections. Default `8000`.
`mgmtHostPort`	The splunkd management-port `host:port` Splunk Web proxies REST calls to on the backend.
`server.socket_host`	Interface to bind the listener to; empty binds all interfaces.
`appServerPorts`	Port(s) used internally by the Python-based app server tier that Splunk Web's front end talks to.
`root_endpoint`	URL path Splunk Web is served under, e.g. `/splunk` instead of `/` -- used when reverse-proxying under a sub-path.
`static_endpoint` / `static_dir`	URL path and filesystem location for static assets (JS/CSS/images).
`max_upload_size`	Maximum upload size (MB) Splunk Web itself will accept, e.g. for the Add Data UI.

TLS/SSL settings

Controls HTTPS for the browser-to-Splunk-Web connection -- independent of splunkd's own management-port SSL configured in server.conf.

Setting	Description
`enableSplunkWebSSL`	Serve Splunk Web over HTTPS instead of plain HTTP. Default `false` -- strongly recommended to enable in production.
`privKeyPath` / `serverCert` / `caCertPath`	Paths to the private key, server certificate, and CA bundle used for the HTTPS listener.
`sslPassword`	Passphrase protecting `privKeyPath`, if any. Encrypted in place on first read.
`cipherSuite` / `sslVersions` / `ecdhCurves`	OpenSSL cipher spec, allowed protocol version list, and ECDH curve list -- the same hardening knobs used elsewhere for splunkd SSL.
`sslCommonNameToCheck` / `sslAltNameToCheck`	When Splunk Web makes outbound TLS connections (e.g. to splunkd), the certificate CN/SAN values it will accept.
`allowSslCompression` / `allowSslRenegotiation`	Legacy TLS behaviors, both normally left disabled for security.

Netloc & origin allow-listing

Splunk Web validates the Host/Origin of incoming browser requests against an explicit allow-list, closing off host-header and DNS-rebinding style attacks against the UI.

Setting	Description
`allowedSplunkWebClientNetlocList`	Comma-separated list of `host[:port]` values Splunk Web will accept as a valid client-facing network location. A request whose Host header doesn't match is rejected.
`allowedSplunkWebClientSchemeList`	Which URL scheme(s) (`http`, `https`) are accepted alongside the netloc check.

Security hardening toggles

Setting	Description
`enable_insecure_login`	Loosens login-form request validation for compatibility with certain reverse proxies/older clients. Leaving disabled is the hardened default.
`enable_insecure_pdfgen`	Relaxes access verification on the PDF-generation subsystem used by scheduled PDF delivery and dashboard export. Leaving disabled is the hardened default.
`enable_secure_entity_move`	Enforces additional ownership/permission verification when a knowledge object is moved between apps or users.
`x_frame_options_sameorigin`	Sends the `X-Frame-Options: SAMEORIGIN` response header, mitigating clickjacking of the Splunk Web UI.

Dashboard HTML & PDF generation

Classic (Simple XML) dashboards can embed a raw HTML panel; because that HTML renders in an authenticated user's browser session, it's a stored-XSS vector if untrusted users can edit dashboards. These settings gate that feature and the separate headless-render pipeline used for PDF export.

Setting	Description
`dashboard_html_injection_mode`	`disabled`, `warn`, or `enabled` -- whether raw HTML dashboard panels render at all, and whether a warning banner is shown when they do.
`dashboard_html_injection_ignore_list`	Dashboards exempted from the injection-mode restriction, by name.
`pdfgen_is_available`	Whether the PDF-generation subsystem is enabled at all.
`pdfgen_trusted_hosts`	Allow-list of hosts the headless PDF renderer is permitted to navigate to while rendering a dashboard.

CORS settings

Setting	Description
`crossOriginSharingPolicy`	List of origin patterns (regex-capable) permitted to make cross-origin requests against Splunk Web's REST proxy -- needed when a separate front-end origin calls the Splunk REST API directly from browser JavaScript.
`crossOriginSharingHeaders`	Additional headers advertised as allowed in the CORS preflight response, beyond Splunk's defaults.

SSO / remoteUser settings

Backs ProxySSO Config (SOT-07.03.10): a reverse-proxy in front of Splunk Web authenticates the user and asserts identity via trusted HTTP headers, which Splunk Web reads instead of prompting for a password.

Setting	Description
`SSOMode`	`permissive` (falls back to normal login if SSO headers are absent) or `strict` (SSO headers are mandatory). `strict` must be set here before the corresponding `authentication.conf`/REST ProxySSO configuration takes effect.
`trustedIP`	IP address(es) of the trusted reverse proxy -- requests asserting an identity header from any other source are rejected.
`remoteUser`	Name of the HTTP header the trusted proxy uses to assert the authenticated username.
`remoteGroups`	Name of the HTTP header the trusted proxy uses to assert group membership, consumed for role mapping.
`ssoAuthFailureRedirect`	Where to send the browser if the SSO identity check fails.

Session & HTTP server settings

Splunk Web runs on an embedded CherryPy HTTP server; these settings tune its request handling, session store, and logging.

Setting	Description
`tools.sessions.timeout`	Browser session idle timeout, in minutes. Default `60`.
`server.thread_pool`	Worker thread pool size for the embedded HTTP server.
`server.max_request_header_size`	Upper bound on total request header size, a hardening limit against oversized-header abuse.
`log.access_file` / `log.error_file` / `log.screen`	Where Splunk Web's own access/error logs are written, and whether they also echo to stdout.
`js_logger_mode` / `js_no_cache`	Browser-side JS logging verbosity, and whether static JS assets are served with cache-busting.

Login page customization

A group of branding settings for the login screen and browser tab -- custom logo and background image, footer links, terms-of-service text, and document title. Normally applied through Splunk Web's own branding manager pages rather than hand-edited, since the manager UI also handles asset upload/placement; the underlying settings persist to this stanza either way.

Custom endpoints & auxiliary stanzas

Stanza	Description
`[endpoint:<name>]` / `[expose:<name>]`	Registers a custom REST-to-UI bridge endpoint or exposes an existing REST endpoint to Splunk Web's JavaScript SDK -- used by apps that ship their own custom Splunk Web pages needing REST access beyond the stock endpoints.
`[nghttpx_server]`	Configures the bundled `nghttpx` reverse-proxy process Splunk Web runs in front of its Python app server tier, chiefly for HTTP/2 termination.
`[remoteUI]`	Narrow toggle for remote-UI framework behavior.
`[admin_config_ui]`	Controls availability of specific configuration-manager UI pages.
`[smc]`	Splunk Cloud management-console integration settings; not applicable to on-prem/self-managed deployments.

All settings

Every stanza and setting in web.conf.spec from Splunk Enterprise 10.4.2: 194 settings across 7 stanzas. Descriptions use the spec's own wording -- the first line shows here and More opens the rest. The Default column is filled only where the spec gives a Default: line.

`[settings]`

Set general Splunk Web configuration options under this stanza name.
Follow this stanza name with any number of the following setting/value pairs.
If you do not specify an entry for each setting, Splunk Web uses the default value.

Setting	Description	Default
`[settings]` `startwebserver`	`[0 \| 1]`Set whether or not to start Splunk Web. More 0 disables Splunk Web, 1 enables it.	1
`[settings]` `httpport`	`<positive integer>`The TCP port on which Splunk Web listens for incoming connections. More Must be present for Splunk Web to start. If omitted or 0 the server will NOT start an http listener. If using SSL, set to the HTTPS port number.	8000
`[settings]` `mgmtHostPort`	`<string>`The host port of the splunkd process. More The IP address and host port where Splunk Web looks for the splunkd process. The port listens on all avalible host IP addresses (0.0.0.0) Don't include "http[s]://" when specifying this setting. Only include the IP address and port.	localhost:8089 (on universal forwarders); 0.0.0.0:8089 (on all other Splunk platform instance types)
`[settings]` `proxyHostPort`	`<string>`The URL through which agents can contact the Splunk daemon when using Data Management. More These agents use the value for this setting to connect to splunkd to receive package and pipeline updates as part of Edge Processor. When you specify this setting, include the scheme, host name, and network port. Example: https://198.51.100.0:8089	No default
`[settings]` `appServerPorts`	`<positive integer>[, <positive integer>, <positive integer> ...]`Port number(s) for the python-based application server to listen on. This port is bound only on the loopback interface -- it is not exposed to the network at large. More Generally, you should only set one port number here. For most deployments a single application server won't be a performance bottleneck. However you can provide a comma-separated list of port numbers here and splunkd will start a load-balanced application server on each one. At one time, setting this to zero indicated that the web service should be run in a legacy mode as a separate service, but as of Splunk 8.0 this is no longer supported.	8065
`[settings]` `splunkdConnectionTimeout`	`<integer>`The amount of time, in seconds, to wait before timing out when communicating with splunkd. More Must be at least 30. Values smaller than 30 will be ignored, resulting in the use of the default value	30
`[settings]` `enableSplunkWebClientNetloc`	`<boolean>`DEPRECATED. Use 'allowedSplunkWebClientNetlocList' and 'allowedSplunkWebClientSchemeList' instead. More Whether or not Splunk Web, as a client, can override the client network location and connect to external Splunk daemons. See the 'allowedSplunkWebClientNetlocList' setting for an explanation of what a network location is.	false
`[settings]` `allowedSplunkWebClientNetlocList`	`<comma-separated list>`A list of host names or IP network addresses and network ports that Splunk Web, as a client, can use to connect to a Splunk daemon. More This set of names or addresses and ports are part of what is called a network location, or netloc. Splunk Web uses these netlocs to access Splunk daemons apart from the splunkd on the local instance. When you configure this setting along with the 'allowedSplunkWebClientSchemeList' setting, Splunk Web builds the list of netlocs that it can use to access external Splunk daemons. For each netloc, specify the host name or IP address and network port only. Do not include the scheme (the part before the host name/IP address and port). Separate the name or IP address and port with a colon. Then, separate each netloc with commas. For example, the following configuration lets Splunk Web access the Splunk daemons at https://198.51.100.0:8089 and http://127.0.0.1:8888: allowedSplunkWebClientNetlocList = 198.51.100.0:8089,127.0.0.1:8888 allowedSplunkWebClientSchemeList = http,https CAUTION: Splunk Web expects to connect to a Splunk daemon when you configure these settings. Undesirable results could occur if the netloc is either down or not a Splunk daemon.	No default
`[settings]` `allowedSplunkWebClientSchemeList`	`<comma-separated list>`A list of Uniform Resource Locator (URL) schemes that Splunk Web, as a client, can use to build a netloc to which it can connect to the management port of an external Splunk daemon. More When you configure this setting along with the 'allowedSplunkWebClientNetlocList' setting, Splunk Web builds the list of netlocs that it can use to access Splunk daemons apart from the local splunkd. For this value, specify the acceptable netloc schemes only (the part before the host name or IP address and network port.) Do not include the host name or IP address and port. See the 'allowedSplunkWebClientNetlocList' setting for examples on how to use both settings to create netlocs. The only acceptable values for this setting are any of: file, http, https	No default
`[settings]` `enableSplunkWebSSL`	`<boolean>`Toggle between http or https. More Set to true to enable https and SSL.	false
`[settings]` `privKeyPath`	`<path>`The path to the file containing the web server SSL certificate private key. More You can also specify an absolute path to an external key. Splunkd interprets a relative path as relative to the $SPLUNK_HOME directory. See also 'enableSplunkWebSSL' and 'serverCert'.	$SPLUNK_HOME/etc/auth/splunkweb/privkey.pem
`[settings]` `serverCert`	`<path>`Full path to the Privacy Enhanced Mail (PEM) format Splunk web server certificate file. More The file may also contain root and intermediate certificates, if required. They should be listed sequentially in the order: [ Server SSL certificate ] [ One or more intermediate certificates, if required ] [ Root certificate, if required ] See also 'enableSplunkWebSSL' and 'privKeyPath'. Splunkd interprets a relative path as relative to the $SPLUNK_HOME directory.	$SPLUNK_HOME/etc/auth/splunkweb/cert.pem
`[settings]` `sslPassword`	`<password>`Password that protects the private key specified by 'privKeyPath'. More If encrypted private key is used, do not enable client-authentication on splunkd server. In [sslConfig] stanza of server.conf, 'requireClientCert' must be 'false'. Optional.	password
`[settings]` `caCertPath`	`<path>`DEPRECATED. More Use 'serverCert' instead. A relative path is interpreted relative to $SPLUNK_HOME and may not refer outside of $SPLUNK_HOME (e.g., no ../somewhere).	No default
`[settings]` `sslRootCAPath`	`<path>`The path to a root certificate authority (CA) certificate, in privacy-enhanced mail (PEM) format, that splunkd is to use to authenticate client certificates under certain specific conditions. More Splunkd uses the certificate specified at the path defined in this setting only when both 'requireClientCert' and 'enableCertBasedUserAuth' have a value of "true". If this setting has no value, splunkd falls back to the value of the 'sslRootCAPath' setting in server.conf. If you have already configured 'sslRootCAPath' in server.conf, the value of this setting does not override the setting of the same name in server.conf.	No default
`[settings]` `enableCertBasedUserAuth`	`<boolean>`Whether or not user authentication with certificates is enabled. More When certificate-based authentication is enabled, splunkd uses a digital certificate to identify and grant a user access to a Splunk platform instance resource. A value of "true" means that splunkd uses certificates for authentication. When this setting has a value of "true", 'requireClientCert' must also have a value of "true". A value of "false" means that splunkd does not use certificates for authentication. NOTE: Splunkd disables the check to determine if Splunk Web is serving web requests after it completes startup when this setting has a value of "true". If you need this check to happen, then this setting must have a value of "false".	false
`[settings]` `certBasedUserAuthMethod`	`<string>`The method that the Splunk platform uses to extract LDAP credentials from client certificates. More This setting takes one of the following values: CommonName: Use the value contained in the Common Name field of a client certificate in its entirety EDIPI (Electronic Data Interchange Personal Identifier): Extract the EDIPI, the 10-digit numeric identifier from the Common Name. If the platform can't find the EDIPI, then it uses the Common Name in its entirety. PIV (Personal Identity Verification): Use PIV, a 16-digit numeric identifier typically formatted as xxxxxxxxxxxxxxxx@mil. It is extracted from an "Other Name" field in the Subject Alternate Name which corresponds to one of the object identifiers (OIDs) that you configure in 'certBasedUserAuthPivOidList'.	No default
`[settings]` `certBasedUserAuthPivOidList`	`<comma-separated list>`A list of object identifiers (OIDs) that the Splunk platform uses to lookup an end-user's PIV info in the Subject Alternate Name extension of the client certificate. More The Splunk platform queries OIDs sequentially in a client certificate until it finds an OID with a value. The value contained in the matched OID is then used to authenticate the user.	1.3.6.1.4.1.311.20.2.3, Microsoft Universal Principal Name, Microsoft User Principal Name
`[settings]` `requireClientCert`	`<boolean>`Whether or not an HTTPS client that connects to the Splunk Web HTTPS server must present a certificate that was signed by the same certificate authority (CA) that signed the certificate that was installed on this instance. More A value of "true" means the following: A client can connect only if it presents a certificate that was created and signed by the same CA that created the certificate that the instance uses You must configure splunkd with the same root CA in the server.conf file. This requirement ensures proper communication between splunkd and Splunk Web. If you give 'enableCertBasedUserAuth' a value of "true", then the previous statements do not apply. Instead, the instance uses the root CA certificate defined in the 'sslRootCAPath' setting in web.conf, and if no certificate path is defined in that file, it then uses the certificate defined in the 'sslRootCAPath' setting in server.conf. A value of "false" means that clients do not need to present a certificate to connect to the instance.	false
`[settings]` `sslCommonNameToCheck`	`<commonName1>, <commonName2>, ...`Checks the common name of the client's certificate against this list of names. More 'requireClientCert' must be set to "true" for this setting to work. Optional.	empty string (No common name checking).
`[settings]` `sslAltNameToCheck`	`<alternateName1>, <alternateName2>, ...`If this value is set, and 'requireClientCert' is set to true, Splunk Web will verify certificates which have a so-called "Subject Alternate Name" that matches any of the alternate names in this list. More Subject Alternate Names are effectively extended descriptive fields in SSL certs beyond the commonName. A common practice for HTTPS certs is to use these values to store additional valid hostnames or domains where the cert should be considered valid. Accepts a comma-separated list of Subject Alternate Names to consider valid. Optional.	empty string (no alternate name checking).
`[settings]` `serviceFormPostURL`	`http://docs.splunk.com/Documentation/Splunk`DEPRECATED. More This setting has been deprecated since Splunk Enterprise version 5.0.3.
`[settings]` `userRegistrationURL`	`https://www.splunk.com/page/sign_up`These are various Splunk.com urls that are configurable. More Setting 'updateCheckerBaseURL' to 0 stops Splunk Web from pinging Splunk.com for new versions of Splunk software.
`[settings]` `updateCheckerBaseURL`	`http://quickdraw.Splunk.com/js/`These are various Splunk.com urls that are configurable. More Setting 'updateCheckerBaseURL' to 0 stops Splunk Web from pinging Splunk.com for new versions of Splunk software.
`[settings]` `docsCheckerBaseURL`	`http://quickdraw.splunk.com/help`These are various Splunk.com urls that are configurable. More Setting 'updateCheckerBaseURL' to 0 stops Splunk Web from pinging Splunk.com for new versions of Splunk software.
`[settings]` `enable_insecure_login`	`<boolean>`Whether or not the GET-based "/account/insecurelogin" REST endpoint is enabled. More Provides an alternate GET-based authentication mechanism. If "true", the following url is available:
`[settings]` `http://localhost:8000/en-US/account/insecurelogin?loginType`	`splunk&username=noc&password=XXXXXXX`If "false", only the main /account/login endpoint is available	false
`[settings]` `enable_secure_entity_move`	`<boolean>`Whether or not you can perform an HTTP GET request on the "move" REST endpoint for any entity that has such an endpoint, to move that entity from one Splunk app to another. More Entities are configurable components of the Splunk Web framework, such as views, styles, and drilldown actions. This is not an exhaustive list. If set to "true", you can perform only HTTP POST requests against the "move" endpoint for an entity. For example, if you have an endpoint "/en_US/manager/launcher/data/ui/views/move", you can only perform an HTTP POST request to access that endpoint to move an entity from one app to another. If set to "false", you can perform both HTTP GET and POST requests against the "move" endpoint of an entity.	true
`[settings]` `enable_insecure_pdfgen`	`<boolean>`Whether or not the "/services/pdfgen/render" REST endpoint allows GET requests. More If "true", allows PDFs to be generated using GET or POST requests. If "false", only allows PDFs to be generated using POST requests.	false
`[settings]` `simple_error_page`	`<boolean>`Whether or not to display a simplified error page for HTTP errors that only contains the error status. More If set to "true", Splunk Web displays a simplified error page for errors (404, 500, etc.) that only contain the error status. If set to "false", Splunk Web displays a more verbose error page that contains the home link, message, a more_results_link, crashes, referrer, debug output, and byline	false
`[settings]` `login_content`	`<string>`Lets you add custom content to the login page. More Supports any text including HTML. The Splunk platform sanitizes HTML for security purposes by removing potentially dangerous tags and attributes.	No default
`[settings]` `sslVersions`	`<comma-separated list>`The list of TLS versions to support. More The versions available are "tls1.0", "tls1.1", "tls1.2" and "tls1.3" The special version "*" selects all supported versions. The version "tls" selects all versions tls1.0 or newer If you prefix a version with "-", it is removed from the list. SSL versions 2 and 3 are always disabled. "-ssl2" and "-ssl3" are accepted as values in the version list, but have no effect. For the default, see $SPLUNK_HOME/etc/system/default/web.conf.
`[settings]` `supportSSLV3Only`	`<boolean>`This setting is DEPRECATED. SSLv2 is now always disabled. The exact set of SSL versions allowed is now configurable via the 'sslVersions' setting above.
`[settings]` `cipherSuite`	`<cipher suite string>`If set, uses the specified cipher string for the HTTP server. More If not set, uses the default cipher string provided by OpenSSL. This is used to ensure that the server does not accept connections using weak encryption protocols. Must specify 'dhFile' to enable any Diffie-Hellman ciphers. The default can vary. See the cipherSuite setting in $SPLUNK_HOME/etc/system/default/web.conf for the current default.
`[settings]` `ecdhCurveName`	`<string>`DEPRECATED. More Use the 'ecdhCurves' setting instead. This setting specifies the Elliptic Curve Diffie-Hellman (ECDH) curve to use for ECDH key negotiation. Splunk only supports named curves that have been specified by their SHORT name. The list of valid named curves by their short and long names can be obtained by running this CLI command: $SPLUNK_HOME/bin/splunk cmd openssl ecparam -list_curves	empty string.
`[settings]` `ecdhCurves`	`<comma-separated list>`A list of ECDH curves to use for ECDH key negotiation. More The curves should be specified in the order of preference. The client sends these curves as a part of an SSL Client Hello. The server supports only the curves specified in the list. Splunk software only supports named curves that have been specified by their SHORT names. The list of valid named curves by their short and long names can be obtained by running this CLI command: $SPLUNK_HOME/bin/splunk cmd openssl ecparam -list_curves Example setting: "ecdhCurves = prime256v1,secp384r1,secp521r1" The default can vary. See the 'ecdhCurves' setting in $SPLUNK_HOME/etc/system/default/web.conf for the current default.
`[settings]` `dhFile`	`<path>`Full path to the Diffie-Hellman parameter file. More Relative paths are interpreted as relative to $SPLUNK_HOME, and must not refer to a location outside of $SPLUNK_HOME. This file is required in order to enable any Diffie-Hellman ciphers.	not set.
`[settings]` `root_endpoint`	`<URI_prefix_string>`Defines the root URI path on which the appserver will listen More For example, if you want to proxy the splunk UI at http://splunk:8000/splunkui, then set root_endpoint = /splunkui	/
`[settings]` `static_endpoint`	`<URI_prefix_string>`Path to static content. More The path here is automatically appended to root_endpoint defined above	/static
`[settings]` `static_dir`	`<relative_filesystem_path>`The directory that holds the static content More This can be an absolute URL if you want to put it elsewhere	share/splunk/search_mrsparkle/exposed
`[settings]` `rss_endpoint`	`<URI_prefix_string>`Path to static rss content More The path here is automatically appended to what you defined in the 'root_endpoint' setting	/rss
`[settings]` `embed_uri`	`<URI>`Optional URI scheme/host/port prefix for embedded content More This presents an optional strategy for exposing embedded shared content that does not require authentication in a reverse proxy/single sign on environment.	empty string, resolves to the client window.location.protocol + "//" + window.location.host
`[settings]` `embed_footer`	`<html_string>`A block of HTML code that defines the footer for an embedded report. More Any valid HTML code is acceptable. The Splunk platform sanitizes HTML for security purposes by removing potentially dangerous tags and attributes.	"splunk>"
`[settings]` `tools.staticdir.generate_indexes`	`[1 \| 0]`Whether or not the webserver serves a directory listing for static directories.	0 (false)
`[settings]` `template_dir`	`<relative_filesystem_path>`The base path to the Mako templates.	"share/splunk/search_mrsparkle/templates"
`[settings]` `module_dir`	`<relative_filesystem_path>`The base path to Splunk Web module assets.	"share/splunk/search_mrsparkle/modules"
`[settings]` `enable_gzip`	`<boolean>`Whether or not the webserver applies gzip compression to responses.	true
`[settings]` `use_future_expires`	`<boolean>`Whether or not the Expires header of /static files is set to a far-future date	true
`[settings]` `flash_major_version`	`<integer>`DEPRECATED.
`[settings]` `flash_minor_version`	`<integer>`DEPRECATED.
`[settings]` `flash_revision_version`	`<integer>`DEPRECATED. More Specifies the minimum Flash plugin version requirements Flash support, broken into three parts. We currently require a min baseline of Shockwave Flash 9.0 r124
`[settings]` `override_JSON_MIME_type_with_text_plain`	`<boolean>`Whether or not to override the MIME type for JSON data served up by Splunk Web endpoints with content-type="text/plain; charset=UTF-8" More If "true", Splunk Web endpoints (other than proxy) that serve JSON data will serve as "text/plain; charset=UTF-8" If "false", Splunk Web endpoints that serve JSON data will serve as "application/json; charset=UTF-8"
`[settings]` `enable_proxy_write`	`<boolean>`Indicates if the /splunkd proxy endpoint allows POST operations. More If "true", both GET and POST operations are proxied through to splunkd. If "false", only GET operations are proxied through to splunkd. Setting to "false" prevents many client-side packages (such as the Splunk JavaScript SDK) from working correctly.	true
`[settings]` `js_logger_mode`	`[None \| Firebug \| Server]`The JavaScript Logger mode. More Available modes: None, Firebug, Server Mode None: Does not log anything. Mode Firebug: Use firebug by default if it exists, or defer to the older less promiscuous version of firebug lite. Mode Server: Log to a defined server endpoint. See js/logger.js Splunk.Logger.Mode for mode implementation details and if you would like to author your own.	None
`[settings]` `js_logger_mode_server_end_point`	`<URI_relative_path>`The server endpoint to post JavaScript log messages More Used when js_logger_mode = Server	util/log/js
`[settings]` `js_logger_mode_server_poll_buffer`	`<integer>`The interval, in milliseconds, to check, post, and cleanse the JavaScript log buffer	1000
`[settings]` `js_logger_mode_server_max_buffer`	`<integer>`The maximum size threshold, in megabytes, to post and cleanse the JavaScript log buffer	100
`[settings]` `ui_inactivity_timeout`	`<integer>`The length of time lapsed, in minutes, for notification when there is no user interface clicking, mouseover, scrolling, or resizing. More Notifies client side pollers to stop, resulting in sessions expiring at the 'tools.sessions.timeout' value. If less than 1, results in no timeout notification ever being triggered (Sessions stay alive for as long as the browser is open).	60
`[settings]` `js_no_cache`	`<boolean>`DEPRECATED. More Toggles the JavaScript cache control.	false
`[settings]` `cacheBytesLimit`	`<integer>`Splunkd can keep a small cache of static web assets in memory. When the total size of the objects in cache grows larger than this setting, in bytes, splunkd begins ageing entries out of the cache. More If set to zero, disables the cache.	4194304
`[settings]` `cacheEntriesLimit`	`<integer>`Splunkd can keep a small cache of static web assets in memory. When the number of the objects in cache grows larger than this, splunkd begins ageing entries out of the cache. More If set to zero, disables the cache.	16384
`[settings]` `staticCompressionLevel`	`<integer>`Splunkd can keep a small cache of static web assets in memory. Splunkd stores these assets in a compressed format, and the assets can usually be served directly to the web browser in compressed format. More This level can be a number between 1 and 9. Lower numbers use less CPU time to compress objects, but the resulting compressed objects will be larger. There is not much benefit to decreasing the value of this setting from its default. Not much CPU time is spent compressing the objects.	9
`[settings]` `enable_autocomplete_login`	`<boolean>`Indicates if the main login page lets browsers autocomplete the username. More If "true", browsers may display an autocomplete drop down in the username field. If "false", browsers may not show autocomplete drop down in the username field.	false
`[settings]` `verifyCookiesWorkDuringLogin`	`<boolean>`Normally, the login page makes an attempt to see if cookies work properly in the user's browser before allowing them to log in. More If you set this to "false", this check is skipped. Do not set to "false" in normal operations.	true
`[settings]` `minify_js`	`<boolean>`Whether or not the static JavaScript files for modules are consolidated and minified. More A value of "true" means that JavaScript files for modules are consolidated and minified. This improves client-side performance by reducing the number of HTTP requests and the size of HTTP responses. A value of "false" means that JavaScript files for modules are not consolidated or minified.	true
`[settings]` `minify_css`	`<boolean>`Whether or not the static CSS files for modules are consolidated and minified. More A value of "true" means that static CSS files for modules are consolidated and minified. This improves client-side performance by reducing the number of HTTP requests and the size of HTTP responses. A value of "false" means that static CSS files for modules are not consolidated or minified. Due to browser limitations, setting this to "false" when using Internet Explorer version 9 and lower might result in display problems.	true
`[settings]` `trap_module_exceptions`	`<boolean>`Whether or not the JavaScript for individual modules is wrapped in a try/catch More If "true", syntax errors in individual modules do not cause the UI to hang, other than when using the module in question. Set to "false" when developing apps.
`[settings]` `enable_pivot_adhoc_acceleration`	`<boolean>`DEPRECATED in version 6.1 and later, use 'pivot_adhoc_acceleration_mode' instead More Whether or not the pivot interface uses its own ad-hoc acceleration when a data model is not accelerated. If "true", the pivot interface uses ad-hoc acceleration to make reporting in pivot faster and more responsive. In situations where data is not stored in time order, or where the majority of events are far in the past, disabling this behavior can improve the pivot experience.
`[settings]` `pivot_adhoc_acceleration_mode`	`[Elastic \| AllTime \| None]`Specifies the type of ad-hoc acceleration used by the pivot interface when a data model is not accelerated. More If "Elastic", the pivot interface only accelerates the time range specified for reporting, and dynamically adjusts when this time range is changed. If "AllTime", the pivot interface accelerates the relevant data over all time. This makes the interface more responsive to time-range changes but places a larger load on system resources. If "None", the pivot interface does not use any acceleration. This means any change to the report requires restarting the search.	Elastic
`[settings]` `jschart_test_mode`	`<boolean>`Whether or not the JSChart module runs in Test Mode. More If "true", JSChart module attaches HTML classes to chart elements for introspection. This negatively impacts performance and should be disabled unless you are actively using JSChart Test Mode.
`[settings]` `jschart_truncation_limit`	`<integer>`Cross-broswer truncation limit. More If set, takes precedence over the browser-specific limits below
`[settings]` `jschart_truncation_limit.chrome`	`<integer>`Chart truncation limit. More For Chrome only.	50000
`[settings]` `jschart_truncation_limit.firefox`	`<integer>`Chart truncation limit. More For Firefox only.	50000
`[settings]` `jschart_truncation_limit.safari`	`<integer>`Chart truncation limit. More For Safari only.	50000
`[settings]` `jschart_truncation_limit.ie11`	`<integer>`Chart truncation limit. More For Internet Explorer version 11 only	50000
`[settings]` `jschart_series_limit`	`<integer>`Chart series limit for all browsers.	100
`[settings]` `jschart_results_limit`	`<integer>`DEPRECATED. More Use 'data_sources.primary.params.count' in visualizations.conf instead. Chart results per series limit for all browsers. Overrides the results per series limit for individual visualizations.	10000
`[settings]` `choropleth_shape_limit`	`<integer>`Choropleth map shape limit for all browsers.	10000
`[settings]` `dashboard_html_allow_inline_styles`	`<boolean>`Whether or not to allow style attributes from inline HTML elements in dashboards. More If "false", style attributes from inline HTML elements in dashboards will be removed to prevent potential attacks.	true
`[settings]` `dashboard_html_allow_embeddable_content`	`<boolean>`Whether or not to allow <embed> and <iframe> HTML elements in dashboards. More If set to "true", <embed> and <iframe> HTML elements in dashboards will not be removed and can lead to a potential security risk. If set to the default value of "false", <embed> and <iframe> HTML elements will be stripped from the dashboard HTML.	false
`[settings]` `dashboard_html_wrap_embed`	`<boolean>`Whether or not to wrap <embed> HTML elements in dashboards with an <iframe>. More If set to "false", <embed> HTML elements in dashboards will not be wrapped, leading to a potential security risk. If set to "true", <embed> HTML elements will be wrapped by an <iframe sandbox> element to help mitigate potential security risks.	true
`[settings]` `dashboard_html_allow_iframes`	`<boolean>`Whether or not to allow iframes from HTML elements in dashboards. More If "false", iframes from HTML elements in dashboards will be removed to prevent potential attacks.	true
`[settings]` `dashboard_html_allowed_domains`	`<comma-separated list>`A list of allowed domains for inline iframe element source ('<iframe src="<URL>">') attributes in dashboards. More If the domain for an <iframe> src attribute is not an allowed domain, the Simple XML dashboard adds the 'sandbox' attribute to the <iframe>, which further restricts the content within the <iframe> by treating it as coming from a unique origin. Simple XML dashboards will allow <iframe> src attributes by default if the src is the same hostname and port number as the Splunk Web server's hostname and port number. You can specify these domains as a hostname or an IPV4 address or an IPV6 address. You can configure a hostname as a full name or with a wildcard to allow for any subdomains. For example, .example.com would allow for any subdomain of example.com as well as example.com itself. You can specify an IPV4 address as an exact address or: You can use an asterisk to specify a wildcard (Example: 192.168.1.). Asterisks allow for any address within that byte segment. You can use a dash to specify a range of addresses (Example: 192.168.1.1-99). Dashes will only match IP addresses within that range. You can specify an IPV6 address either as an exact address or with a subnet mask. If you specify a subnet mask, any IPV6 address within the subnet will be an allowed domain. You can specify a port number for any of the domains. If you do, the '<iframe src>' must match the port number as well. Additional configuration examples: Hostname: docs.splunk.com, .splunk.com IPV4: 127.0.0.1, 127.0.0., 127.0-10.0.*, 127.0.0.1:8000 IPV6: ::1, [::1]:8000, 2001:db8:abcd:12::, 2001:db8::/32	not set
`[settings]` `pdfgen_trusted_hosts`	`<string> [, <string>]`A list of trusted hosts for inline image element source ('<image src="<URL>">') links used during a pdf export. More If the domain for an <image> src attribute is not in the list of trusted hosts, the image will not download during PDF export. Separate multiple rules with commas. Each rule can be in one of the following formats: 1. A single IPv4 or IPv6 address (examples: "203.0.113.2", "2001:db8:3c4d") 2. A Classless Inter-Domain Routing (CIDR) block of addresses (examples: "192.0.2.0/24", "2001:DB8::/32") 3. A DNS name. Use "" as a wildcard (examples: "myhost.example.com", ".splunk.com") 4. "", which matches anything Any link which resolves to a loopback address will not download, unless the "" rule is used. You can prefix an entry with '!' to cause the rule to reject the connection. The input applies rules in order, and uses the first one that matches. For example, "!192.0.2.0/24, " allows connections from everywhere except the 192.0.2. network.	not set. All links will fail by default.
`[settings]` `max_view_cache_size`	`<integer>`The maximum number of views to cache in the appserver.	1000
`[settings]` `pdfgen_is_available`	`[0 \| 1]`Specifies whether Integrated PDF Generation is available on this search head. More This is used to bypass an extra call to splunkd.	1 (on platforms where pdfgen is supported); 0 (on platforms where pdfgen is not supported)
`[settings]` `version_label_format`	`<printf_string>`Internal configuration. More Overrides the version reported by the UI to *.splunk.com resources	%s
`[settings]` `auto_refresh_views`	`[0 \| 1]`Specifies whether the following actions cause the appserver to ask splunkd to reload views from disk. More Logging in through Splunk Web Switching apps Clicking the Splunk logo	0
`[settings]` `show_app_context`	`<boolean>`Whether or not Splunk Web will show app context in certain locations. More You can set this to "false" in situations where you do not want to display app contexts, for example, when apps are under cluster management.	true
`[settings]` `cookieSameSite`	`[ not_specified \| lax \| strict \| none ]`The value of the "SameSite" cookie attribute for which the Splunk web server is to set in the web browser. More A value of "not_specified" means the Splunk web server does not set the "SameSite" attribute. Some browsers, like Chrome, interpret this as if the web server set "SameSite=Lax", according to the latest Internet-Drafts as published by the Internet Engineering Task Force (IETF). Other browsers might interpret this as if the web server set "SameSite=None". A value of "lax" means the Splunk web server sets the "SameSite=Lax" attribute. A value of "strict" means the Splunk web server sets the "SameSite=Strict" attribute. A value of "none" means the Splunk web server sets the "SameSite=None" cookie attribute, to let browsers send the cookies in all contexts. A cookie with this attribute lets the browser embed a Splunk dashboard into a third-party <iframe> component. <iframe> stands for "inline frame", and is a web page component within which you can embed a dashboard. If you want to embed a Splunk dashboard into an outside web application, you must give this setting a value of "none". Otherwise, the third-party <iframe> won't let the user authenticate and use the dashboard that you embedded. The "SameSite=None" attribute in a cookie requires that you set the "Secure" attribute, otherwise the browser might reject the cookie. The Splunk web server adds the "Secure" attribute for connections over HTTPS by default. Use the 'tools.sessions.secure' setting to configure this behavior. You must also give the 'x_frame_options_sameorigin' setting a value of "false" to allow for the embedding of a Splunk dashboard in the <iframe>.	lax
`[settings]` `showProductMenu`	`<boolean>`Used to indicate visibility of product menu.	False.
`[settings]` `productMenuUriPrefix`	`<string>`The domain product menu links to. More Required if 'showProductMenu' is set to "true".
`[settings]` `productMenuLabel`	`<string>`Used to change the text label for product menu.	'My Splunk'
`[settings]` `showUserMenuProfile`	`<boolean>`Used to indicate visibility of 'Profile' link within user menu.	false
`[settings]` `x_frame_options_sameorigin`	`<boolean>`adds a X-Frame-Options header set to "SAMEORIGIN" to every response served More by cherrypy	true
`[settings]` `remoteUser`	`<http_header_string>`Remote user HTTP header sent by the authenticating proxy server. More This header should be set to the authenticated user. CAUTION: There is a potential security concern regarding the treatment of HTTP headers. Your proxy provides the selected username as an HTTP header as specified above. If the browser or other HTTP agent were to specify the value of this header, probably any proxy would overwrite it, or in the case that the username cannot be determined, refuse to pass along the request or set it blank. However, Splunk Web (specifically, cherrypy) normalizes headers containing the dash and the underscore to the same value. For example, USER-NAME and USER_NAME are treated as the same in Splunk Web. This means that if the browser provides REMOTE-USER and Splunk Web accepts REMOTE_USER, theoretically the browser could dictate the username. In practice, however, the proxy adds its headers last, which causes them to take precedence, making the problem moot. See also the 'remoteUserMatchExact' setting which can enforce more exact header matching.	'REMOTE_USER'
`[settings]` `remoteGroups`	`<http_header_string>`Remote groups HTTP header name sent by the authenticating proxy server. More This value is used by Splunk Web to match against the header name. The header value format should be set to comma-separated groups that the user belongs to. Example of header value: Products,Engineering,Quality Assurance	No default
`[settings]` `remoteGroupsQuoted`	`<boolean>`Whether or not the group header value can be comma-separated quoted entries. More This setting is considered only when 'remoteGroups' is set. If "true", the group header value can be comma-separated quoted entries. NOTE: Entries themselves can contain commas. Example of header value with quoted entries: "Products","North America, Engineering","Quality Assurance"	false (group entries should be without quotes.)
`[settings]` `remoteUserMatchExact`	`[0 \| 1]`Whether or not to consider dashes and underscores in a remoteUser header to be distinct. More When set to "1", considers dashes and underscores distinct (so "Remote-User" and "Remote_User" are considered different headers.) When set to 0, dashes and underscores are not considered to be distinct, to retain compatibility with older versions of Splunk software. Set to 1 when you set up SSO	0
`[settings]` `remoteGroupsMatchExact`	`[0 \| 1]`Whether or not to consider dashes and underscores in a remoteGroup header to be distinct. More When set to 1, considers dashes and underscores distinct (so "Remote-Groups" and "Remote_Groups" are considered different headers) When set to 0, dashes and underscores are not considered to be distinct, to retain compatibility with older versions of Splunk software. Set to 1 when you set up SSO	0
`[settings]` `SSOMode`	`[permissive \| strict]`Whether SSO behaves in either permissive or strict mode. More When set to "permissive": Requests to Splunk Web that originate from an untrusted IP address are redirected to a login page where they can log into Splunk Web without using SSO. When set to "strict": All requests to Splunk Web will be restricted to those originating from a trusted IP except those to endpoints that do not require authentication.	lax
`[settings]` `trustedIP`	`<ip_addresses>`IP addresses of the authenticating proxy (trusted IP). More Splunk Web verifies it is receiving data from the proxy host for all SSO requests. Set to a valid IP address to enable SSO. This setting can accept a list of IPs or networks, using the same format as the 'acceptFrom' setting.	not set; the normal value is the loopback address (127.0.0.1).
`[settings]` `allowSsoWithoutChangingServerConf`	`[0 \| 1]`Whether or not to allow SSO without setting the 'trustedIP' setting in server.conf as well as in web.conf. More If set to 1, enables web-based SSO without a 'trustedIP' setting configured in server.conf.	0
`[settings]` `ssoAuthFailureRedirect`	`<scheme>://<URL>`The redirect URL to use if SSO authentication fails. More Examples: http://www.example.com https://www.example.com	empty string; Splunk Web shows the default unauthorized error page if SSO authentication fails.
`[settings]` `export_timeout`	`<integer>`When exporting results, the number of seconds the server waits before closing the connection with splunkd. More If you do not set a value for export_timeout, Splunk Web uses the value for the 'splunkdConnectionTimeout' setting. Set 'export_timeout' to a value greater than 30 in normal operations.	No default
`[settings]` `server.thread_pool`	`<integer>`Determines the minimum number of threads the appserver is allowed to maintain. More The default value of this setting provides acceptable performance for most use cases. If you are experiencing issues with UI latency, you can increase the value based on need, to a maximum value of 200. Values that exceed 200 can cause memory spikes.	50
`[settings]` `server.socket_host`	`<ip_address>`Host values may be any IPv4 or IPv6 address, or any valid hostname. More The string 'localhost' is a synonym for '127.0.0.1' (or '::1', if your hosts file prefers IPv6). The string '0.0.0.0' is a special IPv4 entry meaning "any active interface" (INADDR_ANY), and "::" is the similar IN6ADDR_ANY for IPv6. Default (if 'listenOnIPV6' is set to "no": 0.0.0.0	"::" (otherwise)
`[settings]` `server.socket_timeout`	`<integer>`The timeout, in seconds, for accepted connections between the browser and Splunk Web	10
`[settings]` `listenOnIPv6`	`<no \| yes \| only>`By default, Splunk Web listens for incoming connections using IPv4 only. More To enable IPv6 support in splunkweb, set this to "yes". Splunk Web simultaneously listens for connections on both IPv4 and IPv6 protocols. To disable IPv4 entirely, set to "only", which causes SPlunk Web to exclusively accept connections over IPv6. To listen on an IPV6 address, also set 'server.socket_host' to "::".
`[settings]` `max_upload_size`	`<integer>`The hard maximum limit, in megabytes, of uploaded files.	500
`[settings]` `log.access_file`	`<filename>`The HTTP access log filename. More This file is written in the default $SPLUNK_HOME/var/log directory.	web_access.log
`[settings]` `log.access_maxsize`	`<integer>`The maximum size, in bytes, that the web_access.log file can be. More Comment out or set to 0 for unlimited file size. Splunk Web rotates the file to web_access.log.0 after the 'log.access_maxsize' is reached. See the 'log.access_maxfiles' setting to limit the number of backup files created.	25000000 (25 MB).
`[settings]` `log.access_maxfiles`	`<integer>`The maximum number of backup files to keep after the web_access.log file has reached its maximum size. More CAUTION: Setting this to very high numbers (for example, 10000) can affect performance during log rotation.	5 (if 'access_maxsize' is set)
`[settings]` `log.error_maxsize`	`<integer>`The maximum size, in bytes, the web_service.log can be. More Comment out or set to 0 for unlimited file size. Splunk Web rotates the file to web_service.log.0 after the max file size is reached. See 'log.error_maxfiles' to limit the number of backup files created.	25000000 (25 MB).
`[settings]` `log.error_maxfiles`	`<integer>`The maximum number of backup files to keep after the web_service.log file has reached its maximum size. More CAUTION: Setting this to very high numbers (for example, 10000) can affect performance during log rotations	5 (if 'access_maxsize' is set)
`[settings]` `log.screen`	`<boolean>`Whether or not runtime output is displayed inside an interactive TTY.	true
`[settings]` `request.show_tracebacks`	`<boolean>`Whether or not an exception traceback is displayed to the user on fatal exceptions.	true
`[settings]` `engine.autoreload.on`	`<boolean>`Whether or not the appserver will auto-restart if it detects a python file has changed.	false
`[settings]` `tools.sessions.on`	`true`Whether or not user session support is enabled. More Always set this to true.
`[settings]` `tools.sessions.timeout`	`<integer>`The number of minutes of inactivity before a user session is expired. More The countdown for this setting effectively resets every minute through browser activity until the 'ui_inactivity_timeout' setting is reached. Use a value of 2 or higher, as a value of 1 causes a race condition with the browser refresh, producing unpredictable behavior. Low values are not useful except for testing.	60
`[settings]` `tools.sessions.restart_persist`	`<boolean>`Whether or not the session cookie is deleted from the browser when the browser quits. More If set to "false", then the session cookie is deleted from the browser upon the browser quitting. If set to "true", then sessions persist across browser restarts, assuming the 'tools.sessions.timeout' has not been reached.	true
`[settings]` `tools.sessions.httponly`	`<boolean>`Whether or not the session cookie is available to running JavaScript scripts. More If set to "true", the session cookie is not available to running JavaScript scripts. This improves session security. If set to "false", the session cookie is available to running JavaScript scripts.	true
`[settings]` `tools.sessions.secure`	`<boolean>`Whether or not the browser must transmit session cookies over an HTTPS connection when Splunk Web is configured to serve requests using HTTPS (the 'enableSplunkWebSSL' setting is "true".) More If set to "true" and 'enableSplunkWebSSL' is also "true", then the browser must transmit the session cookie over HTTPS connections. This improves session security. See the 'enableSplunkWebSSL' setting for details on configuring HTTPS session support.	true
`[settings]` `tools.sessions.forceSecure`	`<boolean>`Whether or not the secure bit of a session cookie that has been sent over HTTPS is set. More If a client connects to a proxy server over HTTPS, and the back end connects to Splunk over HTTP, then setting this to "true" forces the session cookie being sent back to the client over HTTPS to have the secure bit set.	false
`[settings]` `response.timeout`	`<integer>`The timeout, in seconds, to wait for the server to complete a response. More Some requests, such as uploading large files, can take a long time.	7200 (2 hours).
`[settings]` `tools.sessions.storage_type`	`[file]`Specifies the session information storage mechanisms. More Set 'tools.sessions.storage_type' and 'tools.sessions.storage_path' to use RAM based sessions instead. Use an absolute path to store sessions outside of $SPLUNK_HOME.	storage_type=file, storage_path=var/run/splunk
`[settings]` `tools.sessions.storage_path`	`<filepath>`Specifies the session information storage mechanisms. More Set 'tools.sessions.storage_type' and 'tools.sessions.storage_path' to use RAM based sessions instead. Use an absolute path to store sessions outside of $SPLUNK_HOME.	storage_type=file, storage_path=var/run/splunk
`[settings]` `tools.decode.on`	`<boolean>`Whether or not all strings that come into CherryPy controller methods are decoded as unicode (assumes UTF-8 encoding). More CAUTION: Setting this to false will likely break the application, as all incoming strings are assumed to be unicode.	true
`[settings]` `tools.encode.on`	`<boolean>`Whether or not to encode all controller method response strings into UTF-8 str objects in Python. More CAUTION: Disabling this will likely cause high byte character encoding to fail.	true
`[settings]` `tools.encode.encoding`	`<codec>`Forces all outgoing characters to be encoded into UTF-8. More This setting only takes effect when 'tools.encode.on' is set to "true". By setting this to "utf-8", CherryPy default behavior of observing the Accept-Charset header is overwritten and forces utf-8 output. Only change this if you know a particular browser installation must receive some other character encoding (Latin-1 iso-8859-1, etc) CAUTION: Change this setting at your own risk.	utf-8
`[settings]` `tools.encode.text_only`	`<boolean>`No description in the spec.
`[settings]` `tools.proxy.on`	`<boolean>`Whether or not the Splunk platform instance is behind a reverse proxy server. More If set to "true", the instance assumes that it is behind a reverse proxy and uses HTTP header information from the proxy to log access requests, secure its cookies properly, and generate valid URLs for redirect responses. All of the instance's HTTP services will use information from "X-Forwarded-*", "Front-End-Https", and "X-Url-Scheme" headers, where available, to override what it receives from proxied requests. If you set this to "true", you must also set 'tools.proxy.base' to a valid host name and network port. If set to "false", the instance relies on its own internal HTTP server settings and the immediate client's HTTP headers for the information needed for access request logging, cookie securing, and redirect URL generation.	false
`[settings]` `tools.proxy.base`	`<scheme>://<URL>`The proxy base URL in Splunk Web.	empty string
`[settings]` `pid_path`	`<filepath>`Specifies the path to the Process IDentification (pid) number file. More Must be set to "var/run/splunk/splunkweb.pid". CAUTION: Do not change this parameter.
`[settings]` `enabled_decomposers`	`<intention> [, <intention>]...`Added in Splunk 4.2 as a short term workaround measure for apps which happen to still require search decomposition, which is deprecated with 4.2. More Search decomposition will be entirely removed in a future release. A comma-separated list of allowed intentions. Modifies search decomposition, which is a Splunk Web internal behavior. Can be controlled on a per-app basis. If set to an empty string, no search decomposition occurs, which causes some usability problems with Report Builder. The current possible values are: addcommand, stats, addterm, addtermgt, addtermlt, setfields, excludefields, audit, sort, plot	"plot", leaving only the plot intention enabled.
`[settings]` `simple_xml_perf_debug`	`<boolean>`Whether or not Simple XML dashboards log performance metrics to the browser console. More If set to "true", Simple XML dashboards log some performance metrics to the browser console.	false
`[settings]` `job_default_auto_cancel`	`<integer>`The amount of time, in seconds, of inactivity in Splunk Web, after which the search job automatically cancels.	62
`[settings]` `job_min_polling_interval`	`<integer>`The minimum polling interval, in milliseconds, for search jobs. More This is the intial wait time for fetching results. The poll period increases gradually from the minimum interval to the maximum interval when search is in a queued or parsing state (and not a running state) for some time. Set this value between 100 and 'job_max_polling_interval' milliseconds.	100
`[settings]` `job_max_polling_interval`	`<integer>`The maximum polling interval, in milliseconds, for search jobs. More This is the maximum wait time for fetching results. In normal operations, set to 3000.	1000
`[settings]` `acceptFrom`	`<network_acl> ...`Lists a set of networks or addresses from which to accept connections. More Separate multiple rules with commas or spaces. Each rule can be in one of the following formats: 1. A single IPv4 or IPv6 address (examples: "10.1.2.3", "fe80::4a3") 2. A Classless Inter-Domain Routing (CIDR) block of addresses (examples: "10/8", "192.168.1/24", "fe80:1234/32") 3. A DNS name, possibly with a "" used as a wildcard (examples: "myhost.example.com", ".splunk.com") 4. "", which matches anything You can also prefix an entry with '!' to cause the rule to reject the connection. The input applies rules in order, and uses the first one that matches. For example, "!10.1/16, " allows connections from everywhere except the 10.1.. network.	"*" (accept from anywhere)
`[settings]` `maxThreads`	`<integer>`The number of threads that can be used for active HTTP transactions. More This value can be limited to constrain resource usage. If set to 0, a limit is automatically picked based on estimated server capacity. If set to a negative number, no limits are enforced.	0
`[settings]` `maxSockets`	`<integer>`The number of simultaneous HTTP connections that Splunk Web can accept. More This value can be limited to constrain resource usage. If set to 0, a limit is automatically picked based on estimated server capacity. If set to a negative number, no limits are enforced.	0
`[settings]` `keepAliveIdleTimeout`	`<integer>`How long, in seconds, that the Splunk Web HTTP server lets a keep-alive connection remain idle before forcibly disconnecting it. More If this number is less than 7200, it will be set to 7200.	7200
`[settings]` `busyKeepAliveIdleTimeout`	`<integer>`How long, in seconds, that the Splunk Web HTTP server lets a keep-alive connection remain idle while in a busy state before forcibly disconnecting it. More CAUTION: Too large a value that can result in file descriptor exhaustion due to idling connections. If this number is less than 12, it will be set to 12.	12
`[settings]` `forceHttp10`	`auto\|never\|always`How the HTTP server deals with HTTP/1.0 support for incoming clients. More When set to "always", the REST HTTP server does not use some HTTP 1.1 features such as persistent connections or chunked transfer encoding. When set to "auto", it limits HTTP 1.1 features only if the client sent no User-Agent header, or if the user agent is known to have bugs in its HTTP/1.1 support. When set to "never", it always allows HTTP 1.1, even to clients it suspects might be buggy.	auto
`[settings]` `crossOriginSharingPolicy`	`<origin_acl> ...`A list of HTTP Origins for which to return Access-Control-Allow-* (CORS) headers. More These headers tell browsers that Splunk Web trusts web applications at those sites to make requests to the REST interface. The origin is passed as a URL without a path component (for example "https://app.example.com:8000") This setting can take a list of acceptable origins, separated by spaces and/or commas Each origin can also contain wildcards for any part. Examples: ://app.example.com: (either HTTP or HTTPS on any port) https://.example.com (any host under example.com, including example.com itself) An address can be prefixed with a '!' to negate the match, with the first matching origin taking precedence. For example, "!://evil.example.com:* ://.example.com:" to not avoid matching one host in a domain. "" can also be used to match all origins.	empty string
`[settings]` `crossOriginSharingHeaders`	`<string>`A list of the HTTP headers to which splunkd sets "Access-Control-Allow-Headers" when replying to Cross-Origin Resource Sharing (CORS) preflight requests. More The "Access-Control-Allow-Headers" header is used in response to a CORS preflight request to tell browsers which HTTP headers can be used during the actual request. A CORS preflight request is a CORS request that checks to see if the CORS protocol is understood and a server is aware of using specific methods and headers. This setting can take a list of acceptable HTTP headers, separated by commas. A single "*" can also be used to match all headers.	Empty string.
`[settings]` `allowSslCompression`	`<boolean>`Whether or not the server lets clients negotiate SSL-layer data compression. More If set to "true", the server lets clients negotiate SSL-layer data compression. The HTTP layer has its own compression layer which is usually sufficient. In Splunk Enterprise version 10.4 and later, this setting has no effect when TLS 1.3 is enabled. TLS 1.3 does not support SSL-layer compression. To use compression for HTTPS connections with TLS 1.3, both the HTTP client and the server must enable HTTP-layer compression. To enable server-side compression, set 'enable_gzip' to "true". Most modern HTTP clients and browsers request compression by default.	false
`[settings]` `allowSslRenegotiation`	`<boolean>`Whether or not the server lets clients renegotiate SSL connections. More In the SSL protocol, a client may request renegotiation of the connection settings from time to time. Setting this to "false" causes the server to reject all renegotiation attempts, breaking the connection. This limits the amount of CPU a single TCP connection can use, but it can cause connectivity problems especially for long-lived connections.	true
`[settings]` `sslServerHandshakeTimeout`	`<integer>`The timeout, in seconds, for an SSL handshake to complete between an SSL client and the Splunk SSL server. More If the SSL server does not receive a "Client Hello" from the SSL client within 'sslServerHandshakeTimeout' seconds, the server terminates the connection.	60
`[settings]` `sendStrictTransportSecurityHeader`	`<boolean>`Whether or not the REST interface sends a "Strict-Transport-Security" header with all responses to requests made over SSL. More If set to "true", the REST interface sends a "Strict-Transport-Security" header with all responses to requests made over SSL. This can help avoid a client being tricked later by a Man-In-The-Middle attack to accept a non-SSL request. This requires a commitment that no non-SSL web hosts will ever be run on this hostname on any port. For example, if splunkweb is in default non-SSL mode this can break the ability of browser to connect to it. Enable this setting with caution.	false
`[settings]` `includeSubDomains`	`<boolean>`Whether or not the REST interface includes the "includeSubDomains" directive in the "Strict-Transport-Security" header with all responses to requests made over SSL. More If set to "true", all subdomains of the current domain name will be enforced with the same HTTP Strict-Transport-Security (HSTS) policy. Can only be enabled if 'sendStrictTransportSecurityHeader' is set to "true". Enable this setting with caution. Enabling 'includeSubDomains' can have consquences by blocking access to subdomains that can only be served over HTTP.	false
`[settings]` `preload`	`<boolean>`Whether or not the REST interface includes the "preload" directive in the "Strict-Transport-Security" header with all responses to requests made over SSL. More If set to "true", domains can be loaded on the HSTS preload list service that the Chromium project maintains for Google Chrome and various other browsers. Can only be enabled if 'sendStrictTransportSecurityHeader' is set to "true". Enable this setting with caution. Enabling 'preload' can have consequences by preventing users from accessing your domain and subdomains in the case of switching back to HTTP.	false
`[settings]` `dedicatedIoThreads`	`<integer>`The number of dedicated threads to use for HTTP input/output operations. More If set to zero, HTTP I/O is performed in the same thread that accepted the TCP connection. If set set to a non-zero value, separate threads run to handle the HTTP I/O, including SSL encryption. Typically this does not need to be changed. For most usage scenarios using the same the thread offers the best performance.	0
`[settings]` `replyHeader.<name>`	`<string>`Adds a static header to all HTTP responses that this server generates. More For example, "replyHeader.My-Header = value" causes Splunk Web to include the response header "My-Header: value" in the reply to every HTTP request to it.	No default
`[settings]` `termsOfServiceDirectory`	`<directory>`The directory to look in for a "Terms of Service" document that each user must accept before logging into Splunk Web. More Inside the directory the TOS should have a filename in the format "<number>.html" <number> is in the range 1 to 18446744073709551615. The active TOS is the filename with the larger number. For example, if there are two files in the directory named "123.html" and "456.html", then 456 will be the active TOS version. If a user has not accepted the current version of the TOS, they must accept it the next time they try to log in. The acceptance times will be recorded inside a "tos.conf" file inside an app called "tos". If the "tos" app does not exist, you must create it for acceptance times to be recorded. The TOS file can either be a full HTML document or plain text, but it must have the ".html" suffix. You do not need to restart Splunk Enterprise when adding files to the TOS directory.	empty string (no TOS)
`[settings]` `appServerProcessShutdownTimeout`	`<nonnegative integer>[smhd]`The amount of time splunkd waits for a Python-based application server process to handle outstanding or existing requests. More If a Python-based application server process "outlives" this timeout, splunkd forcibly terminates the process.	'30s' (30 seconds).
`[settings]` `appServerProcessLogStderr`	`<boolean>`If set to true, messages written to the standard error stream by the Python-based application server processes will be logged to splunkd.log under the "UiAppServer" channel. More This can be useful when debugging issues when the appserver process fails to start However, some appserver code may print sensitive information such as session ID strings to standard error so this defaults to disabled.	false
`[settings]` `enableWebDebug`	`<boolean>`Whether or not the debug REST endpoints are accessible, for example., /debug/**splat.	false
`[settings]` `allowableTemplatePaths`	`<directory> [, <directory>]...`A comma-separated list of template paths that might be added to the template lookup allow list. More Paths are relative to $SPLUNK_HOME.	empty string
`[settings]` `enable_risky_command_check`	`<boolean>`Whether or not checks for data-exfiltrating search commands are enabled.	true
`[settings]` `enable_risky_command_check_dashboard`	`<boolean>`Whether or not checks for data-exfiltrating search commands within a dashboard are enabled.	true
`[settings]` `enableSearchJobXslt`	`<boolean>`REMOVED. This setting no longer has any effect. More Whether or not the search job request accepts XML stylesheet language (XSL) as input to format search results. If set to "true", the search job request accepts XSL as input to format search results. If set to "false", the search job request does not accept XSL as input to format search results.	false
`[settings]` `customFavicon`	`<pathToMyFile, myApp:pathToMyFile, or blank for default>`Customizes the favicon image across the entire application. More If no favicon image file, the favicon default: the Splunk favicon. Supported favicon image files are .ico files, and should be square images. Place the favicon image file in the default or manual location: Default destination folder: $SPLUNK_HOME/etc/apps/search/appserver/static/customfavicon. Example: If your favicon image is located at $SPLUNK_HOME/etc/apps/search/appserver/static/customfavicon/favicon.ico, set 'customFavicon' to "customfavicon/favicon.ico". Manual location: Place the file in $SPLUNK_HOME/etc/apps/<myApp>/appserver/static/<pathToMyFile>, and set 'customFavicon' to "<myApp:pathToMyFile>".	not set, Splunk Web uses the Splunk favicon.
`[settings]` `loginCustomLogo`	`<fullUrl, pathToMyFile, myApp:pathToMyFile, or blank for default>`Customizes the logo image on the login page. More If no image file, the logo Default: the Splunk logo. Supported images are: Full URL image file (secured or not secured), such as https://www.splunk.com/logo.png or http://www.splunk.com/logo.png. Image file, such as .jpg or .png. All image formats are supported. Place logo image file in default or manual location: Default destination folder: $SPLUNK_HOME/etc/apps/search/appserver/static/logincustomlogo. Example: If your logo image is located at $SPLUNK_HOME/etc/apps/search/appserver/static/logincustomlogo/logo.png, type loginCustomLogo = logincustomlogo/logo.png. Manual location: $SPLUNK_HOME/etc/apps/<myApp>/appserver/static/<pathToMyFile>, and type loginCustomLogo = <myApp:pathToMyFile>. The maximum image size is 485px wide and 100px high. If the image exceeds these limits, the image is automatically resized.	not set, Splunk Web uses the Splunk logo.
`[settings]` `loginBackgroundImageOption`	`[default\| custom \| none]`Controls display of the background image of the login page. More "default" displays the Splunk default background image. "custom" uses the background image defined by the backgroundImageCustomName setting. "none" removes any background image on the login page. A dark background color is applied.	"default".
`[settings]` `loginCustomBackgroundImage`	`<pathToMyFile or myApp:pathToMyFile>`Customizes the login page background image. More Supported image files include .jpg, .jpeg or .png with a maximum file size of 20MB. A landscape image is recommended, with a minimum resolution of 1024x640 pixels. Using Splunk Web: Upload a custom image to a manager page under General Settings. The login page background image updates automatically. Using the CLI or a text editor: Set 'loginBackgroundImageOption' to "custom". Place the custom image file in the default or manual location: Default destination folder: $SPLUNK_HOME/etc/apps/search/appserver/static/logincustombg. Example: If your image is located at $SPLUNK_HOME/etc/apps/search/appserver/static/logincustombg/img.png, set 'loginCustomBackgroundImage' to "logincustombg/img.png". Manual location: $SPLUNK_HOME/etc/apps/<myApp>/appserver/static/<pathToMyFile>, and set 'loginCustomBackgroundImage' to "<myApp:pathToMyFile>". The login page background image updates automatically.	not set (If no custom image is used, the default Splunk background image displays).
`[settings]` `loginFooterOption`	`[default \| custom \| none]`Controls display of the footer message of the login page. More "default" displays the Splunk copyright text. "custom" uses the footer text defined by the loginFooterText setting. "none" removes any footer text on the login page. NOTE: This option is made available only to OEM customers participating in the Splunk OEM Partner Program and is subject to the relevant terms of the Master OEM Agreement. All other customers or partners are prohibited from removing or altering any copyright, trademark, and/or other intellectual property or proprietary rights notices of Splunk placed on or embedded in any Splunk materials.	"default".
`[settings]` `loginFooterText`	`<footer_text>`The text to display in the footer of the login page. More Supports any text, including HTML. The Splunk platform sanitizes HTML for security purposes by removing potentially dangerous tags and attributes. To display, the parameter 'loginFooterOption' must be set to "custom".
`[settings]` `loginDocumentTitleOption`	`[default \| custom \| none]`Controls display of the document title of the login page. More "default" displays: "<page_title> \| Splunk". "none" removes the branding on the document title of the login page: "<page_title>". "custom" uses the document title text defined by the loginDocumentTitleText setting. NOTE: This option is made available only to OEM customers participating in the Splunk OEM Partner Program and is subject to the relevant terms of the Master OEM Agreement. All other customers or partners are prohibited from removing or altering any copyright, trademark, and/or other intellectual property or proprietary rights notices of Splunk placed on or embedded in any Splunk materials.	"default".; "default".
`[settings]` `loginDocumentTitleText`	`<document_title_text>`The text to display in the document title of the login page. More Text only. To display, the parameter 'loginDocumentTitleOption' must be set to "custom".
`[settings]` `firstTimeLoginMessageOption`	`[default \| custom \| none]`Controls display of the first time login message of the login page. More "default" displays: "If you installed this instance, use the username and password you created at installation. Otherwise, use the username and password that your Splunk administrator gave you. If you've forgotten your credentials, contact your Splunk administrator." "none" removes the branding on the first time message of the login page: "". "custom" uses the document title text defined by the firstTimeLoginMessage setting. CAUTION: This setting is only configurable for original equipment manufacturer (OEM) customers that participate in the Splunk OEM Partner Program. It is subject to the terms of the Master OEM Agreement. If you are not a member of this program, you MUST NOT remove or alter any Splunk copyright, trademark, and/or other intellectual property or proprietary rights notices that Splunk embeds into any of its material. This action includes but is not limited to configuring this setting.	default
`[settings]` `firstTimeLoginMessage`	`<document_title_text>`The text to display in the first time message of the login page. More Text only. To display this message, you must first set 'firstTimeLoginMessageOption' to "custom".
`[settings]` `loginPasswordHint`	`<default_password_hint>`The text to display the password hint at first time login on the login page. More Text only.	"The password you created when you installed this instance"
`[settings]` `appNavReportsLimit`	`<integer>`Maximum number of reports to fetch to populate the navigation drop-down menu of an app. More An app must be configured to list reports in its navigation XML configuration before it can list any reports. Set to -1 to display all the available reports in the navigation menu. NOTE: Setting to either -1 or a value that is higher than the default might result in decreased browser performance due to listing large numbers of available reports in the drop-down menu.	500
`[settings]` `simplexml_dashboard_create_version`	`<string>`DEPRECATED. The dashboard framework uses the latest Simple XML dashboard version for newly created dashboards. More CAUTION: Do not change this setting without contacting Splunk Support. The Simple XML dashboard version used for newly created Simple XML dashboards. Version must be a valid Simple XML dashboard version of the form 1.x (for example, 1.1).	1.1
`[settings]` `allow_insecure_libraries_toggle`	`<boolean>`Determines whether or not Splunk Web can use insecure libraries which Splunk will deprecate. More A value of "false" means Splunk Web cannot use insecure libraries. CAUTION: Do not change this setting.	true

`[remoteUI]`

Set options to control the loading of remote hosted UI pages in Splunk Cloud
If you do not specify an entry for each setting, Splunk Web uses the default value.

Setting	Description	Default
`[remoteUI]` `optInRemoteUI`	`<boolean>`This setting maps to the Splunk Cloud "Automatic UI updates" menu item. More Determines whether Splunk Cloud fetches configured UI pages from an external content delivery network or from the $SPLUNK_HOME directory.	false
`[remoteUI]` `allowExternalRemote`	`<boolean>`Determines whether or not Splunk Web displays the "Automatic UI updates" menu item.	false

`[admin_config_ui]`

Set the options to control the display of additional dashboard configuration pages.
If you do not specify an entry for each setting, Splunk Web uses the default value.

Setting	Description	Default
`[admin_config_ui]` `dashboards_trusted_domains_list`	`<boolean>`Whether or not Splunk Web displays the Dashboards Trusted Domains List page. More A value of "true" means that Splunk Web displays the Dashboards Trusted Domains List page. A value of "false" means that Splunk Web doesn't display the Dashboards Trusted Domains List page.	true

`[smc]`

Setting	Description	Default
`[smc]` `remoteRoot`	`<string>`The URL of the content delivery network that hosts the remote UI assets for Splunk Assist. More If this setting has no value, the client uses a URL that points to an API that the Teleport Supervisor that runs on the local node exposes. This API serves the remote UI assets for Splunk Assist. Optional.	Not set.

`[endpoint:<python_module_name>]`

Registers a custom python CherryPy endpoint.
The expected file must be located at: $SPLUNK_HOME/etc/apps/<APP_NAME>/appserver/controllers/<PYTHON_NODULE_NAME>.py
This module's methods will be exposed at /custom/<APP_NAME>/<PYTHON_NODULE_NAME>/<METHOD_NAME>

`[expose:<unique_name>]`

Registers a splunkd-based endpoint that should be made available to the UI under the "/splunkd" and "/splunkd/__raw" hierarchies.
The name of the stanza does not matter as long as it begins with "expose:"
Each stanza name must be unique.

Setting	Description	Default
`[expose:<unique_name>]` `pattern`	`<url_pattern>`The pattern to match under the splunkd /services hierarchy. More For instance, "a/b/c" would match URIs "/services/a/b/c" and "/servicesNS///a/b/c", The pattern cannot include leading or trailing slashes. Inside the pattern an element of "" matches a single path element. For example, "a//c" would match "a/b/c" but not "a/1/2/c". A path element of "" matches any number of elements. For example, "a//c" would match both "a/1/c" and "a/1/2/3/c". A path element can end with a "" to match a prefix. For example, "a/elem-/b" would match "a/elem-123/c".
`[expose:<unique_name>]` `methods`	`<method_lists>`A comma-separated list of methods to allow from the web browser (example: "GET,POST,DELETE").	"GET"
`[expose:<unique_name>]` `oidEnabled`	`[0 \| 1]`Whether or not a REST endpoint is capable of taking an embed-id as a query parameter. More If set to 1, the endpoint is capable of taking an embed-id as a query parameter. This is only needed for some internal splunk endpoints, you probably should not specify this for app-supplied endpoints	0
`[expose:<unique_name>]` `skipCSRFProtection`	`[0 \| 1]`Whether or not Splunk Web can safely post to an endpoint without applying Cross-Site Request Forgery (CSRF) protection. More If set to 1, tells Splunk Web that it is safe to post to this endpoint without applying CSRF protection. This should only be set on the login endpoint (which already contains sufficient auth credentials to avoid CSRF problems).	0
`[expose:<unique_name>]` `allowRemoteProxy`	`<boolean>`Determines whether or not splunkd lets the exposed REST endpoint be proxied to remote nodes using the "remote-proxy" REST endpoint. More If set to "true", splunkd will let requests be proxied to remote nodes through the "remote-proxy". If set to "false", splunkd will not let requests be proxied to remote nodes through the "remote-proxy". This setting only works for full URIs without wildcards.	false
`[expose:<unique_name>]` `remoteProxyLegacyRequireDoubleEncodedUriArgs`	`<boolean>`DEPRECATED. More NOTE: Do not configure for new use cases. Determines whether the remote-proxy endpoint requires HTTP GET arguments to be double-encoded before it can forward them to the destination endpoint. A value of "true" means the GET arguments must be double-encoded, for example: https://<server>:<port>/services/remote-proxy/<REST endpoint>?proxy_to=<proxy_to>&param1%3Dval1%26param2%3Dval2%26param3=val3'. A value of "false" means the GET arguments don't need to be double-encoded, as the REST endpoint handles the encoding, for example: https://<server>:<port>/services/remote-proxy/<REST endpoint>?proxy_to=<proxy_to>&param1=val1&param2=val2&param3=val3'.	false

`[nghttpx_server]`

Setting	Description	Default
`[nghttpx_server]` `auto_start`	`<boolean>`Whether or not the Nghttpx proxy server automatically starts when the Splunk platform starts. More A value of "true" means the server starts automatically. A value of "false" means the server does not start automatically.	false
`[nghttpx_server]` `httpport`	`<unsigned integer>`The Transmission Control Protocol (TCP) port on which the Nghttpx proxy server listens for incoming connections. More This setting is required for Nghttpx to start. If you omit this setting or set it to 0, the server does not start an Nghttpx listener. Because the server must use Secure Sockets Layer (SSL), set this port to the Hypertext Transfer Protocol Secure (HTTPS) port number.	9000
`[nghttpx_server]` `workers`	`<unsigned integer>`The number of worker threads in the Nghttpx process.	1
`[nghttpx_server]` `backendConnectionsPerFrontend`	`<unsigned integer>`The maximum number of backend concurrent connections or streams per frontend. More This setting is meaningful when the browser and Nghttpx use Hypertext Transfer Protocol version 2 (HTTP/2). A value of "0" means there is no limit to the number of connections.	0
`[nghttpx_server]` `privKeyPath`	`<path>`The path to the file that contains the Nghttpx server Secure Sockets Layer (SSL) certificate private key. More You can specify an absolute path to an external key. The Splunk daemon (splunkd) interprets a relative path as relative to the $SPLUNK_HOME directory. The default can vary. By default, Nghttpx uses the same private key specified for Splunk Web.
`[nghttpx_server]` `serverCert`	`<path>`The full path to the Privacy Enhanced Mail (PEM) format Nghttpx server certificate file. More The file can also contain root and intermediate certificates. The Splunk daemon (splunkd) interprets a relative path as relative to the $SPLUNK_HOME directory. The default can vary. By default, Nghttpx uses the same certificate file specified for Splunk Web.
`[nghttpx_server]` `sslPassword`	`<string>`The password that protects the private key specified by 'privKeyPath'. More If Nghttpx uses the same private key specified for Splunk Web, it also uses the same password specified for Splunk Web. Optional.	Not set

Example

[settings]
startwebserver = 1
httpport = 8000
enableSplunkWebSSL = true
privKeyPath = /opt/splunk/etc/auth/splunkweb/privkey.pem
serverCert = /opt/splunk/etc/auth/splunkweb/cert.pem
sslVersions = tls1.2,tls1.3
tools.sessions.timeout = 60
allowedSplunkWebClientNetlocList = splunk.example.com,splunk.example.com:8000
allowedSplunkWebClientSchemeList = https
crossOriginSharingPolicy = https://dashboards.example.com
SSOMode = strict
trustedIP = 10.1.2.3
remoteUser = X-Remote-User
remoteGroups = X-Remote-Groups
ssoAuthFailureRedirect = https://splunk.example.com/en-US/account/insufficient_permission
dashboard_html_injection_mode = disabled
enable_insecure_login = false
enable_insecure_pdfgen = false
x_frame_options_sameorigin = true

HTTPS-only Splunk Web, hardened TLS versions, strict host/origin validation, a single trusted CORS origin, ProxySSO in strict mode via a trusted reverse proxy, and every insecure/legacy toggle explicitly left off.

Validation

Confirm enableSplunkWebSSL = true in production -- plaintext HTTP to the UI exposes session cookies and credentials.
Set allowedSplunkWebClientNetlocList explicitly rather than leaving it permissive, especially when Splunk Web sits behind a reverse proxy or load balancer with a different externally-visible hostname.
Leave enable_insecure_login, enable_insecure_pdfgen disabled unless a specific, understood compatibility need requires them.
Set SSOMode = strict only once the trusted proxy is verified to always inject remoteUser/remoteGroups and trustedIP is scoped to the proxy's real address -- a permissive/misconfigured trustedIP lets any upstream host assert an identity.
Scope crossOriginSharingPolicy to specific known origins, never a blanket wildcard.
Leave dashboard_html_injection_mode at disabled unless a specific dashboard genuinely requires raw HTML and its editors are fully trusted -- it's a stored-XSS surface.
Remember this is a distinct file from server.conf's [sslConfig]/[httpServer] -- securing the REST/management port doesn't secure the browser-facing UI, and vice versa.

← Back to References

References / Splunk platform configuration

Web Feature Flag Configuration

web-features.conf holds Splunk Web's feature-flag toggles -- one [feature:<name>] stanza per feature area, almost always gating a single UI capability with one or more booleans. Settings are replicated in a search head cluster environment. A large share of entries in any given release are marked DEPRECATED or REMOVED, reflecting the file's role as a rolling record of in-progress UI migrations rather than a stable schema. Backs the Splunk Taxonomy's Web Feature Flag object (SOT-11.05.03).

Definition

Each stanza is named [feature:<name>] and controls one Splunk Web feature area. Most settings are plain <boolean> values with no interdependency across stanzas. Because features graduate from preview to general availability (or get pulled) across releases, the majority of settings in a given version carry a DEPRECATED or REMOVED annotation -- meaning the setting either has no effect anymore or is scheduled for removal without further notice, and should not be relied upon for durable configuration.

File locations

Configuration file: web-features.conf.

Scope	Path
System	`$SPLUNK_HOME/etc/system/{default,local}/web-features.conf`
App	`$SPLUNK_HOME/etc/apps/<app_name>/{default,local}/web-features.conf`

Dashboards CSP & trusted domains

[feature:dashboards_csp] -- the one stanza in this file with real security consequence, restricting which external domains Studio and Classic Dashboards can load content from or redirect to.

Setting	Description
`enable_dashboards_external_content_restriction`	When `true`, Studio Dashboards get a Content-Security-Policy header blocking images from domains outside the Dashboards Trusted Domains List (DTDL); Classic Dashboards show a warning modal for external URLs outside the DTDL. Default `true`.
`enable_dashboards_redirection_restriction`	When `true`, redirecting to an external URL not in the DTDL shows a warning modal the user must confirm. Default `true`.
`dashboards_trusted_domain.<name>`	One domain per numbered/named line building the DTDL (max 6500 characters total); supports a bare `*` to trust every domain. Governs both the CSP header (Studio) and the warning-modal check (Classic).
`internal.dashboards_trusted_domain.<name>`	Splunk-shipped trusted domains, combined with the user-defined DTDL. Not meant to be hand-edited.

Dashboard Studio & PDF generation

[feature:dashboard_studio] gates Dashboard Studio internals -- Dynamic Options Syntax execution mode, observability integrations, SPL2 data sources, and the Studio Extension Framework for custom visualizations -- almost all flagged "Do not modify this value." [feature:pdfgen] controls scheduled-export image quality via activate_scheduled_export_upscaling (default true).

Page migration flags

[feature:page_migration] is the largest stanza in the file: roughly two dozen enable_<area>_vnext booleans, each toggling whether Splunk Web serves a modernized React-implemented page or the legacy XML/Backbone/Python one for a specific admin or data-management screen.

Representative setting	Legacy page it replaces
`enable_data_ui_workflow-actions_vnext`	Workflow actions management page
`enable_authentication_providers_LDAP_vnext`	LDAP configuration page (XML)
`enable_saml_vnext`	SAML configuration page (Backbone)
`enable_data_indexes_vnext` / `_cloud_vnext`	Classic Indexes management page
`enable_admin_directory_vnext`	"All configurations" page (Python/XML)
`enable_federation_page_vnext`	Legacy federated-search page

Several related flags -- enable_triggered_alerts_vnext, enable_home_vnext, enable_datasets_vnext, enable_authorization_roles_vnext, enable_authentication_users_vnext -- are REMOVED and have no effect; check the current release's spec before relying on any specific flag.

App server & security hardening

Setting	Description
`[feature:appserver]` `python.required`	Comma-separated list of supported Python versions for the app server tier; takes precedence over the deprecated `python.version`. Change only when directed by Splunk Support.
`[feature:appserver_security]` `deactivate_custom_mako_templates`	When `true`, blocks custom Mako templates apps ship under `appserver/templates`/`appserver/modules`. First-party templates are unaffected. Default `false`.
`deactivate_custom_cherrypy_controllers`	When `true`, blocks custom app CherryPy controllers -- `/custom/<app>/*` routes 404 instead of registering. Does not affect REST endpoints, views, or static assets. Default `false`.

Other feature areas

The remaining stanzas each gate a single, narrow capability: [feature:spotlight_search] (Settings-menu search bar), [feature:search_ai_assistant] and [feature:splunk_ai_canvas] (AI-assisted SPL and AI Canvas, the latter Cloud-only), [feature:spl2] (SPL2 language support), [feature:splunk_oauth_clients] (Splunk OAuth client management pages), [feature:federated_search] enable_ipv6_validations (IPv6/CIDR input acceptance), [feature:knowledge_object_favorites] (favoriting dashboards/reports), [feature:modern-nav] (the Layout API version), and [feature:new_data_management_experience] (Data Management app-home routing). Nearly all default to enabled and are flagged "Do not modify."

All settings

Every stanza and setting in web-features.conf.spec from Splunk Enterprise 10.4.2: 75 settings across 28 stanzas. Descriptions use the spec's own wording -- the first line shows here and More opens the rest. The Default column is filled only where the spec gives a Default: line.

`[feature:search_v2_endpoint]`

Setting	Description	Default
`[feature:search_v2_endpoint]` `enable_search_v2_endpoint`	`<boolean>`REMOVED. This setting no longer has any effect. More Determines whether Splunk Web uses the v2 search endpoint. A value of "true" means Splunk Web uses the v2 search endpoint.	true

`[feature:dashboards_csp]`

Setting	Description	Default
`[feature:dashboards_csp]` `enable_dashboards_external_content_restriction`	`<boolean>`Whether or not Splunk Web restricts the loading of external content in Studio Dashboards or Classic Dashboards. More A value of "true" means the following: For Studio Dashboards, Splunk Web sets the Content-Security-Policy header, causing the browser to block images from external domains not included in the Dashboards Trusted Domains List (DTDL). For Classic Dashboards, when the user loads a dashboard with external URLs not included in the DTDL, the user sees a warning modal. The user can decide to load the dashboard with external content or without external content. A value of "false" means the following: For Studio Dashboards, Splunk Web does not set the Content-Security-Policy header. All external images load as usual and the browser does not block images. For Classic Dashboards, all external content loads without warnings.	true
`[feature:dashboards_csp]` `enable_dashboards_redirection_restriction`	`<boolean>`Whether or not Splunk Web restricts redirecting to external content from Studio Dashboards or Classic Dashboards. More A value of "true" means that the user sees a warning modal when redirecting to an external URL not included in the Dashboards Trusted Domains List. The user has the option to continue with the redirect or to cancel the redirect. A value of "false" means that nothing warns the user when redirecting to an external URL.	true
`[feature:dashboards_csp]` `dashboards_trusted_domain.<name>`	`<string>`A list of external domains that Splunk Web trusts for content loads and redirects. This list is called the Dashboards Trusted Domains List (DTDL). More You must prefix each trusted domain on its own line with the string "dashboards_trusted_domain." The list has a maximum size of 6500 characters, after which any excess content will be ignored. If web-features.conf:'enable_dashboards_external_content_restriction' has a value of "true", then the following happens: In Studio Dashboards, Splunk Web includes the DTDL in the Content-Security-Policy (CSP) page header. The CSP header determines which domains Studio Dashboard can use to load images. By default, 'self', data:, and blob: are added to the CSP header. The browser prevents the loading of images from URLs not within the DTDL. In Classic Dashboards, if the dashboard uses external URLs not included in the DTDL to load content, the user sees a warning modal. If web-features.conf:'enable_dashboards_external_content_restriction' has a value of "false" then the DTDL does not effect Dashboard loading and external content loads without warning. If web-features.conf:'enable_dashboards_redirection_restriction' has a value of "true", users see a warning modal when redirecting to an external URL not included in the DTDL. If web-features.conf:'enable_dashboards_redirection_restriction' has a value of "false" then the DTDL does not affect when a user redirects to an external URL, and no warning modal appears. Examples: Only allow images from splunk.com and mozilla.org: dashboards_trusted_domain.endpoint1 = www.splunk.com dashboards_trusted_domain.endpoint2 = www.mozilla.org Allow images from all external domains: dashboards_trusted_domain.endpoint1 = * Only allow images starting with splunk.com/download/ dashboards_trusted_domain.endpoint1 = www.splunk.com/download/ Further documentation can be found by: searching for "Content Security Policy" on the Mozilla Developer Network Docs website. searching for and reading the Content Security Policy Quick Reference Guide.	Not set
`[feature:dashboards_csp]` `internal.dashboards_trusted_domain.<name>`	`<string>`A list of internal domains that Splunk Web trusts for content loading and redirection. When checking for URL trustworthiness, these domains combine with the Dashboards Trusted Domains List. Refer to web-features.conf:'dashboards_trusted_domain.<name>' for information on usage. More Do not modify these values.	List of trusted Splunk Platform domains.

`[feature:highcharts_accessibility]`

Setting	Description	Default
`[feature:highcharts_accessibility]` `disable_highcharts_accessibility`	`<boolean>`Disable accessibility module in the highcharts charting library. More DEPRECATED. A value of "true" means that Splunk Web will not use the accessibility module in the Highcharts charting library. CAUTION: Do not change this setting.	true

`[feature:dashboard_studio]`

Setting	Description	Default
`[feature:dashboard_studio]` `activate_downsampling`	`<boolean>`DEPRECATED: This setting has no effect. It will be removed without notice in a future release.
`[feature:dashboard_studio]` `activate_dsl_webworkers_for_visualizations`	`<boolean>`Uses WebWorkers for Dynamic Options Syntax execution to isolate from overall dashboard loading and performance. More A value of "true" means the WebWorkers are being used in Dashboard Studio. Do not modify this value.	false
`[feature:dashboard_studio]` `lazy_load_data_frames_for_visualizations`	`<boolean>`This setting turns on or off the feature that delays rendering data frames in visualizations within Dashboard Studio until the content is required. More A value of "true" means data frames will be lazy loaded during the execution of Dynamic Options Syntax, which styles visualizations based on connected data. The setting will be removed without notice in a future release. Do not modify this value.	true
`[feature:dashboard_studio]` `bypass_clonedeep_options_scope_for_visualizations`	`<boolean>`This setting turns on or off the cloning of the original data source during Dynamic Options Syntax execution for visualizations in Dashboard Studio. More A value of "true" means the original data source will not be cloned during the execution of Dynamic Options Syntax, which styles visualizations based on connected data. The setting will be removed without notice in a future release. Do not modify this value.	true
`[feature:dashboard_studio]` `execute_chain_searches_with_tokens_in_search_process`	`<boolean>`This setting determines whether Dashboard Studio runs chain searches that use tokens ahead of time in the search process instead of the main splunkd process. If the base search is a scheduled save search, the search runs in the main splunkd process. More A value of "true" means that Dashboard Studio runs chain searches that use tokens ahead of time in the search process. A value of "false" means that Dashboard Studio runs chain searches that use tokens in the main splunkd process rather than ahead of time in the search process.	false
`[feature:dashboard_studio]` `activate_o11y_dashboards`	`<boolean>`This setting turns on or off all observability functionality within Dashboard Studio. More A value of "true" activates observability functionality. The activation of future observability features might be controlled separately. A setup to connect with an instance of observability will still be required. A value of "false" deactivates all observability functionality. The setting will be removed without notice in a future release. Do not modify this value.	true
`[feature:dashboard_studio]` `activate_o11y_service_graph`	`<boolean>`This setting turns on or off observability service graph visualization and data source functionality within Dashboard Studio. More A value of "true" means that Dashboard Studio can use service graph visualization and data source functionality. A setup to connect with an instance of observability will still be required. A value of "false" disables service graph visualization and data source functionality. The setting will be removed without notice in a future release. Do not modify this value.	true
`[feature:dashboard_studio]` `activate_dashboard_publishing_and_view_without_login`	`<boolean>`REMOVED. This setting has been removed and has no effect.
`[feature:dashboard_studio]` `activate_custom_visualizations`	`<boolean>`REMOVED. This setting has been removed and has no effect.
`[feature:dashboard_studio]` `activate_studio_extension_framework`	`<boolean>`Determines whether Dashboard Studio uses custom visualizations built with the Studio Extension Framework. More A value of "true" means that Dashboard Studio displays custom visualizations built with the Studio Extension Framework. A value of "false" means that the Splunk platform supports only legacy custom visualizations. Do not modify this setting.	true
`[feature:dashboard_studio]` `activate_conditional_visibility`	`<boolean>`REMOVED. This setting has been removed and has no effect.
`[feature:dashboard_studio]` `activate_spl2_datasources`	`<boolean>`This setting determines whether users can access SPL2 data sources in More Dashboard Studio. A value of "true" means users can access SPL2 data sources. A value of "false" means users cannot access SPL2 data sources. The setting will be removed without notice in a future release. Do not modify this value.	true

`[feature:pdfgen]`

Setting	Description	Default
`[feature:pdfgen]` `activate_chromium_legacy_export`	`<boolean>`REMOVED. This setting has been removed and has no effect.
`[feature:pdfgen]` `activate_scheduled_export_upscaling`	`<boolean>`Determines whether Dashboard Studio upscales scheduled exports, which improves image quality for large dashboards. More A value of "true" activates automatic upscaling. A value of "false" deactivates upscaling. Instead, Dashboard Studio uses a 1x scale factor, which might result in blurry visualizations and images for large dashboards.	true

`[feature:new_data_management_experience]`

Setting	Description	Default
`[feature:new_data_management_experience]` `enable_new_data_management_home`	`<boolean>`Whether or not the Data Management link navigates to the Data Management app home page on the Splunk platform deployment. More A value of "true" means the link navigates to the Data Management app home page on the Splunk platform deployment. A value of "false" means that the link does not work for Splunk Enterprise, and navigates to the landing page on the Splunk Cloud Services (SCS) tenant for Splunk Cloud Platform.	true

`[feature::windows_rce]`

Setting	Description	Default
`[feature::windows_rce]` `enable_acuif_pages`	`<boolean>`Determines whether to display the new Admin Config UI Framework version of the following Windows input pages: admin_win-event-log-collections, admin_win-perfmon, admin_win-wmi-collections, fwd_admin_win-perfmon. More A value of "true" means that Splunk Cloud Platform will display the Admin Config UI Framework version of the page.	false

`[feature:modern-nav]`

Setting	Description	Default
`[feature:modern-nav]` `enable_nav_vnext`	`<boolean>`Determines whether or not Splunk Web loads the new Layout API. More A value of "true" means Splunk Web loads the latest Layout API. A value of "false" means Splunk Web loads the legacy Layout API. Do not modify this value.	false

`[feature:page_migration]`

Setting	Description	Default
`[feature:page_migration]` `enable_data_ui_workflow-actions_vnext`	`<boolean>`Controls whether Splunk Web loads the updated "Workflow actions" page in the Data user interface (UI). More A value of "true" means that Splunk Web loads the updated page implemented with the React JavaScript library. A value of "false" means that Splunk Web loads the existing page.	true
`[feature:page_migration]` `enable_data_props_sourcetype-rename_vnext`	`<boolean>`Controls whether Splunk Web loads the updated "Sourcetype renaming" page. More A value of "true" means that Splunk Web loads the updated page implemented with the React JavaScript library. A value of "false" means that Splunk Web loads the existing page.	true
`[feature:page_migration]` `enable_data_transforms_extractions_vnext`	`<boolean>`Controls whether Splunk Web loads the updated "Extractions" management page. More A value of "true" means that the Splunk Web component loads the updated page implemented with the React JavaScript library. A value of "false" means that Splunk Web loads the existing page.	true
`[feature:page_migration]` `enable_data_props_fieldaliases_vnext`	`<boolean>`Controls whether Splunk Web loads the updated "Field aliases" page. More A value of "true" means that Splunk Web loads the updated page implemented with the React JavaScript library. A value of "false" means that Splunk Web loads the existing page.	true
`[feature:page_migration]` `enable_data_props_extractions_vnext`	`<boolean>`Controls whether Splunk Web loads the updated "Field extractions" page. More A value of "true" means that Splunk Web loads the updated page implemented with the React JavaScript library. A value of "false" means that Splunk Web loads the existing page.	true
`[feature:page_migration]` `enable_data_props_calcfields_vnext`	`<boolean>`Controls whether Splunk Web loads the updated "Calculated fields" page. More A value of "true" means that Splunk Web loads the updated page implemented with the React JavaScript library. A value of "false" means that Splunk Web loads the existing page.	true
`[feature:page_migration]` `enable_triggered_alerts_vnext`	`<boolean>`Determines whether or not Splunk Web loads the new triggered alerts page. More REMOVED. This setting has been removed and has no effect.
`[feature:page_migration]` `enable_home_vnext`	`<boolean>`REMOVED. This setting has been removed and has no effect.
`[feature:page_migration]` `enable_datasets_vnext`	`<boolean>`REMOVED. This setting has been removed and has no effect.
`[feature:page_migration]` `enable_job_manager_vnext`	`<boolean>`Determines whether or not Splunk Web loads the new job manager page. More DEPRECATED. A value of "true" means that Splunk Web does load the new job manager page. Do not modify this value.	true
`[feature:page_migration]` `enable_authoverview_vnext`	`<boolean>`Whether or not Splunk Web loads the updated authentication methods page that uses the React JavaScript library. More A value of "true" means that Splunk Web loads the updated authentication methods page that uses the React JavaScript library. A value of "false" means that Splunk Web loads the existing authentication methods page.	true
`[feature:page_migration]` `enable_authentication_providers_LDAP_vnext`	`<boolean>`Whether or not Splunk Web loads the updated "LDAP" configuration page that uses the React JavaScript library. More A value of "true" means that Splunk Web loads the updated "LDAP" page implemented with the React library instead of the XML implementation. A value of "false" means that Splunk Web loads the page that uses the existing XML implementation.	true
`[feature:page_migration]` `enable_admin_LDAP-groups_vnext`	`<boolean>`Whether or not Splunk Web loads the updated "LDAP-groups" page that uses the React JavaScript library. More A value of "true" means that Splunk Web loads the "LDAP-groups" page implemented with the React library instead of the XML implementation. A value of "false" means that Splunk Web loads the page that uses the existing XML implementation.	true
`[feature:page_migration]` `enable_authorization_tokens_vnext`	`<boolean>`Whether or not Splunk Web loads the updated "Tokens" page that uses the React JavaScript library. More A value of "true" means that Splunk Web loads the "Tokens" page implemented with the React library instead of the Backbone library. A value of "false" means that Splunk Web loads the page that uses the existing Backbone library.
`[feature:page_migration]` `enable_duo_mfa_vnext`	`<boolean>`Determines whether Splunk Web loads the updated "Duo-MFA" configuration page that uses the React JavaScript library. More A value of "true" means that Splunk Web loads the "Duo-MFA" page implemented with the React library instead of the XML implementation. A value of "false" means that Splunk Web loads the page that uses the existing XML implementation.	true
`[feature:page_migration]` `enable_authorization_roles_vnext`	`<boolean>`REMOVED. Splunk removed an outdated version of the "Authorization roles" page. Configuring this setting no longer has any effect. More Whether or not Splunk Web loads the updated "Authorization roles" page.	true
`[feature:page_migration]` `enable_authentication_users_vnext`	`<boolean>`REMOVED. Splunk removed an outdated version of the "Users" page. Configuring this setting no longer has any effect. More Whether or not Splunk Web loads the updated "Users" page, which uses separate pages for edits.	true
`[feature:page_migration]` `enable_data_indexes_cloud_vnext`	`<boolean>`Whether or not Splunk Web loads the updated "Indexes" Cloud page. More A value of "true" means that Splunk Web loads the updated "Indexes" Cloud page. A value of "false" means that Splunk Web loads the classic "Indexes" Cloud page.	true
`[feature:page_migration]` `enable_data_indexes_vnext`	`<boolean>`Whether or not Splunk Web loads the updated "Indexes" page. More A value of "true" means that Splunk Web loads the updated "Indexes" page. A value of "false" means that Splunk Web loads the classic "Indexes" page.	true
`[feature:page_migration]` `enable_reports_vnext`	`<boolean>`Determines whether or not Splunk Web loads the new reports page. More DEPRECATED. A value of "true" means that Splunk Web does load the new reports page. Do not modify this value.	true
`[feature:page_migration]` `enable_alerts_vnext`	`<boolean>`DEPRECATED. This setting has been deprecated and has no effect.
`[feature:page_migration]` `enable_dashboards_vnext`	`<boolean>`Determines whether or not Splunk Web loads the new dashboards listing page. More A value of "true" means that Splunk Web loads the new dashboards listing page. A value of "false" means that Splunk Web loads the classic dashboards listing page.	true
`[feature:page_migration]` `enable_admin_alert_actions_vnext`	`<boolean>`Determines whether or not Splunk Web loads the "Email Settings" page that uses the React JavaScript library. More A value of "true" means that Splunk Web loads the modernized "Email Settings" page implemented with the React library instead of with Python and XML. A value of "false" means that Splunk Web loads the page that uses the existing Python and XML solution.
`[feature:page_migration]` `enable_saml_vnext`	`<boolean>`Whether or not Splunk Web loads the updated "SAML" page that uses the React JavaScript library. More A value of "true" means that Splunk Web loads the "SAML" page implemented with the React library instead of the Backbone library. A value of "false" means that Splunk Web loads the page that uses the existing Backbone library.	true
`[feature:page_migration]` `enable_admin_directory_vnext`	`<boolean>`Determines whether or not Splunk Web loads the "All configurations" page that uses the React JavaScript library. More A value of "true" means that Splunk Web loads the modernized "All configurations" page implemented with the React library instead of with Python and XML. A value of "false" means that Splunk Web loads the page that uses the existing Python and XML solution.	true
`[feature:page_migration]` `enable_federation_page_vnext`	`<boolean>`Whether or not Splunk Web displays the modernized Federation Page. More A value of "false" means Splunk Web displays the old federated_search page. A value of "true" means Splunk Web displays the modernized Federation Page.	false

`[feature:dashboard_inputs_localization]`

Setting	Description	Default
`[feature:dashboard_inputs_localization]` `enable_dashboard_inputs_localization`	`<boolean>`Determines whether or not Splunk Web will attempt to localize input choices in Classic dashboards. More A value of "true" means that localization for input choices will be enabled in Classic Dashboards. A value of "false" means that localization for input choices will be disabled in Classic Dashboards.	false

`[feature:share_job]`

Setting	Description	Default
`[feature:share_job]` `enable_share_job_control`	`<boolean>`Determines whether or not users can share jobs using the "Share Job" button in the Search app in Splunk Web. More A value of "true" means that users can use the "Share Job" button in the Search app to share search jobs. A value of "false" means that users cannot use the "Share Job" button to share search jobs. Instead, they receive a notice that job sharing has been disabled and they can instead share a search query.	true

`[feature:search_auto_format]`

Setting	Description	Default
`[feature:search_auto_format]` `enable_autoformatted_comments`	`<boolean>`Determines whether or not comments are auto-formatted by the search editor's auto-formatter. More DEPRECATED. CAUTION: Do not change this setting. A value of "false" means that comments are not auto-formatted. Comment auto-formatting may result in undesirable output.	false

`[feature:ui_prefs_optimizations]`

Setting	Description	Default
`[feature:ui_prefs_optimizations]` `optimize_ui_prefs_performance`	`<boolean>`Determines whether or not Splunk Web will optimize performance of the API related to ui-prefs.conf. More DEPRECATED. CAUTION: Do not change this setting. A value of "false" means that Splunk Web will not optimize performance of the API related to ui-prefs.	true

`[feature:splunk_web_optimizations]`

Setting	Description	Default
`[feature:splunk_web_optimizations]` `enable_app_bar_performance_optimizations`	`<boolean>`Determines whether or not Splunk Web will optimize performance when generating the app bar. More DEPRECATED. CAUTION: Do not change this setting. A value of "false" means that Splunk Web will not optimize performance when generating the app bar.	true
`[feature:splunk_web_optimizations]` `bypass_app_bar_performance_optimizations_apps`	`<comma separated list>`Splunk Web will not optimize performance when generating the app bar for this comma separated list of apps. More CAUTION: Do not change this setting. A value of "splunk_monitoring_console,search" means that Splunk Web will not optimize performance when generating the app bar for the splunk_monitoring_console and search apps.	""
`[feature:splunk_web_optimizations]` `enable_search_bar_performance_optimizations`	`<boolean>`DEPRECATED. More Determines whether Splunk Web optimizes search bar load time when it loads the search page. A value of "false" means that Splunk Web does not optimize search bar load time when it loads the search page. CAUTION: Do not change this setting.	true
`[feature:splunk_web_optimizations]` `enable_saved_search_pageload_optimization`	`<boolean>`DEPRECATED. More Determines whether or not Splunk Web optimizes the fetching of details for saved searches. A value of "true" means that Splunk Web optimizes the fetching of details for saved searches. A value of "false" means that Splunk Web does not optimize the fetching of details for saved searches. CAUTION: Do not change this setting.	true
`[feature:splunk_web_optimizations]` `enable_messages_list_performance_optimizations`	`<boolean>`DEPRECATED. More Determines whether Splunk Web optimizes rendering the messages list when it loads some Splunk Web pages. A value of "true" means that Splunk Web optimizes rendering the messages list when it loads some Splunk Web pages. A value of "false" means that Splunk Web does not optimize rendering the messages list when it loads some Splunk Web pages. Do not change this setting.	true

`[feature:spotlight_search]`

Setting	Description	Default
`[feature:spotlight_search]` `enable_spotlight_search`	`<boolean>`Determines whether Splunk Web displays the Spotlight Search bar in the Settings menu. More A value of "true" means that Splunk Web will display the Spotlight Search bar in the Settings menu.	true

`[feature:search_sidebar]`

Setting	Description	Default
`[feature:search_sidebar]` `enable_sidebar_preview`	`<boolean>`Determines whether the Search & Reporting app displays a "preview" column for events, and allows the preview sidebar in the Events view. More A value of "true" means that Splunk Web will show preview links and the preview sidebar will render.

`[feature:field_filters]`

Setting	Description	Default
`[feature:field_filters]` `enable_field_filters_ui`	`<boolean>`Determines whether Splunk Web displays field filters. More A value of "false" means that field filters are not visible in Splunk Web.	true

`[feature:authentication_oauth]`

Setting	Description	Default
`[feature:authentication_oauth]` `enable_authentication_oauth_ui`	`<boolean>`Whether or not Splunk Web displays the Open Authorization (OAuth) configuration page as part of the Authentication Methods configuration workflow. More A value of "true" means that Splunk Web displays the OAuth page. A value of "false" means that Splunk Web does not display the OAuth page.	true

`[feature:identity_sidecar_scim]`

Setting	Description	Default
`[feature:identity_sidecar_scim]` `enabled`	`<boolean>`Whether or not Splunk Web displays Automated User Management (AUM) controls for System for Cross-Domain Identity Management (SCIM) in the SAML configuration dialog page. More A value of "true" means that Splunk Web shows AUM controls in the SAML configuration dialog. A value of "false" means that Splunk Web does not show AUM controls in the SAML configuration dialog.	true

`[feature:system_namespace_redirection]`

Setting	Description	Default
`[feature:system_namespace_redirection]` `enable_system_namespace_redirection`	`<boolean>`Determines whether or not Splunk Web redirects pages with the system app namespace. More A value of "true" means that Splunk Web redirects pages with the system app namespace. A value of "false" means that Splunk Web does not redirect pages with the system app namespace. CAUTION: Do not change this setting.	true

`[feature:appserver]`

Setting	Description	Default
`[feature:appserver]` `python.version`	`latest\|python3.9`DEPRECATED. More A value of "latest" means that the app server uses the latest version of Python that is available in the release. CAUTION: Do not change this setting.	latest
`[feature:appserver]` `python.required`	`<comma-separated list>`The list of Python versions that Splunk Web supports. More This setting takes precedence over the 'python.version' setting if both settings have values. The following values are supported: "3.9": Splunk Web uses Python version 3.9. "3.13": Splunk Web uses Python version 3.13. "latest": Splunk Web uses the latest Python interpreter available. CAUTION: Change this setting only when asked to do so by Splunk Support.	latest

`[feature:federated_search]`

Setting	Description	Default
`[feature:federated_search]` `enable_ipv6_validations`	`<boolean>`Whether or not Splunk Web lets users enter IPv6 addresses and Classless Inter-Domain Routing (CIDR) ranges into address input forms. More A value of "true" means that Splunk Web accepts IPv6 addresses and CIDR ranges in address input forms. A value of "false" means that Splunk Web accepts only IPv4 addresses and CIDR ranges in address input forms, and rejects IPv6 addresses and CIDR ranges.	true

`[feature:knowledge_object_favorites]`

Setting	Description	Default
`[feature:knowledge_object_favorites]` `enable_dashboards_favorites`	`<boolean>`Determines whether users can favorite dashboards. More A value of "true" means users can favorite or unfavorite dashboards. A value of "false" means users cannot favorite or unfavorite dashboards.	true
`[feature:knowledge_object_favorites]` `enable_reports_favorites`	`<boolean>`Determines whether users can favorite reports. More A value of "true" means users can favorite or unfavorite reports. A value of "false" means users cannot favorite or unfavorite reports.	true

`[feature:search_ai_assistant]`

Determines whether Splunk Web displays the Splunk AI Assistant for SPL in the Search app.
A value of "true" means that users can see the Splunk AI Assistant for SPL in the Search app.
A value of "false" means that users can't see the Splunk AI Assistant for SPL in the Search app.

Setting	Description	Default
`[feature:search_ai_assistant]` `enable_search_ai_assistant`	`true`No description in the spec.

`[feature:splunk_ai_canvas]`

Setting	Description	Default
`[feature:splunk_ai_canvas]` `check_ai_canvas_eligible`	`false`Whether or not the Splunk platform displays AI Canvas. More A value of "true" means that users can see AI Canvas. A value of "false" means that users cannot see AI Canvas. This setting applies only to the Splunk Cloud Platform. CAUTION: Do not change this setting.	false

`[feature:spl2]`

Setting	Description	Default
`[feature:spl2]` `enable_spl2`	`<boolean>`Determines whether Splunk Web enables SPL2. More A value of "true" means Splunk Web enables SPL2. A value of "false" means Splunk Web disables SPL2.	true

`[feature:splunk_oauth_clients]`

Setting	Description	Default
`[feature:splunk_oauth_clients]` `enable_splunk_oauth_clients_ui`	`<boolean>`Whether or not Splunk Web displays pages related to Splunk Open Authorization clients. More A value of "true" means that Splunk OAuth clients are visible in Splunk Web. A value of "false" means that Splunk OAuth clients are not visible in Splunk Web.	false

`[feature:appserver_security]`

Setting	Description	Default
`[feature:appserver_security]` `deactivate_custom_mako_templates`	`<boolean>`Whether or not Splunk Web blocks custom Mako templates shipped by apps. More A value of "true" means Splunk Web blocks custom app Mako templates in the $SPLUNK_HOME/etc/apps/<app>/appserver/templates and $SPLUNK_HOME/etc/apps/ <app>/appserver/modules directories. A value of "false" means Splunk Web allows custom app Mako templates in those directories. Regardless of this setting, Splunk Web always allows first-party templates in the $SPLUNK_HOME/share/splunk/search_mrsparkle directory.	false
`[feature:appserver_security]` `deactivate_custom_cherrypy_controllers`	`<boolean>`Whether or not Splunk Web blocks custom CherryPy controllers shipped by apps. More A value of "true" means Splunk Web blocks custom app CherryPy controllers. Also, app controllers in the $SPLUNK_HOME/etc/apps/<app>/appserver/controllers directory are not registered, causing all /custom/<app>/* routes to return a 404 error. A value of "false" means Splunk Web allows custom app CherryPy controllers in those directories. This setting only affects the /custom/<app>/* directory. It does not affect REST endpoints, views, dashboards, and static assets.	false

Example

[feature:dashboards_csp]
enable_dashboards_external_content_restriction = true
enable_dashboards_redirection_restriction = true
dashboards_trusted_domain.splunk = *.splunk.com
dashboards_trusted_domain.example = www.example.com

[feature:page_migration]
enable_data_ui_workflow-actions_vnext = true
enable_saml_vnext = true
enable_federation_page_vnext = false

[feature:spotlight_search]
enable_spotlight_search = true

[feature:federated_search]
enable_ipv6_validations = true

[feature:splunk_oauth_clients]
enable_splunk_oauth_clients_ui = false

A locked-down DTDL trusting only two named domains, a mix of adopted and still-legacy page-migration flags, and Spotlight Search/IPv6 input validation left at their enabled defaults.

Validation

Check the current release's web-features.conf.spec before relying on any specific flag -- REMOVED/DEPRECATED settings churn heavily release to release and silently become no-ops.
Keep enable_dashboards_external_content_restriction and enable_dashboards_redirection_restriction enabled, and populate dashboards_trusted_domain.<name> deliberately rather than with a bare * -- a wildcard trusts every external domain for dashboard content and redirects.
Leave settings flagged "Do not modify this value" or "CAUTION: Do not change this setting" at their shipped default unless Splunk Support directs otherwise.
Remember these settings replicate in a search head cluster -- a locally-set flag on one member does not stay local.

← Back to References

References / Splunk platform configuration

User Preferences Configuration

user-prefs.conf holds per-user Splunk Web preferences -- default app on login, timezone, language, search-bar behavior, and theme. Settings are requested with user and app scope for the user-prefs app; interactively changing a preference in Splunk Web writes it to $SPLUNK_HOME/etc/users/<username>/user-prefs/local/user-prefs.conf. Backs the Splunk Taxonomy's User Preferences object (SOT-04.04.06).

Definition

Four stanza types: [general] holds the per-user settings themselves; [general_default] sets deployment-wide defaults for all users; [role_<name>] supplies role-scoped defaults that apply below a user's own interactive settings but above the deployment default; [default] catches additional settings that are entirely UI-managed. Never edit the shipped default at $SPLUNK_HOME/etc/apps/user-prefs/default/ -- customize via local/ or a specific user's own local/ directory instead.

File locations

Configuration file: user-prefs.conf.

Scope	Path
System	`$SPLUNK_HOME/etc/system/{default,local}/user-prefs.conf`
App	`$SPLUNK_HOME/etc/apps/<app_name>/{default,local}/user-prefs.conf`
User	`$SPLUNK_HOME/etc/users/<user_name>/<app_name>/local/user-prefs.conf`

[general_default] and [role_<name>] stanzas for deployment-wide and role-scoped defaults typically live in the system/local copy.

[general] settings

Setting	Description
`default_namespace`	The app (by short/directory name) the user lands on after login. Default `launcher`, via `authorize.conf`.
`tz`	Per-user timezone (canonical name, e.g. `America/Los_Angeles`). Falls back to the server/search-head timezone if unset.
`lang`	Per-user language preference for non-web-UI operations, using `Accept-Language`-style tags with fuzzy matching and optional quality weights (e.g. `en-US,en;q=0.8,fr;q=0.6`). Falls back to `en-US`.
`restart_background_jobs`	Whether background search jobs not yet complete auto-restart when splunkd restarts. Default `false`.
`search_use_advanced_editor` / `search_auto_format` / `search_line_numbers`	Advanced (SPL-aware) search bar editor vs. plain text. Setting to `false` forces `search_auto_format`/`search_line_numbers` off and disallows a `compact` search assistant. Default `true`.
`search_assistant`	`full`, `compact`, or `none`. Default `compact`.
`search_syntax_highlighting`	`default-system-theme`, `light`, or `dark` -- search-string syntax coloring; dashboards ignore this. Default `default-system-theme`.
`theme`	`default_system_theme`, `light`, or `dark`. Falls back to the system theme in apps that don't support dark mode.
`app_bar_cache_timeout_min`	Minutes the app-bar cache stays valid before regenerating. Default `1440`.
`install_source_checksum`	Checksum of the tarball a set of private user configurations was installed from -- like `app.conf`'s `install_source_checksum`.
`dismissedInstrumentationOptInVersion` / `hideInstrumentationOptInModal`	Set by the `splunk_instrumentation` app when the user dismisses its opt-in modal: the `optInVersion` at the time, and `1`.
`[general_default] showWhatsNew`	Removed -- has no effect.
`[general_default] appOrder`	Deployment-wide default for the first app in the app list.
`[general_default] default_earliest_time` / `default_latest_time`	Deployment-wide default search time range.
`[general_default] notification_python_3_impact` / `notification_python_2_removal` / `notification_noah_upgrade`	Notification snooze flags.

Deployment & role defaults

[general_default] sets deployment-wide defaults -- appOrder (first app in the app list), default_earliest_time/default_latest_time (global default search time range), and notification snooze flags (notification_python_3_impact, notification_python_2_removal, notification_noah_upgrade). [role_<name>] stanzas set the same kind of settings (e.g. tz, lang) scoped to a role rather than the whole deployment -- these apply for any user with that role who hasn't set their own interactive preference. Precedence, low to high: [general_default] deployment default → [role_<name>] role default → the user's own interactively-set [general] value.

Example

[role_power]
tz = GMT
lang = en-US

[role_user]
tz = GMT
lang = fr-FR,fr-CA;q=0

Every member of the Power role defaults to GMT and US English; every member of the User role also defaults to GMT but prefers French (France), falling back to French (Canada) at zero quality weight -- i.e. only if no other listed language is available.

Validation

Never edit or copy the shipped default file directly -- customize through a local/ directory, either the app-wide one or a specific user's own.
Use canonical timezone names (e.g. America/Los_Angeles) for tz, not fixed offsets, so daylight-saving transitions resolve correctly.
Set role-scoped defaults via [role_<name>] rather than editing every individual user's file when a preference should apply deployment-wide to a role.
Remember interactive changes a user makes in Splunk Web always win over role and deployment defaults -- [role_<name>]/[general_default] only take effect before a user has set their own value.

← Back to References

References / Splunk platform configuration

Authorization Configuration

authorize.conf defines roles -- named bundles of capabilities, index access, search filters, and resource quotas assigned to users -- and documents the full, fixed catalog of Splunk system capabilities a role can be granted. Backs the Splunk Taxonomy's Role (SOT-07.02.01) and Capability (SOT-07.02.02) objects.

Definition

Three stanza families: [role_<roleName>] defines a role and everything it grants; [capability::<capability>] stanzas -- one per system capability, never hand-edited -- exist purely to document what each capability does; and a single global [default] stanza plus a [tokens_auth] stanza cover deployment-wide authorization behavior. Role names cannot contain uppercase characters, spaces, colons, semicolons, or forward slashes.

File locations

Configuration file: authorize.conf.

Scope	Path
System	`$SPLUNK_HOME/etc/system/{default,local}/authorize.conf`
App	`$SPLUNK_HOME/etc/apps/<app_name>/{default,local}/authorize.conf`

Global settings & capability stanzas

Every [capability::<name>] in the Splunk Enterprise 10.4.2 spec is on the Roles page, with which built-in roles hold it, what it lets a user do, and -- where Splunk's own files record it -- the REST endpoints and .conf files it relates to.

Stanza / Setting	Description
`[default]` `srchFilterSelecting`	Whether a role's `srchFilter` is used for selecting (`true`, filters OR together across inherited roles) or eliminating (`false`, filters AND together). Default `true`.
`[capability::<capability>]`	DO NOT edit, remove, or add these stanzas -- they are the fixed, Splunk-shipped set of system capabilities, each documented with a description below its own header. Only alphanumeric characters and underscore are valid in a capability name.

Role definition & capability grant

Setting	Description
`<capability> = enabled`	Grants that capability to the role. The only valid value is `enabled` -- capabilities are disabled by default, and there is no explicit deny.
`importRoles`	Semicolon-separated list of roles to inherit capabilities (and index access, search filters, etc.) from. Inherited capabilities cannot be disabled by the importing role.
`grantableRoles`	Semicolon-separated list of roles whose union of capabilities/indexes bounds what a user holding this role -- if it also has `edit_roles_grantable` and `edit_user` but not `edit_roles` -- can view, assign, or create. Only the `admin` role holds `edit_roles_grantable` by default; editing the `admin` role sets this to `admin`. Does not work with token authentication.

Search filtering

Setting Description

srchFilter A search-filter expression (built from source=, host=, index=, eventtype=, sourcetype=, search fields, wildcards, and AND/OR) applied to every search this role's users run. Cannot reference saved searches, time operators, regular expressions, or Splunk-Web-overwritable fields/modifiers. A value of * overrides all inherited filters, as the admin role does. Default empty (no filtering).

fieldFilterExemption Comma-separated list of field filters this role is exempt from at search time. Inherited from imported roles and cannot be removed.

Combined with srchFilterSelecting, inheritance combines filters via OR (selecting) or AND (eliminating) across a role's own filter and every imported role's filter -- see the spec's worked three-role inheritance example for the exact boolean expansion.

Search time & resource limits

Setting	Description
`srchTimeWin`	Maximum search time range in seconds. `-1` (default) means no limit but can be overridden more restrictively by an inherited role; `0` means no limit and cannot be overridden. A user with multiple roles gets the least restrictive combined limit. Doesn't apply to real-time searches.
`srchTimeEarliest`	Earliest searchable event time, in seconds before now. Same `-1`/`0`/least-restrictive-wins semantics as `srchTimeWin`.
`srchDiskQuota`	Max MB of disk a user's search jobs may use; `0` = unlimited. Checked at dispatch and periodically (`disk_usage_update_period` in limits.conf); exceeding it auto-finalizes the search. Default `100`.
`srchJobsQuota` / `rtSrchJobsQuota`	Max concurrent historical / real-time search jobs per user. Defaults `3` / `6`; `0` = unlimited.
`queuedSearchQuota`	Max searches a user may have queued concurrently; a search that would queue beyond this is rejected outright. Default `0` (unlimited).
`srchMaxTime`	Max wall-clock run time for a search job (e.g. `1h`, `2hrs`) before it auto-finalizes. Doesn't apply to real-time searches. Default `100days`.
`cumulativeSrchJobsQuota` / `cumulativeRTSrchJobsQuota`	Total concurrent historical/real-time jobs across all users holding the role, active only when `limits.conf`'s `enable_cumulative_quota = true`. Not cluster-wide -- per search head cluster member. Defaults `50` / `0`.

Index access control

Setting	Description
`srchIndexesDefault`	Semicolon-separated indexes searched when none is specified in the search. Wildcardable, but a bare `` matches only non-internal indexes -- use `_` for internal ones.
`srchIndexesAllowed`	Semicolon-separated indexes this role may search, same wildcard semantics.
`srchIndexesDisallowed`	Indexes this role may not search or delete -- takes precedence over `srchIndexesAllowed`/`srchIndexesDefault`/`deleteIndexesAllowed`. Requires every search head and peer on Splunk Enterprise 8.1.0+. Editing index access in Splunk Web's role UI overwrites and discards any wildcards set here.
`deleteIndexesAllowed`	Indexes this role may delete from, used together with the `delete_by_keyword` capability.

Federated search & KV Store permissions

Setting	Description
`srchFederatedProvidersAllowed`	Semicolon-separated, wildcardable list of transparent-mode federated providers this role may search. Default `*`; an empty value blocks all providers, including the local deployment.
`srchFederatedProvidersDefault`	Providers a search runs against when none is named via `splunk_federated_provider`. `srchFederatedProvidersAllowed` overrides this -- a provider listed here but not in the allowed list is never reached.
`kvstore_create.deny_list` / `kvstore_update.deny_list` / `kvstore_delete.deny_list`	Collections this role cannot create/update/delete in. Not inherited from imported roles.
`kvstore_create.implicit_deny_list` / `kvstore_update.implicit_deny_list` / `kvstore_delete.implicit_deny_list`	Same effect as the deny-list settings above, but inherited from imported roles.

Token authorization

[tokens_auth] is deployment-wide, not per-role.

Setting	Description
`disabled`	Whether Splunk token authentication is turned off (`true`) or on (`false`). Default `false`.
`expiration`	Relative-time-modifier (e.g. `+2h@h`) or `never` for when an issued auth token expires. Requires the `admin` role to change. Default `+30d`.
`ephemeralExpiration`	Same relative-time syntax, for ephemeral tokens (REST-only, never stored in the KV Store, always must expire). Requires `admin`. Maximum `+6h`, default `+1h`.

Capability categories

The bulk of the shipped authorize.conf is the [capability::<capability>] catalog -- well over 200 individually documented, additive-only permission bits. Rather than restate every entry, they group into recognizable themes:

Roles, users & access control: edit_roles, edit_roles_grantable, edit_user, admin_all_objects, list_all_users, list_all_roles, change_authentication
Search & reporting: search, rtsearch, schedule_search, accelerate_search/datamodel, run_* restricted commands, metric_alerts
Data inputs & forwarding: edit_monitor, edit_tcp/edit_udp, edit_forwarders, edit_token_http (HEC), the edit_modinput_* family
Indexing, clustering & storage: indexes_edit, edit_indexer_cluster, edit_search_head_clustering, merge_buckets, create_bulk_data_move
Deployment & distributed search: edit_deployment_server/_client, edit_dist_peer, edit_indexerdiscovery
Federated Analytics & SPL2: edit_datasets, list_federated_providers, edit_federated_providers/_indexes, edit_spl2_modules/_datasets
System, licensing & certificates: restart_splunkd, license_edit/_read, edit_certificates, edit_server, edit_web_settings

Each capability's own [capability::<name>] stanza in the spec carries its authoritative one-paragraph description -- consult it directly when assigning an unfamiliar capability rather than inferring behavior from its name.

Example

[role_ninja]
rtsearch = enabled
importRoles = user
srchFilter = host=foo
srchIndexesAllowed = *
srchIndexesDefault = mail;main
srchJobsQuota   = 8
rtSrchJobsQuota = 8
srchDiskQuota   = 500
srchTimeWin = 86400
srchTimeEarliest = 2592000

A role inheriting from user that adds real-time search, filters every search to host=foo, defaults to the mail and main indexes (searching all public indexes when explicit), allows 8 concurrent historical and 8 real-time jobs at up to 500MB total disk, and caps searches to a one-day time range over data no older than 30 days.

Validation

Never hand-edit, remove, or add a [capability::<name>] stanza -- the catalog is Splunk-shipped and fixed.
Prefer importRoles from a shipped base role (user, power) over building a custom role's capability set from scratch, since inherited capabilities can't be revoked.
Remember capabilities are additive-only with no explicit deny -- a user's effective permissions are the union of every role they hold, so removing a capability from one role doesn't remove it if another held role grants it.
Set srchIndexesDisallowed deliberately when it matters -- it overrides srchIndexesAllowed/srchIndexesDefault/deleteIndexesAllowed, and editing index access via Splunk Web's role UI silently discards any wildcards configured here.
Assign narrow, purpose-specific capabilities (list_alert_actions, edit_alert_actions, edit_saved_search, etc.) instead of admin_all_objects where the spec explicitly calls out a narrower alternative.
Confirm enable_cumulative_quota in limits.conf before relying on cumulativeSrchJobsQuota/cumulativeRTSrchJobsQuota -- they have no effect otherwise.

← Back to References

References / Splunk platform configuration

Alert Actions Configuration

alert_actions.conf defines the global behavior of every alert action a saved search can trigger -- email, RSS, script, lookup, summary index, webhook, and custom alert actions shipped by an add-on. Per-saved-search overrides of these settings live in savedsearches.conf under an action.<name>.* prefix. Backs the Splunk Taxonomy's Alert Action object (SOT-03.01.02).

Definition

One stanza per alert action type -- [email], [rss], [script], [lookup], [summary_index], [summary_metric_index], [populate_lookup] (deprecated), [webhook] -- plus a global settings block, and a free-form [<custom_alert_action>] stanza per custom action an app defines. Settings here are the deployment-wide defaults; a specific saved search overrides them via the matching action.<stanza>.<setting> key in savedsearches.conf.

File locations

Configuration file: alert_actions.conf.

Scope	Path
System	`$SPLUNK_HOME/etc/system/{default,local}/alert_actions.conf`
App	`$SPLUNK_HOME/etc/apps/<app_name>/{default,local}/alert_actions.conf`

Global settings

Setting	Description
`maxresults`	Global max search results sent through any alert. Default `10000`.
`hostname`	Hostname (or full `protocol://host:port`) used to build result links in alerts -- needed when the Splunk server can't construct an externally-reachable URL itself (SSO, proxies, unresolvable hostnames).
`ttl`	Minimum artifact retention, in seconds (or scheduled periods with a trailing `p`), if the action fires. Defaults vary by action: `10p` generally, `86400` for email/rss, `600` for script, `120` for summary_index.
`maxtime`	Max wall-clock time an action may run before being aborted. Default `5m` (`1m` for `[rss]`).
`track_alert`	Whether this action's execution counts as a trackable alert. Default `false`.
`command`	The search pipeline that executes the action, templated with saved-search field values via $field$ substitution (e.g. $name$ , $search$ ).
`is_custom` / `label` / `description` / `icon_path`	Mark and brand a custom alert action for the Search UI -- whether it's custom-framework-based, its display label (default: stanza name), description, and icon (relative to the app's `appserver/static`).
`forceCsvResults`	`auto`\|`true`\|`false` -- whether results serialize as CSV vs. internal SRS format. `auto` uses CSV when `command` starts with `sendalert` or references $results.file$ . Default `auto`.
`alert.execute.cmd` / `alert.execute.cmd.arg.<n>`	For custom alert actions, the binary/script (or a `*.path` pointer file) in the app's `bin/` to run, plus numbered arguments with environment-variable substitution.
`payload_format`	Format -- `xml` or `json` -- in which an alert script receives its configuration on STDIN. Default `xml`.
`python.required` / `python.version`	Python versions an alert script supports (`3.9`, `3.13`); the highest available is used. `python.version` is deprecated, and `python.required` wins when both are set.

Email: core settings

Setting	Description
`from` / `to` / `cc` / `bcc`	Sender and recipient addresses. Default `from` is `splunk`.
`allowedDomainList`	Security-critical: `allow_all`, `deny_all`, or a comma-separated allow-list of domains email/`sendemail` may target. Leaving it unset means users can email search results to any domain -- explicitly called out as a security risk in the spec. When set here it overrides the per-search `action.email.allowedDomainList` in `savedsearches.conf`.
`subject` / `subject.alert` / `subject.report` / `useNSSubject`	Email subject templates; `useNSSubject` switches between the namespaced (`subject.alert`/`subject.report`) and plain `subject` forms. Default subjects reference $name$ .
`message.alert` / `message.report`	Custom body text templates for alerts vs. scheduled reports, with result/saved-search/job field substitution.
`format` / `content_type`	`format` is `table`, `raw`, or `csv` for inline results; `content_type` is `html` or `plain` for the email body itself.
`sendresults` / `inline`	Whether results are included at all, and whether inline in the body (vs. attached as CSV). Both default `false`.
`sendpdf` / `sendcsv` / `sendpng`	Attach results as PDF, CSV, or (Dashboard Studio only) PNG. All default `false`.
`allow_empty_attachment`	Whether a CSV/PDF attachment is still sent when the triggering search returns no results. Default `true`.
`escapeCSVNewline` / `newLineValuesInCSV`	CSV-formatting details: escaping embedded newlines/tabs, and whether multivalue fields use a newline separator instead of a space.
`include.results_link` / `include.search` / `include.trigger` / `include.trigger_time` / `include.view_link`	Whether the email includes a link to the results, the search that triggered it, the trigger condition, the trigger time, and the title with a link to edit the saved search.
`priority`	Email priority, `1` (highest) to `5` (lowest). Default `3`.
`footer.text`	Replacement email footer. The default tells recipients to see their Splunk administrator if they received the email in error.
`preprocess_results`	A search string run on the results before they're emailed -- usually to filter out internal fields. Default empty.
`width_sort_columns`	Plain-text emails only (`format=text`): sort columns from narrowest to widest, left to right. Default `true`.

Email: SMTP & authentication

Setting	Description
`mailserver`	SMTP `host[:port]` to send through; Splunk does not ship its own SMTP server. Default `localhost`.
`use_ssl` / `use_tls`	Connect over SSL, or upgrade with STARTTLS. Both default `false`; `use_ssl` requires an explicit host and port in `mailserver`.
`auth_username` / `auth_password`	SMTP credentials; leaving `auth_username` empty skips authentication entirely, which some SMTP servers reject.
`oauth_client_id` / `oauth_client_secret` / `oauth_url` / `oauth_scope`	OAuth2 credential exchange settings for SMTP authorization, as an alternative to a static password.

Email: PDF rendering

Setting	Description
`pdfview` / `reportFileName`	The view to render as a PDF, and the attachment filename template. Default filename `$name$-$time:%Y-%m-%d$`.
`reportPaperSize` / `reportPaperOrientation`	Paper size (`letter` default, up to `a2`) and `portrait`/`landscape` orientation.
`reportIncludeSplunkLogo` / `pdf.logo_path`	Whether to show the Splunk logo, and an `<app>:<path>` override to use a custom one instead.
`reportCIDFontList`	Space-separated CJK CID font load order (default `gb cns jp kor`) for rendering Chinese/Japanese/Korean glyphs; first font providing a glyph wins.
`pdf.header_left` / `pdf.header_center` / `pdf.header_right` / `pdf.footer_left` / `pdf.footer_center` / `pdf.footer_right`	Which element (`logo`/`title`/`description`/`timestamp`/`pagination`/`none`) appears in each header/footer position. Defaults: header `none` / `description` / `none`; footer `logo` / `title` / `timestamp,pagination`.
`pdf.header_enabled` / `pdf.footer_enabled` / `pdf.html_image_rendering`	Toggle the header/footer bands, and whether HTML-embedded images render in the PDF (disable if rendering breaks the PDF).

Email: TLS/SSL settings

Used exclusively by the email alert action and the sendemail search command, for the SMTP connection.

Setting	Description
`sslVersions`	Comma-separated allowed TLS versions; `tls1.0`/`tls1.1` don't work under Python 3.9.
`sslVerifyServerCert` / `sslVerifyServerName`	Whether to validate the SMTP server's certificate at all, and separately, whether to validate its hostname against the certificate's CN/SAN (requires `sslVerifyServerCert` first). Both default `false`.
`sslCommonNameToCheck` / `sslAltNameToCheck`	Explicit CN/SAN allow-lists to check the server certificate against, when `sslVerifyServerCert` is enabled.
`cipherSuite`	Cipher string for the SMTP TLS connection.

RSS, script & lookup actions

Stanza / Setting	Description
`[rss]` `items_count`	Number of items kept in the RSS feed, capped by the global `maxresults`. Default `30`.
`[script]` `filename`	Script (no path) triggered from `$SPLUNK_HOME/bin/scripts/`; non-shell/batch scripts need a `#!` interpreter line.
`[lookup]` `filename`	CSV file name or KV Store lookup name written on each scheduled run; a CSV file is created if missing, and overwritten each run unless `append` is set. A KV Store lookup's collection must already exist -- this action never creates one.
`[lookup]` `append`	Append to the existing lookup file instead of overwriting it. Default `false`.

Summary index & populate_lookup actions

Stanza / Setting	Description
`[summary_index]` / `[summary_metric_index]` `inline`	Whether the summary/metric-index write runs as part of the scheduled search itself (default `true`) or as a follow-on action -- keep `true` for large result sets.
`_name`	Target summary index name. Default `summary`.
`[populate_lookup]` `dest`	Deprecated -- use `[lookup]` instead. Names the lookup stanza (in `transforms.conf`) or a lookup file path relative to `$SPLUNK_HOME` to populate. Requires the executing user to have app write permission.

Webhook & custom alert actions

Setting	Description
`[webhook]` `param.user_agent`	Custom `User-Agent` header the webhook query sends.
`enable_allowlist`	Security-critical: whether the webhook action restricts queries to an explicit endpoint allow-list. Enabling this without configuring at least one `allowlist.<name>` is flagged as a security risk -- the action can otherwise query any endpoint, including malicious external ones. Default `false`.
`allowlist.<name>`	Regular expression matching an endpoint the webhook action may query.
`[<custom_alert_action>]`	Free-form stanza name for a custom alert action shipped by an add-on, configured with the global settings above (`is_custom`, `label`, `alert.execute.cmd`, etc.).

Example

[email]
ttl = 86400
from = splunk
format = table
inline = false
sendresults = true
hostname = CanAccessFromTheWorld.com
use_tls = 1
sslVersions = tls1.2
sslVerifyServerCert = true
sslCommonNameToCheck = host1, host2

[rss]
items_count = 30
ttl = 86400

[custom_action]
is_custom = 1
label = Custom Alert Action
description = Triggers a custom alert action
icon_path = custom_alert.png
alert.execute.cmd = java.path
alert.execute.cmd.arg.1 = -jar
alert.execute.cmd.arg.2 = $SPLUNK_HOME/etc/apps/myapp/bin/custom.jar
alert.execute.cmd.arg.3 = --execute

Email hardened with TLS 1.2 and certificate CN checking, a 30-item RSS feed with the same 24-hour artifact retention, and a custom alert action that shells out to a bundled Java jar via a path-pointer file.

Validation

Set allowedDomainList explicitly (an allow-list, not allow_all) rather than leaving it unset -- an unset value lets users email search results to any domain.
Never enable enable_allowlist for the webhook action without also configuring at least one allowlist.<name> -- doing so removes the endpoint restriction entirely.
Prefer [lookup] over the deprecated [populate_lookup] for writing scheduled search results to a lookup.
Enable sslVerifyServerCert (and ideally sslVerifyServerName) for the email action's SMTP connection rather than relying on the insecure defaults.
Keep [summary_index]/[summary_metric_index] inline = true for large result sets to avoid a separate, slower follow-on write.
Remember per-search overrides live in savedsearches.conf as action.<stanza>.<setting> -- a change here sets the deployment default, not a hard override.

← Back to References

References / Splunk platform configuration

KV Store Collections Configuration

collections.conf defines the KV Store collections available to an app -- one [<collection-name>] stanza per collection, covering field typing, acceleration indexes, replication, and profiling. Backs the Splunk Taxonomy's KV Store Collection object (SOT-02.05.04).

Definition

Each stanza name is the collection name; the collection itself is created the first time it's referenced (e.g. by a lookup definition or REST write), not by this file alone. Unlike a CSV lookup, a KV Store collection is read/write at runtime from apps and REST endpoints, not just search-time read-only.

File locations

Configuration file: collections.conf.

Scope	Path
App	`$SPLUNK_HOME/etc/apps/<app_name>/{default,local}/collections.conf`

A collection belongs to the app that defines it -- no system-level stanza.

Settings

Setting	Description
`enforceTypes`	When `true`, an insert with an invalid data type fails outright; when `false`, only the invalid field is dropped. Default `false`.
`field.<name>`	Declares the type (`number`\|`bool`\|`string`\|`time`) of a named field; if unset, the type is inferred from the inserted JSON.
`accelerated_fields.<name>`	A JSON acceleration definition, e.g. `{"a":1,"b":-1}` for a compound ascending-then-descending index. An acceleration always exists implicitly on `_key`. Order matters: an `{"a":1,"b":1}` acceleration speeds queries on `a` and `a`+`b`, but not `b` alone. Compound accelerations can't repeat a field in an array, or KV Store may fail to start. Invalid JSON is silently ignored.
`profilingEnabled` / `profilingThresholdMs`	Logs slow-running operations above the threshold (milliseconds); `0` logs everything. Affects collection performance while enabled. Defaults `false` / `1000`.
`replicate`	Whether the collection replicates to indexers. When `false`, non-local lookups against it are unavailable. Default `false`.
`replication_dump_strategy` / `replication_dump_maximum_file_size`	`one_file` or `auto` (split once the collection exceeds the max file size, in KB, capped by `distsearch.conf`'s `concerningReplicatedFileSize`). Defaults `auto` / `10240`.
`type`	Internal use only -- `internal_cache` or `undefined`. Changing topology (standalone/SHC/pool) with `internal_cache` set erases the collection's data. Default `undefined`.

Example

[mycollection]
field.foo = number
field.bar = string
accelerated_fields.myacceleration = {"foo": 1, "bar": -1}

A two-field typed collection with a compound acceleration sorting foo ascending then bar descending.

Validation

Set replicate = true deliberately when a collection backs a lookup that must work from every search head cluster member and indexer, not just locally.
Avoid repeating a field across multiple array positions inside a compound accelerated_fields.<name> definition -- it can prevent KV Store from starting.
Leave profilingEnabled off in normal operation -- it has a real performance cost -- and enable it only while diagnosing slow KV Store operations.
Never hand-set type = internal_cache outside of Splunk-internal use; doing so risks silent data loss on a topology change.

← Back to References

References / Splunk platform configuration

Custom Search Commands Configuration

commands.conf registers a custom SPL command -- one [<STANZA_NAME>] stanza per command, the stanza name being the command's invocation name in SPL -- and declares its script, execution-model characteristics, and (for the newer chunked protocol) resource limits. Backs the Splunk Taxonomy's Custom Search Command object (SOT-01.05.02).

Definition

If filename is not set, Splunk searches for an external program by appending extensions (.py, .pl, and with chunked=true also .exe/.bat/.cmd/.sh/no-extension) to the stanza name. Every setting below falls back to its default if omitted -- a command can be registered with just a stanza header.

File locations

Configuration file: commands.conf.

Scope	Path
System	`$SPLUNK_HOME/etc/system/{default,local}/commands.conf`
App	`$SPLUNK_HOME/etc/apps/<app_name>/{default,local}/commands.conf`

Almost always shipped inside the app that owns the command, rarely hand-edited at system level.

Script identification

Setting	Description
`type`	`python` or `perl`. Default `python`.
`filename`	Script/program in the app's `bin/` directory -- cannot reference anything outside it. With `chunked=true`, a platform-specific `bin/<platform>/` subdirectory (e.g. `linux_x86_64`) is searched first; a `*.path` pointer file can point at a system binary instead.
`python.required` / `python.version`	Comma-separated supported Python versions; takes precedence over the deprecated `python.version`.
`command.arg.<n>`	Additional command-line arguments (with `$SPLUNK_HOME`-style env-var substitution), valid only when `chunked=true`.
`local`	Run only on the search head, never pushed to peers. Default `false`.

Streaming & execution model

Setting	Description
`streaming`	Whether the command is streamable (can run per-event, potentially distributed to peers). Default `false`.
`retainsevents`	Retains events like `sort`/`dedup`/`cluster`, vs. transforming them like `stats`. Default `false`.
`generating` / `generates_timeorder`	Whether the command produces events from scratch rather than transforming input, and if so, whether it emits them in descending time order (latest first).
`overrides_timeorder`	For non-generating, streaming commands: does it change event time-order?
`requires_preop` / `streaming_preop`	A requested pre-streaming search string, and whether it's strictly required vs. an optional optimization.
`is_order_sensitive`	Whether the command needs its input in a specific order. Default `false`.
`is_risky`	Flags the command as a potential security risk in Splunk Web's link/URL search-warning UI (not shown for ad hoc searches). Default `false`.

Input/output & header protocol

Governs the legacy (non-chunked) Intersplunk.py protocol's header/CSV exchange with the script.

Setting	Description
`enableheader` / `outputheader`	Whether the script expects a header section before CSV input, and whether its own output includes one. `enableheader` default `true`; `outputheader` default `false`.
`passauth`	Passes authString/sessionKey/owner/namespace in the header (requires `enableheader=true`; ignored under `chunked=true`, which always passes an auth token). Default `false`.
`pass_timezone`	Passes the user's serialized timezone in the header -- used e.g. so PDF-rendered alert charts use the user's timezone. Requires `enableheader=true`.
`requires_srinfo`	Requires SearchResultsInfo; emits the info CSV's path as `infoPath` in the header. Requires `enableheader=true`.
`changes_colorder` / `needs_empty_results`	Whether script output reorders result columns (default `true`), and whether the command should still be invoked on empty intermediate results (default `true`).
`stderr_dest`	`log` (search.log), `message` (search info messages, optionally leveled via an ALL-CAPS prefix), or `none`. Default `log`.

Field & argument handling

Setting	Description
`required_fields` / `clear_required_fields`	Comma-separated fields the command needs (default `*`, no error if missing), and whether that list is exhaustive (`true`, typical for transforming commands) or additive to downstream requirements (`false`, typical for streaming commands).
`supports_multivalues`	Multivalue fields arrive as Python lists rather than a flat string when using Intersplunk.
`supports_getinfo`	Supports dynamic settings probing via a `__GETINFO__`/`__EXECUTE__` first argument.
`supports_rawargs` / `undo_scheduler_escaping`	Whether the command accepts raw (unquoted-stripped) arguments, and whether scheduler-applied escaping on those raw arguments should be undone. Both default `false`.

Chunked protocol & limits

The newer "chunked" custom search command protocol restricts which settings apply -- only is_risky, maxwait, maxchunksize, filename, command.arg.<n>, python.version, and run_in_preview are valid alongside it.

Setting	Description
`chunked`	Opts into the chunked protocol instead of legacy Intersplunk. Default `false`.
`maxwait`	Max seconds the command may pause before producing output (chunked only; not on Windows). `0` = pause forever. Default `0`.
`maxchunksize`	Max chunk size (metadata + body) the command may emit before being terminated (chunked only). `0` = unlimited. Default `0`.
`run_in_preview`	Whether the command runs during preview generation, not just final output. Defaults to `false` when `chunked=true` (preview can be expensive for chunked commands), `true` otherwise.
`maxinputs`	Max events passed to the command per invocation, capped by `limits.conf`'s `maxresultrows`. `0` = no limit. Default `50000`.
`perf_warn_limit`	Logs a performance warning above this many input events; `0` disables it. Default `0`.

Example

TYPE = python
streaming = false
maxinputs = 50000

[createrss]
filename = createrss.py

[sendemail]
filename = sendemail.py

[windbag]
filename = windbag.py
supports_multivalues = true

Global defaults for every custom command in the file (Python, non-streaming, 50000-event cap), then three commands each pointing at their own script, one of which opts into multivalue-field support.

Validation

Confirm filename resolves inside the app's bin/ directory -- it cannot reference anything outside it, by design.
Set is_risky = true deliberately for any command capable of destructive or sensitive operations, so Splunk Web's link-based search warning fires for it.
Prefer chunked = true for new commands and confirm only the chunked-valid settings (is_risky, maxwait, maxchunksize, filename, command.arg.<n>, python.version, run_in_preview) are relied upon -- other settings are silently ignored under the chunked protocol.
Set clear_required_fields to match the command's real behavior -- false for streaming commands that pass fields through, true for transforming commands that reshape the result set.
Leave python.version unset in favor of python.required, per the spec's deprecation guidance.

← Back to References

References / Splunk platform configuration

Data Models Configuration

datamodels.conf configures a data model's automatic acceleration -- whether it's accelerated, the retention/backfill window, scheduling and workload, cross-instance summary sharing -- plus dataset-editor internals and search-time defaults. Backs the Splunk Taxonomy's Data Model (SOT-01.04.01) and Data Model Acceleration (SOT-01.04.03) objects.

Definition

One [<datamodel_name>] stanza per data model, named to match the model itself. Acceleration creates auxiliary per-bucket tsidx column stores for the model's fields/values, at the cost of disk and indexer CPU -- everything under the acceleration.* prefix tunes that mechanism.

File locations

Configuration file: datamodels.conf.

Scope	Path
System	`$SPLUNK_HOME/etc/system/{default,local}/datamodels.conf`
App	`$SPLUNK_HOME/etc/apps/<app_name>/{default,local}/datamodels.conf`

Acceleration: core settings

Setting	Description
`acceleration`	Enables automatic acceleration for this model. Default `false`.
`acceleration.earliest_time`	Relative time string (e.g. `-7d`) for how far back column stores are retained -- and, absent a backfill setting, how far back they're built. Empty string means keep forever.
`acceleration.backfill_time`	Advanced: limits initial column-store creation to a narrower, more recent window than `acceleration.earliest_time` -- must be more recent than it. Setting this too narrow risks missing a window of data if an indexer is down longer than the backfill period.
`acceleration.max_time`	Approximate max seconds the column-store creation search may run; `0` = no limit. Default `3600`.
`acceleration.poll_buckets_until_maxtime`	When `true`, every machine keeps polling buckets for new data for the full `max_time` instead of finishing early -- reduces summarization latency at the cost of counting against concurrent-search limits for longer. Default `false`.
`acceleration.cron_schedule`	Cron schedule for probing/generating column stores. Default `/5 * * *`.
`acceleration.manual_rebuilds`	When `true`, prevents `summarize` from auto-rebuilding summaries it considers outdated (stale or unparseable search definition). Default `false`.
`acceleration.max_concurrent`	Max concurrent acceleration instances the scheduler runs for this model. Default `3`.

Acceleration: scheduling & workload

Setting	Description
`acceleration.allow_skew`	Percentage or duration that randomly staggers when the scheduled acceleration search actually fires, avoiding thundering-herd scheduling. `0` disallows skew (the default).
`acceleration.schedule_priority`	`default`, `higher`, or `highest` -- raises this model's acceleration search above other data-model-accelerated searches (and, at `highest`, above continuous-scheduled searches too, though real-time-scheduled searches at `highest` still win overall). Requires the owner hold `edit_search_schedule_priority`. Overuse impedes the scheduler's ability to minimize starvation.
`acceleration.workload_pool`	Assigns the acceleration search to a named pool from `workload_pools.conf`. Falls back to workload-rule-based assignment, then `default_pool`, if unset.

Acceleration: consistency & cross-instance sharing

Setting Description

acceleration.allow_old_summaries When false (default), datamodel/from/tstats searches only use bucket summaries whose stored search still matches the model's current definition -- summaries that drifted out of sync are excluded. true allows stale-but-present summaries to answer the search instead.

acceleration.source_guid Advanced: points this model at an already-accelerated summary on a remote search head/SHC by GUID, instead of building its own -- saves duplicate summary-building work across instances sharing an identical model definition. Once set, the model can't be edited in Splunk Web, local acceleration settings are ignored, and allow_old_summaries defaults to true since the remote model's definition can drift.

Hunk-specific acceleration settings

Apply only to Hunk (Hadoop-backed) data models.

Setting	Description
`acceleration.hunk.compression_codec`	Compression codec for the accelerated ORC/Parquet files.
`acceleration.hunk.dfs_block_size`	Block size, in bytes, for the compression files.
`acceleration.hunk.file_format`	`orc` or `parquet`.

Dataset-related attributes

Internal, dataset-editor-managed settings the spec explicitly warns against hand-editing under normal conditions: dataset.description (user-entered description), dataset.type (datamodel vs. the root-table table type), dataset.commands/dataset.fields (auto-generated JSON payloads defining a table dataset), and the dataset.display.* family controlling the editor's preview behavior -- diversity sampling mode, sample ratio, event limit, current editing step, table-vs-datasummary preview mode, and the datasummary view's time range.

Setting	Description
`dataset.description`	User-entered description of the dataset.
`dataset.type`	`datamodel`, or `table` for a root table dataset.
`dataset.commands` / `dataset.fields`	Auto-generated JSON payloads that define a table dataset.
`dataset.display.diversity`	Event sampling for the dataset preview: `latest`, `random`, `diverse` or `rare`. Default `latest`.
`dataset.display.sample_ratio`	Sample ratio as 1/n -- `500` gives each event a 1-in-500 chance. Default `1`.
`dataset.display.limiting`	Maximum events searched for the preview. Default `100000`.
`dataset.display.mode`	`table` (events as rows) or `datasummary` (field values as columns). Default `table`.
`dataset.display.datasummary.earliestTime` / `dataset.display.datasummary.latestTime`	Time range of the search behind the datasummary view.
`dataset.display.currentCommand`	The command step currently selected in the dataset editor.

Search behavior settings

Setting Description

strict_fields Default for | datamodel's strict_fields argument (also applies to | from): true returns only the fields defined in the model's constraints; false also returns inherited/derived fields (extractions, eval fields, lookups). Default true. Overridable per-search.

tags_whitelist Performance setting: comma-separated allow-list of tag fields the model actually needs, so unrelated tag fields (and the event types they tag) aren't loaded for every search against this model. Only useful for models with many tag-field attributes; doesn't recognize tags used in constraint searches. Changing it on an accelerated model triggers a rebuild unless acceleration.manual_rebuilds is set.

Example

[mymodel]
acceleration = true
acceleration.earliest_time = -5d
acceleration.poll_buckets_until_maxtime = true
acceleration.cron_schedule = */10 * * * *
acceleration.hunk.compression_codec = snappy
acceleration.hunk.dfs_block_size = 134217728
acceleration.hunk.file_format = orc

Accelerates the last 5 days of data, polling buckets for the full run time rather than finishing early, on a 10-minute schedule -- with Hunk-specific ORC/snappy settings for a Hadoop-backed data source.

Validation

Size acceleration.earliest_time to genuine query needs -- longer retention windows mean more disk and indexer CPU spent maintaining column stores indefinitely.
Never set acceleration.backfill_time narrower than your indexer downtime tolerance -- an indexer down longer than the backfill window silently misses a slice of accelerated data.
Only set acceleration.source_guid when you fully understand its effects -- it disables Splunk Web editing for the model and stops local summary creation entirely.
Don't hand-edit the dataset.* family outside the dataset editor -- these are internal, editor-managed payloads.
Reserve non-default acceleration.schedule_priority values for genuinely mission-critical models; overuse degrades the scheduler's overall fairness.

← Back to References

References / Splunk platform configuration

Distributed Search Configuration

distsearch.conf configures how a search head discovers and talks to its search peers, generates the key pair used to authenticate distributed search, and replicates its knowledge bundle out to those peers -- via classic, cascading, RFS (remote file system), or mounted-bundle strategies. Most settings are configured on the search head; the bundle-mounting settings are configured on the search peers instead. Backs the Splunk Taxonomy's Distributed Search Peer (SOT-08.02.04) and Knowledge Bundle Replication (SOT-08.01.04) objects.

Definition

Several stanza families: [distributedSearch] (peer list and core behavior), [tokenExchKeys] (key pair generation), [replicationSettings] and its sub-stanzas (bundle replication), [searchhead:<name>] (mounted-bundle configuration, set on peers), the allow/deny list stanzas, and [distributedSearch:<group-name>] (named search-peer groups). Many older settings are DEPRECATED or "no longer supported" and silently ignored -- check the current release's spec before relying on an unfamiliar setting.

File locations

Configuration file: distsearch.conf.

Scope	Path
System	`$SPLUNK_HOME/etc/system/{default,local}/distsearch.conf`
App	`$SPLUNK_HOME/etc/apps/<app_name>/{default,local}/distsearch.conf`

On a search head cluster, edited on the deployer at etc/shcluster/apps/<app_name>/local, then pushed to every member's own etc/apps copy.

Distributed search core settings

Setting	Description
`disabled`	Turns distributed search off entirely. Default `false`.
`statusTimeout`	Timeout, in seconds, for gathering a peer's info via `/services/server/info`; read/write timeouts are automatically double this. Default `10`.
`bestEffortSearch`	When `true`, a peer missing the knowledge bundle still participates in the search rather than being excluded outright (peers with no common bundle simply aren't searched). Default `false`.
`servers` / `disabled_servers` / `quarantined_servers`	Comma-separated `scheme://hostname:port` peer lists: the initial peer set, peers excluded from monitoring and search, and peers monitored-but-not-searched-by-default (an admin quarantines an unhealthy peer degrading overall performance; a user can still target it explicitly via `splunk_server`).
`useDisabledListAsBlacklist`	When `true`, a peer appearing in both `servers` and `disabled_servers` is disabled; when `false` (default), it's enabled.
`defaultUriScheme`	`http` or `https` used for a newly added peer with no explicit scheme. Default `https`.
`parallelReduceBackwardCompatibility`	Whether parallel reduce avoids search ID duplication by appending search head server names to remote SIDs. `enterprise`: only when every search head and peer is newer than 8.3.0; `cloud`: only when all search heads and indexers share the same version. Otherwise SIDs are left unchanged and search may fall back to classic processing. Default `enterprise`.
`searchableIndexMapping`	Whether the search head periodically asks its peers which searchable indexes each holds, to keep a map of indexes to peers. Default `enabled`; change only when Splunk Support directs.
`bcs` / `bcsPath`	Currently not supported -- for a Bucket Catalog Service feature still under development. `bcsPath` defaults to `/bcs/v1/buckets`.
`heartbeatFrequency` / `heartbeatMcastAddr` / `heartbeatPort` / `ttl` / `autoAddServers` / `skipOurselves`	Deprecated.
`trySSLFirst` / `removedTimedOutServers` / `checkTimedOutServersFrequency` / `peerResolutionThreads`	No longer supported; ignored.

Connection & timeout settings

Setting	Description
`connectionTimeout` / `sendTimeout` / `receiveTimeout` / `serverTimeout`	Seconds to establish a connection, write/send data, and read/receive data from a peer. Defaults `10` / `30` / `600`. Replace the deprecated single `serverTimeout` setting.
`authTokenConnectionTimeout` / `authTokenSendTimeout` / `authTokenReceiveTimeout`	Same three phases, specifically for fetching a peer's authentication token; all accept fractional seconds. Defaults `5` / `10` / `10`.
`useIPAddrAsHost`	Caches DNS resolution results from peer communications to speed up connections; search-head-only, refreshed roughly every minute on successful auth. Has no effect if a `[proxyConfig]` proxy is configured or `sslVerifyServerName` is `true`. Default `true`.

Key pair generation

[tokenExchKeys] governs the local instance's distributed-search key pair, used to authenticate search requests between search heads and peers.

Setting	Description
`certDir` / `publicKey` / `privateKey`	Directory holding this instance's key pair (plus peers' public keys), and the public/private key file names within it. Defaults `$SPLUNK_HOME/etc/auth/distServerKeys`, `trusted.pem`, `private.pem`.
`genKeyScript`	Command used to (re)generate the key pair. Default `$SPLUNK_HOME/bin/splunk, createssl, audit-keys`.
`minKeyLength`	Minimum key length (bits) this instance accepts when acting as a search peer, e.g. `2048`. No default (unenforced).
`legacyKeyLengthAuthPolicy`	`warn` (log and allow) or `reject` (log and refuse) an auth-token request from a search head whose key is shorter than `minKeyLength` -- covers search heads registered before `minKeyLength` was configured on this peer.

Bundle replication: policy & classic settings

Setting	Description
`replicationPolicy`	`classic` (search head replicates to every peer directly), `cascading` (replicates to a few peers who relay to the rest), `rfs` (uploads to remote storage like S3, peers pull from there), or `mounted` (peers read the search head's bundle over shared storage -- replaces the old `shareBundles` setting). Default `classic`.
`connectionTimeout` / `sendRcvTimeout`	Classic-replication-specific connection and full-replication send/receive timeouts, in seconds. Both default `60`.
`bundleTransferTimeout`	Max total seconds for a bundle upload to complete; `0` disables the timeout. Default `0`.
`replicationThreads`	Max threads for bundle replication, or `auto` to size by peer CPU count (2 threads at ≤3 CPUs, up to CPUs−4 at 16+). Max accepted value `16`. Default `auto`.
`maxBundleSize` / `warnMaxBundleSizePerc`	Hard cap on bundle size in MB (max `102400`/100GB; replication fails above it) and the percentage of that cap at which the search head starts warning. Defaults `2048` / `75`.
`concerningReplicatedFileSize` / `excludeReplicatedLookupSize`	Per-file size (MB) that triggers a log warning, and a separate lookup-file size cap above which the lookup is excluded from the bundle entirely (`0` disables exclusion). Defaults `500` / `0`.
`allowDeltaUpload` / `allowDeltaIndexing`	Whether replication sends only the changed portion of the bundle, and whether indexers similarly index/hard-link only changed lookup files rather than the full bundle each time. Both default `true`.
`sanitizeMetaFiles`	Strips comments/cosmetic whitespace from `*.meta` files before replication to avoid triggering unnecessary replications. Default `true`.
`useSHPBundleReplication`	Search head pooling only: whether pooled search heads compete to decide which one replicates the bundle (`true`) or each replicates individually (`false`). `always`, with mounted bundles, identifies bundles by the pool GUID rather than each server name. Default `true`.
`preCompressKnowledgeBundlesClassicMode`	Whether a search head cluster member compresses knowledge bundles before replicating them to peers, to save bandwidth. Default `true`.
`useChecksumforDeltaCalculation`	Uses file checksums to decide which files go into a delta bundle, for a more accurate estimate of what changed. Default `false`; change only when Splunk Support directs.
`slowReplicationLoggingInterval`	Interval, in seconds, for logging slow bundle-transfer messages for each peer; `0` turns them off. Default `30`.
`statusQueueSize`	How many bundle-replication cycle status values the search head keeps in memory for queries. Default `5`.
`maxMemoryBundleSize` / `allowStreamUpload` / `allowSkipEncoding`	No longer supported.

Cascading & RFS replication settings

Setting	Description
`cascade_replication_status_interval` / `cascade_replication_status_unchanged_threshold`	How often (max/recommended `60s`) the cascading-replication status thread polls, and how many stuck-unchanged intervals before a peer's replication is resent (max `20`).
`cascade_plan_replication_retry_fast` / `cascade_plan_replication_threshold_failures`	Whether a cascading plan retries after too many peer failures, and the failure-count threshold that triggers it (`0` auto-configures to ~5% of participating peers).
`path`	Required for RFS: the remote storage location for bundles, as `<scheme>://<location>` -- `s3://` for S3-API object stores or `file://` for a (potentially NFS-mounted) POSIX filesystem.
`enableRFSMonitoring` / `rfsMonitoringPeriod`	Enables a peer's periodic poll-and-download of new bundles from remote storage, and the polling interval in seconds (minimum enforced `60`). Required on search peers.
`rfsSyncReplicationTimeout` / `activeServerTimeout`	How long a search head waits for synchronous RFS replication (default computed from `rfsMonitoringPeriod`), and how long a peer waits before considering the search head inactive for RFS purposes. Default `360` for the latter.
`remote.s3.endpoint` / `remote.s3.bucket_name` / `remote.s3.encryption`	S3 endpoint URL, bucket name (when not inferable from the endpoint), and server-side encryption scheme (`sse-s3` or `none`).
`rfsMaxDeltaCountBetweenFull`	Max delta bundle uploads between full uploads for RFS. Default `5`.
`preCompressKnowledgeBundlesCascadeMode`	The same pre-compression of knowledge bundles, for cascading replication only. Default `false`.
`remote.s3.url_version`	`v1` (the bucket is the first element of the path) or `v2` (the bucket is the outermost subdomain). Set only for non-AWS S3-compatible storage configured for v2 URLs. Default `v1`.
`remote.s3.supports_versioning`	Whether the remote storage uses versioning, which changes how splunkd deletes data: `true` deletes every version of an object, `false` issues a simple DELETE. RFS replication itself doesn't use versioning. Don't change it in Splunk-managed Cloud. Default `false`.

Bundle mounting & allow/deny lists

Stanza / Setting	Description
`[searchhead:<name>]` `mounted_bundles` / `bundles_location`	Set on search peers only, paired with `replicationPolicy = mounted` on the search head named by the stanza (matching its `server.conf` `serverName`): whether mounted bundles are used, and the shared-storage mount path equivalent to `$SPLUNK_HOME/etc/`.
`[replicationAllowlist]` / `[replicationDenylist]`	Regex-based (Splunk-style, `...`/`*` wildcards) allow/deny patterns controlling which files under `$SPLUNK_HOME/etc` replicate at all; deny takes precedence over allow. Applied globally, not per-app.
`[replicationSettings:refineConf]` `replicate.<conf_file_name>`	An additional filter layer specifically for `.conf`/`.meta` files, applied only to files already allow-listed with a `refine.`-prefixed name.
`[replicationSettings:fileSpecific]` `<file_path> = allow\|deny`	A specific file path override that supersedes both allow-list and deny-list regex matches.
`[bundleEnforcerAllowlist]` / `[bundleEnforcerDenylist]`	Peer-side safeguard: rejects an incoming bundle containing files that don't match the allow list, or that match the deny list (deny wins over allow). Both empty (the default) means peers accept any bundle.

Distributed search group definitions

[distributedSearch:<splunk-server-group-name>] defines a named subset of peers a search can be explicitly targeted at via the splunk_server_group argument.

Setting	Description
`servers`	Comma-separated `hostname:port` peer identifiers belonging to this group.
`default`	Marks this group as the one searched when a search doesn't specify a group -- only one group may be `true` at a time. If no group is marked default (or the default group has no `servers`), the full `[distributedSearch]` peer set is searched instead. Default `false`.

Example

[distributedSearch]
servers = https://192.168.1.1:8059,https://192.168.1.2:8059

[replicationSettings]
connectionTimeout = 10
sendRcvTimeout = 60
replicationPolicy = mounted

[replicationAllowlist]
allConf = *.conf

[searchhead:searcher01]
mounted_bundles = true
bundles_location = /opt/shared_bundles/searcher01

Two search peers reached over HTTPS on port 8059, shorter classic-replication timeouts, and a mounted-bundle setup for a search head named searcher01 -- its peers read bundles from shared storage instead of receiving a push replication.

Validation

Confirm mounted-bundle settings ([searchhead:<name>]) are placed on the search peers, not the search head -- and that the stanza name exactly matches the search head's server.conf serverName.
Set maxBundleSize above your actual bundle size before relying on it, and never decrease it below the current bundle size on disk.
Constrain [replicationDenylist]/[replicationAllowlist] patterns narrowly -- they apply globally across all configuration data, not per-app, so an overly broad pattern affects every app's replication.
Leave minKeyLength/legacyKeyLengthAuthPolicy unset unless you have a specific key-length hardening requirement; misconfiguring reject can lock out legitimate search heads.
Verify only one [distributedSearch:<group>] stanza has default = true at a time.
Check the current release's spec before relying on a "DEPRECATED" or "no longer supported" setting (e.g. heartbeatFrequency, trySSLFirst, serverTimeout) -- several are silently ignored.

← Back to References

References / Splunk platform configuration

Federated Search Configuration

federated.conf registers federated providers -- remote Splunk deployments a search head can run federated searches against -- and tunes the overall federated-search subsystem: heartbeat monitoring, RBAC, search optimizations, provider capability negotiation, and which SPL commands are blocked on standard- vs. transparent-mode providers. Applies to on-premises Splunk Enterprise; Splunk Cloud/ES use the separate federated-providers.conf/federated-indexes.conf files instead. Backs the Splunk Taxonomy's Federated Search Provider (SOT-06.05.01) and Federated Index (SOT-06.05.02) objects.

Definition

Three stanza families: [provider://<unique-federated-provider-name>] defines one remote federated provider; [general] holds deployment-wide federated-search behavior applicable to every provider and every search head cluster member; and a large set of narrowly-scoped stanzas ([features], [s2s_standard_mode_unsupported_command:<cmd>], [s2s_transparent_mode_unsupported_command:<cmd>], [s2s_unsupported_command:show_source]) control fine-grained command blocking and capability negotiation. A federated index -- the SPL-searchable index=<name> mapping to a provider's dataset -- is defined separately, in indexes.conf. The great majority of [general] settings are explicitly flagged "Do not change ... unless instructed to do so by Splunk Support" -- treat them as support-tunable, not admin-tunable, knobs.

File locations

Configuration file: federated.conf.

Scope	Path
System	`$SPLUNK_HOME/etc/system/{default,local}/federated.conf`
App	`$SPLUNK_HOME/etc/apps/<app_name>/{default,local}/federated.conf`

Provider stanza: connection & identity

Setting	Description
`type`	Provider type; only `splunk` is currently valid here (a remote Splunk deployment). Default `splunk`.
`hostPort`	The remote provider's `host:port`. No default.
`serviceAccount` / `password`	Credentials for a service account on the remote provider, used by the federated search head to query it securely. No defaults.

Provider stanza: mode & app context

Setting	Description
`mode`	`standard` (federated searches can use knowledge objects from either the remote or the local search head, per `useFSHKnowledgeObjects`) or `transparent` (searches can only use local search-head knowledge objects -- `useFSHKnowledgeObjects` is always treated as `true`). Default `standard`.
`useFSHKnowledgeObjects`	Whether federated searches use the local (federated) search head's knowledge objects instead of the remote provider's. Only meaningful in `transparent` mode -- ignored as misconfigured if set `true` on a `standard`-mode provider. Default `false`.
`appContext`	The remote app's short name federated searches with this provider run under -- scopes which knowledge objects are visible and can affect quota/resource allocation. Only applies to `type=splunk`/`mode=standard` providers; ignored for transparent-mode providers, which instead inherit the local search's app context. Default `search`.
`useAppContextFromSearch`	When `true`, uses the app context of the local search itself instead of the fixed `appContext` setting -- risky, since the search fails if that app context doesn't exist on the remote provider. Always effectively `true` for transparent-mode providers, overriding this setting. Default `false`.

Provider stanza: index-based filtering

fedSrchIndexesAllowed works together with [general]'s allowIndexBasedProviderFiltering to decide which federated providers a given search reaches.

Setting Description

fedSrchIndexesAllowed Semicolon-separated, wildcardable list of federated indexes this provider may be searched for (only enforced when allowIndexBasedProviderFiltering=true). Soft enforcement: if a search names multiple federated indexes and at least one maps to this provider and is allowed, the whole search string is still sent to the provider. An empty value blocks the provider from ever being searched. This is additive to, not a replacement for, ordinary RBAC on the underlying indexes. Default *.

General: heartbeat & provider verification

Setting	Description
`heartbeatEnabled` / `heartbeatInterval`	Whether the federated-provider health-monitoring mechanism runs, and its polling interval in seconds (>5). When a provider fails `connectivityFailuresThreshold` consecutive checks it's marked invalid and skipped by federated searches until it reconnects. Defaults `true` / `60`.
`connectivityFailuresThreshold`	Consecutive heartbeat failures before a provider is marked invalid. Default `3`.
`providerVerificationMode`	`deactivated` (no verification), `audit` (verify and log failures, but still allow searches), `strict` (block searches to unverified providers), or `auto` (apply `strict` only to providers that advertise verification capability -- eases mixed-version rollouts). Default `deactivated`.
`fshFeaturesTransactionRequestEnabled`	Whether the local deployment sends a management transaction to each remote provider to query its federated features and capabilities. Default `true`.
`fshHeartbeatRestConnectTimeout` / `fshHeartbeatRestReadTimeout`	Connection and read timeouts, in seconds, for the heartbeat REST calls that poll remote providers (connectivity, server and cluster GUIDs, versions, capabilities). A heartbeat that exceeds either fails with a timeout error. Default `10` each.

General: RBAC & consent

Setting	Description
`needs_consent`	Shows a legal-acknowledgment checkbox in the provider-definition UI, since misconfigured federated providers can create regulatory-compliance risk. Default `true`.
`allowedAndDefaultFederatedProvidersEnabled`	Whether `authorize.conf`'s role-based `srchFederatedProvidersAllowed`/`srchFederatedProvidersDefault` settings are enforced for federated searches on this deployment. Default `true`.
`allowIndexBasedProviderFiltering`	Master switch for the `fedSrchIndexesAllowed` per-provider filtering described above. Default `true`.
`allowCaseInsensitivityForFederatedProvider`	When `true`, provider names are matched case-insensitively over REST -- multiple stanzas differing only by case collapse to one instance. Rename providers to be uniquely-cased rather than relying on this. Default `true`.

General: search optimization & preview control

A large family of allowAst* search-language optimization toggles (projection elimination, predicate merge, redistribute insertion, chart-to-tstats/datamodel-stats-to-tstats replacement, table-to-fields replacement, sdselect-to-sdsql substitution) -- all support-only tuning, cross-referenced against the matching search_optimization::* keys in limits.conf.spec. Alongside these:

Setting	Description
`verbose_mode`	Whether federated searches may run in verbose mode at all (vs. only fast/smart mode). Default `true`.
`enable_streaming_optimization`	For pure streaming searches, sends only enough data to render events/timeline in the UI instead of pulling every matching event. Set only on the federated search head. Default `true`.
`previewOnRshEnabled`	Whether search preview runs on the remote search head for federated searches -- disabling it can speed up long-running high-cardinality federated searches, since previews there serve no UI purpose. Default `false`.
`max_preview_generation_duration` / `max_preview_generation_inputcount`	Caps on preview-generation time (seconds) and input row count for Splunk-to-Splunk federated searches -- raise above `0` (unlimited) if an intermediary like an ELB times out federated searches before preview completes. Both default `0`.
`federated_search_max_events_per_bucket`	Events fetched per search-view timeline bucket. Default `200`.
`allowAstPredicateMerge` / `allowAstReplaceChartCmdsWithTstats`	Turn on the predicate-merge and chart-to-`tstats` search optimizations on the federated search head. Default `true` each.
`allowAstProjectionElim` / `allowAstInsertRedistributeCommand` / `allowAstReplaceDatamodelStatsCmdsWithTstats` / `allowAstReplaceTableWithFields` / `allowAstReplaceSdselectWithSdsql`	Turn on, on the federated search head: projection elimination; inserting a `redistribute` command; replacing `stats` with `tstats` in `\| datamodel` and `\| from datamodel` searches; replacing `table` with `fields`; and substituting `sdselect` with `sdsql`. Default `false` each. All but the last mirror a `search_optimization::*` setting in `limits.conf`; change only when Splunk Support directs.
`allowLookupsToExistOnlyOnRshForStandardMode`	Where lookups must be defined for standard-mode federated searches: `true` -- on the remote search head only; `false` -- both locally on the federated search head and on the remote search head. Default `true`.
`expand_federated_index_wildcard_only`	When `true`, a wildcard only expands to federated indexes if it carries the `federated:` prefix (`index=federated:f`); when `false`, `index=f` also matches federated indexes. Default `true`.

General: retries, timeouts & legacy AWS support

Setting	Description
`federated_search_retry_count`	Retries (with exponential backoff) a federated search against a remote peer that returns HTTP 429 (too many requests) instead of failing outright; `0` disables retry, and the peer returns HTTP 503 instead. Configured only on the federated search head. Default `0`.
`remoteEventsDownloadRetryCountMax` / `remoteEventsDownloadRetryTimeoutMs`	Max retries and retry interval (ms) for a failed verbose-mode event download from a provider. Defaults `20` / `1000`.
`federated_search_remote_ttl`	How long, in seconds, remote-search-head artifacts from a federated search are retained after completion. Default `600`.
`s2s_standard_mode_local_only_commands`	Comma-separated SPL commands that, in standard-mode federated searches, must run only on the local search head -- that command and everything after it in the pipeline. Default `mcollect, outputlookup, sendalert, sendemail`.
`legacy_aws_federated_provider_support` / `legacy_aws_federated_index_support`	Phased-deprecation gates for legacy AWS-backed federated provider/index types (`aws_s3`, `aws_s3_sal`, `aws_lake`) ahead of migration to the Data Management app -- a comma-separated list of `<type>:<allowed-actions>` rules (actions separated by `\|`). Both default `:` (unrestricted). Federated Search for Splunk (S2S) providers are unaffected by either setting.

Feature capability stanza

[features] declares capabilities for named internal features using dot notation: <featureName>.capabilities.<capabilityName>.types.<type> = <value>, where <type> is string, unsignedInt, or boolean. For example, FSH_CATALOGUE_TRANSACTION_REQUEST_TIMEOUT.capabilities.enabled.types.boolean = true. Support-only; not meant for direct administrator tuning.

General: search actions, proxy bundles & other settings

All in [general]. The spec marks most of these as settings to change only when Splunk Support directs you to.

Setting	Description
`controlCommandsFeatureEnabled`	Whether the federated search head can send search actions -- such as pausing or cancelling a search -- to federated providers. Default `true`.
`controlCommandsMaxThreads` / `controlCommandsMaxTimeThreshold`	The maximum threads that run those search actions against providers, and the maximum seconds the federated search head waits for providers to finish the same action. Default `5` each.
`proxyBundleToCaptainEnabled`	Whether bundles from the federated search head are routed through a search head cluster member to the captain via the proxy endpoints (`true`), or sent over the legacy single-hop endpoint (`false`). Default `true`.
`proxyBundleFromMemberToCaptainConnectionTimeout` / `proxyBundleFromMemberToCaptainReadTimeout` / `proxyBundleFromMemberToCaptainWriteTimeout`	Connection, read and write timeouts, in seconds, for that proxy bundle transfer. Default `60` each.
`proxyBundlesTTL`	How long, in seconds, a proxy bundle is kept on the remote search head after it was last used for a search. Default `172800` (48 hours).
`rsh_delta_write_timeout`	Seconds added to `limits.conf`'s `results_queue_read_timeout_sec` and sent to the remote search head as its HTTP write timeout, so it doesn't time out before the federated search head. `0` lets the remote search head use its own default. Default `0`.
`skipLoadWithoutPpcFor`	Comma-separated internal tags for search head pool member functions (`captain_update`, `add_sid`, `remove_sid`); a listed tag reverts to default settings and adds redundant caching. No default.
`sal_api_base_url`	Base URL for the Cisco Security Analytics and Logging (SAL) API. Default `https://ci.manage.security.cisco.com/`.

Blocked-command stanzas

A family of narrow stanzas, each governing whether one SPL command is blocked for federated search, with an active boolean whose sense is inverted from what the name suggests: active=true means the command is not blocked. All default to blocked (active=false) except summarize and tstats, which default to allowed.

Stanza family	Description
`[s2s_standard_mode_unsupported_command:metadata]` / `:metasearch`	Standard-mode-only blocks for `metadata` and `metasearch`.
`[s2s_transparent_mode_unsupported_command:<cmd>]` / `allow_target` / `rsh_min_version_cloud` / `rsh_min_version_onprem` / `active`	One stanza per transparent-mode-blocked command: `makeresults`, `delete`, `dump`, `loadjob`, `map`, `run`, `runshellscript`, `script`, `sendalert`, `sendemail`, `rest`, `summarize`, `tstats`. The `makeresults` stanza additionally has `allow_target`, letting the command run against a specific transparent-mode-provider server/group via `splunk_server`/`splunk_server_group` even when blocked generally. The `summarize` and `tstats` stanzas additionally carry `rsh_min_version_cloud`/`rsh_min_version_onprem`, which force-block the command on providers running an older Splunk version regardless of `active`.
`[s2s_unsupported_command:show_source]`	Not command-blocking as such -- `rsh_min_version_cloud`/`rsh_min_version_onprem` block Show Source requests to providers below the given version.

Example

[provider://provider_1]
hostPort = remote_searchhead1:8090
password = secret1
serviceAccount = user1
type = splunk
appContext = search
useFSHKnowledgeObjects = 0
mode = standard

[provider://provider_2]
hostPort = remote_searchhead2:8090
password = secret2
serviceAccount = user2
type = splunk
appContext = search
useFSHKnowledgeObjects = 1
mode = transparent

[general]
max_preview_generation_duration = 0

Two remote Splunk providers -- one standard mode using its own knowledge objects, one transparent mode explicitly using the local search head's -- plus unlimited preview-generation time in the general federated-search settings.

Validation

Leave the large majority of [general] settings at their shipped defaults -- most are explicitly flagged support-only and changing them without Splunk Support guidance risks breaking federated search behavior in subtle ways.
Set fedSrchIndexesAllowed deliberately rather than leaving the default * when a provider should only serve a specific subset of federated indexes -- remember it's soft enforcement, layered on top of, not replacing, RBAC.
Understand the inverted sense of active in the [s2s_*_unsupported_command:*] stanzas before editing one -- active=true unblocks the command, it does not enable blocking.
Confirm useAppContextFromSearch is safe before enabling it -- every app context a user's search might run under must actually exist on the remote provider, or the federated search fails.
Only set useFSHKnowledgeObjects=true on transparent-mode providers -- it's silently ignored (and the provider is considered misconfigured) on standard-mode ones.
Remember federated indexes themselves are defined in indexes.conf, not here -- this file only defines the providers and the federation subsystem's behavior.

← Back to References

References / Splunk platform configuration

Audit Trail Configuration

audit.conf configures Splunk's internal audit trail subsystem -- whether audit events are routed into the index pipeline, which log format they use, and (per REST path) which audit actions actually get logged, including sampling. Backs the Splunk Taxonomy's Audit Trail Configuration object (SOT-11.06.02).

Definition

Two stanza types: the single [auditTrail] stanza controls the audit subsystem's overall routing and format, and any number of [auditconfig:/path] stanzas control which audit actions are logged for a specific REST endpoint path. There is no shipped default audit.conf -- absent a local override, audit actions are logged by default for every path.

File locations

Configuration file: audit.conf.

Scope	Path
System	`$SPLUNK_HOME/etc/system/{default,local}/audit.conf`
App	`$SPLUNK_HOME/etc/apps/<app_name>/{default,local}/audit.conf`

Audit trail settings

Setting	Description
`queueing`	Whether audit events are sent to the indexQueue. When `false`, an `inputs.conf` stanza must tail the audit log directly for events to reach an index. Default `true`.
`logging_format`	`v1` (legacy `Audit:[...]` format), `v2` (newer JSONL format with enriched metadata), or `both` -- use `both` while transitioning from v1 to v2. Default `both`.

Per-path audit action control

[auditconfig:/path] stanzas, one per REST resource path (e.g. /servicesNS/admin/app), control exactly which audit actions get logged for that path. Settings apply once the audit subsystem or audit.conf is reloaded via the REST API.

Setting	Description
`enabled`	Comma-separated list of audit actions explicitly logged for this path, or `all` to log everything defined for the stanza. Protected actions like `delete` always remain logged regardless of this setting.
`disabled`	Comma-separated list of audit actions explicitly skipped for this path, or `all` to deactivate everything. Attempts to deactivate a protected action like `delete` are ignored, with a warning logged to splunkd.log.
`sampling.<action>`	Positive integer sampling interval for a specific action -- logs 1 out of every N events (the first event, then every Nth after). `sampling.*` applies the same interval to every action the stanza governs. Ignored for protected actions (`delete`, authentication categories) and for any action that's deactivated -- sampling never overrides an explicit `disabled`.

Stanzas inherit settings from their nearest parent path -- [auditconfig:/services] applies to [auditconfig:/services/foo] unless the child stanza overrides the same setting itself.

Example

[auditTrail]
queueing = true
logging_format = v2

[auditconfig:/services/data/inputs]
enabled = all

[auditconfig:/services/data/inputs/monitor]
disabled = list
sampling.edit = 5

Audit events queued into the index pipeline in the newer v2 JSONL format; every audit action logged under /services/data/inputs, except the more specific monitor child path skips list actions entirely and samples edit actions at 1-in-5.

Validation

Remember protected actions such as delete always log regardless of disabled or sampling settings -- don't rely on audit.conf to suppress them.
Set logging_format = both only as a transitional state while consumers migrate from the legacy v1 format to v2 -- pick a single format once migration completes to avoid double-logging overhead.
Place broad [auditconfig:/path] stanzas at parent paths and only override specific settings at child paths, relying on inheritance rather than repeating full configuration at every level.
Confirm the audit subsystem or audit.conf is reloaded via the REST API after an [auditconfig:/path] change -- these settings don't take effect until then.
If queueing = false, confirm a matching inputs.conf stanza tails the audit log directly, or audit events never reach an index.

← Back to References

References / Splunk platform configuration

Indexes Configuration

indexes.conf configures Splunk's indexes and their properties -- from a single index's storage paths and retention policy, to shared volumes, SmartStore remote storage, metric indexes, and (legacy) Hadoop-backed virtual indexes. It is one of the largest and most consequential conf files in the platform; the spec itself opens with a caution that careless changes can drastically affect a Splunk installation. Backs the Splunk Taxonomy's Index (SOT-06.01.01), Metrics Index (SOT-06.01.02), Bucket Lifecycle Settings (SOT-06.03.02), Archive Location (SOT-06.03.03), Volume (SOT-06.04.01), and SmartStore Remote Storage (SOT-06.04.02) objects.

Definition

Four major stanza families: the global [default]/top-of-file settings; [<index>] per-index stanzas (index names use only lowercase letters, numbers, underscores, hyphens); [volume:<name>] shared storage-path allocations; and the External Resource Provider (ERP) family -- [provider-family:<name>], [provider:<name>], and per-virtual-index stanzas -- for Hadoop/Hunk-backed virtual indexes. Many settings require a full splunkd restart, not just a config reload, to take effect.

File locations

Configuration file: indexes.conf.

Scope	Path
System	`$SPLUNK_HOME/etc/system/{default,local}/indexes.conf`
App	`$SPLUNK_HOME/etc/apps/<app_name>/{default,local}/indexes.conf`
Cluster manager	`$SPLUNK_HOME/etc/manager-apps/_cluster/{default,local}/indexes.conf`
Indexer peer	`$SPLUNK_HOME/etc/peer-apps/_cluster/{default,local}/indexes.conf`

On an indexer cluster the manager's copy above is the one that matters -- it's pushed to every peer as the common configuration bundle. etc/master-apps is the pre-9.0 name for the same manager-side directory.

Global settings

Setting	Description
`defaultDatabase`	The index searched when none is specified. Default `main`.
`lastChanceIndex`	Catches events whose target index doesn't exist (bad `index` in `inputs.conf`, an invalid computed `_MetaData:Index`) instead of dropping them. Must name an existing, enabled index or splunkd won't start.
`memPoolMB` / `indexThreads`	Indexer memory pool size and indexing thread count; both default to `auto`-tuned based on system RAM/CPU. Advanced settings -- "CARELESSNESS IN SETTING THIS CAN LEAD TO LOSS OF JOB" per the spec's own caution.
`bucketMerging` / `bucketMerge.minMergeSizeMB` / `bucketMerge.maxMergeSizeMB` / `bucketMerge.minMergeCount` / `bucketMerge.maxMergeCount` / `bucketMerge.maxMergeTimeSpanSecs`	Enables and tunes the bucket-merge service, which localizes and combines small remote/local buckets. Overridable per-index. Default `bucketMerging=false`.
`assureUTF8`	Validates byte strings retrieved from the index are proper UTF-8; degrades indexing performance when enabled, and can only be set globally. Default `false`.
`enableRealtimeSearch`	Enables real-time searches. Default `true`.
`rtRouterThreads` / `rtRouterQueueSize`	Set `rtRouterThreads=1` if non-indexed real-time searches run regularly -- index throughput drops rapidly under a handful of concurrent ones otherwise. Not a true boolean; only `0` or `1` are valid.
`tsidxWritingLevel`	Enables tsidx performance/space improvements (levels 1-4); higher levels have limited backward search compatibility with older Splunk versions. Recommended to set globally. Default `3`.

A large remaining set of global settings (indexThreads tuning, maxRunningProcessGroups, bucketRebuildMemoryHint, hashTableSize, metadata-API auto-tune toggles, and similar) are explicitly advanced, support-only settings -- change them only under Splunk Support direction.

Core per-index paths & lifecycle

Backs the Splunk Taxonomy's Index object (SOT-06.01.01).

Setting	Description
`homePath` / `coldPath` / `thawedPath`	Required. Where hot/warm buckets, cold buckets, and thawed (manually restored) buckets live respectively. `homePath`/`coldPath` can reference a `volume:`; `thawedPath` cannot. Splunkd won't start without valid values for all three. Changes require a full restart.
`summaryHomePath` / `tstatsHomePath` / `bloomHomePath`	Where transparent summarization results, data-model-acceleration tsidx data, and bloomfilter files are stored, respectively. `tstatsHomePath` must reference a volume. None apply to remote-storage-enabled indexes.
`remotePath`	Presence of this setting means the index uses remote storage as its primary bucket repository instead of local disk -- see the remote storage section below. Must reference a `storageType=remote` volume.
`disabled` / `isReadOnly`	Toggles the index off, or makes it accept no new events while remaining searchable. Both default `false`; neither is supported on remote-storage-enabled indexes. `isReadOnly=true` requires `repFactor=0`.
`repFactor`	Indexer-cluster-peer-only: `0` disables replication for the index, `auto` enables it. Must match across all peer nodes. Default `0`.
`createBloomfilter`	Whether bloomfilter files are created; must be `true` for remote-storage-enabled indexes. Default `true`.

Bucket rolling & retention

Backs the Splunk Taxonomy's Bucket Lifecycle Settings object (SOT-06.03.02) -- the settings that mechanically enforce an index's retention policy.

Setting	Description
`maxDataSize`	Hot-bucket size (MB) that triggers a roll to warm. `auto` (750MB) or `auto_high_volume` (10GB on 64-bit) is recommended over a hand-picked value. Default `auto`.
`maxHotBuckets` / `maxHotSpanSecs` / `maxHotIdleSecs`	Max concurrent hot buckets per index per ingestion pipeline (default `auto` = 3), the max timespan a hot/warm bucket can cover (default `7776000`s/90 days, floor `3600`s), and how long a hot bucket may sit idle before rolling to warm (default `0` = never).
`maxWarmDBCount`	Max warm buckets before the oldest rolls to cold; ignored on remote-storage-enabled indexes. Default `300`.
`frozenTimePeriodInSecs`	Age at which indexed data rolls to frozen -- deleted unless a `coldToFrozenScript`/`coldToFrozenDir` is set. Default `188697600` (6 years).
`maxTotalDataSizeMB` / `maxGlobalDataSizeMB` / `maxGlobalRawDataSizeMB`	Size caps that trigger freezing the oldest data: total index size (hot+warm+cold, ignored on remote-storage-enabled indexes, default `500000`MB), total warm-bucket size in a SmartStore index (default `0`=unlimited), and cumulative raw data across an entire indexer cluster for a remote-storage index (default `0`=unlimited). Caution: a size limit can be reached before `frozenTimePeriodInSecs`, and since the default freeze policy is deletion, this can cause unintended data loss.
`homePath.maxDataSizeMB` / `coldPath.maxDataSizeMB`	Per-path size caps that move buckets to cold, or freeze them, respectively, once exceeded. Ignored on remote-storage-enabled indexes. Both default `0` (unconstrained).
`quarantinePastSecs` / `quarantineFutureSecs`	How anomalously old/new an event's timestamp must be before it's quarantined instead of polluting the main hot buckets. Defaults `77760000`s/900 days and `2592000`s/30 days.

Freezing & archiving

Backs the Splunk Taxonomy's Archive Location object (SOT-06.03.03).

Setting	Description
`coldToFrozenDir`	Destination path for frozen buckets; Splunk handles the archival automatically. Takes precedence over `coldToFrozenScript` if both are set. Cannot reference a volume. Restart required.
`coldToFrozenScript`	An alternative to `coldToFrozenDir`: a script (path to interpreter + script) invoked with the bucket directory to archive, responsible for its own success/failure signaling (exit 0 = Splunk deletes the bucket; non-zero = Splunk retries later). Must live under `$SPLUNK_HOME/bin`. The shipped `coldToFrozenExample.py` is explicitly NOT for production use.
`warmToColdScript`	Legacy (pre-4.0) script for warm-to-cold migration; native filesystem migration has superseded it. Ignored on remote-storage-enabled indexes.

Absent either archiving setting, frozen data is deleted permanently -- frozenTimePeriodInSecs without an archive destination is effectively a hard retention limit.

Volumes

Backs the Splunk Taxonomy's Volume object (SOT-06.04.01): a named storage-path allocation multiple indexes can share and be jointly capped by.

Setting	Description
`[volume:<name>]` `path`	Required. Local filesystem path (when `storageType=local`) or a URI-like remote location (when `storageType=remote`, e.g. `s3://bucket/path`) that indexes referencing `volume:<name>` draw storage from.
`storageType`	`local` (default) or `remote`. Only a remote volume can be referenced by an index's `remotePath` setting.
`maxVolumeDataSizeMB`	Caps the total size of all indexes on this volume; when exceeded, the oldest buckets across every index on the volume are trimmed (potentially straight from hot to cold). Ignored for remote volumes or local volumes hosting any remote-storage-enabled index.
`rotatePeriodInSecs`	Per-volume override of the global trim-check interval. Ignored for remote volumes.

Reference a volume from an index setting as volume:<name>/<subpath> (e.g. coldPath = volume:cold1/idx1); omitting the subpath appends the index name automatically.

Remote storage & SmartStore

Backs the Splunk Taxonomy's SmartStore Remote Storage object (SOT-06.04.02): S3-compatible object storage backing an index's searchable buckets, with only a local cache manager footprint kept on indexer disk.

Setting	Description
`hotlist_recency_secs` / `hotlist_bloom_filter_recency_hours`	Cache-manager eviction-eligibility ages for bucket data and bloomfilter/associated files respectively; default to the global `[cachemanager]` setting in `server.conf`.
`enableOnlineBucketRepair`	Asynchronous "online fsck" bucket repair running concurrently with splunkd instead of blocking startup; required `true` for remote-storage-enabled indexes. Default `true`.

Per-provider connection/auth/encryption settings are namespaced remote.<scheme>.* under the volume stanza -- remote.s3.* for AWS S3-API storage (access/secret keys or IAM role, encryption scheme sse-s3/sse-kms/sse-c/cse, multipart transfer tuning, TLS settings), remote.gs.* for Google Cloud Storage (service-account credential file, gcp-sse-c/gcp-sse-kms/gcp-sse-gcp encryption), and remote.azure.* for Microsoft Azure Blob Storage (access key/secret, client-token or workload-identity auth, azure-sse-kv/azure-sse-ms/azure-sse-c encryption) -- each family mirrors the others' shape (credentials, endpoint, encryption scheme, retry policy, TLS) but with provider-specific setting names.

Metric indexes

Backs the Splunk Taxonomy's Metrics Index object (SOT-06.01.02): an index type optimized for high-volume numeric time-series data rather than full-text events.

Setting	Description
`datatype`	`event` (default) or `metric` -- switches the index to metrics storage, queried only via `mstats`/`mcatalog`, not `stats`/`tstats`.
`metric.maxHotBuckets` / `metric.splitByIndexKeys`	Metric-index equivalents of `maxHotBuckets` (default `auto`, effectively 6) and index-key-based bucket splitting (valid keys include `metric_name` in addition to host/sourcetype/source).
`metric.tsidxTargetSizeMB` / `metric.timestampResolution`	Target msidx file size (default `1500`MB, max `4096`) and timestamp precision -- `s` (default) or `ms`, the latter at a search-performance cost.
`metric.enableFloatingPointCompression`	Compresses floating-point metric values; disable only if experiencing high ingest-time CPU usage, at the cost of the disk-space savings compression gives. Default `true`.
`metric.stubOutRawdataJournal`	Deletes the rawdata file's contents once a hot bucket rolls to warm (searches over metrics never use rawdata) -- reduces storage and can improve effective tsidx size headroom, at the cost of losing that file for bucket-repair operations. Has no effect on indexes with replication enabled. Default `true`.

tsidx & performance tuning

A cluster of advanced, mostly support-tunable settings governing how tsidx/journal files are written and optimized: journalCompression (gzip/lz4/zstd, default zstd) and zstdCompressionStrategy for the rawdata journal; rawChunkSizeBytes for target raw-slice size; tsidxTargetSizeMB (default 1500MB, max 4096) for tuning tstats query performance; tsidxDedupPostingsListMaxTermsLimit for compression-vs-memory tradeoffs at tsidxWritingLevel 4+; and enableTsidxReduction/tsidxReductionCheckPeriodInSec/timePeriodInSecBeforeTsidxReduction for shrinking tsidx files on aged warm/cold/thawed buckets of event (not metric) indexes -- explicitly not for use on remote-storage-enabled event indexes.

External resource providers & virtual indexes

A large, largely legacy Hadoop/Hunk-specific settings family for querying data that lives outside Splunk's own index storage. [provider-family:<name>] holds settings common to multiple providers; [provider:<name>] defines a specific ERP connection (vix.family, vix.command/vix.command.arg.<N> to launch the external search process, vix.env.<var> environment variables, and for the Hadoop family specifically, Java/Kerberos properties, HDFS Name Node/Job Tracker addresses, and Splunk-on-Hadoop setup/replication/heartbeat tuning); a [<virtual-index>] stanza then references a provider via vix.provider and defines vix.input.<id>.* settings describing which Hadoop-filesystem paths to search, how to extract earliest/latest time from the path or file mtime, and (for archiving) where and when to move aged Splunk buckets into the virtual index. Format-specific record-reader/splitter settings exist for sequence files, Avro, Parquet, and Hive tables. This entire family is a specialized, largely legacy capability -- consult Splunk Support/the Hunk documentation before configuring rather than hand-deriving settings from this file alone.

Federated dataset settings

federated.provider and federated.dataset, set within an index stanza, identify a Federated Search Provider (defined in federated.conf) and a specific remote dataset (an index, metric index, data model, saved search, or AWS Glue Data Catalog table, depending on provider type) that stanza maps to -- the mechanism underlying Federated Index (SOT-06.05.02) and related to Federated Search for Amazon S3 datasets accessed via sdselect.

All settings

Every stanza and setting in indexes.conf.spec from Splunk Enterprise 10.4.2: 336 settings in 12 sections. Descriptions use the spec's own wording -- the first line shows here and More opens the rest. The Default column is filled only where the spec gives a Default: line.

Global settings

Use the [default] stanza to define any global settings.
You can also define global settings outside of any stanza, at the top of the file.
Each conf file should have at most one default stanza. If there are multiple default stanzas, settings are combined. In the case of multiple definitions of the same setting, the last definition in the file wins.
If a setting is defined at both the global level and in a specific stanza, the value in the specific stanza takes precedence.

Setting	Description	Default
`sync`	`<nonnegative integer>`The index processor syncs events every 'sync' number of events. More Set to 0 to disable. Highest legal value is 32767.	0
`defaultDatabase`	`<index name>`If an index is not specified during search, Splunk software searches the default index. More The specified index displays as the default in Splunk Manager settings.	main
`bucketMerging`	`<boolean>`This setting is supported on indexer clusters when 'storageType' is "remote" or "local". Standalone indexers support "local" only. More The bucket merge task will evaluate and localize remote buckets before merging. Set to true to enable bucket merging service on all indexes You can override this value on a per-index basis.	false
`bucketMerge.minMergeSizeMB`	`<unsigned integer>`This setting is supported on indexer clusters when 'storageType' is "remote" or "local". Standalone indexers support "local" only. More Minimum cumulative bucket sizes to merge. You can override this value on a per-index basis.	750
`bucketMerge.maxMergeSizeMB`	`<unsigned integer>`This setting is supported on indexer clusters when 'storageType' is "remote" or "local". Standalone indexers support "local" only. More Maximum cumulative bucket sizes to merge. You can override this value on a per-index basis.	1000
`bucketMerge.maxMergeTimeSpanSecs`	`<unsigned integer>`This setting is supported on indexer clusters when 'storageType' is "remote" or "local". Standalone indexers support "local" only. More Maximum allowed time span, in seconds, between buckets about to be merged. You can override this value on a per-index basis.	7776000 (90 days)
`bucketMerge.minMergeCount`	`<unsigned integer>`This setting is supported on indexer clusters when 'storageType' is "remote" or "local". Standalone indexers support "local" only. More Minimum number of buckets to merge. You can override this value on a per-index basis.	2
`bucketMerge.maxMergeCount`	`<unsigned integer>`This setting is supported on indexer clusters when 'storageType' is "remote" or "local". Standalone indexers support "local" only. More Maximum number of buckets to merge. You can override this value on a per-index basis.	24
`allowBulkDataMove`	`<boolean>`Whether or not Splunk software allows bulk data move operations on non-SmartStore clustered indexes. More A value of "true" means Splunk software allows bulk data move operations. A value of "false" means Splunk software does not allow bulk data move operations.	false
`queryLanguageDefinition`	`<path to file>`REMOVED. This setting is no longer used.
`lastChanceIndex`	`<index name>`An index that receives events that are otherwise not associated with a valid index. More If you do not specify a valid index with this setting, such events are dropped entirely. Routes the following kinds of events to the specified index: events with a non-existent index specified at an input layer, like an invalid "index" setting in inputs.conf events with a non-existent index computed at index-time, like an invalid _MetaData:Index value set from a "FORMAT" setting in transforms.conf You must set 'lastChanceIndex' to an existing, enabled index. Splunk software cannot start otherwise. If set to "default", then the default index specified by the 'defaultDatabase' setting is used as a last chance index.	empty string
`malformedEventIndex`	`<index name>`Currently not supported. This setting is related to a feature that is still under development. More An index to receive malformed events. If you do not specify a valid index with this setting, or Splunk software cannot use the index specified in the 'defaultDatabase' setting, such events are dropped entirely. Routes the following kinds of events to the specified index: events destined for read-only indexes log events destined for datatype=metric indexes log events with invalid raw data values, like all-whitespace raw metric events destined for datatype=event indexes metric events with invalid metric values, like non-numeric values metric events lacking required attributes, like metric name Malformed events can be modified in order to make them suitable for indexing, as well as to aid in debugging. A high volume of malformed events can affect search performance against the specified index; for example, malformed metric events can lead to an excessive number of Strings.data entries <index name> must refer to an existing, enabled index. Splunk software does not start if this is not the case. If set to "default", the indexer places malformed events in the index specified by the 'defaultDatabase' setting	empty string
`memPoolMB`	`<positive integer>\|auto`Determines how much memory is given to the indexer memory pool. This restricts the number of outstanding events in the indexer at any given time. More Must be greater than 0; maximum value is 1048576 (which corresponds to 1 TB) Setting this too high can cause splunkd memory usage to increase significantly. Setting this too low can degrade splunkd indexing performance. Setting this to "auto" or an invalid value causes splunkd to autotune the value as follows: System Memory Available less than ... \| 'memPoolMB' 1 GB \| 64 MB 2 GB \| 128 MB 8 GB \| 128 MB 16 GB \| 256 MB 32 GB \| 1 GB 64 GB \| 2 GB 64 GB or higher \| 4 GB Only set this value if you are an expert user or have been advised to by Splunk Support. CAUTION: CARELESSNESS IN SETTING THIS CAN LEAD TO LOSS OF JOB.	auto
`indexThreads`	`<nonnegative integer>\|auto`Determines the number of threads to use for indexing. More Must be at least 1 and no more than 16. This value should not be set higher than the number of processor cores in the machine. If splunkd is also doing parsing and aggregation, the number should be set lower than the total number of processors minus two. Setting this to "auto" or an invalid value will cause Splunk to autotune this setting. Only set this value if you are an expert user or have been advised to by Splunk Support. CAUTION: CARELESSNESS IN SETTING THIS CAN LEAD TO LOSS OF JOB.	auto
`rtRouterThreads`	`0\|1`Set to "1" if you expect to use non-indexed real time searches regularly. Index throughput drops rapidly if there are a handful of these running concurrently on the system. More If you are not sure what "indexed vs non-indexed" real time searches are, see README of indexed_realtime* settings in limits.conf NOTE: This is not a boolean value. Acceptable values are "0" and "1" ONLY. At the present time, you can only create a single real-time thread per pipeline set.
`rtRouterQueueSize`	`<positive integer>`This setting is only valid if 'rtRouterThreads' != 0 More This queue sits between the indexer pipeline set thread (producer) and the 'rtRouterThread' Changing the size of this queue can impact real-time search performance.	10000
`selfStorageThreads`	`<positive integer>`Specifies the number of threads used to transfer data to customer-owned remote storage. More The threads are created on demand when any index is configured with self storage options.	2
`assureUTF8`	`<boolean>`Verifies that all data retrieved from the index is proper by validating all the byte strings. More This does not ensure all data will be emitted, but can be a workaround if an index is corrupted in such a way that the text inside it is no longer valid utf8. Will degrade indexing performance when enabled (set to true). Can only be set globally, by specifying in the [default] stanza.	false
`enableRealtimeSearch`	`<boolean>`Enables real-time searches.	true
`perfTuneMetaDataAPIs`	`<boolean>`Whether or not the Splunk daemon auto-tunes metadata access to improve indexing and index replication performance. More A value of "true" means that the Splunk daemon auto-tunes metadata access to improve indexing and replication performance. A value of "false" means that the Splunk daemon does not auto-tune metadata access.	false
`perfTuneMetaDataReads`	`<boolean>`Whether or not the Splunk daemon auto-tunes metadata read APIs. More A value of "true" means that the Splunk daemon auto-tunes metadata read APIs. A value of "false" means that the Splunk daemon does not auto-tune metadata read APIs. When 'perfTuneMetaDataAPIs' has a value of "false", this setting has no effect. This is an advanced setting. Do not change it unless instructed to by Splunk Support.	true
`perfTuneMetaDataWrites`	`<boolean>`Whether or not the Splunk daemon auto-tunes metadata write APIs. More A value of "true" means that the Splunk daemon auto-tunes metadata write APIs. A value of "false" means that the Splunk daemon does not auto-tune metadata write APIs. When 'perfTuneMetaDataAPIs' has a value of "false", this setting has no effect. This is an advanced setting. Do not change it unless instructed to by Splunk Support.	true
`quadReloadHashTable`	`<boolean>`Whether or not the Splunk daemon auto-tunes metadata internal table reloads. More A value of "true" means that the Splunk daemon auto-tunes metadata internal table reloads. A value of "false" means that the Splunk daemon does not auto-tune metadata internal table reloads. When 'perfTuneMetaDataAPIs' has a value of "false", this setting has no effect. This is an advanced setting. Do not change it unless instructed to by Splunk Support.	false
`hashTableSize`	`<integer>`The size, in bytes, of the metadata internal table. More This is an advanced setting. Do not change it unless instructed to by Splunk Support.	1024
`suppressBannerList`	`<comma-separated list of strings>`suppresses index missing warning banner messages for specified indexes	empty string
`maxRunningProcessGroups`	`<positive integer>\|auto`The number of child processes that splunkd can run at a given time. More Splunkd runs helper child processes like "splunk-optimize", "recover-metadata", and so on. This maximum applies to all of splunkd, not per index. If you have N indexes, there will be at most 'maxRunningProcessGroups' child processes, not N * 'maxRunningProcessGroups' processes. The value for this setting must be higher than the value for the 'maxRunningProcessGroupsLowPriority' setting. This is an advanced setting; do NOT set unless instructed by Splunk Support. A value of "auto" means splunkd chooses the number of processes automatically based on system characteristics. Highest legal value is 4294967295.	auto
`maxRunningProcessGroupsLowPriority`	`<positive integer>`Of the 'maxRunningProcessGroups' helper child processes, at most 'maxRunningProcessGroupsLowPriority' may be low-priority (for example, "fsck") ones. More This maximum applies to all of splunkd, not per index. If you have N indexes, there will be at most 'maxRunningProcessGroupsLowPriority' low-priority child processes, not N * 'maxRunningProcessGroupsLowPriority' processes. There must always be fewer 'maxRunningProcessGroupsLowPriority' child processes than there are 'maxRunningProcessGroups' child processes. This is an advanced setting; do NOT set unless instructed by Splunk Support. Highest legal value is 4294967295.	1
`bucketRebuildMemoryHint`	`<positive integer>[KB\|MB\|GB]\|auto`A suggestion for the bucket rebuild process for the size, in bytes, of the tsidx file it will try to build. More Larger files use more memory in a rebuild, but rebuilds fail if there is not enough memory. Smaller files make the rebuild take longer during the final optimize step. NOTE: This value is not a hard limit on either rebuild memory usage or tsidx size. This is an advanced setting, do NOT set this unless instructed by Splunk Support. If set to "auto", the bucket rebuild process tunes the setting based on the amount of physical RAM on the machine: less than 2GB RAM = 67108864 (64MB) tsidx 2GB to 8GB RAM = 134217728 (128MB) tsidx more than 8GB RAM = 268435456 (256MB) tsidx If not set to "auto", then you must set this setting between 16MB and 1GB. A value can be specified using a size suffix: "16777216" or "16MB" are equivalent. Inappropriate use of this setting causes splunkd to not start if rebuild is required. Highest legal value (in bytes) is 4294967295.	auto
`inPlaceUpdates`	`<boolean>`Whether or not splunkd writes metadata updates to .data files in place. More Intended for advanced debugging of metadata issues. If set to "true", metadata updates are written to the .data files directly. If set to "false", metadata updates are written to a temporary file and then moved into place. Configuring this setting to "false" (to use a temporary file) affects indexing performance, particularly with large numbers of hosts, sources, or sourcetypes (~1 million, across all indexes.) This is an advanced setting; do NOT set unless instructed by Splunk Support	true
`serviceInactiveIndexesPeriod`	`<positive integer>`How frequently, in seconds, inactive indexes are serviced. More An inactive index is an index that has not been written to for a period greater than the value of 'serviceMetaPeriod'. The inactive state is not affected by whether the index is being read from. The highest legal value is 4294967295.	60
`serviceOnlyAsNeeded`	`<boolean>`DEPRECATED; use 'serviceInactiveIndexesPeriod' instead. More Causes index service (housekeeping tasks) overhead to be incurred only after index activity. Indexer module problems might be easier to diagnose when this optimization is disabled (set to false).	true
`serviceSubtaskTimingPeriod`	`<positive integer>`Subtasks of indexer service task will be timed on every Nth execution, where N = value of this setting, in seconds. More Smaller values give greater accuracy; larger values lessen timer overhead. Timer measurements are found in metrics.log, marked "group=subtask_seconds, task=indexer_service" Highest legal value is 4294967295 Configure a value for this setting that divides evenly into the value for the 'rotatePeriodInSecs' setting where possible.	30
`processTrackerServiceInterval`	`<nonnegative integer>`How often, in seconds, the indexer checks the status of the child OS processes it has launched to see if it can launch new processes for queued requests. More If set to 0, the indexer checks child process status every second. Highest legal value is 4294967295.	1
`maxBucketSizeCacheEntries`	`<nonnegative integer>`This value is no longer needed. Its value is ignored.
`tsidxStatsHomePath`	`<string>`An absolute path that specifies where the indexer creates namespace data with the 'tscollect' command. More If the directory does not exist, the indexer attempts to create it. Optional. NOTE: The "$SPLUNK_DB" directory must be writable.	$SPLUNK_DB/tsidxstats
`tsidxWritingLevel`	`[1\|2\|3\|4]`Enables various performance and space-saving improvements for tsidx files. More Tsidx files written with a higher tsidxWritingLevel setting have limited backward compatibility when searched with lower versions of Splunk Enterprise. Setting tsidxWritingLevel globally is recommended. It can also be set per-index. For deployments that have multi-site index clustering, change the setting AFTER all your indexers in the cluster have been upgraded to the latest release.	3
`hotBucketTimeRefreshInterval`	`<positive integer>`How often each index refreshes the available hot bucket times used by the 'indexes' REST endpoint. More A refresh occurs every N times service is performed for each index. For busy indexes, this is a multiple of seconds. For idle indexes, this is a multiple of the second-long-periods in which data is received. This setting is only intended to relax the frequency of these refreshes in the unexpected case that it adversely affects performance in unusual production scenarios. This time is tracked on a per-index basis, and thus can be adjusted on a per-index basis if needed. If you want the index information to be refreshed with every service (and accept minor performance overhead), set to 1.	10 (services)
`fileSystemExecutorWorkers`	`<positive integer>`Determines the number of threads to use for file system io operations. More This maximum applies to all of splunkd, not per index. If you have N indexes, there will be at most 'fileSystemExecutorWorkers' workers, not N * 'fileSystemExecutorWorkers' workers. This is an advanced setting; do NOT set unless instructed by Splunk Support. Highest legal value is 4294967295.	5
`hotBucketStreaming.extraBucketBuildingCmdlineArgs`	`<string>`Currently not supported. This setting is related to a feature that is still under development.	empty

Per index options

These options can be set under an [<index>] entry.

Setting	Description	Default
`disabled`	`<boolean>`Toggles your index entry off and on. More Set to "true" to disable an index. CAUTION: Do not set this setting to "true" on remote storage enabled indexes.	false
`deleted`	`true`If present, means that this index has been marked for deletion: if splunkd is running, deletion is in progress; if splunkd is stopped, deletion re-commences on startup. More Do NOT manually set, clear, or modify the value of this setting. CAUTION: Seriously: LEAVE THIS SETTING ALONE.	No default
`deleteId`	`<nonnegative integer>`If present, means that this index has been marked for deletion: if splunkd is running, deletion is in progress; if splunkd is stopped, deletion re-commences on startup. More Do NOT manually set, clear, or modify the value of this setting. CAUTION: Seriously: LEAVE THIS SETTING ALONE.	No default
`homePath`	`<string>`An absolute path that contains the hot and warm buckets for the index. More Best practice is to specify the path with the following syntax: homePath = $SPLUNK_DB/$_index_name/db At runtime, splunkd expands "$_index_name" to the name of the index. For example, if the index name is "newindex", homePath becomes "$SPLUNK_DB/newindex/db". Splunkd keeps a file handle open for warmdbs at all times. Can contain a volume reference (see volume section below) in place of $SPLUNK_DB. CAUTION: The parent path "$SPLUNK_DB/$_index_name/" must be writable. Required. Splunkd does not start if an index lacks a valid 'homePath'. You must restart splunkd after changing this setting for the changes to take effect. Avoid the use of other environment variables in index paths, aside from the possible exception of SPLUNK_DB. As an exception, SPLUNK_DB is explicitly managed by the software, so most possible downsides here do not exist. Environment variables can be different from launch to launch of the software, causing severe problems with management of indexed data, including: Data in the prior location is not searchable. The indexer might not be able to write to the new location, causing outages or data loss. Writing to a new, unexpected location could lead to disk space exhaustion causing additional operational problems. Recovery from such a scenario requires manual intervention and bucket renaming, especially difficult in an index cluster environment. In all circumstances, Splunk Diag, the diagnostic tool that Splunk Support uses, has no way to determine the correct values for the environment variables, and cannot reliably operate. You might need to manually acquire information about your index buckets in troubleshooting scenarios. Volumes provide a more appropriate way to control the storage location for indexes.	No default
`coldPath`	`<string>`An absolute path that contains the colddbs for the index. More Best practice is to specify the path with the following syntax: coldPath = $SPLUNK_DB/$_index_name/colddb At runtime, splunkd expands "$_index_name" to the name of the index. For example, if the index name is "newindex", 'coldPath' becomes "$SPLUNK_DB/newindex/colddb". Cold databases are opened as needed when searching. Can contain a volume reference (see volume section below) in place of $SPLUNK_DB. Path must be writable. Required. Splunkd does not start if an index lacks a valid 'coldPath'. You must restart splunkd after changing this setting for the changes to take effect. Reloading the index configuration does not suffice. Avoid using environment variables in index paths, aside from the possible exception of $SPLUNK_DB. See 'homePath' for additional information as to why. Remote-storage-enabled indexes do not cycle buckets from homePath to coldPath. However, if buckets already reside in 'coldPath' for a non-remote-storage-enabled index, and that index is later enabled for remote storage, those buckets will be searchable and will have their life cycle managed.
`thawedPath`	`<string>`An absolute path that contains the thawed (resurrected) databases for the index. More CANNOT contain a volume reference. Path must be writable. Required. Splunkd does not start if an index lacks a valid thawedPath. You must restart splunkd after changing this setting for the changes to take effect. Reloading the index configuration does not suffice. Avoid the use of environment variables in index paths, aside from the exception of SPLUNK_DB. See 'homePath' for additional information as to why.
`bloomHomePath`	`<string>`The location where the bloomfilter files for the index are stored. More If specified, 'bloomHomePath' must be defined in terms of a volume definition (see volume section below). If 'bloomHomePath' is not specified, the indexer stores bloomfilter files for the index inline, inside index bucket directories. Path must be writable. You must restart splunkd after changing this setting for the changes to take effect. Reloading the index configuration does not suffice. Avoid the use of environment variables in index paths, aside from the exception of SPLUNK_DB. See 'homePath' for additional information as to why. CAUTION: Do not set this setting on indexes that have been configured to use remote storage with the "remotePath" setting.
`createBloomfilter`	`<boolean>`Whether or not to create bloomfilter files for the index. More If set to "true", the indexer creates bloomfilter files. If set to "false", the indexer does not create bloomfilter files. You must set to "true" for remote storage enabled indexes. CAUTION: Do not set this setting to "false" on indexes that have been configured to use remote storage with the "remotePath" setting.	true
`summaryHomePath`	`<string>`An absolute path where transparent summarization results for data in this index should be stored. More This value must be different for each index and can be on any disk drive. Best practice is to specify the path with the following syntax: summaryHomePath = $SPLUNK_DB/$_index_name/summary At runtime, splunkd expands "$_index_name" to the name of the index. For example, if the index name is "newindex", summaryHomePath becomes "$SPLUNK_DB/newindex/summary". Can contain a volume reference (see volume section below) in place of $SPLUNK_DB. Volume reference must be used if you want to retain data based on data size. Path must be writable. If not specified, splunkd creates a directory 'summary' in the same location as 'homePath'. For example, if 'homePath' is "/opt/splunk/var/lib/splunk/index1/db", then 'summaryHomePath' must be "/opt/splunk/var/lib/splunk/index1/summary". The parent path must be writable. You must not set this setting for remote storage enabled indexes. You must restart splunkd after changing this setting for the changes to take effect. Reloading the index configuration does not suffice. Avoid the use of environment variables in index paths, aside from the exception of SPLUNK_DB. See 'homePath' for additional information as to why.	No default
`tstatsHomePath`	`<string>`Location where data model acceleration TSIDX data for this index should be stored. More Required. MUST be defined in terms of a volume definition (see volume section below) Path must be writable. You must not set this setting for remote storage enabled indexes. You must restart splunkd after changing this setting for the changes to take effect. Reloading the index configuration does not suffice.	volume:_splunk_summaries/$_index_name/datamodel_summary, where "$_index_name" is runtime-expanded to the name of the index
`remotePath`	`<root path for remote volume, prefixed by a URI-like scheme>`Optional. More Presence of this setting means that this index uses remote storage, instead of the local file system, as the main repository for bucket storage. The index processor works with a cache manager to fetch buckets locally, as necessary, for searching and to evict them from local storage as space fills up and they are no longer needed for searching. This setting must be defined in terms of a storageType=remote volume definition. See the volume section below. The path portion that follows the volume reference is relative to the path specified for the volume. For example, if the path for a volume "v1" is "s3://bucket/path" and 'remotePath' is "volume:v1/idx1", then the fully qualified path is "s3://bucket/path/idx1". The rules for resolving the relative path with the absolute path specified in the volume can vary depending on the underlying storage type. If 'remotePath' is specified, the 'coldPath' and 'thawedPath' settings are ignored. However, you must still specify them.
`mdlIndex`	`<boolean>`A value of "true" means the Machine Data Lake ecosystem uses this index, and Splunk platform uses the 'mdlRemotePath' setting to configure the index's remote storage path. More A value of "false" means this index is only a regular index, the Machine Data Lake ecosystem won't use it, and Splunk platform instead uses the 'remotePath' setting to configure the index's remote storage path. NOTE: Do not change this setting unless instructed to do so by Splunk Support.	false
`mdlRemotePath`	`<root path for remote volume, prefixed by a URI-like scheme>`Overrides the 'remotePath' setting when the 'mdlIndex' setting has a value of "true". More The path for the remote volume is formatted the same as for the 'remotePath' setting, please refer to that setting for further information on formatting. NOTE: Do not change this setting unless instructed to do so by Splunk Support. Optional.
`maxBloomBackfillBucketAge`	`<nonnegative integer>[smhd]\|infinite`If a (warm or cold) bucket with no bloomfilter is older than this, splunkd does not create a bloomfilter for that bucket. More When set to 0, splunkd never backfills bloomfilters. When set to "infinite", splunkd always backfills bloomfilters. NOTE: If 'createBloomfilter' is set to "false", bloomfilters are never backfilled regardless of the value of this setting. The highest legal value in computed seconds is 2 billion, or 2000000000, which is approximately 68 years.	30d
`hotlist_recency_secs`	`<unsigned integer>`When a bucket is older than this value, it becomes eligible for eviction. Buckets younger than this value are evicted only if there are no older buckets eligible for eviction.	The global setting in the server.conf file [cachemanager] stanza
`hotlist_bloom_filter_recency_hours`	`<unsigned integer>`When a bucket's non-journal and non-tsidx files (such as bloomfilter files) are older than this value, those files become eligible for eviction. Bloomfilter and associated files younger than this value are evicted only if there are no older files eligible for eviction.	The global setting in the server.conf file [cachemanager] stanza
`enableOnlineBucketRepair`	`<boolean>`Controls asynchronous "online fsck" bucket repair, which runs concurrently with splunkd. More When enabled, you do not have to wait until buckets are repaired, to start splunkd. When enabled, you might observe a slight degradation in performance. You must set to "true" for remote storage enabled indexes.	true
`enableDataIntegrityControl`	`<boolean>`Whether or not splunkd computes hashes on rawdata slices and stores the hashes for future data integrity checks. More If set to "true", hashes are computed on the rawdata slices. If set to "false", no hashes are computed on the rawdata slices.	false
`maxWarmDBCount`	`<nonnegative integer>`The maximum number of warm buckets. More Warm buckets are located in the 'homePath' for the index. If set to zero, splunkd does not retain any warm buckets It rolls the buckets to cold as soon as it is able. Splunkd ignores this setting on remote storage enabled indexes. Highest legal value is 4294967295.	300
`maxTotalDataSizeMB`	`<nonnegative integer>`The maximum size of an index, in megabytes. More If an index grows larger than the maximum size, splunkd freezes the oldest data in the index. This setting applies only to hot, warm, and cold buckets. It does not apply to thawed buckets. CAUTION: The 'maxTotalDataSizeMB' size limit can be reached before the time limit defined in 'frozenTimePeriodInSecs' due to the way bucket time spans are calculated. When the 'maxTotalDataSizeMB' limit is reached, the buckets are rolled to frozen. As the default policy for frozen data is deletion, unintended data loss could occur. Splunkd ignores this setting on remote storage enabled indexes. Highest legal value is 4294967295	500000
`maxGlobalRawDataSizeMB`	`<nonnegative integer>`The maximum amount of cumulative raw data (in MB) allowed in a remote storage-enabled index. More This setting is available for both standalone indexers and indexer clusters. In the case of indexer clusters, the raw data size is calculated as the total amount of raw data ingested for the index, across all peer nodes. When the amount of uncompressed raw data in an index exceeds the value of this setting, the bucket containing the oldest data is frozen. For example, assume that the setting is set to 500 and the indexer cluster has already ingested 400MB of raw data into the index, across all peer nodes. If the cluster ingests an additional amount of raw data greater than 100MB in size, the cluster freezes the oldest buckets, until the size of raw data reduces to less than or equal to 500MB. This value applies to warm and cold buckets. It does not apply to hot or thawed buckets. The maximum allowable value is 4294967295.	0 (no limit to the amount of raw data in an index)
`maxGlobalDataSizeMB`	`<nonnegative integer>`The maximum size, in megabytes, for all warm buckets in a SmartStore index. If the index was migrated from non-SmartStore to SmartStore this size also includes the size of all migrated cold buckets. More This setting includes the sum of the size of all buckets that reside on remote storage, along with any buckets that have recently rolled from hot to warm on a peer node and are awaiting upload to remote storage. If the total size of the warm buckets in an index exceeds 'maxGlobalDataSizeMB', the oldest bucket in the index is frozen. For example, assume that 'maxGlobalDataSizeMB' is set to 5000 for an index, and the index's warm buckets occupy 4800 MB. If a 750 MB hot bucket then rolls to warm, the index size now exceeds 'maxGlobalDataSizeMB', which triggers bucket freezing. The cluster freezes the oldest buckets on the index, until the total warm bucket size falls below 'maxGlobalDataSizeMB'. The size calculation for this setting applies on a per-index basis. The calculation applies across all peers in the cluster. The calculation includes only one copy of each bucket. If a duplicate copy of a bucket exists on a peer node, the size calculation does not include it. For example, if the bucket exists on both remote storage and on a peer node's local cache, the calculation ignores the copy on local cache. The calculation includes only the size of the buckets themselves. It does not include the size of any associated files, such as report acceleration or data model acceleration summaries. The highest legal value is 4294967295 (4.2 petabytes.)	0 (No limit to the space that the warm buckets on an index can occupy.)
`rotatePeriodInSecs`	`<positive integer>`Controls the service period (in seconds): how often splunkd performs certain housekeeping tasks. Among these tasks are: More Check if a new hot DB needs to be created. Check if there are any cold DBs that should be frozen. Check whether buckets need to be moved out of hot and cold DBs, due to respective size constraints (i.e., homePath.maxDataSizeMB and coldPath.maxDataSizeMB) This value becomes the default value of the 'rotatePeriodInSecs' setting for all volumes (see 'rotatePeriodInSecs' in the Volumes section) The highest legal value is 4294967295.	60
`frozenTimePeriodInSecs`	`<nonnegative integer>`The number of seconds after which indexed data rolls to frozen. More If you do not specify a 'coldToFrozenScript', data is deleted when rolled to frozen. NOTE: Every event in a bucket must be older than 'frozenTimePeriodInSecs' seconds before the bucket rolls to frozen. The highest legal value is 4294967295.	188697600 (6 years)
`warmToColdScript`	`<script path>`Specifies a script to run when moving data from warm to cold buckets. More This setting is supported for backwards compatibility with versions older than 4.0. Migrating data across filesystems is now handled natively by splunkd. If you specify a script here, the script becomes responsible for moving the event data, and Splunk-native data migration is not used. The script must accept two arguments: First: the warm directory (bucket) to be rolled to cold. Second: the destination in the cold path. If the script you specify is a Python script, it uses the default system-wide Python interpreter. You cannot override this configuration with the 'python.version' setting. Searches and other activities are paused while the script is running. Contact Splunk Support (http://www.splunk.com/page/submit_issue) if you need help configuring this setting. The script must be in $SPLUNK_HOME/bin or a subdirectory thereof. Splunkd ignores this setting for remote storage enabled indexes.	empty string
`coldToFrozenScript`	`<path to script interpreter> <path to script>`Specifies a script to run when data is to leave the splunk index system. More Essentially, this implements any archival tasks before the data is deleted out of its default location. Add "$DIR" (including quotes) to this setting on Windows (see below for details). Script Requirements: The script must accept only one argument: An absolute path to the bucket directory that is to be archived. The bundle push from a Cluster Manager fails if you use more than one argument. In the case of metrics indexes, the script must also accept the flag "--search-files-required", to prevent the script from archiving empty rawdata files. For more details, see the entry for the "metric.stubOutRawdataJournal" setting. Your script should work reliably. If your script returns success (0), Splunk completes deleting the directory from the managed index location. If your script return failure (non-zero), Splunk leaves the bucket in the index, and tries calling your script again several minutes later. If your script continues to return failure, this will eventually cause the index to grow to maximum configured size, or fill the disk. Your script should complete in a reasonable amount of time. If the script stalls indefinitely, it will occupy slots. This script should not run for long as it would occupy resources which will affect indexing. If the string $DIR is present in this setting, it will be expanded to the absolute path to the directory. If $DIR is not present, the directory will be added to the end of the invocation line of the script. This is important for Windows. For historical reasons, the entire string is broken up by shell-pattern expansion rules. Since Windows paths frequently include spaces, and the Windows shell breaks on space, the quotes are needed for the script to understand the directory. If your script can be run directly on your platform, you can specify just the script. Examples of this are: .bat and .cmd files on Windows scripts set executable on UNIX with a #! shebang line pointing to a valid interpreter. You can also specify an explicit path to an interpreter and the script. Example: /path/to/my/installation/of/python.exe path/to/my/script.py Splunk software ships with an example archiving script in that you SHOULD NOT USE $SPLUNK_HOME/bin called coldToFrozenExample.py DO NOT USE the example for production use, because: 1 - It will be overwritten on upgrade. 2 - You should be implementing whatever requirements you need in a script of your creation. If you have no such requirements, use 'coldToFrozenDir' Example configuration: If you create a script in bin/ called our_archival_script.py, you could use: UNIX: coldToFrozenScript = "$SPLUNK_HOME/bin/python" \ "$SPLUNK_HOME/bin/our_archival_script.py" Windows: coldToFrozenScript = "$SPLUNK_HOME/bin/python" \ "$SPLUNK_HOME/bin/our_archival_script.py" "$DIR" The example script handles data created by different versions of Splunk differently. Specifically, data from before version 4.2 and after version 4.2 are handled differently. See "Freezing and Thawing" below: The script must be in $SPLUNK_HOME/bin or a subdirectory thereof.	No default
`python.version`	`{default\|python\|python2\|python3\|python3.7\|python3.9\|latest}`DEPRECATED. Use 'python.required' instead to specify which Python versions the script supports. More For Python scripts only, selects which Python version to use. This setting is valid for 'coldToFrozenScript' only when the value starts with the canonical path to the Python interpreter, in other words, "$SPLUNK_HOME/bin/python". If you use any other path, the Splunk platform ignores this setting. Set to either "default" or "python" to use the system-wide default Python version. Set to "python3" or "python3.7" to use the Python 3.7 version. Set to "python3.9" to use the Python 3.9 version. In the context of configuring apps, the "latest" value is not currently supported. It is related to a feature that is still under development. Optional.	Not set; uses the system-wide Python version.
`python.required`	`<comma-separated list>`For Python scripts only, the versions of Python that the script supports. More The Splunk platform uses this setting for 'coldToFrozenScript' only when the setting value starts with the canonical path to the Python interpreter, in other words, "$SPLUNK_HOME/bin/python". If you use any other path, the Splunk platform ignores this setting. This setting takes precedence over the 'python.version' setting if both have values. The Splunk platform selects the highest version of Python that is available from the list that you provide. The following values are supported: "3.9": The script supports Python version 3.9. "3.13": The script supports Python version 3.13. "latest": The script uses the latest Python interpreter available. Where possible, use a specific version string rather than "latest". NOTE: The "latest" value is an internal value that is related to a feature that is still under development. NOTE: Use this setting instead of the deprecated 'python.version' setting. This setting is optional.	Not set; uses 'python.version' if that setting has a value.
`coldToFrozenDir`	`<path to frozen archive>`An alternative to a 'coldToFrozen' script - this setting lets you specify a destination path for the frozen archive. More Splunk software automatically puts frozen buckets in this directory For information on how buckets created by different versions are handled, see "Freezing and Thawing" below. If both 'coldToFrozenDir' and 'coldToFrozenScript' are specified, 'coldToFrozenDir' takes precedence You must restart splunkd after changing this setting. Reloading the configuration does not suffice. May NOT contain a volume reference.
`compressRawdata`	`true\|false`This setting is ignored. The splunkd process always compresses raw data.
`maxConcurrentOptimizes`	`<nonnegative integer>`The number of concurrent optimize processes that can run against a hot bucket. More This number should be increased if: There are always many small tsidx files in the hot bucket. After rolling, there are many tsidx files in warm or cold buckets. You must restart splunkd after changing this setting. Reloading the configuration does not suffice. The highest legal value is 4294967295.	6
`maxDataSize`	`<positive integer>\|auto\|auto_high_volume`The maximum size, in megabytes, that a hot bucket can reach before splunkd triggers a roll to warm. More Specifying "auto" or "auto_high_volume" will cause Splunk to autotune this setting (recommended). You should use "auto_high_volume" for high-volume indexes (such as the main index); otherwise, use "auto". A "high volume index" would typically be considered one that gets over 10GB of data per day. "auto_high_volume" sets the size to 10GB on 64-bit, and 1GB on 32-bit systems. Although the maximum value you can set this is 1048576 MB, which corresponds to 1 TB, a reasonable number ranges anywhere from 100 to 50000. Before proceeding with any higher value, please seek approval of Splunk Support. If you specify an invalid number or string, maxDataSize will be auto tuned. NOTE: The maximum size of your warm buckets might slightly exceed 'maxDataSize', due to post-processing and timing issues with the rolling policy. For remote storage enabled indexes, consider setting this value to "auto" (750MB) or lower.	"auto" (sets the size to 750 megabytes)
`rawFileSizeBytes`	`<positive integer>`Deprecated in version 4.2 and later. Splunkd ignores this value. More Rawdata chunks are no longer stored in individual files. If you really need to optimize the new rawdata chunks (highly unlikely), configure the 'rawChunkSizeBytes' setting.
`rawChunkSizeBytes`	`<positive integer>`Target uncompressed size, in bytes, for individual raw slices in the rawdata journal of the index. More This is an advanced setting. Do not change it unless a Splunk Support professional asks you to. If you specify "0", 'rawChunkSizeBytes' is set to the default value. NOTE: 'rawChunkSizeBytes' only specifies a target chunk size. The actual chunk size may be slightly larger by an amount proportional to an individual event size. You must restart splunkd after changing this setting. Reloading the configuration does not suffice. The highest legal value is 18446744073709551615	131072 (128 kilobytes)
`minRawFileSyncSecs`	`<nonnegative decimal>\|disable`How frequently splunkd forces a filesystem sync while compressing journal slices. During this interval, uncompressed slices are left on disk even after they are compressed. Splunkd then forces a filesystem sync of the compressed journal and remove the accumulated uncompressed files. More If you specify "0", splunkd forces a filesystem sync after every slice completes compressing. If you specify "disable", syncing is disabled entirely; uncompressed slices are removed as soon as compression is complete. Some filesystems are very inefficient at performing sync operations, so only enable this if you are sure you need it. You must restart splunkd after changing this setting. Reloading the configuration does not suffice. No exponent may follow the decimal. The highest legal value is 18446744073709551615.	"disable"
`maxMemMB`	`<nonnegative integer>`The amount of memory, in megabytes, to allocate for indexing. More This amount of memory will be allocated PER INDEX THREAD, or, if indexThreads is set to 0, once per index. CAUTION: Calculate this number carefully. splunkd crashes if you set this number to higher than the amount of memory available. The default is recommended for all environments. The highest legal value is 4294967295.	5
`tsidxSyncPeriod`	`<positive integer>`The amount of time, in seconds, after which splunkd forces a sync of tsidx files. More Indexed events become searchable after the sync, which happens when the indexing buffer is filled or when 'tsidxSyncPeriod' elapsed. Use the higher value to reduce indexing overhead, especially on systems with many indexes. Use the lower value for faster searchability. If the indexedRealtime mode is used, 'tsidxSyncPeriod' should be less than 'indexed_realtime_disk_sync_delay'.	1
`maxHotSpanSecs`	`<positive integer>`Upper bound of timespan of hot/warm buckets, in seconds. More This is an advanced setting that should be set with care and understanding of the characteristics of your data. Splunkd applies this limit per ingestion pipeline. For more information about multiple ingestion pipelines, see 'parallelIngestionPipelines' in the server.conf.spec file. With N parallel ingestion pipelines, each ingestion pipeline writes to and manages its own set of hot buckets, without taking into account the state of hot buckets managed by other ingestion pipelines. Each ingestion pipeline independently applies this setting only to its own set of hot buckets. If you set 'maxHotBuckets' to 1, splunkd attempts to send all events to the single hot bucket and does not enforce 'maxHotSpanSecs'. If you set this setting to less than 3600, it will be automatically reset to 3600. NOTE: If you set this setting to too small a value, splunkd can generate a very large number of hot and warm buckets within a short period of time. The highest legal value is 4294967295. NOTE: the bucket timespan snapping behavior is removed from this setting. See the 6.5 spec file for details of this behavior.	7776000 (90 days)
`maxHotIdleSecs`	`<nonnegative integer>`How long, in seconds, that a hot bucket can remain in hot status without receiving any data. More If a hot bucket receives no data for more than 'maxHotIdleSecs' seconds, splunkd rolls the bucket to warm. This setting operates independently of 'maxHotBuckets', which can also cause hot buckets to roll. A value of 0 turns off the idle check (equivalent to infinite idle time). The highest legal value is 4294967295	0
`maxHotBuckets`	`<positive integer> \| auto`Maximum number of hot buckets that can exist per index. More When 'maxHotBuckets' is exceeded, the indexer rolls the hot bucket containing the least recent data to warm. Both normal hot buckets and quarantined hot buckets count towards this total. This setting operates independently of maxHotIdleSecs, which can also cause hot buckets to roll. NOTE: the indexer applies this limit per ingestion pipeline. For more information about multiple ingestion pipelines, see 'parallelIngestionPipelines' in the server.conf.spec file. With N parallel ingestion pipelines, the maximum number of hot buckets across all of the ingestion pipelines is N * 'maxHotBuckets', but only 'maxHotBuckets' for each ingestion pipeline. Each ingestion pipeline independently writes to and manages up to 'maxHotBuckets' number of hot buckets. Consequently, when multiple ingestion pipelines are configured, there may be multiple hot buckets with events on overlapping time ranges. The highest legal value is 1024. However, do not set to a value greater than 11 without direction from Splunk Support. Higher values can degrade indexing performance. If you specify "auto", the indexer sets the value to 3. This setting applies only to event indexes.	"auto"
`metric.maxHotBuckets`	`<positive integer> \| auto`Maximum number of hot buckets that can exist per metric index More When 'metric.maxHotBuckets' is exceeded, the indexer rolls the hot bucket containing the least recent data to warm. Both normal hot buckets and quarantined hot buckets count towards this total. This setting operates independently of maxHotIdleSecs, which can also cause hot buckets to roll. NOTE: the indexer applies this limit per ingestion pipeline. For more information about multiple ingestion pipelines, see 'parallelIngestionPipelines' in the server.conf.spec file. With N parallel ingestion pipelines, the maximum number of hot buckets across all of the ingestion pipelines is N * 'metric.maxHotBuckets', but only 'metric.maxHotBuckets' for each ingestion pipeline. Each ingestion pipeline independently writes to and manages up to 'metric.maxHotBuckets' number of hot buckets. Consequently, when multiple ingestion pipelines are configured, there may be multiple hot buckets with events on overlapping time ranges. The highest legal value is 4294967295 When set to "auto", this setting will take the defined value from "maxHotBuckets". If "maxHotBuckets" is also set to "auto", the functional value for "metric.maxHotBuckets" is 6. This setting applies only to metric indexes.	"auto"
`minHotIdleSecsBeforeForceRoll`	`<nonnegative integer>\|auto`When there are no existing hot buckets that can fit new events because of their timestamps and the constraints on the index (refer to 'maxHotBuckets', 'maxHotSpanSecs' and 'quarantinePastSecs'), if any hot bucket has been idle (not receiving any data) for 'minHotIdleSecsBeforeForceRoll' seconds, a new bucket is created to receive these new events and the idle bucket is rolled to warm. More If no hot bucket has been idle for 'minHotIdleSecsBeforeForceRoll' seconds, or if 'minHotIdleSecsBeforeForceRoll' has been set to 0, then a best fit bucket is chosen for these new events from the existing set of hot buckets. This setting operates independently of 'maxHotIdleSecs', which causes hot buckets to roll after they have been idle for 'maxHotIdleSecs' seconds, regardless of whether new events can fit into the existing hot buckets or not due to an event timestamp. 'minHotIdleSecsBeforeForceRoll', on the other hand, controls a hot bucket roll only under the circumstances when the timestamp of a new event cannot fit into the existing hot buckets given the other setting constraints on the system (such as 'maxHotBuckets', 'maxHotSpanSecs', and 'quarantinePastSecs'). If you specify "auto", splunkd autotunes this setting. The value begins at 600 and automatically adjusts upwards for optimal performance. Specifically, the value increases when a hot bucket rolls due to idle time with a significantly smaller size than 'maxDataSize'. As a consequence, the outcome might be fewer buckets, though these buckets might span wider earliest-latest time ranges of events. If you specify a value of "0", splunkd turns off the idle check (this is equivalent to infinite idle time). Setting this to zero means that splunkd never rolls a hot bucket as a consequence of an event not fitting into an existing hot bucket due to the constraints of other settings. Instead, it finds a best fitting bucket to accommodate that event. The highest legal value is 4294967295. NOTE: If you configure this setting, there is a chance that this could lead to frequent hot bucket rolls to warm, depending on the value. If your index contains a large number of buckets whose size on disk falls considerably short of the size specified in 'maxDataSize', and if the reason for the roll of these buckets is due to "caller=lru", then configuring the setting value to a larger value or to zero might reduce the frequency of hot bucket rolls (see the "auto" value above). You can check splunkd.log for a message like the following for rolls due to this setting: INFO HotBucketRoller - finished moving hot to warm bid=_internal~0~97597E05-7156-43E5-85B1-B0751462D16B idx=_internal from=hot_v1_0 to=db_1462477093_1462477093_0 size=40960 caller=lru maxHotBuckets=3, count=4 hot buckets,evicting_count=1 LRU hots	auto
`splitByIndexKeys`	`<comma separated list>`By default, splunkd splits buckets by time ranges. When this happens, each bucket is defined by an earliest and latest time. More Use this setting to optionally split buckets by one or more index key fields instead of time ranges. Valid key values are: host, sourcetype, source. This setting applies only to event indexes and requires that the minimal value of 'maxHotBuckets' is 2. If not set, splunkd splits buckets by time span.	empty string (no key)
`metric.splitByIndexKeys`	`<comma separated list>`By default, splunkd splits buckets by time ranges. When this happens, each bucket is defined by an earliest and latest time. More Use this setting to optionally split buckets by one or more index key fields instead of time ranges. Valid key values are: host, sourcetype, source, metric_name. This setting applies only to metric indexes and requires that the minimal value of 'metric.maxHotBuckets' is 2. If not set, the setting 'splitByIndexKeys' applies. If 'splitByIndexKeys' is not set either, splunkd splits buckets by time span.	empty string (no key)
`quarantinePastSecs`	`<positive integer>`Determines what constitutes an anomalous past timestamp for quarantining purposes. More If an event has a timestamp of 'quarantinePastSecs' older than the current time ("now"), the indexer puts that event in the quarantine bucket. This is a mechanism to prevent the main hot buckets from being polluted with fringe events. The highest legal value is 4294967295	77760000 (900 days)
`quarantineFutureSecs`	`<positive integer>`Determines what constitutes an anomalous future timestamp for quarantining purposes. More If an event has a timestamp of 'quarantineFutureSecs' newer than the current time ("now"), the indexer puts that event in the quarantine bucket. This is a mechanism to prevent the main hot buckets from being polluted with fringe events. The highest legal value is 4294967295	2592000 (30 days)
`maxMetaEntries`	`<nonnegative integer>`The maximum number of unique lines in .data files in a bucket, which might help to reduce memory consumption More If this value is exceeded, a hot bucket is rolled to prevent further increase If your buckets are rolling due to Strings.data reaching this limit, the culprit might be the 'punct' field in your data. If you do not use 'punct', it might be best to simply disable this (see props.conf.spec) NOTE: since at least 5.0.x, large strings.data from usage of punct are rare. There is a delta between when 'maxMetaEntries' is exceeded and splunkd rolls the bucket. This means a bucket might end up with more lines than specified in 'maxMetaEntries', but this is not a major concern unless that excess is significant. If set to 0, splunkd ignores this setting (it is treated as infinite) Highest legal value is 4294967295.	1000000
`syncMeta`	`<boolean>`Whether or not splunkd calls a sync operation before the file descriptor is closed on metadata file updates. More When set to "true", splunkd calls a sync operation before it closes the file descriptor on metadata file updates. This functionality was introduced to improve integrity of metadata files, especially in regards to operating system crashes/machine failures. NOTE: Do not change this setting without the input of a Splunk support professional. You must restart splunkd after changing this setting. Reloading the configuration does not suffice.	true
`serviceMetaPeriod`	`<positive integer>`Defines how frequently, in seconds, that metadata is synced to disk. More You might want to set this to a higher value if the sum of your metadata file sizes is larger than many tens of megabytes, to avoid the negative effect on I/O in the indexing fast path. The highest legal value is 4294967295	25
`partialServiceMetaPeriod`	`<positive integer>`The amount of time, in seconds, that splunkd syncs metadata for records that can be synced efficiently in place without requiring a full rewrite of the metadata file. More Related to 'serviceMetaPeriod'. Records that require a full rewrite of the metadata file are synced every 'serviceMetaPeriod' seconds. If you set this to 0, the feature is turned off, and 'serviceMetaPeriod' is the only time when metadata sync happens. If the value of 'partialServiceMetaPeriod' is greater than the value of 'serviceMetaPeriod', this setting has no effect. Splunkd ignores this setting if 'serviceOnlyAsNeeded' = "true" (the default). The highest legal value is 4294967295.	0 (disabled)
`throttleCheckPeriod`	`<positive integer>`How frequently, in seconds, that splunkd checks for index throttling conditions. More NOTE: Do not change this setting unless a Splunk Support professional asks you to. The highest legal value is 4294967295.	15
`maxTimeUnreplicatedWithAcks`	`<nonnegative decimal>`How long, in seconds, that events can remain in an unacknowledged state within a raw slice. More This value is important if you have enabled indexer acknowledgment on forwarders by configuring the 'useACK' setting in outputs.conf and have enabled replication through indexer clustering. This is an advanced setting. Confirm that you understand the settings on all your forwarders before changing it. Do not exceed the ack timeout configured on any forwarders. Set to a number that is at most half of the minimum value of that timeout. Review the 'readTimeout' setting in the [tcpout] stanza in outputs.conf.spec for information about the ack timeout. Configuring this setting to 0 disables the check. Do not do this. The highest legal value is 2147483647.	60
`maxTimeUnreplicatedNoAcks`	`<nonnegative decimal>`How long, in seconds, that events can remain in a raw slice. More This setting is important only if replication is enabled for this index, otherwise it is ignored. If there are any acknowledged events that share this raw slice, this setting does not apply. Instead, splunkd uses the value in the 'maxTimeUnreplicatedWithAcks' setting.) The highest legal value is 2147483647. Configuring this setting to 0 disables the check. Do not configure this setting on remote storage enabled indexes. NOTE: Take care and understand the consequences before changing this setting.	300
`isReadOnly`	`<boolean>`Whether or not the index is read-only. More If you set to "true", no new events can be added to the index, but the index is still searchable. You must restart splunkd after changing this setting. Reloading the index configuration does not suffice. Do not configure this setting on remote storage enabled indexes. If set to 'true', replication must be turned off (repFactor=0) for the index.	false
`homePath.maxDataSizeMB`	`<nonnegative integer>`Specifies the maximum size of 'homePath' (which contains hot and warm buckets). More If this size is exceeded, splunkd moves buckets with the oldest value of latest time (for a given bucket) into the cold DB until homePath is below the maximum size. If you set this setting to 0, or do not set it, splunkd does not constrain the size of 'homePath'. The highest legal value is 4294967295. Splunkd ignores this setting for remote storage enabled indexes.	0
`coldPath.maxDataSizeMB`	`<nonnegative integer>`Specifies the maximum size of 'coldPath' (which contains cold buckets). More If this size is exceeded, splunkd freezes buckets with the oldest value of latest time (for a given bucket) until coldPath is below the maximum size. If you set this setting to 0, or do not set it, splunkd does not constrain the size of 'coldPath'. If splunkd freezes buckets due to enforcement of this setting, and 'coldToFrozenScript' and/or 'coldToFrozenDir' archiving settings are also set on the index, these settings are used. Splunkd ignores this setting for remote storage enabled indexes. The highest legal value is 4294967295.	0
`repFactor`	`0\|auto`Valid only for indexer cluster peer nodes. More Determines whether an index gets replicated. Configuring this setting to 0 turns off replication for this index. Configuring to "auto" turns on replication for this index. You must configure this setting to the same value on all peer nodes.	0
`minStreamGroupQueueSize`	`<nonnegative integer>`Minimum size of the queue that stores events in memory before committing them to a tsidx file. More As splunkd operates, it continually adjusts this size internally. Splunkd could decide to use a small queue size and thus generate tiny tsidx files under certain unusual circumstances, such as file system errors. The danger of a very low minimum is that it can generate very tiny tsidx files with one or very few events, making it impossible for splunk-optimize to catch up and optimize the tsidx files into reasonably sized files. Do not configure this setting unless a Splunk Support professional asks you to. The highest legal value is 4294967295.	2000
`streamingTargetTsidxSyncPeriodMsec`	`<nonnegative integer>`The amount of time, in milliseconds, that splunkd forces a sync of tsidx files on streaming targets. More This setting is needed for multisite clustering where streaming targets might be primary. If you configure this setting to 0, syncing of tsidx files on streaming targets does not occur.	No default
`journalCompression`	`gzip\|lz4\|zstd`The compression algorithm that splunkd should use for the rawdata journal file of new index buckets. More This setting does not have any effect on already created buckets. There is no problem searching buckets that are compressed with different algorithms.	zstd
`zstdCompressionStrategy`	`[1\|2\|3\|4\|5\|6\|7\|8\|9]`Specifies the zstd compression strategy that splunkd should use for the rawdata journal file of new index buckets. More Changing this setting has no effect on already created buckets and buckets created using a compression algorithm other than zstd. Generally, higher values for this setting result in smaller journal files but often at the expense of significantly reduced throughput. This is an advanced setting. Do not change this setting unless instructed by Splunk Support.	2
`enableTsidxReduction`	`<boolean>`When set to true, this setting enables tsidx file reduction for event indexes. More Under tsidx file reduction, the indexer reduces the tsidx files of buckets when the buckets reach the age specified by 'timePeriodInSecBeforeTsidxReduction'. CAUTION: Do not set this setting to "true" for event indexes that are configured to use remote storage with the "remotePath" setting. NOTE: This setting applies to buckets in warm, cold, and thawed. It does not apply to metrics index buckets	false
`metric.enableFloatingPointCompression`	`<boolean>`Determines whether the floating-point values compression is enabled for metric index files. More Set this to false only if you are experiencing high CPU usage during data ingestion. However, doing this will cause you to lose the disk space savings that the compression gives you.	true
`metric.compressionBlockSize`	`<integer>`The block size, in words (eight-byte multiples), that the floating-point compression algorithm should use to store compressed data within a single block in a column. More Valid only if 'metric.enableMetricTsidxFloatingPointCompression' is set to "true". Minimum value: 128 (1024 bytes)	1024 (8192 bytes)
`metric.stubOutRawdataJournal`	`<boolean>`For metrics indexes only. More Determines whether the data in the rawdata file is deleted when the hot bucket rolls to warm. The rawdata file itself remains in place in the bucket. Tsidx files are not affected by this setting. This setting does not take effect for indexes that have replication enabled ("repFactor=auto") in an indexer cluster deployment. A change to this setting affects only future buckets or buckets that are currently hot when the change occurs. It does not affect buckets already in the warm or cold state. Searches over metrics indexes do not use the rawdata file. Therefore, changing this setting to "true" does not affect search results. The benefits of setting to true are: Reduces storage requirements, by reducing rawdata files to the minimal size. Potentially improves search time, because the maximum bucket size (controlled by "maxDataSizeMB") now allows for larger tsidx files, since the rawdata file no longer occupies significant space. The rawdata file size is discounted from the overall bucket size while writing continues in a hot bucket, even though the rawdata file is not removed until the bucket rolls to warm. Thus, the hot bucket might exceed "maxDataSizeMB", but, once the bucket rolls to warm, its size will no longer exceed "maxDataSizeMB". Caution: Because setting this attribute to "true" eliminates the data in the rawdata files, those files can no longer be used in bucket repair operations.	true
`suspendHotRollByDeleteQuery`	`<boolean>`Whether or not splunkd rolls hot buckets upon running of the "delete" search command, or waits to roll them for other reasons. More When the "delete" search command is run, all buckets that contain data to be deleted are marked for updating of their metadata files. The indexer normally first rolls any hot buckets as rolling must precede the metadata file updates. When 'suspendHotRollByDeleteQuery' is set to "true", the rolling of hot buckets for the "delete" command is suspended. The hot buckets, although marked, do not roll immediately, but instead wait to roll in response to the same circumstances operative for any other hot buckets; for example, due to reaching a limit set by 'maxHotBuckets', 'maxDataSize', etc. When these hot buckets finally roll, their metadata files are then updated.	false
`tsidxReductionCheckPeriodInSec`	`<positive integer>`The amount of time, in seconds, between service runs to reduce the tsidx files for any buckets that have reached the age specified by 'timePeriodInSecBeforeTsidxReduction'.	600
`timePeriodInSecBeforeTsidxReduction`	`<positive integer>`The amount of time, in seconds, that a bucket can age before it becomes eligible for tsidx reduction. More The bucket age is the difference between the current time and the timestamp of the bucket's latest event. When this time difference is exceeded, a bucket becomes eligible for tsidx reduction.	604800
`tsidxDedupPostingsListMaxTermsLimit`	`<positive integer>`This setting is valid only when 'tsidxWritingLevel' is at 4 or higher. More This max term limit sets an upper bound on the number of terms kept inside an in-memory hash table that serves to improve tsidx compression. The tsidx optimizer uses the hash table to identify terms with identical postings lists. When the first instance of a term is received its postings list is stored. When successive terms with identical postings lists are received the tsidx optimizer makes them refer to the first instance of the postings list rather than creating and storing term postings list duplicates. Consider increasing this limit to improve compression for large tsidx files. For example, a tsidx file created with 'tsidxTargetSizeMB' over 1500MB can contain a large number of terms with identical postings lists. Reducing this limit helps conserve memory consumed by optimization processes, at the cost of reduced tsidx compression. Set this limit to 0 to disable deduplicated postings list compression. This setting cannot exceed 1,073,741,824 (2^30).	8,388,608 (2^23)
`tsidxTargetSizeMB`	`<positive integer>`The target size for tsidx files. The indexer attempts to make all tsidx files in index buckets as close to this size as possible when: (a) buckets merge. (b) hot buckets roll to warm buckets. More This value is used to help tune the performance of tsidx-based search queries, especially 'tstats'. If this value exceeds 'maxDataSize', then the hot bucket will roll based on the 'maxDataSize' configuration even if no tsidx file has met the specified 'tsidxTargetSizeMB'. Cannot exceed 4096 MB (4 GB).	1500 (MB)
`metric.tsidxTargetSizeMB`	`<positive integer>`The target size for msidx files (tsidx files for metrics data). The indexer attempts to make all msidx files in index buckets as close to this size as possible when: (a) buckets merge. (b) hot buckets roll to warm buckets. More This value is used to help tune the performance of metrics search queries, especially 'mstats'. If this value exceeds 'maxDataSize', then the hot bucket will roll based on the 'maxDataSize' configuration even if no msidx file has met the specified 'metric.tsidxTargetSizeMB'. Cannot exceed 4096 MB (4 GB).	1500 (MB)
`metric.timestampResolution`	`<s\|ms>`This setting specifies the timestamp resolution for metrics tsidx files. Specify 's' for timestamps with second resolution. Specify 'ms' for timestamps with millisecond resolution. More Indexes with millisecond timestamp precision have reduced search performance. Optional.	s
`datatype`	`<event\|metric>`Determines whether the index stores log events or metric data. More If set to "metric", the indexer optimizes the index to store metric data which can be queried later only using the 'mstats' operator, as searching metric data is different from traditional log events. Use the "metric" data type only for metric sourcetypes like statsd. Optional.	event
`waitPeriodInSecsForManifestWrite`	`<nonnegative integer>`This setting specifies the minimum interval, in seconds, between periodic updates of an index's manifest file. More Setting to a lower value can reduce the performance of bucket operations like fix-ups, freezes, etc. Do not increase this value beyond the default except through consultation with Splunk Support. Increasing the value can lead to inconsistencies in data. The highest legal value is 4294967295.	60 (1 min)
`hotBucketStreaming.sendSlices`	`<boolean>`Enables uploading of journal slices of hot buckets to the remote storage.	false
`hotBucketStreaming.removeRemoteSlicesOnRoll`	`<boolean>`Enables removal of uploaded journal slices of hot buckets from the remote storage after a bucket rolls from hot to warm. More This setting should be enabled only if 'hotBucketStreaming.sendSlices' is also enabled.	false
`hotBucketStreaming.removeRemoteSlicesOnFreeze`	`<boolean>`Enables removal of uploaded journal slices of hot buckets from the remote storage after a bucket rolls from warm to frozen. More This setting should be enabled only if 'hotBucketStreaming.sendSlices' is also enabled.	false
`hotBucketStreaming.reportStatus`	`<boolean>`Currently not supported. This setting is related to a feature that is still under development.	false
`hotBucketStreaming.deleteHotsAfterRestart`	`<boolean>`Currently not supported. This setting is related to a feature that is still under development.	false

Per provider family options

A provider family is a way of collecting properties that are common to multiple providers. There are no properties that can only be used in a provider family, and not in a provider. If the same property is specified in a family, and in a provider belonging to that family, then the latter value "wins".

Per provider options

These options affect External Resource Providers (ERPs). All provider stanzas begin with "provider:".

Setting	Description	Default
`vix.family`	`<family>`A provider family to which this provider belongs. More The only family available by default is "hadoop". Others can be added.
`vix.mode`	`stream\|report`Usually specified at the family level. More Typically should be "stream". In general, do not use "report" without consulting Splunk Support.
`vix.command`	`<command>`The command to be used to launch an external process for searches on this provider. More Usually specified at the family level.
`vix.command.arg.<N>`	`<argument>`The Nth argument to the command specified by vix.command. More Usually specified at the family level, but frequently overridden at the provider level, for example to change the jars used depending on the version of Hadoop to which a provider connects.
`vix.<property name>`	`<property value>`All such properties will be made available as "configuration properties" to search processes on this provider. More For example, if this provider is in the Hadoop family, the configuration property "mapreduce.foo = bar" can be made available to the Hadoop via the property "vix.mapreduce.foo = bar".
`vix.env.<env var name>`	`<env var variable>`Will create an environment variable available to search processes on this provider. More For example, to set the JAVA_HOME variable to "/path/java" for search processes on this provider, use "vix.env.JAVA_HOME = /path/java".

Per provider options -- Hadoop

These options are specific to ERPs with the Hadoop family.
NOTE: Many of these properties specify behavior if the property is not set. However, default values set in system/default/indexes.conf take precedence over the "unset" behavior.

Setting	Description	Default
`vix.javaprops.<JVM system property name>`	`<value>`All such properties will be used as Java system properties. More For example, to specify a Kerberos realm (say "foo.com") as a Java system property, use the property "vix.javaprops.java.security.krb5.realm = foo.com".
`vix.mapred.job.tracker`	`<logical name or server:port>`In high-availability mode, use the logical name of the Job Tracker. More Otherwise, should be set to server:port for the single Job Tracker. Note: this property is passed straight to Hadoop. Not all such properties are documented here.
`vix.fs.default.name`	`<logical name or hdfs://server:port>`In high-availability mode, use the logical name for a list of Name Nodes. More Otherwise, use the URL for the single Name Node. Note: this property is passed straight to Hadoop. Not all such properties are documented here.
`vix.splunk.setup.onsearch`	`true\|false`Whether to perform setup (install & bundle replication) on search.	false
`vix.splunk.setup.package`	`current\|<path to file>`Splunk .tgz package to install and use on data nodes (in vix.splunk.home.datanode). More Uses the current install if set to value 'current' (without quotes).
`vix.splunk.home.datanode`	`<path to dir>`Path to where splunk should be installed on datanodes/tasktrackers, i.e. SPLUNK_HOME. More Required.
`vix.splunk.home.hdfs`	`<path to dir>`Scratch space for this Splunk instance on HDFS More Required.
`vix.splunk.search.debug`	`true\|false`Whether to run searches against this index in debug mode. In debug mode, additional information is logged to search.log. More Optional.	false
`vix.splunk.search.recordreader`	`<list of classes>`Comma separated list of data preprocessing classes. More Each such class must extend BaseSplunkRecordReader and return data to be consumed by Splunk as the value.
`vix.splunk.search.splitter`	`<class name>`Set to override the class used to generate splits for MR jobs. More Classes must implement com.splunk.mr.input.SplitGenerator. Unqualified classes will be assumed to be in the package com.splunk.mr.input. May be specified in either the provider stanza, or the virtual index stanza. To search Parquet files, use ParquetSplitGenerator. To search Hive files, use HiveSplitGenerator.
`vix.splunk.search.mr.threads`	`<postive integer>`Number of threads to use when reading map results from HDFS More Numbers less than 1 will be treated as 1. Numbers greater than 50 will be treated as 50.	10
`vix.splunk.search.mr.maxsplits`	`<positive integer>`Maximum number of splits in an MR job.	10000
`vix.splunk.search.mr.minsplits`	`<positive integer>`Number of splits for first MR job associated with a given search.	100
`vix.splunk.search.mr.splits.multiplier`	`<decimal greater than or equal to 1.0>`Factor by which the number of splits is increased in consecutive MR jobs for a given search, up to the value of maxsplits.	10
`vix.splunk.search.mr.poll`	`<positive integer>`Polling period for job status, in milliseconds.	1000 (1 second).
`vix.splunk.search.mr.mapper.output.replication`	`<positive integer>`Replication level for mapper output.	3
`vix.splunk.search.mr.mapper.output.gzlevel`	`<integer between 0 and 9, inclusive>`The compression level used for the mapper output.	2
`vix.splunk.search.mixedmode`	`<boolean>`Whether mixed mode execution is enabled.	true
`vix.splunk.search.mixedmode.maxstream`	`<nonnegative integer>`Maximum number of bytes to stream during mixed mode. More Value = 0 means there's no stream limit. Will stop streaming after the first split that took the value over the limit.	10737418240 (10 GB).
`vix.splunk.jars`	`<list of paths>`Comma delimited list of Splunk dirs/jars to add to the classpath in the Search Head and MR.
`vix.env.HUNK_THIRDPARTY_JARS`	`<list of paths>`Comma delimited list of 3rd-party dirs/jars to add to the classpath in the Search Head and MR.
`vix.splunk.impersonation`	`true\|false`Enable/disable user impersonation.
`vix.splunk.setup.bundle.replication`	`<positive integer>`Set custom replication factor for bundles on HDFS. More Must be an integer between 1 and 32767. Increasing this setting may help performance on large clusters by decreasing the average access time for a bundle across Task Nodes. Optional.	The default replication factor for the file-system applies.
`vix.splunk.setup.bundle.max.inactive.wait`	`<positive integer>`A positive integer represent a time interval in seconds. More While a task waits for a bundle being replicated to the same node by another task, if the bundle file is not modified for this amount of time, the task will begin its own replication attempt.	5
`vix.splunk.setup.bundle.poll.interval`	`<positive integer>`A positive number, representing a time interval in milliseconds. More While a task waits for a bundle to be installed by another task on the same node, it will check once per interval whether that installation is complete.	100
`vix.splunk.setup.bundle.setup.timelimit`	`<positive integer>`A positive number, representing a time duration in milliseconds. More A task will wait this long for a bundle to be installed before it quits.	20000 (20 seconds).
`vix.splunk.setup.package.replication`	`true\|false`Set custom replication factor for the Splunk package on HDFS. This is the package set in the property vix.splunk.setup.package. More Must be an integer between 1 and 32767. Increasing this setting may help performance on large clusters by decreasing the average access time for the package across Task Nodes. Optional. If not set, the default replication factor for the file-system will apply.
`vix.splunk.setup.package.max.inactive.wait`	`<positive integer>`A positive integer represent a time interval in seconds. More While a task waits for a Splunk package being replicated to the same node by another task, if the package file is not modified for this amount of time, the task will begin its own replication attempt.	5
`vix.splunk.setup.package.poll.interval`	`<positive integer>`A positive number, representing a time interval in milliseconds. More While a task waits for a Splunk package to be installed by another task on the same node, it will check once per interval whether that installation is complete.	100
`vix.splunk.setup.package.setup.timelimit`	`<positive integer>`A positive number, representing a time duration in milliseconds. More A task will wait this long for a Splunk package to be installed before it quits.	20000 (20 seconds)
`vix.splunk.setup.bundle.reap.timelimit`	`<positive integer>`Specific to Hunk provider More For bundles in the working directory on each data node, this property controls how old they must be before they are eligible for reaping. Unit is milliseconds Values larger than 86400000 will be treated as if set to 86400000.	86400000 (24 hours)
`vix.splunk.search.column.filter`	`<boolean>`Enables/disables column filtering. When enabled, Hunk will trim columns that are not necessary to a query on the Task Node, before returning the results to the search process. More Should normally increase performance, but does have its own small overhead. Works with these formats: CSV, Avro, Parquet, Hive.	true
`vix.kerberos.principal`	`<kerberos principal name>`Specifies principal for Kerberos authentication. More Should be used with vix.kerberos.keytab and either 1) vix.javaprops.java.security.krb5.realm and vix.javaprops.java.security.krb5.kdc, or 2) security.krb5.conf
`vix.kerberos.keytab`	`<kerberos keytab path>`Specifies path to keytab for Kerberos authentication. More See usage note with vix.kerberos.principal.
`vix.splunk.heartbeat`	`<boolean>`Turn on/off heartbeat update on search head, and checking on MR side.	true
`vix.splunk.heartbeat.path`	`<path on HDFS>`Path to heartbeat file. More If not set, defaults to <vix.splunk.home.hdfs>/dispatch/<sid>/
`vix.splunk.heartbeat.interval`	`<positive integer>`The frequency, in milliseconds, with which the Heartbeat will be updated on the Search Head. More Minimum value is 1000. Smaller values will cause an exception to be thrown.	6000 (6 seconds)
`vix.splunk.heartbeat.threshold`	`<positive integer>`The number of times the MR job will detect a missing heartbeat update before it considers SplunkMR dead and kills itself.	10
`vix.splunk.search.recordreader.sequence.ignore.key`	`<boolean>`When reading sequence files, if this key is enabled, events will be expected to only include a value. Otherwise, the expected representation is key+"\t"+value.	true
`vix.splunk.search.recordreader.avro.regex`	`<string>`The regular expression that files must match in order to be considered avro files. More Optional.	\.avro$
`vix.splunk.search.splitter.parquet.simplifyresult`	`<boolean>`If enabled, field names for map and list type fields will be simplified by dropping intermediate "map" or "element" subfield names. Otherwise, a field name will match parquet schema completely. More May be specified in either the provider stanza or in the virtual index stanza.	true
`vix.splunk.search.splitter.hive.ppd`	`<boolean>`Enable or disable Hive ORC Predicate Push Down. More If enabled, ORC PPD will be applied whenever possible to prune unnecessary data as early as possible to optimize the search. May be specified in either the provider stanza or in the virtual index stanza.	true
`vix.splunk.search.splitter.hive.fileformat`	`textfile\|sequencefile\|rcfile\|orc`Format of the Hive data files in this provider. More May be specified in either the provider stanza or in the virtual index stanza.	"textfile"
`vix.splunk.search.splitter.hive.dbname`	`<DB name>`Name of Hive database to be accessed by this provider. More Optional. May be specified in either the provider stanza or in the virtual index stanza.	"default"
`vix.splunk.search.splitter.hive.tablename`	`<table name>`Table accessed by this provider. More Required property. May be specified in either the provider stanza or in the virtual index stanza.
`vix.splunk.search.splitter.hive.columnnames`	`<list of column names>`Comma-separated list of file names. More Required if using Hive, not using metastore. Can be specified in either the provider stanza or in the virtual index stanza.
`vix.splunk.search.splitter.hive.columntypes`	`string:float:int # COLON separated list of column types, required`Colon-separated list of column- types. More Required if using Hive, not using metastore. Can be specified in either the provider stanza or in the virtual index stanza.
`vix.splunk.search.splitter.hive.serde`	`<SerDe class>`Fully-qualified class name of SerDe. More Required if using Hive, not using metastore, and if specified in creation of Hive table. Can be specified in either the provider stanza or in the virtual index stanza.
`vix.splunk.search.splitter.hive.serde.properties`	`<list of key-value pairs>`Comma-separated list of "key=value" pairs. More Required if using Hive, not using metastore, and if specified in creation of Hive table. Can be specified in either the provider stanza or in the virtual index stanza.
`vix.splunk.search.splitter.hive.fileformat.inputformat`	`<InputFormat class>`Fully-qualified class name of an InputFormat to be used with Hive table data. More Can be specified in either the provider stanza or in the virtual index stanza.
`vix.splunk.search.splitter.hive.rowformat.fields.terminated`	`<delimiter>`Will be set as the Hive SerDe property "field.delim". More Optional. Can be specified in either the provider stanza or in the virtual index stanza.
`vix.splunk.search.splitter.hive.rowformat.escaped`	`<escape char>`Will be set as the Hive SerDe property "escape.delim". More Optional. Can be specified in either the provider stanza or in the virtual index stanza.
`vix.splunk.search.splitter.hive.rowformat.lines.terminated`	`<delimiter>`Will be set as the Hive SerDe property "line.delim". More Optional. Can be specified in either the provider stanza or in the virtual index stanza.
`vix.splunk.search.splitter.hive.rowformat.mapkeys.terminated`	`<delimiter>`Will be set as the Hive SerDe property "mapkey.delim". More Optional. Can be specified in either the provider stanza or in the virtual index stanza.
`vix.splunk.search.splitter.hive.rowformat.collectionitems.terminated`	`<delimiter>`Will be set as the Hive SerDe property "colelction.delim". More Optional. Can be specified in either the provider stanza or in the virtual index stanza.
`vix.output.buckets.max.network.bandwidth`	`0\|<bits per second>`Throttles network bandwidth to <bits per second> More Set at provider level. Applied to all virtual indexes using a provider with this setting.	0 (no throttling)

Per virtual index options

These options affect virtual indexes. Like indexes, these options may be set under an [<virtual-index>] entry.

Setting	Description	Default
`vix.provider`	`<provider_name>`Name of the external resource provider to use for this virtual index.

Per virtual index options -- Hadoop

These options are specific to ERPs with the Hadoop family.

Setting	Description	Default
`vix.input.x.path`	`<path>`Path in a Hadoop filesystem (usually HDFS or S3). More May contain wildcards. Checks the path for data recursively when ending with '...' Can extract fields with ${field}. I.e: "/data/${server}/...", where server will be extracted. May start with a schema. The schema of the path specifies which hadoop filesystem implementation to use. Examples: hdfs://foo:1234/path, will use a HDFS filesystem implementation s3a://s3-bucket/path, will use a S3 filesystem implementation
`vix.input.x.accept`	`<regex>`Specifies an allow list regex. More Only files within the location given by matching vix.input.x.path, whose paths match this regex, will be searched.
`vix.input.x.ignore`	`<regex>`Specifies a deny list regex. More Searches will ignore paths matching this regex. These matches take precedence over vix.input.x.accept matches.
`vix.input.x.required.fields`	`<comma separated list of fields>`Fields that will be kept in search results even if the field is not required by the search
`vix.input.x.et.regex`	`<regex>`Regex extracting earliest time from vix.input.x.path
`vix.input.x.et.format`	`<java.text.SimpleDateFormat date pattern>`Format of the extracted earliest time. More See documentation for java.text.SimpleDateFormat
`vix.input.x.et.offset`	`<seconds>`Offset in seconds to add to the extracted earliest time.
`vix.input.x.et.timezone`	`<java.util.SimpleTimeZone timezone id>`Timezone in which to interpret the extracted earliest time. More Examples: "America/Los_Angeles" or "GMT-8:00"
`vix.input.x.et.value`	`mtime\|<epoch time in milliseconds>`Sets the earliest time for this virtual index. More Can be used instead of extracting times from the path via vix.input.x.et.regex When set to "mtime", uses the file modification time as the earliest time.
`vix.input.x.lt.regex`	`<regex>`Latest time equivalent of vix.input.x.et.regex
`vix.input.x.lt.format`	`<java.text.SimpleDateFormat date pattern>`Latest time equivalent of vix.input.x.et.format
`vix.input.x.lt.offset`	`<seconds>`Latest time equivalent of vix.input.x.et.offset
`vix.input.x.lt.timezone`	`<java.util.SimpleTimeZone timezone id>`Latest time equivalent of vix.input.x.et.timezone
`vix.input.x.lt.value`	`<mod time>`Latest time equivalent of vix.input.x.et.value
`vix.output.buckets.path`	`<hadoop path>`Path to a hadoop filesystem where buckets will be archived
`vix.output.buckets.older.than`	`<integer>`The age of a bucket, in seconds, before it is archived. More The age of a bucket is determined by the the earliest _time field of any event in the bucket.
`vix.output.buckets.from.indexes`	`<comma separated list of splunk indexes>`List of (non-virtual) indexes that will get archived to this (virtual) index.
`vix.unified.search.cutoff_sec`	`<seconds>`Window length before present time that configures where events are retrieved for unified search More Events from now to now-cutoff_sec will be retrieved from the splunk index and events older than cutoff_sec will be retrieved from the archive index

Per virtual index or provider options -- Hadoop

These options can be set at either the virtual index level or provider level, for the Hadoop ERP.

Setting	Description	Default
`recordreader.<name>.<conf_key>`	`<conf_value>`Sets a configuration key for a RecordReader with <name> to <conf_value>
`recordreader.<name>.regex`	`<regex>`Regex specifying which files this RecordReader can be used for.
`recordreader.journal.buffer.size`	`<bytes>`Buffer size used by the journal record reader
`recordreader.csv.dialect`	`default\|excel\|excel-tab\|tsv`Set the csv dialect for csv files More A csv dialect differs on delimiter_char, quote_char and escape_char. Here is a list of how the different dialects are defined in order delimiter, quote, and escape: default = , " \ excel = , " " excel-tab = \t " " tsv = \t " \
`splitter.<name>.<conf_key>`	`<conf_value>`Sets a configuration key for a split generator with <name> to <conf_value> More See comment above under "PER VIRTUAL INDEX OR PROVIDER OPTIONS". This means that the full format is: vix.input.N.splitter.<name>.<conf_key> (in a vix stanza) vix.splunk.search.splitter.<name>.<conf_key> (in a provider stanza)
`splitter.file.split.minsize`	`<integer>`Minimum size, in bytes, for file splits.	1
`splitter.file.split.maxsize`	`<integer>`Maximum size, in bytes, for file splits.	Long.MAX_VALUE

Volume settings

This section describes settings that affect the volume-optional and volume-mandatory settings only.

Setting	Description	Default
`storageType`	`local \| remote`Optional. More Specifies whether the volume definition is for indexer local storage or remote storage. Only the 'remotePath' setting references a remote volume.	"local"
`path`	`<path on server>`Required. More If storageType is set to its default value of "local": The 'path' setting points to the location on the file system where all indexes that will use this volume reside. This location must not overlap with the location for any other volume or index. If storageType is set to "remote": The 'path' setting points to the remote storage location where indexes reside. The format for this setting is: <scheme>://<remote-location-specifier> The "scheme" identifies a supported external storage system type. The "remote-location-specifier" is an external system-specific string for identifying a location inside the storage system. For Google Cloud Storage, this is specified as "gs://<bucket-name>/path/to/splunk/db" For Microsoft Azure Blob storage, this is specified as "azure://<container-name>/path/to/splunk/db" Note that "<container-name>" is needed here only if 'remote.azure.container_name' is not set.
`maxVolumeDataSizeMB`	`<positive integer>`If set, this setting limits the total size of all databases that reside on this volume to the maximum size specified, in MB. Note that this it will act only on those indexes which reference this volume, not on the total size of the path set in the 'path' setting of this volume. More If the size is exceeded, splunkd removes buckets with the oldest value of latest time (for a given bucket) across all indexes in the volume, until the volume is below the maximum size. This is the trim operation. This can cause buckets to be chilled [moved to cold] directly from a hot DB, if those buckets happen to have the least value of latest-time (LT) across all indexes in the volume. The highest legal value is 4294967295. The lowest legal value is 1. Optional. This setting is ignored when 'storageType' is set to "remote" or when set to "local" and the volume contains any remote-storage enabled indexes.
`rotatePeriodInSecs`	`<nonnegative integer>`Optional, ignored for storageType=remote More Specifies period of trim operation for this volume. The highest legal value is 4294967295.	The global 'rotatePeriodInSecs' value
`remote.*`	`<string>`With remote volumes, communication between the indexer and the external storage system may require additional configuration, specific to the type of storage system. You can pass configuration information to the storage system by specifying the settings through the following schema: remote.<scheme>.<config-variable> = <value>. For example: remote.s3.access_key = ACCESS_KEY More Optional.

S3 specific settings

Setting	Description	Default
`remote.s3.header.<http-method-name>.<header-field-name>`	`<string>`Enable server-specific features, such as reduced redundancy, encryption, and so on, by passing extra HTTP headers with the REST requests. The <http-method-name> can be any valid HTTP method. For example, GET, PUT, or ALL, for setting the header field for all HTTP methods. More Example: remote.s3.header.PUT.x-amz-storage-class = REDUCED_REDUNDANCY Optional.
`remote.s3.access_key`	`<string>`Specifies the access key to use when authenticating with the remote storage system supporting the S3 API. More If not specified, the indexer will look for these environment variables: AWS_ACCESS_KEY_ID or AWS_ACCESS_KEY (in that order). If the environment variables are not set and the indexer is running on EC2, the indexer attempts to use the access key from the IAM role. Unencrypted access key cannot begin with "$1$" or "$7$". These prefixes are reserved for use by Splunk software to signify that the access key is already encrypted. Optional.	No default
`remote.s3.secret_key`	`<string>`Specifies the secret key to use when authenticating with the remote storage system supporting the S3 API. More If not specified, the indexer will look for these environment variables: AWS_SECRET_ACCESS_KEY or AWS_SECRET_KEY (in that order). If the environment variables are not set and the indexer is running on EC2, the indexer attempts to use the secret key from the IAM role. Unencrypted secret key cannot begin with "$1$" or "$7$". These prefixes are reserved for use by Splunk software to signify that the secret key is already encrypted. Optional.	No default
`remote.s3.list_objects_version`	`v1\|v2`The AWS S3 Get Bucket (List Objects) Version to use. More See AWS S3 documentation "GET Bucket (List Objects) Version 2" for details.	v1
`remote.s3.signature_version`	`v2\|v4`The signature version to use when authenticating with the remote storage system supporting the S3 API. More For 'sse-kms' and 'sse-c' server-side encryption schemes, and for 'cse' client-side encryption scheme, you must use signature_version=v4. For signature_version=v2 you must set url_version=v1. Optional.	v4
`remote.s3.url_version`	`v1\|v2`Specifies which url version to use, both for parsing the endpoint/path, and More for communicating with the remote storage. This value only needs to be specified when running on non-AWS S3-compatible storage that has been configured to use v2 urls. In v1 the bucket is the first element of the path. Example: mydomain.com/bucketname/rest/of/path In v2 the bucket is the outermost subdomain in the endpoint. Exmaple: bucketname.mydomain.com/rest/of/path	v1
`remote.s3.auth_region`	`<string>`The authentication region to use for signing requests when interacting with the remote storage system supporting the S3 API. More Used with v4 signatures only. If unset and the endpoint (either automatically constructed or explicitly set with remote.s3.endpoint setting) uses an AWS URL (for example, https://<bucketname>.s3.us-west-1.amazonaws.com), the instance attempts to extract the value from the endpoint URL (for example, "us-west-1"). See the description for the remote.s3.endpoint setting. If unset and an authentication region cannot be determined, the request will be signed with an empty region value. This can lead to rejected requests when using non-AWS S3-compatible storage. Optional.	No default
`remote.s3.use_delimiter`	`<boolean>`Specifies whether a delimiter (currently "guidSplunk") should be used to list the objects that are present on the remote storage. More A delimiter groups objects that have the same delimiter value so that the listing process can be more efficient as it does not need to report similar objects. Optional.	true
`remote.s3.supports_versioning`	`<boolean>`Specifies whether the remote storage supports versioning. More Versioning is a means of keeping multiple variants of an object in the same bucket on the remote storage. This setting determines how splunkd removes data from remote storage. If set to true, splunkd will delete all versions of objects at time of data removal. Otherwise, if set to false, splunkd will use a simple DELETE (See https://docs.aws.amazon.com/AmazonS3/latest/dev/DeletingObjectVersions.html). Optional.	true
`remote.s3.endpoint`	`<URL>`The URL of the remote storage system supporting the S3 API. More The scheme, http or https, can be used to enable or disable SSL connectivity with the endpoint. If not specified and the indexer is running on EC2, the endpoint will be constructed automatically based on the EC2 region of the instance where the indexer is running, as follows: https://<bucketname>.s3.<region>.amazonaws.com Example: https://<bucketname>.s3.us-west-2.amazonaws.com Optional.
`remote.s3.bucket_name`	`<string>`Specifies the S3 bucket to use when endpoint isn't set. More Example path = s3://path/example remote.s3.bucket_name = mybucket Used for constructing the amazonaws.com hostname, as shown above. If neither endpoint nor bucket_name is specified, the bucket is assumed to be the first path element. Optional.
`remote.s3.tsidx_compression`	`<boolean>`DEPRECATED; use 'remote.s3.compression' instead. If both 'remote.s3.tsidx_compression' and 'remote.s3.compression' are specified, 'remote.s3.compression' takes precedence. More Whether or not the indexer compresses tsidx files before it uploads them to S3. A value of "true" means the indexer compresses tsidx files before it uploads them to S3. Ensure that every indexer is running Splunk version 9.0.0 or above before enabling this feature. This feature is not backward compatible. Once activated, you will not be able to downgrade Splunk to versions earlier than 9.0.0.	false
`remote.s3.compression`	`<boolean>`Whether or not the indexer compresses files before it uploads them to S3. More A value of "true" means the indexer compresses files before it uploads them to S3. Ensure that all indexers run Splunk Enterprise version 9.4.0 or higher before you enable this feature. This feature is not backward compatible. After you activate it, you cannot downgrade Splunk Enterprise to versions below 9.4.0.	false
`remote.s3.compression_extension_list`	`<comma-separated list>`A list of extensions of the files to be compressed when 'remote.s3.compression' has a value of "true".	tsidx
`remote.s3.multipart_download.part_size`	`<unsigned integer>`Sets the download size of parts during a multipart download. More This setting uses HTTP/1.1 Range Requests (RFC 7233) to improve throughput overall and for retransmission of failed transfers. The special value of 0 disables downloading in multiple parts. In other words, files will always get downloaded as a single (large) part. Do not change this value unless that value has been proven to improve throughput. Optional. Minimum value: 5242880 (5 MB)	134217728 (128 MB)
`remote.s3.multipart_upload.part_size`	`<unsigned integer>`Sets the upload size of parts during a multipart upload. More The special value of 0 disables uploading in multiple parts. In other words, files will always get uploaded as a single (large) part. Optional. Minimum value: 5242880 (5 MB)	134217728 (128 MB)
`remote.s3.multipart_max_connections`	`<unsigned integer>`Specifies the maximum number of HTTP connections to have in progress for either multipart download or upload. More A value of 0 means unlimited.	8
`remote.s3.max_idle_connections`	`<unsigned integer>`Specifies the maximum number of idle HTTP connections that can be pooled for reuse by the S3 client when connecting to the S3 server. More A value of 0 means pooling of connections is disabled.	25
`remote.s3.enable_data_integrity_checks`	`<boolean>`If set to true, Splunk sets the data checksum in the metadata field of the HTTP header during upload operation to S3. More The checksum is used to verify the integrity of the data on uploads.	false
`remote.s3.enable_signed_payloads`	`<boolean>`If set to true, Splunk signs the payload during upload operation to S3. More Valid only for remote.s3.signature_version = v4	true
`remote.s3.object_locks_retention_period`	`<integer>`The retention period, in days, for AWS S3 Object Locks that splunkd applies to new objects in remote storage. More For Dynamic Data: Active Searchable (DDAS), configure this setting to match the number of days that you want to keep version history in the DDAS AWS S3 bucket, for example, 15. A value of 0 means that Object Lock is deactivated. NOTE: Do not change unless instructed to do so by Splunk Support. Supported only on Splunk Cloud Platform.	0
`remote.s3.retry_policy`	`max_count`Sets the retry policy to use for remote file operations. More A retry policy specifies whether and how to retry file operations that fail for those failures that might be intermittent. Retry policies: + "max_count": Imposes a maximum number of times a file operation will be retried upon intermittent failure both for individual parts of a multipart download or upload and for files as a whole. Optional.	max_count
`remote.s3.max_count.max_retries_per_part`	`<unsigned integer>`When the 'remote.s3.retry_policy' setting is "max_count", sets the maximum number of times a file operation will be retried upon intermittent failure. More The count is maintained separately for each file part in a multipart download or upload. Optional.	9
`remote.s3.max_count.max_retries_in_total`	`<unsigned integer>`When the remote.s3.retry_policy setting is max_count, sets the maximum number of times a file operation will be retried upon intermittent failure. More The count is maintained for each file as a whole. Optional.	128
`remote.s3.timeout.connect`	`<unsigned integer>`Set the connection timeout, in milliseconds, to use when interacting with S3 for this volume More Optional.	5000
`remote.s3.timeout.read`	`<unsigned integer>`Set the read timeout, in milliseconds, to use when interacting with S3 for this volume More Optional.	60000
`remote.s3.timeout.write`	`<unsigned integer>`Set the write timeout, in milliseconds, to use when interacting with S3 for this volume More Optional.	60000
`remote.s3.sslVerifyServerCert`	`<boolean>`If this is set to true, Splunk verifies certificate presented by S3 server and checks that the common name/alternate name matches the ones specified in 'remote.s3.sslCommonNameToCheck' and 'remote.s3.sslAltNameToCheck'. More Optional	false
`remote.s3.sslVersions`	`<comma-separated list>`The list of TLS versions to use to connect to 'remote.s3.endpoint'. More The versions available are "tls1.0", "tls1.1", "tls1.2", and "tls1.3". The special version "*" selects all supported versions. The version "tls" selects all versions tls1.0 or newer. If a version is prefixed with "-" it is removed from the list. SSL versions 2 and 3 are always disabled. "-ssl2" and "-ssl3" are accepted as values in the version list, but have no effect. Optional.	tls1.2,tls1.3
`remote.s3.sslCommonNameToCheck`	`<commonName1>, <commonName2>, ..`If this value is set, and 'remote.s3.sslVerifyServerCert' is set to true, splunkd checks the common name of the certificate presented by the remote server (specified in 'remote.s3.endpoint') against this list of common names.	not set
`remote.s3.sslAltNameToCheck`	`<alternateName1>, <alternateName2>, ..`If this value is set, and 'remote.s3.sslVerifyServerCert' is set to true, splunkd checks the alternate name(s) of the certificate presented by the remote server (specified in 'remote.s3.endpoint') against this list of subject alternate names.	No default
`remote.s3.sslRootCAPath`	`<path>`Full path to the Certificate Authority (CA) certificate PEM format file containing one or more certificates concatenated together. S3 certificate will be validated against the CAs present in this file. More Optional.	[sslConfig/caCertFile] in server.conf
`remote.s3.cipherSuite`	`<cipher suite string>`If set, uses the specified cipher string for the SSL connection. More If not set, uses the default cipher string. Must specify 'dhFile' to enable any Diffie-Hellman ciphers. Optional.	TLSv1+HIGH:TLSv1.2+HIGH:@STRENGTH
`remote.s3.ecdhCurves`	`<comma-separated list>`ECDH curves to use for ECDH key negotiation. More The curves should be specified in the order of preference. The client sends these curves as a part of Client Hello. Splunk software only supports named curves specified by their SHORT names. The list of valid named curves by their short/long names can be obtained by executing this command: $SPLUNK_HOME/bin/splunk cmd openssl ecparam -list_curves e.g. ecdhCurves = prime256v1,secp384r1,secp521r1 Optional.	No default
`remote.s3.dhFile`	`<path>`PEM format Diffie-Hellman parameter file name. More DH group size should be no less than 2048bits. This file is required in order to enable any Diffie-Hellman ciphers. Optional.	No default
`remote.s3.encryption`	`sse-s3 \| sse-kms \| sse-c \| cse \| none`The encryption scheme to use for data buckets that are currently being stored (data at rest). More sse-s3: Search for "Protecting Data Using Server-Side Encryption with Amazon S3-Managed Encryption Keys" on the Amazon Web Services documentation site. sse-kms: Search for "Protecting Data Using Server-Side Encryption with CMKs Stored in AWS Key Management Service (SSE-KMS)" on the Amazon Web Services documentation site. sse-c: Search for "Protecting Data Using Server-Side Encryption with Customer-Provided Encryption Keys (SSE-C)" on the Amazon Web Services documentation site. cse: Search for "SmartStore client-side encryption" on the Splunk Enterprise documentation site, and "Protecting Data Using Server-Side Encryption with Customer-Provided Encryption Keys (SSE-C)" on the Amazon Web Services documentation site. Optional.	none
`remote.s3.encryption.sse-c.key_type`	`kms`Determines the mechanism Splunk uses to generate the key for sending over to S3 for SSE-C. More The only valid value is 'kms', indicating Amazon Web Services Key Management Service (AWS KMS). One must specify required KMS settings: e.g. remote.s3.kms.key_id for Splunk to start up while using SSE-C. Optional.	kms
`remote.s3.encryption.sse-c.key_refresh_interval`	`<unsigned integer>`Specifies period in seconds at which a new key will be generated and used for encrypting any new data being uploaded to S3. More Optional.	86400
`remote.s3.encryption.cse.algorithm`	`aes-256-gcm`Currently not supported. This setting is related to a feature that is still under development. More The encryption algorithm to use for bucket encryption while client-side encryption is enabled. Optional.	aes-256-gcm
`remote.s3.encryption.cse.key_type`	`kms`Currently not supported. This setting is related to a feature that is still under development. More The mechanism that the Splunk platform uses to generate the key for client-side encryption. The only valid value is 'kms', indicating AWS KMS service. You must specify the required KMS settings, for example, 'remote.s3.kms.key_id' for the Splunk platform to start with client-side encryption active. Optional.	kms
`remote.s3.encryption.cse.key_refresh_interval`	`<unsigned integer>`Currently not supported. This setting is related to a feature that is still under development. More The interval, in seconds, at which the Splunk platform generates a new key and uses it to encrypt any data that it uploads to S3 when client-side encryption is active. Optional.	86400
`remote.s3.encryption.cse.tmp_dir`	`<path>`Currently not supported. This setting is related to a feature that is still under development. More The full path to the directory where the Splunk platform temporarily stores encrypted files. Optional.	$SPLUNK_HOME/var/run/splunk/cse-tmp
`remote.s3.kms.endpoint`	`<string>`Indicates the host name to use when server-side or client-side encryption is enabled e.g. https://internal-kms.mycompany.com:8443 More If not set, SmartStore uses 'remote.s3.kms.auth_region' to determine the endpoint. Optional.	No default
`remote.s3.kms.key_id`	`<string>`Required if remote.s3.encryption = sse-c \| sse-kms \| cse More Specifies the identifier for Customer Master Key (CMK) on KMS. It can be the unique key ID or the Amazon Resource Name (ARN) of the CMK or the alias name or ARN of an alias that refers to the CMK. Examples: Unique key ID: 1234abcd-12ab-34cd-56ef-1234567890ab CMK ARN: arn:aws:kms:us-east-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab Alias name: alias/ExampleAlias Alias ARN: arn:aws:kms:us-east-2:111122223333:alias/ExampleAlias	No default
`remote.s3.kms.access_key`	`<string>`Similar to 'remote.s3.access_key'. More If not specified, KMS access uses 'remote.s3.access_key'. Optional.	No default
`remote.s3.kms.secret_key`	`<string>`Similar to 'remote.s3.secret_key'. More If not specified, KMS access uses 'remote.s3.secret_key'. Optional.	No default
`remote.s3.kms.auth_region`	`<string>`Required if 'remote.s3.auth_region' is unset and Splunk can not automatically extract this information. More Similar to 'remote.s3.auth_region'. If not specified, KMS access uses 'remote.s3.auth_region'.	No default
`remote.s3.kms.max_concurrent_requests`	`<unsigned integer>`Optional. More Limits maximum concurrent requests to KMS from this Splunk instance. NOTE: Can severely affect search performance if set to very low value.	10
`remote.s3.kms.<ssl_settings>`	`<...>`Optional. More Check the descriptions of the SSL settings for remote.s3.<ssl_settings> above. e.g. remote.s3.sslVerifyServerCert. Valid ssl_settings are sslVerifyServerCert, sslVersions, sslRootCAPath, sslAltNameToCheck, sslCommonNameToCheck, cipherSuite, ecdhCurves, and dhFile. All of these settings are optional. All of these settings have the same defaults as 'remote.s3.<ssl_settings>'.
`remote.s3.max_batchremove_batch_size`	`<unsigned integer>`Specifies the maximum number of remote objects that can be included in a single batch removal request for AWS S3. More Setting this value to 0 or 1 disables the batch removal feature. The highest permissible value is 1000. If set to a value greater than 1000, it will default to 1000.	1
`remote.s3.max_download_batch_size`	`<unsigned integer>`The maximum number of objects that can be downloaded in a single batch from remote storage. If the number of objects to be downloaded exceeds this value, the indexer downloads the objects in multiple batches.	50
`remote.s3.use_sdk`	`true\|false\|auto`Currently not supported. This setting is related to a feature that is still under development. More Specifies whether to use the AWS C++ SDK or make direct HTTP requests to the S3 or S3-compatible storage endpoint. If auto is specified, the SDK will be used if the storage provider is S3 and HTTP requests will be used if the storage provider is not S3, but is S3-compatible.	false
`remote.s3.data_integrity_validation`	`disabled \| sha256`Specifies the signature algorithm that SmartStore uses to generate file signatures in buckets. SmartStore uses file signatures to test the data integrity of buckets. More A value of "disabled" means that SmartStore ignores existing file signatures in buckets. A value of "sha256" means SmartStore uses the SHA-256 encryption algorithm to generate signatures. This setting is optional.	disabled
`federated.provider`	`<provider_name>`Identifies the federated provider on which this search is run. More Select the stanza for the federated provider defined in the federated.conf file.	""
`federated.dataset`	`<string>`Identifies the dataset located on the federated providers. More The dataset takes a format of <prefix>:<remote_name>. If the 'federated.provider' is a "splunk" type provider: <prefix> can be "index", "metricindex", "datamodel", "lastjob", or "savedsearch". <remote_name> is the name of an index, metric index, data model, load job or saved search, depending on the <prefix> value. The dataset must be defined on the remote search head. A saved search name can be provided as the <remote_name> for both the savedsearch and lastjob <prefix> options. If the 'federated.provider' is an "aws_s3" type provider: <prefix> must be "aws_glue_table". <remote_name> is the name of an AWS Glue Data Catalog table that is used as a dataset schema. The AWS Glue Data Catalog table contains metadata that represents data in an Amazon S3 data store. This table is in your AWS Glue Data Catalog if you have set up a dataset with AWS Glue. You use the 'sdselect' command to run federated searches against the AWS Glue Data Catalog table. Provide "aws_glue_table" as <prefix> only if the 'federated.provider' has non-empty 'database' and 'aws_glue_tables_allowlist' settings. If the 'federated.provider' is an "aws_lake" type provider: <prefix> can be "aws_glue_table" or "aws_glue_unified". If <prefix> is "aws_glue_table", refer to the section above. If <prefix> is "aws_glue_unified", <remote_name> is a comma-delimited list of AWS Glue Data Catalog tables that are associated with the federated provider. Alternatively, <remote_name> can just use a wildcard character (*) to specify all AWS Glue Data Catalog tables that are associated with the federated provider. If <prefix> is not defined, <prefix> defaults to 'index'.	No default

Google Cloud Storage settings

Setting	Description	Default
`remote.gs.credential_file`	`<credentials.json>`Name of the json file with GCS credentials. More For standalone indexers, this file must be located in the $SPLUNK_HOME/etc/auth directory. For indexer clusters, this file must be located either in the _cluster/local directory of the distributed bundle or the $SPLUNK_HOME/etc/auth directory. The distributed bundle location has precedence. You must set either this setting or 'service_account_email' to use custom credentials. The indexer tries different ways of providing credentials in the following order: 1. This setting, for the json credential file, is used if it is set. 2. The 'service_account_email' setting is used if it is set. 3. The credential for the Compute Engine's default service_account is used. The last two methods both require that the indexer is running on GCP. The specified file is encrypted on startup. Optional if the indexer is running on GCP. Required if the indexer is not running on GCP.	Not set.
`remote.gs.service_account_email`	`<email-address>`Credential of the specified custom service_account is used. More This service_account must be associated with every Compute Engine instance used with SmartStore-enabled indexer cluster. This setting uses GCP metadata server to get the credential. It requires the indexer to be running on GCP. This setting is used only if the 'credential_file' setting is unset. For more information, see the entry for the 'credential_file' setting. Optional	Not set.
`remote.gs.project_id`	`<string>`The ID of the GCP project associated with the volume. More The project ID is a unique string across Google Cloud. It can found in GCP console. Required if 'remote.gs.encryption' is set to gcp-sse-c or gcp-sse-kms. Must be left unset if 'remote.gs.encryption' is set to gcp-sse-gcp.	Not set.
`remote.gs.upload_chunk_size`	`<unsigned integer>`Specifies the maximum size, in bytes, for file chunks in a parallel upload. More A value of 0 disables uploading in multiple chunks. Files are uploaded as a single (large) chunk. Minimum value: 5242880 (5 MB)	33554432 (32MB)
`remote.gs.download_chunk_size`	`<unsigned integer>`Specifies the maximum size for file chunks in a parallel download. More Specify as bytes Minimum value: 5242880 (5 MB)	33554432 (32MB)
`remote.gs.max_parallel_non_upload_threads`	`<unsigned integer>`Number of threads used for parallel downloads and other async gcs operations, per index volume. More This is the total count across all such operations. This does not include parallel upload operations, which are specified with the 'max_threads_per_parallel_upload' setting. For SmartStore, this is only used for parallel download of files.	250
`remote.gs.max_threads_per_parallel_upload`	`<unsigned integer>`Number of threads used for a single parallel upload operation.	64
`remote.gs.max_connection_pool_size`	`<unsigned integer>`Size of the connection pool to the remote storage per index volume.	500
`remote.gs.max_download_batch_size`	`<unsigned integer>`The maximum number of objects that can be downloaded in a single batch from remote storage. If the number of objects to be downloaded exceeds this value, the indexer downloads the objects in multiple batches.	50
`remote.gs.remove_all_versions`	`<boolean>`If true, a remove operation on an object explicitly deletes all versions of that object.	true
`remote.gs.use_delimiter`	`<boolean>`Specifies whether a delimiter (currently "guidSplunk") should be used to list the objects that are present on the remote storage. More A delimiter groups objects that have the same delimiter value so that the listing process can be more efficient as it does not need to report similar objects. Optional.	true
`remote.gs.retry_policy`	`max_count`Sets the retry policy to use for remote file operations. More A retry policy specifies whether and how to retry file operations that fail for those failures that might be intermittent. Retry policies: + "max_count": Imposes a maximum number of times an operation will be retried upon intermittent failure	max_count
`remote.gs.max_count.max_retries_per_part`	`<unsigned integer>`When the remote.gs.retry_policy setting is max_count, sets the maximum number of times a file operation will be retried upon intermittent failure. More The count is maintained separately for each file part in a multipart download or upload.	9
`remote.gs.backoff.initial_delay_ms`	`<unsigned integer>`If retries are enabled, an exponential backoff interval is used to perform the retries. More This setting specifies the delay for the first retry, in milliseconds.	3000 (3s)
`remote.gs.backoff.max_delay_ms`	`<unsigned integer>`If retries are enabled, an exponential backoff interval is used to perform the retries. More This setting specifies the maximum delay before the next retry, in milliseconds	60000 (60s)
`remote.gs.backoff.scaling`	`<unsigned integer>`If retries are enabled, an exponential backoff interval is used to perform the retries. More This setting specifies the amount by which subsequent delays are scaled, upto max_delay_ms.	2
`remote.gs.connectUsingIpVersion`	`auto\|4-only\|6-only`When making outbound connections to the storage service, this setting controls whether connections are made using IPv4 or IPv6. More Connections to literal IPv4 or IPv6 addresses are unaffected by this setting. "4-only" : Splunkd only attempts to connect to the IPv4 address. "6-only" : Splunkd only attempts to connect to the IPv6 address. "auto": If [general]/listenOnIPv6 in server.conf is set to "only", this defaults to "6-only" Otherwise, this defaults to "4-only"	auto
`remote.gs.sslVersionsForClient`	`tls1.0\|tls1.1\|tls1.2\|tls1.3`Defines the minimum ssl/tls version to use for outgoing connections.	tls1.2
`remote.gs.sslVerifyServerCert`	`<boolean>`If set to true, Splunkd authenticates the certificate of the services it connects to by using the configured CA.	false.
`remote.gs.sslVerifyServerName`	`<boolean>`Whether or not splunkd, as a client, performs a TLS hostname validation check on an SSL certificate that it receives upon an initial connection to a server. More A TLS hostname validation check ensures that a client communicates with the correct server, and has not been redirected to another by a machine-in-the-middle attack, where a malicious party inserts themselves between the client and the target server, and impersonates that server during the session. Specifically, the validation check forces splunkd to verify that either the Common Name or the Subject Alternate Name in the certificate that the server presents to the client matches the host name portion of the URL that the client used to connect to the server. For this setting to have any effect, the 'sslVerifyServerCert' setting must have a value of "true". If it doesn't, TLS hostname validation is not possible because certificate verification is not on. A value of "true" for this setting means that splunkd performs a TLS hostname validation check, in effect, verifying the server's name in the certificate. If that check fails, splunkd terminates the SSL handshake immediately. This terminates the connection between the client and the server. Splunkd logs this failure at the ERROR logging level. A value of "false" means that splunkd does not perform the TLS hostname validation check. If the server presents an otherwise valid certificate, the client-to-server connection proceeds normally.	false
`remote.gs.sslRootCAPath`	`<path>`Full path to the Certificate Authority (CA) certificate PEM format file containing one or more certificates concatenated together. Google Storage and related service certificates will be validated against the CAs in this file.	value of [sslConfig]/caCertFile in server.conf
`remote.gs.cipherSuite`	`<cipher suite string>`If set, uses the specified cipher string for the SSL connection. More If not set, uses the default cipher string.	value of [sslConfig]/cipherSuite in server.conf
`remote.gs.encryption`	`gcp-sse-c \| gcp-sse-kms \| gcp-sse-gcp`The encryption scheme to use for index buckets while stored on GCS (data-at-rest). More gcp-sse-c: Maps to GCP customer-supplied encryption keys. See Google Cloud documentation for details. gcp-sse-kms: Maps to GCP customer-managed encryption keys. See Google Cloud documentation for details. gcp-sse-gcp: Maps to GCP Google-managed encryption keys. See Google Cloud documentation for details. Google Cloud always encrypts the incoming data on the server side. For the gcp-sse-kms scheme, you must grant your Cloud Storage service account permission to use your Cloud KMS key. For more details, search for "Assigning a Cloud KMS key to a service account" on the Google Cloud documentation site. To find your Cloud Storage service account, search for "Getting the Cloud Storage service account".	gcp-sse-gcp
`remote.gs.encryption.gcp-sse-c.key_type`	`gcp_kms`Affects only the gcp-sse-c encryption scheme. More Determines the mechanism the indexer uses to generate the key for sending data to GCS. The only valid value is 'gcp_kms', indicating Google Cloud Key Management Service (GCP KMS). You must also specify the required KMS settings: 'remote.gs.gcp_kms.locations', 'remote.gs.gcp_kms.key_ring' and 'remote.gs.gcp_kms.key'. If you do not specify those settings, the indexer cannot start while using gcp-sse-c.	gcp_kms
`remote.gs.encryption.gcp-sse-c.key_refresh_interval`	`<unsigned integer>`Specifies the interval, in seconds, for generating a new key that is used for encrypting data uploaded to GCS.	86400
`remote.gs.gcp_kms.locations`	`<string>`Required if 'remote.gs.encryption' is set to gcp-sse-c or gcp-sse-kms. More Specifies the geographical regions where KMS key rings and keys are stored for access. Google Cloud offers three types of locations: regional ones such as "us-central1", dual-regional ones such as "nam4", and multi-regional ones such as "global" and "us". Search for "Cloud KMS locations" on the Google Cloud documentation site for a complete list. For best performance, choose a key ring and a key in the same location as the cloud stack.	none.
`remote.gs.gcp_kms.key_ring`	`<string>`Required if 'remote.gs.encryption' is set to gcp-sse-c or gcp-sse-kms. More Specifies the name of the key ring used for encryption when uploading data to GCS. In Google Cloud, a key ring is a grouping of keys for organizational purposes. A key ring belongs to a Google Cloud Project and resides in a specific location. Search for "key ring" on the Google Cloud documentation site for more details.	none.
`remote.gs.gcp_kms.key`	`<string>`Required if 'remote.gs.encryption' is set to gcp-sse-c or gcp-sse-kms. More Specifies the name of the encryption key used for uploading data to GCS.	none.
`remote.gs.data_integrity_validation`	`disabled \| sha256`Specifies the signature algorithm that SmartStore uses to generate file signatures in buckets. SmartStore uses file signatures to test the data integrity of buckets. More A value of "disabled" means that SmartStore ignores existing file signatures in buckets. A value of "sha256" means SmartStore uses the SHA-256 encryption algorithm to generate signatures. This setting is optional.	disabled

Microsoft Azure Storage settings

Setting	Description	Default
`remote.azure.use_delimiter`	`<boolean>`Specifies whether a delimiter (currently "guidSplunk") should be used to list the objects that are present on the remote storage. More A delimiter groups objects that have the same delimiter value so that the listing process can be more efficient as it does not need to report similar objects.	true
`remote.azure.sslVersions`	`tls1.0\|tls1.1\|tls1.2\|tls1.3`Specifies the minimum SSL/TLS version to use for outgoing connections.	tls1.2
`remote.azure.sslVerifyServerCert`	`<boolean>`If set to true, the indexer cache manager authenticates the certificate of the services it connects to by using the configured CA.	false.
`remote.azure.sslVerifyServerName`	`<boolean>`Whether or not splunkd, as a client, performs a TLS hostname validation check on an SSL certificate that it receives upon an initial connection to a server. More A TLS hostname validation check ensures that a client communicates with the correct server, and has not been redirected to another by a machine-in-the-middle attack, where a malicious party inserts themselves between the client and the target server, and impersonates that server during the session. Specifically, the validation check forces splunkd to verify that either the Common Name or the Subject Alternate Name in the certificate that the server presents to the client matches the host name portion of the URL that the client used to connect to the server. For this setting to have any effect, the 'sslVerifyServerCert' setting must have a value of "true". If it doesn't, TLS hostname validation is not possible because certificate verification is not on. A value of "true" for this setting means that splunkd performs a TLS hostname validation check, in effect, verifying the server's name in the certificate. If that check fails, splunkd terminates the SSL handshake immediately. This terminates the connection between the client and the server. Splunkd logs this failure at the ERROR logging level. A value of "false" means that splunkd does not perform the TLS hostname validation check. If the server presents an otherwise valid certificate, the client-to-server connection proceeds normally.	false
`remote.azure.httpKeepAlive`	`<boolean>`If set to true, All successful requests to the Microsoft Azure Storage API will keep the connection channel open to the remote storage service	true.
`remote.azure.access_key`	`<string>`Specifies the access key (storage account name) to use when authenticating with the remote storage system supporting the Microsoft Azure Storage API. More If a value is not specified for the 'remote.azure.endpoint' setting, the value of this setting is used to construct the remote storage URI. For example: "https://<remote.azure.access_key>.blob.core.windows.net"	No default
`remote.azure.secret_key`	`<string>`Specifies the secret key to use when authenticating with the remote storage system supporting the Microsoft Azure Storage API.	No default
`remote.azure.tenant_id`	`<string>`Specifies the ID of the tenant, which is an instance of an Azure AD directory. Consult your Azure subscription for details. More This setting is required only for client token and workload identity authentication. If this setting is not configured, the system checks the 'AZURE_TENANT_ID' environment variable and uses that value if set.	No default
`remote.azure.client_id`	`<string>`Specifies the ID of the client, also known as the application ID. This unique identifier is issued by Azure Active Directory to an application registration. It identifies a specific application and its associated configurations. You can obtain the client ID for an application from the Azure Portal in the Overview section for the registered application. More This setting is required only for client token and workload identity authentication. This setting is optional for managed identity authentication. If this setting is not configured, the system checks the 'AZURE_CLIENT_ID' environment variable and uses that value if set.	No default
`remote.azure.client_secret`	`<string>`Specifies the secret key to use when authenticating using the client_id. You generate the secret key through the Azure Portal. More Needed only for client token-based authentication.	No default
`remote.azure.federated_token_file`	`<path>`Specifies the full path to the service account token file. This file is used for Azure workload identity authentication in Kubernetes environments. More This setting is required only when using Azure workload identity authentication. If this setting is not configured, the system checks the 'AZURE_FEDERATED_TOKEN_FILE' environment variable and uses that value if set.	No default
`remote.azure.authority_host`	`<string>`Specifies the Azure Active Directory (AAD) endpoint URL. More This setting is not valid for managed identity authentication. This setting is optional for client token and workload identity authentication. If this setting is not configured, the system checks the 'AZURE_AUTHORITY_HOST' environment variable and uses that value if set.	No default
`remote.azure.sslRootCAPath`	`<path>`Full path to the Certificate Authority (CA) certificate PEM format file containing one or more certificates concatenated together. Microsoft Azure Storage and related service certificates will be validated against the CAs in this file.	value of [sslConfig]/caCertFile in server.conf
`remote.azure.cipherSuite`	`<cipher suite string>`If set, uses the specified cipher string for the SSL connection. More If not set, uses the default cipher string.	value of [sslConfig]/cipherSuite in server.conf
`remote.azure.encryption`	`azure-sse-kv \| azure-sse-ms \| azure-sse-c`The encryption scheme to use for containers that are currently being stored. More azure-sse-kv: Maps to Azure customer-managed keys in a key vault. See the Azure documentation for customer-managed keys for Azure Store encryption for details. azure-sse-ms: Maps to Azure Microsoft-managed keys in Microsoft key store. See the Azure documentation for Azure Storage encryption for data at rest for details. azure-sse-c: Maps to Azure customer-provided encryption keys in a Key Vault. See the Azure documentation for customer-provided keys for Azure Store encryption for details.	azure-sse-ms
`remote.azure.azure-sse-kv.encryptionScope`	`<string>`Required if remote.azure.encryption = azure-sse-kv More Specifies the key used for encrypting blobs within the scope of this index.	No default
`remote.azure.encryption.azure-sse-c.key_type`	`azure_kv`Determines the mechanism that the Splunk indexer uses to generate the key for sending data to Azure Storage. More Affects the azure-sse-c encryption scheme only. The only valid value is "azure_kv", indicating Azure Key Vault Key Management Service (Azure KMS). You must also specify the required KMS settings: 'remote.azure.azure_kv.key_name', 'remote.azure.azure_kv.key_vault_tenant_id', 'remote.azure.azure_kv.key_vault_client_id', and 'remote.azure.azure_kv.key_vault_client_secret'. If you do not specify those settings, the indexer cannot start while 'remote.azure.encryption' has a value of "azure-sse-c".	azure_kv
`remote.azure.azure_kv.endpoint`	`<string>`The URL of the Microsoft Azure Key Vault endpoint. More The value of this setting must reference an Azure Key Vault location where the keys are stored. Required if 'remote.azure.encryption = azure-sse-c'. Example: https://<key-vault-name>.vault.azure.net/	No default
`remote.azure.azure_kv.key_name`	`<string>`Specifies the Azure Key Vault Key name for key encryption and decryption. More Required if 'remote.azure.encryption' has a value of "azure-sse-c".	No default
`remote.azure.azure_kv.key_vault_tenant_id`	`<string>`Specifies the ID of the Azure Active Directory tenant for authenticating with the Key Vault. Check your Azure Active Directory subscription for details. More This setting is required only for client token and workload identity authentication. If this setting and the 'remote.azure.tenant_id' setting are not configured, the system checks the 'AZURE_TENANT_ID' environment variable and uses that value if set. You do not need to configure this setting if both of the following are true: You have configured the 'remote.azure.tenant_id' setting to the same value. The Active Directory is provisioned for Key Vault Cryptography operations.	the value of the 'remote.azure.tenant_id' setting.
`remote.azure.azure_kv.key_vault_client_id`	`<string>`Specifies the ID of the client, also known as the application ID. This unique identifier is issued by Azure Active Directory to an application registration. It identifies a specific application and its associated configurations. You can obtain the client ID for an application from the Azure Portal in the Overview section for the registered application. More This setting is required only for client token and workload identity authentication. This setting is optional for managed identity authentication. If this setting and the 'remote.azure.client_id' setting are not configured, the system checks the 'AZURE_CLIENT_ID' environment variable and uses that value if set. You do not need to configure this setting if both of the following are true: You have configured the 'remote.azure.client_id' setting to the same value. The Active Directory is provisioned for Key Vault Cryptography operations.	the value of the 'remote.azure.client_id' setting.
`remote.azure.azure_kv.federated_token_file`	`<path>`Specifies the full path to the service account token file. This file is used for Azure workload identity authentication in Kubernetes environments. More This setting is required only when using Azure workload identity authentication. If this setting and the 'remote.azure.federated_token_file' setting are not configured, the system checks the 'AZURE_FEDERATED_TOKEN_FILE' environment variable and uses that value if set. You do not need to configure this setting if both of the following are true: You have configured the 'remote.azure.federated_token_file' setting to the same value. The Active Directory is provisioned for Key Vault Cryptography operations.	the value of the 'remote.azure.federated_token_file' setting.
`remote.azure.azure_kv.authority_host`	`<url>`Specifies the Azure Active Directory (AAD) endpoint URL. More This setting is not valid for managed identity authentication. This setting is optional for client token and workload identity authentication. If this setting and the 'remote.azure.authority_host' setting are not configured, the system checks the 'AZURE_AUTHORITY_HOST' environment variable and uses that value if set. You do not need to configure this setting if both of the following are true: You have configured the 'remote.azure.authority_host' setting to the same value. The Active Directory is provisioned for Key Vault Cryptography operations.	the value of the 'remote.azure.authority_host' setting.
`remote.azure.azure_kv.key_vault_client_secret`	`<string>`Specifies the secret key to use when authenticating the Key Vault using the client_id. You generate the secret key through the Azure Portal. More Required only for client token-based authentication. You do not need to configure this setting if both of the following are true: You have configured the 'remote.azure.client_secret' setting to the same value. The Active Directory is provisioned for Key Vault Cryptography operations.	the value of the 'remote.azure.client_secret' setting.
`remote.azure.supports_versioning`	`<boolean>`Specifies whether the remote storage supports versioning. More Versioning is a means of keeping multiple variants of an object in the same bucket on the remote storage. This setting determines how the indexer cache manager removes data from remote storage. If set to false, the indexer cache manager will delete all versions of objects at time of data removal. Otherwise, if set to false, the indexer cache manager will use a simple DELETE. For more information on Azure versioning, see the Microsoft Azure documentation.	true
`remote.azure.endpoint`	`<URL>`The URL of the Microsoft Azure Storage endpoint supporting the Azure REST API. More The scheme, http or https, can be used to enable or disable SSL connectivity with the endpoint. The value of this setting must point to an Azure Blob storage location, not a container name. the container name should not be specified here but given seperately in either 'remote.azure.container_name' or as part of 'path' Example: https://<account-name>.blob.core.windows.net/
`remote.azure.container_name`	`<string>`Specifies the Azure container to use complying with Microsoft Azure Storage Container naming convention.
`remote.azure.upload.chunk_size`	`<unsigned integer>`Specifies the maximum size for file chunks in a parallel upload. More Specify as bytes	78643200 (75MB)
`remote.azure.upload.concurrency`	`<unsigned integer>`Specifies the number of threads used for a single parallel upload operation.	5
`remote.azure.download.chunk_size`	`<unsigned integer>`Specifies the maximum size for file chunks in a parallel download. More Specify as bytes	78643200 (75MB)
`remote.azure.download.concurrency`	`<unsigned integer>`Specifies the number of threads used for a single parallel download operation.	5
`remote.azure.max_download_batch_size`	`<unsigned integer>`The maximum number of objects that can be downloaded in a single batch from remote storage. If the number of objects to be downloaded exceeds this value, the indexer downloads the objects in multiple batches.	50
`remote.azure.max_listing_page_size`	`<unsigned integer>`The maximum number of blobs returned in a single list query operation.	1000
`remote.azure.retry_policy`	`max_count`Sets the retry policy to use for remote file operations. More A retry policy specifies whether and how to retry file operations that fail for those failures that might be intermittent. Retry policies: + "max_count": Imposes a maximum number of times an operation will be retried upon intermittent failure	max_count
`remote.azure.max_count.max_retries_in_total`	`<unsigned integer>`When the remote.azure.retry_policy setting is max_count, sets the maximum number of times a file operation will be retried upon intermittent failure. More The count is maintained for each file as a whole. Optional.	3
`remote.azure.backoff.initial_delay_ms`	`<unsigned integer>`If retries are enabled, a backoff interval is used to perform the retries. This interval is doubled on each retry up to the limit set in remote.azure.backoff.max_retry_delay_ms. More This setting specifies the delay between each retry, in milliseconds.	4000 (4s)
`remote.azure.backoff.max_retry_delay_ms`	`<unsigned integer>`If retries are enabled, a backoff interval is used to perform the retries. More This setting specifies the maximum delay before the next retry, in milliseconds	2 * 60 * 1000 (120s)
`remote.azure.data_integrity_validation`	`disabled \| sha256`Specifies the signature algorithm that SmartStore uses to generate file signatures in buckets. SmartStore uses file signatures to test the data integrity of buckets. More A value of "disabled" means that SmartStore ignores existing file signatures in buckets. A value of "sha256" means SmartStore uses the SHA-256 encryption algorithm to generate signatures. This setting is optional.	disabled
`remote.azure.tsidx_compression`	`<boolean>`DEPRECATED; use 'remote.azure.compression' instead. If both 'remote.azure.tsidx_compression' and 'remote.azure.compression' are specified, 'remote.azure.compression' takes precedence. More Whether the indexer compresses tsidx files before it uploads them to Azure. A value of "true" means the indexer compresses tsidx files before it uploads them to Azure. Confirm that every indexer runs Splunk Enterprise version 9.3.0 or higher before you turn on tsidx file compression for Azure. This setting is not backward compatible. When you activate it, you cannot downgrade your Splunk platform deployment to versions earlier than 9.3.0.	false
`remote.azure.compression`	`<boolean>`Whether or not the indexer compresses files before it uploads them to Azure. More A value of "true" means the indexer compresses files before it uploads them to Azure. Ensure that all indexers run Splunk Enterprise version 9.4.0 or higher before you enable this feature. This feature is not backward compatible. After you activate it, you cannot downgrade Splunk Enterprise to versions below 9.4.0.	false
`remote.azure.compression_extension_list`	`<comma-separated list>`A list of extensions of the files to be compressed when 'remote.azure.compression' has a value of "true".	tsidx

Example

[volume:hot1]
path = /mnt/fast_disk
maxVolumeDataSizeMB = 100000

[volume:cold1]
path = /mnt/big_disk

[idx1]
homePath = volume:hot1/idx1
coldPath = volume:cold1/idx1
thawedPath = $SPLUNK_DB/idx1/thaweddb

[idx4]
datatype = metric
homePath = volume:hot1/idx4
coldPath = volume:cold1/idx4
thawedPath = $SPLUNK_DB/idx4/thaweddb
metric.maxHotBuckets = 6
metric.splitByIndexKeys = metric_name

[volume:s3]
storageType = remote
path = s3://remote_volume
remote.s3.bucket_name = example-s3-bucket
remote.s3.access_key = S3_ACCESS_KEY
remote.s3.secret_key = S3_SECRET_KEY

[i4]
remotePath = volume:s3/$_index_name
coldPath = $SPLUNK_DB/$_index_name/colddb
homePath = $SPLUNK_DB/$_index_name/db
thawedPath = $SPLUNK_DB/$_index_name/thaweddb

A hot volume capped at 100GB and an uncapped cold volume backing a shared event index, a sibling metric index splitting hot buckets by metric_name, and a fourth index whose buckets live entirely on a capacity-decoupled S3-backed remote volume.

Validation

Set an archive destination (coldToFrozenDir or coldToFrozenScript) deliberately before relying on frozenTimePeriodInSecs alone -- the default freeze policy is permanent deletion.
Use volume: references for homePath/coldPath rather than raw environment-variable-laden paths (aside from $SPLUNK_DB) -- the spec explicitly warns that ad hoc environment variables in index paths risk unsearchable data, write failures, and disk exhaustion across restarts.
Prefer maxDataSize = auto/auto_high_volume over a hand-tuned byte value unless you have a specific, well-understood reason and Splunk Support's input.
Never set disabled=true, adjust maxWarmDBCount/maxTotalDataSizeMB/homePath.maxDataSizeMB/coldPath.maxDataSizeMB, or otherwise treat as effective the settings the spec marks "ignored on remote storage enabled indexes" -- confirm which regime (local vs. SmartStore) an index is in before tuning it.
Leave advanced/support-only settings (memPoolMB, indexThreads, bucketRebuildMemoryHint, tsidxDedupPostingsListMaxTermsLimit, metadata auto-tune toggles, and similar) at their defaults unless Splunk Support directs otherwise -- the spec repeatedly flags these as capable of destabilizing an installation.
Confirm which settings require a full splunkd restart (most path and bucket-lifecycle settings) versus a config reload -- applying a change and assuming it's live without restarting is a common misconfiguration.

← Back to References

References / Splunk platform configuration

Instance Configuration

instance.cfg holds a single per-instance identity setting -- the instance's GUID -- written to $SPLUNK_HOME/etc/instance.cfg once at first startup. The spec is explicit that this file is not to be modified or removed by a user. Backs the Splunk Taxonomy's Instance Configuration object (SOT-11.05.05).

Definition

A single [general] stanza with one setting. Unlike almost every other Splunk conf file, instance.cfg is not layered across system/local, apps, or users -- it lives at a fixed path and is generated/managed by splunkd itself.

File locations

Configuration file: instance.cfg.

Scope	Path
Singleton	`$SPLUNK_HOME/etc/instance.cfg`

One file, full stop -- no default/local split, no app or user scope. Not meant to be hand-edited; splunk clone-prep-clear-config clears it for cloned installs.

Settings

Setting	Description
`guid`	An all-uppercase GUID (`[0-9A-F]{8}-[0-9A-F]{4}-[0-9A-F]{4}-[0-9A-F]{4}-[0-9A-F]{12}`) uniquely identifying this Splunk instance -- used by clustering to identify participating nodes and by introspective searches (Splunk on Splunk, Deployment Monitor) to identify forwarders. Splunk generates this automatically; no user intervention is normally required.

At startup, splunkd reconciles any legacy guid value still present in server.conf (the setting's pre-5.0 location): if only server.conf has a value, it moves to instance.cfg; if both files have the same value, the server.conf copy is erased; if both have different values, startup halts with an error the operator must resolve manually -- typically by erasing the server.conf value and restarting. The splunk clone-prep-clear-config CLI command exists specifically to fix this class of conflict when mass-cloning Splunk installs (which otherwise duplicates the GUID across every clone).

Example

[general]
guid = B58A86D9-DF3D-4BF8-A426-DB85C231B699

The complete, typical contents of an instance's instance.cfg file -- a single generated GUID.

Validation

Never hand-edit instance.cfg -- the spec explicitly warns to leave the file alone; let splunkd manage the GUID.
When mass-cloning Splunk installs (VM templates, container images, golden AMIs), run splunk clone-prep-clear-config before first boot of each clone so every instance gets its own unique GUID, rather than inheriting a duplicate from the source image.
If startup halts on a GUID mismatch between server.conf and instance.cfg, resolve it by erasing the stale value from server.conf and restarting -- don't attempt to reconcile by editing the GUID value itself.

← Back to References

References / Splunk platform configuration

Server Configuration

server.conf holds core instance-level settings -- general instance identity, TLS for backend (non-Web) communications, and clustering/license coordination. Distinct from web.conf, which configures Splunk Web/browser-facing settings and TLS.

Definition

One stanza per subsystem -- [general], [sslConfig], [clustering], [shclustering], [license], [diskUsage], [kvstore] among others -- covering settings that apply to the Splunk instance as a whole rather than to any one input, sourcetype or knowledge object.

Settings

Every stanza and setting in server.conf.spec from Splunk Enterprise 10.4.2: 755 settings across 87 stanzas. Descriptions use the spec's own wording -- the first line shows here and More opens the rest. The Default column is filled only where the spec gives a Default: line.

`[general]`

Setting	Description	Default
`[general]` `serverName`	`<ASCII string>`The name that identifies this Splunk software instance for features such as distributed search. More Cannot be an empty string. Can contain environment variables. After any environment variables are expanded, the server name (if not an IPv6 address) can only contain letters, numbers, underscores, dots, and dashes. The server name must start with a letter, number, or an underscore.	$HOSTNAME
`[general]` `hostnameOption`	`[ fullyqualifiedname \| clustername \| shortname ]`The type of information to use to determine how splunkd sets the 'host' value for a Windows Splunk platform instance when you specify an input stanza with 'host = $decideOnStartup'. More This setting applies only to machines that run Windows, and only for input stanzas that use the "host = $decideOnStartup" setting and value. Valid values are "fullyqualifiedname", "clustername", and "shortname". The value returned for the 'host' field depends on Windows DNS, NETBIOS, and what the name of the host is. 'fullyqualifiedname' uses Windows DNS to return the fully qualified host name as the value. 'clustername' also uses Windows DNS, but sets the value to the domain and machine name. 'shortname' returns the NETBIOS name of the machine. Cannot be an empty string.	shortname
`[general]` `sessionTimeout`	`<nonnegative integer>[s\|m\|h\|d]`The amount of time before a user session times out, expressed as a search-like time range. More Examples include "24h" (24 hours), "3d" (3 days), "7200s" (7200 seconds, or two hours)	"1" (1 hour)
`[general]` `invalidateSessionTokensOnLogout`	`<boolean>`A value of "true" means the SHC invalidates any tokens associated with a logged-out session across all nodes in the cluster. More This setting has an effect only if search head clustering and App Key Value store are enabled. Splunkd on each node tries to keep the logout information in sync with other nodes in the cluster within the specified 'logoutCacheRefreshInterval'.	false
`[general]` `skipSearchSessionTokenInvalidationOnLogout`	`<boolean>`A value of "true" means the search head cluster skips KV store logout invalidation writes for search-session tokens (for example, scheduled searches). More A value of "false" means these writes are not skipped. This setting has an effect only if search head clustering, KV store, and 'invalidateSessionTokensOnLogout' are turned on.	true
`[general]` `logoutCacheRefreshInterval`	`<nonnegative integer>[s\|m\|h\|d]`This setting controls how often splunkd on a given node updates its local cache from the App Key Value store when 'invalidateSessionTokensOnLogout' is enabled. More This setting has no effect when 'invalidateSessionTokensOnLogout' is disabled. In normal scenarios, maximum time for changes to propogate across the cluster can be upto this interval, plus a few seconds; minimum can be a second or two. There is no guarantee that this sync will always happen within this time. If the system is blocked because of load or other issues like network partition, the information may not be propogated within the specified interval.	30s
`[general]` `trustedIP`	`<IP address>`Only a single IP address is allowed. More All logins from specified IP addresses are trusted. This means a password is no longer required. Only set this if you are using Single Sign-On (SSO).
`[general]` `allowRemoteLogin`	`always\|never\|requireSetPassword`Controls remote management by restricting general login. Note that this does not apply to trusted SSO logins from a trustedIP. More When set to "always", all remote login attempts are allowed. When set to "never", only local logins to splunkd are allowed. Note that this still allows remote management through Splunk Web if Splunk Web is on the same server. If set to "requireSetPassword": In the free license, remote login is disabled. In the pro license, remote login is disabled for the "admin" user if the default password of "admin" has not been changed. NOTE: As of version 7.1, Splunk software does not support the use of default passwords. The "requireSetPassword" value is deprecated and might be removed in the future.	requireSetPassword
`[general]` `tar_format`	`gnutar\|ustar`Sets the default TAR format.	gnutar
`[general]` `access_logging_for_phonehome`	`<boolean>`Enables/disables logging to the splunkd_access.log file for client phonehomes.	true (logging enabled)
`[general]` `hangup_after_phonehome`	`<boolean>`Controls whether or not the deployment server hangs up the connection after the phonehome is done. More By default, persistent HTTP 1.1 connections are used with the server to handle phonehomes. This might show higher memory usage if you have a large number of clients. If you have more than the maximum recommended concurrent TCP connection deployment clients, persistent connections can not help with the reuse of connections. Setting this setting to true helps bring down memory usage.	false (persistent connections for phonehome)
`[general]` `pass4SymmKey`	`<string>`Authenticates traffic between: More A license manager and its license peers. Members of a cluster. A deployment server (DS) and its deployment clients (DCs). When authenticating members of a cluster, clustering might override the passphrase specified in the clustering stanza. A clustering search head connecting to multiple managers might further override in the [clustermanager:<cm-nameX>] stanza. When authenticating deployment servers and clients, by default, DS-DCs passphrase authentication is disabled. To enable DS-DCs passphrase authentication, you must also add the following line to the [broker:broker] stanza in the restmap.conf file: requireAuthentication = true In all scenarios, every node involved must set the same passphrase in the same stanzas. For example in the [general] stanza and/or [clustering] stanza. Otherwise, the respective communication does not proceed: - licensing and deployment in the case of the [general] stanza - clustering in case of the [clustering] stanza) Unencrypted passwords must not begin with "$1$". This is used by Splunk software to determine if the password is already encrypted.
`[general]` `pass4SymmKey_minLength`	`<integer>`The minimum length, in characters, that a 'pass4SymmKey' can be for a particular stanza. More When you start the Splunk platform, if the 'pass4SymmKey' is shorter in length than what you specify with this setting, the platform warns you and advises that you change the pass4SymmKey. If you use the CLI to modify 'pass4SymmKey' to a value that is shorter than what you specify with this setting, the platform warns you and advises that you change the pass4SymKey.	12
`[general]` `unbiasLanguageForLogging`	`<boolean>`Specifies whether to replace the old language terms such as "master" and "slave" with the new terms such as "manager" and "peer"	false
`[general]` `listenOnIPv6`	`no\|yes\|only`By default, splunkd listens for incoming connections (both REST and TCP inputs) using IPv4 only. More When you set this value to "yes", splunkd simultaneously listens for connections on both IPv4 and IPv6. To disable IPv4 entirely, set listenOnIPv6 to "only". This causes splunkd to exclusively accept connections over IPv6. You might need to change the mgmtHostPort setting in the web.conf file. Use '[::1]' instead of '127.0.0.1'. Any setting of SPLUNK_BINDIP in your environment or the splunk-launch.conf file overrides the listenOnIPv6 value. In this case splunkd listens on the exact address specified.
`[general]` `connectUsingIpVersion`	`auto\|4-first\|6-first\|4-only\|6-only`When making outbound TCP connections for forwarding event data, making distributed search requests, etc., this setting controls whether the connections are made using IPv4 or IPv6. More Connections to literal addresses are unaffected by this setting. For example, if a forwarder is configured to connect to "10.1.2.3" the connection is made over IPv4, regardless of what the value of this setting is. A value of "auto" means the following: If 'listenOnIPv6' is set to "no", the Splunk server follows the "4-only" behavior. If 'listenOnIPv6' is set to "yes", the Splunk server follows "6-first" If 'listenOnIPv6' is set to "only", the Splunk server follow "6-only" behavior. A value of "4-first" means, if a host is available over both IPv4 and IPv6, then the Splunk server connects over IPv4 first and falls back to IPv6 if the IPv4 connection fails. A value of "6-first" means splunkd tries IPv6 first and falls back to IPv4 on failure. A value of "4-only" means splunkd only attempts to make connections over IPv4. A value of "6-only" means splunkd only attempts to connect to the IPv6 address.	auto (the Splunk server selects a reasonable value based on the listenOnIPv6 setting.)
`[general]` `guid`	`<globally unique identifier for this instance>`This setting (as of version 5.0) belongs in the [general] stanza of SPLUNK_HOME/etc/instance.cfg file. See the .spec file of instance.cfg for more information.
`[general]` `useHTTPServerCompression`	`<boolean>`Specifies whether the splunkd HTTP server should support gzip content encoding. For more info on how content encoding works, see Section 14.3 of Request for Comments: 2616 (RFC2616) on the World Wide Web Consortium (W3C) website.	true
`[general]` `defaultHTTPServerCompressionLevel`	`<integer>`If the useHTTPServerCompression setting is enabled (it is enabled by default), this setting controls the compression level that the Splunk server attempts to use. More This number must be between 1 and 9. Higher numbers produce smaller compressed results but require more CPU usage.	6 (This is appropriate for most environments)
`[general]` `skipHTTPCompressionAcl`	`<comma- or space-separated list>`Lists a set of networks or addresses to skip data compression. These are addresses that are considered so close that network speed is never an issue, so any CPU time spent compressing a response is wasteful. More Note that the server might still respond with compressed data if it already has a compressed version of the data available. These rules are separated by commas or spaces. The accepted formats for network and address rules are: 1. A single IPv4 or IPv6 address (examples: "192.0.2.3", "2001:db8::2:1") 2. A Classless Inter-Domain Routing (CIDR) block of addresses (examples: "192.0.2/24", "2001:DB8::/32") 3. A DNS name. Use "" as a wildcard. (examples: "myhost.example.com", ".example.org") 4. The wildcard "*" matches anything. Entries can also be prefixed with '!' to negate their meaning.	localhost addresses
`[general]` `legacyCiphers`	`decryptOnly\|disabled`This setting controls how Splunk software handles support for legacy encryption ciphers. More If set to "decryptOnly", Splunk software supports decryption of configurations that have been encrypted with legacy ciphers. It encrypts all new configurations with newer and stronger cyphers. If set to "disabled", Splunk software neither encrypts nor decrypts configurations that have been encrypted with legacy ciphers.	decryptOnly
`[general]` `site`	`<string>`Specifies the site that this Splunk instance belongs to when multisite is enabled. More Valid values for site-id include site0 to site63 The special value "site0" can be set only on search heads or on forwarders that are participating in indexer discovery. For a search head, "site0" disables search affinity. For a forwarder participating in indexer discovery, "site0" causes the forwarder to send data to all peer nodes across all sites.
`[general]` `useHTTPClientCompression`	`true\|false\|on-http\|on-https`Specifies whether gzip compression should be supported when splunkd acts as a client (including distributed searches). Note: For the content to be compressed, the HTTP server that the client is connecting to should also support compression. More If the connection is being made over https and "useClientSSLCompression=true", then setting "useHTTPClientCompression=true" results in double compression work without much compression gain. To mitigate this, set this value to "on-http" (or to "true", and 'useClientSSLCompression' to "false").	true
`[general]` `embedSecret`	`<string>`When using report embedding, normally the generated URLs can only be used on the search head that they were generated on. More If "embedSecret" is set, then the token in the URL is encrypted with this key. Then other search heads with the exact same setting can also use the same URL. This is needed if you want to use report embedding across multiple nodes on a search head pool.
`[general]` `parallelIngestionPipelines`	`<integer>`The number of discrete data ingestion pipeline sets to create for this instance. More A pipeline set handles the processing of data, from receiving streams of events through event processing and writing the events to disk. An indexer that operates multiple pipeline sets can achieve improved performance with data parsing and disk writing, at the cost of additional CPU cores. For most installations, the default setting of "1" is optimal. Use caution when changing this setting. Increasing the CPU usage for data ingestion reduces available CPU cores for other tasks like searching. If the data source is streamed over TCP or UDP, such as syslog sources, only one pipeline will be used. NOTE: Enabling multiple ingestion pipelines can change the behavior of some settings in other configuration files. Each ingestion pipeline enforces the limits of the following settings independently: 1. maxKBps (in the limits.conf file) 2. max_fd (in the limits.conf file) 3. maxHotBuckets (in the indexes.conf file) 4. maxHotSpanSecs (in the indexes.conf file)	1
`[general]` `pipelineSetAutoScale`	`<boolean>`Whether or not splunkd automatically scales up the number of pipeline sets in certain cases when CPU resources are available. More A value of "true" means splunkd automatically scales up pipeline sets using the "blocked_queue_count" pipeline set selection policy. See the 'pipelineSetSelectionPolicy' setting for more information on the "blocked_queue_count" policy. A value of "true" also means that intermediate forwarders scale the number of pipeline sets to half the number of available virtual CPUs. If a workload management pool exists, then: Splunk instance scales up the number of pipeline sets to the number of virtual CPUs for the 'ingest' workload pool divided by 4. If a workload management pool does not exist, then: Splunk instance types scale up the number of pipeline sets to the number of available virtual CPUs divided by 15. A value of "false" means that splunkd uses the value for 'parallelIngestionPipelines' and does not scale the number of pipeline sets to meet demand. If 'parallelIngestionPipelines' has a higher value than the previously-described automatic calculations, then splunkd uses that value instead to scale up the number of pipeline sets.	false
`[general]` `pipelineSetSelectionPolicy`	`round_robin\|weighted_random\|blocked_queue_count`Specifies the pipeline set selection policy to use while selecting pipeline sets for new inputs. More A value of "round_robin" means that splunkd assigns incoming inputs to pipeline sets in around robin fashion. A value of "weighted_random" means that splunkd assigns the incoming inputs to pipeline sets using a weighted random scheme designed to even out the CPU usage of each pipeline set. The "weighted_random" value is valid only when 'parallelIngestionPipelines' has a value that is greater than 1. A value of "blocked_queue_count" means that splunkd assigns the incoming inputs to pipeline sets using a combination of a round-robin scheme for each input type and a blocked queue count scheme that tracks the number of blocked queues in each pipeline set. There are 5 input types in general: modular input, file input, network input, replication, and others. If the pipeline set that splunkd selects has a blocked queue count, then splunkd selects another pipeline set with the lowest blocked queue count and assigns the input to that pipeline set. This ensures that a particular input type is balanced across all available pipeline sets. Splunkd writes a "blocked queue count (blocked_count)" message to the metrics.log log file regardless of the value of this setting. The "blocked_queue_count" value is valid only when 'parallelIngestionPipelines' has a value that is greater than 1.	round_robin
`[general]` `pipelineSetWeightsUpdatePeriod`	`<integer>`The interval, in seconds, when pipeline set weights are recalculated for the weighted_random pipeline set selection policy. More Reducing this interval causes pipeline set weights to be re-evaluated more frequently, thereby enabling the system to react more quickly to changes in dutycycle estimation. Increasing this interval causes pipeline set weights to be re-evaluated less frequently, thereby reducing the likelihood of the system responding to bursty events.	30
`[general]` `pipelineSetNumTrackingPeriods`	`<integer>`The number of look-back periods, of interval pipelineSetWeightsUpdatePeriod, that are used to keep track of incoming ingestion requests for pipeline sets. More This information is used as a heuristic to calculate the pipeline set weights at every expiry of pipelineSetWeightsUpdatePeriod.	5
`[general]` `pipelineSetChannelSetCacheSize`	`<integer>`Maximum number of inactive channels to be stored in the per-pipeline set cache to reduce load in the configuration management system. More Currently only affects ingestion via the HTTP Event Collector. Increasing this setting should reduce the number of created channels reported in metrics.log under the 'channel_cache' group. If neither that group nor the 'created' field exists in metrics.log, increasing this value has no effect.	12
`[general]` `instanceType`	`<string>`Should not be modified by users. More Informs components (such as the Splunk Web Manager section) which environment the Splunk server is running in, to allow for more customized behaviors.	download
`[general]` `requireBootPassphrase`	`<boolean>`Prompt the user for a boot passphrase when starting splunkd. More Splunkd uses this passphrase to grant itself access to platform-provided secret storage facilities, like the GNOME keyring. For more information about secret storage, see the [secrets] stanza in $SPLUNK_HOME/etc/system/README/authentication.conf.spec.	true (if Common Criteria mode is enabled); false (if Common Criteria mode is disabled)
`[general]` `numThreadsForIndexInitExecutor`	`<positive integer>`Number of threads that can be used by the index init thread pool. More Maximum accepted value for this setting is 32.	16
`[general]` `remoteStorageRecreateIndexesInStandalone`	`<boolean>`Controls re-creation of remote storage enabled indexes in standalone mode.	true
`[general]` `cleanRemoteStorageByDefault`	`<boolean>`Allows 'splunk clean eventdata' to clean the remote indexes when set to true.	false
`[general]` `is_remote_queue_accounting_batched`	`<boolean>`Allows indexer to maintain a batched count of events that have been uploaded to remote storage when set to true. More This count is subsequently used to delete corresponding messages from remote queue.	false
`[general]` `recreate_index_fetch_bucket_batch_size`	`<positive integer>`Controls the maximum number of bucket IDs to fetch from remote storage as part of a single transaction for a remote storage enabled index. More Only valid for standalone mode.	500
`[general]` `recreate_bucket_fetch_manifest_batch_size`	`<positive integer>`Controls the maximum number of bucket manifests to fetch in parallel from remote storage. More Only valid for standalone mode.	100
`[general]` `splunkd_stop_timeout`	`<positive integer>`The maximum time, in seconds, that splunkd waits for a graceful shutdown to complete before splunkd forces a stop.	360 (6 minutes)
`[general]` `decommission_search_jobs_wait_secs`	`<unsigned integer>`The maximum time, in seconds, that splunkd waits for running searches to complete during a shutdown_decommission_search. More To trigger this type of shutdown, post to 'services/server/control/shutdown_decommission_search' If set to 0, splunkd does not wait, and all searches in progress will fail. If this search head is a member of a search head cluster, use 'decommission_search_jobs_wait_secs' in the [shclustering] stanza instead. NOTE: If this search head is a node of an indexer cluster, use 'decommission_search_jobs_wait_secs' in the [clustering] stanza instead.	0
`[general]` `decommission_search_jobs_min_wait_ratio`	`<decimal>`Fraction of the decommission_search_jobs_wait_secs that splunkd will always wait during a shutdown_decommission_search. More This wait is not contingent on whether or not there are any actively running searches Once this minimum wait time has elapsed, splunkd will wait the remainder of decommission_search_jobs_wait_secs contingent on the presence of actively running search processes on this indexer.	0.15
`[general]` `python.version`	`python3\|python3.9\|force_python3\|unspecified`DEPRECATED. Use 'python.required' in individual configuration files to specify supported Python versions for specific scripts. More For Python scripts only, sets the default Python version to use. A value of either "python3" or "python3.9" means the system uses Python 3.9. Can be overridden by other 'python.version' values elsewhere, with the following exception: A value of "force_python3" means the system always uses Python 3.9, and ignores values for 'python.version' that you set elsewhere. A value of "unspecified” means the system calls the Python interpreter 'python'. to run scripts. Used on universal forwarders when calling an external instance of python. This setting value is not supported.	force_python3
`[general]` `python.not_compatible`	`<comma-separated list>`The list of features that are not compatible with the default version of Python. More The previously-supported value "openssl3.0" is no longer supported. Currently, there are no supported values for this setting. The setting remains for future compatibility purposes.	<empty>
`[general]` `roll_and_wait_for_uploads_at_shutdown_secs`	`<non-negative integer>`Currently not supported. This setting is related to a feature that is still under development.	0 (disabled)
`[general]` `preShutdownCleanup`	`<boolean>`Currently not supported. This setting is related to a feature that is still under development. More Specifies if indexer waits to complete any indexing activities before continuing with shutdown.	true
`[general]` `reset_manifests_on_startup`	`<boolean>`Whether or not the Splunk platform instance regenerates size retention information for index bucket summaries that have been stored in the manifest.csv files. More Configuring this setting lets the platform instance have the most up-to-date size retention information immediately after startup. When set to true, the size retention information for summaries stored in the manifest.csv files are removed and regenerated during startup. When set to false, manifest.csv files are not reset during startup.	true
`[general]` `percent_manifests_to_reset`	`<integer>`In order to minimize the cost of resetting all manifest.csv files at once the manifest.csv files are separated in groups that are processed separately. More This percentage defines how many manifest.csv files each group will reset. For example, a setting of 20 means each group resets 20% of all manifests resulting in 5 groups with 20% each. The minimum of one manifest.csv file will be processed per group. Legal values are between 0 and 100.	10
`[general]` `regex_cache_hiwater`	`<integer>`A threshold for the number of entries in the regex cache. If the regex cache grows larger than this, splunkd server will purge some of the older entries. More When set to a negative value, no purge occurs, no matter how large the cache.	2500
`[general]` `enable_search_process_long_lifespan`	`<boolean>`Controls whether the search process can have a long lifespan. More Configuring a long lifespan on a search process can optimize performance by reducing the number of new processes that are launched and old processes that are reaped, and is a more efficient use of system resources. When set to "true": Splunk software does the following: Suppresses increases in the configuration generation. See the 'conf_generation_include' setting for more information. Avoids unnecessary replication of search configuration bundles. Allows a certain number of idle search processes to live. Sets the size of the pool of search processes. Checks memory usage before a search process is reused. When set to "false": The lifespan of a search process at the 50th percentile is approximately 30 seconds. NOTE: Do not change this setting unless instructed to do so by Splunk Support.	true
`[general]` `conf_generation_include.<conf_file_name>`	`<boolean>`Controls whether conf generation bumps at a property change in a particular type of *.conf file, mainly used on search head. More In general, do not bump when a property change needs to restart Splunk server or is not related to search execution. If set properly, Splunk server skips unnecessary generation increments to maximize reuse of preforked search processes at search head. As a result, overall search performance is improved in shorter execution time and better system resource utilization. Has no effect if 'enable_search_process_long_lifespan' is set to "false".	false
`[general]` `encrypt_fields`	`<comma-separated list>`A list of the fields that need to be re-encrypted when a search head cluster performs a first-time run on syncing all members with a new splunk.secret key, and when a bundle is created and applied in an indexer cluster. More Provide each field as a three-element entry. Separate each field element with colons, and each field with commas, for example: <conf-file>:<stanza-prefix>:<setting>, <conf-file>:<stanza-prefix>:<setting>... Do not include brackets when you specify a stanza-prefix. To match all stanzas from a configuration file, leave the stanza-prefix empty. For example: "server: :pass4SymmKey" matches all stanzas with 'pass4SymmKey' as the key in the server.conf file.	a default list of fields containing passwords, secret keys, and identifiers: "server: :sslKeysfilePassword", "server: :sslPassword", "server: :pass4SymmKey",...
`[general]` `conf_cache_memory_optimization`	`<boolean>`Turns on or off memory optimization for configuration file caches for all Splunk configuration file types. More A value of "true" turns on memory optimization for configuration files. A value of "false" turns off memory optimization for configuration files. Turning on this setting can reduce the memory footprint of the splunkd process due to caching of configurations. NOTE: Do not change this setting without first consulting with Splunk Support.	true
`[general]` `conf_cache_rebuild_stanzas_optimization`	`<boolean>`Turns on or off per stanza configuration cache rebuild for all Splunk configuration file types. More A value of "true" turns on per stanza configuration cache rebuild. Only the changed stanzas of the configuration cache are rebuilt. A value of "false" turns off per stanza configuration cache rebuild. All contents of the configuration file cache are rebuilt. Turning on this setting can reduce the read latency of a changed configuration file cache. NOTE: Do not change this setting without first consulting with Splunk Support.	true
`[general]` `cgroup_location`	`<string>`Specifies the location of the cgroup hierarchy for the splunkd, search, and helper processes within cgroups version 1 or 2. More This setting requires a Linux system with systemd. A value of "auto" turns on automatic detection, which is based on the contents of /proc/<pid>/cgroup and /proc/<pid>/mountinfo. An empty string indicates the setting is off. NOTE: Do not change this setting unless instructed to do so by Splunk Support.	auto
`[general]` `allowed_unarchive_commands`	`<comma-separated list>`A list of *nix shell commands that the 'unarchive_cmd' setting in the props.conf configuration file can run. More This setting is only applicable when 'unarchive_cmd_start_mode' has a value of "direct". NOTE: Leaving this setting with no value means that 'unarchive_cmd' can run any shell command, which is a potential security risk.	Empty string ('unarchive_cmd' can use any shell command.)

`[config_change_tracker]`

Setting	Description	Default
`[config_change_tracker]` `disabled`	`<boolean>`Whether or not splunkd writes configuration changes to the configuration change log at $SPLUNK_HOME/var/log/splunk/configuration_change.log. More If set to "false", configuration changes are captured in $SPLUNK_HOME/var/log/splunk/configuration_change.log. If set to "true", configuration changes are not captured in $SPLUNK_HOME/var/log/splunk/configuration_change.log.	false
`[config_change_tracker]` `mode`	`[auto\|diff\|track-only]`Determines the method used by 'config_change_tracker' to track and record changes to .conf files. More A value of "auto" or "diff" means splunkd logs all configuration changes made to .conf files, including changes to setting values. In this mode, config change tracking only includes changes that could have an effect on your environment. For example, if a file with a stanza and setting-value pair is created, updated, or deleted, splunkd logs the change. But if an empty file or a stanza without any setting-value pairs is added or deleted, splunkd does not log the change since it will not have an impact. Similarly, splunkd does not track any comments that are added to or removed from files. A value of "track-only" means splunkd logs .conf file changes, but excludes configuration setting values. In this mode, config change tracking includes changes whether or not they can have an effect on your environment. For example, splunkd logs a change for any updates to file content, or that come from a change by the operating system. Splunkd also sees a comment that has been added to a .conf file as a change, because that change results in a different file checksum. Splunkd tracks all .conf files under the following directories: $SPLUNK_HOME/etc/system $SPLUNK_HOME/etc/apps $SPLUNK_HOME/etc/users $SPLUNK_HOME/etc/peer-apps It also tracks changes to the following: $SPLUNK_HOME/etc/instance.cfg The values "auto" and "diff" have the same behavior at this time. Setting the value to "auto" ensures that the instance will always use the latest feature set.	auto
`[config_change_tracker]` `denylist`	`<regular expression>`If set, splunkd does not monitor files for configuration change tracker if their path matches the specified regex.	No default
`[config_change_tracker]` `log_throttling_disabled`	`<boolean>`Describes whether or not splunkd logs config changes to a .conf file that occur within the 'log_throttling_threshold_ms' time span as a single event. More A value of "false" means that splunkd logs all changes to a conf file within the time span 'log_throttling_threshold_ms' as a single event. A value of "true" means that splunkd logs all changes individually as soon as it detects them. This setting requires a Linux system with the "inotify" API for file system event monitoring. Do not change this setting without first consulting with Splunk Support.	true
`[config_change_tracker]` `log_throttling_threshold_ms`	`<positive integer>`The span of time, in milliseconds, during which splunkd logs multiple changes to a .conf file as a single configuration change event. More If multiple changes are made to a conf file within the time span 'log_throttling_threshold_ms' milliseconds, splunkd logs those changes as a single event.	10000
`[config_change_tracker]` `exclude_fields`	`<comma-separated list>`One or more stanza keys that splunkd is to exclude when it writes information about stanza configuration changes to the configuration_change.log file. More The format for each entry is '<conf-file>:<stanza>:<key>'. Separate multiple entries with commas. To exclude all keys under a stanza, use the '<conf-file>:<stanza>:' format. <stanza> can end with a '' (asterisk). Splunkd treats this as a wildcard. If <stanza> contains a colon, enclose it in quotes. For example: 'inputs.conf:"tcp-ssl:":' This setting has no effect if 'mode' has a value of "track-only". Example: 'server.conf:general:pass4SymmKey, authentication.conf:authentication:*' NOTE: The [config_change_audit] stanza, which was previously mentioned in the Splunk version 8.2.0 documentation and configuration specification files, is now DEPRECATED.	No default

`[deployment]`

Setting	Description	Default
`[deployment]` `pass4SymmKey`	`<passphrase string>`Authenticates traffic between the deployment server (DS) and its deployment clients (DCs). More By default, DS-DCs passphrase authentication key is disabled. To enable DS-DCs passphrase authentication, you must also add the following line to the [broker:broker] stanza in the restmap.conf file: requireAuthentication = true If the key is not set in the [deployment] stanza, the key is looked for in the [general] stanza. NOTE: Unencrypted passwords must not begin with "$1$", because this is used by Splunk software to determine if the password is already encrypted.
`[deployment]` `pass4SymmKey_minLength`	`<integer>`The minimum length, in characters, that a 'pass4SymmKey' should be for a particular stanza. More When you start the Splunk platform, if the 'pass4SymmKey' is shorter in length than what you specify with this setting, the platform warns you and advises that you change the pass4SymKey. If you use the CLI to modify 'pass4SymmKey' to a value that is shorter than what you specify with this setting, the platform warns you and advises that you change the pass4SymKey.	12

`[sslConfig]`

Set TLS for communications on the Splunk platform back-end under this stanza name.
NOTE: To set TLS (for example HTTPS) for Splunk Web and the browser, use the web.conf configuration file.
Follow this stanza with any number of the following setting/value pairs.
If you do not specify an entry for each setting, the Splunk platform uses the default values.

Setting	Description	Default
`[sslConfig]` `enableSplunkdSSL`	`<boolean>`Whether or not the Splunk daemon uses TLS/SSL on the management port (default 8089) and app key value store (KV Store, default 8191) network ports. More A value of "true" means that splunkd runs TLS on the management and KV Store ports. A value of "false" means that splunkd does not run TLS on any port. NOTE: Where practical, do not run splunkd without using TLS. Distributed search often performs better when you enable TLS.	true
`[sslConfig]` `useClientSSLCompression`	`<boolean>`Whether or not HTTP client compression is turned on. More Server-side compression is turned on by default. Setting this on the client-side enables compression between server and client. Enabling this potentially gives you much faster distributed searches across multiple Splunk instances. CAUTION: There are known performance issues when TLS compression is on. Confirm that the following settings have "false" values before you configure this setting to "true" to avoid double compression: 'conf_deploy_precompress_bundles' 'precompress_cluster_bundle' 'precompress_artifacts' 'preCompressKnowledgeBundlesClassicMode' 'preCompressKnowledgeBundlesCascadeMode' 'useHTTPClientCompression'	false
`[sslConfig]` `useSplunkdClientSSLCompression`	`<boolean>`Whether or not splunkd, as an HTTP client, uses TLS compression during activities like certificate exchange, bundle replication, remote calls, and so on. More This setting is effective if, and only if, 'useClientSSLCompression' has a value of "true". A value of "true" means that splunkd, as a client, uses TLS compression when connecting to other services. A value of "false" means that splunkd does not use TLS compression. NOTE: splunkd is not involved in data transfer in distributed search, the search in a separate process is.	true
`[sslConfig]` `deprecatedTlsVersionSupport`	`<boolean>`Whether or not the Splunk platform supports the "tls1.0" and "tls1.1" TLS protocol versions. More A value of "true" means the Splunk platform supports these deprecated TLS versions. A value of "false" means the Splunk platform does not support these deprecated TLS versions.	false
`[sslConfig]` `sslVersions`	`<comma-separated list>`The list of TLS versions to support for incoming connections. More The versions available are "tls1.0", "tls1.1", "tls1.2", and "tls1.3". The special version "*" selects all supported versions. The version "tls" selects all versions tls1.0 or newer. If you prefix a version with "-", it means to exclude that version from the list. SSL versions 2 and 3 are always disabled. "-ssl2" and "-ssl3" are accepted as values in the version list, but have no effect. The default can vary. See the 'sslVersions' setting in the $SPLUNK_HOME/etc/system/default/server.conf file for the current default
`[sslConfig]` `sslVersionsForClient`	`<comma-separated list>`The list of TLS/SSL versions to support for outgoing HTTP connections from splunkd. This includes distributed search, deployment client, etc. More Configuring this setting is usually less critical than configuring the 'sslVersions' setting, since TLS/SSL always picks the highest version that both client and server support. However, you can use this setting to prohibit making connections to remote servers that only support older protocols. The syntax is the same as the 'sslVersions' setting. NOTE: For forwarder connections, there is a separate 'sslVersions' setting in the outputs.conf file. For connections to SAML servers, there is a separate 'sslVersions' setting in the authentication.conf file. The default can vary. See the 'sslVersionsForClient' setting in the $SPLUNK_HOME/etc/system/default/server.conf file for the current default
`[sslConfig]` `supportSSLV3Only`	`<boolean>`DEPRECATED. Use 'sslVersions' or 'sslVersionsForClient' instead.
`[sslConfig]` `sslVerifyServerCert`	`<boolean>`Whether or not splunkd, as a client, validates the TLS certificate that a server presents to it when it connects to a server. More This setting serves as an additional step for authenticating connections to other Splunk platform services. Multiple services can use this setting, including but not limited to distributed search and distributed deployment clients. For distributed search, the client uses this setting when it makes a search request to another search head cluster peer. For distributed deployment, the client uses this setting when it polls a deployment server. A value of "true" means that the client inspects and validates the certificate that it receives from the server upon connecting to it. This ensures that the server you are connecting to has a valid TLS/SSL certificate. The client then checks both the X.509 Common Name and Subject Alternative Name of the server in the certificate for a match. If the server does not present a certificate, or the validation check does not pass, then the client terminates the handshake between it and the server immediately, which terminates the connection. NOTE: Certificates that contain the same Common Name as a certificate authority (CA) certificate are not suitable for this validation check, even if the same CA issued the certificate. A value of "false" means that the client does not check the TLS certificate that it receives as part of the session negotiation. The client considers any valid TLS certificate as acceptable.	false
`[sslConfig]` `sslCommonNameToCheck`	`<comma-separated list>`One or more X.509 standard Common Names of the server certificate which splunkd, as a client, checks against when it connects to a server using TLS. More The Common Name (CN) is an X.509 standard field in a certificate that identifies the host name that is associated with the certificate. The CN can be a short host name or a fully qualified domain name. For example, the CN can be one of "example", "www.example.com", or "example.com". If the client cannot match the CN in the certificate that the server presents, then the client cannot authenticate the server, and terminates the session negotiation immediately. For this setting to have any affect, the 'sslVerifyServerCert' setting must have a value of "true". This setting is optional. No default (no common name checking).
`[sslConfig]` `sslCommonNameList`	`<commonName1>, <commonName2>, ...`DEPRECATED. Use the 'sslCommonNameToCheck' setting instead.
`[sslConfig]` `sslAltNameToCheck`	`<comma-separated list>`One or more Subject Alternative Names of the server certificate which splunkd, as a client, checks against when it connects to a server using TLS. More The Subject Alternative Name (SAN) is an extension to the X.509 standard that lets you specify additional host names for a TLS certificate. The SAN can be a short host name or a fully qualified domain name. If the client cannot match the SAN in the certificate that the server presents, then the client cannot authenticate the server, and terminates the session negotiation immediately. The client does not validate any names in this list against the Common Name. For this setting to have any affect, the 'sslVerifyServerCert' setting must have a value of "true". This setting is optional. No default (no alternative name checking).
`[sslConfig]` `requireClientCert`	`<boolean>`Whether or not an HTTPS client which connects to a splunkd server must possess a certificate that a certificate authority signed to complete the connection. More Multiple services can use this setting, including but not limited to distributed search and distributed deployment clients. Splunk platform indexers must use this setting to connect to other Splunk platform indexers. Deployment clients must present certificates to deployment servers before they can poll the servers for new configurations or applications. A value of "true" means that a client can connect only if it has a certificate that was signed by a certificate authority that the splunkd server trusts. A value of "false" means that there is no certificate requirement to connect to services on another Splunk platform instance.	false
`[sslConfig]` `sslVerifyServerName`	`<boolean>`Whether or not splunkd, as a client, performs a TLS hostname validation check on a TLS certificate that it receives upon an initial connection to a server. More A TLS hostname validation check ensures that a client communicates with the correct server, and has not been redirected to another by a machine-in-the-middle attack, where a malicious party inserts themselves between the client and the target server, and impersonates that server during the session. Specifically, the validation check forces splunkd to verify that either the Common Name or the Subject Alternative Name in the certificate that the server presents to the client matches the host name portion of the URL that the client used to connect to the server. For this setting to have any effect, the 'sslVerifyServerCert' setting must have a value of "true". If it doesn't, TLS hostname validation is not possible because certificate verification is not on. A value of "true" for this setting means that splunkd performs a TLS hostname validation check, in effect, verifying the server's name in the certificate. If that check fails, splunkd terminates the TLS handshake immediately. This terminates the connection between the client and the server. Splunkd logs this failure at the ERROR logging level. A value of "false" means that splunkd does not perform the TLS hostname validation check. If the server presents an otherwise valid certificate, the client-to-server connection proceeds normally.	false
`[sslConfig]` `caTrustStore`	`<[splunk],[OS]>`The type of trust store that the Splunk platform accesses to validate connections over TLS. More The Splunk platform uses this setting to load certificate authority certificates for this kind of validation. A value of "splunk" means the platform only uses the certificate authority certificates in the trust store that the 'sslRootCAPath' setting references. A value of "OS" means the platform only uses the CA certificates in the trust store that the operating system on the instance defines. Splunk provides support for OS trust store usage on the Linux and Windows operating systems. There is currently no support for loading certificate trust stores on macOS. Providing both values ("splunk,OS") means that the platform uses CA certificates within both the Splunk platform and operating system trust stores. If a duplicate certificate exists in both types of trust store, the platform prioritizes using the certificate in the Splunk platform trust store. This values for this setting are not case sensitive.	splunk
`[sslConfig]` `caTrustStorePath`	`<string>`The path to the location of the certificate authority trust store on a machine that runs a distribution of Linux. More Different Linux distributions use different locations for the CA trust store. This setting lets you configure where the Splunk platform looks for the trust store, based on the distribution of Linux you run. If 'caTrustStore' has a value of "OS", but this setting has either no value or an invalid value, then the Splunk platform does not attempt to load any certificates from the OS trust store to validate TLS, and logs an error message in the splunkd.log log file. Following are example trust store locations for popular Linux distributions: Debian/Ubuntu/Gentoo: /etc/ssl/certs/ca-certificates.crt Fedora/RHEL 6, 8, 9: /etc/pki/tls/certs/ca-bundle.crt CentOS/RHEL 7: /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem	No default
`[sslConfig]` `cipherSuite`	`<string>`A list of cipher suites for splunkd to use. More If set, Splunk uses the specified cipher string for the HTTP server. If not set, Splunk uses the default cipher string that the OpenSSL binary provides. If you want to use any Diffie-Hellman ciphers, you must use the 'dhFile' setting. The default can vary. See the 'cipherSuite' setting in the $SPLUNK_HOME/etc/system/default/server.conf file for the current default.
`[sslConfig]` `ecdhCurveName`	`<string>`DEPRECATED. Use the 'ecdhCurves' setting instead.	empty string
`[sslConfig]` `ecdhCurves`	`<comma-separated list>`A list of elliptic curves to use for the Elliptic-curve Diffie-Hellman (ECDH) key negotiation protocol. More The client sends elliptic curves as part of the Client Hello during a TLS handshake. Specify elliptic curves in the order that you prefer them. The server supports only the curves specified in the list. Splunk software only supports named curves that you specify by their short names. You can get the list of valid named curves by their short and long names by running this CLI command: $SPLUNK_HOME/bin/splunk cmd openssl ecparam -list_curves Example configuration: "ecdhCurves = prime256v1,secp384r1,secp521r1" The default can vary. See the 'ecdhCurves' setting in $SPLUNK_HOME/etc/system/default/server.conf for the current default.
`[sslConfig]` `serverCert`	`<path>`The full path to the server certificate. More The Splunk daemon auto-generates certificates when you start Splunk Enterprise the first time. Where applicable, replace the default certificate with a certificate that you either create on your own or obtain from a third party. For more information about certificates, and how to obtain, create, and install them, search the Securing Splunk Enterprise Manual for "Introduction to Securing the Splunk Platform with TLS". The certificate must be in privacy-enhanced mail (PEM) format.	$SPLUNK_HOME/etc/auth/server.pem
`[sslConfig]` `sslKeysfile`	`<string>`DEPRECATED. Use the 'serverCert' setting instead. More The location of the server certificate file, as located in the directory that the DEPRECATED 'caPath' setting references.	server.pem
`[sslConfig]` `sslPassword`	`<string>`The password for the server certificate, if you created one.	password
`[sslConfig]` `sslKeysfilePassword`	`<string>`DEPRECATED. Use the 'sslPassword' setting instead.
`[sslConfig]` `sslRootCAPath`	`<path>`The path to the certificate authority (CA), or root certificate store. More The certificate store must be a file that contains one or more CA certificates that have been concatenated together. This setting expects a value that represents a file object, not a directory object. The certificates in the certificate store file must be in privacy-enhanced mail (PEM) format. If you run Splunk Enterprise in Common Criteria mode, then you must give this setting a value. This setting is valid on Windows machines only if the 'sslRootCAPathHonoredOnWindows' has a value of "true".	No default
`[sslConfig]` `sslRootCAPathHonoredOnWindows`	`<boolean>`DEPRECATED. More Whether or not the Splunk instance respects the 'sslRootCAPath' setting on Windows machines. This setting is valid only on Windows, and only if you have set 'sslRootCAPath'. A value of "true" means that the instance respects the 'sslRootCAPath' setting on Windows machines. A value of "false" means that the instance does not respect the 'sslRootCAPath' setting on Windows machines. When the 'sslRootCAPath' setting is respected, the instance expects to find a valid PEM file with valid root certificates that are referenced by that path. If a valid file is not present, TLS communication fails.	true
`[sslConfig]` `caCertFile`	`<string>`DEPRECATED. Use the 'sslRootCAPath' setting instead. More The file name for the CA certificate file. This file must be in PEM format and contain one or more certificates concatenated together. If you have not given the 'sslRootCAPath' setting a value, then Splunk Enterprise attempts to locate a CA certificate using this setting.	cacert.pem
`[sslConfig]` `dhFile`	`<path>`The location of the Diffie-Hellman (DH) parameter file. More This file must be in PEM format. The DH group size, which determines the strength of the key that the DH key exchange process uses, must not be fewer than 2048 bits. You must specify this file to enable any Diffie-Hellman ciphers.	No default
`[sslConfig]` `caPath`	`<path>`DEPRECATED. Use absolute paths for all certificate files. More If certificate files given by other settings in this stanza are not absolute paths, then they are relative to this path.	$SPLUNK_HOME/etc/auth
`[sslConfig]` `certCreateScript`	`<script name>`The creation script for generating certificates when you start Splunk Enterprise for the first time.	No default
`[sslConfig]` `sendStrictTransportSecurityHeader`	`<boolean>`Whether or not the REST interface sends a "Strict-Transport-Security" header with all responses to requests made over TLS. More A value of "true" means the REST interface sends a "Strict-Transport- Security" header with its responses. This can help to avoid a client being tricked later by a machine-in-the-middle attack to accept a non-TLS request. However, this requires a commitment that no non-TLS web hosts ever run on this hostname on any port. For example, if Splunk Web is in its default non-TLS mode, this can prevent a web browser from connecting to it. A value of "false" means the REST interface does not send a "Strict-Transport-Security" header with its responses.	false
`[sslConfig]` `allowSslCompression`	`<boolean>`Whether or not the server lets clients negotiate compression at the TLS layer. More A value of "true" means the server lets clients negotiate TLS-layer data compression. A value of "false" means the server does not let clients negotiate TLS-layer data compression. The app key value store (KV Store) service observes and uses this setting.	true
`[sslConfig]` `allowSslRenegotiation`	`<boolean>`Whether or not the server lets clients request renegotiation of TLS connection settings. More In the TLS protocol, a client can request renegotiation of the connection settings from time to time. A value of "true" means that the server lets clients request the renegotiation of TLS connection settings. A value of "false" causes the server to reject all renegotiation attempts, which breaks the connection. This limits the amount of CPU a single TCP connection can use, but it can cause connectivity problems, especially for long-lived connections.	true
`[sslConfig]` `sslClientSessionPath`	`<path>`The path to the location where the Splunk platform stores client sessions for session re-use. More Used if 'useSslClientSessionCache' has a value of "true".	No default
`[sslConfig]` `useSslClientSessionCache`	`<boolean>`Whether or not the Splunk platform can re-use TLS client sessions. More A value of "true" means the Splunk platform stores client sessions in memory for session re-use. This reduces handshake time, latency, and computation time to improve TLS performance. A value of "false" means each TLS connection performs a full TLS handshake.	false
`[sslConfig]` `sslServerSessionTimeout`	`<integer>`The timeout, in seconds, for newly created TLS sessions. More A value of 0 means that the Splunk platform disables server-side TLS session cache. The default server-side session cache for OpenSSL is 300 seconds.	300 (5 minutes)
`[sslConfig]` `sslServerHandshakeTimeout`	`<integer>`The timeout, in seconds, for a TLS handshake to complete between an TLS client and the Splunk TLS server. More If the TLS server does not receive a "Client Hello" from the TLS client within 'sslServerHandshakeTimeout' seconds, the server terminates the connection.	60
`[sslConfig]` `certificateStatusValidationMethod`	`crl`Specifies the certificate status validation method that splunkd is to use. More Certificate status validation checks the status of a digital certificate upon its presentation during a network connection. When certificate status validation is active, it is active for any kind of Splunk platform-related network communication that uses SSL, including the Splunk Web, splunkd, and Splunk-to-Splunk (S2S) communication channels. Currently, the only acceptable value for this setting is "crl". If you do not give this setting a value of "crl", the setting, and thus certificate status validation checks, are turned off. "crl" stands for Certificate Revocation List, which is a list of digital certificates that have been revoked by the issuing Certificate Authority (CA) before their scheduled expiration date and can no longer be trusted. The default path for CRL files in a Splunk platform instance is at $SPLUNK_HOME/auth/crl. Any CRL files must reside there, and must be in privacy-enhanced mail (PEM) format. For more information on using CRLs and configuring CRL files on a Splunk platform instance, see the '[kvstore]:sslCRLPath' setting.	empty string (certificate status validation checks are off)
`[sslConfig]` `cliVerifyServerName`	`<boolean>`Whether or not the Splunk CLI must validate the host name in the splunkd server certificate that it receives when it connects to another splunkd server. More The CLI performs transport layer security server certificate validation by comparing the host name or IP address in the certificate it receives from the splunkd server to which it connects. Validation happens whether you connect to a local instance of splunkd or use the "--uri" argument to connect to a remote instance of splunkd. If the certificate doesn't contain the host name or IP address of the splunkd server it is connecting to, the connection to that server fails, and the server does not process the CLI command. When the CLI performs certificate host name validation, it uses the certificate authority certificate or certificate chain that you specify in the server.conf configuration file, at '[sslConfig]/sslRootCAPath', to verify incoming server certificates. The CLI does not perform certificate host name validation in cases where it hands off execution to a Python script. A value of "true" means that the CLI validates host names in server certificates, where applicable. When this setting is "true", you can temporarily disable validation for a particular invocation of the Splunk CLI by providing the "--no-server-name-check" argument. Use this argument to defeat host name certificate validation on local instances of splunkd. This is an alternative to adding the localhost hostname or IP address to the splunkd server certificate, which is insecure. A value of "false" means that the CLI does not validate host names in server certificates.	false

`[dataplaneSslConfig]`

Setting	Description	Default
`[dataplaneSslConfig]` `serverCertDataplane`	`<string>`The full path to the server data plane certificate. More The server data plane certificate is used by the HTTP servers within helper processes to secure communications between those processes. It is separate from the standard server certificate. Splunk helper processes run alongside the Splunk daemon and implement certain functionalities that do not exist inside the Splunk daemon. The Splunk daemon auto-generates all certificates when you start Splunk Enterprise the first time. Where applicable, replace the default certificate with a certificate that you either create on your own or obtain from a third party. Both this server data plane certificate and the server certificate referenced by the 'serverCert' setting must use the same certificate authority (CA) store file during their creation. For more information about certificates, and how to obtain, create, and install them, search the Securing Splunk Enterprise Manual for "Introduction to Securing the Splunk Platform with TLS". The server data plane certificate must be in privacy-enhanced mail (PEM) format.	$SPLUNK_HOME/etc/auth/server_dp.pem
`[dataplaneSslConfig]` `certDPCreateScript`	`<string>`The creation script for generating the server data plane certificate when you start Splunk Enterprise for the first time.	$SPLUNK_HOME/bin/splunk, createssl, server-cert-dp

`[etcdTlsConfig]`

Configures a certificate for TLS communication in an 'etcd' cluster.
The 'etcd' binary is a dependency of the Nascent sidecar (process name: nascent) and the Storage sidecar (process name: postgres).
By default, the system uses automatically generated self-signed certificates for TLS connections. Splunk software activates these auto-generated certificates by passing the --peer-auto-tls and --auto-tls arguments to 'etcd'. Set 'insecureAutoGeneratedTls' to "false" to use a custom certificate.
You must use absolute paths.

Setting	Description	Default
`[etcdTlsConfig]` `insecureAutoGeneratedTls`	`<boolean>`Determines whether the system uses auto-generated or custom TLS certificates for 'etcd'. More A value of "true" means the system ignores the 'serverCertFile', 'serverKeyFile' and 'caCertFile' fields and uses auto-generated TLS certificates. A value of "false" means the system uses certificates provided in the 'serverCertFile', 'serverKeyFile', and 'caCertFile' fields. You must set both the 'serverCertFile' and 'serverKeyFile'. If 'serverCertFile' or 'serverKeyFile' is missing or points to a non-existent file, Splunk software defaults to using auto-generated certificates while generating Splunk Web bulletin error messages. When 'insecureAutoGeneratedTls' is set to any other value, the behavior is the same as when 'insecureAutoGeneratedTls' is set to "true", and Splunk Web displays bulletin error messages.	true
`[etcdTlsConfig]` `serverCertFile`	`<string>`The absolute path to a certificate file used for TLS connections. More The system uses the same certificate for listening on the peer address and sending requests to other peers. Therefore, the certificate must be generated to serve as both a server certificate and a client certificate. For example, a valid TLS certificate for 'etcd' can be generated by using an OpenSSL configuration file that includes the following section: [ v3_ext ] extendedKeyUsage = serverAuth,clientAuth	No default
`[etcdTlsConfig]` `serverKeyFile`	`<string>`Specifies the absolute path to a key file for the certificate. More Key must be unencrypted.	No default
`[etcdTlsConfig]` `caCertFile`	`<string>`The absolute path to the certificate authority (CA) file. More If 'caCertFile' is left empty or not specified, the system will use the default CA certificates of the operating system.	No default

`[tls1.3]`

Use this stanza to configure communications between Splunk components using version 1.3 of the transport layer security (TLS) network encryption protocol.
For any of the settings under this stanza to have an effect, TLS version 1.3 must be active on the instance. The '[sslConfig]/sslVersions' setting controls whether or not the instance uses TLS 1.3, and must have "tls1.3" as an entry in its value list.
The settings under this stanza apply specifically to TLS 1.3. You can find settings that other versions of TLS use under the [sslConfig] stanza. You can configure other settings in the [sslConfig] stanza for TLS 1.3.
The Splunk platform uses the default values for TLS 1.3 settings that you do not explicitly specify under this stanza, or if the stanza is missing.

Setting	Description	Default
`[tls1.3]` `cipherSuite`	`<string>`See the description of 'cipherSuite' under the [sslConfig] stanza for details on this setting. More The default can vary. See the 'cipherSuite' setting in the $SPLUNK_HOME/etc/system/default/server.conf file for the current default.
`[tls1.3]` `groups`	`<comma-separated list>`A list of named Diffie-Hellmann groups that the Splunk platform can use for key exchanges under version 1.3 of the TLS protocol. More This setting is similar to the 'ecdhCurves' setting under the [sslConfig] stanza, but replaces it and extends functionality for TLS 1.3 with support for post-quantum cryptography (PQC) and hybrid groups in addition to classical elliptic curve groups. Supported group types include: - Classical elliptic curve groups (for example, prime256v1, secp384r1, secp521r1). - PQC groups (for example, MLKEM768, MLKEM768, MLKEM1024). - Hybrid groups that combine classical and PQC algorithms (for example, X25519MLKEM768, SecP256r1MLKEM768). Specify groups in the order that you prefer. The Splunk platform logs a warning for any invalid group names and uses any remaining valid groups. The default can vary. See the 'groups' setting in the $SPLUNK_HOME/etc/system/default/server.conf file for the current default.

`[pythonSslClientConfig]`

TLS settings for Splunk Python client connections.
Follow this stanza name with any number of the following setting/value pairs.
If you do not specify an entry for each setting, splunkd uses the values from the settings under the [sslConfig] stanza.

Setting	Description	Default
`[pythonSslClientConfig]` `sslVerifyServerCert`	`<boolean>`See the description of 'sslVerifyServerCert' under the [sslConfig] stanza for details on this setting. More If you give this setting a value of "true", confirm that you have also set '[sslConfig]/sslRootCAPath' with the correct value.	false
`[pythonSslClientConfig]` `sslVerifyServerName`	`<boolean>`See the description of 'sslVerifyServerName' under the [sslConfig] stanza for details on this setting.	false

`[proxyConfig]`

NOTE: Splunkd does not support Transport Layer Security (TLS) as a protocol for proxying connections. It only supports using the HTTP CONNECT method for HTTPS requests. The proxy server cannot listen on an SSL port.

Setting	Description	Default
`[proxyConfig]` `http_proxy`	`<string>`If set, splunkd sends all HTTP requests through the proxy server that you specify.	No default
`[proxyConfig]` `https_proxy`	`<string>`If set, splunkd sends all HTTPS requests through the proxy server that you specify. More If not set, splunkd uses the 'http_proxy' setting instead.	No default
`[proxyConfig]` `proxy_rules`	`<string>`One or more host names or IP addresses for which splunkd is to route HTTPS requests only through the proxy server. More If set, splunkd uses the proxy server only for endpoints that match the host names or IP addresses in this value. Splunkd does not route requests to either the localhost or loopback addresses through the proxy server. Separate multiple entries with commas. This setting accepts the following values: '*' (asterisk): Route all requests through the proxy server. This is the only wildcard value, and it can be used only by itself. <IPv4 or IPv6 address>: Route the request through the proxy if the request is intended for that address. <hostname>/<domain name>: Route the request through the proxy if the request is intended for that host name or domain name. Examples: proxy_rules = "wimpy": This matches the host name "wimpy". If the request is for the machine "wimpy", route that request through the proxy server. proxy_rules = "splunk.com": Matches all host names in the splunk.com domain (such as apps.splunk.com, www.splunk.com, etc.) Route requests to any machine with a host name that ends in "splunk.com" through the proxy server.	*
`[proxyConfig]` `no_proxy`	`<string>`One or more host names or IP addresses for which splunkd is to explicitly bypass the proxy server for HTTPS requests. More If set, splunkd does not route requests to matching host names and IP addresses through the proxy server. This setting overrides the 'proxy_rules' setting. If a host name or IP address is in both settings, splunkd does not route requests for that host name or IP address through the proxy server. Splunkd does not route requests to either the localhost or loopback addresses through the proxy server. Separate multiple entries with commas. This setting accepts the following values: '*' (asterisk): Do not route any request through the proxy server. This is the only wildcard value, and it can be used only by itself. <IPv4 or IPv6 address>: Do not route the request through the proxy if the request is intended for that address. <hostname>/<domain name>: Do not route the request through the proxy if the request is intended for that host name or domain name. Examples: no_proxy = "wimpy": This matches the host name "wimpy". Bypass the proxy server for requests for the machine "wimpy". no_proxy = "splunk.com": Matches all host names in the splunk.com domain (such as apps.splunk.com, www.splunk.com, etc.) Bypass the proxy server for requests for any machine whose hostname ends in "splunk.com".	localhost, 127.0.0.1, ::1
`[proxyConfig]` `enable_tls_proxy`	`<boolean>`Whether or not the Splunk daemon (splunkd) launches a helper process to proxy outbound network connections over transport layer security (TLS) from the Splunk platform instance to external Splunk nodes or services. More The helper process, called splunk-tlsd, improves the overall availability of splunkd by proxying requests to certain external nodes or services over TLS. This reduces the need to restart splunkd after TLS-related configuration changes. Currently, splunk-tlsd handles connections over TLS to Splunk Telemetry and SplunkBase only. When splunk-tlsd is active, splunkd routes network traffic for certain external nodes to the helper process. The splunk-tlsd process then sends that traffic over TLS to the external node. A value of "true" means that splunkd launches splunk-tlsd to handle network connections' over TLS to external nodes. A value of "false" means that splunkd handles the connections to external services. You must restart the Splunk platform instance for this change to take effect.	false

`[httpServer]`

Set stand-alone HTTP settings for splunkd under this stanza name.
Follow this stanza name with any number of the following setting/value pairs.
If you do not specify an entry for each setting, splunkd uses the default value.

Setting	Description	Default
`[httpServer]` `atomFeedStylesheet`	`<string>`Defines the stylesheet relative URL to apply to default Atom feeds. More Set to 'none' to stop writing out xsl-stylesheet directive.	/static/atom.xsl
`[httpServer]` `max-age`	`<nonnegative integer>`Set the maximum time, in seconds, to cache a static asset served off of the '/static' directory. More This value is passed along in the 'Cache-Control' HTTP header.	3600 (60 minutes)
`[httpServer]` `follow-symlinks`	`<boolean>`Specifies whether the static file handler (serving the '/static' directory) follows filesystem symlinks when serving files.	false
`[httpServer]` `disableDefaultPort`	`<boolean>`If set to "true", turns off listening on the splunkd management port, which is 8089 by default. More NOTE: Changing this setting is not recommended. This is the general communication path to splunkd. If it is disabled, there is no way to communicate with a running splunk instance. This means many command line splunk invocations cannot function, Splunk Web cannot function, the REST interface cannot function, etc. If you choose to disable the port anyway, understand that you are selecting reduced Splunk functionality.	false
`[httpServer]` `mgmtMode`	`none\|auto\|tcp`Sets the transport layer protocol mode for Splunk CLI management commands. More A value of "none" means that only Splunk CLI commands that can be run offline are available for use on the instance. A value of "auto" means that CLI commands execute over a Unix Domain Socket (UDS), which represents as $SPLUNK_HOME/var/run/splunk/cli.socket on the file system. If the OS does not support UDS, and if 'disableDefaultPort' has a value of "false", the CLI executes over the splunkd management port. If 'disableDefaultPort' has a value of "true", only CLI commands that can be run offline are available for use on the instance. A value of "tcp" means the CLI commands execute over the splunkd management port. This setting is only available on the universal forwarder. NOTE: There is a path length limit of 104-108 characters for the UDS socket file. This includes whatever the $SPLUNK_HOME environment variable expands to. If you exceed this length for the socket file, UDS does not work, and you must reinstall the universal forwarder, because you cannot take corrective action to fix the UDS path. Verify the UDS path length when configuring this setting.	auto
`[httpServer]` `acceptFrom`	`<network_acl> ...`Lists a set of networks or addresses from which to accept connections. More Separate multiple rules with commas or spaces. Each rule can be in one of the following formats: 1. A single IPv4 or IPv6 address (examples: "10.1.2.3", "fe80::4a3") 2. A Classless Inter-Domain Routing (CIDR) block of addresses (examples: "10/8", "192.168.1/24", "fe80:1234/32") 3. A DNS name, possibly with a "" used as a wildcard (examples: "myhost.example.com", ".splunk.com") 4. "", which matches anything You can also prefix an entry with '!' to cause the rule to reject the connection. The input applies rules in order, and uses the first one that matches. For example, "!10.1/16, " allows connections from everywhere except the 10.1.. network.	"*" (accept from anywhere)
`[httpServer]` `streamInWriteTimeout`	`<positive number>`The timeout, in seconds, for uploading data to the http server. More When uploading data to http server, if the http server is unable to write data to the receiver for the specified value, the operation aborts.	5
`[httpServer]` `max_content_length`	`<integer>`Maximum content length, in bytes. More HTTP requests over the size specified are rejected. This setting exists to avoid allocating an unreasonable amount of memory from web requests. In environments where indexers have enormous amounts of RAM, this number can be reasonably increased to handle large quantities of bundle data.	2147483648 (2GB)
`[httpServer]` `maxSockets`	`<integer>`The number of simultaneous HTTP connections that Splunk Enterprise accepts simultaneously. You can limit this number to constrain resource usage. More If set to "0", Splunk Enterprise automatically sets maxSockets to one third of the maximum allowable open files on the host. If this number is less than 50, it is set to 50. If this number is greater than 400000, it is set to 400000. If set to a negative number, no limit is enforced.	0
`[httpServer]` `maxThreads`	`<integer>`The number of threads that can be used by active HTTP transactions. You can limit this number to constrain resource usage. More If set to 0, Splunk Enterprise automatically sets the limit to one third of the maximum allowable threads on the host. If this number is less than 20, it is set to 20. If this number is greater than 150000, it is set to 150000. If maxSockets is not negative and maxThreads is greater than maxSockets, then Splunk Enterprise sets maxThreads to be equal to maxSockets. If set to a negative number, no limit is enforced.	0
`[httpServer]` `keepAliveIdleTimeout`	`<integer>`How long, in seconds, that the Splunkd HTTP server allows a keep-alive connection to remain idle before forcibly disconnecting it. More If this number is less than 7200, it is set to 7200.	7200 (120 minutes)
`[httpServer]` `busyKeepAliveIdleTimeout`	`<integer>`How long, in seconds, that the Splunkd HTTP server allows a keep-alive connection to remain idle while in a busy state before forcibly disconnecting it. More Use caution when configuring this setting as a value that is too large can result in file descriptor exhaustion due to idling connections. If this number is less than 12, it is set to 12.	12
`[httpServer]` `forceHttp10`	`auto\|never\|always`When set to "always", the REST HTTP server does not use some HTTP 1.1 features such as persistent connections or chunked transfer encoding. More When set to "auto" it does this only if the client sent no User-Agent header, or if the user agent is known to have bugs in its HTTP/1.1 support. When set to "never" it always allows HTTP 1.1, even to clients it suspects may be buggy.	auto
`[httpServer]` `crossOriginSharingPolicy`	`<origin_acl> ...`List of the HTTP Origins for which to return Access-Control-Allow-* (CORS) headers. More These headers tell browsers that web applications are trusted at those sites to make requests to the REST interface. The origin is passed as a URL without a path component (for example "https://app.example.com:8000"). This setting can take a list of acceptable origins, separated by spaces and/or commas. Each origin can also contain wildcards for any part. Examples: ://app.example.com: (either HTTP or HTTPS on any port) https://.example.com (any host under example.com, including example.com itself) An address can be prefixed with a '!' to negate the match, with the first matching origin taking precedence. For example, "!://evil.example.com:* ://.example.com:" to not avoid matching one host in a domain A single "" can also be used to match all origins	No default
`[httpServer]` `crossOriginSharingHeaders`	`<string>`A list of the HTTP headers to which splunkd sets "Access-Control-Allow-Headers" when replying to Cross-Origin Resource Sharing (CORS) preflight requests. More The "Access-Control-Allow-Headers" header is used in response to a CORS preflight request to tell browsers which HTTP headers can be used during the actual request. A CORS preflight request is a CORS request that checks to see if the CORS protocol is understood and a server is aware of using specific methods and headers. This setting can take a list of acceptable HTTP headers, separated by commas. A single "*" can also be used to match all headers.	Empty string.
`[httpServer]` `x_frame_options_sameorigin`	`<boolean>`Adds a X-Frame-Options header set to "SAMEORIGIN" to every response served by splunkd.	true
`[httpServer]` `allowEmbedTokenAuth`	`<boolean>`A value of "false" means splunkd does not allow any access to artifacts that previously had been explicitly shared to anonymous users. More This effectively disables all use of the "embed" feature.	true
`[httpServer]` `cliLoginBanner`	`<string>`Sets a message which is added to the HTTP reply headers of requests for authentication, and to the "server/info" endpoint More This is printed by the Splunk CLI before it prompts for authentication credentials. This can be used to print access policy information. If this string starts with a '"' character, it is treated as a CSV-style list with each line comprising a line of the message. For example: "Line 1","Line 2","Line 3"	No default
`[httpServer]` `allowBasicAuth`	`<boolean>`Allows clients to make authenticated requests to the splunk server using "HTTP Basic" authentication in addition to the normal "authtoken" system More This is useful for programmatic access to REST endpoints and for accessing the REST API from a web browser. It is not required for the UI or CLI.	true
`[httpServer]` `allowWwwAuthHeader`	`<boolean>`Describes whether or not Splunk Web can include a "www-authenticate" header in a response to a request from a web client to access a management endpoint. More When Splunk Web sends the "www-authenticate" header in response to such a request, the client forces its user to provide credentials to authenticate. A value of "true" means that Splunk Web sends a "www-authenticate" header in its response to the web client request. This means that the user of that client will be prompted to enter valid credentials to access the instance, even if they provide those credentials as part of the request. A value of "false" means that Splunk Web does not send the "www-authenticate" header in its response to the web client request. This means that the user of that client will not be prompted to provide valid credentials to access the instance. Giving this setting a value of "false" reduces the attack surface in the management API when you access it through Splunk Web. This setting is not valid for the CLI. It works only with Splunk Web.	true
`[httpServer]` `basicAuthRealm`	`<string>`When using "HTTP Basic" authentication, the 'realm' is a human-readable string describing the server. Typically, a web browser presents this string as part of its dialog box when asking for the username and password. More This can be used to display a short message describing the server and/or its access policy.	/splunk
`[httpServer]` `allowCookieAuth`	`<boolean>`Allows clients to request an HTTP cookie from the /services/auth/login endpoint which can then be used to authenticate future requests	true
`[httpServer]` `cookieAuthHttpOnly`	`<boolean>`When using cookie based authentication, mark returned cookies with the "httponly" flag to tell the client not to allow javascript code to access its value More NOTE: has no effect if allowCookieAuth=false	true
`[httpServer]` `cookieSameSiteSecure`	`<boolean>`DEPRECATED. More Describes whether or not the Splunk REST server sets all Splunk cookies with the "SameSite=None" cookie attribute. A value of "true" means that the Splunk REST server sets the "SameSite=None" attribute for all cookies. A value of "false" means that the REST server does not set cookies with the "SameSite=None" attribute. NOTE: The REST server does not change the 'secure' cookie attribute with this setting. Use the 'cookieAuthSecure' setting to perform this task. The Splunk web server and the Splunk REST server use different settings to make cookie modifications. To modify cookies that the Splunk web server sets, use the 'cookieSameSite' setting in the web.conf configuration file.	false
`[httpServer]` `cookieAuthSecure`	`<boolean>`When using cookie based authentication, mark returned cookies with the "secure" flag to tell the client never to send it over an unencrypted HTTP channel More NOTE: has no effect if allowCookieAuth=false OR the splunkd REST interface has SSL disabled	true
`[httpServer]` `dedicatedIoThreads`	`[<integer>\|auto]`The number of threads that splunkd dedicates to handling HTTP I/O requests. More This setting controls thread usage for all HTTP requests through splunkd, including SSL encryption. If you set this to "0", splunkd uses the same thread that accepted the initial connection over TCP to perform the HTTP I/O. If you set this to a number other than "0", splunkd creates that number of threads to handle HTTP I/O. If you set this to "auto", splunkd uses the number of CPU cores on the machine to determine the number of threads available for HTTP I/O as follows: Number of CPU cores available \| 'dedicatedIoThreads' 0 - 16 \| 0 17 - 48 \| 2 49 - 128 \| 4 129 - 192 \| 6 193 and higher \| 8 You do not usually need to change this setting. However, for an instance running as a dedicated deployment server, the best practice is to set 'dedicatedIoThreads' to a value of CPU cores/2, or CPU cores-1, in the case of a very active deployment server. For example, in the case of a deployment server with 8 CPU cores, set 'dedicatedIoThreads' to 4 or 7.	auto
`[httpServer]` `dedicatedIoThreadsSelectionPolicy`	`<round_robin \| weighted_random>`Specifies the I/O threads selection policy to use while selecting I/O thread for new connection. More If set to "round_robin", the incoming connections are assigned to I/O threads in a round robin fashion. If set to "weighted_random", the connections are assigned to I/O threads using a weighted random scheme designed to even out the CPU usage of each I/O thread. NOTE: This setting only takes effect when dedicatedIoThreads is greater than 1.	round_robin
`[httpServer]` `dedicatedIoThreadsWeightsUpdatePeriod`	`<number>`The interval, in seconds, when I/O thread weights are recalculated for the "weighted_random" selection policy. More Reducing this interval causes the weights to be re-evaluated more frequently, thereby enabling the system to react more quickly to changes in relative thread load. Increasing this interval causes the weights to be re-evaluated less frequently, thereby reducing the ability of the system to respond to bursty events.	30
`[httpServer]` `replyHeader.<name>`	`<string>`Add a static header to all HTTP responses this server generates More For example, "replyHeader.My-Header = value" causes the response header "My-Header: value" to be included in the reply to every HTTP request to the REST server

`[httpServerListener:<ip:><port>]`

Enable the splunkd REST HTTP server to listen on an additional port number specified by <port>. If a non-empty <ip> is included (for example: "[httpServerListener:127.0.0.1:8090]") the listening port is bound only to a specific interface.
Multiple "httpServerListener" stanzas can be specified to listen on more ports.
Normally, splunkd listens only on the single REST port specified in the web.conf "mgmtHostPort" setting, and none of these stanzas need to be present. Add these stanzas only if you want the REST HTTP server to listen to more than one port.

Setting	Description	Default
`[httpServerListener:<ip:><port>]` `ssl`	`<boolean>`Toggle whether this listening ip:port uses SSL or not. More If the main REST port is SSL (the "enableSplunkdSSL" setting in this file's [sslConfig] stanza) and this stanza is set to "ssl=false" then clients on the local machine such as the CLI may connect to this port.	true
`[httpServerListener:<ip:><port>]` `listenOnIPv6`	`no\|yes\|only`Toggle whether this listening ip:port listens on IPv4, IPv6, or both. More If not present, the setting in the [general] stanza is used
`[httpServerListener:<ip:><port>]` `acceptFrom`	`<network_acl> ...`Lists a set of networks or addresses from which to accept connections. More Separate multiple rules with commas or spaces. Each rule can be in one of the following formats: 1. A single IPv4 or IPv6 address (examples: "10.1.2.3", "fe80::4a3") 2. A Classless Inter-Domain Routing (CIDR) block of addresses (examples: "10/8", "192.168.1/24", "fe80:1234/32") 3. A DNS name, possibly with a "" used as a wildcard (examples: "myhost.example.com", ".splunk.com") 4. "", which matches anything You can also prefix an entry with '!' to cause the rule to reject the connection. The input applies rules in order, and uses the first one that matches. For example, "!10.1/16, " allows connections from everywhere except the 10.1.. network.	The setting in the [httpServer] stanza

`[mimetype-extension-map]`

Map filename extensions to MIME type for files served from the static file handler under this stanza name.

Setting	Description	Default
`[mimetype-extension-map]` `<file-extension>`	`<MIME-type>`Instructs the HTTP static file server to mark any files ending in 'file-extension' with a header of 'Content-Type: <MIME-type>'.	[mimetype-extension-map] gif = image/gif htm = text/html jpg = image/jpg png = image/png txt = text/plain xml = text/xml xsl = text/xml

`[stderr_log_rotation]`

Controls the data retention of the file containing all messages written to splunkd's stderr file descriptor (fd 2).
Typically this is extremely small, or mostly errors and warnings from linked libraries.

Setting	Description	Default
`[stderr_log_rotation]` `maxFileSize`	`<bytes>`When splunkd_stderr.log grows larger than this value, it is rotated. More maxFileSize is expressed in bytes. You might want to increase this if you are working on a problem that involves large amounts of output to the splunkd_stderr.log file. You might want to reduce this to allocate less storage to this log category.	10000000 (10 si-megabytes)
`[stderr_log_rotation]` `BackupIndex`	`<non-negative integer>`How many rolled copies to keep. More For example, if this setting is 2, the splunkd_stderr.log.1 and splunkd_stderr.log.2 file might exist. Further rolls delete the current splunkd_stderr.log.2 file. You might want to increase this value if you are working on a problem that involves large amounts of output to the splunkd_stderr.log fils You might want to reduce this to allocate less storage to this log category.	2
`[stderr_log_rotation]` `checkFrequency`	`<seconds>`How often. in seconds, to check the size of splunkd_stderr.log More Larger values may result in larger rolled file sizes but take less resources. Smaller values may take more resources but more accurately constrain the file size.	10

`[stdout_log_rotation]`

Controls the data retention of the file containing all messages written to splunkd's stdout file descriptor (fd 1).
Almost always, there is nothing in this file.
This stanza can have the same settings as the [stderr_log_rotation] stanza with the same defaults. See above for definitions.

Setting	Description	Default
`[stdout_log_rotation]` `maxFileSize`	`<bytes>`No description in the spec.
`[stdout_log_rotation]` `BackupIndex`	`<non-negative integer>`No description in the spec.
`[stdout_log_rotation]` `checkFrequency`	`<seconds>`No description in the spec.

`[applicationsManagement]`

Set remote applications settings for Splunk under this stanza name.
Follow this stanza name with any number of the following setting/value pairs.
If you do not specify an entry for each setting, the Splunk platform instance uses the default value.

Setting	Description	Default
`[applicationsManagement]` `allowInternetAccess`	`<boolean>`Lets the Splunk platform instance access the remote applications repository.
`[applicationsManagement]` `url`	`<string>`Applications repository URL.	https://apps.splunk.com/api/apps
`[applicationsManagement]` `loginUrl`	`<string>`Applications repository login URL.	https://apps.splunk.com/api/account:login/
`[applicationsManagement]` `detailsUrl`	`<string>`Base URL for application information, keyed off of app ID.	https://apps.splunk.com/apps/id
`[applicationsManagement]` `useragent`	`<splunk-version>-<splunk-build-num>-<platform>`User-agent string to use when contacting applications repository. More <platform> includes information like operating system and CPU architecture.
`[applicationsManagement]` `updateHost`	`<string>`Host section of URL to check for app updates, e.g. https://apps.splunk.com
`[applicationsManagement]` `updatePath`	`<string>`Path section of URL to check for app updates For example: /api/apps:resolve/checkforupgrade
`[applicationsManagement]` `updateTimeout`	`<time range string>`The minimum amount of time Splunk software waits between checks for app updates. More Examples include '24h' (24 hours), '3d' (3 days), '7200s' (7200 seconds, or two hours)	24h
`[applicationsManagement]` `sslVersions`	`<comma-separated list>`The list of TLS versions to use to connect to 'url'. (https://apps.splunk.com). More The versions available are "tls1.0", "tls1.1", "tls1.2", and "tls1.3". The special version "*" selects all supported versions. The version "tls" selects all versions tls1.0 or newer. If a version is prefixed with "-" it is removed from the list. SSL versions 2 and 3 are always disabled. "-ssl2" and "-ssl3" are accepted as values in the version list, but have no effect. The default can vary. See the 'sslVersions' setting in the $SPLUNK_HOME/etc/system/default/server.conf file for the current default)
`[applicationsManagement]` `sslVerifyServerCert`	`<boolean>`See the description of 'sslVerifyServerCert' under the [sslConfig] stanza for details on this setting.	true
`[applicationsManagement]` `sslVerifyServerName`	`<boolean>`See the description of 'sslVerifyServerName' under the [sslConfig] stanza for details on this setting.	false
`[applicationsManagement]` `caCertFile`	`<path>`DEPRECATED. More Used for validating TLS certificate from the Splunkbase website. See the description of 'caCertFile' under the [sslConfig] stanza for details on this setting.
`[applicationsManagement]` `caTrustStore`	`<[splunk],[OS]>`See the description of 'caTrustStore' under the [sslConfig] stanza for details on this setting.	splunk
`[applicationsManagement]` `caTrustStorePath`	`<string>`See the description of 'caTrustStorePath' under the [sslConfig] stanza for details on this setting.	No default
`[applicationsManagement]` `sslCommonNameToCheck`	`<commonName1>, <commonName2>, ...`See the description of 'sslCommonNameToCheck' under the [sslConfig] stanza for details on this setting.	splunkbase.splunk.com, apps.splunk.com, cdn.apps.splunk.com
`[applicationsManagement]` `sslCommonNameList`	`<commonName1>, <commonName2>, ...`DEPRECATED. Use the 'sslCommonNameToCheck' setting instead.
`[applicationsManagement]` `sslAltNameToCheck`	`<alternateName1>, <alternateName2>, ...`See the description of 'sslAltNametoCheck' under the [sslConfig] stanza for details on this setting.	splunkbase.splunk.com, apps.splunk.com, cdn.apps.splunk.com
`[applicationsManagement]` `splunkbaseAppsDumpUrl`	`<string>`JSON file link with data on current Splunkbase apps.	https://cdn.splunkbase.splunk.com/public/report/apps_dump.json
`[applicationsManagement]` `archivedSplunkbaseAppsDumpUrl`	`<string>`JSON file link with data on archived Splunkbase apps.	https://cdn.splunkbase.splunk.com/public/report/archived_apps_dump.json
`[applicationsManagement]` `cipherSuite`	`<string>`See the description of 'cipherSuite' under the [sslConfig] stanza for details on this setting. More The default can vary. See the 'cipherSuite' setting in the $SPLUNK_HOME/etc/system/default/server.conf file for the current default.
`[applicationsManagement]` `ecdhCurves`	`<comma separated list>`See the description of 'ecdhCurves' under the [sslConfig] stanza for details on this setting. More The default can vary. See the 'ecdhCurves' setting in the $SPLUNK_HOME/etc/system/default/server.conf file for the current default.

`[scripts]`

Setting	Description	Default
`[scripts]` `initialNumberOfScriptProcesses`	`<num>`The number of pre-forked script processes that are launched when the system comes up. These scripts are reused when script REST endpoints and search scripts are executed. The idea is to eliminate the performance overhead of launching the script interpreter every time it is invoked. These processes are put in a pool. If the pool is completely busy when a script gets invoked, a new processes is fired up to handle the new invocation - but it disappears when that invocation is finished.

`[diskUsage]`

Setting	Description	Default
`[diskUsage]` `minFreeSpace`	`<num>\|<percentage>`Minimum free space for a partition. More Specified as an integer that represents a size in binary megabytes (ie MiB) or as a percentage, written as a decimal between 0 and 100 followed by a '%' sign, for example "10%" or "10.5%" If specified as a percentage, this is taken to be a percentage of the size of the partition. Therefore, the absolute free space required varies for each partition depending on the size of that partition. Specifies a safe amount of space that must exist for splunkd to continue operating. Note that this affects search and indexing For search: Before attempting to launch a search, Splunk software requires this amount of free space on the filesystem where the dispatch directory is stored, $SPLUNK_HOME/var/run/splunk/dispatch Applied similarly to the search quota values in authorize.conf and limits.conf. For indexing: Periodically, the indexer checks space on all partitions that contain splunk indexes as specified by indexes.conf. Indexing is paused and a ui banner + splunkd warning posted to indicate need to clear more disk space.	5000 (approx 5GB)
`[diskUsage]` `pollingFrequency`	`<num>`Specifies that after every 'pollingFrequency' events are indexed, the disk usage is checked.	100000
`[diskUsage]` `pollingTimerFrequency`	`<num>`Minimum time, in seconds, between two disk usage checks.	10

`[queue]`

Setting	Description	Default
`[queue]` `maxSize`	`[<integer>\|<integer>[KB\|MB\|GB]]`Specifies default capacity of a queue. More If specified as a lone integer (for example, maxSize=1000), maxSize indicates the maximum number of events allowed in the queue. If specified as an integer followed by KB, MB, or GB (for example, maxSize=100MB), it indicates the maximum RAM allocated for queue.	500KB
`[queue]` `cntr_1_lookback_time`	`[<integer>[s\|m]]`The lookback counters are used to track the size and count (number of elements in the queue) variation of the queues using an exponentially moving weighted average technique. Both size and count variation has 3 sets of counters each. The set of 3 counters is provided to be able to track short, medium and long term history of size/count variation. The user can customize the value of these counters or lookback time. More Specifies how far into history should the size/count variation be tracked for counter 1. It must be an integer followed by [s\|m] which stands for seconds and minutes respectively.	60s
`[queue]` `cntr_2_lookback_time`	`[<integer>[s\|m]]`Specifies how far into history should the size/count variation be tracked for counter 2. More See the 'cntr_1_lookback_time' setting description for explanation and usage of the lookback counter.	600s (10 minutes)
`[queue]` `cntr_3_lookback_time`	`[<integer>[s\|m]]`Specifies how far into history should the size/count variation be tracked for counter 3. More See the 'cntr_1_lookback_time' setting description for explanation and usage of the lookback counter.	900s (15 minutes)
`[queue]` `sampling_interval`	`[<integer>[s\|m]]`The lookback counters described earlier collect the size and count measurements for the queues. This setting specifies at what interval the measurement collection happens. More NOTE: The counter sampling interval is the same for all counters in a particular queue. Specify this value using integer followed by [s\|m] which stands for seconds and minutes, respectively.	1s
`[queue]` `autoAdjustQueue`	`<boolean>`Whether or not splunkd adjusts the value of the 'maxSize' setting automatically for all pipeline queues. More A value of "true" means splunkd adjusts the value of `maxSize` automatically for all pipeline queues. A value of "false" means splunkd does not adjust the 'maxSize' value automatically and you must configure it manually.	false

`[queue=<queueName>]`

Setting	Description	Default
`[queue=<queueName>]` `autoAdjustQueue`	`<boolean>`Whether or not splunkd adjusts the value of the 'maxSize' setting automatically for the named pipeline queue. More See the description for 'autoAdjustQueue' earlier in this file for specifics on how to configure this setting for individual queues.	The value of `autoAdjustQueue` in the "[queue]" stanza.
`[queue=<queueName>]` `maxSize`	`[<integer>\|<integer>[KB\|MB\|GB]]`Specifies the capacity of a queue. It overrides the default capacity specified in the [queue] stanza. More If specified as a lone integer (for example, maxSize=1000), maxSize indicates the maximum number of events allowed in the queue. If specified as an integer followed by KB, MB, or GB (for example, maxSize=100MB), it indicates the maximum RAM allocated for queue.	The default is inherited from the 'maxSize' value specified in the [queue] stanza
`[queue=<queueName>]` `cntr_1_lookback_time`	`[<integer>[s\|m]]`Same explanation as mentioned in the [queue] stanza. More Specifies the lookback time for the specific queue for counter 1.	The default value is inherited from the 'cntr_1_lookback_time' value that is specified in the [queue] stanza
`[queue=<queueName>]` `cntr_2_lookback_time`	`[<integer>[s\|m]]`Specifies the lookback time for the specific queue for counter 2.	The default value is inherited from the 'cntr_2_lookback_time' value that is specified in the [queue] stanza.
`[queue=<queueName>]` `cntr_3_lookback_time`	`[<integer>[s\|m]]`Specifies the lookback time for the specific queue for counter 3.	The default value is inherited from the 'cntr_3_lookback_time' value that is specified in the [queue] stanza.
`[queue=<queueName>]` `sampling_interval`	`[<integer>[s\|m]]`Specifies the sampling interval for the specific queue.	The default value is inherited from the 'sampling_interval' value specified in the [queue] stanza.

`[pubsubsvr-http]`

Setting	Description	Default
`[pubsubsvr-http]` `disabled`	`<boolean>`If disabled, then http endpoint is not registered. Set this value to 'false' to expose PubSub server on http.	true
`[pubsubsvr-http]` `stateIntervalInSecs`	`<seconds>`The number of seconds before a connection is flushed due to inactivity. The connection is not closed, only messages for that connection are flushed.	300 (5 minutes)

`[diag]`

Setting	Description	Default
`[diag]` `EXCLUDE-<class>`	`<glob expression>`Specifies a glob / shell pattern to be excluded from diags generated on this Splunk instance. More Example: /etc/secret_app/local/.conf Further excludes can be added at the splunk diag command line, but there is no facility to disable configuration-based excludes at the command line. There is one exclude by default, for the splunk.secret file.
`[diag]` `components`	`<comma-separated list>`Specifies which components of the diag should be gathered. More This allows the disabling and enabling, categorically, of entire portions of diag functionality. All of these components are further subject to the EXCLUDE-<class> setting and component-specific filters (see the following component list.) Currently, with no configuration, all components except "rest" are enabled by default. Available components are: index_files : Files from the index that indicate their health (Hosts\|Sources\|Sourcetypes.data and bucketManifests). User data is not collected. index_listing : Directory listings of the index contents are gathered, in order to see filenames, directory names, sizes, timestamps and the like. etc : The entire contents of the $SPLUNK_HOME/etc directory. In other words, the configuration files. log : The contents of $SPLUNK_HOME/var/log/... pool : If search head pooling is enabled, the contents of the pool dir. dispatch : Search artifacts, without the actual results, In other words var/run/splunk/dispatch, but not the results or events files searchpeers : Directory listings of knowledge bundles replicated for distributed search In other words: $SPLUNK_HOME/var/run/searchpeers consensus : Consensus protocol files produced by search head clustering In other words: $SPLUNK_HOME/var/run/splunk/_raft conf_replication_summary : Directory listing of configuration replication summaries produced by search head clustering In other words: $SPLUNK_HOME/var/run/splunk/snapshot rest : The contents of a variety of splunkd endpoints Includes server status messages (system banners), licenser banners, configured monitor inputs & tailing file status (progress reading input files). On cluster managers, also gathers manager info, fixups, current peer list, clustered index info, current generation, & buckets in bad stats On cluster peers, also gathers local buckets & local peer info, and the manager information remotely from the configured manager. kvstore : Directory listings of the KV Store data directory contents are gathered, in order to see filenames, directory names, sizes, and timestamps. file_validate : Produce list of files that were in the install media which have been changed. Generally this should be an empty list. profiler : The profiler directory at $SPLUNK_HOME/var/run/profiler The special value "all" is also supported, enabling everything explicitly. Further controlling the components from the command line: The switch --collect replaces this list entirely. Example: --collect log,etc This would set the components to log and etc only, regardless of config The switch --enable adds a specific component to this list. Example: --enable pool This would ensure that pool data is collected, regardless of config The switch --disable removes a specific component from this list. Example: --disable pool This would ensure that pool data is NOT collected, regardless of config	All components except "rest"
`[diag]` `all_dumps`	`<boolean>`This setting currently is not applicable on UNIX platforms. More Affects the 'log' component of diag. (dumps are written to the log directory on Windows) Can be overridden with the --all-dumps command line argument. Normally, Splunk diag gathers only three .DMP (crash dump) files on Windows to limit diag size. If this is set to true, splunk diag collects all .DMP files from the log directory. No default. (false equivalent)
`[diag]` `index_files`	`[full\|manifests]`Selects a detail level for the 'index_files' component. More Can be overridden with the --index-files command line flag. If set to "manifests", limits the index file-content collection to just .bucketManifest files which give some information about the general state of buckets in an index. If set to "full", adds the collection of Hosts.data, Sources.data, and Sourcetypes.data which indicate the breakdown of count of items by those categories per-bucket, and the timespans of those category entries "full" can take quite some time on very large index sizes, especially when slower remote storage is involved.	manifests
`[diag]` `index_listing`	`[full\|light]`Selects a detail level for the 'index_listing' component. More Can be overridden with the --index-listing command line flag. "light" gets directory listings (ls, or dir) of the hot/warm and cold container directory locations of the indexes, as well as listings of each hot bucket. "full" gets a recursive directory listing of all the contents of every index location, which should mean all contents of all buckets. "full" can take a significant amount of time with very large bucket counts, especially on slower storage.	light
`[diag]` `etc_filesize_limit`	`<non-negative integer>`This filters the 'etc' component. More Can be overridden with the --etc-filesize-limit command line flag This value is specified in kilobytes. Example: 2000 - this would be approximately 2MB. Files in the $SPLUNK_HOME/etc directory which are larger than this limit is not collected in the diag. Diag produces a message stating that a file has been skipped for size to the console. (In practice, large files have been found to oftentimes be a surprise to the administrator, and indicate problems). You can disable this filter by setting the value to 0. Currently, as a special exception, the file $SPLUNK_HOME/system/replication/ops.json is permitted to be 10x the size of this limit.	10000 (10MB)
`[diag]` `log_age`	`<non-negative integer>`This filters the 'log' component. More Can be overridden with the --log-age command line flag This value is specified in days. Example: 75 - this would be 75 days, or about 2.5 months. You can disable this filter by setting the value to 0. The idea of this default filter is that data older than this is rarely helpful in troubleshooting cases in any event.	60 (or approximately 2 months)
`[diag]` `upload_proto_host_port`	`<protocol://host:port>\|disabled`The URI base to use for uploading files/diags to Splunk support. More If set to "disabled" (override in a local/server.conf file), effectively disables diag upload functionality for this Splunk instance. Modification can theoretically permit operations with some forms of proxies, but diag is not specifically designed for such, and support of proxy configurations that do not currently work is considered an Enhancement Request. The communication path with api.splunk.com is over a simple but not documented protocol. If you want to accept diag uploads into your own systems, it probably is simpler to run diag and then upload via your own means independently. However if you have business reasons that you want this built-in, get in touch. Do not upload using unencrypted HTTP protocol unless you have no other choice.	https://api.splunk.com
`[diag]` `SEARCHFILTERSIMPLE-<class>`	`regex`Redacts strings from ad-hoc searches logged in the audit.log and remote_searches.log files. More Substrings which match these regexes inside a search string in one of those two files is replaced by sequences of the character X, as in XXXXXXXX. Substrings which match a SEARCHFILTERLUHN regex has the contained numbers further tested against the Luhn algorithm, used for data integrity in mostly financial circles, such as credit card numbers. This permits more accurate identification of that type of data, relying less heavily on regex precision. See the Wikipedia article on the "Luhn algorithm" for additional information. Search string filtering is disabled if --no-filter-searchstrings is used on the command line. NOTE: That matching regexes must match only the bytes of the term. Each match "consumes" a portion of the search string, so matches that extend beyond the term (for example, to adjacent whitespace) could prevent subsequent matches, and/or redact data needed for troubleshooting. Use a name that hints at the purpose of the filter in the <class> component of the setting name, and consider an additional explicative comment, even for custom local settings. This might skip inquiries from support.
`[diag]` `SEARCHFILTERLUHN-<class>`	`regex`Redacts strings from ad-hoc searches logged in the audit.log and remote_searches.log files. More Substrings which match these regexes inside a search string in one of those two files is replaced by sequences of the character X, as in XXXXXXXX. Substrings which match a SEARCHFILTERLUHN regex has the contained numbers further tested against the Luhn algorithm, used for data integrity in mostly financial circles, such as credit card numbers. This permits more accurate identification of that type of data, relying less heavily on regex precision. See the Wikipedia article on the "Luhn algorithm" for additional information. Search string filtering is disabled if --no-filter-searchstrings is used on the command line. NOTE: That matching regexes must match only the bytes of the term. Each match "consumes" a portion of the search string, so matches that extend beyond the term (for example, to adjacent whitespace) could prevent subsequent matches, and/or redact data needed for troubleshooting. Use a name that hints at the purpose of the filter in the <class> component of the setting name, and consider an additional explicative comment, even for custom local settings. This might skip inquiries from support.

`[license]`

Setting	Description	Default
`[license]` `master_uri`	`[self\|<uri>]`DEPRECATED. Use the 'manager_uri' setting instead.
`[license]` `manager_uri`	`[self\|<uri>]`The URI of the license manager to which a license peer connects. More A value of "self" means that the instance itself handles license manager operations. A URI value means that the instance attempts to connect to the license manager at the URI you specify. A URI consists of the following string: <scheme>://<hostname>:<port>, where <scheme> is the URI scheme to use to attempt to connect to the license manager. <hostname> is the machine on which the license manager runs. <port> is the network port on which the license manager listens. For example, if you set "manager_uri = https://example.com:8089", then the instance attempts a connection to the instance at "http://example.com:8089" to get licensing information.	No default
`[license]` `active_group`	`Enterprise\|Trial\|Forwarder\|Free`If the instance is a license manager, the license type will be set in 'active_group'.	<empty>
`[license]` `connection_timeout`	`<integer>`Maximum time, in seconds, to wait before sending data to the manager times out. More This timeout applies only if 'manager_uri' is set.	30
`[license]` `send_timeout`	`<integer>`Maximum time, in seconds, to wait before sending data to the manager times out. More This timeout applies only if 'manager_uri' is set.	30
`[license]` `receive_timeout`	`<integer>`Maximum time, in seconds, to wait before receiving data from the manager times out More This timeout applies only if 'manager_uri' is set.	30
`[license]` `squash_threshold`	`<positive integer>`Periodically the indexer reports the indexed data to the license manager, broken down by source, sourcetype, host, index and scenario. When the number of distinct tuples exceeds the 'squash_threshold', the peer gradually squashes the rows: first by source, then finally if necessary by host. This reduces the risk of explosions in memory and license_usage.log lines. More Set this value on license peers as well as on the license manager. CAUTION: Do not alter this value without contacting Splunk Support.	2000
`[license]` `report_interval`	`<nonnegative integer>[s\|m\|h]`Selects a time period for reporting in license usage to the license manager. More This value is intended for very large deployments (hundreds of indexers) where a large number of indexers may overwhelm the license server. The maximum permitted interval is 1 hour. The minimum permitted interval is 1 minute. Can be expressed as a positive number of seconds, minutes or hours. If no time unit is provided, seconds is assumed.	1m
`[license]` `license_warnings_update_interval`	`<nonnegative integer>`Specifies a time period, in seconds, for license manager to update license warnings in Splunk Web bulletin messages. More License manager checks at every second the last time it updated the warnings, and updates if this time period has elapsed. Increase this value for very large deployments that contain very large number of source types. The minimum permitted interval is 10. The maximum permitted interval is 3600, equivalent to 1 hour. If set to the special value of 0, the license manager automatically tunes this setting to accommodate the size of the deployment.	0
`[license]` `strict_pool_quota`	`<boolean>`Toggles strict pool quota enforcement. More A value of "true" means members of pools receive warnings for a given day if usage exceeds pool size regardless of whether overall stack quota was exceeded A value of "false" means members of pool only receive warnings if both pool usage exceeds pool size AND overall stack usage exceeds stack size	true
`[license]` `pool_suggestion`	`<string>`Suggest a pool to the manager for this peer. More The manager uses this suggestion if the manager doesn't have an explicit rule mapping the peer to a given pool (ie...no peer list for the relevant license stack contains this peer explicitly) If the pool name doesn't match any existing pool, it is ignored, no error is generated This setting is intended to give an alternative management option for pool/peer mappings. When onboarding an indexer, it may be easier to manage the mapping on the indexer itself via this setting rather than having to update server.conf on manager for every addition of new indexer NOTE: If you have multiple stacks and a peer maps to multiple pools, this feature is limited in only allowing a suggestion of a single pool; This is not a common scenario however. No default. (which means this feature is disabled)
`[license]` `lm_uri`	`<comma-separated list>`A list of the URIs of license managers that this instance is to use when in High Availability Redundancy Mode. More High Availability Redundancy mode lets you use multiple license managers behind a load balancer. Separate multiple entries with commas. If you give this setting a value, that value cannot be empty. This setting is valid only when you enable High Availability Redundancy mode, which requires a special license and is only available to select customers.	No default
`[license]` `lm_ping_interval`	`<positive integer>`How often, in seconds, that license managers communicate with each other to check if they are all online and have the same license. More This setting is valid only when you enable High Availability Redundancy mode, which requires a special license and is only available to select customers.	86400 (once a day)
`[license]` `request_full_license_info`	`<boolean>`Controls the amount of license information that is synchronized between this peer and the license manager. More By default, only aggregated information from the license stack for add-ons, feature flags, and license keys is exchanged. If an application requires detailed information about its license, the license peer, such as the search head, receives all license details.	false

`[lmpool:auto_generated_pool_forwarder]`

This is the auto generated pool for the forwarder stack

Setting	Description	Default
`[lmpool:auto_generated_pool_forwarder]` `description`	`<textual description of this license pool>`MAX indicates the total capacity of the license. You may have only 1 pool with MAX size in a stack. More The quota can also be specified as a specific size eg. 20MB, 1GB, etc.
`[lmpool:auto_generated_pool_forwarder]` `quota`	`MAX\|<maximum amount allowed by this license>`MAX indicates the total capacity of the license. You may have only 1 pool with MAX size in a stack. More The quota can also be specified as a specific size eg. 20MB, 1GB, etc.
`[lmpool:auto_generated_pool_forwarder]` `slaves`	`*\|<slave list>`DEPRECATED. Use the 'peers' setting instead.
`[lmpool:auto_generated_pool_forwarder]` `peers`	`\|<peer list>`An asterisk() indicates that any peer can connect to this pool. More You can also specify a comma separated peer GUID list.
`[lmpool:auto_generated_pool_forwarder]` `stack_id`	`forwarder`The stack to which this pool belongs.

`[lmpool:auto_generated_pool_free]`

This is the auto generated pool for the free stack.
Field descriptions are the same as that for the 'lmpool:auto_generated_pool_forwarder' setting.

`[lmpool:auto_generated_pool_enterprise]`

This is the auto generated pool for the enterprise stack.
Field descriptions are the same as that for the 'lmpool:auto_generated_pool_forwarder' setting.

`[lmpool:auto_generated_pool_fixed-sourcetype_<sha256 hash of srctypes>]`

This is the auto generated pool for the enterprise fixed srctype stack
Field descriptions are the same as that for the 'lmpool:auto_generated_pool_forwarder' setting.

`[lmpool:auto_generated_pool_download_trial]`

This is the auto generated pool for the download trial stack.
Field descriptions are the same as that for the "lmpool:auto_generated_pool_forwarder"

`[pooling]`

Setting	Description	Default
`[pooling]` `state`	`[enabled\|disabled]`UNSUPPORTED: This setting is no longer supported.
`[pooling]` `storage`	`<path to shared storage>`UNSUPPORTED: This setting is no longer supported.
`[pooling]` `app_update_triggers`	`true\|false\|silent`UNSUPPORTED: This setting is no longer supported.
`[pooling]` `lock.timeout`	`<time range string>`UNSUPPORTED: This setting is no longer supported.
`[pooling]` `lock.logging`	`<boolean>`UNSUPPORTED: This setting is no longer supported.
`[pooling]` `poll.interval.rebuild`	`<time range string>`UNSUPPORTED: This setting is no longer supported.
`[pooling]` `poll.interval.check`	`<time range string>`UNSUPPORTED: This setting is no longer supported.
`[pooling]` `poll.blacklist.<name>`	`<regex>`UNSUPPORTED: This setting is no longer supported.

`[imds]`

Setting	Description	Default
`[imds]` `imds_version`	`[v1\|v2]`Sets IMDS version for EC2 instances metadata endpoints. More This setting is AWS specific. Certain features of the Splunk platform use AWS Instance Metadata Service (IMDS) when hosted on EC2. IMDS is accessible from the instance via a link-local address. It provides metadata about the instance. v1 uses request/response method while v2 uses a session-oriented method to access IMDS. The version should match the setting used on your EC2 instance. More information about IMDS can be found in the AWS documentation.	v1

`[clustering]`

Setting	Description	Default
`[clustering]` `mode`	`[manager\|peer\|searchhead\|disabled]`Sets operational mode for this cluster node. More Only one manager may exist per cluster. Note: "manager" and "peer" replace the prior 'mode' values of "master" and "slave". The prior values are currently still supported, but they will be removed from the product in a future release.	disabled
`[clustering]` `master_uri`	`[<uri> \| clustermanager:<cm-name1>, clustermanager:<cm-name2>, ...]`DEPRECATED. Use the 'manager_uri' setting instead.
`[clustering]` `manager_uri`	`[<uri> \| clustermanager:<cm-name1>, clustermanager:<cm-name2>, ...]`There are two uses for this setting, one for 'mode=peer' and 'mode=searchhead', and another for 'mode=manager'. More For 'mode=peer' and 'mode=searchhead': Specify the URI of the cluster manager that the peer or search head connects to. An example of <uri>: <scheme>://<hostname>:<port> For 'mode=searchhead' only: If the search head belongs to multiple clusters, specify the manager URIs in a comma separated list. For 'mode=manager': Only valid if 'manager_switchover_mode=auto\|manual'. In this mode, a list of cluster manager stanzas [clustermanager:<cm-nameX>] must be provided. Those managers participate in the manager redundancy feature for the indexer cluster. This list must be exactly identical in all the participating manager instances. The list of managers serves as a priority list, where a manager earlier in the list has higher priority than a manager later in the list. When two managers start up together, they detect each other's presence. To determine which manager will be active and which will be standby, they use the priority established by the list. Similarly, when 'manager_switchover_mode=auto', and there is one active cluster manager and multiple standby managers, if the active manager then goes down, the standby manager with highest priority becomes the active manager.
`[clustering]` `manager_switchover_mode`	`[disabled\|auto\|manual]`Set the cluster manager redundancy operation mode. More Only valid for 'mode=manager'. If set to "disabled", the cluster manager does not operate with redundancy. The values "auto" and "manual" are valid only when the 'manager_uri' setting in server.conf includes multiple cluster manager values. If set to "auto", an eligible "standby" cluster manager will try to automatically set its redundancy state to "active" upon consecutive loss of heartbeat to the manager which is currently in active state. If set to "manual", there is no automatic change of redundancy state to "active" during heartbeat failure, but there can be other scenarios, where the redundancy state may change automatically for some manager instances, as explained below: An eligible "standby" cluster manager will not set its redundancy state to "active" upon consecutive loss of heartbeat to the manager which is currently in active state. The administrator must manually change the cluster manager redundancy state to "active" or "standby". However, when the administrator initiates a redundancy state change request to one of the managers, the given manager may communicate with other managers internally and can change their redundancy states appropriately so that it can move to the correct redundancy state as requested by the administrator. Cluster manager redundancy solution is closely related to the general Splunk Enterprise deployment topology and network environment. In redundancy mode, the effectiveness of the chosen 'manager_switchover_mode' can be dependent on the actual network architecture that connects the peer nodes with the cluster manager, for example, DNS or load-balancer based deployment. Contact Splunk Professional Services for guidance on implementing cluster manager redundancy.	disabled
`[clustering]` `advertised_disk_capacity`	`<integer>`Only valid for 'mode=peer'. More Percentage to use when advertising disk capacity to the cluster manager. This is useful for modifying weighted load balancing in indexer discovery. For example, if you set this to 50 for an indexer with a 500GB disk, the indexer advertises its disk size as 250GB, not 500GB. Acceptable value range is 10 to 100.	100
`[clustering]` `pass4SymmKey`	`<string>`Secret shared among the nodes in the cluster to prevent any arbitrary node from connecting to the cluster. If a peer or search head is not configured with the same secret as the manager, it is not able to communicate with the manager. More If 'pass4SymmKey' is not set in the [clustering] stanza, Splunk software looks for the key in the [general] stanza. Unencrypted passwords must not begin with "$1$", as Splunk software uses this substring to determine if the password is already encrypted.	No default
`[clustering]` `pass4SymmKey_minLength`	`<integer>`The minimum length, in characters, that a 'pass4SymmKey' should be for a particular stanza. More When you start the Splunk platform, if the 'pass4SymmKey' is shorter in length than what you specify with this setting, the platform warns you and advises that you change the pass4SymKey. If you use the CLI to modify 'pass4SymmKey' to a value that is shorter than what you specify with this setting, the platform warns you and advises that you change the pass4SymKey.	12
`[clustering]` `service_interval`	`<zero or positive integer>`Only valid when 'mode=manager'. More How often, in seconds, that the manager runs its service loop. In its service loop, the manager checks the state of the peers and the buckets in the cluster and also schedules corrective action, if possible, for buckets that are not in compliance with replication policies. A special default value of 0 indicates an auto mode where the service interval for the next service call is determined by the time taken by previous call. It also sets the minimum service interval to be 0.5 second. Service interval is bounded by the values 1 and the 'max_auto_service_interval' setting. If the previous service call takes more than 'max_auto_service_interval' seconds, the next service interval is set to 'max_auto_service_interval' seconds.	0
`[clustering]` `service_execution_threshold_ms`	`<zero or positive integer>`Only valid when 'mode=manager'. More Specifies, in milliseconds, the maximum period for one execution of the manager's service loop. This setting is useful for large clusters with large numbers of buckets, to prevent the service loop from blocking other operations for significant amounts of time.	1500
`[clustering]` `deferred_cluster_status_update`	`<boolean>`Only valid when 'mode=manager'. More A value of "true" means that SF/RF met (complete cluster state) checks are performed lazily for optimal performance, only when CM is busy with cluster maintenance operations (for example, peer addition, fix ups, data rebalance). A value of "false" means that SF/RF met checks are performed relatively more aggressively to improve accuracy, increasing CM overhead and slowing down cluster maintenance operations (e.g peer addition, fix ups, data rebalance). NOTE: It is recommended to be set as "true" with high number of indexers and buckets.	true
`[clustering]` `deferred_rest_api_update`	`<boolean>`Only valid when 'mode=manager'. More A value of "true" means the manager responds to a REST API call from a source peer immediately. It might defer part of the actions related to the call until it completes already pending work. A value of "false" means the manager finishes all work for a received REST API call and only then responds to the source peer. The response might be delayed if the manager is busy with other work.	true
`[clustering]` `max_fixup_time_ms`	`<zero or positive integer>`Only valid for 'mode=manager'. More How long, in milliseconds, each fixup level runs before short circuiting to continue to the next fixup level. This introduces an upper bound on each service level, and likewise introduces an upper bound on the full service() call. This setting is useful for larger clusters that have lots of buckets, where service() calls can consume a significant amount of time blocking other operations. 0 denotes that there is no max fixup timer.	1000
`[clustering]` `max_delayed_updates_time_ms`	`<zero or positive integer>`Only valid for 'mode=manager'. More How long, in milliseconds, the cluster manager can continuously serve the delayed jobs before quitting to run other jobs. This setting is useful for larger clusters that have a large number of peer nodes and indexes, where customer manager could occasionally receive thousands of REST APIs in a short period. Do not change this setting without first consulting with Splunk Support. 0 denotes that there is no limit to how long the delayed jobs thread can run continuously.	1000
`[clustering]` `primary_src_persist_secs`	`<zero or positive integer>`Only valid for 'mode=manager'. More For a warm bucket, this setting specifies the interval after the bucket's latest time that a primary rebalance operation attempts to assign the primary to the copy on the source peer node. Once the interval is exceeded, the rebalance operation no longer considers the bucket's origin when assigning its primary. For a hot bucket, a non-zero value causes the primary to always reside with the source's hot bucket. Do not change this setting without first consulting with Splunk Support. If set to 0, the rebalance operation does not consider bucket origin when assigning primaries, for both hot and warm buckets.	604800 (1 week, 60 * 60 * 24 * 7 seconds)
`[clustering]` `cm_heartbeat_period`	`<non-zero positive integer>`Only valid for 'mode=manager' and 'manager_switchover_mode=auto\|manual'. More Determines the frequency, in seconds, of cluster manager to cluster manager heartbeat.	1
`[clustering]` `cm_max_hbmiss_count`	`<non-zero positive integer>`Only valid for 'mode=manager' and 'manager_switchover_mode=auto\|manual'. More The maximum number of consecutive heartbeat misses allowed before a cluster manager in standby state triggers the switchover sequence.	3
`[clustering]` `cm_com_timeout`	`<integer>`The timeout, in seconds, used in communications between cluster managers in redundancy mode. More Only valid with 'mode=manager' and 'manager_switchover_mode=auto\|manual'. Depending on the type of message being exchanged, triggering a timeout can result in a variety of consequences. For example, if the timeout is triggered for a heartbeat message, and the missed heartbeat count exceeds the value of 'cm_max_hbmiss_count', a manager switchover will be triggered, if 'manager_switchover_mode=auto'.	10
`[clustering]` `cxn_timeout`	`<integer>`The low-level timeout, in seconds, for establishing connection between cluster nodes.	60
`[clustering]` `send_timeout`	`<integer>`The low-level timeout, in seconds, for sending data between cluster nodes.	60
`[clustering]` `rcv_timeout`	`<integer>`The low-level timeout, in seconds, for receiving data between cluster nodes.	60
`[clustering]` `rep_cxn_timeout`	`<integer>`Valid only for 'mode=peer'. More The low-level timeout, in seconds, for establishing connection for replicating data.	60
`[clustering]` `rep_send_timeout`	`<integer>`Only valid for 'mode=peer'. More The low-level timeout, in seconds, for sending replication slice data between cluster nodes. This is a soft timeout. When this timeout is triggered on a source peer, it tries to determine if target is still alive. If the target is still alive, it resets the timeout for another 'rep_send_timeout' seconds and continues. If target has failed or the cumulative timeout has exceeded the 'rep_max_send_timeout', replication fails.	60
`[clustering]` `rep_rcv_timeout`	`<integer>`Only valid for 'mode=peer'. More Lowlevel timeout, in seconds, for receiving acknowledgment data from peers. This is a soft timeout. When this timeout is triggered on source peer, it tries to determine if target is still alive. If it is still alive, it reset the timeout for another 'rep_send_timeout' interval and continues. If target has failed or cumulative timeout has exceeded 'rep_max_rcv_timeout', replication fails.	60
`[clustering]` `rep_max_send_timeout`	`<integer>`Only valid for 'mode=peer'. More Maximum send timeout, in seconds, for sending replication slice data between cluster nodes. On rep_send_timeout source peer determines if total send timeout has exceeded 'rep_max_send_timeout'. If so, replication fails. If cumulative 'rep_send_timeout' exceeds 'rep_max_send_timeout', replication fails. For a standalone indexer, changes to this setting are dynamically reloadable and do not require a restart. For indexer clusters, changes to this setting trigger a rolling restart of peer nodes.	180 (3 minutes)
`[clustering]` `rep_max_rcv_timeout`	`<integer>`Only valid for 'mode=peer'. More Maximum cumulative receive timeout, in seconds, for receiving acknowledgment data from peers. On 'rep_rcv_timeout', the source peer determines if the total receive timeout has exceeded 'rep_max_rcv_timeout'. If so, replication fails. For a standalone indexer, changes to this setting are dynamically reloadable and do not require a restart. For indexer clusters, changes to this setting trigger a rolling restart of peer nodes.	180 (3 minutes)
`[clustering]` `search_files_retry_timeout`	`<integer>`Only valid for 'mode=peer'. More Timeout, in seconds, after which request for search files from a peer is aborted. To make a bucket searchable, search specific files are copied from another source peer with search files. If search files on source peers are undergoing changes, the source peer asks the requesting peer to retry after some time. If the cumulative retry period exceeds the specified timeout, the requesting peer aborts the request and requests search files from another peer in the cluster that might have search files.	600 (10 minutes)
`[clustering]` `re_add_on_bucket_request_error`	`<boolean>`Valid only for 'mode=peer'. More Whether or not a peer re-adds itself to the cluster manager if the manager returns an error on any bucket request. A value of "true" means the peer re-adds itself to the cluster manager if cluster manager returns an error on any bucket request. On re-add, peer updates the manager with the latest state of all its buckets. A value of "false" means the peer doesn't re-add itself to the cluster manager. Instead, it updates the manager with those buckets that manager returned an error.	false
`[clustering]` `decommission_search_jobs_wait_secs`	`<unsigned integer>`Valid only for 'mode=peer'. More The maximum time, in seconds, that a peer node waits for search jobs to finish before it transitions to the 'down' or 'GracefulShutdown' state, in response to the 'splunk offline' or 'splunk offline --enforce-counts' command. NOTE: When using this setting, the 'decommission_search_jobs_wait_secs' setting in the '[general]' stanza must remain set to its default value. You do not need to restart the cluster peer when making changes to this setting. This setting reloads automatically.	180 (3 minutes)
`[clustering]` `decommission_node_force_timeout`	`<seconds>`Valid only for 'mode=peer' and during node offline operation. More The maximum time, in seconds, that a peer node waits for searchable copy reallocation jobs to finish before it transitions to the 'down' or 'GracefulShutdown' state. This period begins after the peer node receives a 'splunk offline' command or its '/cluster/slave/control/control/decommission' REST endpoint is accessed. This attribute is not applicable to the "--enforce-counts" version of the “splunk offline" command	300 seconds
`[clustering]` `decommission_force_finish_idle_time`	`<zero or positive integer>`Valid only for 'mode=manager'. More The time, in minutes, that the manager waits before forcibly finishing the decommissioning of a peer when there is no progress in the associated fixup activity. A value of zero (0) means that the manager does not forcibly finish decommissioning.	0
`[clustering]` `rolling_restart`	`restart\|shutdown\|searchable\|searchable_force`Only valid for 'mode=manager'. More Determines whether indexer peers restart or shutdown during a rolling restart. If set to "restart", each peer automatically restarts during a rolling restart. If set to "shutdown", each peer is stopped during a rolling restart, and the customer must manually restart each peer. If set to "searchable", the cluster attempts a best effort to maintain a searchable state during the rolling restart by reassigning primaries from peers that are about to restart to other searchable peers, and performing a health check to ensure that a searchable rolling restart is possible. If set to "searchable_force", the cluster performs a searchable rolling restart, but overrides the health check and enforces 'decommission_force_timeout' and 'restart_inactivity_timeout'. If set to "searchable" or "searchable_force", scheduled searches are deferred or run during the rolling restart based on the 'defer_scheduled_searchable_idx' setting in 'savedsearches.conf'. You do not need to restart the cluster manager when making changes to this setting. This setting reloads automatically.	restart
`[clustering]` `searchable_rolling_peer_state_delay_interval`	`<zero or positive integer>`Only valid for 'mode=manager'. More Specifies an extra time interval, in seconds, during which the peer remains in the ReassigningPrimaries state. Extending the amount of time the peer remains in the ReassigningPrimaries state gives the peer more time to complete inflight searches and ingest events. This also reduces the impact of incomplete searches and bucket corruption, which can impede the searchable rolling restart process.	60
`[clustering]` `searchable_rolling_site_down_policy`	`full\|most\|half`Only valid for 'mode=manager' and is only used if 'multisite=true' and 'site_by_site=true'. More Sets the policy for calculating the maximum number of peers in a site allowed to shutdown at the same time during a searchable rolling restart. If set to 'full', the manager will allow an entire site to shutdown at once if there are searchable copies of buckets available in at least 3 sites. If set to 'most', the manager will maintain a few peers in a site to act as hot bucket streaming targets, and shutdown the other peers. At least one peer is available as a streaming target, but there can be more depending on the cluster's search factor. The 'most' policy attempts to speed up the rolling restart more aggressively than 'half', at the expense of a longer period fixing up replication and search factors afterwards. If set to 'half', the manager will maintain half the peers in a site to act as hot bucket streaming targets, and shutdown the other peers. The maximum number of peers allowed down at one time is the smallest peer count between 'percent_peers_to_restart' and 'searchable_rolling_site_down_policy'.	half
`[clustering]` `rolling_restart_condition`	`up\|batch_adding\|starting`Only valid for 'mode=manager'. More Determines the target peer status the manager waits for, when restarting a peer during a rolling restart, before it restarts other peers. If set to "up", the manager will wait for a restarting peer to reach the 'Up' status before restarting other peers. A peer reaches 'Up' status when it has finished reporting all of its buckets to the manager. This option will always respect 'percent_peers_to_restart'. If set to "batch_adding", the manager will wait for a restarting peer to reach the 'BatchAdding' status before restarting other peers. A peer reaches 'BatchAdding' status when it is in the process of reporting its buckets to the manager. This option will respect 'percent_peers_to_restart' as long as the current restarting peer finishes adding before the next restarting peer finishes shutting down, which is extremely likely. If set to "starting", the manager will wait for a restarting peer to reach the 'Starting' status before restarting other peers. A peer reaches 'Starting' status when it first starts up and is in the process of scanning its buckets on disk. This option is the fastest, but may not always respect 'percent_peers_to_restart'.	batch_adding
`[clustering]` `site_by_site`	`<boolean>`Only valid for 'mode=manager' and 'multisite=true'. More Whether or not the manager limits peer restarts to one site at a time during a rolling restart. A value of "true" means the manager restarts peers from one site at a time, waiting for all peers from a site to restart before moving on to another site, during a rolling restart. A value of "false" means the manager randomly selects peers to restart, from across all sites, during a rolling restart.	true
`[clustering]` `decommission_force_timeout`	`<zero or positive integer>`Only valid for 'mode=manager'. More Only valid for 'rolling_restart=searchable_force'. The amount of time, in seconds, the cluster manager waits for a peer in primary decommission status to finish primary reassignment and restart, during a searchable rolling restart with timeouts. Differs from 'decommission_force_finish_idle_time' in its default value and its presence only during a searchable rolling restart with timeouts. If you set this parameter to 0, it is automatically reset to default value. Maximum accepted value is 1800 (30 minutes).	180 (3 minutes)
`[clustering]` `restart_inactivity_timeout`	`<zero or positive integer>`Only valid for 'mode=manager'. More Only valid for 'rolling_restart=searchable_force'. The amount of time, in seconds, that the manager waits for a peer to restart and rejoin the cluster before it considers the restart a failure and proceeds to restart other peers. More specifically, the amount of time that the manager waits for a peer in the 'Down' status to transition to 'BatchAdding' or 'Up' status. A value of zero (0) means that the manager waits indefinitely for a peer to restart.	600 (10 minutes)
`[clustering]` `rebalance_pipeline_batch_size`	`<integer>`Valid only for 'mode=manager'. More Valid only for 'searchable_rebalance=true'. The maximum number of buckets for a batch entering the excess bucket removal phase of the rebalance pipeline. You do not need to restart the cluster manager when making changes to this setting. This setting reloads automatically.	60
`[clustering]` `rebalance_primary_failover_timeout`	`<zero or positive integer>`Valid only for 'mode=manager'. More Valid only for 'searchable_rebalance=true'. The maximum length of time, in seconds, that the manager waits for primacy to be reassigned from the batch of excess buckets to other buckets.	75
`[clustering]` `rebalance_newgen_propagation_timeout`	`<zero or positive integer>`Valid only for 'mode=manager'. More Valid only for 'searchable_rebalance=true'. The amount of time, in seconds, that the manager waits for the search heads to get the newly committed generation after the discarded buckets' primacy has been reassigned.	60 (1 minute)
`[clustering]` `rebalance_search_completion_timeout`	`<integer>`Valid only for 'mode=manager'. More Valid only for 'searchable_rebalance=true'. The amount of time, in seconds, that the manager waits for older generation searches on indexers to complete before removing any excess buckets. You do not need to restart the cluster manager when making changes to this setting. This setting reloads automatically.	180 (3 minute)
`[clustering]` `searchable_rebalance`	`<boolean>`Valid only for 'mode=manager'. More Controls whether searches can continue uninterrupted during data rebalancing. You do not need to restart the cluster manager when making changes to this setting. This setting reloads automatically.	false
`[clustering]` `multisite`	`<boolean>`Applicable in 'mode=manager' and 'mode=searchhead'. More In 'mode=manager': Indicates if the cluster manager is operating in a multisite configuration. When set to "true", it enables multisite clustering features. It's crucial to ensure that site parameters on all peers are set accordingly. In 'mode=searchhead': Determines whether the search head should operate in multisite mode. If "true", the search head is part of a multisite cluster and should have the 'site' attribute set in the [general] stanza. When part of a multisite cluster, the search head will utilize search affinity based on the 'site' parameter.	false
`[clustering]` `replication_factor`	`<positive integer>`Only valid for 'mode=manager'. More Determines how many copies of rawdata are created in the cluster. Use 'site_replication_factor' instead of this in case 'multisite' is turned on. Must be greater than 0.	3
`[clustering]` `site_replication_factor`	`<comma-separated string>`Only valid for 'mode=manager' and is only used if 'multisite=true'. More This specifies the per-site replication policy for any given bucket represented as a comma-separated list of per-site entries. Currently specified globally and applies to buckets in all indexes. Each entry is of the form <site-id>:<positive integer> which represents the number of copies to make in the specified site Valid site-ids include two mandatory keywords and optionally specific site-ids from site1 to site63 The mandatory keywords are: - origin: Every bucket has a origin site which is the site of the peer that originally created this bucket. The notion of 'origin' makes it possible to specify a policy that spans across multiple sites without having to enumerate it per-site. - total: The total number of copies needed for each bucket. When a site is the origin, it could potentially match both the origin and a specific site term. In that case, the max of the two is used as the count for that site. The total must be greater than or equal to sum of all the other counts (including origin). The difference between total and the sum of all the other counts is distributed across the remaining sites. Example 1: site_replication_factor = origin:2, total:3 Given a cluster of 3 sites, all indexing data, every site has 2 copies of every bucket ingested in that site and one rawdata copy is put in one of the other 2 sites. Example 2: site_replication_factor = origin:2, site3:1, total:3 Given a cluster of 3 sites, 2 of them indexing data, every bucket has 2 copies in the origin site and one copy in site3. So site3 has one rawdata copy of buckets ingested in both site1 and site2 and those two sites have 2 copies of their own buckets.	origin:2, total:3
`[clustering]` `search_factor`	`<positive integer>`Only valid for 'mode=manager'. More Determines how many buckets have index structures pre-built. Must be less than or equal to the 'replication_factor' setting and greater than 0.	2
`[clustering]` `site_search_factor`	`<comma-separated list>`Only valid for 'mode=manager' and is only used if 'multisite=true'. More This specifies the per-site policy for searchable copies for any given bucket represented as a comma-separated list of per-site entries. This is similar to the 'site_replication_factor' setting. See that entry for more information on the syntax.	origin:1, total:2
`[clustering]` `ack_factor`	`<positive integer>`Sets the number of copies of incoming data that must be saved across the indexer cluster before an acknowledgement (ACK) is returned from the source peer to the forwarder. More For example, a value of 2 means that two copies of the incoming data must be saved on cluster peer nodes - one copy on the source node and another copy on one of the target nodes. Valid only if 'useACK=true' and 'mode=peer'. Supported values range from 0 to the replication factor. When configured to 1, the acknowledgement is sent immediately after the incoming data is written to the source peer's disk. The default value of 0 signifies the replication factor. For example, if the cluster has a replication factor of 3, the value of 0 requires that 3 copies of the incoming data be saved locally on peer nodes before the acknowledgement is returned to the forwarder. This setting must be configured to the same value on all peers in the cluster.	0
`[clustering]` `available_sites`	`<comma-separated list>`Only valid for 'mode=manager' and is only used if 'multisite=true'. More This is a comma-separated list of all the sites in the cluster. If 'multisite=true' then 'available_sites' must be explicitly set. Example: available_sites = site1,site2,site3	an empty string
`[clustering]` `forwarder_site_failover`	`<comma-separated list>`Only valid for 'mode=manager' and is only used if 'multisite=true'. More This is a comma-separated list of pair of sites, "site1:site2", in the cluster. If 'multisite' is turned on 'forwarder_site_failover' must be explicitly set.	an empty string
`[clustering]` `site_mappings`	`<comma-separated list>`Only valid for 'mode=manager'. More When you decommission a site, you must update this attribute so that the origin bucket copies on the decommissioned site are mapped to a remaining active site. This attribute maps decommissioned sites to active sites. The bucket copies for which a decommissioned site is the origin site are then replicated to the active site specified by the mapping. Used only if multisite is true and sites have been decommissioned. Each comma-separated entry is of the form <decommissioned_site_id>:<active_site_id> or default_mapping:<default_site_id>. <decommissioned_site_id> is a decommissioned site and <active_site_id> is an existing site,specified in the 'available_sites' setting. For example, if available_sites=site1,site2,site3,site4 and you decommission site2, you can map site2 to a remaining site such as site4, like this: site2:site4 . If a site used in a mapping is later decommissioned, its previous mappings must be remapped to an available site. For instance, if you have the mapping site1:site2 but site2 is later decommissioned, you can remap both site1 and site2 to an active site3 using the following replacement mappings - site1:site3,site2:site3. Optional entry with syntax default_mapping:<default_site_id> represents the default mapping, for cases where an explicit mapping site is not specified. For example: default_mapping:site3 maps any decommissioned site to site3, if they are not otherwise explicitly mapped to a site. There can only be one such entry. Example 1: site_mappings = site1:site3,default_mapping:site4. The cluster must include site3 and site4 in available_sites, and site1 must be decommissioned. The origin bucket copies for decommissioned site1 is mapped to site3. Bucket copies for any other decommissioned sites is mapped to site4. Example 2: site_mappings = site2:site3 The cluster must include site3 in available_sites, and site2 must be decommissioned. The origin bucket copies for decommissioned site2 is mapped to site3. This cluster has no default. Example 3: site_mappings = default_mapping:site5 The specified cluster must include site5 in available_sites. The origin bucket copies for any decommissioned sites is mapped onto site5.	an empty string
`[clustering]` `constrain_singlesite_buckets`	`<boolean>`Only valid for 'mode=manager' and is only used if multisite is true. More Specifies whether the cluster keeps single-site buckets within one site in multisite clustering. When this setting is "true", buckets in a single site cluster do not replicate outside of their site. The buckets follow 'replication_factor' 'search factor' policies rather than 'site_replication_factor' 'site_search_factor' policies. This is to mimic the behavior of single-site clustering. When this setting is "false", buckets previously created in non-multisite clusters can replicate across sites, and must meet the specified 'site_replication_factor' and 'site_search_factor' policies.	true
`[clustering]` `heartbeat_timeout`	`<positive integer>`Only valid for 'mode=manager'. More Specifies, in seconds, when the manager considers a peer down. After a peer is down, the manager initiates fixup steps to replicate buckets from the dead peer to its peers.	60
`[clustering]` `access_logging_for_heartbeats`	`<boolean>`Only valid for 'mode=manager'. More Whether or not the manager logs peer heartbeats to the splunkd_access.logEnables/disables logging to the splunkd_access.log file for peer heartbeats. You do not have to restart the manager to set this config parameter. Instead, run the cli command on the manager: % splunk edit cluster-config -access_logging_for_heartbeats <<boolean>>	false (logging disabled)
`[clustering]` `restart_timeout`	`<positive integer>`Only valid for 'mode=manager'. More The amount of time, in seconds, the manager waits for a peer to come back when the peer is restarted, to avoid the overhead of trying to fixup the buckets that were on the peer. More specifically, the amount of time that the manager waits for a peer in the 'Restarting' status to transition to the 'Down' status. Note that this only works with the offline command or if the peer is restarted through the UI. You do not need to restart the cluster manager when making changes to this setting. This setting reloads automatically.	60
`[clustering]` `streaming_replication_wait_secs`	`<positive integer>`Only valid for 'mode=manager'. More The amount of time, in seconds, that a peer node waits to restart after receiving a restart request from the manager. During this period, the node remains in the eRestartRequested state. This time allows the ongoing replications on the peer to complete.	60
`[clustering]` `quiet_period`	`<positive integer>`Only valid for 'mode=manager'. More The amount of time, in seconds, that the manager is quiet upon start-up. However, if peers are still registering themselves with the manager after the initial quiet_period has elapsed, the manager continues to remain quiet until all peers finish registering, up to a total quiet time not to exceed 3x the specified 'quiet_period', including the initial quiet time. During the quiet time, the manager does not initiate any actions. At the end of this period, the manager builds its view of the cluster based on the registered information. It then starts normal operations. You do not need to restart the cluster manager when making changes to this setting. This setting reloads automatically.	60
`[clustering]` `manager_switchover_quiet_period`	`<positive integer>`Only valid for 'mode=manager' and 'manager_switchover_mode=auto\|manual'. More This setting determines the amount of time, in seconds, that the manager is quiet upon switchover from standby to active redundancy mode. However, if peers are still registering themselves with the manager after the initial manager_switchover_quiet_period has elapsed, the manager continues to remain quiet until all peers finish registering, up to a total quiet time not to exceed 3x the specified 'manager_switchover_quiet_period', including the initial quiet time. During the quiet time, the manager does not initiate any actions. At the end of this period, the manager builds its view of the cluster based on the registered information. It then starts normal operations. You do not need to restart the cluster manager when making changes to this setting. This setting reloads automatically.	60
`[clustering]` `reporting_delay_period`	`<positive integer>`Only valid for 'mode=manager'. More The acceptable amount of delay, in seconds, for reporting both unmet search and unmet replication factors for newly created buckets. This setting helps provide more reliable cluster status reporting by limiting updates to the specified granularity. You do not need to restart the cluster manager when making changes to this setting. This setting reloads automatically.	30
`[clustering]` `generation_poll_interval`	`<positive integer>`How often, in seconds, the search head polls the manager for generation information. More This setting is valid only if 'mode=manager' or 'mode=searchhead'. This setting reloads automatically and does not require a restart.	5
`[clustering]` `generation_max_staleness`	`<interval><unit>`Search heads will ignore search generation information from a cluster manager if it looks incomplete, either because it doesn't contain any search peers, or because it consists of a subset of the search head's known peers and at least one of the missing peers is currently joining the cluster. More This setting specifies how old a search head's own information can be before the search head forcefully accepts new search generation information from a cluster manager. When search performance is compromised by cluster manager restarts, increase 'generation_max_staleness' to the time it takes for all indexers to join the cluster. This setting is valid only when 'mode=searchhead'.	60s
`[clustering]` `max_peer_build_load`	`<integer>`Only valid for 'mode=manager'. More This is the maximum number of concurrent tasks to make buckets searchable that can be assigned to a peer.	2
`[clustering]` `max_peer_rep_load`	`<integer>`Only valid for 'mode=manager'. More This is the maximum number of concurrent non-streaming replications that a peer can take part in as a target.	5
`[clustering]` `max_peer_sum_rep_load`	`<integer>`Only valid for 'mode=manager'. More This is the maximum number of concurrent summary replications that a peer can take part in as either a target or source.	5
`[clustering]` `max_peer_truncate_load`	`<integer>`Only valid for 'mode=manager'. More The maximum number of concurrent truncations in which a peer can participate. A value of 0 means all truncations happen at once.	0
`[clustering]` `max_nonhot_rep_kBps`	`<integer>`Only valid for 'mode=peer'. More The maximum throughput, in kilobytes per second, for warm/cold/summary replications on a specific source peer. Similar to forwarder's 'maxKBps' setting in the limits.conf file. This setting throttles total bandwidth consumption for all outgoing non-hot replication connections from a given source peer. It does not throttle at the per-replication-connection, per-target level. This setting can be updated without restart on the source peers by using the command "splunk edit cluster-config" or by making the corresponding REST call. If set to 0, signifies unlimited throughput.	0
`[clustering]` `max_replication_errors`	`<integer>`Only valid for 'mode=peer'. More This is the maximum number of consecutive replication errors (currently only for hot bucket replication) from a source peer to a specific target peer. Until this limit is reached, the source continues to roll hot buckets on streaming failures to this target. After the limit is reached, the source no longer rolls hot buckets if streaming to this specific target fails. This is reset if at least one successful (hot bucket) replication occurs to this target from this source. The special value of 0 turns off this safeguard; so the source always rolls hot buckets on streaming error to any target. For a standalone indexer, changes to this setting are dynamically reloadable and do not require a restart. For indexer clusters, changes to this setting trigger a rolling restart of peer nodes.	3
`[clustering]` `searchable_targets`	`<boolean>`Only valid for 'mode=manager'. More Tells the manager to make some replication targets searchable even while the replication is going on. This only affects hot bucket replication for now.	true
`[clustering]` `searchable_target_sync_timeout`	`<integer>`Only valid for 'mode=peer'. More How long, in seconds, that a hot bucket replication connection can be inactive before a searchable target flushes out any pending search related in-memory files. Regular syncing - when the data is flowing through regularly and the connection is not inactive - happens at a faster rate (default of 5 secs controlled by streamingTargetTsidxSyncPeriodMsec in indexes.conf). The special value of 0 turns off this timeout behavior.	60
`[clustering]` `hot_bucket_slice_poll_frequency_ms`	`<positive integer>`The frequency, in milliseconds, at which a replication target peer of a hot bucket polls for new hot bucket slices from the remote store. More This setting only applies when 'mode' has a value of "peer" and 'indexes.conf:[<index>]/hotBucketStreaming.sendSlices' has a value of "true".	500
`[clustering]` `target_wait_time`	`<positive integer>`Only valid for 'mode=manager'. More Specifies the time, in seconds, that the manager waits for the target of a replication to register itself before it services the bucket again and potentially schedules another fixup. This setting is dynamically reloadable and does not require restart of cluster manager.	150 (2 minutes 30 seconds)
`[clustering]` `summary_wait_time`	`<positive integer>`Only valid when 'mode=manager' and 'summary_replication=true'. More Specifies the time, in seconds, that the manager waits before scheduling fixups for a newly 'done' summary that transitioned from 'hot_done'. This allows for other copies of the 'hot_done' summary to also make their transition into 'done', avoiding unnecessary replications.	660 (11 minutes)
`[clustering]` `commit_retry_time`	`<positive integer>`Only valid for 'mode=manager'. More Specifies the interval, in seconds, after which, if the last generation commit failed, the manager forces a retry. A retry is usually automatically kicked off after the appropriate events. This is just a backup to make sure that the manager does retry no matter what.	300 (5 minutes)
`[clustering]` `percent_peers_to_restart`	`<integer between 0-100>`Only valid for 'mode=manager'. More Suggested percentage of maximum peers to restart for rolling-restart. Actual percentage may vary due to lack of granularity for smaller peer sets. Regardless of setting, a minimum of 1 peer is restarted per round.	10
`[clustering]` `percent_peers_to_reload`	`<integer between 0-100>`Only valid for 'mode=manager'. More Suggested percentage of maximum peers to reload for bundle push. Actual percentage may vary due to lack of granularity for smaller peer sets. If set to 0, a minimum of 1 peer reloads the bundle per round.	100
`[clustering]` `max_peers_to_download_bundle`	`<positive integer>`Only valid for 'mode=manager'. More The maximum number of peers to simultaneously download the configuration bundle from the manager, in response to the 'splunk apply cluster-bundle' command. When a peer finishes the download, the next waiting peer, if any, begins its download. If set to 0, all peers try to download at once.	5
`[clustering]` `precompress_cluster_bundle`	`<boolean>`Only valid for 'mode=manager'. More Whether or not the manager compresses the configuration bundle files before it pushes them to peers. A value of "true" means the manager compresses the configuration bundle, which helps reduce network bandwidth consumption during the bundle push. Set this option to "true" only when SSL compression is off. Otherwise, the files will be compressed twice, which wastes CPU resources and does not save network bandwidth. To turn off SSL compression, set 'allowSslCompression = false' in server.conf on the manager. Compressed bundles are denoted by the suffix ".bundle.gz". Uncompressed bundles use the suffix ".bundle".	true
`[clustering]` `auto_rebalance_primaries`	`<boolean>`Only valid for 'mode=manager'. More Specifies if the manager should automatically rebalance bucket primaries on certain triggers. Currently the only defined trigger is when a peer registers with the manager. When a peer registers, the manager redistributes the bucket primaries so the cluster can make use of any copies in the incoming peer.	true
`[clustering]` `rebalance_primaries_execution_limit`	`<non-negative integer>`DEPRECATED. Use the 'rebalance_primaries_execution_limit_ms' setting instead.
`[clustering]` `rebalance_primaries_execution_limit_ms`	`<non-negative integer>`Only valid for 'mode=manager'. More The maximum period, in milliseconds, for one execution of the rebalance primary operation. This setting is useful for large clusters with large numbers of buckets, to prevent the primary rebalance operation from blocking other operations for significant amounts of time. The default value of 0 signifies auto mode. In auto mode, the cluster manager uses the value of the 'service_interval' setting to determine the maximum time for the operation.	0
`[clustering]` `commit_generation_execution_limit_ms`	`<non-negative integer>`Only valid for 'mode=manager'. More Specifies, in milliseconds, the maximum period for one execution of the committing pending generation. This setting is useful for large clusters with large numbers of buckets, to prevent the commit-generation operation from blocking other operations for significant amounts of time. The default value of 0 signifies auto mode. In auto mode, the cluster manager uses the value of the 'service_interval' setting to determine the maximum time for the operation. If 'service_interval' is auto, the range of this value will be within the range of 10ms and 25ms.	0
`[clustering]` `idle_connections_pool_size`	`<integer>`Only valid for 'mode=manager'. More Specifies how many idle http(s) connections that should be kept alive to reuse. Reusing connections improves the time it takes to send messages to peers in the cluster. -1 corresponds to "auto", letting the manager determine the number of connections to keep around based on the number of peers in the cluster.	-1
`[clustering]` `use_batch_mask_changes`	`<boolean>`Only valid for 'mode=manager'. More Specifies if the manager should process bucket mask changes in batch or individually one by one. Set to 'false' when there are version 6.1 peers in the cluster for backwards compatibility. You do not need to restart the cluster manager when making changes to this setting. This setting reloads automatically.	true
`[clustering]` `service_jobs_msec`	`<positive integer>`Only valid for 'mode=manager'. More The maximum time, in milliseconds, that the cluster manager spends in servicing finished jobs for each service call. Increase this if the 'metrics.log' file has very high 'current_size' values. You do not need to restart the cluster manager when making changes to this setting. This setting reloads automatically.	100 (0.1 seconds)
`[clustering]` `summary_replication`	`true\|false\|disabled`Valid for both 'mode=manager' and 'mode=peer'. More Cluster Manager: If set to "true", summary replication is enabled. If set to "false", summary replication is disabled, but can be enabled at runtime. If set to disabled, summary replication is disabled. Summary replication cannot be enabled at runtime. Peers: If set to "true" or "false", there is no effect. The indexer follows whatever setting is on the Cluster Manager. If set to "disabled", summary replication is disabled. The indexer does no scanning of summaries (increased performance during peers joining the cluster for large clusters).	false (for both Cluster Manager and Peers)
`[clustering]` `rebalance_threshold`	`<decimal>`Only valid for 'mode=manager'. More During rebalancing buckets amongst the cluster, this threshold is used as a percentage to determine when the cluster is balanced. Valid values are between 0.10 and 1.00. 1.00 is 100% indexers fully balanced.	0.90
`[clustering]` `max_auto_service_interval`	`<positive integer>`Only valid for 'mode=manager'. More Only valid when 'service_interval' is in auto mode. For example service_interval=0. Indicates the maximum value, in seconds, that service interval is bounded by when the 'service_interval' is in auto mode. If the previous service call took more than 'max_auto_service_interval' seconds, the next service call runs after 'max_auto_service_interval' seconds. You do not need to restart the cluster manager when making changes to this setting. This setting reloads automatically.	1
`[clustering]` `buckets_to_summarize`	`<primaries\|primaries_and_hot\|all>`Only valid for 'mode=manager'. More Determines which buckets are sent to '\| summarize' searches (searches that build report acceleration and data models). Set to "primaries" to apply only to primary buckets. Set to "primaries_and_hot" to also apply it to all hot searchable buckets. Set to "all" to apply the search to all buckets. If "summary_replication' is enabled, then 'buckets_to_summarize' defaults to "primaries_and_hot". Do not change this setting without first consulting with Splunk Support.	primaries
`[clustering]` `maintenance_mode`	`<boolean>`Only valid for 'mode=manager'. More To preserve the maintenance mode setting in case of manager restart, the manager automatically updates this setting in the etc/system/local/server.conf file whenever you enable or disable maintenance mode using the CLI or REST API. NOTE: Do not manually update this setting. Instead, use the CLI or REST API to enable or disable maintenance mode.
`[clustering]` `backup_and_restore_primaries_in_maintenance`	`<boolean>`Only valid for 'mode=manager'. More Determines whether the manager performs a backup/restore of bucket primary masks during maintenance mode or rolling-restart of cluster peers. A value of "true" means, restoration of primaries occurs automatically when the peers rejoin the cluster after a scheduled restart or upgrade.	false
`[clustering]` `max_primary_backups_per_service`	`<zero or positive integer>`Only valid for 'mode=manager'. More For use with the 'backup_and_restore_primaries_in_maintenance' setting. Determines the number of peers for which the manager backs up primary masks for each service call. The special value of 0 causes the manager to back up the primary masks for all peers in a single service call.	10
`[clustering]` `allow_default_empty_p4symmkey`	`<boolean>`Only valid for 'mode=manager'. More Affects behavior of manager during start-up, if 'pass4SymmKey'resolves to the null string or the default password ("changeme"). A value of "true" means the manager posts a warning but still launches. A value of "false" means the manager posts a warning and stops.	false
`[clustering]` `register_replication_address`	`<string>`Only valid for 'mode=peer'. More This is the address on which a peer is available for accepting replication data. This is useful in the cases where a peer host machine has multiple interfaces and only one of them can be reached by another splunkd instance. This must be either an IP address or fully qualified machine/domain name.	No default
`[clustering]` `register_forwarder_address`	`<string>`Only valid for 'mode=peer'. More This is the address on which a peer is available for accepting data from forwarder.This is useful in the cases where a splunk host machine has multiple interfaces and only one of them can be reached by another splunkd instance. This must be either an IP address or fully qualified machine/domain name.	No default
`[clustering]` `register_search_address`	`<string>`Only valid for 'mode=peer'. More This is the address that advertises the peer to search heads. This is useful in the cases where a splunk host machine has multiple interfaces and only one of them can be reached by another splunkd instance. This must be either an IP address or fully qualified machine/domain name.	No default
`[clustering]` `executor_workers`	`<positive integer>`Only valid if 'mode=manager' or 'mode=peer'. More Number of threads that can be used by the clustering thread pool. A value of 0 defaults to 1. This setting reloads automatically and does not require a restart.	10
`[clustering]` `local_executor_workers`	`<positive integer>`DEPRECATED.
`[clustering]` `manual_detention`	`on\|on_ports_enabled\|off`Only valid for 'mode=peer'. More Puts this peer node in manual detention.	off
`[clustering]` `allowed_hbmiss_count`	`<positive integer>`Only valid for 'mode=peer'. More Sets the count of number of heartbeat failures before the peer node disconnects from the manager.	3
`[clustering]` `buckets_per_addpeer`	`<non-negative integer>`Only valid for 'mode=peer'. More Controls the number of buckets for each add peer request. When a peer is added or re-added to the cluster, it sends the manager information for each of its buckets. Depending on the number of buckets, this could take a while. For example, a million buckets could require more than a minute of the manager's processing time. To prevent the manager from being occupied by this single task too long, you can use this setting to split large numbers of buckets into several "batch-add-peer" requests. If it is invalid or non-existent, the peer uses the default setting instead. If it is set to 0, the peer sends only one request with all buckets instead of batches. You do not need to restart the cluster peer when making changes to this setting. This setting reloads automatically.	1000
`[clustering]` `heartbeat_period`	`<non-zero positive integer>`Controls the interval, in seconds, with which the peer attempts to send heartbeats to the manager node. More Only valid for 'mode=peer'.	1
`[clustering]` `auto_fix_corrupt_buckets`	`<boolean>`Only valid for 'mode=manager'. More If set to "true", the manager performs automatic fixup of corrupted buckets. To fix a corrupted bucket, the manager fetches the current searchable events count from all copies of the bucket. It then selects a copy with the largest searchable events count as the canonical copy. The manager tells all peers holding copies with smaller events counts to discard their copies. The cluster then replicates the canonical copy as needed until the cluster holds the configured replication factor number of copies. The manager's peer nodes must be running a version that supports this feature. This feature is available only for non-SmartStore buckets. SmartStore buckets require manual fixup.	true
`[clustering]` `bucketsize_mismatch_strategy`	`smallest\|largest`Only valid for 'mode=manager'. More This setting determines how the manager decides which target peer's bucket copy is retained on the cluster when the source peer is not present at the time that a hot bucket is rolled, and there is a bucket size mismatch between the target peers A value of "largest" means the largest copy of the bucket on any target peer gets propagated to the other peers through fixups, overwriting all other copies. A value of "smallest" means the smallest copy of the bucket on any target peer gets propagated to the other peers through fixups, overwriting all other copies. Do not alter this value without contacting Splunk Support.	largest
`[clustering]` `remote_storage_upload_timeout`	`<non-zero positive integer>`Only valid for 'mode=peer'. More For a remote storage enabled index, this setting specifies the interval in seconds, after which target peers assume responsibility for uploading a bucket to the remote storage, if they do not hear from the source peer. For a standalone indexer, changes to this setting are dynamically reloadable and do not require a restart. For indexer clusters, changes to this setting trigger a rolling restart of peer nodes.	60 (1 minute)
`[clustering]` `report_remote_storage_bucket_upload_to_targets`	`<boolean>`Only valid for 'mode=peer' or 'mode=manager'. More For a remote storage enabled index, this setting specifies whether the source peer reports the successful bucket upload to target peers. This notification is used by target peers to cancel their upload timers and synchronize their bucket state with the uploaded bucket on remote storage. Do not change the value from the default unless instructed by Splunk Support. You do not need to restart the cluster manager when making changes to this setting. This setting reloads automatically.	false
`[clustering]` `remote_storage_retention_period`	`<non-zero positive integer>`Only valid for 'mode=manager'. More The interval, in seconds, after which the manager checks buckets in remote storage enabled indexes against the retention policy. It then triggers freeze operations on the cluster peers as necessary. This setting also determines the time that the manager waits following a restart before checking retention policy. For details on retention policies, examine the 'maxGlobalDataSizeMB' and 'frozenTimePeriodInSecs' settings. This setting is dynamically reloadable and does not require restart of cluster manager.	900 (15 minutes)
`[clustering]` `remote_storage_freeze_delay_period`	`<non-zero positive integer>`Only valid for 'mode=manager'. More The interval, in seconds, that the manager waits for any bucket that has recently rolled to warm or cold before potentially triggering freezing on the bucket. This ensures that buckets that have very recently rolled to warm or cold do not immediately roll to freezing. For example, if set to the default of 3600 seconds (one hour), a bucket that rolls to warm or cold waits at least one hour before subsequently rolling to frozen. (The bucket could typically continue in the warm or cold state for a much longer period of time, according to when it reaches the limit set by the data retention policy.)	3600 (60 minutes)
`[clustering]` `recreate_bucket_attempts_from_remote_storage`	`<positive integer>`Only valid for 'mode=manager'. More Controls the number of attempts the manager makes to recreate the bucket of a remote storage enabled index on a random peer node in these scenarios: Manager detects that the bucket is not present on any peers. A peer informs the manager about the bucket as part of the re-creation of an index. See 'recreate_index_attempts_from_remote_storage' setting. Re-creation of the bucket involves the following steps: 1. Manager provides a random peer with the bucket ID of the bucket that needs to be recreated. 2. Peer fetches the metadata of the bucket corresponding to this bucket ID from the remote storage. 3. Peer creates a bucket with the fetched metadata locally and informs the manager that a new bucket has been added. 4. Manager initiates fix-ups to add the bucket on the necessary number of additional peers to match the replication and search factors. If set to 0, disables the re-creation of the bucket.	10
`[clustering]` `recreate_bucket_max_per_service`	`<positive integer>`Only valid for 'mode=manager'. More Only applies when using remote storage enabled indexes. Controls the maximum number of buckets that the cluster can recreate during a service interval. Do not change the value from the default unless instructed by Splunk Support. If set to 0, recreating buckets will go at full speed.	20000
`[clustering]` `recreate_bucket_fetch_manifest_batch_size`	`<positive integer>`Only valid for 'mode=manager'. More Controls the maximum number of bucket IDs for which a peer attempts to initiate a parallel fetch of manifests at a time in the process of recreating buckets that have been requested by the manager. The manager sends this setting to all the peers that are involved in the process of recreating the buckets.	50
`[clustering]` `recreate_index_attempts_from_remote_storage`	`<positive integer>`Only valid for 'mode=manager'. More Controls the number of attempts the manager makes to recreate a remote storage enabled index on a random peer node when the manager is informed about the index by a peer. Re-creation of an index involves the following steps: 1. Manager pushes a bundle either when it is ready for service or when requested by the user. 2. Manager waits for the bundle to be applied successfully on the peer nodes. 3. Manager requests that a random peer node provide it with the list of newly added remote storage enabled indexes. 4. Manager distributes a subset of indexes from this list to random peer nodes. 5. Each of those peer nodes fetches the list of bucket IDs for the requested index from the remote storage and provides it to the manager. 6. The manager uses the list of bucket IDs to recreate the buckets. See recreate_bucket_attempts_from_remote_storage. If set to 0, disables the re-creation of the index.	10
`[clustering]` `recreate_index_fetch_bucket_batch_size`	`<positive integer>`Only valid for 'mode=manager'. More Controls the maximum number of bucket IDs that the manager requests a random peer node to fetch from remote storage as part of a single transaction for a remote storage enabled index. The manager uses the bucket IDs for re-creation of the index. See the 'recreate_index_attempts_from_remote_storage' setting.	2000
`[clustering]` `use_batch_remote_rep_changes`	`<boolean> or <positive integer>`Only valid for 'mode=manager'. More Specifies whether the manager processes bucket copy changes (to meet replication_factor and search_factor) in batch or individually. Also controls the maximum number of bucket replications that are processed in one replication batch. This is applicable to buckets belonging to remote storage enabled indexes only. Do not change this setting without consulting with Splunk Support. This setting is dynamically reloadable and does not require restart of cluster manager. If 'false' is specified, batching of buckets would be turned off If 'true' is specified, batching of buckets would be turned on, the maximum number of buckets processed per batch would be the system default (1000) If 0 is specified, batching of buckets would be turned off If <any non zero positive integer> is specified, batching of buckets would be turned on, and the maximum number of buckets processed per batch would be the value of the integer specified	1000
`[clustering]` `max_peer_batch_rep_load`	`<positive integer>`Only valid for 'mode=manager'. More This setting is applicable to buckets belonging to remote storage enabled indexes only. Only valid when 'use_batch_remote_rep_changes=true' This setting specifies the maximum number of concurrent batch replications that a peer node can take part in, as a source.	5
`[clustering]` `enable_primary_fixup_during_maintenance`	`<boolean>`Only valid for 'mode=manager'. More Specifies whether the manager performs primary fixups during maintenance mode. This gets overridden by searchable rolling restart. This setting is dynamically reloadable and does not require restart of cluster manager.	true
`[clustering]` `freeze_during_maintenance`	`<boolean>`Only valid for 'mode=manager'. More Specifies whether the manager will tell peers to freeze buckets during maintenance mode. This setting is dynamically reloadable and does not require restart of cluster manager.	false
`[clustering]` `assign_primaries_to_all_sites`	`<boolean>`Only valid for 'mode=manager' and 'multisite=true'. More Controls how the manager assigns bucket primary copies on a multisite cluster. If set to "true", the manager assigns a primary copy to each site defined in 'available_sites', as well as site0. If set to "false": The manager assigns a primary copy only to sites with a search head. Sites without search heads do not get primary copies. When a new site with a search head joins the cluster, or an existing site attains its first search head, the cluster manager gradually adds all buckets in the cluster to its fixup list to ensure that the site will be populated with primaries. If a site loses its search heads, no action is taken to remove existing primaries from the site. Setting this parameter to 'false' can significantly reduce the work of primary assignments, especially if search heads are only on site0 and search affinity is disabled.	false
`[clustering]` `log_bucket_during_addpeer`	`<boolean>`Only valid for 'mode=manager'. More Controls the log level for bucket information during add-peer activities. If set to "true", the manager logs bucket information to INFO level under CMMaster componenet during add-peer. If set to "false", the manager logs bucket information to DEBUG level under CMMaster component during add-peer. Set to 'false' for large clusters with large numbers of buckets.	false
`[clustering]` `max_concurrent_peers_joining`	`<nonzero integer>`Only valid for 'mode=manager'. More Limits the number of peers that are allowed to join the cluster at one time. The peer reports its buckets to the cluster manager upon first establishing a connection with the manager, and it finishes joining the cluster when all of its buckets have been reported. Once this limit is hit, any remaining peers check at one second intervals for an available slot to join the cluster. By limiting the number of peers that can join simultaneously, this setting can facilitate faster restart for some peers, thus more quickly restoring partial ingest to the cluster.	10
`[clustering]` `enable_parallel_add_peer`	`<boolean>`Only valid for 'mode=manager'. More Enables the cluster manager to accept and process multiple 'add peer' requests in parallel. The upper limit of concurrent 'add peer' requests that the manager can handle is limited by the 'max_concurrent_peers_joining setting'. When this feature is enabled, the largest recommended value for 'max_concurrent_peers_joining' is half the number of CPU cores of the indexer. For example, if the indexer has 24 CPU cores, the largest recommended value for 'max_concurrent_peers_joining' is 12. This setting is useful for clusters with large numbers of buckets and large numbers of indexers. It also improves the responsiveness of the cluster manager, helping to prevent unnecessary timeouts.	true
`[clustering]` `buckets_status_notification_batch_size`	`<positive integer>`Only valid for 'mode=peer'. More Controls the number of existing buckets IDs that the peer reports to the manager every notify_scan_period seconds. The manager then initiates fix-ups for these buckets. CAUTION: Do not modify this setting without guidance from Splunk personnel.	1000
`[clustering]` `notify_scan_period`	`<non-zero positive integer>`Only valid for 'mode=peer'. More Controls the frequency, in seconds, that the indexer handles the following options: 1. summary_update_batch_size 2. summary_registration_batch_size CAUTION: Do not modify this setting without guidance from Splunk personnel.	10
`[clustering]` `notify_scan_min_period`	`<non-zero positive integer>`Only valid for 'mode=peer'. More Controls the highest frequency, in milliseconds, that the indexer scans summary folders for summary updates/registrations. The notify_scan_period temporarily becomes notify_scan_min_period when there are more summary updates/registration events to be processed but has been limited due to either summary_update_batch_size or summary_registration_batch_size. CAUTION: Do not modify this setting without guidance from Splunk personnel.	10
`[clustering]` `notify_buckets_period`	`<non-zero positive integer>`Only valid for 'mode=peer'. More Controls the frequency, in milliseconds, that the indexer handles buckets_status_notification_batch_size CAUTION: Do not modify this setting without guidance from Splunk personnel.	10
`[clustering]` `notify_buckets_usage_period`	`<interval>`Only valid for 'mode=peer'. More Controls the frequency that the indexer sends bucket usage notifications to the cluster manager. If set to '0s' (0 seconds), indexers will not attempt to send bucket usage notifications to the cluster manager. CAUTION: Do not modify this setting without guidance from Splunk personnel.	1m (1 minute)
`[clustering]` `notify_buckets_usage_batch_size`	`<positive integer>`Only valid for 'mode=peer'. More Controls the batch size of bucket usage notifications sent by the indexer to the cluster manager. This setting specifies the maximum number of bucket usage notifications that can be batched together in a single message. CAUTION: Do not modify this setting without guidance from Splunk personnel.	2048
`[clustering]` `clustered_bucket_database_granularity`	`global \| index`Currently not supported. This setting is related to a feature that is still under development. More Only valid for 'mode=peer'. Specifies the level at which Splunk software creates search manifest files on search peers in an indexer cluster. Search manifest files list primary buckets for the search peer. This is not the same as .bucketManifest files, which list all buckets that reside on the host per index. A value of "global" means Splunk software creates a single search manifest file that spans all indexes on the search peer. A value of "index" means Splunk software creates a search manifest file per index. This setting is dynamically reloadable and does not require a restart of the Splunk instance. NOTE: Do not change this setting unless instructed to do so by Splunk Support.	global
`[clustering]` `max_usage_rebalance_retries`	`<positive integer>`Only valid for 'mode=manager'. More The maximum number of retry attemtps before the cluster manager gives up moving a bucket during bucket usage rebalancing. CAUTION: Do not modify this setting without guidance from Splunk personnel.	3
`[clustering]` `max_usage_rebalance_operations_per_service`	`<non-zero positive integer>`Only valid for 'mode=manager'. More The maximum number of operations which bucket usage rebalance will initiate per manager service period including bucket replications, bucket searchability changes, transferring of bucket usage data and removals of remaining excess buckets. CAUTION: Do not modify this setting without guidance from Splunk personnel.	50
`[clustering]` `bucket_usage_decay_half_life`	`<interval>`Only valid for 'mode=manager'. More The interval after which a bucket usage record will exponentially decay by half. The higher this parameter, the less weight is given to older usage statistics compared to the more recent usage statistics. The interval can be specified as a string for seconds, minutes, hours, days, etc. For example: 60s, 1m, 1h, 1d, etc. Must be greater than 0s (0 seconds).	7d (7 days)
`[clustering]` `usage_rebalance_bucket_movement_factor`	`<decimal>`Only valid for 'mode=manager'. More A number between 0 and 1, non-inclusive. The higher this parameter, the more buckets and peers will be deemed insignificant to the usage rebalance and will be skipped when selecting buckets to move. For a bucket to be moved during usage rebalance, the usage value for the bucket compared to the excess usage of the busy source peer must be at least this ratio. For a busy peer to be included in the usage rebalance, the busy peer must have excess usage which when compared to the average excess usage of all busy peers in the site, is at least this ratio. CAUTION: Do not modify this setting without guidance from Splunk personnel.	0.01
`[clustering]` `summary_update_batch_size`	`<non-zero positive integer>`Only valid for 'mode=peer'. More Controls the number of summary updates the indexer sends per batch to the manager every notify_scan_period. CAUTION: Do not modify this setting without guidance from Splunk personnel.	10
`[clustering]` `summary_registration_batch_size`	`<non-zero positive integer>`Only valid for 'mode=peer'. More Controls the number of summaries that get asynchronously registered on the indexer and sent as a batch to the manager every notify_scan_period. Caution: Do not modify this setting without guidance from Splunk personnel.	1000
`[clustering]` `enableS2SHeartbeat`	`<boolean>`Only valid for 'mode=peer'. More Splunk software monitors each replication connection for presence of a heartbeat, and if the heartbeat is not seen for 's2sHeartbeatTimeout' seconds, it closes the connection.	true
`[clustering]` `s2sHeartbeatTimeout`	`<integer>`This specifies the global timeout value, in seconds, for monitoring heartbeats on replication connections. More Splunk software closes a replication connection if heartbeat is not seen for 's2sHeartbeatTimeout' seconds. Replication source sends heartbeats every 30 seconds.	600 (10 minutes)
`[clustering]` `throwOnBucketBuildReadError`	`<boolean>`Valid only for 'mode=peer'. More A value of "true" means index clustering peer throws an exception if it encounters a journal read error while building the bucket for a new searchable copy. It also throws all the search & other files generated so far in this particular bucket build. A value of "false" means index clustering peer just logs the error and preserves all the search & other files generated so far & finalizes them as it cannot proceed further with this bucket.	false
`[clustering]` `cluster_label`	`<string>`Only valid for 'mode=manager'. More This specifies the label of the indexer cluster
`[clustering]` `warm_bucket_replication_pre_upload`	`<boolean>`Valid only for 'mode=peer'. More This setting applies to remote storage enabled indexes only. A value of "true" means the target peers replicate all warm bucket contents when necessary for bucket-fixing if the source peer has not yet uploaded the bucket to remote storage. A value of "false" means the target peers never replicate warm bucket contents. In either case the target peers replicate metadata only, once the source peer uploads the bucket to remote storage.	false
`[clustering]` `bucketsize_upload_preference`	`largest \| smallest`Valid only for 'mode=peer'. More This setting applies to remote storage enabled indexes only. This setting determines the criteria a target peer uses when deciding whether to overwrite a bucket copy uploaded to remote storage by another target peer. Target peers never overwrite copies uploaded by a source peer. When "largest" is selected, the largest copy of the bucket on any target peer gets uploaded. When "smallest" is selected, the smallest copy of the bucket on any target peer gets uploaded. Note, this and "bucketsize_mismatch_strategy" should follow same scheme. Do not alter this value without contacting Splunk Support.	largest
`[clustering]` `upload_rectifier_timeout_secs`	`<unsigned integer>`Valid only for 'mode=peer'. More This setting applies to remote storage enabled indexes only. When a peer uploads a bucket copy to remote storage, it checks, after a , timeout based on the value of this setting, to determine whether another peer overwrote the copy. Depending on the value of "bucketsize_upload_preference" it will determine if the bucket needs to be re-uploaded. This setting controls the timeout that the peer waits before checking.	2
`[clustering]` `localization_based_primary_selection`	`[disabled\|auto]`Only valid for 'mode=manager'. More This setting determines the behavior of the cluster manager when assigning primacy to SmartStore bucket copies. If set to 'auto', the cluster manager examines each copy's localization flag and assigns primacy to a bucket copy, if any, with existing localized content. If multiple peers have localized content for the bucket, the cluster manager assigns primacy to the copy on the peer with the least number of total primary bucket copies. If set to 'disabled' the localization flags of the buckets are not taken into account during primary assignment.	disabled
`[clustering]` `localization_update_batch_size`	`<non-zero positive integer>`Only valid for 'mode=peer'. More Controls the number of bucket localization updates the peer sends per batch to the manager every heartbeat_period. CAUTION: Do not modify this setting without guidance from Splunk personnel.	1000
`[clustering]` `corrupt_bucket_updates_batch_size`	`<non-zero positive integer>`Only valid for 'mode=peer'. More Controls the number of corrupt bucket updates the peer sends per batch to the manager every notify_buckets_period. CAUTION: Do not modify this setting without guidance from Splunk personnel.	100
`[clustering]` `enable_encrypt_bundle`	`<boolean>`Whether or not an indexer cluster manager encrypts sensitive fields from the 'encrypt_fields' setting when it creates an indexer clustering bundle. More A value of "true" means that indexer clustering bundle encryption is enabled. A value of "false" means that indexer clustering bundle encryption is disabled. NOTE: If you disable this setting, confirm that all fields in files in the configuration bundle on the manager node are not encrypted before you deploy the bundle to the peer nodes.	true

`[clustermanager:<cm-nameX>]`

Valid for 'mode=searchhead' when the search head belongs to multiple indexer clusters.
Valid for 'mode=manager' and 'manager_switchover_mode=auto|manual'.

Setting	Description	Default
`[clustermanager:<cm-nameX>]` `master_uri`	`<uri>`DEPRECATED. Use the 'manager_uri' setting instead.
`[clustermanager:<cm-nameX>]` `manager_uri`	`<string>`There are two uses for this setting, one for 'mode=searchhead', and another for 'mode=manager'. More For 'mode=searchhead': This represents the URI of the cluster manager that this search head should connect to. For 'mode=manager': Only valid if 'manager_switchover_mode=auto\|manual' This setting is the URI for the manager described by this stanza. Each cluster manager must include a separate copy of this stanza for each manager in the cluster, including itself. For example, if the cluster has three managers, each manager's configuration must include an identical set of three stanzas, one for each manager.
`[clustermanager:<cm-nameX>]` `pass4SymmKey`	`<string>`Secret shared among the nodes in the cluster to prevent any arbitrary node from connecting to the cluster. If a search head is not configured with the same secret as the manager, it not be able to communicate with the manager. More If it is not present here, the key in the clustering stanza is used. If it is not present in the clustering stanza, the value in the general stanza is used. Ignored when 'mode=manager' and 'manager_switchover_mode=auto\|manual'. In this mode, the 'pass4SymmKey' is picked up from the [clustering] stanza for connecting to all the managers defined in the [clustermanager] stanzas. Unencrypted passwords must not begin with "$1$", as this is used by Splunk software to determine if the password is already encrypted.	No default
`[clustermanager:<cm-nameX>]` `pass4SymmKey_minLength`	`<integer>`The minimum length, in characters, that a 'pass4SymmKey' should be for a particular stanza. More When you start the Splunk platform, if the 'pass4SymmKey' is shorter in length than what you specify with this setting, the platform warns you and advises that you change the pass4SymKey. If you use the CLI to modify 'pass4SymmKey' to a value that is shorter than what you specify with this setting, the platform warns you and advises that you change the pass4SymKey.	12
`[clustermanager:<cm-nameX>]` `site`	`<site-id>`Specifies the site this search head belongs to for this particular manager when multisite is enabled (see below). More Valid values for site-id include site0 to site63. The special value "site0" disables site affinity for a search head in a multisite cluster. It is only valid for a search head. Ignored when 'mode=manager' and 'manager_switchover_mode=auto\|manual'. In this mode, site id is picked up from the [general] stanza.
`[clustermanager:<cm-nameX>]` `multisite`	`<boolean>`Turns on the multisite feature for this manager_uri for the search head. More Make sure the manager has the multisite feature turned on. Make sure you specify the site in case this is set to true. If no configuration is found in the [clustermanager] stanza, the search head defaults to any value for 'site' that might be defined in the [general] stanza. Ignored when 'mode=manager' and 'manager_switchover_mode=auto\|manual'. In this mode, the multisite flag is picked up from the [clustering] stanza.	false

`[replication_port://<port>]`

Setting	Description	Default
`[replication_port://<port>]` `disabled`	`<boolean>`Set to true to disable this replication port stanza.	false
`[replication_port://<port>]` `listenOnIPv6`	`no\|yes\|only`Toggle whether this listening port listens on IPv4, IPv6, or both. More If not present, the setting in the [general] stanza is used.
`[replication_port://<port>]` `acceptFrom`	`<network_acl> ...`Lists a set of networks or addresses from which to accept connections. More Separate multiple rules with commas or spaces. Each rule can be in one of the following formats: 1. A single IPv4 or IPv6 address (examples: "10.1.2.3", "fe80::4a3") 2. A Classless Inter-Domain Routing (CIDR) block of addresses (examples: "10/8", "192.168.1/24", "fe80:1234/32") 3. A DNS name, possibly with a "" used as a wildcard (examples: "myhost.example.com", ".splunk.com") 4. "", which matches anything You can also prefix an entry with '!' to cause the rule to reject the connection. The input applies rules in order, and uses the first one that matches. For example, "!10.1/16, " allows connections from everywhere except the 10.1.. network.	"*" (accept from anywhere)

`[replication_port-ssl://<port>]`

This configuration is same as the [replication_port] stanza above, but uses SSL.

Setting	Description	Default
`[replication_port-ssl://<port>]` `disabled`	`<boolean>`Set to true to disable this replication port stanza.	false
`[replication_port-ssl://<port>]` `listenOnIPv6`	`no\|yes\|only`Toggle whether this listening port listens on IPv4, IPv6, or both. More If not present, the setting in the [general] stanza is used.
`[replication_port-ssl://<port>]` `acceptFrom`	`<string> ...`This setting is the same as the setting in the [replication_port] stanza.
`[replication_port-ssl://<port>]` `serverCert`	`<string>`Full path to file containing private key and server certificate. More The <path> must refer to a PEM format file.	No default
`[replication_port-ssl://<port>]` `sslPassword`	`<string>`See the description of 'sslPassword' under the [sslConfig] stanza for details on this setting.	No default
`[replication_port-ssl://<port>]` `password`	`<string>`DEPRECATED. Use 'sslPassword' instead.
`[replication_port-ssl://<port>]` `rootCA`	`<string>`DEPRECATED. Use '[sslConfig]/sslRootCAPath' instead.	No default
`[replication_port-ssl://<port>]` `cipherSuite`	`<string>`See the description of 'cipherSuite' under the [sslConfig] stanza for details on this setting. More The default can vary. See the 'cipherSuite' setting in the $SPLUNK_HOME/etc/system/default/server.conf file for the current default.
`[replication_port-ssl://<port>]` `sslVersions`	`<comma-separated list>`See the description of 'sslVersions' under the [sslConfig] stanza for details on this setting. More The default can vary. See the 'sslVersions' setting in the $SPLUNK_HOME/etc/system/default/server.conf file for the current default.
`[replication_port-ssl://<port>]` `ecdhCurves`	`<comma separated list>`See the description of 'ecdhCurves' under the [sslConfig] stanza for details on this setting. More The default can vary. See the 'ecdhCurves' setting in the $SPLUNK_HOME/etc/system/default/server.conf file for the current default.
`[replication_port-ssl://<port>]` `dhFile`	`<string>`See the description of 'dhFile' under the [sslConfig] stanza for details on this setting.	No default
`[replication_port-ssl://<port>]` `dhfile`	`<string>`DEPRECATED. Use 'dhFile' (with a capital F) instead.
`[replication_port-ssl://<port>]` `supportSSLV3Only`	`<boolean>`DEPRECATED. Use 'sslVersions' instead.
`[replication_port-ssl://<port>]` `useSSLCompression`	`<boolean>`Whether or not the client performs data compression at the TLS layer upon connection to the server. More A value of "true" means that the client attempts to negotiate and send compressed data to the server at the TLS layer. A value of "false" means that the client does not try to compress data at the TLS layer.	true
`[replication_port-ssl://<port>]` `compressed`	`<boolean>`DEPRECATED. Use 'useSSLCompression' instead. More Used only if 'useSSLCompression' is not set.
`[replication_port-ssl://<port>]` `requireClientCert`	`<boolean>`See the description of 'requireClientCert' under the [sslConfig] stanza for details on this setting.	false
`[replication_port-ssl://<port>]` `allowSslRenegotiation`	`<boolean>`See the description of 'allowSslRenegotiation' under the [sslConfig] stanza for details on this setting.	true
`[replication_port-ssl://<port>]` `sslCommonNameToCheck`	`<comma-separated list>`See the description of 'sslCommonNameToCheck' under the [sslConfig] stanza for details on this setting.	No default
`[replication_port-ssl://<port>]` `sslAltNameToCheck`	`<comma-separated list>`See the description of 'sslAltNameToCheck' under the [sslConfig] stanza for details on this setting.	No default

`[introspection:generator:disk_objects]`

For 'introspection_generator_addon', packaged with Splunk; provides the data ("i-data") consumed, and reported on, by 'introspection_viewer_app' (due to ship with a future release).
This stanza controls the collection of i-data about: indexes; bucket superdirectories (homePath, coldPath, ...); volumes; search dispatch artifacts.
On forwarders the collection of index, volumes and dispatch disk objects is disabled.

Setting	Description	Default
`[introspection:generator:disk_objects]` `acquireExtra_i_data`	`<boolean>`If true, extra Disk Objects i-data is emitted; you can gain more insight into your site, but at the cost of greater resource consumption both directly (the collection itself) and indirectly (increased disk and bandwidth utilization, to store the produced i-data). More Consult documentation for the list of regularly emitted Disk Objects i-data, and extra Disk Objects i-data, appropriate to your release.	false
`[introspection:generator:disk_objects]` `collectionPeriodInSecs`	`<positive integer>`Controls frequency of Disk Objects i-data collection; higher frequency (hence, smaller period) gives a more accurate picture, but at the cost of greater resource consumption both directly (the collection itself) and indirectly (increased disk and bandwidth utilization, to store the produced i-data).	600 (10 minutes)

`[introspection:generator:disk_objects__indexes]`

This stanza controls the collection of i-data about indexes.
Inherits the values of 'acquireExtra_i_data' and 'collectionPeriodInSecs' attributes from the 'introspection:generator:disk_objects' stanza, but may be enabled/disabled independently of it.
This stanza should only be used to force collection of i-data about indexes on dedicated forwarders.
Default: Data collection is disabled on universal forwarders and enabled on all other installations.

`[introspection:generator:disk_objects__volumes]`

This stanza controls the collection of i-data about volumes.
Inherits the values of 'acquireExtra_i_data' and 'collectionPeriodInSecs' settings from the 'introspection:generator:disk_objects' stanza, but may be enabled/disabled independently of it.
This stanza should only be used to force collection of i-data about volumes on dedicated forwarders.
Default: Data collection is disabled on universal forwarders and enabled on all other installations.

`[introspection:generator:disk_objects__dispatch]`

This stanza controls the collection of i-data about search dispatch artifacts.
Inherits the values of 'acquireExtra_i_data' and 'collectionPeriodInSecs' settings from the 'introspection:generator:disk_objects' stanza, but may be enabled/disabled independently of it.
This stanza should only be used to force collection of i-data about search dispatch artifacts on dedicated forwarders.
Default: Data collection is disabled on universal forwarders and enabled on all other installations.

`[introspection:generator:disk_objects__fishbucket]`

This stanza controls the collection of i-data about: $SPLUNK_DB/fishbucket, where per-input status of file-based inputs is persisted.
Inherits the values of 'acquireExtra_i_data' and 'collectionPeriodInSecs' settings from the 'introspection:generator:disk_objects' stanza, but may be enabled/disabled independently of it.

`[introspection:generator:disk_objects__bundle_replication]`

This stanza controls the collection of i-data about: bundle replication metrics of distributed search
Inherits the values of 'acquireExtra_i_data' and 'collectionPeriodInSecs' settings from the 'introspection:generator:disk_objects' stanza, but may be enabled/disabled independently of it.

`[introspection:generator:disk_objects__partitions]`

This stanza controls the collection of i-data about: disk partition space utilization.
Inherits the values of 'acquireExtra_i_data' and 'collectionPeriodInSecs' settings from the 'introspection:generator:disk_objects' stanza, but may be enabled/disabled independently of it.

`[introspection:generator:disk_objects__summaries]`

Introspection data about summary disk space usage. Summary disk usage includes both data model and report summaries. The usage is collected for each summaryId, locally at each indexer.

Setting	Description	Default
`[introspection:generator:disk_objects__summaries]` `disabled`	`<boolean>`If not specified, inherits the value from [introspection:generator:disk_objects] stanza.
`[introspection:generator:disk_objects__summaries]` `collectionPeriodInSecs`	`<positive integer>`Controls frequency, in seconds, of Disk Objects - summaries collection; higher frequency (hence, smaller period) gives a more accurate picture, but at the cost of greater resource consumption directly (the summaries collection itself); it is not recommended for a period less than 15 minutes. More If you enable summary collection, the first collection happens 5 minutes after the Splunk instance is started. For every subsequent collection, this setting is honored. If 'collectionPeriodInSecs' is smaller than 5 * 60, it resets to 30 minutes internally. Set to (N*300) seconds. Any remainder is ignored.	1800 (30 minutes)

`[introspection:generator:resource_usage]`

For 'introspection_generator_addon', packaged with Splunk; provides the data ("i-data") consumed, and reported on, by 'introspection_viewer_app' (due to ship with a future release).
"Resource Usage" here refers to: CPU usage; scheduler overhead; main (physical) memory; virtual memory; pager overhead; swap; I/O; process creation (a.k.a. forking); file descriptors; TCP sockets; receive/transmit networking bandwidth.
Resource Usage i-data is collected at both hostwide and per-process levels; the latter, only for processes associated with this SPLUNK_HOME.
Per-process i-data for Splunk search processes include additional, search-specific, information.

Setting	Description	Default
`[introspection:generator:resource_usage]` `acquireExtra_i_data`	`<boolean>`A value of "true" means extra Resource Usage i-data is emitted; you can gain more insight into your site, but at the cost of greater resource consumption both directly (the collection itself) and indirectly (increased disk and bandwidth utilization, to store the produced i-data). More Consult the documentation for list of regularly emitted Resource Usage i-data, and extra Resource Usage i-data, appropriate to your release.	false
`[introspection:generator:resource_usage]` `collectionPeriodInSecs`	`<positive integer>`Controls frequency of Resource Usage i-data collection; higher frequency (hence, smaller period) gives a more accurate picture, but at the cost of greater resource consumption both directly (the collection itself) and indirectly (increased disk and bandwidth utilization, to store the produced i-data).	600 (10 minutes) (on universal forwarders); 10 (1/6th of a minute) (on all other Splunk platform instance types)
`[introspection:generator:resource_usage]` `disabled`	`<boolean>`Disables Resource Usage data collection.	true (on universal forwarders); false (on all other Splunk platform instance types)

`[introspection:generator:resource_usage__iostats]`

This stanza controls the collection of i-data about: IO Statistics data
"IO Statistics" here refers to: read/write requests; read/write sizes; io service time; cpu usage during service
IO Statistics i-data is sampled over the collectionPeriodInSecs
Does not inherit the value of the 'collectionPeriodInSecs' setting from the 'introspection:generator:resource_usage' stanza, and may be enabled/disabled independently of it.

Setting	Description	Default
`[introspection:generator:resource_usage__iostats]` `collectionPeriodInSecs`	`<positive integer>`Controls interval of IO Statistics i-data collection; higher intervals gives a more accurate picture, but at the cost of greater resource consumption both directly (the collection itself) and indirectly (increased disk and bandwidth utilization, to store the produced i-data).	60 (1 minute)
`[introspection:generator:resource_usage__iostats]` `disabled`	`<boolean>`Disables IO Statistics data collection.	true (on universal forwarders); false (on all other Splunk platform instance types)

`[introspection:generator:kvstore]`

For 'introspection_generator_addon', packaged with Splunk Enterprise.
"KV Store" here refers to: statistics information about KV Store process.

Setting	Description	Default
`[introspection:generator:kvstore]` `serverStatsCollectionPeriodInSecs`	`<positive integer>`The frequency, in seconds, of KV Store server status collection.	27
`[introspection:generator:kvstore]` `operationStatsCollectionPeriodInSecs`	`<positive integer>`The frequency, in seconds, of KV Store operation statistics collection (currentOp).	60 seconds
`[introspection:generator:kvstore]` `collectionStatsCollectionPeriodInSecs`	`<positive integer>`The frequency, in seconds, of KV Store db statistics collection.	600 (10 minutes)
`[introspection:generator:kvstore]` `profilingStatsCollectionPeriodInSecs`	`<positive integer>`The frequency, in seconds, of KV Store profiling data collection.	5 seconds
`[introspection:generator:kvstore]` `rsStatsCollectionPeriodInSecs`	`<positive integer>`The frequency, in seconds, of KV Store replica set stats collection	60 seconds

`[introspection:distributed-indexes]`

This stanza controls the collection of information for distributed indexes.

Setting	Description	Default
`[introspection:distributed-indexes]` `disabled`	`<boolean>`Whether or not collection of introspection information on distributed indexes is disabled. More A value of "false" means information on distributed indexes is collected. This provides additional insight into index usage at the cost of greater resource consumption.	true
`[introspection:distributed-indexes]` `collectionPeriodInSecs`	`<positive integer>`The frequency, in seconds, of distributed index data collection. Shorter intervals provide more accurate results, at the cost of greater resource consumption. More Must be set between 300 (5 minutes) and 86400 (24 hours).	3600 (60 minutes)
`[introspection:distributed-indexes]` `collectLocalIndexes`	`<boolean>`This setting determines whether the search head retrieves index metadata, such as current size and event count. More In single-instance configurations, where the instance serves as both search head and indexer, set the value to "true", so that the local index metadata is retrieved. In distributed search deployments, with separate search heads and indexers, set the value to "false" to retrieve metadata only from indexes on the indexers.	false

`[commands:user_configurable]`

Setting	Description	Default
`[commands:user_configurable]` `prefix`	`<string>`All non-internal commands started by splunkd are prefixed with this string, allowing for "jailed" command execution. More Should be only one word. In other words, commands are supported, but commands and arguments are not. Applies to commands such as: search scripts, scripted inputs, SSL certificate generation scripts. (Any commands that are user-configurable). Does not apply to trusted/non-configurable command executions, such as: splunk search, splunk-optimize, gunzip. $SPLUNK_HOME is expanded.	No default

`[app_backup]`

Setting	Description	Default
`[app_backup]` `backup_path`	`<string>`Full path to the directory that contains configuration backups created by Splunk Enterprise. More For search head clusters, this directory resides on the deployer.	$SPLUNK_HOME/var/backup

`[shclustering]`

Setting	Description	Default
`[shclustering]` `disabled`	`<boolean>`Disables or enables search head clustering on this instance. More When enabled, the captain needs to be selected via a bootstrap mechanism. Once bootstrapped, further captain selections are made via a dynamic election mechanism. When enabled, you must also specify the cluster member's own server address / management URI for identification purpose. This can be done in 2 ways: by specifying the 'mgmt_uri' setting individually on each member or by specfing pairs of 'GUID, mgmt-uri' strings in the servers_list setting.	true
`[shclustering]` `mgmt_uri`	`[ mgmt-URI ]`The management URI is used to identify the cluster member's own address to itself. More Either 'mgmt_uri' or 'servers_list' is necessary. The 'mgmt_uri' setting is simpler to author but is unique for each member. The 'servers_list' setting is more involved, but can be copied as a config string to all members in the cluster.
`[shclustering]` `servers_list`	`[ <(GUID, mgmt-uri);>+ ]`A semicolon separated list of instance GUIDs and management URIs. More Each member uses its GUID to identify its own management URI.
`[shclustering]` `adhoc_searchhead`	`<boolean>`This setting configures a member as an ad-hoc search head; i.e., the member does not run any scheduled jobs. More Use the setting 'captain_is_adhoc_searchhead' to reduce compute load on the captain.	false
`[shclustering]` `no_artifact_replications`	`<boolean>`Prevent this Search Head Cluster member to be selected as a target for replications. More This is an advanced setting, and not to be changed without proper understanding of the implications.	false
`[shclustering]` `precompress_artifacts`	`<boolean>`Determines whether this search head cluster member compresses the search artifacts before replicating them to other members. More When set to "true", the search head compresses the artifacts before replicating them to all other members. This helps reduce network bandwidth consumption during artifact replications. Set this option to 'true' only when SSL compression is off on each search head cluster member. To turn off SSL compression, set 'allowSslCompression = false' under the [sslConfig] stanza in the server.conf file on each member.	true
`[shclustering]` `captain_is_adhoc_searchhead`	`<boolean>`This setting prohibits the captain from running scheduled jobs. More The captain is dedicated to controlling the activities of the cluster, but can also run adhoc search jobs from clients.	false
`[shclustering]` `preferred_captain`	`<boolean>`The cluster tries to assign captaincy to a member with 'preferred_captain=true'. More Note that it is not always possible to assign captaincy to a member with preferred_captain=true - for example, if none of the preferred members is reachable over the network. In that case, captaincy might remain on a member with preferred_captain=false.	true
`[shclustering]` `prevent_out_of_sync_captain`	`<boolean>`This setting prevents a node that could not sync config changes to current captain from becoming the cluster captain. More This setting takes precedence over the preferred_captain setting. For example, if there are one or more preferred captain nodes but the nodes cannot sync config changes with the current captain, then the current captain retains captaincy even if it is not a preferred captain. This must be set to the same value on all members.	true
`[shclustering]` `replication_factor`	`<positive integer>`Determines how many copies of search artifacts are created in the cluster. More This must be set to the same value on all members.	3
`[shclustering]` `pass4SymmKey`	`<string>`Secret shared among the members in the search head cluster to prevent any arbitrary instance from connecting to the cluster. More All members must use the same value. If set in the [shclustering] stanza, it takes precedence over any setting in the [general] stanza. Unencrypted passwords must not begin with "$1$", as this is used by Splunk software to determine if the password is already encrypted.	The 'changeme' from the [general] stanza in the default the server.conf file.
`[shclustering]` `pass4SymmKey_minLength`	`<integer>`The minimum length, in characters, that a 'pass4SymmKey' should be for a particular stanza. More When you start the Splunk platform, if the 'pass4SymmKey' is shorter in length than what you specify with this setting, the platform warns you and advises that you change the pass4SymKey. If you use the CLI to modify 'pass4SymmKey' to a value that is shorter than what you specify with this setting, the platform warns you and advises that you change the pass4SymKey.	12
`[shclustering]` `async_replicate_on_proxy`	`<boolean>`If the jobs/${sid} REST endpoint or its sub-resources (e.g. jobs/${sid}/results, jobs/${sid}/summary, etc.) had to be proxied to a different member due to missing local replica, this setting automatically schedules an async replication to that member when set to true.	true
`[shclustering]` `master_dump_service_periods`	`<integer>`DEPRECATED. Use 'captain_dump_service_periods' instead.
`[shclustering]` `captain_dump_service_periods`	`<integer>`If SHPMaster info is switched on in log.cfg, then captain statistics are dumped in splunkd.log after the specified number of service periods. Purely a debugging aid.	500
`[shclustering]` `long_running_jobs_poll_period`	`<integer>`Long running delegated jobs are polled by the captain every "long_running_jobs_poll_period" seconds to ascertain whether they are still running, in order to account for potential node/member failure.	600 (10 minutes)
`[shclustering]` `scheduling_heuristic`	`<string>`This setting configures the job distribution heuristic on the captain. More There are currently two supported strategies: 'round_robin' or 'scheduler_load_based'.	'scheduler_load_based'
`[shclustering]` `id`	`<string>`Unique identifier for this cluster as a whole, shared across all cluster members.	Splunk software arranges for a unique value to be generated and shared across all members.
`[shclustering]` `cxn_timeout`	`<integer>`Low-level timeout, in seconds, for establishing connection between cluster members.	60
`[shclustering]` `send_timeout`	`<integer>`Low-level timeout, in seconds, for sending data between search head cluster members.	60
`[shclustering]` `rcv_timeout`	`<integer>`Low-level timeout, in seconds, for receiving data between search head cluster members.	60
`[shclustering]` `cxn_timeout_raft`	`<integer>`Low-level timeout, in seconds, for establishing connection between search head cluster members for the raft protocol.	2
`[shclustering]` `send_timeout_raft`	`<integer>`Low-level timeout, in seconds, for sending data between search head cluster members for the raft protocol.	5
`[shclustering]` `rcv_timeout_raft`	`<integer>`Low-level timeout, in seconds, for receiving data between search head cluster members for the raft protocol.	5
`[shclustering]` `rep_cxn_timeout`	`<integer>`Low-level timeout, in seconds, for establishing connection for replicating data.	60
`[shclustering]` `rep_send_timeout`	`<integer>`Low-level timeout, in seconds, for sending replication slice data between cluster members. More This is a soft timeout. When this timeout is triggered on source peer, it tries to determine if target is still alive. If it is still alive, it reset the timeout for another rep_send_timeout interval and continues. If target has failed or cumulative timeout has exceeded rep_max_send_timeout, replication fails.	60
`[shclustering]` `rep_rcv_timeout`	`<integer>`Low-level timeout, in seconds, for receiving acknowledgement data from members. More This is a soft timeout. When this timeout is triggered on source member, it tries to determine if target is still alive. If it is still alive, it reset the timeout for another rep_send_timeout interval and continues. If target has failed or cumulative timeout has exceeded the 'rep_max_rcv_timeout' setting, replication fails.	60
`[shclustering]` `rep_max_send_timeout`	`<integer>`Maximum send timeout, in seconds, for sending replication slice data between cluster members. More On 'rep_send_timeout' source peer determines if total send timeout has exceeded rep_max_send_timeout. If so, replication fails. If cumulative rep_send_timeout exceeds 'rep_max_send_timeout', replication fails.	600 (10 minutes)
`[shclustering]` `rep_max_rcv_timeout`	`<integer>`Maximum cumulative receive timeout, in seconds, for receiving acknowledgement data from members. More On 'rep_rcv_timeout' source member determines if total receive timeout has exceeded 'rep_max_rcv_timeout'. If so, replication fails.	600 (10 minutes)
`[shclustering]` `log_heartbeat_append_entries`	`<boolean>`If true, Splunk software logs the the low-level heartbeats between members in splunkd_access.log file. These heartbeats are used to maintain the authority of the captain authority over other members.	false
`[shclustering]` `election_timeout_ms`	`<positive_integer>`The amount of time, in milliseconds, that a member waits before trying to become the captain. More Note that modifying this value can alter the heartbeat period (See election_timeout_2_hb_ratio for further details) A very low value of election_timeout_ms can lead to unnecessary captain elections.	60000 (1 minute)
`[shclustering]` `election_timeout_2_hb_ratio`	`<positive_integer>`The ratio between the election timeout, set in 'election_timeout_ms', and the raft heartbeat period. More The raft heartbeat period is 'election_timeout_ms' / 'election_timeout_2_hb_ratio'. This ratio determines the number of heartbeat attempts that would fail before a member starts to timeout and tries to become the captain. A typical ratio between 5 - 20 is desirable.	12 (to keep the raft heartbeat period at 5 seconds)
`[shclustering]` `heartbeat_timeout`	`<positive integer>`The amount of time, in seconds, that the captain considers a member down. After a member is down, the captain initiates fixup steps to replicate artifacts from the dead member to its peers. More This heartbeat exchanges data between the captain and members, which helps in maintaining the in-memory centralized state for all the cluster members. Note that this heartbeat is different from the Raft heartbeat described in the 'election_timeout_2_hb_ratio' setting.	60 (1 minute)
`[shclustering]` `raft_rpc_backoff_time_ms`	`<positive integer>`Provides a delay, in milliseconds, should a raft RPC request fail. More This avoids rapid connection requests being made to unreachable peers. This setting should not normally be changed from the default.	5000 (5 seconds)
`[shclustering]` `access_logging_for_heartbeats`	`<boolean>`Only valid on captain. More Enables/disables logging to the splunkd_access.log file for member heartbeats NOTE: you do not have to restart captain to set this config parameter. Simply run the cli command on master: % splunk edit shcluster-config -access_logging_for_heartbeats <<boolean>>	false (logging disabled)
`[shclustering]` `restart_timeout`	`<positive integer>`This is the amount of time the captain waits for a member to come back when the instance is restarted (to avoid the overhead of trying to fixup the artifacts that were on the peer).
`[shclustering]` `quiet_period`	`<positive integer>`The amount of time, in seconds, for which a newly elected captain waits for members to join. More During this period the captain does not initiate any fixups but instead waits for the members to register themselves. Job scheduling and conf replication still happen as usual during this time. At the end of this time period, the captain builds its view of the cluster based on the registered peers and starts normal processing.	60
`[shclustering]` `max_peer_rep_load`	`<integer>`This is the maximum number of concurrent replications that a member can take part in as a target.	5
`[shclustering]` `target_wait_time`	`<positive integer>`The amount of time, in seconds, that the captain waits for the target of a replication to register itself before it services the artifact again and potentially schedules another fixup.	150
`[shclustering]` `manual_detention`	`on\|off`This property toggles manual detention on member. More When a node is in manual detention, it does not accept new search jobs, including both scheduled and ad-hoc searches. It also does not receive replicated search artifacts from other nodes.	off
`[shclustering]` `percent_peers_to_restart`	`<integer>`The percentage of members to restart at one time during rolling restarts. More Actual percentage may vary due to lack of granularity for smaller peer sets regardless of setting, a minimum of 1 peer is restarted per round. Valid values are between 0 and 100. CAUTION: Do not set this setting to a value greater than 20%. Otherwise, issues can arise during the captain election process.
`[shclustering]` `rolling_restart_with_captaincy_exchange`	`<boolean>`Whether or not the captain tries to exchange captaincy with another node during a rolling restart. More A value of "true" means the captain tries to exchange captaincy with another node during a rolling restart. A value of "false" means the captain restarts and captaincy transfers to some other node.	true
`[shclustering]` `rolling_restart`	`restart\|searchable\|searchable_force`Determines the rolling restart mode for a search head cluster. More If set to "restart", a rolling restart runs in classic mode. If set to "searchable", a rolling restart runs in searchable (minimal search disruption) mode. If set to "searchable_force", the search head cluster performs a searchable rolling restart, but overrides the health check. You do not have to restart any search head members to configure this setting. Run this CLI command from any member: % splunk edit shcluster-config -rolling_restart restart\|searchable\|searchable_force	restart (runs in classic rolling-restart mode)
`[shclustering]` `decommission_search_jobs_wait_secs`	`<unsigned integer>`The amount of time, in seconds, that a search head cluster member waits for existing searches to complete before restarting. More Applies only when rolling restart is triggered in searchable or searchable_force mode (i.e.'rolling_restart' is set to "searchable" or "searchable_force"). You do not have to restart search head members to configure this setting. Run this CLI command from any member: % splunk edit shcluster-config -decommission_search_jobs_wait_secs <positive integer> NOTE: If you specify 'decommission_search_jobs_wait_secs' in the '[general]' stanza, leave it unchanged at its default value.	180
`[shclustering]` `register_replication_address`	`<string>`This setting is the address on which a member is available for accepting replication data. This is useful in the cases where a member host machine has multiple interfaces and only one of them can be reached by another splunkd instance. More Can be an IP address, or a fully qualified machine/domain name.
`[shclustering]` `executor_workers`	`<positive integer>`Number of threads that can be used by the search head clustering threadpool. More A value of 0 is interpreted as 1.	50
`[shclustering]` `heartbeat_period`	`<non-zero positive integer>`The frequency, in seconds, with which the member attempts to send heartbeats to the captain. More This heartbeat exchanges data between the captain and members, which helps in maintaining the in-memory centralized state for all the cluster members. NOTE: This heartbeat period is different from the Raft heartbeat period in the 'election_timeout_2_hb_ratio' setting.	5
`[shclustering]` `enableS2SHeartbeat`	`<boolean>`Whether or not Splunk software monitors each replication connection for presence of a heartbeat. More A value of "true" means that Splunk software monitors the presence of a heartbeat. If the heartbeat is not seen for 's2sHeartbeatTimeout' seconds, the instance that monitors the heartbeat closes the connection.	true
`[shclustering]` `s2sHeartbeatTimeout`	`<integer>`The global timeout, in seconds, for monitoring heartbeats on replication connections. More Splunk software closes a replication connection if a heartbeat is not seen for 's2sHeartbeatTimeout' seconds. Replication source sends a heartbeat every 30 seconds.	600 (10 minutes)
`[shclustering]` `captain_uri`	`[ static-captain-URI ]`The management URI of static captain is used to identify the cluster captain for a static captain.
`[shclustering]` `election`	`<boolean>`This is used to classify a cluster as static or dynamic (RAFT based). More If set to "false", a static captain, which is used for DR situation. If set to "true", a dynamic captain election enabled through RAFT protocol.
`[shclustering]` `mode`	`<member>`Accepted values are captain and member, mode is used to identify the function of a node in static search head cluster. More Setting mode as captain assumes it to function as both captain and a member.
`[shclustering]` `sid_proxying`	`<boolean>`Enable or disable search artifact proxying. More Changing this affects the proxying of search results, and jobs feed is not cluster-aware. Only for internal/expert use.	true
`[shclustering]` `ss_proxying`	`<boolean>`Enable or disable saved search proxying to captain. More Changing this affects the behavior of Searches and Reports page in Splunk Web. Only for internal/expert use.	true
`[shclustering]` `ra_proxying`	`<boolean>`Enable or disable saved report acceleration summaries proxying to captain. More Changing this affects the behavior of report acceleration summaries page. Only for internal/expert use.	true
`[shclustering]` `alert_proxying`	`<boolean>`Enable or disable alerts proxying to captain. More Changing this impacts the behavior of alerts, and essentially make them not cluster-aware. Only for internal/expert use.	true
`[shclustering]` `csv_journal_rows_per_hb`	`<integer>`How many rows of CSV from the delta-journal are sent per hb More Used for both alerts and suppressions Do not alter this value without contacting Splunk Support.	10000
`[shclustering]` `conf_replication_period`	`<integer>`How often, in seconds, a cluster member replicates configuration changes. More A value of 0 disables automatic replication of configuration changes.	5
`[shclustering]` `conf_replication_max_pull_count`	`<integer>`The maximum number of configuration changes a member replicates from the captain at one time. More A value of 0 disables any size limits.	1000
`[shclustering]` `conf_replication_max_push_count`	`<integer>`The maximum number of configuration changes a member replicates to the captain at one time. More A value of 0 disables any size limits.	100
`[shclustering]` `conf_replication_max_json_value_size`	`[<integer>\|<integer>[KB\|MB\|GB]]`The maximum size of a JSON string element at any nested level while parsing a configuration change from JSON representation. More If a knowledge object created on a member has some string element that exceeds this limit, the knowledge object is not replicated to the rest of the search head cluster, and a warning that mentions conf_replication_max_json_value_size is written to splunkd.log. If you do not specify a unit for the value, the unit defaults to bytes. The lower limit of this setting is 512KB. When increasing this setting beyond the default, you must take into account the available system memory.	15MB
`[shclustering]` `conf_replication_include.<conf_file_name>`	`<boolean>`Whether Splunk replicates changes to a particular type of .conf file, along with any associated permissions in .meta files.	false
`[shclustering]` `conf_replication_summary.whitelist.<name>`	`<whitelist_pattern>`DEPRECATED. Use 'conf_replication_summary.includelist.<name>' instead.
`[shclustering]` `conf_replication_summary.includelist.<name>`	`<includelist_pattern>`Files to be included in configuration replication summaries.
`[shclustering]` `conf_replication_summary.blacklist.<name>`	`<blacklist_pattern>`DEPRECATED. Use 'conf_replication_summary.excludelist.<name>' instead.
`[shclustering]` `conf_replication_summary.excludelist.<name>`	`<excludelist_pattern>`Files to be excluded from configuration replication summaries.
`[shclustering]` `conf_replication_summary.concerning_file_size`	`<integer>`Any individual file within a configuration replication summary that is larger than this value (in MB) triggers a splunkd.log warning message.	50
`[shclustering]` `conf_replication_summary.period`	`<timespan>`How often configuration replication summaries are created.	1m (1 minute)
`[shclustering]` `conf_replication_purge.eligibile_count`	`<integer>`How many configuration changes must be present before any become eligible for purging. More In other words: controls the minimum number of configuration changes Splunk software remembers for replication purposes.	20000
`[shclustering]` `conf_replication_purge.eligibile_age`	`<timespan>`How old a configuration change must be before it is eligible for purging.	1d (1 day).
`[shclustering]` `conf_replication_purge.period`	`<timespan>`How often configuration changes are purged.	1h (1 hour)
`[shclustering]` `conf_replication_find_baseline.use_bloomfilter_only`	`<boolean>`Whether or not a search head cluster only uses bloom filters to determine a baseline, when it replicates configurations. More Set to "true" to only use bloom filters in baseline determination during configuration replication. Set to "false" to first attempt a standard method, where the search head cluster captain interacts with members to determine the baseline, before falling back to using bloom filters.	false
`[shclustering]` `conf_replication_quarantine_large_lookups`	`<boolean>`Determines whether or not a search head cluster quarantines and excludes from replication any lookup file change that creates a lookup file larger than the allowed limit, which is 5GB or the value of the `max_content_length` setting, whichever is greater. More A value of "true" means that the cluster quarantines and does not replicate CSV files whose size exceeds 5GB. Conf replication quarantine can prevent cluster out of sync issues caused by the cluster's inability to replicate CSV file sizes greater than 5GB. Lookup replication resumes when a change occurs to the lookup file that reduces its size to less than or equal to the allowed limit.	true
`[shclustering]` `conf_replication_max_csv_lookup_size_bytes`	`<integer>`Specifies the maximum size of a CSV lookup file, in bytes, that can be replicated in a search head cluster. More A value of "5000000000" means that the cluster quarantines and does not replicate CSV files that exceed 5GB. Lookup files that do not exceed 5GB continue to replicate across the cluster. Lookup replication resumes when a change occurs to the lookup file that reduces its size to less than or equal to the specified size limit. Until then, the CSV lookup file remains on the search head and is not distributed to other cluster members. CAUTION: Setting this value higher than 5GB can cause downstream issues. For use cases involving large lookup file sizes, use KV store lookups instead. This setting is not reloadable. You must restart Splunk software for this setting to take effect.	5000000000
`[shclustering]` `conf_deploy_repository`	`<path>`Full path to directory containing configurations to deploy to cluster members.
`[shclustering]` `conf_deploy_staging`	`<path>`Full path to directory where preprocessed configurations may be written before being deployed cluster members.
`[shclustering]` `conf_deploy_concerning_file_size`	`<integer>`Any individual file within <conf_deploy_repository> that is larger than this value (in MB) triggers a splunkd.log warning message.	50
`[shclustering]` `conf_deploy_precompress_bundles`	`<boolean>`Determines whether or not the deployer compresses the configuration bundle files before pushing them to search heads, which reduces network bandwidth consumption. More Set this option to "true" only when SSL compression is off. Otherwise, the files will be compressed twice, which wastes CPU resources and does not save network bandwidth. To turn off SSL compression, set "allowSslCompression = false" in server.conf on the deployer.	true
`[shclustering]` `conf_deploy_fetch_url`	`<URL>`Specifies the location of the deployer from which members fetch the configuration bundle. More This value must be set to a <URL> in order for the configuration bundle to be fetched.	No default
`[shclustering]` `conf_deploy_fetch_mode`	`auto\|replace\|none`Controls configuration bundle fetching behavior when the member starts up. More When set to "replace", a member checks for a new configuration bundle on every startup. When set to "none", a member does not fetch the configuration bundle on startup. Regarding "auto": If no configuration bundle has yet been fetched, "auto" is equivalent to "replace". If the configuration bundle has already been fetched, "auto" is equivalent to "none".	replace
`[shclustering]` `artifact_status_fields`	`<comma-separated list>`Give a comma separated fields to pick up values from status.csv and info.csv for each search artifact. More These fields are shown in the CLI/REST endpoint splunk list shcluster-member-artifacts	user, eai:acl.app , label
`[shclustering]` `encrypt_fields`	`<comma-separated list>`DEPRECATED. More Use the setting in the '[general]' stanza instead.
`[shclustering]` `enable_jobs_data_lite`	`<boolean>`DEPRECATED. More Use the 'jobs_data_lite.enabled' instead.
`[shclustering]` `jobs_data_lite.enabled`	`<boolean>`Enable memory optimizations for sharing search job status within search head clustering.	true
`[shclustering]` `jobs_data_lite.exclude_fields`	`<comma separated list>`List of job status fields to be excluded from truncation when jobs_data_lite.enabled is true. More Fields to exclude must be in a comma separated list.	No default
`[shclustering]` `jobs_data_lite.search_field_len`	`<non-negative integer>`Maximum length for any search-based field in the search job status when jobs_data_lite.enabled is true. Fields longer than this value will be truncated. More Any field larger than this size will be truncated unless configured in the jobs_data_lite.exclude_fields list. Search fields include: remote_search, normalized_search, optimized_search, phase_0_search, phase_1_search, report_search, and events_search.	100
`[shclustering]` `jobs_data_lite.default_field_len`	`<non-negative integer>`Maximum length for any nonsearch-based field in the search job status when jobs_data_lite.enabled is true. Fields longer than this value will be truncated. More Any field larger than this size will be truncated unless configured in the jobs_data_lite.exclude_fields list.	1000000
`[shclustering]` `jobs_data_lite.max_status_size_per_hb`	`<non-negative integer>`The maximum size, in megabyte, of status.csv More status.csv tracks job statuses and is sent between the captain and each cluster member in each heartbeat. Limiting the size of status.csv helps to stabilize the communication between the captain and members by preventing the heartbeat from growing overly large. Recommended range: 500-1000 Absolute range: 100-1500	700
`[shclustering]` `shcluster_label`	`<string>`This specifies the label of the search head cluster.
`[shclustering]` `retry_autosummarize_or_data_model_acceleration_jobs`	`<boolean>`Whether or not the captain tries a second time to delegate an auto-summarized or data model acceleration job, if the first attempt to delegate the job fails.	true
`[shclustering]` `deployerPushThreads`	`<positive integer>\|auto`The maximum number of threads to use when performing a deployer bundle push to target members. More If set to "auto", the deployer auto-tunes the number of threads it uses for a deployer bundle push. There will be one thread per target member.	1
`[shclustering]` `remote_job_retry_attempts`	`<positive integer>`Defines the maximum number of re-run attempts for a failing search job (this number includes the initial attempt). More Note that this setting only applies to jobs that either failed to be delegated or jobs that returned failure. This means that jobs which have 'allow_partial_results' set to true will not be re-run. The upper limit of the number of job re-run attempts is constrained by the total number of nodes in the Search Head Cluster.	2
`[shclustering]` `member_add_use_artifact_status_cache`	`<boolean>`Whether or not search head cluster members use cached artifact status when messaging the captain during the cluster member addition process. More This option improves the performance of the search head cluster member addition process. A value of "true" means cluster members use cached artifact status during the cluster member addition process. A value of "false" means cluster members do not use cached artifact status during the cluster member addition process. NOTE: Do not change this setting without first consulting with Splunk Support.	true
`[shclustering]` `member_add_decouple_artifact_reporting`	`<boolean>`Turns on or off an optimization for search head cluster member addition that decouples artifact reporting from the cluster member addition process. More This option can improve the performance of the search head cluster member addition process. A value of "true" means artifact reporting is decoupled from the cluster member addition process. A value of "false" means artifact reporting is not decoupled from the cluster member addition process. NOTE: Do not change this setting without first consulting with Splunk Support.	true
`[shclustering]` `allow_concurrent_dispatch_savedsearch`	`<boolean>`The search head cluster captain might dispatch multiple saved searches to a member through REST calls. More This option controls whether the member processes the dispatched REST calls concurrently or sequentially. If true, the member processes the REST calls concurrently. If false, the member processes the REST calls sequentially.	true

`[replication_port://<port>]`

Setting	Description	Default
`[replication_port://<port>]` `disabled`	`<boolean>`Set to true to disable this replication port stanza.	false
`[replication_port://<port>]` `listenOnIPv6`	`no\|yes\|only`Toggle whether this listening port listens on IPv4, IPv6, or both. More If not present, the setting in the [general] stanza is used.
`[replication_port://<port>]` `acceptFrom`	`<network_acl> ...`Lists a set of networks or addresses from which to accept connections. More Separate multiple rules with commas or spaces. Each rule can be in one of the following formats: 1. A single IPv4 or IPv6 address (examples: "10.1.2.3", "fe80::4a3") 2. A Classless Inter-Domain Routing (CIDR) block of addresses (examples: "10/8", "192.168.1/24", "fe80:1234/32") 3. A DNS name, possibly with a "" used as a wildcard (examples: "myhost.example.com", ".splunk.com") 4. "", which matches anything You can also prefix an entry with '!' to cause the rule to reject the connection. The input applies rules in order, and uses the first one that matches. For example, "!10.1/16, " allows connections from everywhere except the 10.1.. network.	"*" (accept from anywhere)

`[replication_port-ssl://<port>]`

This configuration is the same as the replication_port stanza, but uses TLS.

Setting	Description	Default
`[replication_port-ssl://<port>]` `disabled`	`<boolean>`Set to true to disable this replication port stanza.	false
`[replication_port-ssl://<port>]` `listenOnIPv6`	`no\|yes\|only`Toggle whether this listening port listens on IPv4, IPv6, or both.	The setting in the [general] stanza
`[replication_port-ssl://<port>]` `acceptFrom`	`<network_acl> ...`This setting is the same as the setting in the [replication_port] stanza.
`[replication_port-ssl://<port>]` `serverCert`	`<path>`See the description of 'serverCert' under the [sslConfig] stanza for details on this setting.	No default
`[replication_port-ssl://<port>]` `sslPassword`	`<string>`See the description of 'sslPassword' under the [sslConfig] stanza for details on this setting.	No default
`[replication_port-ssl://<port>]` `password`	`<string>`DEPRECATED. Use 'sslPassword' instead. More Used only if 'sslPassword' is not set.
`[replication_port-ssl://<port>]` `rootCA`	`<string>`DEPRECATED. Use '[sslConfig]/sslRootCAPath' instead.	No default
`[replication_port-ssl://<port>]` `cipherSuite`	`<string>`See the description of 'cipherSuite' under the [sslConfig] stanza for details on this setting. More The default can vary. See the 'cipherSuite' setting in the $SPLUNK_HOME/etc/system/default/server.conf file for the current default.
`[replication_port-ssl://<port>]` `supportSSLV3Only`	`<boolean>`DEPRECATED. Use 'sslVersions' instead.
`[replication_port-ssl://<port>]` `useSSLCompression`	`<boolean>`See the description of 'useSSLCompression' under the [sslConfig] stanza for details on this setting.	false
`[replication_port-ssl://<port>]` `compressed`	`<boolean>`DEPRECATED. Use 'useSSLCompression' instead. More Used only if 'useSSLCompression' is not set.
`[replication_port-ssl://<port>]` `requireClientCert`	`<boolean>`See the description of 'requireClientCert' under the [sslConfig] stanza for details on this setting.	false
`[replication_port-ssl://<port>]` `allowSslRenegotiation`	`<boolean>`See the description of 'allowSslRenegotiation' under the [sslConfig] stanza for details on this setting.	true

`[kvstore]`

Setting	Description	Default
`[kvstore]` `disabled`	`<boolean>`Set to true to disable the KV Store process on the current server. To completely disable KV Store in a deployment with search head clustering or search head pooling, you must also disable KV Store on each individual server.	false
`[kvstore]` `port`	`<integer>`Port to connect to the KV Store server.	8191
`[kvstore]` `replicaset`	`<string>`Replica set name.	splunkrs
`[kvstore]` `distributedLookupTimeout`	`<integer>`This setting has been removed, as it is no longer needed.
`[kvstore]` `shutdownTimeout`	`<integer>`Time, in seconds, to wait for a clean shutdown of the KV Store. If this time is reached after signaling for a shutdown, KV Store is forcibly terminated	100
`[kvstore]` `initAttempts`	`<integer>`The maximum number of attempts to initialize the KV Store when starting splunkd.	300
`[kvstore]` `replication_host`	`<string>`The host name to access the KV Store. More This setting has no effect on a single Splunk platform instance. When using search head clustering, if the "replication_host" value is not set in the [kvstore] stanza, the host you specify for "mgmt_uri" in the [shclustering] stanza is used for KV Store connection strings and replication. In search head pooling, this host value is a requirement for using KV Store. This is the address on which a kvstore is available for accepting remotely.
`[kvstore]` `verbose`	`<boolean>`Whether or not verbose logging for KV Store is enabled. More Set to "true" to enable verbose logging.	false
`[kvstore]` `verboseLevel`	`<nonnegative integer>`When verbose logging is enabled, specifies the level of verbosity for logging from 0 to 5, where 5 is the most verbose.	2
`[kvstore]` `dbPath`	`<string>`Path where KV Store data is stored. More Changing this directory after initial startup does not move existing data. The contents of the directory should be manually moved to the new location.	$SPLUNK_DB/kvstore
`[kvstore]` `storageEngine`	`wiredTiger`The storage engine that KV Store uses to manage its data. More "mmapv1" is no longer supported for KV Store. When you upgrade the Splunk platform, the KV Store storage engine will be migrated to "wiredTiger" automatically if "mmapv1" is still being used and the Splunk platform instance is not a member of a search head cluster.	wiredTiger
`[kvstore]` `storageEngineMigration`	`<boolean>`DEPRECATED.
`[kvstore]` `oplogSize`	`<integer>`The size of the replication operation log, in megabytes, for environments with search head clustering or search head pooling. In a standalone environment, 20% of this size is used. More After the KV Store has created the oplog for the first time, changing this setting does NOT affect the size of the oplog. A full backup and restart of the KV Store is required. Do not change this setting without first consulting with Splunk Support.	1000 (1GB)
`[kvstore]` `minSnapshotHistoryWindow`	`<integer>`The minimum time window, in seconds, that the storage engine keeps the snapshot history. More Do not change this setting without first consulting with Splunk Support.	5
`[kvstore]` `replicationWriteTimeout`	`<integer>`The time to wait, in seconds, for replication to complete while saving KV store operations. When the value is 0, the process never times out. More Used for replication environments (search head clustering or search head pooling).	1800 (30 minutes)
`[kvstore]` `clientConnectionTimeout`	`<positive integer>`The time, in seconds, to wait while attempting a connection to the KV Store before the attempt times out.	10
`[kvstore]` `clientSocketTimeout`	`<positive integer>`The time, in seconds, to wait while attempting to send or receive on a socket before the attempt times out.	300 (5 minutes)
`[kvstore]` `dbCursorOperationTimeout`	`<positive integer>`Specifies a cumulative time limit in seconds for processing operations on the database cursor. The database interrupts the operation if it exceeds the defined timeout. Typically this value is equal to or smaller than the value for the 'clientSocketTimeout' setting.	300 (5 minutes)
`[kvstore]` `clientConnectionPoolSize`	`<positive integer>`The maximum number of active client connections to the KV Store. More When the number of active connections exceeds this value, KV Store will reject new connection attempts until at least one active connection closes. Do not change this setting without first consulting with Splunk Support.	500
`[kvstore]` `caCertFile`	`<string>`DEPRECATED. Use '[sslConfig]/sslRootCAPath' instead. More KV Store uses this setting for TLS connections and authentication. See the description of 'caCertFile' under the [sslConfig] stanza for details on this setting.	$SPLUNK_HOME/etc/auth/cacert.pem
`[kvstore]` `caCertPath`	`<string>`DEPRECATED. Use '[sslConfig]/sslRootCAPath' instead. More See the description of 'sslRootCAPath' under the [sslConfig] stanza for details on this setting.
`[kvstore]` `serverCert`	`<string>`See the description of 'serverCert' under the [sslConfig] stanza for details on this setting. More This setting is used for the server part of the KV store connection. If the [kvstoreSslClientConfig] stanza is not present, this setting is used for the client part of the KV store connection as well.	No default
`[kvstore]` `sslVersions`	`<comma-separated list>`The list of TLS versions that the Splunk platform uses for KV Store. More The Splunk platform supports only the following versions: "tls1.0", "tls1.1", "tls1.2", and "tls1.3". Use a wildcard "*" to include all supported versions. Use the value "tls" to include all SSL versions 1.0 and higher. Prefix a version with the "-" character to exclude a version from the list. SSL versions 2 and 3 are not supported. You can include the values "-ssl2" and "-ssl3" in this list, but they have no effect.	The value of 'server.conf:[sslConfig]/sslVersions'.
`[kvstore]` `sslVerifyServerCert`	`<boolean>`DEPRECATED. Configure client-related settings in the [kvstoreSslClientConfig] stanza. Use '[kvstoreSslClientConfig]/sslVerifyServerCert' instead. More See the description of 'sslVerifyServerCert' under the [sslConfig] stanza for details on this setting. If you have enabled FIPS (by setting SPLUNK_FIPS=1), splunkd always verifies the server certificate, and ignores this setting.	false (if you have not enabled FIPS)
`[kvstore]` `sslVerifyServerName`	`<boolean>`DEPRECATED. Configure client-related settings in the [kvstoreSslClientConfig] stanza. Use '[kvstoreSslClientConfig]/sslVerifyServerName' instead. More See the description of 'sslVerifyServerName' under the [sslConfig] stanza for details on this setting.	false
`[kvstore]` `sslKeysPath`	`<string>`DEPRECATED. Use 'serverCert' instead. More The Splunk platform uses this setting if the 'serverCert' setting does not have a value.
`[kvstore]` `sslPassword`	`<string>`See the description of 'sslPassword' under the [sslConfig] stanza for details on this setting. More Splunk Enterprise uses this setting only if you have turned on FIPS mode for the instance. If you have turned on FIPS mode in Splunk Enterprise, then you must configure this setting with a value. If you do not, then App Key Value Store is not available. This setting is used for the server part of the KV store connection. If the [kvstoreSslClientConfig] stanza is not present, this setting is used for the client part of the KV store connection as well.	No default
`[kvstore]` `sslKeysPassword`	`<string>`DEPRECATED. Use 'sslPassword' instead. More Used only when 'sslPassword' is empty.
`[kvstore]` `sslCRLPath`	`<string>`The path to the Certificate Revocation List (CRL) file. More A CRL is a list of digital certificates that have been revoked by the issuing Certificate Authority (CA) before their scheduled expiration date and can no longer be trusted. Splunkd uses the CRL file only in the following cases: When the Splunk platform instance is in Common Criteria mode (SPLUNK_COMMON_CRITERIA=1). When you have enabled certificate status validation checks by configuring the '[sslConfig]:certificateStatusValidationMethod' setting. See this setting to learn how to configure certificate status validation. The file that this setting value references must be in privacy-enhanced mail (PEM) format. NOTE: Splunk supports using the product in Common Criteria mode only for specific software configurations that the National Information Assurance Partnership (NIAP) certifies. See the "Securing Splunk Enterprise for Common Criteria" manual for specific information on the status of Common Criteria certification. This setting is optional.	empty string (no revocation list)
`[kvstore]` `modificationsReadIntervalMillisec`	`<integer>`How often, in milliseconds, to check for modifications to KV Store collections in order to replicate changes for distributed searches.	1000 (1 second)
`[kvstore]` `modificationsMaxReadSec`	`<integer>`Maximum time interval KVStore can spend while checking for modifications before it produces collection dumps for distributed searches.	30
`[kvstore]` `initialSyncMaxFetcherRestarts`	`<positive integer>`Specifies the maximum number of query restarts an oplog fetcher can perform before failing the ongoing Initial Sync attempt. More Increasing this value might help in dynamic deployments with very large KV Store databases where Initial Sync might take a long time. NOTE: This setting should be changed only if you have been asked to set it by a Splunk Support engineer. It might increase KV Store cluster failover time.	0
`[kvstore]` `max_backup_restore_threads`	`<positive integer>`Specifies the number of parallel threads to run when backing up and restoring KV store data.	4
`[kvstore]` `max_backup_restore_jobs`	`<positive integer>`Specifies the number of jobs that can be queued at a given time on a thread that backs up and restores KV store data. Each job backs up and restores a single collection.	10
`[kvstore]` `kvserviceConnectionString`	`<string>`Specifies the connection string for the external KV service. More NOTE: Do not change this setting unless instructed to do so by Splunk Support.	empty string
`[kvstore]` `defaultKVStoreType`	`local \| external \| cohosted`Set to "local" to use a local KV store instance, to "external" to use the external KV service, or to "cohosted" to use a local KV store with a cohosted PDL sidecar. More Always follow proper KV storage migration procedures when you change this setting. NOTE: Do not change this setting unless instructed to do so by Splunk Support.	local
`[kvstore]` `forceLocalForInternalCollections`	`<boolean>`Specifies whether to use the local KV store instance for internal collections when the 'defaultKVStoreType' setting is "external" or "cohosted". More A value of "true" means that the local KV store is always used for internal collections, even when 'defaultKVStoreType' is "external" or "cohosted". A value of "false" means that the local KV store is not used for internal collections when 'defaultKVStoreType' is "external" or "cohosted". Always follow proper KV storage migration procedures when you change this setting. NOTE: Do not change this setting unless Splunk Support instructs you to do so.	true
`[kvstore]` `shutDownMongo`	`<boolean>`Specifies a requirement for starting the 'mongod' process the next time Splunk software starts. More A value of "true" means that the 'mongod' process does not start if the 'defaultKVStoreType' setting is "external" or "cohosted" and the 'forceLocalForInternalCollections' setting is "false" when Splunk software starts. A value of "false" means that the 'mongod' process starts when Splunk software starts, regardless of the 'defaultKVStoreType' and 'forceLocalForInternalCollections' settings. This setting must be "false" during migration from a local KV store to the external Splunk Cloud Services (SCS) KV service or a local KV store with a cohosted PDL sidecar. NOTE: Do not change this setting unless Splunk Support instructs you to do so.	false
`[kvstore]` `max_restore_external_attempts`	`<positive integer>`Specifies the number of attempts that Splunk software makes to restore a collection from a local KV store to an external Splunk Cloud Services (SCS) KV service or a local KV store with a cohosted PDL sidecar after a failure occurs. More NOTE: Do not change this setting unless Splunk Support instructs you to do so.	5
`[kvstore]` `delayShutdownOnBackupRestoreInProgress`	`<boolean>`Whether or not splunkd should delay a shutdown if a KV Store backup or restore operation is in progress. More If set to "true", splunkd waits until either the running backup/restore operation completes, or 'splunkd_stop_timeout' seconds have elapsed since it received the shutdown request. NOTE: Setting this to "true" might delay splunkd shutdown for several minutes, depending on the amount of data that KV Store uses and the value of 'splunkd_stop_timeout'.	false
`[kvstore]` `percRAMForCache`	`<positive integer>`The percentage of total system memory that KV store can use. More Value can range from 5 to 50, inclusive. If less than 1 GB of system memory is present, only 256 MB of cache will be used. If you have less than 256 MB of system memory, you cannot use KVStore with wiredTiger. Changing this value can affect performance on KV store, Splunk Enterprise apps that use KV store, and KV store lookups. For more information, search the Splunk documentation for "KV store troubleshooting tools". If you are not using the WiredTiger storage engine, Splunk Enterprise ignores this setting.	15
`[kvstore]` `kvstoreUpgradeCheckInterval`	`<integer>`How often, in seconds, to check the status of the KV store version upgrade.	5 seconds
`[kvstore]` `kvstoreUpgradeOnStartupEnabled`	`<boolean>`REMOVED. This setting has been removed and has no effect. More In Splunk platform versions 10.3 and higher, the KV store server version upgrade is always initiated automatically when Splunk software starts up.
`[kvstore]` `kvstoreUpgradeOnStartupRetries`	`<positive int>`The number of times to retry the KV store version upgrade.	2
`[kvstore]` `kvstoreUpgradeOnStartupDelay`	`<positive int>`How long, in seconds, to delay the startup of the KV store version upgrade after Splunk software boots up.	60 seconds
`[kvstore]` `postgresMigrateOnStartup`	`<boolean>`A value of "true" means that when Splunk platform starts, it automatically initiates migration from the MongoDB storage engine to the Postgres database system. More A value of "false" means that Splunk platform does not initiate this migration.	false
`[kvstore]` `defaultCidrPrefixLength`	`<positive int>[0-32]\|disabled`The default prefix length added to IPs without such prefix in CIDR match type mode. More When this setting is enabled it must have the inclusive range 0-32. Set this setting to "disabled" to explicitly turn it off.	disabled
`[kvstore]` `ocspValidation`	`<boolean>`OCSP (Online Certificate Status Protocol) checks for certificate revocation. More A value of "true" means OSCP validation is turned on, which eliminates the requirement to periodically download a Certificate Revocation List (CRL) and restart the KV store. A value of "false" means OSCP validation is turned off. You must periodically download a CRL and restart KV store.	true

`[kvstoreSslClientConfig]`

TLS settings for the KV store client connections.
If you do not specify this stanza, splunkd uses the [kvstore] stanza TLS server settings for KV store client TLS configuration as fallback. These settings are: [kvstore]/serverCert, [kvstore]/sslPassword, [kvstore]/sslVerifyServerCert, [kvstore]/sslVerifyServerName.
Splunk platform does not fall back on the [kvstore] stanza settings if you've specified any of the settings in the [kvstoreSslClientConfig] stanza. Once you specify one setting in the [kvstoreSslClientConfig] stanza, you must specify clientCert and sslPassword, or else KV store fails.

Setting	Description	Default
`[kvstoreSslClientConfig]` `clientCert`	`<string>`The full path to the client certificate. More For more information about certificates, and how to obtain, create, and install them, search the Securing Splunk Enterprise Manual for "Introduction to Securing the Splunk Platform with TLS". The certificate must be in privacy-enhanced mail (PEM) format. Add root CA cert to the file on [sslConfig]/sslRootCAPath path.	No default
`[kvstoreSslClientConfig]` `sslVerifyServerCert`	`<boolean>`See the description of 'sslVerifyServerCert' under the [kvstore] stanza for details on this setting.	false (if you have not enabled FIPS)
`[kvstoreSslClientConfig]` `sslVerifyServerName`	`<boolean>`See the description of 'sslVerifyServerName' under the [kvstore] stanza for details on this setting.	false
`[kvstoreSslClientConfig]` `sslPassword`	`<string>`The password for the client certificate, if you created one.	No default

`[indexer_discovery]`

Setting	Description	Default
`[indexer_discovery]` `pass4SymmKey`	`<string>`Security key shared between manager node and forwarders. More If specified here, the same value must also be specified on all forwarders connecting to this manager. Unencrypted passwords must not begin with "$1$", as this is used by Splunk software to determine if the password is already encrypted.
`[indexer_discovery]` `pass4SymmKey_minLength`	`<integer>`The minimum length, in characters, that a 'pass4SymmKey' should be for a particular stanza. More When you start the Splunk platform, if the 'pass4SymmKey' is shorter in length than what you specify with this setting, the platform warns you and advises that you change the pass4SymKey. If you use the CLI to modify 'pass4SymmKey' to a value that is shorter than what you specify with this setting, the platform warns you and advises that you change the pass4SymKey.	12
`[indexer_discovery]` `polling_rate`	`<integer>`A value between 1 to 10. This value affects the forwarder polling frequency to achieve the desired polling rate. The number of connected forwarders is also taken into consideration. More The formula used to determine effective polling interval, in Milliseconds, is: (number_of_forwarders/polling_rate + 30 seconds) * 1000	10
`[indexer_discovery]` `indexerWeightByDiskCapacity`	`<boolean>`A value of "true" means it instructs the forwarders to use weighted load balancing. In weighted load balancing, load balancing is based on the total disk capacity of the target indexers, with the forwarder streaming more data to indexers with larger disks. More The traffic sent to each indexer is based on the ratio of: indexer_disk_capacity/total_disk_capacity_of_indexers_combined	false

`[cascading_replication]`

Setting	Description	Default
`[cascading_replication]` `pass4SymmKey`	`<string>`Security key shared between indexers participating in cascading replication. More The same value must be specified on all indexers participating in cascading replication. Unencrypted passwords must not begin with "$1$", as this is used by Splunk software to determine if the password is already encrypted. Empty passwords will not be accepted.	None
`[cascading_replication]` `pass4SymmKey_minLength`	`<integer>`The minimum length, in characters, that a 'pass4SymmKey' should be for a particular stanza. More When you start the Splunk platform, if the 'pass4SymmKey' is shorter in length than what you specify with this setting, the platform warns you and advises that you change the pass4SymKey. If you use the CLI to modify 'pass4SymmKey' to a value that is shorter than what you specify with this setting, the platform warns you and advises that you change the pass4SymKey.	12
`[cascading_replication]` `max_replication_threads`	`<integer>`Maximum threads used for replicating metadata and payload to search peers. More If set to "auto", the peer auto-tunes the number of threads it uses for cascading replication. If the peer has 3 or fewer CPUs, it allocates 2 threads. If the peer has 4-7 CPUs, it allocates up to '# of CPUs - 2' threads. If the peer has 8-15 CPUs, it allocates up to '# of CPUs - 3' threads. If the peer has 16 or more CPUs, it allocates up to '# of CPUs - 4' threads. Maximum accepted value for this setting is 16.	auto
`[cascading_replication]` `max_replication_jobs`	`<integer>`Maximum jobs used for replicating metadata and payload to search peers.	5
`[cascading_replication]` `cascade_replication_plan_reap_interval`	`<interval>`The interval at which the cascade replication plans are reaped. More The interval can be specified as a string for minutes, seconds, hours, days. For example: 60s, 1m, 1h, 1d etc. Maximum accepted value is 5h	1h
`[cascading_replication]` `cascade_replication_plan_age`	`<interval>`The age of the cascade replication plan when it gets reaped. More The interval can be specified as a string for minutes, seconds, hours, or days. For example: 60s, 1m, 1h, 1d etc. Maximum accepted value is 24h	8h
`[cascading_replication]` `cascade_replication_plan_fanout`	`auto\|<positive integer>`Number of receivers that each sender replicates to at a time. More If set to auto, Splunk automatically calculates an optimal fanout, based on the maximum number of replication threads, as determined by the 'max_replication_threads' setting under [cascading_replication] in server.conf. If set to an integer, the integer must be no greater than the number of cluster peers, or, in the case of multisite clustering, no greater than the least number of peers on any one site.	auto
`[cascading_replication]` `cascade_replication_plan_topology`	`size_balanced`Topology used for building a cascading plan. More When set to size_balanced, receivers are evenly distributed among senders. Senders on the same layer have same or similar number of receivers.	size_balanced
`[cascading_replication]` `cascade_replication_plan_select_policy`	`random`Policy for deciding which receivers the senders pick. More When set to random, receivers are randomly picked.	random

`[node_auth]`

Setting	Description	Default
`[node_auth]` `signatureVersion`	`<comma-separated list>`A list of authentication protocol versions that nodes of a Splunk deployment use to authenticate to other nodes. More Each version of node authentication protocol implements an algorithm that specifies cryptographic parameters to generate authentication data. Nodes may only communicate using the same authentication protocol version. For example, if you set "signatureVersion = v1,v2" on one node, that node sends and accepts authentication data using versions "v1" and "v2" of the protocol, and you must also set "signatureVersion" to one of "v1", "v2", or "v1,v2" on other nodes for those nodes to mutually authenticate. For higher levels of security, set 'signatureVersion' to "v2".	v1,v2

`[cachemanager]`

Setting	Description	Default
`[cachemanager]` `max_concurrent_downloads`	`<unsigned integer>`The maximum number of buckets that can be downloaded simultaneously from external storage	8
`[cachemanager]` `max_concurrent_uploads`	`<unsigned integer>`The maximum number of buckets that can be uploaded simultaneously to external storage.	8
`[cachemanager]` `eviction_policy`	`<string>`The name of the eviction policy to use. More Current options: lru, clock, random, lrlt, noevict, lruk Do not change the value from the default unless instructed by Splunk Support.	lru
`[cachemanager]` `enable_eviction_priorities`	`<boolean>`When requesting buckets, search peers can give hints to the Cache Manager about the relative importance of buckets. More When enabled, the Cache Manager takes the hints into consideration; when disabled, hints are ignored.	true
`[cachemanager]` `eviction_padding`	`<positive integer>`Specifies the additional space, in megabytes, beyond 'minFreeSpace' that the cache manager uses as the threshold to start evicting data. More If free space on a partition falls below ('minFreeSpace' + 'eviction_padding'), then the cache manager tries to evict data from remote storage enabled indexes.	5120 (~5GB)
`[cachemanager]` `max_cache_size`	`<positive integer>`Specifies the maximum space, in megabytes, per partition, that the cache can occupy on disk. If this value is exceeded, the cache manager starts evicting buckets. More A value of 0 means this setting is not used to control cache eviction. Eviction will instead be based on the sum of 'minFreeSpace' and 'eviction_padding' settings, which limits the size of the partition that the cache resides on.	0
`[cachemanager]` `persist_pending_upload_from_external`	`<boolean>`Currently not supported. This setting is related to a feature that is still under development. More Specifies whether the information of the buckets that have been uploaded to remote storage can be serialized to disk or not. When set to true, this information is serialized to disk and the bucket is deemed to be on remote storage. Otherwise, the bucket is deemed to be not on remote storage and bucket is then uploaded to remote storage.	true
`[cachemanager]` `persistent_id_set_remove_min_sync_secs`	`<unsigned integer>`Currently not supported. This setting is related to a feature that is still under development. More Cache manager persists the set of objects that are no longer pending upload to the remote storage based on when the previous set of changes were persisted to disk. This setting controls the interval from the last persist time that cache manager waits to persist the current set of changes to disk.	5
`[cachemanager]` `local_delete_summary_metadata_ttl`	`<unsigned integer>`Currently not supported. This setting is related to a feature that is still under development. More The local copy of a bucket needs to be synced with the copy in remote storage only when the bucket switches primaries. However in certain experimental modes of operation the delete journals in the remote storage could be mutated without an update to the local copy. Similarly, accelerated summaries in remote storage could be updated without an update to the local copy. This setting is meant for use in such modes. The Cache manager will make a best effort to invalidate the local delete journals and summary metadata files periodically. The period will be controlled by this ttl. A value of 0 will disable this behavior	0
`[cachemanager]` `hotlist_recency_secs`	`<unsigned integer>`When a bucket is older than this value, it becomes eligible for eviction. Buckets younger than this value are evicted only if there are no older buckets eligible for eviction. More For the purpose of determining recency, the age of a bucket is calculated by subtracting the time of the bucket's most recent event data from the current time. For example, if the current time (expressed in UTC epoch time) is 1567891234 and the bucket is named db_1567809123_1557891234_10_8A21BEE9-60D4-436B-AA6D-21B68F631A8B, thus indicating that the time of the most recent event in the bucket is 1567809123, then the bucket's age, in seconds, is 82111 (~23 hours). Ensure that the cache is of sufficient size to handle the value of this setting. Otherwise, cache eviction cannot function optimally. In other words, do not configure this setting to a size that will cause the cache to retain a quantity of buckets that approach or exceed the size of the cache based on this setting alone. Also, consider the amount of data you're ingesting and the needs of the types of searches you run. As a best practice, start with a fairly low value for this setting and adjust over time. For example, if the cache size is 100 GB and you typically add 10 GB of new buckets to the indexer in a 24 hour period, setting this to 172800 (48 hours) would mean that the cache manager will try to keep those 20 GB of recent buckets in the cache all the time. This setting can be overridden on a per-index basis in indexes.conf.	86400 (24 hours)
`[cachemanager]` `hotlist_bloom_filter_recency_hours`	`<unsigned integer>`When a bucket's non-journal and non-tsidx files (such as bloomfilter files) are older than this value, those files become eligible for eviction. Bloomfilter and associated files younger than this value are evicted only if there are no older files eligible for eviction. More The recency of a bloomfilter file is based on its bucket's recency and is calculated in the same manner described for 'hotlist_recency_secs'. This setting works in concert with 'hotlist_recency_secs' which is designed to be configured for a shorter age. If 'hotlist_recency_secs' leads to the eviction of a bucket, the bloomfilter and associated files will continue to remain in the cache until they reach the age configured by this setting. Thus, the bucket will remain in cache, but without its journal and tsidx files. This setting can be overridden on a per-index basis in indexes.conf.	360 (15 days)
`[cachemanager]` `evict_on_stable`	`<boolean>`When the source peer completes upload of a bucket to remote storage, it notifies the target peers so that they can evict any local copies of the bucket. More When set to true, each target peer evicts its local copy, if any, upon such notification. When set to false, each target peer continues to store its local copy, if any, until its cache manager eventually evicts the bucket according to its cache eviction policy.	false
`[cachemanager]` `max_file_exists_retry_count`	`<unsigned integer>`The cache manager retries its check on whether the file exists on remote storage when the check fails due to network errors until the retry count exceeds this setting.	5
`[cachemanager]` `access_logging`	`<boolean>`Enables/disables logging to the splunkd_access.log file for cachemanager requests.	false
`[cachemanager]` `cache_usage_collection_interval_minutes`	`<positive integer>`Currently not supported. This setting is related to a feature that is still under development. More Interval at which cache usage information is reported to metrics.log. The cache usage logging reports cache usage, in bytes, broken down by cache type (bid, dma, ra, metrics), index and by time range. The time bins are defined by the setting 'cache_usage_collection_time_bins'. A value of 0 will disable this feature. Do not use a value less than 10 (minutes). Doing so can affect performance. Hot buckets are not managed by the cache manager and not reflected in the log messages.	10
`[cachemanager]` `cache_usage_collection_time_bins`	`<comma-separated list>`Currently not supported. This setting is related to a feature that is still under development. More This setting is used when 'cache_usage_collection_interval_minutes' is non-zero. See the 'cache_usage_collection_interval_minutes' section for more information. This comma-separated list of integers, representing days, are boundaries to the time ranges to which the cache usage is broken down and reported. There is an implicit bin, 0, that represents all data more recent than the first non-zero value. The highest value specified will represent all data older than that value. For example, using the default "1, 3, 7, 14, 30, 60, 90", cache usage will collect the size of buckets whose latest-time (endEpoch) into the following bins: 0 (future-1d), 1 (1d-3d), 3 (3d-7d), 7 (7d-15d), 15 (15d-30d), 30 (30d-60d), 60 (60d-90d), 90 (90d and older).	1, 3, 7, 15, 30, 60, 90
`[cachemanager]` `cache_usage_collection_per_index`	`<boolean>`Currently not supported. This setting is related to a feature that is still under development. More Enables the reporting cache usage information by index. This setting is used when 'cache_usage_collection_interval_minutes' is non-zero. See the 'cache_usage_collection_interval_minutes' section for more information.	false
`[cachemanager]` `batch_registration`	`<boolean>`This setting enables/disables batch registration of buckets upon indexer startup. More If this setting is disabled, then when an indexer starts up, its cache manager registers each index bucket individually. This can slow the startup process. If an indexer is experiencing long startup durations, enable this setting to register buckets in batches. The size of each batch of buckets is set with 'batch_registration_size'.	true
`[cachemanager]` `batch_registration_size`	`<unsigned integer>`This setting specifies the size of each batch of buckets that are registered. More This setting is used when 'batch_registration' is enabled. Use the default value unless instructed otherwise by Splunk Support.	5000
`[cachemanager]` `cache_upload_backoff_sleep_secs`	`<unsigned_integer>`This setting specifies the interval, in seconds, that the cache manager waits to retry an upload to the remote store after encountering a 4xx HTTP error. More A value of 0 causes the cache manager to continue retrying the upload without performing a backoff.	60
`[cachemanager]` `cache_upload_bucket_has_priority`	`<boolean>`This setting when enabled will prioritize bucket upload over DMA and RA uploads. Otherwise, uploads will be done in the order they were scheduled.	false
`[cachemanager]` `max_known_remote_absent_summaries`	`<unsigned_integer>`This setting specifies the maximum number of frozen (absent) summaries that the cache manager maintains in a list. More The list of frozen summaries helps the cache manager to avoid making calls to the remote store that could result in an HTTP 404 "not found" error. By increasing the limit, you decrease the likelihood of such calls, while potentially using more memory in the process. When this value is reached, the cache manager deletes the oldest frozen summaries from the list.	200000 (200K)

`[raft_statemachine]`

Setting	Description	Default
`[raft_statemachine]` `disabled`	`<boolean>`Set to true to disable the raft statemachine. More This feature requires search head clustering to be enabled. Any consensus replication among search heads uses this feature.	true
`[raft_statemachine]` `replicate_search_peers`	`<boolean>`Add/remove search-server request is applied on all members of a search head cluster, when this value to set to true. More Requires a healthy search head cluster with a captain.

`[watchdog]`

Setting	Description	Default
`[watchdog]` `disabled`	`<boolean>`Disables thread monitoring functionality. More Any thread that has been blocked for more than 'responseTimeout' milliseconds is logged to $SPLUNK_HOME/var/log/watchdog/watchdog.log	false.
`[watchdog]` `responseTimeout`	`<decimal>`Maximum time, in seconds, that a thread can take to respond before the watchdog logs a 'thread blocked' incident. More The minimum value for 'responseTimeout' is 0.1. If you set 'responseTimeout' to lower than 0.1, the setting uses the minimum value instead.	8
`[watchdog]` `actions`	`<comma-separated list>`A comma-separated list of actions that execute sequentially when a blocked thread is encountered. More The following actions can be included in the list: 'pstacks', 'script', and 'bulletin'. 'pstacks' enables call stack generation for a blocked thread. Call stack generation gives the user immediate information on the potential thread bottleneck or deadlock. The watchdog saves each call stack in a separate file in $SPLUNK_HOME/var/log/watchdog with the following file name format: wd_stack_<pid>_<thread_name>_%Y_%m_%d_%H_%M_%S.%f_<uid>.log. 'script' executes the script configured by the [watchdogaction:script] stanza. 'bulletin' causes a message to be displayed on the web interface. NOTE: Use this setting only under the guidance of a Splunk Support engineer. It might degrade performance by increasing CPU and disk usage.	empty list (no action executed)
`[watchdog]` `actionsInterval`	`<decimal>`The interval, in seconds, that the watchdog uses while tracing a blocked thread. The watchdog executes each action every 'actionsInterval' seconds. More The minimum value for 'actionsInterval' is 0.01. If you set 'actionsInterval' to lower than 0.01, the setting uses the minimum value instead. NOTE: A very brief interval might reduce performance by increasing CPU usage. Frequently-executed actions can also slow down performance.	1
`[watchdog]` `pstacksEndpoint`	`<boolean>`Whether or not the 'pstacks' endpoint at '/services/server/pstacks' is turned on. More This endpoint allows ad-hoc pstacks generation of all running threads. A value of "true" means that the 'pstacks' endpoint is turned on. A value of "false" means that the 'pstacks' endpoint is turned off. This setting has no effect if 'watchdog' has a value of "false". Use this setting only during troubleshooting and only if a Splunk Support engineer explicitly asks you to set it. CAUTION: On Windows machines, requests to the 'pstacks' endpoint can cause the Splunk daemon to become unresponsive. While this rarely happens under certain specific thread collection conditions, if it does happen, further requests to the endpoint will fail, requiring a restart of the Splunk platform instance.	true
`[watchdog]` `usePreloadedPstacks`	`<boolean>`Use preloaded wrapper to enable pstacks. More NOTE: This setting should be changed only during troubleshooting and only if you have been explicitly asked to disable it by a Splunk Support engineer.	true

`[watchdog:<threadname>]`

Settings under this stanza apply only to the specified "<threadname>".
When these per-thread settings are defined, they take precedence over the default settings in the [watchdog] stanza.
NOTE: Use this feature only under the guidance of Splunk Support. A Splunk engineer will provide the <threadname>.

Setting	Description	Default
`[watchdog:<threadname>]` `disabled`	`<boolean>`Disables thread monitoring for the specified thread. More If the thread has been blocked for more than 'responseTimeout' milliseconds the Splunk platform logs it to $SPLUNK_HOME/var/log/watchdog/watchdog.log	false.
`[watchdog:<threadname>]` `responseTimeout`	`<decimal>`Maximum time, in seconds, that this thread can take to respond before the watchdog logs a 'thread blocked' incident. More The minimum value for 'responseTimeout' is 0.1. If you set 'responseTimeout' to lower than 0.1, the setting uses the minimum value instead.	8
`[watchdog:<threadname>]` `actions`	`<comma-separated list>`The actions that are to run sequentially when this thread is blocked. More The following actions can be included in the list: 'pstacks', 'script', and 'bulletin'. 'pstacks' turns on call stack generation for the blocked thread. Call stack generation gives you immediate information on the potential thread bottleneck or deadlock. The watchdog saves each call stack in a separate file in $SPLUNK_HOME/var/log/watchdog with the following file name format: wd_stack_<pid>_<thread_name>_%Y_%m_%d_%H_%M_%S.%f_<uid>.log. 'script' runs the script configured by the [watchdogaction:script] stanza. 'bulletin' causes Splunk Web to display a message about the blocked thread. Use this setting only under the guidance of a Splunk Support engineer. It might degrade performance by increasing CPU and disk usage. CAUTION: On Windows machines, the 'pstacks' action can cause the Splunk daemon to become unresponsive. If this happens, you must restart the Splunk platform instance to restore full functionality. Monitor the Splunk daemon whenever you turn on this automated action.	No default
`[watchdog:<threadname>]` `actionsInterval`	`<decimal>`The interval, in seconds, that the watchdog uses while tracing this blocked thread. The watchdog executes each action every 'actionsInterval' seconds. More The minimum value for 'actionsInterval' is 0.01. If you set 'actionsInterval' to lower than 0.01, the setting uses the minimum value instead. NOTE: A very brief interval might reduce performance by increasing CPU usage. Frequently-executed actions can also slow down performance.	1

`[watchdogaction:pstacks]`

Setting under this stanza are ignored if 'pstacks' is not enabled in the 'actions' list.
NOTE: Change these settings only during troubleshooting, and if you have been asked to set it by a Splunk Support engineer. It can affect performance by increasing CPU and disk usage.

Setting	Description	Default
`[watchdogaction:pstacks]` `dumpAllThreads`	`<boolean>`Determines whether or not the watchdog saves stacks of all monitored threads when it encounters a blocked thread. More If you set 'dumpAllThreads' to true, the watchdog generates call stacks for all threads, regardless of thread state.	true
`[watchdogaction:pstacks]` `stacksBufferSizeOrder`	`<unsigned integer>`The maximum number of call stacks an internal queue can hold. More The watchdog uses the internal queue to temporarily store a call stack between the time the watchdog generates the call stack and the time it saves the call stack to a file. Increase the value of this setting if you see gaps in stack files due to high frequency of call stack generation. This might occur when, for example, you set 'stacksBufferSizeOrder' to a very low value, or if the number of threads is high. This number must be in the range 1 to 16. The watchdog uses this value to calculate the real size of the buffer, whose value must be a power of 2. For example, if 'stackBufferSizeOrder' is 4, the size of the buffer is 4 ^ 2, or 16. CAUTION: Setting to too low a value can cause dropped call stacks, and too high a value can cause increased memory consumption.	14
`[watchdogaction:pstacks]` `maxStacksPerBlock`	`<unsigned integer>`Maximum number of stacks that the watchdog can generate for a blocked thread. More If you set 'dumpAllThreads' to true, the watchdog generates call stacks for all threads. If the blocked thread starts responding again, the count of stacks that the watchdog has generated resets to zero. If another thread blockage occurs, the watchdog begins generating stacks again, up to 'maxStacksPerBlock' stacks. When set to 0, an unlimited number of stacks will be generated. list.	60
`[watchdogaction:pstacks]` `batchStacksThreshold`	`<unsigned integer>\|auto`The timeout, in milliseconds, after which the watchdog generates a new call stack file. More This setting controls the batching up of call stacks when saving them to files, and can decrease the number of files the watchdog creates. When set to 0, batching is disabled. When set to 'auto', Splunk Enterprise determines the best frequency to create new call stack files.	auto

`[watchdogaction:script]`

Setting under this stanza are ignored if 'script' is not enabled in the 'actions' list.
NOTE: Change these settings only during troubleshooting, and if you have been asked to set it by a Splunk Support engineer. It can affect performance by increasing CPU and disk usage.

Setting	Description	Default
`[watchdogaction:script]` `path`	`<string>`The path to the script to execute when the watchdog triggers the action. More If you do not set 'path', the watchdog ignores the action.	No default
`[watchdogaction:script]` `useShell`	`<boolean>`A value of "true" means the script runs from the OS shell ("/bin/sh -c" on UNIX, "cmd.exe /c" on Windows) More A value of "false" means the program will be run directly without attempting to expand shell metacharacters.	false
`[watchdogaction:script]` `forceStop`	`<boolean>`Whether or not the watchdog forcefully stops an active watchdog action script when a blocked thread starts to respond. More Use this setting when, for example, the watchdog script has internal logic that controls its lifetime and must run without interruption.	false
`[watchdogaction:script]` `forceStopOnShutdown`	`<boolean>`If you set this setting to "true", the watchdog forcefully stops active watchdog scripts upon receipt of a shutdown request.	true

`[parallelreduce]`

Setting	Description	Default
`[parallelreduce]` `pass4SymmKey`	`<string>`DEPRECATED. The setting is no longer required.
`[parallelreduce]` `pass4SymmKey_minLength`	`<integer>`The minimum length, in characters, that a 'pass4SymmKey' should be for a particular stanza. More When you start the Splunk platform, if the 'pass4SymmKey' is shorter in length than what you specify with this setting, the platform warns you and advises that you change the pass4SymKey. If you use the CLI to modify 'pass4SymmKey' to a value that is shorter than what you specify with this setting, the platform warns you and advises that you change the pass4SymKey.	12

`[scs]`

Setting	Description	Default
`[scs]` `mvl-enabled`	`<boolean>`Specifies whether MVL (Multi-Valued Lookup) is enabled and supported on KVService. More NOTE: Do not change this setting unless instructed to do so by Splunk Support.	false

`[search_artifact_remote_storage]`

Setting	Description	Default
`[search_artifact_remote_storage]` `disabled`	`<boolean>`Currently not supported. This setting is related to a feature that is still under development. More Optional. Specifies whether or not search artifacts should be stored remotely. Splunkd does not clean up artifacts from remote storage. Set up cleanup separately with the remote storage provider.	true
`[search_artifact_remote_storage]` `path`	`<path on server>`The path setting points to the remote storage location where artifacts reside. More The format for this setting is: <scheme>://<remote-location-specifier> The "scheme" identifies a supported external storage system type. The "remote-location-specifier" is an external system-specific string for identifying a location inside the storage system. These external systems are supported: Object stores that support AWS's S3 protocol. These use the scheme "s3". For example, "path=s3://mybucket/some/path". This is a required setting. If you do not set the path, the search artifact remote storage feature is disabled.	No default
`[search_artifact_remote_storage]` `upload_archive_format`	`[none\|tar.lz4]`Creates a tarball so that the entire artifact can be stored as a single object on the remote storage. More This can reduce time to upload and artifact when the remote storage has a high seek penalty and the search artifact contains more than 100 individual files	none
`[search_artifact_remote_storage]` `remote.s3.header.<http-method-name>.<header-field-name>`	`<String>`Enable server-specific features, such as reduced redundancy, encryption, and so on, by passing extra HTTP headers with the REST requests. More The <http-method-name> can be any valid HTTP method. For example, GET, PUT, or ALL, for setting the header field for all HTTP methods. Optional. Example: remote.s3.header.PUT.x-amz-storage-class = REDUCED_REDUNDANCY
`[search_artifact_remote_storage]` `remote.s3.access_key`	`<String>`Specifies the access key to use when authenticating with the remote storage system supporting the S3 API. More If not specified, the indexer looks for these environment variables: AWS_ACCESS_KEY_ID or AWS_ACCESS_KEY (in that order). If the environment variables are not set and the indexer is running on EC2, the indexer attempts to use the access key from the IAM role. Optional.	No default
`[search_artifact_remote_storage]` `remote.s3.secret_key`	`<String>`Specifies the secret key to use when authenticating with the remote storage system supporting the S3 API. More If not specified, the indexer looks for these environment variables: AWS_SECRET_ACCESS_KEY or AWS_SECRET_KEY (in that order). If the environment variables are not set and the indexer is running on EC2, the indexer attempts to use the secret key from the IAM role. Optional.	No default
`[search_artifact_remote_storage]` `remote.s3.list_objects_version`	`v1\|v2`The AWS S3 Get Bucket (List Objects) Version to use. More See AWS S3 documentation "GET Bucket (List Objects) Version 2" for details.	v1
`[search_artifact_remote_storage]` `remote.s3.signature_version`	`v2\|v4`The signature version to use when authenticating with the remote storage system supporting the S3 API. More For 'sse-kms' server-side encryption scheme, you must use signature_version=v4. Optional.	v4
`[search_artifact_remote_storage]` `remote.s3.auth_region`	`<String>`The authentication region to use for signing requests when interacting with the remote storage system supporting the S3 API. More Used with v4 signatures only. If unset and the endpoint (either automatically constructed or explicitly set with remote.s3.endpoint setting) uses an AWS URL (for example, https://s3.us-west-1.amazonaws.com), the instance attempts to extract the value from the endpoint URL (for example, "us-west-1"). See the description for the remote.s3.endpoint setting. If unset and an authentication region cannot be determined, the request will be signed with an empty region value. Optional.	No default
`[search_artifact_remote_storage]` `remote.s3.use_delimiter`	`<boolean>`Specifies whether a delimiter (currently "guidSplunk") should be used to list the objects that are present on the remote storage. More A delimiter groups objects that have the same delimiter value so that the listing process can be more efficient as it does not need to report similar objects. Optional.	true
`[search_artifact_remote_storage]` `remote.s3.supports_versioning`	`<boolean>`Specifies whether the remote storage supports versioning. More Versioning is a means of keeping multiple variants of an object in the same bucket on the remote storage. This setting determines how splunkd removes data from remote storage. A value of "true" means splunkd will delete all versions of objects at time of data removal. Otherwise, A value of "false" means splunkd will use a simple DELETE (See https://docs.aws.amazon.com/AmazonS3/latest/dev/DeletingObjectVersions.html). Optional.	true
`[search_artifact_remote_storage]` `remote.s3.endpoint`	`<URL>`The URL of the remote storage system supporting the S3 API. More The scheme, http or https, can be used to enable or disable SSL connectivity with the endpoint. If not specified and the indexer is running on EC2, the endpoint is constructed automatically based on the EC2 region of the instance where the indexer is running, as follows: https://s3.<region>.amazonaws.com Optional. Example: https://s3.us-west-2.amazonaws.com
`[search_artifact_remote_storage]` `remote.s3.multipart_download.part_size`	`<unsigned integer>`Sets the download size of parts during a multipart download. More This setting uses HTTP/1.1 Range Requests (RFC 7233) to improve throughput overall and for retransmission of failed transfers. A value of 0 disables downloading in multiple parts, i.e., files are always downloaded as a single (large) part. Do not change this value unless that value has been proven to improve throughput. Minimum value: 5242880 (5 MB) Optional.	134217728 (128 MB)
`[search_artifact_remote_storage]` `remote.s3.multipart_upload.part_size`	`<unsigned integer>`Sets the upload size of parts during a multipart upload. More Minimum value: 5242880 (5 MB) Optional.	134217728 (128 MB)
`[search_artifact_remote_storage]` `remote.s3.multipart_max_connections`	`<unsigned integer>`Specifies the maximum number of HTTP connections to have in progress for either multipart download or upload. More A value of 0 means unlimited.	8
`[search_artifact_remote_storage]` `remote.s3.retry_policy`	`max_count`Sets the retry policy to use for remote file operations. More A retry policy specifies whether and how to retry file operations that fail for those failures that might be intermittent. Retry policies: + "max_count": Imposes a maximum number of times a file operation is retried upon intermittent failure both for individual parts of a multipart download or upload and for files as a whole. Optional.	max_count
`[search_artifact_remote_storage]` `remote.s3.max_count.max_retries_per_part`	`<unsigned integer>`When the remote.s3.retry_policy setting is max_count, sets the maximum number of times a file operation is retried upon intermittent failure. More The count is maintained separately for each file part in a multipart download or upload. Optional.	1
`[search_artifact_remote_storage]` `remote.s3.max_count.max_retries_in_total`	`<unsigned integer>`When the remote.s3.retry_policy setting is max_count, sets the maximum number of times a file operation is retried upon intermittent failure. More The count is maintained for each file as a whole. Optional.	1
`[search_artifact_remote_storage]` `remote.s3.timeout.connect`	`<unsigned integer>`Set the connection timeout, in milliseconds, to use when interacting with S3 for this volume. More Optional.	5000 (5 seconds)
`[search_artifact_remote_storage]` `remote.s3.timeout.read`	`<unsigned integer>`Set the read timeout, in milliseconds, to use when interacting with S3 for this volume. More Optional.	60000 (60 seconds)
`[search_artifact_remote_storage]` `remote.s3.timeout.write`	`<unsigned integer>`Set the write timeout, in milliseconds, to use when interacting with S3 for this volume. More Optional.	60000 (60 seconds)
`[search_artifact_remote_storage]` `remote.s3.sslVerifyServerCert`	`<boolean>`If this is set to true, Splunk verifies certificate presented by S3 server and checks that the common name/alternative name matches the ones specified in 'remote.s3.sslCommonNameToCheck' and 'remote.s3.sslAltNameToCheck'. More Optional.	false
`[search_artifact_remote_storage]` `remote.s3.sslVersions`	`<comma-separated list>`The list of TLS versions to use to connect to 'remote.s3.endpoint'. More The versions available are "tls1.0", "tls1.1", "tls1.2", and "tls1.3". The special version "*" selects all supported versions. The version "tls" selects all versions tls1.0 or newer. If a version is prefixed with "-" it is removed from the list. SSL versions 2 and 3 are always disabled. "-ssl2" and "-ssl3" are accepted as values in the version list, but have no effect. Optional.	tls1.2,tls1.3
`[search_artifact_remote_storage]` `remote.s3.sslCommonNameToCheck`	`<commonName1>, <commonName2>, ..`If this value is set, and 'remote.s3.sslVerifyServerCert' is set to true, splunkd checks the common name of the certificate presented by the remote server (specified in 'remote.s3.endpoint') against this list of common names.	No default
`[search_artifact_remote_storage]` `remote.s3.sslAltNameToCheck`	`<alternateName1>, <alternateName2>, ..`If this value is set, and 'remote.s3.sslVerifyServerCert' is set to true, splunkd checks the alternative name(s) of the certificate presented by the remote server (specified in 'remote.s3.endpoint') against this list of subject alternative names.	No default
`[search_artifact_remote_storage]` `remote.s3.sslRootCAPath`	`<path>`Full path to the Certificate Authority (CA) certificate PEM format file containing one or more certificates concatenated together. S3 certificate is validated against the CAs present in this file. More Optional.	[sslConfig/caCertFile] in the server.conf file
`[search_artifact_remote_storage]` `remote.s3.cipherSuite`	`<cipher suite string>`If set, uses the specified cipher string for the SSL connection. More If not set, uses the default cipher string. Must specify 'dhFile' to enable any Diffie-Hellman ciphers. Optional.	TLSv1+HIGH:TLSv1.2+HIGH:@STRENGTH
`[search_artifact_remote_storage]` `remote.s3.ecdhCurves`	`<comma separated list>`ECDH curves to use for ECDH key negotiation. More The curves should be specified in the order of preference. The client sends these curves as a part of Client Hello. Splunk software only supports named curves specified by their SHORT names. The list of valid named curves by their short/long names can be obtained by executing this command: $SPLUNK_HOME/bin/splunk cmd openssl ecparam -list_curves e.g. ecdhCurves = prime256v1,secp384r1,secp521r1 Optional.	No default
`[search_artifact_remote_storage]` `remote.s3.dhFile`	`<path>`PEM format Diffie-Hellman parameter file name. More DH group size should be no less than 2048bits. This file is required in order to enable any Diffie-Hellman ciphers. Optional.	No default
`[search_artifact_remote_storage]` `remote.s3.encryption`	`sse-s3 \| sse-kms \| sse-c \| none`Specifies the scheme to use for Server-side Encryption (SSE) for data-at-rest. More sse-s3: Check http://docs.aws.amazon.com/AmazonS3/latest/dev/UsingServerSideEncryption.html sse-kms: Check http://docs.aws.amazon.com/AmazonS3/latest/dev/UsingKMSEncryption.html sse-c: Check http://docs.aws.amazon.com/AmazonS3/latest/dev/ServerSideEncryptionCustomerKeys.html none: no Server-side encryption enabled. Data is stored unencrypted on the remote storage. Optional.	none
`[search_artifact_remote_storage]` `remote.s3.encryption.sse-c.key_type`	`kms`Optional More Determines the mechanism Splunk uses to generate the key for sending over to S3 for SSE-C. The only valid value is 'kms', indicating AWS KMS service. One must specify required KMS settings: e.g. remote.s3.kms.key_id for Splunk to start up while using SSE-C. Optional.	kms
`[search_artifact_remote_storage]` `remote.s3.encryption.sse-c.key_refresh_interval`	`<unsigned integer>`Specifies the period, in seconds, at which a new key is generated and used for encrypting any new data being uploaded to S3. More Optional.	86400 (24 hours)
`[search_artifact_remote_storage]` `remote.s3.kms.key_id`	`<string>`Required if remote.s3.encryption = sse-c \| sse-kms More Specifies the identifier for Customer Master Key (CMK) on KMS. It can be the unique key ID or the Amazon Resource Name (ARN) of the CMK or the alias name or ARN of an alias that refers to the CMK. Examples: Unique key ID: 1234abcd-12ab-34cd-56ef-1234567890ab CMK ARN: arn:aws:kms:us-east-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab Alias name: alias/ExampleAlias Alias ARN: arn:aws:kms:us-east-2:111122223333:alias/ExampleAlias	No default
`[search_artifact_remote_storage]` `remote.s3.kms.access_key`	`<string>`Similar to 'remote.s3.access_key'. More If not specified, KMS access uses 'remote.s3.access_key'. Optional.	No default
`[search_artifact_remote_storage]` `remote.s3.kms.secret_key`	`<string>`Optional. More Similar to 'remote.s3.secret_key'. If not specified, KMS access uses 'remote.s3.secret_key'. Optional.	No default
`[search_artifact_remote_storage]` `remote.s3.kms.auth_region`	`<string>`Required if 'remote.s3.auth_region' is not set and Splunk can not automatically extract this information. More Similar to 'remote.s3.auth_region'. If not specified, KMS access uses 'remote.s3.auth_region'.	No default
`[search_artifact_remote_storage]` `remote.s3.kms.max_concurrent_requests`	`<unsigned integer>`Limits maximum concurrent requests to KMS from this Splunk instance. More NOTE: Can severely affect search performance if set to very low value. Optional.	10
`[search_artifact_remote_storage]` `remote.s3.kms.<ssl_settings>`	`<...>`Check the descriptions of the SSL settings for remote.s3.<ssl_settings> above. e.g. remote.s3.sslVerifyServerCert. More Valid ssl_settings are sslVerifyServerCert, sslVersions, sslRootCAPath, sslAltNameToCheck, sslCommonNameToCheck, cipherSuite, ecdhCurves and dhFile. All of these are optional and fall back to same defaults as the 'remote.s3.<ssl_settings>'.

`[s3_client_threads]`

Setting	Description	Default
`[s3_client_threads]` `pool_size`	`<positive integer> \| per_client`Thread pool size for asynchronous S3 client transactions. More If a positive integer value is specified, a single thread pool is shared among internal components that use the S3 client. If the "per_client" value is specified, the thread pool size for each component is set in the [s3_client_threads:<component>] stanza. NOTE: Do not change this setting unless instructed to do so by Splunk Support.	1
`[s3_client_threads]` `enable_for_sync_transactions`	`<boolean>`Whether or not the thread pool for synchronous S3 client transactions is turned on. More Depending on the context, this setting can help improve search performance when you turn it on. A value of "true" means that the thread pool will be used for synchronous S3 client transactions. A value of "false" means that the thread pool won't be used for synchronous S3 client transactions.	false

`[s3_client_threads:<component>]`

Setting	Description	Default
`[s3_client_threads:<component>]` `pool_size`	`<positive integer>`Thread pool size for asynchronous S3 client transactions for a particular internal Splunk component. More This setting takes effect only if the 'pool_size' setting in the [s3_client_threads] stanza is set to "per_client". NOTE: Do not change this setting unless instructed to do so by Splunk Support.

`[hot_bucket_streaming]`

Setting	Description	Default
`[hot_bucket_streaming]` `slices_list_executor_workers`	`<unsigned integer>`Number of workers that do list operations to discover slices during bucket recovery. More Must be greater than 0.	4
`[hot_bucket_streaming]` `slices_download_executor_workers`	`<unsigned integer>`Number of workers that download slices during bucket recovery. More Must be greater than 0.	10
`[hot_bucket_streaming]` `slices_build_executor_workers`	`<unsigned integer>`Maximum number of parallel bucket rebuilds during bucket recovery. More Must be greater than 0.	4
`[hot_bucket_streaming]` `slices_removal_executor_workers`	`<unsigned integer>`Number of workers that remove slices after a bucket rolls to warm or is rebuilt. More Must be greater than 0.	2
`[hot_bucket_streaming]` `slices_upload_executor_workers`	`<unsigned integer>`Number of workers that upload slices from hot buckets. More Must be greater than 0.	10
`[hot_bucket_streaming]` `slices_upload_executor_capacity`	`<unsigned integer>`Maximum number of queued slices to be uploaded. This affects the same thread pool that uses the 'slices_upload_executor_workers' setting. More A value of 0 means that the queue capacity is unlimited.	10
`[hot_bucket_streaming]` `slices_upload_send_interval`	`<interval><unit>`Periodic send interval, in seconds, for the slices to be uploaded. More Examples: 10s, 1m Must not be greater than 300s or 5m	5s
`[hot_bucket_streaming]` `slices_upload_size_threshold`	`<unsigned integer>[B\|KB\|MB]`Slice size threshold. More When this threshold is reached, slice coalescing ends and the accumulated slice is uploaded. Must be a positive number followed by a size suffix. Valid suffixes: b: bytes, kb: kilobytes, mb: megabytes Suffixes are case insensitive. Must not be greater than 10MB	1MB. On indexer cluster peers, the default is 128KB
`[hot_bucket_streaming]` `slices_upload_retry_pending`	`<unsigned integer>`Maximum number of upload slices that could be pending retry due to failure to enqueue or failure to upload. More Must not be greater than 500	100

`[federated_search]`

Setting	Description	Default
`[federated_search]` `disabled`	`<boolean>`Set this flag to 'false' to enable the data federation functionality on this instance.	false
`[federated_search]` `transparent_mode`	`<boolean>`A setting of 'true' means federated search transparent mode is enabled on this Splunk platform instance.	true
`[federated_search]` `whole_search_execution_optimization`	`<boolean>`A setting of 'true' means federated searches that involve only a single provider run phases 0 and 1 entirely on the remote search head. More When set to 'true', this setting can improve federated search performance and reduce the network bandwidth used by federated searches. This setting is dynamically set to 'true' for federated searches involving Splunk Cloud Platform federated providers. A setting of 'false' means that federated searches that involve only a single provider might do some search processing on the local search head.	false
`[federated_search]` `sendsDeltaBundle`	`<boolean>`Set this flag to 'false' on a federated search head to disable it from sending delta knowledge object bundles to its remote providers. Full knowledge object bundles will be continued to be sent to the remote providers. More Set this flag to 'false' on a federated remote provider to disable it from sending delta knowledge object bundles to it's indexers. Full knowledge object bundles will be continued to be sent to the remote provider indexers.	true
`[federated_search]` `receivesDeltaBundle`	`<boolean>`Specifies whether federated providers can receive delta knowledge object bundles from federated search heads. More When set to 'false' for a federated provider, the federated provider can't receive delta knowledge bundles from federated search heads. The federated provider continues to receive full knowledge bundles from federated search heads even when this setting is set to 'false'.	true
`[federated_search]` `syncProxyBundleToClusterMembers`	`<boolean>`If you set up a load balancer in front of a search head cluster as a federated provider, this setting specifies whether the provider syncs proxy bundles among the cluster members. More A setting of 'false' means that the federated provider will not sync the proxy bundle with the cluster members and federated searches using this provider will fail to run properly. Change this setting from its default only when instructed to do so by Splunk Support.	true

`[distributed_leases]`

Setting	Description	Default
`[distributed_leases]` `sslVerifyServerCert`	`<boolean>`See the description of 'sslVerifyServerCert' under the [sslConfig] stanza for details on this setting.	false
`[distributed_leases]` `sslVerifyServerName`	`<boolean>`See the description of 'sslVerifyServerName' under the [sslConfig] stanza for details on this setting.	false
`[distributed_leases]` `disabled`	`<boolean>`Determines whether or not the distributed lease manager is enabled.	true
`[distributed_leases]` `provider`	`[AWS\|KVstore]`The type of provider that the Distributed Leases feature for modular inputs uses to achieve consensus among search head cluster members for modular inputs. More The feature can use either the Amazon Web Services (AWS) or app key value store (KVStore) providers. A value of "AWS" means Distributed Leases uses a DynamoDB table to achieve consensus among search head cluster members for modular inputs. A value of "KVstore" means Distributed Leases uses a KV Store collection called DistributedLeases for this purpose. Do not change this setting value without consulting Splunk Support.	AWS

`[search_state]`

Setting	Description	Default
`[search_state]` `alert_store`	`local`Specifies location of alert state store	local
`[search_state]` `suppression_store`	`local`Specifies location of suppression state store	local
`[search_state]` `job_state_store`	`local\|kvstore`The location of the search job state store. More A value of "local" means the Splunk platform uses the standard local job state behavior. A value of "kvstore" means the Splunk platform uses the job state offloading workflow. NOTE: Do not change this setting unless instructed to do so by Splunk Support or product guidance for the rollout.	local

`[manager_pages]`

Setting	Description	Default
`[manager_pages]` `sanitize_uri_param`	`<boolean>`Determines whether the URI parameter received in the manager pages will be sanitized. More A value of 'true' means the URI parameter will be sanitized. A value of 'false' means the URI parameter will not be sanitized. Use this flag to opt out of URI parameter sanitization in case it causes any breaking changes. Note: It is critical to sanitize the URI parameter if possible as it can be abused.	true

`[teleport_supervisor]`

Setting	Description	Default
`[teleport_supervisor]` `disabled`	`<boolean>`Determines whether or not splunkd launches the teleport supervisor process, which handles authorization tokens for System for Cross-Domain Identity Management (SCIM) operations. More A value of "true" means splunkd does not launch the teleport supervisor process. A value of "false" means splunkd launches the teleport supervisor process.	false
`[teleport_supervisor]` `enable_splunk_spotlight`	`<boolean>`Whether or not to start the Splunk spotlight Open Telemetry (OTel) collector to collect metrics from packages. More A value of "true" means the Splunk spotlight OTel collector is turned on and collects metrics from packages. A value of "false" means the Splunk spotlight OTel collector is turned off and packages metrics are not collected.	true
`[teleport_supervisor]` `enable_supervisor_admin_api`	`<boolean>`Whether or not the supervisor enables the admin API endpoints, which provide information about supervised packages. More You must restart Splunk software after you make changes to this setting. A value of "true" means the admin API endpoints are enabled by the supervisor. A value of "false" means the admin API endpoints are disabled by the supervisor.	true
`[teleport_supervisor]` `sslVerifyServerCert`	`<boolean>`Whether or not the Splunk supervisor and the sidecar processes that it manages, as clients, validate the TLS certificate that a server presents when they connect to that server. More See the 'sslVerifyServerCert' setting under the [sslConfig] stanza for more details on this setting. No value for this setting means that the supervisor and its managed sidecars use the value for 'sslVerifyServerCert' in the [sslConfig] stanza.	Not set

`[spotlight]`

Setting	Description	Default
`[spotlight]` `enable_otlp_traces`	`<boolean>`Determines whether or not OpenTelemetry (OTel) trace collection is enabled for the Spotlight sidecar. More A value of "false" means that OTel trace collection is disabled. A value of "true" means that OTel trace collection is enabled.	false
`[spotlight]` `enable_otlp_metrics`	`<boolean>`Whether or not OTel metrics collection is activated for the Spotlight sidecar. More A value of "false" means that Splunk software deactivates OTel metrics collection. A value of "true" means that Splunk software activates OTel metrics collection. You must restart the Splunk software after you make changes to this setting.	false
`[spotlight]` `enable_otlp_metrics_export`	`<boolean>`Whether or not OTel metrics are exported to the Spotlight sidecar. More This setting takes effect only if 'enable_otlp_metrics' has a value of "true". A value of "false" means that Splunk software does not export OTel metrics to the Spotlight sidecar. A value of "true" means that Splunk software exports OTel metrics to the Spotlight sidecar.	true
`[spotlight]` `traces_head_sampling_rate`	`<decimal>`Specifies the head sampling rate for trace data collected by the Spotlight sidecar. Must be between 0.0 and 1.0. More A value of 1.0 means that all traces are sampled. A value of 0.0 means that no traces are sampled.	0.0

`[spotlight:splunkd]`

Settings in this stanza overwrite corresponding settings in the '[spotlight]' stanza.

Setting	Description	Default
`[spotlight:splunkd]` `enable_otlp_traces`	`<boolean>`Changes whether OpenTelemetry (OTel) trace collection is disabled or enabled in splunkd for the Spotlight sidecar by overriding the enable_otlp_traces setting value in the '[spotlight]' stanza. More A value of "false" means that OTel trace collection in splunkd is disabled. A value of "true" means that OTel trace collection in splunkd is enabled.	false
`[spotlight:splunkd]` `enable_otlp_metrics`	`<boolean>`Whether or not OTel metrics collection is activated in splunkd for the Spotlight sidecar. This setting overrides the 'enable_otlp_metrics' setting in the '[spotlight]' stanza. More A value of "false" means that OTel metrics collection in splunkd is deactivated. A value of "true" means that OTel metrics collection in splunkd is activated. You must restart the Splunk software after you make changes to this setting.	false
`[spotlight:splunkd]` `enable_otlp_metrics_export`	`<boolean>`Determines whether or not OTel metrics are exported to the Spotlight sidecar by overriding the 'enable_otlp_metrics' setting value in the '[spotlight]' stanza. More This setting takes effect only if 'enable_otlp_metrics' has a value of "true". A value of "false" means that OTel metrics are not exported to the Spotlight sidecar. A value of "true" means that OTel metrics are exported to the Spotlight sidecar.	true
`[spotlight:splunkd]` `traces_head_sampling_rate`	`<decimal>`Changes the head sampling rate for trace data collected by the Spotlight sidecar in splunkd by overriding the value of traces_head_sampling_rate setting in the '[spotlight]' stanza. Must be between 0.0 and 1.0. More A value of 1.0 means that all traces from splunkd are sampled. A value of 0.0 means that no traces from splunkd are sampled.	0.0

`[localProxy]`

Setting	Description	Default
`[localProxy]` `allocated_max_threads_percentage`	`<integer>`Specifies the percentage of maxThreads that can be allocated to service "local-proxy" and "ws-local-proxy" REST endpoint requests. More The maximum accepted value for this setting is "90". The minimum accepted value for this setting is "1".	20
`[localProxy]` `response_timeout_ms`	`<decimal>`The maximum time, in milliseconds, to wait for the proxy destination to complete a response. More Maximum accepted value for this setting is "3600000" milliseconds (1 hour). Minimum accepted value for this setting is "100" milliseconds. CAUTION: Setting this to a value close to the lower bound might result in timeouts due to insufficient time for the operation to complete, causing error or interruption. CAUTION: Setting this to a value close to the upper bound might delay cleaning up unresponsive sessions.	600000 (10 minutes)

`[localWebSocketProxy]`

Setting	Description	Default
`[localWebSocketProxy]` `disabled`	`<boolean>`Determines whether splunkd is able to proxy WebSocket requests to a local WebSocket server. More A value of "false" means splunkd is able to proxy WebSocket requests to a local WebSocket server. A value of "true" means splunkd is not able to proxy WebSocket requests to a local WebSocket server.	false

`[spl2]`

Setting	Description	Default
`[spl2]` `run_as_owner_enabled`	`<boolean>`Specifies whether or not a user can run searches as if the user was the owner of the searches when permitted. More A value of "true" means run-as-owner searches are allowed. A value of "false" means run-as-owner searches are not allowed.	false

`[version_control]`

Setting	Description	Default
`[version_control]` `disabled`	`<boolean>`Whether or not the Version Control feature is turned on or off. More The Version Control feature lets you track and manage changes made to dashboards in the current version of Splunk Cloud Platform. A value of "true" means that the Version Control feature is turned off. A value of "false" means that the Version Control feature is turned on. The Splunk platform ignores this setting if the 'shclustering' setting has a value of "true". This means that the Version Control feature is disabled on search head clusters. This setting is currently the only configuration setting of the Version Control feature that can be set to a true value and reloaded at runtime.	false
`[version_control]` `repoDir`	`<path>`The full path to the directory where the Version Control metadata is stored. More NOTE: Before you modify this setting, consult the Splunk support team.	$SPLUNK_HOME/var/vcs

`[version_control:compression]`

Setting	Description	Default
`[version_control:compression]` `disabled`	`<boolean>`Whether or not the automated compression job for the Version Control repository is turned on. More The compression job reduces the on-disk footprint of the Version Control metadata by periodically archiving and compressing stale objects. A value of "true" means that compression is turned off. A value of "false" means that compression is turned on.	true
`[version_control:compression]` `interval`	`<interval><unit>`How often the Splunk platform runs the Version Control compression job. More Use the standard Splunk interval syntax for seconds, minutes, hours, days, etc. For example: 60s, 1m, 1h, 1d, etc. Must be greater than 0s (0 seconds).	1d (1 day)

`[postgres]`

Setting	Description	Default
`[postgres]` `disabled`	`<boolean>`Determines whether or not PostgresSQL is disabled.	false
`[postgres]` `enable_clustered_mode`	`<boolean>`REMOVED. This setting has been removed and has no effect.

`[ipc_broker]`

Setting	Description	Default
`[ipc_broker]` `port`	`<integer>`The TCP/IP network port that the IPC broker process uses to serve incoming requests. More Required. If you do not configure this setting, the IPC broker can't provide its service and IPC functionality will not work. The lowest valid value is 1025 and the highest is 65535.	8194
`[ipc_broker]` `<splunkd_helper_process_name>:<service_name>:address`	`<value>`Splunkd helper process settings that define IPC address for a specific service within More the splunkd helper process. The helper process will use this address to receive and handle incoming requests. The name for this setting varies depending on the name of the helper process and the service name for which you want to configure an IPC address. Use the key portion of this key-value pair to specify settings for a specific service within a helper process for splunkd. The name of the helper process goes before the first colon and the service name within that process goes after the first colon. Use the value portion to specify the IPC address that the splunkd helper process uses to serve incoming requests. The IPC address can be either a TCP/IP network port or a Unix Domain Sockets (UDS) socket path. If you specify a TCP/IP network port in the value portion, the lowest valid value is 1024 and the highest is 65535.	No default

`[cluster_state_server]`

Setting	Description	Default
`[cluster_state_server]` `disabled`	`<boolean>`Whether or not the cluster state server is turned off. More A value of "true" means the state server is turned off. A value of "false" means the state server is turned on.	false
`[cluster_state_server]` `http_port`	`<integer>`The TCP/IP network port that the cluster state server helper process uses to serve incoming requests. More This setting is optional. The lowest valid value is 1025 and the highest is 65535.	8600
`[cluster_state_server]` `helper_process_read_timeout_secs`	`<unsigned integer>`The maximum time, in seconds, that splunkd waits for the cluster state server helper process to return results of query execution.	5 (five seconds)
`[cluster_state_server]` `etcd_backup_interval`	`<unsigned integer>`The interval, in minutes, at which the cluster state server periodically backs up etcd (distributed key-value store) data. More Reduce the value if you prioritize minimization of data loss during restore. Increase the value if reducing backup overhead is a higher priority.	5
`[cluster_state_server]` `max_peerdown_time`	`<unsigned integer>`The maximum wait time, in minutes, for a downed search head to rejoin before the cluster state server reconfigures the etcd cluster. More Reduce the value if you want fast reconfiguration when a node is down. Increase the value if nodes might be slow to return and you want to avoid premature reconfiguration.	30
`[cluster_state_server]` `etcd_auto_compaction_retention`	`<string>`The retention period for etcd periodic auto-compaction. More Accepts duration strings such as "1h", "30m", or bare numbers interpreted as hours. For example, "24" means 24 hours. Auto-compaction removes old, unused data versions, called Multi-Version Concurrency Control (MVCC) revisions, from the etcd database, reducing logical space usage. This operation runs only on the etcd leader node, which coordinates write requests, makes decisions, and manages cluster consistency. Because leadership can change at any time, configure this setting consistently on all instances. If the value is set to zero (0) or is invalid, the system uses the default value.	1h
`[cluster_state_server]` `etcd_defrag_interval`	`<string>`The interval at which the cluster state server defragments the local etcd database to reclaim physical disk space. More Accepts duration strings such as "1h", "30m", or bare numbers interpreted as hours. For example: "24" means 24 hours. Defragmentation runs independently on each instance with a random initial delay to prevent simultaneous defragmentation across the cluster. If the value is set to zero (0) or is invalid, the system uses the default value.	24h

`[data_management]`

Setting	Description	Default
`[data_management]` `edge_processor_enabled`	`<boolean>`Specifies whether or not the Edge Processor solution is enabled or disabled. The Edge Processor solution is disabled by default.	false
`[data_management]` `otel_collector_management_enabled`	`<boolean>`Specifies whether or not the management of Open Telemetry Collectors is enabled. More If you modify this setting, you must restart Splunk software.	false
`[data_management]` `spl2_preview_enabled`	`<boolean>`Whether or not the SPL2 (Search Processing Language, version 2) preview sidecar is turned on. More When the SPL2 preview sidecar is turned on, previews for Edge Processor pipelines are generated based on the SPL2 syntax that is supported for pipelines rather than searches, producing more accurate results. A value of "true" means the SPL2 preview sidecar is turned on. A value of "false" means the SPL2 preview sidecar is turned off. If you modify this setting, you must restart Splunk software.	true

`[opamp_binary_edge]`

NOTE: Do not change settings in this stanza unless instructed to do so by Splunk Support.

Setting	Description	Default
`[opamp_binary_edge]` `name`	`<string>`The name of the opamp_binary_edge file to be installed onto a remote host. More This file is the edge processor binary.	not set
`[opamp_binary_edge]` `url`	`<string>`The URL of the opamp_binary_edge file to be installed onto a remote host. More Do not include the host or protocol in the URL. Example: url = servicesNS/-/splunk_pipeline_builders/dmx/packages/edge/1.5.2-74148061-25194506/linux-amd64/edge.tar.gz	not set
`[opamp_binary_edge]` `signature`	`<string>`The base64-encoded PGP signature of the opamp_binary_edge file to be installed onto a remote host. More Encode the signature as a single line, base64-encoded string. The signature will not work if it is not in this format.	not set
`[opamp_binary_edge]` `version`	`<positive integer>.<positive integer>.<positive integer>`The version of the opamp_binary_edge file to be installed onto a remote host. More The version should be in the format <major>.<minor>.<patch>	not set

`[opamp_binary_splunk_edge]`

NOTE: Do not change settings in this stanza unless instructed to do so by Splunk Support.

Setting	Description	Default
`[opamp_binary_splunk_edge]` `name`	`<string>`The name of the opamp_binary_splunk_edge to be installed onto a remote host. More This file is a splunk supervisor which communicates with OpAMP server, downloads and installs the edge processor binary.	not set
`[opamp_binary_splunk_edge]` `url`	`<string>`The URL of the opamp_binary_splunk_edge file to be installed onto a remote host. More Do not include the host or protocol in the URL. Example: url = servicesNS/-/splunk_pipeline_builders/dmx/packages/splunksup/v0.1.301-fb5e0c5e-20250404t180911/linux-amd64/splunksup.tar.gz	not set
`[opamp_binary_splunk_edge]` `signature`	`<string>`The base64-encoded PGP signature of the opamp_binary_splunk_edge file to be installed onto a remote host. More Encode the signature as a single line, base64-encoded string. The signature will not work if it is not in this format.	not set
`[opamp_binary_splunk_edge]` `version`	`<positive integer>.<positive integer>.<positive integer>`The version of the opamp_binary_splunk_edge file to be installed onto a remote host. More The version should be in the format <major>.<minor>.<patch>	not set

`[data_orchestrator]`

NOTE: Do not change settings in this stanza unless instructed to do so by Splunk Support.

Setting	Description	Default
`[data_orchestrator]` `disabled`	`<boolean>`Whether or not the data orchestrator component is turned on. More This component is what lets SPL2 function. A value of "false" means that the data orchestrator component is turned on. A value of "true" means that the data orchestrator component is turned off. You must restart the Splunk platform instance for this change to take effect.	false

`[heap_profiler]`

Setting	Description	Default
`[heap_profiler]` `disabled`	`<boolean>`Whether or not the splunkd server periodically writes files with diagnostic information about its heap memory usage. These files are also called heap dumps. More This functionality is available only on Linux platform. If set to "false", Splunk platform generates files with the filename prefix specified by the "output_prefix" parameter. If set to "true", Splunk platform does not generate these files. To turn on automatic heap profiling, add the following line to the splunk-launch.conf file: MALLOC_CONF="prof:true,prof_active:false,prof_accum:true" If you turn on automatic heap profiling, Splunk platform automatically selects the correct version of jemalloc.	true
`[heap_profiler]` `period`	`<interval>`Interval at which the splunkd server writes files with the heap diagnostic information. More Use <integer><unit> to specify a duration. If <integer> is not specified, it defaults to 1. If <unit> is not specified, it defaults to seconds. Specify one of the following units: s, sec, second, secs, seconds, m, min, minute, mins, minutes, h, hr, hour, hrs, hours, d, day, days. For example: 60s = 60 seconds, 5m = 5 minutes. A value of 0 means Splunk platform does not generate any files.	1m
`[heap_profiler]` `output_prefix`	`<string>`Output prefix for the files with heap diagnostic information. More Splunk platform names the generated files according to the following pattern: <output_prefix>.<pid>.<counter>.m<counter>.heap For example: /tmp/heap_data.1234.1m1.heap If the directory to store these files is missing, Splunk platform creates it if possible.	/tmp/heap_data
`[heap_profiler]` `min_free_space`	`<unsigned integer>[MB\|GB\|TB]`Determines the minimum free space for the heap dump generation. More If the filesystem free space is lower than the specified threshold, Splunk platform cannot generate any new heap dumps. You must specify both an integer and a unit.	256MB

File locations

Configuration file: server.conf.

Scope	Path
System	`$SPLUNK_HOME/etc/system/{default,local}/server.conf`
App	`$SPLUNK_HOME/etc/apps/<app_name>/{default,local}/server.conf`

App-level overrides are supported by the layering model but rarely used in practice -- nearly all real deployments set these at system/local, the same pattern already noted for web.conf on this page.

Example

[general]
serverName = idx01-use1
pass4SymmKey = $7$encrypted_value_here

[sslConfig]
enableSplunkdSSL = true

A named instance with a shared inter-Splunk secret and management-port TLS enabled.

Validation

Set the same pass4SymmKey passphrase in the matching stanza on every node that must authenticate to this one (clustering, distributed search) -- a mismatch breaks the relationship rather than degrading gracefully.
Keep serverName within its allowed character set after variable expansion (letters, numbers, underscores, dots, dashes) -- confirm any environment variable it references actually expands to a valid value.
Remember enableSplunkdSSL affects the KV Store port (8191) as well as the management port (8089) -- check both before disabling it.

← Back to References

References / Splunk platform configuration

Search Limits Configuration

limits.conf applies resource and behavior caps to search commands and other bounded Splunk operations, organized as one stanza per feature area (search, indexing, REST API, KV Store and more).

Definition

Each stanza scopes a Splunk subsystem's operating limits -- [search] and [searchresults] for search generally, per-command stanzas such as [stats|sistats], [top] and [join], plus indexing, the REST API, KV Store and other bounded operations (all listed under Settings below). Settings here are guardrails; Splunk generally recommends not changing them without a specific, informed reason.

Settings

Every stanza and setting in limits.conf.spec from Splunk Enterprise 10.4.2: 645 settings across 110 stanzas. Descriptions use the spec's own wording -- the first line shows here and More opens the rest. The Default column is filled only where the spec gives a Default: line.

`[default]`

Setting	Description	Default
`[default]` `DelayArchiveProcessorShutdown`	`<boolean>`Specifies whether during splunk shutdown archive processor should finish processing archive file under process. More When set to "false": The archive processor abandons further processing of the archive file and will process again from start again. When set to "true": The archive processor will complete processing of the archive file. Shutdown will be delayed.	false
`[default]` `maxArchiveNestLevel`	`<non-negative integer>`Specifies the maximum number of nested levels for an archive file for processing. More If an archive file exceeds the maximum specified nested level, Splunk software ignores the archive file. Maximum value: 10	4
`[default]` `max_mem_usage_mb`	`<non-negative integer>`The maximum amount of RAM, in megabytes (MB), that a batch of events or results can use in the memory of a search process. More Operates on an estimation of memory use which is not exact. The estimation can deviate by an order of magnitude or so to both the smaller and larger sides. The search processor applies the limitation in an unusual way. If the number of results or events exceeds 'maxresultrows', AND the estimated memory exceeds this limit, the data is spilled to disk. This means, as a general rule, lower limits will cause a search to use more disk I/O and less RAM, and be somewhat slower, but should cause the same results to typically come out of the search in the end. This limit is applied currently to a number, but not all search processors. However, more will likely be added as it proves necessary. The number is thus effectively a ceiling on batch size for many components of search for all searches run on this system. Some search processors might truncate results if they can't process the results within the 'max_mem_usage_mb' limit. The search head displays a warning if this occurs. A value of "0" means that there is no limit to the amount of memory that a search process can use for events or results. Searches might be allowed to grow to arbitrary sizes. NOTE: The mvexpand command uses the ‘max_mem_usage_mb’ value in a different way. The mvexpand command has no combined logic with ‘maxresultrows’. If the memory limit is exceeded, output is truncated, not spilled to disk. The 'stats' and 'sdselect' command processors use the ‘max_mem_usage_mb’ value in the following way. If the estimated memory usage exceeds the specified limit, the results are cached to the disk. This means that when a large volume of data exceeds the 'max_mem_usage_mb' setting, the search processor doesn't store all the data in memory. Instead, the search processor puts some data into temporary data files on disk, so that it can do further processing on that data later as needed. If 0 is specified, the results are cached to the disk when the number of results exceeds the ‘maxresultrows’ setting. The eventstats command processor uses the ‘max_mem_usage_mb’ value in the following way. Both the ‘max_mem_usage_mb’ and the ‘maxresultrows’ settings are used to determine the maximum number of results to return. If the limit for one setting is reached, the eventstats processor continues to return results until the limit for the other setting is reached. When both limits are reached, the eventstats command processor stops adding the requested fields to the search results. If you set ‘max_mem_usage_mb’ to 0, the eventstats command processor uses only the ‘maxresultrows’ setting as the threshold. When the number of results exceeds the ‘maxresultrows’ setting, the eventstats command processor stops adding the requested fields to the search results.	200
`[default]` `max_search_string_size`	`<unsigned integer>[B\|KB\|MB\|GB]`Specifies the maximum allowed length of the search string, in bytes, kilobytes, megabytes, or gigabytes. More Every time a search runs, it undergoes multiple rounds of parsing, expansion, and optimization before producing the final optimized string. This limit is applied in every round and can cause the search to fail even if the initial search string is below the limit. If a search has subsearches, part of the search string is replaced with the results of its subsearches. The size of these results is factored into the total length of the search string. This setting prevents the search string from expanding indefinitely and provides guardrails to limit memory usage during the parsing phase of searches. If a search exceeds this limit, it stops running and does not complete successfully. This setting does not limit the total memory used by the search process; it only controls the size of the search string. A value of 0 means no limit is enforced on the search string size.	0B
`[default]` `min_batch_size_bytes`	`<integer>`Specifies the size, in bytes, of the file/tar after which the file is handled by the batch reader instead of the trailing processor. More Global setting, cannot be configured per input. NOTE: Configuring this to a very small value could lead to backing up of jobs at the tailing processor.	20971520
`[default]` `regex_cpu_profiling`	`<boolean>`Enable CPU time metrics for RegexProcessor. Output will be in the metrics.log file. Entries in metrics.log will appear per_host_regex_cpu, per_source_regex_cpu, per_sourcetype_regex_cpu, per_index_regex_cpu.	true
`[default]` `agg_cpu_profiling`	`<boolean>`Enable CPU time metrics for AggregatorProcessor. Output will be in the metrics.log file. Entries in metrics.log will appear per_host_agg_cpu, per_source_agg_cpu, per_sourcetype_agg_cpu, per_index_agg_cpu.	true
`[default]` `msp_cpu_profiling`	`<boolean>`Enable CPU time metrics for MetricSchemaProcessor. Output will be in the metrics.log file. Entries in metrics.log will appear per_host_msp_cpu, per_source_msp_cpu, per_sourcetype_msp_cpu, per_index_msp_cpu.	true
`[default]` `mp_cpu_profiling`	`<boolean>`Enable CPU time metrics for MetricsProcessor. Output will be in the metrics.log file. Entries in metrics.log will appear per_host_mp_cpu, per_source_mp_cpu, per_sourcetype_mp_cpu, per_index_mp_cpu.	true
`[default]` `lb_cpu_profiling`	`<boolean>`Enable CPU time metrics for LineBreakingProcessor. Output will be in the metrics.log file. Entries in metrics.log will appear per_host_lb_cpu, per_source_lb_cpu, per_sourcetype_lb_cpu, per_index_lb_cpu.	true
`[default]` `clb_cpu_profiling`	`<boolean>`Enable CPU time metrics for ChunkedLBProcessor. Output will be in the metrics.log file. Entries in metrics.log will appear per_host_clb_cpu, per_source_clb_cpu, per_sourcetype_clb_cpu, per_index_clb_cpu.	false
`[default]` `xml_cpu_profiling`	`<boolean>`Whether or not the Splunk platform turns on Central Processing Unit (CPU) time metrics for the XmlExtractionProcessor. More A value of "true" means the Splunk platform turns on these metrics and writes the output to the 'metrics.log' file. The log file entries appear as 'per_host_xml_cpu', 'per_source_xml_cpu', 'per_sourcetype_agg_cpu', and 'per_index_xml_cpu'. A value of "false" means the Splunk platform does not enable these metrics.	true
`[default]` `file_and_directory_eliminator_reaper_interval`	`<integer>`Specifies how often, in seconds, to run the FileAndDirectoryEliminator reaping process. More The FileAndDirectoryEliminator eliminates files and directories by moving them to a location that is reaped periodically. This reduces the chance of encountering issues due to files being in use. On Windows, the FileAndDirectoryEliminator is used by the deployment client to delete apps that have been removed or that are being redeployed. A value of 0 disables the FileAndDirectoryEliminator. NOTE: Do not change this setting unless instructed to do so by Splunk Support.	60 (on Windows); 0 (otherwise)
`[default]` `interval`	`<integer>`Number of seconds between logging splunkd metrics to metrics.log for different subgroups. More Check metrics.log for the list of configurable "metrics_modules". Set "interval" under the desired "metrics_module" stanza. Example: If you want 60 seconds metrics logging interval for "thruput:thruput", [thruput:thruput] interval = 60 Minimum value is 10 seconds. Valid value is multiple of 10. If value is not exact multiple of 10, it will be adjusted to nearest downward multiple. Recommended value multiple of 30. Splunk will decide how often to check for metrics reporting based on greatest common divisor across different values. If "interval" is set 30, 40 for two different components, then greatest common divisor for 30, 40 and 60(default) is 10. It's expensive for metrics reporting thread to log every 10 sec. If "interval" is set 30, 900 for two different components, then greatest common divisor for 30, 90 and 60(default) is 30. It's less expensive for metrics reporting thread to log every 30 sec.	"interval" config value set under [metrics] stanza.

`[email]`

This stanza controls email settings that are enforced in the sendemail alert action.

Setting	Description	Default
`[email]` `result_limit`	`<unsigned integer>`Limits the number of inline search results that Splunk software can send in a 'sendemail' alert email. More Raising this setting to a higher value might result in increased splunkd memory usage. This setting takes precdence over the 'maxinputs' setting in commands.conf. NOTE: Change this setting only under the direction of Splunk Support.	10000

`[searchresults]`

This stanza controls search results for a variety of Splunk search commands.

Setting	Description	Default
`[searchresults]` `compression_level`	`<integer>`Compression level to use when writing search results to .csv.gz files.	1
`[searchresults]` `maxresultrows`	`<integer>`Configures the maximum number of events generated by search commands which grow the size of your result set (such as multikv) or that create events. Other search commands are explicitly controlled in specific stanzas that follow. More NOTE: Do not change this setting unless instructed to do so by Splunk Support.	50000
`[searchresults]` `tocsv_maxretry`	`<integer>`Maximum number of times to retry the atomic write operation. More When set to "1": Specifies that there will be no retries.	5
`[searchresults]` `tocsv_retryperiod_ms`	`<integer>`Period of time to wait before each retry. More These setting control logging of error messages to the info.csv file. All messages will be logged to the search.log file regardless of these settings.	500

`[search_info]`

This stanza controls logging of messages to the info.csv file.
Messages logged to the info.csv file are available to REST API clients and Splunk Web. Limiting the messages added to info.csv will mean that these messages will not be available in the UI and/or the REST API.

Setting	Description	Default
`[search_info]` `filteredindexes_log_level`	`[DEBUG\|INFO\|WARN\|ERROR]`Log level of messages when search returns no results because user has no permissions to search on queried indexes.	DEBUG
`[search_info]` `infocsv_log_level`	`[DEBUG\|INFO\|WARN\|ERROR]`Limits the messages which are added to the info.csv file to the stated level and above. More For example, if "infocsv_log_level" is WARN, messages of type WARN and higher will be added to the info.csv file.	INFO
`[search_info]` `max_infocsv_messages`	`<positive integer>`Limits the number of messages which are added to the info.csv file, per log level. More If more than max_infocsv_messages log entries are generated, additional entries will not be logged in the info.csv file. All entries will still be logged in the search.log file.	20
`[search_info]` `show_warn_on_filtered_indexes`	`<boolean>`Log warnings if search returns no results because user has no permissions to search on queried indexes.	false

`[subsearch]`

This stanza controls subsearch results.
Read more about subsearches in the online documentation: http://docs.splunk.com/Documentation/Splunk/latest/Search/Aboutsubsearches

Setting	Description	Default
`[subsearch]` `capture_subsearch_telemetry`	`<boolean>`Controls whether to capture subsearch telemetry. More When set to "true", subsearch telemetry is sent into a separate dispatch folder. NOTE: Do not change this setting unless instructed to do so by Splunk Support.	false
`[subsearch]` `enable_early_evaluated_subsearch`	`<boolean>`When set to "true" relevant subsearches get executed earlier in order to run through search optimization. Do not set the value to "1" to indicate "true", because some systems might not parse this value correctly.	false
`[subsearch]` `maxout`	`<integer>`Maximum number of results to return from a subsearch. More If the value of 'maxout' is greater than the 'maxresultrows' setting in the [searchresults] stanza, the subsearch ignores the 'maxout' setting and uses 'maxresultrows' instead.	100
`[subsearch]` `maxtime`	`<integer>`Maximum number of seconds to run a subsearch before finalizing	60
`[subsearch]` `ttl`	`<integer>`The time to live (ttl), in seconds, of the cache for the results of a given subsearch. More Do not set this below 120 seconds. See the definition in the [search] stanza under the "TTL" section for more details on how the ttl is computed.	300 (5 minutes)
`[subsearch]` `subsearch_artifacts_delete_policy`	`[immediate\|ttl]`How subsearch artifacts are deleted after a sub search completes. More Set to `immediate` to have subsearch artifacts remove immediately after a subsearch completes. Set to 'ttl' to have subsearch artifacts delete after the time-to-live of the subsearch has been reached. For example, you could use '\|noop subsearch_artifacts_delete_policy = [immediate\|ttl]' to overwrite the setting for a particular search.	ttl

`[search]`

NOTE: The following batch search settings control the periodicity of retries to search peers in the event of failure (Connection errors, and others). The interval exists between failure and first retry, as well as successive retries in the event of further failures.

Setting	Description	Default
`[search]` `allow_batch_mode`	`<boolean>`Specifies whether or not to allow the use of batch mode which searches in disk based batches in a time insensitive manner. More In distributed search environments, this setting is used on the search head.	true
`[search]` `batch_search_max_index_values`	`<integer>`When using batch mode, this limits the number of event entries read from the index file. These entries are small, approximately 72 bytes. However batch mode is more efficient when it can read more entries at one time. More Setting this value to a smaller number can lead to slower search performance. A balance needs to be struck between more efficient searching in batch mode and running out of memory on the system with concurrently running searches.	10000000
`[search]` `batch_search_max_pipeline`	`<integer>`This setting controls the number of search pipelines that are launched on the indexer during batch search. More Increasing the number of search pipelines can improve search performance. However, this can also result in increased thread and memory usage. This setting applies only to searches that run on remote indexers. The value for this setting should be >=1. When this setting is >1 on the search head, the setting is applied to all remote indexers. Otherwise, remote indexers use their local 'batch_search_max_pipeline' setting. You can override this setting on a per-search basis by appending '\|noop batch_search_max_pipeline=<integer>' to the search string. The <integer> should be >1.	1
`[search]` `batch_search_max_results_aggregator_queue_size`	`<integer>`Controls the size, in bytes, of the search results queue to which all the search pipelines dump the processed search results. More Increasing the size can lead to search performance gains. Decreasing the size can reduce search performance. Do not specify zero for this setting.	100000000
`[search]` `batch_search_max_serialized_results_queue_size`	`<integer>`Controls the size, in bytes, of the serialized results queue from which the serialized search results are transmitted. More Increasing the size can lead to search performance gains. Decreasing the size can reduce search performance. Do not specify zero for this setting.	100000000
`[search]` `batch_retry_min_interval`	`<integer>`When batch mode attempts to retry the search on a peer that failed, specifies the minimum time, in seconds, to wait to retry the search.	5
`[search]` `batch_retry_max_interval`	`<integer>`When batch mode attempts to retry the search on a peer that failed, specifies the maximum time, in seconds, to wait to retry the search.	300 (5 minutes)
`[search]` `batch_retry_scaling`	`<double>`After a batch retry attempt fails, uses this scaling factor to increase the time to wait before trying the search again. More The value should be > 1.0.	1.5
`[search]` `load_remote_bundles`	`<boolean>`On a search peer, allow remote (search head) bundles to be loaded in splunkd.	false.
`[search]` `replication_file_ttl`	`<integer>`The time to live (ttl), in seconds, of bundle replication tarballs, for example: *.bundle files.	600 (10 minutes)
`[search]` `replication_period_sec`	`<integer>`The minimum amount of time, in seconds, between two successive bundle replications.	60
`[search]` `sync_bundle_replication`	`[0\|1\|auto]`Indicates whether configuration file replication blocks searches or is run asynchronously. More When set to "auto": The Splunk software uses asynchronous replication only if all of the peers support asynchronous bundle replication. Otherwise synchronous replication is used.	auto
`[search]` `bundle_status_expiry_time`	`<interval>`The amount of time the search head waits before purging the status of a knowledge bundle push request to the indexer. More The status is purged either when it is not queried for a period greater than this setting or when its associated bundle is deleted by the reaper. The interval can be specified as a string for minutes, seconds, hours, days. For example; 60s, 1m, 1h, 1d etc.	1h
`[search]` `total_search_concurrency_limit`	`auto \| <integer>`Specifies the maximum search concurrency limit for a search head cluster or standalone search head. More When set to "auto", the search head cluster or standalone search head calculates the historical search concurrency limit using max_hist_searches = max_searches_per_cpu x number_of_cpus + base_max_searches. The real-time search concurrency limit is calculated based on the historical search concurrency limit. When set to an integer, the setting specifies the maximum search concurrency limit. For a search head cluster, the number specifies the maximum search limit across the cluster. For a standalone search head, the number specifies the maximum search limit for the search head. The value must be in the range of 1 to 8192.	auto
`[search]` `base_max_searches`	`<integer>`A constant to add to the maximum number of searches, computed as a multiplier of the CPUs.	6
`[search]` `max_rt_search_multiplier`	`<decimal number>`A number by which the maximum number of historical searches is multiplied to determine the maximum number of concurrent real-time searches. More NOTE: The maximum number of real-time searches is computed as: max_rt_searches = max_rt_search_multiplier x max_hist_searches	1
`[search]` `max_searches_per_cpu`	`<integer>`The maximum number of concurrent historical searches for each CPU. The system-wide limit of historical searches is computed as: max_hist_searches = max_searches_per_cpu x number_of_cpus + base_max_searches More NOTE: The maximum number of real-time searches is computed as: max_rt_searches = max_rt_search_multiplier x max_hist_searches	1
`[search]` `shc_adhoc_quota_enforcement`	`on \| off \| overflow`Determines the way in which the cluster enforces limits on the number of concurrent searches. Since concurrent searches include both scheduled and ad hoc searches, this setting effectively determines the enforcement method for admitting new ad hoc searches. More "on" means the ad hoc search admission process is managed cluster-wide by the captain. "off" means the ad hoc search admission process is managed locally, by each search head that receives an ad hoc search request. "overflow" means the local search head checks its local capacity first when admitting an ad hoc search. If the search head has capacity (that is, if the search head is below the local limit on number of concurrent searches), it runs the search locally. If the search head has reached its limit on concurrent searches, it defers to the captain for permission to run the search. The captain will check which search head has the capacity, and tell the local search head to proxy the search to the remote search head to run it. NOTE: Setting it to "on" or "overflow" lets a user run more ad hoc searches than individual cluster member concurrency limits allow. While this can help a user/role with heavier ad hoc search requirements, it can lead to under-counting of the cluster-wide ad hoc search numbers and cause the ad hoc search count to exceed cluster-wide quota limits. Do not change this setting without consulting Splunk Support. NOTE: When `shc_role_quota_base_only_enforcement` is enabled, the behavior of this setting changes such that role-based quotas are not multiplied by the size of the cluster.	off
`[search]` `hostwide_queued_search_limit`	`<integer>`Specifies the maximum number of queued searches for a search head. More When the hostwide_queued_search_limit is reached, searches that would normally be queued will be rejected, until the number of queued searches does not exceed the limit. A value of 0 means there is no limit to the number of queued searches on the search head. NOTE: Setting this value too high can cause performance issues, as Splunk software might spend more time servicing queued jobs.	0
`[search]` `addpeer_skew_limit`	`<positive integer>`Absolute value of the largest time skew, in seconds, that is allowed when configuring a search peer from a search head, independent of time. More If the difference in time (skew) between the search head and the peer is greater than "addpeer_skew_limit", the search peer is not added. This is only relevant to manually added peers. This setting has no effect on index cluster search peers.	600 (10 minutes)
`[search]` `fetch_remote_search_log`	`[enabled\|disabledSavedSearches\|disabled]`When set to "enabled": All remote search logs are downloaded barring the oneshot search. More When set to "disabledSavedSearches": Downloads all remote logs other than saved search logs and oneshot search logs. When set to "disabled": Irrespective of the search type, all remote search log download functionality is disabled. NOTE: The previous Boolean values:[true\|false] are still supported, but are not recommended. The previous value of "true" maps to the current value of "enabled". The previous value of "false" maps to the current value of "disabled". You can override this setting on a per-search basis by appending '\|noop remote_log_fetch=[*\|<indexer1;indexer2...>]' to the search string, where <indexer1;indexer2...> is a list of indexers that contain the remote search logs that you want to collect.	disabled
`[search]` `max_chunk_queue_size`	`<integer>`The maximum size of the chunk queue.	10000000
`[search]` `max_combiner_memevents`	`<integer>`Maximum size of the in-memory buffer for the search results combiner. The <integer> is the number of events.	50000
`[search]` `max_tolerable_skew`	`<positive integer>`Absolute value of the largest time skew, in seconds, that is tolerated between the native clock on the search head and the native clock on the peer (independent of time zone). More If this time skew is exceeded, a warning is logged. This estimate is approximate and tries to account for network delays.	60
`[search]` `max_workers_searchparser`	`<integer>`The number of worker threads in processing search result when using round robin policy.	5
`[search]` `results_queue_min_size`	`<integer>`The minimum size, of search result chunks, that will be kept from peers for processing on the search head before throttling the rate that data is accepted. More The minimum queue size in chunks is the "results_queue_min_size" value and the number of peers providing results, which ever is greater.	10
`[search]` `result_queue_max_size`	`<unsigned integer>[KB\|MB\|GB]`The maximum amount of metadata and search results that the search head processes from peers before the search head throttles the rate for accepting additional data in the queue from peers. More The value of 'results_queue_min_size' takes precedence over this setting. This means that the number of search result chunks specified by 'results_queue_min_size' are retained in the results queue even if the total size of the chunks in MB exceeds the value of 'result_queue_max_size'. Specify this value as an integer followed by KB, MB, or GB (for example, for 10 megabytes, use 10MB). If a unit is not specified, the setting uses "bytes" by default.	100MB
`[search]` `high_accuracy_results_queue_size`	`<boolean>`If set to "true", this setting uses metadata and search results to calculate with a high level of accuracy the memory consumption of data transmitted between Splunk hosts in order to fine tune parsing of the results queue. More This setting helps prevent out-of-memory issues and protect the search head when searches transmit high volumes of metadata. Works in conjunction with 'result_queue_max_size'. If set to "true", the 'result_queue_max_size' value must be at least 200MB. NOTE: Do not change this setting unless instructed to do so by Splunk Support.	false
`[search]` `results_queue_read_timeout_sec`	`<integer>`The amount of time, in seconds, to wait when the search executing on the search head has not received new results from any of the peers. More Cannot be less than the 'receiveTimeout' setting in the distsearch.conf file.	900
`[search]` `batch_wait_after_end`	`<integer>`DEPRECATED: Use the 'results_queue_read_timeout_sec' setting instead.
`[search]` `remote_search_requests_throttling_type`	`disabled \| per_cpu \| physical_ram`Sets the way remote searches are throttled on remote peers. Search request that is throttled is rejected with 429 HTTP code. More "disabled" simply disables any throttling. "per_cpu" sets the throttling based on available CPU number. "physical_ram" sets the throttling based on available system memory. Multiple, comma-separated, throttling types can be set. For example: 'remote_search_requests_throttling_type = per_cpu, physical_ram' enables both "per_cpu" and "physical_ram". Does not apply to real-time searches.	disabled
`[search]` `throttle_peer_busy_wait`	`<integer>[s\|m]`Controls how long the search head waits before it launches new searches after receiving a peer busy response from a search peer notifying the search head that it has submitted too many search requests. More This setting has no effect if the 'remote_search_requests_throttling_type' setting is disabled on all search peers because the search peers can't send peer busy (429) responses. Specify the interval as a string with minutes or seconds. For example: 60s, 1m, etc.	1m
`[search]` `remote_search_requests_send_capabilities_list`	`<boolean>`When turned on, the search head sends the list of all capabilities of the user running the search to every search peer participating in the search. More This makes it possible to uniformly enforce user-level role-based access control (RBAC).	false
`[search]` `remote_search_requests_reject_if_capabilities_list_absent`	`<boolean>`When turned on for a search peer, the search peer rejects search requests that do not also specify the full capability list for the user running the search. More The search head sends the full capability list for users running the search when 'send_capabilities_list_to_indexer' is set to true. Turn this on only if all search heads have already set 'send_capabilities_list_to_indexers' to true.	false
`[search]` `fieldstats_update_freq`	`<number>`How often to update the field summary statistics, as a ratio to the elapsed run time so far. More Smaller values means update more frequently. When set to "0": Specifies to update as frequently as possible.	0
`[search]` `fieldstats_update_maxperiod`	`<number>`The maximum period, in seconds, for updating field summary statistics. More When set to "0": Specifies that there is not maximum period. The period is dictated by the calculation: current_run_time x fieldstats_update_freq Fractional seconds are allowed.	60
`[search]` `min_freq`	`<number>`Minimum frequency of a field that is required for the field to be included in the /summary endpoint. More The frequency must be a fraction >=0 and <=1.	0.01 (1%)
`[search]` `enable_history`	`<boolean>`Specifies whether to keep a history of the searches that are run.	true
`[search]` `max_history_length`	`<integer>`Maximum number of searches to store in history for each user and application. More When 'search_history_storage_mode' has a value of "kvstore", this value is applicable per user only, and not per user and application combination.	500
`[search]` `max_history_storage_retention_time`	`<integer>[s\|m\|h\|d]`The maximum time to store search history records for each user and application. More This setting and the 'max_history_length' setting determine how many search history records appear in persistent storage. Search stops storing search history records when either the retention time or the number of search history records exceeds the values you configure with these settings. A value of 0 means that search only uses 'max_history_length' to retain search history to persistent storage. The time units you can specify for this setting are: s, sec, second, secs, seconds, m, min, minute, mins, minutes, h, hr, hour, hrs, hours, d, day, days. This setting is only applicable when 'search_history_storage_mode' has a value of "kvstore".	90d
`[search]` `search_history_storage_mode`	`<string>`The storage mode by which a search head cluster saves search history. More Valid storage modes include "csv" and "kvstore". This setting is valid only when the 'enable_history' setting has a value of "true". A value of "kvstore" means that the cluster can replicate search history across all its members using the App Key Value Store service. A value of "csv" means that search history is saved to CSV files only on the local search head. When you initially give this setting a value of "kvstore", the search head migrates the existing search history records, if they are present in existing CSV files, into the App Key Value Store service. This migration of search history can only happen once. If you later change the storage mode to "csv", then back to "kvstore", subsequent migrations do not occur. NOTE: In the "kvstore" storage mode, the 'max_history_length' is the maximum number of searches that the SHC can store for each user. In this case, the maximum acceptable value of 'max_history_length' cannot exceed 1000.	csv
`[search]` `enable_memory_tracker`	`<boolean>`Specifies if the memory tracker is enabled. More When set to "false" (disabled): The search is not terminated even if the search exceeds the memory limit. When set to "true": Enables the memory tracker. Must be set to "true" to enable the "search_process_memory_usage_threshold" setting or the "search_process_memory_usage_percentage_threshold" setting.	false
`[search]` `search_process_memory_usage_threshold`	`<double>`To use this setting, the "enable_memory_tracker" setting must be set to "true". More Specifies the maximum memory, in MB, that the search process can consume in RAM. Search processes that violate the threshold are terminated. If the value is set to 0, then search processes are allowed to grow unbounded in terms of in memory usage.	4000 (4GB)
`[search]` `search_process_memory_usage_percentage_threshold`	`<decimal>`To use this setting, the 'enable_memory_tracker' setting must be set to "true". More Specifies the percent of the total memory that the search process is entitled to consume. Search processes that violate the threshold percentage are terminated. If the value is set to zero, then splunk search processes are allowed to grow unbounded in terms of percentage memory usage. Any setting larger than 100 or less than 0 is discarded and the default value is used.	25%
`[search]` `allow_inexact_metasearch`	`<boolean>`Specifies if a metasearch that is inexact be allowed. More When set to "true": An INFO message is added to the inexact metasearches. When set to "false": A fatal exception occurs at search parsing time.	false
`[search]` `indexed_as_exact_metasearch`	`<boolean>`Specifies if a metasearch can process <field>=<value> the same as <field>::<value>, if <field> is an indexed field. More When set to "true": Allows a larger set of metasearches when the 'allow_inexact_metasearch' setting is "false". However, some of the metasearches might be inconsistent with the results of doing a normal search.	false
`[search]` `async_quota_update`	`<boolean>`When set to 'true', this setting enables a thread that periodically checks the disk quota cache for searches. More Because it moves disk quota checking to an async function, this setting improves search performance. However, this thread can cause the number of in-process searches to slightly exceed concurrent search quotas. Set this setting to 'false' if you require strict maintenance of user disk quotas.	false
`[search]` `async_quota_update_freq`	`<number>`The frequency, in seconds, at which the disk quota cache for searches is updated. More Applies only when 'async_quota_update=true'.	30
`[search]` `use_removable_search_cache`	`<boolean>`Determines if the /saved/searches handler will use a cache that lets it emit <removable> tags on a list call. More This slightly changes the appearance of the delete option on saved search knowledge objects in Splunk Web, but results in a performance boost.
`[search]` `disk_usage_update_period`	`<number>`Specifies how frequently, in seconds, should the search process estimate the artifact disk usage. More The quota for the amount of disk space that a search job can use is controlled by the 'srchDiskQuota' setting in the authorize.conf file. Exceeding this quota causes the search to be auto-finalized immediately, even if there are results that have not yet been returned. Fractional seconds are allowed.	10
`[search]` `dispatch_dir_warning_size`	`<integer>`Specifies the number of jobs in the dispatch directory that triggers when to issue a bulletin message. The message warns that performance might be impacted.	5000
`[search]` `do_not_use_summaries`	`<boolean>`Do not use this setting without working in tandem with Splunk support. More This setting is a very narrow subset of 'summary_mode=none'. When set to "true": Disables some functionality that is necessary for report acceleration. In particular, when set to "true", search processes will no longer query the main splunkd's /admin/summarization endpoint for report acceleration summary IDs. In certain narrow use-cases this might improve performance if report acceleration (savedsearches.conf:auto_summarize) is not in use, by lowering the main splunkd's process overhead.	false
`[search]` `enable_createrss_command`	`<boolean>`Enables the deprecated 'createrss' search command. Enabling 'createrss' does not affect the behavior of the 'rss' alert action. More This deprecated command is now disabled by default.	false
`[search]` `enable_datamodel_meval`	`<boolean>`Enable concatenation of successively occurring evals into a single comma-separated eval during the generation of datamodel searches.	true
`[search]` `enable_file_command`	`<boolean>`DEPRECATED. This setting has been deprecated and has no effect.
`[search]` `enable_conditional_expansion`	`<boolean>`Determines whether or not scoped conditional expansion of knowledge More objects occurs during search string expansion. This only applies on the search head. NOTE: Do not change unless instructed to do so by Splunk Support.	true
`[search]` `force_saved_search_dispatch_as_user`	`<boolean>`Specifies whether to overwrite the "dispatchAs" value. More When set to "true": The "dispatchAs" value is overwritten by "user" regardless of the [user\|owner] value in the savedsearches.conf file. When set to "false": The value in the savedsearches.conf file is used. You might want to set this to "true" to effectively disable "dispatchAs = owner" for the entire install, if that more closely aligns with security goals.	false
`[search]` `get_summary_id_connection_timeout`	`<integer>`The connection timeout, in seconds, for a search to check for available summaries using the admin/summarization REST endpoint. More This setting does not apply if 'do_not_use_summaries' is "true", or if 'summary_mode' is set to "none".	5
`[search]` `get_summary_id_rcv_timeout`	`<integer>`The timeout, in seconds, for a search to receive data from the admin/summarization REST endpoint when checking for available summaries. More This setting does not apply if 'do_not_use_summaries' is "true", or if 'summary_mode' is set to "none".	5
`[search]` `get_summary_id_send_timeout`	`<integer>`The timeout, in seconds, for a search to send a query to the admin/summarization REST endpoint when checking for available summaries. More This setting does not apply if 'do_not_use_summaries' is "true", or if 'summary_mode' is set to "none".	5
`[search]` `max_id_length`	`<integer>`Maximum length of the custom search job ID when spawned by using REST API argument "id".	150
`[search]` `max_id_length_before_hash`	`<integer>`Specifies the maximum length of a generated or custom search job ID before the Splunk software shortens the directory name. The search job ID itself remains the same. More If set to 0, the Splunk software never hashes the ID. In this case, IDs that are too long cause the search to fail. NOTE: Do not change this setting unless instructed to do so by Splunk Support.	230
`[search]` `search_keepalive_frequency`	`<integer>`Specifies how often, in milliseconds, a keepalive is sent while a search is running.	30000 (30 seconds)
`[search]` `search_keepalive_max`	`<integer>`The maximum number of uninterupted keepalives before the connection is closed. More This counter is reset if the search returns results.	100
`[search]` `search_retry`	`<Boolean>`Specifies whether the Splunk software reruns all or elements of a currently running search process when the search process is affected by indexer failures in an indexer clustering environment. More Indexers can fail during rolling restart or indexer upgrade when indexer clustering is enabled. Indexer reboots can also result in failures. When set to 'true', the Splunk software attempts to rerun search processes that are affected by indexer failures. The Splunk software can rerun entire searches and it can rerun searches from the indexer fail point. Do not set the value to "1" to indicate "true", because some systems might not parse this value correctly. NOTE: Splunk software performs search reruns on a best effort basis. When you enable this setting it is possible for Splunk software to return partial results for searches without warning. When set to 'false', search processes stop returning results from specific indexers when those indexers fail, and the Splunk software does not rerun those searches.	false
`[search]` `search_retry_max_historical`	`<integer>`Specifies the maximum number of attempts that the Splunk software makes to rerun a historical search as described by 'search_retry'. More This setting is applied only when 'search_retry = true'. This setting applies only to historical searches. When the number of attempts exceeds 'search_retry_max_historical', the search fails with an error stating that results are incomplete.	15
`[search]` `search_retry_waiting_time`	`<integer>`Sets how long, in seconds, 'search_retry' waits to get updated indexer information. More The wait time required for recovery after indexer failure can vary depending on your indexer environment. Increase this value if your environment needs more recovery time to get updated indexer information. The value should be >= 1	70
`[search]` `stack_size`	`<integer>`The stack size, in bytes, of the thread that executes the search.	4194304 (4MB)
`[search]` `summary_mode`	`[all\|only\|none]`Specifies if precomputed summary data are to be used. More When set to "all": Use summary data if possible, otherwise use raw data. When set to "only": Use summary data if possible, otherwise do not use any data. When set to "none": Never use precomputed summary data.	all
`[search]` `track_indextime_range`	`<boolean>`Specifies if the system should track the _indextime range of returned search results.	true
`[search]` `use_bloomfilter`	`<boolean>`Specifies whether the Splunk software uses Bloom filters to optimize searches. More When set to 'true', the Splunk software consults 'bloomfilter' files that may be present in index buckets to determine whether those buckets contain relevant search terms, thereby enabling the software to skip search of tsidx files that do not have relevant search terms. In this way, Bloom filter usage can improve search performance. When set to 'false', the Splunk software searches tsidx summary files without filtering out tsidx files that do not have relevant terms. NOTE: Do not change this setting unless instructed to do so by Splunk Support.	true
`[search]` `use_metadata_elimination`	`<boolean>`Control whether to use metadata to rule out buckets.	true
`[search]` `results_serial_format`	`[csv\|srs]`The internal format used for storing serialized results on disk. More Options: csv: Comma-separated values format srs: Splunk binary format NOTE: Do not change this setting unless instructed to do so by Splunk Support.	srs
`[search]` `results_compression_algorithm`	`[gzip\|zstd\|none]`The compression algorithm used for storing serialized results on disk. More Options: gzip: gzip zstd: zstd none: No compression NOTE: Do not change this setting unless instructed to do so by Splunk Support.	zstd
`[search]` `record_search_telemetry`	`<boolean>`Controls whether to record search related metrics in search_telemetry.json in the dispatch dir. It also indexes this file to the _introspection index. More NOTE: Do not change this setting unless instructed to do so by Splunk Support.	true
`[search]` `index_remote_search_telemetry`	`<boolean>`Controls whether search peers can index remote search telemetry. This setting applies locally to search peers. More NOTE: Do not change this setting unless instructed to do so by Splunk Support.	false
`[search]` `fetch_remote_search_telemetry`	`<boolean>`Controls whether to fetch remote search telemetry from indexer peers to the search head. More NOTE: Do not change this setting unless instructed to do so by Splunk Support. Do not set the value to "1" to indicate "true", because some systems might not parse this value correctly.	true
`[search]` `optimize_search_telemetry`	`<boolean>`When set to "true", optimizes the search telemetry payload by disabling the following low priority metrics: phases.nodes.splunk_version, phases.nodes.splunk_build and perf.subsearch_properties. More NOTE: Do not change this setting unless instructed to do so by Splunk Support.	false
`[search]` `search_telemetry_file_limit`	`<integer>`Sets a limit to the number of telemetry files that the Splunk software can copy to the var/run/splunk/search_telemetry/ directory, so that it may index them in the _introspection index. More This setting applies only to the search head. See 'remote_search_telemetry_file_limit' to set the corresponding setting for search peers, which applies to remote searches. Once this limit is reached, the Splunk software stops adding telemetry files to the directory for indexing. NOTE: Do not change this setting unless instructed to do so by Splunk Support.	500
`[search]` `remote_search_telemetry_file_limit`	`<integer>`Sets a limit for the number of telemetry files that Splunk software copies to the var/run/splunk/search_telemetry/ directory when indexing the files in the _introspection index. More This setting applies only to telemetry on search peers and is typically set to a lower value than the 'search_telemetry_file_limit' setting to limit the impact of search telemetry on indexer input pipelines. When this limit is reached, Splunk software stops adding telemetry files to the directory for indexing. NOTE: Do not change this setting unless instructed to do so by Splunk Support.	30
`[search]` `search_telemetry_component_limit`	`<integer>`Sets a limit to the size (in bytes) of each of the constituent components in the search telemetry json representation. More Once this limit is reached, the Splunk software will replace the constituent component with a simple value: "trimmed". NOTE: Do not change this setting unless instructed to do so by Splunk Support.	10000
`[search]` `use_dispatchtmp_dir`	`<boolean>`DEPRECATED. This setting has been deprecated and has no effect.
`[search]` `auto_cancel_after_pause`	`<integer>`Specifies the amount of time, in seconds, that a search must be paused before the search is automatically cancelled. More If set to 0, a paused search is never automatically cancelled.	0
`[search]` `always_include_indexedfield_lispy`	`<boolean>`Whether or not search always looks for a field that does not have "INDEXED = true" set in fields.conf using both the indexed and non- indexed forms. More If set to "true", when searching for <field>=<value>, the lexicon is searched for both "<field>::<value>" and "<value>". If set to "false", when searching for <field>=<val>, the lexicon is searched only for "<value>". Set to "true" if you have fields that are sometimes indexed and sometimes not indexed. For field names that are always indexed, it is much better for performance to set "INDEXED = true" in fields.conf for that field instead.	true
`[search]` `indexed_fields_expansion`	`<boolean>`Specifies whether search scopes known indexed fields with the source types that they are known to be indexed with. More When set to 'true', for every field known to be indexed, the Splunk software converts every known field=val statement to field::val, scoped with the applicable sourcetypes.	true
`[search]` `max_searchinfo_map_size`	`<integer>`Maximum number of entries in each SearchResultsInfo data structure map that are used to track information about search behavior	50000
`[search]` `track_matching_sourcetypes`	`<boolean>`if true, keeps track of the number of events of each sourcetype that match a search, and store that information in info.csv	true
`[search]` `search_launch_timeout_seconds`	`<positive integer>`The maximum amount of time, in seconds, to wait before a search job is launched successfully. More If a search job does not launch after the timeout interval elapses, the job terminates as a search failure. If search jobs time out frequently before successfully launching, check whether the server running Splunk software is overloaded. Alternatively, change this setting to a number greater than 180. For most deployments, 180 seconds is sufficient.	180
`[search]` `search_startup_config_timeout_ms`	`<positive integer>`The amount of time allowed in milliseconds to initialize a search job's configuration, including the knowledge bundle. More If initializing the search configuration takes longer than the time allowed by this setting, the 'DISPATCH_RUNNER:SLOW_CONFIG_INITIAL' warning message is displayed in Splunk Web. This setting is used only to monitor search performance.	3000
`[search]` `max_audit_sourcetypes`	`<integer>`if track_matching_sourcetypes = true, the matching sourcetypes for a search will be written to the info=completed audit.log message upon completion of the search, up to max_audit_sourcetypes. More If max_audit_sourcetypes is set to 0, sourcetype information will not be added to audit.log. If the number of matching sourcetypes exceeds the max_audit_sourcetypes setting, the sourcetypes with the greatest number of matching events will be included.	100
`[search]` `use_search_evaluator_v2`	`<boolean>`If true, search evaluator v2 is used. More NOTE: Do not change this setting unless instructed to do so by Splunk Support.	true
`[search]` `use_bucket_predictor_v2`	`<boolean>`If set to "true", uses version 2 of the bucket predictor, which improves sparse SmartStore search performance. If set to "false", search uses the older version of the bucket predictor. More NOTE: Do not change this setting unless instructed to do so by Splunk Support.	false
`[search]` `execute_postprocess_in_search`	`<boolean>`If true, try to run postprocess searches ahead of time in the search process instead of the main splunkd process.	true
`[search]` `max_fieldmeta_cnt_ui`	`<number>`The maximum number of field metadata displayed in the /jobs/fieldmeta endpoint. More When viewing the search job status for searches with a large number of field metadata, decreasing this value will reduce the memory load on splunkd mothership, but show less field metadata in the web UI.	1000
`[search]` `max_macro_depth`	`<integer>`Maximum recursion depth for macros. Specifies the maximum levels for macro expansion. More It is considered a search exception if macro expansion does not stop after this many levels. Value must be greater than or equal to 1.	100
`[search]` `max_subsearch_depth`	`<integer>`Maximum recursion depth for subsearches. Specifies the maximum levels for subsearches. More It is considered a search exception if a subsearch does not stop after this many levels.	8
`[search]` `min_prefix_len`	`<integer>`The minimum length of a prefix before a wildcard (*) to use in the query to the index.	1
`[search]` `use_directives`	`<boolean>`Specifies whether a search can take directives and interpret them into arguments. More This is used in conjunction with the search optimizer in order to improve search performance.	true
`[search]` `auto_exclude_segmented_terms`	`[yes\|no]`Whether or not LISPY expressions generated from search predicates of form "field=a.b" can be optimized by excluding segmentation of the search term that is used as input when the LISPY expression is generated. More This optimization setting generates a more selective LISPY expression, which potentially improves search performance. Candidates for this optimization are search predicate expressions where the right side of the expression is a segmented search term. For this example, assume the setting 'always_include_indexedfield_lispy' is set to "true", which is the default setting. A value of "true" means that the Splunk platform generates the following optimized LISPY: [ OR a.b field::a.b field=a.b ] A value of "false" means that the predicate "field=a.b" results in the following LISPY: [ OR field::a.b [ AND a b ] ] If enabled, this optimization is applied only if the optimized LISPY would generate the same search result as the non-optimized LISPY expression.	no
`[search]` `phased_execution`	`<boolean>`DEPRECATED: This setting has been deprecated.
`[search]` `phased_execution_mode`	`[multithreaded\|auto\|singlethreaded]`DEPRECATED: This setting has been deprecated. More Controls whether searches use the multiple-phase method of search execution, which is required for parallel reduce functionality as of Splunk Enterprise 7.1.0. When set to 'multithreaded' the Splunk platform uses the multiple-phase search execution method. Allows usage of the 'prjob' command and the 'redistribute' command. When set to 'auto', the Splunk platform uses the multiple-phase search execution method when the 'prjob' command or the 'redistribute' command are used in the search string. If neither the 'prjob' command nor the 'redistribute' command are present in the search string, the single-phase search execution method is used. When set to 'singlethreaded' the Splunk platform uses the single-threaded search execution method, which does not allow usage of the 'prjob' command or the 'redistribute' command. NOTE: Do not change this setting unless instructed to do so by Splunk Support.	multithreaded
`[search]` `max_preview_period`	`<integer>`The maximum time, in seconds, between previews. More Used with the preview interval that is calculated with the 'preview_duty_cycle' setting. When set to "0": Specifies unlimited time between previews.	0
`[search]` `min_preview_period`	`<integer>`The minimum time, in seconds, required between previews. When the calculated interval using 'preview_duty_cycle' indicates previews should be run frequently. This setting is used to limit the frequency with which previews run.	1
`[search]` `preview_duty_cycle`	`<number>`The maximum time to spend generating previews, as a fraction of the total search time. More Must be > 0.0 and < 1.0	0.25
`[search]` `preview_freq`	`<timespan> or <decimal>`The minimum amount of time between results preview updates. More You can specify values for this setting in one of two formats: As a span of time. In this format, you specify an integer and a character that represents a time unit, for example, "10s" means 10 seconds. The preview updates every period of 'preview_freq'. As a ratio of the amount of time that the search has been running. In this format, you specify a decimal. The preview updates as a ratio of the amount of time that the search has ben running, or as a ratio of the length of the time window for real-time windowed searches. If you use the ratio format, you must specify a decimal number above 0 and less than 1. A setting of 0 disables preview_freq, meaning that there are no limits to the minimum time between previews. NOTE: Change this setting only when instructed to do so by Splunk Support.	0.05
`[search]` `max_preview_generation_inputcount`	`<unsigned integer>`The maximum number of input result rows that the search head can use to generate search result previews. More NOTE: This setting doesn't apply to Splunk-to-Splunk federated searches. To change your federated search configuration, use the 'max_preview_generation_inputcount' setting in the federated.conf file. This limit doesn't stop searches from completing and returning final result sets. When a search reaches this limit, preview generation processes only the first number of rows specified by the 'max_preview_generation_inputcount' setting in order to generate the preview results. Change the value of this setting to a number above zero if your searches are being terminated because their preview generation duration exceeds a timeout set by another component in your network, such as an elastic load balancer (ELB). For example, if you have an ELB that times out at 60 seconds, you might set the 'max_preview_generation_inputcount' to "500000". A setting of "0" means that the preview generation input count of searches is unlimited.	0
`[search]` `default_allow_queue`	`<boolean>`Unless otherwise specified by using a REST API argument, specifies if an asynchronous job spawning request should be queued on quota violation. If not, an http error of server too busy is returned.	1 (true)
`[search]` `dispatch_quota_retry`	`<integer>`The maximum number of times to retry to dispatch a search when the quota has been reached.	1
`[search]` `dispatch_quota_sleep_ms`	`<integer>`The time, in milliseconds, between retrying to dispatch a search when a quota is reached. More Retries the given number of times, with each successive wait 2x longer than the previous wait time.	10
`[search]` `enable_cumulative_quota`	`<boolean>`Specifies whether to enforce cumulative role based quotas.	false
`[search]` `queued_job_check_freq`	`<number>`Frequency, in seconds, to check queued jobs to determine if the jobs can be started. More Fractional seconds are allowed.	1.
`[search]` `chunk_multiplier`	`<integer>`A multiplier that the 'max_results_perchunk', 'min_results_perchunk', and 'target_time_perchunk' settings are multiplied by for a long running search.	5
`[search]` `long_search_threshold`	`<integer>`The time, in seconds, until a search is considered "long running".	2
`[search]` `max_rawsize_perchunk`	`<integer>`The maximum raw size, in bytes, of results for each call to search (in dispatch). More When set to "0": Specifies that there is no size limit. This setting is not affected by the 'chunk_multiplier' setting.	100000000 (100MB)
`[search]` `max_results_perchunk`	`<integer>`Maximum results for each call to search (in dispatch). More Must be less than or equal to the 'maxresultrows' setting.	2500
`[search]` `min_results_perchunk`	`<integer>`The minimum results for each call to search (in dispatch). More Must be less than or equal to the 'max_results_perchunk' setting.	100
`[search]` `target_time_perchunk`	`<integer>`The target duration, in milliseconds, of a particular call to fetch search results.	2000 (2 seconds)
`[search]` `check_splunkd_period`	`<number>`Amount of time, in seconds, that determines how frequently the search process (when running a real-time search) checks whether the parent process (splunkd) is running or not. More Fractional seconds are allowed.	60 (1 minute)
`[search]` `realtime_buffer`	`<integer>`Maximum number of accessible events to keep for real-time searches in Splunk Web. More Acts as circular buffer after this buffer limit is reached. Must be greater than or equal to 1.	10000
`[search]` `bucket_localize_acquire_lock_timeout_sec`	`<integer>`The maximum amount of time, in seconds, to wait when attempting to acquire a lock for a localized bucket. More When set to 0, waits indefinitely. This setting is only relevant when using remote storage.	60 (1 minute)
`[search]` `bucket_localize_connect_timeout_max_retries`	`<integer>`The maximum number of times to retry when getting connect timeouts while trying to localize a bucket. More When set to 0, do not retry This setting is only relevant when using remote storage.	5
`[search]` `bucket_localize_max_timeout_sec`	`<integer>`The maximum amount of time, in seconds, to spend localizing a bucket stored in remote storage. More If the bucket contents (what is required for the search) cannot be localized in that timeframe, the bucket will not be searched. When set to "0": Specifies an unlimited amount of time. This setting is only relevant when using remote storage.	300 (5 minutes)
`[search]` `bucket_localize_status_check_period_ms`	`<integer>`The amount of time, in milliseconds, between consecutive status checks to see if the needed bucket contents required by the search have been localized. More This setting is only relevant when using remote storage. The minimum and maximum values are 10 and 60000, respectively. If the specified value falls outside this range, it is effectively set to the nearest value within the range. For example, if you set the value to 70000, the effective value will be 60000.	50 (.05 seconds)
`[search]` `bucket_localize_status_check_backoff_start_ms`	`<integer>`When explicitly set, and different from bucket_localize_status_check_period_ms, enables exponential backoff between consecutive status checks for bucket localization. Starting from the specified amount of time, in milliseconds, up to bucket_localize_status_check_period_ms. More This setting is only relevant when using remote storage. Setting this option is beneficial when bucket contents localize quickly (e.g., in less time than the minimal allowed value for bucket_localize_status_check_period_ms), or with high variability. The minimum and maximum values are 1 and bucket_localize_status_check_period_ms, respectively. If the specified value falls outside this range, it is effectively set to the nearest value within the range. NOTE: Do not change this setting unless instructed to do so by Splunk Support.	0 (no backoff)
`[search]` `bucket_localize_max_lookahead`	`<integer>`Specifies the maximum number of buckets the search command localizes for look-ahead purposes, in addition to the required bucket. More Increasing this value can improve performance, at the cost of additional network/io/disk utilization. Valid values are 0-64. Any value larger than 64 will be set to 64. Other invalid values will be discarded and the default will be substituted. This setting is only relevant when using remote storage.	5
`[search]` `bucket_localize_lookahead_priority_ratio`	`<integer>`A value of N means that lookahead localizations will occur only 1 out of N search localizations, if any.	5
`[search]` `bucket_predictor`	`[consec_not_needed\|everything]`Specifies which bucket file prediction algorithm to use. More Do not change this unless you know what you are doing.	consec_not_needed
`[search]` `max_count`	`<integer>`The number of events that can be accessible in any given status bucket (when status_buckets = 0). More The last accessible event in a call that takes a base and count. NOTE: This value does not reflect the number of events displayed in the UI after the search is evaluated or computed.	500000
`[search]` `max_events_per_bucket`	`<integer>`For searches with 'status_buckets>0', this setting limits the number of events retrieved for each timeline bucket.	1000 in code.
`[search]` `status_buckets`	`<integer>`The approximate maximum number buckets to generate and maintain in the timeline.	0, which means do not generate timeline information
`[search]` `read_final_results_from_timeliner`	`<boolean>`When you run a search of event data where 'status_buckets > 0', this setting controls the contents of the results.csv.gz and results.srs.zstd files in the search artifact. More When set to "true", the final results saved to disk by the search process on the search head are a sample of events ready from the timeliner. Do not set the value to "1" to indicate "true", because some systems might not parse this value correctly. When set to "false", the final results saved to disk by the search process on the search head are all events produced by the last SPL command, up to a limit of 'max_count' events. The 'read_final_results_from_timeliner' setting affects the output of subsequent 'loadjob' searches. When set to "true" the 'loadjob' search returns the sample of the final results, not the full result set. For example, if the full result set is 10k results, it might return only 1000 results. When set to "false" the 'loadjob' search returns the full set of search results. For example, if the full result set is 10k results, it returns 10k results.	true
`[search]` `field_filters`	`<boolean>`Determines whether field filters can be used to protect sensitive data in Splunk platform indexes. More When set to "true": field filters are turned on. When set to "false": field filters are turned off.	true
`[search]` `truncate_report`	`[1\|0]`Specifies whether or not to apply the 'max_count' setting to report output.	0 (false)
`[search]` `write_multifile_results_out`	`<boolean>`At the end of the search, if results are in multiple files, write out the multiple files to the results_dir directory, under the search results directory. More This setting speeds up post-processing search, since the results will already be split into appropriate size files.	true
`[search]` `include_temp_dirs_in_disk_usage`	`<boolean>`Whether or not the size of temporary directories that user searches create counts toward the total disk usage for the user who runs the search. More A value of "true" means that the Splunk platform counts the size of temporary directories that user searches create. A value of "false" means that the Splunk platform does not count the size of temporary directories that user searches create.	false
`[search]` `idle_process_cache_search_count`	`<integer>`The number of searches that the search process must reach, before purging older data from the cache. The purge is performed even if the 'idle_process_cache_timeout' has not been reached. More When a search process is allowed to run more than one search, the search process can cache some data between searches. When set to a negative value: No purge occurs, no matter how many searches are run. Has no effect on Windows if 'search_process_mode' is not set to "auto" or if 'max_searches_per_process' is set to "0" or "1".	8
`[search]` `idle_process_cache_timeout`	`<number>`The amount of time, in seconds, that a search process must be idle before the system purges some older data from these caches. More When a search process is allowed to run more than one search, the search process can cache some data between searches. When set to a negative value: No purge occurs, no matter on how long the search process is idle. When set to "0": Purging always occurs, regardless of whether the process has been idle or not. Has no effect on Windows if 'search_process_mode' is not set to "auto" or if 'max_searches_per_process' is set to "0" or "1".	0.5 (seconds)
`[search]` `idle_process_regex_cache_hiwater`	`<integer>`A threshold for the number of entries in the regex cache. If the regex cache grows to larger than this number of entries, the systems attempts to purge some of the older entries. More When a search process is allowed to run more than one search, the search process can cache compiled regex artifacts. Usually the 'idle_process_cache_search_count' and the 'idle_process_cache_timeout' settings keep the regex cache at a reasonable size. This setting prevents the cache from growing extremely large during a single large search. When set to a negative value: No purge occurs, not matter how large the cache. Has no effect on Windows if 'search_process_mode' is not set to "auto" or if 'max_searches_per_process' is set to "0" or "1".	2500
`[search]` `idle_process_reaper_period`	`auto \| <number>`The amount of time, in seconds, between checks to determine if there are too many idle search processes. More When a search process is allowed to run more than one search, the system checks if there are too many idle search processes. Has no effect on Windows if 'search_process_mode' is not set to "auto" or if 'max_searches_per_process' is set to "0" or "1".	30
`[search]` `idle_process_hostwide_memory_threshold`	`auto \| <positive integer>`The threshold, specified as a percentage of allowed hostwide memory usage, that determines whether a search process can enter the pool of preforked search processes and become idle for reuse. More When total memory used by hostwide processes exceeds this threshold, instead of idling a search process after job completion, the system terminates and doesn't reuse the search process when the total number of idle search processes reaches the 'max_idle_process_count' limit, or when the pool size reaches the 'max_search_process_pool' limit. A value of "auto" lets the system automatically adjust the threshold. This setting applies only when 'search_process_mode' has a value of "auto", and has no effect on Windows platforms. The valid value range for this threshold is from 1 to 100.	90
`[search]` `launcher_max_idle_checks`	`auto \| <integer>`Specifies the number of idle processes that are inspected before giving up and starting a new search process. More When allowing more than one search to run for each process, the system attempts to find an appropriate idle process to use. When set to a negative value: Every eligible idle process is inspected. Has no effect on Windows if 'search_process_mode' is not set to "auto" or if 'max_searches_per_process is set to "0" or "1".	5
`[search]` `launcher_threads`	`<integer>`The number of server thread to run to manage the search processes. More Valid only when more than one search is allowed to run for each process. Has no effect on Windows if 'search_process_mode' is not set to "auto" or if 'max_searches_per_process' is set to "0" or "1".	-1 (a value is selected automatically)
`[search]` `max_idle_process_count`	`auto \| <integer>`The maximum number of preforked search processes that are allowed to be idle and reused by later search execution. More The setting is valid if the 'enable_search_process_long_lifespan' setting in the server.conf file is set to "true". Otherwise, it is set to zero when "enable_search_process_long_lifespan = false". If the total number of idle search processes exceeds this setting, some processes are reaped until the number meets the setting. Adjust this setting to control how the Splunk server memory is used by idle search processes. The Splunk server can consume more system memory when the number of idle search processes is higher. When set to "auto": the initial value is set to 64. When set to "-1" or another negative value: the setting has no limit. This setting is not applied on computers running Windows or when 'search_process_mode' is not "auto".	auto
`[search]` `max_idle_process_memory`	`auto \| <integer>`The maximum amount of memory (RSS) in KB used by a search process that is allowed to be idle and reused later after running successfully. More The setting is valid if the 'enable_search_process_long_lifespan' setting in the server.conf file is set to "true". If the memory used by a search process when it runs exceeds this setting, the process is not reusable. As a result, the process exits after it runs. Use this setting to prevent a search process from potential OOM issues due to the increase in memory usage after the process has been reused too many times. When set to "auto": The initial default value is set to "(1024*1024)" KB and subsequently adjusted automatically depending on the amount of system memory that is available to Splunk software. When set to "-1" or another negative value: The memory size is not limited. Has no effect on Windows or if “search_process_mode” is not "auto".	auto
`[search]` `max_search_process_pool`	`auto \| <integer>`The maximum number of search processes that can be launched to run searches in the pool of preforked search processes. More The setting is valid if the 'enable_search_process_long_lifespan' setting in the server.conf file is set to "true". Use this setting to limit the total number of running search processes on a search head or peer that is prevented from being overloaded or using high system resources (CPU, Memory, etc). When set to "auto": Splunk server determines the pool size by multiplying the number of CPU cores and the allowed number of search processes (16). The pool size is 64 at minimum. When set to "-1" or another negative value: The pool size is not limited. Has no effect on Windows or if “search_process_mode” is not "auto".	2048
`[search]` `max_old_bundle_idle_time`	`auto \| <number>`The amount of time, in seconds, that a process bundle must be idle before the process bundle is considered for reaping. More Used when reaping idle search processes and the process is not configured with the most recent configuration bundle. When set to "auto": Splunk software uses the internal default value. If the 'enable_search_process_long_lifespan' setting in the server.conf file is set to "true", the default value is "300". Otherwise, it is "5". When set to "-1" or negative value: The idle processes are not reaped sooner than normal if the processes are using an older configuration bundle. Has no effect on Windows if 'search_process_mode' is not set to "auto" or if 'max_searches_per_process' is set to "0" or "1".	5
`[search]` `max_searches_per_process`	`<integer>`Specifies the maximum number of searches that each search process can run before exiting. More After a search completes, the search process can wait for another search to start and the search process can be reused. When set to "0" or "1": The process is never reused. When set to a negative value: There is no limit to the number of searches that a process can run. Has no effect on Windows if 'search_process_mode' is not set to "auto".	500 (Linux); 1 (Windows)
`[search]` `max_searches_started_per_cycle`	`<integer>`Specifies the number of new, concurrent searches started by the search launcher in a cycle. More This limits the contention between running searches and new searches, improving search process reuse, and efficiency. Note: Do not change this setting unless instructed to do so by Splunk Support. Has no effect on Windows if 'search_process_mode' is not set to "auto" or if 'max_searches_per_process' is set to "0" or "1".	30
`[search]` `max_time_per_process`	`auto \| <number>`Specifies the maximum time, in seconds, that a process can spend running searches. More When a search process is allowed to run more than one search, limits how much time a process can accumulate running searches before the process must exit. When set to a negative value: There is no limit on the amount of time a search process can spend running. Has no effect on Windows if 'search_process_mode' is not set to "auto" or if 'max_searches_per_process' is set to "0" or "1". NOTE: A search can run longer than the value set for 'max_time_per_process' without being terminated. This setting ONLY prevents the process from being used to run additional searches after the maximum time is reached.	auto
`[search]` `process_max_age`	`<number>`Specifies the maximum age, in seconds, for a search process. More When a search process is allowed to run more than one search, a process is not reused if the process is older than the value specified. When set to a negative value: There is no limit on the age of the search process. This setting includes the time that the process spends idle, which is different than "max_time_per_process" setting. Has no effect on Windows if 'search_process_mode' is not set to "auto" or if 'max_searches_per_process' is set to "0" or "1". NOTE: A search can run longer than the time set for 'process_max_age' without being terminated. This setting ONLY prevents that process from being used to run more searches after the search completes.	7200 (120 minutes or 2 hours)
`[search]` `process_min_age_before_user_change`	`auto \| <number>`The minimum age, in seconds, of an idle process before using a process from a different user. More When a search process is allowed to run more than one search, the system tries to reuse an idle process that last ran a search by the same Splunk user. If no such idle process exists, the system tries to use an idle process from a different user. The idle process from a different user must be idle for at least the value specified for the 'process_min_age_before_user_change' setting. When set to "0": Any idle process by any Splunk user can be reused. When set to a negative value: Only a search process by same Splunk user can be reused. Has no effect on Windows if 'search_process_mode' is not set to "auto" or if 'max_searches_per_process' is set to "0" or "1".	4
`[search]` `search_process_mode`	`[auto\|traditional\|debug <debugging-command> <debugging-args>]`Controls how search processes are started. More When set to "traditional": Each search process is initialized completely from scratch. When set to "debug": When set to a string beginning with "debug", searches are routed through the <debugging-command>, where the user can "plug in" debugging tools. The <debugging-command> must reside in one of the following locations: $SPLUNK_HOME/etc/system/bin/ $SPLUNK_HOME/etc/apps/$YOUR_APP/bin/ $SPLUNK_HOME/bin/scripts/ The <debugging-args> are passed, followed by the search command it would normally run, to <debugging-command> For example, given the following setting: search_process_mode = debug $SPLUNK_HOME/bin/scripts/search-debugger.sh 5 A command similar to the following is run: $SPLUNK_HOME/bin/scripts/search-debugger.sh 5 splunkd search \ --id=... --maxbuckets=... --ttl=... [...]	auto
`[search]` `search_process_configure_oom_score_adj`	`<boolean>`Determines whether to increase the value of the oom_score (Out of Memory Score) for search processes. More The oom_score is proportional to the amount of memory used by the process, and shows how likely the system is to terminate the process due to low available memory. When memory runs low, the system kills the process with the highest oom_score to free the most memory. If set to true, when system runs out of memory, the kernel preferentially kills search processes to protect the main splunkd process and make the overall service more stable. Applies to Linux operating system only.	true.
`[search]` `search_process_set_oom_score_adj`	`<integer>`Specifies the value added to the existing oom_score for search processes. More Applies only when 'search_process_configure_oom_score_adj' is set to true. The higher the value, the more likely the system is to kill search processes before the main splunkd process, decreasing the risk of a Splunk software crash. Supports integers between 0 and 1000. If set to 0, this setting has no effect on searches. Generally, the highest oom_score of main splunkd process is less than 700. Thus, by adding the default value, in most cases the system is likely to kill search processes before it kills the main splunkd process.	700.
`[search]` `toggle_server_conf_reload`	`<boolean>`A value of "true" means Splunk platform reloads the server.conf file before creating a search process. More A value of "false" means Splunk platform does not reload the server.conf file before creating a search process. NOTE: Do not change this setting unless instructed to do so by Splunk Support.	true
`[search]` `log_search_messages`	`<boolean>`Specifies whether splunkd promotes user-facing search messages from $SPLUNK_HOME/var/run/splunk/dispatch/<sid>/info.csv to $SPLUNK_HOME/var/log/splunk/search_messages.log. More Splunkd does not promote messages with a severity that is ranked lower than the value of search_messages_severity. Splunkd promotes messages only after search has been audited. The search_messages.log file follows this format when it logs messages: orig_component="..." sid="..." peer_name="..." message=...	true
`[search]` `search_messages_severity`	`<string>`When 'log_search_messages = true', this setting specifies the lowest severity of message that splunkd logs to search_messages.log. The processor ignores all messages with a lower severity. More Possible values in ascending order: DEBUG, INFO, WARN, ERROR For example, when 'search_messages_severity = WARN', splunkd logs only messages with 'WARN' and 'ERROR' severities.	WARN
`[search]` `allow_reuse`	`<boolean>`Specifies whether to allow normally executed historical searches to be implicitly re-used for newer requests if the newer request allows it.	true
`[search]` `reuse_map_maxsize`	`<integer>`Maximum number of jobs to store in the reuse map.	1000
`[search]` `reduce_duty_cycle`	`<number>`The maximum time to spend performing the reduce, as a fraction of total search time. More Must be > 0.0 and < 1.0.	0.25
`[search]` `reduce_freq`	`<integer>`When the specified number of chunks is reached, attempt to reduce the intermediate results. More When set to "0": Specifies that there is never an attempt to reduce the intermediate result.	10
`[search]` `remote_reduce_limit`	`<unsigned long>`The number of results processed by a streaming search before a reduce is forced. More NOTE: this option applies only if the search is run with --runReduce=true (currently only Splunk Analytics for Hadoop does this) When set to "0": Specifies that there is no limit.	1000000
`[search]` `unified_search`	`<boolean>`Specifies if unified search is turned on for hunk archiving.	false
`[search]` `status_cache_size`	`<integer>`The number of status data for search jobs that splunkd can cache in RAM. This cache improves performance of the jobs endpoint.	10000
`[search]` `status_cache_per_entry_max_size`	`<integer>`The maximum serialized size, in bytes, of a search job eligible for caching in the status cache.	1048576
`[search]` `status_period_ms`	`<integer>`The minimum amount of time, in milliseconds, between successive status/info.csv file updates. More This setting ensures that search does not spend significant time just updating these files. This is typically important for very large number of search peers. It could also be important for extremely rapid responses from search peers, when the search peers have very little work to do.	1000 (1 second)
`[search]` `status_field_truncation.enabled`	`<boolean>`NOTE: Do not change this setting unless instructed to do so by Splunk Support. More Reduces memory usage by truncating individual fields of status CSV files before storing them internally for managing search job status. All fields are eligible for truncation unless they are included in 'status_field_truncation.exclude_fields'.	false
`[search]` `status_field_truncation.exclude_fields`	`<comma separated list>`NOTE: Do not change this setting unless instructed to do so by Splunk Support. More A comma-separated list of job status fields to exclude from truncation when 'status_field_truncation.enabled' has a value of "true".	report_search
`[search]` `status_field_truncation.search_field_len`	`<non-negative integer>`NOTE: Do not change this setting unless instructed to do so by Splunk Support. More The maximum length, in characters, for any search-based field in the search job status when 'status_field_truncation.enabled' has a value of "true". Field values longer than this length are truncated unless included in the 'status_field_truncation.exclude_fields' list. Search-based fields include: remote_search, normalized_search, optimized_search, phase_0_search, phase_1_search, report_search, and events_search.	5000
`[search]` `status_field_truncation.default_field_len`	`<non-negative integer>`NOTE: Do not change this setting unless instructed to do so by Splunk Support. More The maximum length, in characters, for any non search-based field in the search job status when 'status_field_truncation.enabled' has a value of "true". Field values longer than this length are truncated unless included in the 'status_field_truncation.exclude_fields' list.	1000000
`[search]` `remote_event_download_finalize_pool`	`<integer>`Size of the pool, in threads, responsible for writing out the full remote events.	5
`[search]` `remote_event_download_initialize_pool`	`<integer>`Size of the pool, in threads, responsible for initiating the remote event fetch.	5
`[search]` `remote_event_download_local_pool`	`<integer>`Size of the pool, in threads, responsible for reading full local events.	5
`[search]` `remote_timeline`	`<boolean>`Specifies if the timeline can be computed remotely to enable better map/reduce scalability.	1 (true)
`[search]` `remote_timeline_connection_timeout`	`<integer>`Connection timeout, in seconds, for fetching events processed by remote peer timeliner.	5.
`[search]` `remote_timeline_fetchall`	`<boolean>`When set to "1" (true): Splunk fetches all events accessible through the timeline from the remote peers before the job is considered done. More Fetching of all events might delay the finalization of some searches, typically those running in verbose mode from the main Search view in Splunk Web. This potential performance impact can be mitigated by lowering the 'max_events_per_bucket' settings. When set to "0" (false): The search peers might not ship all matching events to the search head, particularly if there is a very large number of them. Skipping the complete fetching of events back to the search head will result in prompt search finalization. Some events may not be available to browse in the UI. This setting does NOT affect the accuracy of search results computed by reporting searches.	1 (true)
`[search]` `remote_timeline_max_count`	`<integer>`Maximum number of events to be stored per timeline bucket on each search peer.	10000
`[search]` `remote_timeline_max_size_mb`	`<integer>`Maximum size of disk, in MB, that remote timeline events should take on each peer. More If the limit is reached, a DEBUG message is emitted and should be visible in the job inspector or in messages.	100
`[search]` `remote_timeline_min_peers`	`<integer>`Minimum number of search peers for enabling remote computation of timelines.	1
`[search]` `remote_timeline_parallel_fetch`	`<boolean>`Specifies whether to connect to multiple peers at the same time when fetching remote events.	true
`[search]` `remote_timeline_prefetch`	`<integer>`Specifies the maximum number of full eventuate that each peer should proactively send at the beginning.	100
`[search]` `remote_timeline_receive_timeout`	`<integer>`Receive timeout, in seconds, for fetching events processed by remote peer timeliner.	10
`[search]` `remote_timeline_send_timeout`	`<integer>`Send timeout, in seconds, for fetching events processed by remote peer timeliner.	10
`[search]` `remote_timeline_thread`	`<boolean>`Specifies whether to use a separate thread to read the full events from remote peers if 'remote_timeline' is used and 'remote_timeline_fetchall' is set to "true". Has no effect if 'remote_timeline' or 'remote_timeline_fetchall' is set to "false".	1 (true)
`[search]` `remote_timeline_touchperiod`	`<number>`How often, in seconds, while a search is running to touch remote timeline artifacts to keep the artifacts from being deleted by the remote peer. More When set to "0": The remote timelines are never touched. Fractional seconds are allowed.	300 (5 minutes)
`[search]` `timeline_events_preview`	`<boolean>`When set to "true": Display events in the Search app as the events are scanned, including events that are in-memory and not yet committed, instead of waiting until all of the events are scanned to see the search results. You will not be able to expand the event information in the event viewer until events are committed. More When set to "false": Events are displayed only after the events are committed (the events are written to the disk). This setting might increase disk usage to temporarily save uncommitted events while the search is running. Additionally, search performance might be impacted.	false
`[search]` `timeline_freq`	`<timespan> or <ratio>`The minimum amount of time, in seconds, between timeline commits. More If specified as a number < 1 (and > 0), minimum time between commits is computed as a ratio of the amount of time that the search has been running.	0
`[search]` `cache_ttl`	`<integer>`The length of time, in seconds, to persist search cache entries.	300 (5 minutes)
`[search]` `default_save_ttl`	`<integer>`How long, in seconds, the ttl for a search artifact should be extended in response to the save control action. More When set to 0, the system waits indefinitely.	604800 (1 week)
`[search]` `failed_job_ttl`	`<integer>`How long, in seconds, the search artifacts should be stored on disk after a job has failed. The ttl is computed relative to the modtime of the status.csv file of the job, if the file exists, or the modtime of the artifact directory for the search job. More If a job is being actively viewed in the Splunk UI then the modtime of the status.csv file is constantly updated such that the reaper does not remove the job from underneath.	86400 (24 hours)
`[search]` `remote_ttl`	`<integer>`How long, in seconds, the search artifacts from searches run in behalf of a search head should be stored on the indexer after completion.	600 (10 minutes)
`[search]` `shc_cached_artifacts_ttl`	`<integer>`The maximum amount of time, in seconds, that search artifacts generated by asynchronous replication or downloaded from remote storage can persist on search head cluster members that did not originally run the search. More NOTE: This setting does not apply to replicated artifacts containing a "shpoolManaged" file. Those replicas are removed when the original copy is removed. 'failed_job_ttl' takes precedence for artifacts from failed search jobs and artifacts missing a metadata.csv file. If a job is being actively viewed in the Splunk UI then the modtime of the status.csv file is constantly updated such that the reaper does not remove the job from underneath.	86400 (24 hours)
`[search]` `ttl`	`<integer>`How long, in seconds, the search artifacts should be stored on disk after the job completes. The ttl is computed relative to the modtime of the status.csv file of the job, if the file exists, or the modtime of the artifact directory for the search job. More If a job is being actively viewed in the Splunk UI then the modtime of the status.csv file is constantly updated such that the reaper does not remove the job from underneath.	600 (10 minutes)
`[search]` `check_search_marker_done_interval`	`<integer>`The amount of time, in seconds, that elapses between checks of search marker files, such as hot bucket markers and backfill complete markers. More This setting is used to identify when the remote search process on the indexer completes processing all hot bucket and backfill portions of the search.	60
`[search]` `check_search_marker_sleep_interval`	`<integer>`The amount of time, in seconds, that the process will sleep between subsequent search marker file checks. More This setting is used to put the process into sleep mode periodically on the indexer, then wake up and check whether hot buckets and backfill portions of the search are complete.	1
`[search]` `srtemp_dir_ttl`	`<integer>`The time to live, in seconds, for the temporary files and directories within the intermediate search results directory tree. More These files and directories are located in $SPLUNK_HOME/var/run/splunk/srtemp. Every 'srtemp_dir_ttl' seconds, the reaper removes files and directories within this tree to reclaim disk space. The reaper measures the time to live through the newest file modification time within the directory. When set to 0, the reaper does not remove any files or directories in this tree.	86400 (24 hours)
`[search]` `search_transaction_establish_connection_max_retries`	`<integer>`Controls the number of retries a search head performs when it initially contacts search peers. More NOTE: Do not change this setting unless instructed to do so by Splunk Support.	3
`[search]` `priority_based_dispatch_reaper`	`<boolean>`Whether or not the priority-based dispatch reaper is active. This reaper uses the expiration time (creation or modification time plus the Time-To-Live (TTL) period) of a search artifact to optimize the order in which artifacts are reaped from the artifact directory on disk. This reaping strategy builds an in-memory state of reaping attributes of search artifacts based on the order of their expiration in ascending order. More A value of "true" means the priority-based dispatch reaper is turned on. A value of "false" means the priority-based dispatch reaper is turned off. NOTE: Do not change this setting unless instructed to do so by Splunk Support.	false
`[search]` `dispatch_dir_maximum_count`	`<integer>`The maximum number of completed jobs in the dispatch directory. This setting helps prioritize the health of Splunk platform deployments by reaping older dispatch directories. More When the maximum is exceeded, completed search artifacts are reaped in order of earliest creation or modification time. For example, the oldest artifacts are reaped first until the count of completed search artifacts falls below the limit. If two artifacts exist, one created at time t1 and another at time t2, where t1 is earlier than t2, the artifact from t1 is reaped first if the limit is exceeded and it is the earliest one in the order. This setting can reap search artifacts ahead of their expiration to satisfy this limit and preserve the health of the Splunk platform deployment. This setting applies only when 'priority_based_dispatch_reaper' has a value of "true". This setting applies only to dispatch directories containing completed search artifacts. In-progress search jobs are not affected. NOTE: Do not change this setting unless instructed to do so by Splunk Support.	40000
`[search]` `enable_status_cache`	`<boolean>`This is not a user tunable setting. Do not use this setting without working in tandem with Splunk personnel. This setting is not tested at non-default. More This controls whether the status cache is used, which caches information about search jobs (and job artifacts) in memory in main splunkd. Normally this cacheing is enabled and assists performance. However, when using Search Head Pooling, artifacts in the shared storage location will be changed by other search heads, so this cacheing is disabled. Explicit requests to jobs endpoints , eg /services/search/jobs/<sid> are always satisfied from disk, regardless of this setting.	true (when search head pooling is not enabled); false (when search head pooling is enabled)
`[search]` `status_cache_in_memory_ttl`	`<positive integer>`This is not a user tunable setting. Do not use this setting without working in tandem with Splunk personnel. This setting is not tested at non-default. More This setting has no effect unless search head pooling is enabled, AND enable_status_cache has been set to true. If set, controls the number of milliseconds which a status cache entry may be used before it expires.	60000 (60 seconds)
`[search]` `max_bucket_bytes`	`<integer>`This setting has been deprecated and has no effect.
`[search]` `rr_min_sleep_ms`	`<integer>`REMOVED. This setting is no longer used.
`[search]` `rr_max_sleep_ms`	`<integer>`REMOVED. This setting is no longer used.
`[search]` `rr_sleep_factor`	`<integer>`REMOVED. This setting is no longer used.

`[search_throttling::per_cpu]`

Setting	Description	Default
`[search_throttling::per_cpu]` `max_concurrent`	`<non-negative decimal>`Sets the maximum number of remote searches for each available CPU. More The total number of searches for this throttling type is calculated using: max_searches = max_concurrent x number_of_cpus When the calculated value is exceeded, search requests are rejected until the number of concurrent searches falls below the 'max_concurrent' limit. A value of a fractional number less than 1 means that the limit of concurrent searches is less than 1 search per CPU. A value of 0 means that throttling is turned off. This setting is relevant only when used with 'remote_search_requests_throttling_type'.	12

`[search_throttling::physical_ram]`

Setting	Description	Default
`[search_throttling::physical_ram]` `min_memory_per_search`	`<unsigned integer>[KB\|MB\|GB]`Sets the minimum memory requirement per search instance. The total number of searches for this throttling type is thus calculated as: max_searches = available_system_memory / min_memory_per_search More When the calculated value is exceeded, search requests are rejected until the number of concurrent searches falls below the limit. A value of 0 disables throttling. This setting is relevant only when used with 'remote_search_requests_throttling_type'. Specify this value as an integer followed by KB, MB, or GB (for example, 10MB is 10 megabytes)	450MB

`[anomalousvalue]`

Setting	Description	Default
`[anomalousvalue]` `maxresultrows`	`<integer>`Configures the maximum number of events that can be present in memory at one time.	The value set for 'maxresultrows' in the [searchresults] stanza, which is 50000 by default.
`[anomalousvalue]` `maxvalues`	`<integer>`Maximum number of distinct values for a field.	0
`[anomalousvalue]` `maxvaluesize`	`<integer>`Maximum size, in bytes, of any single value (truncated to this size if larger).	0

`[associate]`

Setting	Description	Default
`[associate]` `maxfields`	`<integer>`Maximum number of fields to analyze.	10000
`[associate]` `maxvalues`	`<integer>`Maximum number of values for any field to keep track of.	0
`[associate]` `maxvaluesize`	`<integer>`Maximum length of a single value to consider.	0

`[autoregress]`

Setting	Description	Default
`[autoregress]` `maxp`	`<integer>`Maximum number of events for auto regression.	10000
`[autoregress]` `maxrange`	`<integer>`Maximum magnitude of range for p values when given a range.	1000

`[collect]`

Setting	Description	Default
`[collect]` `format_multivalue_collect`	`<boolean>`Specifies whether the 'collect' processor should format multivalued fields specially when it collects them into a summary index. More A setting of 'true' means that the 'collect' processor will break each value of a multivalue field out into a discrete key/value pair. For example, when this setting is 'true' and the 'collect' processor is given the field 'alphabet' with values 'a, b, c', the 'collect' processor adds the following fields to the summary index: alphabet="a", alphabet="b", alphabet="c" A setting of 'false' means that the 'collect' processor will collect each multivalued field as a single key with values listed and newline-separated. For example, when this setting is 'false' and the 'collect' processor is given the field 'alphabet' with values 'a, b, c', the 'collect' processor adds the following field to the summary index: alphabet="a b c"	false
`[collect]` `collect_ignore_minor_breakers`	`<boolean>`Specifies whether the 'collect' command adds quotation marks around field values containing major or minor breakers when the command collects those values into a summary index. More A setting of 'true' means that the 'collect' command checks for major breakers in field values, such as spaces, square or curly brackets, parentheses, semicolons, or exclamation points. If 'collect' finds major breakers in a field value, it adds quotation marks to that field value. This enables the use of 'tstats' with the PREFIX() directive on fields that do not contain major breakers. A setting of 'false' means that the 'collect' command adds quotation marks when it finds either a minor breaker or a major breaker in a field value. For example, say you have the field-value pair 'user_name = name@spl.com'. In this case both '@' and '.' are minor breakers. When 'collect_ignore_minor_breakers = true', the 'collect' command does not enclose the value of 'user_name' in quotation marks when it adds the field-value pair to the summary index: user_name = name@spl.com When 'collect_ignore_minor_breakers = false', the 'collect' command encloses the value of 'user_name' in quotation marks because 'collect' detects that the value contains minor breakers. In this case, this is what 'collect' adds to the summary index: user_name = "name@spl.com"	false

`[concurrency]`

Setting	Description	Default
`[concurrency]` `max_count`	`<integer>`Maximum number of detected concurrencies.	10000000

`[correlate]`

Setting	Description	Default
`[correlate]` `maxfields`	`<integer>`Maximum number of fields to correlate.	1000

`[ctable]`

This stanza controls settings for the contingency command.
Aliases for the contingency command are: ctable and counttable.

Setting	Description	Default
`[ctable]` `maxvalues`	`<integer>`Maximum number of columns/rows to generate (the maximum number of distinct values for the row field and column field).	1000

`[dbinspect]`

Setting	Description	Default
`[dbinspect]` `maxresultrows`	`<integer>`The maximum number of result rows that the dbinspect command can fetch at one time. More A smaller value uses less search head memory in scenarios with large number of buckets. However, setting the value too small decreases search performance. Note: Do not change this setting unless instructed to do so by Splunk Support.	50000

`[discretize]`

This stanza contains the settings for the bin command.
Aliases for the bin command are: bucket and discretize.

Setting	Description	Default
`[discretize]` `default_time_bins`	`<integer>`When discretizing time for timechart or explicitly via bin, the default bins to use if no span or bins is specified.	100
`[discretize]` `maxbins`	`<integer>`Maximum number of bins to discretize into. More If 'maxbins' is not specified or = 0, 'maxbins' uses the value set for 'maxresultrows' in the [searchresults] stanza, which is 50000 by default.	50000

`[eval]`

Setting	Description	Default
`[eval]` `printf_max_precision`	`<non-negative integer>`The maximum usable precision for 'printf' format strings. More NOTE: Do not change this setting unless instructed to do so by Splunk Support.	1000000
`[eval]` `printf_max_width`	`<integer>`The maximum usable width for 'printf' format strings. More NOTE: Do not change this setting unless instructed to do so by Splunk Support.	1000000

`[findkeywords]`

Setting	Description	Default
`[findkeywords]` `maxevents`	`<integer>`Maximum number of events used by the findkeywords command and the Patterns tab.	50000

`[geomfilter]`

Setting	Description	Default
`[geomfilter]` `enable_clipping`	`<boolean>`Whether or not polygons are clipped to the viewport provided by the render client.	true
`[geomfilter]` `enable_generalization`	`<boolean>`Whether or not generalization is applied to polygon boundaries to reduce point count for rendering.	true

`[geostats]`

Setting	Description	Default
`[geostats]` `filterstrategy`	`<integer>`Controls the selection strategy on the geoviz map. More Valid values are 1 and 2.
`[geostats]` `maxzoomlevel`	`<integer>`Controls the number of zoom levels that geostats will cluster events on.
`[geostats]` `zl_0_gridcell_latspan`	`<decimal>`Controls what is the grid spacing in terms of latitude degrees at the lowest zoom level, which is zoom-level 0. More Grid-spacing at other zoom levels are auto created from this value by reducing by a factor of 2 at each zoom-level.
`[geostats]` `zl_0_gridcell_longspan`	`<decimal>`Controls what is the grid spacing in terms of longitude degrees at the lowest zoom level, which is zoom-level 0 More Grid-spacing at other zoom levels are auto created from this value by reducing by a factor of 2 at each zoom-level.

`[indexing_search_log]`

Setting	Description	Default
`[indexing_search_log]` `enabled`	`<boolean>`Controls whether to enable the setting that indexes search.log files for failed searches. The number of failed searches per day whose search.log files are indexed is based on the 'rate_limit_per_day' setting. More NOTE: Do not change this setting unless directed to do so by Splunk Support.	false
`[indexing_search_log]` `rate_limit_per_day`	`<integer>`The maximum number of times per day that failed search.log files should be indexed. More NOTE: Do not change this setting unless directed to do so by Splunk Support.	5
`[indexing_search_log]` `queue_capacity`	`<integer>`The capacity of the queue for search.log files, which is the maximum number of files that can be held in memory for processing before the queue starts rejecting new entries. More NOTE: Do not change this setting unless directed to do so by Splunk Support.	10
`[indexing_search_log]` `sinkhole_file_limit`	`<integer>`The maximum number of search.log files that can be held in the var/run/splunk/search_log directory while search.log data is being indexed. More NOTE: Do not change this setting unless directed to do so by Splunk Support.	100

`[inputcsv]`

Setting	Description	Default
`[inputcsv]` `mkdir_max_retries`	`<integer>`Maximum number of retries for creating a tmp directory (with random name as subdir of SPLUNK_HOME/var/run/splunk)	100

`[inputlookup]`

Setting	Description	Default
`[inputlookup]` `kv_chunk_size`	`<integer>`Specifies the maximum number of results to fetch in a single read from an external or cohosted KV store by the 'inputlookup' command. More This setting applies to external or cohosted KV store lookups only. A smaller value requires less memory on the search head. However, setting this value too small decreases 'inputlookup' performance. NOTE: Do not change this setting unless Splunk Support instructs you to do so.	50000
`[inputlookup]` `inputlookup_cursor`	`<boolean>`Controls whether 'inputlookup' operations use cursor mode for external or cohosted KV store lookups. More A value of "true" means that 'inputlookup' operations send multiple requests to the external or cohosted KV store 'inputlookup' cursor API. This maintains state across requests and improves performance for 'inputlookup' operations with complex queries. A value of "false" means that 'inputlookup' operations use the standard 'inputlookup' mode, which makes multiple separate requests to the external or cohosted KV store, with each request receiving a single response. This mode supports pagination with offset-based data retrieval. This setting applies to external or cohosted KV store lookups only. NOTE: Do not change this setting unless Splunk Support instructs you to do so.	false

`[iplocation]`

Setting	Description	Default
`[iplocation]` `db_path`	`<path>`The absolute path to the GeoIP database in the MMDB format. More The 'db_path' setting does not support standard Splunk environment variables such as SPLUNK_HOME.	The database that is included with the Splunk platform.

`[join]`

Setting	Description	Default
`[join]` `subsearch_maxout`	`<integer>`The maximum number of result rows to output from subsearch to join against More The join command subsearch results are restricted by two settings, 'subsearch_maxout' setting in this stanza and 'maxresultrows' setting in the [searchresults] stanza.	50000
`[join]` `subsearch_maxtime`	`<integer>`Maximum search time, in seconds, before auto-finalization of subsearch.	60
`[join]` `subsearch_timeout`	`<integer>`Maximum time, in seconds, to wait for subsearch to fully finish. More DEPRECATED	120

`[kmeans]`

Setting	Description	Default
`[kmeans]` `maxdatapoints`	`<integer>`Maximum data points to do kmeans clusterings for.	100000000 (100 million)
`[kmeans]` `maxkrange`	`<integer>`Maximum number of k values to iterate over when specifying a range.	100
`[kmeans]` `maxkvalue`	`<integer>`Maximum number of clusters to attempt to solve for.	1000

`[lookup]`

Setting	Description	Default
`[lookup]` `batch_index_query`	`<boolean>`Should non-memory file lookups (files that are too large) use batched queries to possibly improve performance?	true
`[lookup]` `batch_response_limit`	`<integer>`When doing batch requests, the maximum number of matches to retrieve. More If more than this limit of matches would otherwise be retrieved, the lookup falls back to non-batch mode matching.	5000000
`[lookup]` `max_lookup_messages`	`<positive integer>`If more than "max_lookup_messages" log entries are generated, additional entries will not be logged in info.csv. All entries will still be logged in search.log.
`[lookup]` `max_matches`	`<integer>`DEPRECATED: Use this setting in transforms.conf for lookup definitions.
`[lookup]` `max_memtable_bytes`	`<integer>`Maximum size, in bytes, of static lookup file to use an in-memory index for. More Lookup files with size above max_memtable_bytes will be indexed on disk NOTE: This setting also applies to lookup files loaded through the lookup() eval function which runs at search time. The same function if called through the ingest-eval functionality, uses ingest_max_memtable_bytes instead. CAUTION: Setting this to a large value results in loading large lookup files in memory. This leads to a bigger process memory footprint.	26214400 (25MB)
`[lookup]` `ingest_max_memtable_bytes`	`<integer>`Maximum size, in bytes, of static lookup file to use for a lookup when used in the ingest context. (i.e when used with the lookup() eval function at ingest time). More Lookup files with size above ingest_max_memtable_bytes cannot be used for the lookup() eval function when used with the ingest-eval functionality. CAUTION: Setting this to a large value results in loading large lookup files in memory. This leads to a bigger process (splunkd) memory footprint.	10485760 (10MB)
`[lookup]` `ingest_lookup_refresh_period_secs`	`<integer>`Period of time, in seconds, after which the in-memory lookup tables that are used with the lookup() eval function at ingest time are refreshed. More This does not apply if the lookup() function is used at search time.	60 (1 minute).
`[lookup]` `indexed_csv_ttl`	`<positive integer>`Specifies the amount of time, in seconds, that a indexed CSV lookup table can exist without update before it is removed by Splunk software. More On a period set by 'indexed_csv_keep_alive_timeout', Splunk software checks the CSV lookup table to see if it has been updated. If it has been updated, Splunk software modifies a special token file. At the end of the 'indexed_csv_ttl' period Splunk software looks at the token file. If the token file shows that its CSV lookup table has been updated, Splunk software does not delete that CSV lookup table.	300
`[lookup]` `indexed_csv_keep_alive_timeout`	`<positive integer>`Sets the period, in seconds, for an activity check that Splunk software performs on indexed CSV lookup tables. More When Splunk software performs a CSV lookup table check and finds that the table has been updated, it marks this activity on a token file. The token file update prevents the CSV lookup table from being deleted after 'indexed_csv_ttl' seconds of inactivity have passed.	30
`[lookup]` `indexed_csv_inprogress_max_timeout`	`<positive integer>`Sets the maximum time, in seconds, for Splunk software to wait for ongoing indexing of a CSV lookup table to finish before failing any search that is awaiting the lookup table.	300
`[lookup]` `max_reverse_matches`	`<integer>`maximum reverse lookup matches (for search expansion)	50
`[lookup]` `shared_provider_cache_size`	`<integer>`Sets the cache size in bytes that the Splunk software uses when it shares CSV lookups across multiple lookup commands. More The <integer> represents the size of the cache in bytes. This is incremented by the size of each in-memory file (in bytes) inserted into the shared cache. Set this to 0 to disable lookup sharing, defaults to 200MB (209715200 bytes). Do not change this value unless you are advised to do so by Splunk Support or a similar authority.	209715200
`[lookup]` `input_errors_fatal`	`<boolean>`This setting determines whether certain inputlookup or inputcsv command errors cause searches to fail or return a warning message. More When set to true, this setting causes inputlookup and inputcsv errors to make an entire search fail. This happens even when the errors take place in a subsearch. When set to false, this setting returns a warning message for many inputlookup and inputcsv error conditions. Certain kinds of errors cause searches to fail no matter how this setting is set.	false
`[lookup]` `scripted_lookup_raw_write_enforcement`	`[warn\|block]`Controls how Splunk platform handles raw configuration writes through the /properties/transforms and /configs/conf-transforms files, when the resulting transforms.conf stanza would create or edit a scripted lookup definition and the caller does not have the required external lookup capability. More A value of "warn" logs a warning and allows the write. A value of "block" rejects the write.	warn
`[lookup]` `enable_splunkd_kv_lookup_indexing`	`<boolean>`This setting determines whether KV Store lookup indexing is performed during bundle replication. More When set to true, KVStore lookup indexing occurs on the main splunkd process, asynchronous to searches. When set to false, KV Store lookup indexing is triggered by the search process, potentially slowing search performance. NOTE: Do not change this setting unless instructed to do so by Splunk Support.	true
`[lookup]` `enforce_auto_lookup_order`	`<boolean>`true: LOOKUP-<name>s in props.conf are looked up in ASCII order by <name>. More false: LOOKUP-<name>s in props.conf are looked up in random order.	false
`[lookup]` `indexed_csv_include_underscore_key_field`	`<boolean>`Determines whether Splunk software indexes the _key field during CSV lookup indexing. More NOTE: Do not change this setting unless instructed to do so by Splunk Support.	true

`[makeresults]`

Setting	Description	Default
`[makeresults]` `maxresultrows`	`<integer>`Maximum number of result rows to create. More If not specified, defaults to the value set for 'maxresultrows' in the [searchresults] stanza, which is 50000 by default.	50000

`[metadata]`

Setting	Description	Default
`[metadata]` `bucket_localize_max_lookahead`	`<integer>`This setting is only relevant when using remote storage. More Specifies the maximum number of buckets the metadata command localizes for look-ahead purposes, in addition to the required bucket. Increasing this value can improve performance, at the cost of additional network/io/disk utilization. Valid values are 0-64. Any value larger than 64 will be set to 64. Other invalid values will be discarded and the default will be substituted.	10
`[metadata]` `maxcount`	`<integer>`The total number of metadata search results returned by the search head; after the 'maxcount' is reached, any additional metadata results received from the search peers will be ignored (not returned). More A larger number incurs additional memory usage on the search head.	100000
`[metadata]` `maxresultrows`	`<integer>`The maximum number of results in a single chunk fetched by the metadata command More A smaller value will require less memory on the search head in setups with large number of peers and many metadata results, though, setting this too small will decrease the search performance. NOTE: Do not change this setting unless instructed to do so by Splunk Support.	10000

`[metric_alerts]`

This stanza provides global settings for metric alerts.

Setting	Description	Default
`[metric_alerts]` `condition_evaluation_interval`	`<integer>`This setting provides the alert condition evaluation interval in minutes. More Must be a number from 1 to 60.	1
`[metric_alerts]` `search_delay`	`<time specifier>`Specifies a delay time for metric alert searches. It can be passed to the 'allow_skew' setting for the search. More The search delay allows the search to wait for the latest indexed data. For example, * 15s+ means search delay is at least 15s after the minute determined by `condition_evaluation_interval`. * 15s+30s means search delay is a random number from 15s to 45s after the minute. Only change this setting if you are experiencing significant data latency issues.	15s+
`[metric_alerts]` `search_ttl`	`<positive integer>p`Specifies the default life span of metric alert search jobs. More The time to live is defined as "at least until the Nth periodic run of the search, where the period is defined by the 'condition_evaluation_interval' setting".	2p
`[metric_alerts]` `honor_action`	`<boolean>`Specifies whether the Splunk software should change the 'search_ttl' to the action ttl when an action is triggered. More If there are multiple actions, the largest action ttl wins.	false

`[msearch]`

Setting	Description	Default
`[msearch]` `chunk_size`	`<unsigned integer>`Specifies the default value of the 'chunk_size' argument for the 'msearch' command. More When you run an 'msearch' search, the search head returns batches of metric time series until the search result set is complete. This argument sets a limit for the number of metric time series that the search head can gather in a single batch from a single MSIDX file. For example, when 'chunk_size=100', the search head can return 100 metric time series worth of metric data points in batches until the search is complete. Lower this value when 'msearch' searches use too much memory, or when they infrequently return events. Larger 'chunk_size' values can improve search performance, with the tradeoff of using more memory per search. Smaller 'chunk_size' values can reduce search performance, with the tradeoff of using less memory per search. This setting cannot be set lower than 10.	1000
`[msearch]` `target_per_timeseries`	`<unsigned integer>`Specifies the maximum number of metric data points to retrieve per tsidx file associated with an 'msearch' query. More When set to 0, this setting returns all data points available within the given time range for each time series.	5

`[mvexpand]`

This stanza allows for fine tuning of mvexpand search command.

Setting	Description	Default
`[mvexpand]` `max_mem_usage_mb`	`<non-negative integer>`Overrides the default value for 'max_mem_usage_mb'. More Limits the amount of RAM, in megabytes (MB), a batch of events or results will use in the memory of a search process. See definition in the [default] stanza for 'max_mem_usage_mb' for more details.	500

`[mvcombine]`

This stanza allows for fine tuning of mvcombine search command.

Setting	Description	Default
`[mvcombine]` `max_mem_usage_mb`	`<non-negative integer>`Overrides the default value for 'max_mem_usage_mb' More Limits the amount of RAM, in megabytes (MB), a batch of events or results use in the memory of a search process. See definition in the [default] stanza for 'max_mem_usage_mb' for more details.	500

`[outputlookup]`

Setting	Description	Default
`[outputlookup]` `outputlookup_check_permission`	`<boolean>`Specifies whether the outputlookup command should verify that users have write permissions to CSV lookup table files. More outputlookup_check_permission is used in conjunction with the transforms.conf setting check_permission. The system only applies outputlookup_check_permission to .csv lookup configurations in transforms.conf that have check_permission=true. You can set lookup table file permissions in the .meta file for each lookup file, or through the Lookup Table Files page in Settings. By default, only users who have the admin or power role can write to a shared CSV lookup file.	false
`[outputlookup]` `create_context`	`[app\|user\|system]`Specifies the context where the lookup file will be created for the first time. If there is a current application context and the following options, file will be created under: More app : etc/apps/<app>/lookups user : etc/users/<user>/<app>/lookups Otherwise, file will be created under: system : etc/system/local/lookups	app

`[rare]`

Setting	Description	Default
`[rare]` `maxresultrows`	`<integer>`Maximum number of result rows to create. More If not specified, defaults to the value set for 'maxresultrows' in the [searchresults] stanza, which is 50000 by default.	50000
`[rare]` `maxvalues`	`<integer>`Maximum number of distinct field vector values to keep track of.	0
`[rare]` `maxvaluesize`	`<integer>`Maximum length of a single value to consider.	0

`[rest]`

Setting	Description	Default
`[rest]` `allow_reload`	`<boolean>`Whether or not the '_reload' action is allowed for the 'rest' search command.	false

`[set]`

Setting	Description	Default
`[set]` `maxresultrows`	`<integer>`The maximum number of results the set command will use from each result set to compute the required set operation.	50000

`[sort]`

Setting	Description	Default
`[sort]` `maxfiles`	`<integer>`Maximum files to open at once. Multiple passes are made if the number of result chunks exceeds this threshold.	64.

`[spath]`

Setting	Description	Default
`[spath]` `extract_all`	`<boolean>`Controls whether to respect automatic field extraction when spath is invoked manually. More If set to "true", all fields are extracted regardless of settings. If set to "false", only fields used by later search commands are extracted.	true
`[spath]` `extraction_cutoff`	`<integer>`For 'extract-all' spath extraction mode, this setting applies extraction only to the first <integer> number of bytes. This setting applies both the auto kv extraction and the spath command, when explicitly extracting fields.	5000

`[stats|sistats]`

NOTE: The following are rdigest and tdigest settings. rdigest is a data structure used to compute approximate order statistics (such as median and percentiles) using sublinear space.

Setting	Description	Default
`[stats\|sistats]` `approx_dc_threshold`	`<unsigned integer>`Applies specifically to the estdc(x) function (approximate distinct count). More When the Splunk software uses estdc(x) for commands such as stats, chart, and timechart, it does not use approximated results if the actual number of distinct values is below this threshold. To always use estimation, set 'approx_dc_threshold=1'. Note: When 'approx_dc_threshold=0' the Splunk software uses the default value for this setting (1000)	1000
`[stats\|sistats]` `dc_digest_bits`	`<integer>`The size of the digest used for approximating distinct count. More The digest is configured to be 2 ^ 'dc_digest_bits' bytes in size. Must be >= 8 (128B) and <= 16 (64KB)	10 (equivalent to 1KB)
`[stats\|sistats]` `default_partitions`	`<integer>`Number of partitions to split incoming data into for parallel/multithreaded reduce.	1
`[stats\|sistats]` `check_for_invalid_time`	`<boolean>`Specifies whether the stats processor returns results for searches with time-sensitive aggregations such as 'latest', 'latest_time', and 'rate' when the '_time' or '_origtime' field is missing from input events. More When you run a search that fits this description: A setting of 'true' means that the stats processor does not return results for that search. A setting of 'false' means that the stats processor returns results for that search that are likely incorrect or random. In either case, the stats processor displays an info message that tells you what has gone wrong and how it can be corrected.	false
`[stats\|sistats]` `list_maxsize`	`<integer>`Maximum number of list items to emit when using the list() function stats/sistats	100
`[stats\|sistats]` `max_keymap_rows`	`<integer>`Limits the number of result rows that the search head stores in the key map during the map phase of a 'stats' operation. The Splunk software looks up rows stored in the map and combines them greedily prior to final reduce. More 'Stats' performance is nonlinear with respect to the number of rows in the key map. Limiting the number of rows held can improve performance. Excess rows expunged from the key map remain in memory, subject to max_mem_usage_mb. A key map maps vectors of group-by keys (field values) to their associated rows. It is a feature of the 'stats' family of search commands. This setting applies particularly to high cardinality searches. This setting does not apply to 'streamstats' or 'eventstats' searches.	1000000
`[stats\|sistats]` `maxmem_check_freq`	`<integer>`How frequently, in number of rows, to check if the in-memory data structure size limit is exceeded, as specified by the 'max_mem_usage_mb' setting.	50000
`[stats\|sistats]` `maxresultrows`	`<integer>`Maximum number of rows allowed in the process memory. More When the search process exceeds 'max_mem_usage_mb' and 'maxresultrows', data is sent to the disk. If not specified, uses the value set for 'maxresultrows' in the [searchresults] stanza, which is 50000 by default.	50000
`[stats\|sistats]` `max_stream_window`	`<integer>`For the streamstats command, the maximum allow window size.	10000
`[stats\|sistats]` `maxvalues`	`<integer>`Maximum number of values for any field to keep track of. More When set to "0": Specifies an unlimited number of values.	0
`[stats\|sistats]` `maxvaluesize`	`<integer>`Maximum length of a single value to consider. More When set to "0": Specifies an unlimited number of values.	0
`[stats\|sistats]` `max_valuemap_bytes`	`<integer>`For the sistats command, the maximum encoded length of the valuemap, per result written out. More If limit is exceeded, extra result rows are written out as needed. 0 = no limit per row	100000
`[stats\|sistats]` `natural_sort_output`	`<boolean>`Whether or not to perform a natural sort on the output of 'stats' if the output size is greater than or equal to the 'maxresultrows' setting. More A natural sort means that numbers are sorted numerically and non-numbers are sorted lexicographically.	true
`[stats\|sistats]` `partitions_limit`	`<integer>`Maximum number of partitions to split into that can be specified with the 'partitions' option. More When exceeded, the number of partitions is reduced to this limit.	100
`[stats\|sistats]` `perc_method`	`nearest-rank\|interpolated`Which method to use for computing percentiles (and medians=50 percentile). More nearest-rank picks the number with 0-based rank R = floor((percentile/100)count) interpolated means given F = (percentile/100)(count-1), pick ranks R1 = floor(F) and R2 = ceiling(F). Answer = (R2 * (F - R1)) + (R1 * (1 - (F - R1))) See wikipedia percentile entries on nearest rank and "alternative methods"	nearest-rank
`[stats\|sistats]` `perc_digest_type`	`rdigest\|tdigest`Which digest algorithm to use for computing percentiles ( and medians=50 percentile). More rdigest picks the rdigest_k, rdigest_maxnodes and perc_method properties. tdigest picks the tdigest_k and tdigest_max_buffer_size properties.	tdigest
`[stats\|sistats]` `sparkline_maxsize`	`<integer>`Maximum number of elements to emit for a sparkline	The value of the 'list_maxsize' setting
`[stats\|sistats]` `sparkline_time_steps`	`<time-step-string>`Specify a set of time steps in order of decreasing granularity. Use an integer and one of the following time units to indicate each step. More s = seconds m = minutes h = hours d = days month A time step from this list is selected based on the <sparkline_maxsize> setting. The lowest <sparkline_time_steps> value that does not exceed the maximum number of bins is used. Example: If you have the following configurations: <sparkline_time_steps> = 1s,5s,10s,30s,1m,5m,10m,30m,1h,1d,1month <sparkline_maxsize> = 100 The timespan for 7 days of data is 604,800 seconds. Span = 604,800/<sparkline_maxsize>. If sparkline_maxsize = 100, then span = (604,800 / 100) = 60,480 sec == 1.68 hours. The "1d" time step is used because it is the lowest value that does not exceed the maximum number of bins.	1s,5s,10s,30s,1m,5m,10m,30m,1h,1d,1month
`[stats\|sistats]` `rdigest_k`	`<integer>`rdigest compression factor More Lower values mean more compression After compression, number of nodes guaranteed to be greater than or equal to 11 times k. Must be greater than or equal to 2.	100
`[stats\|sistats]` `rdigest_maxnodes`	`<integer>`Maximum rdigest nodes before automatic compression is triggered. More When set to "1": Specifies to automatically configure based on k value.	1
`[stats\|sistats]` `tdigest_k`	`<integer>`tdigest compression factor More Higher values mean less compression, more mem usage, but better accuracy. Must be greater than or equal to 1.	50
`[stats\|sistats]` `tdigest_max_buffer_size`	`<integer>`Maximum number of elements before automatic reallocation of buffer storage is triggered. More Smaller values result in less memory usage but is slower. Very small values (<100) are not recommended as they will be very slow. Larger values help performance up to a point after which it actually hurts performance. Recommended range is around 10tdigest_k to 30tdigest_k.	1000
`[stats\|sistats]` `tmpfile_compression`	`<string>`temporary file compression format, used for stats tmp files only More "lz4" indicates use of the lz4 format "zstd" indicates use of the zstd format "none" indicates use of no compression	lz4
`[stats\|sistats]` `tmpfile_compression_level`	`<int>`Temporary file compression format level. More If tmpfile_compression is lz4 or zstd, this will indicate the compression level. For zstd higher numbers indicate higher speed, and lower compression ratios. For lz4 higher numbers indicate lower speed, and higher compression ratios.	0
`[stats\|sistats]` `min_chunk_size_kb`	`<integer>`Specifies the minimum size of a chunk of intermediate results during 'stats' search processing. See 'chunk_size_double_every' for additional details. More This affects the minimum amount of ram required for low-cardinality 'stats' searches as well as the size and number of the files produced when that data is spilled to disk due to memory pressure. Adjust this value only when such an adjustment is absolutely necessary. If the 'stats' process must use less memory in low cardinality cases, reduce this value at the cost of increased filesystem inode usage and possibly decreased search performance. If the 'stats' process must use fewer filesystem inodes and create larger data chunks even for small searches, increase this value at the cost of memory in low cardinality searches.	64
`[stats\|sistats]` `max_chunk_size_kb`	`<integer>`Specifies the maximum size of a chunk of intermediate results during 'stats' search processing. See 'chunk_size_double_every' for additional details. More By limiting the maximum chunk size, this setting affects the number of data chunks that the 'stats' processor can create when intermediate data is spilled to disk due to memory pressure. Increase this setting if you need to reduce the filesystem inode usage of your 'stats' processes. This setting should never exceed 1/20th of 'max_mem_usage_mb'.	4096
`[stats\|sistats]` `chunk_size_double_every`	`<integer>`The 'stats' processor stores intermediate data for 'stats' searches in data chunks. These intermediate data chunks must have a size between 'min_chunk_size_kb' and 'max_chunk_size_kb'. More At the start of a stats job, the 'stats' processor sets the chunk size at the 'min_chunk_size_kb' limit. However, when the number of chunks it creates reaches the threshold set by 'chunk_size_double_every', the 'stats' processor doubles the size of each chunk it creates thereafter. The 'stats' processor continues doubling the chunk size it creates each time it creates an additional number of chunks equivalent to 'chunk_size_double_every'. The 'stats' processor stops doubling the chunk size when it reaches the 'max_chunk_size_kb' limit. This behavior lets the 'stats' processor begin 'stats' processes with small data chunks, which reduces ram usage on low cardinality searches. It also lets the 'stats' processor increase the chunk size when it spills a lot of data to disk, which reduces filesystem inode usage for high cardinality searches. To minimize allocation of unused memory, increase the 'chunk_size_double_every' threshold to keep the chunks smaller for a longer amount of time. To reduce filesystem inode usage, decrease the 'chunk_size_double_every' threshold so the 'stats' processor reaches the 'max_chunk_size_kb' limit quicker. This lowers the number of temporary files created by the search process.	100

`[top]`

Setting	Description	Default
`[top]` `maxresultrows`	`<integer>`Maximum number of result rows to create. More If not specified, uses the value set for 'maxresultrows' in the [searchresults] stanza, which is 50000 by default.	50000
`[top]` `maxvalues`	`<integer>`Maximum number of distinct field vector values to keep track of.	100000
`[top]` `maxvaluesize`	`<integer>`Maximum length of a single value to consider.	1000

`[transactions]`

Setting	Description	Default
`[transactions]` `maxopentxn`	`<integer>`Specifies the maximum number of not yet closed transactions to keep in the open pool before starting to evict transactions.	5000
`[transactions]` `maxopenevents`	`<integer>`Specifies the maximum number of events (which are) part of open transactions before transaction eviction starts happening, using LRU policy.	100000

`[tscollect]`

Setting	Description	Default
`[tscollect]` `squashcase`	`<boolean>`The default value of the 'squashcase' argument if not specified by the command	false
`[tscollect]` `keepresults`	`<boolean>`The default value of the 'keepresults' argument if not specified by the command	false
`[tscollect]` `optimize_max_size_mb`	`<unsigned integer>`The maximum size in megabytes of files to create with optimize More Specify 0 for no limit (may create very large tsidx files)	256

`[tstats]`

Setting	Description	Default
`[tstats]` `allow_old_summaries`	`<boolean>`Whether or not the 'tstats' command, when run on an accelerated datamodel, confirms that the datamodel search in each bucket's summary metadata is considered to be up to date with the current datamodel search. More Only bucket summaries that are considered "up to date" are used to deliver results. This value is the default value of the 'allow_old_summaries' setting, if that argument is not specified in the command. When set to "false", 'tstats' always confirms that the datamodel search in each bucket's summary metadata is considered up to date with the current datamodel search. When set to "true", 'tstats' delivers results even from bucket summaries that are considered out of date with the current datamodel.	false
`[tstats]` `apply_search_filter`	`<boolean>`Whether or not 'tstats' applies role-based search filters when users run the command on normal index data. More If set to "true", 'tstats' applies role-based search filters. NOTE: Regardless of this setting value, 'tstats' never applies search filters to data collected with 'tscollect', or with datamodel acceleration.	true
`[tstats]` `bucket_localize_max_lookahead`	`<integer>`This setting is only relevant when using remote storage. More Specifies the maximum number of buckets the tstats command localizes for look-ahead purposes, in addition to the required bucket. Increasing this value can improve performance, at the cost of additional network/io/disk utilization. Valid values are 0-64. Any value larger than 64 will be set to 64. Other invalid values will be discarded and the default will be substituted.	10
`[tstats]` `chunk_size`	`<unsigned integer>`ADVANCED: The default value of 'chunk_size' arg if not specified by the command More This argument controls how many events are retrieved at a time within a single TSIDX file when answering queries Consider lowering this value if tstats queries are using too much memory (cannot be set lower than 10000) Larger values will tend to cause more memory to be used (per search) and might have performance benefits. Smaller values will tend to reduce performance and might reduce memory used (per search). Altering this value without careful measurement is not advised.	10000000
`[tstats]` `include_events_omitted_when_filtering_numeric_values`	`<boolean>`When you run a 'tstats' search that filters numeric values of one or more fields, it might omit events where those fields do not exist or have NULL values from the search results. More This setting specifies whether this omission of events takes place when 'tstats' filters out events based on numeric values of fields. A setting of 'true' means that when the 'tstats' command filters out events where a field has a specific numeric value, it also matches events where that field is not present. A setting of 'false' means that when the 'tstats' command filters out events where a field has a specific numeric value, it also omits events where that field is not present.	false
`[tstats]` `summariesonly`	`<boolean>`Whether or not 'tstats' employs a mixed mode when running against an accelerated datamodel. More This value is the default value for the 'summariesonly' setting, if that argument is not specified in the command. In mixed mode, 'tstats' falls back to search if it encounters missing tsidx data. If set to "true", 'tstats' overrides this mixed mode, and only generates results from available tsidx data, which might be incomplete. If set to "false", 'tstats' uses mixed mode, and falls back to search for tsidx data that is missing.	false
`[tstats]` `warn_on_missing_summaries`	`<boolean>`ADVANCED: Only meant for debugging 'summariesonly=true' searches on accelerated datamodels. More When set to "true", search will issue a warning for a tstats 'summariesonly=true' search for the following scenarios: a) If there is a non-hot bucket that has no corresponding datamodel acceleration summary whatsoever. b) If the bucket's summary does not match with the current datamodel acceleration search.	false
`[tstats]` `batch_search_max_pipeline`	`<integer>`Controls the number of tstats/mstats search pipelines launched at the indexer during batch search. More Increase the number of search pipelines to improve search performance, at the cost of a concurrent increase in thread and memory usage. This value applies only to searches that run on remote indexers.	1
`[tstats]` `use_bloomfilter`	`<boolean>`Specifies whether the Splunk software uses Bloom filters to optimize searches. More When set to 'true', the Splunk software consults 'bloomfilter' files that may be present in index buckets to determine whether those buckets contain relevant search terms, thereby enabling the software to skip search of tsidx files that do not have relevant search terms. In this way, Bloom filter usage can improve search performance. When set to 'false', the Splunk software searches tsidx summary files without filtering out tsidx files that do not have relevant terms. NOTE: Do not change this setting unless instructed to do so by Splunk Support.	true
`[tstats]` `update_datamodel_usage_stats`	`<boolean>`Specifies whether or not Splunk software can call the summary touch endpoint when it detects that it is using summaries from an accelerated data model. More The summary touch endpoint is an internal endpoint that helps track how frequently a summary is being used, if ever. When 'update_datamodel_usage_stats' is set to "false", Splunk software skips this endpoint call. NOTE: Do not change this setting unless instructed to do so by Splunk Support.	true

`[mstats]`

Setting	Description	Default
`[mstats]` `time_bin_limit`	`<unsigned integer>`Applies only to mstats search jobs. More Controls how many time bins can be allocated within a single TSIDX file when the search head processes mstats search jobs that group results by time (by using 'span', for example). When this setting is set to 0, there is no time bin limit for qualifying mstats search jobs. Removing the time bin limit can cause the Splunk platform to run out of memory when you run those jobs. Lower this value when your mstats search jobs are using too much memory per search. Raise this value if your mstats searches return errors when they have wide time ranges or their group-by spans are too small. The Splunk platform estimates the number of time bins a search requires by dividing its time range by its group-by span. If range/span > 'time_bin_limit', it outputs an error. This could happen with a search with a time range of a year and a span of '1s', for example. The search time range is determined through the 'earliest' and 'latest' values for the search. Some types of searches, such as 'all time' searches, do not have 'earliest' and 'latest' values. In those cases the Splunk platform checks within each single TSIDX file to derive a time range for the search.	1000000
`[mstats]` `use_bloomfilter`	`<boolean>`Specifies whether the Splunk software uses Bloom filters to optimize searches. More When set to 'true', the Splunk software consults 'bloomfilter' files that may be present in index buckets to determine whether those buckets contain relevant search terms, thereby enabling the software to skip search of tsidx files that do not have relevant search terms. In this way, Bloom filter usage can improve search performance. When set to 'false', the Splunk software searches tsidx summary files without filtering out tsidx files that do not have relevant terms. NOTE: Do not change this setting unless instructed to do so by Splunk Support.	true
`[mstats]` `optimize_time_bin_memory`	`<boolean>`Whether or not Splunk software allocates optimized time bins within a single TSIDX file when mstats search jobs process data that groups results by time (for example, using 'span') and the data contains a dimset. More This setting applies only to mstats search jobs. A value of "false" means Splunk software does not optimize time bins for mstats search jobs and uses the old algorithm. A value of "true" means Splunk software optimizes time bins for mstats search jobs and uses the new, optimized algorithm. This setting, when "true", can reduce memory usage for mstats search jobs that process large amounts of data. It applies to all mstats searches. You can apply the setting to an individual search by using the '\|noop' command: '\| noop feature_flag="mstats:optimize_time_bin_memory:<boolean>"' NOTE: Do not change this setting unless instructed to do so by Splunk Support.	false

`[typeahead]`

Setting	Description	Default
`[typeahead]` `cache_ttl_sec`	`<integer>`How long, in seconds, the typeahead cached results are valid. More Default 300
`[typeahead]` `fetch_multiplier`	`<integer>`A multiplying factor that determines the number of terms to fetch from the index, fetch = fetch_multiplier x count.	50
`[typeahead]` `max_concurrent_per_user`	`<integer>`The maximum number of concurrent typeahead searches per user. Once this maximum is reached only cached typeahead results might be available	3
`[typeahead]` `maxcount`	`<integer>`Maximum number of typeahead results to find.	1000
`[typeahead]` `max_servers`	`<integer>`Specifies the maximum number of remote search servers that are used in addition to the search head for the purpose of providing typeahead functionality. More When properly set, 'max_servers' minimizes the workload impact of running typeahead search jobs in a clustering deployment. If your target indexes are evenly distributed among search servers, use the default setting or a similarly low number. For load balancing, the choice of remote search servers for typeahead searches is random. When set to "0": There is no limit and all available search servers are used for typeahead search jobs.	2
`[typeahead]` `min_prefix_length`	`<integer>`The minimum length of the string prefix after which to provide typeahead.	1
`[typeahead]` `use_cache`	`<boolean>`Specifies whether the typeahead cache will be used if use_cache is not specified in the command line or endpoint.	true or 1
`[typeahead]` `banned_segments`	`<semicolon-separated-list>`Specifies a semicolon-separated list of segments. The 'typeahead' search processor filters events with these segments out of the results it returns. More A best practice is to bracket each listed segment with wildcard asterisks (''). For example, if you set 'banned_segments = password;SSN*', the 'typeahead' processor removes any event that contains the string 'password' or 'SSN' from the final result set.	No default

`[typer]`

Setting	Description	Default
`[typer]` `maxlen`	`<integer>`In eventtyping, pay attention to first <integer> characters of any attribute (such as _raw), including individual tokens. Can be overridden by supplying the typer operator with the argument maxlen (for example, "\|typer maxlen=300").	10000

`[xyseries]`

This stanza allows for fine tuning of xyseries search command.

Setting	Description	Default
`[xyseries]` `max_mem_usage_mb`	`<non-negative integer>`Overrides the default value for 'max_mem_usage_mb' More See definition in [default] max_mem_usage_mb for more details

`[auto_summarizer]`

Setting	Description	Default
`[auto_summarizer]` `allow_event_summarization`	`<boolean>`Whether auto summarization of searches whose remote part returns events rather than results will be allowed.	false
`[auto_summarizer]` `cache_timeout`	`<integer>`The minimum amount of time, in seconds, to cache auto summary details and search hash codes. More The cached entry expires randomly between 'cache_timeout' and 2 * "cache_timeout" seconds.	600 (10 minutes)
`[auto_summarizer]` `detailed_dashboard`	`<boolean>`Turn on/off the display of both normalized and regular summaries in the Report Acceleration summary dashboard and details.	false
`[auto_summarizer]` `maintenance_period`	`<integer>`The period of time, in seconds, that the auto summarization maintenance happens	1800 (30 minutes)
`[auto_summarizer]` `max_run_stats`	`<integer>`Maximum number of summarization run statistics to keep track and expose via REST.	48
`[auto_summarizer]` `max_verify_buckets`	`<integer>`When verifying buckets, stop after verifying this many buckets if no failures have been found More 0 means never	100
`[auto_summarizer]` `max_verify_bucket_time`	`<integer>`Maximum time, in seconds, to spend verifying each bucket.	15
`[auto_summarizer]` `max_verify_ratio`	`<number>`Maximum fraction of data in each bucket to verify	0.1 (10%)
`[auto_summarizer]` `max_verify_total_time`	`<integer>`Maximum total time in seconds to spend doing verification, regardless if any buckets have failed or not More When set to "0": Specifies no limit.	0
`[auto_summarizer]` `normalized_summaries`	`<boolean>`Turn on/off normalization of report acceleration summaries.	true
`[auto_summarizer]` `return_actions_with_normalized_ids`	`[yes\|no\|fromcontext]`Report acceleration summaries are stored under a signature/hash which can be regular or normalized. More Normalization improves the re-use of pre-built summaries but is not supported before 5.0. This config will determine the default value of how normalization works (regular/normalized) When set to 'fromcontext': Specifies that the end points and summaries would be operating based on context. Normalization strategy can also be changed via admin/summarization REST calls with the 'use_normalization' argument, which can take the values "yes"/"no"/"fromcontext"	fromcontext
`[auto_summarizer]` `search_2_hash_cache_timeout`	`<integer>`The amount of time, in seconds, to cache search hash codes	The value of the 'cache_timeout' setting
`[auto_summarizer]` `shc_accurate_access_counts`	`<boolean>`Only relevant if you are using search head clustering More Turn on/off to make acceleration summary access counts accurate on the captain. by centralizing
`[auto_summarizer]` `verify_delete`	`<boolean>`Should summaries that fail verification be automatically deleted?	false
`[auto_summarizer]` `disable_transparent_mode_federation`	`<boolean>`Disable fowarding summarization searches to the remote search head for federated search transparent mode. More NOTE: Do not change this setting unless instructed to do so by Splunk Support.	false

`[export]`

Setting	Description	Default
`[export]` `add_offset`	`<boolean>`Add an offset/row number to JSON streaming output	true
`[export]` `add_timestamp`	`<boolean>`Add a epoch time timestamp to JSON streaming output that reflects the time the results were generated/retrieved	false

`[extern]`

Setting	Description	Default
`[extern]` `perf_warn_limit`	`<integer>`Warn when external scripted command is applied to more than this many events More When set to "0": Specifies for no message (message is always INFO level)	10000

`[auth]`

Settings for managing auth features.

Setting	Description	Default
`[auth]` `enable_install_apps`	`<boolean>`Whether or not the "install_apps" capability is enabled for app installation, uninstallation, creation, and update. More If set to "true", you must be assigned a role that holds the 'install_apps' capability to access the 'apps/local' REST endpoint for app installation, uninstallation, creation, and update. If set to "false", you must be assigned a role that holds either the 'admin_all_objects' or 'edit_local_apps' capabilities for app installation, uninstallation, creation, and update.	false
`[auth]` `enable_oauth2_for_applications`	`<boolean>`Whether or not OAuth authentication for third-party applications is turned on. More A value of "true" means OAuth authentication for third-party applications is turned on. A value of "false" means OAuth authentication for third-party applications is turned off.	true

`[http_input]`

Setting	Description	Default
`[http_input]` `max_number_of_tokens`	`<unsigned integer>`The maximum number of tokens reported by logging input metrics.	10000
`[http_input]` `max_content_length`	`<integer>`The maximum length, in bytes, of HTTP request content that is accepted by the HTTP Event Collector server.	838860800 (~ 800 MB)
`[http_input]` `max_number_of_ack_channel`	`<integer>`The maximum number of ACK channels accepted by HTTP Event Collector server.	1000000 (~ 1 million)
`[http_input]` `max_number_of_acked_requests_pending_query`	`<integer>`The maximum number of ACKed requests pending query on HTTP Event Collector server.	10000000 (~ 10 million)
`[http_input]` `max_number_of_acked_requests_pending_query_per_ack_channel`	`<integer>`The maximum number of ACKed requested pending query per ACK channel on HTTP Event Collector server..	1000000 (~ 1 million)
`[http_input]` `metrics_report_interval`	`<integer>`The interval, in seconds, of logging input metrics report.	60 (1 minute)

`[indexpreview]`

Setting	Description	Default
`[indexpreview]` `max_preview_bytes`	`<integer>`Maximum number of bytes to read from each file during preview	2000000 (2 MB)
`[indexpreview]` `max_results_perchunk`	`<integer>`Maximum number of results to emit per call to preview data generator	2500
`[indexpreview]` `soft_preview_queue_size`	`<integer>`Loosely-applied maximum on number of preview data objects held in memory	100

`[inputproc]`

Setting	Description	Default
`[inputproc]` `file_tracking_db_threshold_mb`	`<integer>`The maximum size (in megabytes) of the fishbucket file tracking checkpoint database. More When the fishbucket reaches this limit, the least recently used checkpoints are automatically deleted.	500
`[inputproc]` `file_tracking_db_fsync_enabled`	`<boolean>`Flushes modified file tracking checkpoints to disk immediately, which ensures durability, but might negatively impact performance in some cases. More Turn off this setting only if performance of file tracking databases is a concern. When turned off, recently updated checkpoints might be lost in the event of a power failure.	true
`[inputproc]` `learned_sourcetypes_limit`	`<0 or positive integer>`Limits the number of entries added to the learned app for performance reasons. More If nonzero, limits two properties of data added to the learned app by the file classifier. (Code specific to monitor:: stanzas that auto-determines sourcetypes from content.) The number of sourcetypes added to the learned app's props.conf file will be limited to approximately this number. The number of file-content fingerprints added to the learned app's sourcetypes.conf file will be limited to approximately this number. The tracking for uncompressed and compressed files is done separately, so in some cases this value may be exceeded. This limit is not the recommended solution for auto-identifying sourcetypes. The usual best practices are to set sourcetypes in input stanzas, or alternatively to apply them based on filename pattern in props.conf [source::<pattern>] stanzas.	1000
`[inputproc]` `max_fd`	`<integer>`Maximum number of file descriptors that a ingestion pipeline in Splunk will keep open, to capture any trailing data from files that are written to very slowly. More Note that this limit will be applied per ingestion pipeline. For more information about multiple ingestion pipelines see parallelIngestionPipelines in the server.conf.spec file. With N parallel ingestion pipelines the maximum number of file descriptors that can be open across all of the ingestion pipelines will be N * max_fd.	100
`[inputproc]` `monitornohandle_max_heap_mb`	`<integer>`The maximum amount of memory, in megabytes, used by the MonitorNoHandle modular input in user mode. More The memory of this input grows in size when the data being produced by applications writing to monitored files comes in faster than the Splunk instance can accept it. When set to 0, the heap size (memory allocated in the modular input) can grow without limit. If this size is limited, and the limit is encountered, the input drops some data to stay within the limit. This setting is valid only on Windows machines.	0
`[inputproc]` `tailing_proc_speed`	`<integer>`REMOVED. This setting is no longer used.
`[inputproc]` `monitornohandle_max_driver_mem_mb`	`<integer>`The maximum amount of NonPaged memory, in megabytes, used by the kernel driver of the MonitorNoHandle modular input. More The memory of this input grows in size when the data being produced by applications writing to monitored files comes in faster than the Splunk instance can accept it. When set to 0, the NonPaged memory size (memory allocated in the kernel driver of the modular input) can grow without limit. If this size is limited, and the limit is encountered, the input drops some data to stay within the limit. This setting is valid only on Windows machines.	0
`[inputproc]` `monitornohandle_max_driver_records`	`<integer>`The maximum number of in-memory records that the kernel module for the MonitorNoHandle modular input stores. More This setting controls memory growth by limiting the amount of memory that the MonitorNoHandle input kernel module uses. When 'monitornohandle_max_driver_mem_mb' is set to > 0, this setting is ignored. The 'monitornohandle_max_driver_mem_mb' and 'monitornohandle_max_driver_records' settings are mutually exclusive. If the limit is encountered, the input drops some data to remain within the limit.	500.
`[inputproc]` `time_before_close`	`<integer>`MOVED. This setting is now configured per-input in inputs.conf. More Specifying this setting in limits.conf is DEPRECATED, but overrides the setting for all inputs, for now.

`[journal_compression]`

Setting	Description	Default
`[journal_compression]` `threads`	`<integer>`Specifies the maximum number of indexer threads which will be work on compressing hot bucket journal data. More This setting does not typically need to be modified.	The number of CPU threads of the host machine

`[kv]`

Setting	Description	Default
`[kv]` `avg_extractor_time`	`<integer>`Maximum amount of CPU time, in milliseconds, that the average (over search results) execution time of a key-value pair extractor will be allowed to take before warning. Once the average becomes larger than this amount of time a warning will be issued	500 (.5 seconds)
`[kv]` `limit`	`<integer>`The maximum number of fields that an automatic key-value field extraction (auto kv) can generate at search time. More Increase this setting if you want to ensure that the field picker in the Splunk Web search page displays all fields. Set this value to 0 if you do not want to limit the number of fields that can be extracted at search time.	100
`[kv]` `indexed_kv_limit`	`<integer>`The maximum number of fields that can be extracted at index time from a data source. More This setting does not prevent a search from extracting indexed fields that the search needs and explicitly requests. The Splunk platform imposes this limit for each index bucket. Fields that can be extracted at index time include default fields, custom fields, and structured data header fields. The summary fields 'host', 'index', 'source', 'sourcetype', 'eventtype', 'linecount', 'splunk_server', and 'splunk_server_group' do not count against this limit and are always returned. Increase this setting if, for example, you have indexed data with a large number of columns and want to ensure that the field picker in the Splunk Web search page displays all fields. This setting is different from the 'limit' setting in that it limits field extraction in different phases of data processing. Previously, the 'limit' setting handled both index-time and search-time field extraction limits, and to maintain backward compatibility, both settings work in concert. The Splunk platform always uses the higher value for either setting to enforce index-time field extraction limits. For example, if you set 'indexed_kv_limit' to "500" and 'limit' to "200", then the platform limits indexed-time field extractions to 500 and search-time field extractions to 200. If you set 'indexed_kv_limit' to "200" and 'limit' to "500", then the platform limits both index-time and search-time field extraction to 500. Set this value to 0 if you do not want to limit the number of fields that can be extracted at index time.	200
`[kv]` `maxchars`	`<integer>`When non-zero, truncate _raw to this size and then do auto KV.	10240 characters
`[kv]` `maxcols`	`<integer>`When non-zero, the point at which kv should stop creating new fields.	512
`[kv]` `max_extractor_time`	`<integer>`Maximum amount of CPU time, in milliseconds, that a key-value pair extractor will be allowed to take before warning. If the extractor exceeds this execution time on any event a warning will be issued	1000 (1 second)

`[kvstore]`

Setting	Description	Default
`[kvstore]` `max_accelerations_per_collection`	`<unsigned integer>`The maximum number of accelerations that can be assigned to a single collection More Valid values range from 0 to 50	10
`[kvstore]` `max_documents_per_batch_save`	`<unsigned integer>`The maximum number of documents that can be saved in a single batch	1000
`[kvstore]` `max_documents_per_batch_export_backup_kvservice`	`<unsigned integer>`The maximum number of documents that can be exported from kvservice in a single batch during backup.	50000
`[kvstore]` `max_size_per_batch_export_backup_kvservice_mb`	`<unsigned integer>`The maximum size, in megabytes (MB), that can be exported from kvservice in a single batch during backup.	50
`[kvstore]` `max_fields_per_acceleration`	`<unsigned integer>`The maximum number of fields that can be part of a compound acceleration (i.e. an acceleration with multiple keys) More Valid values range from 0 to 50	10
`[kvstore]` `max_queries_per_batch`	`<unsigned integer>`The maximum number of queries that can be run in a single batch	1000
`[kvstore]` `max_rows_in_memory_per_dump`	`<unsigned integer>`The maximum number of rows in memory before flushing it to the CSV projection of KVStore collection.	200
`[kvstore]` `max_rows_per_query`	`<unsigned integer>`The maximum number of rows that will be returned for a single query to a collection. More If the query returns more rows than the specified value, then returned result set will contain the number of rows specified in this value.	50000
`[kvstore]` `max_size_per_batch_result_mb`	`<unsigned integer>`The maximum size, in megabytes (MB), of the result set from a set of batched queries	100
`[kvstore]` `max_size_per_batch_save_mb`	`<unsigned integer>`The maximum size, in megabytes (MB), of a batch save query.	50
`[kvstore]` `max_size_per_result_mb`	`<unsigned integer>`The maximum size, in megabytes (MB), of the result that will be returned for a single query to a collection.	50
`[kvstore]` `max_threads_per_outputlookup`	`<unsigned integer>`The maximum number of threads to use during outputlookup commands on KVStore More If the value is 0 the thread count will be determined by CPU count	1
`[kvstore]` `indexedcsv_failure_cleanup`	`<boolean>`Determines whether Splunk software resolves inconsistencies in states when CSV lookup files fail to be indexed. More NOTE: Do not change this setting unless instructed to do so by Splunk Support.	false
`[kvstore]` `max_documents_per_conditional_update`	`<unsigned integer>`Determines how many documents you can modify per conditional update request. More If you configure this setting to a value less than 1, the software sets it to 1. If you configure this setting to a value greater than 100, the software sets it to 100.	10

`[kvstore_migration]`

Setting	Description	Default
`[kvstore_migration]` `periodic_timer_interval`	`<integer>`The interval, in seconds, at which a search head cluster member polls the status of a KV Store migration or upgrade after the start of that migration or upgrade. More The minimum accepted value is 1. The maximum accepted value is 60.	10
`[kvstore_migration]` `max_failed_status_unchanged_count`	`<integer>`The maximum number of intervals, as determined by the 'periodic_timer_interval' setting, that a search head cluster member's status can remain in a failed state during a KV Store migration or upgrade before the member retries that migration or upgrade. If the number of intervals has been exceeded, then the member is marked as aborted. More Once this limit is reached, the member aborts the migration or upgrade.	30
`[kvstore_migration]` `version_upgrade_max_start_retries`	`<unsigned integer>`This is an internal setting. More NOTE: Do not change this setting unless instructed to do so by Splunk Support.	10
`[kvstore_migration]` `version_upgrade_max_retries`	`<unsigned integer>`This is an internal setting. More NOTE: Do not change this setting unless instructed to do so by Splunk Support.	4
`[kvstore_migration]` `version_upgrade_max_command_time_ms`	`<unsigned integer>`This is an internal setting. More NOTE: Do not change this setting unless instructed to do so by Splunk Support.	60000
`[kvstore_migration]` `version_upgrade_time_duration_block_s`	`<unsigned integer>`This is an internal setting. More NOTE: Do not change this setting unless instructed to do so by Splunk Support.	1
`[kvstore_migration]` `version_upgrade_polling_max_wait_ms`	`<unsigned integer>`This is an internal setting. More NOTE: Do not change this setting unless instructed to do so by Splunk Support.	26460000
`[kvstore_migration]` `version_upgrade_polling_version_max_wait_ms`	`<unsigned integer>`This is an internal setting. More NOTE: Do not change this setting unless instructed to do so by Splunk Support.	4800000
`[kvstore_migration]` `version_upgrade_polling_interval_ms`	`<unsigned integer>`This is an internal setting. More NOTE: Do not change this setting unless instructed to do so by Splunk Support.	100
`[kvstore_migration]` `version_upgrade_terminate_timeout_s`	`<unsigned integer>`This is an internal setting. More NOTE: Do not change this setting unless instructed to do so by Splunk Support.	600
`[kvstore_migration]` `version_upgrade_backup_disabled`	`<boolean>`This is an internal setting. More NOTE: Do not change this setting unless instructed to do so by Splunk Support. This setting turns off the creation of a KV store backup before an upgrade. If set to "true" and there's a failure, you can't roll back to a previous back up.	false
`[kvstore_migration]` `version_upgrade_keep_backups`	`<boolean>`This is an internal setting. More NOTE: Do not change this setting unless instructed to do so by Splunk Support. After successfully upgrading the KV store, does not clean up the backup that was created on the local disk in $SPLUNK_DB/kvstore/mongo_backup.	true

`[input_channels]`

Setting	Description	Default
`[input_channels]` `max_inactive`	`<integer>`The Maximum number of inactive input channel configurations to keep in cache. More Each source/sourcetype/host combination requires an independent input channel, which contains all relevant settings for ingestion. When set to 'auto', the Splunk platform will tune this setting based on the physical RAM present in the server at startup. Increasing this number might help with low ingestion throughput when there are no blocked queues (i.e., no 'blocked=true' events for 'group=queue' in metrics.log), and splunkd is creating a very high number of new input channels (see the value of 'new_channels' in 'group=map, name=pipelineinputchannel', also in metrics.log), usually in the order of thousands. However, this action is only effective when those input channels could have been reused: for example, the source, sourcetype, and host fields are not generated randomly and tend to be reused within the lifetime of cached channel entries.	auto
`[input_channels]` `lowater_inactive`	`<integer>`Size of the inactive input channel cache after which entries will be considered for recycling: having its memory reused for storing settings for a different input channel. More When set to 'auto', the Splunk platform will tune this setting value based on the value of 'max_inactive'.	auto
`[input_channels]` `inactive_eligibility_age_seconds`	`<integer>`Time, in seconds, after which an inactive input channel will be removed from the cache to free up memory.	330
`[input_channels]` `disable_inactive_channels`	`<boolean>`Whether or not splunkd disables the inactive input channel cache. More A value of "true" means splunkd disables the inactive input channel cache and maintains the active input channel cache. Turning off the inactive input channel cache provides the best ingestion performance. A value of "false" means splunkd enables the inactive input channel cache.	true
`[input_channels]` `active_eligibility_age`	`<integer>`The time, in seconds, after which splunkd removes an idle input channel from the active channel cache to free up memory.	330

`[ldap]`

Setting	Description	Default
`[ldap]` `allow_multiple_matching_users`	`<boolean>`Whether or not Splunk Enterprise allows login when it finds multiple entries in LDAP with the same value for the 'username' attribute. More When multiple entries are found, it chooses the first Distinguished Name (DN) lexicographically. Setting this to false is more secure as it does not allow any ambiguous login, but users with duplicate entries will be unable to login.	true
`[ldap]` `max_users_to_precache`	`<unsigned integer>`The maximum number of users that are pre-cached from LDAP after reloading auth. More Set this to 0 to turn off pre-caching.

`[metrics]`

Setting	Description	Default
`[metrics]` `interval`	`<integer>`Number of seconds between logging splunkd metrics to metrics.log. More Minimum of 10.	60 (Splunk Enterprise); 60 (Splunk Universal Forwarder)
`[metrics]` `maxseries`	`<integer>`The number of series to include in the per_x_thruput reports in metrics.log.	10

`[metrics:tcpin_connections]`

Setting	Description	Default
`[metrics:tcpin_connections]` `aggregate_metrics`	`<boolean>`For each splunktcp connection from forwarder, splunk logs metrics information every metrics interval. More When there are large number of forwarders connected to indexer, the amount of information logged can take lot of space in metrics.log. When set to true, it will aggregate information across each connection and report only once per metrics interval.	false
`[metrics:tcpin_connections]` `suppress_derived_info`	`<boolean>`For each forwarder connection, _tcp_Bps, _tcp_KBps, _tcp_avg_thruput, _tcp_Kprocessed is logged in metrics.log. More This can be derived from kb. When set to true, the above derived info will not be emitted.	false
`[metrics:tcpin_connections]` `idle_connections_log_frequency`	`<integer>`For each splunktcp connection from forwarder, splunk logs metrics information every metrics interval "[metrics]->interval". There may be large number of idle connections. Idle connection received zero bytes during last "[metrics]->interval"*idle_connections_log_frequency seconds. More Setting to skip logging idle connection metrics to metrics.log. A value of 1 means always log idle connection metrics to metrics.log.	1

`[pdf]`

Setting	Description	Default
`[pdf]` `max_rows_per_table`	`<unsigned integer>`The maximum number of rows that will be rendered for a table within integrated PDF rendering.	1000
`[pdf]` `render_endpoint_timeout`	`<unsigned integer>`The number of seconds after which the pdfgen render endpoint will timeout if it has not yet finished rendering the PDF output.	3600 (60 minutes)
`[pdf]` `render_chromium_timeout`	`<unsigned integer>`The number of seconds after which the Chromium engine will timeout if the engine still needs to render the dashboard output. This setting does not impact the render_chromium_screenshot_delay.	30
`[pdf]` `render_chromium_screenshot_delay`	`<unsigned integer>`The number of seconds after which the Chromium engine takes a screenshot of a dashboard to render before exporting the dashboard. This setting does not impact the render_chromium_timeout setting.	0
`[pdf]` `export_max_file_size`	`<positive integer>`The maximum file size allowed, in megabytes, for Dashboard Studio scheduled exports. More Set this value to half of the maximum attachment size of your mail server minus about 1MB, because PNG scheduled exports are attached twice inside of emails. An extra 1MB leaves room for metadata produced during export. If an export exceeds this max file size, Dashboard Studio retries the export at lower resolutions until it creates an export within this limit.	8
`[pdf]` `export_max_scale_factor`	`<positive integer>`The maximum scale factor the exporter can apply to Dashboard Studio scheduled exports. More A value of 1 means no scaling. The maximum allowed value is 10. Higher values permit higher-resolution dashboard exports, which impact the export file size, export time, and memory usage.	4

`[realtime]`

Setting	Description	Default
`[realtime]` `alerting_period_ms`	`<integer>`The time, in milliseconds, to wait between triggering alerts during a realtime search. More This setting limits the frequency at which alerts are triggered during realtime search. A value of 0 means that alerts are triggered for every batch of events that are read. In dense realtime searches with expensive alerts, this can overwhelm the alerting system. Precedence: Searchhead	0
`[realtime]` `blocking`	`<boolean>`Whether or not the indexer should block if a queue is full.	false
`[realtime]` `default_backfill`	`<boolean>`Whether or not windowed real-time searches should backfill events.	true
`[realtime]` `enforce_time_order`	`<boolean>`Whether or not real-time searches should ensure that events are sorted in ascending time order. More Splunk Web automatically reverses the order that it displays events for real-time searches. If set to "true", the latest events will be shown first.	true
`[realtime]` `indexfilter`	`<boolean>`Whether or not the indexer should pre-filter events for efficiency.	1 (true)
`[realtime]` `indexed_realtime_update_interval`	`<integer>`When you run an indexed realtime search, the list of searchable buckets needs to be updated. If the Splunk software is installed on a cluster, the list of allowed primary buckets is refreshed. If not installed on a cluster, the list of buckets, including any new hot buckets are refreshed. This setting controls the interval for the refresh. The setting must be less than the "indexed_realtime_disk_sync_delay" setting. If your realtime buckets transition from new to warm in less time than the value specified for the "indexed_realtime_update_interval" setting, data will be skipped by the realtime search in a clustered environment. More Precedence: Indexers	30
`[realtime]` `indexed_realtime_cluster_update_interval`	`<integer>`This setting is deprecated. Use the "indexed_realtime_update_interval" setting instead. More While running an indexed realtime search on a cluster, the list of allowed primary buckets is updated. This controls the interval at which the list is updated. This value must be less than the 'indexed_realtime_disk_sync_delay' setting. If your buckets transition from Brand New to warm in less than the interval time specified, indexed realtime will lose data in a clustered environment. Precedence: Indexers	30
`[realtime]` `indexed_realtime_default_span`	`<integer>`An indexed realtime search is made up of many component historical searches that by default will span this many seconds. If a component search is not completed in this many seconds the next historical search will span the extra seconds. To reduce the overhead of running an indexed realtime search you can change this span to delay longer before starting the next component historical search. More Precedence: Indexers	1
`[realtime]` `indexed_realtime_disk_sync_delay`	`<integer>`The number of seconds to wait for disk flushes to finish when using indexed/continuous/pseudo realtime search, so that all data can be seen. More After indexing there is a non-deterministic period where the files on disk, when opened by other programs, might not reflect the latest flush to disk, particularly when a system is under heavy load. Precedence: SearchHead overrides Indexers	60
`[realtime]` `indexed_realtime_maximum_span`	`<integer>`While running an indexed realtime search, if the component searches regularly take longer than 'indexed_realtime_default_span' seconds, then indexed realtime search can fall more than 'indexed_realtime_disk_sync_delay' seconds behind realtime. More Use this setting to set a limit after which search drops data to catch back up to the specified delay from realtime, and only search the default span of seconds. Precedence: API overrides SearchHead overrides Indexers	0 (unlimited)
`[realtime]` `indexed_realtime_use_by_default`	`<boolean>`Whether or not the indexedRealtime mode should be used by default. More Precedence: SearchHead This is an app/user level configuration setting, and cannot be set as global.	false
`[realtime]` `local_connect_timeout`	`<integer>`Connection timeout, in seconds, for an indexer's search process when connecting to that indexer's splunkd.	5
`[realtime]` `local_receive_timeout`	`<integer>`Receive timeout, in seconds, for an indexer's search process when connecting to that indexer's splunkd.	5
`[realtime]` `local_send_timeout`	`<integer>`Send timeout, in seconds, for an indexer's search process when connecting to that indexer's splunkd.	5
`[realtime]` `max_blocking_secs`	`<integer>`Maximum time, in seconds, to block if the queue is full (meaningless if blocking = false) More 0 means no limit	60
`[realtime]` `queue_size`	`<integer>`Size of queue for each real-time search (must be >0).	10000

`[restapi]`

Setting	Description	Default
`[restapi]` `maxresultrows`	`<integer>`Maximum result rows to be returned by /events or /results getters from REST API.	50000
`[restapi]` `jobscontentmaxcount`	`<integer>`Maximum length of a property in the contents dictionary of an entry from /jobs getter from REST API More Value of 0 disables truncation	0
`[restapi]` `time_format_reject`	`<regular expression>`HTTP arguments for time_format and output_time_format that match this regex will be rejected. More The regex will be satisfied by a substring match anywhere in the argument. Intended as defense-in-depth against XSS style attacks against browser users by crafting specially encoded URLS for them to access splunkd. If unset, all argument strings are accepted. To disable this check entirely, set the value to empty. Example of disabling: time_format_reject =	[<>!] , which means that the less-than '<', greater-than '>', and exclamation point '!' are not allowed.
`[restapi]` `restprocessor_errors_fatal`	`<boolean>`Determines whether to return a hard error for REST command usages that are invalid. More An invalid REST command usage is a REST request that returns an HTTP status outside the range of [200, 300].	false
`[restapi]` `max_persistent_connections`	`<integer>`The maximum number of persistent processes that EAI custom REST handlers can create to serve REST API calls in persistent mode. More A value of "0" means that there is no limit to the number of processes that the handlers can create.	3000

`[reversedns]`

Setting	Description	Default
`[reversedns]` `rdnsMaxDutyCycle`	`<integer>`Generate diagnostic WARN in splunkd.log if reverse dns lookups are taking more than this percent of time More Range 0-100	10

`[sample]`

Setting	Description	Default
`[sample]` `maxsamples`	`<integer>`No description in the spec.	10000
`[sample]` `maxtotalsamples`	`<integer>`No description in the spec.	100000

`[scheduler]`

Setting	Description	Default
`[scheduler]` `action_execution_threads`	`<integer>`Number of threads to use to execute alert actions, change this number if your alert actions take a long time to execute. More This number is capped at 100.	10
`[scheduler]` `actions_queue_size`	`<integer>`The number of alert notifications to queue before the scheduler starts blocking, set to 0 for infinite size.	500
`[scheduler]` `actions_queue_timeout`	`<integer>`The maximum amount of time, in seconds, to block when the action queue size is full.	30
`[scheduler]` `alerts_expire_period`	`<integer>`The amount of time, in seconds, between expired alert removal More This period controls how frequently the alerts list is scanned, the only benefit from reducing this is better resolution in the number of alerts fired at the savedsearch level. Change not recommended.	120
`[scheduler]` `alerts_max_count`	`<integer>`Maximum number of unexpired alerts information to keep for the alerts manager, when this number is reached Splunk will start discarding the oldest alerts.	50000
`[scheduler]` `alerts_max_history`	`<integer>[s\|m\|h\|d]`Maximum time to search in the past for previously triggered alerts. More splunkd uses this property to populate the Activity -> Triggered Alerts page at startup. Values greater than the default may cause slowdown. Relevant units are: s, sec, second, secs, seconds, m, min, minute, mins, minutes, h, hr, hour, hrs, hours, d, day, days.	7d
`[scheduler]` `alerts_scoping`	`host\|splunk_server\|all`Determines the scoping to use on the search to populate the triggered alerts page. Choosing splunk_server will result in the search query using splunk_server=local, host will result in the search query using host=<search-head-host-name>, and all will have no scoping added to the search query.	splunk_server
`[scheduler]` `async_saved_search_fetch`	`<boolean>`Enables a separate thread that will fetch scheduled or auto-summarized saved searches asynchronously. More Do not change this setting unless instructed to do so by Splunk support.	true
`[scheduler]` `async_saved_search_interval`	`<integer>`The interval, in seconds, that scheduled or auto-summarized saved searches will be fetched asynchronously. More Has no effect if async_saved_search_fetch is set to false.	30
`[scheduler]` `async_admission_eval_interval`	`<integer>`The interval, in seconds, that scheduled saved searches will be evaluated for admission rules asynchronously. More Has no effect if async_saved_search_fetch is set to false. If async_saved_search_fetch is false, admission rule evaluation for saved searches is done on the scheduler thread.	600
`[scheduler]` `scheduler_user_timezone_cache_expiry`	`<integer>[s\|m\|h\|d]`The amount of time that the scheduler caches the timezones that are associated with the scheduled searches. More Use this setting to decrease scheduler cycle time by letting the scheduler use cached timezones instead of fetching them from the configuration cache. A value of 0 turns off timezone caching. Specify the interval as a string with minutes, seconds, hours, or days. For example: 60s, 1m, 1h, 1d, etc.	150m
`[scheduler]` `suppression_cleanup_interval`	`<positive integer>`The interval, in seconds, at which the suppression cleanup background thread processes queued suppression deletions. More Minimum value: 1. Maximum value: 300. If you configure this setting to a value less than 1, the software sets it to 1. If you configure this setting to a value greater than 300, the software sets it to 300. NOTE: Do not change this setting unless instructed to do so by Splunk Support.	5
`[scheduler]` `auto_summary_perc`	`<integer>`The maximum number of concurrent searches to be allocated for auto summarization, as a percentage of the concurrent searches that the scheduler can run. More Auto summary searches include: Searches which generate the data for the Report Acceleration feature. Searches which generate the data for Data Model acceleration. NOTE: user scheduled searches take precedence over auto summary searches.	50
`[scheduler]` `auto_summary_perc.<n>`	`<integer>`The same as auto_summary_perc but the value is applied only when the cron string matches the current time. This allows 'auto_summary_perc' to have different values at different times of day, week, month, etc. More There may be any number of non-negative <n> that progress from least specific to most specific with increasing <n>. The scheduler looks in reverse-<n> order looking for the first match. If either these settings aren't provided at all or no "when" matches the current time, the value falls back to the non-<n> value of 'auto_summary_perc'.
`[scheduler]` `auto_summary_perc.<n>.when`	`<cron string>`The same as auto_summary_perc but the value is applied only when the cron string matches the current time. This allows 'auto_summary_perc' to have different values at different times of day, week, month, etc. More There may be any number of non-negative <n> that progress from least specific to most specific with increasing <n>. The scheduler looks in reverse-<n> order looking for the first match. If either these settings aren't provided at all or no "when" matches the current time, the value falls back to the non-<n> value of 'auto_summary_perc'.
`[scheduler]` `concurrency_message_throttle_time`	`<integer>[s\|m\|h\|d]`Amount of time controlling throttling between messages warning about scheduler concurrency limits. More Relevant units are: s, sec, second, secs, seconds, m, min, minute, mins, minutes, h, hr, hour, hrs, hours, d, day, days.	10m
`[scheduler]` `dispatch_mode`	`push \| pull`Specifies the search job dispatching mode. More There are currently two supported modes: 'push' or 'pull'. The 'push' mode means the captain pushes the search jobs to search head cluster members. The 'pull' mode means the search head cluster members pull the search jobs from the captain.	'push'
`[scheduler]` `allow_skew_hash_algorithm`	`djb2 \| xxh32`The hash algorithm used for deterministic scheduler allow_skew placement. More NOTE: Do not change this setting unless instructed to do so by Splunk Support.	djb2
`[scheduler]` `introspection_lookback`	`<duration-specifier>`The amount of time to "look back" when reporting introspection statistics. More For example: what is the number of dispatched searches in the last 60 minutes? Use [<integer>]<unit> to specify a duration; a missing <integer> defaults to 1. Relevant units are: m, min, minute, mins, minutes, h, hr, hour, hrs, hours, d, day, days, w, week, weeks. For example: "5m" = 5 minutes, "1h" = 1 hour.	1h
`[scheduler]` `max_action_results`	`<integer>`The maximum number of results to load when triggering an alert action.	50000
`[scheduler]` `max_continuous_scheduled_search_lookback`	`<duration-specifier>`The maximum amount of time to run missed continuous scheduled searches for once Splunk Enterprise comes back up, in the event it was down. More Use [<integer>]<unit> to specify a duration; a missing <integer> defaults to 1. Relevant units are: m, min, minute, mins, minutes, h, hr, hour, hrs, hours, d, day, days, w, week, weeks, mon, month, months. For example: "5m" = 5 minutes, "1h" = 1 hour. A value of 0 means no lookback.	24h
`[scheduler]` `max_lock_files`	`<integer>`The number of most recent lock files to keep around. More This setting only applies in search head pooling.
`[scheduler]` `max_lock_file_ttl`	`<integer>`Time, in seconds, that must pass before reaping a stale lock file. More Only applies in search head pooling.
`[scheduler]` `max_per_result_alerts`	`<integer>`Maximum number of alerts to trigger for each saved search instance (or real-time results preview for RT alerts) More Only applies in non-digest mode alerting. Use 0 to disable this limit	500
`[scheduler]` `max_per_result_alerts_time`	`<integer>`Maximum amount of time, in seconds, to spend triggering alerts for each saved search instance (or real-time results preview for RT alerts) More Only applies in non-digest mode alerting. Use 0 to disable this limit.	300 (5 minutes)
`[scheduler]` `max_searches_perc`	`<integer>`The maximum number of searches the scheduler can run, as a percentage of the maximum number of concurrent searches, see [search] max_searches_per_cpu for how to set the system wide maximum number of searches.	50
`[scheduler]` `max_searches_perc.<n>`	`<integer>`The same as max_searches_perc but the value is applied only when the cron string matches the current time. This allows 'max_searches_perc' to have different values at different times of day, week, month, etc. More There may be any number of non-negative <n> that progress from least specific to most specific with increasing <n>. The scheduler looks in reverse-<n> order looking for the first match. If either these settings aren't provided at all or no "when" matches the current time, the value falls back to the non-<n> value of 'max_searches_perc'.
`[scheduler]` `max_searches_perc.<n>.when`	`<cron string>`The same as max_searches_perc but the value is applied only when the cron string matches the current time. This allows 'max_searches_perc' to have different values at different times of day, week, month, etc. More There may be any number of non-negative <n> that progress from least specific to most specific with increasing <n>. The scheduler looks in reverse-<n> order looking for the first match. If either these settings aren't provided at all or no "when" matches the current time, the value falls back to the non-<n> value of 'max_searches_perc'.
`[scheduler]` `max_pull_based_fetch`	`<integer>`The maximum number of searches a SHC member can pull in a single fetch request to the captain. More 0 means the limit will be based on the maximum available scheduled searches the member can currently run.	0
`[scheduler]` `dynamic_max_searches_perc`	`<boolean>`Whether or not the search scheduler can dynamically adjust the maximum percentage of searches that it can run, based on ad-hoc and scheduled search workload. More When this feature is turned on, the percentage of search concurrency allotted to the scheduler, 'max_searches_perc', will gradually increase when the number of concurrent ad-hoc searches is low. When ad-hoc searches are at risk of queueing due to lack of search concurrency, 'max_searches_perc' will dynamically scale down to reserve search concurrency for ad-hoc searches. A value of "true" means that the search scheduler dynamically adjusts the maximum percentage of scheduled searches that it can run. A value of "false" means that the schedule does not dynamically adjust the maximum percentage of scheduled searches that it can run.	false
`[scheduler]` `dynamic_max_searches_perc_upper_limit`	`<integer>`The maximum possible percentage of total search concurrency that can be allocated to scheduled searches. More When 'dynamic_max_searches_perc' has a value of "true", this is the upper bound that 'max_searches_perc' can reach. This setting only applies when 'dynamic_max_searches_perc' has a value of "true". If the value for this setting is less than 'max_searches_perc', then 'max_searches_perc' becomes the upper limit.	0
`[scheduler]` `dynamic_max_searches_perc_increase_period`	`<integer>`The amount of time, in seconds, that the search scheduler must observe a steady state before it may dynamically increase 'max_searches_perc'. More A "steady state" is a continuous period of time where the following conditions are true: There is an absence of ad-hoc searches in the search queue due to the instance-wide search concurrency limit. The percentage of ad-hoc search concurrency does not exceed 100 minus the current value for 'max_searches_perc'. For example, if 'max_searches_perc' is currently 50, the percentage of ad-hoc search concurrency cannot be more than 50 for this condition to remain true. The "steady state" begins when all of these conditions are true, and ends the moment any of the conditions is not true. This setting only applies when 'dynamic_max_searches_perc' has a value of "true".	300
`[scheduler]` `dynamic_max_searches_perc_increase_increment`	`<integer>`The amount by which the scheduler can increase 'max_searches_perc' during a dynamic adjustment of maximum search percentage. More This setting only applies when 'dynamic_max_searches_perc' has a value of "true".	5
`[scheduler]` `persistence_period`	`<integer>`The period, in seconds, between scheduler state persistence to disk. The scheduler currently persists the suppression and fired-unexpired alerts to disk. More This is relevant only in search head pooling mode.	30
`[scheduler]` `persistance_period`	`<integer>`DEPRECATED: Use the 'persistence_period' setting instead.
`[scheduler]` `priority_runtime_factor`	`<double>`The amount to scale the priority runtime adjustment by. More Every search's priority is made higher (worse) by its typical running time. Since many searches run in fractions of a second and the priority is integral, adjusting by a raw runtime wouldn't change the result; therefore, it's scaled by this value.	10
`[scheduler]` `priority_skipped_factor`	`<double>`The amount to scale the skipped adjustment by. More A potential issue with the priority_runtime_factor is that now longer-running searches may get starved. To balance this out, make a search's priority lower (better) the more times it's been skipped. Eventually, this adjustment will outweigh any worse priority due to a long runtime. This value controls how quickly this happens.	1
`[scheduler]` `dispatch_retry_delay`	`<unsigned integer>`The amount of time, in seconds, to delay retrying a scheduled search that failed to dispatch (usually due to hitting concurrency limits). More Maximum value: 30	0
`[scheduler]` `saved_searches_disabled`	`<boolean>`Whether saved search jobs are disabled by the scheduler.	false
`[scheduler]` `durable_search_disabled`	`<boolean>`Specifies whether durable search functionality is disabled for all saved search jobs. More When set to 'true', the Splunk software ignores the durable search settings of all saved search configurations. To disable durable search for an individual saved search, find its configuration in 'savedsearches.conf' and set its 'durable.track_time_type' setting to 'none'.	false
`[scheduler]` `scheduled_view_timeout`	`<integer>[s\|m\|h\|d]`The maximum amount of time that a scheduled view (pdf delivery) would be allowed to render More Relevant units are: s, sec, second, secs, seconds, m, min, minute, mins, minutes, h, hr, hour, hrs, hours, d, day, days.	60m
`[scheduler]` `shc_role_quota_enforcement`	`<boolean>`Controls whether the search head cluster captain enforces user-role quotas for scheduled searches globally (cluster-wide). More A value of "true" means the captain enforces quotas globally. A given role can have (n * number_of_members) searches running cluster-wide. 'n' is the quota for that role as defined by 'srchJobsQuota' and 'rtSrchJobsQuota' on the captain. 'number_of_members' is the count of members capable of running scheduled searches. When this setting is "true", scheduled searches do not have an enforcement of user role quota on a per-member basis. Role-based disk quota checks ('srchDiskQuota' in 'authorize.conf') are enforced only on a per-member basis. These checks are skipped when 'shc_role_quota_enforcement' is "true". Quota information travels from the members to the captain. Network delays can cause the quota calculation on the captain to vary from the actual values in the members and might cause search limit warnings. This discrepancy clears up as the information syncs. NOTE: When the 'shc_role_quota_base_only_enforcement' setting is enabled, the behavior of this setting changes such that role-based quotas are not multiplied by the size of the cluster.	false
`[scheduler]` `shc_role_quota_base_only_enforcement`	`<boolean>`Controls whether the 'shc_role_quota_enforcement' setting multiplies the user quota by the size of nodes in the search head cluster. More A value of "true" means that the user quota is not multiplied by the cluster size. Enable this setting only if the number of users causes search concurrency issues for all of your cluster members. A value of "false" means that the user quota is multiplied by the cluster size, as determined by the 'shc_role_quota_enforcement' setting. This setting has no effect if 'shc_role_quota_enforcement' is "false" or 'shc_adhoc_quota_enforcement' is "off".	false
`[scheduler]` `shc_syswide_quota_enforcement`	`<boolean>`When this is enabled, Maximum number of concurrent searches is enforced globally (cluster-wide) by the captain for scheduled searches. Concurrent searches include both scheduled searches and ad hoc searches. More This is (n * number_of_members) where n is the max concurrent searches per node (see max_searches_per_cpu for a description of how this is computed) and number_of_members include members capable of running scheduled searches. Scheduled searches will therefore not have an enforcement of instance-wide concurrent search quota on a per-member basis. Note that this does not control the enforcement of the scheduler quota. For a search head cluster, that is defined as (max_searches_perc * number_of_members) and is always enforced globally on the captain. Quota information is conveyed from the members to the captain. Network delays can cause the quota calculation on the captain to vary from the actual values in the members and may cause search limit warnings. This should clear up as the information is synced.	false
`[scheduler]` `shc_local_quota_check`	`<boolean>`DEPRECATED. Local (per-member) quota check is enforced by default. More To disable per-member quota checking, enable one of the cluster-wide quota checks (shc_role_quota_enforcement or shc_syswide_quota_enforcement). For example, setting 'shc_role_quota_enforcement=true' turns off local role quota enforcement for all nodes in the cluster and is enforced cluster-wide by the captain.
`[scheduler]` `shp_dispatch_to_slave`	`<boolean>`DEPRECATED; use shp_dispatch_to_member instead.
`[scheduler]` `shp_dispatch_to_member`	`<boolean>`By default the scheduler should distribute jobs throughout the pool.	true
`[scheduler]` `search_history_load_timeout`	`<duration-specifier>`The maximum amount of time to defer running continuous scheduled searches while waiting for the KV Store to come up in order to load historical data. This is used to prevent gaps in continuous scheduled searches when splunkd was down. More Use [<integer>]<unit> to specify a duration; a missing <integer> defaults to 1. Relevant units are: s, sec, second, secs, seconds, m, min, minute, mins, minutes. For example: "60s" = 60 seconds, "5m" = 5 minutes.	2m
`[scheduler]` `search_history_max_runtimes`	`<unsigned integer>`The number of runtimes kept for each search. More Used to calculate historical typical runtime during search prioritization.	10
`[scheduler]` `pull_interval`	`<double>`The amount of time, in seconds, between SHC members' requests to pull scheduled jobs from the SHC captain. More This setting is applicable when "dispatching_mode=pull". Value must be greater than 0 and less than or equal to 60.	.5
`[scheduler]` `pull_interval_throttle_limit`	`<unsigned integer>`Controls how many times a SHC member can check for the available search capacity before throttling occurs. More When a SHC member reaches its scheduled search capacity, this setting determines how many additional capacity checks will be allowed before the member temporarily pauses (throttles) requests to pull jobs from the captain. Once the throttle limit is reached, the SHC member will wait for the duration specified in the 'pull_interval_throttle_interval' setting before resuming capacity checks. This setting is only applicable when "dispatching_mode=pull". Valid values range from 0 to 500. Set to 0 to turn off throttling.	20
`[scheduler]` `pull_interval_throttle_interval`	`<double>`This setting is used in conjunction with 'pull_interval_throttle_limit'. Use this setting to specify the amount of time in seconds a SHC member should throttle before rechecking its scheduled search capacity to pull jobs from the SHC captain. More This setting is applicable when "dispatching_mode=pull" and the 'pull_interval_throttle_limit' setting is enabled. Value must be greater than 0 and less than or equal to 300	10
`[scheduler]` `shc_scheduler_sticky_jobs_expiry`	`<double>`The amount of time in seconds that pull-based scheduled searches with affinity to a particular SHC member can remain enqueued before they are retried or skipped. More This setting is applicable when "dispatching_mode=pull". The value must be greater than 0, and less than or equal to 300.	120
`[scheduler]` `dispatch_only_when_kvstore_ready`	`<boolean>`Whether or not KVStore must be ready on peers before the SHC captain dispatches search jobs. More A value of "true" means all searches are prevented from dispatching until KVStore is ready. A value of "false" means searches dispatch regardless of KVStore readiness. Use this setting only if most search jobs depend on KVStore. NOTE: Do not change this setting unless instructed to do so by Splunk Support.	false

`[search_metrics]`

Setting	Description	Default
`[search_metrics]` `debug_metrics`	`<boolean>`This indicates whether to output more detailed search metrics for debugging. More This will do things like break out where the time was spent by peer, and might add additional deeper levels of metrics. This is NOT related to "metrics.log" but to the "Execution Costs" and "Performance" fields in the Search inspector, or the count_map in the info.csv file.	false

`[show_source]`

Setting	Description	Default
`[show_source]` `distributed`	`<boolean>`Whether or not a distributed search is performed to get events from all servers and indexes. More Turning this off results in better performance for show source, but events will only come from the initial server and index.	true
`[show_source]` `distributed_search_limit`	`<unsigned integer>`The maximum number of events that are requested when performing a search for distributed show source. More As this is used for a larger search than the initial non-distributed show source, it is larger than max_count Splunk software rarely returns anywhere near this number of results, as excess results are pruned. The point is to ensure the distributed search captures the target event in an environment with many events.	30000
`[show_source]` `max_count`	`<integer>`Maximum number of events accessible by show_source. More The show source command will fail when more than this many events are in the same second as the requested event.	10000
`[show_source]` `max_timeafter`	`<timespan>`Maximum time after requested event to show.	'1day' (86400 seconds)
`[show_source]` `max_timebefore`	`<timespan>`Maximum time before requested event to show.	'1day' (86400 seconds)

`[rex]`

Setting	Description	Default
`[rex]` `match_limit`	`<integer>`Limits the amount of resources that are spent by PCRE when running patterns that will not match. More Use this to set an upper bound on how many times PCRE calls an internal function, match(). If set too low, PCRE might fail to correctly match a pattern.	100000
`[rex]` `depth_limit`	`<integer>`Limits the amount of resources that are spent by PCRE when running patterns that will not match. More Use this to limit the depth of nested backtracking in an internal PCRE function, match(). If set too low, PCRE might fail to correctly match a pattern.	1000

`[slc]`

Setting	Description	Default
`[slc]` `maxclusters`	`<integer>`Maximum number of clusters to create.	10000.

`[slow_peer_disconnect]`

Setting	Description	Default
`[slow_peer_disconnect]` `batch_search_activation_fraction`	`<decimal>`The fraction of peers that must have completed before disconnection begins. More This is only applicable to batch search because the slow peers will not hold back the fast peers.	0.9
`[slow_peer_disconnect]` `bound_on_disconnect_threshold_as_fraction_of_mean`	`<decimal>`The maximum value of the threshold data rate that is used to determine if a peer is slow. More The actual threshold is computed dynamically at search time but never exceeds (100*maximum_threshold_as_fraction_of_mean)% on either side of the mean.	0.2
`[slow_peer_disconnect]` `disabled`	`<boolean>`Whether or not this feature is enabled.	true
`[slow_peer_disconnect]` `grace_period_before_disconnect`	`<decimal>`How long, in seconds, when multiplied by life_time_of_collector, to wait while the heuristic claims that a peer is slow, before disconnecting the peer. More If the heuristic consistently claims that the peer is slow for at least <grace_period_before_disconnect>*life_time_of_collector seconds, then the peer is disconnected.	0.1
`[slow_peer_disconnect]` `packets_per_data_point`	`<unsigned integer>`Rate statistics will be sampled once every packets_per_data_point packets.	500
`[slow_peer_disconnect]` `sensitivity`	`<decimal>`Sensitivity of the heuristic to newer values. For larger values of sensitivity the heuristic will give more weight to newer statistic.	0.3
`[slow_peer_disconnect]` `threshold_connection_life_time`	`<unsigned integer>`All peers will be given an initial grace period of at least these many seconds before they are considered in the heuristic.	5
`[slow_peer_disconnect]` `threshold_data_volume`	`<unsigned integer>`The volume of uncompressed data that must have accumulated, in kilobytes (KB), from a peer before it is considered in the heuristic.	1024

`[summarize]`

Setting	Description	Default
`[summarize]` `bucket_refresh_interval`	`<integer>`When poll_buckets_until_maxtime is enabled in a non-clustered environment, this is the minimum amount of time (in seconds) between bucket refreshes.	30
`[summarize]` `bucket_refresh_interval_cluster`	`<integer>`When poll_buckets_until_maxtime is enabled in a clustered environment, this is the minimum amount of time (in seconds) between bucket refreshes.	120
`[summarize]` `hot_bucket_min_new_events`	`<integer>`The minimum number of new events that need to be added to the hot bucket (since last summarization) before a new summarization can take place. To disable hot bucket summarization set this value to a * large positive number.	100000
`[summarize]` `indextime_lag`	`<unsigned integer>`The amount of lag time, in seconds, to give indexing to ensure that it has synced any received events to disk. More Effectively, the data that has been received in the past 'indextime_lag' seconds is NOT summarized. NOTE: Do not change this setting unless instructed to do so by Splunk Support.	90
`[summarize]` `max_hot_bucket_summarization_idle_time`	`<unsigned integer>`Maximum amount of time, in seconds, a hot bucket can be idle. When the time exceeds the maximum, all of the events are summarized even if there are not enough events (determined by the hot_bucket_min_new_events attribute).	900 (15 minutes)
`[summarize]` `max_replicated_hot_bucket_idle_time`	`<unsigned integer>`The maximum amount of time, in seconds, that a replicated hot bucket can remain idle before 'indextime_lag' is no longer applied to it. More This applies only to idle replicated hot buckets. When new events arrive, the default behavior of applying 'indextime_lag' resumes.	150
`[summarize]` `max_summary_ratio`	`<decimal>`A number in the [0-1] range that indicates the maximum ratio of summary data / bucket size at which point the summarization of that bucket, for the particular search, will be disabled. More Set to 0 to disable.	0
`[summarize]` `max_summary_size`	`<integer>`Size of summary, in bytes, at which point we'll start applying the max_summary_ratio. More Set to 0 to disable.	0
`[summarize]` `max_time`	`<integer>`The maximum amount of time, seconds, that a summary search process is allowed to run. More Set to 0 to disable.	0
`[summarize]` `poll_buckets_until_maxtime`	`<boolean>`Only modify this setting when you are directed to do so by Support. More Use the datamodels.conf setting 'acceleration.poll_buckets_until_maxtime' for individual data models that are sensitive to summarization latency delays.	false
`[summarize]` `auto_finalize_secs_after_maxtime`	`<integer>`The maximum amount of time, in seconds, that a summary search process is allowed to run after having exceeded max_time before it is auto-finalized. More The Splunk software auto-finalizes searches after a period of time that is the combination of this setting with the 'acceleration.max_time' setting. For example, if you set 'acceleration.max_time' to 3600 and you set 'auto_finalize_secs_after_maxtime' to 300, the Splunk software finalizes the search after 3900 seconds. An 'acceleration.max_time' setting of "0" indicates that there is no time limit for a summary search and causes the Splunk software to ignore the 'auto_finalize_secs_after_maxtime' setting.	300
`[summarize]` `disable_local_dma_search`	`<boolean>`Controls whether to turn off local data model acceleration (DMA) search execution when the search head has no meaningful local data. More When turned on, data model summarization searches run only on remote indexers instead of the local search head, which avoids unnecessary computation and reduces the risk of out-of-memory (OOM) errors that can occur when large DMA creation searches are run against empty local buckets. This optimization is most useful for Splunk Cloud Platform deployments and large Splunk Enterprise installations where search heads forward all data to dedicated indexer tiers. In single-instance deployments (where the search head is also the indexer), this optimization is automatically disabled regardless of this setting, ensuring local data is properly searched. Turn this setting off if you need to run DMA locally for troubleshooting purposes.	false
`[summarize]` `sleep_seconds`	`<integer>`The amount of time, in seconds, to sleep between polling the summarization complete status.	5
`[summarize]` `sleep_rebuild_deletion_seconds`	`<integer>`The maximum amount of time, in seconds, for Splunk software to wait for data model acceleration summary deletion to occur during an automatic summary rebuild. When this interval is reached the summary rebuild process moves on to the next bucket. More NOTE: Do not change this setting unless instructed to do so by Splunk Support.	5
`[summarize]` `stale_lock_seconds`	`<integer>`The amount of time, in seconds, to have elapse since the mod time of a .lock file before summarization considers * that lock file stale and removes it.	600
`[summarize]` `tscollect_queue_size`	`<unsigned integer>`This setting sets the size (in bytes) of the internal producer-consumer queue. Accelerated data model summary creation searches use this queue to speed up the summarization task. More Setting this to a non-zero value reduces the memory usage of the data model acceleration search process while accelerating large buckets of events. A value of 0 represents no bound on the queue size. CAUTION: Do not change this setting without consulting Splunk Support. Changing it may slow down the accelerated data model summary creation search.	0
`[summarize]` `results_deduplication`	`<boolean>`NOTE: Do not change this setting unless instructed to do so by Splunk Support. More This is an internal setting used by the summarize processor to deduplicate intermediate results. If set to "true", memory usage might increase on the search head.	false

`[system_checks]`

Setting	Description	Default
`[system_checks]` `insufficient_search_capabilities`	`enabled \| disabled`Enables/disables automatic daily logging of scheduled searches by users who have insufficient capabilities to run them as configured. More Such searches are those that: + Have schedule_priority set to a value other than "default" but the owner does not have the edit_search_schedule_priority capability. + Have schedule_window set to a value other than "auto" but the owner does not have the edit_search_schedule_window capability. This check and any resulting logging occur on system startup and every 24 hours thereafter.	enabled
`[system_checks]` `installed_files_integrity`	`enabled \| log_only \| disabled`Enables/disables automatic verification on every startup that all the files that were installed with the running Splunk version are still the files that should be present. More Effectively this finds cases where files were removed or changed that should not be removed or changed, whether by accident or intent. The source of truth for the files that should be present is the manifest file in the $SPLUNK_HOME directory that comes with the release, so if this file is removed or altered, the check cannot work correctly. Reading of all the files provided with the install has some I/O cost, though it is paid out over many seconds and should not be severe. When "enabled", detected problems will cause a message to be posted to the bulletin board (system UI status message). When "enabled" or "log_only", detected problems will cause details to be written out to the splunkd.log file. When "disabled", no check will be attempted or reported.	enabled
`[system_checks]` `installed_files_integrity_interval`	`<interval>`The amount of time between each installed file integrity check. More Has no effect if 'installed_files_integrity' is disabled. Specify the interval as a string with minutes, seconds, hours, days. For example: 60s, 1m, 1h, 1d, etc.	12h
`[system_checks]` `installed_files_anomalous_integrity_interval`	`<interval>`The interval at which splunkd checks the $SPLUNK_HOME/bin and $SPLUNK_HOME/lib directories for files that exist in those directories but should not, according to the Splunk manifest file. More Has no effect if 'installed_files_integrity' is disabled. Specify the interval as a string with minutes, seconds, hours, days. For example: 60s, 1m, 1h, 1d, etc.	5m
`[system_checks]` `orphan_searches`	`enabled\|disabled`Enables/disables automatic UI message notifications to admins for scheduled saved searches with invalid owners. More Scheduled saved searches with invalid owners are considered "orphaned". They cannot be run because Splunk cannot determine the roles to use for the search context. Typically, this situation occurs when a user creates scheduled searches then departs the organization or company, causing their account to be deactivated. Currently this check and any resulting notifications occur on system startup and every 24 hours thereafter.	enabled

`[thruput]`

Setting	Description	Default
`[thruput]` `maxKBps`	`<integer>`The maximum speed, in kilobytes per second, that incoming data is processed through the thruput processor in the ingestion pipeline. More To control the CPU load while indexing, use this setting to throttle the number of events this indexer processes to the rate (in kilobytes per second) that you specify. NOTE: There is no guarantee that the thruput processor will always process less than the number of kilobytes per second that you specify with this setting. The status of earlier processing queues in the pipeline can cause temporary bursts of network activity that exceed what is configured in the setting. The setting does not limit the amount of data that is written to the network from the tcpoutput processor, such as what happens when a universal forwarder sends data to an indexer. The thruput processor applies the 'maxKBps' setting for each ingestion pipeline. If you configure multiple ingestion pipelines, the processor multiplies the 'maxKBps' value by the number of ingestion pipelines that you have configured. For more information about multiple ingestion pipelines, see the 'parallelIngestionPipelines' setting in the server.conf.spec file.	0 (unlimited) (Splunk Enterprise); 256 (Splunk Universal Forwarder)

`[viewstates]`

Setting	Description	Default
`[viewstates]` `enable_reaper`	`<boolean>`Controls whether the viewstate reaper runs.	true
`[viewstates]` `reaper_freq`	`<integer>`Controls how often, in seconds, the viewstate reaper runs.	86400 (24 hours)
`[viewstates]` `reaper_soft_warn_level`	`<integer>`Controls what the reaper considers an acceptable number of viewstates.	1000
`[viewstates]` `ttl`	`<integer>`Controls the age, in seconds, at which a viewstate is considered eligible for reaping.	86400 (24 hours)

`[scheduled_views]`

Setting	Description	Default
`[scheduled_views]` `enable_reaper`	`<boolean>`Controls whether the scheduled views reaper runs, as well as whether More scheduled views are deleted when the dashboard they reference is deleted.	true
`[scheduled_views]` `reaper_freq`	`<integer>`Controls how often, in seconds, the scheduled views reaper runs.	86400 (24 hours)

`[search_optimization]`

Setting	Description	Default
`[search_optimization]` `enabled`	`<boolean>`Enables search optimizations	true

`[search_optimization::search_expansion]`

Setting	Description	Default
`[search_optimization::search_expansion]` `enabled`	`<boolean>`Enables optimizer-based search expansion. More This enables the optimizer to work on pre-expanded searches.	true

`[search_optimization::replace_append_with_union]`

Setting	Description	Default
`[search_optimization::replace_append_with_union]` `enabled`	`<boolean>`Enables replace append with union command optimization	true

`[search_optimization::merge_union]`

Setting	Description	Default
`[search_optimization::merge_union]` `enabled`	`<boolean>`Merge consecutive unions	true

`[search_optimization::insert_redistribute_command]`

Setting	Description	Default
`[search_optimization::insert_redistribute_command]` `enabled`	`<boolean>`Enables a search language optimization that inserts a 'redistribute' command. This lets you use parallel reduce search processing to shorten the search runtime for a set of supported SPL commands. More This optimization cannot be used by Splunk platform implementations that are restricted to the single-threaded search execution method. For more information about search execution methods, see the description of the 'phased_execution_mode' setting in this file.	true

`[search_optimization::predicate_merge]`

Setting	Description	Default
`[search_optimization::predicate_merge]` `enabled`	`<boolean>`Enables predicate merge optimization	true
`[search_optimization::predicate_merge]` `inputlookup_merge`	`<boolean>`Enables predicate merge optimization to merge predicates into inputlookup More predicate_merge must be enabled for this optimization to be performed	true
`[search_optimization::predicate_merge]` `merge_to_base_search`	`<boolean>`Enable the predicate merge optimization to merge the predicates into the first search in the pipeline.	true
`[search_optimization::predicate_merge]` `fields_black_list`	`<fields_list>`A comma-separated list of fields that will not be merged into the first search in the pipeline. More If a field contains sub-tokens as values, then the field should be added to fields_black_list	No default

`[search_optimization::predicate_push]`

Setting	Description	Default
`[search_optimization::predicate_push]` `enabled`	`<boolean>`Enables predicate push optimization	true

`[search_optimization::predicate_split]`

Setting	Description	Default
`[search_optimization::predicate_split]` `enabled`	`<boolean>`Enables predicate split optimization	true

`[search_optimization::projection_elimination]`

Setting	Description	Default
`[search_optimization::projection_elimination]` `enabled`	`<boolean>`Enables projection elimination optimization	true
`[search_optimization::projection_elimination]` `cmds_black_list`	`<comma separated list>`DEPRECATED. Use the 'excluded_commands' setting instead.
`[search_optimization::projection_elimination]` `excluded_commands`	`<Commands List>`A comma-separated list of commands that are not affected by projection elimination optimization.	No default

`[search_optimization::required_field_values]`

Setting	Description	Default
`[search_optimization::required_field_values]` `enabled`	`<boolean>`Enables required field value optimization	true
`[search_optimization::required_field_values]` `fields`	`<comma-separated-string>`Provide a comma-separated-list of field names to optimize. More Currently the only valid field names are eventtype and tag. Optimization of event type and tag field values applies to transforming searches. This optimization ensures that only the event types and tags necessary to process a search are loaded by the search processor. Only change this setting if you need to troubleshoot an issue.	eventtype, tag

`[search_optimization::search_flip_normalization]`

Setting	Description	Default
`[search_optimization::search_flip_normalization]` `enabled`	`<boolean>`Enables predicate flip normalization. More This type of normalization takes 'where' command statements in which the value is placed before the field name and reverses them so that the field name comes first. Predicate flip normalization only works for numeric values and string values where the value is surrounded by quotes. Predicate flip normalization also prepares searches to take advantage of predicate merge optimization. Disable search_flip_normalization if you determine that it is causing slow search performance.	true

`[search_optimization::reverse_calculated_fields]`

Setting	Description	Default
`[search_optimization::reverse_calculated_fields]` `enabled`	`<boolean>`Enables reversing of calculated fields optimization.	true

`[search_optimization::search_sort_normalization]`

Setting	Description	Default
`[search_optimization::search_sort_normalization]` `enabled`	`<boolean>`Enables predicate sort normalization. More This type of normalization applies lexicographical sorting logic to 'search' command expressions and 'where' command statements, so they are consistently ordered in the same way. Disable search_sort_normalization if you determine that it is causing slow search performance.	true

`[search_optimization::eval_merge]`

Setting	Description	Default
`[search_optimization::eval_merge]` `enabled`	`<boolean>`Enables a search language optimization that combines two consecutive "eval" statements into one and can potentially improve search performance. More There should be no side-effects to enabling this setting and need not be changed unless you are troubleshooting an issue with search results.	true

`[search_optimization::replace_table_with_fields]`

Setting	Description	Default
`[search_optimization::replace_table_with_fields]` `enabled`	`<boolean>`Enables a search language optimization that replaces the table command with the fields command in reporting or stream reporting searches More There should be no side-effects to enabling this setting and need not be changed unless you are troubleshooting an issue with search results.	true

`[search_optimization::replace_stats_cmds_with_tstats]`

Setting	Description	Default
`[search_optimization::replace_stats_cmds_with_tstats]` `enabled`	`<boolean>`If you are not using summary indexing, enable this setting to improve performance for searches that perform statistical operations only on indexed fields. More Do not enable this optimizer if you are dependent on summary indexes. When it is enabled, searches that perform timechart operations on summary indexes may need to perform extra work to run a fallback search and may run slower. This is because the 'tstats' command does not respect the fields created by summary indexing commands. If you use summary indexing but still choose to enable this optimization globally, you can disable this optimization on a per-search basis by appending '\| noop search_optimization.replace_stats_cmds_with_tstats=f' to the search string.	true
`[search_optimization::replace_stats_cmds_with_tstats]` `detect_search_time_field_collisions`	`<boolean>`Enables checking field collisions between fields.conf which indicates whether a field is indexed and props.conf which may contain fields which override those fields at search time. More This enables logic to perform an additional search expansion before the replace_stats_cmds_with_tstats optimizer can be applied so that we get correct results when this case occurs.	true

`[search_optimization::replace_datamodel_stats_cmds_with_tstats]`

Setting	Description	Default
`[search_optimization::replace_datamodel_stats_cmds_with_tstats]` `enabled`	`<boolean>`Enables a search language optimization that replaces stats commands with tstats commands in "\| datamodel .. \| stats" and "\| from datamodel .. \| stats" SPL strings.	true

`[search_optimization::replace_chart_cmds_with_tstats]`

If you are not using summary indexing, enable this optimizer to improve performance for searches that perform timechart queries on statistical operations only on indexed fields.
Do not enable this optimizer if you are dependent on summary indexes. When it is enabled, searches that perform timechart operations on summary indexes may need to perform extra work to run a fallback search and may run slower. This is because the 'tstats' command does not respect the fields created by summary indexing commands. If you use summary indexing but still choose to enable this optimization globally, you can disable this optimization on a per-search basis by appending '| noop search_optimization.replace_chart_cmds_with_tstats=f' to the search string.
Default: true

Setting	Description	Default
`[search_optimization::replace_chart_cmds_with_tstats]` `detect_search_time_field_collisions`	`<Boolean>`When set to 'true', the Splunk software checks for field collisions between 'fields.conf', which indicates whether a field is indexed, and 'props.conf', which may contain fields that override indexed fields at search time. More This setting enables logic which performs an additional search expansion before the replace_chart_cmds_with_tstats optimizer can be applied, to ensure that searches return correct results when these field collisions occur.	true

`[directives]`

Setting	Description	Default
`[directives]` `required_tags`	`enabled\|disabled`Enables the use of the required tags directive, which allows the search processor to load only the required tags from the conf system. More Disable this setting only to troubleshoot issues with search results.	enabled
`[directives]` `required_eventtypes`	`enabled\|disabled`Enables the use of the required eventtypes directive, which allows the search processor to load only the required event types from the conf system. More Disable this setting only to troubleshoot issues with search results.	enabled
`[directives]` `read_summary`	`enabled\|disabled`Enables the use of the read summary directive, which allows the search processor to leverage existing data model acceleration summary data when it performs event searches. More Disable this setting only to troubleshoot issues with search results.	enabled

`[parallelreduce]`

Setting	Description	Default
`[parallelreduce]` `maxReducersPerPhase`	`<positive integer>`The maximum number of valid indexers that can be used as intermediate reducers in the reducing phase of a parallel reduce operation. Only healthy search peers are valid indexers. More If you specify a number greater than 200 or an invalid value, parallel reduction does not take place. All reduction processing moves to the search head.	20
`[parallelreduce]` `defaultReducersPerPhase`	`<positive integer>`Specifies the default number of valid indexers that are used as intermediate reducers in the reducing phase of a parallel reduce search job, if the number of indexers is not set in the search string by the 'prjob' or 'redistribute' commands. More If 'winningRate' calculates that the size of the potential reducer pool is lower than 'defaultReducersPerPhase', the Splunk software uses the number of indexers determined by 'winningRate'. The value of this setting cannot exceed 'maxReducersPerPhase'.	4
`[parallelreduce]` `maxRunningPrdSearches`	`<unsigned integer>`DEPRECATED. Use the 'maxPrdSearchesPerCpu' setting instead.
`[parallelreduce]` `maxPrdSearchesPerCpu`	`<unsigned integer>`The maximum number of parallel reduce searches that can run, per CPU core, on an indexer. More If 'maxPrdSearchesPerCpu=1' and the number of concurrent searches exceeds the number of CPU cores on the indexer, new search requests will fail. If 'maxPrdSearchesPerCpu=0', there is no limit. The indexer runs as many parallel reduce searches as the indexer hardware permits	0
`[parallelreduce]` `reducers`	`<string>`Use this setting to configure one or more valid indexers as dedicated intermediate reducers for parallel reduce search operations. Only healthy search peers are valid indexers. More For <string>, specify the indexer host and port using the following format - host:port. Separate each host:port pair with a comma to specify a list of intermediate reducers. If the 'reducers' list includes one or more valid indexers, all of those indexers (and only these indexers) are used as intermediate reducers when you run a parallel reduce search. If the number of valid indexers in the 'reducers' list exceeds 'maxReducersPerPhase', the Splunk software randomly selects the set of indexers that are used as intermediate reducers. If all of the indexers in the 'reducers' list are invalid, the search runs without parallel reduction. All reduce operations for the search are processed on the search head. If 'reducers' is empty or not configured, all valid indexers are potential intermediate reducer candidates. The Splunk software randomly selects valid indexers as intermediate reducers with limits determined by the 'winningRate' and 'maxReducersPerPhase' settings.	""
`[parallelreduce]` `winningRate`	`<positive integer>`The percentage of valid indexers that can be selected from the search peers as intermediate reducers for a parallel reduce search operation. More This setting is only respected when the 'reducers' setting is empty or not configured. If 100 is specified, the search head attempts to use all of the indexers. If 1 is specified, the search head attempts to use 1% of the indexers. The minimum number of indexers used as intermediate reducers is 1. The maximum number of indexers used as intermediate reducers is the value of 'maxReducersPerPhase'.	50
`[parallelreduce]` `rdinPairingTimeout`	`<positive integer>`The amount of time (in seconds) to wait so that indexers and intermediate indexers may get paired More Note: Only change this setting unless instructed to do so by Splunk Support.	30
`[parallelreduce]` `autoAppliedPercentage`	`<non-negative integer>`The percentage of search queries to be selected to run as prjob, should be in range of [0, 100]. More If 100 is specified, all search queries will be wrapped as 'prjob'; if 0 is specified, no search query will be wrapped.	0
`[parallelreduce]` `autoAppliedToAdhocSearches`	`<boolean>`When set to true, the Splunk software uses parallel reduce processing to improve the performance of qualifying ad-hoc searches. More This setting is ignored when '0' is specified for 'autoAppliedPercentage'.	false
`[parallelreduce]` `maxPreviewMemUsageMb`	`<positive integer>`Sets the maximum amount of memory usage (in MB) that parallel reduce search can use in its preview cache. More NOTE: Do not change this setting unless instructed to do so by Splunk Support.	100
`[parallelreduce]` `enablePreview`	`<boolean>`When set to 'true', parallel reduce search jobs generate preview data, meaning that partial search results are returned as the search job runs. More When set to 'false', parallel reduce search jobs do not generate preview data. They display only the final results of a parallel reduce search job when the search job completes.	true
`[parallelreduce]` `disabledCommandList`	`<comma-separated list>`Specifies a list of commands that are not run for searches that undergo parallel reduce search processing. More This list is comma-separated, without spaces. For example, to disable the 'dedup' and 'sort' commands in parallel reduce searches, set 'disabledCommandList = dedup,sort'. Note: Do not change this setting unless instructed to do so by Splunk Support.	addinfo,lookup
`[parallelreduce]` `previewReducerDutyCycle`	`<number>`Sets the maximum time to spend generating previews on intermediate reducers, as a fraction of the total search time. More Note: This setting affects only preview generation on intermediate reducers. This setting is not affected by the 'preview_duty_cycle' setting under the '[search]' stanza, which controls preview generation on the search head. Must be > 0.0 and < 1.0	0.1

`[rollup]`

Setting	Description	Default
`[rollup]` `minSpanAllowed`	`<integer>`Sets the minimum timespan for the scheduled searches that generate metric rollup summaries. More Each rollup summary uses a scheduled search to provide its metric data point aggregations. The interval of the search matches the span defined for the rollup summary. However, when you run large numbers of scheduled searches with short intervals, you can encounter search concurrency problems, where some searches skip scheduled runs. To reduce the risk of search concurrency issues, this setting ensures that the rollup summaries created for your have longer spans. Do not set below 60 seconds.	300

`[mcollect]`

Setting	Description	Default
`[mcollect]` `always_use_single_value_output`	`<boolean>`When set to true, mcollect outputs metric data points that only have one measure per data point. More When set to false, mcollect outputs metric data points that can have several measures per data point. When your Splunk platform instance is fully upgraded to Splunk 8.0.0, change this setting to 'false'.	true

`[segmenter]`

Setting	Description	Default
`[segmenter]` `use_segmenter_v2`	`<boolean>`When set to true, this setting causes certain tokenization operations to use SSE (Streaming SIMD Extensions) instructions. This improves overall search performance. More This setting affects only those CPUs that support SSE4.2. NOTE: Do not change this setting unless instructed to do so by Splunk Support.	false

`[search_optimization::set_required_fields]`

The settings in this stanza affect how the search processors handle required field optimization.
Required field optimization prevents specified but unused fields from being extracted or otherwise created during a search. This can improve search performance.

Setting	Description	Default
`[search_optimization::set_required_fields]` `stats`	`<boolean>`This setting determines whether the stats processor uses the required field optimization methods of Stats V2, or if it falls back to the older, less optimized version of required field optimization that was used prior to Stats v2. More When set to 'true': the stats processor uses the Stats v2 version of the required field optimization. Do not set the value to "1" to indicate "true", because some systems might not parse this value correctly. When set to 'false': the stats processor falls back to the older version of the required field optimization. Do not change this setting unless instructed to do so by Splunk support.	false
`[search_optimization::set_required_fields]` `foreach`	`<boolean>`A value of "true" means the foreach processor delegates assembly of required fields to its subsearch pipeline. This can narrow the required field list and improve performance by reducing unnecessary field extractions. More A value of "false" means that all fields are extracted by default, which can make the search slower.	true

`[watchdog]`

Setting	Description	Default
`[watchdog]` `stack_files_ttl`	`<integer>`The amount of time to keep a watchdog stack file. More The interval can be specified as a string for minutes, seconds, hours, days. For example; 60s, 1m, 1h, 1d etc. These files are located in $SPLUNK_HOME/var/log/watchdog. If set to 0, the files will not be removed.	7d
`[watchdog]` `stack_files_removal_period`	`<integer>`The time interval used to check for files that exceed the 'stack_files_ttl' setting. More The interval can be specified as a string for minutes, seconds, hours, days. For example; 60s, 1m, 1h, 1d etc.	1h

`[ingest_actions]`

Setting	Description	Default
`[ingest_actions]` `rfs.provider.rawdata_limit_mb`	`<non-negative integer>`Limits the amount of RAM, in megabytes (MB), that a specific storage provider type (such as AWS S3) can use for forwarding events to one or more destinations. More This limit is applied only to the raw event data held in memory or in the process of being written to the storage endpoint. If the limit is reached, the RFS worker thread will not fetch further events from the pipeline, potentially causing upstream queues to fill up and eventually block the overall event pipeline. To avoid queue blocking, RFS worker thread may attempt to flush events more frequently than required, resulting in creating smaller files than expected. Therefore, a lower limit can result in smaller file sizes.	1024
`[ingest_actions]` `rfs.provider.max_workers`	`<non-negative integer>`Max number of worker threads per storage provider type (such as AWS S3) used to serialize events into compressed JSON file for storing on one or more destinations.	4
`[ingest_actions]` `rfs.provider.max_concurrent_uploads`	`<unsigned integer>`The maximum number of uploads to a storage provider, such as AWS S3, that can occur at the same time. More Increasing this value might help with low outbound throughput, especially for small batch uploads. The lowest acceptable value is 1 and the highest acceptable value is 8.	4
`[ingest_actions]` `rfsS3DestinationOff`	`<boolean>`Specifies whether Ingest Actions S3 destination configuration is turned off. More If S3 destination configuration is turned off, users will not see "Destination" page in the UI. If S3 destination configuration is turned off, users will not be able to configure S3 destination through REST endpoint. S3 destination configuration is turned off by default in GCP instances.	false
`[ingest_actions]` `enableDestConfigOnDs`	`<boolean>`Specifies whether S3 destinations for ingest actions can be configured on deployment servers.	true

`[reloads]`

Setting	Description	Default
`[reloads]` `custom_configuration_files_ignore_reload`	`<boolean>`If set to "true", all calls to /configs/conf-<config file name>/_reload for custom configuration files will return an HTTP 200 status code, but won't perform any actions on the receiving system. In this state, applications will break if they improperly manipulate configuration files directly on the filesystem instead of using the REST API. More NOTE: Do not change this setting unless instructed to do so by Splunk Support.	false

`[datalake]`

Setting	Description	Default
`[datalake]` `sqs.ingest.max_threads`	`<non-negative integer>`The maximum number of threads per pipeline-set that can be used by Splunk software to handle ingest from Amazon Security Lake instances that are subscribed through SQS remote queue for Federated Analytics data lake indexes.	2

`[spl2]`

Setting	Description	Default
`[spl2]` `origin`	`[all\|none\|<comma-separated list>]`The location from where the SPL2 search can originate. More To limit the location from where the search can originate, specify a comma-separated list of values. Currently, the only supported search origin values are "ad-hoc" and "scheduler". A value of "all" means that SPL2 searches can originate from any location that supports SPL2. A value of "ad-hoc" means that the search can originate from the Search & Reporting search bar. A value of "scheduler" means that the search can originate from scheduled searches. A value of "none" means that the search cannot originate from anywhere.	all
`[spl2]` `run_as_owner_ttl`	`<nonnegative integer>[s\|m\|h\|d]`The time-to-live (ttl), specified as a relative time, for searches that are designated to run as if the user is the owner of the search. More Valid time units are s (seconds), m (minutes), h (hours), and d (days).	"1d" (1 day)

`[storage_passwords_masking]`

Setting	Description	Default
`[storage_passwords_masking]` `view_cleartext_allowlist`	`<comma-separated list>`A set of external networks or addresses that can receive passwords in cleartext in response to calls to the "/storage/passwords" REST endpoint. More This setting does not apply for requests to the "localhost" address. Those requests always receive passwords in cleartext. Separate multiple rules with commas or spaces. Each rule can be in one of the following formats: 1. A single IPv4 or IPv6 address (examples: "10.1.2.3", "fe80::4a3") 2. A Classless Inter-Domain Routing (CIDR) block of addresses (examples: "10/8", "192.168.1/24", "fe80:1234/32") 3. A DNS name, possibly with a "" used as a wildcard (examples: "myhost.example.com", ".splunk.com") 4. "", which matches anything You can also prefix an entry with '!' to cause the rule to reject the connection. The input applies rules in order, and uses the first one that matches. For example, "!10.1/16, " returns cleartext passwords to calls from everywhere except the 10.1.. network.	"*" (always return cleartext passwords)
`[storage_passwords_masking]` `view_cleartext_spl_rest`	`<boolean>`Whether or not the SPL 'rest' command can return passwords in cleartext when it makes calls to the "/storage/passwords" REST endpoint. More A value of "true" means that the command can return cleartext passwords when it makes calls to the "/storage/passwords" endpoint. A value of "false" means that the command cannot return cleartext passwords when it makes calls to the "/storage/passwords" endpoint.	true
`[storage_passwords_masking]` `mask_encr_password`	`<boolean>`Whether or not the Splunk platform masks the 'encr_password' field in responses from the "/storage/passwords" REST endpoint. More A value of "true" means the 'encr_password' field is replaced with a static placeholder value that does not contain the actual encrypted secret. The placeholder uses the "$7$" prefix followed by asterisks. A value of "false" means the 'encr_password' field returns the actual encrypted password value. This setting applies to both direct REST API calls and the SPL 'rest' command. There is no separate per-path control for this setting, unlike 'view_cleartext_spl_rest' which only affects the SPL 'rest' command.	false

File locations

Configuration file: limits.conf.

Scope	Path
System	`$SPLUNK_HOME/etc/system/{default,local}/limits.conf`
App	`$SPLUNK_HOME/etc/apps/<app_name>/{default,local}/limits.conf`

App-level overrides are common in practice -- an app commonly ships its own limits.conf to raise or lower a limit for its own saved searches or commands specifically, rather than changing the system-wide default.

Example

[searchresults]
maxresultrows = 50000

[search]
dispatch_dir_warning_size = 5000

The spec's default result-row cap and dispatch-directory job-count warning threshold -- note they live in different stanzas.

Validation

Don't change [searchresults] maxresultrows unless Splunk Support tells you to -- the spec says so explicitly. Several command stanzas ([stats|sistats], [top], [rare] and others) have their own maxresultrows.
Watch for bulletin warnings tied to dispatch_dir_warning_size as an early signal that dispatched job cleanup is falling behind.
Prefer an app-scoped override to a system-wide change when only one app's searches actually need a different limit.

← Back to References

References / Splunk platform configuration

Search Macros Configuration

macros.conf defines reusable search-language macros -- the stanza name encodes the macro name and, in parentheses, its argument count. Backs the same knowledge-object model as eventtypes.conf and tags.conf elsewhere in this reference.

Definition

A stanza named [<macro_name>] (no arguments) or [<macro_name>(<arg_count>)] (with arguments) defines one macro. A search referencing `macro_name(val1,val2)` expands to the stanza's definition, with argument substitution applied.

Settings

Setting	Description
`args`	Comma-separated argument names. Argument names may only contain alphanumeric characters, underscores and hyphens, and the list cannot repeat an element. Ignored if the stanza name indicates the macro takes no arguments.
`definition`	The string the macro expands to, with $argname$ substitution applied from the caller's supplied values.
`validation` / `errormsg`	An eval expression checking the macro's argument values are acceptable. Must evaluate to a boolean or a string; a false boolean or a NULL result fails validation and returns the message defined by `errormsg`. A non-boolean, non-NULL result is treated as a validation failure message itself.
`iseval`	When `true`, `definition` is itself evaluated as an eval expression rather than treated as literal SPL text to splice in.
`description`	Optional description of what the macro does.

File locations

Configuration file: macros.conf.

Scope	Path
System	`$SPLUNK_HOME/etc/system/{default,local}/macros.conf`
App	`$SPLUNK_HOME/etc/apps/<app_name>/{default,local}/macros.conf`
User	`$SPLUNK_HOME/etc/users/<user_name>/<app_name>/local/macros.conf`

Universal Forwarder has no search head or per-user knowledge-object context, the same exception already flagged for props.conf/savedsearches.conf and the rest of this reference's knowledge-object files -- the User tier does not apply there.

Example

[fooeval(2)]
args = foo, bar
definition = if (bar > 0, "$foo$ + $bar$", "$foo$ - $bar$")
iseval = true

A two-argument eval-based macro: `fooeval(10,20)` expands to 10 + 20 since bar is positive.

Validation

Keep argument names in args alphanumeric/underscore/hyphen only, with no repeated element.
Pair validation with a specific errormsg rather than leaving the caller to guess why their arguments were rejected.
Remember iseval = true changes how definition is interpreted -- a definition written as literal SPL text under that setting will not behave as expected.

← Back to References

References / Splunk platform configuration

REST Endpoints Configuration

restmap.conf registers every custom REST endpoint -- an endpoint must be registered here to become available. Backs the Splunk Taxonomy's Custom Search Commands and related extension objects alongside commands.conf.

Definition

A [global] stanza (at most one per file) holds file-wide defaults. Per-endpoint stanzas follow: [script:<uniqueName>] binds a handler to a URI; [admin:<name>] and [admin_external:<name>] register admin-configuration endpoints. A Splunk restart is required to pick up changes.

Settings

Every stanza and setting in restmap.conf.spec from Splunk Enterprise 10.4.2: 66 settings across 15 stanzas. Descriptions use the spec's own wording -- the first line shows here and More opens the rest. The Default column is filled only where the spec gives a Default: line.

`[global]`

Setting	Description	Default
`[global]` `allowGetAuth`	`<boolean>`Allows the username/password to be passed as a GET parameter to endpoint services/authorization/login. More Setting to "true" might result in your username and password being logged as cleartext in Splunk logs and any proxy servers in between.	false
`[global]` `allowRestReplay`	`<boolean>`Allows POST/PUT/DELETE requests to be replayed on other nodes in the deployment. More Setting to "true" enables centralized management. You can also control replay at each endpoint level. CAUTION: This feature is currently internal. Do not enable it without consulting Splunk support.	false
`[global]` `defaultRestReplayStanza`	`<string>`Points to the default or global REST replay configuration stanza. More This setting is related to the 'allowRestReplay' setting.	restreplayshc
`[global]` `pythonHandlerPath`	`<path>`Path to the 'main' python script handler. More Used by the script handler to determine where the actual 'main' script is located. Typically you do not need to edit this setting.	$SPLUNK_HOME/bin/rest_handler.py
`[global]` `v1APIBlockGETSearchLaunch`	`<boolean>`Triggers breaking changes in default and v1 variants of the endpoints: More /search/jobs/export /search/jobs/{sid}/(events\|results\|results_preview) /search/jobs/oneshot /search/parser These changes involve removing the abilty to launch searches using HTTP GET requests.	false

`[<rest endpoint name>:<endpoint description string>]`

Settings under this stanza are applicable to all REST stanzas.
Settings in other stanzas might supply additional information.

Setting	Description	Default
`[<rest endpoint name>:<endpoint description string>]` `match`	`<path>`Specify the URI that calls the handler. More For example, if match=/foo then https: //$SERVER:$PORT/services/foo calls this handler. NOTE: You must start your path with a "/".
`[<rest endpoint name>:<endpoint description string>]` `requireAuthentication`	`<boolean>`Determines if this endpoint requires authentication. More (OPTIONAL)	true
`[<rest endpoint name>:<endpoint description string>]` `authKeyStanza`	`<string>`A list of comma or space separated stanza names that specifies the location of the pass4SymmKeys in the server.conf file to use for endpoint authentication. More Tries to authenticate with all configured pass4SymmKeys. If no pass4SymmKey is available, authentication is done using the pass4SymmKey in the [general] stanza. This setting applies only if the 'requireAuthentication' setting is set to "true". (OPTIONAL) When not set, the endpoint will not be authenticated using pass4SymmKeys.	not set
`[<rest endpoint name>:<endpoint description string>]` `restReplay`	`<boolean>`Enables REST replay on this endpoint group. More (OPTIONAL) Related to the 'allowRestReplay' setting. CAUTION: This feature is currently internal. Do not enable it without consulting Splunk support.	false
`[<rest endpoint name>:<endpoint description string>]` `restReplayStanza`	`<string>`This setting points to a stanza that can override the [global]/defaultRestReplayStanza value on a per-endpoint/regex basis.	empty string
`[<rest endpoint name>:<endpoint description string>]` `capability`	`<capabilityName>`Depending on the HTTP method, check capabilities on the authenticated session user. More If you use the 'capability.<post\|delete\|get\|put>' setting, the associated method is checked against the authenticated user's role. If you use the capability' setting, all calls are checked against this capability regardless of the HTTP method. You can also express capabilities as a boolean expression. Supported operators include: or, and, ()
`[<rest endpoint name>:<endpoint description string>]` `capability.<post\|delete\|get\|put>`	`<capabilityName>`Depending on the HTTP method, check capabilities on the authenticated session user. More If you use the 'capability.<post\|delete\|get\|put>' setting, the associated method is checked against the authenticated user's role. If you use the capability' setting, all calls are checked against this capability regardless of the HTTP method. You can also express capabilities as a boolean expression. Supported operators include: or, and, ()
`[<rest endpoint name>:<endpoint description string>]` `acceptFrom`	`<comma-separated list>`A list of networks or addresses from which to allow this endpoint to be accessed. More Do not confuse this setting with the identical setting in the [httpServer] stanza of server.conf which controls whether a host can make HTTP requests at all. Each rule can be in the following forms: 1. A single IPv4 or IPv6 address (examples: "10.1.2.3", "fe80::4a3") 2. A CIDR block of addresses (examples: "10/8", "fe80:1234/32") 3. A DNS name, possibly with a '' used as a wildcard (examples: "myhost.example.com", ".splunk.com") 4. A single '' which matches anything. You can also prefix entries with '!' to cause the rule to reject the connection. Rules are applied in order, and the first one to match is used. For example, "!10.1/16, " allows connections from everywhere except the 10.1.. network.	"*" (accept from anywhere)
`[<rest endpoint name>:<endpoint description string>]` `includeInAccessLog`	`<boolean>`Whether to include requests to this endpoint in the splunkd_access.log. More If set to "true", requests appear in splunkd_access.log. If set to "false", requests do not appear in splunkd_access.log.	true
`[<rest endpoint name>:<endpoint description string>]` `maxConcurrent`	`<positive integer>\|unlimited`If the number of concurrent requests that a handler receives from users exceeds this limit, the handler returns HTTP 429 errors until the total request count drops below the limit again. More When 'maxConcurrent' is set, the response to the handler includes an HTTP Retry-After header that clients must honor before they call the handler again. A single user can't exceed the number of requests set by 'maxConcurrent'. A value of "unlimited" means that there are no restrictions on the number of client requests for this handler.	unlimited
`[<rest endpoint name>:<endpoint description string>]` `max_content_length`	`<non-negative integer><unit>`The maximum size of the request body for a given REST handler. More You can specify this limit in base-10 (for example, 1 KB = 1000 bytes) or base-2 (1 KiB = 1024 bytes) format by using the appropriate term as the <unit>. The limit affects all REST handlers that are specified for a given endpoint. If you want to add a custom setting for one or more handlers separately, you can add this setting under a custom handler stanza. For example, if you have the following existing stanza: [admin:endpoint_group] match = /mypath capability = mycapability members = subpath1, subpath2, subpath3 max_content_length = 100 KiB and you want to set a different 'max_content_length' for a specific member, you must add a separate, new stanza, with a unique name, for the member whose 'max_content_length' you want to change. You then add that member to the new stanza and confirm that the member no longer exists in the old stanza. You must also copy all other settings and values from the old stanza to the new one: [admin:endpoint_group] match = /mypath capability = mycapability members = subpath2, subpath3 max_content_length = 100 KiB [admin:endpoint_my_new_group] match = /mypath members = subpath1 capability = mycapability max_content_length = 1 GB In this example, the subpath1 member has its 'max_content_length' increased to 1 gigabyte while the subpath2 and subpath3 members retain a 'max_content_length' of 100 kibibytes. This setting is optional.	The value of 'server.conf:[httpServer]/max_content_length'

`[script:<uniqueName>]`

Per-endpoint stanza.
Use this stanza to specify a handler and other handler-specific settings.
The handler is responsible for implementing arbitrary namespace underneath each REST endpoint.
NOTE: The uniqueName must be different for each handler.
Call the specified handler when executing this endpoint.
The attribute/value pairs below support the script handler.

Setting	Description	Default
`[script:<uniqueName>]` `scripttype`	`<string>`Tells the system what type of script to run when using this endpoint. More If set to "persist", it runs the script using a persistent process that uses the protocol from persistconn/appserver.py.	python
`[script:<uniqueName>]` `python.version`	`{default\|python\|python2\|python3\|python3.7\|python3.9\|latest}`DEPRECATED. Use 'python.required' instead to specify which Python versions the script supports. More For Python scripts only, selects which Python version to use. Set to either "default" or "python" to use the system-wide default Python version. Set to "python3" or "python3.7" to use the Python 3.7 version. Set to "python3.9" to use the Python 3.9 version. In the context of configuring apps, the "latest" value is not currently supported. It is related to a feature that is still under development. (OPTIONAL)	Not set (Uses the system-wide Python version.)
`[script:<uniqueName>]` `python.required`	`<comma-separated list>`For Python scripts only, the versions of Python that the script supports. More This setting takes precedence over the 'python.version' setting if both have values. The Splunk platform selects the highest version of Python that is available from the list that you provide. The following values are supported: "3.9": The script supports Python version 3.9. "3.13": The script supports Python version 3.13. "latest": The script uses the latest Python interpreter available. Where possible, use a specific version string rather than "latest". NOTE: The "latest" value is an internal value that is related to a feature that is still under development. NOTE: Use this setting instead of the deprecated 'python.version' setting. This setting is optional.	Not set; uses 'python.version' if that setting has a value.
`[script:<uniqueName>]` `handler`	`<SCRIPT>.<CLASSNAME>`The name and class name of the file to execute. More The file must be located in an application's bin subdirectory. For example, $SPLUNK_HOME/etc/apps/<APPNAME>/bin/TestHandler.py has a class called MyHandler (which, in the case of python must be derived from a base class called 'splunk.rest.BaseRestHandler'). The attribute/value pair for it is: "handler=TestHandler.MyHandler".
`[script:<uniqueName>]` `script`	`<string>`The path to a script executable. More (Optional). Use this setting only if the 'scripttype' setting is set to "python". This setting allows you to run a script which is not derived from 'splunk.rest.BaseRestHandler'. This setting is rarely used. If the 'scripttype' setting is set to "persist", this setting is the path that is sent to the driver to run. In that case, environment variables are substituted.
`[script:<uniqueName>]` `script.arg.<N>`	`<string>`A list of arguments that are passed to the driver to start the script. More Only has effect if the 'scripttype' setting is set to "persist". The script can use this information however it wants. Environment variables are substituted.
`[script:<uniqueName>]` `script.param`	`<string>`A free-form argument that is passed to the driver when it starts the script. More (OPTIONAL) Only has effect if the 'scripttype' setting is set to "persist". The script can use this information however it wants. Environment variables are substituted.
`[script:<uniqueName>]` `output_modes`	`<comma-separated list>`Specify which output formats this endpoint can request. More Valid values: json, xml	xml
`[script:<uniqueName>]` `passSystemAuth`	`<boolean>`Specifies whether or not to pass in a system-level authentication token on each request.	false
`[script:<uniqueName>]` `driver`	`<path>`If the 'scripttype' setting is set to "persist", specifies the command to start a persistent server for this process. More Endpoints that share the same driver configuration can share processes. Environment variables are substituted.	the persistconn/appserver.py server
`[script:<uniqueName>]` `driver.arg.<n>`	`<string>`If the 'scripttype' setting is set to "persist", specifies the command to start a persistent server for this process. More Environment variables are substituted. Only takes effect when "driver" is specifically set.
`[script:<uniqueName>]` `driver.env.<name>`	`<string>`If the 'scripttype' setting is set to "persist", specifies an environment variable to set when running the driver process.
`[script:<uniqueName>]` `passConf`	`<boolean>`If set, the script is sent the contents of this configuration stanza as part of the request. More Only has effect if the 'scripttype' setting is set to "persist".	true
`[script:<uniqueName>]` `passPayload`	`[true\|false\|base64]`If set to "true", sends the driver the raw, unparsed body of the POST/PUT as a "payload" string. More If set to "base64", the same body is instead base64-encoded and sent as a "payload_base64" string. Only has effect if the 'scripttype' setting is set to "persist".	false
`[script:<uniqueName>]` `passSession`	`<boolean>`If set to "true", sends the driver information about the user's session. This includes the user's name, an active authtoken, and other details. More Only has effect if the 'scripttype' setting is set to "persist".	true
`[script:<uniqueName>]` `passHttpHeaders`	`<boolean>`Determines whether splunkd passes HTTP request headers to the driver. More A value of "true" means splunkd passes the HTTP request headers to the driver. Only has effect if the 'scripttype' setting is set to "persist".	false
`[script:<uniqueName>]` `passHttpCookies`	`<boolean>`If set to "true", sends the driver the HTTP cookies of the request. More Only has effect if the 'scripttype' setting is set to "persist".	false
`[script:<uniqueName>]` `stream`	`<boolean>`Describes whether or not splunkd sends the payload in the request to the driver in a streaming fashion. More A value of "true" means splunkd sends the payload in the request to the driver in a stream, or multiple sequential requests. A value of "false" means splunkd sends the payload in the request to the driver as a field of the original request. Only has effect if the 'scripttype' setting is set to "persist".	false

`[admin:<uniqueName>]`

'admin'
The built-in handler for the Extensible Administration Interface (EAI).
Exposes the listed EAI handlers at the given URL.

Setting	Description	Default
`[admin:<uniqueName>]` `match`	`<string>`A partial URL which, when accessed, displays the handlers listed below.
`[admin:<uniqueName>]` `members`	`<comma-separated list>`A list of handlers to expose at this URL. More See https://localhost:8089/services/admin for a list of all possible handlers.
`[admin:<uniqueName>]` `maxCacheTime`	`<interval>`The maximum amount of time that the Splunk platform can cache a response for this REST endpoint. More Determines how the endpoint handles the caching of HTTP responses. Specifically, controls the value of HTTP cache control headers, which is important for those who use a reverse proxy or an external client to access REST endpoints. You can specify the interval in seconds (s), minutes (m), hours (h), or days (d). For example: 60s, 1m, 1h, 1d; etc. Maximum accepted value is 1 year.	0 (disabled)
`[admin:<uniqueName>]` `capability`	`<string>`One or more capabilities that an authenticated user must hold before they can execute an HTTP request against the REST endpoint URL that you specify in the stanza name. More When a logged-in user submits an HTTP request to an endpoint, splunkd confirms that the user holds a minimum of the capabilities you specify in this setting before it lets the request act upon the endpoint. If the HTTP request is not submitted, splunkd rejects the attempt. This setting has two forms, which determine how capability checking occurs: 'capability' on its own configures splunkd to confirm that the logged-in user holds the capabilities you specify to act upon the URL for any HTTP request method. 'capability.<post\|delete\|get\|put>' configures splunkd to confirm that the logged-in user holds the capabilities to act upon the URL through the HTTP method you specify after the period. You can only specify one method type after the period. For example, if you specify "capability.get = admin_all_objects", splunkd confirms that the user holds the "admin_all_objects" capability before it lets them perform an HTTP GET operation on the endpoint. You can represent values for this setting in two ways: As a single capability name, for example, "admin_all_objects". As an expression for multiple capabilities, using the 'and' or 'or' operators. You can group capabilities together using parentheses ("()") to create complex expressions. For example, if you specify "capability.post = (edit_monitor or edit_sourcetypes) and (edit_user and edit_tcp)" then the user must hold one of 'edit_monitor' or 'edit_sourcetypes' and both 'edit_user' and 'edit_tcp' before they can perform an HTTP POST operation on the endpoint. Both setting formats can use either value format as long as the capabilities you specify are valid. Regardless of the HTTP request method that the user submits, the request can only act upon the handlers that this endpoint exposes with the 'members' setting. To set granular capability checking over multiple custom handlers, create multiple [admin:<uniqueName>] stanzas with the same name and use the 'members' setting to define different custom handlers within each stanza.	No default
`[admin:<uniqueName>]` `capability.<post\|delete\|get\|put>`	`<string>`One or more capabilities that an authenticated user must hold before they can execute an HTTP request against the REST endpoint URL that you specify in the stanza name. More When a logged-in user submits an HTTP request to an endpoint, splunkd confirms that the user holds a minimum of the capabilities you specify in this setting before it lets the request act upon the endpoint. If the HTTP request is not submitted, splunkd rejects the attempt. This setting has two forms, which determine how capability checking occurs: 'capability' on its own configures splunkd to confirm that the logged-in user holds the capabilities you specify to act upon the URL for any HTTP request method. 'capability.<post\|delete\|get\|put>' configures splunkd to confirm that the logged-in user holds the capabilities to act upon the URL through the HTTP method you specify after the period. You can only specify one method type after the period. For example, if you specify "capability.get = admin_all_objects", splunkd confirms that the user holds the "admin_all_objects" capability before it lets them perform an HTTP GET operation on the endpoint. You can represent values for this setting in two ways: As a single capability name, for example, "admin_all_objects". As an expression for multiple capabilities, using the 'and' or 'or' operators. You can group capabilities together using parentheses ("()") to create complex expressions. For example, if you specify "capability.post = (edit_monitor or edit_sourcetypes) and (edit_user and edit_tcp)" then the user must hold one of 'edit_monitor' or 'edit_sourcetypes' and both 'edit_user' and 'edit_tcp' before they can perform an HTTP POST operation on the endpoint. Both setting formats can use either value format as long as the capabilities you specify are valid. Regardless of the HTTP request method that the user submits, the request can only act upon the handlers that this endpoint exposes with the 'members' setting. To set granular capability checking over multiple custom handlers, create multiple [admin:<uniqueName>] stanzas with the same name and use the 'members' setting to define different custom handlers within each stanza.	No default
`[admin:<uniqueName>]` `maxRestResults`	`<unsigned integer>`The maximum number of results that a REST API call can return. More A REST API call fails if it tries to retrieve more results than you specify here. A value of 0, or no value, means that REST API calls can return any number of results, if possible. Do not change this setting without first consulting with Splunk Support.	0
`[admin:<uniqueName>]` `streamlineXmlSerialization`	`<boolean>`Determines how the web server produces XML output for the results required by REST API calls. More Only applies when a REST API call asks for XML outputs. A value of "true" means the web server produces XML output for each result one by one, which consumes less memory. A value of "false" means the web server produces XML output for all results at once, which consumes more memory. Do not change this setting without first consulting with Splunk Support.	true

`[admin_external:<uniqueName>]`

'admin_external'
Register Python handlers for the Extensible Administration Interface (EAI).
The handler is exposed via its "uniqueName".
NOTE: Splunkd does not honor capability checks under this stanza. Define capability checks on endpoints under [admin:*] stanzas instead. handlertype = <string>
The script type.
Currently the only valid value is "python".

Setting	Description	Default
`[admin_external:<uniqueName>]` `python.version`	`{default\|python\|python2\|python3\|python3.7\|python3.9\|latest}`DEPRECATED. Use 'python.required' instead to specify which Python versions the script supports. More For Python scripts only, selects which Python version to use. Either "default" or "python" select the system-wide default Python version. Set to "python3" or "python3.7" to use the Python 3.7 version. Set to "python3.9" to use the Python 3.9 version. In the context of configuring apps, the "latest" value is not currently supported. It is related to a feature that is still under development. Optional.	not set; uses the system-wide Python version.
`[admin_external:<uniqueName>]` `python.required`	`<comma-separated list>`For Python scripts only, the versions of Python that the script supports. More This setting takes precedence over the 'python.version' setting if both have values. The Splunk platform selects the highest version of Python that is available from the list that you provide. The following values are supported: "3.9": The script supports Python version 3.9. "3.13": The script supports Python version 3.13. "latest": The script uses the latest Python interpreter available. Where possible, use a specific version string rather than "latest". NOTE: The "latest" value is an internal value that is related to a feature that is still under development. NOTE: Use this setting instead of the deprecated 'python.version' setting. This setting is optional.	Not set; uses 'python.version' if that setting has a value.
`[admin_external:<uniqueName>]` `handlerfile`	`<string>`Script to execute. More For bin/myAwesomeAppHandler.py, specify only myAwesomeAppHandler.py.
`[admin_external:<uniqueName>]` `handlerpersistentmode`	`<boolean>`Set to "true" to run the script in persistent mode and keep the process running between requests.
`[admin_external:<uniqueName>]` `passHttpHeaders`	`<boolean>`Determines whether splunkd passes HTTP request headers to the handler. More A value of "true" means splunkd passes the HTTP request headers to the handler. Currently not supported. This setting is related to a feature that is still under development.	false
`[admin_external:<uniqueName>]` `handleractions`	`<comma-separated list>`a list of EAI actions supported by this handler. More Valid values: create, edit, list, delete, _reload

`[validation:<handler-name>]`

Validation stanzas.
Add stanzas using the following definition to add argument validation to the appropriate EAI handlers.

Setting	Description	Default
`[validation:<handler-name>]` `<field>`	`<validation-rule>`<field> is the name of the field whose value is validated when an object is being saved. More <validation-rule> is an eval expression using the validate() function to evaluate argument correctness and return an error message. If you use a boolean returning function, a generic message is displayed. <handler-name> is the name of the REST endpoint that this stanza applies to. handler-name is what is used to access the handler via /servicesNS/<user>/<app/admin/<handler-name>. For example: action.email.sendresult = validate( isbool('action.email.sendresults'), "'action.email.sendresults' must be a boolean value"). NOTE: Use "'" or "$" to enclose field names that contain non-alphanumeric characters.

`[eai:<EAI handler name>]`

'eai'
Settings to alter the behavior of EAI handlers in various ways.
Users do not need to edit these settings.

Setting	Description	Default
`[eai:<EAI handler name>]` `showInDirSvc`	`<boolean>`Whether configurations managed by this handler should be enumerated via the directory service, used by SplunkWeb's "All Configurations" management page.	false
`[eai:<EAI handler name>]` `desc`	`<string>`Allows for renaming the configuration type of these objects when enumerated via the directory service.

`[input:...]`

Miscellaneous parameters.
The undescribed settings in these stanzas all operate according to the descriptions listed under the [script] stanza above.
Users do not need to edit these settings. They only exist to quiet down the configuration checker.

Setting	Description	Default
`[input:...]` `dynamic`	`<boolean>`If set to "true", listen on the socket for data. More If set to "false", data is contained within the request body.	false

`[peerupload:...]`

Setting	Description	Default
`[peerupload:...]` `path`	`<path>`The path to search through to find configuration bundles from search peers.
`[peerupload:...]` `untar`	`<boolean>`Whether or not to untar a file once the transfer is complete.

`[proxybundleupload:...]`

Setting	Description	Default
`[proxybundleupload:...]` `path`	`<path>`The path to search through to find proxy configuration bundles from search heads.
`[proxybundleupload:...]` `untar`	`<boolean>`Whether or not to untar a file once the transfer is complete.

`[proxybundleshcmember:...]`

Setting	Description	Default
`[proxybundleshcmember:...]` `path`	`<directory path>`The directory path to search for configuration bundles from search peers.
`[proxybundleshcmember:...]` `untar`	`[true\|false]`A value of "true" means the file is untarred on the target after the transfer completes. More A value of "false" means the file is not untarred after the transfer completes.

`[proxybundleshccaptain:...]`

Setting	Description	Default
`[proxybundleshccaptain:...]` `path`	`<directory path>`The directory path to search for configuration bundles from search head cluster captain.
`[proxybundleshccaptain:...]` `untar`	`[true\|false]`A value of "true" means the file is untarred on the target after the transfer completes. More A value of "false" means the file is not untarred after the transfer completes.

`[proxybundleuploadrshcluster:...]`

Setting	Description	Default
`[proxybundleuploadrshcluster:...]` `path`	`<path>`The path to search through to find proxy configuration bundles from search heads.
`[proxybundleuploadrshcluster:...]` `untar`	`<boolean>`Whether or not to untar a file once the transfer is complete.

`[restreplayshc]`

Setting	Description	Default
`[restreplayshc]` `methods`	`<comma-separated list>`REST methods that are replayed. More Available fields: POST, PUT, DELETE, HEAD, GET
`[restreplayshc]` `nodelists`	`<comma-separated list>`Strategies for replay. More Available fields: shc, nodes, filternodes "shc" replays to all other nodes in a search head cluster. "nodes" provide raw comma-separated URIs in nodes variable. "filternodes" filters out specific nodes. It is always applied after other strategies.
`[restreplayshc]` `nodes`	`<comma-separated list>`A list of management URIs (specific nodes) that you want the REST call to be replayed to.
`[restreplayshc]` `filternodes`	`<comma-separated list>`A list of management URIs (specific nodes) that you do not want the REST call to be replayed to.

`[proxy:appsbrowser]`

Setting	Description	Default
`[proxy:appsbrowser]` `destination`	`<URL>`The protocol, subdomain, domain, port, and path of the Splunkbase API used to browse apps.	https://splunkbase.splunk.com/api

File locations

Configuration file: restmap.conf.

Scope	Path
System	`$SPLUNK_HOME/etc/system/{default,local}/restmap.conf`
App	`$SPLUNK_HOME/etc/apps/<app_name>/{default,local}/restmap.conf`

Apps that ship custom REST endpoints or admin handlers commonly include their own restmap.conf alongside the handler script itself.

Example

[script:hello_world]
match = /hello_world
script = hello_world.py
scripttype = python
python.required = 3.9,3.13
handler = hello_world.HelloWorldHandler

A minimal custom endpoint mapped to a Python handler class that supports Python 3.9 and 3.13.

Validation

Give every [script:<uniqueName>] stanza a name unique across the whole instance, not just within its own app.
Restart Splunk after any restmap.conf change -- it is not a live-reloadable file.
Declare the Python versions a handler supports with python.required -- the spec marks python.version as deprecated, and python.required wins if both are set.

← Back to References

References / Splunk platform configuration

Health Report Configuration

health.conf sets the default thresholds for Splunk Enterprise's built-in Health Report. Feature stanzas group indicators; each indicator carries a Yellow (investigate) and Red (effectively not working) threshold.

Definition

Each monitored feature gets its own stanza; inside it, one or more indicators are tracked, each against a Yellow and a Red threshold. Reflected in Splunk Web's health-status indicator and the Monitoring Console.

Settings

Every stanza and setting in health.conf.spec from Splunk Enterprise 10.4.2: 35 settings across 7 stanzas. Descriptions use the spec's own wording -- the first line shows here and More opens the rest. The Default column is filled only where the spec gives a Default: line.

`[distributed_health_reporter]`

Setting	Description	Default
`[distributed_health_reporter]` `disabled`	`<boolean>`Whether or not this Splunk platform instance calls connected search peers to retrieve health report information. More A value of 1 disables the distributed health report on this Splunk platform instance. When disabled, the instance does not call connected search peers to retrieve health report information.	0 (enabled)

`[health_reporter]`

Setting	Description	Default
`[health_reporter]` `full_health_log_interval`	`<number>`The amount of time, in seconds, that elapses between each ‘PeriodicHealthReporter=INFO’ log entry.	30.
`[health_reporter]` `suppress_status_update_ms`	`<number>`The minimum amount of time, in milliseconds, that must elapse between an indicator's health status changes. More Changes that occur earlier are suppressed.	300.
`[health_reporter]` `suppress_status_reason_update_s`	`<number>`The minimum amount of time, in seconds, that must elapse between a change to the reason for the indicator. More Changes that occur earlier are suppressed.	10.
`[health_reporter]` `latency_tracker_log_interval`	`<number>`The amount of time, in seconds, that elapses between each latency tracker log entry.	30.
`[health_reporter]` `aggregate_ingestion_latency_health`	`[0\|1]`A value of 0 disables the aggregation feature for ingestion latency health reporter.	1 (enabled).
`[health_reporter]` `ingestion_latency_send_interval`	`<integer>`The amount of time, in seconds, that splunkd waits before it sends ingestion latency data as part of a heartbeat message. More splunkd determines the actual interval at which it sends this data by factoring the value for 'ingestion_latency_send_interval' with the value for 'heartbeatFrequency' in the [tcpout] stanza of the outputs.conf file. This is because splunkd uses the tcpout heartbeat to send ingestion latency data, and that it won't send ingestion latency data at a frequency of less than outputs.conf:[tcpout].'heartbeatFrequency' seconds. If you set 'ingestion_latency_send_interval' to a value that is higher than 'heartbeatFrequency', splunkd sends that data only when the number of 'heartbeatFrequency' seconds exceeds the number of 'ingestion_latency_send_interval' seconds at each 'ingestion_latency_send_interval'. For example: if 'ingestion_latency_send_interval' has a value of 75 and 'heartbeatFrequency' has a value of 60, splunkd sends the data every 120 seconds, because it takes two periods of 'heartbeatFrequency' seconds before the 'heartbeatFrequency' is greater than the 'ingestion_latency_send_interval'. Conversely, if you set 'ingestion_latency_send_interval' to a value that is lower than 'heartbeatFrequency', splunkd sends that data only when the number of 'ingestiona_latency_send_interval' seconds has elapsed. If, for example, 'ingestion_latency_send_interval' has a value of 30 and 'heartbeatFrequency' has a value of 90, splunkd sends the data every 90 seconds because of the value of 'heartbeatFrequency', even though you set a 'ingestion_latency_send_interval' of 30.	30
`[health_reporter]` `ingestion_latency_send_interval_max`	`<number>`The maximum amount of time, in seconds, that elapses between ingestion latency sent as part of heart beat message. Should be in range 0-86400	86400.
`[health_reporter]` `alert.disabled`	`[0\|1]`A value of 1 disables the alerting feature for health reporter. More If the value is set to 1, alerting for all features is disabled.	0 (enabled)
`[health_reporter]` `alert.actions`	`<string>`The alert actions that will run when an alert is fired.
`[health_reporter]` `alert.min_duration_sec`	`<integer>`The minimum amount of time, in seconds, that the health status color must persist within threshold_color before triggering an alert.	60.
`[health_reporter]` `alert.threshold_color`	`[yellow\|red]`The health status color that will trigger an alert.	red.
`[health_reporter]` `alert.suppress_period`	`<integer>[m\|s\|h\|d]`The minimum amount of time, in [minutes\|seconds\|hours\|days], that must elapse between each fired alert. More Alerts that occur earlier will be sent as a batch after this time period elapses.	10m

`[clustering]`

Setting	Description	Default
`[clustering]` `health_report_period`	`<number>`The amount of time, in seconds, that elapses between each Clustering health report run.	20.
`[clustering]` `disabled`	`<boolean>`Whether or not the clustering feature health check is disabled. More A value of 1 disables the clustering feature health check.	0 (enabled)

`[data_management_health_reporter]`

Setting	Description	Default
`[data_management_health_reporter]` `disabled`	`<boolean>`Whether or not the health check for data management is disabled. More A value of 1 disables the health check for data management.	0 (enabled)
`[data_management_health_reporter]` `health_report_period`	`<number>`The time interval, in seconds, between each execution of the data management health report.	30

`[tree_view:health_subset]`

Defines a tree view for health features.
Users with 'list_health_subset' capability can view features belonging to this tree view.
Users with 'edit_health_subset' capability can edit thresholds for features belonging to this tree view.

`[feature:*]`

Setting	Description	Default
`[feature:*]` `suppress_status_update_ms`	`<number>`The minimum amount of time, in milliseconds, that must elapse between an indicator's health status changes. More Changes that occur earlier are suppressed.	300.
`[feature:*]` `suppress_status_reason_update_s`	`<number>`The minimum amount of time, in seconds, that must elapse between a change to the reason for the indicator. More Changes that occur earlier are suppressed.	3.
`[feature:*]` `display_name`	`<string>`A human readable name for the feature.
`[feature:*]` `distributed_disabled`	`<boolean>`Whether or not the distributed health report (DHR) tree view includes information about this feature. More A value of "true" means that the DHR does not include this feature in its tree view, which means you won't see it when you open the Health Report in Splunk Web. This value doesn't apply to the ability of the feature to generate alerts, as appropriate. A value of "false" means that the DHR includes this feature in its tree view.	0
`[feature:*]` `snooze_end_time`	`<number>`Determines the snooze end time, in seconds since the epoch (Unix time), for this feature. Specifying a value for this setting enables a snooze period that suppresses color changes for a feature until the <snooze_end_time>. More A value of 0 disables snoozing for this feature. Default = 0
`[feature:*]` `alert.disabled`	`<boolean>`Whether or not alerting is disabled for this feature. More A value of 1 disables alerting for this feature. If alerting is disabled in the [health_reporter] stanza, alerting for this feature is disabled, regardless of the value set here. Otherwise, if the value is set to 1, alerting for all indicators is disabled.	0 (enabled)
`[feature:*]` `alert.min_duration_sec`	`<integer>`The minimum amount of time, in seconds, that the health status color must persist within threshold_color before triggering an alert.
`[feature:*]` `alert.threshold_color`	`[yellow\|red]`The health status color to trigger an alert.	red.
`[feature:*]` `friendly_description`	`<string>`A general description to help the user determine what functionality is monitored by the heath report indicator.
`[feature:*]` `indicator:<indicator name>:friendly_description`	`<string>`A general description of the technical behavior monitored by the indicator. Use common terminology that a user can search on to find documentation, details, or troubleshooting guidance.
`[feature:*]` `indicator:<indicator name>:description`	`<string>`Description of this indicator to help users to make basic decisions such as: Turning indicators on or off Adjusting the threshold of an indicator Turning on alerting for an indicator
`[feature:*]` `indicator:<indicator name>:<indicator color>`	`<number>`There are various indicator names. See your health.conf for the complete list. More There are two valid colors: yellow and red. These settings should not be adjusted lightly. If the numbers are set too high, you might inadvertently mask serious errors that the Health Report is trying to bring to your attention.
`[feature:*]` `alert:<indicator name>.disabled`	`[0\|1]`A value of 1 disables alerting for this indicator.	0 (enabled)
`[feature:*]` `alert:<indicator name>.min_duration_sec`	`<integer>`The minimum amount of time, in seconds, that the health status color must persist within threshold_color before triggering an alert.
`[feature:*]` `alert:<indicator name>.threshold_color`	`[yellow\|red]`The health status color to trigger an alert.
`[feature:*]` `tree_view:health_subset`	`[enabled \| disabled]`Indicates that this feature belongs to the 'health_subset' tree view.

`[alert_action:*]`

Setting	Description	Default
`[alert_action:*]` `disabled`	`[0\|1]`A value of 1 disables this alert action.	0 (enabled)
`[alert_action:*]` `action.<action parameter>`	`<string>`There are various parameters for different alert actions. More Each value defines one parameter for the alert action. NOTE: [feature:master_connectivity], [feature:slave_state] feature:slave_version] stanzas are now DEPRECATED.

File locations

Configuration file: health.conf.

Scope	Path
System	`$SPLUNK_HOME/etc/system/{default,local}/health.conf`

No app-level location was found during verification -- unlike most files in this reference, health.conf appears to be a system-scope-only file, not confirmed as app-overridable.

Validation

distributed_disabled in a [feature:<name>] stanza only hides that feature from the distributed health report's tree view -- it doesn't stop the feature's alerts.
Use alert.disabled (or alert:<indicator name>.disabled for one indicator) when the health signal is still wanted but its alert isn't.
Consult the shipped default health.conf for the authoritative indicator names before setting per-indicator thresholds -- don't guess an indicator name.

← Back to References

References / Splunk platform configuration

Internal Logging Configuration

log.cfg governs Splunk's own internal logging verbosity -- the one file in this reference that lives at a fixed path rather than the standard etc/system/{default,local} layering every other file here uses.

Definition

Component-hierarchical logging levels for Splunk's Python-side processes (notably Splunk Web). Setting a parent component's level cascades to every child component beneath it unless a more specific child entry overrides it.

Settings

Stanza / Setting	Description
`[python]` `<component> = <level>`	Sets the logging level (e.g. `DEBUG`, `INFO`, `WARN`) for a named, hierarchical Python component such as `splunk`, `splunk.appserver`, or `splunk.appserver.controllers`.

Splunkd's own C++-side logging uses a separate mechanism (log-btool.cfg, log-searchprocess.cfg and other sibling files) not covered on this lighter entry.

File locations

Configuration file: log.cfg.

Scope	Path
Shipped	`$SPLUNK_HOME/etc/log.cfg`
Local override	`$SPLUNK_HOME/etc/log-local.cfg`

Not the usual default/local subdirectory pattern -- these are two sibling files directly under etc/. log-local.cfg takes precedence over log.cfg and survives an upgrade; log.cfg itself is overwritten on upgrade, so persistent changes belong in log-local.cfg. Related sibling files exist for other invocation contexts: log-cmdline.cfg, log-cmdline-debug.cfg, log-searchprocess.cfg, log-btool.cfg, log-btool-debug.cfg, log-utility.cfg, log-debug.cfg.

Example

[python]
splunk = DEBUG
splunk.appserver = INFO
splunk.appserver.controllers = INFO

Debug-level logging for the top-level splunk component, with the app-server branch pinned back to INFO so it doesn't inherit the parent's verbosity.

Validation

Edit log-local.cfg, never log.cfg directly -- log.cfg is overwritten on the next upgrade.
Restart the affected process (splunkweb for [python] changes) after editing -- this is not a live-reloadable file.
Remember component names are hierarchical -- setting a broad parent component's level affects every child beneath it unless a more specific override exists.

← Back to References

References / Splunk platform configuration

Agent Management Configuration

agent_management.conf configures the agent management feature's helper process: how it talks to splunkd, the searches it runs to track agents, and how it stores and prunes agent data.

Definition

[general] sets a global request_timeout and the repository_type (the storage layer agent management uses). [search_client] sets the polling interval and the SPL searches that find agents in error, offline agents, agents with updated configurations, agent versions and an app status summary. [splunkd_client] covers the connection pool and timeouts for calls to splunkd, and [settings_sync] how often it retrieves the Deployment Server settings. [effective_configuration] limits the effective configuration data universal forwarders send and schedules its cleanup; [telemetry] controls product telemetry; and [repository_database] tunes agent-matching refresh, record pruning, event ingestion and stale CSV cleanup.

fallback_to_deployment_server_ui and log_level are removed. Settings go in etc/system/local; changes need a restart.

Config

Settings

Every stanza and setting in agent_management.conf.spec from Splunk Enterprise 10.4.2: 38 settings across 7 stanzas. Descriptions use the spec's own wording -- the first line shows here and More opens the rest. The Default column is filled only where the spec gives a Default: line.

`[general]`

Agent management helper process settings. This stanza must exist.

Setting	Description	Default
`[general]` `fallback_to_deployment_server_ui`	`<boolean>`REMOVED. This setting is no longer used.
`[general]` `log_level`	`<string>`REMOVED. Use $SPLUNK_HOME/etc/log-node-platform-local.cfg settings instead. More See $SPLUNK_HOME/etc/log-node-platform.cfg for detailed instructions.
`[general]` `request_timeout`	`<string>`A global request timeout setting that defines how long the agent management processes a request before it times out. More Valid values are numbers followed by a time unit. Valid time units are "ms", "s", "m", "h".	5m.
`[general]` `repository_type`	`<string>`The type of storage layer that agent management uses. More Valid values are "ds" and "database". A value of "ds" means agent management uses the deployment server as the storage layer. A value of "database" means agent management uses a database as the storage layer.	database

`[search_client]`

Agent management helper process settings for the SPL subsystem.

Setting	Description	Default
`[search_client]` `polling_interval`	`<string>`How long the agent management waits between HTTP calls to retrieve search results. More Valid values are numbers followed by a time unit. Valid time units are "ms", "s", "m", "h".	500ms.
`[search_client]` `query_agents_with_error`	`<string>`The SPL search that is run to obtain a list of agents with a status of "error".
`[search_client]` `query_agents_offline`	`<string>`The SPL search that is run to obtain a list of offline agents.
`[search_client]` `query_agents_updated_config`	`<string>`The SPL search that is run to obtain a list of agents with updated configurations.
`[search_client]` `query_agent_version`	`<string>`The SPL search that is run to obtain a list of agents and their corresponding versions.
`[search_client]` `query_app_summary`	`<string>`The SPL search that is run to obtain a summary of the status of each application.

`[splunkd_client]`

Agent management helper process settings that are used for communicating with splunkd.

Setting	Description	Default
`[splunkd_client]` `connection_pool_size`	`<integer>`The number of HTTP connections that can be handled simultaneously by the agent management.	10
`[splunkd_client]` `request_timeout`	`<string>`A time limit for HTTP requests made by the agent management to splunkd. More Valid values are numbers followed by a time unit. Valid time units are "ms", "s", "m", "h".	285s
`[splunkd_client]` `connection_keep_alive`	`<string>`The maximum amount of time an idle connection made by the agent management to splunkd remains idle before closing. More This value must be set lower than the 'busyKeepAliveIdleTimeout' setting in server.conf, '[httpServer]' stanza. Valid values are numbers followed by a time unit. Valid time units are "ms", "s", "m", and "h".	11s

`[settings_sync]`

The agent management helper process settings for the settings synchronization subsystem.
The settings synchronization subsystem periodically obtains the Deployment Server settings.

Setting	Description	Default
`[settings_sync]` `polling_interval`	`<string>`How long the agent management waits between HTTP calls to retrieve the Deployment Server settings. More Valid values are numbers followed by a time unit. Valid time units are "ms", "s", "m", "h".	5m.

`[effective_configuration]`

Settings dedicated to the Effective Configuration feature.

Setting	Description	Default
`[effective_configuration]` `max_size`	`<positive integer>`The maximum size, in megabytes, of the effective configuration that the universal forwarder sends to the agent management, and that the deployment server saves. More The effective configuration of the forwarder is comprised of the rules of operation and data processing for the forwarder, specifically, the configuration as shown by various 'splunk btool' commands. If the size of the effective configuration for a forwarder exceeds this value, then the agent management rejects the payload as too large, and the deployment server does not save the configuration. Must be a positive number.	16
`[effective_configuration]` `cleanup_threshold`	`<positive integer>`The limit of the total size of all effective configurations data on the disk (in MB). When this limit is exceeded, the scheduled cron cleanup job will perform the cleanup. More There is no maximum value for this setting, a very large value (over 10000) can cause the cleanup to never run. Must be a positive number.	6144
`[effective_configuration]` `cleanup_schedule`	`<string>`The cron schedule for cleaning up the effective configuration data. More The default schedule is set to 3:00 AM every day in the local time zone. To turn off the effective configuration cleanup, set the value to "disabled". Must be in the cron format.	0 3 * * *

`[telemetry]`

Agent management settings for product telemetry data collection.
These settings control whether and how the agent management collects telemetry data.
Sending telemetry data to the Splunk platform is done according to rules defined in the 'telemetry.conf' file.

Setting	Description	Default
`[telemetry]` `enabled`	`<boolean>`A value of "true" enables product telemetry collection in agent management. More A value of "false" disables product telemetry collection. This flag does not override settings from the 'telemetry.conf' file. In particular, collected data will not be sent to the Splunk platform until proper consent is given in general telemetry settings for the Splunk software instance.	true
`[telemetry]` `cron_schedule`	`<string>`The cron schedule for telemetry data collection by agent management. More The default schedule is set to 3:15 AM every day in the local time zone. The value must be in cron format.	15 3 * * *
`[telemetry]` `collection_timeout`	`<string>`The maximum amount of time agent management can spend processing the whole telemetry collection operation. More Valid values are numbers followed by a time unit. Minimum value is 1s. Valid time units are "s", "m", "h".	10m
`[telemetry]` `job_timeout`	`<string>`The maximum amount of time agent management can spend on running a single telemetry job, which is a part of whole telemetry collection. More Valid values are numbers followed by a time unit. Minimum value is 1s. Valid time units are "s", "m", "h".	5m

`[repository_database]`

Agent management data retrieval and storage settings for the database repository.
Settings prefixed with 'agents_matching' configure how agent management retrieves server classes and apps matching to each connected agent based on the criteria configured in serverclass.conf.

Setting	Description	Default
`[repository_database]` `agents_matching_refresh_batch_size`	`<positive integer>`The number of agent entries processed in a single batch during the agent matching refresh operation.	10000
`[repository_database]` `agents_matching_refresh_interval_s`	`<positive integer>`How often, in seconds, the agent matching data is refreshed in the background.	60
`[repository_database]` `agents_matching_max_concurrent_ds_requests`	`<positive integer>`The maximum number of concurrent requests that agent management can make to the deployment server to obtain agents matching data.	10
`[repository_database]` `agents_matching_refresh_timeout_m`	`<positive integer>`The maximum amount of time, in minutes, that a single matching refresh request can run before it times out.	20
`[repository_database]` `database_prune_interval_h`	`<positive integer>`How often, in hours, the agent management prunes stale agent, server class, and app records from the database.	24
`[repository_database]` `database_items_ttl_h`	`<positive integer>`The time-to-live, in hours, for inactive agent, server class, and app records in the database. More Records older than this value are eligible for pruning.	744 (31 days)
`[repository_database]` `app_events_file_limit`	`<positive integer>`The maximum number of app event files retained by the database repository.	10
`[repository_database]` `app_events_ingestion_interval_m`	`<positive integer>`How often, in minutes, agent management ingests app event files into the database.	1
`[repository_database]` `app_events_ingestion_batch_size`	`<positive integer>`The number of app event entries processed in a single ingestion batch.	10000
`[repository_database]` `client_events_file_limit`	`<positive integer>`The maximum number of client event files retained by the database repository.	10
`[repository_database]` `client_events_ingestion_interval_m`	`<positive integer>`How often, in minutes, agent management ingests client event files into the database.	1
`[repository_database]` `client_events_ingestion_batch_size`	`<positive integer>`The number of client event entries processed in a single ingestion batch.	10000
`[repository_database]` `phonehome_events_file_limit`	`<positive integer>`The maximum number of phonehome event files retained by the database repository.	10
`[repository_database]` `phonehome_events_ingestion_interval_m`	`<positive integer>`How often, in minutes, agent management ingests phonehome event files into the database.	1
`[repository_database]` `phonehome_events_ingestion_batch_size`	`<positive integer>`The number of phonehome event entries processed in a single ingestion batch.	10000
`[repository_database]` `stale_csv_cleanup_interval_m`	`<positive integer>`How often, in minutes, agent management runs the stale comma-separated value (CSV) file cleanup operation.	60
`[repository_database]` `stale_csv_cleanup_ttl_m`	`<positive integer>`The maximum age, in minutes, of CSV files before agent management considers them stale and eligible for cleanup.	10080 (7 days)

File locations

Scope	Path
System	`$SPLUNK_HOME/etc/system/{default,local}/agent_management.conf`

← Back to References

References / Splunk platform configuration

Authentication Node Configuration

authentication_node.conf holds node-local authentication settings -- the OAuth2 internal clients defined on this instance.

Definition

Each [client_<id>] stanza defines one OAuth2 internal client: its id (matching the stanza suffix) and name, the grantTypes it can use, jwks -- the public keys used to verify its signed client assertions -- the roles it's granted, tokenEndpointAuthMethod (private_key_jwt), instanceId, redirectUris, responseTypes and scopes. Place it in $SPLUNK_HOME/etc/system/local.

Capabilitiesedit_authentication_node list_authentication_node edit_internal_oauth_clients list_internal_oauth_clients

Settings

Every stanza and setting in authentication_node.conf.spec from Splunk Enterprise 10.4.2: 10 settings across 1 stanza. Descriptions use the spec's own wording -- the first line shows here and More opens the rest. The Default column is filled only where the spec gives a Default: line.

`[client_<string>]`

Settings that define an OAuth2 internal client.
The '<string>' suffix in this stanza heading is the client ID.

Setting	Description	Default
`[client_<string>]` `id`	`<string>`The client ID, as defined in the suffix of this stanza. More The Splunk platform uses this value to identify the client during request handling and to look up the client configuration. Required.	No default
`[client_<string>]` `name`	`<string>`A human-readable name for the OAuth2 client. More This value does not have to be unique because the ID string in the stanza name identifies the client. Required.	No default
`[client_<string>]` `grantTypes`	`<semicolon-separated list>`A list of OAuth2 grant types that this client can use. More Valid values are "client_credentials" and "authorization_code". The list can contain either or both of these values. A value of "client_credentials" means that service-to-service grants are allowed for this OAuth2 client. These grants do not involve an end user. The client authenticates with its own credentials and acts on its own behalf. When 'grantTypes' includes "client_credentials", you must provide one or more roles for the 'roles' setting. A value of "authorization_code" means that this OAuth2 client can use user-to-service grants. These grants involve an end user. The client obtains authorization and acts on behalf of the authenticated user. Required.	No default
`[client_<string>]` `jwks`	`<string>`A JSON Web Key Set (JWKS) array of public keys that the Splunk platform uses to verify the signature on a signed client assertion and authenticate the OAuth2 client. More When specifying a value for this setting, use the following format: {"keys":[{<string>:<string>,<string>:<string>,...}]} Required if 'tokenEndpointAuthMethod' has a value of "private_key_jwt".	No default
`[client_<string>]` `roles`	`<semicolon-separated list>`A list of roles that the Splunk platform grants to the OAuth2 client. More Required when 'grantTypes' includes the value "client_credentials".	No default
`[client_<string>]` `tokenEndpointAuthMethod`	`private_key_jwt`The requested authentication method. More The only valid value is "private_key_jwt". Required.	No default
`[client_<string>]` `instanceId`	`<string>`The Splunk instance ID. More This ID is a globally unique identifier (GUID). You can obtain this ID by running an HTTP GET method against the /services/server/info REST endpoint and extracting the "guid" field. Required.	No default
`[client_<string>]` `redirectUris`	`<semicolon-separated list>`A list of OAuth2 redirect URIs. More Required when 'grantTypes' includes the value "authorization_code". Optional otherwise.	No default
`[client_<string>]` `responseTypes`	`<semicolon-separated list>`A list of OAuth2 response types. More Optional.	No default
`[client_<string>]` `scopes`	`<semicolon-separated list>`A list of OAuth2 scopes that the OAuth2 client requests. More Optional.	No default

File locations

Scope	Path
System	`$SPLUNK_HOME/etc/system/local/authentication_node.conf`

← Back to References

References / Splunk platform configuration

Global Banner Configuration

global-banner.conf configures a banner at the top of every page in Splunk Web, above the Splunk bar.

Settings

Every stanza and setting in global-banner.conf.spec from Splunk Enterprise 10.4.2: 5 settings across 1 stanza. Descriptions use the spec's own wording -- the first line shows here and More opens the rest. The Default column is filled only where the spec gives a Default: line.

`[BANNER_MESSAGE_SINGLETON]`

IMPORTANT: It is only possible to declare one global banner. This is the only stanza that Splunk Web will read.

Setting	Description	Default
`[BANNER_MESSAGE_SINGLETON]` `global_banner.visible`	`<bool>`No description in the spec.	false
`[BANNER_MESSAGE_SINGLETON]` `global_banner.message`	`<string>`No description in the spec.	Sample banner notification text. Please replace with your own message.
`[BANNER_MESSAGE_SINGLETON]` `global_banner.background_color`	`[green\|blue\|yellow\|orange\|red]`No description in the spec.	blue
`[BANNER_MESSAGE_SINGLETON]` `global_banner.hyperlink`	`[http://<string>\|https://<string>]`No description in the spec.	none
`[BANNER_MESSAGE_SINGLETON]` `global_banner.hyperlink_text`	`<string>`No description in the spec.	none

← Back to References

References / Splunk platform configuration

Monitoring Console Checklist Configuration

checklist.conf defines Monitoring Console health checks.

Definition

Each [<uniq-check-item-name>] stanza is one check. title, category and search are required; optional settings add a description, failure_text, a suggested_action, a documentation link (doc_link, doc_title), a drilldown, tags, the groups it applies to (applicable_to_groups) and environments to skip (environments_to_exclude). disabled = 1 turns a check off. Per the spec, checks you add yourself belong in your app's local directory.

Not the same as health.conf, which configures splunkd's health report.

Config

Settings

Every stanza and setting in checklist.conf.spec from Splunk Enterprise 10.4.2: 13 settings across 1 stanza. Descriptions use the spec's own wording -- the first line shows here and More opens the rest. The Default column is filled only where the spec gives a Default: line.

`[<uniq-check-item-name>]`

A unique string for the name of this health check.

Setting	Description	Default
`[<uniq-check-item-name>]` `title`	`<ASCII string>`(required) Displayed title for this health check.
`[<uniq-check-item-name>]` `category`	`<ASCII string>`(required) Category for overarching goups of health check items.
`[<uniq-check-item-name>]` `tags`	`<ASCII string>`(optional) Comma separated list of tags that apply to this health check. More If omitted user will not be able to run this health check as part of a subset of health checks.
`[<uniq-check-item-name>]` `description`	`<ASCII string>`(optional) A description of what this health check is checking. More If omitted no description will be displayed.
`[<uniq-check-item-name>]` `failure_text`	`<ASCII string>`If this health check did not pass, the text that you specify in this setting can explain what went wrong. More While this setting is optional, if you do not specify a value for this setting, this health check does not display any text that helps identify why it did not pass.
`[<uniq-check-item-name>]` `suggested_action`	`<ASCII string>`(optional) Suggested actions for diagnosing and fixing your Splunk installation so this health check is no longer failing. More If omitted no suggested actions for fixing this health check will be displayed.
`[<uniq-check-item-name>]` `doc_link`	`<ASCII string>`(optional) Location string for help documentation for this health check. More If omitted no help link will be displayed to help the user fix this health check. Can be a comma separated list if more than one documentation link is needed.
`[<uniq-check-item-name>]` `doc_title`	`<ASCII string>`(optional) Title string for help documentation link for this health check. More Must be included if doc_link exists. Will be inserted in the text for the help documentation link like so: "Learn more about $doc_title$" If doc_link is a comma separated list, then doc_title must also be a comma separated list with one title per item corresponding to doc_link.
`[<uniq-check-item-name>]` `applicable_to_groups`	`<ASCII string>`(optional) Comma separated list of applicable groups that this check should be run against. More If omitted this check item can be applied to all groups.
`[<uniq-check-item-name>]` `environments_to_exclude`	`<ASCII string>`(optional) Comma separated list of environments that the health check should not run in. More Possible environments are 'standalone' and 'distributed' If omitted this check can be applied to all groups.
`[<uniq-check-item-name>]` `disabled`	`<boolean>`Disable this check item by setting to 1.	0
`[<uniq-check-item-name>]` `search`	`<ASCII string>`(required) Search string to be run to perform the health check. More Please separate lines by "\" if the search string has multiple lines. In single-instance mode, this search will be used to generate the final result. In multi-instance mode, this search will generate one row per instance in the result table. THE SEARCH RESULT NEEDS TO BE IN THE FOLLOWING FORMAT: \|--------------------------------------------------------------- \| instance \| metric \| severity_level \| \|--------------------------------------------------------------- \| <instance name> \| <metric number or string> \| <level number> \| \|--------------------------------------------------------------- \| ... \| ... \| ... \| \|--------------------------------------------------------------- <instance name> (required, unique) is either the "host" field of events or the "splunk_server" field of "\| rest" search. In order to generate this field, please do things like: ... \| rename host as instance or ... \| rename splunk_server as instance <metric number or string> (optional) one ore more columns to "show your work" This should be the data that severity_level is determined from. The user should be able to look at this field to get some idea of what made the instance fail this check. <level number> (required) could be one of the following: - -1 (N/A) means: "Not Applicable" - 0 (ok) means: "all good" - 1 (info) means: "just ignore it if you don't understand" - 2 (warning) means: "well, you'd better take a look" - 3 (error) means: "FIRE!" Please also note that the search string must contain either of the following token to properly scope to either a single instance or a group of instances, depending on the settings of checklistsettings.conf. $rest_scope$ - used for "\|rest" search $hist_scope$ - used for historical search
`[<uniq-check-item-name>]` `drilldown`	`<ASCII string>`(optional) Link to a search or Monitoring Console dashboard for additional information. More Please note that the drilldown string must contain a $ delimited string. This string must match one of the fields output by the search. Most dashboards will need the name of the instance, eg $instance$

File locations

Scope	Path
App	`$SPLUNK_HOME/etc/apps/<app_name>/local/checklist.conf`

← Back to References

References / Splunk platform configuration

Process Monitor Filters Configuration

procmon-filters.conf is deprecated. It held regular-expression filters for the Windows processes Splunk monitors.

Definition

Deprecated. Each [<stanza name>] is one filter: proc is a regular expression for the process image to monitor and type one for the process event types; hive isn't used here and should always be .*. The spec's header describes the file as configuring Windows registry monitoring, but its settings filter processes. Changes need a restart.

Settings

Every stanza and setting in procmon-filters.conf.spec from Splunk Enterprise 10.4.2: 3 settings across 1 stanza. Descriptions use the spec's own wording -- the first line shows here and More opens the rest. The Default column is filled only where the spec gives a Default: line.

`[<stanza name>]`

The name of the filter being defined.

Setting	Description	Default
`[<stanza name>]` `proc`	`<string>`A regular expression that specifies process image that you want the Splunk platform to monitor.	No default
`[<stanza name>]` `type`	`<string>`A regular expression that specifies the type(s) of process events that you want the Splunk platform to monitor.	No default
`[<stanza name>]` `hive`	`<string>`Not used in this context, but should always have value ".*"

File locations

Scope	Path
System	`$SPLUNK_HOME/etc/system/{default,local}/procmon-filters.conf`

← Back to References

References / Splunk platform configuration

Source Classifier Configuration

source-classifier.conf configures the file classifier Splunk uses when it learns source types.

Definition

Two settings, outside any stanza: ignored_model_keywords -- terms to ignore when generating a sourcetype model -- and ignored_filename_keywords -- terms to ignore when comparing a new source name with known source names to classify it. Settings go in etc/system/local; changes need a restart.

Config

Settings

Every stanza and setting in source-classifier.conf.spec from Splunk Enterprise 10.4.2: 2 settings across 0 stanzas. Descriptions use the spec's own wording -- the first line shows here and More opens the rest. The Default column is filled only where the spec gives a Default: line.

Settings outside any stanza

Setting	Description	Default
`ignored_model_keywords`	`<space-separated list of terms>`Terms to ignore when generating a sourcetype model. More To prevent sourcetype "bundles/learned/*-model.xml" files from containing sensitive terms (e.g. "bobslaptop") that occur very frequently in your data files, add those terms to ignored_model_keywords.
`ignored_filename_keywords`	`<space-separated list of terms>`Terms to ignore when comparing a new sourcename against a known sourcename, for the purpose of classifying a source.

File locations

Scope	Path
System	`$SPLUNK_HOME/etc/system/{default,local}/source-classifier.conf`

← Back to References

References / Splunk platform configuration

Time Ranges Configuration

times.conf defines the time ranges offered in Splunk Web's time range picker, and which of the picker's panels are shown.

Definition

Each [<timerange_name>] stanza is one time range; the stanza name is the token used for it through the API or command line. It has a label (and a header_label shown with results), earliest_time and latest_time, an order for sorting, and disabled = 1 to hide it. [settings] shows or hides the picker's panels: show_presets, show_relative, show_realtime, show_date_range, show_datetime_range and show_advanced. sub_menu and is_sub_menu are removed. Changes need a restart.

Settings

Every stanza and setting in times.conf.spec from Splunk Enterprise 10.4.2: 14 settings across 2 stanzas. Descriptions use the spec's own wording -- the first line shows here and More opens the rest. The Default column is filled only where the spec gives a Default: line.

`[<timerange_name>]`

The token to use when accessing time ranges through the API or command line.
A times.conf file can contain multiple stanzas.

Setting	Description	Default
`[<timerange_name>]` `label`	`<string>`The textual description used by the UI to reference this time range. More Required
`[<timerange_name>]` `header_label`	`<string>`The textual description used by the UI when displaying search results in this time range. More Optional.	The <timerange_name>
`[<timerange_name>]` `earliest_time`	`<string>`The string that represents the time of the earliest event to return, inclusive. More The time can be expressed with a relative time identifier or in UNIX time. Optional. No default (No earliest time bound is used)
`[<timerange_name>]` `latest_time`	`<string>`The string that represents the time of the earliest event to return, inclusive. More The time can be expressed with a relative time identifier or in UNIX time. Optional. NOTE: events that occur in the future (relative to the server timezone) might be returned. No default (No latest time bound is used)
`[<timerange_name>]` `order`	`<integer>`The key on which all custom time ranges are sorted, ascending. More The default time range selector in the UI will merge and sort all time ranges according to the 'order' key, and then alphabetically. Optional.	0
`[<timerange_name>]` `disabled`	`<integer>`Specifies if the menu item is shown. Set to 1 to hide menu item. More Optional.	0
`[<timerange_name>]` `sub_menu`	`<submenu name>`REMOVED. This setting is no longer used.
`[<timerange_name>]` `is_sub_menu`	`<boolean>`REMOVED. This setting is no longer used.

`[settings]`

List of flags that modify the panels that are displayed in the time range picker.

Setting	Description	Default
`[settings]` `show_advanced`	`<boolean>`Specifies if the 'Advanced' panel should be displayed in the time range picker. More Optional.	true
`[settings]` `show_date_range`	`<boolean>`Specifies if the 'Date Range' panel should be displayed in the time range picker. More Optional.	true
`[settings]` `show_datetime_range`	`<boolean>`Specifies if the 'Date & Time Range' panel should be displayed in the time range picker. More Optional.	true
`[settings]` `show_presets`	`<boolean>`Specifies if the 'Presets' panel should be displayed in the time range picker. More Optional.	true
`[settings]` `show_realtime`	`<boolean>`Specifies if the 'Realtime' panel should be displayed in the time range picker. More Optional.	true
`[settings]` `show_relative`	`<boolean>`Specifies if the 'Relative' panel should be displayed in the time range picker. More Optional.	true

File locations

Scope	Path
System	`$SPLUNK_HOME/etc/system/{default,local}/times.conf`
App	`$SPLUNK_HOME/etc/apps/<app_name>/{default,local}/times.conf`

← Back to References

References / Splunk platform configuration

WMI Inputs Configuration

wmi.conf configures Windows Management Instrumentation (WMI) data collection on Windows: how the WMI input retries and checkpoints, and one stanza per input naming the servers to poll and the data to collect.

Definition

Windows only. [settings] holds the retry backoff for failed connections to a WMI provider (initial_backoff, max_backoff, max_retries_at_max_backoff) and checkpoint_sync_interval. Each [WMI:<name>] stanza is one input: the servers to poll, the polling interval, the destination index, and either event_log_file (Event Log channels) or wql with an optional namespace (a query against a WMI provider).

The spec puts the shipped default in %SPLUNK_HOME%\etc\system\default\ and your settings in %SPLUNK_HOME%\etc\system\local\; changes need a restart.

Settings

Every stanza and setting in wmi.conf.spec from Splunk Enterprise 10.4.2: 25 settings across 2 stanzas. Descriptions use the spec's own wording -- the first line shows here and More opens the rest. The Default column is filled only where the spec gives a Default: line.

`[settings]`

Specifies parameters for the WMI input.
The entire stanza and every parameter within it is optional.
If the stanza is missing, Splunk Enterprise assumes system defaults.

Setting	Description	Default
`[settings]` `initial_backoff`	`<integer>`How long, in seconds, to wait before retrying the connection to the WMI provider after the first connection error. More If connection errors continue, the wait time doubles until it reaches the integer specified in 'max_backoff'.	5
`[settings]` `max_backoff`	`<integer>`How long, in seconds, to attempt to reconnect to the WMI provider.	20
`[settings]` `max_retries_at_max_backoff`	`<integer>`When the WMI input has connection errors to the WMI provider, it backs off connection attempts by doubling the amount of time it waits between connection attempts. It modifies attempts from an initial interval of 'initial_backoff' seconds to an interval specified 'max_backoff' seconds. More After the input has waited 'max_backoff' seconds between connection attempts, and while connection errors persist, this setting tells the input how many times it should continue trying to connect at the 'max_backoff' interval. If reconnection to the WMI provider fails after 'max_retries' attempts, the input gives up and does not attempt further connections until you restart Splunk Enterprise.	2
`[settings]` `checkpoint_sync_interval`	`<integer>`How long, in seconds, to wait for state data (event log checkpoint) to be written to disk.	2

`[WMI:<name>]`

There are two types of WMI input stanza:
Event log stanza: Used to collect Windows Event Logs. You must configure the 'event_log_file' setting.
Windows Query Language (WQL): Used to issue raw Windows Query Language (WQL) requests. You must configure the 'wql' setting.
Do not use both the 'event_log_file' amd 'wql' attributes. Use one or the other.

Setting	Description	Default
`[WMI:<name>]` `server`	`<comma-separated strings>`A comma-separated list of WMI providers (Windows machines) from which to get data.	the local machine
`[WMI:<name>]` `interval`	`<integer>`How often, in seconds, to poll the WMI provider for new data. More You must supply this setting. No default is supplied and the input does not run if the setting is not specified.	No default
`[WMI:<name>]` `disabled`	`<boolean>`Whether or not the input is enabled. More Set to 1 to disable the input, 0 to enable it.	0 (enabled).
`[WMI:<name>]` `hostname`	`<string>`All results generated by this stanza will appear to have arrived from the string you specify here. More This setting is optional.	input detects the host automatically
`[WMI:<name>]` `current_only`	`<boolean>`Changes the characteristics and interaction of WMI-based event collections. More When you set 'current_only' to 1: For event log stanzas, captures events that occur only while Splunk Enterprise is running. For WQL stanzas, the input expects event notification queries. The WMI class you query must support sending events. Failure to supply the correct event notification query structure causes WMI to return a syntax error to the input. An example event notification query that watches for process creation: SELECT * FROM __InstanceCreationEvent WITHIN 1 WHERE TargetInstance ISA 'Win32_Process'. When you set 'current_only' to 0: For event log stanzas, Splunk Enterprise gathers all the events from the checkpoint. If there is no checkpoint, Splunk Enterprise retrieves all events starting from the oldest. For WQL stanzas, Splunk Enterprise executes the query and retrieves the results. The query is a non-notification query. For example Select * Win32_Process where caption = "explorer.exe"	0
`[WMI:<name>]` `use_old_eventlog_api`	`<boolean>`Whether or not to read Event Log events with the Event Logging API rather than the Windows Event Log API. More This is an advanced setting. Contact Splunk Support before you change it. If set to "true", the input uses the Event Logging API (instead of the Windows Event Log API) to read from the Event Log on Windows Server 2008, Windows Vista, and later installations.	false (Use the API that is specific to the OS.)
`[WMI:<name>]` `use_threads`	`<integer>`The number of threads, in addition to the default writer thread, that can be created to filter events with the deny list or allow list regular expression. More This is an advanced setting. Contact Splunk Support before you change it. The maximum number of threads is 15.	0
`[WMI:<name>]` `thread_wait_time_msec`	`<integer>`The interval, in milliseconds, between attempts to re-read Event Log files when a read error occurs. More This is an advanced setting. Contact Splunk Support before you change it.	5000
`[WMI:<name>]` `suppress_checkpoint`	`<boolean>`Whether or not the Event Log strictly follows the 'checkpointInterval' setting when it saves a checkpoint. More By default, the Event Log input saves a checkpoint from between zero and 'checkpointInterval' seconds, depending on incoming event volume. This is an advanced setting. Contact Splunk Support before you change it.	false
`[WMI:<name>]` `suppress_sourcename`	`<boolean>`Whether or not to exclude the 'sourcename' field from events. More When set to "true", the input excludes the 'sourcename' field from events and throughput performance (the number of events processed per second) improves. This is an advanced setting. Contact Splunk Support before you change it.	false
`[WMI:<name>]` `suppress_keywords`	`<boolean>`Whether or not to exclude the 'keywords' field from events. More When set to "true", the input excludes the 'keywords' field from events and throughput performance (the number of events processed per second) improves. This is an advanced setting. Contact Splunk Support before you change it.	false
`[WMI:<name>]` `suppress_type`	`<boolean>`Whether or not to exclude the 'type' field from events. More When set to true, the input excludes the 'type' field from events and throughput performance (the number of events processed per second) improves. This is an advanced setting. Contact Splunk Support before you change it.	false
`[WMI:<name>]` `suppress_task`	`<boolean>`Whether or not to exclude the 'task' field from events. More When set to "true", the input excludes the 'task' field from events and thruput performance (the number of events processed per second) improves. This is an advanced setting. Contact Splunk Support before you change it.	false
`[WMI:<name>]` `suppress_opcode`	`<boolean>`Whether or not to exclude the 'opcode' field from events. More When set to "true", the input excludes the 'opcode' field from events and throughput performance (the number of events processed per second) improves. This is an advanced setting. Contact Splunk Support before you change it.	false
`[WMI:<name>]` `batch_size`	`<integer>`Number of events to fetch on each query.	10
`[WMI:<name>]` `checkpointInterval`	`<integer>`How often, in seconds, that the Windows Event Log input saves a checkpoint. More Checkpoints store the event ID of acquired events. This lets the input continue monitoring at the correct event after a shutdown or outage.	0
`[WMI:<name>]` `index`	`<string>`Specifies the index that this input should send the data to. More This setting is optional. When you define 'index', the input prepends "index=" to <string>.	"index=main" (or whatever you have set as your default index).
`[WMI:<name>]` `event_log_file`	`<string> <Application, System, etc>`Tells the input to expect event log data for this stanza, and specifies the event log channels you want the input to monitor. More To specify Event Log sources, use this setting instead of WQL. Specify one or more event log channels to poll. You must separate multiple Event Log channels with commas. For exmaple, to include the Application and System channels, specify "Application, System".	No default
`[WMI:<name>]` `disable_hostname_normalization`	`<boolean>`Whether or not the WMI input normalizes hostnames from 'localhost' to what is present in the %COMPUTERNAME% Windows system variable. More If set to "true", hostname normalization is disabled. If set to "false" or not set, the input converts the hostname for 'localhost' to %COMPUTERNAME%. 'localhost' refers to the following list of strings: localhost 127.0.0.1 ::1 the name of the DNS domain for the local computer the fully qualified DNS name the NetBIOS name the DNS host name of the local computer
`[WMI:<name>]` `wql`	`<string>`Configures the WMI input to expect data from a WMI provider for this stanza, and specifies the Windows Query Language query you want the input to make to gather that data. More Use this if you are not using the 'event_log_file' setting. Ensure that your WQL queries have the correct syntax and structure when you use this option. For example, SELECT * FROM Win32_PerfFormattedData_PerfProc_Process WHERE Name = "splunkd". If you want to use event notification queries, you must also set the "current_only" attribute to "1" within the stanza, and your query must be appropriately structured for event notification (meaning its WQL string must contain one or more of the GROUP, WITHIN or HAVING clauses.) For example, SELECT * FROM __InstanceCreationEvent WITHIN 1 WHERE TargetInstance ISA 'Win32_Process'	No default
`[WMI:<name>]` `namespace`	`<string>`The namespace where the WMI provider resides. More The namespace specification can either be relative (root\cimv2) or absolute (\\server\root\cimv2). If the server attribute is present, you cannot specify an absolute namespace.	root\cimv2.

File locations

Scope	Path
System	`%SPLUNK_HOME%\etc\system\{default,local}\wmi.conf`

← Back to References

References / Splunk platform configuration

Transaction Types Configuration

transactiontypes.conf defines named transaction types for the transaction search command, so a search can reuse a grouping definition instead of repeating its options.

Definition

Each [<TRANSACTIONTYPE>] stanza is one type: the fields events must share, limits on a transaction (maxspan, maxpause, maxevents), how one starts and ends (startswith, endswith), how many open transactions and events are held in memory (maxopentxn, maxopenevents) and whether evicted ones are kept (keepevicted). search seeds transactions of the type -- make it as specific as possible to limit the events retrieved.

The spec puts the shipped default in etc/system/default and your settings in etc/system/local; changes need a restart.

Settings

Every stanza and setting in transactiontypes.conf.spec from Splunk Enterprise 10.4.2: 14 settings across 1 stanza. Descriptions use the spec's own wording -- the first line shows here and More opens the rest. The Default column is filled only where the spec gives a Default: line.

`[<TRANSACTIONTYPE>]`

Create any number of transaction types, each represented by a stanza name and any number of the following attribute/value pairs.
Use the stanza name, [<TRANSACTIONTYPE>], to search for the transaction in Splunk Web.
If you do not specify a value for an attribute, the Splunk platform uses the default value.

Setting	Description	Default
`[<TRANSACTIONTYPE>]` `maxspan`	`[<integer> s\|m\|h\|d\|-1]`Set the maximum time span between the events in a transaction. More Can be in seconds, minutes, hours, or days, or -1 for an unlimited timespan. Example: 5s, 6m, 12h or 30d. The events in the transaction must span less than the integer specified for 'maxspan'. Events that exceed the 'maxspan' limit are treated as part of a separate transaction. If the value is negative, the 'maxspan' constraint is disabled and there is no limit. Events must be sorted in descending chronological order before the 'maxspan' argument is used.	maxspan=-1
`[<TRANSACTIONTYPE>]` `maxpause`	`[<integer> s\|m\|h\|d\|-1]`Set the maximum pause between the events in a transaction. More Can be in seconds, minutes, hours, or days, or -1 for an unlimited pause. Example: 5s, 6m, 12h or 30d. If the value is negative, the 'maxpause' constraint is disabled and there is no limit. Events must be sorted in descending chronological order before the 'maxpause' argument is used.	maxpause=-1
`[<TRANSACTIONTYPE>]` `maxevents`	`<integer>`The maximum number of events in a transaction. This constraint is disabled if the value is a negative integer.	maxevents=1000
`[<TRANSACTIONTYPE>]` `fields`	`<comma-separated list of fields>`If set, each event must have the same field(s) to be considered part of the same transaction. More Example: fields=host,cookie	""
`[<TRANSACTIONTYPE>]` `connected`	`< boolean>`Relevant only if 'fields' (see above) is not empty. Controls whether an event that is not inconsistent and not consistent with the fields of a transaction opens a new transaction (connected=true) or is added to the transaction. More An event can be not inconsistent and not field-consistent if it contains fields required by the transaction but none of these fields has been instantiated in the transaction (by a previous event addition).	true
`[<TRANSACTIONTYPE>]` `startswith`	`<transam-filter-string>`A search or eval filtering expression which, if satisfied by an event, marks the beginning of a new transaction. More Examples: startswith="login" startswith=(username=foobar) startswith=eval(speed_field < max_speed_field) startswith=eval(speed_field < max_speed_field/12)	empty string
`[<TRANSACTIONTYPE>]` `endswith`	`<transam-filter-string>`A search or eval filtering expression which, if satisfied by an event, marks the end of a transaction. More Examples: endswith="logout" endswith=(username=foobar) endswith=eval(speed_field > max_speed_field) endswith=eval(speed_field > max_speed_field/12) For 'startswith' and 'endswith' <transam-filter-string> has the following syntax: syntax: "<search-expression>" \| (<quoted-search-expression>) \| eval(<eval-expression>) Where: <search-expression> is a valid search expression that does not contain quotes <quoted-search-expression> is a valid search expression that contains quotes <eval-expression> is a valid eval expression that evaluates to a boolean. For example, startswith=eval(foo<bar*2) matches events where "foo" is less than 2 x "bar". Examples: "<search expression>": startswith="foo bar" <quoted-search-expression>: startswith=(name="mildred") <quoted-search-expression>: startswith=("search literal") eval(<eval-expression>): startswith=eval(distance/time < max_speed)	empty string
`[<TRANSACTIONTYPE>]` `maxopentxn`	`<int>`Specifies the maximum number of not yet closed transactions to keep in the open pool. When this limit is exceeded, the Splunk platform begins to evict transactions using LRU (least-recently-used memory cache algorithm) policy. More The default value of this attribute is read from the transactions stanza in limits.conf.
`[<TRANSACTIONTYPE>]` `maxopenevents`	`<int>`Specifies the maximum number of events that can be part of open transactions. When this limit is exceeded, the Splunk platform begins to evict transactions using LRU (least-recently-used memory cache algorithm) policy. More The default value of this attribute is read from the transactions stanza in limits.conf.
`[<TRANSACTIONTYPE>]` `keepevicted`	`<bool>`Specifies whether to output evicted transactions. Evicted transactions can be distinguished from non-evicted transactions by checking the value of the 'evicted' field, which is set to "1" for evicted transactions.	keepevicted=false
`[<TRANSACTIONTYPE>]` `mvlist`	`<bool>\|<field-list>`Specifies whether the multivalued fields of the transaction are (1) a list of the original events ordered in arrival order or (2) a set of unique field values ordered lexicographically. More If a comma or space delimited list of fields is provided, only those fields are rendered as lists.	mvlist=f
`[<TRANSACTIONTYPE>]` `delim`	`<string>`A string used to delimit the original event values in the transaction event fields.	" " (a single space)
`[<TRANSACTIONTYPE>]` `nullstr`	`<string>`The string value to use when rendering missing field values as part of mv fields in a transaction. More This option applies only to fields that are rendered as lists.	NULL
`[<TRANSACTIONTYPE>]` `search`	`<string>`A search string used to more efficiently seed transactions of this type. More Make the value as specific as possible, to limit the number of events that must be retrieved to find transactions. Example: sourcetype="sendmaill_sendmail"	"*" (all events)

File locations

Scope	Path
System	`$SPLUNK_HOME/etc/system/{default,local}/transactiontypes.conf`
App	`$SPLUNK_HOME/etc/apps/<app_name>/{default,local}/transactiontypes.conf`

← Back to References

References / Splunk platform configuration

Metadata Permissions Configuration

default.meta records who owns, can read and can change an app's objects -- at the level of the app, each category of object and individual objects -- and whether objects are shared beyond the app. Each app has its own.

Definition

Access is layered. To use an object, a user needs read access to the app, to the object's category in the app (for example [views]), and to the object itself; if any layer denies read, the object isn't accessible. To change an object they also need write access to it. To add or remove objects in an app they need write access to the app.

Objects are only visible in the app they were created in unless exported: export = system makes an object available in all apps. Exporting doesn't change access rules -- users still need read access to the app, category and object.

Stanzas & settings

Stanza / Setting	Description
`[]`	The app itself. Its `access` sets who can read the app's contents and who can share objects into it.
`[<category>]`	One category of objects in the app, such as `[views]` or `[savedsearches]`.
`[<category>/<object>]`	One object, such as `[views/index_status]`.
`access`	`read : [ <roles> ], write : [ <roles> ]` -- the roles that can read and the roles that can write; `*` means all users.
`export`	`system` makes the object available in all apps; `none` keeps it in this app.
`owner`	The object's owner, e.g. `admin`.

File locations

Scope	Path
App	`$SPLUNK_HOME/etc/apps/<app_name>/metadata/default.meta`
App (local)	`$SPLUNK_HOME/etc/apps/<app_name>/metadata/local.meta`

← Back to References

References / Splunk platform configuration

Field Filters Configuration

field_filters.conf defines field filters, which protect sensitive values in search results -- removing, hashing or replacing a field -- for chosen indexes, hosts, sources or sourcetypes.

Definition

Each [<fieldFilterName>] stanza is one filter. action sets what happens to a field: null() removes it from the results of searches the filter applies to, sha256() or sha512() hash it, a string literal replaces it, and sed() rewrites it. index and limit (one of host, source or sourcetype) scope the filter. roleExemptions is generated by Splunk Web or the REST API; don't edit it by hand.

Read first: the spec advises against field filters in production if you run Splunk Enterprise Security, or rely heavily on the commands they restrict by default (mpreview and mstats), until you've planned how to work around those restrictions.

Capabilitiesedit_field_filter list_field_filter run_commands_ignoring_field_filter

Settings

Every stanza and setting in field_filters.conf.spec from Splunk Enterprise 10.4.2: 5 settings across 1 stanza. Descriptions use the spec's own wording -- the first line shows here and More opens the rest. The Default column is filled only where the spec gives a Default: line.

`[<fieldFilterName>]`

Field filter names can contain only alphanumeric characters and underscores "_".
Each field filter must have a unique name.

Setting	Description	Default
`[<fieldFilterName>]` `action`	`<field> = <operator>`BNF for <action> syntax: <action> ::= <field> = <operator> <operator> ::= null() \| sha256() \| sha512() \| <string literal> \| sed(<string literal>) <field> ::= <string literal> More An operator for an action can be one of the following: null(): Removes the <field> from results of searches to which this filter is applied. For example: action = "password"=null() sha256(): Hashes the <field> value with a SHA-256 hash wherever the <field> appears in results of searches to which this filter is applied. For example: action = "userid"=sha256() sha512(): Hashes the <field> value with a SHA-512 hash wherever the <field> appears in results of searches to which this filter is applied. For example: action = "userid"=sha512() <string literal>: Replaces the <fieldname> value with the specified string wherever the <field> value appears in results of searches to which this filter is applied. For example: action = "ssn"="xxx-xx-xxx" sed(<string literal>): Uses the sed expression on the '_raw' field to which this filter is applied. The sed expression replaces strings in raw events that are matched by a regular expression (s) or transliterates characters found in raw events with corresponding characters provided by the sed expression (y). For example: action = "_raw"=sed("s/drop_count=0/drop_count=ZERO/g") <string literal> is a sequence of characters enclosed in double quotation marks (" "). Use \ to escape the characters \ and " in a string literal (\\ and \" respectively). Required.	No default
`[<fieldFilterName>]` `limit`	`[<limit_type>::<string>]`Apply the action of a field filter to events matching the specified 'host', 'source', or 'sourcetype' limit. More Use <limit_type> to specify the limit type: 'host', 'source', or 'sourcetype'. You can't specify multiple limit types in a single field filter. Use <string> to specify a value or a list of comma-separated values for the specified limit. Example 1: limit = sourcetype::access_combined The field filter acts on events that match the 'access_combined' source type. Example 2: limit = sourcetype::st1,st2,st3 The field filter acts on events that match any of the following source types: 'st1', 'st2', or 'st3'. Optional.	No default
`[<fieldFilterName>]` `index`	`<string>`Apply the action of a field filter to events from the specified indexes. More Use <string> to specify an index name or a list of comma-separated index names. Example 1: index = myidx A field filter acts on events from the 'myidx' index. Example 2: index = idx1,idx2,idx3 A field filter acts on events from any of the following indexes: 'idx1', 'idx2', or 'idx3'. Required.	No default
`[<fieldFilterName>]` `description`	`<string>`Used to store a description of the field filter. More Optional.	No default
`[<fieldFilterName>]` `roleExemptions`	`<string>`To maintain data security and integrity, do not manually change this setting. More Identifies the user roles that are exempt from this field filter. This setting is automatically generated by Splunk Web or Splunk platform REST API requests, and should not be manually edited. <string> indicates a role name or a list of comma-separated role names that are exempt from this field filter. This setting and the 'fieldFilterExemption' setting in the 'authorize.conf' file are both required to exempt a role from a field filter. Example 1: roleExemptions = myrole A field filter is not applied to searches of a user who has the role "myrole". Example 2: roleExemptions = role_1,role_2,role_3 A field filter is not applied to searches of a user who has any of the following roles: "role_1", "role_2", "role_3". Optional.	No default

File locations

Scope	Path
System	`$SPLUNK_HOME/etc/system/{default,local}/field_filters.conf`

← Back to References

References / Splunk platform configuration

Workload Pools Configuration

workload_pools.conf sets up workload management's resource groups: whether workload management is on, and how CPU and memory are shared between workload categories and the pools within them.

Definition

[general] turns workload management on (enabled, default false) and names the default_pool and ingest_pool. Each [workload_category:<category>] gets a cpu_weight and mem_weight as a percentage of all resources, and each [workload_pool:<pool_name>] gets weights as a percentage of its category's share; mem_weight is required to create a pool.

The spec cautions that misconfigured workloads can crash splunkd or overuse memory. Settings go in etc/system/local; you may need a restart. Which searches run in which pool is set in workload_rules.conf.

ConfigCapabilitiesedit_workload_pools list_workload_pools select_workload_pools

Settings

Every stanza and setting in workload_pools.conf.spec from Splunk Enterprise 10.4.2: 12 settings across 3 stanzas. Descriptions use the spec's own wording -- the first line shows here and More opens the rest. The Default column is filled only where the spec gives a Default: line.

`[general]`

Setting	Description	Default
`[general]` `enabled`	`<bool>`Specifies whether workload management has been enabled on the system or not. More This setting only applies to the default stanza as a global setting.	false
`[general]` `allow_basic`	`<boolean>`Whether or not the Splunk platform allows workload management to run in BASIC mode. More A value of "true" means the Splunk platform allows workload management to run in BASIC mode, such as when the host cannot use ADVANCED mode or when systemd delegation is not configured for ADVANCED mode. A value of "false" means the Splunk platform does not allow BASIC mode, and the policy may deactivate workload management if only BASIC mode is available. NOTE: Do not change this setting unless instructed to do so by Splunk Support.	false
`[general]` `default_pool`	`<string>`Specifies the default workload pool to be used at runtime for search workloads. More This setting is maintained for backward compatibility with previous releases. Its value is set but is not used in the current release. This value matches the default_pool value of [workload_category:search]. This setting is only applicable when workload management has been enabled in the system. If workload management has been enabled, this is a mandatory setting.
`[general]` `ingest_pool`	`<string>`Specifies the workload pool for splunkd and helper processes that control data ingestion and related actions in the Splunk deployment. More This setting is maintained for backward compatibility with previous releases. Its value is set but is not used in the current release. This value matches the default_pool value of [workload_category:ingest]. This setting is only applicable when workload management has been enabled in the system. If workload management has been enabled, this is a mandatory setting.
`[general]` `workload_pool_base_dir_name`	`<string>`Specifies the base controller directory name for Splunk cgroups on Linux that is used by a Splunk deployment. More Workload pools created from the workload management page are all created relative to this base directory. This setting is only applicable when workload management has been enabled in the system. If workload management has been enabled, this is a mandatory setting.	splunk

`[workload_pool:<pool_name>]`

Setting	Description	Default
`[workload_pool:<pool_name>]` `cpu_weight`	`<number>`Specifies the cpu weight to be used by this workload pool. More This is a percentage of the total cpu resources available to the category to which the pool belongs.	not set
`[workload_pool:<pool_name>]` `mem_weight`	`<number>`Specifies the memory weight to be used by this workload pool. More This is a percentage of the total memory resources available to the category to which the pool belongs. This is a mandatory parameter for the creation of a workload pool and only allows positive integral values. This setting has no effect if "threaded=true".	not set
`[workload_pool:<pool_name>]` `category`	`<string>`Specifies the category to which this workload pool belongs. More Required to create a workload pool. Valid categories are "search", "misc" and "ingest". The "misc" category must contain only one pool, which is "default_pool". When the "ingest" category is specified: If "threaded=false", then the "ingest" category must contain only one pool: "default_pool". If "threaded=true", then the "ingest" category must contain at least 2 pools: the "default_pool", and the threaded pool defined in this stanza.	not set
`[workload_pool:<pool_name>]` `default_category_pool`	`<boolean>`Specifies if this pool is the default pool for its category. More Admin users can specify workload pools associated with roles. If no workload pool is found, the default_pool defined for this category is used. The first pool that is added to a category has this value set to 1. All other pools have this value set to 0. Required if workload management is enabled.	0
`[workload_pool:<pool_name>]` `threaded`	`<boolean>`Specifies whether this workload pool will manage threads. More This setting applies only if "category=ingest" is set on the workload pool. Threaded workload pools are supported only with cgroups v2. If set to "true": The 'mem_weight' setting has no effect. The workload pool can't be the default pool for the category. The workload pool name must match the prefix of the name of the threads that belong to this pool. For example, the pool for SmartStore download threads would be "name=cachemanagerDownloadExecutorWorker". NOTE: Do not change this setting unless instructed to do so by Splunk Support.	false

`[workload_category:<category>]`

Specifies the resource allocation for workload pools in this category. The <category> value can be "search","ingest' or "misc".

Setting	Description	Default
`[workload_category:<category>]` `cpu_weight`	`<number>`Specifies the cpu weight to be used by this category. More This is a percentage of the total cpu resources available to all categories. This parameter exists in the default configuration and is editable with values that are positive integer values less than 100.	set.
`[workload_category:<category>]` `mem_weight`	`<number>`Specifies the memory weight to be used by this category. More This is a percentage of the total memory resources available to all categories. This parameter exists in the default configuration and is editable with values that are positive integer values less than 100.	set.

File locations

Scope	Path
System	`$SPLUNK_HOME/etc/system/{default,local}/workload_pools.conf`

← Back to References

References / Splunk platform configuration

Workload Rules Configuration

workload_rules.conf classifies searches into workload pools, and defines admission rules that filter or queue searches before they run.

Definition

A [workload_rule:<rule_name>] matches searches with a predicate -- for example app=search AND (NOT role=power), using types such as app, role, user, index and search_type -- and places them in a workload_pool. When a search exceeds a runtime condition, its action can alert, move it to another pool, or abort it. [workload_rules_order] lists the rules in priority order.

A [search_filter_rule:<rule_name>] is an admission rule: filter stops matching searches from running, and queue holds matching ad hoc searches for later when the predicate uses adhoc_search_percentage. Either kind of rule can be limited to a schedule. Per the spec, changes don't need a restart; admission rules only apply once workload_policy.conf turns them on.

ConfigCapabilitiesedit_workload_rules list_workload_rules

Settings

Every stanza and setting in workload_rules.conf.spec from Splunk Enterprise 10.4.2: 25 settings across 4 stanzas. Descriptions use the spec's own wording -- the first line shows here and More opens the rest. The Default column is filled only where the spec gives a Default: line.

`[general]`

Setting	Description	Default
`[general]` `numeric_search_time_range`	`<bool>`Specifies whether the search_time_range predicate accepts numerical values. More A value of "true" means search_time_range accepts numerical values. Allows assigning numerical values to the search_time_range predicate when defining workload rules and admission rules. For example, "search_time_range>7d" or "search_time_range<=24h". The search_time-range predicate accepts the value "alltime" regardless of the value of this setting. This setting applies only to the default stanza as a global setting. Note: This setting can cause slower search performance.	false

`[workload_rule:<rule_name>]`

Setting	Description	Default
`[workload_rule:<rule_name>]` `predicate`	`<string>`The logical expression for this workload classification rule. More The format is a logical expression where the predicate is <type>=<value>. For example, "app=search AND (NOT role=power)". The valid <type> values are "app", "role", "user", "index", "indexes_count", "search_type", "search_mode", "search_time_range", and "runtime". Provide the exact value for the specified <type>. For the "app" type, provide the name of the app. For example, "app=search". For the "role" type, provide the name of the role. For example, "role=admin". For the "index" type, provide the name of the index. For example, "index=_internal". You can refer to an internal or public index. For the "user" type, provide the name of any valid user. For example, "user=bob". Note that the reserved internal user "nobody" is invalid, but the reserved internal user "splunk-system-user" is valid. For the "search_type" type, specify the type of the search. Valid search types include "adhoc", "scheduled", "datamodel_acceleration", "report_acceleration", and "summary_index". For the "search_mode" type, specify the mode of the search. Valid modes include "realtime" and "historical". For the "search_time_range" type, provide the time range of the search. The value can be "alltime" or a numerical value. For example, "search_time_range>7d" or "search_time_range<=24h". To specify a numerical value, activate the 'numerical_search_time_range' setting. For the "indexes_count" type, provide a non-negative integer that indicates the number of indexes targeted by the search. Supported operators are "=", ">", and "<". For example, "indexes_count>500". For the "runtime" type, provide the amount of time a search runs in a workload pool to trigger a specified action, such as an alert, move, or abort. Valid units for runtime values include s, second, seconds, m, minute, minutes, h, hour, and hours. Required.
`[workload_rule:<rule_name>]` `workload_pool`	`<string>`Specifies the name of the workload pool, for example "pool1". More The pool name that you specify must already be defined in the [workload_pool:<pool_name>] stanza in workload_pools.conf.
`[workload_rule:<rule_name>]` `action`	`alert \| move \| abort`Specifies the action to take when a search exceeds the specified runtime value. More The action "alert" sends a notification message to Splunk Web that indicates the runtime of the search. The action "move" moves the search from the original workload pool to a designated alternate workload pool, and sends a notification message to Splunk Web. The action "abort" kills the search, and sends a notification message to Splunk Web. Optional.
`[workload_rule:<rule_name>]` `schedule`	`always_on \| time_range \| every_day \| every_week \| every_month`Specifies whether the rule is always on or has a valid time range that expires. More Optional. If it's empty, it means the rule is always on.
`[workload_rule:<rule_name>]` `start_time`	`<string>`This setting is required when 'schedule' is set to: "time_range", "every_week", "every_month", or "every_day". More The time format for 'start_time' is HH:00. If 'schedule' is set to "time_range", the 'start_time' specifies the exact time that the valid time range starts, including 'start_date', 'end_date', time, and time zone. If 'schedule' is set to "every_week" or "every_month", the 'start_time' specifies the start hour. If 'schedule' is set to "every_day", the 'start_time' is set to 0. Default 0.
`[workload_rule:<rule_name>]` `end_time`	`<string>`This setting is required when 'schedule' is set to: "time_range", "every_week", "every_month", or "every_day". More The time format for 'end_time' is HH:00. If 'schedule' is set to "time_range", the 'end_time' specifies the exact time that the valid time range ends, including 'start_date', 'end_date', time, and time zone. If 'schedule' is set to "every_week" or "every_month", the 'end_time' specifies the end hour. If 'schedule' is set to "every_day", the 'end_time' is set to 0. Default 0.
`[workload_rule:<rule_name>]` `every_week_days`	`<string>`This setting is required when 'schedule' is set to "every_week". More Specifies recurring days of the week. Supports comma separated numbers from 0 to 6, where 0 represents Sunday.	No default
`[workload_rule:<rule_name>]` `every_month_days`	`<string>`This setting is required when 'schedule' is set to "every_month". More Specifies recurring days of the month. Supports comma separated numbers from 1 to 31, where 1 represents the 1st day of the month.	No default
`[workload_rule:<rule_name>]` `start_date`	`<string>`This setting is required when 'schedule' is set to "time_range". More The date format is YYYY-MM-DD.	the current date. (in SplunkWeb); none. (manual configuration)
`[workload_rule:<rule_name>]` `end_date`	`<string>`This setting is required when 'schedule' is set to "time_range". More The date format is YYYY-MM-DD	the current date. (in SplunkWeb); none. (manual configuration)
`[workload_rule:<rule_name>]` `user_message`	`<string>`Specifies the message shown in the search job inspector if the rule is applied to a search. More Cannot exceed 140 characters. Optional.
`[workload_rule:<rule_name>]` `disabled`	`<boolean>`Toggles a workload rule off and on. More Set to "true" to disable a rule.	false

`[workload_rules_order]`

Setting	Description	Default
`[workload_rules_order]` `rules`	`<string>`List of all workload classification rules. More The format of the "string" is comma separated items, "rule1,rule2,...". The rules listed are defined in [workload_rule:<rule_name>] stanza. The order of the rule name in the list determines the priorities of that rule. For example, in "rule1,rule2", rule1 has higher priority than rule2. The default value for this property is empty, meaning there is no rule defined.

`[search_filter_rule:<rule_name>]`

Setting	Description	Default
`[search_filter_rule:<rule_name>]` `predicate`	`<string>`The logical expression for this search filter rule. More The format is a logical expression where the predicate is <type>=<value>. For example, "app=search AND (NOT role=power)". The valid <type> values are "app", "role", "user", "index", "indexes_count", "search_type", "search_mode", "search_time_range", and "adhoc_search_percentage". Provide the exact value for the specified <type>. For the "app" type, provide the name of the app. For example, "app=search". For the "role" type, provide the name of the role. For example, "role=admin". For the "index" type, provide the name of the index. For example, "index=_internal". You can refer to an internal or public index. For the "user" type, provide the name of any valid user. For example, "user=bob". Note that the reserved internal user "nobody" is invalid, but the reserved internal user "splunk-system-user" is valid. For the "search_type" type, specify the type of the search. Valid search types include "adhoc", "scheduled", "datamodel_acceleration", "report_acceleration", and "summary_index". For the "search_mode" type, specify the mode of the search. Valid modes include "realtime" and "historical". For the "search_time_range" type, provide the time range of the search. For now, the value can only be "alltime". For the "indexes_count" type, provide a non-negative integer that indicates the number of indexes targeted by the search. Supported operators are "=", ">", and "<". For example, "indexes_count>500". For the "adhoc_search_percentage" type, provide an integer in the range [0,100] indicating the percentage of total concurrent searches that adhoc searches can consume before being filtered or queued. If specified, the predicate must also include "search_type=adhoc". Required.
`[search_filter_rule:<rule_name>]` `action`	`filter \| queue`Specifies the action to take when a search meets the rule criteria. More The action "filter" is defined for search filter rules. If a search meets the rule criteria, the search is not executed. The action "queue" is only defined for search filter rules with "adhoc_search_percentage" specified in the predicate. If an ad hoc search meets the rule criteria, it will be queued and attempted later. A search meeting criteria for both "filter" and "queue" actions will be filtered. Required.
`[search_filter_rule:<rule_name>]` `schedule`	`always_on \| time_range \| every_day \| every_week \| every_month`Specifies whether the rule is always on or has a valid time range that expires. More Optional. If it's empty, it means the rule is always on.
`[search_filter_rule:<rule_name>]` `start_time`	`<string>`This setting is required when 'schedule' is set to: "time_range", "every_week", "every_month", or "every_day". More The time format for 'start_time' is HH:00. If 'schedule' is set to "time_range", the 'start_time' specifies the exact time that the valid time range starts, including 'start_date', 'end_date', time, and time zone. If 'schedule' is set to "every_week" or "every_month", the 'start_time' specifies the start hour. If 'schedule' is set to "every_day", the 'start_time' is set to 0. Default 0.
`[search_filter_rule:<rule_name>]` `end_time`	`<string>`This setting is required when 'schedule' is set to: "time_range", "every_week", "every_month", or "every_day". More The time format for 'end_time' is HH:00. If 'schedule' is set to "time_range", the 'end_time' specifies the exact time that the valid time range ends, including 'start_date', 'end_date', time, and time zone. If 'schedule' is set to "every_week" or "every_month", the 'end_time' specifies the end hour. If 'schedule' is set to "every_day", the 'end_time' is set to 0. Default 0.
`[search_filter_rule:<rule_name>]` `every_week_days`	`<string>`This setting is required when 'schedule' is set to "every_week". More Specifies recurring days of the week. Supports comma separated numbers from 0 to 6, where 0 represents Sunday.	No default
`[search_filter_rule:<rule_name>]` `every_month_days`	`<string>`This setting is required when 'schedule' is set to "every_month". More Specifies recurring days of the month. Supports comma separated numbers from 1 to 31, where 1 represents the 1st day of the month.	No default
`[search_filter_rule:<rule_name>]` `start_date`	`<string>`This setting is required when 'schedule' is set to "time_range". More The date format is YYYY-MM-DD.	the current date. (in SplunkWeb); none. (manual configuration)
`[search_filter_rule:<rule_name>]` `end_date`	`<string>`This setting is required when 'schedule' is set to "time_range". More The date format is YYYY-MM-DD	the current date. (in SplunkWeb); none. (manual configuration)
`[search_filter_rule:<rule_name>]` `user_message`	`<string>`Specifies the message when a search is filtered out by this rule. More Cannot exceed 140 characters. Optional.
`[search_filter_rule:<rule_name>]` `disabled`	`<boolean>`Toggles a search filter rule off and on. More Set to "true" to disable a rule.	false

File locations

Scope	Path
System	`$SPLUNK_HOME/etc/system/{default,local}/workload_rules.conf`

← Back to References

References / Splunk platform configuration

Workload Policy Configuration

workload_policy.conf turns search admission control on or off.

Definition

Its one setting, admission_rules_enabled in [search_admission_control], decides whether admission rules -- the [search_filter_rule:…] stanzas in workload_rules.conf -- are applied when a search is dispatched. Default 0 (off). Settings go in etc/system/local; you may need a restart.

ConfigCapabilitiesedit_workload_policy list_workload_policy

Settings

Every stanza and setting in workload_policy.conf.spec from Splunk Enterprise 10.4.2: 1 settings across 1 stanza. Descriptions use the spec's own wording -- the first line shows here and More opens the rest. The Default column is filled only where the spec gives a Default: line.

`[search_admission_control]`

Setting	Description	Default
`[search_admission_control]` `admission_rules_enabled`	`<bool>`Determines whether admission rules are applied to searches. More If set to true, admission rules for pre-filtering searches are applied when a search is dispatched.	0

File locations

Scope	Path
System	`$SPLUNK_HOME/etc/system/{default,local}/workload_policy.conf`

← Back to References

References / Splunk platform configuration

Splunk Launch Configuration

splunk-launch.conf holds values used at startup by the splunk command and by Windows services -- mainly environment variables such as SPLUNK_HOME and SPLUNK_DB.

Definition

Unlike most Splunk configuration files, there's only one, at $SPLUNK_HOME/etc/splunk-launch.conf, and it has no stanzas; copies under etc/apps or etc/users are ignored. Each line sets an environment variable for Splunk's programs, as export (Unix shells) or SET (Windows) would. The spec documents the ones Splunk reads, including SPLUNK_HOME, SPLUNK_DB, SPLUNK_BINDIP, SPLUNK_OS_USER, SPLUNK_SERVER_NAME and SPLUNK_FIPS.

Settings

Every stanza and setting in splunk-launch.conf.spec from Splunk Enterprise 10.4.2: 14 settings across 0 stanzas. Descriptions use the spec's own wording -- the first line shows here and More opens the rest. The Default column is filled only where the spec gives a Default: line.

Settings outside any stanza

Setting	Description	Default
`<environment_variable>`	`<value>`Any desired environment variable can be set to any value. Whitespace is trimmed from around both the key and value. Variable substitution (VAR=$OTHER_VAL) is not supported. More Environment variables set here will be available to all Splunk platform processes, barring operating system limitations.
`SPLUNK_HOME`	`<string>`The fully qualified path to the Splunk platform instance installation directory. More The comment in the auto-generated splunk-launch.conf is informational, not a live setting, and does not need to be uncommented. If not set, the Splunk platform automatically determines the location of SPLUNK_HOME based on the location of the splunk CLI executable. Specifically, the parent of the directory containing splunk or splunk.exe Must be set if Common Criteria mode is enabled. NOTE: Splunk supports using the product in Common Criteria mode for specific software configurations that the National Information Assurance Partnership (NIAP) certifies only. See the "Securing Splunk Enterprise for Common Criteria" manual for specific information on the status of Common Criteria certification.	not set
`SPLUNK_DB`	`<string>`The comment in the auto-generated splunk-launch.conf is informational, not a live setting, and does not need to be uncommented. More The fully qualified path to the directory containing the index directories for the Splunk platform instance. Primarily used by paths expressed in indexes.conf The comment in the autogenerated splunk-launch.conf is informational, not a live setting, and does not need to be uncommented. If unset, the path becomes $SPLUNK_HOME/var/lib/splunk (unix) or %SPLUNK_HOME%\var\lib\splunk (windows>)	not set
`SPLUNK_BINDIP`	`<ip address>`The network IP address that splunkd and splunkweb should bind to, as opposed to binding to the default for the local operating system. More If not set, the Splunk platform makes no specific request to the operating system when binding to ports or opening a listening socket. This means it effectively binds to '*', meaning an unspecified bind. Operating system behavior and configuration controls the exact result in this case. NOTE: When using this setting you must update 'mgmtHostPort' in web.conf to match. Otherwise, the command line and splunkweb cannot reach splunkd. For splunkd, this sets both the management port and the ports that receive from forwarders. This setting is useful for a host with multiple IP addresses, either to enable or restrict access. But using a firewall is typically a superior method of restriction. Does not override web.conf/[settings]/server.socket_host for SplunkWeb if set; the latter is preferred when SplunkWeb behavior is the focus.	not set
`SPLUNK_OS_USER`	`<string> \| <nonnegative integer>`The OS user whose privileges splunkd adopts when running. More Example: SPLUNK_OS_USER=fnietzsche. Splunkd starts with a root login. Immediately upon starting, splunkd abandons the root user's privileges, and acquires fnietzsche's privileges. User fnietzsche owns any files that splunkd creates (index data, logs, etc.) When fnietzsche starts splunkd the next time, the files are readable. When 'splunk enable boot-start -user <user>' is invoked, SPLUNK_OS_USER is set to <user> as a side effect. On UNIX, username or apposite numeric UID are both acceptable; on Windows, only usernames are acceptable.	not set
`SPLUNK_FIPS`	`[0\|1]`Whether or not the Splunk platform instance operates in Federal Information Processing Standards (FIPS) mode, and uses the algorithms and restrictions that apply to the FIPS standard. More Use this setting along with the 'SPLUNK_FIPS_VERSION' setting to configure the FIPS module to use. If you do not specify 'SPLUNK_FIPS_VERSION', the instance uses the default version for that setting. If the machine on which the Splunk platform instance operates runs a kernel that operates in FIPS mode, this setting is "true" by default. Configure this setting to ensure that your Splunk platform instance operates fully within US federal guidelines set by the FIPS publication. NOTE: This setting is one-time only. If you need for the instance to be fully FIPS-compliant, configure it to "true" before you start it for the first time. If you do not do this, the Splunk secret key that the instance generates on first-time startup might not meet FIPS guidance. If you configure it to "true" and then start the Splunk platform instance, you cannot later configure it to "false". You must reinstall the software. Running the Splunk platform in FIPS mode can result in the platform operating more slowly than if you ran it in normal mode.	0
`SPLUNK_FIPS_VERSION`	`[140-2\|140-3]`The FIPS mode in which this Splunk platform instance is to operate. More The instance can operate in either FIPS 140-2 mode or 140-3 mode. FIPS 140-2 is the current publication standard that the National Institute of Standards and Technology (NIST) plans to retire by September of 2026. FIPS 140-3 is the standard that replaces FIPS 140-2.	140-2
`PYTHONHTTPSVERIFY`	`[0\|1]`Whether or not the Splunk platform instance sets up TLS validation for the httplib module in the Python interpreter embedded with the Splunk package.	0
`PYTHONUTF8`	`[0\|1]`Determines whether the Splunk platform instance enables the UTF-8 mode in the Python interpreter embedded with the Splunk package. More A value of 1 means UTF-8 mode is enabled. This setting applies regardless of the system locale encoding.	1
`SPLUNK_SERVER_NAME`	`<string>`Names the splunkd server/service. More Defaults to splunkd (UNIX), or Splunkd (Windows).
`SPLUNK_WEB_NAME`	`<string>`No longer used.
`OPTIMISTIC_ABOUT_FILE_LOCKING`	`[0\|1]`Whether or not Splunk software skips the file system lock check on unrecognized file systems. More CAUTION: USE THIS SETTING AT YOUR OWN RISK. YOU CAN LOSE ANY DATA THAT HAS BEEN INDEXED WHILE THE SETTING IS ACTIVE. When set to 1, Splunk software skips the file system check, and splunkd starts whether or not it can recognize the file system. Defaults to 0 (Run the file system check.)
`SPLUNK_PYTHON_DONT_ESCAPE_PRINTABLE`	`0\|1`Determines whether the Splunk Python interpreter escapes non-printable characters such as ASCII 0–32,127, when logging with the Python logging module. More Exceptions: \t (chr(9)/0x09), \n (chr(10)/0x0a), \r (chr(13)/0x0d) When set to 1, scripts that log when using Splunk's Python interpreter will NOT escape non-printable characters and may be in log files Defaults to 0 (Non-printable characters WILL be escaped)
`ENABLE_CPUSHARES`	`<boolean>`Whether or not Splunk software adds 'CPUShares=1024' to the systemd service unit file named Splunkd.service by default, in /etc/systemd/system. More Supported for only Linux.	true

File locations

Scope	Path
Singleton	`$SPLUNK_HOME/etc/splunk-launch.conf`

← Back to References

References / Splunk platform configuration

User Seed Configuration

user-seed.conf sets Splunk's initial username and password.

Definition

One [user_info] stanza with USERNAME and either HASHED_PASSWORD -- recommended; create the hash with splunk hash-passwd -- or a cleartext PASSWORD. Only one user can be configured. Place it in $SPLUNK_HOME/etc/system/local and restart; it isn't used if $SPLUNK_HOME/etc/passwd already exists.

Capabilitiesedit_user_seed

Settings

Every stanza and setting in user-seed.conf.spec from Splunk Enterprise 10.4.2: 3 settings across 1 stanza. Descriptions use the spec's own wording -- the first line shows here and More opens the rest. The Default column is filled only where the spec gives a Default: line.

`[user_info]`

Default is Admin.

Setting	Description	Default
`[user_info]` `USERNAME`	`<string>`Username you want to associate with a password. More Default is Admin.
`[user_info]` `PASSWORD`	`<password>`Password you wish to set for that user. More Password must meet complexity requirements.
`[user_info]` `HASHED_PASSWORD`	`<password hash>`Password hash you wish to set for that user.

File locations

Scope	Path
System	`$SPLUNK_HOME/etc/system/local/user-seed.conf`

← Back to References

References / Splunk platform configuration

Multikv Configuration

multikv.conf defines rules for extracting events from table-like events, such as the output of top, ps, ls or netstat.

Definition

A table-like event has up to four sections: pre (optional description), header (optional; without it, fields are named Column_N), body (required -- the rows child events are built from) and post (optional). Each [<multikv_config_name>] stanza defines sections with settings such as <Section Name>.start, .end and .linecount, and processes them with .ignore, .replace and .tokens.

The spec advises configuring it only when the default multikv behaviour doesn't meet your needs. Settings go in etc/system/local; changes need a restart.

Settings

Every stanza and setting in multikv.conf.spec from Splunk Enterprise 10.4.2: 12 settings across 1 stanza. Descriptions use the spec's own wording -- the first line shows here and More opens the rest. The Default column is filled only where the spec gives a Default: line.

`[<multikv_config_name>]`

Name of the stanza to use with the multikv search command, for example: '| multikv conf=<multikv_config_name> rmorig=f | ....'
Follow this stanza name with any number of the following setting/value pairs.

Setting	Description	Default
`[<multikv_config_name>]` `<Section Name>.start`	`<regex>`A line matching this regex denotes the start of this section (inclusive). More OR
`[<multikv_config_name>]` `<Section Name>.start_offset`	`<int>`Line offset from the start of an event or the end of the previous section (inclusive). More Use this if you cannot define a regex for the start of the section.
`[<multikv_config_name>]` `<Section Name>.member`	`<regex>`A line membership test. More Member if lines match the regex.
`[<multikv_config_name>]` `<Section Name>.end`	`<regex>`A line matching this regex denotes the end of this section (exclusive). More OR
`[<multikv_config_name>]` `<Section Name>.linecount`	`<int>`Specify the number of lines in this section. More Use this if you cannot specify a regex for the end of the section.
`[<multikv_config_name>]` `<Section Name>.ignore`	`[_all_\|_none_\|_regex_ <regex-list>]`Determines which member lines will be ignored and not processed further.
`[<multikv_config_name>]` `<Section Name>.replace`	`<quoted-str> = <quoted-str>, <quoted-str> = <quoted-str>,...`List of the form: "toReplace" = "replaceWith". More Can have any number of quoted string pairs. For example: "%" = "_", "#" = "_"
`[<multikv_config_name>]` `<Section Name>.tokens`	`[<chopper>\|<tokenizer>\|<aligner>\|<token-list>]`See below for definitions of each possible token: chopper, tokenizer, aligner, and token-list.
`[<multikv_config_name>]` `<chopper>`	`_chop_, <int-list>`A token that transform each string into a list of tokens specified by <int-list>. More <int-list> is a list of (offset, length) tuples, separated by commas. Do not contain tuples within parentheses. Example: body.tokens = _chop_, 0, 9, 10, 4, 15, 4, 20, 7
`[<multikv_config_name>]` `<tokenizer>`	`_tokenize_ <max_tokens (int)> <delims> (<consume-delims>)?`A token used to tokenize the string using the delimiter characters. More This generates at most 'max_tokens' number of tokens. Set 'max_tokens' to: -1 for complete tokenization. 0 to inherit from the previous section, usually the header section. A non-zero number for a specific token count. If tokenization is limited by the 'max_tokens', the rest of the string is added onto the last token. <delims> is a comma-separated list of delimiting characters. <consume-delims> - A Boolean that specifies whether to consume consecutive delimiters. Set to "false" or "0" if you want consecutive delimiters treated as empty values.	true
`[<multikv_config_name>]` `<aligner>`	`_align_, <header_string>, <side>, <max_width>`A token that generates tokens by extracting text aligned to the specified header fields. More header_string: A complete or partial header field value that the columns are aligned with. side: Either L or R (for left or right align, respectively). max_width: The maximum width of the extracted field. Set 'max_width' to -1 for automatic width. This expands the field until any of the following delimiters are found: " ", "\t"
`[<multikv_config_name>]` `<token_list>`	`_token_list_ <comma-separated list>`A token that defines a list of static tokens in a section. More This setting is useful for tables with no header, for example: the output of 'ls -lah' which misses a header altogether.

File locations

Scope	Path
System	`$SPLUNK_HOME/etc/system/{default,local}/multikv.conf`

← Back to References

References / Splunk platform configuration

Segmenters Configuration

segmenters.conf configures how events are segmented -- the breaker characters that split raw text into the major and minor segments Splunk indexes and searches.

Definition

Each [<SegmenterName>] stanza sets the MAJOR and MINOR breakers, INTERMEDIATE_MAJORS, a FILTER, and length and count limits (MAJOR_LEN, MINOR_LEN, MAJOR_COUNT, MINOR_COUNT). The spec's limitations: definitions mustn't conflict between installed apps, must match between search heads and search peers, and must be visible in the global context -- in [default] or outside any stanza.

Settings go in etc/system/local; changes need a restart. A segmenter is assigned to data with props.conf's SEGMENTATION setting.

Config

Settings

Every stanza and setting in segmenters.conf.spec from Splunk Enterprise 10.4.2: 9 settings across 1 stanza. Descriptions use the spec's own wording -- the first line shows here and More opens the rest. The Default column is filled only where the spec gives a Default: line.

`[<SegmenterName>]`

Name your stanza.
Follow this stanza name with any number of the following setting/value pairs.
If you don't specify a setting/value pair, Splunk will use the default.

Setting	Description	Default
`[<SegmenterName>]` `MAJOR`	`<space separated list of breaking characters>`Set major breakers. More Major breakers are words, phrases, or terms in your data that are surrounded by set breaking characters. By default, major breakers are set to most characters and blank spaces. Typically, major breakers are single characters. Note: \s represents a space; \n, a newline; \r, a carriage return; and \t, a tab.	[ ] < > ( ) { } \| ! ; , ' " * \n \r \s \t & ? + %21 %26 %2526 %3B %7C %20 %2B %3D -- %2520 %5D %5B %3A %0A %2C %28 %29
`[<SegmenterName>]` `MINOR`	`<space separated list of strings>`Specifies minor breakers. More In addition to the segments specified by the major breakers, for each minor breaker found, Splunk indexes the token from the last major breaker to the current minor breaker and from the last minor breaker to the current minor breaker.	/ : = @ . - $ # % \\ _
`[<SegmenterName>]` `INTERMEDIATE_MAJORS`	`true \| false`Set this to "true" if you want an IP address to appear in typeahead as a, a.b, a.b.c, a.b.c.d More The typical negative effect on performance by setting to "true" is 30%.	false
`[<SegmenterName>]` `FILTER`	`<regular expression>`If specified, segmentation will only take place if the regular expression matches. More Furthermore, segmentation will only take place on the first group of the matching regex.	None
`[<SegmenterName>]` `LOOKAHEAD`	`<integer>`Specifies how far into a given event, in characters, the Splunk segments. More LOOKAHEAD is applied after any FILTER rules. To disable segmentation, set to 0.	-1 (read the whole event)
`[<SegmenterName>]` `MINOR_LEN`	`<integer>`Specifies how long a minor token can be. More Longer minor tokens are discarded without prejudice.	-1
`[<SegmenterName>]` `MAJOR_LEN`	`<integer>`Specifies how long a major token can be. More Longer major tokens are discarded without prejudice.	-1.
`[<SegmenterName>]` `MINOR_COUNT`	`<integer>`Specifies how many minor segments to create for each event. More After the specified number of minor segments are created, later minor segments are discarded without prejudice.	-1
`[<SegmenterName>]` `MAJOR_COUNT`	`<integer>`Specifies how many major segments are created for each event. More After the specified number of major segments are created, later segments are discarded without prejudice.	-1

File locations

Scope	Path
System	`$SPLUNK_HOME/etc/system/{default,local}/segmenters.conf`
App	`$SPLUNK_HOME/etc/apps/<app_name>/{default,local}/segmenters.conf`

← Back to References

References / Splunk platform configuration

Metric Alerts Configuration

metric_alerts.conf stores metric alerts: a condition over metric indexes, evaluated on a regular interval with an mstats search, and what happens when it's met.

Definition

Each [<alert_name>] stanza names the metric_indexes to watch (required), an optional filter and groupby dimensions, and a condition on metric and aggregation pairs. trigger.* settings control when it fires -- for example trigger.threshold (always, once, or after the condition holds for some minutes) and trigger.suppress -- and action.<action_name> settings set what it does.

The spec puts the shipped default in etc/system/default and your settings in etc/system/local; changes need a restart.

ConfigCapabilitiesmetric_alerts

Settings

Every stanza and setting in metric_alerts.conf.spec from Splunk Enterprise 10.4.2: 19 settings across 1 stanza. Descriptions use the spec's own wording -- the first line shows here and More opens the rest. The Default column is filled only where the spec gives a Default: line.

`[<alert_name>]`

The <alert_name> is the name of the metric alert.
Required.

Setting	Description	Default
`[<alert_name>]` `description`	`<string>`This string provides a description of the metric alert. More Optional.	No default
`[<alert_name>]` `groupby`	`<list of dimension fields>`The list of dimension fields, delimited by comma, for the group-by clause of the alert search. More This leads to multiple aggregation values, one per group, instead of one single value. Optional.	No default
`[<alert_name>]` `filter`	`<string>`This setting provides one or more Boolean expressions like '<dimension_field>=<value>' to filter the search result dataset to monitor for the alert condition. More Link multiple Boolean expressions with the 'AND' operator. The filter does not support subsearches, macros, tags, event types, or time modifiers such as 'earliest' or 'latest'. This setting combines with the metric_indexes setting to provide the full alert search filter. Optional.	No default
`[<alert_name>]` `metric_indexes`	`<metric index name>`Specifies one or more metric indexes, delimited by comma. More Combines with the filter setting to filter the search result dataset to monitor for the alert condition. Required.	No default
`[<alert_name>]` `condition`	`<boolean eval expression>`Specifies an alert condition for one or more metric_name and aggregation pairs. The Splunk software applies this evaluation to the results of the alert search on a regular interval. This alert search takes the form of an 'mstats' search. More When the alert condition evaluates to 'true', the Splunk software might trigger the alert, depending on how 'trigger.threshold' and 'trigger.suppress' are evaluated. The condition must reference at least one metric aggregation in single quotes: '<mstats_aggregation_function>(<metric_name>)' The condition can also reference dimensions specified in the group-by fields. Dimension field names starting with numeric characters or with non-alphanumeric characters must be surrounded by single quotation marks. If the expression references a literal string, the literal string must be surrounded by double quotation marks. Required.	No default
`[<alert_name>]` `trigger.prepare`	`<string>`Specifies a postprocessing search that the Splunk software applies to the filtered results of the alert search, before it runs the designated alert actions. More Use this postprocessing search to augment or filter the filtered results of the alert search. Employ commands like 'eval' or 'inputlookup' to rename existing fields in the results or add new fields to the results. Design filters that remove unnecessary events from the result dataset used by the alert action. Optional.	No default
`[<alert_name>]` `trigger.suppress`	`<time-specifier>`Specifies the suppression period to silence alert actions and notifications. More The suppression period goes into effect when an alert is triggered. During this period, if the alert is triggered again, its actions do not happen and its notifications do not go out. When the period elapses, a subsequent triggering of the alert causes alert actions and notifications to take place as usual, and the alert is suppressed again. Use [number]m to specify a timespan in minutes. Set to 0 to disable suppression.	0
`[<alert_name>]` `trigger.expires`	`<time-specifier>`Sets the period of time that a triggered alert record displays on the Triggered Alerts page. More Use [positive integer][time-unit], where time_unit can be 'm' for minutes, 'h' for hours, and 'd' for days. Set to 0 to make triggered alerts expire immediately so they do not appear on the Triggered Alerts page at all.	24h
`[<alert_name>]` `trigger.max_tracked`	`<number>`Specifies the maximum number of instances of this alert that can display in the triggered alerts dashboard. More When this threshold is passed, the Splunk software removes the earliest instances from the dashboard to honor this maximum number. Set to 0 to remove the cap.	20
`[<alert_name>]` `trigger.evaluation_per_group`	`<boolean>`Optional. More Only applies if 'groupby' is set. When set to true, the Splunk software independently evaluates the alert 'condition', 'trigger.threshold', and 'trigger.suppress' settings against each result, in correspondence with a unique group of dimension field values defined by the 'groupby' setting. Use 'trigger.evaluation_per_group' in conjunction with the 'trigger.action_per_group' setting.	false
`[<alert_name>]` `trigger.action_per_group`	`<boolean>`Optional. More Only applies if 'groupby' and 'trigger.evaluation_per_group' are set. When set to true, the Splunk software runs actions for each result, in correspondence with a unique group of dimension field values defined by the 'groupby' setting, using the evaluations produced by the 'trigger.evaluation_per_group' setting. When 'trigger.evaluation_per_group' is enabled and this setting is disabled, the Splunk software runs the alert action only once when one or more groups meet the alert condition. This setting cannot be enabled when 'trigger.evaluation_per_group' is disabled.	false
`[<alert_name>]` `trigger.threshold`	`[always\|once\|always after <number>m\|once after <number>m]`Specify when to perform an alert action such as sending an email: More always - Whenever the alert 'condition' is true. once - Only once, the first time the alert 'condition' makes a positive state change from false to true. always after <number>m - Whenever the alert 'condition' is met continuously for <number> minutes. once after <number>m - Only once, the first time the alert 'condition' is met continuously for <number> minutes. Examples: A setting of 'always after 5m' means that the Splunk software performs the alert action every time the alert condition is met for 5 minutes in a row. So if the alert condition is true for 8 minutes, the Splunk software performs the action 3 times. A setting of 'once after 5m' means that the Splunk software performs the alert action the first time the alert condition is met for 5 minutes in a row. If the alert condition is met continuously for 8 minutes the Splunk software performs the action only once. If after that, the condition switches to false and is then true continuously for another 12 minutes, the Splunk software would perform the action again.	always
`[<alert_name>]` `label.<label-name>`	`<label-value>`Arbitrary key-value pairs for labeling this alert. More These settings will be opaque to the backend (not interpreted in any way). Can be used by applications calling `alerts/metric_alerts` endpoint.
`[<alert_name>]` `splunk_ui.<label-name>`	`<label-value>`For Splunk internal use only. More Arbitrary key-value pairs for labeling this alert for the exclusive use of the Splunk software.
`[<alert_name>]` `splunk_ui.track`	`<boolean>`Optional. More Indicates whether the alert is tracked on the Triggered Alerts page and the Splunk Analytics Workspace.	false
`[<alert_name>]` `splunk_ui.severity`	`<integer>`Optional. More Sets the severity level displayed for the alert in Splunk Web. Valid values are: 1-debug, 2-info, 3-warn, 4-error, 5-severe, 6-fatal	3
`[<alert_name>]` `action.<action_name>`	`<boolean>`Indicates whether the action is enabled or disabled for a particular metric alert. More The 'action_name' can be: email \| logevent \| rss \| script \| webhook For more about the defined alert actions see the alert_actions.conf file. Optional.	No default
`[<alert_name>]` `action.<action_name>.<parameter>`	`<value>`Overrides an action's parameter as defined in the alert_actions.conf file, with a new <value> for this metric alert only.	No default
`[<alert_name>]` `action.email.include.smaDefinition`	`[1\|0]`Specify whether to include streaming alert setup information in the email content. More Setup information includes indexes, filter, groupby, condition.

File locations

Scope	Path
System	`$SPLUNK_HOME/etc/system/{default,local}/metric_alerts.conf`

← Back to References

References / Splunk platform configuration

Metric Rollups Configuration

metric_rollups.conf holds rollup policies: summaries of a metric index's data points, aggregated over a span into another index.

Definition

Each [index:<Metric Index Name>] stanza is the policy for one source metric index: a required defaultAggregation, per-metric aggregation.<metric_name> overrides, which dimensions and metrics to include or exclude (dimensionList/dimensionListType, metricList/metricListType), and one or more summaries, each with a rollup.<n>.span and a rollup.<n>.rollupIndex that must exist in indexes.conf. The summary numbers are assigned when you create the policy in Splunk Web or through the REST API.

The spec puts the shipped default in etc/system/default and your settings in etc/system/local; changes need a restart.

ConfigCapabilitiesedit_metrics_rollup

Settings

Every stanza and setting in metric_rollups.conf.spec from Splunk Enterprise 10.4.2: 8 settings across 1 stanza. Descriptions use the spec's own wording -- the first line shows here and More opens the rest. The Default column is filled only where the spec gives a Default: line.

`[index:<Metric Index Name>]`

Each metric_rollups.conf stanza defines the rollup summarization policy for a specific metric index.
A rollup policy can include multiple rollup summaries, each with a different rollup period.
Go to indexes.conf to find metric index configurations. Metric indexes have datatype=metric in their configurations.

Setting	Description	Default
`[index:<Metric Index Name>]` `defaultAggregation`	`<'#' separated list of aggregation functions>`Required. The default aggregation function for the rollup policy. The Splunk software uses this aggregation function to generate the rollup summmary data points for all metrics in the source index with the exception of metrics that are identified by 'aggregation.<metric_name>' exclusion rules. More For example, if a rollup summary with a period of 1 hour has 'defaultAggregation = avg', each metric data point that it generates is the average of an hour of data points from the source metric. Note that the 'perc' and 'upperperc' options require an integer. Supported aggregation functions: [avg\|count\|max\|median\|min\|perc<int>\|sum]	avg
`[index:<Metric Index Name>]` `dimensionList`	`<comma-separated list of dimensions>`Optional. This setting provides a comma-separated list of dimensions. The dimensions must be present within the index to which the rollup policy applies. More This list corresponds to the `dimensionListType` setting, which determines whether this set of dimensions is included or excluded from the rollup metrics that are generated by the rollup summary. Use the Metrics Catalog REST API endpoints to see the metrics and dimensions for a particular index. For more information see the REST API Reference Manual.	not set
`[index:<Metric Index Name>]` `dimensionListType`	`[excluded\|included]`Optional. This setting determines whether the list of dimensions specified by the `dimensionList` setting is included or excluded from the rollup metrics that are generated by the rollup summaries in the rollup policy. More Select 'included' to indicate that the rollup metrics produced by the rollup policy will filter out all dimensions except the ones in the list. Select 'excluded' to indicate that the rollup metrics produced by the rollup policy will include all available dimensions except the ones in the list.	excluded
`[index:<Metric Index Name>]` `metricList`	`<comma-separated list of metrics>`Optional. This setting provides a comma-separated list of metrics. More This list corresponds to the 'metricListType' setting. The listed metrics must be present within the source metric index. Use the Metrics Catalog REST API endpoints in conjunction with the 'rest' command to see the metrics that exist within a particular source index. See the REST API Reference Manual and the Search Reference for more information.	not set
`[index:<Metric Index Name>]` `metricListType`	`<excluded/included>`Optional. This setting determines whether the list of metrics specified by the 'metricList' setting is included or excluded when the search head rolls metrics up to the rollup summaries. More Select "included" to have the search head roll up only the listed metrics. Select "excluded" to have the search head roll up all available metrics in the source metric index except the listed metrics.	excluded
`[index:<Metric Index Name>]` `aggregation.<metric_name>`	`<'#' separated list of aggregation functions>`Optional. Sets an exclusion rule for a rollup policy. Use this setting to override the 'defaultAggregation' setting for a specific metric. More Create exclusion rules for metrics that require different aggregation functions than the majority of the metrics in a rollup policy. A single rollup policy can have multiple exclusion rules. Supported aggregation functions: [avg\|count\|max\|median\|min\|perc<int>\|sum]	no values
`[index:<Metric Index Name>]` `rollup.<summary number>.span`	`<time range string>`Required for each rollup summary in the rollup policy. More The Splunk software defines the '<summary number>' when you create a summary policy through Splunk Web or the REST API endpoint. Defines the rollup period for a rollup summary. The '<time range string>' cannot be shorter than the 'minSpanAllowed' setting in limits.conf. This setting is required. Do not leave it blank. Default for <summary number>: 1 Default for <time range string>: 1h
`[index:<Metric Index Name>]` `rollup.<summary number>.rollupIndex`	`<string Index name>`Required for each rollup summary in the rollup policy. More Defines the target index for the rollup metrics generated by a rollup summary. The Splunk software defines the '<summary number>' when you create a summary policy through Splunk Web or the REST API endpoint. The index name must exist in indexes.conf. This setting is required. Do not leave it blank. Default for <summary number>: 1 Default for <string Index name>: The <Metric Index Name> in the stanza header for this rollup policy.

File locations

Scope	Path
System	`$SPLUNK_HOME/etc/system/{default,local}/metric_rollups.conf`

← Back to References

References / Splunk platform configuration

Retention Policy

Retention Policy (TAX-02.06.05) records the approved retention period for a data source, index or platform. This article documents the mechanism behind that record: the Splunk bucket lifecycle and the indexes.conf settings that actually enforce a retention period, plus what genuinely secure deletion requires beyond normal bucket aging.

Definition

A Retention Policy record documents the approved retention period for a data source, index or platform, including any regulatory or contractual minimum and the basis for the assigned period. Retention isn't only a documented number -- it's enforced mechanically by an index's bucket lifecycle, so the recorded policy should match the deployed indexes.conf settings, not just organisational intent.

Bucket lifecycle

An index's data moves through a fixed sequence of bucket states as it ages. Each transition is driven by indexes.conf settings, not by a single "retention" switch.

Stage	Access	Definition
Hot	Writable	The newest data; the only bucket state Splunk actively writes to. Rolls to warm on a `splunkd` restart, when it reaches `maxDataSize`, or when it reaches the age set by `maxHotSpanSecs`.
Warm	Read-only	Recently rolled-off data, still searched by default; an index typically holds several warm buckets at once.
Cold	Read-only	Older data, often relocated to cheaper or slower storage via `coldPath`; still searchable exactly like warm, just not necessarily on the same volume.
Frozen	Not searchable	Data that has aged past `frozenTimePeriodInSecs` or pushed the index past `maxTotalDataSizeMB`. By default this means deletion; if `coldToFrozenDir` or `coldToFrozenScript` is configured, the bucket is archived instead of deleted.
Thawed	Read-only (manual)	A frozen bucket restored for search -- copy it into `thawedPath` and run `splunk rebuild`. Splunk does not manage thawed buckets automatically; removing them again afterward is a manual step.

indexes.conf settings

Setting	Default	Definition
`maxHotSpanSecs`	7776000 (90 days)	Upper bound on how long a hot bucket may span before it's forced to roll to warm, regardless of size.
`maxDataSize`	`auto` (~750MB)	The size a hot bucket may reach before `splunkd` rolls it to warm.
`maxWarmDBCount`	300	The maximum number of warm buckets an index may hold before the oldest are rolled to cold.
`frozenTimePeriodInSecs`	188697600 (~6 years)	Age, measured from a cold bucket's newest event, at which it rolls to frozen.
`maxTotalDataSizeMB`	500000	Overall index size cap; once exceeded, the oldest cold buckets are frozen regardless of `frozenTimePeriodInSecs`.
`coldToFrozenDir`	(unset)	Destination path cold buckets are moved to instead of being deleted when they freeze.
`coldToFrozenScript`	(unset)	A custom script run when a bucket freezes, for handling like off-platform archival, instead of (or as well as) `coldToFrozenDir`.
`homePath` / `coldPath` / `thawedPath`	index-specific	The filesystem locations for an index's hot+warm, cold, and thawed buckets respectively -- typically on different volumes to balance storage cost against search performance.

Deleted, not archived, by default. An index with neither coldToFrozenDir nor coldToFrozenScript configured silently and permanently deletes its data the moment a bucket freezes. If any retention or legal-hold requirement calls for archival rather than deletion, one of these two settings must be present -- freezing alone is not archival.

Secure deletion

Normal bucket aging and the SPL delete command remove data from search, but neither one guarantees the underlying bytes are gone from disk or unrecoverable.

Method	What it actually does	Secure erasure?
Bucket aging to frozen (no archive configured)	Deletes the bucket's files from the index's storage path.	Only if the underlying storage is separately wiped -- file deletion alone can leave recoverable remnants on disk.
`\| delete` SPL command	Marks matching events as non-searchable.	No -- the raw data remains physically present on disk.
Overwriting storage	Repeatedly overwrites the freed disk sectors with random data.	Yes, when performed correctly.
Physical destruction	Physically destroys the storage media.	Yes -- appropriate for the most sensitive data.
Encryption at rest	Data on disk is unrecoverable without the encryption key, even if the underlying bytes are read.	Yes, provided the key itself is properly managed and eventually destroyed or rotated.

Plan before ingestion, not at deletion time. Encryption at rest is the only one of these methods that has to be decided before the data is ever ingested. If a source's compliance requirement (GDPR, HIPAA, or similar) mandates secure erasure, confirm the encryption-at-rest posture during onboarding rather than discovering the gap when a deletion request arrives.

Example

[example_index]
homePath   = $SPLUNK_DB/example_index/db
coldPath   = $SPLUNK_DB/example_index/colddb
thawedPath = $SPLUNK_DB/example_index/thaweddb

maxDataSize        = 750
maxHotSpanSecs      = 86400      # roll hot to warm at least daily
maxWarmDBCount      = 30
frozenTimePeriodInSecs = 5184000 # 60 days total (30 warm + 30 cold)

# Archive instead of delete when a bucket freezes:
coldToFrozenDir    = /path/to/archive/example_index

This configuration keeps roughly 60 days of searchable data (30 in warm, 30 in cold) and archives everything older instead of deleting it. Adjust maxHotSpanSecs, maxWarmDBCount and frozenTimePeriodInSecs to match the source's actual ingest volume and the approved Retention Policy period.

Validation

Confirm the retention period recorded on the Retention Policy record matches the deployed indexes.conf stanza for that specific index -- don't assume a platform-wide default applies without checking.
Distinguish "deleted" from "archived": an index with no coldToFrozenDir or coldToFrozenScript loses its cold data permanently once it freezes.
If secure erasure is a compliance requirement, decide the method (encryption at rest, storage wipe, physical destruction) before ingestion begins, not at deletion time.
Test splunk rebuild against a real thawed bucket before relying on it during an incident or legal-hold scenario.
Clean up thawed buckets manually after use -- Splunk does not expire or manage them automatically.
Check maxTotalDataSizeMB as well as frozenTimePeriodInSecs -- an index can freeze data early on size alone, even before its configured age limit.

← Back to References

References / Data Collection & Routing

Transport Delivery Patterns

Comparison reference for the four Transport Delivery Pattern (TAX-03.02.07) children -- Event-Driven Delivery (TAX-03.02.07.01), Managed Retrieval or Polling (TAX-03.02.07.02), Local Buffering and Store-and-Forward (TAX-03.02.07.03), and Direct Point-to-Point Integration (TAX-03.02.07.04) -- across positioning, fit, use cases, strengths, risks, validation focus and operational characteristics.

Comparison matrix

Category	Event-Driven Delivery	Managed Retrieval or Polling	Local Buffering and Store-and-Forward	Direct Point-to-Point Integration
Pattern Positioning	Stronger enterprise pattern when engineered correctly.	Useful where streaming or event-driven delivery is unavailable.	Resilience-focused pattern for constrained or intermittently connected environments.	Limited or narrow-use pattern.
Best Fit	High-value telemetry where timeliness, monitoring, and early response matter.	Sources exposing telemetry through APIs, scheduled exports, administrative feeds, or other provider retrieval mechanisms.	Remote, segmented, bandwidth-constrained, OT, IoT, specialized, or intermittently connected environments.	Limited use cases with narrow scope, legacy constraints, temporary requirements, or unavoidable source limitations.
Use Cases	Identity events; cloud control-plane activity; security alerts; endpoint detections; native event buses; webhooks; brokered forwarding.	SaaS audit feeds; periodic exports; administrative APIs; reconciliation; historical retrieval; targeted backfill.	Remote sites; segmented enclaves; OT gateways; branch environments; constrained systems; isolated networks.	Small-scale integrations; temporary feeds; legacy tools; tightly scoped source-to-destination connections.
Strengths	Low latency; timely detection; strong potential for durable handoff; acknowledgement; buffering; replay; scalable routing; better operational awareness when properly engineered.	Works where streaming is unavailable; supports backfill, reconciliation, completeness checking, historical recovery, and controlled retrieval.	Preserves data close to the source; supports buffering and delayed forwarding; tolerates connectivity interruptions and downstream outages.	Simple initial design for narrow use cases; fewer intermediary components; potentially low transport latency.
Risks / Limits	Requires source support, queue design, acknowledgement, back-pressure handling, replay, transport monitoring, failure handling, and operational ownership.	Can introduce lag, missed retrieval windows, pagination gaps, API limits, checkpoint failures, provider dependency, and weaker real-time monitoring.	Delayed availability; local storage limitations; buffer exhaustion; gateway dependency; prolonged outage risk; potential provenance loss if forwarding is poorly designed.	Brittle at enterprise scale; tightly coupled; difficult to govern; often weak buffering, checkpointing, replay, health monitoring, and failure recovery.
Validation Focus	Measure source-to-destination latency, acknowledgement success, queue depth, queue age, throughput, transport health, retry behaviour, back pressure, partial failures, dropped events, replay success, and completeness.	Measure retrieval lag, checkpoint age, missed intervals, API failures, pagination completeness, retry behaviour, duplicate handling, schema drift, provider changes, and record completeness.	Validate buffer capacity, oldest queued event, timestamp preservation, forwarding success, queue persistence, storage utilisation, retry behaviour, replay after outage, and recovery after connectivity restoration.	Confirm ownership, endpoint availability, connectivity, failure visibility, dropped-event detection, transport health, change control, and migration path to a more durable pattern.
Detail	Event-driven delivery is generally the preferred pattern for high-value security telemetry sources that support it. Native export, streaming delivery, brokered forwarding, webhooks, event buses, and similar mechanisms should be favored where timeliness matters for monitoring or early response. Durable handoff should include acknowledgement, buffering, retry, back-pressure handling, replay, partial-failure awareness, and visibility into queue or transport health. Cloud and SaaS environments should generally use the strongest provider-native delivery mechanism that supports required timeliness, fidelity, integrity, and operational monitoring.	Retrieval and polling remain valid where a source exposes telemetry only through APIs, periodic export, scheduled retrieval, or administrative audit interfaces. Polling is useful as a bounded secondary capability for backfill, reconciliation, completeness checking, or recovery, but should not become the hidden default where operationally relevant telemetry could be delivered more directly. Checkpointing, cursors, pagination state, retrieval windows, and retry behaviour should be explicitly managed.	Local buffering and store-and-forward patterns are appropriate where direct low-latency delivery would introduce operational strain or is not technically feasible. This is common in remote, segmented, bandwidth-constrained, OT, IoT, or specialized environments. Events should remain durably buffered until forwarding succeeds, while original timestamps, provenance, integrity, ordering requirements, buffer state, and delivery awareness are preserved.	Direct point-to-point integration should generally be reserved for narrow, temporary, legacy, or otherwise constrained use cases. Where durable handoff, buffering, checkpointing, replay, health monitoring, or strong failure recovery are absent, these should be treated as explicit operational limitations rather than assumed capabilities.
Timeliness	High. Usually near-real-time or low-latency. Well suited to active monitoring, detection, alerting, and early response. Measure event creation time, queue delay, transport delay, and arrival time.	Medium–Low. Determined by polling interval, API availability, rate limits, pagination, retrieval windows, and provider processing delay. Define and monitor acceptable retrieval lag.	Variable. Events may be generated immediately but delivered later due to connectivity, bandwidth, buffering, or operational constraints. Track original event time separately from receipt time.	Potentially High, but direct low latency does not necessarily imply reliable, complete, or observable delivery.
Encryption	Use TLS/mTLS or equivalent provider-native encryption. Protect certificates, trust relationships, credentials, tokens, message integrity, and broker connections.	Use TLS for APIs and exports. Protect API keys, OAuth tokens, service credentials, secrets, certificates, and provider trust configuration.	Encrypt data in transit and, where buffered locally, at rest. Protect spool files, queues, local disks, credentials, and forwarding channels.	Require encrypted transport wherever supported. Direct integrations should not bypass enterprise TLS, authentication, certificate, or credential-management requirements.
Reliability	High when properly engineered. Reliability depends on durable handoff, acknowledgement, persistent queues, retry, back-pressure handling, redundancy, delivery guarantees, and health monitoring. Temporary source, broker, network, or destination failure should not cause silent loss.	Medium–High when managed carefully. Reliability depends on stable APIs, checkpointing, pagination, retry logic, retention windows, rate-limit handling, and the ability to detect and recover missed retrieval periods. Successful API calls alone should not be treated as proof of complete collection.	High for disruption tolerance. Reliability depends on sufficient buffer capacity, persistent storage, queue durability, retry behaviour, controlled recovery, and protection against buffer exhaustion. Validate behaviour after restart, prolonged outage, or downstream unavailability.	Variable and often lower at scale. Reliability depends directly on both endpoints and the intervening path. Without buffering, retry, acknowledgement, or replay, transient failures may cause permanent loss.
Resilience	High when engineered correctly. Require durable handoff, acknowledgement, persistent buffering, retry, flow control, back pressure, queue persistence, redundancy, and graceful handling of partial failure. Temporary outages should not cause silent loss.	Medium. Recovery depends on provider retention, checkpoints, pagination, retry logic, historical query capability, and detection of partial provider or API failure.	High for connectivity disruption. Buffering and store-and-forward are core resilience mechanisms. Size storage for expected outage duration, define buffer exhaustion behaviour, and validate recovery after prolonged interruption.	Generally Low–Medium. Tight coupling makes source, destination, or path failure significant. Without explicit buffering and retry, interruptions may cause loss or require manual recovery.
Replay	Support offsets, checkpoints, acknowledgements, durable queues, broker retention, or equivalent mechanisms. Validate replay window, ordering, duplicate handling, idempotency, and reprocessing behaviour.	Use checkpoints, cursors, timestamps, sequence identifiers, continuation tokens, or retrieval windows. Validate bounded backfill, resume-from-last-success, duplicate suppression, and missed-record recovery.	Replay is a core capability. Buffered events should remain until successfully forwarded or until an explicitly defined retention threshold is reached. Validate ordering, duplicate handling, queue persistence, and recovery after restart or outage.	Often weak or absent. If replay is unavailable, document the potential for unrecoverable loss and consider migration to a more durable pattern.
Provenance	Preserve original source identity, source-generated timestamp, event ID, tenant/account/subscription context, sequence information, and intermediary routing metadata where practical. Broker or forwarding layers should not obscure the authoritative source.	Preserve provider identity, tenant/account context, original timestamps, record IDs, API endpoint or dataset, retrieval time, checkpoint/cursor state, and collection method. Distinguish event time from retrieval time.	Preserve original timestamps, source system identity, device/site identity, sequence information, and collection metadata while events are buffered. Gateways should not replace the authoritative source identity with their own unless clearly represented as intermediary metadata.	Preserve original source identity and timestamps even when the destination receives data directly. Avoid replacing source provenance with proxy, NAT, collector, or transport-layer identity. Document any transformation or enrichment applied in transit.
Change Over Time	Monitor changes to schemas, event versions, broker topics, native exports, certificates, endpoints, authentication, routing, queue configuration, and provider delivery guarantees. Test changes against buffering, replay, back-pressure, and downstream parsing.	Monitor API versions, schemas, authentication methods, pagination behaviour, rate limits, retention, endpoints, permissions, provider deprecations, and checkpoint compatibility.	Monitor gateway software, local storage capacity, filesystem utilisation, queue format, certificates, forwarding destinations, network paths, buffer configuration, and environmental constraints.	Higher change risk because of tight coupling. Track endpoint, schema, network, authentication, application, ownership, and dependency changes through formal change control and testing.

← Back to References

References / Splunk platform configuration

Access Control

Access Control (TAX-02.08) records who can access a data source, index or platform's data, the model used to grant that access, and the approval and review process governing it. This article documents the Splunk mechanism behind that record: predefined and custom roles, the capability model, and how LDAP/SAML authentication maps external identities onto Splunk roles.

Definition

An Access Control record documents the access control model applied to an index, source or platform -- role-based (RBAC) or attribute-based (ABAC) -- the specific roles or groups granted access and their scope, the approval authority behind each grant, and the review cadence. In Splunk, RBAC is the default and dominant model: every user is assigned one or more roles, and a role's capabilities and index access are what the recorded model and scope actually describe.

Predefined roles

Splunk ships four predefined roles. Splunk's own guidance is not to edit these directly -- build custom roles that importRoles from one of them instead.

Role	Capabilities
`admin`	The most capabilities of any predefined role; full administrative control over the platform.
`power`	Can edit all shared objects (saved searches, alerts and similar), tag events, and perform other privileged-but-non-administrative tasks.
`user`	Can create and edit only their own saved searches, run searches, edit their own preferences, and create/edit event types.
`can_delete`	Grants the ability to delete indexed data by keyword (the `delete` SPL command). Not granted to any predefined role by default -- must be explicitly added, and should be treated as high-risk.

authorize.conf settings

Custom roles are defined in authorize.conf, one stanza per role.

Setting	Definition
`<capability> = enabled`	Grants a specific capability (for example `edit_user`, `admin_all_objects`, `rtsearch`). Capabilities are additive only -- there is no explicit "deny" -- so a user's effective permissions are the union of every role and imported role they hold.
`importRoles`	Inherits every capability and setting from one or more other roles. The recommended way to build a custom role: import a predefined role, then adjust only what differs.
`srchIndexesAllowed`	The indexes a role is permitted to search; supports wildcards (for example `security_*`).
`srchIndexesDefault`	The indexes searched automatically when a search doesn't specify one explicitly.
`srchFilter`	A search-time filter automatically applied to every search the role runs, restricting which events are visible even within an allowed index.
`srchJobsQuota` / `rtSrchJobsQuota`	The number of concurrent historical / real-time search jobs the role may run.
`srchDiskQuota`	The maximum disk space this role's search-job artifacts may consume, in MB.
`srchTimeWin`	Limits how far a scheduled search's time range can be adjusted at dispatch time.

Authentication integration

Role assignment is separate from authentication -- authorize.conf defines what a role can do, while authentication.conf defines how a user proves who they are and which roles they receive.

Method	Config	Definition
Native	`authentication.conf` (`authType = Splunk`)	Splunk's built-in username/password store; roles are assigned directly to the local user record.
LDAP	`authentication.conf` (an `authenticationLDAP:...` stanza)	Authenticates against an existing LDAP/Active Directory server; LDAP groups are mapped to Splunk roles via a group-to-role mapping stanza.
SAML	`authentication.conf` (`saml` / `samlSp...` stanzas)	Integrates with an external SAML identity provider for single sign-on; the IdP asserts group or role attributes that are mapped to Splunk roles.

Mapping drift. When an LDAP group or SAML IdP attribute mapping changes upstream, a user's effective Splunk capabilities change on their next login -- without any change made inside Splunk itself. This is a real risk for Access Review Cadence (TAX-02.08.04): a review that only checks Splunk's own role assignments can miss a privilege change that originated in the identity provider.

Example

[role_analyst]
importRoles = user
srchIndexesAllowed = main;security_*
srchIndexesDefault = security_events
srchJobsQuota = 6
srchDiskQuota = 500
srchTimeWin = 86400
rtsearch = disabled

This role inherits everything from user, then narrows search to the main and security_* indexes, defaults searches to security_events, caps concurrent jobs and disk usage, and disables real-time search.

Validation

Confirm the Access Control Model (TAX-02.08.01) recorded matches the actual authorize.conf role assignments deployed, not intended policy.
Build custom roles by importRoles from a predefined role rather than editing admin/power/user directly.
Remember capabilities are additive only -- check every imported role, not just the directly assigned one, when reasoning about a user's effective permissions.
Verify srchIndexesAllowed doesn't grant broader index access than the Authorised Role/Group (TAX-02.08.02) record states.
Reconcile LDAP/SAML group-to-role mappings against Access Review Cadence (TAX-02.08.04) -- upstream group membership changes silently change Splunk capabilities.
Treat can_delete as a high-risk capability requiring its own entry in Access Approval Reference (TAX-02.08.03), since it isn't granted to any role by default.

← Back to References

References / Splunk platform configuration

File Monitoring Profile

A structured profile for documenting a file-based Splunk data source end to end -- identification, lifecycle, access, characteristics, size, parsing, collection behaviour, identity/duplicate handling, metadata, security and assurance. Use it to capture everything an onboarding engineer needs to know about a monitored file before writing the inputs.conf stanza, and to check the resulting configuration against.

Definition

The File Monitoring Profile is a twelve-branch checklist for the file-level mechanics of a Splunk monitor:// or batch:// input -- distinct from, and sitting beneath, the general Data Source and Collection Configuration records that describe any input type. It separates file size from event size, and separates file lifecycle at the source from Splunk's own collection and index-side behaviour, so that a slow-growing multi-gigabyte log file and a fast-rotating small one are assessed on the dimensions that actually differ between them.

File Identification & File Lifecycle

File Identification -- where the file lives and how it is named.

Field	Captures	Taxonomy reference
Path	The directory (or directories) the input stanza targets.	TAX-03.04.02 Input Parameters — generic
Filename pattern	The wildcard/glob expression identifying which files in the path belong to this input.	TAX-03.04.02 Input Parameters — generic
Extension	The expected file extension (`.log`, `.csv`, `.json`, etc.).	TAX-03.04.02 Input Parameters — generic
Directory structure	How files are organised into subdirectories -- flat, dated, per-host, per-application.	TAX-03.04.02 Input Parameters — generic
File naming convention	The pattern the producing application uses to name files, including any embedded date, host or sequence token.	TAX-03.04.02 Input Parameters — generic

File Lifecycle -- how a monitored file is created, appended to, rotated and eventually retired at the source, independent of Splunk's own bucket lifecycle.

Field	Captures	Taxonomy reference
Creation behaviour	How and when the file first comes into existence -- pre-allocated, created on first write, or created per rotation cycle.	TAX-03.06.01 File Lifecycle
Append behaviour	Continuously appended, periodically appended, delivered only once complete, or immutable/write-once after creation.	TAX-03.06.01.01 Append Behaviour
Rotation mechanism	How the file is rotated once its threshold is reached -- rename, copy/truncate, numbered rotation, timestamped rotation, or full replacement.	TAX-03.06.01.02 Rotation Mechanism
Rotation threshold	The trigger that causes rotation -- size-based, time-based, or controlled by the writing application's own logic.	TAX-03.06.01.03 Rotation Threshold
Retention	How long rotated or completed files are kept at the source, independent of Splunk's own index retention.	TAX-03.06.01.04 Source Retention & Deletion
Compression	Whether rotated files are compressed at the source, and in what format.	TAX-03.06.01.04 Source Retention & Deletion
Deletion behaviour	What deletes rotated/completed files at the source, and what triggers it.	TAX-03.06.01.04 Source Retention & Deletion

File Access & Filesystem

Permissions, sharing and locking behaviour that govern whether and how the collection component can read a monitored file, including network-filesystem-specific considerations.

Field	Captures	Taxonomy reference
Permissions	Filesystem permissions on the monitored file or directory.	TAX-03.06.02.01 File Permissions & Ownership
Ownership	The owning user/group of the file or directory.	TAX-03.06.02.01 File Permissions & Ownership
Splunk service account access	Confirmation that the account the collection component runs as actually has read access.	TAX-03.06.02.01 File Permissions & Ownership
Read sharing	Whether other processes read the file concurrently with Splunk's collection.	TAX-03.06.02.02 Concurrent Read & Locking Behaviour
Write sharing	Whether other processes write to the file concurrently with Splunk's collection.	TAX-03.06.02.02 Concurrent Read & Locking Behaviour
Concurrent read behaviour	What happens when the collection component and the producing application access the file at the same time.	TAX-03.06.02.02 Concurrent Read & Locking Behaviour
File locking	Lock type, duration, exclusive-lock behaviour and release behaviour.	TAX-03.06.02.02 Concurrent Read & Locking Behaviour
Filesystem	Local filesystem, or a network filesystem (SMB, NFS) with its own locking and latency considerations.	TAX-03.06.02.03 Filesystem Type

File Characteristics & Event Parsing

File Characteristics -- the raw structure of the file content.

Field	Captures	Taxonomy reference
Format	Structured, semi-structured or unstructured.	TAX-04.05.01 Data Format
Serialization	JSON, XML, CSV, TSV, syslog, CEF or raw/proprietary.	TAX-04.05.01 Data Format
Encoding	The character encoding needed to safely parse the event stream.	TAX-04.05.02 Encoding & Character Set
BOM	Whether the file carries a byte-order mark that must be stripped before parsing.	TAX-04.05.02 Encoding & Character Set — generic
Header	A known preamble or field-label row appearing before the event data.	TAX-04.05.03 Header / Prefix Pattern
Footer	A known trailer or summary row appearing after the event data.	TAX-04.05.03 Header / Prefix Pattern — generic
Line structure	Single-line-per-event versus multi-line-per-event layout.	TAX-04.03 Line Breaking
Escaping / quoting	How delimiters and special characters are escaped or quoted within a field.	TAX-04.06.04 DELIMS

Event Parsing -- how Splunk turns the raw file content into individual, correctly timestamped events.

Field	Captures	Taxonomy reference
Event structure	Single-line or multi-line events.	TAX-04.03.03 Multiline Event Handling
Event boundary	What marks where one event ends and the next begins.	TAX-04.03.04 Event Boundary Handling
Event start pattern	The pattern used to recognise the start of a new event, typically a `LINE_BREAKER` regex.	TAX-04.03.01 LINE_BREAKER
Line breaking	How the raw stream is split into individual events.	TAX-04.03.01 LINE_BREAKER; TAX-04.03.02 SHOULD_LINEMERGE
Timestamp present / location / format / length	Whether event time is present, where in the event it sits, its format and its length.	TAX-04.01.01 Datetime Format; TAX-04.02.01 Timestamp Location
Timezone	Explicit offset, or the source timezone that must be configured.	TAX-04.01.02 Timezone
Multiple timestamp formats	Whether the file mixes more than one timestamp format across its events.	TAX-04.02.06 Parsing Examples — generic
Character set	The character set assumption event parsing relies on.	TAX-04.05.02 Encoding & Character Set
Sourcetype	The sourcetype classification assigned at index time.	TAX-04.11.01 Sourcetype

File Size & Growth, Event Size

File size is assessed separately from event size: a large file made of small events behaves very differently from a small file made of a few enormous ones.

Field	Captures	Taxonomy reference
Current / average / maximum / initial file size	The file's size profile over its lifecycle.	Not modeled
>20 MB assessment flag	A trigger for deeper evaluation of file-processing behaviour -- not an automatic indication the file is unsuitable for monitoring.	Not modeled
Growth rate (average / peak)	How quickly the file grows under typical and peak conditions.	TAX-04.08 Event Volume Profile
Files per day	How many new files this input produces daily, where rotation creates new files rather than appending indefinitely.	TAX-04.08 Event Volume Profile — generic
Historical backlog / backlog size	Pre-existing unread data at onboarding time, and its volume.	TAX-03.04.04 Batch / Checkpoint State — generic
Daily ingest volume	The expected daily indexed volume this source contributes.	TAX-04.08.03 Daily GB
Events per file	The typical number of events contained in one file.	Not modeled
Average / maximum event size	The typical and largest individual event sizes.	TAX-04.04.02 UTF-8 Byte Length; TAX-04.04.03 Event Size Recommendations
Maximum line length	The largest single physical line the source produces.	TAX-04.04.02 UTF-8 Byte Length
Multi-line event size	The size of a complete event when it spans multiple physical lines.	TAX-04.04.03 Event Size Recommendations; TAX-04.04.04 Large Event Handling
TRUNCATE requirement	Whether the default `TRUNCATE` value must be raised to avoid silently cutting off oversized events.	TAX-04.04.01 TRUNCATE

Collection Behaviour & Identity Tracking

How the collection component actually monitors the file, recognises completion and rotation, and tracks file identity to avoid duplicate or missed ingestion.

Field	Captures	Taxonomy reference
Collector	Universal Forwarder, Heavy Forwarder, or a full Splunk Enterprise instance.	TAX-03.03.02 Collector
Splunk collection mode	`monitor://` (tail) or `batch://` (whole-file, one-time).	TAX-03.06.03.01 Collection Mode
Collection method -- Tail Monitoring	`monitor://` against a persistent, growing file: append monitoring, rotation handling, CRC tracking, Fishbucket tracking, the `TailingProcessor`.	TAX-03.06.03.01 Collection Mode; TAX-03.06.03.03 CRC & Fishbucket Identity Tracking
Collection method -- Batch Monitoring	`batch://` against completed files: whole-file processing, completion and lock-state validation, post-processing (typically delete).	TAX-03.06.03.01 Collection Mode
Processor behaviour	How the tail or batch processor actually behaves once monitoring begins.	TAX-03.06.03.01 Collection Mode — generic
File completion behaviour	File closed, lock released, rename, marker file, or the producer signalling it has finished writing.	TAX-03.06.03.02 File Completion Detection
Include / exclude rules, wildcards, recursion	Which files within a monitored path are actually collected, and whether monitoring recurses into subdirectories.	TAX-03.06.03.04 Include / Exclude & Recursive Monitoring Rules
Collection interval / behaviour	How often a pull-based collector checks the source.	TAX-03.04.03 Polling Interval

File Identity & Duplicate Handling -- how the collection component avoids re-reading or skipping a file.

Field	Captures	Taxonomy reference
CRC behaviour & sampling	How the CRC used to identify a file is computed and which bytes it samples.	TAX-03.06.03.03 CRC & Fishbucket Identity Tracking
`crcSalt` requirement	Whether a salt is required to disambiguate files that would otherwise produce identical CRCs.	TAX-03.06.03.03 CRC & Fishbucket Identity Tracking
Fishbucket state	The record of how much of the file has already been read.	TAX-03.06.03.03 CRC & Fishbucket Identity Tracking
Filename reuse / identical headers / file replacement / truncation / rewrite	Known scenarios that can fool identity tracking into skipping or re-reading data.	TAX-03.06.03.03 CRC & Fishbucket Identity Tracking — generic
Rotation recognition	Whether the tracking mechanism correctly recognises a rotated file as the same logical source.	TAX-03.06.03.03 CRC & Fishbucket Identity Tracking
Duplicate ingestion risk	The overall assessed risk of duplicate or lost events for this source.	TAX-03.06.03.03 CRC & Fishbucket Identity Tracking

Metadata, Security & Assurance

Splunk Metadata & Routing

Field	Captures	Taxonomy reference
Index	The target index for this input's events.	TAX-03.01.03 Index Destination
Sourcetype	The sourcetype assigned to this input's events.	TAX-04.11.01 Sourcetype
Source	The recorded `source` value, typically the file path.	TAX-03.01.02 Data Source–Input Mapping
Host	The host value assigned -- from the collector, or overridden per input.	TAX-01.01.03 System Name
Application	The application or system this file belongs to.	TAX-01.01.05 System Application Type
Environment	Production, test, staging, etc.	TAX-01.03.01 Environment
Routing / filtering requirements	Any rule that routes or drops events from this input before or during indexing.	TAX-03.02.03.03 Destination Rule; TAX-03.02.03.04 Drop / Keep Routing Rule

Security & Data Handling

Field	Captures	Taxonomy reference
Data classification	The sensitivity classification of this data source's content.	TAX-02.02.06 Data Classification
Sensitive information / PII	Whether the file is known or expected to carry sensitive personal data.	TAX-02.02.06 Data Classification
Credentials / secrets	Whether the file can contain credentials or secrets that require special handling.	TAX-04.13.08 Field Masking / Redaction Rule
Masking requirements	Fields or patterns that must be masked or redacted before storage.	TAX-04.13.02 Masking Rule; TAX-04.13.08 Field Masking / Redaction Rule
Filtering requirements	Events that must be filtered out before or during ingestion for compliance or noise-reduction reasons.	TAX-04.13.06 Event Filtering Rule
Access restrictions	Who is permitted to search this data once indexed.	TAX-02.08 Access Control
Retention requirements	The approved retention period for this source's data.	TAX-02.06.05 Retention Policy

Assurance

Field	Captures	Taxonomy reference
File exists / discovered / permissions valid / readable / not exclusively locked	Pre-collection reachability checks.	TAX-04.10.04 Parsing, Line Breaking & Timestamp Check
Concurrent read successful / file changing as expected	Confirmation the file behaves as profiled during live collection.	TAX-04.10.04 Parsing, Line Breaking & Timestamp Check
Completion detected / rotation detected / old file fully consumed / new file discovered	Confirmation lifecycle transitions are handled correctly.	TAX-04.10.04 Parsing, Line Breaking & Timestamp Check
Bytes read / events collected / event boundaries correct / timestamp correct	Confirmation of correct low-level collection and parsing.	TAX-04.10.04 Parsing, Line Breaking & Timestamp Check
Events forwarded / events indexed	Confirmation of successful end-to-end delivery.	TAX-04.10.04 Parsing, Line Breaking & Timestamp Check
No duplicate ingestion / no missing events / collection lag	Ongoing data-quality checks against expected behaviour.	TAX-04.10.03 Volume, Gap & Duplicate Check
Expected event count / expected volume / backlog within tolerance	Confirmation collected volume matches the profiled expectation.	TAX-04.10.02 Presence & Timeliness Check; TAX-04.08 Event Volume Profile

Taxonomy coverage

Checked against both taxonomies in this app. Onboard Taxonomy (TAX-XX) already carries a dedicated file-monitoring branch, TAX-03.06 "File Monitoring Mechanics", with children for File Lifecycle, File Access & Locking, and Tail/Batch Collection & Identity Tracking -- plus generic collection fields under TAX-03.03/03.04, parsing/quality fields under TAX-04, governance fields under TAX-02, and assurance fields under TAX-06. Splunk Taxonomy (SOT-XX) cross-links to the same TAX codes via its relatedTax field on the Data Input (SOT-05.01.01), Source Type (SOT-02.01.01) and Index (SOT-06.01.01) objects -- so both taxonomies already model this profile, from their own respective angles, rather than needing a new branch.

Profile branch	Onboard Taxonomy	Splunk Taxonomy	Coverage
File Identification	TAX-03.04.01 Input Stanza; TAX-03.04.02 Input Parameters	Data Input (SOT-05.01.01)	Partial -- path is a named example parameter; filename pattern, extension, directory structure and naming convention are not individually named fields.
File Lifecycle	TAX-03.06.01 + 4 children	Data Input (`relatedTax` includes TAX-03.06)	Direct -- dedicated branch.
File Access	TAX-03.06.02 + 3 children	Data Input (`relatedTax` includes TAX-03.06)	Direct -- dedicated branch; read/write sharing folded into Concurrent Read & Locking Behaviour.
File Characteristics	TAX-04.05 Log Format Detection & Parsing; TAX-04.06.04 DELIMS	Source Type (`relatedTax` includes TAX-04.05.01/.04)	Mostly direct -- format/serialization/encoding/header covered; BOM and footer are generic, not individually named.
File Size & Growth	TAX-04.08 Event Volume Profile; TAX-03.04.04 Batch/Checkpoint State	Data Input	Partial -- EPS/daily/monthly volume and forecasting are direct; literal file-size-in-bytes metrics and the >20 MB flag are assessment-time working data, not taxonomy fields.
Event Size	TAX-04.04 Line Length + 4 children	Source Type	Direct -- dedicated branch.
Event Parsing	TAX-04.01 Datetime Standards; TAX-04.02 Datetime Parsing; TAX-04.03 Line Breaking; TAX-04.05.02; TAX-04.11.01 Sourcetype	Source Type	Direct -- extensively covered.
Collection Behaviour	TAX-03.03.01/.02; TAX-03.04.01–.03; TAX-03.06.03 + children	Data Input (`relatedTax` includes TAX-03.06.03*)	Direct -- dedicated branch.
File Identity & Duplicate Handling	TAX-03.06.03.03 CRC & Fishbucket Identity Tracking	Data Input (`relatedTax` includes TAX-03.06.03.03)	Direct at the mechanism level; individual failure scenarios (filename reuse, identical headers, etc.) are covered generically via its duplicate/loss-risk attribute, not named separately.
Splunk Metadata & Routing	TAX-03.01.02/.03; TAX-04.11.01; TAX-03.02.03.03/.04; TAX-01.01.03/.05, TAX-01.03.01 (host/app/environment)	Index (SOT-06.01.01); Source Type	Direct -- host/application/environment are recorded at the platform/system level (TAX-01) rather than per input.
Security & Data Handling	TAX-02.02.06 Data Classification; TAX-04.13.02/.08 Masking/Redaction; TAX-02.06.05 Retention Policy; TAX-02.08 Access Control	—	Direct -- covered by the Governance & Compliance domain, which applies platform-wide rather than per input type.
Assurance	TAX-04.10.02–.04 Health Checks; TAX-06.03.02 Data Source Assurance Roll-up	—	Direct -- file-mechanics assurance rolls up through the general data-quality and assurance framework rather than each check having its own named field.

Net finding: nine of the twelve branches are directly represented by existing taxonomy fields today. The remaining three -- File Identification, File Characteristics and File Size & Growth -- are covered at a generic or assessment-working-data level rather than by individually named fields; that is a deliberate design choice already in place (these are exactly the kind of source-specific, high-cardinality details -- literal file paths, byte counts -- the taxonomy intentionally keeps out of its fixed field catalogue), not a gap that needs a new taxonomy branch.

Design notes

File size is assessed separately from event size, and file lifecycle at the source is assessed separately from Splunk's own collection/index-side behaviour -- a large file of small events and a small file of huge events fail differently, and source-side rotation is independent of Splunk's bucket lifecycle.
The >20 MB assessment flag is a trigger for deeper evaluation of file-processing behaviour, not an automatic indication that a file is unsuitable for Splunk monitoring.
CRC and Fishbucket considerations are kept as their own branch because file identity, state tracking and duplicate prevention are core aspects of Splunk file monitoring, not an edge case.

← Back to References

References / Splunk platform configuration

REST API Collection Profile

A structured profile for documenting a REST-API-based Splunk data source end to end -- endpoint identification, authentication, request construction, pagination, polling/checkpointing, rate limiting, response handling, reliability, identity/duplicate handling, metadata, security and assurance. Companion to the File Monitoring Profile, for sources pulled by a scripted or modular input rather than tailed from a local file.

Definition

The REST API Collection Profile is a twelve-branch checklist for the mechanics of a Splunk collector that polls a vendor or internal REST API on a schedule -- typically a modular input, but equally applicable to a DB Connect-style scripted poll or a Heavy Forwarder scripted input. It is the pull-based counterpart to the File Monitoring Profile: instead of a persistent file being tailed or batch-read, a stateless HTTP request is issued repeatedly against a remote endpoint, and the profile exists to make explicit everything that differs about that model -- authentication and token lifecycle, pagination through a result set, vendor-imposed rate limits, and cursor-based checkpointing in place of file-offset tracking.

Endpoint Identification & Authentication

Endpoint Identification -- what is being called and where.

Field	Captures	Taxonomy reference
Base URL	The root API endpoint the collector calls, for example `https://api.vendor.com`.	TAX-03.04.02 Input Parameters — generic
Endpoint path / resource	The specific REST resource or collection being polled.	TAX-03.04.02 Input Parameters — generic
API version	The API version pinned or negotiated, via URL path segment, header, or query parameter.	TAX-03.04.02 Input Parameters — generic
Environment	Production, sandbox/test, or a region-specific endpoint.	TAX-03.04.02 Input Parameters — generic
Query parameters	Static filters, field selection, or scope parameters applied to every request.	TAX-03.04.02 Input Parameters — generic

Authentication & Authorization -- how the collector proves its identity to the API.

Field	Captures	Taxonomy reference
Authentication method	API key, OAuth2 (client credentials or authorization code), Basic Auth, bearer token, mutual TLS, or a signed-request scheme such as AWS SigV4.	TAX-03.05.01 Authentication Method
Credential type	The credential material itself -- password, client secret, private key, certificate.	TAX-03.05.02 Credential Type
Credential storage location	Where the credential is stored -- Splunk's encrypted password store, or an external secret manager.	TAX-03.05.10 Secret Storage Location
Token refresh / expiry handling	How an expiring access token is renewed before or after it lapses.	TAX-03.05.11 Credential Rotation
Permission scope	The API scopes or permissions the credential was actually granted.	TAX-03.05.12 Permission Scope
Least privilege validation	Confirmation the credential holds only the read access this collection needs.	TAX-03.05.13 Least Privilege Validation
Authentication failure handling	Expected behaviour, alerting and retry when a call is rejected as unauthenticated or unauthorized.	TAX-03.05.14 Authentication Failure Handling

Request Construction & Pagination

Request Construction -- the shape of each individual call.

Field	Captures	Taxonomy reference
HTTP method	`GET` for most read polling; `POST` where the API requires a query body.	TAX-03.04.02 Input Parameters — generic
Request headers	Custom headers required by the API -- content negotiation, tenant identifiers, correlation IDs.	TAX-03.04.02 Input Parameters — generic
Request body / query template	The templated payload sent for query-by-body APIs (GraphQL-style or search-style REST endpoints).	TAX-03.04.02 Input Parameters — generic
Timeout	How long the collector waits for a response before treating the call as failed.	TAX-03.04.05 Retry / Backoff Configuration
Concurrency / parallel requests	Whether the collector issues more than one request at a time, and how many.	Not modeled

Pagination & Result Set Handling -- how a result set larger than one response is retrieved in full.

Field	Captures	Taxonomy reference
Pagination mechanism	Offset/limit, cursor or continuation token, page number, or a `Link`/`next` response header.	Not modeled
Page size	The number of records requested per page, and any vendor-imposed maximum.	Not modeled
Total-results / has-more indicator	How the collector knows another page exists -- a total count, a next-page token, or an empty final page.	Not modeled
Multi-page aggregation behaviour	Whether pages are emitted as events as they arrive, or assembled before indexing.	Not modeled

Polling, Scheduling & Rate Limits

Polling, Scheduling & Checkpointing

Field	Captures	Taxonomy reference
Polling interval	How often the collector calls the endpoint.	TAX-03.04.03 Polling Interval
Polling mode	Fixed interval, cron-style schedule, or event-driven (webhook) delivery in place of polling.	TAX-03.04.03 Polling Interval — generic
Checkpoint / cursor state	The since-timestamp, sequence ID, or continuation token that marks how far collection has progressed.	TAX-03.04.04 Batch / Checkpoint State
Backfill / historical pull behaviour	How the collector handles an initial or resumed run that must catch up on historical data.	TAX-03.04.04 Batch / Checkpoint State — generic
Overlap / de-duplication window	A deliberate overlap between polling windows used to avoid missing boundary records, and how the resulting duplicates are handled.	TAX-03.04.04 Batch / Checkpoint State — generic

Rate Limiting & Throttling

Field	Captures	Taxonomy reference
Rate limit type	Requests per second, requests per minute, or a daily/monthly quota.	Not modeled
Rate limit signal	How the API communicates the limit -- `X-RateLimit-*` response headers, or an HTTP 429 status.	Not modeled
Backoff strategy	Fixed delay, exponential backoff, or a vendor-specified `Retry-After` value.	TAX-03.04.05 Retry / Backoff Configuration
Concurrent request limit	The maximum number of simultaneous in-flight requests the API tolerates.	Not modeled
Vendor-specific quota tier	Any account/subscription tier that changes the effective rate limit.	Not modeled

Response Handling & Reliability

Response Handling & Parsing

Field	Captures	Taxonomy reference
Response format	JSON, XML, or CSV.	TAX-04.05.01 Data Format
Response envelope structure	A wrapping object around the actual records -- a `data` array, a `metadata` block, both.	TAX-04.05.01 Data Format — generic
Nested object flattening	How deeply nested response fields are flattened into indexable fields.	TAX-04.06.01 Extracted Fields — generic
Array / list event splitting	Whether one API response containing many records is split into one Splunk event per record.	Not modeled
Error response structure	How the API represents an error in its response body, distinct from the HTTP status code.	Not modeled
Empty-result handling	What the collector does when a poll legitimately returns zero records.	Not modeled

Reliability & Error Handling

Field	Captures	Taxonomy reference
Retry policy	Which HTTP statuses and error classes are retried, and how many times.	TAX-03.04.05 Retry / Backoff Configuration
Idempotency	Whether repeating a call after a failure is safe -- important for any request with side effects.	Not modeled
Timeout handling	What happens when a request times out rather than returning an error status.	TAX-03.04.05 Retry / Backoff Configuration
Partial failure handling	Behaviour when some pages of a multi-page pull succeed and others fail.	Not modeled
Dead-letter / failed-request handling	Where a request that exhausts its retries ends up, and how it is surfaced for follow-up.	TAX-03.04.05 Retry / Backoff Configuration
TLS / certificate validation	Whether the collector validates the endpoint's certificate, and against which trust store.	TAX-03.05.07 Certificate Authentication

Data Identity & Duplicate Handling

How the collector avoids re-ingesting or skipping records across polls, in place of the file-based CRC/Fishbucket mechanism.

Field	Captures	Taxonomy reference
Unique event identifier field	The response field, if any, that uniquely identifies a record for de-duplication.	Not modeled
De-duplication key	The field or combination of fields used to detect a record already ingested.	Not modeled
Ordering guarantee	Whether the API guarantees records are returned in a stable order (typically required for cursor-based checkpointing to be safe).	Not modeled
Delivery semantics	At-least-once (possible duplicates) versus exactly-once, and which the collector is actually designed for.	Not modeled
Replay / resume behaviour	What happens when the collector is restarted -- resumes from the last checkpoint, or re-pulls a safety window.	TAX-03.04.04 Batch / Checkpoint State

Metadata, Security & Assurance

Splunk Metadata & Routing

Field	Captures	Taxonomy reference
Index	The target index for this input's events.	TAX-03.01.03 Index Destination
Sourcetype	The sourcetype assigned to this input's events.	TAX-04.11.01 Sourcetype
Source	The recorded `source` value, typically the endpoint path or modular input name.	TAX-03.01.02 Data Source–Input Mapping
Host	The host value assigned -- from the collector, or overridden per input.	TAX-01.01.03 System Name
Application	The application or system this API belongs to.	TAX-01.01.05 System Application Type
Environment	Production, test, staging, etc.	TAX-01.03.01 Environment
Routing / filtering requirements	Any rule that routes or drops events from this input before or during indexing.	TAX-03.02.03.03 Destination Rule; TAX-03.02.03.04 Drop / Keep Routing Rule

Security & Data Handling

Field	Captures	Taxonomy reference
Data classification	The sensitivity classification of this data source's content.	TAX-02.02.06 Data Classification
Sensitive information / PII	Whether the API response is known or expected to carry sensitive personal data.	TAX-02.02.06 Data Classification
Credentials / secrets	Whether the response can itself contain credentials or secrets that require special handling.	TAX-04.13.08 Field Masking / Redaction Rule
Masking requirements	Fields or patterns that must be masked or redacted before storage.	TAX-04.13.02 Masking Rule; TAX-04.13.08 Field Masking / Redaction Rule
Filtering requirements	Records that must be filtered out before or during ingestion for compliance or noise-reduction reasons.	TAX-04.13.06 Event Filtering Rule
Access restrictions	Who is permitted to search this data once indexed.	TAX-02.08 Access Control
Retention requirements	The approved retention period for this source's data.	TAX-02.06.05 Retention Policy

Assurance

Field	Captures	Taxonomy reference
Endpoint reachable / authentication successful	Pre-collection connectivity and credential checks.	TAX-03.05.14 Authentication Failure Handling
Expected schema validated	Confirmation the response shape matches what parsing expects, so a silent vendor API change is caught.	TAX-04.10.04 Parsing, Line Breaking & Timestamp Check — generic
Events collected / forwarded / indexed	Confirmation of successful end-to-end delivery.	TAX-04.10.04 Parsing, Line Breaking & Timestamp Check
No duplicate ingestion / no missing events	Ongoing data-quality checks against the expected checkpoint behaviour.	TAX-04.10.03 Volume, Gap & Duplicate Check
Collection lag	The delay between a record existing at the source and it being searchable in Splunk.	TAX-04.10.02 Presence & Timeliness Check
Expected event count / expected volume	Confirmation collected volume matches the profiled expectation.	TAX-04.10.02 Presence & Timeliness Check; TAX-04.08 Event Volume Profile
Rate-limit incidents / token-expiry incidents	Operational failures specific to the API-polling model, tracked separately from generic collection failures.	TAX-03.05.14 Authentication Failure Handling — generic

Taxonomy coverage

Checked against both taxonomies in this app, the same way as the File Monitoring Profile. Onboard Taxonomy (TAX-XX) has no dedicated REST-API-collection branch equivalent to TAX-03.06 -- authentication is comprehensively covered by TAX-03.05 Data Collection Authentication, and scheduling/checkpointing/retry by TAX-03.04, but pagination, rate limiting and API-response-specific identity/duplicate handling have no dedicated fields. Splunk Taxonomy (SOT-XX) represents a REST-polling input as Modular Input (SOT-05.01.06); its current relatedTax (TAX-03.06.03.01, TAX-03.04.04) points at the file-monitoring collection-mode and checkpoint-state codes and is not yet cross-linked to the TAX-03.05 authentication branch, despite OAuth/API-key authentication being how most REST modular inputs actually authenticate.

Profile branch	Onboard Taxonomy	Splunk Taxonomy	Coverage
Endpoint Identification	TAX-03.04.01 Input Stanza; TAX-03.04.02 Input Parameters	Modular Input (SOT-05.01.06)	Partial -- endpoint is a named example parameter; base URL, resource path, API version and environment are not individually named fields.
Authentication & Authorization	TAX-03.05 + 9 children (Authentication Method, Credential Type, API Key/Token, OAuth/Client Credentials, Certificate Authentication, Managed Identity, IAM Role, Secret Storage Location, Credential Rotation, Permission Scope, Least Privilege Validation, Authentication Failure Handling)	Modular Input	Direct -- extensively and specifically covered.
Request Construction	TAX-03.04.01/.02	Modular Input	Partial -- generic input-parameter fields only; HTTP method, headers, body template and concurrency are not individually named.
Pagination & Result Set Handling	—	—	Not modeled -- no taxonomy field for pagination mechanism, page size or multi-page aggregation.
Polling, Scheduling & Checkpointing	TAX-03.04.03 Polling Interval; TAX-03.04.04 Batch/Checkpoint State	Modular Input (`relatedTax` includes TAX-03.04.04)	Direct for interval and checkpoint state; backfill and overlap-window behaviour are generic.
Rate Limiting & Throttling	TAX-03.04.05 Retry/Backoff Configuration	—	Partial -- backoff strategy is covered; rate-limit type, signal and vendor quota tier are not individually named.
Response Handling & Parsing	TAX-04.05 Log Format Detection & Parsing; TAX-04.06 Field Extraction	Source Type (SOT-02.01.01)	Direct at the format/extraction level; envelope structure and array-splitting are generic, not individually named.
Reliability & Error Handling	TAX-03.04.05 Retry/Backoff Configuration; TAX-03.05.07 Certificate Authentication; TAX-03.05.14 Authentication Failure Handling	Modular Input	Direct.
Data Identity & Duplicate Handling	TAX-03.04.04 Batch/Checkpoint State	Modular Input	Partial -- resume/replay is covered via checkpoint state; unique-identifier field, ordering guarantee and delivery semantics have no dedicated field (unlike File Monitoring's own CRC & Fishbucket Identity Tracking node).
Splunk Metadata & Routing	TAX-03.01.02/.03; TAX-04.11.01; TAX-03.02.03.03/.04; TAX-01.01.03/.05, TAX-01.03.01 (host/app/environment)	Index (SOT-06.01.01); Source Type	Direct -- same as File Monitoring Profile.
Security & Data Handling	TAX-02.02.06 Data Classification; TAX-04.13.02/.08 Masking/Redaction; TAX-02.06.05 Retention Policy; TAX-02.08 Access Control; TAX-03.05.07 Certificate Authentication	—	Direct.
Assurance	TAX-04.10.02–.04 Health Checks; TAX-06.03.02 Data Source Assurance Roll-up; TAX-03.05.14 Authentication Failure Handling	—	Direct.

Net finding: seven of the twelve branches are directly represented today, weighted heavily by how thorough TAX-03.05 Data Collection Authentication already is. The remaining five -- Endpoint Identification, Request Construction, Pagination & Result Set Handling, Rate Limiting & Throttling, and Data Identity & Duplicate Handling -- are covered only generically or not at all. This is a materially thinner picture than the File Monitoring Profile's 9-of-12, because file monitoring has its own dedicated TAX-03.06 branch and REST API collection has no equivalent. Pagination and rate limiting in particular have zero taxonomy representation today. If REST-API-sourced data becomes a significant share of onboarded sources, a parallel TAX-03.07 "REST API Collection Mechanics" branch -- mirroring TAX-03.06's structure -- would close that gap; this profile is scoped to document the mechanics and the coverage finding, not to add that branch unprompted.

Design notes

Endpoint/request/pagination mechanics are assessed separately from authentication, mirroring the File Monitoring Profile's split of file identification from file lifecycle -- a vendor can change its pagination scheme without touching how the collector authenticates, and vice versa.
Rate limiting is documented as its own branch rather than folded into generic retry/backoff, because a 429 response is an expected, routine condition for a well-behaved poller to handle -- not a failure in the same sense as a 500 or a timeout.
Data Identity & Duplicate Handling is the REST-API analogue of File Monitoring's CRC & Fishbucket Identity Tracking branch: both exist because avoiding duplicate or lost events under a resumed/restarted collector is a first-class concern, not an edge case, whichever transport is in use.

← Back to References

References / Splunk sourcetype definition

Field Normalisation

Field Normalisation (TAX-04.07) maps a sourcetype's extracted fields onto standard names, data types and common data models such as CIM or ECS. This is what makes "search for authentication events" work identically across dozens of differently-formatted sourcetypes instead of requiring a separate query per vendor field name.

Definition

Field Normalisation documents how a sourcetype's already-extracted fields (see Field Extraction) are mapped onto standard field names, target data types and, where applicable, a Splunk Common Information Model (CIM) data model or the Elastic Common Schema (ECS). Extraction determines whether a field exists; normalisation determines whether it's called the same thing, and means the same thing, as the equivalent field on every other sourcetype.

CIM data models

The CIM Add-on (Splunk_SA_CIM) ships a fixed catalogue of data models, each defining the least-common-denominator field names and tags for a domain of interest. The list below reflects the models commonly shipped; Splunk has renamed and added models over versions (for example, Inventory was formerly labelled Compute Inventory), so confirm the exact set and field lists against the installed Splunk_SA_CIM version rather than treating this as a frozen list.

Data model	Typical use
Alerts	Events generated by a detection or monitoring tool signalling that a rule or threshold was triggered.
Application State	The current or periodic state of an application's internal components.
Authentication	Login, logout and authentication attempt events (success/failure).
Certificates	Certificate issuance, expiry, validation and revocation events.
Change	Administrative changes to configurations, policies or auditing services (start, stop, reconfigure, disable).
Data Loss Prevention	Events from DLP tools describing sensitive-data detection and policy actions.
Databases	Database server instance, session and query-performance events.
Email	Mail delivery, filtering and message-tracking events.
Endpoint	Endpoint client processes, services, files, ports and registry activity.
Interprocess Messaging	Message broker/queue produce and consume events.
Intrusion Detection	IDS/IPS signature and detection events.
Inventory	Infrastructure and network device inventory and topology snapshots (formerly labelled Compute Inventory).
Java Virtual Machines	JVM performance and garbage-collection metrics.
Malware	Anti-malware detection, quarantine and remediation events.
Network Resolution (DNS)	DNS query and response events.
Network Sessions	Session-oriented network connection events (VPN, firewall sessions).
Network Traffic	Individual network connection/flow events (allow/deny).
Performance	Host and application resource-utilisation metrics (CPU, memory, disk).
Ticket Management	Helpdesk/ITSM ticket creation, update and resolution events.
Updates	Patch and software update installation status events.
Vulnerabilities	Vulnerability scan results and finding events.
Web	HTTP/web proxy access and error log events.

Normalisation mechanisms

Mechanism	Config	Definition
Field aliasing	`FIELDALIAS-<class> = <field> AS <alias> ...`	Maps a vendor-specific field name to the CIM standard name (for example `username AS user`) at search time, after field extraction and before calculated fields. One alias can map to only one source field.
Calculated fields	`EVAL-<fieldname> = <eval expression>`	Derives a new field from an eval expression (for example `action=if(status="0","success","failure")`). Runs after field aliasing, so it can reference an already-aliased field.
Automatic lookups	`LOOKUP-<class> = <transform> <match_field> OUTPUT <output_field>`	Enriches events at search time from a CSV or KV-store lookup table defined in `transforms.conf`, without needing an explicit `\| lookup` command in every search.
Tags	`tags.conf`	Marks events matching a field/value pair as belonging to a CIM dataset (for example `authentication = enabled`). See the Field Extraction reference's "Tags" note for the stanza syntax.

CIM compliance workflow

Confirm the sourcetype already has a stable definition (Field Extraction, Line Break, Datetime Parse).
Extract the raw fields (see Field Extraction's extraction methods).
Create field aliases mapping vendor-specific field names to the target data model's standard names.
Create calculated fields for values that need transformation, such as vendor status codes mapped to CIM's success/failure vocabulary.
Create tags so the sourcetype's events are recognised as belonging to the target CIM dataset.
Validate field coverage and tags against the target data model's reference table, using the datamodel command or the CIM Add-on's own validation tooling, against representative events rather than a single sample.

A Splunk-certified Technology Add-on for the vendor/product usually ships this mapping already done -- check Splunkbase before building it by hand.

Example

[example:auth_source]
FIELDALIAS-cim = username AS user src_ip AS src dest_ip AS dest
EVAL-action = if(status="0", "success", "failure")
LOOKUP-severity = severity_lookup status_code OUTPUT severity

This maps username/src_ip/dest_ip onto the Authentication data model's user/src/dest fields, derives action from the vendor's raw status code, and enriches each event with a severity value from a lookup table keyed on status_code.

Validation

Confirm the target data model recorded on CIM Mapping (TAX-04.07.04) matches what the sourcetype's tags actually declare -- a missing or wrong tag means the data silently doesn't appear in CIM-based searches and dashboards, even with perfectly extracted fields.
Remember the processing order: extraction, then field aliasing, then calculated fields, then lookups -- an EVAL-* statement can reference an aliased field, but a FIELDALIAS cannot reference a calculated field.
Don't apply the same alias target field name from two different original fields within one stanza; each alias maps to exactly one source field.
Prefer a Splunk-certified Technology Add-on's built-in CIM mapping over hand-rolled FIELDALIAS/EVAL/LOOKUP stanzas where one already exists.
Record CIM Mapping (TAX-04.07.04) and ECS Mapping (TAX-04.07.05) separately -- they are not the same schema and rarely require identical field names.
Validate Standard Field Names (TAX-04.07.01) and Data Types (TAX-04.07.02) conformance with the datamodel command against representative events, not just one sample record.

← Back to References

References / Detailed reference

Timestamp Quality

Timestamp Quality measures whether event time can be parsed, trusted, ordered and correlated consistently. It separates the source event timestamp from receipt or ingestion time and scores six equally weighted criteria from 0 to 4.

Definition and calculation

Assess the timestamp carried by the source event. Do not substitute Splunk _indextime, collector receipt time or a file modification time unless the source does not provide event time and the limitation is explicitly recorded.

Timestamp Quality (%) = (total criterion points / 24) × 100Six criteria × a maximum of 4 points = 24 points.

Six scoring criteria

1Presence and completeness

Is event time present on every applicable event, with all required components such as year, month, day, hour, minute and second?

timestampevent_timeTimeGenerated_time

Penalise missing timestamps, partial dates, inherited header timestamps and timestamps present only on some event types.

2Format and parseability

Is the format recognised, unambiguous and consistently parseable without brittle assumptions?

Prefer ISO 8601 or IETF RFC 3339. Penalise locale-dependent dates, mixed ordering, ambiguous epoch units and undocumented proprietary formats.

3Timezone clarity

Does the timestamp include Z, an explicit UTC offset or a reliably documented source timezone?

Do not infer timezone solely from the analyst location or Splunk search-head timezone.

4Precision and resolution

Is precision appropriate for the event rate and investigation requirement?

Milliseconds or finer may be required for high-volume authentication, process or transaction logs; second precision can be sufficient for low-rate administrative events.

5Correctness and event-time reliability

Does the value plausibly represent when the activity occurred rather than when it was batched, received or processed?

Check future timestamps, excessive past drift, impossible dates, clock rollback and conflict between multiple time fields.

6Consistency

Is one stable timestamp convention used across the representative dataset and across event types?

Penalise mixed timezones, mixed precision, mixed delimiters and format changes that require multiple parsing branches.

Criterion scoring matrix

Score	Meaning	Evidence expected
4	Exceptional	Complete, explicit, correctly parsed and consistent; no material ambiguity or drift.
3	Good	Operationally reliable with a minor limitation that does not normally impede investigation.
2	Fair	Usable with documented assumptions, enrichment or non-trivial parsing.
1	Poor	Frequently incomplete, ambiguous, inconsistent or unreliable.
0	Fail	Absent, invalid or unusable for dependable event ordering.

Worked examples

Example 1 — ISO 8601 with offset and milliseconds

2026-07-21T08:00:11.902+10:00 event_type=login_attempt result=success

Presence	4	Complete on the event.
Format	4	Unambiguous ISO 8601.
Timezone	4	Explicit +10:00 offset.
Precision	4	Millisecond precision.
Correctness	4	Represents event time and is plausible.
Consistency	4	Stable across the sample.

24 / 24 = 100% — Exceptional

Example 2 — Traditional syslog without year or timezone

Jul 21 08:00:11 host01 sshd[2211]: Failed password for jsmith

Presence	2	Month, day and time exist; year is absent.
Format	3	Recognised syslog format.
Timezone	1	Must be supplied by source configuration.
Precision	2	Second precision only.
Correctness	2	Year rollover and host clock require assurance.
Consistency	3	Stable within the sample.

13 / 24 = 54.2% — Poor

Example 3 — Mixed locale dates and epoch values

21/07/26 08:00:11 ...
07/21/2026 08:00:12 ...
1784592013000 ...

Representative score: 7 / 24 = 29.2% — Very Poor. Mixed locale order and undocumented epoch units create material parsing and ordering risk.

Splunk parsing guidance

Only propose settings supported by the sample. Record TIME_PREFIX when a stable prefix exists, TIME_FORMAT when the format is known, and MAX_TIMESTAMP_LOOKAHEAD as the number of characters Splunk must inspect from the prefix to the end of the timestamp. Validate against representative events and timezone behaviour before production use.

Interpretation bands

Percentage	Rating	Operational meaning
90–100%	Exceptional	Reliable for ordering, correlation and investigation.
80–89%	Excellent	Strong with only minor limitations.
70–79%	Good	Operationally usable; document known limitations.
60–69%	Fair	Usable with remediation or enrichment.
40–59%	Poor	Material investigation and parsing risk.
20–39%	Very Poor	Significant source or parsing remediation required.
0–19%	Fail	Not dependable as event time.

← Back to References

References / Detailed reference

Log Format Quality

Log Format Quality measures whether events can be separated, parsed and normalised reliably without losing meaning. The local calculator scores six criteria from 0 to 4 for a maximum of 24 points.

Definition and calculation

Assess the raw source format before relying on search-time extractions. Distinguish defects in the source data from defects introduced by transport, line breaking or Splunk configuration.

Log Format Quality (%) = (total criterion points / 24) × 100Six criteria × a maximum of 4 points = 24 points.

Six scoring criteria

1Structure and format identification

Can the format be identified confidently as valid JSON, XML, CSV, TSV, key-value, CEF, LEEF, syslog, fixed-width or another documented structure?

Do not award structured-format credit merely because braces, tags or delimiters appear.

2Event boundary reliability

Can every event be separated without accidental merging or splitting?

Assess newline behaviour, multiline stack traces, headers, continuations and stable start patterns.

3Delimiter, quoting and escaping integrity

Are delimiters, quotes, escape characters and embedded newlines handled consistently?

Penalise unescaped delimiters, broken quotes, invalid JSON escaping and values that silently shift columns.

4Schema and field stability

Are field names, order, optionality, nesting and data types stable across representative events and versions?

Record mixed schemas and event families rather than hiding them in an average.

5Encoding and content integrity

Are character encoding, Unicode, control characters, binary fragments and truncation handled without corrupting meaning?

Prefer UTF-8 and verify that special characters, paths, commands and user-provided text survive transport.

6Parsing and normalisation complexity

Can fields be extracted and normalised with native structured parsing or stable, maintainable rules?

Penalise extensive brittle regular expressions, positional assumptions and source-specific exceptions.

Criterion scoring matrix

Score	Meaning	Evidence expected
4	Exceptional	Valid, stable, lossless and straightforward to parse using supported mechanisms.
3	Good	Reliable with minor exceptions or manageable configuration.
2	Fair	Usable but requires non-trivial parsing, multiple branches or documented constraints.
1	Poor	Frequent inconsistency, malformed records, boundary failures or brittle extraction.
0	Fail	Cannot be separated or parsed reliably without loss or manual reconstruction.

Worked examples

Example 1 — Stable one-object-per-event JSON

{"time":"2026-07-21T08:00:11.902+10:00","event_type":"login","user":"ADAM.SMITH","result":"success"}

24 / 24 = 100% — Exceptional, provided validation confirms valid JSON, UTF-8 and stable types.

Example 2 — Consistent key-value with multiline continuation

2026-07-21 08:00:11 INFO User login successful.
    User=ADAM.SMITH
    ClientIP=10.50.12.81
    SessionID=1A2C9B41

Structure	3	Recognisable timestamp/message plus key-value continuation.
Boundaries	2	Requires a reliable timestamp-start rule.
Delimiters	3	Stable equals delimiter.
Schema	3	Fields vary by event type but remain clear.
Encoding	4	No evidence of corruption.
Complexity	2	Multiline extraction and event-type handling required.

17 / 24 = 70.8% — Good

Example 3 — Mixed free text, malformed CSV and concatenated events

Representative score: 5 / 24 = 20.8% — Very Poor. Repair source delimiters and event boundaries before relying on search-time regular expressions.

Splunk parsing guidance

Validate event breaking before field extraction. Determine whether SHOULD_LINEMERGE, LINE_BREAKER, structured parsing settings, character-set handling or source-side changes are required. Keep raw-event preservation and truncation checks in the acceptance test.

Interpretation bands

Percentage	Rating	Operational meaning
90–100%	Exceptional	Stable, efficient and low-risk parsing.
80–89%	Excellent	Strong format with minor manageable exceptions.
70–79%	Good	Operationally usable with documented parsing.
60–69%	Fair	Non-trivial parsing and assurance required.
40–59%	Poor	Material extraction and maintenance risk.
20–39%	Very Poor	Source-side or transport remediation strongly recommended.
0–19%	Fail	Not dependable for production ingestion.

← Back to References

References / Detailed reference

Log Assessment Framework

A reusable, source-agnostic procedure for assessing the structure, format consistency and data quality of a raw log file at both the physical-line and logical-event level. It derives the dominant convention from the data itself -- the majority baseline -- and measures every deviation from it, rather than checking against an external spec.

Core concepts

Physical line vs. logical event. A physical line is one newline-terminated string. A logical event (record) is one meaningful unit, which may span several physical lines -- a stack trace, a pretty-printed JSON object, a wrapped message. Every assessment must decide the mapping between the two, because a naive line-oriented parser treats each continuation line as its own record and manufactures malformed events.

Majority baseline. For each axis (delimiter, timestamp format, structure, etc.), find the value that dominates the file and treat it as the reference. Everything else is a non-conformer to be explained. This makes the assessment self-calibrating across sources without an external spec to check against.

Two counting units. Report conformance at both line level (of all physical lines) and event level (of all logical records). They diverge exactly when multi-line records exist, and that divergence is itself a signal about how much of the file is continuation content.

Assessment dimensions

The generalised feature set to extract per line and roll up per event. Not every dimension applies to every file -- pick the ones relevant to the source, and add domain-specific columns (severity, host, user, status code) as needed.

Dimension	What it captures	Non-conformance signal
Line number	Physical position in the file	Anchors every finding back to a source location
Record / Event ID	Which logical record the line belongs to	Multi-line records must map many lines to one event
Serialization format	Delimiter / structure family (CSV, TSV, JSON, logfmt, syslog)	Mixed formats in one stream break single-parser ingestion
Format conformance	Line matches the dominant format	Deviations need routing, transformation or rejection
Timestamp presence	Line carries a timestamp	Absence usually means a continuation line
Timestamp format	The date/time pattern used	Divergent patterns misparse or fail downstream
Timestamp conformance	Matches the dominant timestamp pattern	Mixed ordering, precision or separators cause silent misparse
Timestamp offset (distance)	Characters before the timestamp	Nonzero/variable offset means a prefix exists; fixed-slice extraction breaks
Timestamp width	Length of the timestamp token	Equal width across different formats can mask a defect
Field count	Number of delimited fields	Under/over-count flags truncated or corrupt records
Line length	Character count of the line, excluding the trailing newline	Extreme outliers flag truncation, binary junk or injected data
Line size (bytes)	UTF-8 byte length of the line, plus 1 for the on-disk LF newline or 2 for CRLF	Byte weight ≠ record count -- drives storage, retention and keep/discard sizing; equals character count only for pure ASCII
First character & class	Leading character and its category (digit, alpha, whitespace, symbol)	Cheap record-boundary heuristic
First-char class conformance	Whether the leading-char class matches the dominant class	Divergent leading class flags a record-start anomaly or a continuation line
Structure	Single- vs multi-line event, from record grouping	Determines whether line-oriented parsing is safe
Line ending	Newline convention (LF / CRLF / mixed)	A stray `\r` corrupts the last field of every record
Encoding	Byte encoding / BOM	A UTF-8 BOM or non-UTF-8 bytes break naive readers

Procedure

Ingest raw. Read bytes, not decoded text, first -- capture encoding, BOM and line endings before anything normalises them away.
Split into physical lines and number them.
Detect the dominant format by tallying delimiters/structure across lines; this is the majority baseline for the format axis.
Establish a record-start rule (e.g. "a new record begins only on a line with a leading timestamp / leading digit / {") and fold continuation lines into their parent event. Assign event IDs. Continuation status must be earned, not defaulted: only leading whitespace/tab, or an established open-block context (an unclosed JSON array, an in-progress stack trace), counts as evidence of continuation. A line with no leading whitespace that matches none of the known record-start patterns is not automatically a continuation of whatever preceded it -- default it to starting a new record and let it fail conformance as its own event (or bucket as FREE_TEXT once fingerprinted). Silently folding it into the prior record is the more common error: it under-counts events and corrupts that prior record's byte/structure totals.
Extract per-line features from the dimension table for the axes that apply.
Compute the majority baseline for each axis independently.
Score conformance per line against each baseline (Yes/No), then roll up to events.
Aggregate percentages at both line and event level; compute an overall "conforms on all axes" rate.
Flag and explain outliers -- every non-conformer should have an attributed reason (wrong delimiter, day-first date, continuation line, truncated field, etc.).

Conformance scoring

% conforming = conforming units ÷ total unitsComputed at line level (÷ total physical lines) and event level (÷ total logical events).

Also compute the all-axes rate: the fraction of records that pass every applicable check. This is the single most useful "clean data" number, because a high per-axis rate can still hide a low all-axes rate when defects are spread thinly across many records for different reasons.

Report each partition three ways. For every axis, split records into the conforming set (matches the baseline) and the non-conforming set (the remainder), and report three metrics for each side: percentage, size in bytes, and event count. Percentage and event count measure how many records deviate; byte size measures how much of the file's weight they represent. These deliberately diverge whenever records differ in size -- a dominant format is often a larger share of the bytes than of the events, because its records are individually longer. Byte size is therefore the metric that storage, retention and keep-vs-discard decisions actually need; a count-based percentage alone will mis-size them. The percentage itself can be computed two ways -- by event count and by bytes -- and reporting both makes the size skew explicit.

Interpretation guide. One axis at 100% while others are lower means that convention is stable but says nothing about correctness (e.g. uniform line endings on a file full of malformed records). Several axes partitioning the file identically means they are likely detecting the same underlying split (e.g. "has timestamp", "starts with a digit" and "is a record start" all flagging the same continuation lines) -- treat that as one finding, not several. High per-axis rates with a low all-axes rate means many small, distinct defects rather than one systemic one -- triage record-by-record.

Structural fingerprinting

A compact way to measure how many structurally distinct record types a file contains: hash a tuple of the independent, varying properties and count the distinct results.

fingerprint = md5(format | timestamp_format)[:8]Use the two axes that carry independent signal -- serialization format and timestamp format. The number of distinct fingerprints equals the number of structurally distinct record types in the file.

Why only these two

Most other assessed properties are either constant or derived, so they add no distinctions and only inflate the theoretical space:

Constant properties (single-valued across the file -- encoding, line ending, field count or structure when uniform) contribute nothing to a fingerprint.
Derived properties restate one of the two: first-character class is a function of format; timezone is a function of timestamp format. Including them leaves the distinct count unchanged.
Positional properties (timestamp offset) are noisy -- in container formats like CEF the offset drifts with unrelated content (variable-length header fields), fragmenting the fingerprint without adding meaning. Exclude them.

Interpreting the count

Compare distinct fingerprints against the theoretical maximum (the product of the two cardinalities). Sparse usage (e.g. 17 of a possible 64) means the timestamp formats are largely disjoint per serialization -- each format brings its own timestamp conventions.
1 distinct fingerprint = structurally monolithic (a single-source, single-format feed).

Fold first (critical). Compute the fingerprint per logical event, on the record-start line, after boundary detection -- never per physical line. A multi-line record's continuation lines carry no format or timestamp signal and would each mint a junk signature (typically OTHER | none), inflating the count with noise. In a correctly folded multi-line file, structure never enters the fingerprint at all -- it is an attribute of the event, not a component of the hash.

When the base tuple is degenerate

For single-source structured logs (one XML schema, one timestamp format), both properties are constant and the fingerprint collapses to a single value. Extend the tuple with the one property that actually varies -- a type/ID field such as an EventID, or a hash of the record's field-name schema -- to regain separation:

fingerprint = md5(format | timestamp_format | type_key)[:8]

Which property is needed to make the fingerprint discriminating is itself diagnostic: a file separated by format | timestamp_format is a heterogeneous multi-source stream, while one that only separates once you add a semantic ID is a uniform single-source feed whose diversity lives in content, not structure.

When the format has no name

format in the fingerprint is a label you assign, not something intrinsic -- an unnamed format is not a blocker, it just means falling back from a name to a derived structural signature. Split "unnamed" into two cases:

Structured but unnamed (a proprietary or ad-hoc format that still has real structure -- delimiters, key=value, fixed columns). Do not dump it in OTHER; that collapses genuinely different structures into one signature and understates diversity. Derive a shape token to stand in for the name, two good options:
- Delimiter + arity -- dominant separator and field count, e.g. pipe/8. This is literally what a name like "CSV" is -- shorthand for "comma-delimited, N fields." Every CSV in an assessment could be written comma/7 with nothing lost.
- Masked token skeleton -- replace digit runs with 9, letter runs with A, keep punctuation: 2026-07-31T04:03Z → 9999-99-99T99:99A, then hash it. Structurally identical lines collapse to one signature while different shapes stay distinct, regardless of the actual values. This is the log-template / Drain approach, and it means a pre-existing name is never actually required -- you can fingerprint purely on derived shape.
The fingerprint generalises to md5(shape_hash | timestamp_format), where shape_hash is the family name when one matches and the derived skeleton otherwise.
Genuinely unstructured (a free-text message, a banner, a wrapped line). There is no stable structure to name or fingerprint -- bucket it as FREE_TEXT. Note the overlap with the fold-first rule: continuation lines of multi-line records land here, but they should have been folded into their parent before fingerprinting, so in a correctly processed file they never reach this bucket.

The meta-point: a format name is just a cached alias for a recurring structural profile. If a shape recurs often enough to matter, its derived signature earns it a de-facto name; if it is a true one-off or shapeless, OTHER / FREE_TEXT is the honest label. Names are optional human-friendly aliases over the real key, which is structure.

Naming the derived shape

A shape_hash like ab2b2fe9 is stable but unreadable. Give each derived shape a deterministic codename -- a human-friendly encoding of the hash, never an RNG draw:

codename = "FMT-" + adjective[hash_byte0] + "-" + noun[hash_byte1] + "-" + hash[:4]comma/19 → FMT-ember-shrike-0594 (always the same)

Prefix FMT- namespaces it so a codename is never mistaken for a real format name.
Adjective + noun, indexed into two curated word lists by the first two hash bytes, make it memorable (the Docker / Heroku container-name pattern).
-hash4 suffix (first 4 hex of the shape hash) is the collision safety net and ties the name back to the underlying signature.

The essential property is that codename() is a pure function of the shape: the same structure yields the same name across every run, file and machine. A random name would rename the same format on re-run, make two files disagree, and carry no information -- strictly worse than the raw hash. Compact alternatives on the same deterministic principle: proquint (pronounceable five-letter tokens from the hash bits, e.g. FMT-bikih), NATO-phonetic + number (FMT-BRAVO-7, unambiguous over voice), or a BIP-39 wordlist mapping. In every case the codename adds readability, never entropy.

Common pitfalls checklist

These are the traps that make a log look consistent while silently misparsing. Check each explicitly.

Delimiter collision. A delimiter character appearing inside a field (a comma before milliseconds like 43,512; a comma inside a quoted CSV value) inflates the apparent format match. Validate structure and field count, not just the presence of the character.
Fixed-width timestamp trap. Two different timestamp formats can share the same character width and both pass a length/offset check while parsing to different, or wrong, values. Always validate the pattern, not the width.
Mixed date ordering. DD-MM-YYYY vs MM-DD-YYYY vs YYYY-MM-DD are ambiguous whenever the day is ≤12 -- misparses occur with no error raised. Anchor on ISO 8601 or require an explicit declared format.
Prefix before the timestamp. Syslog priorities (<13>), log levels or leading hostnames push the timestamp off offset 0. Fixed-slice extraction breaks; use search-based extraction.
Multi-line records. Stack traces, pretty-printed JSON and wrapped messages produce continuation lines with no timestamp. Fold them into the parent event via the record-start rule, or a line-oriented parser will emit one bogus event per continuation line.
Ambiguous continuation default. The opposite error is just as common: a banner, separator or free-text line with no leading whitespace and no recognisable pattern gets silently folded into the *preceding* record instead of starting its own -- because "doesn't match a known record-start pattern" was treated as equivalent to "is a continuation." Only leading whitespace/tab or an open-block context is evidence of continuation; anything else defaults to a new record, even if unstructured.
Line endings. LF vs CRLF vs mixed. Normalise on ingest; an unhandled trailing \r silently corrupts the final field of every record.
Encoding. A UTF-8 BOM at the file start attaches invisible bytes to the first field; non-UTF-8 bytes crash or mojibake naive readers. Detect and normalise.
Timezone. Naive (no offset) vs offset-aware timestamps. Missing or inconsistent timezones make cross-source correlation and ordering unreliable.
Whitespace type. Tabs vs spaces in indentation change both the first-character class and the character count; do not assume one.

Assessment template

Extract values per line, then compute the majority per column and the conformance flags. Drop or add columns to fit the source.

Line #	Evt #	Format	Fmt Conf	TS Present	TS Format	TS Conf	TS Offset	TS Width	Field Count	Chars	Bytes	1st Char	Char Class	Cls Conf	Structure	Line Ending

Assessment summary block to fill after scoring

For each axis, report the conforming and non-conforming partitions, each with percentage, size in bytes and event count. Percentage may be given by event count and/or by bytes -- they differ when record sizes vary.

Axis	Baseline	Conf %	Conf events	Conf bytes	Non-conf %	Non-conf events	Non-conf bytes
Serialization format
Timestamp format
Structure (single-line)
First-char class
Line ending
All axes combined

Totals for reference: file = _ events / _ bytes. The conforming-bytes figure is what you retain if you keep only baseline-conforming records; non-conforming bytes is what you discard. Because these are byte totals rather than record counts, they translate directly into storage and retention numbers.

Relationship to other assessments

This framework is the procedural, line-by-line method for gathering the evidence that Timestamp Quality and Log Format Quality score by rubric. Its Timestamp Format/Offset/Conformance columns feed Timestamp Quality's "Format and parseability" and "Consistency" criteria; its Format/Structure/Line-Ending/Encoding columns feed Log Format Quality's structure, boundary, delimiter and encoding criteria. Both roll up into the Data Quality Score.

This framework also operationalises the onboarding Pre-ingest cyber-value gate (TAX-06.05.02) -- "minimum parse rate, timestamp & timezone, and schema stability" -- whose pass criteria are exactly the all-axes conformance rate and majority-baseline schema check produced by this procedure.

Structural conformance answers "is this record well-formed and consistent?" It is orthogonal to "how important is this event?" -- severity or risk scoring is a separate concern, layered on top for detection and triage rather than data-quality purposes, and is out of scope for this framework.

← Back to References

References / Detailed reference

Exploratory Data Analysis & Field Correlation Playbook

A reusable, source-agnostic, phase-based procedure for onboarding and investigating an undocumented Splunk source end to end -- from parse-time sanity checks through data quality, temporal, correlation and outlier analysis, entity discovery, field relationship and CIM readiness assessment, sensitive-data exposure, enrichment validation, and finally value-space blind correlation for when field names can't be trusted at all. Run the phases roughly in order; several explicitly build on an earlier phase's output.

Definition

Standard field investigation assumes you can trust field names -- search on user=, pivot on src_ip. That assumption breaks down with new or badly-onboarded sources: extractions are broken, names are cryptic (f1, cs23, data.attr.0), or two sources name the same entity completely differently. This playbook works phase by phase from parse-time sanity checks through profiling, data quality, temporal rhythm, entity correlation, outliers, entity discovery, field-relationship analysis, CIM readiness, sensitive-data exposure and enrichment validation, closing with a value-space Blind Correlation toolkit for when field names still can't be trusted after all of that. Later phases explicitly build on earlier ones -- expect to re-run an earlier phase after a parsing fix or a new field promotion.

Every search below uses generic placeholders that must be substituted for the source under review. <<FIELD>> is the one exception -- it is not a placeholder, it is Splunk's own foreach * iteration syntax and should be left exactly as written.

Placeholder	Substitute with
`<index>`	The Splunk index name being assessed.
`<sourcetype>`	The sourcetype being assessed.
`<sourcetype_a>` / `<sourcetype_b>`	The two sourcetypes being cross-correlated against each other.
`<known_value>`	A value you already know exists somewhere in the data -- a username, IP or hostname -- whose holder field you are trying to find.
`<value_prefix>`	A partial value used to filter `walklex` term output down to a manageable range.
`<field>`, `<field_a>` / `<field_b>`	A specific field on the source under review, once identified. Every other `<..._field>` placeholder below (`<user_field>`, `<host_field>`, `<ip_field>`, `<process_field>`, `<asset_field>`, `<hash_field>`, `<port_field>`, `<numeric_field>`, `<enum_field>`, `<action_field>`, `<status_field>`, `<src_ip_field>`/`<dest_ip_field>`, `<parent_process_field>`, `<sender_field>`/`<recipient_field>`, `<entity_field>`) follows the same convention -- substitute the actual field name that holds that entity type on the source, typically identified via the Entity Discovery phase.
`<asset_lookup>` / `<asset_key_field>`	An asset lookup table and its key field, as inventoried in the Enrichment & Context Validation phase.
`<identity_lookup>` / `<identity_key_field>`	An identity lookup table and its key field, as inventoried in the Enrichment & Context Validation phase.
`<<FIELD>>` (not a placeholder)	Splunk's own `foreach ` wildcard iteration syntax. `foreach ` binds every field on the event in turn; `'<<FIELD>>'` in single quotes reads that field's value, while `"<<FIELD>>"` in double quotes reads its name as a string. Leave it exactly as written.

Parse-time health & structure fingerprinting

Run this before everything else. If line breaking, timestamping or truncation is wrong, every downstream phase inherits corrupted data. These checks confirm the source is parsed correctly, or point at the specific props.conf setting to fix first. Much of this ground is already covered in depth by the Log Assessment Framework, Line Length and Timestamp Quality references below -- treat this phase as the fast, source-agnostic sanity pass, not a replacement for those.

Structure fingerprinting (punct)

The indexed punct field reduces each event to its punctuation skeleton -- a free structural fingerprint:

index=<index> sourcetype=<sourcetype>
| stats count by punct
| sort -count
| head 20

A clean single-format source concentrates into a handful of dominant punct patterns. Dozens of low-count patterns mean mixed event formats in one sourcetype, multiline bleed, or a feed that should be split into separate sourcetypes.

Event clustering

Group structurally similar events and keep one representative per cluster -- the fastest way to enumerate the "event types" in an unstructured source:

index=<index> sourcetype=<sourcetype>
| cluster showcount=true t=0.8
| table cluster_count _raw
| sort -cluster_count
| head 20

Lower t toward 0.1 for looser grouping on highly variable logs; raise it toward 1.0 for near-exact grouping.

Format detection

index=<index> sourcetype=<sourcetype>
| eval format=case(
    match(_raw,"^\s*\{.*\}\s*$"),"json",
    match(_raw,"^\s*<\w"),"xml",
    match(_raw,"\w+=\S+\s+\w+=\S+"),"key_value",
    match(_raw,"^[^,\s]+,[^,]+,[^,]+,"),"csv_like",
    1=1,"unstructured")
| stats count by format
| sort -count

If JSON is detected, test automatic extraction and inventory the resulting fields:

index=<index> sourcetype=<sourcetype>
| head 1000
| spath
| fieldsummary
| table field count distinct_count

If spath yields useful fields, set KV_MODE=json (or INDEXED_EXTRACTIONS=json) on the sourcetype so they extract automatically.

Timestamp lag, timezone and impossible timestamps

Lag between event time and index time:

index=<index> sourcetype=<sourcetype>
| eval lag_sec=_indextime-_time
| stats avg(lag_sec) as avg_lag median(lag_sec) as median_lag perc95(lag_sec) as p95_lag
        min(lag_sec) as min_lag max(lag_sec) as max_lag

Timezone misconfiguration -- look for a dominant bucket at exactly ±N whole hours:

index=<index> sourcetype=<sourcetype>
| eval lag_hr=round((_indextime-_time)/3600,0)
| stats count by lag_hr
| sort -count

Impossible timestamps -- run this over All time, since misdated events fall outside normal search windows:

index=<index> sourcetype=<sourcetype>
| where _time>now()+300 OR _time<relative_time(now(),"-2y")
| stats count earliest(_time) as earliest latest(_time) as latest
| eval earliest=strftime(earliest,"%F %T"), latest=strftime(latest,"%F %T")

A constant whole-hour offset almost always means TZ or TIME_FORMAT is wrong in props.conf -- fix it before baselining anything temporal in Temporal Analysis.

Truncation & line-breaking

Event size vs. the default 10,000-character TRUNCATE:

index=<index> sourcetype=<sourcetype>
| eval raw_len=len(_raw)
| stats count avg(raw_len) as avg_len perc95(raw_len) as p95_len max(raw_len) as max_len
        count(eval(raw_len>=9990)) as near_truncate_events

Merged events -- more than one timestamp inside a single event signals broken line breaking:

index=<index> sourcetype=<sourcetype>
| rex max_match=10 "(?<ts_hit>\d{4}-\d{2}-\d{2}[T ]\d{2}:\d{2}:\d{2})"
| eval ts_per_event=mvcount(ts_hit)
| where ts_per_event>1
| stats count by ts_per_event

Line-count distribution (multiline should be deliberate, not accidental):

index=<index> sourcetype=<sourcetype>
| stats count by linecount
| sort -count

Fixes live in props.conf: LINE_BREAKER, SHOULD_LINEMERGE, TIME_PREFIX, TIME_FORMAT, MAX_TIMESTAMP_LOOKAHEAD, TRUNCATE. Re-run Data Source Profiling and Data Quality Analysis after any parsing change -- earlier numbers are invalid.

Data source profiling

Establish the shape and scale of the source before looking at content.

Volume and ingestion trends

Total event volume over time, bucketed hourly. Use tstats for speed across large indexes:

| tstats count where index=<index> by _time span=1h
| timechart span=1h sum(count) as events

Per-sourcetype volume to see which sourcetypes dominate the index:

| tstats count where index=<index> by sourcetype _time span=1d
| timechart span=1d sum(count) by sourcetype

Average daily volume and license-relevant byte size (helps capacity planning -- see the Splunk Index Sizing Calculator):

| tstats count where index=<index> by _time span=1d
| stats avg(count) as avg_daily_events min(count) as min_day max(count) as max_day

index=<index>
| eval bytes=len(_raw)
| timechart span=1d sum(bytes) as ingest_bytes
| eval ingest_MB=round(ingest_bytes/1024/1024,2)

Event diversity

Inventory of sourcetypes, sources and hosts feeding the index, with first/last seen:

| metadata type=sourcetypes index=<index>
| eval firstTime=strftime(firstTime,"%F %T"), lastTime=strftime(lastTime,"%F %T"), recentTime=strftime(recentTime,"%F %T")
| table sourcetype totalCount firstTime lastTime recentTime
| sort -totalCount

| metadata type=hosts index=<index> | sort -totalCount
| metadata type=sources index=<index> | sort -totalCount

Cardinality snapshot -- how many distinct sourcetypes/sources/hosts in one view:

| tstats dc(sourcetype) as sourcetypes dc(source) as sources dc(host) as hosts count as events where index=<index>

Field discovery

The fastest way to see every field, its fill count, distinct count and sample values:

index=<index> sourcetype=<sourcetype>
| head 50000
| fieldsummary
| table field count distinct_count is_exact max min mean stdev numeric_count values
| sort -count

List just the field names extracted at search time:

index=<index> sourcetype=<sourcetype>
| head 10000
| fieldsummary
| fields field

Check whether the source is structured (key=value, JSON, CSV) by inspecting raw events directly:

index=<index> sourcetype=<sourcetype> | head 20 | table _raw

A high distinct_count relative to event count suggests an identifier or high-entropy field. A distinct_count of 1-10 suggests an enum/category (status, action, severity). numeric_count near count indicates a numeric field.

Data quality analysis

Decide whether fields are trustworthy enough to build detections on. The checks below cover the classic quality dimensions: completeness (fill and null rates), validity (values match their expected format), consistency (one canonical form per value), uniqueness (no duplicated events) and drift (quality holding steady over time) -- timeliness is covered by the lag checks in Parse-Time Health above. A composite scorecard closes the phase.

Critical field population

Define the fields a detection would depend on (e.g. user, src, dest, action) and measure how often they are populated:

index=<index> sourcetype=<sourcetype>
| stats count as total
    count(<user_field>) as user_pop
    count(<host_field>) as host_pop
    count(<ip_field>) as ip_pop
| eval user_fill=round(user_pop/total*100,2),
       host_fill=round(host_pop/total*100,2),
       ip_fill=round(ip_pop/total*100,2)
| table total user_fill host_fill ip_fill

Null analysis

Per-field null vs. populated breakdown for a single field (treats empty string and "null"/"-" as missing):

index=<index> sourcetype=<sourcetype>
| eval status=if(isnull(<field>) OR <field>="" OR <field> IN ("null","-","N/A","unknown"),"missing","populated")
| stats count by status
| eventstats sum(count) as total
| eval pct=round(count/total*100,2)

Rank all fields by missing rate (uses fieldsummary count against total event count):

index=<index> sourcetype=<sourcetype>
| head 50000
| eventstats count as total_events
| fieldsummary
| eval fill_rate=round(count/(mvindex(split(total_events,""),0)),2)
| eval null_rate=round((1-(count/50000))*100,2)
| table field count distinct_count null_rate
| sort -null_rate

Simpler and exact for one field: index=<index> | stats count(eval(isnull(<field>))) as nulls count as total | eval null_pct=round(nulls/total*100,2).

CIM alignment

Quick check of which CIM-standard field names already exist in the source. Adjust the field list to the data model you're targeting:

index=<index> sourcetype=<sourcetype>
| head 50000
| fieldsummary
| eval is_cim_field=if(field IN (
    "action","app","dest","dest_ip","dest_port","src","src_ip","src_port",
    "user","user_id","src_user","dvc","signature","severity","status",
    "bytes","bytes_in","bytes_out","duration","transport","protocol",
    "process","process_name","process_id","parent_process","file_name",
    "file_hash","url","http_method","http_user_agent","vendor_product"
  ),"yes","no")
| table field count distinct_count is_cim_field
| sort - is_cim_field count

Data type identification

Classify each field as numeric, IP, timestamp-like or string using fieldsummary plus pattern checks:

index=<index> sourcetype=<sourcetype>
| head 50000
| fieldsummary
| eval type=case(
    numeric_count=count AND count>0,"numeric",
    match(values,"\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}"),"ip_like",
    match(values,"^\d{10,13}$"),"epoch_like",
    distinct_count<=20,"categorical/enum",
    distinct_count=count,"identifier/high-cardinality",
    1=1,"string")
| table field type count distinct_count numeric_count

Field completeness assessment

Combine fill rate, cardinality and stability into a single review table you can hand off:

index=<index> sourcetype=<sourcetype>
| head 50000
| eventstats count as sample_size
| fieldsummary
| eval fill_pct=round(count/sample_size*100,1)
| eval assessment=case(
    fill_pct>=95,"reliable",
    fill_pct>=60,"partial - validate before use",
    1=1,"sparse - not detection-ready")
| table field fill_pct distinct_count assessment
| sort -fill_pct

Fields below ~60% fill are risky for primary detection logic. They can still enrich, but alerts should not silently miss events because the field is null.

Placeholder & junk value detection

A field can be 100% "populated" and still useless -- -, N/A, unknown and 0 all count as values. Quantify junk for one field:

index=<index> sourcetype=<sourcetype>
| eval quality=case(
    isnull(<field>) OR <field>="","missing",
    <field> IN ("-","--","N/A","n/a","NA","null","NULL","(null)","none","unknown","UNKNOWN","undefined","(empty)","TBD","test"),"placeholder",
    match(<field>,"^\s+$"),"whitespace_only",
    1=1,"real_value")
| stats count by quality
| eventstats sum(count) as total
| eval pct=round(count/total*100,2)

Scan every field for junk rates at once (reuses the Blind Correlation wide-to-long pattern):

index=<index> sourcetype=<sourcetype>
| head 5000
| foreach * [eval fv=mvappend(fv, "<<FIELD>>=" . mvjoin(mvdedup('<<FIELD>>'),"|"))]
| fields fv
| mvexpand fv
| rex field=fv "^(?<f>[^=]+)=(?<v>.+)$"
| eval is_junk=if(v IN ("-","N/A","null","NULL","none","unknown","undefined","0","(empty)"),1,0)
| stats count sum(is_junk) as junk by f
| eval junk_pct=round(junk/count*100,1)
| where junk_pct>0
| sort -junk_pct

Extend the sentinel list with vendor-specific placeholders found while sampling in Data Source Profiling. "Effective fill rate" = populated minus junk -- use that number, not raw fill, when judging detection readiness.

Format validity checks

Populated and non-junk can still be malformed. Validate entity fields against their expected shapes.

IP validity (special placeholders checked first):

index=<index> sourcetype=<sourcetype> <ip_field>=*
| eval ip_check=case(
    <ip_field> IN ("0.0.0.0","255.255.255.255"),"special_placeholder",
    cidrmatch("127.0.0.0/8",<ip_field>),"loopback",
    match(<ip_field>,"^(25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)(\.(25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)){3}$"),"valid_ipv4",
    match(<ip_field>,"^([0-9a-fA-F]{0,4}:){2,7}[0-9a-fA-F]{0,4}$"),"ipv6_like",
    1=1,"invalid_format")
| stats count by ip_check
| sort -count

Port validity:

index=<index> sourcetype=<sourcetype> <port_field>=*
| eval port_check=case(
    NOT match(<port_field>,"^\d+$"),"non_numeric",
    tonumber(<port_field>)>65535,"out_of_range",
    tonumber(<port_field>)=0,"zero",
    1=1,"valid")
| stats count by port_check

Hash validity (zero-filled placeholders first, since they also match the length regexes):

index=<index> sourcetype=<sourcetype> <hash_field>=*
| eval hash_check=case(
    match(<hash_field>,"^0+$"),"all_zeros_placeholder",
    match(<hash_field>,"(?i)^[a-f0-9]{32}$"),"md5",
    match(<hash_field>,"(?i)^[a-f0-9]{40}$"),"sha1",
    match(<hash_field>,"(?i)^[a-f0-9]{64}$"),"sha256",
    1=1,"malformed")
| stats count by hash_check

Pull samples from any invalid_format/malformed bucket with | where ip_check="invalid_format" | head 20 | table <ip_field> _raw -- malformed entity values usually trace back to a broken extraction, not the device.

Value consistency checks

Case-variant collisions -- values that differ only by case split your stats, baselines and lookup joins:

index=<index> sourcetype=<sourcetype>
| stats count by <field>
| eval canon=lower(<field>)
| stats dc(<field>) as variants values(<field>) as forms sum(count) as events by canon
| where variants>1
| sort -events

Whitespace and control characters:

index=<index> sourcetype=<sourcetype> <field>=*
| eval ws_issue=case(
    match(<field>,"^\s|\s$"),"leading_or_trailing_space",
    match(<field>,"\s{2,}"),"internal_double_space",
    match(<field>,"[\x00-\x1F]"),"control_characters",
    1=1,"clean")
| stats count by ws_issue

Encoding artifacts (URL-encoding, HTML entities, mojibake):

index=<index> sourcetype=<sourcetype> <field>=*
| eval enc_issue=case(
    match(<field>,"%[0-9A-Fa-f]{2}"),"url_encoded",
    match(<field>,"&(amp|lt|gt|quot|#\d+);"),"html_entities",
    match(<field>,"â€|Ã©|Ã¼"),"mojibake_suspect",
    1=1,"clean")
| stats count by enc_issue

Mixed representation inside one field (the classic: a host field holding shortnames, FQDNs and IPs):

index=<index> sourcetype=<sourcetype> <host_field>=*
| eval form=case(
    match(<host_field>,"^(\d{1,3}\.){3}\d{1,3}$"),"ip",
    match(<host_field>,"\."),"fqdn",
    1=1,"shortname")
| stats count dc(<host_field>) as distinct by form

Every issue found here becomes a normalization rule in Field Relationship Analysis (EVAL- with lower(), trim(), urldecode()). The mojibake patterns are heuristics -- review samples before acting.

Duplicate event detection

Double-forwarding, overlapping inputs and API backfill re-runs create exact duplicates that inflate every count downstream:

index=<index> sourcetype=<sourcetype>
| eval raw_hash=md5(_raw)
| stats count as copies by raw_hash
| stats sum(eval(copies-1)) as surplus_events sum(copies) as total_events count(eval(copies>1)) as duplicated_groups
| eval dup_rate_pct=round(surplus_events/total_events*100,2)

Locate where duplicates come from:

index=<index> sourcetype=<sourcetype>
| eval raw_hash=md5(_raw)
| stats count as copies dc(source) as sources dc(host) as hosts by raw_hash
| where copies>1
| sort -copies
| head 20

sources>1 for the same hash means two inputs are reading the same data (overlapping monitor stanzas, UF + HF double pipeline). Same-source duplicates point at the feed re-sending.

Cross-field logical consistency

Fields can be individually valid yet contradict each other. Adapt the rules to the source:

index=<index> sourcetype=<sourcetype>
| eval issue=case(
    isnotnull(src) AND src==dest,"src_equals_dest",
    isnotnull(duration) AND tonumber(duration)<0,"negative_duration",
    isnotnull(bytes) AND tonumber(bytes)<0,"negative_bytes",
    isnotnull(bytes_in) AND isnotnull(bytes_out) AND isnotnull(bytes)
        AND abs((tonumber(bytes_in)+tonumber(bytes_out))-tonumber(bytes))>0,"bytes_sum_mismatch",
    1=1,null())
| where isnotnull(issue)
| stats count by issue

Contradiction matrix between an action field and a status field -- scan for impossible pairs (e.g. action=allowed with status=failure):

index=<index> sourcetype=<sourcetype>
| stats count by <action_field> <status_field>
| sort -count

Some "violations" are legitimate vendor semantics (e.g. bytes excluding headers). Confirm with samples before declaring the data wrong -- but document the semantics either way.

Multivalue field anomalies

A field that is unexpectedly multivalued usually means two extractions write to the same name, or the raw event repeats a key:

index=<index> sourcetype=<sourcetype> <field>=*
| eval mv_n=mvcount(<field>)
| stats count by mv_n
| sort -mv_n

index=<index> sourcetype=<sourcetype>
| where mvcount(<field>)>1
| head 20
| table <field> _raw

Numeric sanity checks

For each numeric field, confirm type purity and plausible range:

index=<index> sourcetype=<sourcetype> <numeric_field>=*
| eval n=tonumber(<numeric_field>)
| stats count count(eval(isnull(n))) as non_numeric count(eval(n<0)) as negative
        min(n) as min max(n) as max avg(n) as avg median(n) as median perc99(n) as p99

non_numeric>0 means mixed types in a "numeric" field. A max orders of magnitude above p99 is either a true outlier (interesting) or a parsing artifact like concatenated digits (a bug) -- sample it before deciding which.

Quality drift over time

Quality at onboarding is a snapshot; sources degrade silently. Fill-rate trend for a critical field:

index=<index> sourcetype=<sourcetype>
| timechart span=1d count as total count(<field>) as populated
| eval fill_pct=round(populated/total*100,1)

Fields that appeared or disappeared vs. a baseline window:

index=<index> sourcetype=<sourcetype> earliest=-7d latest=now
| head 5000 | fieldsummary | eval window="current" | fields field window
| append
    [search index=<index> sourcetype=<sourcetype> earliest=-37d latest=-30d
     | head 5000 | fieldsummary | eval window="baseline" | fields field window]
| stats values(window) as windows by field
| eval status=case(mvcount(windows)=2,"stable", windows="current","new_field", windows="baseline","disappeared")
| where status!="stable"

New values appearing in a low-cardinality (enum) field:

index=<index> sourcetype=<sourcetype> earliest=-24h
| stats count by <enum_field>
| search NOT
    [search index=<index> sourcetype=<sourcetype> earliest=-30d latest=-24h
     | stats count by <enum_field> | fields <enum_field>]

Schedule the fill-rate and field-drift searches as weekly health alerts per onboarded source -- quality regressions are far cheaper to catch than to backfill. Subsearches cap around 10k results: fine for enum fields, not for identifiers.

Data quality scorecard

One composite number per source, mirroring the CIM Assessment coverage score below -- completeness, validity, uniqueness and timeliness, weighted:

index=<index> sourcetype=<sourcetype>
| eval raw_hash=md5(_raw),
       lag=_indextime-_time,
       junk=if(<user_field> IN ("-","N/A","unknown","null") OR <host_field> IN ("-","N/A","unknown","null"),1,0)
| stats count as total
        count(<user_field>) as user_pop count(<host_field>) as host_pop count(<ip_field>) as ip_pop
        sum(junk) as junk_events
        dc(raw_hash) as unique_events
        perc95(lag) as p95_lag
| eval completeness=round((user_pop+host_pop+ip_pop)/(total*3)*100,1),
       validity=round((1-junk_events/total)*100,1),
       uniqueness=round(unique_events/total*100,1),
       timeliness=case(p95_lag<300,100, p95_lag<3600,75, 1=1,50),
       dq_score=round((completeness*0.4)+(validity*0.2)+(uniqueness*0.2)+(timeliness*0.2),1)
| table dq_score completeness validity uniqueness timeliness total p95_lag

Tune the field list, junk sentinels and weights to the source. Track the score per sourcetype over time -- it is the single number that tells you whether a feed is still detection-grade. It's the same composite-score idea as the taxonomy's own Data Quality Score reference, which scores by rubric rather than raw SPL.

Temporal analysis

Understand the rhythm of the source so you can baseline normal and spot gaps.

Hourly & day-of-week activity

Event distribution by hour of day (aggregated across the window):

index=<index> sourcetype=<sourcetype>
| eval hour=strftime(_time,"%H")
| stats count by hour
| sort hour

Day-of-week activity:

index=<index> sourcetype=<sourcetype>
| eval dow_num=strftime(_time,"%w"), day=strftime(_time,"%A")
| stats count by dow_num day
| sort dow_num

Combined hour × day heatmap (great for spotting business-hours patterns):

index=<index> sourcetype=<sourcetype>
| eval hour=strftime(_time,"%H"), day=strftime(_time,"%A")
| chart count over hour by day

Event frequency analysis

Events-per-minute distribution to learn the source's natural rate:

index=<index> sourcetype=<sourcetype>
| timechart span=1m count
| stats avg(count) as avg_per_min median(count) as median_per_min
        max(count) as peak_per_min stdev(count) as stdev_per_min

Inter-arrival spacing between consecutive events:

index=<index> sourcetype=<sourcetype>
| sort 0 _time
| streamstats current=f window=1 last(_time) as prev_time
| eval gap_seconds=_time-prev_time
| stats avg(gap_seconds) as avg_gap median(gap_seconds) as median_gap max(gap_seconds) as max_gap

Ingestion gap detection

timechart fills empty buckets, so zero-count buckets reveal collection outages:

index=<index> sourcetype=<sourcetype>
| timechart span=1h count
| where count=0

For sub-hour sources, detect any gap larger than an expected threshold (here 30 min):

| tstats count where index=<index> sourcetype=<sourcetype> by _time span=5m
| streamstats current=f window=1 last(_time) as prev_time
| eval gap_min=round((_time-prev_time)/60,1)
| where gap_min>30
| eval gap_start=strftime(prev_time,"%F %T"), gap_end=strftime(_time,"%F %T")
| table gap_start gap_end gap_min

Also compare event _time to index time with | eval lag=_indextime-_time to catch sources that are arriving but heavily delayed rather than missing.

Seasonality analysis

Average load per hour-of-day to expose recurring daily cycles:

index=<index> sourcetype=<sourcetype>
| bin _time span=1h
| stats count by _time
| eval hour=strftime(_time,"%H")
| stats avg(count) as avg_count stdev(count) as stdev_count by hour
| sort hour

Week-over-week comparison to confirm the pattern repeats:

index=<index> sourcetype=<sourcetype>
| timechart span=1d count
| timewrap 1w

Correlation analysis

Measure how strongly entities co-occur. The dc() + values() pattern is the workhorse here: a high distinct count of B per single A signals fan-out worth investigating.

The dc()/values() correlation template

User correlation, in full -- every other entity pair below applies the same shape against different fields:

index=<index> sourcetype=<sourcetype>
| stats count dc(<host_field>) as host_count dc(<ip_field>) as ip_count
        values(<host_field>) as hosts by <user_field>
| sort -count

Relationship	`by` field(s)	Additional stats / notes
Host correlation	`<host_field>`	`dc(<user_field>)`, `dc(<ip_field>)`, `values(<user_field>)`; sort `-user_count`
IP correlation	`<ip_field>`	`dc(<user_field>)`, `dc(<host_field>)`, `values(<user_field>)`; sort `-user_count`
User ↔ host relationships	`<user_field> <host_field>`	`count`, `earliest(_time)`, `latest(_time)`; sort `-count`
User ↔ IP relationships	`<user_field>`	`dc(<ip_field>)`, `values(<ip_field>)`; sort `-ip_count`
Host ↔ IP relationships	`<host_field>` (and the inverse, by `<ip_field>`)	`dc(<ip_field>)` per host and `dc(<host_field>)` per IP -- confirms 1:1 (good asset hygiene) vs. many:many (DHCP churn, NAT)
Process ↔ user relationships	`<process_field>` (filter `<process_field>=*`)	`count`, `dc(<user_field>)`, `values(<user_field>)`; sort `-count`
Process ↔ host relationships	`<process_field>` (filter `<process_field>=*`)	`count`, `dc(<host_field>)`, `values(<host_field>)`; sort `-host_count`
Asset ↔ user relationships	`<asset_field>`	`count`, `dc(<user_field>)`, `values(<user_field>)`, `earliest(_time)`/`latest(_time)`; sort `-user_count`

Flagging shared or service accounts

Users on an unusually large number of hosts are worth a second look -- potential shared/service accounts or lateral movement:

index=<index> sourcetype=<sourcetype>
| stats dc(<host_field>) as host_count values(<host_field>) as hosts by <user_field>
| where host_count>5
| sort -host_count

Multi-entity correlation

A single view of how the major entity types span each other -- useful as a one-shot relationship profile:

index=<index> sourcetype=<sourcetype>
| stats count
    dc(<user_field>) as users
    dc(<host_field>) as hosts
    dc(<ip_field>) as ips
    dc(<process_field>) as processes
| eval events_per_user=round(count/users,1)

Per-session/per-user rollup tying everything together:

index=<index> sourcetype=<sourcetype>
| stats values(<host_field>) as hosts values(<ip_field>) as ips
        values(<process_field>) as processes count by <user_field>
| eval host_n=mvcount(hosts), ip_n=mvcount(ips), proc_n=mvcount(processes)
| table <user_field> host_n ip_n proc_n count hosts ips
| sort -count

Strong correlation = one value of A almost always maps to a small, stable set of B. Weak/diffuse correlation (one A → many B) either indicates churn (DHCP, NAT) or is itself the signal (one account hitting many hosts).

Outlier analysis

Find what is unusual by frequency or volume. Pair this with Correlation Analysis once you know which fields are entities.

Rare events & entities

Least common event types/signatures:

index=<index> sourcetype=<sourcetype>
| rare limit=25 <field>

Long-tail view (everything seen 5 times or fewer):

index=<index> sourcetype=<sourcetype>
| stats count by <field>
| where count<=5
| sort count

The same shape applied to specific entity types -- stats count [extra fields] by <entity_field> | where <threshold> | sort count:

Entity	Threshold	Additional fields
Rare users	`count<5`	`dc(_time) as active_seconds`, `earliest(_time) as first`
Rare hosts	`count<10`	`earliest(_time) as first_seen`
Rare processes	`count<5 OR host_count=1`	`dc(<host_field>) as host_count` (filter `<process_field>=*`)
Rare IP addresses	`count<5`	`earliest(_time) as first`

High-volume outliers

The opposite tail -- entities responsible for disproportionate volume:

index=<index> sourcetype=<sourcetype>
| stats count by <entity_field>
| eventstats avg(count) as avg stdev(count) as stdev
| eval z=round((count-avg)/stdev,2)
| where z>3
| sort -count

Statistical anomaly detection

Time-series spikes/drops using a 3-sigma band over hourly counts:

index=<index> sourcetype=<sourcetype>
| timechart span=1h count as events
| eventstats avg(events) as avg stdev(events) as stdev
| eval upper=avg+(3*stdev), lower=avg-(3*stdev)
| eval anomaly=if(events>upper OR events<lower,1,0)
| where anomaly=1

Splunk's built-in multivariate outlier finder:

index=<index> sourcetype=<sourcetype>
| timechart span=1h count avg(<numeric_field>) as avg_val
| anomalydetection action=annotate

3-sigma assumes roughly normal data. For spiky/bursty machine data, also try | streamstats window=24 avg(events) as ma stdev(events) as sd | eval z=(events-ma)/sd for a rolling baseline that adapts to trend.

Field correlation & entity discovery

Identify which raw fields actually represent entities, then classify and extract them. This is the heart of onboarding an undocumented source.

Candidate entity fields

Surface fields whose names or values hint at entities. Start from fieldsummary, then inspect promising names:

index=<index> sourcetype=<sourcetype>
| head 50000
| fieldsummary
| eval entity_hint=case(
    match(field,"(?i)user|account|uid|logon|principal|upn|sam"),"user",
    match(field,"(?i)host|computer|device|machine|node|dvc|asset|serial"),"host/asset",
    match(field,"(?i)ip|addr|src|dst|dest"),"ip",
    match(field,"(?i)proc|image|exe|command|cmdline"),"process",
    match(field,"(?i)file|path|object"),"file",
    match(field,"(?i)hash|md5|sha|imphash"),"hash",
    match(field,"(?i)url|uri|domain|referer|fqdn"),"url/domain",
    match(field,"(?i)mail|email|sender|recipient|from|to"),"email",
    1=1,"unclassified")
| where entity_hint!="unclassified"
| table field entity_hint count distinct_count
| sort entity_hint -count

Entity classification framework

Use value patterns (not just names) to confirm what a field holds:

Entity	Typical value signature
User	`DOMAIN\user`, `user@domain`, short alphanumeric SAM names, numeric UID
Host	hostname tokens, FQDNs, `*-LAPTOP`, NetBIOS names
IPv4	`\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}`
IPv6	colon-separated hex groups
URL/Domain	`https?://...`, dotted FQDN
Email	`local@domain.tld`
Process	`*.exe`, full image paths, command lines
File	path with separators, file extension
Hash	32 (MD5) / 40 (SHA1) / 64 (SHA256) hex chars

The logic below tags a single field; loop it over candidates surfaced above:

index=<index> sourcetype=<sourcetype>
| eval classified=case(
    match(<field>,"^\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}$"),"ipv4",
    match(<field>,"^[0-9a-fA-F:]+:[0-9a-fA-F:]+$"),"ipv6",
    match(<field>,"^[^@\s]+@[^@\s]+\.[a-zA-Z]{2,}$"),"email",
    match(<field>,"^https?://"),"url",
    match(<field>,"(?i)^[a-f0-9]{64}$"),"sha256",
    match(<field>,"(?i)^[a-f0-9]{40}$"),"sha1",
    match(<field>,"(?i)^[a-f0-9]{32}$"),"md5",
    match(<field>,"(?i)\.exe$|\\\\"),"process/file_path",
    match(<field>,"(?i)^[^\\@]+\\[^\\@]+$|@"),"user",
    1=1,"other")
| stats count by classified
| sort -count

Discovering entities from raw text

When no clean field exists yet, pull entity-like tokens straight out of _raw with rex. All of the searches below share the same shape -- rex max_match=0 "<pattern>" | stats count [extras] by <found_field> | sort -count -- only the regex, extracted field name and extra stats vary. User discovery in full:

index=<index> sourcetype=<sourcetype>
| rex max_match=0 "(?i)(?:user|account|logon|upn)[\"'=:\s]+(?<found_user>[A-Za-z0-9._\\\\@-]{2,64})"
| stats count by found_user
| sort -count

Entity	Extracted field	Regex pattern	Extra stats / notes
Domain-qualified accounts	`dom_user`	`(?<dom_user>[A-Za-z0-9.-]+\\\\[A-Za-z0-9._-]+)`	--
Host	`found_host`	`(?i)(?:host\|computer\|device\|machine)name?["'=:\s]+(?<found_host>[A-Za-z0-9._-]{2,64})`	--
IP address	`found_ip`	`(?<found_ip>\b(?:\d{1,3}\.){3}\d{1,3}\b)`	`dc(host) as seen_on_hosts`; split internal/external with `cidrmatch("10.0.0.0/8",found_ip) OR cidrmatch("172.16.0.0/12",found_ip) OR cidrmatch("192.168.0.0/16",found_ip)`
URL	`found_url`	`(?<found_url>https?://[^\s"'<>]+)`	reduce to registered domain with `https?://(?<found_domain>[A-Za-z0-9.-]+)`, `dc(host)`
Email	`found_email`	`(?<found_email>[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,})`	--
Process	`found_proc`	`(?<found_proc>[A-Za-z0-9_\-.]+\.(?:exe\|dll\|sys\|ps1\|sh\|bin\|py))`	`dc(host) as hosts`; full command lines via `(?<found_path>(?:[A-Za-z]:\\\\\|/)[^\s"']+\.(?:exe\|dll\|sh\|bin))`
File	`found_file`	`(?<found_file>[\w\-.]+\.(?:doc\|docx\|xls\|xlsx\|pdf\|zip\|rar\|7z\|txt\|csv\|conf\|key\|pem))`	--
Hash	`found_hash`	`(?<found_hash>\b[a-fA-F0-9]{32,64}\b)`	label `hash_type` by length: 32=MD5, 40=SHA1, 64=SHA256
MAC address	`found_mac`	`(?<found_mac>\b(?:[0-9A-Fa-f]{2}[:-]){5}[0-9A-Fa-f]{2}\b)`	`dc(host) as hosts`
Asset tag / serial	`found_asset`	`(?i)(?:serial\|asset[_-]?tag\|sn)["'=:\s]+(?<found_asset>[A-Za-z0-9-]{4,32})`	--

Once discovery shows a token type appears with high coverage, promote it to a real field with a field extraction (props.conf/transforms.conf or EXTRACT-) so later phases and detections can rely on it natively.

Field relationship analysis

Determine whether two fields are duplicates, aliases, or candidates for normalization/CIM mapping. This is how you collapse redundant fields and pick canonical names.

Compare two fields for matching values

Row-level agreement between two fields:

index=<index> sourcetype=<sourcetype> <field_a>=* <field_b>=*
| eval match=if(<field_a>==<field_b>,"equal","different")
| stats count by match
| eventstats sum(count) as total
| eval pct=round(count/total*100,2)

Distinct count & value set comparison

Compare cardinality and overlap of the value sets:

index=<index> sourcetype=<sourcetype>
| stats dc(<field_a>) as distinct_a dc(<field_b>) as distinct_b
        dc(eval(if(<field_a>==<field_b>,<field_a>,null()))) as overlap_values
        count as events

List values present in A but not in B (and vice versa) to spot partial aliases:

index=<index> sourcetype=<sourcetype>
| eval a_val=<field_a>, b_val=<field_b>
| stats values(a_val) as set_a values(b_val) as set_b
| eval only_in_a=mvmap(set_a, if(isnull(mvfind(set_b, "^".set_a."$")), set_a, null()))
| eval only_in_b=mvmap(set_b, if(isnull(mvfind(set_a, "^".set_b."$")), set_b, null()))
| table only_in_a only_in_b

Simpler alternative for large sets: run | stats count by <field_a> and | stats count by <field_b> separately and diff the value lists, or use set diff across two subsearches.

Similarity & duplicate field detection

Quantify how often the two fields carry the same value when both are present -- a high score means they are likely the same logical field:

index=<index> sourcetype=<sourcetype> <field_a>=* <field_b>=*
| eval same=if(lower(<field_a>)==lower(<field_b>),1,0)
| stats sum(same) as matches count as both_present
| eval similarity_pct=round(matches/both_present*100,2)

Scan all fields for pairs that are effectively identical. Run pairwise similarity (above) on the candidate pairs surfaced by comparing fieldsummary distinct counts and sample values:

index=<index> sourcetype=<sourcetype>
| head 50000
| fieldsummary
| table field count distinct_count values
| sort distinct_count

Fields with identical distinct_count and overlapping sample values are prime duplicate candidates -- confirm with the similarity search above.

Alias field detection

Aliases are fields that always hold the same value but differ in name (e.g. usr vs. user, clientip vs. src_ip). Confirm a suspected alias pair:

index=<index> sourcetype=<sourcetype>
| eval a=coalesce(<field_a>,"∅"), b=coalesce(<field_b>,"∅")
| stats count by a b
| where a!=b
| sort -count

If this returns (near) zero rows, the two fields never disagree -- treat one as an alias of the other (FIELDALIAS- in props.conf).

Normalization & CIM mapping candidates

Find fields whose values need cleanup before they can be compared or correlated (mixed case, domain prefixes, trailing whitespace, $ machine-account suffix):

index=<index> sourcetype=<sourcetype>
| eval needs_norm=case(
    <field>!=lower(<field>),"mixed_case",
    match(<field>,"\\\\"),"contains_domain_prefix",
    match(<field>,"\$$"),"machine_account_suffix",
    match(<field>,"^\s|\s$"),"whitespace",
    1=1,"clean")
| stats count by needs_norm
| sort -count

For each non-CIM field, suggest the CIM field it most likely maps to (extend the mapping table to your target data model):

index=<index> sourcetype=<sourcetype>
| head 50000
| fieldsummary
| eval cim_candidate=case(
    match(field,"(?i)^(usr|username|account|logon|samaccountname)$"),"user",
    match(field,"(?i)^(clientip|client_ip|sourceip|srcip|c_ip)$"),"src_ip",
    match(field,"(?i)^(destinationip|dstip|targetip|s_ip)$"),"dest_ip",
    match(field,"(?i)^(computer|hostname|machine|nodename)$"),"dest",
    match(field,"(?i)^(image|process_path|exe)$"),"process",
    match(field,"(?i)^(md5|sha1|sha256|filehash)$"),"file_hash",
    match(field,"(?i)^(method|httpmethod|verb)$"),"http_method",
    match(field,"(?i)^(uri|request_url|requesturl)$"),"url",
    1=1,null())
| where isnotnull(cim_candidate)
| table field cim_candidate count distinct_count

The output of this phase becomes your field-rename/alias plan: a mapping of native fields to canonical (CIM) names, plus a list of fields to normalize at search or index time -- feed it into Field Normalisation and the CIM Assessment's Data Model Mapping below.

Field value correlation matrix

Build co-occurrence matrices between two fields. contingency produces a value-vs-value count matrix; the chart ... over ... by ... pattern gives a readable, sortable equivalent. These reveal which specific entity values stick together.

contingency can explode on high-cardinality fields. Pre-filter to top values (e.g. | top limit=20 <field>) or use maxcols/maxrows options. The chart form below is usually safer for exploration.

User field correlation matrix

User × host occurrence counts:

index=<index> sourcetype=<sourcetype>
| eval u=<user_field>, h=<host_field>
| where isnotnull(u) AND isnotnull(h)
| chart limit=20 count over u by h

index=<index> sourcetype=<sourcetype>
| contingency maxcols=25 maxrows=25 <user_field> <host_field>

Matrix	Pattern
Host × IP	`chart limit=20 count over <host_field> by <ip_field>`
Source IP × destination IP (flow pairs)	`chart limit=20 count over <src_ip_field> by <dest_ip_field>`
Process × host (filter `<process_field>=*`)	`chart limit=20 count over <process_field> by <host_field>`
Parent/child process pairing	`contingency maxcols=25 maxrows=25 <parent_process_field> <process_field>`
Asset × user	`chart limit=20 count over <asset_field> by <user_field>`
Sender × recipient (email)	`chart limit=20 count over <sender_field> by <recipient_field>`

Dense rows (one value correlating with many columns) mark hubs -- shared accounts, jump hosts, mail relays, gateways. Sparse one-to-one cells indicate tightly bound pairs (a user and their single workstation) that make clean baselines.

CIM assessment

Score how ready the source is for a CIM data model and produce the gap list needed to finish onboarding. Pick the target data model first (Authentication, Network Traffic, Web, Endpoint/Processes, Email, Malware, etc.) and adjust field lists accordingly.

CIM compliance assessment

High-level pass: which expected CIM fields for the target model are present at all. Example uses the Authentication model -- swap the list for your model:

index=<index> sourcetype=<sourcetype>
| head 50000
| fieldsummary
| eval cim_model="Authentication"
| eval is_required=if(field IN ("action","app","src","dest","user"),1,0)
| eval is_recommended=if(field IN ("src_user","user_id","signature","status","reason","authentication_method"),1,0)
| where is_required=1 OR is_recommended=1
| table field is_required is_recommended count distinct_count

Required CIM fields

Confirm presence and fill rate of the required fields for the model (Authentication example):

index=<index> sourcetype=<sourcetype>
| stats count as total
    count(action) as action count(app) as app
    count(src) as src count(dest) as dest count(user) as user
| eval action=round(action/total*100,1), app=round(app/total*100,1),
       src=round(src/total*100,1), dest=round(dest/total*100,1), user=round(user/total*100,1)
| transpose
| rename column as cim_field "row 1" as fill_pct
| where cim_field!="total"

Optional CIM fields

Same check for recommended/optional fields that improve detection coverage:

index=<index> sourcetype=<sourcetype>
| stats count as total
    count(src_user) as src_user count(user_id) as user_id
    count(signature) as signature count(status) as status
    count(reason) as reason count(authentication_method) as auth_method
| transpose
| rename column as cim_field "row 1" as populated_events

Missing CIM fields

Explicitly list required fields that do not exist or are effectively empty so they become onboarding action items:

index=<index> sourcetype=<sourcetype>
| head 50000
| fieldsummary
| eval present_fields=field
| stats values(present_fields) as present
| eval required=split("action,app,src,dest,user",",")
| eval missing=mvmap(required, if(isnull(mvfind(present,"^".required."$")), required, null()))
| table missing

Data model mapping

Document the native → CIM field mapping you will implement (this is the deliverable that drives props.conf/transforms.conf). Build it from the CIM Mapping Candidate Identification and Cross-Sourcetype Join-Key Discovery results above; the search below renders your decided mapping for review:

| makeresults
| eval mappings=split("clientip=src_ip,usr=user,computer=dest,verb=http_method,requesturl=url,md5=file_hash","|")
| makemv delim="," mappings
| mvexpand mappings
| rex field=mappings "(?<native_field>[^=]+)=(?<cim_field>.+)"
| table native_field cim_field

Apply renames via FIELDALIAS-<name> = <native> AS <cim> (preserves the original) or EVAL-<cim> = <expression> for derived/normalised values -- see the Field Normalisation reference for both mechanisms in full. Validate with the CIM data model's "Pivot" or | datamodel <Model> <Object> search.

CIM coverage score

A single percentage covering required-field presence and fill -- useful for tracking onboarding progress across many sources. Weights required fields fully and recommended fields at half:

index=<index> sourcetype=<sourcetype>
| stats count as total
    count(action) as action count(app) as app count(src) as src
    count(dest) as dest count(user) as user
    count(src_user) as src_user count(status) as status count(signature) as signature
| eval req_score=((if(action>0,1,0)+if(app>0,1,0)+if(src>0,1,0)+if(dest>0,1,0)+if(user>0,1,0))/5)
| eval rec_score=((if(src_user>0,1,0)+if(status>0,1,0)+if(signature>0,1,0))/3)
| eval cim_coverage_pct=round(((req_score*0.7)+(rec_score*0.3))*100,1)
| table cim_coverage_pct req_score rec_score

Validate the source actually populates the model after mapping (returns events only if they match the accelerated/defined data model):

| datamodel Authentication Authentication search
| search index=<index>
| stats count by sourcetype

Interpretation. Treat required-field coverage as a gate -- a source with <100% required coverage will silently underperform in any out-of-the-box CIM-based detection. Use the coverage score over time to show onboarding is converging, and re-run this assessment and the blind-correlation techniques below whenever the upstream log format changes.

Sensitive data & secrets discovery

New, undocumented sources are the most likely place to find credentials, tokens and PII accidentally written to logs. Quantify exposure before widening index access. Count and locate -- never table the matched values themselves.

index=<index> sourcetype=<sourcetype>
| eval cleartext_password=if(match(_raw,"(?i)\b(password|passwd|pwd)\b\s*[=:]\s*\S+"),1,0),
       aws_access_key=if(match(_raw,"\bAKIA[0-9A-Z]{16}\b"),1,0),
       bearer_token=if(match(_raw,"(?i)\bbearer\s+[A-Za-z0-9._~+/=-]{20,}"),1,0),
       private_key_block=if(match(_raw,"BEGIN (RSA |EC |OPENSSH |PGP )?PRIVATE KEY"),1,0),
       ssn_like=if(match(_raw,"\b\d{3}-\d{2}-\d{4}\b"),1,0),
       card_like=if(match(_raw,"\b\d{4}[ -]?\d{4}[ -]?\d{4}[ -]?\d{4}\b"),1,0)
| stats count as total_events sum(cleartext_password) as password_hits
        sum(aws_access_key) as aws_key_hits sum(bearer_token) as bearer_hits
        sum(private_key_block) as private_key_hits sum(ssn_like) as ssn_like_hits
        sum(card_like) as card_like_hits

Locate the offending emitters without displaying the secrets:

index=<index> sourcetype=<sourcetype>
| where match(_raw,"(?i)\b(password|passwd|pwd)\b\s*[=:]\s*\S+") OR match(_raw,"\bAKIA[0-9A-Z]{16}\b")
| stats count earliest(_time) as first latest(_time) as last by source host
| eval first=strftime(first,"%F %T"), last=strftime(last,"%F %T")
| sort -count

Remediation: mask at ingest with SEDCMD- in props.conf or Ingest Actions, restrict index access while exposed data remains searchable, and file a fix against the upstream application. ssn_like/card_like are pattern matches only -- order numbers and internal IDs will false-positive, so validate a sample before escalating. Findings here directly inform Access Control's scope decisions and Retention Policy's secure-deletion requirement.

Enrichment & context validation

Detection value multiplies when entities in the new source resolve against your asset and identity inventory. Measure the match rate; a low rate is itself a finding.

Inventory available lookups first:

| rest /services/data/transforms/lookups splunk_server=local
| table title filename
| sort title

Host/asset match rate (in Enterprise Security use asset_lookup_by_str / asset_lookup_by_cidr):

index=<index> sourcetype=<sourcetype>
| stats count by <host_field>
| lookup <asset_lookup> <asset_key_field> as <host_field> OUTPUT <asset_key_field> as matched
| eval status=if(isnotnull(matched),"known_asset","unknown_asset")
| stats sum(count) as events dc(<host_field>) as distinct_entities by status

User/identity match rate (in ES, identity_lookup_expanded):

index=<index> sourcetype=<sourcetype>
| stats count by <user_field>
| lookup <identity_lookup> <identity_key_field> as <user_field> OUTPUT <identity_key_field> as matched
| eval status=if(isnotnull(matched),"known_identity","unknown_identity")
| stats sum(count) as events dc(<user_field>) as distinct_entities by status

Top unmatched entities -- naming-convention mismatches or genuine inventory gaps:

index=<index> sourcetype=<sourcetype>
| stats count by <host_field>
| lookup <asset_lookup> <asset_key_field> as <host_field> OUTPUT <asset_key_field> as matched
| where isnull(matched)
| sort -count
| head 50

Low match rates usually trace to normalization issues (case, FQDN vs. shortname, DOMAIN\ prefixes -- fix with Field Relationship Analysis outputs) or to assets/identities genuinely missing from your inventory. Both belong in the onboarding findings either way. This also ties into Access Control's authentication integration -- an LDAP/SAML mapping change upstream can silently degrade identity match rates.

Blind correlation: field-name-agnostic techniques

Everything in standard field investigation up to this point still assumes you can at least see field names. Sometimes you can't trust them -- extractions are broken, names are cryptic, or two sources name the same thing completely differently. The fix is to stop thinking in field names and work in value space: pivot on values, transform events from wide to long, intersect token sets, and fall back to time itself.

Find which field holds a known value

You know an entity exists (a username, an IP, a hostname) but not where it lives. foreach * iterates over every field without naming any:

index=<index> sourcetype=<sourcetype> "<known_value>"
| head 1000
| foreach * [eval holders=if('<<FIELD>>'=="<known_value>", mvappend(holders,"<<FIELD>>"), holders)]
| stats count by holders
| sort -count

Swap == for match('<<FIELD>>',"<known_value>") to catch the value embedded inside longer strings (escape regex metacharacters first). '<<FIELD>>' in single quotes reads the field's value; "<<FIELD>>" in double quotes is the field's name as a string.

Indexed-term pivot (TERM + tstats)

Find every index and sourcetype that contains a value as an indexed token -- no fields involved, and fast across the whole estate:

| tstats count where index=* TERM(<known_value>) by index sourcetype
| sort -count

TERM() is case-sensitive, cannot contain major breakers (spaces), and works best for values whose internal punctuation consists of minor breakers -- IPs, FQDNs, GUIDs, emails. This is the fastest possible answer to "where else does this entity appear?"

Read the lexicon directly (walklex)

walklex lists the indexed fields and terms straight from the index's lexicon files -- the ultimate blind inventory of what a source contains:

| walklex index=<index> type=field
| stats sum(count) as occurrences by field
| sort -occurrences

| walklex index=<index> prefix=<value_prefix> type=term
| stats sum(count) as occurrences by term
| sort -occurrences
| head 100

Requires an elevated capability (admin roles by default). Results reflect indexed tokens and fields only -- search-time extractions won't appear, which itself tells you which fields are index-time vs. search-time.

Wide → long transformation (the foundation)

Explode every event into (field, value) rows. Once data is in long format, every comparison becomes value-space analysis, independent of names:

index=<index> sourcetype=<sourcetype>
| head 5000
| foreach * [eval fv=mvappend(fv, "<<FIELD>>=" . mvjoin(mvdedup('<<FIELD>>'),"|"))]
| fields _time sourcetype fv
| mvexpand fv
| rex field=fv "^(?<f>[^=]+)=(?<v>.+)$"
| where isnotnull(v) AND NOT match(f,"^(date_|punct|linecount|timestamp|splunk_server|eventtype|tag)")

Performance. foreach * + mvexpand is O(events × fields) -- keep head at 5-10k. mvjoin flattens multivalue fields so they don't break the transform. Every technique below builds on this pattern.

Cross-sourcetype join-key discovery (the Rosetta Stone)

The headline technique: automatically find which field in sourcetype A shares values with which field in sourcetype B -- your field mapping, derived from the data itself:

index=<index> (sourcetype=<sourcetype_a> OR sourcetype=<sourcetype_b>)
| head 10000
| foreach * [eval fv=mvappend(fv, "<<FIELD>>=" . mvjoin(mvdedup('<<FIELD>>'),"|"))]
| fields sourcetype fv
| mvexpand fv
| rex field=fv "^(?<f>[^=]+)=(?<v>.+)$"
| where len(v)>=4 AND NOT match(f,"^(date_|punct|linecount|timestamp|splunk_server|eventtype|tag)")
| eval loc=sourcetype . "::" . f
| stats values(loc) as locations dc(sourcetype) as st_count by v
| where st_count>1
| eval field_pair=mvjoin(mvsort(locations)," <-> ")
| stats count as shared_values values(v) as sample_values by field_pair
| eval sample_values=mvindex(sample_values,0,4)
| sort -shared_values

Output reads like proxy::src <-> edr::local_ip | shared_values=4812 -- a ranked list of join-key candidates between the two sources. Discard pairs whose sample values are enums ("success", "tcp") shared trivially; the real keys are high-cardinality identifiers. Feed confirmed pairs into the Field Extraction and Field Normalisation references and the CIM Data Model Mapping above.

Value-shape field profiling

Classify every field by what its values look like -- length, digit density, charset -- instead of by name. Fields with near-identical shape profiles and cardinality are alias candidates even across sourcetypes:

index=<index> sourcetype=<sourcetype>
| head 5000
| foreach * [eval fv=mvappend(fv, "<<FIELD>>=" . mvjoin(mvdedup('<<FIELD>>'),"|"))]
| fields fv
| mvexpand fv
| rex field=fv "^(?<f>[^=]+)=(?<v>.+)$"
| eval vlen=len(v),
       digit_ratio=round((vlen-len(replace(v,"\d","")))/vlen,2),
       shape=case(
         match(v,"(?i)^[0-9a-f]+$") AND vlen>=32,"hex_hash_like",
         match(v,"^\d+$"),"numeric",
         match(v,"^[\d\.\:]+$"),"ip_like",
         match(v,"\\\\|/"),"path_like",
         match(v,"@"),"email_like",
         1=1,"mixed")
| stats count dc(v) as cardinality avg(vlen) as avg_len avg(digit_ratio) as avg_digit_ratio
        values(shape) as shapes by f
| sort -cardinality

Raw-token intersection (nothing extracts at all)

When field extraction is completely broken, tokenize _raw itself and intersect token sets across sources. Tokens containing digits filter out log keywords (ERROR, session) and keep entity-shaped values (IDs, hostnames, IPs, GUIDs):

index=<index> (sourcetype=<sourcetype_a> OR sourcetype=<sourcetype_b>)
| head 10000
| rex max_match=100 field=_raw "(?<tok>\b[A-Za-z0-9][A-Za-z0-9._:-]{5,}\b)"
| stats dc(sourcetype) as st_count count values(sourcetype) as seen_in by tok
| where st_count>1 AND match(tok,"\d")
| sort -count
| head 100

Very high-count shared tokens are format boilerplate; the interesting join keys sit in the mid-frequency band. Drop the match(tok,"\d") filter if you need to catch all-alpha usernames.

Time-proximity correlation (no shared values at all)

If two sources share nothing extractable, correlate on time itself. First, co-occurrence rate per second:

index=<index> (sourcetype=<sourcetype_a> OR sourcetype=<sourcetype_b>)
| bin _time span=1s
| stats dc(sourcetype) as st by _time
| stats count(eval(st>1)) as co_occurring count as total_buckets
| eval co_rate_pct=round(co_occurring/total_buckets*100,1)

Then profile the lag from every A event to the next B event -- a tight, consistent lag distribution implies a causal pipeline between the sources even with zero shared fields:

index=<index> (sourcetype=<sourcetype_a> OR sourcetype=<sourcetype_b>)
| sort 0 + _time
| eval a_time=if(sourcetype="<sourcetype_a>",_time,null())
| filldown a_time
| where sourcetype="<sourcetype_b>" AND isnotnull(a_time)
| eval lag_sec=_time-a_time
| stats count avg(lag_sec) as avg_lag median(lag_sec) as median_lag perc95(lag_sec) as p95_lag

sort 0 removes the 10k result cap -- restrict the time window before running this on busy sources. A flat/wide lag distribution means the sources are unrelated; a spike at a fixed small lag (B fires 0-2s after A) is a relationship you can build a transaction-style correlation on.

Blind-source workflow

walklex / TERM() pivot -- learn what tokens the index holds and where known entities live.
foreach needle search -- pin each known value to its holder field(s).
Wide → long transform -- make the whole source name-independent.
Join-key discovery + shape profiling -- derive the cross-source field mapping from data.
Token intersection / time-lag -- fall back when extraction or shared values fail entirely.
Promote findings into Field Extraction aliases and the CIM Assessment mappings above -- then re-validate with real field names.

Quick reference

A condensed index of the highest-value technique from each phase above, grouped by concern.

Parse health & exposure

stats count by punct -- structural fingerprint of event formats
cluster showcount=true t=0.8 -- one representative per event "type"
eval lag=_indextime-_time -- timestamp lag and timezone-offset check
len(_raw) approaching 10,000 -- TRUNCATE risk
match(_raw,"AKIA[0-9A-Z]{16}") and friends -- count secrets/PII without displaying them
lookup <asset_lookup> ... + match-rate stats -- enrichment coverage

Profiling & inventory

| metadata type=sourcetypes index=<index> -- sourcetype inventory with first/last seen
| tstats count where index=<index> by sourcetype _time span=1h -- fast volume
| fieldsummary -- per-field count, distinct_count, numeric_count, sample values

Quality

count(<field>) vs. count -- fill rate
isnull(<field>), <field>="", value-in-list checks -- null/placeholder/junk detection
lower() canon + dc() variants -- case-collision detection
md5(_raw) group counts -- duplicate-event rate and origin
case(match(...)) shape rules -- IP/port/hash format validity
timechart count(<field>)/count, fieldsummary append-diff -- quality drift
weighted completeness/validity/uniqueness/timeliness -- DQ scorecard

Temporal

timechart span=1h count then where count=0 -- ingestion gaps
timewrap 1w, bin _time span=1h + per-hour stats -- seasonality

Correlation & outliers

stats dc(B) values(B) count by A -- fan-out / relationships
rare / top, stats count by X | where count<=N -- rarity
eventstats avg stdev + z-score, anomalydetection, streamstats rolling baseline -- anomalies

Entity discovery

rex max_match=0 "<pattern>" -- extract repeated tokens from _raw
cidrmatch() -- internal vs. external IP
case(... match(...) ...) -- value-pattern classification

Relationships & CIM

contingency A B, chart count over A by B -- co-occurrence matrix
FIELDALIAS-, EVAL-, EXTRACT- (props/transforms) -- promote & map fields
| datamodel <Model> <Object> search -- verify CIM population

Blind correlation (no trusted field names)

| tstats count where index=* TERM(<value>) by index sourcetype -- value pivot across the estate
| walklex index=<index> type=field|term -- read the index lexicon directly
foreach * [eval ...mvappend(holders,"<<FIELD>>")...] -- find which field holds a known value
foreach * + mvexpand wide→long explode -- name-independent (field,value) analysis
shared-value field_pair discovery -- auto-derived cross-sourcetype field mapping
rex token intersection on _raw; filldown time-lag profiling -- correlate with zero extractions

Onboarding documentation template

Copy this skeleton into your knowledge base and fill it from the phase outputs above -- it is the deliverable that proves the source is understood.

# Source Onboarding: <index> / <sourcetype>
## Overview
- Technology / vendor / version:
- Collection path (UF / HF / HEC / API / syslog):
- Business owner & escalation contact:
- Date profiled / engineer:
## Parse Health (Parse-Time Health)
- Format: json | kv | csv | xml | unstructured
- Dominant punct patterns:            Event clusters:
- Timestamp lag (p95):                TZ verified: yes/no
- Truncation risk: yes/no             Line breaking verified: yes/no
## Volume Profile (Data Source Profiling, Temporal Analysis)
- Avg daily events / MB:
- Peak hours / quiet hours / weekend pattern:
- Known ingestion gaps & cause:
## Field Dictionary (Data Quality, Entity Discovery, Field Relationships)
| Native field | Type | Fill % | Distinct | Entity class | CIM mapping | Notes |
|---|---|---|---|---|---|---|
|  |  |  |  |  |  |  |
## Data Quality (Data Quality Analysis)
- DQ score:                           Duplicate-event rate:
- Junk/placeholder rate (key fields):
- Validity / consistency issues & fixes:
## Entity Relationships (Correlation Analysis, Correlation Matrix)
- user ↔ host cardinality & hubs:
- host ↔ ip stability (DHCP / NAT?):
- Shared / service accounts identified:
## Outliers & Baseline (Outlier Analysis)
- Baseline window captured:
- Known-benign high-volume entities:
## CIM Assessment (CIM Assessment)
- Target data model:
- Required-field coverage:            Coverage score:
- Missing fields & remediation plan:
## Sensitive Data Review (Sensitive Data & Secrets Discovery)
- Findings:                           Masking applied:
## Enrichment (Enrichment & Context Validation)
- Asset match rate:                   Identity match rate:
## Quirks & Normalizations
-
## Sign-off
- Detection-ready: yes/no             Date:

Detection-readiness checklist

The gate before this source feeds correlation searches. Tip: package the recurring searches from this playbook as macros (e.g. eda_fill_rate(2), eda_entity_matrix(3)) so every onboarding runs the same way.

Parse health verified: stable punct, single timestamp per event, no truncation
_time trustworthy: acceptable lag, no whole-hour TZ offset, no future-dated events
No unexplained ingestion gaps across the baseline window
Detection-critical fields ≥95% fill (or gaps documented and accepted)
Junk/placeholder rate quantified; effective fill (populated minus junk) meets the bar
Entity formats validated (IP/port/hash); case collisions and encoding artifacts normalized
Duplicate-event rate measured and explained; DQ scorecard baselined with drift alerts scheduled
Entity fields discovered, classified, and promoted to real extractions
Duplicate/alias fields collapsed to one canonical name each
Values normalized (case, domain prefixes, FQDN vs. shortname, machine $ suffix)
CIM required-field coverage 100% for the target model; | datamodel search returns events
Asset/identity enrichment match rate measured and acceptable
Sensitive-data scan complete; masking applied where required
Baseline captured: per-entity volumes, rare lists, hourly/weekly profile

This checklist operationalises the same onboarding Pre-ingest cyber-value gate (TAX-06.05.02) that the Log Assessment Framework's all-axes conformance rate feeds -- that gate covers structural parse health; this checklist covers the full detection-readiness bar built on top of it.

Relationship to other references

This playbook is a full pass over its source document: all fourteen phases and all three appendices are covered above. It is deliberately a reusable, cross-cutting procedure rather than a scored taxonomy leaf -- like Log Assessment Framework, it produces the evidence and mappings that other reference articles and calculators score or consume. Parse-Time Health leans on Log Assessment Framework, Line Length and Timestamp Quality for the structural detail it only sanity-checks; Data Quality Analysis's scorecard mirrors Data Quality Score; Entity Discovery and Field Relationship Analysis feed Field Extraction and Field Normalisation directly; Sensitive Data Discovery and Enrichment Validation tie into Access Control and Retention Policy; and CIM Assessment's Data Model Mapping is the same deliverable Field Normalisation's CIM compliance workflow describes.

Reference · Splunk platform

Data Pipeline

The stages an event passes through from a Universal Forwarder's input pipeline to an indexer's write to disk, including the internal queues connecting them, and which component (UF vs. Heavy Forwarder/Indexer) each stage typically applies to.

Pipeline	Stage	What happens	Common configuration	UF	HF/Indexer
Input pipeline	Source acquisition	Reads data from monitored files, operating-system inputs, raw TCP/UDP listeners, HEC, scripts or modular inputs.	`inputs.conf`	Y	Y
Input pipeline	Input checkpointing	Tracks file offsets, CRC state or input-specific checkpoints so collection can resume without unnecessarily rereading data.	`inputs.conf`, fishbucket, modular-input checkpoints	Y	Y
Input pipeline	Input block creation	Divides the incoming raw stream into blocks for movement through the pipeline. These blocks are not yet individual Splunk events.	Internal processing	Y	Y
Input pipeline	Source-wide metadata annotation	Adds metadata that applies to the input stream or block, including initial host, source, sourcetype, target index and encoding information.	`inputs.conf`, input-time `props.conf`	Y	Y
Input/parsing boundary	Character decoding	Applies the configured character encoding where the data is first read and converts textual data to Splunk's internal UTF-8 representation.	`CHARSET` in `props.conf`	Y	Y
Input buffering	Persistent input queue	Optionally writes queued input data to disk when downstream processing or forwarding is blocked.	`persistentQueueSize`, `queueSize` in `inputs.conf`	Y	Y
TCP input handoff	tcpin_queue	Buffers incoming Splunk-to-Splunk data before passing it to the receiving component's processing path.	Internal queue; `[splunktcp://<port>]` in `inputs.conf`	N	Y
Structured parsing handoff	structuredParsingQueue	Holds data requiring structured parsing, such as CSV or other inputs using indexed structured-field extraction.	Internal queue	Y	Y
Structured parsing pipeline	Structured-data parsing	Parses supported structured formats and can create indexed fields from headers, delimiters or structured keys. A UF can perform this locally.	`INDEXED_EXTRACTIONS`, `FIELD_DELIMITER`, `FIELD_NAMES`, `HEADER_FIELD_LINE_NUMBER`, `TIMESTAMP_FIELDS`	Y	Y
Parsing handoff	parsingQueue	Buffers incoming data before full parsing or lightweight forwarding processing.	Internal queue	Y	Y
UF forwarding pipeline	Event boundary detection	Uses lightweight boundary recognition so a UF can distribute data between receivers without dividing an event. It does not create the final indexed event.	`EVENT_BREAKER_ENABLE`, `EVENT_BREAKER` in `props.conf`	Y	N
Parsing pipeline	Line breaking and line-length control	Uses the raw stream to identify initial event boundaries and enforces the maximum permitted line length.	`LINE_BREAKER`, `LINE_BREAKER_LOOKBEHIND`, `TRUNCATE`	N	Y
Parsing pipeline	Header processing	Recognises or removes headers and preambles where applicable and establishes structured field names.	`HEADER_FIELD_LINE_NUMBER`, `FIELD_HEADER_REGEX`, `PREAMBLE_REGEX`	N	Y
Merging handoff	aggQueue	Passes initial lines or fragments to event aggregation and timestamp processing.	Internal queue	N	Y
Merging pipeline	Event aggregation	Combines physical lines into logical events or keeps them as individual events.	`SHOULD_LINEMERGE`, `BREAK_ONLY_BEFORE`, `BREAK_ONLY_BEFORE_DATE`, `MUST_BREAK_AFTER`, `MUST_NOT_BREAK_BEFORE`, `MUST_NOT_BREAK_AFTER`, `MAX_EVENTS`	N	Y
Merging pipeline	Timestamp extraction	Locates and parses the event timestamp and assigns `_time`.	`TIME_PREFIX`, `TIME_FORMAT`, `MAX_TIMESTAMP_LOOKAHEAD`, `DATETIME_CONFIG`, `TZ`	N	Y
Merging pipeline	Default timestamp handling	Assigns an input-provided, file-modification, previous-event or current timestamp when configured timestamp extraction does not produce a valid value.	`DATETIME_CONFIG`, timestamp settings in `props.conf`	N	Y
Merging pipeline	Timestamp validation	Applies acceptable past and future timestamp boundaries.	`MAX_DAYS_AGO`, `MAX_DAYS_HENCE`	N	Y
Merging pipeline	Event age filtering	Optionally sends events older than the configured age to `nullQueue` after timestamp extraction.	`ROUTE_EVENTS_OLDER_THAN`	N	Y
Typing handoff	typingQueue	Buffers completed events before index-time transformation, annotation and typing.	Internal queue	N	Y
Typing pipeline	Per-event metadata annotation	Copies source-wide metadata onto individual events and applies per-event metadata overrides.	`props.conf`, `transforms.conf`	N	Y
Typing pipeline	Index-time transformations	Applies regex or expression-based transformations to event content and metadata.	`TRANSFORMS-`, `RULESET-`, `REGEX`, `FORMAT`, `DEST_KEY`, `INGEST_EVAL`	N	Y
Typing pipeline	Metadata routing	Selects or changes the index, processing queue, host, source or sourcetype. Events can be routed to `nullQueue`.	`_MetaData:Index`, `MetaData:Host`, `MetaData:Source`, `MetaData:Sourcetype`, `queue`	N	Y
Typing pipeline	_raw modification and masking	Rewrites, removes or masks portions of the raw event before forwarding or indexing.	`SEDCMD-*`; transforms with `DEST_KEY = _raw`	N	Y
Typing pipeline	Event cloning	Creates a copy of an event under another sourcetype for separate processing.	`CLONE_SOURCETYPE` in `transforms.conf`	N	Y
Typing pipeline	Indexed-field creation	Creates explicitly configured fields that are stored as index-time metadata.	`WRITE_META = true`, `INGEST_EVAL`, `fields.conf`	N	Y
Typing pipeline	Event typing and punctuation	Generates internal event characteristics, including the `_punct` representation.	Primarily internal processing	N	Y
Indexing handoff	indexQueue	Buffers fully parsed events before local indexing or forwarding.	Internal queue	N	Y
Forwarding pipeline	Output selection and load balancing	Chooses an available receiver, target group or forwarding destination for outgoing data.	`[tcpout]`, `[tcpout:<target_group>]`, `server`, `autoLBFrequency`, `forceTimebasedAutoLB`	Y	Y
TCP output handoff	tcpout_queue	Buffers outgoing data before transmission to a Splunk receiver using Splunk-to-Splunk.	Internal output queue; `outputs.conf`	Y	Y
Forwarding pipeline	Splunk-to-Splunk transmission	Packages and sends raw or cooked data to the selected receiver over the Splunk-to-Splunk protocol.	`outputs.conf`; TCP/9997 by default	Y	Y
Indexing pipeline	Index selection and validation	Resolves the target index and confirms that the index is available to receive the event.	Event metadata, `indexes.conf`	N	Y
Indexing pipeline	Searchable segmentation	Breaks event text into searchable segments or terms before index structures are generated.	`SEGMENTATION` in `props.conf`, `segmenters.conf`	N	Y
Indexing pipeline	Hot-bucket allocation	Selects or creates the appropriate hot bucket based on index, time and bucket configuration.	`indexes.conf`	N	Y
Indexing pipeline	Rawdata journal writing	Compresses and writes event data and associated information into the bucket's rawdata journal.	`indexes.conf`, `journalCompression`	N	Y
Indexing pipeline	TSIDX creation	Creates searchable term-to-event mappings and other index structures that reference the rawdata journal.	`indexes.conf`, `segmenters.conf`	N	Y
Indexing pipeline	Bucket metadata update	Updates bucket metadata, time boundaries and related index files as events are written.	`indexes.conf`, internal indexing processing	N	Y
Replication pipeline	Rawdata replication	In an indexer cluster, streams replicated rawdata to other peer indexers to satisfy the replication factor.	Indexer-cluster settings in `server.conf`	N	Y
Replication pipeline	Searchable-copy creation	Creates TSIDX and related index files on the required replicated copies to satisfy the search factor.	Replication factor and search factor in cluster configuration	N	Y
Acknowledgement path	Outbound acknowledgement tracking	Retains and tracks forwarded data until the receiver acknowledges it. Data can be resent following qualifying connection failures.	`useACK` in `outputs.conf`	Y	Y
Acknowledgement path	Receiver acknowledgement generation	Generates an acknowledgement after the applicable receipt, persistence or cluster-replication requirements are met.	Receiver and indexer-cluster configuration	N	Y
Pipeline control	Queue flow control and backpressure	Blocks or slows upstream processors when a downstream queue is full.	Queue settings in `server.conf`; internal flow control	Y	Y
Pipeline control	Throughput throttling	Limits data-processing or forwarding throughput where an applicable limit is configured.	`[thruput]` settings in `limits.conf`	Y	Y
Post-index management	Hot-to-warm bucket rolling	Closes and rolls hot buckets to warm based on size, time, count or restart conditions.	`indexes.conf`	N	Y
Post-index management	Retention and bucket ageing	Moves buckets through warm, cold, frozen and optional thawed states according to retention and storage policy.	`indexes.conf`, archive scripts, SmartStore settings	N	Y

Reference · Scoring tools

Assessment methodologies

Purpose, inputs, outputs and interpretation for each scoring tool.

Log Onboarding Viability

Determines whether engineering should proceed and how complex the engagement is likely to be.

Security value
Technical readiness
Operational assurance
Engagement complexity

Timestamp Quality

Scores consistency, timezone, precision, completeness, event-time reliability and Splunk parsing complexity.

Six criteria scored 0–4
Total score out of 24
Exceptional to Fail rating

Log Format Quality

Measures how consistently and reliably events can be separated, parsed and normalised.

Structure and delimiters
Schema and event boundaries
Encoding and parsing complexity

Investigative Context Density (ICD)

Measures the breadth of distinct investigative context types present across individual events and a representative file.

Distinct context types per event
Average ICD across the file
Signal, noise and minimum-threshold compliance

Context Dimension Coverage (CDC)

Measures how many of the seven investigative context dimensions are represented in each event and across a representative file.

When, Who, Where, What, Outcome, Impact and Correlation
Average dimensions and average CDC for the file
Minimum-threshold compliance and noise percentage

Investigative Noise Percentage (INP)

Measures the proportion of valid events that fail an approved minimum investigative-value threshold.

Noise and signal event counts
Noise percentage and signal percentage
Configurable metric, threshold and comparison rule

Identity Diversity (IDS)

Measures the breadth, quality and investigative usefulness of identities represented in a log source without rewarding repeated activity from the same identity.

Human, privileged, service, machine, application and federated identities
Identity-type breadth and population spread
Dominance, anonymity and identity-quality penalties
Score normalised to 0–100

Investigation Breadth (IBS)

Measures the range of investigative questions, entities, timelines and response paths supported by a log source.

Identity, asset and activity investigations
Timeline reconstruction, outcomes and impact analysis
Correlation and pivot-enabled investigation routes
Score normalised to 0–100 without rewarding repetition

Log Source Cyber Value

Measures incremental cyber value and value density after minimum data-quality gates pass.

Marginal novelty
Pivot density and breadth
Semantic value, entity coverage, identity diversity and investigation breadth
Detection Value: correlation, alerting, anomaly detection, threat hunting, control validation and triage usefulness
90-day realised-value review

Data Source Assurance

Measures whether an implemented source remains complete, healthy, governed and useful.

Collection health
Data quality
CIM and detection coverage
Ownership and evidence

Reference · Authoritative sources

Standards & references

Record the authoritative sources used to define local requirements and scoring.

Transport Delivery Patterns

Comparison reference for the four Transport Delivery Pattern (TAX-03.02.07) children -- positioning, best fit, use cases, strengths, risks, validation focus, and operational characteristics (timeliness, encryption, reliability, resilience, replay, provenance, change management) for each.

Event-Driven Delivery
Managed Retrieval or Polling
Local Buffering and Store-and-Forward
Direct Point-to-Point Integration

Splunk configuration and CIM

Use Splunk product documentation, Common Information Model guidance, validated add-on documentation and deployment requirements as implementation references.

Types of Search Commands

The six broad categorisations almost every SPL command falls into -- distributable streaming, centralized streaming, transforming, generating, orchestrating and dataset processing -- and why the distinction determines whether a search runs on the indexers or the search head.

Streaming vs. non-streaming
Processing-attribute comparison table
Worked pipeline example

Datetime Format

Defines the timestamp representation used by the source event, including the literal layout, date standard, precision, timezone expression and example value.

Raw timestamp example
Named standard or vendor format
Timezone and precision
Equivalent Splunk strptime pattern

Datetime Parse

Defines how Splunk locates, interprets and assigns event time for a sourcetype using timestamp parsing settings.

TIME_PREFIX
TIME_FORMAT
MAX_TIMESTAMP_LOOKAHEAD
TZ

Username / Principal Format

Catalogues how identity values appear across sources -- SAML NameIDs, cloud IAM identifiers, internet/messaging URIs, Windows/AD and Entra forms, database and directory identifiers, Kerberos principals and social/fediverse handles -- so a username-shaped field can be classified from its value.

37 formats across 13 categories
Template shape and detection regex
Formats sharing an identical regex (ambiguous by value alone)
Detector precedence order

Line Break

Defines how Splunk separates the incoming data stream into individual events for a sourcetype.

SHOULD_LINEMERGE
LINE_BREAKER
Single-line and multiline behaviour
Boundary validation

Field Extraction

Documents how a field is pulled from raw event data and, critically, at which pipeline stage -- search time or index time -- that extraction happens.

EXTRACT-* / REPORT-* / KV_MODE / DELIMS
INDEXED_EXTRACTIONS
Custom indexed fields (WRITE_META)
INGEST_EVAL

Field Normalisation

Documents how a sourcetype's extracted fields are mapped onto standard names, data types and common data models such as CIM or ECS.

CIM data model catalogue
FIELDALIAS-*, EVAL-*, LOOKUP-*
CIM compliance workflow
CIM vs. ECS mapping

Retention Policy

Documents the Splunk bucket lifecycle and indexes.conf settings that enforce a data source's approved retention period, plus what genuinely secure deletion requires.

Hot / warm / cold / frozen / thawed bucket lifecycle
maxHotSpanSecs, frozenTimePeriodInSecs, coldToFrozenDir
Deleted vs. archived on freeze
Secure deletion: bucket aging, delete, overwrite, physical destruction, encryption at rest

Access Control

Documents predefined and custom Splunk roles, the capability model, and how LDAP/SAML authentication maps external identities onto Splunk roles.

Predefined roles: admin, power, user, can_delete
authorize.conf: capabilities, importRoles, srchIndexesAllowed
LDAP / SAML group-to-role mapping
Mapping drift and review-cadence risk

File Monitoring Profile

A twelve-branch checklist for the file-level mechanics of a monitor:// or batch:// input -- identification, lifecycle, access, characteristics, size, parsing, collection behaviour, identity/duplicate handling, metadata, security and assurance.

File lifecycle, access & locking, filesystem
CRC / Fishbucket identity & duplicate-ingestion risk
File size vs. event size, assessed separately
Mapped against both the Onboard and Splunk Taxonomies

REST API Collection Profile

A twelve-branch checklist for a Splunk collector that polls a REST API -- endpoint identification, authentication, request construction, pagination, polling/checkpointing, rate limiting, response handling, reliability, identity/duplicate handling, metadata, security and assurance.

OAuth / API key / certificate authentication
Pagination, rate limiting & checkpoint state
Companion to the File Monitoring Profile
Mapped against both the Onboard and Splunk Taxonomies

Line Length

Measures whether event sizes are safe, consistent and suitable for Splunk ingestion without truncation or accidental merging.

TRUNCATE sizing
UTF-8 byte length analysis
Boundary-integrity checks
Line Length Quality Score

Log Format Detection & Parsing

Defines how Splunk interprets CSV, TSV, JSON, XML, structured, semi-structured and unstructured events after line breaking and timestamp recognition.

Format detection
Index-time versus search-time extraction
props.conf
Optional transforms.conf

Log Assessment Framework

Reusable line-by-line and event-level procedure for deriving structural conformance from a raw log file using a self-calibrating majority baseline, feeding Timestamp Quality, Log Format Quality and the pre-ingest schema-stability gate.

Physical line vs logical event
Per-line dimension extraction
Majority baseline & conformance scoring, reported by percentage, bytes and event count
Structural fingerprinting -- count distinct record types
Common pitfalls checklist

Exploratory Data Analysis & Field Correlation Playbook

A full fourteen-phase, source-agnostic procedure for onboarding and investigating an undocumented source -- parse health, profiling, data quality, temporal rhythm, correlation, outliers, entity discovery, field relationships, CIM readiness, sensitive-data exposure, enrichment validation, and value-space blind correlation for when field names can't be trusted at all.

Parse health, source profiling & data quality scorecards
Temporal, correlation & outlier analysis
Entity discovery, field relationships & CIM readiness
Sensitive-data discovery, enrichment validation & blind correlation
Quick reference, onboarding template & detection-readiness checklist

Security and logging obligations

Map applicable organisational policy, ACSC guidance, ISM controls, incident-response requirements and retention obligations to TAX-02 and TAX-05 records.

Local scoring rubrics

Assessment thresholds and weights must carry a rubric version, owner, approval status, calibration date and evidence source. Locally defined scoring should not be presented as an external standard.

Reference · Splunk platform configuration

Configuration file reference

Stanzas and settings for individual Splunk .conf files, mapped onto the Splunk Taxonomy objects they configure.

Agent Management Configuration

The helper-process stanzas agent_management.conf uses to run agent management -- agent status searches, splunkd calls, effective configuration and its database.

Agent status searches
Effective configuration limits and cleanup
Database refresh, pruning and ingestion

Alert Actions Configuration

The global alert-action defaults alert_actions.conf defines -- email, RSS, script, lookup, summary index, webhook, and custom alert actions -- overridden per saved search via action.<name>.* settings in savedsearches.conf.

[email] SMTP, TLS & PDF rendering settings
allowedDomainList & webhook allowlist.<name> hardening
[script], [lookup] & [summary_index] actions
Worked alert_actions.conf example

App Configuration

The per-app app.conf stanzas covering identity/launcher metadata, install/upgrade behaviour, custom-conf reload triggers, UI visibility, search head cluster deployment mode, and legacy credential verification.

[install] state, build & upgrade settings
[triggers] conf-level & stanza-level reload
[shclustering] deployer push modes
Worked app.conf example

Audit Trail Configuration

The [auditTrail] and [auditconfig:/path] stanzas audit.conf uses to route audit events into the index pipeline, choose the audittrail log format, and control which REST-path audit actions are logged, including sampling.

queueing & logging_format (v1/v2/both)
Per-path enabled/disabled audit action control
sampling.<action> & protected-action enforcement
Worked audit.conf example

Authentication Configuration

Every authentication mechanism authentication.conf configures -- native password policy, LDAP, scripted auth, SAML SSO, ProxySSO, Duo/RSA multifactor authentication, OAuth2 token validation, and secret storage.

LDAP directory & group-mapping settings
SAML signing, security & role-mapping mechanics
Duo/RSA MFA & OAuth2 external IdP configuration
Worked authentication.conf example

Authentication Node Configuration

The [client_<id>] stanzas authentication_node.conf uses to define this node's OAuth2 internal clients.

Grant types, scopes and redirect URIs
JWKS keys for signed client assertions
Roles granted to the client

Authorization Configuration

The role and capability catalog authorize.conf defines -- capability grants, search filtering, search-time/resource quotas, index access control, federated search & KV Store permissions, and deployment-wide token authorization settings.

[role_<roleName>] capability grants & importRoles
srchFilter, srchIndexesAllowed/Default/Disallowed
srchTimeWin, srchJobsQuota & other resource limits
Worked authorize.conf example

Custom Search Commands Configuration

The [<STANZA_NAME>] stanzas commands.conf uses to register a custom SPL command -- its script, streaming/execution-model characteristics, and chunked-protocol limits.

streaming/generating/retainsevents execution model
chunked protocol & its restricted setting list
required_fields & maxinputs/perf_warn_limit
Worked commands.conf example

Data Inputs Configuration

The stanzas and settings inputs.conf accepts -- global defaults, file & directory monitoring, network inputs, scripted/HEC inputs, and Windows inputs -- mapped onto the corresponding Splunk Taxonomy objects.

[monitor://] / [batch://] file inputs
[tcp://] / [udp://] network inputs
[script://] and HEC [http://<token>]
Worked inputs.conf example

Data Models Configuration

The [<datamodel_name>] stanzas datamodels.conf uses to configure automatic acceleration -- retention/backfill window, scheduling & workload, cross-instance summary sharing -- plus dataset-editor internals and search-time defaults.

acceleration.earliest_time/backfill_time retention
acceleration.cron_schedule, allow_skew & schedule_priority
acceleration.source_guid cross-instance summary sharing
Worked datamodels.conf example

DB Connect Connection Types Configuration

The JDBC driver template stanzas db_connection_types.conf accepts -- driver class, connection URL formats, and pooling defaults -- that a named Database Connection selects from, rather than restating.

jdbcUrlFormat & serviceClass
HikariCP-based connection pooling settings
deprecated connection-type lifecycle
Worked db_connection_types.conf example

DB Connect Database Inputs Configuration

The stanzas and settings db_inputs.conf accepts -- scheduling, connection & query, rising-mode checkpointing, and timestamp handling -- for the Splunk DB Connect app-specific input file, distinct from core inputs.conf.

connection, mode, query settings
Rising-mode checkpoint columns
index_time_mode & timestamp parsing
Worked db_inputs.conf example

DB Connect Database Outputs Configuration

The stanzas and settings db_outputs.conf accepts -- search source, target table & upsert behaviour, and timeouts/retry -- for the Splunk DB Connect app-specific output file, distinct from core outputs.conf forwarding.

search, table_name, using_upsert settings
customized_mappings field-to-column mapping
retry_attempts & retry_delay
Worked db_outputs.conf example

DB Connect Identities Configuration

The stanzas and settings identities.conf accepts -- credential storage, CyberArk integration, and HashiCorp Vault integration -- kept separately from Splunk's core passwords.conf.

identity_type: normal / CyberArk / HashiCorp / token
CyberArk Safe & Central Credential Provider settings
HashiCorp Vault secrets engine settings
Worked identities.conf example

DB Connect Settings Configuration

The instance-wide operational stanzas dbx_settings.conf accepts -- Java runtime, per-component log levels, HEC delivery tuning, and security/synchronization -- generated by DB Connect itself, not meant for direct editing.

[loglevel] per-component logging
[hec] retry & delivery tuning
[security] denylist & [synchronizer]
Worked dbx_settings.conf example

Deployment Client Configuration

The client-side counterpart to serverclass.conf -- how deploymentclient.conf points an instance at a Deployment Server and controls polling frequency, content location, and endpoint delivery policy.

repositoryLocation & server-location trust policy
Phone-home, handshake & resync timing
SSL/TLS settings with server.conf fallback
Worked deploymentclient.conf example

Distributed Search Configuration

The [distributedSearch]/[replicationSettings] stanzas distsearch.conf uses to configure search peers, distributed-search key pairs, and knowledge bundle replication -- classic, cascading, RFS, or mounted.

servers/disabled_servers/quarantined_servers peer lists
replicationPolicy: classic, cascading, rfs, mounted
replicationAllowlist/Denylist & bundle enforcer lists
Worked distsearch.conf example

Event Types Configuration

The eventtypes.conf settings for named, search-based event classifications applied at search time -- including the field-substitution template naming pattern and why event types shouldn't reference a report.

search restrictions (no pipe, subsearch, or report reference)
%field% template stanza naming
priority & the fixed color palette
Worked eventtypes.conf example

Federated Search Configuration

The [provider://<name>] and [general] stanzas federated.conf uses to register remote federated providers and tune heartbeat monitoring, RBAC, search optimization, and blocked SPL commands for federated search.

mode: standard vs. transparent & knowledge-object sourcing
fedSrchIndexesAllowed index-based provider filtering
[s2s_*_unsupported_command:<cmd>] command blocking
Worked federated.conf example

Field Filters Configuration

The [<fieldFilterName>] stanzas field_filters.conf uses to remove, hash or replace sensitive field values at search time.

null(), sha256(), sha512(), sed() actions
Scoping by index, host, source or sourcetype
Caution for Enterprise Security

Fields Configuration

The fields.conf settings for multivalue tokenization and index-time vs. raw-text field behaviour, including metadata-scoped wildcard stanzas for bulk-indexing structured-data fields.

TOKENIZER multivalue field extraction
INDEXED/INDEXED_VALUE and the LISPY substitution form
Metadata-scoped wildcard stanzas (sourcetype::...::data*)
Worked fields.conf example

Forwarder Outputs Configuration

The stanzas and settings outputs.conf accepts -- global defaults, named forwarding groups, the servers listed inside a group, and syslog-format output -- mapped onto the four corresponding Splunk Taxonomy objects.

[tcpout] global defaults
[tcpout:<group>] and server=
[syslog:<name>] settings
Worked outputs.conf example

Global Banner Configuration

The single [BANNER_MESSAGE_SINGLETON] stanza global-banner.conf uses to show a banner across Splunk Web.

One banner only
Message, colour and optional link

Indexes Configuration

The global, per-index, volume, and remote-storage stanzas indexes.conf uses to configure Splunk's indexes -- storage paths, bucket rolling & retention, freezing/archiving, shared volumes, SmartStore, and metric indexes.

homePath/coldPath/thawedPath & bucket lifecycle
[volume:<name>] & remote-storage-enabled indexes
datatype = metric metric index settings
Worked indexes.conf example

Instance Configuration

The single [general]/guid setting instance.cfg holds -- the instance's unique GUID, generated at first startup and explicitly not meant to be hand-edited.

Auto-generated all-uppercase GUID
server.conf/instance.cfg GUID reconciliation at startup
splunk clone-prep-clear-config for mass-cloned installs
Worked instance.cfg example

KV Store Collections Configuration

The [<collection-name>] stanzas collections.conf uses to define a KV Store collection's field typing, acceleration indexes, replication, and profiling.

field.<name> typing & enforceTypes
accelerated_fields.<name> compound acceleration
replicate & replication dump strategy
Worked collections.conf example

Metadata Permissions Configuration

The ownership, access control and export settings each app keeps for itself and its objects, in metadata/default.meta and local.meta.

App, category and object layers
Read vs. write access by role
Exporting objects to all apps

Metric Alerts Configuration

The [<alert_name>] stanzas metric_alerts.conf uses to alert on conditions in metric indexes.

Metric indexes, filter and group-by
Condition and trigger thresholds
Suppression and alert actions

Metric Rollups Configuration

The [index:<Metric Index Name>] rollup policies metric_rollups.conf uses to summarise metric data into other indexes.

Default and per-metric aggregation
Dimension and metric allow/deny lists
Rollup span and target index

Monitoring Console Checklist Configuration

The [<uniq-check-item-name>] stanzas checklist.conf uses to define Monitoring Console health checks.

Required title, category and search
Failure text, suggested action and drilldown
Group and environment targeting

Multikv Configuration

The [<multikv_config_name>] stanzas multikv.conf uses to split table-like output into events.

pre, header, body and post sections
Section definition and processing

Passwords Configuration

The single [credential:<realm>:<username>:] stanza passwords.conf uses to store an encrypted secret -- a file that doesn't even exist until the first credential is stored via the REST endpoint.

No shipped default file
Realm-scoped vs. realm-less credentials
Always-encrypted-on-save behaviour
Worked passwords.conf example

Process Monitor Filters Configuration

The deprecated filter stanzas procmon-filters.conf used to choose which Windows processes to monitor.

Deprecated
Process image and event type regexes

Props Configuration

The central per-sourcetype/source/host processing file props.conf covers -- line breaking, encoding, timestamp extraction, structured data parsing, index-time and search-time field extraction, masking, segmentation, and sourcetype classification learning.

[<spec>] stanza precedence & collision resolution
TRANSFORMS/REPORT/EXTRACT field extraction
FIELDALIAS, EVAL, LOOKUP, SEDCMD
Worked props.conf example

Saved Searches Configuration

Every Report and Alert setting savedsearches.conf accepts -- scheduling, workload management, the five alert-action namespaces, dispatch/durable-search options, auto-summarization, alert suppression, and UI display formatting.

Scheduling: cron, skew, priority & workload pools
Email/script/lookup/summary-index/populate-lookup actions
Durable search & auto-summarization tuning
Worked savedsearches.conf example

Segmenters Configuration

The [<SegmenterName>] stanzas segmenters.conf uses to set the breakers that divide events into indexed segments.

MAJOR and MINOR breakers
Length and count limits
Must match across search heads and peers

Server Class Configuration

The three-level [global] → [serverClass:<name>] → [serverClass:<name>:app:<appName>] hierarchy serverclass.conf uses to decide which deployment clients get which apps -- and the atomic-override pitfalls that trip up filter changes at a child level.

filterType whitelist/blacklist truth tables
Atomic override: whitelist/blacklist pairs & machineTypesFilter
Allow/deny list import from a CSV file
Worked serverclass.conf example

Source Classifier Configuration

The two keyword lists source-classifier.conf uses to tune how Splunk learns and matches source types.

Terms ignored in sourcetype models
Terms ignored when matching source names

Sourcetype Classification Models

The machine-generated sourcetypes.conf document models Splunk's file classifier uses to auto-recognize new files -- and the only two attributes (_sourcetype, _source) actually meant to be hand-edited.

Per-file learning-example stanzas
Which attributes are safe to edit vs. opaque
Distinct from the technical sourcetype definition (props.conf)
Worked sourcetypes.conf example

Splunk Launch Configuration

The startup environment variables in splunk-launch.conf -- one file per installation, no stanzas.

SPLUNK_HOME, SPLUNK_DB, SPLUNK_OS_USER
Only $SPLUNK_HOME/etc/splunk-launch.conf is read

Splunk Web Configuration

The web.conf settings behind Splunk Web itself -- HTTPS/TLS, host/origin allow-listing, insecure-toggle hardening, dashboard HTML/PDF sandboxing, CORS, ProxySSO header-based SSO, session timeout, login-page branding, and custom REST endpoint registration.

allowedSplunkWebClientNetlocList host/origin validation
SSOMode/trustedIP/remoteUser/remoteGroups
dashboard_html_injection_mode XSS hardening
Worked web.conf example

Tags Configuration

The two-level [<fieldname>=<value>] stanza and <tag> = enabled|disabled setting tags.conf uses to attach one or more named tags to a specific field/value pair.

One field/value pair per stanza
Multiple tags per stanza, one per line
Enabling vs. explicitly disabling a tag
Worked tags.conf example
CIM tag names by data model

Time Ranges Configuration

The [<timerange_name>] and [settings] stanzas times.conf uses to define time range presets and the time picker's panels.

Custom presets with earliest/latest time
Sort order and hiding
Showing or hiding picker panels

Transaction Types Configuration

The [<TRANSACTIONTYPE>] stanzas transactiontypes.conf uses to define reusable transaction types for the transaction command.

Grouping fields and start/end conditions
Span, pause and event limits
Memory limits and evicted transactions

Transforms Configuration

The multi-purpose stanzas transforms.conf accepts -- index-time and search-time field extraction, host/source/index routing, sensitive-data masking, lookup table definitions, and log-to-metrics conversion -- almost always invoked by a matching props.conf setting.

REGEX/FORMAT, index-time vs. search-time settings
DEST_KEY/SOURCE_KEY and the full KEYS reference
Lookup table settings: temporal, KV Store, external
Worked transforms.conf example

User Preferences Configuration

The per-user Splunk Web preference settings user-prefs.conf accepts -- default app, timezone, language, search-bar behavior, and theme -- plus deployment-wide and role-scoped defaults.

default_namespace, tz, lang per-user settings
[general_default] deployment-wide defaults
[role_<name>] role-scoped defaults & precedence
Worked user-prefs.conf example

User Seed Configuration

The [user_info] stanza user-seed.conf uses to create Splunk's initial user.

HASHED_PASSWORD vs. PASSWORD
Ignored once etc/passwd exists

Web Feature Flag Configuration

The [feature:<name>] stanzas web-features.conf uses to toggle Splunk Web UI capabilities -- dashboard CSP/trusted domains, Dashboard Studio internals, React page-migration flags, and app-server hardening.

Dashboards Trusted Domains List & CSP restriction
enable_<area>_vnext React page-migration flags
appserver_security Mako/CherryPy hardening
Worked web-features.conf example

WMI Inputs Configuration

The [settings] and [WMI:<name>] stanzas wmi.conf uses to collect Windows Event Log channels and WMI provider data from Windows servers.

Windows only
Event Log channels or a WQL query per input
Retry backoff and checkpointing

Workflow Actions Configuration

The link/search action types and field-value substitution syntax workflow_actions.conf uses to attach clickable event/field actions in search results.

$field$ and $@field_name$ / $@field_value$ substitution
link.uri/link.postargs GET & POST construction
search.search_string follow-up search construction
Worked workflow_actions.conf example

Workload Policy Configuration

The single [search_admission_control] setting in workload_policy.conf that turns admission rules on or off.

admission_rules_enabled
Works with workload rules

Workload Pools Configuration

The [general], [workload_category:…] and [workload_pool:…] stanzas workload_pools.conf uses to divide CPU and memory for workload management.

Turning workload management on
Category and pool CPU/memory weights
Default and ingest pools

Workload Rules Configuration

The [workload_rule:…] and [search_filter_rule:…] stanzas workload_rules.conf uses to place searches in pools and to filter or queue them.

Predicates on app, role, user, index and more
Alert, move or abort long-running searches
Admission rules: filter or queue

Server Configuration

Core instance-level settings server.conf defines -- general instance identity, TLS for backend (non-Web) communications, and clustering/license coordination. Distinct from web.conf, which configures Splunk Web/browser-facing settings.

All 87 stanzas and 755 settings from the Splunk 10.4.2 spec
[general] serverName & pass4SymmKey
[sslConfig] enableSplunkdSSL (mgmt port 8089 / KV Store 8191)
[clustering]/[shclustering]/[license]/[kvstore] stanzas
Worked server.conf example

Search Limits Configuration

Resource and behavior caps limits.conf applies to search commands and other bounded Splunk operations, organized as one stanza per feature area.

All 110 stanzas and 645 settings from the Splunk 10.4.2 spec
[searchresults] maxresultrows (event-generating command result cap)
[search] dispatch_dir_warning_size
Worked limits.conf example

Search Macros Configuration

Reusable search-language macros macros.conf defines -- the stanza name encodes the macro name and, in parentheses, its argument count.

args, definition & $arg$ substitution
validation & errormsg eval-based argument checking
iseval -- definition evaluated as eval, not literal SPL
Worked macros.conf example

REST Endpoints Configuration

Registers REST endpoints restmap.conf uses -- the [script:<uniqueName>] stanza binds a URI to a handler; [admin:<name>]/[admin_external:<name>] register admin-config endpoints.

All 15 stanzas and 66 settings from the Splunk 10.4.2 spec
[global], [script:<uniqueName>] stanzas
scripttype: python (default) or persist
python.required (replaces the deprecated python.version)
Worked restmap.conf example

Health Report Configuration

Thresholds health.conf sets for Splunk's built-in Health Report -- feature stanzas group indicators, each with a Yellow (investigate) and Red (broken) threshold.

All 7 stanzas and 35 settings from the Splunk 10.4.2 spec
distributed_disabled (hide from the distributed health report)
alert.disabled per-feature alerting toggle
Per-indicator thresholds: indicator:<name>:yellow/:red in [feature:<name>]

Internal Logging Configuration

Governs Splunk's own internal logging verbosity via log.cfg -- the one file in this reference that lives at a fixed path rather than the standard system/{default,local} layering every other file here uses.

[python] stanza: hierarchical component log levels
log.cfg (shipped) vs. log-local.cfg (persistent override)
Sibling files: log-btool.cfg, log-searchprocess.cfg & others
Worked log.cfg example

Network reference

Splunk Ports

What is a Default Port? A port is considered to be default when the software sets it automatically, when the community uses it as a default, and when admins cannot change the port. Essentially, these are all the possible ways to define a default port, even though they are all very different. Three labels are used in the Type column below: Default -- the port is set without the user specifying it (e.g. Splunk Web on-prem runs on port 8000 by default -- the user does not choose it, but can change it if they wish). Convention -- ports used so often that they feel like default ports; the admin sets the port and can select any other one (e.g. the Splunk forwarding port of 9997 is not a default for Splunk Enterprise, yet almost every environment uses it). Default -- Immutable -- a default port the user cannot modify, found mostly in managed services such as Splunk Cloud.

What is a Port in Splunk? In Splunk, ports are communication endpoints. When processes or applications exchange information over a network, they use a port to segment the data. Unless a row below states otherwise, ports refer specifically to the Transmission Control Protocol (TCP) communications standard.

45 visible ports 4 Splunk products

Port(s)	Product	Component	Type	Description

Disclaimer: The ports above are current as of May 2024. Most of these ports have been static through the years but may change to support new services and offerings. It is essential to regularly review the Splunk documentation and consult with your organization's Splunk Administrator for the most up-to-date information on network ports and their usage in your environment.

Network reference

Network Flow Matrix

A Splunk network source-to-destination matrix suitable as the basis for firewall rules, architecture documentation, or a Splunk network taxonomy -- who initiates a connection to whom, over which protocol and port, and why. Complements the Splunk ports table: ports lists what each component listens on; this matrix lists the actual flows between components.

Important: ports such as 9997, 8088, 8089, 8000 and 9887 are common/default Splunk ports, but most can be changed. Treat this as a reference architecture and validate the configured ports on each Splunk environment.

91 visible flows 11 architecture sections

Section	Source	Destination	Protocol	Port	Purpose

Operational notes

The Indexer cluster peer-to-peer bucket-replication port and the Search Head Cluster artifact-replication port are both selected/configured per environment -- 9887 is a common convention, not a guaranteed default; confirm the configured value before writing a firewall rule.
A stateful firewall for Deployment Server normally only needs the deployment client → Deployment Server connection initiated on TCP 8089; the return traffic does not need its own rule.
For Splunk Cloud, use the stack-specific allowlist/endpoints Splunk provides rather than building firewall rules solely from generic port numbers.
Splunk Enterprise Security does not require its own network tier -- it runs on the search head / search head cluster; the ES rows above are its external integrations (SOAR, threat intelligence, TAXII, enrichment APIs).
Ingest Processor / Edge ingestion is a modern, largely Splunk Cloud-managed architecture whose exact data-plane connections vary considerably by the specific ingestion product in use.

Consolidated flow overview (ASCII diagram)

ENDPOINT / SERVER
     |
     | TCP/TLS 9997
     v
UNIVERSAL FORWARDER
     |
     +------------------ TCP/TLS 9997 ------------------+
     |                                                   |
     v                                                   v
HEAVY FORWARDER                                      INDEXER
     |                                                   ^
     | TCP/TLS 9997                                      |
     +----------------------------------------------------+
UF / HF
 |
 | HTTPS 8089
 v
DEPLOYMENT SERVER

APPLICATION / API / FUNCTION
 |
 | HTTPS 8088 / 443
 v
HEC
 |
 v
INDEXER

SEARCH HEAD
 |
 | HTTPS 8089
 v
INDEXERS

CLUSTER MANAGER
 |
 | HTTPS 8089
 v
INDEXER PEERS

INDEXER PEER
 |
 | TCP/TLS replication port (commonly 9887)
 v
INDEXER PEER

SEARCH HEAD CLUSTER MEMBER
 |
 | 8089 + configured replication port
 v
SEARCH HEAD CLUSTER MEMBER

USER
 |
 | HTTPS 443
 v
LOAD BALANCER
 |
 | HTTPS / configured Splunk Web port
 v
SEARCH HEAD

SPLUNK ES
 |
 +---- HTTPS 443 ----> SOAR
 +---- HTTPS 443 ----> TAXII
 +---- HTTPS 443 ----> Threat Intelligence
 +---- HTTPS 443 ----> Enrichment APIs

SOURCE SYSTEM
 |
 | HTTPS 443
 v
INGEST PROCESSOR
 |
 +----> SPLUNK CLOUD
 |
 +----> AWS S3

Access & Capability reference

Roles & Assigned Capabilities

Every Splunk role and the individual capabilities assigned to it, derived from the uploaded role/capability matrix. Click a role below, or use search and the filters, to see exactly which capabilities a role carries, what each capability lets you do, whether it is flagged as a privileged capability, and where the mapping came from.

Pick two roles to see which capabilities only one of them has and which they share.

Role A Role B

Pick two different roles to compare.

Import existing roles, add the extra capabilities you need, and copy the resulting authorize.conf stanza.

Role name Lowercase letters, numbers, underscores and hyphens.

Import roles (inherits all of their capabilities)

Indexes allowed srchIndexesAllowed, semicolon-separated Default indexes srchIndexesDefault

Capabilities to add (inherited ones are ticked and locked)

Paste or load an authorize.conf to check its roles against the reference matrix: each role's full capabilities including importRoles, unknown capability names, imports that don't resolve, capabilities disabled with no effect, missing prerequisites, and the closest built-in role. Nothing leaves your browser and nothing is saved.

Load a file

580 visible assignments 21 roles with capabilities

Role	Platform	Capability	Granted how	What it lets you do	Priv	Source / Notes

The search and filters above choose which capabilities appear. The Platform filter also limits the role columns, and the Role filter highlights that role's column. Hover a capability for its description.

Capabilities no built-in role has by default (0)

These are in Splunk Enterprise 10.4.2's authorize.conf.spec, but its shipped default authorize.conf doesn't give them to user, power, admin or can_delete. Some go only to an internal system role. Grant them through a custom role -- they're available in Build a custom role.

Capability	What it lets you do	Default grant

About this data

Splunk Enterprise 10.4.2 capabilities: 26 capabilities the supplied tables didn't include were added from authorize.conf.spec (descriptions) and the shipped default authorize.conf (which roles hold them), both version 10.4.2, taken from the jewnix/splunk-spec-files mirror. That added the built-in can_delete role, which holds only delete_by_keyword. The mirror doesn't say which OS package the defaults come from.

Note: the source file also lists three roles with no capabilities assigned in this matrix -- mc_analyst, mc_analyst_reader, mc_soar_automation -- they carry nothing to list in the table below and so do not appear in the Role filter.

Platform: derived from each role's naming convention and the source file's Mission Control Roles tab -- Sc_admin is Splunk Cloud-specific; User/Power/Admin are the base roles (shown as Splunk On-premises, since Sc_admin is the file's distinct Splunk Cloud counterpart to Admin); ess_* and the non-SOAR mc_* Mission Control/incident-review roles are Splunk ES; the mc_soar_* roles are Splunk SOAR.

Granted how: whether a role adds a capability itself or inherits it through importRoles. This follows Splunk Enterprise's shipped authorize.conf, where power imports user and admin imports power and user, so it's recorded for User, Power and Admin only. No inheritance data is held for Sc_admin, ES, SOAR or Mission Control roles, so their capabilities show "Not recorded".

Operational reference

Splunk bin CLI Commands

The full splunk command-line verb catalogue, run from the platform's bin/ directory.

Note: commands shown with a placeholder in angle brackets (for example <name>) require a real value substituted in; run with -auth <user>:<password> or an active login session as appropriate for the instance.

Complete CLI command reference (all verbs & objects)

Every top-level splunk command, the objects it operates on, and worked examples. Each example command has a Copy button; a command name is a link you can share.

Command	Objects	Examples
`add`	exec, forward-server, index, licenser-pools, licenses, manager, monitor, oneshot, saved-search, search-server, tcp, udp, user	1. Adds monitor directory and file inputs to source /var/log. `./splunk add monitor /var/log/` 2. Adds another indexer cluster manager node to the list of instances the search head searches across. `./splunk add cluster-manager https://127.0.0.1:8089 -secret testsecret -multisite false`
`anonymize`	source	1. Replaces identifying data, such as usernames and IP addresses, in the file located at /tmp/messages. `./splunk anonymize file -source /tmp/messages` 2. Anonymizes Mynames.txt using name-terms, a file containing a list of common English personal names. `./splunk anonymize file -source /tmp/messages -name_terms $SPLUNK_HOME/bin/Mynames.txt`
`apply`	cluster-bundle, shcluster-bundle	1. Makes validated bundle active on peers. `./splunk apply cluster-bundle` 2. Skip-validation is an optional argument to skip bundle validation on the indexer cluster manager and peers. `./splunk apply cluster-bundle --skip-validation` 3. For shcluster-bundle examples, see Deploy a configuration bundle in the Distributed Search manual.
`check-integrity`	NONE	1. Verifies the integrity of an index with the optional parameter verbose. `./splunk check-integrity -index $SPLUNK_HOME/var/lib/splunk/defaultdb/ [-<verbose>]` 2. Verifies the integrity of a bucket with the optional parameter verbose. `./splunk check-integrity -bucketPath $SPLUNK_HOME/var/lib/splunk/defaultdb/db/ [-<verbose>]`
`clean`	all, eventdata, globaldata, inputdata, userdata, kvstore	1. Removes data from Splunk installation. eventdata refers to exported events indexed as raw log files. `./splunk clean eventdata` 2. globaldata refers to host tags and source type aliases. `./splunk clean globaldata`
`cluster-manager-redundancy`	NONE	1. Shows status of all the cluster managers in redundancy mode. `./splunk cluster-manager-redundancy -show-status` 2. Switches HA mode of a cluster manager from standby to active. `./splunk cluster-manager-redundancy -switch-mode active` 3. Switches HA mode of a cluster manager from active to standby. Consequently, another, currently standby cluster manager gets switched to active automatically. `./splunk cluster-manager-redundancy -switch-mode standby`
`cmd`	btprobe, classify, locktest, locktool, pcregextest, searchtest, signtool, toCsv, toSrs, tsidxprobe, walklex	1. Displays the contents in the $SPLUNK_HOME/bin directory. `./splunk cmd /bin/ls` 2. Runs the chosen command from the $SPLUNK_HOME/bin directory with the environment variables set. Run `splunk envvars` to see which environment variables are set. `./splunk cmd locktest`
`create`	app	1. Builds myNewApp from a template. `./splunk create app myNewApp -template sample_app`
`createssl`	NONE	—
`diag`	NONE	—
`disable`	app, boot-start, deploy-client, deploy-server, dist-search, index, listen, local-index, maintenance-mode, perfmon, webserver, web-ssl, wmi	1. Disables the maintenance mode on peers in indexer clustering. Must be invoked on the manager node. `./splunk disable maintenance-mode` 2. Disables the logs1 collection. `./splunk disable eventlog logs1`
`display`	app, boot-start, deploy-client, deploy-server, dist-search, jobs, listen, local-index	1. Displays status information, such as enabled/disabled, for all apps. `./splunk display app` 2. Displays status information for the unix app. `./splunk display app unix`
`edit`	app, cluster-config, shcluster-config, exec, index, licenser-localpeer, licenser-groups, monitor, saved-search, search-server, tcp, udp, user	1. Edits the current clustering configuration. `./splunk edit cluster-config -mode peer -site site2` 2. Edits monitored directory inputs in /var/log and only reads from the end of this file. `./splunk edit monitor /var/log -follow-only true`
`enable`	app, boot-start, deploy-client, deploy-server, dist-search, index, listen, local-index, maintenance-mode, perfmon, webserver, web-ssl, wmi	1. Sets the maintenance mode on peers in indexer clustering. Must be invoked on the manager node. `./splunk enable maintenance-mode` 2. Enables the col1 collection. `./splunk enable perfmon col1`
`export`	eventdata, user data	1. Exports data out of your Splunk server into /tmp/apache_raw_404_logs. `./splunk export eventdata -index my_apache_data -dir /tmp/apache_raw_404_logs -host localhost -terms "404 html"`
`fsck`	repair, scan, clear-bloomfilter	—
`help`	NONE	—
`import`	userdata	1. Imports user accounts data from directory /tmp/export.dat. `./splunk import userdata -dir /tmp/export.dat`
`install`	app	1. Installs the app from foo.tar to the local Splunk server. `./splunk install app foo.tar` 2. Installs the app from foo.tgz to the local Splunk server. `./splunk install app foo.tgz`
`list`	cluster-buckets, cluster-config, cluster-generation, cluster-peers, deploy-clients, excess-buckets, exec, forward-server, index, inputstatus, licenser-groups, licenser-localpeer, licenser-messages, licenser-pools, licenser-peers, licenser-stacks, licenses, jobs, manager-info, monitor, peer-info, peer-buckets, perfmon, saved-search, search-server, tcp, udp, user, wmi	1. Lists all active monitored directory and file inputs. This displays files and directories currently or recently monitored by splunkd for change. `./splunk list monitor` 2. Lists all licenses across all stacks. `./splunk list licenses`
`login`, `logout`	NONE	—
`migrate`	kvstore-storage-engine	1. Migrates the KV store to the target storage engine. `./splunk migrate kvstore-storage-engine --target-engine wiredTiger`
`offline`	NONE	1. Used to shut down the peer in a way that does not affect existing searches. The manager node rearranges the primary peers for buckets, and fixes up the cluster state in case the enforce-counts flag is set. `./splunk offline` 2. Because the --enforce-counts flag is used, the cluster is completely fixed up before this peer is taken down. `./splunk offline --enforce-counts`
`package`	app	1. Packages the app "stubby" and returns the package location. `./splunk package app stubby` The package command includes local.meta by default. If your app package already contains local.meta, this fails AppInspect app validation -- use -merge-local-meta or -exclude-local-meta to avoid it. 2. When packaging the app, merges local.meta to default.meta and packages the resulting default.meta. `./splunk package app stubby -merge-local-meta true` 3. When packaging the app, excludes local.meta from the app package. `./splunk package app stubby -exclude-local-meta true`
`rebalance`	cluster-data	1. Rebalances data for all indexes. `./splunk rebalance cluster-data -action start` 2. Rebalances data for a single index using the optional -index parameter. `./splunk rebalance cluster-data -action start -index _internal` 3. Rebalances data using the optional -max_runtime parameter to limit the rebalancing activity to 5 minutes. `./splunk rebalance cluster-data -action start -max_runtime 5`
`rebuild`	NONE	—
`reload`	ad, auth, deploy-server, exec, index, listen, monitor, registry, tcp, udp, perfmon, wmi	1. Reloads your deployment server, in entirety or by server class. `./splunk reload deploy-server` 2. Reloads my_serverclass. `./splunk reload deploy-server -class my_serverclass` 3. Reloads a specific index configuration. To reload all indexes, do not include an index name. `./splunk reload index [index_name]`
`remove`	app, cluster-peers, cluster-manager, excess-buckets, exec, forward-server, index, jobs, licenser-pools, licenses, monitor, saved-search, search-server, tcp, udp, user	1. Removes the cluster manager node from the list of instances the search head searches across. Uses testsecret as the secret/pass4SymmKey. `./splunk remove cluster-manager https://127.0.0.1:8089 -secret testsecret` 2. Removes the Unix app. `./splunk remove app unix`
`rollback`	cluster-bundle	Rolls back your Splunk Web configuration bundle to your previous version. Run from the manager node: `./splunk rollback cluster-bundle`
`rolling-restart`	cluster-peers, shcluster-members	—
`rtsearch`	app, batch, detach, earliest_time, header, id, index_earliest, index_latest, max_time, maxout, output, preview, rt_id, timeout, uri, wrap	1. Runs a real-time search that does not line-wrap for individual lines. `./splunk rtsearch 'error' -wrap false` 2. Runs a real-time search. Use rtsearch exactly as you use the traditional search command. `./splunk rtsearch 'eventtype=webaccess error \| top clientip'`
`search`	app, batch, detach, earliest_time, header, id, index_earliest, index_latest, latest_time, max_time, maxout, output, preview, timeout, uri, wrap	1. Uses the wildcard as the search object. Triggers an asynchronous search and displays the job id and ttl for the search. `./splunk search '*' -detach true` 2. Uses eventtype=webaccess error as the search object. Does not line wrap for individual lines longer than the terminal width. `./splunk search 'eventtype=webaccess error' -wrap 0`
`set`	datastore-dir, deploy-poll, default-hostname, default-index, indexing-ready, minfreemb, servername, server-type, splunkd-port, web-port, kvstore-port	1. Sets the force indexing ready bit. `./splunk set indexing-ready` 2. Sets bologna:1234 as the deployment server to poll updates from. `./splunk set deploy-poll bologna:1234`
`show`	config, cluster-bundle-status, datastore-dir, deploy-poll, default-hostname, default-index, jobs, minfreemb, servername, splunkd-port, web-port, kvstore-port, kvstore-status, shcluster-kvmigration-status	1. Shows current logging levels. `./splunk show log-level` 2. Shows which deployment server Splunk Enterprise is configured to poll from. `./splunk show deploy-poll`
`spool`	NONE	—
`start-shcluster-migration`	kvstore	1. Migrate the KV store to the target storage engine in a clustered environment. `./splunk start-shcluster-migration kvstore -storageEngine wiredTiger` 2. Check to see if the KV store is ready to migrate to the target storage engine. `./splunk start-shcluster-migration kvstore -storageEngine wiredTiger -isDryRun`
`start`, `stop`, `restart`	splunkd, splunkweb	—
`status`	splunkd, splunkweb	Checks if splunkd is running and shows the PID.
`validate`	index, files, cluster-bundle	1. Validates the main index and verifies the index paths specified in indexes.conf. `./splunk validate index main` 2. For files examples, see Check the integrity of your Splunk software files. 3. For cluster-bundle examples, see Update common peer configurations and apps in the Managing Indexers and Clusters of Indexers manual.

Operational reference

Splunk timezone

To determine the time zone to assign to a timestamp in an event, Splunk uses this logic in order of precedence:

Time zone specified in the raw event data (if present)

Examples: PST, -0800, +0900, Z, or a full offset like -07:00. If the event’s timestamp includes an explicit time zone or offset, Splunk uses that.
2
TZ attribute in props.conf

Applied if the event matches the host, source, or sourcetype stanza that defines TZ. (Use a valid TZ database ID, e.g. America/Los_Angeles, UTC, Asia/Tokyo.)

Note on props.conf stanza precedence when multiple match:
1. source:: overrides
2. host:: overrides
3. sourcetype
Reference
Time zone provided by the forwarder

Applies if both the forwarder and the receiving indexer are version 6.0 or higher. The forwarder (Universal or Heavy) sends its local system time zone information with the data.
Time zone of the host that indexes the event

The system time zone of the indexer (or the receiving instance that performs indexing).

If multiple time zones are specified, Splunk always picks the one highest in the list above.

Additional notes

Timestamps are stored internally as UTC (Unix epoch) in the _time field. The time zone determined above is used only to correctly convert the event’s original timestamp into that UTC value.
Display of _time in the UI follows the user’s preferred time zone (set in the user profile), which is independent of the index-time time zone calculation.
Best practice: Prefer explicit time zones/offsets in the raw data whenever possible, or set a clear TZ in props.conf for sources that lack them. Many recommend running Splunk infrastructure itself in UTC to reduce confusion.

Official reference: Specify time zones for timestamps (Splunk Docs).

Assessment reference

Log assessment lifecycle & framework

End-to-end progression from raw log intake to governance approval, powered by the Log Assessment Framework. Select a lifecycle layer, an assessment domain or an output to see how they connect.

Lifecycle layers

LOG ASSESSMENT FRAMEWORK (Stage 3)Comprehensive analysis of raw logs across the assessment domains — select one

FRAMEWORK OUTPUTS FEED MULTIPLE AREAS

Terms key

🎯Collection / Intake
🔍Analysis / Assessment
⚙Engineering / Build
🛡Quality / Assurance
🏅Scoring / Value
🚀Implementation / Operations
📄Outputs / Deliverables

How the framework works

Legend

Framework domain
Lifecycle stage
Flow / progression
Feedback / feeds
Outputs

Stages, key terms and outputs

Stage	Stage label	Key terms / assessments (not exhaustive)	Key outputs

Domain numbering follows the source diagram, which numbers the domains 1–9 and 11 and leaves Line Analysis unnumbered (shown as “8?”). Which domains feed which output items is indicative.

Reference

Questions

Every question-form sentence extracted from logging-reference-architecture.md (the CISA Logging Reference Architecture, converted for AI processing), traceable back to the section it appears under, the taxonomy node it is most relevant to, and the onboarding phase it applies to. Sourced from questions.json in this repository -- an extensible catalogue additional questions can be appended to, regardless of source document.

0 visible questions 0 source sections

Section	Subsection	Question	Taxonomy	Onboarding Phase

Assessment centre

Logging Assessment Hub

Launch the scoring and assurance tools used across the SIEM onboarding lifecycle. Detailed assessment evidence remains linked to the relevant taxonomy records.

Available assessments

Log Onboarding Viability

Assesses security value, technical readiness, operational assurance and engagement complexity before engineering begins.

ScoreDecisionComplexity

Data Source Assurance

Measures onboarding completeness, health, CIM alignment, detection coverage and operational supportability.

AssuranceHealthCoverage

Timestamp Quality

Scores format consistency, timezone quality, precision, completeness, event-time reliability and Splunk parsing complexity.

0–24 scoreTAX-07.05

Log Format Quality

Scores structural consistency, delimitation, schema identification, event boundaries, encoding integrity and parsing complexity.

0–24 scoreTAX-07.06

Investigative Context Density

Calculates distinct investigative context types per event, average ICD for a file, threshold compliance and investigative noise percentage.

ICD %TAX-07.11Noise %

Context Dimension Coverage

Counts how many of the seven investigative dimensions each event covers, calculates the file average, and reports useful versus noise lines.

CDC %TAX-07.227 dimensions

Investigative Noise Percentage

Classifies event lines against a configurable minimum usefulness threshold and calculates investigative noise and signal percentages.

INP %TAX-07.23Signal vs noise

Log Source Cyber Value

Assesses incremental novelty, investigative pivots, semantic value, entity coverage and value relative to daily ingestion volume.

Decision supportTAX-06.0590-day review

Planned assessments

API Quality

Planned assessment for documentation, vendor support, authentication, pagination, stability, schema control and resilience.

Schema Quality

Planned assessment for schema availability, field stability, identifiers, data types, optionality and change control.

Collection Resilience

Planned assessment for retries, checkpointing, deduplication, failure recovery, alerting and operational ownership.

Assessment tools produce scores or ratings. Engineering utilities such as the Logging Pattern Advisor remain accessible from their relevant workflow pages.

Capacity planning

Splunk Index Sizing Calculator

Estimate index storage and, for on-premises deployments, indexer count from a daily ingest volume and retention period. Formulas follow Splunk's published guidance that indexed data compresses to roughly 50% of raw size (15% raw journal + 35% tsidx metadata) and the standard indexer-clustering storage multiplier for Replication Factor and Search Factor. Treat results as a planning estimate to sanity-check a design, not a vendor quote.

Deployment type

Index tier terminology and available inputs change depending on whether Splunk manages the indexing tier for you.

On-Premises index tiers: Hot → Warm → Cold → Frozen → Thawed. You configure and pay for storage across all of these yourself via indexes.conf (see the Retention Policy reference). Replication Factor and Search Factor determine how many copies of each bucket exist across your indexer cluster.

Compression assumptions

Splunk's published guidance -- 15% raw journal + 35% tsidx metadata, ~50% total -- is an average across all data. Real compression depends heavily on how repetitive and structured the source is; adjust the two percentages directly, or start from a typical-sourcetype preset and refine from your own sample data.

Typical sourcetype (optional preset)

Raw journal compression (% of raw ingest) tsidx metadata overhead (% of raw ingest)

These are illustrative starting points, not published Splunk figures for any specific sourcetype. Splunk does not publish per-sourcetype compression ratios -- actual compression depends on field cardinality, value repetition and event structure in your real data. Measure against a representative sample where the estimate materially affects a purchasing or capacity decision.

Ingest & retention

Daily ingest volume (GB/day)

Hot + Warm + Cold retention, i.e. searchable (days) Archive to Frozen (coldToFrozenDir/coldToFrozenScript configured) Frozen archive retention beyond searchable (days)

Indexer clustering

On-premises only.

Replication Factor (RF) Search Factor (SF) Ingest capacity per indexer (GB/day)

Cost & capacity planning

Splunk Cloud → Ingest Processor → Amazon S3 → Federated Search Cost & Size Calculator

Models two distinct cost paths -- writing security telemetry from Splunk Cloud / Ingest Processor to Amazon S3, and searching that S3 data from Splunk Cloud using Federated Search -- plus a combined Total Cost of Ownership view. AWS region: Asia Pacific (Sydney), ap-southeast-2, data residency Australia.

This is a planning tool, not a vendor quote. It runs entirely in your browser with no backend, no database and no live AWS/Splunk API calls. Every price is user-editable in Pricing Configuration below -- default figures are illustrative examples only and must be verified against current ap-southeast-2 and Splunk contract pricing before use in any purchasing or architecture decision.

Overview & design principles

Scenario name Currency USD → AUD exchange rate Show both currencies on totals

Ingest Processor → Sydney S3 cost is primarily driven by volume × retention, plus processing, routing and transfer.
Federated Search → Sydney S3 cost is primarily driven by search frequency × search breadth × data scanned.

Write-side optimisation

Optimise retention, compression, object size, S3 storage class, regional placement and replication.

Read-side optimisation

Optimise partition pruning, time constraints, file layout, dataset selection, SPL search discipline, search frequency and bytes scanned.

Security/SOC context. S3 is generally most economically attractive when data is retained extensively but searched relatively infrequently. High-value, frequently queried telemetry (real-time detections, correlation searches, ES risk/notables, dashboards, active investigations) may be more appropriate for Splunk indexing. S3/Federated Search may be more appropriate for long-term retention, historical investigations, compliance, hunting older telemetry, or lower-value/deferred telemetry. This calculator does not automatically recommend one architecture -- it calculates and compares.

Architecture diagram

Data Source

GB/day

Ingest Processor

Processing cost
Transformation cost
Routing entitlement

Indexed

Splunk Cloud

Ingest
Retention
Workload

Data volume, compression & retention

Example initial scenario: 500 GB/day raw, 365 days retention, 30% stored after compression ≈ 182.5 TB raw retained / 54.75 TB compressed retained.

Volume input mode Raw GB/day (user-entered if volume-driven) Average event size (bytes) Events/second (user-entered if event-driven) Peak multiplier (× average EPS) Number of data sources Number of sourcetypes Number of hosts Number of tenants Number of environments

Calculated	Value
GB/hour (raw)
GB/day (raw)
GB/month (raw)
TB/month (raw)
GB/year (raw)
TB/year (raw)
Events/hour
Events/day
Events/month
Events/year
Peak EPS (avg × multiplier)

Compression

Compression mode Stored percentage of raw (%) Compression ratio (N:1) Custom compressed GB/day

Calculated	Value
Resolved stored percentage
Compressed GB/day (raw × stored %)
Compressed GB/month
Compressed TB/month
Compressed GB/year
Compressed TB/year
Storage saved (raw − compressed, GB/year)
Percentage reduction

Retention

Retention (days) Presets

Calculated	Value
Stored GB (compressed GB/day × retention days)
Stored TB
Raw retained TB (uncompressed equivalent)
Average stored capacity (ramp-up average)	GB
Monthly growth	GB/month
Annual growth	TB/year

Ingest Processor cost model

Splunk commercial licensing varies by subscription and contract. Confirm whether Ingest Processor entitlement is based on data processed, data delivered, workload, routing, or another commercial metric.

Cost model Cost per GB (Pricing Config) Workload units Cost per workload unit Flat monthly entitlement Contract discount (%) Custom/manual monthly cost

Daily processing cost: Monthly processing cost: Annual processing cost:

Splunk indexed copy

Toggle whether this data is also indexed in Splunk Cloud (Source → Ingest Processor → Splunk Index + S3) versus S3-only (Source → Ingest Processor → S3 only).

Also index this data in Splunk Cloud Percentage of total data indexed Splunk cost per GB Workload cost (monthly) Splunk index retention (days) Other Splunk storage/entitlement charges (monthly)

Indexed GB/day at this %: Indexed stored GB: Monthly Splunk indexing cost: Annual Splunk indexing cost:

Use the Scenario Comparison section below to see the financial impact of indexing 100%, 50%, 25% or 0% of this data side by side.

Amazon S3 storage & lifecycle

Region: Asia Pacific (Sydney), ap-southeast-2. Percentages should sum to 100% across the classes actually in use (a warning appears in Recommendations if they don't).

Storage class	% of data stored	Cost / GB-month	Min duration (days)	Retrieval cost / GB

Monthly S3 storage cost: Annual S3 storage cost: Cost / TB-month: Cost / TB-year:

Storage lifecycle modelling

Enable lifecycle tiering (overrides the flat percentages above) Tier 1 ends at day Tier 1 class Tier 2 ends at day Tier 2 class Tier 3 ends at day Tier 3 class Beyond tier 3, class

Federated Search may require immediate object access. Archive storage classes can introduce retrieval delay, retrieval charges, minimum storage duration, or restore requirements.

S3 object size & PUT cost

Target object size (MB) Buffer / flush interval (minutes) Parallel data sources PUT cost / 1,000 requests

Objects/hour: Objects/day: Objects/month: Objects/year: Small file risk:

Excessive small files can increase S3 PUT/GET/LIST requests, Glue metadata, KMS operations, Federated Search startup overhead and partition management overhead. 128-512 MB is shown here as an example analytical object-size range, not a universally optimal figure -- validate against your own workload.

PUT requests/month: PUT requests/year: Monthly PUT cost: Annual PUT cost:

S3 GET/LIST, KMS, Glue & SQS

Request- and metadata-level costs driven by Federated Search activity (configured in the next section).

S3 GET & LIST (Federated Search requests)

Objects accessed/search GET requests/object accessed LIST requests/search GET cost / 1,000 requests LIST cost / 1,000 requests

GETs/day: GETs/month: LISTs/day: LISTs/month: Monthly request cost: Annual request cost:

AWS KMS

Use AWS KMS encryption (SSE-KMS) KMS key monthly cost Cost / 10,000 API calls

Monthly encrypt requests (from writes): Monthly decrypt requests (from search reads): Monthly KMS cost: Annual KMS cost:

AWS Glue / metadata

Use Glue Data Catalog / crawler Databases Tables New partitions/day Crawler runs/day Crawler duration (minutes) Cost / DPU-hour Catalog request cost / million Flat/custom monthly cost

New partitions/month: Monthly Glue cost: Annual Glue cost:

Amazon SQS

Use SQS for object notifications / discovery Messages/object Requests/message Cost / million requests

Requests/month: Requests/year: Monthly SQS cost: Annual SQS cost:

AWS data transfer

Actual transfer treatment depends on Splunk Cloud hosting location, AWS region, service architecture, and whether data remains inside AWS, crosses regions, or crosses a cloud boundary. Not every byte scanned is assumed to leave S3/AWS -- bytes scanned, physically read, returned and transferred are tracked separately.

Write path: ingress cost/GB (Ingest Processor → Sydney) Write path: Splunk egress cost/GB (if applicable) Write path: cross-cloud transfer cost/GB Search path transfer model Same-region transfer cost/GB Cross-region transfer cost/GB Internet/cloud egress cost/GB

Write-path transfer/month: Search-path transfer/month: Total transfer/month: Total transfer/year:

Federated Search usage, partition pruning & search amplification

Searches/day % of searches targeting S3 Average GB scanned/search (unoptimised) Average GB returned/search Analysts Search workload cost/search Federated Search entitlement (monthly) Custom monthly Federated Search charge

TB scanned/day: TB scanned/month: TB scanned/year: TB returned/month: Cost/search: Cost/analyst: Monthly Federated Search cost: Annual Federated Search cost:

Partitioning model

Example partition layout: s3://splunk-security-data/source=windows/sourcetype=wineventlog_security/year=2026/month=08/day=14/hour=08/

Partition pruning efficiency (%)

Unoptimised scan/search: GB Optimised (effective) scan/search: GB Data avoided/search: GB Percentage reduction:

Search Amplification Ratio

Bytes scanned/search: GB Bytes returned/search: GB Amplification ratio: :1 ()

Thresholds (Excellent/Good/Moderate/Poor/Severe) are organisation-configurable engineering thresholds built into this tool's defaults, not universal industry standards. Use the ratio to identify potentially inefficient SPL, partitioning, data organisation, search time windows, or dataset selection.

Search guardrail calculator

Constrained search: GB scanned/search (bounded by earliest/latest, dataset, source, sourcetype, tenant, environment, year/month/day/hour)

Replication

Replication mode Replica percentage Replication PUT cost / 1,000 Replication data transfer cost/GB (CRR) Secondary region storage cost/GB-month

Primary S3 storage cost/month: Replica storage cost/month: Replication request cost/month: Replication transfer cost/month: Total replication overhead/month: Total replication overhead/year:

Primary S3 cost and resilience/replication overhead are kept separate above and in the Cost Summary breakdown -- replication is an overhead on top of primary storage, not a substitute for it.

Cost summary

Category	Monthly	Annual	% of total

Write / Retention cost

Ingest Processor → Sydney S3: processing, transfer, storage, PUT, KMS, metadata, lifecycle, replication.

/mo
/yr

Search cost

Splunk Federated Search → Sydney S3: search workload, GET, LIST, KMS decrypt, metadata/catalog, retrieval, transfer.

/mo
/yr

Combined TCO

Write + Retention + Search.

/mo
/yr

Cost / raw GB Cost / stored GB Cost / TB retained Cost / million events Cost / search Cost / analyst Cost / datasource Cost / year of retention

Cost drivers (ranked)

Capacity dashboard

Cost breakdown by category

Monthly cost trend, months 1-12

Storage growth over time

Raw vs compressed (TB/year)

Scan efficiency (available vs scanned vs returned)

Cost by architecture scenario

Scenario comparison

Four named scenarios computed from the current inputs above, varying only the Splunk-indexed percentage and (for Scenario D) partition pruning efficiency.

Scenario	Splunk indexed GB/day	Stored TB	Search TB/month	Monthly cost	Annual cost	3-year cost	5-year cost

Long-term cost projection

Annual data growth (%) Annual AWS price adjustment (%) Annual Splunk price adjustment (%) Annual search growth (%) Annual analyst growth (%)

Milestone	Annual cost at that year	Cumulative TCO

Break-even analysis

Splunk storage/index cost, $/GB-month

Cost optimisation recommendations

Automatically generated from the values entered above.

Assumptions register

Parameter	Value	Unit	Source	Entered/Calculated	Confidence

Pricing configuration

All unit prices used throughout this calculator, in one place. Defaults are illustrative examples only -- verify against current ap-southeast-2 AWS pricing and your Splunk contract before use.

Splunk

Ingest Processor cost/GB Ingest Processor cost/workload unit Splunk indexed ingestion cost/GB Splunk Federated Search cost/search Splunk Federated Search entitlement (monthly) Custom Splunk monthly cost

Splunk pricing is never invented by this tool. Every figure above defaults to 0 until you enter a value sourced from your own Splunk quote or contract.

AWS -- Sydney (ap-southeast-2)

Storage-class prices are edited directly in the S3 storage table above. The fields below cover the remaining unit prices. Example figures only -- verify against the AWS Pricing Calculator for ap-southeast-2 before use.

Field	Unit	Current value	Source / notes	Last verified
S3 PUT	$ / 1,000 requests
S3 GET	$ / 1,000 requests
S3 LIST	$ / 1,000 requests
KMS key	$ / key / month
KMS requests	$ / 10,000 calls
Glue crawler	$ / DPU-hour
SQS requests	$ / million
Cross-region transfer	$ / GB
Internet/cloud egress	$ / GB
Replication (CRR) transfer	$ / GB

Export / Import & scenario management

Import a previously exported JSON configuration

Saved scenarios (this browser)

Values, saved scenarios and pricing persist in this browser's local storage. Nothing is sent to a server -- clearing browser data or using a different browser/device will not carry saved scenarios across.

Reusable AI analysis

Prompt library

Copy-ready prompts for analysing SIEM data quality, investigation value, cyber value and logging assurance. Each prompt is designed to work only from the supplied sample evidence and to avoid assuming fields or context that are not present.

Cyber logging analysis prompts

Use these prompts with representative raw events and retain the output as assessment evidence where appropriate.

Select a prompt

Pivot Density and Pivot Breadth

Copilot prompt for assessing pivot-key coverage, category breadth, investigation usability and missing identifiers.

Copilot Prompt — Cyber Value Pivot Analysis

You are a cyber security logging analyst specialising in SIEM data quality and investigation value.

Analyse the supplied sample log events and determine the Pivot Density and Pivot Breadth of the data.

Definitions

Pivot Density

Determine the percentage of log events that contain at least one usable investigation or correlation key.

A pivot key is any field that allows an analyst to locate related activity across datasets or continue an investigation.

Examples include (but are not limited to):

* Username
* User ID
* Email address
* Source IP Address
* Destination IP Address
* Hostname
* Device Name
* Asset ID
* Endpoint ID
* Session ID
* Process ID
* Process GUID
* Parent Process ID
* File Hash (MD5/SHA1/SHA256)
* Certificate Thumbprint
* URL
* Domain Name
* DNS Query
* MAC Address
* Container ID
* Kubernetes Pod
* Virtual Machine ID
* Cloud Resource ID
* Azure Resource ID
* AWS ARN
* GCP Resource Name
* Correlation ID
* Request ID
* Transaction ID
* Trace ID
* Authentication Token ID
* API Key ID
* Device Serial Number
* Certificate Subject
* Object GUID
* SID
* Group ID

Calculate

Pivot Density (%) =
(Number of events containing one or more usable pivot keys ÷ Total events analysed) × 100

Do not count timestamps, severity, event IDs or static metadata as pivot keys unless they uniquely identify related activity.

⸻

Pivot Breadth

Determine how many different categories of pivot keys appear across the dataset.

Group individual fields into logical pivot categories.

Example categories include

Pivot Category Example Fields
User Identity username, userid, email, SID
Host Identity hostname, computer name, device name
Network Identity source IP, destination IP, MAC
Session session ID, logon ID
Process PID, Process GUID, Parent PID
File filename, hash
URL / Web URL, URI
DNS domain, FQDN, DNS query
Cloud Resource Azure Resource ID, AWS ARN, GCP resource
Container Container ID, Pod ID
Certificate Thumbprint, Subject
Application Object Object ID, Record ID
Transaction Trace ID, Request ID, Correlation ID

Only include a pivot category if it appears in a meaningful proportion of the sample (approximately 5% or more of events unless the sample is very small).

Calculate

Pivot Breadth =
Number of distinct pivot categories present.

⸻

Assessment

For the supplied logs produce:

1. Pivot Density

* Percentage
* Number of events analysed
* Number containing at least one pivot key
* Rating

Use

* Excellent (95–100%)
* Good (80–94%)
* Moderate (60–79%)
* Poor (40–59%)
* Very Poor (<40%)

⸻

2. Pivot Breadth

List every pivot category identified.

For each category include

* Category name
* Example fields found
* Percentage of events containing that category

Then calculate

Total Pivot Breadth = X categories

Rate as

* Excellent (10+ categories)
* Good (8–9)
* Moderate (6–7)
* Limited (4–5)
* Poor (0–3)

⸻

3. Investigation Assessment

Describe:

* Which pivots are strongest.
* Which pivots are missing.
* How easily an analyst could pivot into authentication, endpoint, network, cloud or application telemetry.
* Whether investigations would rely on a single pivot or multiple independent pivots.

⸻

4. Recommendations

Recommend additional fields that would significantly improve investigation capability.

Prioritise:

* User identity
* Host identity
* Network identity
* Session identifiers
* Process identifiers
* Correlation IDs
* Cloud resource identifiers
* Transaction identifiers

⸻

5. Final Output

Return the results in the following format.

Pivot Density

* Events Analysed:
* Events with Pivot Keys:
* Density:
* Rating:

Pivot Breadth

Pivot Category Fields Found Coverage %

Total Categories:

Rating:

Investigation Summary

(Analysis)

Recommendations

(Ordered list)

Do not assume fields exist. Only report what is present in the supplied log samples.

Event Context Completeness Score

Copilot prompt for scoring how completely events answer when, who, where, what, outcome, impact and correlation.

Copilot Prompt — Event Context Completeness Score (ECCS)

You are a cyber security logging analyst specialising in SIEM data quality, threat detection, incident response and cyber logging assurance.

Analyse the supplied sample log events and calculate an Event Context Completeness Score (ECCS).

The purpose of ECCS is to measure how completely the events answer the seven key investigative questions required for cyber investigations, detection engineering, threat hunting and incident response.

Evaluate the quality of context, not simply whether fields exist.

⸻

Scoring Method

Score each of the seven dimensions from 0–4.

Score	Meaning
0	Missing
1	Minimal
2	Basic
3	Good
4	Excellent

Maximum possible score:

28 points

⸻

Seven Context Dimensions

1. WHEN

Determine how well the event explains when something happened.

Consider:

* Event timestamp
* UTC offset or timezone
* Millisecond precision
* Event duration
* Start/end time
* Multiple timestamps where appropriate

Example fields

* _time
* timestamp
* event_time
* created
* start_time
* end_time
* duration

Score:

* 0 = no meaningful timestamp
* 1 = timestamp only
* 2 = timestamp with limited precision
* 3 = precise timestamp with timezone
* 4 = precise timeline including duration or multiple relevant timestamps

⸻

2. WHO

Determine how well the event identifies who performed the activity.

Consider:

* Username
* Account
* Service account
* SID
* Process owner
* Identity provider ID
* Email
* Role

Example fields

* user
* username
* account
* sid
* principal
* actor
* email

Score:

* 0 = no identity
* 1 = weak identity
* 2 = one usable identity
* 3 = multiple identity attributes
* 4 = complete identity context including account type or ownership

⸻

3. WHERE

Determine how well the event identifies where the activity occurred.

Consider:

* Hostname
* Device
* Source IP
* Destination IP
* Cloud resource
* Tenant
* VM
* Container
* Kubernetes node
* Region

Example fields

* host
* hostname
* src_ip
* dest_ip
* asset_id
* cloud_resource
* tenant
* vm
* pod

Score:

* 0 = no location
* 1 = one location attribute
* 2 = host or IP only
* 3 = host plus network context
* 4 = complete infrastructure context

⸻

4. WHAT

Determine how well the event explains what occurred.

Consider:

* Event type
* Resource
* Object
* Process
* Command
* API
* File
* Registry key
* Service
* Operation

Example fields

* action
* operation
* process
* command
* object
* file
* event_type

Score:

* 0 = unclear activity
* 1 = generic activity
* 2 = identifiable action
* 3 = detailed operation
* 4 = complete operational context

⸻

5. OUTCOME

Determine how well the event describes what happened as a result.

Consider:

* Success
* Failure
* Status code
* Return code
* Error
* Reason
* Authentication result

Example fields

* result
* status
* success
* reason
* status_code
* error

Score:

* 0 = unknown outcome
* 1 = vague result
* 2 = success/failure only
* 3 = detailed result
* 4 = complete outcome including reason or status code

⸻

6. IMPACT

Determine how well the event describes why the event matters.

Consider:

* Severity
* Risk
* Classification
* Alert level
* Threat score
* Policy
* Confidence

Example fields

* severity
* priority
* risk
* classification
* confidence
* policy

Score:

* 0 = no impact
* 1 = minimal
* 2 = severity only
* 3 = meaningful impact information
* 4 = comprehensive impact context

⸻

7. CORRELATION

Determine how well the event supports pivoting and correlation.

Consider identifiers such as:

* Session ID
* Trace ID
* Correlation ID
* Transaction ID
* Process ID
* Parent Process ID
* GUID
* Request ID

Example fields

* session_id
* trace_id
* correlation_id
* process_id
* parent_process_id
* guid

Score:

* 0 = no correlation identifiers
* 1 = one weak identifier
* 2 = one usable pivot
* 3 = multiple pivot identifiers
* 4 = rich correlation context across systems

⸻

Calculate ECCS

Equal-weighted ECCS

ECCS (%) =

((Sum of seven dimension scores) / 28) × 100

⸻

Determine Rating

ECCS	Rating
0–39%	Poor
40–59%	Weak
60–74%	Adequate
75–89%	Good
90–100%	Excellent

⸻

Analysis Guidance

Do not simply award points because fields exist.

Evaluate:

* completeness
* usefulness
* investigation value
* detection value
* response value
* ability to reconstruct events
* ability to correlate across systems

Reward context richness rather than field count.

⸻

Output Format

Produce the following report.

Event Context Completeness Score (ECCS)

Overall Score

* Total Score: XX / 28
* ECCS: XX%
* Rating: Poor / Weak / Adequate / Good / Excellent

⸻

Dimension Assessment

Dimension	Score	Assessment	Missing Context	Improvement Recommendations
When	X/4	…	…	…
Who	X/4	…	…	…
Where	X/4	…	…	…
What	X/4	…	…	…
Outcome	X/4	…	…	…
Impact	X/4	…	…	…
Correlation	X/4	…	…	…

⸻

Strengths

Summarise the strongest investigative context contained within the events.

⸻

Weaknesses

Summarise the largest context gaps and explain how they limit investigations, detections or incident response.

⸻

Priority Improvements

List the highest-value improvements in priority order, explaining how each would increase the Event Context Completeness Score.

⸻

Executive Summary

Provide a concise summary of the overall investigation readiness of the log data, including whether the events provide sufficient context for efficient detection, triage, correlation, and incident response, and identify the key improvements that would most increase cyber value.

Required Field Coverage

Copilot prompt for assessing whether mandatory fields are present, consistently populated, correctly formatted and investigation ready.

Copilot Prompt — Required Field Coverage (RFC)

You are a cyber security logging analyst specialising in SIEM data quality, threat detection, incident response and cyber logging assurance.

Analyse the supplied sample log events and calculate the Required Field Coverage (RFC).

The purpose of RFC is to measure whether events consistently contain the mandatory fields required for cyber investigations, threat detection, incident response, reporting and compliance.

Assess not only whether fields exist, but also whether they are populated, usable, correctly formatted and consistently present across the sample events.

⸻

Scoring Method

Determine the percentage of required fields that are present and usable.

RFC Formula

RFC (%) =

(Number of Required Fields Present ÷ Total Required Fields) × 100

⸻

Required Field Assessment

For each required field determine:

* Present (Yes/No)
* Consistently populated
* Correctly formatted
* Suitable for investigations
* Notes on quality or issues

⸻

Typical Required Fields

Evaluate the presence and quality of the following fields.

Time

* Event Time (UTC)
* Event Creation Time
* Event Received Time

⸻

Identity

* User
* Username
* Account
* Service Account
* SID

⸻

Network

* Source IP Address
* Destination IP Address
* Source Port
* Destination Port

⸻

Host / Asset

* Hostname
* Device Name
* Asset ID
* Cloud Resource
* Instance ID

⸻

Event Classification

* Event Type
* Event Category
* Action
* Object
* Resource

⸻

Outcome

* Result
* Status
* Success / Failure
* Status Code
* Error Reason

⸻

Severity

* Severity
* Risk
* Priority
* Classification

⸻

Correlation

* Session ID
* Transaction ID
* Trace ID
* Correlation ID
* Process ID

⸻

Additional Context

* Message
* Vendor
* Product
* Sourcetype
* Tenant
* Region
* Command
* Process
* Parent Process
* File
* URL
* Registry Key

⸻

Field Evaluation Criteria

For every field evaluate the following.

Present

Is the field included?

Yes / No

⸻

Population

Is the field populated?

* Always
* Usually
* Sometimes
* Rarely
* Never

⸻

Consistency

Is the field consistently populated across the supplied events?

* High
* Medium
* Low

⸻

Format Quality

Is the value correctly formatted?

Examples:

* Valid IP address
* ISO 8601 timestamp
* Username format
* Hostname
* UUID
* Integer
* Boolean

⸻

Investigation Usefulness

How useful is the field during:

* Investigation
* Detection
* Correlation
* Threat Hunting
* Incident Response

Rate:

* High
* Medium
* Low

⸻

Calculate RFC

Count every required field that is:

* Present
* Correctly populated
* Usable

Do not count fields that are:

* Missing
* Empty
* Null
* Placeholder values
* Incorrectly formatted
* Unusable

Calculate:

RFC (%) =
(Number of Valid Required Fields ÷ Total Required Fields) × 100

⸻

Determine Rating

RFC	Rating
0–39%	Poor
40–59%	Weak
60–74%	Adequate
75–89%	Good
90–100%	Excellent

⸻

Analysis Guidance

Do not simply count fields.

Consider whether each field is:

* correctly populated
* consistently present
* investigation ready
* machine readable
* useful for detections
* useful for correlation
* suitable for reporting

Highlight:

* missing fields
* inconsistent fields
* formatting problems
* parsing failures
* enrichment opportunities

⸻

Output Format

Required Field Coverage (RFC)

Overall Score

* Required Fields Evaluated: XX
* Fields Present: XX
* Fields Missing: XX
* RFC: XX%
* Rating: Poor / Weak / Adequate / Good / Excellent

⸻

Required Field Assessment

Required Field	Present	Population	Consistency	Format Quality	Investigation Value	Notes
Event Time	Yes	Always	High	Good	High	ISO 8601 with UTC offset
User	Yes	Always	High	Good	High	AD username
Source IP	Yes	Always	High	Good	High	IPv4
Destination IP	No	Never	Low	N/A	Low	Missing
Severity	No	Never	Low	N/A	Low	Not logged
Session ID	Partial	Sometimes	Medium	Good	Medium	Missing in some events
…	…	…	…	…	…	…

⸻

Missing Required Fields

List all mandatory fields that are absent from the supplied events.

For each field explain:

* Why it matters
* Investigative impact
* Detection impact
* Correlation impact

⸻

Consistency Issues

Identify fields that are:

* inconsistently populated
* intermittently missing
* incorrectly formatted
* null or empty
* populated with placeholder values

Explain the operational impact.

⸻

Data Quality Issues

Highlight:

* malformed timestamps
* invalid IP addresses
* inconsistent usernames
* missing hostnames
* inconsistent event types
* incorrect status codes
* duplicate identifiers
* parsing failures

⸻

Priority Improvements

Rank improvements by the increase in Required Field Coverage they would provide.

Include:

* field to add
* why it matters
* expected benefit
* estimated RFC improvement

⸻

Executive Summary

Provide a concise assessment of whether the supplied events contain the required fields needed for effective cyber investigations, threat detection, incident response, reporting, and compliance. Summarise the current RFC rating, the most significant gaps, and the highest-priority improvements that would increase the overall Cyber Value Index (CVI).

Data Quality Score

Copilot prompt for assessing timestamp quality, parsing success, consistency, normalization and completeness.

Copilot Prompt — Data Quality Score (DQS)

You are a cyber security logging analyst specialising in SIEM data quality, threat detection, incident response and cyber logging assurance.

Analyse the supplied sample log events and calculate the Data Quality Score (DQS).

The purpose of DQS is to measure the technical quality, reliability and usability of logging data to ensure it is accurate, consistent, correctly parsed and suitable for cyber investigations, threat detection, incident response and reporting.

Assess the quality of the data, not merely whether fields exist.

⸻

Scoring Method

Score each of the five data quality dimensions from 0–4.

Score\tMeaning
0\tPoor / Missing
1\tWeak
2\tAdequate
3\tGood
4\tExcellent

Maximum possible score:

20 points

⸻

Five Data Quality Dimensions

1. Timestamp Quality

Determine the quality of timestamps used within the events.

Evaluate:

* Accuracy
* Precision
* Millisecond support
* UTC offset or timezone
* ISO 8601 compliance
* Event time vs ingestion time
* Timestamp consistency
* Future or historical timestamp anomalies
* Clock drift
* Multiple timestamps where appropriate

Example fields

* _time
* timestamp
* event_time
* created
* received_time

Score

0 — Poor

* Missing timestamps
* Invalid timestamps
* Cannot determine event time

1 — Weak

* Timestamp present
* No timezone
* Low precision
* Inconsistent formatting

2 — Adequate

* Correct timestamp
* Basic consistency
* Minor formatting issues

3 — Good

* ISO 8601
* UTC offset
* Millisecond precision
* Consistent

4 — Excellent

* High precision
* Multiple useful timestamps
* Fully normalized
* No observable quality issues

⸻

2. Parsing Success

Determine how successfully raw events have been parsed.

Evaluate:

* Field extraction success
* JSON parsing
* KV extraction
* Structured events
* Broken fields
* Multi-line handling
* Escaping
* Delimiters
* Parsing failures

Example indicators

* Extracted fields
* Indexed fields
* JSON objects
* CIM mapping

Score

Most fields unavailable.

Only a few fields extracted.

Core fields extracted with some failures.

Nearly all fields extracted correctly.

Complete parsing with no observed issues.

⸻

3. Consistency

Determine whether values remain consistent across the supplied events.

Evaluate:

* Field names
* Value formats
* Enumerations
* Capitalisation
* Username formats
* Hostname formats
* IP formatting
* Event naming
* Vendor naming
* Severity values

Score

Highly inconsistent.

Many inconsistencies.

Mostly consistent.

Consistent with minor issues.

Completely consistent.

⸻

4. Normalization

Determine whether the events follow standard cyber logging practices.

Evaluate:

* Standard timestamp formats
* Common field naming
* CIM compatibility
* ECS compatibility
* Vendor normalization
* Taxonomy mapping
* Event categorisation
* Severity normalization
* Action normalization

Examples

* CIM
* ECS
* LATCH taxonomy
* Standard severity
* Standard event actions

Score

No normalization.

Very limited normalization.

Partial normalization.

Good normalization.

Fully normalized.

⸻

5. Completeness

Determine whether events contain the expected technical information with minimal gaps.

Evaluate:

* Missing values
* Empty values
* Null values
* Truncated events
* Partial messages
* Missing context
* Expected metadata
* Required enrichment

Score

Large portions missing.

Many missing values.

Some missing values.

Mostly complete.

Complete with virtually no gaps.

⸻

Calculate DQS

Equal-weighted DQS

DQS (%) =

((Sum of the five dimension scores) ÷ 20) × 100

⸻

Optional Cyber-Weighted DQS (Recommended)

Apply the following weights:

Dimension\tWeight
Timestamp Quality\t30%
Parsing Success\t25%
Consistency\t20%
Normalization\t15%
Completeness\t10%

Weighted DQS (%) =

Σ(Dimension Score × Weight) × 100

⸻

Determine Rating

DQS\tRating
0–39%\tPoor
40–59%\tWeak
60–74%\tAdequate
75–89%\tGood
90–100%\tExcellent

⸻

Analysis Guidance

Do not simply award points because fields exist.

Assess whether the data is:

* technically accurate
* consistently formatted
* machine readable
* reliable
* investigation ready
* detection ready
* normalized
* suitable for long-term analytics

Identify:

* parsing failures
* malformed timestamps
* inconsistent formats
* missing values
* truncated events
* duplicate fields
* inconsistent severity values
* inconsistent usernames
* inconsistent hostnames
* normalization opportunities

Reward reliable, standardized and high-quality data rather than field quantity.

⸻

Output Format

Data Quality Score (DQS)

Overall Score

* Total Score: XX / 20
* Equal-weighted DQS: XX%
* Weighted DQS: XX% (if calculated)
* Rating: Poor / Weak / Adequate / Good / Excellent

⸻

Data Quality Assessment

Dimension\tScore\tAssessment\tIssues Identified\tImprovement Recommendations
Timestamp Quality\tX/4\t…\t…\t…
Parsing Success\tX/4\t…\t…\t…
Consistency\tX/4\t…\t…\t…
Normalization\tX/4\t…\t…\t…
Completeness\tX/4\t…\t…\t…

⸻

Parsing Issues

Identify:

* Extraction failures
* Incorrect field mappings
* JSON issues
* KV parsing problems
* Multi-line event issues
* Truncated events
* Delimiter issues

Explain how each affects investigations and detections.

⸻

Timestamp Quality Issues

Identify:

* Missing UTC offsets
* Lack of millisecond precision
* Non-standard formats
* Clock drift
* Future timestamps
* Event time versus ingestion time discrepancies
* Multiple timestamp inconsistencies

⸻

Consistency Issues

Identify inconsistencies in:

* Field names
* Event types
* Severity values
* Username formats
* Hostnames
* IP addresses
* Vendor values
* Product names
* Status values

⸻

Normalization Opportunities

Recommend improvements such as:

* Common Information Model (CIM) mapping
* Elastic Common Schema (ECS) mapping
* LATCH taxonomy alignment
* Standard timestamp formats
* Consistent severity scales
* Standard event categories
* Normalized action names

⸻

Completeness Gaps

Highlight:

* Missing metadata
* Missing enrichment
* Null values
* Empty fields
* Truncated events
* Missing identifiers

Explain the impact on investigations, threat hunting and detection engineering.

⸻

Priority Improvements

List the highest-value technical improvements in priority order.

For each recommendation include:

* Issue
* Why it matters
* Expected improvement
* Which DQS dimension it improves

⸻

Executive Summary

Provide a concise assessment of the overall technical quality and reliability of the supplied log data. Summarise whether the events are suitable for cyber investigations, threat detection, incident response, analytics and reporting, identify the most significant data quality issues, and recommend the highest-priority improvements that would increase the overall Cyber Value Index (CVI).

Event Type Coverage

Copilot prompt for measuring required event-type coverage, visibility gaps, detection blind spots and improvement priorities.

Copilot Prompt — Event Type Coverage (ETC)

You are a cyber security logging analyst specialising in SIEM logging assurance, threat detection engineering, incident response and cyber logging maturity.

Analyse the supplied sample log events and calculate the Event Type Coverage (ETC).

The purpose of ETC is to measure how well the supplied logging captures the required event types needed to support cyber investigations, threat detection, incident response, compliance and security monitoring.

Event Diversity is assessed within ETC rather than as a separate score. It measures whether the captured event types provide a meaningful spread of security-relevant behaviours instead of merely repeating one event class or counting unique message strings. Do not reward cosmetic name variations, raw repetition, parameter changes or vendor-specific aliases as behavioural diversity.

Assess whether the required security-relevant event types are present, not simply how many events were collected.

⸻

Scoring Method

Determine which required event types are represented within the supplied sample.

ETC Formula

ETC (%) =

(Number of Required Event Types Captured ÷ Total Required Event Types) × 100

⸻

Required Event Types

Unless the user supplies a technology-specific event catalogue, assess against the following common cyber security event categories.

Authentication

Examples include:

* User logon
* User logoff
* Failed authentication
* MFA events
* Kerberos
* NTLM
* SSO
* Token issuance
* Password changes
* Account lockout
* Account unlock
* Service account authentication

⸻

Identity & Account Management

Examples include:

* User creation
* User deletion
* User modification
* Group membership changes
* Privilege assignment
* Role assignment
* Account enable/disable
* Password reset

⸻

Authorization & Access

Examples include:

* Resource access
* Application access
* File access
* Database access
* Share access
* API authorization
* Permission denied

⸻

Configuration Changes

Examples include:

* Configuration modifications
* Policy changes
* Registry changes
* Firewall rule changes
* Security configuration changes
* Cloud configuration updates
* Software installation
* Software removal

⸻

Administrative Activity

Examples include:

* Administrative logons
* Console access
* Remote administration
* PowerShell
* SSH
* RDP
* Management API activity
* Scheduled task creation

⸻

Process Execution

Examples include:

* Process creation
* Process termination
* Parent-child relationships
* Command execution
* Script execution
* Scheduled jobs
* Service start/stop

⸻

Network Activity

Examples include:

* Network connections
* Firewall allow/deny
* VPN activity
* DNS queries
* DHCP
* Proxy activity
* HTTP requests
* TLS connections
* NetFlow

⸻

Data Access

Examples include:

* File creation
* File deletion
* File modification
* Database queries
* Object access
* SharePoint access
* OneDrive activity
* Cloud storage access

⸻

Security Events

Examples include:

* Malware detection
* Antivirus events
* EDR detections
* IPS alerts
* IDS alerts
* Threat intelligence matches
* Security policy violations

⸻

System Events

Examples include:

* System startup
* Shutdown
* Service failures
* Driver loading
* Kernel events
* Crash events
* Scheduled maintenance

⸻

Availability & Health

Examples include:

* Service health
* Resource exhaustion
* CPU
* Memory
* Disk
* Cluster status
* High availability events

⸻

Cloud Activity

Examples include:

* API calls
* Resource provisioning
* Resource deletion
* IAM changes
* Subscription changes
* Container activity
* Kubernetes events
* Serverless execution

⸻

Detection & Alerting

Examples include:

* Correlation searches
* SIEM detections
* SOAR alerts
* Threat findings
* Behaviour analytics
* Risk events

⸻

Other Security-Relevant Events

Include any additional event types specific to the technology being assessed.

⸻

Event Type Assessment

For every identified event type determine:

* Present (Yes/No)
* Number of sample events
* Investigation usefulness
* Detection usefulness
* Coverage quality
* Notes

⸻

Coverage Assessment

Determine whether each required event type is:

* Fully covered
* Partially covered
* Not covered

⸻

Calculate ETC

Count each required event type that is represented by at least one valid event.

Calculate:

ETC (%) =
(Number of Event Types Captured ÷ Total Required Event Types) × 100

⸻

Determine Rating

ETC	Rating
0–39%	Poor
40–59%	Weak
60–74%	Adequate
75–89%	Good
90–100%	Excellent

⸻

Analysis Guidance

Do not count the number of events.

Instead evaluate whether the required event types exist.

Reward:

* broad event coverage
* security-relevant behavioural diversity across distinct event classes
* a useful spread across authentication, authorisation, privilege, administration, configuration, audit and technology-specific behaviours
* detection usefulness
* investigation usefulness
* compliance coverage

Highlight:

* missing event types
* underrepresented categories
* blind spots
* opportunities to improve visibility

If the supplied logs represent only one log source (for example, Windows Security, FortiGate Firewall, Microsoft Entra ID, AWS CloudTrail, Linux AuditD, Kubernetes Audit Logs, etc.), assess coverage against the event types that would reasonably be expected from that technology rather than against all possible cyber event types. Clearly state the assessment baseline used.

⸻

Output Format

Event Type Coverage (ETC)

Overall Score

* Required Event Types: XX
* Event Types Captured: XX
* Event Types Missing: XX
* ETC: XX%
* Rating: Poor / Weak / Adequate / Good / Excellent

⸻

Event Type Summary

Event Category	Required	Captured	Coverage	Assessment
Authentication	XX	XX	XX%	…
Identity & Account Management	XX	XX	XX%	…
Authorization & Access	XX	XX	XX%	…
Configuration Changes	XX	XX	XX%	…
Administrative Activity	XX	XX	XX%	…
Process Execution	XX	XX	XX%	…
Network Activity	XX	XX	XX%	…
Data Access	XX	XX	XX%	…
Security Events	XX	XX	XX%	…
System Events	XX	XX	XX%	…
Availability & Health	XX	XX	XX%	…
Cloud Activity	XX	XX	XX%	…
Detection & Alerting	XX	XX	XX%	…
Other Security Events	XX	XX	XX%	…

⸻

Captured Event Types

List every event type observed in the supplied logs.

For each include:

* Event type
* Example event
* Investigation value
* Detection value
* Confidence that the event type has been correctly identified

⸻

Missing Event Types

List the important event types that are expected but not observed.

For each explain:

* Why it is important
* Investigative impact
* Detection impact
* Compliance impact
* Likely logging source that should provide it

⸻

Detection Blind Spots

Describe which cyber security use cases are weakened because of missing event types.

Examples include:

* Credential compromise
* Privilege escalation
* Lateral movement
* Malware execution
* Persistence
* Data exfiltration
* Insider threats
* Cloud attacks
* Configuration abuse
* Denial of service

⸻

Priority Improvements

Rank the highest-value event types to onboard or improve.

For each recommendation include:

* Event type
* Why it matters
* Primary data source
* Expected improvement to Event Type Coverage
* Impact on Cyber Value Index (CVI)

⸻

Executive Summary

Provide a concise assessment of whether the supplied logging captures the breadth of event types required for effective cyber monitoring, threat detection, investigations, incident response, and compliance. Summarise the current Event Type Coverage rating, identify the most significant visibility gaps, explain the associated detection blind spots, and recommend the highest-priority logging improvements that would most increase the overall Cyber Value Index (CVI).

Identity Diversity

AI prompt for measuring identity-type breadth, identity quality, population spread, dominance and investigative usefulness.

Copilot Prompt — Identity Diversity Score (IDS)

You are a cyber security logging analyst specialising in identity telemetry, SIEM data quality, threat detection, investigation and logging assurance.

Analyse the supplied representative log sample and calculate the Identity Diversity Score (IDS).

Definition

Identity Diversity measures the breadth, quality and investigative usefulness of identities represented in a log source.

It answers:

“Does this log source show a useful range of actors and identity types, or is it dominated by one account, anonymous activity or a single service identity?”

Do not reward raw repetition. A thousand events generated by the same machine or service account still represent low identity diversity.

Identity categories

Classify observed identities into the following categories where supported by evidence:

* Human user
* Privileged or administrative user
* Service account
* Machine or device identity
* Application or workload identity
* API client identity
* Federated identity
* External or guest identity
* Anonymous or unauthenticated actor
* Unknown or unresolved identity

Scoring dimensions

Score each dimension from 0 to 4.

1. Identity-Type Breadth — 25%
0 = no usable identity
1 = one identity type only
2 = two useful identity types
3 = three to four useful identity types
4 = five or more useful identity types with security relevance

2. Distinct Identity Population — 20%
0 = no resolvable identities
1 = almost all events belong to one identity
2 = small identity population with limited spread
3 = useful spread across multiple distinct identities
4 = broad representative population without artificial inflation

3. Privileged and High-Risk Identity Visibility — 20%
0 = privileged identity cannot be distinguished
1 = weak or ambiguous administrator indicators
2 = some privileged identities identifiable
3 = privileged, elevated and high-risk identities are consistently identifiable
4 = strong visibility of privilege level, role and elevation context

4. Identity Quality and Resolution — 20%
0 = anonymous, blank or unusable identity values
1 = inconsistent or ambiguous identity strings
2 = partially normalised identities with material gaps
3 = consistently resolvable identities with type or domain context
4 = stable identifiers, normalised names, domains/tenants and correlation-ready identity context

5. Distribution Balance and Dominance — 15%
0 = one account or identity type dominates almost all events
1 = extreme concentration with little additional identity value
2 = moderate concentration but some useful variety
3 = balanced enough to support behavioural comparison
4 = representative distribution across meaningful identity populations

Formula

IDS = ((Identity-Type Breadth × 0.25) + (Distinct Identity Population × 0.20) + (Privileged Visibility × 0.20) + (Identity Quality × 0.20) + (Distribution Balance × 0.15)) ÷ 4 × 100

Rules

* Do not count duplicate usernames, aliases or case variations as different identities.
* Normalise DOMAIN\user, user@domain and equivalent identifiers before counting.
* Do not infer an identity type solely from a username pattern unless confidence is stated.
* Repeated events from one identity do not increase diversity.
* Anonymous and unknown identities may be reported but do not increase useful diversity.
* Service, machine and application identities are valuable only when distinguishable and operationally attributable.
* Use a representative time window and state the sample size.
* Identify sampling bias, synthetic test accounts and shared accounts.

Rating bands

90–100 = Exceptional
75–89 = High
60–74 = Moderate
40–59 = Low
0–39 = Very Low

Output

1. Overall IDS, rating and confidence.
2. Dimension table with score, weight, weighted contribution, evidence and limitations.
3. Identity-category table showing category, distinct count, event count, event percentage, examples and confidence.
4. Dominance analysis listing the top identities and top identity types by event percentage.
5. Quality findings covering anonymous, unknown, shared, inconsistent, duplicated or non-normalised identities.
6. Improvement recommendations.
7. A concise explanation of how IDS complements Event Type Coverage, Pivot Breadth, Entity Coverage and Event Context Completeness.

Investigation Breadth

AI prompt for measuring the range of investigative questions, entities, timelines and response paths supported by a log source.

Copilot Prompt — Investigation Breadth Score (IBS)

You are a cyber security logging analyst specialising in SIEM investigations, threat detection, incident response, event context and logging assurance.

Analyse the supplied representative log sample and calculate the Investigation Breadth Score (IBS).

Definition

Investigation Breadth measures the range of investigative questions, entities, timelines and response paths a log source can support.

It answers:

“How many different investigation routes can this log source support across identity, asset, activity, outcome, impact and correlation?”

A log containing one repeated event may have strong semantic clarity but low Investigation Breadth. Do not reward repetition, field count alone, unique message strings, or multiple names for the same underlying investigative route.

Scoring dimensions

Score each dimension from 0 to 4 using evidence from the sample.

1. Identity Investigations — 20%
0 = no usable actor identity
1 = limited or ambiguous identity evidence
2 = a primary actor can be identified for some events
3 = users, administrators, services or other actors support multiple identity enquiries
4 = strong actor attribution, identity type and cross-event identity tracing

2. Asset and Location Investigations — 15%
0 = no usable asset or location context
1 = generic source only
2 = a host, device, application, tenant, network or location is identifiable
3 = multiple asset or location routes are consistently available
4 = strong source-target, infrastructure and location tracing across events

3. Activity and Behaviour Investigations — 20%
0 = activity cannot be determined
1 = broad message only
2 = a useful action or event class can be identified
3 = multiple distinct security-relevant behaviours can be investigated
4 = rich behavioural variety with actor, action, object and purpose context

4. Timeline Reconstruction — 15%
0 = no reliable event time
1 = weak or inconsistent timestamps
2 = events can be placed in basic order
3 = sessions, sequences or related actions can be reconstructed
4 = reliable multi-event chronology with event, received and correlation timing where relevant

5. Outcome and Response Paths — 10%
0 = no result or response evidence
1 = vague success, failure or status text
2 = useful outcome or disposition is available
3 = outcomes support escalation, containment or validation decisions
4 = outcomes, enforcement actions and response status support several response paths

6. Impact and Affected-Object Investigations — 10%
0 = no affected object or consequence
1 = consequence is implied only
2 = an affected account, object, resource or data set can be identified
3 = scope or consequence can be assessed across several events
4 = strong affected-entity, impact and scope evidence supports impact analysis

7. Correlation and Pivot Routes — 10%
0 = no stable correlation key
1 = one weak or inconsistent pivot
2 = at least one reliable user, host, IP, session, transaction, process or event identifier
3 = several distinct pivot types support cross-event investigation
4 = strong internal and cross-source correlation routes with stable identifiers

Formula

IBS = ((Identity × 20) + (Asset × 15) + (Activity × 20) + (Timeline × 15) + (Outcome × 10) + (Impact × 10) + (Correlation × 10)) ÷ 4

The result is normalised to 0–100.

Scoring rules

* Assess investigation routes supported by the dataset, not the number of events.
* Do not double-count the same capability across dimensions without distinct evidence.
* Do not award breadth for repeated instances of one event type.
* Field presence alone is insufficient; the field must support an investigative question.
* Distinguish Investigation Breadth from ECCS: ECCS measures context completeness within an event, while IBS measures the range of enquiries supported across the source.
* Distinguish Investigation Breadth from Pivot Breadth: pivot breadth counts usable pivot-key types, while IBS measures complete investigative routes and questions.
* Distinguish Investigation Breadth from Event Type Coverage: ETC measures expected event-class coverage, while IBS measures the investigations enabled by the available evidence.
* Use representative samples and state any sampling limitations.
* Where evidence is ambiguous, score conservatively and identify the validation required.

Return

1. Executive summary.
2. A dimension table containing dimension, weight, score from 0 to 4, weighted contribution, evidence, supported investigative questions, gaps and confidence.
3. Total IBS from 0 to 100.
4. A list of distinct investigation routes supported by the source.
5. The most important unsupported investigation routes.
6. Comparison with ECCS, Pivot Breadth, Entity Coverage, Identity Diversity and Event Type Coverage.
7. Recommended fields or event classes that would most improve Investigation Breadth.
8. Overall rating:
* 90–100 Exceptional
* 75–89 High
* 60–74 Moderate
* 40–59 Limited
* 20–39 Poor
* 0–19 Minimal
9. Confidence rating and sample limitations.

Investigative Context Density

AI prompt for measuring average usable investigation context across events.

Copilot Prompt — Investigative Context Density (ICD)

You are a cyber security logging analyst. Analyse the supplied representative log sample and calculate Investigative Context Density.

Definition
ICD measures how many of the seven investigation context dimensions are present per event on average.

Dimensions
1. When — reliable event time.
2. Who — user, account, service, process owner or other actor.
3. Where — source, destination, host, device, application, tenant or location.
4. What — event type, activity, action or affected object.
5. Outcome — success, failure, denial, result or status.
6. Impact — affected resource, scope, consequence or material change.
7. Correlation — session, transaction, request, trace, event, process or other linking identifier.

Scoring rules
- Score each dimension once per event: present and usable = 1; absent, empty, static or unusable = 0.
- Do not award multiple points for several fields representing the same dimension.
- Do not infer context that is not present.
- A timestamp alone does not establish timeline quality if it cannot be parsed reliably.
- Static product or sourcetype metadata does not establish Where unless it identifies the event origin.

Calculations
Event Context Count = sum of the seven dimensions for that event.
Event ICD Percentage = Event Context Count ÷ 7 × 100.
Dataset ICD = sum of all Event Context Counts ÷ (Total Events × 7) × 100.

Return
1. Total events analysed and sampling limitations.
2. One row per event with seven dimension flags, context count and event ICD percentage.
3. Dataset ICD percentage.
4. Average number of dimensions per event.
5. Distribution from 0 through 7 dimensions.
6. Strongest and weakest dimensions.
7. Examples of unusable or misleading context.
8. Recommended field or parsing improvements.
9. Confidence score from 0 to 100.

Context Dimension Coverage

AI prompt for identifying dataset-wide coverage and gaps across the seven context dimensions.

Copilot Prompt — Context Dimension Coverage (CDC)

You are a cyber security logging analyst. Analyse the supplied representative log sample and calculate Context Dimension Coverage.

Definition
CDC measures the percentage of events that contain usable evidence for each investigation context dimension across the dataset. It identifies systemic context gaps even when the average event appears acceptable.

Dimensions
When, Who, Where, What, Outcome, Impact and Correlation.

Scoring rules
- Assess each event against every dimension.
- Present means populated, correctly interpreted and useful for investigation.
- Empty, null, placeholder, constant, malformed or incorrectly parsed values count as absent.
- Do not infer values from undocumented assumptions.
- Count each event once per dimension.

Calculation for each dimension
Dimension Coverage Percentage = Events with usable dimension evidence ÷ Total events × 100.

Overall CDC
Overall CDC = average of the seven dimension coverage percentages unless a supplied policy defines different weights. State any weighting used.

Return
1. Total events and sample period.
2. Coverage table for all seven dimensions with event count, percentage, evidence and gaps.
3. Overall CDC.
4. Coverage bands: 90–100 Exceptional; 75–89 High; 60–74 Moderate; 40–59 Limited; below 40 Poor.
5. Event types responsible for each gap.
6. Whether missingness is random, event-type-specific or systemic.
7. Recommended remediation priorities.
8. Confidence and limitations.

Investigative Noise Percentage

AI prompt for classifying context-poor events and calculating investigative noise.

Copilot Prompt — Investigative Noise Percentage (INP)

You are a cyber security logging analyst. Analyse the supplied representative log sample and calculate Investigative Noise Percentage.

Definition
INP measures the percentage of events that do not meet the defined minimum investigation-context threshold and therefore provide insufficient standalone investigative value.

Default threshold
An event is useful when at least 4 of the 7 context dimensions are usable and What is present. Use a different threshold only when the assessment policy supplied with the data explicitly requires it.

Context dimensions
When, Who, Where, What, Outcome, Impact and Correlation.

Rules
- Score each dimension as usable or not usable.
- Missing, empty, placeholder, static or malformed values do not count.
- Do not classify an event as useful solely because it has high severity.
- Apply the same threshold consistently to all events unless event-type-specific requirements are supplied.

Calculations
Useful Events = events meeting the threshold.
Noise Events = events failing the threshold.
INP = Noise Events ÷ Total Events × 100.
Useful Percentage = 100 − INP.

Return
1. Threshold used and justification.
2. Total, useful and noise event counts.
3. INP and useful percentage.
4. One row per event with context count, mandatory What result, useful/noise classification and reason.
5. Noise percentage by event type.
6. Primary causes of noise.
7. Whether filtering, enrichment, parsing or source-configuration changes are appropriate.
8. Confidence and sample limitations.

Entity Coverage

AI prompt for scoring the breadth and quality of security-relevant entities.

Copilot Prompt — Entity Coverage Score

You are a cyber security logging analyst. Measure the breadth and quality of security-relevant entities represented in the supplied log sample.

Definition
Entity Coverage measures whether the source identifies the actors, assets, resources and objects needed to investigate and correlate activity. It does not reward repetition of the same entity.

Entity classes
- Human and non-human identities
- Hosts, endpoints and devices
- Source and destination network entities
- Applications, services and workloads
- Cloud resources, accounts, subscriptions, projects and tenants
- Processes, files, certificates and software objects
- Data, business or protected objects
- Sessions, requests, transactions and traces
- Security controls, policies, roles and groups

Rules
- Count a class only when at least one value is populated and usable.
- Report distinct counts but do not convert raw cardinality directly into quality.
- Penalise anonymous, generic, shared, truncated, unstable or unnormalised identifiers.
- Distinguish entity presence from reliable entity resolution.
- Do not infer entities absent from the sample.

Scoring
Score each applicable entity class from 0 to 4:
0 absent; 1 rare/unreliable; 2 partial; 3 strong; 4 comprehensive and consistently usable.
Overall Entity Coverage = weighted achieved points ÷ weighted possible points × 100. Use equal weights unless supplied requirements define priorities.

Return
1. Applicable entity-class register.
2. Score, evidence, distinct count, quality issues and confidence for each class.
3. Overall score from 0 to 100.
4. Dominant entities and blind spots.
5. Correlation routes enabled by the entities.
6. Recommended normalisation, enrichment or collection improvements.
7. Confidence and limitations.

Marginal Novelty

AI prompt for measuring security visibility added beyond existing telemetry.

Copilot Prompt — Marginal Novelty Score

You are a cyber security logging architect. Assess the marginal novelty of the candidate log source against the supplied inventory of already-onboarded sources, fields, detections and investigative capabilities.

Definition
Marginal Novelty measures the additional security visibility gained from the candidate source after accounting for telemetry already available. It must not reward duplicated events merely because formats or field names differ.

Assess novelty across
- New event or behaviour classes
- New identity, asset or object visibility
- New authoritative outcomes or decisions
- New timestamps or timeline precision
- New correlation keys or pivot routes
- New detection use cases
- New investigation or response paths
- New environmental or technology scope

Scoring per dimension
0 no additional value; 1 minor duplication with small enrichment; 2 partial new context; 3 substantial new visibility; 4 unique or authoritative capability unavailable elsewhere.

Rules
- Compare semantic behaviour, not raw strings or sourcetypes.
- Treat replicated, forwarded or reformatted copies as duplicates.
- Distinguish authoritative evidence from inferred or secondary evidence.
- State when the comparison inventory is incomplete.

Calculation
Overall Marginal Novelty = weighted achieved points ÷ weighted possible points × 100. Use equal weighting unless priorities are supplied.

Return
1. Candidate-source summary.
2. Comparison sources used.
3. Dimension table with score, evidence, overlap, unique contribution and confidence.
4. Overall score from 0 to 100.
5. Unique detections and investigation routes enabled.
6. Duplicated capabilities and avoidable ingestion.
7. Recommendation: high-priority onboarding, targeted onboarding, enrichment-only, archive-only or do not onboard.
8. Confidence and evidence gaps.

Semantic Value

AI prompt for measuring whether events explain the action taken and its outcome.

Copilot Prompt — Semantic Value Score

You are a cyber security logging analyst. Measure how completely the supplied log sample explains what action occurred and what result it had.

Definition
Semantic Value is the combined percentage of a representative sample where an event explicitly states the specific action performed and the result of that action, in dedicated fields — not something the analyst must infer from free text, an unexplained event code or tribal knowledge.

Assess two components
1. Action Completeness — does a dedicated field identify the specific action or operation performed, not just an event type or generic category? Evidence: action, operation, change_type, command.
2. Outcome Completeness — does a dedicated field state the explicit result: success, failure, reason or enforcement decision? Evidence: result, status, outcome, reason, decision, error_code.

Rules
- Score each component as the percentage of the sample where it is explicitly and reliably populated, not inferred.
- Do not credit success inferred only from the absence of a separate failure event.
- Do not credit an unexplained numeric code as an explicit action or outcome.
- A category field (for example "AccountManagement") is not the same as an action field (for example "account disabled").
- Report the two component percentages separately, even though they are averaged for the final score — a wide gap between them is itself a finding, not just noise to be smoothed over.

Calculation
Semantic Value (%) = (Action Completeness % + Outcome Completeness %) / 2

Scoring bands (local Log Source Cyber Value model, weight ×1.5, max 7.5 of 40 points)
0–<10% = score 0; 10–<25% = score 1; 25–<50% = score 2; 50–<75% = score 3; 75–<90% = score 4; 90–100% = score 5.

Return
1. Sample summary and event classes covered.
2. Action Completeness percentage with evidence and representative examples.
3. Outcome Completeness percentage with evidence and representative examples.
4. Combined Semantic Value percentage, 0–5 score and weighted contribution (score × 1.5).
5. Events where meaning had to be inferred rather than read directly, with counts.
6. Recommended parsing, extraction or enrichment changes to close the largest gap.
7. Confidence and evidence gaps.

Log Source Cyber Value

AI prompt for assessing potential and realised detection, investigation and response value.

Copilot Prompt — Log Source Cyber Value

You are a cyber security logging architect. Assess the overall realised and potential cyber value of the supplied log source using only the evidence provided.

Evaluate
- Detection and prevention use cases
- Detection Value: usefulness for correlation, rule-based alerting, anomaly detection, threat hunting, control validation and incident triage
- Investigation usefulness and context
- Event and identity diversity
- Investigation breadth
- Pivot density and pivot breadth
- Entity coverage
- Marginal novelty compared with existing sources
- Semantic clarity and authoritative value
- Noise and unnecessary duplication
- Operational adoption, including detections, searches, dashboards and incident use where evidence is supplied

Rules
- Separate potential value from realised value.
- Do not award value for hypothetical detections without mapping evidence.
- Do not reward event volume, repeated identities or duplicated telemetry.
- Identify business, compliance or operational value separately from threat-detection value.
- Do not confuse Detection Value with Threat Signal Density: density measures the proportion of relevant signal, while Detection Value measures how useful that signal is for detection engineering.
- State unavailable evidence rather than estimating it.

Scoring
Score each applicable dimension from 0 to 5. For the embedded Log Source Cyber Value model, use these default multipliers unless an approved local rubric is supplied:
- Marginal Novelty × 2.0
- Pivot Density × 1.5
- Semantic Value × 1.5
- Pivot Breadth × 1.0
- Entity Coverage × 1.0
- Detection Value × 1.0

Detection Value scoring guidance:
0 = no evidenced detection use; 1 = very limited or indirect use; 2 = narrow use with substantial gaps; 3 = useful for multiple credible detections or hunts; 4 = strong detection and triage value; 5 = exceptional, well-evidenced value across correlation, alerting, behavioural detection, hunting, control validation and triage.

Embedded score maximum = 40 points. Normalised Cyber Value = weighted achieved points ÷ 40 × 100.

Return
1. Executive summary.
2. Dimension table with weight, score, evidence, gaps and confidence.
3. Detection Value score with mapped detection, hunting, control-validation and triage evidence.
4. Potential cyber value score.
5. Realised cyber value score where usage evidence exists.
6. Noise, duplication and marginal novelty findings.
7. Supported detections, investigations and response paths.
8. Highest-value improvements.
9. Collection recommendation and retention/filtering advice.
10. Confidence and limitations.

Response Readiness Index (RRI)

AI prompt for assessing whether analysts and responders could actually act on this source today.

Copilot Prompt — Response Readiness Index (RRI)

You are a cyber security operations analyst. Assess whether analysts and responders could actually act on the supplied log source or platform right now, using only the evidence provided — not whether detections exist for it.

Definition
RRI measures operational preparedness for investigation and incident response: a runbook, a named owner, usable retained evidence, a current escalation path and a defined response action, each specifically linked to this source or platform rather than merely present somewhere in the organisation.

Assess five dimensions
1. Runbook Readiness — is there an approved, current IR plan, runbook or SOP that specifically names this source, platform or use case?
2. Ownership Readiness — is there a named, contactable platform, technical, security or risk owner (not a placeholder or unmonitored distribution list)?
3. Evidence Availability — is retention recorded and sufficient for the required investigation lookback, and does the source clear minimum data-quality gates (parse rate, timestamp/timezone reliability, schema stability) so retained data is actually usable?
4. Escalation Readiness — is there a current, approved escalation matrix and contact register covering this source's severity class?
5. Response & Recovery Capability — is there a defined response action, and where relevant a shared responsibility, business continuity, disaster recovery or recovery procedure reference, that has been tested rather than only documented?

Rules
- Score each dimension against this specific source or platform. A generic, organisation-wide document that never names it does not count as readiness for it.
- Do not credit an overdue review date, an untested runbook, or an unreachable "team mailbox" owner at the same level as a current, tested, individually-owned one.
- Do not infer readiness that is not evidenced in the supplied material.
- Evidence Availability is a gate: if it scores 0, the overall rating must be capped at "Not response-ready" regardless of the other four scores, and this must be stated explicitly.

Scoring
Score each dimension 0 to 4: 0 absent; 1 generic or unlinked (or review overdue); 2 current and linked but never tested; 3 current, linked and usable today; 4 all of the above plus a recorded test, drill or real incident proving it works.
Equal weighting by default (×1.0 each) unless an approved local rubric supplies different weights. Maximum 20 points.

Calculation
RRI (%) = achieved points ÷ 20 × 100, then apply the Evidence Availability gate.

Interpretation bands
90–100% Ready; 75–<90% Substantially ready; 50–<75% Partially ready; 25–<50% Weak; 0–<25% Not response-ready.

Return
1. Source or platform summary.
2. Dimension table with score, evidence cited, gaps and confidence.
3. Raw RRI percentage and whether the Evidence Availability gate was triggered.
4. Final rating after the gate is applied.
5. The single weakest dimension and the specific action that would close it fastest.
6. Confidence and evidence gaps.

Operational Assurance Index (OAI)

AI prompt for assessing whether a collection pipeline can be trusted to keep working.

Copilot Prompt — Operational Assurance Index (OAI)

You are a cyber security platform engineer. Assess whether the collection pipeline behind the supplied log source or platform can be trusted to keep working, using only the evidence provided — not whether the data itself is valuable or whether responders are prepared to use it.

Definition
OAI measures pipeline reliability: whether the collection path stays up, arrives on time, is actually monitored, can be safely changed, and is being kept current — each specifically confirmed for this path rather than assumed because nothing has broken recently.

Assess five dimensions
1. Availability — is the collection path actually up, and would it stay up if one component failed? Evidence: service health, listener and pool/redundancy status, cluster peer status.
2. Timeliness — is data arriving within a known, acceptable latency without silent backlog? Evidence: queue health, backpressure, throughput against expected volume, source-to-destination reconciliation.
3. Health Checks — are the defined health tests for this source actually scheduled, running and passing, not just available in a catalogue? Evidence: health test definitions, source-level pass/fail record, last-run date.
4. Supportability — can this path be changed, patched or fixed safely without tribal knowledge? Evidence: deployment-server management, configuration baseline, dependency mapping, configuration change history.
5. Maintenance — is this path being actively kept current, or running unattended until something breaks? Evidence: certificate/credential expiry tracking, app or platform version currency, licence and capacity headroom, review cadence.

Rules
- Score each dimension against this specific collection path. A platform-wide mechanism that is not confirmed against this path does not count.
- Do not credit redundancy, monitoring or supportability that exists on paper but has never been exercised or confirmed.
- Do not infer reliability that is not evidenced in the supplied material — "nothing has broken recently" is not evidence of availability, timeliness or maintenance.
- Health Checks is a gate: if it scores 0, the overall rating must be capped at "Unverified" regardless of the other four scores, and this must be stated explicitly, because none of the other claims can be independently confirmed without monitoring in place.

Scoring
Score each dimension 0 to 4: 0 absent; 1 generic or unconfirmed (or evidence stale); 2 confirmed and current but never exercised under failure or load; 3 confirmed, current and scheduled; 4 all of the above plus a recorded test or real event proving it works, with failure actively alerting someone.
Equal weighting by default (×1.0 each) unless an approved local rubric supplies different weights. Maximum 20 points.

Calculation
OAI (%) = achieved points ÷ 20 × 100, then apply the Health Checks gate.

Interpretation bands
90–100% Assured; 75–<90% Substantially assured; 50–<75% Partially assured; 25–<50% Weak; 0–<25% Not assured / Unverified.

Return
1. Source or platform summary.
2. Dimension table with score, evidence cited, gaps and confidence.
3. Raw OAI percentage and whether the Health Checks gate was triggered.
4. Final rating after the gate is applied.
5. The single weakest dimension and the specific action that would close it fastest.
6. Confidence and evidence gaps.

Threat Detection Index (TDI)

AI prompt for assessing whether detections built against a source actually work.

Copilot Prompt — Threat Detection Index (TDI)

You are a detection engineer. Assess how effectively detections actually use the supplied log source, using only the evidence provided — not whether the data could theoretically support detection, but whether a built, tested, accurate and timely rule exists.

Definition
TDI measures detection effectiveness against an already-onboarded, governed source: technique coverage, rule coverage, validation, fidelity and latency, each confirmed for the detections built against this source rather than inferred from the data's general profile.

Assess five dimensions
1. Technique Coverage — does this source's data actually support the MITRE ATT&CK tactics and techniques it is supposed to, per an assessed coverage record (not assumed from the sourcetype alone)?
2. Rule Coverage — for each mapped use case, does a real, active detection analytic exist with working logic and a defined schedule, not just a documented intention to build one?
3. Validation — has the rule been proven to fire correctly against expected events via a documented test scenario, method and result, and how recently?
4. Fidelity — of the alerts these detections generate, what proportion are confirmed true positives rather than noise, based on actual alert and true-positive counts?
5. Latency — does the detection fire within an acceptable end-to-end time of the underlying event, covering collection and parsing lag as well as search schedule, not just the search's cron interval?

Rules
- Score each dimension against the detections actually built for this source. A high coverage percentage without a cited rule inventory is not rule coverage.
- Do not credit validation, fidelity or latency for a rule that does not exist — score those dimensions Not applicable and 0 in that case.
- Do not infer fidelity from low alert volume alone; distinguish a precise rule from one that simply rarely fires, including on real activity.
- Rule Coverage is a gate: if it scores 0, the overall rating must be capped at "Undetected" regardless of the other four scores, and this must be stated explicitly, because validation, fidelity and latency cannot be meaningfully assessed for a detection that does not exist.

Scoring
Score each dimension 0 to 4: 0 absent; 1 generic or unconfirmed; 2 current and confirmed but never proven or measured; 3 confirmed and backed by an actual measured or tested result; 4 all of the above and the measured result itself is strong.
Equal weighting by default (×1.0 each) unless an approved local rubric supplies different weights. Maximum 20 points.

Calculation
TDI (%) = achieved points ÷ 20 × 100, then apply the Rule Coverage gate.

Interpretation bands
90–100% Strong detection; 75–<90% Substantially covered; 50–<75% Partially covered; 25–<50% Weak; 0–<25% Undetected / Minimal.

Return
1. Source summary and mapped use cases.
2. Dimension table with score, evidence cited, gaps and confidence.
3. Raw TDI percentage and whether the Rule Coverage gate was triggered.
4. Final rating after the gate is applied.
5. The single weakest dimension and the specific action that would close it fastest.
6. Confidence and evidence gaps.

Timestamp Quality

AI prompt for scoring timestamp presence, parsing, timezone, precision and consistency.

Copilot Prompt — Timestamp Quality Score

You are a SIEM data-quality analyst. Analyse the supplied raw events and score timestamp quality for reliable parsing, ordering, correlation and investigation.

Assess the six calculator-aligned criteria
1. Presence and completeness.
2. Recognised format and parseability.
3. Timezone or UTC-offset clarity.
4. Precision and resolution appropriate to the event rate.
5. Correctness and event-time reliability, including future/past drift.
6. Consistency across events and event types.

Score each criterion from 0 to 4:
0 unusable; 1 poor; 2 fair; 3 good; 4 exceptional.
Use equal weights unless a supplied standard defines otherwise.

Checks
- Identify event time separately from receipt, processing or ingestion time.
- Detect mixed formats, missing years, locale ambiguity, truncated fractions and epoch-unit ambiguity.
- Compare timestamps for ordering anomalies where multiple time fields exist.
- Do not assume a timezone when none is present.

Calculation
Timestamp Quality raw score = sum of six criterion scores, maximum 24.
Timestamp Quality percentage = achieved points ÷ 24 × 100.

Use these interpretation bands:
90–100 Exceptional; 80–89 Excellent; 70–79 Good; 60–69 Fair; 40–59 Poor; 20–39 Very Poor; 0–19 Fail.

Return
1. Detected timestamp fields and examples.
2. Criterion table with score, evidence and remediation.
3. Overall score and rating.
4. Parsing risks and time-zone risks.
5. Suggested Splunk TIME_FORMAT, TIME_PREFIX and MAX_TIMESTAMP_LOOKAHEAD where the evidence permits.
6. Confidence and limitations.

Log Format Quality

AI prompt for scoring event structure, consistency, boundaries and parseability.

Copilot Prompt — Log Format Quality Score

You are a SIEM parsing and data-quality analyst. Analyse the supplied raw events and score the quality of the log format for reliable ingestion and field extraction.

Assess the six calculator-aligned criteria
1. Structure and confident format identification.
2. Event boundary reliability and multiline behaviour.
3. Delimiter, quoting and escaping integrity.
4. Schema, field-name and value-type stability.
5. Encoding and content integrity, including truncation and special characters.
6. Parsing and normalisation complexity without brittle regular expressions.

Score each applicable criterion from 0 to 4:
0 unusable; 1 poor; 2 fair; 3 good; 4 exceptional.
Use equal weights unless requirements are supplied.

Rules
- Identify the actual format: JSON, XML, CSV, TSV, key-value, CEF, LEEF, syslog, fixed-width, free text or mixed.
- Do not award JSON/XML quality merely because braces or tags appear; validate structure.
- Report malformed, truncated, concatenated or inconsistent events.
- Distinguish source-format defects from SIEM parsing configuration defects.

Calculation
Log Format Quality raw score = sum of six criterion scores, maximum 24.
Log Format Quality percentage = achieved points ÷ 24 × 100.

Use these interpretation bands:
90–100 Exceptional; 80–89 Excellent; 70–79 Good; 60–69 Fair; 40–59 Poor; 20–39 Very Poor; 0–19 Fail.

Return
1. Format identification and confidence.
2. Criterion table with evidence and score.
3. Overall score and rating.
4. Parsing failure examples.
5. Recommended event-breaking, extraction or normalisation approach.
6. Risks requiring source-side remediation.
7. Confidence and limitations.

Line Length Quality Score and TRUNCATE

Measure event size, identify truncation risk and derive a justified Splunk configuration.

Copilot Prompt — Calculate Line Length Quality Score and Recommend Splunk TRUNCATE

Act as a senior Splunk parsing engineer and log-data-quality analyst.

Analyse complete logical events after event-boundary reconstruction. Measure character length and UTF-8 byte length. Use UTF-8 byte length for TRUNCATE analysis. Distinguish genuine large events from incorrectly merged events.

Required metrics:
- event count, minimum, mean, median, P90, P95, P99 and maximum
- maximum UTF-8 byte size
- percentage above 10,000 bytes
- percentage above configured TRUNCATE
- estimated truncated bytes
- suspected merged-event count and percentage
- recommended TRUNCATE and safety margin

Scoring:
1. Truncation Risk, 35 points: none=35; <0.1%=30; 0.1–1%=22; >1–5%=12; >5%=0.
2. Boundary Integrity, 25 points: all valid=25; minor uncertainty=18; some merging=10; large-scale merging=0.
3. Size Consistency, 15 points using P95/median: ≤3=15; >3–6=12; >6–10=8; >10–20=4; >20=0.
4. Maximum Event Suitability, 15 points: ≤10KB=15; >10–50KB=12; >50–250KB=8; >250KB–1MB=4; >1MB=0.
5. Configuration Safety, 10 points: measured plus margin=10; validated default=8; high but bounded=5; TRUNCATE=0 justified=4; unjustified=0.

Bands: 90–100 Exceptional; 75–89 Good; 60–74 Fair; 40–59 Poor; 0–39 Fail.

Recommend a bounded TRUNCATE from the maximum observed valid UTF-8 event size plus a justified margin, rounded to a practical boundary. Do not recommend TRUNCATE=0 without strong evidence.

Output:
A. Executive conclusion
B. Event-size statistics
C. Dimension scoring table
D. Large-event and boundary-integrity analysis
E. Recommended props.conf
F. Validation tests
G. Assumptions and limitations

props.conf format:
[sourcetype_name]
TRUNCATE = value

Include SHOULD_LINEMERGE and LINE_BREAKER only when evidence requires them.

Log Format Detection & Parsing and Splunk sourcetype definition

Determine the format and propose evidence-based props.conf and optional transforms.conf.

Copilot Prompt — Determine Log Format Detection & Parsing and Splunk Sourcetype Definition

You are a senior Splunk parsing engineer and log-format analyst.

Analyse the supplied representative raw events and determine how Splunk should interpret and extract their structural format after line breaking and timestamp parsing.

Evidence rules
- Use only the supplied raw events and stated source context.
- Do not infer the format from the filename alone.
- Distinguish transport envelope, syslog header, HEC metadata and application payload.
- Classify the primary payload as CSV, TSV, JSON, XML, structured key-value, semi-structured, unstructured, mixed or unknown.
- Do not recommend indexed extraction unless the evidence and collection method justify it.
- Avoid duplicate extraction where HEC, an add-on, modular input or upstream processor already supplies fields.
- Recommend separate sourcetypes when schemas or formats are incompatible.
- State uncertainty and conditional alternatives rather than inventing settings.

Tasks
1. Identify format, delimiter, headers, quoting, escaping, nesting, arrays, duplicate keys, optional fields, encoding and consistency.
2. Choose index-time, search-time, add-on, HEC/upstream, or separate-sourcetype extraction.
3. Consider only evidence-supported settings: INDEXED_EXTRACTIONS, FIELD_DELIMITER, FIELD_QUOTE, HEADER_FIELD_LINE_NUMBER, TIMESTAMP_FIELDS, KV_MODE, AUTO_KV_JSON, CHARSET, TRUNCATE, SHOULD_LINEMERGE, LINE_BREAKER, EXTRACT-* and REPORT-*.
4. Produce transforms.conf only when explicit search-time extraction is required. Include REGEX, FORMAT and MV_ADD where justified.
5. Validate expected fields, headers, quoting, duplicate keys, nested content, multiline records, schema drift and collection-path duplication.

Required output
A. Executive conclusion: detected format, extraction strategy, sourcetype approach and confidence.
B. Format analysis table: Sample | Format | Delimiter/structure | Header | Quoting/escaping | Nested content | Consistency | Confidence.
C. Extraction strategy table: Option | Recommended | Evidence | Risks | Rationale.
D. Proposed props.conf.
E. Proposed transforms.conf if required.
F. Expected extracted field examples.
G. Validation findings and exceptions.
H. Omitted settings and rationale.
I. Assumptions, unresolved inputs and ingestion tests.

Example patterns

CSV:
[example:csv]
SHOULD_LINEMERGE = false
LINE_BREAKER = ([\r\n]+)
INDEXED_EXTRACTIONS = CSV
FIELD_DELIMITER = ,
FIELD_QUOTE = "
HEADER_FIELD_LINE_NUMBER = 1
TIMESTAMP_FIELDS = event_time

TSV:
[example:tsv]
SHOULD_LINEMERGE = false
LINE_BREAKER = ([\r\n]+)
INDEXED_EXTRACTIONS = TSV
HEADER_FIELD_LINE_NUMBER = 1
TIMESTAMP_FIELDS = event_time

JSON:
[example:json]
SHOULD_LINEMERGE = false
LINE_BREAKER = ([\r\n]+)
INDEXED_EXTRACTIONS = JSON
KV_MODE = none
TIMESTAMP_FIELDS = event_time

XML:
[example:xml]
SHOULD_LINEMERGE = false
LINE_BREAKER = ([\r\n]+)(?=<event(?:\s|>))
KV_MODE = xml

Structured key-value:
[example:key_value]
SHOULD_LINEMERGE = false
LINE_BREAKER = ([\r\n]+)
KV_MODE = auto

Semi-structured:
[example:semi_structured]
SHOULD_LINEMERGE = false
LINE_BREAKER = ([\r\n]+)
KV_MODE = none
REPORT-fields = extract_example_fields

transforms.conf:
[extract_example_fields]
REGEX = (\w+)=("[^"]*"|\S+)
FORMAT = $1::$2
MV_ADD = true

Treat examples as patterns only. Derive the final recommendation from the supplied sample.

Line Break and Splunk props.conf

AI prompt for determining logical event boundaries and deriving safe Splunk line-breaking settings.

Copilot Prompt — Determine Line Break and Splunk props.conf Settings

You are a senior Splunk parsing engineer and SIEM data-quality analyst.

Analyse the supplied representative raw log sample and determine how Splunk should separate the incoming stream into individual logical events.

Evidence rules
- Use only the supplied raw sample and stated source context.
- Do not assume that every physical line is a complete event.
- Preserve continuation lines, stack traces, indented attributes, wrapped messages and embedded newlines when they belong to the preceding event.
- Identify the start and end of each logical event before proposing configuration.
- Do not invent an event marker that is not present in the sample.
- Treat different line-ending styles separately where relevant: Windows CRLF, Unix LF and legacy CR.
- Remember that Splunk removes the text matched by the first capturing group in LINE_BREAKER.
- Use a lookahead when the next event begins with a stable marker that must remain part of the next event.
- If the source contains incompatible event-boundary patterns, recommend separate sourcetypes or preprocessing rather than an unsafe universal regex.

Tasks

1. Identify the physical line structure
Report:
- Observed line-ending style
- Number of physical lines
- Number of blank lines
- Whether indentation or continuation lines occur
- Whether stack traces, XML, JSON pretty-printing or wrapped messages occur
- Whether one physical line consistently equals one logical event

2. Reconstruct logical events
For each representative event, identify:
- First physical line
- Last physical line
- Start-of-event marker
- Continuation-line pattern
- End-of-event evidence
- Confidence that the boundary is correct

3. Classify the line-break model
Choose one:
- One event per physical line
- Multiline event beginning with a timestamp
- Multiline event beginning with a stable header or prefix
- Structured payload with embedded newlines
- Delimiter-separated records
- Mixed or inconsistent
- Insufficient evidence

4. Derive Splunk line-breaking settings

SHOULD_LINEMERGE
- Prefer false when event boundaries can be expressed explicitly with LINE_BREAKER.
- Explain any case where true is proposed and identify the operational risk.

LINE_BREAKER
- Provide a valid Splunk regular expression.
- Put the discarded boundary characters in the first capturing group.
- Preserve the next event's start marker using lookahead where required.
- Escape backslashes correctly.
- Avoid consuming timestamps, event identifiers or useful payload content.
- Explain exactly where the split occurs.

5. Produce the proposed props.conf stanza

Use this exact structure:

[sourcetype_name]
SHOULD_LINEMERGE = false
LINE_BREAKER = <regular expression>

Replace sourcetype_name with the supplied sourcetype. If none is supplied, use [replace_with_sourcetype].

For a verified one-event-per-line source, use:

[replace_with_sourcetype]
SHOULD_LINEMERGE = false
LINE_BREAKER = ([\r\n]+)

Do not use the baseline newline rule when continuation lines belong to the preceding event.

6. Validate the proposal
Explain:
- Expected event count before and after parsing
- Which sample boundaries match
- Any sample boundaries that do not match
- Whether blank lines are consumed safely
- Whether the first capturing group removes only separators
- Whether the next event marker remains intact
- Whether CRLF and LF are both handled
- Whether exceptionally long events create truncation or size risks
- Whether timestamp parsing will receive the correct first line
- Whether separate sourcetypes are required

Required output

A. Executive conclusion
- Detected line-break model
- Recommended SHOULD_LINEMERGE
- Recommended LINE_BREAKER
- Confidence: High, Medium or Low

C. Derived settings table
Columns:
Setting | Proposed value | Evidence | Regex behaviour | Confidence

D. Proposed props.conf stanza

E. Boundary walkthrough
Show exactly where at least two consecutive events split.

F. Validation findings and exceptions

G. Assumptions, unresolved inputs and recommended ingestion tests

Example 1 — one event per line

Raw sample:
2026-07-21T08:00:11.902+10:00 INFO event_type=login_attempt user=ADAM.SMITH
2026-07-21T08:03:44.614+10:00 WARN event_type=login_attempt user=jsmith result=failure

Expected configuration:

[replace_with_sourcetype]
SHOULD_LINEMERGE = false
LINE_BREAKER = ([\r\n]+)

Example 2 — multiline event beginning with a timestamp

Raw sample:
2026-07-21 08:02:16.453 INFO User login successful.
User=ADAM.SMITH
ClientIP=10.50.12.81
2026-07-21 08:02:22.993 INFO Cube view opened.
User=ADAM.SMITH
Cube=GL_Budget

Expected configuration:

[replace_with_sourcetype]
SHOULD_LINEMERGE = false
LINE_BREAKER = ([\r\n]+)(?=\d{4}-\d{2}-\d{2}\s+\d{2}:\d{2}:\d{2})

Explain that the newline separator is discarded while the timestamp remains at the beginning of the next event.

Log Assessment Framework

Derive a majority-baseline structural conformance assessment of a raw log sample at both line and event level.

Copilot Prompt — Run the Log Assessment Framework on a Raw Log Sample

You are a senior SIEM data-quality analyst applying a reusable, source-agnostic structural conformance methodology.

Core principle
Do not check the sample against an external spec. Derive the dominant convention for each axis from the data itself (the majority baseline) and measure every deviation from it. Report at both physical-line level and logical-event level, and treat their divergence as a signal, not noise.

Evidence rules
- Use only the supplied raw sample. Do not assume fields, formats or context that are not present.
- Decide the physical-line-to-logical-event mapping before scoring anything else.
- Do not award structured-format credit merely because braces, tags or delimiters appear somewhere in the line.
- State uncertainty and flag insufficient sample size rather than inventing a baseline.

Procedure
1. Ingest raw. Note encoding, BOM and line-ending convention (LF / CRLF / mixed) before anything normalises them away.
2. Split into physical lines and number them.
3. Detect the dominant serialization format (CSV, TSV, JSON, XML, key-value/logfmt, syslog, fixed-width, other) by tallying structure across lines. This is the majority baseline for the format axis.
4. Establish a record-start rule (e.g. leading timestamp, leading digit, leading brace) and fold continuation lines into their parent event. Assign sequential event IDs. Continuation status must be earned, not defaulted: only leading whitespace/tab, or an established open-block context (an unclosed JSON array, an in-progress stack trace), counts as evidence of continuation. A line with no leading whitespace that matches none of the known record-start patterns is NOT automatically a continuation — default it to starting a new record and let it fail conformance as its own event (it will typically bucket as FREE_TEXT once fingerprinted in step 10). Silently folding an unmatched, non-indented line into the prior record is the more common error: it under-counts events and corrupts that prior record's byte/structure totals.
5. Extract per-line features for the axes that apply: line number, event ID, serialization format, format conformance, timestamp presence, timestamp format, timestamp conformance, timestamp offset (characters before the match), timestamp width, field count, line length in characters (excluding trailing newline), line size in bytes (UTF-8 byte length, plus 1 for an on-disk LF newline or 2 for CRLF), first character and its class (digit/alpha/whitespace/symbol), first-char class conformance (matches the dominant class), structure (single- vs multi-line), line ending, encoding.
6. Compute the majority baseline independently for each axis.
7. Score conformance per line against each baseline (Yes/No), then roll up to events.
8. Aggregate percentages at line level (÷ total physical lines) and event level (÷ total logical events). Compute the all-axes rate: the fraction of records passing every applicable check. For every axis, also split records into the conforming and non-conforming sets and report each side three ways: percentage (by event count and, where record sizes vary, by bytes too), event count, and byte size. Byte size is the metric storage/retention/keep-vs-discard decisions actually need — a count-based percentage alone mis-sizes them whenever the two partitions differ in average record length.
9. Flag and explain every non-conformer with an attributed reason (wrong delimiter, day-first date, continuation line, truncated field, delimiter collision, etc.) — do not report a bare percentage without examples.
10. Compute a structural fingerprint per logical event (on the record-start line, after boundary detection — never per physical line): fingerprint = md5(format | timestamp_format)[:8], using only serialization format and timestamp format (the two independent, varying axes — everything else is constant or derived and adds no distinctions, and timestamp offset is too positionally noisy to include). Count distinct fingerprints against the theoretical maximum (product of the two cardinalities); 1 distinct fingerprint means the file is structurally monolithic. If the base tuple is degenerate (both properties constant, e.g. one XML schema with one timestamp format), extend it with the one property that actually varies — a type/ID field such as an EventID, or a hash of the record's field-name schema: fingerprint = md5(format | timestamp_format | type_key)[:8]. If a format has no name but has real structure (delimiters, key=value, fixed columns), do not bucket it as OTHER — derive a shape token instead: delimiter+arity (e.g. pipe/8) or a masked token skeleton (digit runs → 9, letter runs → A, e.g. 2026-07-31T04:03Z → 9999-99-99T99:99A, then hash it), and use fingerprint = md5(shape_hash | timestamp_format)[:8]. Only bucket a line as FREE_TEXT if it is genuinely unstructured (a free-text message, banner or wrapped line) — continuation lines should already have been folded into their parent before this step, so they should never reach FREE_TEXT in a correctly processed file. Give each derived shape a deterministic codename (never randomly generated) for readability: codename = "FMT-" + adjective[hash_byte0] + "-" + noun[hash_byte1] + "-" + hash[:4], e.g. comma/19 → FMT-ember-shrike-0594, always the same for the same shape.

Pitfalls to check explicitly
- Delimiter collision (a delimiter character inside a field, e.g. a comma before milliseconds or inside a quoted CSV value).
- Fixed-width timestamp trap: two different timestamp formats sharing the same character width. Validate the pattern, not the width.
- Mixed date ordering (DD-MM-YYYY vs MM-DD-YYYY vs YYYY-MM-DD) — ambiguous whenever the day is ≤12, with no error raised.
- A prefix before the timestamp (syslog priority, log level, hostname) that breaks fixed-slice extraction.
- Multi-line records (stack traces, pretty-printed JSON, wrapped messages) that a naive line-oriented parser would treat as separate malformed events.
- Line-ending inconsistency and an unhandled trailing \r corrupting the final field.
- Encoding: a UTF-8 BOM attaching invisible bytes to the first field, or non-UTF-8 bytes.
- Naive vs offset-aware timestamps and inconsistent timezones.
- Whitespace type (tabs vs spaces) silently changing first-character class and character counts.
- Ambiguous continuation default: a banner, separator or free-text line with no leading whitespace and no recognisable pattern silently folded into the *preceding* record instead of starting its own, because "no known record-start match" was wrongly treated as "is a continuation."

Required output
A. Executive conclusion — overall all-axes conformance rate (line and event level, plus byte share), the single most important finding, and whether the sample is large enough to trust the baseline.
B. Per-line assessment table — Line # | Evt # | Format | Fmt Conf | TS Present | TS Format | TS Conf | TS Offset | TS Width | Field Count | Chars | Bytes | 1st Char | Char Class | Cls Conf | Structure | Line Ending.
C. Assessment summary block — for each axis (Serialization format, Timestamp format, Structure, First-char class, Line ending, All axes combined): Axis | Baseline | Conf % | Conf events | Conf bytes | Non-conf % | Non-conf events | Non-conf bytes. Include file totals (total events / total bytes) so the byte figures translate directly into storage and retention numbers.
D. Structural fingerprint summary — distinct fingerprint count vs. theoretical maximum, the fingerprint (or codename) and event/byte share for each distinct structural type, and which tuple was needed (base two-axis tuple vs. an extended type_key) with what that implies about whether the file is a heterogeneous multi-source stream or a uniform single-source feed.
E. Non-conformer list — every flagged line/event with an attributed reason, grouped by root cause rather than listed as isolated defects.
F. Pitfalls triggered — which of the checklist items were found, with the specific evidence.
G. Assumptions and limitations — sample size, any axis that could not be assessed, and confidence in the derived baseline.

Interpretation guidance
- One axis at 100% while others are lower shows that convention is stable, not that the data is correct.
- Several axes partitioning the file identically (e.g. "has timestamp", "starts with a digit" and "is a record start" all flagging the same lines) are one finding, not several — merge them.
- High per-axis rates with a low all-axes rate mean many small, distinct defects rather than one systemic one — triage record-by-record rather than reporting a single blended cause.
- A dominant format's byte share is often larger than its event share, because its records tend to run longer — always report both, since a count-only percentage under-states what it would cost to discard the non-conforming minority.

Datetime Standard and Splunk props.conf

AI prompt for identifying the datetime standard and deriving evidence-based Splunk timestamp parsing settings.

Copilot Prompt — Determine Datetime Standard and Splunk props.conf Settings

You are a senior Splunk parsing engineer and SIEM data-quality analyst.

Analyse the supplied representative raw log events. Determine the datetime standard used by the source and propose the Splunk timestamp settings that would be appropriate for the sourcetype.

Evidence rules
- Use only the supplied raw events and stated source context.
- Do not invent a timestamp, prefix, timezone, year, locale or precision that is not supported by evidence.
- Distinguish event time from receipt time, processing time, file time and index time.
- If more than one timestamp appears, identify each one and state which should become Splunk _time.
- If the sample is insufficient or inconsistent, say so and provide conditional alternatives rather than presenting one configuration as certain.
- Escape TIME_PREFIX as a valid regular expression.
- Do not include the timestamp itself in TIME_PREFIX.
- Calculate MAX_TIMESTAMP_LOOKAHEAD from the first character after TIME_PREFIX through the end of the longest valid timestamp.
- Omit TZ when the timestamp already carries an unambiguous UTC marker or numeric offset, unless a specific Splunk deployment requirement is supplied.
- Do not assume the indexer timezone is suitable.

Tasks

1. Identify every candidate datetime value
For each candidate, report:
- Exact raw example
- Field name or location
- Position within the event
- Whether it represents event time, receipt time, processing time or another time
- Percentage of sampled events containing it
- Whether it is consistent across event types

2. Determine the datetime standard
Classify the selected event timestamp as one of:
- ISO 8601 extended
- ISO 8601 basic or compact
- IETF RFC 3339
- IETF RFC 2822 or IETF RFC 822
- Unix epoch seconds
- Unix epoch milliseconds
- Unix epoch microseconds
- Windows File Time
- Syslog timestamp
- Vendor-defined
- Unknown or mixed

Report:
- Standard name
- Exact literal pattern
- Splunk strptime pattern
- Precision: seconds, milliseconds, microseconds, nanoseconds or other
- Timezone representation: Z, numeric offset, named zone, abbreviation or absent
- Locale dependence
- Ambiguity or parsing risks

3. Derive the Splunk timestamp settings

TIME_PREFIX
- Identify stable text immediately before the selected timestamp.
- Provide the narrowest reliable regular expression.
- Use ^ when the timestamp begins the event.
- Explain why the prefix is safe across the supplied samples.

TIME_FORMAT
- Provide the Splunk strptime expression matching the raw timestamp.
- Preserve literal separators.
- Use the correct fractional-second token supported by Splunk.
- Include the timezone token only when it exists in the raw value.

MAX_TIMESTAMP_LOOKAHEAD
- Show the character-count calculation.
- Count from the first character after TIME_PREFIX to the end of the longest valid timestamp.
- Provide the final integer.
- State whether a safety margin is necessary and why.

TZ
- If the timestamp contains Z or an explicit numeric offset, normally return: not required.
- If the timestamp lacks a zone but the source timezone is supplied, return the appropriate IANA timezone, for example Australia/Sydney.
- If the timezone cannot be proven, return: unresolved — deployment input required.
- Do not infer timezone from an IP address, hostname or organisation name alone.

4. Produce the proposed props.conf stanza

Use this exact structure:

[sourcetype_name]
TIME_PREFIX = <regular expression>
TIME_FORMAT = <Splunk strptime pattern>
MAX_TIMESTAMP_LOOKAHEAD = <integer>
TZ = <IANA timezone, only when required>

Replace sourcetype_name with the supplied sourcetype. If no sourcetype is supplied, use [replace_with_sourcetype].

Only include settings supported by the evidence. If a setting should be omitted, show it separately under “Omitted settings and rationale” rather than placing it in the stanza.

5. Validate the proposal
Explain:
- Which samples match the proposed configuration
- Any samples that do not match
- Whether multiline events affect timestamp discovery
- Whether mixed timestamp formats require separate sourcetypes or routing
- Whether the timestamp could be truncated by MAX_TIMESTAMP_LOOKAHEAD
- How to verify in Splunk that _time equals the source event time
- Any daylight-saving implications
- Any risk of Splunk falling back to previous-event time, file time or index time

Required output

A. Executive conclusion
- Selected event timestamp
- Detected standard
- Confidence: High, Medium or Low

C. Derived settings table
Columns:
Setting | Proposed value | Evidence | Calculation or rationale | Confidence

D. Proposed props.conf stanza

E. Omitted settings and rationale

F. Validation findings and exceptions

G. Assumptions, unresolved inputs and recommended test cases

Example

Raw event:
2026-07-21T08:00:11.902+10:00 INFO event_type=login_attempt user=ADAM.SMITH

Expected analysis:
- Standard: ISO 8601 extended / IETF RFC 3339-compatible
- Precision: milliseconds
- Timezone: explicit numeric UTC offset
- TIME_PREFIX: ^
- TIME_FORMAT: %Y-%m-%dT%H:%M:%S.%3N%:z
- MAX_TIMESTAMP_LOOKAHEAD: 29
- TZ: not required because the raw timestamp contains an explicit offset

Example props.conf:

[replace_with_sourcetype]
TIME_PREFIX = ^
TIME_FORMAT = %Y-%m-%dT%H:%M:%S.%3N%:z
MAX_TIMESTAMP_LOOKAHEAD = 29

Data Source Assurance

AI prompt for assessing collection reliability, governance, monitoring and sustained fitness.

Copilot Prompt — Data Source Assurance Score

You are a security logging assurance analyst. Assess whether the supplied data source is reliably collected, monitored, governed and fit for sustained security use.

Assess
- Source ownership and accountability
- Collection-path documentation
- Authentication and secret management
- Transport security
- Availability and freshness monitoring
- Volume/EPS baselines and anomaly detection
- Parsing and schema monitoring
- Completeness and gap detection
- Retry, checkpoint and recovery behaviour
- Duplicate prevention
- Change management and version control
- Access control and segregation of duties
- Retention and legal obligations
- Operational runbooks, alerting and escalation
- Periodic validation and evidence retention

Score each applicable control from 0 to 4:
0 absent; 1 ad hoc; 2 partially implemented; 3 implemented and evidenced; 4 measured, automated and regularly assured.

Rules
- Score only from supplied evidence.
- Mark controls not evidenced as unknown rather than assuming implementation.
- Separate design claims from operational evidence.
- Identify mandatory control failures.

Calculation
Data Source Assurance = weighted achieved points ÷ weighted possible points × 100. Apply supplied control weights; otherwise use equal weights.

Return
1. Assurance summary and scope.
2. Control table with score, evidence, owner, gap and remediation.
3. Overall score and maturity rating.
4. Mandatory failures and operational risks.
5. Evidence required to raise confidence.
6. Prioritised assurance plan.
7. Confidence and limitations.

Log Onboarding Viability

AI prompt for assessing security value, technical readiness, operational assurance and complexity.

Copilot Prompt — Log Onboarding Viability Score

You are a senior SIEM onboarding architect. Assess whether the proposed log source is viable for onboarding and identify the conditions required for a successful implementation.

Assess the three parent areas used by LATCH:
1. Security Value — required use cases, event types, fields, documentation, schema and expected cyber benefit.
2. Technical Readiness — sample availability, volume/EPS knowledge, transport and ingestion method, authentication, network path, formatting, parsing and platform supportability.
3. Operational Assurance — ownership, monitoring, support model, resilience, change management, retention and ongoing validation.

Also assess engagement complexity across
- Transport and ingestion
- Data formatting and parsing
- Volume and variability
- Use-case and value mapping
- Engineering complexity

Rules
- Use only supplied evidence.
- Record unknowns explicitly.
- Do not treat a custom integration as impossible, but score its supportability and engineering burden accurately.
- Identify blocking conditions separately from weighted score.
- Do not award value solely because data can technically be collected.

Scoring
Use the LATCH rubric supplied with the assessment. Where no rubric is provided, score each question from 0 to 4 and normalise each parent area to 0–100. Calculate the overall score using the supplied parent weights; otherwise report parent scores separately rather than inventing weights.

Return
1. Executive viability decision.
2. Parent-area scores and evidence.
3. Question-level table with score, evidence, uncertainty and action.
4. Mandatory blockers.
5. Engagement complexity rating.
6. Required discovery, engineering and governance actions.
7. Recommendation: proceed, proceed with conditions, discovery required, defer or not viable.
8. Confidence and limitations.

Cyber Value Index

Copilot prompt for calculating the weighted overall cyber value of logging from ETC, RFC, ECCS and DQS.

Copilot Prompt — Cyber Value Index (CVI)

You are a cyber security logging analyst specialising in SIEM logging assurance, threat detection engineering, cyber logging maturity and security data quality.

Analyse the supplied sample log events and calculate the Cyber Value Index (CVI).

The purpose of the Cyber Value Index is to provide a single objective score that measures the overall cyber value of logging data by combining four independent measures of logging quality:

* Event Type Coverage (ETC)
* Required Field Coverage (RFC)
* Event Context Completeness Score (ECCS)
* Data Quality Score (DQS)

The CVI converts logging quality into a measurable indicator of investigation readiness, detection capability and cyber value.

⸻

CVI Components

The Cyber Value Index is calculated from four weighted components.

Component	Weight
Event Type Coverage (ETC)	30%
Required Field Coverage (RFC)	25%
Event Context Completeness Score (ECCS)	25%
Data Quality Score (DQS)	20%

⸻

Step 1 — Calculate Event Type Coverage (ETC)

Determine how well the supplied logging captures the required security event types.

Evaluate:

* Authentication
* Identity Management
* Access
* Configuration
* Administrative Activity
* Process Execution
* Network Activity
* Data Access
* Security Events
* System Events
* Availability
* Cloud Activity
* Detection Events
* Technology-specific event types

Calculate:

ETC (%) =
(Number of Required Event Types Captured ÷ Total Required Event Types) × 100

⸻

Step 2 — Calculate Required Field Coverage (RFC)

Determine whether required investigative fields are consistently present.

Assess:

* Event Time
* User
* Source IP
* Destination IP
* Host
* Event Type
* Action
* Result
* Severity
* Session ID
* Correlation IDs
* Required technology-specific fields

Calculate:

RFC (%) =
(Number of Required Fields Present ÷ Total Required Fields) × 100

⸻

Step 3 — Calculate Event Context Completeness Score (ECCS)

Assess how completely the events answer the seven key investigative questions.

Score each from 0–4.

The seven dimensions are:

* When
* Who
* Where
* What
* Outcome
* Impact
* Correlation

Calculate:

ECCS (%) =

((Total Score ÷ 28) × 100)

⸻

Step 4 — Calculate Data Quality Score (DQS)

Assess the technical quality of the supplied logs.

Score each from 0–4.

Dimensions:

* Timestamp Quality
* Parsing Success
* Consistency
* Normalization
* Completeness

Calculate:

DQS (%) =

((Total Score ÷ 20) × 100)

⸻

Step 5 — Calculate Cyber Value Index

Use the weighted formula.

CVI Formula

CVI =

(ETC × 0.30)

(RFC × 0.25)

(ECCS × 0.25)

(DQS × 0.20)

⸻

Example

Suppose:

ETC = 70%

RFC = 75%

ECCS = 64%

DQS = 65%

Then

CVI

=

(70 × 0.30)

(75 × 0.25)

(64 × 0.25)

(65 × 0.20)

=

21.0

18.75

16.0

13.0

=

68.75%

⸻

Determine Rating

CVI	Rating
0–39%	Poor
40–59%	Weak
60–74%	Adequate
75–89%	Good
90–100%	Excellent

⸻

Assessment Guidance

Do not simply calculate a percentage.

Assess whether the logging provides genuine cyber value by considering:

* Detection capability
* Investigation readiness
* Incident response support
* Threat hunting capability
* Correlation opportunities
* Data reliability
* Logging maturity
* Compliance readiness
* Operational usefulness

Explain how each component contributes to the overall score.

Identify which component is currently limiting the Cyber Value Index.

⸻

Output Format

Cyber Value Index (CVI)

Overall Score

Component	Score	Weight	Weighted Contribution
Event Type Coverage (ETC)	XX%	30%	XX.X
Required Field Coverage (RFC)	XX%	25%	XX.X
Event Context Completeness (ECCS)	XX%	25%	XX.X
Data Quality Score (DQS)	XX%	20%	XX.X

⸻

Final Result

* Cyber Value Index: XX%
* Rating: Poor / Weak / Adequate / Good / Excellent

⸻

Component Summary

Event Type Coverage (30%)

Summarise:

* Coverage achieved
* Missing event types
* Detection blind spots
* Impact on investigations

⸻

Required Field Coverage (25%)

Summarise:

* Missing required fields
* Field consistency
* Parsing issues
* Investigation impact

⸻

Event Context Completeness (25%)

Summarise:

* Strengths across the seven investigative dimensions
* Missing context
* Correlation capability
* Incident response readiness

⸻

Data Quality (20%)

Summarise:

* Timestamp quality
* Parsing quality
* Consistency
* Normalization
* Completeness

⸻

Strengths

Summarise the strongest aspects of the supplied logging that contribute positively to cyber value.

⸻

Key Gaps

Identify the most significant weaknesses reducing the Cyber Value Index.

Examples include:

* Missing event types
* Missing required fields
* Poor event context
* Weak correlation identifiers
* Timestamp issues
* Parsing failures
* Inconsistent formats
* Missing normalization
* Incomplete events

⸻

Improvement Roadmap

Prioritise improvements based on the greatest expected increase in the Cyber Value Index.

For each recommendation include:

Priority	Recommendation	Improves	Estimated CVI Increase
High	…	ETC / RFC / ECCS / DQS	+X%
Medium	…	…	+X%
Low	…	…	+X%

⸻

Executive Summary

Provide a concise assessment of the overall cyber value of the supplied logging. Explain whether the logs provide sufficient visibility for effective threat detection, investigations, incident response, threat hunting and compliance. Highlight the strongest areas, identify the component that most limits the current Cyber Value Index, and recommend the highest-priority improvements that would deliver the greatest increase in measurable cyber value.

Business Impact Level (BIL)

AI prompt for assessing Confidentiality, Integrity and Availability impact and deriving an overall BIL rating.

Copilot Prompt — Assess Business Impact Level (BIL)

You are a senior security governance analyst specialising in data classification and business impact assessment.

Assess the Business Impact Level (BIL) of the supplied data source or system description across Confidentiality, Integrity and Availability, and derive the overall rating and its rationale.

Evidence rules
- Use only the supplied source/system description and stated organisational context.
- Do not infer likelihood, threat actor capability or existing controls -- BIL is a consequence-only rating, independent of probability (that belongs to Risk Assessment, TAX-02.04.01).
- Do not blend Confidentiality, Integrity and Availability into an average; the overall rating is the highest (worst-case) of the three, not a mean.
- If the organisation's own BIL-to-classification table is not supplied, use the illustrative scale below and flag that the mapping is illustrative, not an asserted external standard.
- State uncertainty rather than inventing detail not present in the supplied description.

Tasks

1. Assess Confidentiality impact
What harm results if this data is disclosed to someone not authorised to see it? Consider exposed credentials, privileged-account activity, personal information, commercially sensitive detail.

2. Assess Integrity impact
What harm results if this data is altered or fabricated without detection? Consider falsified audit evidence, tampered financial records, a masked security event.

3. Assess Availability impact
What harm results if this data becomes inaccessible when needed? Consider a blocked investigation, a missed compliance deadline, an unrecoverable incident timeline.

4. Determine the overall rating
Take the highest (worst-case) of the three dimension ratings. Identify and state the driving dimension and why -- the rationale is what makes the rating defensible and repeatable, not the number alone.

5. Derive the indicative classification
Use this scale unless an organisational BIL-to-classification table is supplied:

BIL 1 — No or negligible harm — OFFICIAL
BIL 2 — Limited damage — OFFICIAL: Sensitive
BIL 3 — Damage — PROTECTED
BIL 4 — Serious damage — PROTECTED (upper band)
BIL 5 — Exceptionally grave damage — SECRET
BIL 6 — Catastrophic / exceptional national-level damage — TOP SECRET

Required output

A. Executive conclusion
- Overall BIL
- Driving dimension
- Indicative classification
- Confidence: High, Medium or Low

B. Dimension assessment table
Columns: Dimension | Finding | Rating rationale

C. Overall BIL derivation
Show the highest-dimension logic explicitly -- do not average.

D. Indicative classification
State the mapped classification and note that the organisation's own approved BIL-to-classification table is the governing reference, not this illustrative scale.

E. Relationship notes
Confirm this assessment is the input to Data Classification (TAX-02.02.06), not a substitute for recording it, and that it is not a probability-weighted Risk Assessment (TAX-02.04.01).

F. Assumptions and unresolved inputs

Username / Principal Format

AI prompt for classifying a raw username/principal value against the format catalogue using detector precedence order.

Copilot Prompt — Classify Username / Principal Format

You are a senior identity and log-normalisation analyst.

Analyse the supplied raw username/principal value(s) and classify each against the Username / Principal Format catalogue, using the detector precedence order to resolve ambiguous matches.

Evidence rules
- Use only the supplied raw value(s) and stated source context (sourcetype, vendor, protocol).
- Several formats share an identical regex (UPN, Email address and NAI, for example) and are genuinely indistinguishable by value alone; use source context to disambiguate, and say so explicitly when you do.
- Test formats in detector precedence order and return the first match, not just any match.
- Do not invent a source context that was not supplied to break a tie.
- If a value matches nothing in the catalogue, say so rather than forcing the closest fit.

Tasks

1. For each supplied value, list every catalogue format whose regex matches.
2. Apply detector precedence order and select the first (most specific) match.
3. State the category (SAML protocol, Cloud IAM, Windows/AD, Entra/Azure AD, Kerberos, Social/Fediverse, etc.).
4. Flag genuinely ambiguous cases (identical regex across formats) where source context, not the value, was the deciding factor.
5. Note any value that matches no catalogue entry.

Required output

A. Executive conclusion
Format classification per value, with confidence.

B. Per-value match table
Columns: Value | Candidate matches | Selected format | Category | Deciding evidence

C. Ambiguity notes
Any values resolved by source context rather than value shape alone.

D. Unmatched values
List any values that matched nothing, and the recommended next step.

E. Assumptions and unresolved inputs

Field Extraction

AI prompt for determining the extraction method and pipeline stage (search-time or index-time) for a set of target fields.

Copilot Prompt — Determine Field Extraction Method and Pipeline Stage

You are a senior Splunk parsing engineer.

Analyse the supplied representative raw events and the target field list, and determine the extraction method and pipeline stage (search-time or index-time) for each field.

Evidence rules
- Use only the supplied raw events and stated target fields.
- Default to search-time extraction; only recommend index-time extraction (INDEXED_EXTRACTIONS, a custom WRITE_META stanza, or INGEST_EVAL) when a specific operational reason is evident -- event routing, access-control decisions that must happen before search, or search cost at volumes where repeated search-time computation is measurably too expensive.
- State that reason explicitly whenever index-time is recommended; do not recommend it merely because it is fastest.
- Do not recommend indexed extraction of an entire structured event when only one or two custom fields actually need to be indexed.
- Check whether a field is already covered by INDEXED_EXTRACTIONS, KV_MODE or an existing EXTRACT-*/REPORT-* before proposing a duplicate.

Tasks

1. For each target field, identify where in the raw event it appears and whether it is regex-extractable, delimiter-positional, or requires a calculation.
2. Recommend the extraction method: EXTRACT-*/REPORT-* (regex), KV_MODE, DELIMS, INDEXED_EXTRACTIONS, a custom WRITE_META stanza, or INGEST_EVAL.
3. Justify the pipeline stage -- search-time by default; index-time only with a stated operational reason.
4. Produce the proposed props.conf and, where required, transforms.conf stanza.
5. Flag any field name that collides with a reserved or default field (host, source, sourcetype, index, _time, punct).

Required output

A. Executive conclusion
Per-field method and stage, with confidence.

B. Field analysis table
Columns: Field | Location in raw event | Extraction method | Stage | Index-time justification (if applicable)

C. Proposed props.conf

D. Proposed transforms.conf
Only if required.

E. Validation findings
Duplicate-extraction risk, reserved-field collisions.

F. Assumptions and unresolved inputs

Retention Policy

AI prompt for deriving indexes.conf bucket-lifecycle settings from a stated retention period and ingest volume.

Copilot Prompt — Derive Retention Policy and indexes.conf Settings

You are a senior Splunk platform engineer specialising in data lifecycle and retention.

Given the supplied retention requirement (approved retention period, ingest volume, and any archival or legal-hold requirement), derive the indexes.conf bucket-lifecycle settings that enforce it and identify whether secure deletion is required.

Evidence rules
- Use only the supplied retention period, volume and archival requirement; do not assume a platform-wide default applies without it being stated.
- Distinguish "deleted" from "archived": an index configuration with neither coldToFrozenDir nor coldToFrozenScript set permanently deletes data on freeze -- only recommend omitting both when deletion (not archival) is the explicitly stated intent.
- Size maxWarmDBCount and frozenTimePeriodInSecs together against ingest volume; a retention period alone does not determine bucket counts.
- If a compliance requirement (GDPR, HIPAA or similar) is stated, flag that secure erasure needs deciding at design time (encryption at rest), not left until deletion time.
- Do not recommend TRUNCATE, LINE_BREAKER or other parsing settings -- retention and parsing are separate concerns.

Tasks

1. Confirm the required retention period and whether archival (not deletion) is required at end of life.
2. Derive maxHotSpanSecs and maxDataSize appropriate to expected hot-bucket churn.
3. Derive maxWarmDBCount and frozenTimePeriodInSecs from the stated ingest volume and retention period.
4. Recommend maxTotalDataSizeMB as a safety bound.
5. Recommend coldToFrozenDir or coldToFrozenScript if archival is required; state explicitly if deletion-on-freeze is the intended behaviour instead.
6. Flag whether secure deletion requirements apply, and if so, which of bucket aging, encryption at rest, storage overwrite or physical destruction actually satisfies them.

Required output

A. Executive conclusion
Retention period enforced, archival vs. deletion, confidence.

B. Derived indexes.conf stanza

C. Settings rationale table
Columns: Setting | Value | Evidence

D. Secure-deletion assessment
Is the stated requirement met, and by which mechanism.

E. Validation findings and exceptions

F. Assumptions and unresolved inputs

Access Control

AI prompt for deriving a custom Splunk role (authorize.conf stanza) from stated user responsibilities and access requirements.

Copilot Prompt — Derive a Splunk Access Control Role

You are a senior Splunk platform security engineer.

Given the supplied user responsibilities and required index/data access, derive a custom Splunk role (authorize.conf stanza) built by importing from the nearest predefined role.

Evidence rules
- Use only the supplied responsibilities and stated access requirements.
- Build the custom role by importRoles from the nearest predefined role (admin, power or user) rather than duplicating capabilities from scratch.
- Do not grant can_delete unless bulk deletion of indexed data is an explicitly stated requirement -- treat it as high-risk and flag it for its own approval record.
- Scope srchIndexesAllowed to only the indexes the stated responsibilities require; do not default to wildcard access.
- Remember capabilities are additive only -- there is no explicit deny -- so state the full effective capability set including anything inherited via importRoles.
- Do not propose LDAP/SAML group mappings unless an identity provider and its groups are supplied.

Tasks

1. Identify the nearest predefined role (admin, power or user) to base the custom role on.
2. Determine the specific indexes required (srchIndexesAllowed, srchIndexesDefault).
3. Determine any additional capabilities required beyond the imported role, and any that should be explicitly disabled.
4. Recommend reasonable srchJobsQuota, srchDiskQuota and srchTimeWin bounds if the responsibilities suggest heavy or scheduled search usage.
5. Flag whether can_delete or any other high-risk capability is genuinely required, and note it needs its own Access Approval Reference entry if so.
6. If an identity provider is supplied, recommend the LDAP/SAML group-to-role mapping.

Required output

A. Executive conclusion
Proposed role name, imported base role, confidence.

B. Proposed authorize.conf stanza

C. Effective capability summary
Inherited vs. explicitly added.

D. High-risk capability flags
Any capability requiring its own approval record.

E. Validation findings and exceptions

F. Assumptions and unresolved inputs

Field Normalisation

AI prompt for deriving FIELDALIAS, EVAL, LOOKUP and tag mappings to bring a sourcetype into CIM compliance.

Copilot Prompt — Normalise Fields to a CIM Data Model

You are a senior Splunk CIM compliance engineer.

Given the supplied extracted fields and the target CIM data model, derive the field aliases, calculated fields, lookups and tags required to bring the sourcetype into compliance.

Evidence rules
- Use only the supplied extracted field names, sample values and target CIM data model.
- Check Splunkbase for a certified Technology Add-on's built-in CIM mapping before proposing a hand-rolled one; only propose custom FIELDALIAS/EVAL/LOOKUP/tags stanzas when none exists or the add-on's mapping is incomplete.
- Respect processing order: field extraction, then field aliasing (FIELDALIAS-*), then calculated fields (EVAL-*), then lookups -- an EVAL-* statement may reference an aliased field, but a FIELDALIAS may not reference a calculated field.
- One alias may map to only one source field; do not propose the same alias target from two different original fields in one stanza.
- Do not invent a CIM field name that is not part of the target data model's documented field list.
- Record CIM Mapping and ECS Mapping separately if both are required -- they are not the same schema and rarely need identical field names.

Tasks

1. Identify which of the target CIM data model's standard fields the supplied extracted fields correspond to.
2. Propose FIELDALIAS-* mappings for direct name correspondences.
3. Propose EVAL-* calculated fields for values needing transformation (status codes to success/failure, severities, and similar).
4. Propose a LOOKUP-* automatic lookup if enrichment from a reference table is required and evidenced.
5. Propose the tags.conf stanza needed to mark events as belonging to the target data model's dataset.
6. Identify any required CIM field with no corresponding source field, and flag it as a coverage gap rather than fabricating a mapping.

Required output

A. Executive conclusion
Target data model, overall coverage, confidence.

B. Field mapping table
Columns: Source field | CIM field | Mechanism (alias/eval/lookup) | Evidence

C. Proposed props.conf
FIELDALIAS-*, EVAL-*, LOOKUP-* stanzas.

D. Proposed tags.conf

E. Coverage gaps
Required CIM fields with no source mapping.

F. Assumptions and unresolved inputs

Punct Field Calculation

AI prompt for computing the Splunk punct field value for each sample event's first line, character by character.

Copilot Prompt — Compute the Splunk punct Field for Sample Events

You are a senior Splunk parsing engineer.

Given the supplied representative raw sample events, compute the Splunk punct field value for each event's first line, showing your character-by-character reasoning, then group events that would share an identical punct value.

Evidence rules
- Use only the supplied raw sample events.
- Apply punct to the FIRST LINE of each event only, not the whole event -- Splunk documents punct as "the pattern of the first thirty punctuation characters in the first line of the event," computed once per event from its first physical line.
- Punct is capped at the first 30 punctuation characters found on that first line; if the line has more than 30, truncate at 30 and say so explicitly.
- Strip every letter (a-z, A-Z) and every digit (0-9) entirely -- they contribute nothing to punct.
- Represent whitespace explicitly: a literal space becomes an underscore (_); a tab becomes a literal "t" character.
- Keep every other punctuation or symbol character (period, colon, comma, parentheses, brackets, quotes, question mark, exclamation mark, equals sign, ampersand, pipe, slash, backslash, hyphen, underscore, asterisk, plus, percent, hash, at-sign, caret, tilde, semicolon) as-is, in original order, subject to the exception below.
- Known implementation nuance (community-observed, not part of Splunk's formal field reference): a hyphen immediately following an alphanumeric character is commonly dropped rather than kept, similar to how a negative-number-looking or hyphenated token is not treated as standalone punctuation. Apply this rule, but flag every case where you applied it so it can be spot-checked, since it is reverse-engineered behaviour, not documented Splunk specification.
- Do not fabricate a punct value for an event whose first line has no punctuation at all -- state plainly that punct would be empty.
- Punct is computed at index time from the literal indexed text. If the supplied sample is a formatted or pretty-printed representation of the event rather than the literal raw bytes, note that the real indexed punct could differ.

Tasks

1. For each supplied event, isolate the first physical line -- this is the only part punct is computed from.
2. Walk the line character by character, classifying each one: letter/digit (dropped), space (converted to _), tab (converted to t), the dash-after-alphanumeric exception (dropped), or other punctuation/symbol (kept as-is).
3. Concatenate the kept/converted characters in original order, truncated to the first 30 punctuation characters.
4. Produce the resulting punct value for each event.
5. Group events by identical punct value to show which raw samples Splunk's punct-based grouping would treat as "the same shape," and separately flag any samples whose punct values are identical only because of the 30-character truncation (their first 30 characters match, but they would diverge further into the line).

Required output

A. Executive conclusion
Number of distinct punct values found across the supplied samples, with confidence.

B. Per-event working table
Columns: Event (first line only) | Character-by-character derivation notes | Computed punct value | Truncated? (Y/N)

C. Grouping
Events sharing an identical punct value, and what that implies for search-time grouping (a "| stats count by punct"-style analysis).

D. Flags
Every application of the dash-after-alphanumeric exception, and every case affected by 30-character truncation, called out explicitly for manual verification against a real Splunk instance.

E. Assumptions and unresolved inputs

Cyber monitoring framework

Cyber Monitoring Effectiveness Framework

The Cyber Monitoring Effectiveness Framework explains how valuable logging, effective threat detections, prepared response processes and reliable operational pipelines combine to support measurable monitoring effectiveness.

What is the Cyber Monitoring Effectiveness Index?

The Cyber Monitoring Effectiveness Index (CMEI) is the overarching model within this framework. It brings together four complementary indices. Each index answers a different question, preventing data quality, detection performance, response preparedness and operational reliability from being blended into a single unclear measure.

CVI

Cyber Value Index

Quality and usefulness of the logging data itself.

Event Type Coverage
Required Field Coverage
Event Context Completeness
Data Quality

TDI

Threat Detection Index

How effectively detections use the available data.

Technique Coverage
Rule Coverage (gate)
Validation
Fidelity
Latency

RRI

Response Readiness Index

Preparedness for investigation and incident response.

Runbook Readiness
Ownership Readiness
Evidence Availability (gate)
Escalation Readiness
Response & Recovery Capability

OAI

Operational Assurance Index

Health, reliability and operational maturity of the logging pipeline.

Availability
Timeliness
Health Checks (gate)
Supportability
Maintenance

How the indices fit together

CMEI provides an executive view of monitoring effectiveness while retaining each component index as an independently explainable assessment.

CVIIs the data valuable and investigation ready?

TDIAre threats detected effectively using that data?

RRICan analysts and responders act effectively?

OAIIs the monitoring pipeline reliable and supportable?

CMEI — Overall Cyber Monitoring Effectiveness

Onboarding · TAX records

Onboard taxonomy

Every term a log source is described by, from platform and ownership through collection, parsing, detection and lifecycle. Search the terms or the values already recorded, select a term to see its definition, and export the TAX records.

– taxonomy terms – current entries – populated sources – reference source families – governed logging patterns – reusable health checks

Click a row to open its full definition and notes in the panel on the right.

Code	Term	Domain	Entity type	Status

Reference · Splunk Object Taxonomy (SOT)

Splunk Object Taxonomy

A hierarchical taxonomy of every kind of object that exists across the Splunk universe -- describing what each object is, organised into 14 SOT-01–SOT-14 domains (each with class → subclass levels down to the object itself), independent of this app's own LATCH TAX-XX taxonomy. Attributes like scope, config file, dependencies and lifecycle live on the object as properties rather than as branches of the classification. Use the Tree Explorer for the hierarchy, or the Table View for a flat, filterable catalogue.

Click a row to open its full definition and notes.

Object	SOT code	Domain	Type	Scope	Config file / location

Object names, config files and scopes reflect Splunk Enterprise/Cloud platform conventions as of Splunk 9.x/10.x; verify against your specific version's documentation before relying on an exact setting name. Attributes shown as To be confirmed (Owner, Cloud/Enterprise support, Namespace/App, Mutable, Exportable, Security relevance, Configuration layer, Platform) have no derivable value in the current catalogue and are placeholders for future enrichment, not fabricated data. A few nodes carry explicit cross-references between this taxonomy and the LATCH TAX-XX taxonomy (e.g. TAX-03.06.03.01 Collection Mode ↔ SOT-05.01.01 Data Input/SOT-05.01.06 Modular Input) -- click a related-code pill on either side to jump across.

Lifecycle, Assurance & Dependency · TAX-06.03.02

Data Source Assurance

Operational assurance view centred on configured input components. It joins collection configuration, current test results, CIM compliance, detection coverage, dependencies and lifecycle evidence without duplicating the underlying taxonomy records. Select a source to review its end-to-end assurance profile or open the source directly in the taxonomy explorer.

Operational sources

Input components are the primary operational assurance record until a dedicated Data Sources register is populated.

0 visible

Component	Data source	Input type	Platform	Owner	Health	CIM	Detection	Assurance

Onboarding pipeline

Lifecycle records remain separate from deployed components until a stable component or data-source identifier is assigned.

0 visible

Request	Data source	Requestor	Business owner	Input type	Platform	Index	Sourcetype	Stage	TA	CIM	Health tests	UAT	Target date

Lifecycle, Assurance & Dependency · TAX-06.01.02

Log Onboarding Viability Assessment

Phase 1 decision gate used during the initial consultation. It separates security value from technical readiness, operational assurance and implementation effort, then applies supportability, custom-solution, reverse-engineering and discovery modifiers before a source proceeds to detailed design.

Interactive phase gate

Viability calculator

Enter consultation findings to calculate the viability score, question-based security value, question-based technical readiness, question-based operational assurance, supportability impact, reverse-engineering trigger, transport/ingestion complexity, data formatting/parsing complexity, log volume/EPS complexity, analytics/use-case mapping complexity, engineering complexity, implementation effort and recommended next action before detailed design.

Platform

Data source

Owner

Recommended logging pattern Optional. Select the currently preferred pattern so it appears in the exported result.

Security value Calculated from questions Answer the security value questions below. N/A answers are excluded.

Technical readiness Calculated from questions Answer the technical readiness questions below. N/A answers are excluded.

Operational assurance Calculated from questions Answer the operational assurance questions below. N/A answers are excluded.

Security value questions15 scored questions

These answers calculate the Security Value percentage. Use High/confirmed only when the source has clear business, detection, compliance or incident-response value; use Low/unknown when the value is assumed or not yet proven.

Approved security / business use case

Log coverage for the use case

Detection engineering value

Compliance / audit requirement

Incident-response value

Platform / asset criticality

Identity / asset context

Threat scenario relevance

Uniqueness / gap closure

SOC actionability

Admin / configuration events

Authentication / access events

Security alerts / severity

Retention / forensic value

Stakeholder priority

Technical readiness questions19 scored + complexity factors

These answers calculate the Technical Readiness percentage. Each question asks whether the source has enough evidence to move from viability into design/build. Use Confirmed/ready only when evidence is available; use Partial when a design assumption still needs validation.

Is a custom solution required?Select Yes when the source cannot use a certified TA, supported API input, standard syslog/agent path, or other repeatable ingestion method.

Custom or integration approachDescribe the likely build path, such as supported add-on/API, custom REST polling, custom parser, routing logic, or still to be confirmed.

Documentation availability & accessibilityAssess whether product, API, audit-log and integration documentation is easy to access, current, searchable and usable by the onboarding team.

Data schema availability & accessibilityAssess whether field dictionaries, API schemas, table layouts, object relationships, data types and constraints are documented and accessible.

Sample events available for validationUse Yes only when real or representative raw events are available for parsing, timestamp, field, CIM and detection validation.

EPS / volume estimate confidenceAssess whether expected EPS, daily GB, peak bursts and retention/cost impact are known enough for sizing and approval.

Source integration or export pathCan the source reliably send, expose or export the required logs through a supported connector, API, syslog, database or file path?

Splunk / vendor support pathIndicates whether onboarding can use a certified Splunk TA, a standard vendor export/API, a custom integration, or no known supported path.

Log location and accessDo we know where the events live, which event types are needed, and whether the collection account or collector can access them?

Log enablement and licensingConfirms whether the required audit/security logs are enabled and whether any licence, plan, feature flag or subscription is required.

Source platform prerequisitesChecks whether required tenant IDs, subscriptions, endpoints, namespaces, database details, scopes, APIs or source-side settings are known.

Authentication and credential modelConfirms the credential method, approval path and ownership for API keys, OAuth apps, service accounts, certificates or tokens.

Network and firewall pathConfirms ports, proxy, allowlists, private endpoints, routing and firewall/security-zone paths between the source, collectors and Splunk.

Encryption and certificate trustChecks TLS, certificate chain, mTLS, CA trust, certificate ownership and whether encryption meets platform/security requirements.

Raw event structure / data formatDescribes how predictable the raw data is, such as JSON, CEF, key-value, syslog, CSV, multi-line or proprietary text.

Timestamp and timezone qualityConfirms whether event time is present, parseable, accurate, timezone-aware and not dependent on ingestion time.

Parser and sourcetype readinessChecks whether a TA, parser, sourcetype, props/transforms or field extraction approach already exists or must be created.

Required fields knownConfirms the fields needed for detection, CIM, entity mapping and investigation, such as user, src, dest, action, status and object.

CIM / detection mappingConfirms whether fields can map to Splunk CIM or the detection schema needed by existing correlation searches and dashboards.

Capacity and cost impactAssesses whether expected storage, licence, index, retention, filtering and infrastructure impact are known and accepted.

Routing and architecture fitConfirms the target architecture, such as direct to Splunk Cloud/on-prem, heavy forwarder, syslog server, ingest processor or security-zone intermediary.

Technical complexity factors. These answers sit under Technical readiness but remain separate from the Technical Readiness percentage. They continue to calculate transport, parsing, volume/EPS, analytics, engineering complexity and overall implementation effort.

Transport & ingestion method complexity1 complexity input

This answer calculates the transport part of implementation complexity. Low = native/cloud connector or standard vendor API. Medium = standard syslog or a lightweight pre-configured agent. High = custom REST/script/webhook, database polling/JDBC, or air-gapped collection.

Transport & ingestion method

Calculated transport complexity Calculated from transport method Select the transport and ingestion method.

Data formatting & parsing complexity1 complexity input

This answer calculates the parsing part of implementation complexity. Low = natively supported vendor formats or structured JSON/CEF where a parser exists. Medium = semi-structured logs or custom apps needing parser modifications. High = unstructured raw text, multi-line logs or proprietary formats requiring complex regex from scratch.

Data formatting & parsing method

Calculated parsing complexity Calculated from data format Select the data formatting and parsing method.

Log volume & EPS complexity1 complexity input

This answer calculates the size part of implementation complexity. Low = low EPS and predictable volume. Medium = moderate or fluctuating volume needing basic load balancing or edge filtering. High = massive, noisy streams such as firewall traffic, DNS query logs or endpoint EDR telemetry that need dedicated forwarders, heavy filtering and storage planning.

Log volume & EPS profile

Calculated volume/EPS complexity Calculated from volume and EPS profile Select the expected log volume and EPS profile.

Analytics / use case & value mapping complexity1 complexity input

This answer calculates the analytics part of implementation complexity. Low = compliance-only storage or out-of-the-box vendor detection rules. Medium = mapping custom fields to a standard schema such as Splunk CIM, Elastic ECS or Microsoft Sentinel ASIM. High = brand-new multi-source correlation rules or behavior/anomaly analytics.

Analytics / use case mapping profile

Calculated analytics complexity Calculated from analytics mapping profile Select the expected use-case and analytics mapping profile.

Engineering complexitycalculated from existing answers

Engineering complexity is calculated from existing viability answers across ingestion architecture, parsing & normalisation, and maintenance & technical debt. It uses a 1–4 matrix: 1 = low, 2 = medium, 3 = high, 4 = very high. The equivalent implementation rating is also considered in the combined complexity calculation.

Ingestion architecture Calculated from existing answers Uses transport method, integration path, routing and network/firewall answers.

Parsing & normalisation Calculated from existing answers Uses parser availability, data format, fields and CIM/use-case mapping answers.

Maintenance & technical debt Calculated from existing answers Uses custom solution, supportability, documentation, runbook, monitoring and change-notification answers.

Calculated engineering complexity Calculated from engineering matrix The engineering score uses the highest score across ingestion, parsing and maintenance debt.

Combined implementation complexitycalculated summary

Implementation complexity uses the highest rating across transport/ingestion, data formatting/parsing, log volume/EPS, analytics/use-case mapping, engagement complexity and the engineering-complexity equivalent rating. Engagement complexity uses an evidence score out of 18: higher scores mean lower engagement complexity.

Calculated difficulty Calculated from answered questions Difficulty is derived from readiness blockers, discovery gaps, supportability, sample evidence and operational maturity.

Engagement complexity Calculated from engagement evidence score Uses documentation, schema, log location, integration support, parser readiness and custom/reverse-engineering pressure.

Combined calculated complexity Calculated from transport, parsing, volume/EPS, analytics, engagement and engineering The implementation complexity uses the highest rating across transport/ingestion, data formatting/parsing, log volume/EPS, analytics/use-case mapping, engagement complexity and engineering complexity.

Score range	Rating	Engagement complexity
15–18	Low Complexity	Logs are well documented, locations and schemas are known, and integration is strongly supported.
10–14	Medium Complexity	Some documentation or support exists, but validation, parsing, or custom work is required.
5–9	High Complexity	Limited documentation, unclear schemas, or weak integration support.
0–4	Very High Complexity	Significant discovery, reverse engineering, vendor engagement, or custom development required.

Operational assurance questions15 scored questions

These answers calculate the Operational Assurance percentage. Use Confirmed/ready only when ownership, support and operating evidence are known; use Partial when a support assumption still needs validation.

Business / platform owner

Technical owner

Support model

Custom-solution support ownership

Runbook / operating procedure

Failure monitoring

Data-quality monitoring

Credential / certificate rotation

Privacy / compliance handling

Index / retention ownership

Change-management path

Schema / API change notification

Testing / acceptance criteria

Escalation path

Operational handover

Phase 1 viability records

Use these records to hold or progress onboarding before schema, fields, collection mechanisms and support responsibilities are fully defined.

0 visible

Assessment	Platform	Data source	Decision	Supportability	Score	Custom	Reverse eng.	Effort	Next action

Data Collection & Routing · TAX-03.01.01

SIEM Data Source Catalogue

Reference catalogue of the security and operational source families the SIEM should cover. Catalogue records describe intended telemetry, ACSC/ISM-aligned event types and use-case value; explicit mappings connect them to configured input components, current assurance results and onboarding work without treating reference requirements as deployed inputs.

Clean event requirements export Exports one row per required/recommended event type, grouped by category, source, focus group and critical collection focus.

Reference source families

Coverage is derived from approved stable-ID mappings to operational components, onboarding records and registered platforms. Event type counts come from the Event_Type_Matrix tab.

0 visible

Source	Category	Sub-category	Priority	Event types	Coverage	Implementations	Onboarding	Assurance

Data Collection & Routing · TAX-03.02.01

Logging Patterns Table

Compare all 39 governed logging patterns, including conditional port/firewall, authentication and source-platform prerequisites. Filter by destination or category, search across every field, export the visible records, or select a Pattern ID to open its full taxonomy detail. Ports shown are common defaults and must be validated against the approved local design.

Taxonomy alignment (per column)

Every pattern below is itself an instance of TAX-03.02.01 Logging Pattern (its Pattern ID is the instance's own primary key, browsable in Tree Explorer). The other twelve columns each describe an attribute governed by a more specific taxonomy code -- this mapping holds for every row, so it's shown once rather than repeated per pattern.

Table column	Governing taxonomy code
Pattern ID	TAX-03.02.01 Logging Pattern — the instance's own primary key
Pattern	TAX-03.02.01 Logging Pattern — the instance's own name
Source data	TAX-03.01.01 Data Source
Category	TAX-03.03.01 Input Component — generic, no dedicated category field
Direction	Not modeled — closest is TAX-03.02.06.04 Initiating Direction / TAX-03.04.03 Polling Interval (pull-based collectors)
Source mechanism	TAX-03.03.01 Input Component
Collection tier / runtime	TAX-03.03.02 Collector
Transport	TAX-03.02.02 Transport; TAX-03.02.02.01 Transport Reliability Requirement
Destination	TAX-03.01.03 Index Destination
Required app / add-on	TAX-03.03.03 App & Technology Add-on
Port / firewall requirements	TAX-03.02.06 Firewall Rule (+ Source/Destination Network Zone, Initiating Direction, Stateful Return Traffic)
Authentication requirements	TAX-03.05 Data Collection Authentication
Source platform requirements	TAX-03.04 Collection Configuration (Input Stanza, Input Parameters, Source-side Logging Configuration)

39 visible patterns 20 Splunk Cloud 19 Splunk on-premises 13 comparison columns

Pattern ID	Pattern	Source data	Category	Direction	Source mechanism	Collection tier / runtime	Transport	Destination	Required app / add-on	Port / firewall requirements	Authentication requirements	Source platform requirements

Data Engineering & Parsing · TAX-04.10.01

Health Checks Table

Review all 678 reusable health-check templates, spanning per-input pipeline checks (event-quality, multi-host, Ingest Processor, Splunk Stream, REST/script, Universal Forwarder, osquery, Sysmon, raw TCP, syslog-server file collection, Azure Function, AWS Lambda, Heavy Forwarder and more) plus Splunk platform checks: security/upgrade-readiness (TLS, certificates, app compatibility, Python runtime), and operational health for Search Head, Indexer/Indexer Cluster, Forwarder Platform, Deployment Server, License Master, Cluster Master and Monitoring Console. Search across every field, filter by input type, category, subcategory or priority, export the visible records, or select a Test ID to open its complete taxonomy detail. Where a check's purpose matches an existing pattern in the companion Splunk SPL Library, the SPL Library column links straight to that reusable query. The Personal SPL Notes column additionally flags checks that match a browser-local custom entry (personal notes, not published on the public site) by name and original source query -- shown for reference only, since no public link exists for those.

678 visible health checks 321 critical 644 automated 58 input types 0 linked to SPL Library 0 matched in personal SPL notes 17 comparison columns

Test ID	Input type	Test name	Category	Subcategory	Description	Priority	Pass criteria	Failure action	Automation	Frequency	SPL query / definition	Thresholds	Lookback window	Owner	SPL Library	Personal SPL Notes

Network reference

Splunk Component-to-Component TCP Ports Matrix (Expanded)

A source-component-to-destination-component cross-matrix of the TCP ports Splunk components use to talk to each other. Ports shown are the destination component's listening ports; source ports are ephemeral unless otherwise noted. This complements the Splunk Ports and Network Flow Matrix tables under Reference → Network reference -- those list ports and flows as flat rows; this page lays the same information out as a component × component grid.

Your environment's ports Using Splunk defaults

If your environment has moved a Splunk listener off its default port, enter the port you actually use. The matrix, flow schema table, cell details and every export will show your ports. Custom ports only apply to flows into customer-run Splunk components (Core Platform Roles). Splunk Cloud, SaaS and third-party endpoints keep their fixed ports. Saved in this browser.

Expanded Cross-Matrix

52 / 52 components shown 190 / 190 flows shown

Flow types: ING Ingest MGMT Management CLU Cluster SRCH Search AUTH Authentication LIC Licensing REPL Replication API External API INFRA Infrastructure ACC User Access ALRT Alerting CCP Cloud Control Plane

Column/row groups (click to isolate):

TLS defaults (optional overlay, "Show TLS defaults" above): 🔒 TLS: On encrypted by default everywhere 🔒 TLS: Cloud only Cloud: on · Enterprise: off 🔒 TLS: Capable supported on this port, not on by default Sourced from three places: Splunk's TLS scenarios table (9 On, 3 Cloud-only), this matrix's own port wording for dual plaintext/TLS options -- 9997 within Core Platform Roles, LDAP/LDAPS to the LDAP / AD Server column, Kafka's 9092/9093, SMTP Relay's 25/465/587, User's Splunk Web UI at 8000/8443, 9887 among the SHC and indexer-cluster replication ports, Syslog's 514/6514, and Database Server (JDBC)'s same-port TLS negotiation (23 Capable total), plus HTTP Event Collector's HTTPS-by-Splunk-default on 8088/443 (9 more On) -- and every remaining populated cell whose port is 443 (HTTPS) or 8089 (splunkd's management/REST API, HTTPS by Splunk default) -- both TLS by definition/default (102 more On). Together these cover 146 of the matrix's 190 populated flows; the other 44 aren't badged simply because none of these three sources describe them, not because they're unencrypted.

Source ↓ / Destination →	Universal Forwarder (UF)	Heavy Forwarder (HF)	Indexer / IDX Peer	Search Head / SHC Member	Deployment Server (DS)	Cluster Manager (CM)	License Manager (LM)	Deployer	Splunk Stream Server	Splunk Stream Forwarder (Client)	Monitoring Console (MC)	Edge / Ingest Processor	User	Syslog Source	HEC Client (Application)	Admin / API Client	LDAP / AD Server	SAML IdP	DNS Server	NTP Server	SMTP Relay	Internet / Proxy	CA / CRL / OCSP (PKI Validation)	Syslog Collector (SC4S / rsyslog / syslog-ng)	Load Balancer / Reverse Proxy	Database Server (JDBC)	Azure Event Hub	AWS S3	AWS SQS	AWS STS	AWS KMS	AWS Glue	Vendor / Source API (External REST/HTTPS)	Kafka	AWS Kinesis	Azure Storage / ARM	Microsoft Graph	Google Cloud APIs / Pub/Sub	SNMP Manager / Trap Receiver	OpenTelemetry Collector	Container / Kubernetes API	Splunk Cloud	Splunk SOAR / SOAR Cloud	Splunk Enterprise Security / Mission Control (Cloud)	Splunk ACS (Admin Config Service)	Splunk Observability Cloud	Splunkbase / Update Service	Webhook Destination	Ticketing / ITSM API	TAXII Server (Threat Intelligence)	Proxy Authentication Service	Git Host (GitHub / GitLab / Azure DevOps)
Universal Forwarder (UF)	—	ING 9997 (S2S, TCP, optionally TLS)	ING 9997 (S2S, TCP, optionally TLS)	—	MGMT 8089 (mgmt / phone-home / apps)	—	—	—	—	—	—	—	—	—	—	—	—	—	INFRA 53 (DNS, UDP/TCP)	INFRA 123 (NTP, UDP)	—	INFRA 443 (HTTPS, apps/updates/cloud APIs)	INFRA 80 / 443 (CA / CRL / OCSP, TLS certificate validation)	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	ING 9997 (S2S, TCP) -- conventional default; verify the actual forwarding endpoint/port for your Splunk Cloud stack	—	—	—	—	MGMT 443 (HTTPS, app/update download)	—	—	—	INFRA environment-specific (often the proxy's own listener, e.g. 3128/8080)	—
Heavy Forwarder (HF)	—	ING 9997 (S2S, TCP, chained/intermediate forwarding, optionally TLS)	ING 9997 (S2S, TCP, optionally TLS)	—	MGMT 8089 (mgmt)	—	LIC 8089 (license)	—	—	—	—	—	—	—	—	—	AUTH 389 (LDAP) 636 (LDAPS) 88 (Kerberos, TCP/UDP), optional 3268 / 3269 (Global Catalog, LDAP/LDAPS -- AD forest-wide lookups)	AUTH 443 (SAML SSO), optional	INFRA 53 (DNS, UDP/TCP)	INFRA 123 (NTP, UDP)	—	INFRA 443 (HTTPS, apps/updates/cloud APIs)	INFRA 80 / 443 (CA / CRL / OCSP, TLS certificate validation)	—	—	ING 1433 (SQL Server) 1521 (Oracle) 5432 (PostgreSQL) 3306 (MySQL), varies by target DB	ING 5671 (AMQP over TLS) 443 (HTTPS / AMQP-WebSockets)	ING 443 (HTTPS, S3 regional endpoint)	ING 443 (HTTPS, SQS regional endpoint)	API 443 (HTTPS, conditional -- if using temporary/assumed IAM credentials)	API 443 (HTTPS, conditional -- if server-side encryption is used)	—	API 443 (HTTPS, REST/API polling)	ING 9092 (plaintext) 9093 (TLS)	ING 443 (HTTPS)	ING 443 (HTTPS)	ING 443 (HTTPS)	ING 443 (HTTPS)	ING 161 (UDP, polling)	—	—	ING 9997 (S2S, TCP) -- where supported/configured; verify the actual forwarding endpoint/port for your Splunk Cloud stack	—	—	—	API 443 (HTTPS)	MGMT 443 (HTTPS, app/update download)	—	—	—	INFRA environment-specific (often the proxy's own listener, e.g. 3128/8080)	—
Indexer / IDX Peer	—	—	REPL 9887 (cluster replication)	SRCH 8089 (cluster internal) 8089 (distributed search responses)	MGMT 8089 (mgmt)	CLU 8089 (cluster control)	LIC 8089 (license)	—	—	—	—	—	—	—	—	—	AUTH 389 (LDAP) 636 (LDAPS) 88 (Kerberos, TCP/UDP), optional 3268 / 3269 (Global Catalog, LDAP/LDAPS -- AD forest-wide lookups)	—	INFRA 53 (DNS, UDP/TCP)	INFRA 123 (NTP, UDP)	—	INFRA 443 (HTTPS, apps/updates/cloud APIs)	INFRA 80 / 443 (CA / CRL / OCSP, TLS certificate validation)	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	MGMT 443 (HTTPS, app/update download)	—	—	—	INFRA environment-specific (often the proxy's own listener, e.g. 3128/8080)	—
Search Head / SHC Member	—	—	SRCH 8089 (distributed search)	REPL 8081 / 8181 / 9777 / 9887 (SHC replication, examples -- validate against your SHC's actual configured/versioned ports, not a fixed default) 8191 (KV Store, primary) 8065 (KV Store-related, context-dependent -- not a universal default)	MGMT 8089 (mgmt)	CLU 8089 (optional)	LIC 8089 (license)	—	—	—	—	—	—	—	—	—	AUTH 389 (LDAP) 636 (LDAPS) 88 (Kerberos, TCP/UDP) 3268 / 3269 (Global Catalog, LDAP/LDAPS -- AD forest-wide lookups)	AUTH 443 (SAML SSO)	INFRA 53 (DNS, UDP/TCP)	INFRA 123 (NTP, UDP)	ALRT 25 / 465 / 587 (SMTP, alert email)	INFRA 443 (HTTPS, apps/updates/cloud APIs)	INFRA 80 / 443 (CA / CRL / OCSP, TLS certificate validation)	—	—	—	—	ING 443 (HTTPS, federated search to S3 regional endpoint)	—	API 443 (HTTPS, conditional -- if using temporary/assumed IAM credentials)	API 443 (HTTPS, conditional -- if server-side encryption is used)	SRCH 443 (HTTPS, federated search to Glue Data Catalog)	—	—	—	—	—	—	—	—	—	MGMT 8089 (mgmt / API access, immutable)	API 443 (HTTPS, ES adaptive response)	API 443 (HTTPS, ES app)	—	—	MGMT 443 (HTTPS, app/update download)	ALRT 443 (HTTPS, commonly)	ALRT 443 (HTTPS, alert action / add-on)	ING 443 (HTTPS, ES Threat Intelligence framework)	INFRA environment-specific (often the proxy's own listener, e.g. 3128/8080)	—
Deployment Server (DS)	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	INFRA 53 (DNS, UDP/TCP)	INFRA 123 (NTP, UDP)	—	INFRA 443 (HTTPS, apps/updates/cloud APIs)	INFRA 80 / 443 (CA / CRL / OCSP, TLS certificate validation)	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	MGMT 443 (HTTPS, app/update download)	—	—	—	INFRA environment-specific (often the proxy's own listener, e.g. 3128/8080)	—
Cluster Manager (CM)	—	—	CLU 8089 (cluster management)	—	—	—	LIC 8089 (license)	—	—	—	—	—	—	—	—	—	—	—	INFRA 53 (DNS, UDP/TCP)	INFRA 123 (NTP, UDP)	—	INFRA 443 (HTTPS, apps/updates/cloud APIs)	INFRA 80 / 443 (CA / CRL / OCSP, TLS certificate validation)	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	MGMT 443 (HTTPS, app/update download)	—	—	—	INFRA environment-specific (often the proxy's own listener, e.g. 3128/8080)	—
License Manager (LM)	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	INFRA 53 (DNS, UDP/TCP)	INFRA 123 (NTP, UDP)	—	INFRA 443 (HTTPS, apps/updates/cloud APIs)	INFRA 80 / 443 (CA / CRL / OCSP, TLS certificate validation)	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	MGMT 443 (HTTPS, app/update download)	—	—	—	INFRA environment-specific (often the proxy's own listener, e.g. 3128/8080)	—
Deployer	—	—	—	MGMT 8089 (app / config push)	—	—	—	—	—	—	—	—	—	—	—	—	—	—	INFRA 53 (DNS, UDP/TCP)	INFRA 123 (NTP, UDP)	—	INFRA 443 (HTTPS, apps/updates/cloud APIs)	INFRA 80 / 443 (CA / CRL / OCSP, TLS certificate validation)	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	MGMT 443 (HTTPS, app/update download)	—	—	—	INFRA environment-specific (often the proxy's own listener, e.g. 3128/8080)	—
Splunk Stream Server	—	—	—	—	MGMT 8089 (mgmt / phone-home / apps)	—	LIC 8089 (license)	—	—	MGMT not confirmed (config push, see note)	—	—	—	—	—	—	—	—	INFRA 53 (DNS, UDP/TCP)	INFRA 123 (NTP, UDP)	—	INFRA 443 (HTTPS, apps/updates/cloud APIs)	INFRA 80 / 443 (CA / CRL / OCSP, TLS certificate validation)	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	MGMT 443 (HTTPS, app/update download)	—	—	—	INFRA environment-specific (often the proxy's own listener, e.g. 3128/8080)	—
Splunk Stream Forwarder (Client)	—	ING 9997 (S2S, TCP, optionally TLS)	ING 9997 (S2S, TCP, optionally TLS)	—	MGMT 8089 (mgmt / phone-home / apps)	—	—	—	MGMT not confirmed (config check-in, see note)	—	—	—	—	—	—	—	—	—	INFRA 53 (DNS, UDP/TCP)	INFRA 123 (NTP, UDP)	—	INFRA 443 (HTTPS, apps/updates/cloud APIs)	INFRA 80 / 443 (CA / CRL / OCSP, TLS certificate validation)	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	ING 9997 (S2S, TCP, immutable)	—	—	—	—	MGMT 443 (HTTPS, app/update download)	—	—	—	INFRA environment-specific (often the proxy's own listener, e.g. 3128/8080)	—
Monitoring Console (MC)	—	MGMT 8089 (mgmt / distributed monitoring, if registered as a search peer -- exact relationship depends on how distributed monitoring is configured)	MGMT 8089 (mgmt / distributed monitoring, if registered as a search peer -- exact relationship depends on how distributed monitoring is configured)	MGMT 8089 (mgmt / distributed monitoring, if registered as a search peer -- exact relationship depends on how distributed monitoring is configured)	MGMT 8089 (mgmt / distributed monitoring, if registered as a search peer -- exact relationship depends on how distributed monitoring is configured)	CLU 8089 (mgmt / distributed monitoring, if registered as a search peer -- exact relationship depends on how distributed monitoring is configured)	LIC 8089 (mgmt / distributed monitoring, if registered as a search peer -- exact relationship depends on how distributed monitoring is configured)	MGMT 8089 (mgmt / distributed monitoring, if registered as a search peer -- exact relationship depends on how distributed monitoring is configured)	MGMT 8089 (mgmt / distributed monitoring, if registered as a search peer -- exact relationship depends on how distributed monitoring is configured)	MGMT 8089 (mgmt / distributed monitoring, if registered as a search peer -- exact relationship depends on how distributed monitoring is configured)	—	—	—	—	—	—	AUTH 389 (LDAP) 636 (LDAPS) 88 (Kerberos, TCP/UDP), optional 3268 / 3269 (Global Catalog, LDAP/LDAPS -- AD forest-wide lookups)	AUTH 443 (SAML SSO), optional	INFRA 53 (DNS, UDP/TCP)	INFRA 123 (NTP, UDP)	ALRT 25 / 465 / 587 (SMTP, platform alerting), optional	INFRA 443 (HTTPS, apps/updates/cloud APIs)	INFRA 80 / 443 (CA / CRL / OCSP, TLS certificate validation)	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	MGMT 443 (HTTPS, app/update download)	—	—	—	INFRA environment-specific (often the proxy's own listener, e.g. 3128/8080)	—
Edge / Ingest Processor	—	ING 8088 (HEC) or 9997 (S2S), depending on configuration	ING 8088 (HEC) or 9997 (S2S), depending on configuration	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	INFRA 53 (DNS, UDP/TCP)	INFRA 123 (NTP, UDP)	—	INFRA 443 (management plane / identity)	INFRA 80 / 443 (CA / CRL / OCSP, TLS certificate validation)	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	ING 443 (ingest / HEC endpoint)	—	—	—	—	MGMT 443 (HTTPS, app/update download)	—	—	—	INFRA environment-specific (often the proxy's own listener, e.g. 3128/8080)	—
User	—	ACC 8000 (Splunk Web UI, optional) / 8443 (Splunk Web UI, HTTPS, optional)	ACC 8000 (Splunk Web UI, optional) / 8443 (Splunk Web UI, HTTPS, optional)	ACC 8000 (Splunk Web UI) / 8443 (Splunk Web UI, HTTPS)	—	—	—	—	—	—	ACC 8000 (Splunk Web UI) / 8443 (Splunk Web UI, HTTPS)	—	—	—	—	—	—	AUTH 443 (SAML SSO, browser-mediated redirect to the IdP -- the user's browser participates directly, not just Splunk server-to-IdP)	—	—	—	—	—	—	ACC 443 (HTTPS, front-end)	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	ACC 443 (Web, mandatory SSL, immutable)	—	—	—	—	—	—	—	—	—	—
Syslog Source	—	ING 514 (syslog input, TCP/UDP), not recommended	ING 514 (syslog input, TCP/UDP), possible, not recommended	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	ING 514 (TCP/UDP) 6514 (TLS)	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—
HEC Client (Application)	—	ING 8088 (HEC, HTTP/HTTPS)	ING 8088 (HEC, HTTP/HTTPS)	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	ING 443 (HTTPS, front-end, when HEC is proxied)	—	—	—	—	—	—	—	API 443 (HTTPS, REST/API polling before pushing via HEC -- e.g. Azure Function, AWS Lambda, on-premises script)	—	—	—	—	—	—	ING 4317 (OTLP gRPC) 4318 (OTLP HTTP)	—	ING 443 (HEC, HTTPS) -- Splunk Cloud's public HEC endpoint; 8088 is the on-premises default and is not used for Splunk Cloud	—	—	—	—	—	—	—	—	—	—
Admin / API Client	MGMT 8089 (mgmt / REST API)	MGMT 8089 (mgmt / REST API)	MGMT 8089 (mgmt / REST API)	MGMT 8089 (mgmt / REST API)	MGMT 8089 (mgmt / REST API)	CLU 8089 (mgmt / REST API)	LIC 8089 (mgmt / REST API)	MGMT 8089 (mgmt / REST API)	MGMT 8089 (mgmt / REST API)	MGMT 8089 (mgmt / REST API)	MGMT 8089 (mgmt / REST API)	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	MGMT 8089 (mgmt / API access, immutable)	API 443 (HTTPS)	—	CCP 443 (HTTPS)	—	—	—	—	—	—	API 443 (HTTPS, detection-as-code / CI-CD sync)
LDAP / AD Server	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—
SAML IdP	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—
DNS Server	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—
NTP Server	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—
SMTP Relay	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—
Internet / Proxy	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—
CA / CRL / OCSP (PKI Validation)	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—
Syslog Collector (SC4S / rsyslog / syslog-ng)	ING N/A (local file access, not a network flow)	ING 8088 / 443 (HEC, default); 9997 (S2S) also supported	ING 8088 / 443 (HEC, default); 9997 (S2S) also supported	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	ING 443 (HEC)	—	—	—	—	—	—	—	—	—	—
Load Balancer / Reverse Proxy	—	ING 8088 (backend, implementation-specific)	ING 8088 (backend, implementation-specific)	ACC 8000 (backend, implementation-specific)	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—
Database Server (JDBC)	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—
Azure Event Hub	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—
AWS S3	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—
AWS SQS	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—
AWS STS	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—
AWS KMS	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—
AWS Glue	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—
Vendor / Source API (External REST/HTTPS)	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—
Kafka	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—
AWS Kinesis	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—
Azure Storage / ARM	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—
Microsoft Graph	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—
Google Cloud APIs / Pub/Sub	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—
SNMP Manager / Trap Receiver	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—
OpenTelemetry Collector	—	ING 8088 (HEC, relaying collected telemetry onward)	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	API 443 / 6443 (K8s API access for metadata/collection)	—	—	—	—	API 443 (HTTPS, OTLP/HEC ingestion)	—	—	—	—	—	—
Container / Kubernetes API	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—
Splunk Cloud	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	API 443 (HTTPS, Splunk Cloud input service to vendor API)	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—
Splunk SOAR / SOAR Cloud	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	ALRT 443 (HTTPS, response/enrichment action against a third-party security product via a SOAR app connector)	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	ALRT 443 (HTTPS, playbook action)	—	—	—
Splunk Enterprise Security / Mission Control (Cloud)	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—
Splunk ACS (Admin Config Service)	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—
Splunk Observability Cloud	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—
Splunkbase / Update Service	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—
Webhook Destination	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—
Ticketing / ITSM API	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—
TAXII Server (Threat Intelligence)	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—
Proxy Authentication Service	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—
Git Host (GitHub / GitLab / Azure DevOps)	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—

Key Port Meanings in the Matrix

Port	Typical Use in Matrix
8089	Management / REST API / distributed search / deployment / licensing / cluster control (used almost everywhere)
9997	Splunk-to-Splunk (S2S) data forwarding (conventional default) -- used whether or not TLS is enabled; TLS changes the protocol on this same port rather than moving to a different one.
9998	Seen in some older references as a distinct "SSL forwarding" port, but not represented as a standard default in this matrix -- S2S forwarding conventionally stays on 9997 with or without TLS. Confirm against the specific Splunk release/documentation if an environment genuinely uses 9998.
9887	Indexer cluster (bucket/data) replication -- the primary convention. Configurable; don't treat other numbers seen in older references (e.g. 8080) as a validated default without a specific configured use.
8081 / 8181 / 9777 / 9887	Search Head Cluster replication (examples -- configurable)
8191 / 8065	KV Store + replication (critical for SHC)

Additional Listening Ports (not always inter-component)

Commonly open on the listed components, but usually accessed by users, external systems, or internal processes rather than other Splunk roles:

Port	Component(s)	Purpose
8000	Search Head, (optional) Indexer / HF	Splunk Web UI
8088	Indexer, Heavy Forwarder	HTTP Event Collector (HEC)
514	Indexer / HF / UF	Syslog input (TCP or UDP) -- not recommended directly into Splunk

Encrypted Communication Scenarios (TLS)

Sourced from Splunk's "Introduction to securing the Splunk platform with TLS" documentation (version 10.4) -- its own "Table of most common encrypted Splunk platform instance communication scenarios." Cloud refers specifically to Splunk Cloud Platform; Enterprise refers to Splunk Enterprise and its components, including the universal forwarder.

Type of Exchange	Node A (initiates / client)	Node B (responds / server)	Default Encryption	Default Certificate-Based Authentication	Default Common Name Checking	Type of Data Exchanged
Browser to Splunk Web	Browser	Splunk Web	Cloud: on · Enterprise: off	Browser determines this	Browser determines this	Configuration and search data
Splunk Web to search head	Splunk Web	`splunkd` as a search head	On	Cloud: on · Enterprise: off	Cloud: on · Enterprise: off	Configuration and search data
Forwarding	`splunkd` as a forwarder	`splunkd` as an indexer	Cloud: on · Enterprise: off	Cloud: on · Enterprise: off	Cloud: on · Enterprise: off	Data to be indexed
Splunk-to-Splunk	`splunkd` as a client	`splunkd` as a server	On	Off	Off	Configuration data, user data
Agent management to agents	`splunkd` as agent	`splunkd` as agent management	On	Cloud: on · Enterprise: off	Cloud: on · Enterprise: off	Configuration data
Distributed search	`splunkd` as search peer	`splunkd` as a search head	On	Cloud: on · Enterprise: off	Cloud: on · Enterprise: off	Search data
Search head clusters	`splunkd` as cluster members	`splunkd` as cluster members	Cloud: on · Enterprise: off	Cloud: on · Enterprise: off	Cloud: on · Enterprise: off	Cluster data
Search head cluster deployer	`splunkd` as cluster members	`splunkd` as cluster deployer	On	Cloud: on · Enterprise: off	Cloud: on · Enterprise: off	Configuration data
Indexer cluster peer nodes	`splunkd` as indexer cluster peer nodes	`splunkd` as indexer cluster peer nodes	Cloud: on · Enterprise: off. Use the `replication_port-ssl` setting in the `server.conf` configuration file to turn on replication over TLS.	Cloud: on · Enterprise: off	Cloud: on · Enterprise: off	Replication data
Indexer cluster manager	`splunkd` as peer and search head nodes	`splunkd` as a manager node	On	Cloud: on · Enterprise: off	Cloud: on · Enterprise: off	Cluster data

Flow Schema Table

The same 191 populated flows as the Matrix grid view, one row per flow, expanded into a per-field network-flow-catalog record (Flow ID, ports, protocols, initiator/firewall direction, TLS posture, authentication, Splunk config stanzas, firewall rule text, and return traffic) -- the format commonly used for firewall change requests and network-flow documentation.

191 / 191 flows shown

Splunk REST API

Splunk API

REST endpoints across Splunk's products, and where each one works.

0 endpoints 0 paths

About this data

Data source coverage

Input Coverage

Reference listings of the specific inputs a Splunk technology add-on (TA) exposes for a vendor platform, organised by product family. Use these alongside the Data Source Catalogue (TAX-03.01.01) when scoping which inputs a tenant/subscription needs enabled.

Microsoft cloud based inputs

Inputs across four Splunk-maintained Microsoft add-ons. Each input is a distinct, separately-enabled data feed within its TA -- not every tenant/subscription will need every input. Select an input to see its details.

Note: Azure Metrics appears under both Splunk_TA_microsoft-cloudservices and TA-MS-AAD -- these are two distinct inputs from two different apps, not a duplicate. See the Coverage tab for tenant/subscription-level enablement tracking against these inputs.

Coverage

Editable tenant/subscription-level enablement tracking against the Microsoft cloud inputs listed under Inputs. Edits are saved in this browser automatically.

Schema explorer

Search, filter and browse every field documented across the linked JSON Schema files. Only inputs with a Schema link (see the Inputs tab) appear here.

App	Input	Field	Type	Description

Permissions

App-only Microsoft Graph/Office 365 Management permissions required per input, plus deployment-side and Azure-side prerequisites. Not every deployment needs every permission below -- select a marked cell for the full detail (service, purpose, notes).

Transcribed verbatim from five supplied CSVs, one per app: splunk_o365_permissions.csv (splunk_ta_o365), splunk_cloudservices_permissions.csv (Splunk_TA_microsoft-cloudservices), splunk_aad_permissions.csv (TA-MS-AAD), splunk_mssecurity_permissions.csv (Splunk_TA_MS_Security) and soar_m365defender_permissions.csv (Splunk SOAR: Microsoft 365 Defender). The first four are Splunk Enterprise TAs whose rows are modular inputs; the fifth is a Splunk SOAR connector whose "Input" column is really playbook action names (Test Connectivity, On Poll, List/Get/Update Incidents and Alerts, Run Query) -- no verified internal connector package ID was available so it's tagged with this descriptive label rather than a guessed technical name. The splunk_ta_o365 rows were redone from a newer, more granular version of its source CSV that lists permissions per literal input stanza name (e.g. Mailbox:MailboxUsageDetail) grouped by module family, rather than the earlier Required/Optional/GCC-substitute tiering -- its Input Family pills are colored the same as the other apps' baseline "required" pills since this CSV draws no required/optional distinction. Rows are the distinct App+Input combinations across all five files, columns the distinct individual actions -- a marked cell means that row's input requires that column's action (per its Input Family); some inputs (e.g. Management Activity:DLP.All, All inputs/All actions in any of the five apps, All ARM-backed inputs, Microsoft Entra ID Audit, Microsoft Entra ID Identity Protection) require more than one action and so have multiple marked cells -- a source row whose own Actions cell listed two scopes required together (e.g. TA-MS-AAD's "AuditLog.Read.All; Directory.Read.All", or splunk_ta_o365's "ActivityFeed.Read; ActivityFeed.ReadDlp") was split into one marked cell per scope, reusing whichever column that scope already has. Splunk_TA_MS_Security's Actions cells instead list two equivalent, alternative permission forms ("X (Graph) or Y (Graph Security)") rather than a joint requirement, so those are kept as a single column carrying the full "X or Y" string rather than split. Splunk SOAR: Microsoft 365 Defender's two Auth mode rows are a third case: each lists a full bundle of scopes required together for that one auth mode via a semicolon-separated Actions cell, but since Application and Delegated auth are mutually exclusive alternatives (not a joint requirement) and both rows share the literal input "All actions", splitting them would have wrongly read as one combined 11-scope ask -- so each bundle is instead kept as its own single, self-labeled column, same treatment as Splunk_TA_MS_Security's OR-style actions. All five apps happen to use the literal input name "All inputs" or "All actions" for their own Splunk/Azure-side prerequisites -- these are kept as separate rows (one per app), not merged. Two Splunk_TA_MS_Security rows are alert-action prerequisites rather than modular inputs (labelled Alert actions (not inputs)) and are included for completeness. A sixth file, soar_azure_connectors_permissions.csv, adds eight more Splunk SOAR connectors at once (azuread -- deprecated, retired Sept 2025, migrate to msadgraph -- msadgraph, azuredevops, msgraphforoffice365, microsoftdefenderforendpoint, microsoftonedrive, microsoftazurecompute and microsoftazuresql) and uses a different shape: a Delegated Permission column and an Application Permission column instead of one combined Actions column. Where both list the identical scope, only one shared column/mark is added; where they differ (even by a suffix, e.g. "Machine.Read" vs "Machine.Read.All") each gets its own column, kept distinct per the no-fuzzy-merge rule above; a placeholder cell with no real scope ("N/A", "Not supported", "Not applicable", or "Same" referring back to the other column) is skipped rather than becoming a column. A handful of rows list several scopes required together for one specific action (joined by "+" or ";") and are AND-split as above; three rows instead describe a full scope bundle for an entire legacy connector or an alternative auth method (azuread's single row, and two of azuredevops's three) and are kept as one unsplit column each, the same "alternatives, don't split" treatment as Splunk SOAR: Microsoft 365 Defender's Auth mode rows. This file's own final row is a cross-cutting admin-consent note rather than belonging to one app, so it's expanded into one row per app here, for the six apps the source text says it applies to (it explicitly excludes microsoftazurecompute and microsoftazuresql, which don't use Graph consent at all). microsoftazurecompute's and microsoftazuresql's Application-permission values are the source file's own inferred guesses (each labelled "- inferred" since neither connector's README documents a required role) -- transcribed verbatim, inferred label intact. — means not applicable.

Resource input

Which collection path normally carries each Azure resource's telemetry into Splunk: a Universal Forwarder (UF), the HTTP Event Collector (HEC), Event Hub or an API.

Primary Preferred or normal collection path
Secondary Alternative, supplementary, or service-specific path
Not normally used Not normally selected for this resource/source

Azure resource / source	Layer / plane	UF	HEC	Event Hub	API	Typical telemetry

Transcribed verbatim from the supplied workbook azure_resource_splunk_collection_crosscut.xlsx (sheets Azure Collection Matrix and Legend).

Amazon AWS based inputs

Inputs across Splunk-maintained AWS add-ons, organised the same way as the Microsoft cloud inputs above.

App/Input/Sourcetype data transcribed from a supplied Splunk_TA_aws_sourcetypes.csv; Splunkbase app name/ID/base link confirmed against Splunkbase directly. See the Coverage tab for AWS account-level enablement tracking against these inputs, and the Schema tab for the AWS field-level schema (transcribed separately from a supplied CSV, organised by sourcetype rather than by these input names).

Coverage

Editable AWS account-level enablement tracking against the AWS cloud inputs listed under Inputs. Edits are saved in this browser automatically.

Schema explorer

Search, filter and browse field-level schema for AWS sourcetypes -- native TA fields, CIM/OCSF model mappings, and lookup/derived fields.

Sourcetype	Category	Field	CIM model	Description

Permissions

IAM permissions required per input, across Splunk_TA_aws (CloudTrail, Config, CloudWatch, Billing, Metadata, S3-based logs and more) and Data Management (Federated Search/catalog access). Not every deployment needs every permission below -- select a marked cell for the full detail.

Replaced with a supplied permissions matrix spreadsheet (App/Input rows × 55 IAM-action columns, one worksheet) that supersedes the earlier two-CSV version of this table in its entirety -- transcribed verbatim, cell by cell, and diffed back against the source workbook after transcription (zero mismatches across all 105 marks). Rows are the distinct App+Input combinations in the sheet, columns the distinct marked actions -- a marked cell's pill text is the source's own family label for that cell (Billing, S3-based log, Log/Config history, Metrics/Security, Metadata, or a bare Required mark for the Data Management app's rows, which the source marks with a plain "y" rather than a named family). The source carries no Required/Optional distinction the way the superseded CSVs did -- every marked cell is styled the same (required). Service (S3, SQS, EC2, CloudTrail, ...) is derived from each action's own IAM namespace prefix, not a separate source column. Three actions are cross-reference prose rather than concrete IAM actions -- Custom Data Type ("Same as Generic S3 or SQS-based S3 depending on which underlying input you configure"), Transit Gateway Flow Logs ("Same as SQS-based S3 input"), and VPC Flow Logs ("Depends on chosen delivery mechanism...") -- kept as their own one-off columns rather than fabricating concrete scopes. One header column in the source, s3:AbortMultipartUpload, has zero marks anywhere and so never appears as a rendered column here. A second app, Data Management, appears alongside Splunk_TA_aws for Federated Search/catalog-style access (Federated Data: Dataset Access/Dataset KMS/Data Connection/Catalog Sync, and a combined Data Routing row). This source has no Purpose/Notes prose column, so those detail-modal fields are empty for every row here (unlike the superseded version).

Zscaler based inputs

No Zscaler inputs have been documented yet. This section is structured the same way as the Microsoft and AWS tabs above, ready to receive the same input-list/sourcetype CSV format once it's supplied.

Awaiting source data: no Zscaler input-list/sourcetype CSV has been supplied yet. Once provided, inputs will appear here the same way the Microsoft and AWS ones do, with Coverage-tab enablement tracking and Schema-tab field-level detail.

Coverage

Editable Zscaler tenant-level enablement tracking against the Zscaler cloud inputs listed under Inputs. Edits are saved in this browser automatically.

No Zscaler inputs are documented yet, so this tracker currently has just the tenant identifier column -- one Y/N column per input will appear here once the Inputs tab has real data.

Schema explorer

Search, filter and browse field-level schema for the 13 Zscaler log sourcetypes (ZIA and ZPA). Field category (ZIA/ZPA) is derived from each source input. See the CIM Coverage tab for which of these sourcetypes are wired into a CIM data model, and the confirmed real field names the TA actually extracts.

Sourcetype	Category	Field	CIM model	Description

Transcribed verbatim from the field_schemas block of a supplied Zscaler_Splunk_Onboarding_Reference.json (the same file the Inputs tab's data came from). Field names for the Web log sourcetype come from Zscaler's own official NSS format reference; every other sourcetype's field list is sourced from a third-party (Elastic) integration reference instead, since the corresponding official Zscaler documentation pages are JavaScript-rendered and could not be scraped directly -- hover a Sourcetype filter for its specific source. The source file's own caution applies here too: verify exact field names against your own onboarded data before building dashboards or CIM mappings. ZIA config objects and ZPA config objects (the two config/enrichment inputs) have no field schema here since they're lookup/KV data, not event logs.

Permissions

Permissions required per Zscaler input, once supplied. Select a marked cell for the full detail (service, purpose, notes).

Awaiting source data: no Zscaler permissions CSV has been supplied yet. Once provided, this table will follow the same (app, input, action) model as the Microsoft and AWS Permissions tabs -- one marked, colored pill per required action, with click-through detail.

CIM Coverage summary

Which of the 18 confirmed Zscaler eventtypes are wired into a Splunk CIM data model in the real TA-Zscaler_CIM v4.1.5 package, and which aren't despite having usable field extractions.

Input	Sourcetype	Eventtype	CIM tags	CIM data model(s)	Notes

CIM Field Mapping crosswalk

The TA's actual props.conf FIELDALIAS/EVAL stanzas, field by field -- what each raw Zscaler field is renamed or computed into, and which CIM data model that target field belongs to.

Sourcetype	CIM data model	Raw field	Set via	CIM field	Notes

TA extra sourcetypes

Sourcetypes confirmed present in the same TA-Zscaler_CIM v4.1.5 package that fall outside this reference's ZIA/ZPA onboarding scope -- listed here for completeness. These also appear as a third input group under the Inputs and Coverage tabs.

Sourcetype	Product / feed	Eventtype	CIM tags	CIM data model(s)	Notes

Fortinet based inputs

No Fortinet inputs have been documented yet.

Transcribed from the real Fortinet FortiGate Add-on for Splunk package (Splunk_TA_fortinet_fortigate, Splunkbase app 2846, version 1.6.10) the user provided. Unlike the Microsoft/AWS/Zscaler add-ons above, this TA has no modular inputs at all -- FortiGate devices push syslog to a receiver (a Splunk Heavy Forwarder or a syslog relay such as SC4S), and the TA's own TRANSFORMS-force_sourcetype_fortigate stanza inspects each raw event for devid="F..." and type="traffic|utm|event|anomaly" to reclassify it from the generic ingest sourcetype (fortigate_log/fgt_log) into one of the four sourcetypes listed below. Those four sourcetypes are therefore the closest equivalent this vendor has to a discrete, separately-trackable "input."

Coverage

Editable per-FortiGate-device enablement tracking against the sourcetypes listed under Inputs. Edits are saved in this browser automatically.

No Fortinet inputs are documented yet, so this tracker currently has just the device identifier column.

Schema explorer

Every raw FortiOS log field the TA actually knows about (via FIELDALIAS, EVAL or LOOKUP in its real props.conf) across the 4 sourcetypes, and the CIM field each becomes. There is no separate prose field-schema document for this vendor -- props.conf itself is the schema.

Sourcetype	Set via	Field	CIM field	Description

Permissions

Splunk-side API/IAM permissions, for comparison with the Microsoft/AWS/Zscaler Permissions tabs.

Not applicable to this vendor. The Fortinet FortiGate Add-on for Splunk (Splunk_TA_fortinet_fortigate) ships no modular input and calls no API -- confirmed directly from the package, which has no inputs.conf.spec and whose only executable content is parsing/CIM-mapping configuration (props.conf, transforms.conf, eventtypes.conf, tags.conf). There is therefore no Splunk-side IAM role, OAuth scope, or API key for this input, unlike the Microsoft/AWS/Zscaler tabs above. The real prerequisites sit on the other two ends of the pipe instead: on FortiOS, enabling syslog/log delivery (Log & Report > Log Settings) in the TA's native (non-CEF) format so the devid="F..." type="traffic|utm|event|anomaly" pattern its TRANSFORMS-force_sourcetype_fortigate stanza expects is present; and on the receiver side, network reachability from each FortiGate device to whatever is listening (a Splunk Heavy Forwarder, or a syslog relay such as SC4S) on the configured port, with the generic ingest sourcetype set to fortigate_log (or the legacy fgt_log).

CIM Coverage summary

All 35 eventtypes the TA defines, their real CIM tags (or lack thereof) transcribed from tags.conf, and the closest-matching CIM data model this reference derives from those tags.

Eventtype	CIM tags	CIM data model	Search (verbatim)	Notes

SOC Metrics

SOC Metrics Taxonomy

724 SOC metrics spanning 6 capability families and 44 domains -- from operational KPIs (alert volume, case backlog, SLA compliance) through risk indicators (KRI) and control indicators (KCI). Search or filter the full table, or cross-tabulate any two classification dimensions in the Pivot explorer.

SOC Metrics Table

Search across every field, or filter by capability family, domain, dimension, indicator timing, management level or indicator type.

724 visible metrics 724 total metrics 6 capability families 44 domains

Classification legend (from the source taxonomy's own Classification sheet) -- Dimension: primary measurement dimension (Coverage, Quality, Timeliness, Effectiveness, Efficiency, Outcome). Indicator Timing: whether the metric signals future state (Leading) or reports realized results (Lagging). Management Level: primary management audience (Operational, Tactical, Strategic). Indicator Type: performance, risk, or control indicator classification (KPI, KRI, KCI).

Capability Family	Domain	Metric	Dimension	Indicator Timing	Management Level	Indicator Type	What it measures

Pivot Explorer

Cross-tabulate the 724 metrics by any two classification dimensions. Select Rows and Columns, then click a cell to open those exact metrics in the Table view.

Governance & Compliance · TAX-02.06.01

Naming Convention

A single standard for taxonomy registry IDs, Splunk object names, event-health checks, detection content, analytical assets, and cloud storage Connections/Datasets.

Technical-name pattern

Use this structure where a technical object needs platform, dataset, purpose and environment context.

Examplesec_azure_entra_signin_prodValid structure

Grandfathering: existing production indexes and sourcetypes do not need to be renamed solely for style. Record exceptions and apply the standard to new or materially changed objects.

Name validator

Check a proposed name against the selected governed pattern.

Object type Proposed name

Pattern catalogue

Registry identifiers align with the current taxonomy and workbook records; technical patterns define how new Splunk content should be named.

Object	Pattern	Example	Separator / case	Scope
Platform ID	`PLT-###`	`PLT-003`	Hyphen / uppercase	Registry
Source Family ID	`SRC-###`	`SRC-001`	Hyphen / uppercase	Reference catalogue
Governance Profile ID	`GOV-###`	`GOV-003`	Hyphen / uppercase	Registry
Logging Pattern ID	`LP-###`	`LP-006`	Hyphen / uppercase	Registry
Input Component ID	`IC-###`	`IC-011`	Hyphen / uppercase	Registry
Collector ID	`COL-###`	`COL-005`	Hyphen / uppercase	Registry
App / TA ID	`APP-###`	`APP-003`	Hyphen / uppercase	Registry
Stanza ID	`STZ-###`	`STZ-021`	Hyphen / uppercase	Registry
Health Test ID	`TC-<TYPE>-###`	`TC-HEC-004`	Hyphen / uppercase	Assurance
Dependency ID	`DEP-###`	`DEP-007`	Hyphen / uppercase	Lineage
Onboarding ID	`ONB-###`	`ONB-005`	Hyphen / uppercase	Workflow
Viability Assessment ID	`VIA-###`	`VIA-001`	Hyphen / uppercase	Workflow / phase gate
Change Record ID	`CCR-###`	`CCR-002`	Hyphen / uppercase	Assurance
Business Impact Level ID	`BIL-###`	`BIL-002`	Hyphen / uppercase	Governance
SOAR Integration ID	`SOAR-###`	`SOAR-002`	Hyphen / uppercase	Lineage
Required SIEM Event Type ID	`SRC-###-EVT-###-##`	`SRC-010-EVT-004-01`	Hyphen / uppercase	Reference catalogue
Index	`<domain_or_platform>[_<dataset>]`	`aws_cloudtrail`	Underscore / lowercase	Splunk
Sourcetype	`<vendor>:<product>:<dataset>`	`azure:aad:signin`	Colon / lowercase preferred	Splunk
Event Health Check	`HC_<platform>_<source>_<check>`	`HC_entra_signin_freshness`	Underscore / lowercase	Assurance
Detection Use Case ID	`DET-<DOMAIN>-###`	`DET-IDM-012`	Hyphen / uppercase	Detection
Detection Search	`<Domain> - <Platform> - <Behaviour>`	`Identity - Entra ID - Repeated MFA Denial`	Title case / spaced hyphen	Detection
Dashboard	`<Domain> - <Platform> - <Audience>`	`Security - Entra ID - Operations`	Title case / spaced hyphen	Analytics
Cloud Storage Connection	`<Org>_<storage>_<account>`	`acme_s3_123456789012`	Underscore / lowercase	S3 / Azure Federated Search
Cloud Storage Dataset	`<Org>_<storage>_<account>_<content>_<format>_unified`	`acme_azure_prod_windows_security_json_unified`	Underscore / lowercase	S3 / Azure Federated Search

Cloud storage Connections & Datasets

Applies to Splunk Federated Search / Ingest Actions objects backed by Amazon S3 or Azure Blob Storage / ADLS Gen2. A Connection names the storage account; a Dataset names one content set within it that supports routing, Federated Search, or both.

Connection

Exampleacme_s3_123456789012Valid structure

Note: do not include unified on Connections -- that suffix applies to Datasets only.

Dataset

<Org>_ <storage>_ <account>_ <content>_ <format>_ unified

Exampleacme_azure_prod_windows_security_json_unifiedValid structure

Note: include unified only when the dataset supports both data routing and Federated Search.

Component	Meaning	Example values	Notes
`<Org>`	Short organization or company name	`acme` / `contoso`
`<storage>`	Cloud storage type	`s3` / `azure`	s3 = Amazon S3; azure = Microsoft Azure Blob / ADLS Gen2
`<account>`	AWS Account ID or Azure account/environment label	`123456789012` / `prod` / `nonprod`
`<content>`	Logical data content or source type	`windows_security` / `cloudtrail` / `vpcflow`
`<format>`	File format	`json` / `parquet`
`unified`	Used only on Datasets		Indicates support for both data routing and Federated Search. Not used on Connections.

Windows event log examples -- the same six object types, named consistently across both storage backends.

Object	Format	S3 example	Azure example
Windows Security Event Logs	JSON	`acme_s3_123456789012_windows_security_json_unified`	`acme_azure_prod_windows_security_json_unified`
Windows Security Event Logs	Parquet	`acme_s3_123456789012_windows_security_parquet_unified`	`acme_azure_prod_windows_security_parquet_unified`
Windows System Event Logs	JSON	`acme_s3_123456789012_windows_system_json_unified`	`acme_azure_prod_windows_system_json_unified`
Windows System Event Logs	Parquet	`acme_s3_123456789012_windows_system_parquet_unified`	`acme_azure_prod_windows_system_parquet_unified`
Windows Application Event Logs	JSON	`acme_s3_123456789012_windows_application_json_unified`	`acme_azure_prod_windows_application_json_unified`
Windows Application Event Logs	Parquet	`acme_s3_123456789012_windows_application_parquet_unified`	`acme_azure_prod_windows_application_parquet_unified`
Windows PowerShell Logs	JSON	`acme_s3_123456789012_windows_powershell_json_unified`	`acme_azure_prod_windows_powershell_json_unified`
Windows PowerShell Logs	Parquet	`acme_s3_123456789012_windows_powershell_parquet_unified`	`acme_azure_prod_windows_powershell_parquet_unified`
Windows Sysmon	JSON	`acme_s3_123456789012_windows_sysmon_json_unified`	`acme_azure_prod_windows_sysmon_json_unified`
Windows Sysmon	Parquet	`acme_s3_123456789012_windows_sysmon_parquet_unified`	`acme_azure_prod_windows_sysmon_parquet_unified`
All Windows Event Logs (mixed)	JSON	`acme_s3_123456789012_windows_eventlogs_json_unified`	`acme_azure_prod_windows_eventlogs_json_unified`
All Windows Event Logs (mixed)	Parquet	`acme_s3_123456789012_windows_eventlogs_parquet_unified`	`acme_azure_prod_windows_eventlogs_parquet_unified`

Additional examples

Object	Storage / format	Example
CloudTrail	S3 / JSON	`acme_s3_123456789012_cloudtrail_json_unified`
CloudTrail	S3 / Parquet	`acme_s3_123456789012_cloudtrail_parquet_unified`
VPC Flow Logs	S3 / JSON	`acme_s3_123456789012_vpcflow_json_unified`
Azure Activity Logs	Azure / JSON	`acme_azure_prod_activity_logs_json_unified`
Azure NSG Flow Logs	Azure / Parquet	`acme_azure_prod_nsg_flow_parquet_unified`
Security Logs	S3 / JSON	`acme_s3_123456789012_security_logs_json_unified`
Application Logs	Azure / Parquet	`acme_azure_prod_app_logs_parquet_unified`

Governance rules

01Stable identifiers

Never reuse an ID after retirement. Display names can change; registry IDs must remain stable.

02Controlled separators

Use hyphens for registry IDs, underscores for technical names and colons for sourcetype hierarchy.

03No embedded secrets

Never include tokens, credentials, personal data or sensitive business values in object names.

04Environment last

When environment is required, use a controlled suffix such as dev, test, uat or prod.

Use

TC-AWS-002
HC_entra_signin_freshness
azure:aad:signin
Identity - Entra ID - Repeated MFA Denial

Avoid

new_test_2
AzureLogs
hec-token-prod-9f2…
Critical Alert

Data Collection & Routing · TAX-03.02.01

Logging Pattern Advisor

Answer the source, supportability, runtime, destination and network-boundary questions to receive a governed destination-specific pattern, architecture flow, implementation controls, health profile and an 8-axis comparison radar.

Collection questions

Choose the closest answer. The advisor evaluates all 39 active variants, including direct HEC, Heavy Forwarder HEC, scripted REST API polling and syslog-server file collection through a Splunk forwarder.

1. What is the final Splunk destination?

2. How is the data exposed by the source?

3. What is the app or add-on support position?

4. Can the source itself send events to HEC?

5. Where should a custom REST polling script run? Used for LP-017 when no supported add-on exists and the source cannot push to HEC.

6. Can the source or collection runtime reach the final destination directly?

7. Is a collection tier already preferred or mandated?

8. Can a Splunk agent be installed on the source host or designated syslog server?

9. Is pre-index filtering, masking, splitting or routing needed?

10. What delivery behaviour is required?

Ready to assessComplete the questions and select Suggest pattern.

Compare patterns

Pick two or three governed patterns to see implementation complexity, configuration footprint, delivery guarantees and the 8-axis profile side by side.

Select at least two patterns, then select Compare.

LATCH turns log onboarding into a governed decision path.

What LATCH covers

Start here

Quick actions

What LATCH produces

Onboarding flow, end to end

Track log sources and detections

Candidate log source identified PLANNED

Gate · Platform Registered? TAX-01.01 / TAX-01.02

Phase 1 — Viability Assessment TAX-06.01.02 / TAX-07.01 ONBOARDING

Gate · Viability Decision TAX-07.01.04

Log Worthiness TAX-07.02

Gate · Worthiness Decision

Select logging pattern & topology TAX-03.02 / TAX-03.05

Connectivity validation TAX-03.02.05

Gate · Connectivity Succeeded?

Engineering build TAX-04.01–04.09

Ingestion check TAX-04.10.02 / TAX-04.10.03

Gate · Ingestion Confirmed?

Data quality assessment TAX-07.05–07.12 / 07.15 / 07.22–07.23 / TAX-04.07.07

Gate · Quality gates pass?

Pre-ingest cyber-value gates TAX-06.05.02

Gate · Overall Gate Result TAX-06.05.02.04

Cyber value scoring TAX-06.05.03–10 / TAX-07.16

Gate · Ingestion Decision TAX-06.05.11

Log Implementation TAX-07.03

Gate · Build & Acceptance Result

Governance approval TAX-02.03

Gate · Approval Decision TAX-02.03.03

Operational readiness TAX-07.04.03 / TAX-07.04.04

Gate · Operational Readiness Confirmed?

SOC readiness

Gate · SOC Ready?

GO-LIVE Onboarding Record TAX-06.01.01 ACTIVE

Log Sustainment TAX-07.04 / TAX-07.19

Detection Engineering TAX-05.03–05.05

Response readiness TAX-05.04 / TAX-02.07 / TAX-07.18

90-day value review TAX-06.05.14

Gate · Retain, Filter or Retire Decision

Detection lifecycle

Threat detection use case TAX-05.01.01 PROPOSED

Threat mapping & context TAX-05.01.02 / TAX-05.01.03

Gate · Hypothesis testable, value established? TAX-05.03.12

Data & event requirements TAX-05.02.01 / TAX-05.02.02

Gate · Required sources & fields available? TAX-05.03.12

Detection analytic & rule TAX-05.03.01 / TAX-05.03.03–05.03.06 DEVELOPMENT

Thresholds, exclusions & timing TAX-05.03.09–05.03.11

Detection-as-code TAX-05.08.01

Detection testing TAX-05.05.04 TESTING

Detection validation TAX-05.05.01 / TAX-05.05.05

Peer review TAX-05.08.01 PEER REVIEW

Gate · Detection Quality Gate TAX-05.03.12

CI/CD & deployment TAX-05.08.02 PRODUCTION

Response action & triage TAX-05.04.01 / TAX-05.07.02

Gate · Deployment verified? TAX-05.08.02

Detection health TAX-05.03.07 MONITORING

Quality metrics & effectiveness TAX-05.05.06 / TAX-05.05.07

Drift review TAX-05.03.13

Gate · Keep, retune, revalidate or retire? TAX-05.03.02

Concepts, methodologies and terminology

Event Context Completeness Score (ECCS)

Definition

The seven investigative dimensions

Investigative question

What to assess

Example fields

0–4 scoring

Scoring guidance

Common mistakes

Investigative question

What to assess

Example fields

0–4 scoring

Scoring guidance

Common mistakes

Investigative question

What to assess

Example fields

0–4 scoring

Scoring guidance