QueueMetrics > General Asterisk configuration

"Agent status cannot be determined" on agent screen

(1/4) > >>

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

Navigation

[0] Message Index

[#] Next page