Господа, а не подскажет ли кто-нибудь, как настроить сы 1000 на отсылку логов на Syslog Server?
заранее благодарен.

Логов чего?
И что есть syslog server? Каким протоколом принимает данные?

Вероятно имелось ввиду вот это (http://ru.wikipedia.org/wiki/Syslog). Что-то я несколько сомневаюсь, что Меридиан будет это делать...
:rolleyes:
Это если тока специальную софтинку написать, которая будет типа шлюзиком между Меридианом и этим самым server...

А не проще трапы по снмп посылать? Так прямее, правду говорю...

Мне всё-таки кажется, что топикстартер имел ввиду CDR (интересно, почему? ;) ). А вот что Меридиан умеет CDR по SNMP отправлять я пока ещё не слышал. Хотя век живи - век учись, а всё останется как было...
:p
Но если посмотреть на предназначение syslog server, ему, на самом деле, родной брат - SNMP.
Ау! Топикстартер! Не будете ли Вы столь любезны пояснить нам суть Вашего вопроса? А то штатные ясновидящие пока ещё не увидели Ваш вопрос, а мы можем только догадываться о том, что же Вы понимете под ... отсылкой логов ...

Вот честное слово сколько "копий сломано" насчет скачивания CDR по FTP! Ну не проще ли подключить этот бедный CDR порт к WTI буфферу и закачайся с помощью FTP до "посинения". Вопрос только в цене.
Если хочется дешево, ставишь самый наидешевейший компухтер, на него Линукс и пишеш софт для складывания логов в файлы, FTP и прочая шняга там от рождения.
Даже в Инете видел статьи когда тоже самое реализовывалось чуть ли не на скриптах..

Меридиан умеет CDR по SNMP отправлять я пока ещё не слышал.

Нет, Уважаемый, конечно же я имел ввиду сообщения системы, алармы, и т.д.
В общем-то по приведённой Вами ссылке на википедию мне кажется речь о чём угодно, только не о билинге :)

Да, топикстартер! Ау-у-у!

???

vv11 пишет
... пишеш софт для складывания логов в файлы, FTP и прочая шняга там от рождения ... Уважаемый коллега! Позвольте с Вами не согласиться. Сбор CDR по FTP только на первый взгляд простейшая задача. На самом деле особых сложностей там нет, но есть "нюансы"...
В своё время, мы с уважаемыми коллегами Gluker и TheRam активно эту проблему обсуждали. Почитать нашу стародавнюю дискуссию, до тех пор, пока мы не ушли в личку, можно тут (http://bbs.radiolink.ru/forum/showthread.php?s=&threadid=24959&perpage=40&highlight=cdr%20ftp&pagenumber=1). В результате и у Gluker и у меня появилась реализация этого алгоритма в виде готовой программы.

Использование FTP самого коммутатора для регистрации соединений - намного более правильный подход, нежели установка промежуточного буфера или сбор данных по RS-232C. Хотя - бы с точки зрения надёжности. Промежуточный буфер нуна ещё как-то запитывать, а Meridian, насколько мне известно, не учитывает наличие флажка готовности по RS-232C и не может складывать CDR в свой буфер, если сбор данных идёт по RS-232C, а ваше оборудование не готово к приёму данных.

Так что накопление CDR в самом коммутаторе, а потом "забирание" их по FTP - наиболее безопасный и удобный способ получения CDR записей.

Вот как-то так...

;)

TheRam пишет
В общем-то по приведённой Вами ссылке на википедию мне кажется речь о чём угодно, только не о билинге :)
Уважаемый коллега! Я полностью с Вами согласен, однако топикстартер употребил словосочетание ... на отсылку логов .... Поэтому я, в силу специфики своей деятельности, прочитал это именно как логи соединений. :)
Каюсь, топикстартер, скорее всего, не желая того, ввёл меня в заблуждение относительно предмета дискуссии.

Хотя ему самому наше обсуждение, как мне кажется, уже не интересно...

****
Использование FTP самого коммутатора для регистрации соединений - намного более правильный подход, нежели установка промежуточного буфера или сбор данных по RS-232C. Хотя - бы с точки зрения надёжности.
****
Интересно чем же именно надежен?
Тем что вы "загаживаете" внутренний диск станции посторонними данными. Попробуйте не выкачивать эти данные и грамотно не обнулять буффер и постоянные ошибки софта станции станут вашими спутниками по жизни.

***
Промежуточный буфер нуна ещё как-то запитывать
***
Если вы в курсе на 11 машине есть разьем AUX на котором присутствует питание 48 В., есть такие буферы у WTI потребляют они крайне немного.

***
А Meridian, насколько мне известно, не учитывает наличие флажка готовности по RS-232C и не может складывать CDR в свой буфер, если сбор данных идёт по RS-232C, а ваше оборудование не готово к приёму данных.
***
Так для этого буффер и нужен (он готов всегда как ПИОНЕР), он принимает с порта Rs232 данные и складывает их в память. У него есть также Ethernet порт с которого по протоколу FTP время от времени можно скачивать данные.

****
Так что накопление CDR в самом коммутаторе, а потом "забирание" их по FTP - наиболее безопасный и удобный способ получения CDR записей.
****
К сожалению отнюдь небезопасный и не очень удобный, как это реализовано в Меридиане.

К примеру если бы этот буфер в станции был бы организован по примеру циклических файлов станции EWSD это был бы толк. Т.е. когда файлу выставляется определенный размер и он пишется циклически затирая самые старые данные.

