Our JSON endpoint for HTTP Event Collector does not do timestamp extraction. Our JSON endpoint expects events sent using a lightweight structure, our JSON Event Protocol. The plus side is your "event" payload can be any JSON (or not) / can have whitespace, newlines, etc and it will still come as a single event. For example you could also have a Java stack trace and it will easily go in as a single event. For the timestamp, you have to specify "time" explicitly outside the payload in the event envelope in epoch format i.e. { "time": 1426279439, "host": "localhost", "source": "datasource", "sourcetype": "txt", "index": "main", "event": { "hello": "world" } } In Splunk Cloud / Splunk 6.4 you have a different option, our new raw endpoint. With raw you can send an arbitrary payload to HEC (/services/collector/raw) and we will honor breaking rules and do timestamp extraction. It should I believe meet your need. ... View more

@mdufrasne it is technically possible to do this, but you will need a derived listener and the code is going to get a bit ugly. The reason is because our listener requires parameters to be passed via the constructor because we did not optimize toward the config file based approach. Please file a bug though in our repo, as we could look into making this work, though it will be some time before we got to it. You could also consider sending us a PR. Here's how to do it yourself with the current listener. Basically you need to derive from our listener and add a default constructor. In your new listener add properties for all the parameters that would be passed via the constructor. The tricky part is the parameters in the ctor are then used to configure the internal HttpEventCollectorSender instance. You'll need to override this member using reflection APIs. The next question is when to do that override as you cannot do it in the default constructor as the properties are not initialized yet. One way to do it (cleaner but harder) is to override each of the methods in this region and have them check a flag which if not initialized, then overrides the sender. The check function needs a lock because multiple threads could be accessing the listener. Once the sender is overridden, then you can set the flag to true. The alternative is to have each property override the sender as it is set, or add a dummy boolean property that when set to true overrides the sender. Then you set the property last in your config. If it were me, I'd probably keep it simple and just go with the last option and use the dummy property. As far as how to wire up the listener itself in config, you have to specify the type and assembly as is mentioned in this SO post. Let me know if any of this makes sense 😛 ... View more

@otryshko based on the error my guess is you have enabled indexer acknowledgment on the token. If so, then you have to supply a channel. You can find this in our API docs. If you disable indexer acknowledgment for the token you won't need to supply channel. ... View more

This is fixed in the next version of Splunk, 6.4 which will be shipping very soon. ... View more