Sign in to follow this  

Logging system Output

This topic is 2339 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hey guys,

So I'm working on the logging system for my engine. I already (more or less) have output to console done, so I just want to create an output to file. I already have a file class that can create files, append to files, and so forth. And my string class can handle streaming in of text and numbers, so in terms of sending stuff to files, I'm golden. That's done.

So I have turned my attention to what sort of output format I want. I could just create a .txt or a .log file and keep appending new log entries to the end and call it done. But I kind of want something a little more sophisticated than that. I was thinking something that could be opened in a browser, so an .html (or .xls or even .php?) file.

The problem with that is the footers (.e. html closing tags and what have you). Since I'm logging events in chronological order, I have to keep adding stuff to the end of the file, but then I need those footers at the end. Plus, at any given time, I would like to always have a valid file (so that if the engine should crash, we at least have logs up to that point). Which means I can't just write the footers when the engine shuts down, they have to be there always.

So you see my problem. I can't just append text to the end of the file, because then it would be after the closing tags. I suppose I could find where the closing tags start in the file, and start writing my new lines there, and rewrite the closing tags with each new entry. But that seems a bit inelegant.

I was thinking perhaps I could actually write two files per log, one with all the standard html stuff but no actual data, and then a second file with just the data in it that could be written to sequentially. Then the first file would load the second into the proper place. The downside to that of course being that now there are two files per log, but perhaps I don't really care so much about that.

Anyway, do you guys have any advice on the subject?

Share this post


Link to post
Share on other sites
HTML logs are pretty, but ultimately pointless. For logs you generally want to search them quickly, so a simple text format that is easy to grep is ideal.

You can write a post-processor batch program that takes the log and prettifies it, your web server could even include some PHP that loads the file and dynamically styles it.

Share this post


Link to post
Share on other sites
Before spending any time on a fancy logging system think about your general workflow and whether you would honestly benefit from having this system. I personally spend very little time reading log files, and most of it involves scrolling to the bottom and seeing what happened last before everything blew up. In my case, making it look pretty would be a complete waste of time.

If your logging system can output onto the screen in some form (such as your console), outputs to the Visual Studio output window, and outputs to a file which can be emailed or attached to a bug report in the event of a crash, it's fine. In fact, if you simply use OutputDebugString to send messages to the Visual Studio output window, you can use the Debug View program from sysinternals to be able to view your log in real-time while you run your game and piggy back it's features for free. If you want to go more advanced than that, the ability to throttle verbosity would be more useful than pretty formatting.

However, if you're really interested in making an HTML logger, I would recommend running a second process to write the log file and some form of IPC to communicate between the two. That would allow you to continue running when your game crashes and write the closing tags properly. It's actually pretty common for logging systems to operate this way, and sending all the data over the network. It ensures you get the log in the event of a crash, even one which takes down the entire machine since it enables you to connect remotely. You also get the benefit of not being tied down to any platform/language, which enables you to capture log files for your game running on consoles and the ability to write the GUI app to display the logs in any language you choose since you only need to read packets off the network. You can connect to multiple machines (or even instances) at once if you're testing a multiplayer session against yourself. The application you write to capture and display the log can enable several other useful features, like filtering, highlighting, etc. It would probably be overkill for your project, but just to give you ideas of what else is out there.

Share this post


Link to post
Share on other sites
Okay, thank for the advice everyone.

I think, based on what you guys have said, and upon giving it some further thought, that I will (at least for now) stick with a simple .txt file.

One of the reasons I was thinking html was to have the ability to spit out some useful information on the hardware, version numbers, DirectX versions, and so forth, in addition to the sequential event logging, and have it nicely formatted for use with bug reports. And I'd still like to do that at some point. However, for the moment, I can forgo that. As Gekko says, right now the only real reason I'll go into the logs is to figure out why something blows up. So it really doesn't need to be all that pretty.

Share this post


Link to post
Share on other sites
Well, I don't see why you can't have both... keep a .txt file for your "everything that happens in the program" spam, and then once at startup (or on crash or whatever) output a nicely formatted HTML file with all the data you want in your snapshot.

Share this post


Link to post
Share on other sites
Oh, definitely. I do want that functionality before the engine goes out and people other than me are using it. Otherwise I'm going to be lost when it comes to dealing with incoming bug reports. But for now, while the engine is in production, and the only one using it is me, I don't really need that, so it can wait.

As long as I have a console output and an output to file (with independent verbosity levels), that's all I really need for the production phase.

Share this post


Link to post
Share on other sites

This topic is 2339 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this