Interesting idea, but...

Posted Nov 20, 2011 22:19 UTC (Sun) by Cyberax (✭ supporter ✭, #52523)
In reply to: Interesting idea, but... by vrfy
Parent article: That newfangled Journal thing

Have you considered using reverse domain names for message ids?
UUID are just too unwieldy. Imagine that I'm a developer writing:

class SomeClass
{
    void someMethod()
    {
         while(true)
         FILE *fl = fopen(...);
         if (!fl)
             log(DEBUG, "File with data is not found, trying to create it");
    ...

At that moment you realize that you need a UUID for this message. Ok, easy enough:

class SomeClass
{
    void someMethod()
    {
         while(true)
         FILE *fl = fopen(...);
         if (!fl)
             log(DEBUG, "d92bc8ba-7a98-4e49-8384-8ee013e2f773", "File with data is not found, trying to create it");
    ...

But damn! Now my string wraps around 80 character limit! And if I'm unlucky it can wrap around inside the UUID itself, so I need to reformat my code.

Alternatively, I need to create a file with #defines of UUIDs and write things like this: "log(DEBUG, FILE_DATA_NOT_FOUND_UUID, "File with data is not found, trying to create it");" which leads to duplications. So most lazy programmers (such as myself) would just define a couple of UUIDs and use them with free-form text fields for verbose messages.

So please, consider making a good API for developers to be your first priority. And using UUIDs in API is definitely doubleplus ungood.

to post comments

Actually I think it's good idea to have two types of logs

Posted Nov 20, 2011 23:43 UTC (Sun) by khim (subscriber, #9252) [Link] (6 responses)

I think Google does it right. They have two separate types of logs:
1) Binary structured logs which are moved to centralized storage, kept for a long time and are used for a lot of things.
2) Debug free-text logs which are only kept around till server is restarted.

Sometimes messages generated in logs of second type are deemed valuable enough and are "promoted": at this point unique message type should be added, message should be documented, etc. Adding unique UUID is trivial in comparison :-)

I doubt it makes much sense to force structure on all log messages which program can ever generate. If log record is supposed to be analyzed exclusively by humans then it's Ok to use free-form text for it. If it can be used by other software then it's time to organize and document it.

Actually I think it's good idea to have two types of logs

Posted Nov 21, 2011 1:22 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (5 responses)

Well, if it can be made easy to use structured logging everywhere, then why not do it?

I don't really see how reverse domain names are worse, except of handwavy 'it's faster to use UUIDs'.

Actually I think it's good idea to have two types of logs

Posted Nov 21, 2011 1:31 UTC (Mon) by dlang (guest, #313) [Link] (3 responses)

what is making it hard to use structured logging with syslog?

Actually I think it's good idea to have two types of logs

Posted Nov 21, 2011 1:49 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

Well, the lack of structure, for one thing. There are even tools (like http://www.splunk.com/ ) that exist to parse at least some of the logs.

Actually I think it's good idea to have two types of logs

Posted Nov 21, 2011 10:31 UTC (Mon) by dlang (guest, #313) [Link]

I am very familiar with splunk, it doesn't parse the logs, it just indexes every word in the logs.

but back to my point. you can send structured logs via syslog today, there is even a standard to do so. People choose not to do this today, but that's not the fault of the syslog mechanism, that's the fault of the programmers.

As has been noted elsewhere, you can still make unstructured logs through this new mechanism, so the new mechanism doesn't give you structured logs any more than syslog does

Actually I think it's good idea to have two types of logs

Posted Nov 23, 2011 17:01 UTC (Wed) by sam-williams (guest, #57470) [Link]

Splunk is really more about using the data in the logs for enterprise systems management. Suggesting its purpose is solely for reformatting syslog data is inaccurate.

Structure would improve things a bit, but no self-respecting systems administrator would suggest they can't do their job without a bit of binary hand-holding. The binary fileformat could cause more problems then it cures. Care should be used in providing an ability to access this information with simply tools.

As I've already said...

Posted Nov 21, 2011 8:08 UTC (Mon) by khim (subscriber, #9252) [Link]

Any conclusion made from false premise will be true so you rant is certainly valid.

Well, if it can be made easy to use structured logging everywhere, then why not do it?

The only way known to humanity is to put fixed value in all fields except textual "details" field and then write free-form description there. A lot of peoples tried to make "structured logging everywhere" work, yet none succeeded. This means it's time to stop trying to push "structured logging everywhere" idea and think about different question "do we really need structured logging?" and the answer is "probably not". A lot of logs only make sense for someone who has detailed knowledge of the program. If you don't think long and hard about what your log is trying to convey and to whom then then no amount of structure applied will help. And not all log messages deserve such attention. At least this is what developers usually think - and if you system will not be accepted by developers then it may as well not exist.