Getting Data In

Delay during log ingestion from Azure

antnovo
New Member

Hello, have a question regarding log ingestion from Azure. At the moment, im using REST API to onboard logs to the on premise Heavy Forwarder which sends data to indexes located on splunkcloud.

For some reason there's a huge delay between event indexing and event creation time, still receiving logs that are 3 months old and new logs are getting delayed. What can be a reason for such a delay? Is it a normal behavior during Azure and Splunk integration?

Thank you in advance.

0 Karma

integratorz
Path Finder

@antnovo I would check the throughput restriction Splunk has by default. It throttles how much data splunk can send to 256kbps. This is done in limits.conf:

[thruput]
# setting this to 0 means makes it unlimited (be careful as a single forwarder can overwhelm an indexer)
maxKBps = 0
0 Karma

antnovo
New Member

Hi,

Thank you for suggestion, checked limits.conf and it was already set to 0. Could it be related to usage of REST? Haven't found a single issue like this in Splunk answers related to log injection via Splunk add-on for Microsoft Cloud Services.
I'm considering to switch from REST to direct integration of Splunk and Azure via App but not sure if it will solve the problem.

Have a great weekend

0 Karma

integratorz
Path Finder

What is the interval you a querying the API at?

0 Karma

antnovo
New Member

Hi, i was querying the API at 1h interval, changed it this morning to 5 minutes.

Thanks

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 ...