???????-?????? : Cisco ICM Logger

Перезапуск средства ведения журнала создает старые ловушки SNMP

20 октября 2016 - Машинный перевод
Другие версии: PDF-версия:pdf | Английский (22 августа 2015) | Отзыв


Содержание


Введение

Этот документ описывает устаревший сообщения Перехвата простого протокола управления сетью (SNMP) в Cisco Унифицированная Среда предприятия Intelligent Contact Management (ICM) и предоставляет два возможных метода, чтобы препятствовать тому, чтобы были сообщены эти информационные сообщения.

Предварительные условия

Требования

Компания Cisco рекомендует предварительно ознакомиться со следующими предметами:

  • ICM Enterprise Cisco

  • Понимание SNMP

Используемые компоненты

Настоящий документ не имеет жесткой привязки к каким-либо конкретным версиям программного обеспечения и оборудования.

Условные обозначения

Дополнительные сведения об условных обозначениях см. в документе Условные обозначения технических терминов Cisco.

Общие сведения

Logger ICM собирает события и сообщения от всех составляющих системы. Logger передает эту информацию к процессу Customer Support Forwarding Service (CSFS), который получает события, фильтрует их и держит их в памяти на Logger, поскольку рисунок 1 показывает. Канал SNMP является дополнительной функцией ICM, которая позволяет вам получать источник данных для события через соответствие требованиям SNMP интерфейс (TCP/IP). При использовании канала SNMP можно настроить его, чтобы передать trap-сообщения SNMP желаемому клиенту управления.

Рисунок 1 — канал CSFS

logger-rest-old-snmp-1.gif

Проблема

Дизайном после перезапуска одного регистратора в дуплексной среде, или если один регистратор возвращается, устаревший, trap-сообщения SNMP могли бы генерироваться и отображаться в настроенной станции (станциях) управления SNMP. Когда процесс CSFS запущен как часть Logger, это получает событие (сигнал тревоги), о котором сообщат удаленному клиенту (через SNMP, Системный журнал или Сервис удалeнного мониторинга [RMS]), и это сохраняет копию события в памяти, названной базовой записью. В дуплексной, отказоустойчивой среде, когда процесс CSFS на одной стороне выключается и затем перезапускает, это получает все выдающиеся базовые записи от другой стороны и вперед их клиенту управления.

Решения

В этом разделе описываются возможные методы, которые можно использовать, чтобы препятствовать тому, чтобы были сообщены устаревшие сведения SNMP. Решение 1 показывает вам, как удалить устаревшие сведения SNMP от регистратора, и Решение 2 показывает вам, как подавить или фильтровать устаревшие сведения SNMP от клиента управления.

Решение 1

Удалите базовые записи. Чтобы сделать это, остановите Logger с обеих сторон одновременно и затем перезапустите их. Этот процесс удаляет всех, которые устарели trap-сообщения SNMP от процесса CSFS.

Примечание: Эта процедура должна быть сделана во время периода технического обслуживания или в течение времен влияния низкого маршрута.

  1. Остановите Logger B.

  2. Остановите Logger A.

  3. Запустите Logger A.

  4. Запустите Logger B.

Решение 2

Альтернативное решение должно иметь сигналы тревоги фильтра клиента управления клиента, которые являются более старыми, чем определенная продолжительность, например, одна неделя. Каждое trap-сообщение, которое сервис SNMP передает к второму партийному приложению клиента (такому как HP OpenView) содержит метку времени того, когда происходит фактическое событие. Клиенты могут тогда настроить свое приложение от стороннего разработчика для игнорирования сигналов тревоги со штампом времени, более старым, чем конкретный номер дней или недель. Следует отметить, что Центр технической поддержки (TAC) Contact Center Cisco не помогает в конфигурации определенного приложения от стороннего разработчика, которое клиент принимает решение использовать для управления этими событиями / trap-сообщения.


Дополнительные сведения


Document ID: 91626