Messages

16

QueueMetrics installation / Re: QueueMetrics and CallWeaver

« on: July 24, 2007, 04:33:11 »

Much appreciated.  I'm going to be converting my home server to CallWeaver first, so I'll do some testing there and let you know.

17

QueueMetrics installation / QueueMetrics and CallWeaver

« on: July 08, 2007, 03:50:09 »

Just a quick question - has anyone attempted to install/use QueueMetrics with a CallWeaver (aka OpenPBX) install?

I'm toying with the idea of migrating to CallWeaver for a number of reasons - the biggest being the T.38 capabilities of CallWeaver and wanted to know if anyone has already taken this upgrade path.

Given that CallWeaver is a fork of Asterisk 1.2, I'm guessing that it should be OK.  I'll understand if it's not an officially supported configuration, but I'd still like to know what success others may (or may not) have had.

18

MySQL storage and Qloaderd/Uniloader / Re: Problem after converting to Qloaderd 1.7/QueueMetrics 1.4

« on: July 07, 2007, 03:31:30 »

1. You're able to see correct data in realtime monitoring.
2. The mysql information is showing you have data from October of 2006, to current.
3. Records are actively being inserted into the queue_log table.

All correct.  I'll make the additional note that "live" monitoring is working very nicely.

Are all of the quick activity reports working, or only for today?

None of the quick activity reports are working.

I'm a little puzzled as to why the latest time is being shown between 7am and 8am, given that it's now just after 2pm.  It looks like a clue, but what it means, I don't know.  Other than the funny looking end times, the dates seem about right.

Hmm... are the timezones set the same on you Asterisk and Queuemetrics servers? Do you have liveclock.enable=true in your configuration.properties. This setting is supposed to make sure the system clock is synchronized with asterisk server system clock.

Yes and yes.  The second server was originally built by cloning the first server.

The thing that stumps me is that you are seeing realtime activity and historic activity (at least for the day) using the quick activity reports, but nothing is showing for you in the custom reporting. The MySQL information you provided shows that data exists from last October and March of this year.

Sorry, I may have led you astray here - I was seeing historic data, but am not any longer.

