Premise Data Logging?
- Thread starter lazyone
- Start date
Motorola Premise
pm2000
New Member
lz,
Here are some relevant threads in the original Premise SYS forum. Extending one of the logging modules is probably the best way to go. I was thinking about writing one myself. Database is defintely the way to go. I would also write a UI class so that you could browse the event log directly in the SYS Browser.
patrik
http://www.premisesystems.info/forums/4168/ShowPost.aspx
http://www.premisesystems.info/forums/1123/ShowPost.aspx
http://www.premisesystems.info/forums/6231/ShowPost.aspx
Here are some relevant threads in the original Premise SYS forum. Extending one of the logging modules is probably the best way to go. I was thinking about writing one myself. Database is defintely the way to go. I would also write a UI class so that you could browse the event log directly in the SYS Browser.
patrik
http://www.premisesystems.info/forums/4168/ShowPost.aspx
http://www.premisesystems.info/forums/1123/ShowPost.aspx
http://www.premisesystems.info/forums/6231/ShowPost.aspx
123
Senior Member
If you plan to develop a data-logging tool may I suggest you forego dumping the data into a traditional relational database and consider using RRDTool (RRD=Round Robin Database).
Described as "high performance data logging and graphing system for time series data" it is optimized for handling reams of data. RRD can do something natively that'd be a lot trickier with a table-oriented database. It is described here but in a nutshell:
RRD uses circular buffers. You can define a buffer that holds 60 elements where each one is a reading taken at a one second interval. After 60 seconds pass, the buffer begns to be overwritten with new data.
I hear you say, "Hold on there! That means I just lost visibility of the last 60 seconds!". True enough, but you rarely use a single buffer. You make one to hold Seconds, another for Minutes, yet another for Hours (and Days, Months, Years, Decades, etc). When the Seconds buffer is about to overwrite itself, it dumps its latest reading into the Minutes buffer ... when the Minutes buffer is about to overwrite itself it dumps its latest reading to the Hours buffer (i.e. a cascade effect). In this scenario, you have second-by-second visibility for the last minute, minute-by-minute visibility for the last hour, hour-by-hour visibility for the last day ... you get the idea.
RRD was designed to store gobs of data in a practical fashion. It was derived from Multi Router Traffic Grapher (MRTG), a utility designed to display traffic handled by a router (and that's a lot of data).
Described as "high performance data logging and graphing system for time series data" it is optimized for handling reams of data. RRD can do something natively that'd be a lot trickier with a table-oriented database. It is described here but in a nutshell:
RRD uses circular buffers. You can define a buffer that holds 60 elements where each one is a reading taken at a one second interval. After 60 seconds pass, the buffer begns to be overwritten with new data.
I hear you say, "Hold on there! That means I just lost visibility of the last 60 seconds!". True enough, but you rarely use a single buffer. You make one to hold Seconds, another for Minutes, yet another for Hours (and Days, Months, Years, Decades, etc). When the Seconds buffer is about to overwrite itself, it dumps its latest reading into the Minutes buffer ... when the Minutes buffer is about to overwrite itself it dumps its latest reading to the Hours buffer (i.e. a cascade effect). In this scenario, you have second-by-second visibility for the last minute, minute-by-minute visibility for the last hour, hour-by-hour visibility for the last day ... you get the idea.
RRD was designed to store gobs of data in a practical fashion. It was derived from Multi Router Traffic Grapher (MRTG), a utility designed to display traffic handled by a router (and that's a lot of data).
Similar threads
- Article