Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - wilsonchua

Pages: [1] 2
1
QueueMetrics installation / Help with Upgrade
« on: September 08, 2014, 07:47:49 »
Hi Guys, I have a 12.5.1 version that i upgraded to 14.06.2-822 today.
I used the instructions using YUM update command found in :http://astrecipes.net/index.php?from=226&q=astrecipes/updating+queuemetrics+using+yum

The install process went well. There is now a folder queuemetric-14.06.02-822
I have transferred web.xml and config.properties to the /WEB-INF folders
I have restarted /etc/init.d/queuemetrics restart

The issue here is that when i logged into http://localhost:8080/queuemetrics
I still see the 12.5.1 version and NOT the new 14.06.2-822 version.

What did i miss out on doing?

2
so it might be because my centos version is 4.6 final. (which is old)
so i replaced the baseurl with vault.centos.org instead of mirro.centos.org

and then i did this:

yum clean metadata
yum clean dbcache
yum makecache

to which i get these errors:

Making cache files for all metadata files.
This may take a while depending on the speed of this computer
Setting up repositories
trixbox                   100% |=========================|  951 B    00:00
update                    100% |=========================|  951 B    00:00
http://rh-mirror.linux.iastate.edu/pub/dag/redhat/el3/en/i386/dag/repodata/repomd.xml: [Errno 4] IOError: <urlopen error (113, 'No route to host')>
Trying other mirror.
rpmforge                  100% |=========================| 1.9 kB    00:00
base                      100% |=========================| 1.1 kB    00:00
trixboxaddons             100% |=========================|  951 B    00:00
addons                    100% |=========================|  951 B    00:00
LowayResearch             100% |=========================|  951 B    00:00
extras                    100% |=========================| 1.1 kB    00:00
http://yum.trixbox.org/centos/4/RPMS/repodata/primary.xml.gz: [Errno 12] Timeout: <urlopen error timed out>
Trying other mirror.
Error: failure: repodata/primary.xml.gz from trixbox: [Errno 256] No more mirrors to try.


on the server, i can ping both urls without any issues.

3
I have already worked on /etc/resolv.conf
I have already uncommented /etc/yum.repos.d/ baseurl

yum update still fails..

Setting up Update Process
Setting up repositories
not using ftp, http, or file for repos, skipping - 4 is not a valid release or hasnt been released yet
http://mirror.centos.org/centos/4/updates/i386/repodata/repomd.xml: [Errno 14] HTTP Error 404: Not Found
Trying other mirror.
Cannot open/read repomd.xml file for repository: update
failure: repodata/repomd.xml from update: [Errno 256] No more mirrors to try.
Error: failure: repodata/repomd.xml from update: [Errno 256] No more mirrors to try.

4
Hi All,

I tried to upgrade my queuemetric v 1.5.4 to the latest v 12.05 using the yum method. but this is what i get:


[root@asterisk1 webapps]# yum update queuemetrics
Setting up Update Process
Setting up repositories
not using ftp, http, or file for repos, skipping - 4 is not a valid release or hasnt been released yet
Cannot find a valid baseurl for repo: update
Error: Cannot find a valid baseurl for repo: update


Any one encountered this before?

5
argh!!! there are 1000s of these files.
It means we have to run it 1000s of times as well?

Surely, there must be an easier way?

6
Hi Lenz,

Thanks for the response to this issue. We first merged all the queue_log.xxx into one big file.
Then ran the queuepartialupdater
But since it only inserts data that is NEWER, the old data in the merged file was not inserted into it.

Is there any way to reinsert the old data back into the database?

7
When I ran the queuePartialUpdater tool (found in /usr/local/qloader) against the file, it did not restore items that were greater than the current timestamp (aug 2, 2011), the missing data were for July 23 and July 24th, 2011...

Is there a workaround for this?

8
Hi Marco,

thanks for looking into this. The past 2 days of activities were not in the mysql. The most recent calls are being added correctly into the mysql database.

