News for hackers. Stuff that matters.
Re:Distributed Logging Architecture in the Container Era by manyxcxi on Thursday August 11, 2016 @11:45PM (#12273287)
I've just started down a path for us and been pretty happy with Loggly so far.

Just by adding a UUID to the requests as they're initially received I'm able to follow the chain of events across 5 different services, a message queue, and reconcile with any code exception reports from Bugsnag.

We don't have a lot of unique clients, but we do have a lot of requests.

Loggly can be set to parse logs (or have the data sent directly to it) and then tag messages with keys/values that can let you watch your request through every server.

Re:Distributed Logging Architecture in the Container Era by rjbwork on Friday August 12, 2016 @12:28AM (#12273396)
Yeah, Loggly is very solid. I've set up logging infrastructure for 2 companies using it now. Their structured logging parsing, searching, and alerting is fantastic.
Re:Distributed Logging Architecture in the Container Era by ktamura on Thursday August 11, 2016 @11:59PM (#12273318)
Now that I understand the parent comment, I don't think this quite solves the problem he's asking unless all of your services are perfectly synchronized. No?
Re:Distributed Logging Architecture in the Container Era by manyxcxi on Friday August 12, 2016 @12:08AM (#12273341)
For us, messaging between services go through queues and a client request might start in a particular service and wind it's way through a few others to finish the work. You wouldn't have the same client requesting things from two different services simultaneously, though in fairly short order they come through. Our use case might be just simple enough that this wouldn't work for a lot of people.

Also, if I'm looking at access logs I'm not going to have that ID unless I start putting it in request headers. Right now the application logs and other monitoring tools pick it up though.

Edit: Didn't see mention of the clock on my first post, but it still stands for us that we're not in the millisecond timings between requests going in and out of services so we haven't had a problem with the timestamps from the systems they're on. Requests generally take a few seconds to process (handle a file upload of decent size, ETL some data, pump out some output document, etc) so each step through a service buys enough time before moving on to the next thing that we're not getting out of order log statements across each service.

Re:Distributed Logging Architecture in the Container Era by vardump on Friday August 12, 2016 @04:55AM (#12274176)
> Edit: Didn't see mention of the clock on my first post, but it still stands for us that we're not in the millisecond timings

Vector clocks don't necessarily have much to do with clocks. It's an algorithm for generating order in a distributed system.

https://en.wikipedia.org/wiki/Vector_clock

Re:Distributed Logging Architecture in the Container Era by ben_jones on Friday August 12, 2016 @04:28AM (#12274099)
Any tips for a beginner on optimizing usage of the dashboard? Not using it for much right now, and I feel like the interface is going to take awhile to optimize/learn.
Re:Distributed Logging Architecture in the Container Era by organsnyder on Friday August 12, 2016 @06:36AM (#12274490)
How are you passing that UUID along the request chain? For instance, when one microservice calls another, does it have to be manually passed in?
Re:Distributed Logging Architecture in the Container Era by eddieroger on Friday August 12, 2016 @10:09AM (#12275742)
My web stack checks for a specific header at each potential level of entry, and in the absence of a value, generates one. Then each layer's logger will log it back out. It's pretty straightforward for web requests - just use the plumbing that's already there, headers.
Re:Distributed Logging Architecture in the Container Era by jacques_chester on Friday August 12, 2016 @09:22AM (#12275380)
Some platforms will do this for you -- Cloud Foundry will show `x-cf-requestid` for anything that passed through the gorouter and back.