Note two replies of mine prior where I state ISO 8601 or similar. Also not where I said the json would be constrained to the message portion of the entry. Preferably there's a logging mechanism that takes care of that for you, so you
can't screw up the timestamp and type portions of the entry. In that case, your entries become:
2015-01-01 01:01:01 Info Log message A
2015-12-13 12:34:55 Debug Log message B
2015-12-13 01:34:55 Error log message C
2015-12-13 13:34:55 Error log message D # let's assume that was 1 PM data for the sake of the example
2015-12-13 01:34:55 Error log message E
Getting the date is trivial. Getting the type is also trivial. Give a static field size to type and it's event more so. The point is, you abstract the message from the rest of it, so the message
can't screw up the metadata of the entry, and log whatever you want for the actual message (xml, json, plain text, whatever, just no raw newlines). This is what we have today with syslog, sans newline replacement and a slightly different date format (but still unambiguous). It works. It's useful. It's
VERY easy to filter type type or date. You can take the first X chars and split on space/whitespace if you need to. You can log a message of a few megabytes and if there's no raw newlines there's efficient utilities to ignore that until you have what you want (/bin/cut).