I see a lot of queue_log.xxxx in the /var/log/asterisk directory, a partial list looks like this:
rw-rw-r--   1 asterisk asterisk        40 Jul 23 08:38 queue_log.9964
-rw-rw-r--   1 asterisk asterisk        40 Jul 23 08:38 queue_log.9965
-rw-rw-r--   1 asterisk asterisk        40 Jul 23 08:43 queue_log.9966
-rw-rw-r--   1 asterisk asterisk        40 Jul 23 08:43 queue_log.9967
-rw-rw-r--   1 asterisk asterisk        40 Jul 23 08:44 queue_log.9968
-rw-rw-r--   1 asterisk asterisk        40 Jul 23 08:44 queue_log.9969
-rw-rw-r--   1 asterisk asterisk        40 Jul 22 12:14 queue_log.997
-rw-rw-r--   1 asterisk asterisk        40 Jul 23 08:45 queue_log.9970
-rw-rw-r--   1 asterisk asterisk        40 Jul 23 08:45 queue_log.9971
-rw-rw-r--   1 asterisk asterisk        40 Jul 23 08:45 queue_log.9972
-rw-rw-r--   1 asterisk asterisk        40 Jul 23 08:45 queue_log.9973
-rw-rw-r--   1 asterisk asterisk        40 Jul 23 08:45 queue_log.9974
-rw-rw-r--   1 asterisk asterisk        40 Jul 23 08:45 queue_log.9975
-rw-rw-r--   1 asterisk asterisk        99 Jul 23 08:47 queue_log.9976
-rw-rw-r--   1 asterisk asterisk       113 Jul 23 08:47 queue_log.9977
-rw-rw-r--   1 asterisk asterisk        40 Jul 23 08:50 queue_log.9978
-rw-rw-r--   1 asterisk asterisk        40 Jul 23 08:50 queue_log.9979
-rw-rw-r--   1 asterisk asterisk        40 Jul 22 12:14 queue_log.998
-rw-rw-r--   1 asterisk asterisk        40 Jul 23 08:51 queue_log.9980
-rw-rw-r--   1 asterisk asterisk        40 Jul 23 08:51 queue_log.9981
-rw-rw-r--   1 asterisk asterisk        40 Jul 23 08:51 queue_log.9982
-rw-rw-r--   1 asterisk asterisk       126 Jul 23 08:52 queue_log.9983
-rw-rw-r--   1 asterisk asterisk        40 Jul 23 08:52 queue_log.9984
-rw-rw-r--   1 asterisk asterisk        40 Jul 23 08:52 queue_log.9985
-rw-rw-r--   1 asterisk asterisk        40 Jul 23 08:52 queue_log.9986
-rw-rw-r--   1 asterisk asterisk        40 Jul 23 08:52 queue_log.9987
-rw-rw-r--   1 asterisk asterisk        40 Jul 23 08:52 queue_log.9988
-rw-rw-r--   1 asterisk asterisk        40 Jul 23 08:53 queue_log.9989
-rw-rw-r--   1 asterisk asterisk        40 Jul 22 12:14 queue_log.999
-rw-rw-r--   1 asterisk asterisk        40 Jul 23 08:53 queue_log.9990
-rw-rw-r--   1 asterisk asterisk        40 Jul 23 08:54 queue_log.9991
-rw-rw-r--   1 asterisk asterisk        40 Jul 23 08:54 queue_log.9992
-rw-rw-r--   1 asterisk asterisk        40 Jul 23 08:54 queue_log.9993
-rw-rw-r--   1 asterisk asterisk       155 Jul 23 08:55 queue_log.9994
-rw-rw-r--   1 asterisk asterisk        93 Jul 23 08:55 queue_log.9995
-rw-rw-r--   1 asterisk asterisk        40 Jul 23 08:55 queue_log.9996
-rw-rw-r--   1 asterisk asterisk       155 Jul 23 08:56 queue_log.9997
-rw-rw-r--   1 asterisk asterisk       114 Jul 23 08:56 queue_log.9998
-rw-rw-r--   1 asterisk asterisk        40 Jul 23 08:57 queue_log.9999


