With ingestion-based charges a fact of life in our new SaaS world, we constantly need to be aware if the logs and events that we are ingesting into vRealize Log Insight Cloud. A flood of one kind of stray event could be causing thousands of dollars of unnecessary ingestion costs, or even worse, causing overages if you purchased vRealize Cloud Universal. Let’s look at some of the queries and chart parameters we can use to find out what events are spamming your vRLIC instance and if they actually belong there or can be dropped.
Let’s start in the Log Explorer in vRLIC. We see our standard view of all logs that have been ingested in the past 5 minutes.
First thing we need to do is switch our chart to group by non-time series hostname. This will break out how many events each host has pushed to vRLIC in the last five minutes.
Next, we need to change the time interval to 24 hours. If you’re ingesting a particularly large amount of events and 24 hours takes too long to populate, you can lower the time period to 12 or 6 hours.
This should give us a nice chart of which objects are pushing the most logs to vRLIC, and where we need to start looking.
Log Insight Cloud is set to show an event stream by default, which isn’t useful in troubleshooting where event floods are coming from, but we can change this to ‘Types’ and see which events are the loudest.
In this example, we have one event across our environment that is the loudest, making up almost 37% of our ingested events. Now you need to decide if this event can be fixed at the host end, dropped or kept if it’s necessary.
If we want to drill in deeper to an individual host, we can click on the host in question in the chart, and it should bring up all events for it.
Then we can check the ‘Types’ and see which logs are misbehaving.
This concludes our demonstration on checking for noisy logs in vRealize Log Insight Cloud. Even if you aren’t experiencing overages and you just want to know if any hosts or apps are flooding vRLIC with unnecessary logs from a misconfiguration or issue, you can do that with these simple steps.
3 comments have been added so far
How about an ingestion filter so the customer can limit chatty log message log types right at the ingestion point rather than on multiple endpoints?
I agree with the other commenter. There needs to be a way to easily identify and drop logs before it counts towards your ingestion limit. This can be done reasonably easily for sources with a VRLI agent. But for host logs it’s extremely difficult.
Good news on that front. We’re working on a way to drop logs before ingestion so it doesn’t count towards ingestion limits. The solution should be available in late Q3 or early Q4.