4 ms·

His first bullet point is probably the most practical thing I know about logging. Log lines are useless without context especially when the lines are interleave

by zawerf 7y ago

His first bullet point is probably the most practical thing I know about logging. Log lines are useless without context especially when the lines are interleaved. But this is easily fixed just by prefixing them with a context id that you filter on later. This requires no frameworks and even works with unstructured text logging. Super simple, super useful, not everyone does it.

meowface 7y ago
True, but this is semi-automatically handled by any structured logging library, though. No need to reinvent the wheel or force yourself to remember to prefix or postfix every log message with one or more "%s"'s (or equivalent) and the ID(s) to interpolate. I think that's one of the main reasons to use a structured logging library in the first place, and maybe the main purpose of structured logging. A simple example for a Python Flask app: http://www.structlog.org/en/stable/examples.html http://www.structlog.org/en/stable/examples.html log = logger.new(request_id=str(uuid.uuid4())) log.info("user logged in", user="test-user") # gives you: # event='user logged in' request_id='ffcdc44f-b952-4b5f-95e6-0f1f3a9ee5fd' user='test-user' Sure, if you absolutely must use unstructured logging, you need to remember to do the format string prefixing or postfixing for every single message. But why put yourself in that position if you don't need to? Other than maybe when maintaining large legacy apps that aren't worth the effort to add structured logging to.
- SahAssar 7y ago
  The point as I read it was to do this once, and only once per request. So if you have a few different microservices that call each other you generate the id once, either at the first service it hits or (preferably) at the load balancer, and then propagate it down to all other services. This is especially useful if you use queueing or methods of doing tasks not bound to the same process as what the request hits. If I just copied your example I would probably have a few different ID:s for the same request in different parts of the application (unless it was a single-service app directly exposed to the internet).
  - meowface 7y ago
    True, this is complicated by a microservice model. I haven't worked with microservices much, but I figure there must be some libraries and tooling out there that can make this simpler. From some quick Googling, it looks like this is a component of some microservice frameworks. But I understand that this is a case where you'd often have to implement this yourself into your architecture, like at a load balancer / reverse proxy. So point 1 is valid.

by zawerf 7y ago

meowface 7y ago

True, but this is semi-automatically handled by any structured logging library, though. No need to reinvent the wheel or force yourself to remember to prefix or postfix every log message with one or more "%s"'s (or equivalent) and the ID(s) to interpolate. I think that's one of the main reasons to use a structured logging library in the first place, and maybe the main purpose of structured logging. A simple example for a Python Flask app: http://www.structlog.org/en/stable/examples.html http://www.structlog.org/en/stable/examples.html log = logger.new(request_id=str(uuid.uuid4())) log.info("user logged in", user="test-user") # gives you: # event='user logged in' request_id='ffcdc44f-b952-4b5f-95e6-0f1f3a9ee5fd' user='test-user' Sure, if you absolutely must use unstructured logging, you need to remember to do the format string prefixing or postfixing for every single message. But why put yourself in that position if you don't need to? Other than maybe when maintaining large legacy apps that aren't worth the effort to add structured logging to.

SahAssar 7y ago
The point as I read it was to do this once, and only once per request. So if you have a few different microservices that call each other you generate the id once, either at the first service it hits or (preferably) at the load balancer, and then propagate it down to all other services. This is especially useful if you use queueing or methods of doing tasks not bound to the same process as what the request hits. If I just copied your example I would probably have a few different ID:s for the same request in different parts of the application (unless it was a single-service app directly exposed to the internet).
- meowface 7y ago
  True, this is complicated by a microservice model. I haven't worked with microservices much, but I figure there must be some libraries and tooling out there that can make this simpler. From some quick Googling, it looks like this is a component of some microservice frameworks. But I understand that this is a case where you'd often have to implement this yourself into your architecture, like at a load balancer / reverse proxy. So point 1 is valid.