Log parsing can be a slippery slope, depending on how you do it. I think you'd want to be pretty targeted to avoid alerting about stuff that's not very important. But then, you still want to be effective in catching issues, so you don't want to be too permissive...

I noticed at least one of the reports you link to is a proper kernel WARNING (e.g., WARN_ON()). Those are at least pretty well-defined, and we have infrastructure for trapping and reporting those (dumped to /var/spool/crash/, goes to crash reporter). And I see there's even a test which checks that already:

client/site_tests/audio_CrasSanity/audio_CrasSanity.py

It parses for files named /var/spool/crash/cras* and reports failure if there are any additional dumps after its sanity tests are run. We could probably imitate that, at least.

We wouldn't be able to do that for *all* Wifi tests though, since some are actually intending to trigger recovery behavior [1], where we've instrumented that code path to trigger WARNINGs on some kernels, since we'd like to know if users are having to exercise that recovery behavior very often.

[1] server/site_tests/network_WiFi_Reset