1

We have a system that generates lots of logs and we have to somehow maintain logging workflow in a project.

The 'strict' (let's assume it's strict) requirement is that there should be a document describing format for each message and each message should comply to that format.

(By format I mean BNF-like things like 'some text {one|two} [three]' etc.

It's also desirable to see log messages themselves in the code, not some IDs referring to them in some 'message list'.

Currently the state is that there is a large file with 1000+ messages with IDs, severities and user actions described for each one, and in the main code we are just struggling to keep log messages exactly in the format we specified (and of course failing in that).

It isn't obviously a viable option to like parse the source code on build and try to ensure message format that way (messages can be written not literally etc.).

So, how to implement such a format-complying logging system?

I know it sounds a bit like a 'advise me some tool'-kind-of-question, but I still think it's more about conceptual approaches to the problem (yet still I'd be really glad to see example of such systems! :) language doesn't matter).

Improve this question
3
  • If I understand your problem correctly, it sounds like the ideal solution would be to put some new rules into whatever linting system you're using, such as your IDE. I would imagine that most linting systems allow rules expressed in the form of regexes, so it should be a simple matter to match your BNF pattern.
    – Robert Harvey
    Feb 2, 2018 at 5:20
  • I don't understand the question. You got a table of error codes and text, why can't you display them?
    – Mikhail
    Feb 2, 2018 at 6:14
  • It seems that OP wants to ensure consistency of log messages even if they are used multiple times in different places, but they should also be fully available to the code reader in each place. Those two requirements can't be combined without external tool support, hence the idea of adding linting rules.
    – Kilian Foth
    Feb 2, 2018 at 7:09

1 Answer 1

Reset to default
2

Your first and most important step is to develop an API. Create a library which when called will log the message. Yes, that's all for step one. The reason for this is to coordinate logging into a collective place for future development to occur. If the caller is providing his or her own format, offer a second method to call which is deprecated from the start, but adds no formatting.

Once you've done this step (and if you have many projects, it is no small step), then you can load a configuration and use it to determine the proper format of logging entries. I would highly recommend you have a means to hide logging levels so you can filter out messages according to severity. Better still if you can filter out specific namespaces or packages.

Each project/caller then removes his or her format from the message and calls the standard logger methods which automatically adds the desired format.

Ideally your logging format should be entirely configurable for future usage. I don't know the language you're using (you didn't specify), but a number of libraries already exist which do this functionality, for example Log4J in Java. If such a library exists, you'd probably be better off using that. However it is still recommended to create your own API so that future changes don't have to be performed across the board but only in one place.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.