My experience when doing tuning of a different file integrity checker a number of years ago led me to 2 approaches to maintaining my operational sanity.
1) The files showing changes on an average day I almost always turned off reporting for without guilt. There were only so many cycles in a day and almost any file mod that happened as a matter of course that COULD have been from a bad actor would ALSO have required other modifications to produce a successful compromise AND a bunch of log data I was also using the tool to watch so while the security purist in me said, "That program shouldn't change that file in that way that prevents me from seeing a real compromise that would involve a change in that file" so much of the software we all use is out of our control so I would write the exception to stop the reporting, make a note on my "exceptions I hate" list and revisit the decision as part of my annual reviews. Sometimes the thing got fixed that allowed me to turn monitoring back on for that file, but that was uncommon. I just needed to come to peace with it.
2) The files showing changes during system updates I, too, wanted an automagic way to have the system differentiate for me, but I was never able to find a way and I ended up being OK with that. For file changes during system patching, I knew when patch day was coming so I could "safely" ignore massive numbers of file change alerts at the time and then went through my summary report the next day, scrolled through it next to the list of software that had been updated (found on the change control form) and ended up being pretty confident no one had snuck anything in that wasn't expected. You might call that "ignoring" messages, but operational reality is seldom so black and white and people need to make choices of where to expend their time in a sea of information. The other reason that helped me sleep well with this approach is that it meant when someone did a change that did NOT go through the change control process on an average Tuesday, my tightly wound file integrity checker would spring into action and I could immediately track down whether it was a breach (it never ended up being a breach) or a tech who violated policy by skipping over the change control process (almost as big a threat as a breach). Either way, it was a win, but took a while of reminding people we were watching to stop them from skipping over the change control process they previously thought they could get away with. Management support was absolutely necessary to make this happen.
So once I got past the psychological barrier of "I have to check every file integrity monitoring tool alert" after patch day the tool became really useful in a completely unexpected way. Obviously, your situation will be different, but you asked how people deal with this and my answer was I used it to get patching and software installations under control and it worked great for that. Perhaps OS updates occurring at unpredictable times (setting off OSSEC in unpredictable ways) is the issue you may want to address.
My 2 cents,
Scott