QueueMetrics forum
QueueMetrics => MySQL storage and Qloaderd/Uniloader => Topic started by: transltr on May 22, 2007, 08:10:35
-
Hi
We are using QM 1.3.5 and the latest qloader 1.7.
Recently had an issue with qm and was down for a week, it is now back up and running, what is the best way to update the db ?
According to the manual - perl queueLoader.pl /my/queue_log P00
The queue_log has rotated already and is queue_log.2, but only a part of needs to be uploaded, do i just cutout the parts that I don't need and upload manually the missing parts ?
Cheers
-
Hello,
qloaderd is built so that it will not upload if newer data exists. If you still have the log files, you could do the following:
1. delete all data in your database that is newer than your crash
2. reload manually all log files, starting from the oldest to the newest. If a log file is partially loaded, qloaderd should be smart enough not to load the existing older part.
Do make a backup before doing this :)
-
When you say "delete all data" which tables are you referring too? (running 1.3.5). Just want to confirm before I delete.
Also, should restarting asterisk cause data loss in QM?
thanks,
Chris
-
You should remove data only from the table queue_log, and only after making a backup and having stopped qloaderd!
As Qm and asterisk are completely decoupled by design, there should be no problems at all or data lost: asterisk will simply go on writing to the queue_log file.
-
OK,
One sanity check... table queue_log is already empty. However, I do have data in the actual (web) reports. (weird no?)
Something odd may be going on here, This a one week old QM installation ( we had a server hardware problem and moved asterisk and QM to a new server last week).
When I went home Friday night I had a weeks worth of data in the QM reports. This morning, I only have data since Saturday (~2.5 days worth). To my knowledge, nothing was done on the server except an automated Asterisk restart (/etc/init.d/asterisk restart) early Saturday morning. I have restarted Asterisk in the past w/o losing data, so by my own experience I know they are decoupled. Now, I am at a loss as to what happened to the previous weeks data.
$ last shows no activity on the server, so I don't think we have a saboteur, (unless he had a root kit ;-))
Any suggestions?
thanks!
-
If your table is empty but you see data, QueueMetrics is pulling data from the local queue_log file :) - edit the configuration to pull data from the correct partition.
-
OK, I think I have this figured out. IF you are not using the MySQL storage, QM can only report on the data it sees in queue_log. If you are rolling your queue_log, you'll truncate the data available to QM. It may make sense to point this out in the docs (for morons like me ;-))
As I understand the docs, I do not think my call center is high volume enough to warrant using MySQL storage. However, does that mean I can never roll queue_log? Is it possible to have QM read the current and the last queue_log? Here is what my /var/log/asterisk looks like:
/var/log/asterisk$ ls -ltrh | grep queue
-rw-r--r-- 1 root root 330K Jun 15 18:02 queue_log.0
-rw-r--r-- 1 root root 45K Jun 19 09:07 queue_log
chaag@asterisk4:/var/log/asterisk$
thanks,
Chris
-
Hi Chris,
having two queue_log files is not currently possible. I'd go for MySQL, it's pretty easy to set up and works just fine.