cdr reports Не Отображает звонки

[ch.a.sh]

Не отображаются запись звонков в разделе Reports - CDR reports (freepbx ), пусто, сами звонки астериск записывает, хранятся тут /var/spool/asterisk/monitor/ ,

Установлена версия FreePBX 15.0.16.27

Код: Выделить всё

cdr_odbc.so                    ODBC CDR Backend                         0          Running          extended

Код: Выделить всё

cdr show status

Call Detail Record (CDR) settings
----------------------------------
  Logging:                    Enabled
  Mode:                       Simple
  Log unanswered calls:       No
  Log congestion:             No

* Registered Backends
  -------------------
    cdr_manager (suspended)
    csv
    Adaptive ODBC

в файле /etc/asterisk/res_odbc_additional.conf поменял ;dsn=>MySQL-asteriskcdrdb
dsn=>asterisk-cdr
но не помогло

Код: Выделить всё

[2019-11-26 17:44:34] VERBOSE[23946] loader.c: Reloading module 'cdr_adaptive_odbc.so' (Adaptive ODBC CDR backend)
[2019-11-26 17:44:34] WARNING[23946] cdr_adaptive_odbc.c: No such connection 'asteriskcdrdb' in the 'asteriskcdrdb' section of cdr_adaptive_odbc.conf.  Check res_odbc.conf.
[2019-11-26 17:44:34] VERBOSE[23946] loader.c: Reloading module 'cdr_csv.so' (Comma Separated Values CDR Backend)
[2019-11-26 17:44:34] VERBOSE[23946] loader.c: Reloading module 'cdr_manager.so' (Asterisk Manager Interface CDR Backend)
[2019-11-26 17:44:34] VERBOSE[23946] loader.c: Reloading module 'cdr_odbc.so' (ODBC CDR Backend)
[2019-11-26 17:44:34] WARNING[23946] cel_odbc.c: No such connection 'asteriskcdrdb' in the 'cel' section of cel_odbc.conf.  Check res_odbc.conf.
[2019-11-26 17:45:08] NOTICE[23946] res_odbc.c: Registered ODBC class 'asteriskcdrdb' dsn->[asterisk-cdr]
[2019-11-26 17:45:08] VERBOSE[23946] loader.c: Reloading module 'cdr' (CDR Engine)
[2019-11-26 17:45:08] NOTICE[23946] cdr.c: CDR simple logging enabled.
[2019-11-26 17:45:08] VERBOSE[23946] loader.c: Reloading module 'cdr_adaptive_odbc.so' (Adaptive ODBC CDR backend)
[2019-11-26 17:45:08] WARNING[23946] cdr_adaptive_odbc.c: No such connection 'asteriskcdrdb' in the 'asteriskcdrdb' section of cdr_adaptive_odbc.conf.  Check res_odbc.conf.
[2019-11-26 17:45:08] VERBOSE[23946] loader.c: Reloading module 'cdr_csv.so' (Comma Separated Values CDR Backend)
[2019-11-26 17:45:08] VERBOSE[23946] loader.c: Reloading module 'cdr_manager.so' (Asterisk Manager Interface CDR Backend)
[2019-11-26 17:45:08] VERBOSE[23946] loader.c: Reloading module 'cdr_odbc.so' (ODBC CDR Backend)
[2019-11-26 17:45:08] WARNING[23946] cel_odbc.c: No such connection 'asteriskcdrdb' in the 'cel' section of cel_odbc.conf.  Check res_odbc.conf.

[zzuz]

No such connection 'asteriskcdrdb' in the 'asteriskcdrdb' section of cdr_adaptive_odbc.conf. Check res_odbc.conf.

[virus_net]

zzuz, вы думаете это ему поможет?
Видно же, что чел даже не понимает, что именно он делает. Это называется "по колесам постучал, фары протёр, но не едет!". Понимания как это работает равно нулю.

2ТС, обратитесь к системному администратору, ибо ну не ваше это.

[ch.a.sh]

virus_net: Главное что вы понимаете как всё это работает ,остальное мелочи


upd: Разобрался спасибо zzuz

[ded]

За что спасибо?
За то что zzuz вам же процитировал последнюю строчку вашего лога?
Очень не понимаю.

[Ethereal^flame]

Добрый день!
Такая же проблема...старый добрый Asterisk 11.17.1 built by palosanto @ rpmbuild64-2.elastix.palosanto.com on a x86_64 running Linux on 2015-04-12 12:33:25 UTC, звонки все пишутся в /var/spool/asterisk/monitor а в вебке не видно ни одного из записей, это случилось после резкого отключения электричества, в логах тоже самое:

