"Agent status cannot be determined" on agent screen

[bluegrass]

I am having a problem that recently showed up after a disaster recovery with a customer. The agent screens are now telling them they cannot determine their status despite being logged in and not paused. Google returns virtually nothing in the way of a solution

[QueueMetrics]

The error means that there is no agent data in the last X bytes of the queue_log file for that agent.

You should check that:
1. the realtime screen looks correct - calls appear and disappear with the right time and agents log in and log out
2. calls appear on the agent's page correctly
3. the realtime.max_bytes_agent=250000 for a start.

Are you using database or flat-file storage?

[bluegrass]

yes, i am using qloaderd to send the log into P01

[QueueMetrics]

Do agents see calls coming their way (or just passed) on the Agent's page?

If you use SQL storage, use realtime.max_bytes_agent=7200 as the term is seconds to look back...

[shm267]

We are having this issue too.

Some background, we have two asterisk boxes running TrixBox, both have qloaderd running and pushing the queuelog data to a third queuemetrics box. This appears to be working fine but there is a lot of data being pushed into the database. We have about ~20 queues with an average of 30 agents statically defined in each queue. We are also running Trixbox/Asterisk in device/user mode to allow our agents to move about between cisco phones. Right now they are using *11 and * 12 to login and logout, but we are moving toward using agent login in addition to allow agents to register their extension with *11, get DID and extension calls, without actually being in the queues. Then they can dial extension 299 to login/logout of the queues as an actual asterisk agent.

Right now we have the variable realtime.max_bytes_agent=30000. This seems to keep the calls on the agent GUI for about 30 seconds, then it disappears. Also the agent status goes to unknown.

After looking at the query behind the agent GUI, we are not sure if we may have asterisk configured in the most optimal way for queuemetrics. My major concern is the number of RINGNOANSWER rows in the database. Currently there are around 8.7 million rows in the queue_log table, of those, 8.5 are RINGNOANSWER records.

Right now, the GUI executed the following query based on the configuration above:

SELECT time_id , call_id , queue , agent , verb , data1 , data2 , data3 , data4
FROM queue_log  WHERE  partition ='P002' AND ( time_id >= ( UNIX_TIMESTAMP() - 30000)
AND time_id <=  UNIX_TIMESTAMP() ) ORDER BY time_id ASC , unique_row_count ASC

From our database, this returns around 155,300 rows (WOW).

**With a simple change to the query, the count can be reduced to 20 rows. (and agent like 'Agent/70017')

SELECT time_id , call_id , queue , agent , verb , data1 , data2 , data3 , data4
FROM queue_log  WHERE  partition ='P002' AND ( time_id >= ( UNIX_TIMESTAMP() - 30000)
AND time_id <=  UNIX_TIMESTAMP() ) and agent like 'Agent/70017' ORDER BY time_id ASC , unique_row_count ASC

[QueueMetrics]

Ok this does not explain why you should bot get LOGON/LOGOFF infiormation though. There should be plenty of information in the last 30,000 secs, so it makes no sense that the status appears for 30 seconds or so.

[shm267]

Ok, we have discovered what appears to be two related issues. 

1.  "max_bytes_agent" parameter is supposed to, while in database access mode, control the where clause for the time window to retrieve queue_log records from.  It does do that.  However, additionally, the temp file that is generated off this query (that is then java class filtered for agent portal display) is also byte restricted by the same parameter.  This is a problem since in order to process enough temp result file (in our case) you need to increase the parameter up to ~2,000,000. (2MB of temp file parsed).  However, this then also affects the database retreival in giving 23 days worth of activity even if you just are processing the first 2MB worth.  To fix this, the DB retreival window (in seconds) should be a separate parameter from the temporary results file parsing (in bytes).

2.  The database retreival query is not optimal.  It spools all records including ACD RINGNOANSWER rows, of which we have a large amount of, and are not revelant to this query.  Currently, we have had to modify the qloader to post RINGNOANSWER rows to another partition just so that we get something byte short enough to process (for problem #1 above).   Even if #1 above is fixed, the query time, java class temp file filtering is a tiny fraction of processing by making this query specific to the login.

Fix number #1 above would allows us to process 1 day (instead of 23 days) worth of records to assertain statuses and calls for the portal.  Fix #2 above allows the portal to process a few K worth of agent specific records instead of many many MB of records for a whole day of non-relevant records (once we cut the ACD record back to the proper partition).  In effect, if #1 is fixed and the parameters separated, without #2, we would need to put the DB windowing to 86400 secs (1 day) and the byte filtering to ~50MB once we cut the RINGNOANSWER back.

Thanks for your help!

[QueueMetrics]

This is correct. We are tracking the issues as #471 (your #1) and #472 (your #2).  Of course #1 is top priority - if you can contact our offices, we'll send you a beta to be manually installed as soon as it's ready.

[bonesyjr]

Can you also let me know when the beta is ready.  I am having the same issue as above.

[QueueMetrics]

Please contact us by e-mail to have a beta abvailable.

[bonesyjr]

Did anyone figure out what the issue was here?  I am having the same issue. Any help would be appreciated.

Thanks.

[QueueMetrics]

The issue has been fixed and version 1.5.0 will be free of it. We are about to release it.

[zpcanada]

I am using Queuemetrics version 1.5.5 and I am having the same problem. This problem seems occurred after update the pbx using update-scripts, update-fixes and update-source(PBX in a Flash commands) Please help.

[QueueMetrics]

Have you tried logging off and on agents manually?

[torontob]

Same problem. I am not using qloader or mysql but rather the simple queue_log file. I can even see this message on the documentation snapshot.