topic Dragon EMS "dragon.db" files taking up space in Security

Dragon EMS "dragon.db" files taking up space

dtitzer — Tue, 05 Nov 2013 02:41:00 GMT

A Dragon EMS server accumulates "dragon.db" files under the DB directory. What is the recommended practice for dealing with all these files? Is it worthwhile to archive them?

RE: Dragon EMS "dragon.db" files taking up space

Mullins__Keith — Tue, 05 Nov 2013 19:17:00 GMT

Hi, Thank you for posting. The dragon.db files contain the raw data of the events that occurred on that specific day. These files can also be used to repopulate the mysql database with event data. Within Dragon, there is a utility that can be used to archive or delete these files based on event age. Within Dragon v7.x, this utility is accessed through the Tools menu and is called 'Set Default Log Policy'. This will pop up a window that allows a user to define a specific event retention rate (in days), and whether to compress or delete these dragon.db files when this age is reached for that dragon.db file. For example, you can confirm this utility to compress all dragon.db files that are older than 30 days, or delete all dragon.db files older than 360 days, etc. This tool also exists in Dragon v8.x, under the 'Options --> Log/Data Policy' view in the web interface. This utility can also be used to manage the debug logs in the /opt/dragon/logs directory. This log archive/delete utility is documented in each versions Dragon Configuration Guide for your convenience as well. Is this the information you were looking for?

RE: Dragon EMS "dragon.db" files taking up space

dtitzer — Tue, 05 Nov 2013 21:25:00 GMT

Yes, this is what I was looking for. Unfortunately, it didn't appear to be working. My EMS server was set up to compress the data and maintain 4 rolled-over logs, but no compression was taking place. The DragonDB.log doesn't show any failures. What I really wanted to to was preserve a few logs, compress the rest, and delete them after a while. The policy doesn't appear to support a three-tier lifecycle. May need to script the clean-out myself.

RE: Dragon EMS "dragon.db" files taking up space

Mullins__Keith — Tue, 05 Nov 2013 22:02:00 GMT

Hello, You are correct, the current utility does not have a 3-tier feature in the manner you are looking for. However, I will submit this feature to our product management group for consideration into a future revision of Dragon. A workaround, as you have mentioned, would be to create a script that could manipulate the logs in different 'tiers and have that script be called by the cron daemon.

RE: Dragon EMS "dragon.db" files taking up space

dtitzer — Wed, 06 Nov 2013 04:19:00 GMT

I can handle the script work. I do, though, want to keep this going to see if it's working to compress files. It will take a few days before it is supposed to start. I lowered the number of roll-overs to two.

RE: Dragon EMS "dragon.db" files taking up space

Tamera_Rousseau — Wed, 06 Nov 2013 20:13:00 GMT

We will certainly keep this topic open for discussion David. Please feel free to update the community with what you discover. Thanks for the great question!

RE: Dragon EMS "dragon.db" files taking up space

dtitzer — Thu, 07 Nov 2013 03:26:00 GMT

Your old Knowledge Base article 13305 seems very relevant. Assuming I opt for deletion after 30 days, the daily directories will be deleted when they fall outside the 30-day sliding window. It doesn't sound like it matters whether the dragon.db file(s) inside are compressed or not. Take a look and tell me what you think. If I want to conserve space, I can compress the dragon.db files with a script, and let the Log Policy delete the aged-off directories and their contents.

RE: Dragon EMS "dragon.db" files taking up space

Mullins__Keith — Thu, 07 Nov 2013 03:59:00 GMT

That is correct. The Log Policy can be configured to delete the files after 30-days (using your example), but the only items that will be deleted are the /opt/dragon/DB//dragon.db (or the dragon.log.xxx files if you configure those files to be deleted). Any files that are compressed would not be deleted in this manner by this utility. Using your example, you would have 2 copies of data for each day: one for the default location, and another of the days worth of events compressed by your script. This could compound your diskspace issue, especially if you have a day where a lare amount of events are generated. One thing you may want to consider is to have the Log Policy utility compress these database files if they are older than 30-days rather than delete. Than you can create your script to periodically check diskspace, and delete (or move to a different location/machine) these compressed files according to their age, size, age, etc.

RE: Dragon EMS "dragon.db" files taking up space

Mullins__Keith — Thu, 07 Nov 2013 16:52:00 GMT

Hi Dennis, In the upcoming Dragon v8.2 release, the Log Policy utility has been modified to perform a two-tier approach. This may be more inline in what you are looking for. The dragon.db files are compressed after one day automatically (this part cannot be changed by user configuration). The compressed files stay on the system until they are deleted after the user-defined retention period. Dragon v8.2 is scheduled to be released ~11/15.