статистичні дані про характеристики пакетів, кількості колізій і т.п.
History - статистичні дані, збережені через певні проміжки часу для подальшого аналізу тенденцій їх змін.
Alarms - порогові значення статистичних показників, при перевищенні яких агент RMON посилає повідомлення менеджеру. Дозволяє користувачеві визначити ряд порогових рівнів (ці пороги можуть ставитися до самих різних речей - будь-якому параметру з групи статистики, амплітуді або швидкості його зміни і багато чому іншому), по перевищенні яких генерується аварійний сигнал. Користувач може також визначити, за яких умов перевищення порогового значення повинно супроводжуватися аварійним сигналом - це дозволить уникнути генерації сигналу по дурницях raquo ;, що погано, по-перше, тому, що на постійно палаючу червону лампочку ніхто не звертає уваги, а во-друге, тому, що передача непотрібних аварійних сигналів по мережі призводить до зайвої завантаженні ліній зв'язку. Аварійний сигнал, як правило, передається в групу подій, де і визначається, що з ним робити далі.
Host - даних про хостах мережі, у тому числі і про їх MAC-адресах ..
HostTopN - таблиця найбільш завантажених хостів мережі. Таблиця N головних хостів (HostTopN) містить список N перших хостів, що характеризуються максимальним значенням заданого статистичного параметра для заданого інтервалу. Наприклад, можна зажадати список 10 хостів, для яких спостерігалося максимальну кількість помилок протягом останніх 24 годин. Список цей буде складений самим агентом, а додаток управління отримає тільки адреси цих хостів і значення відповідних статистичних параметрів. Видно, до якої міри такий підхід економить мережеві ресурси
TrafficMatrix - статистика про інтенсивність трафіку між кожною парою хостів мережі, впорядкована у вигляді матриці. Рядки цієї матриці пронумеровані відповідно до MAC-адресами станцій - джерел повідомлень, а стовпці - відповідно з адресами станцій-одержувачів. Матричні елементи характеризують інтенсивність трафіку між відповідними станціями і кількість помилок. Проаналізувавши таку матрицю, користувач легко може з'ясувати, які пари станцій генерують найбільш інтенсивний трафік. Ця матриця, знову-таки, формується самим агентом, тому відпадає необхідність у передачі великих обсягів даних на центральний комп'ютер, що відповідає за управління мережею.
Filter - умови фільтрації пакетів. Ознаки, за якими фільтруються пакети, можуть бути найрізноманітнішими - наприклад, можна зажадати відфільтровувати як помилкові всі пакети, довжина яких виявляється менше деякого заданого значення. Можна сказати, що установка фільтра відповідає як би організації каналу для передачі пакета. Куди веде цей канал - визначає користувач. Наприклад, всі помилкові пакети можуть перехоплюватися і направлятися в соответсвующий буфер. Крім того, поява пакету, відповідного встановленому фільтру, може розглядатися як подія (event), на яке система повинна реагувати заздалегідь обумовленим чином.
PacketCapture - умови захоплення пакетів. До складу групи перехоплення пакетів (packet capture) входять буфера для захоплення, куди направляються пакети, чиї ознаки задовольняють умовам, сформульованим у групі фільтрів. При цьому захоплюватися може не пакет цілком, а, скажімо, тільки перші кілька десятків байт пакета. Вміст буферів перехоплення можна згодом аналізувати за допомогою різних програмних засобів, з'ясовуючи цілий ряд вельми корисних характеристик роботи мережі. Перебудовуючи фільтри на ті чи інші ознаки, можна характеризувати різні параметри роботи мережі.
Event - умови реєстрації і генерації подій. У групі подій (events) визначається, коли слід відправляти аварійний сигнал додатком управління, коли - перехоплювати пакети, і взагалі - як реагувати на ті чи інші події, що відбуваються в мережі, наприклад, на перевищення заданих в групі alarms порогових значень: чи слід ставити до відома додаток управління, або треба просто запротоколювати дана подія і продовжувати працювати. Події можуть і не бути пов'язані з предачі аварійних сигналів - наприклад, напрямок пакета в буфер перехоплення теж являє собою подія.
Дані групи пронумеровані у вказаному порядку, тому, наприклад, група Hosts має числове ім'я 1.3.6.1.2.1.16.4.
Десяту групу складають спеціальні об'єкти протоколу TokenRing.
Всього стандарт RMON MIB визначає близько 200 об'єктів у 10 групах, зафіксованих в двох документах - RFC тисяча двісті сімдесят одна для мереж Ethernet і RFC 1513 для мереж TokenRing [28, с. 95].
Відмінною рисою стандарту RMON MIB є його незалежність від протоколу мережевого рівня (на відміну від стандартів MIB-I і MIB-II, орієнтованих на протоколи TCP/IP). Тому, його зручно використовувати в гетерогенн...