When you run a custom report are you selecting:
1. "all queues" (or its equivalent)
2. ' ' in Agent
3. '-' in Location
4. a really broad date range for your start and end date
5. file (i.e. SQL:PBX1 or cluster:*) (you're already familiar with this one)
6. no timezone offset
7. join multistint calls (this is up to your Asterisk implementation)

Bingo.  I had a timezone offset of +10 hours set. (=Australian Eastern Standard Time)  When I return this to "no offset" everything starts working again.  (I had default.timeZoneOffset set to 10)

Thanks greatly for your help!

19

MySQL storage and Qloaderd/Uniloader / Re: Problem after converting to Qloaderd 1.7/QueueMetrics 1.4

« on: July 05, 2007, 06:28:55 »

Before you upgraded, was QueueMetrics reading from the Asterisk-produced queue_log file or from the MySQL queue_log table?

Previously we were referring directly to the Asterisk generated queue_log since the last time I had the software working, we hadn't yet built the backup server.

What version of qloader are you using, the older version (in WEB-INF/mysql-utils) or the new one (in WEB-INF/mysql-utils/qloader)? From your post, it sounds like you're using the new one, but I just want to make sure.

Qloader was installed via yum and is version 1.7.

Regarding the call data you were seeing yesterday, was this call data produced by the new installation of the QueueMetrics 1.4 install with the clusters and qloader, or from your previous older installation? Was this 'call data' shown in realtime monitoring, custom report analysis, or both?

The data seen was after the QueueMetrics 1.4 and Qloader install.  Obviously I've managed to mangle something in the mean time.  The call data was seen through the quick activity reports (which I think is just a link to the custom report analysis).

I'm looking at realtime monitoring now, and it is correctly showing the operators logged on as well as both calls in the queue and those that have been answered.

1. that the qloader you have running for each Asterisk server is configured to send data using the correct parition and that it continues to send data to you QueueMetrics queue_log MySQL table. In your case, you have one running for PBX1 and one for PBX2.

Verified.  I'm running a select count(*) from queue_log; and can see records being inserted into the database.

2. the 'MySQL Storage Information' page (accessible from the main “Edit settings” menu if the user holds the key USR_MYSQL) that provides general database information. It should show the current storage information. Check to see if it matches the days of data, partitions, and other information you are expecting.

Data shown on this page is as follows:-

Code: [Select]

Current storage info
Total number of rows in table: 64.444
Total table space: 18,8 M ( Data: 16,5 M - Indexes: 2,3 M )

Partition Entries N. calls From: To: Days of data: Last heartbeat:
PBX1 46.497 13.525   2006-10-18 10:02   2007-07-05 07:02 260,0 days   2007-07-05 07:02
PBX2 17.947 5.098   2007-03-03 03:31   2007-07-05 07:17 123,8 days   2007-07-05 07:17

I'm a little puzzled as to why the latest time is being shown between 7am and 8am, given that it's now just after 2pm.  It looks like a clue, but what it means, I don't know.  Other than the funny looking end times, the dates seem about right.

3. in the 'file' field of the 'Custom Report Analysis' you can adjust the file/ MySQL-table-partition you want to see information from. Make sure this is reflecting the correct settings for reading from your cluster/SQL. For example, 'cluster:*' and 'cluster:PBX1|PBX2' should produce the same results in your scenario for your clustered servers. For testing, you could also see if the settings 'sql:PBX1' or 'sql:PBX2' produces any different results (this should just do a report of data in MySQL existing on partition PBX1 or PBX2 respectively).

I've tried multiple variations around this theme without success.  I'm still not seeing any data.

4. that you have a 'sqlPreset' defined in your configuration.properties file

The sqlPreset Section is as follows:- (this is the default in the qloader rpm package)

Code: [Select]

# Preset 1: standard DB access. Edit to suit your DB needs.
sqlPreset.1.table=queue_log
sqlPreset.1.f_time_id=time_id
sqlPreset.1.f_call_id=call_id
sqlPreset.1.f_queue=queue
sqlPreset.1.f_agent=agent
sqlPreset.1.f_verb=verb
sqlPreset.1.f_partition=partition
sqlPreset.1.f_data1=data1
sqlPreset.1.f_data2=data2
sqlPreset.1.f_data3=data3
sqlPreset.1.f_data4=data4
sqlPreset.1.f_incr=unique_row_count

sqlPreset.2.table=queue_log
sqlPreset.2.f_time_id=time_id
sqlPreset.2.f_call_id=call_id
sqlPreset.2.f_queue=queue
sqlPreset.2.f_agent=agent
sqlPreset.2.f_verb=verb
sqlPreset.2.f_partition=
sqlPreset.2.f_data1=data1
sqlPreset.2.f_data2=data2
sqlPreset.2.f_data3=data3
sqlPreset.2.f_data4=data4
sqlPreset.2.f_incr=unique_row_count


The table structure is as follows:-

Code: [Select]

mysql> show columns from queue_log;
+------------------+------------------+------+-----+---------+----------------+
| Field            | Type             | Null | Key | Default | Extra          |
+------------------+------------------+------+-----+---------+----------------+
| partition        | char(20)         | NO   | MUL | NULL    |                |
| time_id          | int(11) unsigned | NO   |     | 0       |                |
| call_id          | char(30)         | NO   |     | NULL    |                |
| queue            | char(30)         | NO   |     | NULL    |                |
| agent            | char(30)         | NO   |     | NULL    |                |
| verb             | char(30)         | NO   |     | NULL    |                |
| data1            | char(30)         | NO   |     | NULL    |                |
| data2            | char(30)         | NO   |     | NULL    |                |
| data3            | char(30)         | NO   |     | NULL    |                |
| data4            | char(30)         | NO   |     | NULL    |                |
| unique_row_count | int(11)          | NO   | PRI | NULL    | auto_increment |
+------------------+------------------+------+-----+---------+----------------+
11 rows in set (0.00 sec)


20

MySQL storage and Qloaderd/Uniloader / Problem after converting to Qloaderd 1.7/QueueMetrics 1.4

« on: July 01, 2007, 15:33:28 »

I've just converted our trial install of QueueMetrics to using Qloaderd and upgraded to version 1.4 of QueueMetrics at the same time and started logging data from both our Asterisk servers to the same database using different partitions (PBX1 and PBX2)

Data is getting logged to the database - the current database storage is showing heartbeats and the data range is what I would expect it to be.  The install was successful and I was seeing call data yesterday.

However today, it doesn't matter how far back I go (yesterday, last week or last year) I'm getting no data at all.  Needless to say, this is a little frustrating...

I've configured the cluster as follows:-

Code: [Select]

default.queue_log_file=cluster:*

[...]

cluster.servers=pbx1|pbx2

cluster.pbx1.manager=tcp:xxx:xxxs@pbxbelgrave1
cluster.pbx1.queuelog=sql:PBX1
#cluster.pbx1.monitored_calls=z:/qm_streamcall/server_aleph
cluster.pbx1.callfilesdir=
cluster.pbx1.audioRpcServer=
cluster.pbx1.agentSecurityKey=

cluster.pbx2.manager=tcp:xxx:xxx@pbxbelgrave2
cluster.pbx2.queuelog=sql:PBX2
#cluster.pbx2.monitored_calls=z:/qm_streamcall/server_trix
cluster.pbx2.callfilesdir=
cluster.pbx2.audioRpcServer=
cluster.pbx2.agentSecurityKey=

Could anyone give me a hint as to what might be going wrong?