Снова про кактус и snmp
Oct. 7th, 2014 09:21 amНу и кто придумал так тупо именовать счётчики в snmp?
А теперь догадайтесь что значат по три температуры для проца и мамкм. Ну, понятно, что придумать и догадаться можно, что один - собственно сама температура, второй и третий - лимиты. А может сначала лимиты, а потом температура? А лимиты верх-низ или предупреждение-паника? Понятно, что достаточно взглянуть на сами значения, чтобы понять и порядок, и смысл, и шкалу. Но почему описание нельзя сделать адеватным? Отсутствие адекватного описание означает, что его использовать не получится. Ну, да: "А вдруг, можно задать в кактусе sensorName CPU Temperature и он возьмёт первый?" Может и так. А может и не так. Проверить либо только через 5 минут (хорошо если период опроса короткий), либо вручную, на что кактус после штатного запуска будет обижаться: "сэр, тут насрано".
В принципе, мне все эти датчики не особо-то и нужны, по большому счёту. Обходился и без них столько лет. Но ведь как-то оно же должно работать? Почему, после очередного рестарта компа (после апгрейда ядра или чего-нибудь подобно-чувствительного) датчики уползают и кактус показывает вместо текущей температуры её лимит.
Можно было бы, конечно, плюнуть на кактус и самостоятельно собирать данные, но нет ни времени, не желания. Пока что. :)
Надо будет всё-таки переписать настройки чтобы для начала понять кто свинячит - кактус или snmp. Почему нет простого экспорта текстового конфига? Да и конфиг не в простом тексте. Ну да - если несколько десятков или даже сотен девайсов с десятками датчиков, то текстом не сильно-то и удобно конфигурять.
Снял дамп с кактусовой базы (mysql). Глянул - не прозрачно, надо разбираться. Нет времени и желания. :) Скоро можно будет ставить © или придумывать аббревиатуру.
Проще переписать пару цифр...
iso.3.6.1.4.1.2021.13.16.2.1.2.1 = STRING: "Core0 Temp" iso.3.6.1.4.1.2021.13.16.2.1.2.2 = STRING: "Core1 Temp" iso.3.6.1.4.1.2021.13.16.2.1.2.3 = STRING: "CPU Temperature" iso.3.6.1.4.1.2021.13.16.2.1.2.4 = STRING: "CPU Temperature" iso.3.6.1.4.1.2021.13.16.2.1.2.5 = STRING: "CPU Temperature" iso.3.6.1.4.1.2021.13.16.2.1.2.6 = STRING: "MB Temperature" iso.3.6.1.4.1.2021.13.16.2.1.2.7 = STRING: "MB Temperature" iso.3.6.1.4.1.2021.13.16.2.1.2.8 = STRING: "MB Temperature"
А теперь догадайтесь что значат по три температуры для проца и мамкм. Ну, понятно, что придумать и догадаться можно, что один - собственно сама температура, второй и третий - лимиты. А может сначала лимиты, а потом температура? А лимиты верх-низ или предупреждение-паника? Понятно, что достаточно взглянуть на сами значения, чтобы понять и порядок, и смысл, и шкалу. Но почему описание нельзя сделать адеватным? Отсутствие адекватного описание означает, что его использовать не получится. Ну, да: "А вдруг, можно задать в кактусе sensorName CPU Temperature и он возьмёт первый?" Может и так. А может и не так. Проверить либо только через 5 минут (хорошо если период опроса короткий), либо вручную, на что кактус после штатного запуска будет обижаться: "сэр, тут насрано".
В принципе, мне все эти датчики не особо-то и нужны, по большому счёту. Обходился и без них столько лет. Но ведь как-то оно же должно работать? Почему, после очередного рестарта компа (после апгрейда ядра или чего-нибудь подобно-чувствительного) датчики уползают и кактус показывает вместо текущей температуры её лимит.
Можно было бы, конечно, плюнуть на кактус и самостоятельно собирать данные, но нет ни времени, не желания. Пока что. :)
Надо будет всё-таки переписать настройки чтобы для начала понять кто свинячит - кактус или snmp. Почему нет простого экспорта текстового конфига? Да и конфиг не в простом тексте. Ну да - если несколько десятков или даже сотен девайсов с десятками датчиков, то текстом не сильно-то и удобно конфигурять.
Снял дамп с кактусовой базы (mysql). Глянул - не прозрачно, надо разбираться. Нет времени и желания. :) Скоро можно будет ставить © или придумывать аббревиатуру.
Проще переписать пару цифр...