Form-view and flashtimeline displaying different results when the search has tag::eventtype

[Paolo_Prigione]

I have a form-view (that feeds many panels out of the same searchTemplate) which only displays about 10k to 16k results while the same search, run in the flashtimeline over the same time period shows > 100k....
My search is as simple as this:

tag::eventtype=perform_monitoring | fields + host sourcetype eventtype

Is there any limit to the results returned by a search performed into a view looking only at tag::eventtype?

I am using eventtypes to classify some notable events. Something like:

• user login success
• user login failure
• user provisioning success
• user provisioning failure
• ... and so on.

These eventtypes all have a tag: "perform_monitoring". I created a form view which has a single search to feed all its panels:

<searchTempate>tag::eventtype=perform_monitoring | fields + ...all the necessary fields</searchTempate>

Every single panel has its own:

<searchPostProcess>search eventtype="user login *" | rex field=eventtype "user login (?<result>\w+)" | timechart count by result </searchPostProcess>

However, if I execute this search, say, on the last 24 hours, the results will only show about 2 hours of data, and will always be between 10k and 15k. But if I run the same search on the flashtimeline view, I get > 100k results for the same time period (and same user), and they span over the full 24 hours.

The job manager is telling me the correct earliest time (i.e. 24h ago) and reporting a # of events coherent with what displayed on the form-view. Yet, same search on the flashtimeline shows 10x more results...

I really have no idea why this happens... Do you?

[Paolo_Prigione]

Limits.conf seems to be the reason:

[search]
max_count = <integer>
* The number of events that can be accessible in any given status bucket.
* The last accessible event in a call that takes a base and bounds.
* Defaults to 10000.

In facts, by inspecting the search job, I find :

eventAvailableCount 10000
eventCount  10714
statusBuckets 0

However, I see no easy way to circumvent this, other than disrupting limits.conf with an unreasonably high setting....