Код: Выделить всё

No such connection 'asteriskcdrdb' in the 'cel' section of cel_odbc.conf.  Check res_odbc.conf.

Если открываем файлик cat /etc/asterisk/res_odbc.conf, то видим содержимое:

Код: Выделить всё

; Do NOT edit this file as it is auto-generated by FreePBX. All modifications to ;
; this file must be done via the web gui. There are alternative files to make    ;
; custom modifications, details at: http://freepbx.org/configuration_files       ;
;--------------------------------------------------------------------------------;
;
; This file is part of FreePBX.
;
;    FreePBX is free software: you can redistribute it and/or modify
;    it under the terms of the GNU General Public License as published by
;    the Free Software Foundation, either version 2 of the License, or
;    (at your option) any later version.
;
;    FreePBX is distributed in the hope that it will be useful,
;    but WITHOUT ANY WARRANTY; without even the implied warranty of
;    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;    GNU General Public License for more details.
;
;    You should have received a copy of the GNU General Public License
;    along with FreePBX.  If not, see <http://www.gnu.org/licenses/>.
;
; Copyright (C) 2012 Astrogen LLC (USA)

#include res_odbc_custom.conf
#include res_odbc_additional.conf

И как бы всё на этом, тут нам явно говорят, что в него лезть не нужно и он автоматом генерится FreePBX'ом.
Есть бекап его с именем res_odbc.conf.old_freePBX-2.11.0-17 , вот его содержимое:
cat /etc/asterisk/res_odbc.conf.old_freePBX-2.11.0-17

Код: Выделить всё

;;; odbc setup file

; ENV is a global set of environmental variables that will get set.
; Note that all environmental variables can be seen by all connections,
; so you can't have different values for different connections.
[ENV]
;INFORMIXSERVER => my_special_database
;INFORMIXDIR => /opt/informix
;ORACLE_HOME => /home/oracle

; All other sections are arbitrary names for database connections.

;
; The context name is what will be used in other configuration files, such
; as extconfig.conf and func_odbc.conf, to reference this connection.
[asterisk]
;
; Permit disabling sections without needing to comment them out.
; If not specified, it is assumed the section is enabled.
enabled => no
;
; This value should match an entry in /etc/odbc.ini
; (or /usr/local/etc/odbc.ini, on FreeBSD and similar systems).
dsn => asterisk
;
; Username for connecting to the database.  The user defaults to the context
; name if unspecified.
;username => myuser
;
; Password for authenticating the user to the database.  The default
; password is blank.
;password => mypass
;
; Build a connection at startup?
pre-connect => yes
;
; What should we execute to ensure that our connection is still alive?  The
; statement should return a non-zero value in the first field of its first
; record.  The default is "select 1".
;sanitysql => select 1
;
; On some databases, the connection times out and a reconnection will be
; necessary.  This setting configures the amount of time a connection
; may sit idle (in seconds) before a reconnection will be attempted.
;idlecheck => 3600
;
; Should we use a single connection for all queries?  Most databases will
; allow sharing the connection, though Sybase and MS SQL Server will not.
;share_connections => yes
;
; If we aren't sharing connections, what is the maximum number of connections
; that we should attempt?
;limit => 5
;
; When the channel is destroyed, should any uncommitted open transactions
; automatically be committed?
;forcecommit => no
;
; How should we perceive data in other transactions within the database?
; Possible values are read_uncommitted, read_committed, repeatable_read,
; and serializable.  The default is read_committed.
;isolation => repeatable_read
;
; Is the backslash a native escape character?  The default is yes, but for
; MS SQL Server, the answer is no.
;backslash_is_escape => yes
;
; When enabled (default behavior), empty column values are stored as empty strings
; during realtime updates. Disabling this option causes empty column values to be
; stored as NULLs for non-text columns.
; Disable it for PostgreSQL backend in order to avoid errors caused by updating
; integer columns with an empty string instead of NULL (sippeers, sipregs, ..).
; NOTE: This option will be removed in asterisk 13. At that point, it will always
; behave as if it was set to 'no'.
;allow_empty_string_in_nontext => yes
;
; How long (in seconds) should we attempt to connect before considering the
; connection dead?  The default is 10 seconds, but you may wish to reduce it,
; to increase responsiveness.
;connect_timeout => 10
;
; When a connection fails, how long (in seconds) should we cache that
; information before we attempt another connection?  This increases
; responsiveness, when a database resource is not working.
;negative_connection_cache => 300

[mysql2]
enabled => no
dsn => MySQL-asterisk
username => myuser
password => mypass
pre-connect => yes

