Can anybody tell me how long KNM stores alarm/log data for, and where I can find the settings to adjust this if necessary?
We are keen to confirm how far back the reporting can cover, and how to perform maintenance when needed if too much drive space gets used up by the sql database.
- Sorry, this might be in the user guide but I have gone through it a couple of times and don't seem to be able to find it.
I had written a long answer but this forum thingy ate it ...
Long store short:
\statistics <--- report data, stored in our own system, files are cut of when they reach 10 MB you can throw it away if you do not needed, last stored data == name of file
\logs <--- text logs, same system as above.
> sql database
Statistics is time series data and it has no place in a relational database , therefore we have our own system for this that is purpose built for the task, resulting in a faster more disk efficient system.
Thanks for this, so there is no set ‘duration’ that data is kept for? – It would be useful to know if we are likely to have a month’s worth of logs or a year’s, as it affects how much reporting we should be able to offer (for example on bandwidth utilisation, or disk usage trending)
Thanks again! :-)
>Thanks for this, so there is no set ‘duration’ that data is kept for?
No, but we are considering this for v5
>>Thanks for this, so there is no set ‘duration’ that data is kept for?
> No, but we are considering this for v5
The 10MB is the total space for all objects & monitors? Can you give an estimate (or an exact value!) of how big each sample is in this file? I'm trying to get a feel of the max duration that's kept for a given number of objects & monitors..
Also, when the 10MB limit is reached, does the data wrap so that you always have the last 10MB of data or does the file get truncated back to 0B?
First, KNM v4 do never delete or overwrite your data.
It rotate the file at 10 MB and name the old file with the the date and time it was rotated (see pic from our test machine), so it does not truncate or overwrite anything. So this means that depending on the amound of monitors, KNM will now and then begin on a new "current.nxr" file and the old one will be renamed with a date and time.
The rotated files are used in reports if time period of the query includes them.
Each "file" is infact a pair of files , one .nxi which is the database index and one .nxr which contains the data. The index file (.nxi) can be rebuilt if missing.
The amount of consumed disk space is very dependent on what type of monitors you have, best way to see how it uses the space, is actually to create a directory property monitor in KNM that watches the \statistics directory.
V5 the disk usage will be a bit more deterministic.