Позвольте подискутировать.
С утверждением "загаживаете" внутренний диск станции посторонними данными не согласен, ибо OTM (сейчас просто TM) использует именно этот механизм буферизирования и получения данных. Так что они не посторонние.
Кроме того существует более чем корректное решение проблемы буфера в 11с - флэшка в слоте B. Что касается больших машин, там такой проблемы нет вовсе.
У меня с трёх больших машин и с более чем десятка 11с данные собираются с использованием dbalog от Glukera, за что ему большое человеческое спасибо!
Нюанс правда есть всегда. Это - дублирующий способ, основной с помощью датаколлекторов на локальных ПК, подключенных сериальником.
И если вдруг, а такое всё-таки бывает, сбор прекращается (ну автор программы знает почему ;) - то до момента, пока эксплуатация опомнится, буфер успевает переполниться, генерится алярм, отсылается трап диспетчеру, админ сервака получает "по башке" и музыка снова начинает играть. Но это всё, других проблем не наблюдаю.
Реальные проблемы были на релизе 25.40 при установлении live-session с OTM-а по IP. Но со временем и они патчами и новыми релизами ОТМ полечились.
Так что вот тут хотелось бы услышать Ваш опыт насчёт постоянные ошибки софта станции

на самом деле у ОТМа и у dbalog есть большой минус в работе на нестабильных сетях
если после переименовывания файла или во время фтп сессии происходит обрыв сети, то файл не докачивается и не стирается со станции
в результате диск может переполнится такими файлами, а в биллинге могут быть дырки

Коллега! Это решаемо! Для этого достаточно сканировать содержимое папки на предмет наличия этих самых "переименованых" файлов. Если вести журнальчик что и когда забиралось - то проблем не будет. Да и просто наличие "переименованного" файла ненулевого размера - признак того, что предыдущая сессия "обломилась."

Так что переполнение диска такими файлами скорее не недостаток технологии, а э-э-э... особенности конкретной реализации алгоритма по установлению FTP сессий...
;)

dbalog есть большой минус
Ага, есть - автору лениво в нём что-то доделывать :)
Правильный функционал он скорее всего положил в...другой продукт? :)

И где же топикстартер? А то мы эдак до большой политики дорассуждаемся...:D

Господа не умаляя знаний и опыта большинства из вас хочу сказать следующее. Есть решения промышленные когда поставил и работает без всяких но. А есть решения когда "идет програмирование, ради програмирования" это тоже можно применить когда есть "вагон времени" и желание его потратить.
Но говорить что подход "на коленке" самый правильный, это позвольте....:cool:
Кстати а никто не желает в софте Меридиана реализовать циклические файлы, а то я могу и алгоритм накидать.:D

Позвольте, когда это подход "на коленке" самый правильный декларировался как "самый правильный"? Я описал своё решение не для тиражирования в массы и не дай Бог для навязывания таких решений заказчику, а как демонстрацию работоспособности технологии. Наоборот, я против таких "наколенковых" решений, и согласен с Вами, что EWSD во многом может служить эталоном.

И вообще, о чём это мы....

Кто здесь?

:D

Ув. ThaRam я вообще писал это не вам а Pvalera, я его отлично понимаю, он работает в фирме которая пишет софт и ему нужно блеснуть програмным решением.
Я в последнее время больше был эксплуатантом, хотя в свое время пришлось писать программы и на Ассемблере и на ++ и в том числе программы для однокристалок, но суть не в этом.
Решение если оно промышленное должно быть такое "поставил и забыл".
А что например произойдет если Нортел завтра "забанит" выкачку по FTP для "чужих" и что дальше? Опять к клавиатуре?

И действительно, о чем это мы...

Уважаемый vv11!
Что именно вы имеете ввиду говоря ...подход "на коленке"...? Я надеюсь не штатную возможность Meridian накапливать CDR записи на флеш-карте, расположенной в слоте процессора?

Решение, которое предлагает вендор, исключает необходимость использования каких - либо посторонних "примочек", в виде внешнего буфера.

А то, что многие из нас по старинке стараются не использовать того, за что они руками подержаться не успели - это факт.

Ещё раз повторю свою мысль:
Использование внутренних возможностей коммутатора, а именно документированное вендором накопление CDR записей на флеш-карте, установленной в слоте процессора, надёжнее, нежели использование внешнего буфера, который с коммутатором связан через RS-232C.

Если у Вас, уважаемый vv11, есть аргументы против этого, я с удовольствием их выслушаю.

Нортел завтра "забанит" выкачку по FTP для "чужих"

Э-э-х, раз уж топик такой...
Asterisk в последнем релизе поддерживает более 10 потоков Е1. У меня есть Заказчик с такой вот игрушкой на 20 потоков. 5 четырёх-портовых адаптеров в PCI-слотах, 4-ядерный камушек. Бюджет - около $30к
Это тоже "на коленке", но если бы я делал для себя за свои деньги, то однозначно собрал бы что-то подобное, ни у одного вендора за эту сумму внятное решение не купить...

pvalera пишет
Коллега! Это решаемо!
ни кто в этом и не сомневается :)
TheRam пишет
Ага, есть - автору лениво в нём что-то доделывать
не лениво, а невозможно т.к. нет исходников и пересел с BCB на MVS
Правильный функционал он скорее всего положил в...другой продукт? :)
в процессе :)

Вот! Это наш подход!
:D
А то "на коленке - на коленке"
:p

TheRam пишет
... если бы я делал для себя за свои деньги, то однозначно собрал бы что-то подобное ...
Вот она, ключевая фраза...
;)

vv11 пишет
А что например произойдет если Нортел завтра "забанит" выкачку по FTP для "чужих" и что дальше? Опять к клавиатуре?
рекомендую начинать добавлять поддержку SFTP ;-)

мы подождем пока в ордерпро добавят ssh :)

Gluker пишет
мы подождем пока в ордерпро добавят ssh :)
похоже все-таки добавят - я с ними разговаривал достаточно давно на эту тему