Upload old stats from queueloq

[transltr]

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

[QueueMetrics]

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

[chaag]

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

[QueueMetrics]

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.

[chaag]

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!

[QueueMetrics]

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.

[chaag]

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

[QueueMetrics]

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.