; Certain servers, such as MS SQL Server and Sybase use the TDS protocol, which
; limits the number of active queries per connection to 1.  By telling res_odbc
; not to share connections, Asterisk can be made to work with these servers.
[sqlserver]
enabled => no
dsn => mickeysoft
share_connections => no
limit => 5
username => oscar
password => thegrouch
pre-connect => yes
sanitysql => select count(*) from systables
; forcecommit => no            ; Default to committing uncommitted transactions?
                               ; Note:  this is NOT the autocommit flag; this
                               ; determines the end result of transactions which
                               ; are not explicitly committed or rolled back.  By
                               ; default, such transactions are rolled back if the
                               ; call ends without an explicit commit.
; isolation => read_committed  ; Isolation level; supported levels are:
                               ; read_uncommitted, read_committed, repeatable_read,
                               ; serializable.  Note that not all databases support
                               ; all isolation levels (e.g. Postgres only supports
                               ; repeatable_read and serializable).  See database
                               ; documentation for further information.
;
; Many databases have a default of '\' to escape special characters.  MS SQL
; Server does not.
backslash_is_escape => no

;
; If you are having problems with concurrency, please read this note from the
; mailing lists, regarding UnixODBC:
;
; http://lists.digium.com/pipermail/asterisk-dev/2009-February/036539.html
;
; In summary, try setting "Threading=2" in the relevant section within your
; odbcinst.ini.
;

Может бекапный файлик переименовать в res_odbc.conf и рестартнуть Asterisk?

[Wapo]

То что в логе сказано смотреть в res_odbc не есть ЕДИНСТВЕННЫЙ ПУТЬ ДЖЕДАЯ - там же указано подцепить еще и _custom и _addition варианты - вот и гляньте что в них.
Ну а файл бакапа совсем из другой версии (видимо сделан до обновления оболочки)

[Ethereal^flame]

Все, разобрался, дело было в поврежденной таблице "cdr" базы "asteriskcdrdb", что я сделал чтобы найти и пофиксить проблему:
1. Для начала подключился к консоли Asterisk и проверил, работают ли следующие три модуля:

Код: Выделить всё

Connected to Asterisk 11.17.1 currently running on Elastix (pid = 2585)
Elastix*CLI> module show like res_odbc
Module                         Description                              Use Count
res_odbc.so                    ODBC resource                            0
1 modules loaded

Elastix*CLI> module show like cdr_adaptive_odbc.so
Module                         Description                              Use Count
cdr_adaptive_odbc.so           Adaptive ODBC CDR backend                0
1 modules loaded


Elastix*CLI> module show like cel_odbc.so
Module                         Description                              Use Count
cel_odbc.so                    ODBC CEL backend                         0
1 modules loaded

Все, видим, что три модуля res_odbc cdr_adaptive_odbc.so cel_odbc.so загружены, значит работают, едем дальше.


2. Логинимся в mysql и открываем базу "asteriskcdrdb"
[root@Elastix asterisk]# mysql -u root -p
вводим пароль админа
далее появляется приглашение mysql
пишем: connect asteriskcdrdb

Код: Выделить всё

mysql> connect asteriskcdrdb
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Connection id:    2580
Current database: asteriskcdrdb

Далее делаем запрос на выборку записей по дате:

Код: Выделить всё

mysql> select calldate, src, dst from cdr where calldate >= '2022-08-24';
ERROR 1194 (HY000): Table 'cdr' is marked as crashed and should be repaired

И тут нам система четко говорит, что таблица "cdr" помечена как поврежденная и нужно её восстановить, запускаем команду восстановления этой таблицы:

Код: Выделить всё

mysql> repair table cdr;

Видим сообщение:

Код: Выделить всё

+-------------------+--------+----------+-----------------------------------------------+
| Table             | Op     | Msg_type | Msg_text                                      |
+-------------------+--------+----------+-----------------------------------------------+
| asteriskcdrdb.cdr | repair | info     | Wrong bytesec:   0-  0-  0 at 991236; Skipped |
| asteriskcdrdb.cdr | repair | warning  | Number of rows changed from 15920 to 15820    |
| asteriskcdrdb.cdr | repair | status   | OK                                            |
+-------------------+--------+----------+-----------------------------------------------+
3 rows in set (0.55 sec)

Как видим, status таблицы стал "ОК", следовательно, еще раз проверяем записи в этой таблице с выборкой по дате командой:

Код: Выделить всё

mysql> select calldate, src, dst from cdr where calldate >= '2022-08-24';

Таблица ожила, записи восстановились, все работает!