Конфигурация

Технология управления сетью предполагает наличие двух сторон: управляющей (в нашем случае AggreGate Network Manager) и управляемой (т.е. сетевых устройств и сервисов/приложений, обеспечивающих их работу). Обе стороны должны быть сконфигурированы должным образом.

Конфигурация системы относится к разделу Конфигурация AggreGate Network Manager . Если Вы не знакомы с продуктом, проверьте следующие задачи:

• Регистрация устройств для управления и мониторинга. Вы можете сделать это как вручную так и автоматически (используя обнаружение). Для лучшего понимания различных аспектов данной задачи рекомендуется настроить сначала несколько устройств вручную. На следующем этапе, когда Вам потребуется управлять и следить за большим количеством устройств, Вы освоите автоматические операции обнаружения.

• Задача ручной регистрации устройств тесно связана с задачей по их конфигурации, т.е с корректировкой параметров для них. Вы должны хорошо понимать эту задачу, поскольку она является решающей для успешного сетевого управления и мониторинга.

• Установка средств мониторинга (т.е. тревог, отчетов или диаграмм) для зарегистрированных устройств. См. раздел мониторинг, чтобы ознакомиться с доступными средствами и типами мониторинга.

Задача по конфигурации управляемой стороны не может быть полностью описана, так как существует огромное количество ПО и оборудования, которым можно управлять и следить. Если Вы не знакомы с проблемами конфигурации Ваших устройств, сервисов и приложений, то, на данном этапе, оставьте их настройки по умолчанию. С получением большего опыта и навыков, Вы вернетесь к этому вопросу и настроите управляемые элементы для лучшего взаимодействия с AggreGate Network Manager.

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

В производственных системах, где объем собираемых данных значителен, необходимо убедиться, что система настроена на использование соответствующей реляционной базы данных.

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

• Если большинство запросов не будут выполнять поиск по сериализованным данным в таблице данных событий, а вместо этого будут запрашивать только контекст, временную метку или уровень события, то просто убедитесь, что база данных хранилища событий способна обрабатывать входящие события.

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