Colleagues, please tell me the answer to my question.
Is it possible, using the settings mechanisms, to change the format of the date and time field in queue_log, making it human-oriented?
There is a suspicion that this module was programmed either by robots or by aliens, and, moreover, exclusively for themselves.
I would like to be able to set a format like "YYYYMMDD HHMMSS|".
Thanks in advance for your reply,
Ogogon.
Instructions for using your key may be found at:
The binary codec may be found at:
The register utility may be found at:
Piense en el medio ambiente, imprima este correo sólo si es necesario
How can installing this codec help me change the date and time format in the queue log file?
pufff… I got confused from ticket to sending the answer … sorry
Piense en el medio ambiente, imprima este correo sólo si es necesario
From what I’ve seen, no. A unix timestamp, however, is not the worst format you could get. 
Your best option as is, would be to either create your own log, or log to a database, as most database systems has an option for converting timestamps when you perform a query.
If you don’t need the log in realtime, you can also make a log processor, that adds the time in whatever format you like, to the log.
So my guess about aliens turned out to be correct - they always do that!
I started dumping this log into MySQL and it became much easier to work with it.
Although, as far as I understand, disk space is consumed much more. For each data field, 64 bytes are reserved in the database table. There are six of them and they are occupied by 5-6 bytes. I wonder if MySQL still reserves 64 bytes or does it know how to reduce table fields to real ones?
And another interesting observation - one data field is basically not used. This is the data field.
I created the queue_log table with this SQL spell:
CREATE TABLE IF NOT EXISTS
queue_log(
timevarchar(32) DEFAULT NULL,
callidchar(64) DEFAULT NULL,
queuenamechar(64) DEFAULT NULL,
agentchar(64) DEFAULT NULL,
eventchar(32) DEFAULT NULL,
datachar(64) DEFAULT NULL,
data1char(64) DEFAULT NULL,
data2char(64) DEFAULT NULL,
data3char(64) DEFAULT NULL,
data4char(64) DEFAULT NULL,
data5char(64) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
In the few days that this works for me, in all the data fields I have only one value - NULL?
Is this how it should be, or am I not completely configured something?
Does asterisk write to the queue log on it’s own, or do you have something that processes the log, and adds it to the database?
I have several Asterisk instances, all writing to the same database, no problem. However, not all data fields are used with every event. Some events have no data at all, some has 3-4 values.
For storage, my understanding of MySQL is, that char() fields allocate a fixed amount of storage on disk, while varchar() reserves only what is needed, they are otherwise functionally identical. But best to check with a MySQL specialist if you really need to preserve storage, to be sure. However, you can change from char() to varchar() without a problem. (But probably no storage gain either)
My table is setup like this:
CREATE TABLE `asteriskQueue_log` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`time` char(26) DEFAULT NULL,
`callid` varchar(255) NOT NULL DEFAULT '',
`queuename` varchar(255) NOT NULL DEFAULT '',
`agent` varchar(255) NOT NULL DEFAULT '',
`event` varchar(255) NOT NULL DEFAULT '',
`data1` varchar(255) NOT NULL DEFAULT '',
`data2` varchar(255) NOT NULL DEFAULT '',
`data3` varchar(255) NOT NULL DEFAULT '',
`data4` varchar(255) NOT NULL DEFAULT '',
`data5` varchar(255) NOT NULL DEFAULT '',
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=0 DEFAULT CHARSET=latin1;
As for res_odbc.conf it contains the following
[CDR]
enabled = yes
dsn => CDR
username => <user>
password => <pass>
pre-connect => yes
And in extconfig.conf I have this:
queue_log => odbc,CDR,asteriskQueue_log
As far as I can find, and remember, I didn’t change anything else.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.