За шаблон конечно спасибо, тем более что далеко не всегда СКУД слава богу интегрируется в общую ИТ-систему, и многим действительно будет это полезно. А еще лучше было бы добавить во-первых SNMP-сервер в сам сервер СКУД для мониторинга в единой системе контроллеров не поддерживающих SNMP (ну конечно в части тех данных которые контроллер может вернуть в СКУД), а во-вторых для критичных реакций сделать трапы что бы получать информацию о проблеме сразу а не через какое-то время (период опроса+число проблем в настройке триггера).
Здравствуйте, СКУД в первую очередь является инструментом управления доступа, а для выполнения задач по мониторингу сетевых устройств - есть специализированные системы. Мы, в свою очередь, предоставляем возможность для достаточного детального мониторинга наших сетевых компонентов. Касаемо своевременного получения информации, в системах мониторинга, при настройке отслеживаемых метрик и параметров, а также настройке триггеров - можно указать пользовательское время опроса тех или иных данных и их важность. Например, для самых важных метрик можно уменьшить время опроса до нескольких секунд и получать своевременные уведомления в случае возникновения критических ситуаций.
@@sigursys Какие специализированные системы? Я про сервер SNMP в самом сервер sigur. Иными словами для получения информации по SNMP не от контроллеров которые не умеют это делать а от сервера который информацию от контроллеров получать может. Ну аналогично SNMP или WMI в Windows. Время опроса это нагрузка на сервер. Не всегда нужная. Не всегда которая может быть корректно обработана. Метрик может быть тысячи. Трап все-таки это немного другое.
@@alexsar5500 как мы уже упоминали ранее, Sigur, в первую очередь, является системой контроля доступа, а не SNMP-сервером. Контроллеры, действительно, могут сообщать серверу о каких-либо критически важных событиях, но это внутренний функционал взаимодействия компонентов системы. Для своевременного оповещения ответственных сотрудников - можно настроить функционал модуля "Реакция на события" в части уведомлений о событиях СКУД. В связи с этим, на данный момент, нет необходимости в разработке и добавлении в сервер системы контроля доступа функционала SNMP-сервера. Для этого была добавлена возможность подключения сетевых компонентов СКУД (E510, E2, E4) к специализированным системам мониторинга. Старые модели контроллеров, действительно, не поддерживают протокол SNMP, но и более не производятся. Касаемо, так называемых, SNMP-трапов - данный функционал доступен при настройке сетевых параметров контроллера в части "Включение SNMP v2 trap". В случае, если данный функционал, действительно, важен и необходим для решения Ваших задач, то Вы можете связаться с нашим коммерческим отделом для консультации по его доработке: sales@sigur.com
@@sigursys Ну а куда деваться. Реакция на события + обработчих их в том же заббиксе. Сложнее но не невозможно. Ведь не ставить же отдельное рабочее место для мониторинга скуд - это утопия. Кстати в реакции на события можно было бы добавить трапы :)))
@@sigursys Полностью согласен с коллегой. У меня на объекте допустим стоят контроллеры старой версии, которые не поддерживают snmp протокол. А задача получать данные от системы есть, но без коммерческого подтекста на данный момент. В связи с этим было полезно получать данные из самого сервера sigur, например о тех же падениях контроллера или считывателя. Ну не покупать же для этого новые контроллеры. Тем более я думаю связь у вашего сервера и контроллеров старого образца не сложнее, чем новый контроллер. И бы до бы полезно тоже самое внедрить в сам софт
Здравствуйте! Передача статусов работы устройства по протоколу SNMP поддерживается контроллерами Sigur моделей E510, E2 и E4. Следовательно, настроить данную функцию для контроллеров Е300Х/Е500Х/Е900Х не получится.
За шаблон конечно спасибо, тем более что далеко не всегда СКУД слава богу интегрируется в общую ИТ-систему, и многим действительно будет это полезно. А еще лучше было бы добавить во-первых SNMP-сервер в сам сервер СКУД для мониторинга в единой системе контроллеров не поддерживающих SNMP (ну конечно в части тех данных которые контроллер может вернуть в СКУД), а во-вторых для критичных реакций сделать трапы что бы получать информацию о проблеме сразу а не через какое-то время (период опроса+число проблем в настройке триггера).
Здравствуйте, СКУД в первую очередь является инструментом управления доступа, а для выполнения задач по мониторингу сетевых устройств - есть специализированные системы. Мы, в свою очередь, предоставляем возможность для достаточного детального мониторинга наших сетевых компонентов.
Касаемо своевременного получения информации, в системах мониторинга, при настройке отслеживаемых метрик и параметров, а также настройке триггеров - можно указать пользовательское время опроса тех или иных данных и их важность. Например, для самых важных метрик можно уменьшить время опроса до нескольких секунд и получать своевременные уведомления в случае возникновения критических ситуаций.
@@sigursys Какие специализированные системы? Я про сервер SNMP в самом сервер sigur. Иными словами для получения информации по SNMP не от контроллеров которые не умеют это делать а от сервера который информацию от контроллеров получать может. Ну аналогично SNMP или WMI в Windows. Время опроса это нагрузка на сервер. Не всегда нужная. Не всегда которая может быть корректно обработана. Метрик может быть тысячи. Трап все-таки это немного другое.
@@alexsar5500 как мы уже упоминали ранее, Sigur, в первую очередь, является системой контроля доступа, а не SNMP-сервером. Контроллеры, действительно, могут сообщать серверу о каких-либо критически важных событиях, но это внутренний функционал взаимодействия компонентов системы. Для своевременного оповещения ответственных сотрудников - можно настроить функционал модуля "Реакция на события" в части уведомлений о событиях СКУД.
В связи с этим, на данный момент, нет необходимости в разработке и добавлении в сервер системы контроля доступа функционала SNMP-сервера. Для этого была добавлена возможность подключения сетевых компонентов СКУД (E510, E2, E4) к специализированным системам мониторинга. Старые модели контроллеров, действительно, не поддерживают протокол SNMP, но и более не производятся.
Касаемо, так называемых, SNMP-трапов - данный функционал доступен при настройке сетевых параметров контроллера в части "Включение SNMP v2 trap".
В случае, если данный функционал, действительно, важен и необходим для решения Ваших задач, то Вы можете связаться с нашим коммерческим отделом для консультации по его доработке: sales@sigur.com
@@sigursys Ну а куда деваться. Реакция на события + обработчих их в том же заббиксе. Сложнее но не невозможно. Ведь не ставить же отдельное рабочее место для мониторинга скуд - это утопия. Кстати в реакции на события можно было бы добавить трапы :)))
@@sigursys
Полностью согласен с коллегой. У меня на объекте допустим стоят контроллеры старой версии, которые не поддерживают snmp протокол. А задача получать данные от системы есть, но без коммерческого подтекста на данный момент.
В связи с этим было полезно получать данные из самого сервера sigur, например о тех же падениях контроллера или считывателя. Ну не покупать же для этого новые контроллеры. Тем более я думаю связь у вашего сервера и контроллеров старого образца не сложнее, чем новый контроллер. И бы до бы полезно тоже самое внедрить в сам софт
Я так полагаю контроллер E900X к забиксу не подключить?
Здравствуйте! Передача статусов работы устройства по протоколу SNMP поддерживается контроллерами Sigur моделей E510, E2 и E4. Следовательно, настроить данную функцию для контроллеров Е300Х/Е500Х/Е900Х не получится.