4 ms·

NO! No, no, no, a thousand times, no. I spend all day every day troubleshooting broken things. Human readable logs are the very last thing that I have left tha

• jeffffff 15y ago
  as a big data guy, every time i see structured data written in an unstructured, non standard, and possibly ambiguous and unparseable format i get the same urges. i think the best solution is separate logs for human consumption and machine consumption. if someone logs data that they want analyzed in some goofy format then they can also write and maintain their own damn parsers for it, i don't have time for that shit and the solution is so simple.
  • thaumaturgy 15y ago
    Yeah, I can grok that. I think that the needs of big data are a bit different from the needs of troubleshooters. For example, I usually just need to sift through the data to quickly find the few bits that are interesting to me; you probably need to do aggregation and derive patterns and all kinds of other magic. I would only counterpoint that what I wrote was not at all a defense of badly-formatted logs. I'm also not at all opposed to people generate separate logs for humans and separate logs for machines. In fact, I think that's a great idea. I just really really do not want to see machine logs taking the place of human-readable logs.
    • sneak 15y ago
      You could easily make a small unix filter that takes the json logs in, and spits out strings with "%date : %short_message" from them - enabling you to use them just like all of your other one-line-per-entry unixy plain logs. tail -f logfile | grep blah becomes tail -f logfile | json2line | grep blah There is no reason to have two sets of logs. JSON is human readable (with effort), and of course you can make a very small filter that will make it even moreso if you don't want to adapt at all. Machine-readable logs are a win. JSON is very close to providing the holy grail, machine _and_ human readable.
      • CrLf 15y ago
        In what format should that filter output? Which fields should it show? Should it be specific for the application or should it be generic? What parameters should it accept in this case? Do you see where I'm going with this? We have been using text-based logs and text-based pipes on unix for decades, even though it has always been inefficient to parse (especially on ancient machines). The thing is: it's much more efficient for humans. I understand the kind of cognitive dissonance this causes in programmers, I feel it myself. However, I've also been a sysadmin for a few years now and understand just how having plain text makes my life (much) easier.
        • sneak 15y ago
• CoffeeDregs 15y ago
  >Here's the thing: I can do anything with a human >readable text log. I can scan it visually and look for >anomalies; I can use my favorite text editor with it; I >can grep it; I can cobble together some magic >incantation on a command line to munge it to death >until it cries out in mercy and gives me exactly what I'm looking for. That's basically why the article is proposing using JSON: it's easily readable/scannable by a human, can be easily opened in a text editor, isn't all garbagy like XML, has near perfect support in every scripting language and is rumored to be Christ 2.0. >But if I ever open up a server log and get blasted by a jillion >lines of JSON that make it a thousand times harder for me to figure >out how something broke I'm going to go on a shooting spree. Are these really that different?: >host.com:80 w.x.y.z - - [25/Dec/2011:06:07:42 -0600] "POST /page/open HTTP/1.1" >200 1200 "-" "Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20100101 Firefox/8.0" >{'host':'host.com', 'timestamp':'2011-12-25 06:07:42', 'method': 'POST', >'path':'/page/open', 'protocol':'HTTP 1/1", 'response_code':200, >'content_length':1200, 'user_agent': 'Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20100101 Firefox/8.0'} There's a bit of extra verbiage, but the JSON version is perfectly extensible and would allow the devs to add additional debugging information to help you find issues. That said, I can see the downside to letting devs insert random crap, because you could get reams of garbage in the logs. As example of possibly helpful info it'd be easy to add db and app times: >{'host':'host.com', 'timestamp':'2011-12-25 06:07:42', 'method': 'POST', 'path':'/page/open', >'db_time':0.157, 'app_time':0.43, 'protocol':'HTTP 1/1", 'response_code':200, >'content_length':1200, 'user_agent': 'Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20100101 Firefox/8.0'}
  • thaumaturgy 15y ago
    > ...isn't all garbagy like XML... I don't think it's fair to take something that isn't garbagy at all and then say that the proposed alternative isn't bad because it's not as garbagy as one of the garbagiest things ever invented. :-) JSON may not be as garbagy as XML, but it's still garbagy. With logs in their current format, often my very first tool in log analysis is the scroll wheel on my mouse. It's so lovely because all the lines are unbroken, the columns line up so neatly, and the data in the columns are so distinct from each-other. JSON dicks all that up. Now, OK, I'll admit it wouldn't be very hard for me to whip up something that will take a JSON-formatted log and turn it into something I actually want to read. And in fact that's exactly what I'd end up doing. But, logs are already getting big enough that some companies are doing very stupid things to them. (Bluehost, by default, logs only the last 24 hours for all hosted sites; if you turn on their "extended" logs feature, their logs still have huge gaps in them.) JSON makes that problem a lot worse for those companies. And, if their log rotation isn't set up correctly -- and if they're doing vhosting I'll bet you a donut it's not -- then what would have been a silly amount of data to process now becomes nearly impossible to process.