I don't think logdog is the right place to infer the contents of free-form text.  The problem with most approaches to solve "highlighting interesting stuff" problem is by:
1. Assuming the underlying text has some structure, and building around it
2. Prescribing a format to the underlying executor and recognizing that one format.

(1) is unsustainable because test execution output format is essentially uncountable and perpetually changing.  How the stackdriver team solve this problem was by (2), prescribing a logEntry format, and writing tools to convert log lines to the logEntry format via flumed:
https://cloud.google.com/logging/docs/reference/v2/rest/v2/LogEntry

But anyways, fret not, we do have project proposals to solve the "can't find the error in log" problem, named shamwow:
https://docs.google.com/document/d/1bWtKtR4hJzWMIvXu6lyOjerukxpTcnOKjU2d-D1rOKM/edit?ts=5aa1e16d#heading=h.x9snb54sjlu9

Actually it's been renamed test-trove.  The idea is to a "test output format" and build tools around viewing and groking test results with a first class understanding of what they mean.

But back to the original question.  LogDog only deals with (1) datagrams (2) binary bit streams and (3) plaintext data.  Here we are talking about plaintext data, and Plaintext lines are not and will never be structured, so I think this bug is infeasible.