Apache NiFi and Splunk integration for teams that already run both
If your team already collects logs in NiFi and needs them in Splunk, or needs Splunk search results inside a flow, the supported approach is PutSplunkHTTP for pushing events to the Splunk HTTP Event Collector (HEC) with indexing acknowledgement, and GetSplunk for pulling results from Splunk searches. NiFi also sits in front of Splunk as a reduction layer, so you can filter, route, sample and enrich events before they consume indexing license volume. This integration moves and shapes data. It does not replace Splunk's own forwarders, index configuration, search design or access model, and it does not decide which events your security or compliance teams need to keep.
Before you build anything, confirm the processor names, property names and bundle version in the NiFi component documentation for your exact NiFi 2 release, since the Splunk processors are provided in a separate bundle and their properties can change between versions. Check the HEC token configuration, the target index and sourcetype on the Splunk side, and whether indexer acknowledgement is enabled on that HEC endpoint, because acknowledgement only works when Splunk has it turned on. Ask your Splunk administrator to confirm the HEC endpoint and TLS settings your environment requires before you write the flow.
The practical question is where filtering belongs. Dropping noisy fields, routing low-value events to cheaper storage and deduplicating repeated messages in NiFi reduces what Splunk must index, but every rule you add is a decision someone must own and test. Document which events are removed or sampled, keep the provenance needed to show what left the flow, and agree those rules with the teams that rely on the Splunk searches and alerts before production cutover.
What you need in place before you connect NiFi to Splunk
Most delays in a NiFi to Splunk flow come from missing preconditions, not from the processors themselves. The six items below cover the NiFi runtime, the Splunk side, the network, the trust chain, the account, and a safe place to test before anything reaches production indexes.
A supported NiFi 2 release and Java runtime
Start from a current NiFi 2 release and the Java runtime the administration guide lists as the minimum. The processors in this integration belong to the NiFi 2 component set, so confirm that your release includes them before you design the flow. If you still run NiFi 1.x, plan the migration first, because the 1.x line has reached end of support and its flows need changes before they run on NiFi 2. Record the exact NiFi version in your runbook, since processor properties can change between releases.
Splunk with HEC enabled
Confirm that the Splunk deployment you are sending to has the HTTP Event Collector turned on, and check the HEC version, listening port, and whether the endpoint is on indexers, a heavy forwarder, or a load balancer. Settings such as the HEC port, acknowledgement support, and ingest limits vary by Splunk version and deployment type. Verify them against Splunk's own documentation for your version, not against examples in this guide.
HEC tokens scoped to target indexes
Create a dedicated HEC token for this flow and restrict its allowed indexes to the ones the flow needs. Avoid a shared token that can write to every index, because a leaked credential would then reach all of them. Store the token value in a NiFi sensitive property or a parameter context marked sensitive, and document which token maps to which data source so that rotation does not break unrelated pipelines.
Network paths from every NiFi node
In a cluster, every node that runs the Splunk processors must reach the HEC endpoint, and the flow may also need the Splunk management API for search-based work. Test each node separately with the same host name and port that the flow will use, because a firewall rule that allows one node can silently block another. Ask your network team to confirm routes, proxies, and the ports for both paths in each environment.
TLS certificates and the Splunk trust chain
Obtain the certificate chain that Splunk presents on the HEC and management endpoints, and import the issuing CA into the truststore that NiFi uses for outbound calls. Check that the host name in the certificate matches the name in the flow. Certificates on Splunk are often issued by an internal CA that NiFi does not trust by default, so a missing intermediate is a common cause of failed connections that look like network faults.
A dedicated Splunk role and a test index
Give the flow's Splunk account a role that can write only to the intended indexes and, if the flow reads results, can run the searches it needs with limited capabilities. Pair this with a separate test index and a non-production HEC token, so that you can validate event formats, timestamps, and acknowledgement behavior without polluting production searches or license usage. Remove the test index and token once the flow is approved for production.
Choosing between pushing events and pulling search results
Start with the question: how much data will arrive at the index each day, and who owns the parsing rules? Push is the right direction when Splunk must hold the events for search, alerting and retention. Before the build, read the PutSplunkHTTP component documentation to confirm how the processor sends data to the HTTP Event Collector, how indexing acknowledgement works, and what retry behavior applies when Splunk returns an error. From Splunk, the flow needs an HEC endpoint, a token limited to the target indexes, and an agreed sourcetype for each data type. From NiFi, it needs record parsing so events carry consistent fields, and queues sized to absorb slowdowns on the Splunk side.
- Volume and batching: Ask for the expected peak and average event rate per source, then confirm how the processor batches FlowFiles before sending.
- Parsing location: Decide whether NiFi structures events before they leave, or whether Splunk extracts fields at search time. Each choice moves work and maintenance to a different team.
- Sourcetype and index routing: Confirm which attributes or settings select the index and sourcetype, and who approves new values.
- Acknowledgement and retry: Check whether acknowledgement is enabled, how retries interact with it, and where duplicates can appear after a failure.
- Token scope: Use a separate HEC token per data source so that access can be revoked without stopping other feeds.
Confirm the acknowledgement and retry behavior in the component documentation against your tolerance for lost and duplicated events before you agree on the design.
Start with the question: what decision will the search result support, and how often must the result be refreshed? Pulling with GetSplunk suits cases where NiFi needs the output of a Splunk search, such as a summary feeding another system, not the raw events. From Splunk, the flow needs an account with read access limited to the indexes and searches it uses, and an agreed search runtime. From NiFi, it needs a schedule, a record of the time window already retrieved, and a destination for the results. Confirm the property names, scheduling behavior and cluster handling in the GetSplunk component documentation before you design the schedule.
- Search scheduling: Each run consumes Splunk search capacity. Agree the frequency with the Splunk administrators and avoid overlapping windows.
- Result volume: Large result sets can strain NiFi memory and downstream queues. Ask Splunk for aggregated results where possible.
- Time window tracking: Confirm how the processor records what it has already retrieved, so that a restart does not re-read or skip a window.
- Cluster behavior: Confirm whether the processor should run on the primary node only, to prevent duplicate pulls.
- Wrong tool signals: If the data already flows as events, or if alerts must fire within seconds, pushing events or using Splunk's own alerting is usually the better fit, and repeated pulls add load without adding value.
Close the design by asking the Splunk team to confirm the search cost and the account permissions in writing.
Start with the question: which events, fields and repeated messages can be removed without losing evidence that your retention or audit rules require? NiFi can filter, route and reshape data before it reaches PutSplunkHTTP, which lowers the volume Splunk must ingest. Agree the list of required events with the Splunk owner, the security team and whoever answers audit questions, because removed data cannot be recovered from Splunk later. From Splunk, the flow needs the agreed retention categories and index design. From NiFi, it needs routing rules, field-level transformation and provenance so that every decision can be traced.
- Severity and source routing: Send low-value events to a separate destination, such as object storage, and only forward the events that answer defined use cases.
- Field reduction: Remove verbose fields that no search or dashboard uses, after confirming that none appear in required reports.
- Sampling: Sample high-volume, low-risk sources only where the policy allows it, and record the sampling rule in the flow documentation.
- Raw copy retention: If an audit or incident process needs the original events, store them before any reduction step.
- Measurement: Use NiFi provenance and throughput figures to compare volume before and after each change, and report the results to the Splunk owner.
Before going live, ask for written sign-off from the data owner on each filtering rule, and test that dropped events are still available in the raw store.
How to configure PutSplunkHTTP step by step
This sequence takes a NiFi flow from an empty canvas to a tested path that sends events into a Splunk index through HTTP Event Collector, with indexing acknowledgement, controlled failure handling and a token kept out of the flow definition.
Create the HEC token and confirm the target index
A Splunk administrator creates an HTTP Event Collector token in Splunk Web, sets the default index it may write to, and confirms that the index exists and that the token is allowed to write to it. Keep the token value in a secure location for the next step. Indexing acknowledgement is a token-level setting, so decide now whether this token will be used with acknowledgement enabled. The step is done when a test event sent with curl from a NiFi node returns a success response and appears in the test index in Splunk Search. Confirm the exact Splunk Enterprise or Splunk Cloud steps against the version your organization runs, because HEC setup screens differ between releases.
Store the token as a sensitive value
The NiFi administrator adds the HEC token to a parameter context and marks the parameter as sensitive, so the value is encrypted at rest and is not shown in the UI or exported with the flow. Reference the parameter from the controller service instead of pasting the token into a property field. If your team uses an external secrets source, confirm with your NiFi version whether a parameter provider can populate this parameter context. The step is done when the flow definition, exported as a JSON file from the canvas, contains no token text and the parameter shows as sensitive in the parameter context dialog.
Configure the Splunk controller service
The NiFi administrator adds a Splunk controller service, sets the HTTP Event Collector URL for the Splunk endpoint, and points the token property at the sensitive parameter. Configure TLS trust by pointing the service at a truststore that contains the CA chain for the HEC listener, and avoid disabling certificate validation to get past an error. Enable the controller service only after its validation shows no errors. The step is done when the service is enabled and a test connection from the service, or a single test FlowFile through the processor in the next steps, returns a successful response from Splunk. If the handshake fails, check the certificate chain and the hostname in the HEC URL before changing any other setting.
Build the ingest path with record parsing
The data engineer builds the upstream path that brings log or event data into NiFi, such as a ListenTCP, ConsumeKafka or tailing processor, followed by a record reader that matches the source format. Set attributes with UpdateAttribute or a record path step so each FlowFile carries the target index name, sourcetype and source values that Splunk expects. Keep only the fields needed for search and retention in the record, because filtering here reduces the volume Splunk indexes. The step is done when a sample file or message passes through the path and the attributes on the queued FlowFile show the expected index, sourcetype and source values in the Data Provenance view.
Configure PutSplunkHTTP and indexing acknowledgement
The data engineer adds a PutSplunkHTTP processor, assigns the Splunk controller service, and sets the index, sourcetype and source properties from the attributes built in the previous step. Choose the record or batch settings that match the source volume, and enable indexing acknowledgement only if the HEC token in Splunk is configured for it, because the processor waits for Splunk to confirm each batch was indexed. Send the success relationship onward to the next stage. The step is done when a test batch reaches the success relationship and the provenance event shows the acknowledgement was received, and when the events appear in the test index with the expected fields.
Add failure and retry routing
The data engineer routes the failure relationship to a retry path with a bounded retry count, and sends anything that still fails to a dead-letter destination such as a local directory, object storage bucket or queue that an operator monitors. Add a bulletin or alerting reporting task for the processor so failed batches are visible to operators. Record the expected behavior when Splunk is unavailable so operators know whether data will back up in NiFi queues. The step is done when the failure and retry paths have no unconnected relationships in the canvas validation and a deliberately failing test confirms that FlowFiles reach the dead-letter destination with their original content intact.
Run a controlled test with a bad token
The NiFi administrator runs a controlled test in a non-production process group. First send a small, labeled set of events and confirm they appear in the test index with the right fields. Then change the token parameter to an invalid value, run the same events, and confirm they take the failure route rather than disappearing. Restore the valid token and confirm recovery. Finally, check that the token value does not appear in the bulletin log, the provenance details or the exported flow. The step is done when the three checks pass and the results are recorded for the change record. Only then promote the flow to production with the same parameter context reference, not a copy of the token text.
How NiFi attributes map to Splunk event metadata
This table maps NiFi FlowFile content and attributes to the Splunk event fields that HEC accepts, showing who sets each value and how to confirm it arrived as intended. Read each row as a checkpoint: if the value is wrong at the Splunk end, trace it back to the parser, enrichment step or static parameter named in the row. Confirm accepted field names and constraints in the Splunk HEC documentation for your deployed Splunk version before you build the mapping.
| NiFi source | Splunk target | Who sets it | Check that confirms it |
|---|---|---|---|
| FlowFile content | Event body (event field) | Source processor or parser that emits the raw or record-formatted payload | Search a sample event and compare the raw text to the original log line byte for byte |
| FlowFile entry time or parsed timestamp attribute | Event time (time field) | Parser step that extracts the source timestamp, with an explicit time format | Compare Splunk _time with the source timestamp for events across a DST change and a late-arriving batch |
| Hostname attribute (for example, from ListenTCP or a file path parser) | host metadata | Enrichment step that maps the originating system name, or a static parameter for a fixed collector | Run a stats count by host and confirm no events carry the NiFi node name by mistake |
| File path or source system attribute | source metadata | Parser or RouteOnAttribute branch that sets the source per feed | Confirm each feed lands under its expected source value in a test index |
| Feed type attribute from routing logic | sourcetype metadata | Routing step that assigns a sourcetype from the feed definition, ideally from a parameter context | Check that props or sourcetype configuration on the Splunk side matches every value NiFi can emit |
| Target index parameter or attribute | index metadata | Static parameter per environment, or a routing attribute, not set by the payload itself | Confirm the HEC token permits the target index and that test events appear only in the intended index |
| Selected fields extracted by a parser | Indexed fields (fields object) | Parser or JSON/record writer step that adds fields, with names kept to Splunk's accepted pattern | Search with the field name and confirm values are present, typed as expected and not duplicated in the event body |
| Acknowledgement result from PutSplunkHTTP | Indexing acknowledgement status | PutSplunkHTTP configuration with acknowledgement enabled, verified by the flow's success and failure relationships | Force a failure in a test environment and confirm the FlowFile routes to failure and is not counted as delivered |
Reducing Splunk ingestion volume with NiFi before events are indexed
Filtering and routing in NiFi before events reach Splunk is the lever that changes how much data your indexers receive, and that directly affects licensing and index load. A flow can drop events that carry no detection value, sample high-volume sources that are useful only in aggregate, mask sensitive fields, and route whole sources to cheaper storage instead of the Splunk index. The processors that do this work, such as RouteOnAttribute, RouteOnContent, QueryRecord and UpdateRecord, sit upstream of PutSplunkHTTP, so the decision is made once in the flow rather than repeated in search-time filters. Before building anything, measure event volume per source and per index for a representative period, so you can prove the effect of each change afterward.
The first decision is which fields your detections actually need. Work backward from each correlation search, dashboard and alert, and list the fields it reads. Anything not on that list is a candidate for removal or reduction, but keep fields that analysts use during investigations even if no alert depends on them. Be careful with fields that Splunk uses for source typing and event boundaries, because removing them can break parsing on the receiving side. The second decision is which sources can move to cheaper storage. Sources that are mainly for retention, compliance or occasional forensic search can be written to object storage or a data lake through a separate branch of the same flow, leaving only detection-relevant events in Splunk. Confirm the retention requirements for each source with the people who own them.
Dropping events is acceptable only if you can show what was dropped and why. NiFi provenance records each FlowFile's path through the flow, including events routed to a drop branch, so keep provenance retention long enough to answer audit questions, and size the provenance repository for that window. Make the archive branch a deliberate destination rather than an afterthought, with its own naming, access controls and retention. Test that a reviewer can recover a dropped event from the archive and trace its route in provenance. Plan validation the same way: after each filter change, compare counts in Splunk with counts at the NiFi input, and confirm that masked fields are masked in both the indexed events and the archive. Review the rules with your security and compliance owners before changes go to production, since they determine what evidence exists later.
How to secure the NiFi to Splunk path
The NiFi to Splunk path crosses two systems that each hold credentials, and both need their own controls. The cards below cover the decisions that most often decide whether the path is safe: the HEC token, its storage, TLS validation, the Splunk role used for searches, NiFi parameter access and what sensitive data is allowed into flow logs and provenance.
Scope the HEC token to specific indexes
A HTTP Event Collector token should write only to the indexes its flows need, with the default index and any unused indexes removed from its allow list. Check the token's source type restrictions as well, so a leaked token cannot write arbitrary events into production indexes. Confirm the exact token and index settings available in your Splunk version, since the administration options differ between releases. Review the token's scope each time a new flow is added to the same token.
Store and rotate the token in NiFi
Keep the HEC token in a NiFi sensitive parameter or a parameter provider backed by your secrets manager, never in a processor property written in plain text in the flow definition. Sensitive values are encrypted in the flow and should be referenced through parameter contexts. Plan a rotation procedure that updates the token in NiFi and Splunk together, and confirm how a changed parameter value reaches running processors in your cluster before you schedule the change.
Validate TLS for HEC and the management API
Configure PutSplunkHTTP and GetSplunk to validate the Splunk server certificate against a trust store that your organization controls, rather than disabling verification to get a flow working. NiFi's own UI and API should use TLS with client authentication where your policy requires it. The NiFi administration guide describes the keystore and truststore settings used for this, and you should confirm the certificate chain Splunk presents, including any internal certificate authority.
Use a dedicated Splunk role for searches
GetSplunk runs saved or ad hoc searches under a Splunk account, so give it a dedicated role that can read only the indexes and fields the flow needs. Avoid reusing an administrator or a personal account, because the search results and the account's audit trail will then be hard to attribute. Confirm the role's search quotas and capabilities in your Splunk version, and check that searches cannot modify knowledge objects or configuration.
Restrict who can view sensitive parameters
Parameter contexts control which flows can read a value, and NiFi's authorization policies control who can view or change a parameter context. Limit the policies that allow reading sensitive parameter values to the few operators who manage the Splunk connection, and separate the people who edit flows from those who manage credentials. Use the NiFi authentication options supported by your environment, such as LDAP, OpenID Connect or SAML 2.0, so each change is tied to a named user.
Keep regulated data out of logs and provenance
Provenance and bulletin logs record attributes and, depending on configuration, content of events passing through a flow. If events carry personal or regulated data, remove or mask those fields before they reach PutSplunkHTTP and check how provenance retention applies to the content repository. Confirm with your compliance owner whether the events can be stored in NiFi at all, and test that sensitive fields do not appear in bulletins or debug output during a dry run.
Common Splunk integration failures and how to fix them
This table maps the most common symptoms in NiFi to Splunk flows to their likely causes and the configuration fixes that resolve them. Start with the provenance and bulletin checks in NiFi, then confirm the Splunk side, because most failures trace back to a token, an index, a TLS trust chain or a parsing setting.
| Symptom | Likely cause | Fix |
|---|---|---|
| HEC requests rejected with an authorization error | The HEC token is disabled, mistyped, or bound to a different sourcetype or index scope than the flow sends | Confirm the token is enabled in Splunk, copy it again into the PutSplunkHTTP controller service, and check that the token's allowed indexes include the target index |
| Events send successfully but do not appear in the expected index | The index parameter is empty or misspelled, or the token's default index differs from the one the search uses | Set the index explicitly in the flow, check provenance for the index value sent, and search across the expected index and the token's default index |
| Acknowledgement timeouts and FlowFiles stuck in the success path | Indexer acknowledgement is enabled but Splunk is slow to confirm, or the acknowledgement window is shorter than indexing latency | Check indexer acknowledgement status on the HEC endpoint, review Splunk indexing queues, and tune the acknowledgement wait settings in PutSplunkHTTP after confirming capacity with your Splunk team |
| TLS handshake or certificate trust failures | The Splunk HEC certificate chain is not in the SSL context used by NiFi, or the hostname does not match the certificate | Add the internal CA to the truststore used by the SSL Context Service, confirm the certificate subject matches the URL, and test the endpoint from the NiFi node itself |
| Duplicate events after retries or restarts | A failed request was retried after Splunk had already indexed it, or the flow reprocessed input after a node or session restart | Use indexer acknowledgement so retries are tied to confirmed ids, add a stable event identifier in the record, and check provenance for replayed FlowFiles before adding downstream deduplication in Splunk |
| Fields missing or values parsed incorrectly in Splunk | The record reader or writer drops fields that do not match the schema, or the sourcetype props on the Splunk side do not match the payload format | Compare the record schema with the event payload in provenance, fix the reader schema or choice strategy, and align sourcetype and line-breaking settings in Splunk |
| Queue backpressure when Splunk is slow | Connections before PutSplunkHTTP fill to their object threshold because HEC throughput is lower than upstream output | Read connection queue counts and bulletins, batch events before the put step, add filtering to reduce volume, and set backpressure thresholds that match the agreed Splunk ingest capacity |
| GetSplunk returns no results | The search time range, earliest and latest settings, or the query scope do not match the data, or the account lacks permission on the index | Run the same search in Splunk Web with the same time range, confirm the account can read the index, and check the last-event state the processor stores |
| GetSplunk returns too many results or repeated results | The query has no time bound or the processor state does not advance, so each run reads the same window | Bound the query with explicit time settings, confirm the stored time state advances between runs, and restrict fields and result counts to what the flow needs |
Questions buyers ask before connecting NiFi to Splunk
What drives the cost of connecting NiFi to Splunk?
The main cost driver is how many sources, sinks and data formats the flow must handle, followed by how much filtering and enrichment NiFi performs before data reaches Splunk. A partner charges for analysis of your sources, flow design, testing against your Splunk environment, documentation and handover. Ongoing costs come from running NiFi itself, including infrastructure, patching and upgrades, and any retainer you choose for support. Ask for a written scope that separates one-time build work from recurring operations, and confirm which Splunk and NiFi versions the quote assumes. DeployOpen does not publish a price list, so a quote follows from that written scope.
How long does a typical NiFi to Splunk build take?
Duration depends mostly on the number of log sources, how many of them need custom parsing, and how long it takes your Splunk team to confirm index, sourcetype and HEC token decisions. Testing against real indexes and agreed test windows often takes longer than the flow build itself. Environment access, change approval cycles and the number of data owners who must sign off also extend the timeline. Ask for a schedule in the written scope with named milestones and the client actions each one depends on, rather than a single end date.
What does our team need to provide for a Splunk integration?
You need to provide several things before work starts. Splunk administrators must grant access to create or confirm HTTP Event Collector tokens, indexes and sourcetypes in a test environment and then in production. Data owners must name which logs are in scope, what fields matter, and what must be removed or masked before indexing. Your team also needs test windows on both NiFi and Splunk, a place to run NiFi, and a named person who approves changes. Confirm each of these in the scope, because missing access is a common cause of delay.
Can our internal team build this without outside help?
Yes, if your team already runs NiFi in production and has Splunk administration skills. The work requires knowledge of NiFi processors, record readers and writers, controller services, clustering, and Splunk HEC behavior, including indexing acknowledgement. Teams without recent NiFi operations experience often underestimate the testing and error-handling work. A useful check is whether someone on the team has built a flow that handles failed deliveries and restarts without losing or duplicating events. If that experience is missing, a partner can build the flow, train your staff, or both under a written scope.
How do acknowledgement and retries affect duplicate events in Splunk?
Duplicates can appear when NiFi retries a delivery that Splunk already indexed but whose acknowledgement did not return. With indexing acknowledgement enabled on PutSplunkHTTP, NiFi waits for confirmation that the event was indexed before it marks the FlowFile as successful, which reduces silent loss. Retries still create the risk of duplicates, so the flow needs a deliberate design: consistent event identifiers, a clear policy for failed FlowFiles, and tests that interrupt delivery on purpose. Confirm acknowledgement settings and retry behavior with your Splunk team and in your own test environment before production use.
Does NiFi replace the Splunk Universal Forwarder?
Not necessarily. NiFi can receive, filter, enrich and route data that you send to Splunk, but it does not automatically replace a forwarder for every host. A Universal Forwarder is designed to monitor files and system data on endpoints, while NiFi is a dataflow platform that suits central routing, reduction and transformation. Many organizations use both: forwarders where they already work well, and NiFi where data must be reshaped, sent to several destinations, or reduced before indexing. Decide per source, and document which path each log type takes.
How should we handle an existing NiFi 1.x flow that sends data to Splunk?
Treat the migration as a separate project before you connect new Splunk paths. NiFi 1.28 is the last minor release of the 1.x series, and the project strongly encourages users to upgrade to NiFi 2. The migration guidance requires upgrading to NiFi 1.27.0 before moving to 2.0.0 and changing the flow configuration file from flow.xml.gz to flow.json.gz. Processors used for Splunk delivery may also need checking, so inventory every processor and controller service in the flow first. Ask for a written upgrade scope that includes a test cluster and a rollback plan.
How do we protect Splunk credentials and log data in transit?
Store HEC tokens and any other credentials in NiFi's sensitive value handling rather than in flow definitions that others can read, and restrict who can view or change controller services. Send data to HEC over TLS, and confirm that the certificates NiFi trusts match your internal certificate authority. Review what each log type contains, because security logs often include personal or regulated data that should be masked or removed before indexing. Confirm these controls against your own security policy and your Splunk deployment, since the exact settings depend on your versions and environment.
How DeployOpen scopes and delivers a NiFi to Splunk integration
DeployOpen plans, builds, documents and supports Apache NiFi flows that send logs and events to Splunk, inside infrastructure you control. The work starts with a written scope that fixes which sources, filters, HEC endpoints and indexes are included before any flow is built.
How we scope
- Inventory the log sources, event volumes and Splunk indexes that the NiFi flows must serve.
- Define which fields NiFi filters, masks or drops before data reaches Splunk, and who approves those rules.
- Agree the HEC token handling, TLS trust, NiFi cluster topology and acknowledgement expectations in the written scope.
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we build
- Build PutSplunkHTTP flows with indexing acknowledgement enabled and test how failed or unacknowledged events are retried.
- Build GetSplunk flows for search result pulls, including the query scheduling and state handling your team needs.
- Keep credentials in NiFi parameter and controller service configuration, with sensitive values kept out of flow definitions.
- Test each route with representative sample events and confirm the event counts and fields that arrive in each index.
How we hand over
- Version flows in the Git-based flow registry your team chooses so changes are tracked and reviewed.
- Document each flow's sources, filters, routing, index targets, failure handling and the reasons behind each reduction rule.
- Run a handover session with the engineers who will operate the flows, covering restart, replay and monitoring steps.
- Deliver runbooks for the cluster nodes, HEC tokens and acknowledgement settings so your team can change them safely.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after the initial handover.
- Review flow changes when Splunk sources, index design or NiFi versions change, including planned NiFi 2 upgrade work.
- Confirm with your Splunk administrators which HEC features and acknowledgement settings your Splunk version supports before go-live.
