Getting Data In

How to optimize data (key/value pairs) to be injected into Splunk 6.3 using the HTTP Event Collector?

simpkins1958
Contributor

We are adding a new feature to our product to send data in key value pairs into Splunk using the new 6.3 Http Event Collector. We want our data in Splunk to be easily usable by customers as they build Splunk dashboards.

We have some values that change infrequently. Should we be sending the value that changes infrequently with each event we send to Splunk, or just when it actually changes? Or should we send that value only when it changes?

2015-11-09 16:00:00.000 sentbytes=1000 receivedbytes=50 signalstrength=good
2015-11-09 16:00:05.000 sentbytes=10 receivedbytes=750 signalstrength=good
2015-11-09 16:00:10.000 sentbytes=109 receivedbytes=0 signalstrength=good
2015-11-09 16:00:15.000 sentbytes=244 receivedbytes=987 signalstrength=poor

or

2015-11-09 16:00:00.000 sentbytes=1000 receivedbytes=50 signalstrength=good
2015-11-09 16:00:05.000 sentbytes=10 receivedbytes=750 
2015-11-09 16:00:10.000 sentbytes=109 receivedbytes=0
2015-11-09 16:00:15.000 sentbytes=244 receivedbytes=987 signalstrength=poor
0 Karma

jeffland
SplunkTrust
SplunkTrust

It's possible (and quite simple if you know how, a simple streamstats with coalesce should do) to have the data from an earlier event appear in the following events. If you want the easiest solution for your customers however, then send every value with every event. The tradeoff is more license usage.

0 Karma
Get Updates on the Splunk Community!

Enterprise Security Content Update (ESCU) | New Releases

In December, the Splunk Threat Research Team had 1 release of new security content via the Enterprise Security ...

Why am I not seeing the finding in Splunk Enterprise Security Analyst Queue?

(This is the first of a series of 2 blogs). Splunk Enterprise Security is a fantastic tool that offers robust ...

Index This | What are the 12 Days of Splunk-mas?

December 2024 Edition Hayyy Splunk Education Enthusiasts and the Eternally Curious!  We’re back with another ...