Can  I just merge all the queue_log.xxx into the queue_log and restart qloaderd ?

If the above were possible, im planning to do this:

find . -name 'queue_log.*' | xargs cat >> queue_log

Will this approach work?

9
It did! Apparently, the Master.csv was never rotated, so its file size just kept on increasing.
AFter a while, it hit the 2gb limit and that triggered the SIGXFSZ (exceeded files limit), in turn , this triggered the log files to rotate.
This results in a LOT of event_log.* and Full.x.* files being made of zero size file.

I restarted qloader with /etc/init.d/qloader restart

I can now see data in the 'today' , real time monitoring.

I need your advise if i am to do anything about the past 2 days where no data is still showing in the queuemetrics.
Should i just wait for the qloader to process everything>? Or should i manually run some script?

10
I read this:
http://www.mail-archive.com/asterisk-users@lists.digium.com/msg188549.html

Basically, the logrotate is also triggered when a large file exceed 2gb in size. This causes the the SIGXFSZ to be triggered, which in turn triggers the log rotation...

So i used this command to look for large files :
find / -type f -size +50000k -exec ls -lh {} \;| awk '{print $9": " $5}'

And found this:
/var/log/asterisk/cdr-csv/Master.csv: 2.0G

I will back this file up to Master.csv.bak and then rm the Master.csv and see if this resolves the situation.

11
further INfo:
I went into my /var/log/asterisk and saw a lot of empty sized event_log.xxxxx
Could these be related?

What could be causing it? And how is it affecting queuemetrics?

12
I got this error message on my asterisk :
" Asterisk queue logger restarted".
"Rotated Logs Per SIGXFSZ (exceeded files limit)"

Then from that time on, I couldnt get any stats on the queuemetrics.
Has anyone come across this yet? Any ideas on how to resolve this?


13
Hi Guys,

Thanks to help from Lorenzo,  the issue is resolved. Apparently, the web.xml file also had a pointer to the old flatfile.
By changing the pointers in that file, it is now working!

Thanks Lorenzo!!

14
if i point the file back to /var/log/asteriks/queue_log
I can see all the data.

If i do a mysql command:
SELECT `partition`, from_unixtime(`time_id`), from_unixtime(`call_id`), `queue`, `agent` FROM `queue_log` order by time_id desc

I can see new records inserted:
partition    from_unixtime( `time_id` )    from_unixtime( `call_id` )    queue    agent
P001   2011-04-20 17:03:20   1970-01-01 08:00:00   NONE   NONE
P001   2011-04-20 16:44:29   1970-01-01 08:00:00   NONE   NONE
P001   2011-04-20 13:45:48   2011-04-20 13:28:22   7202   NONE
P001   2011-04-20 13:28:55   2011-04-20 13:28:22   7202   NONE
P001   2011-04-20 13:28:43   2011-04-20 13:28:22   7202   NONE
P001   2011-04-20 13:12:00   2011-04-20 13:08:04   7202   NONE
P001   2011-04-20 13:08:46   2011-04-20 13:08:04   7202   NONE
P001   2011-04-20 13:08:35   2011-04-20 13:08:04   7202   NONE


So why is it now showing up on the queuemetrics page?




15
Hi Guys,

I was able to migrate our queuemetrics installation from flatfile to using mysql over on a separate server. I followed the instructions on : http://queuemetrics.com/download/QM_mysql_cluster_100.pdf .

So our partition is P001.

I can see qloader.log and queue_log in the /var/log/asterisk are working.
I can see in mysql that new data are being inserted, including the heartbeat records.

However, in http://localhost:8080/queuemetrics, when i set the [File] parameter to : sql:P001
I dont see any records for the current day up to the 7 days old. I can see data from 7days old and older.

Also, since i migrated, i noticed that the "Start Real Time Monitoring" does not show any data at all.

Anyone ever experienced this before? I appreciate any tips or directions to take.

Pages: [1] 2