Comments 41
3. Для удобной установки датчика использовали вот такой переходник RJ45 на RJ45, кат. 5e GCT11-8p8c, так же в количестве 128 штукПлагиат, однако ;)
Ну а если серьезно, скажите, чем обоснован выбор Zabbix? Почему не использовали, например, rrdtool, или БД какую-нить с гуглочартами?
Про плагиат я промолчу… :)
Это только часть системы, другая часть собирала данные по SNMP с Uniping Server Solution.
Во-вторых нужна была нормальная современная система с веб-интерфейсом, нормальными графиками, и самое главное с нормальной системой триггеров и настройкой действий для них.
Так как в Zabbix можно посылать любые данные, он является прекрасным средством мониторинга практически чего угодно :) Если сам не может забрать данные то всегда есть zabbix_sender или сейчас можно написать подключаемый модуль.
Это только часть системы, другая часть собирала данные по SNMP с Uniping Server Solution.
Во-вторых нужна была нормальная современная система с веб-интерфейсом, нормальными графиками, и самое главное с нормальной системой триггеров и настройкой действий для них.
Так как в Zabbix можно посылать любые данные, он является прекрасным средством мониторинга практически чего угодно :) Если сам не может забрать данные то всегда есть zabbix_sender или сейчас можно написать подключаемый модуль.
Вас понял, спасибо. Я просто к тому, что такие вещи как мониторинг можно своими несложными скриптами через тот же крон фигачить с учетом оповещений, храня данные в БД. Думаю, не сильно монструозно получится, зато полностью управляемо и расширяемо. А для графиков куча вариантов есть…
Я не люблю солянку, я выберу ту систему которая максимально удовлетворяет задачам из коробки, но при этом расширяемая (желательно без писания кода на С++ :) )
В Zabbix ничего нет монструазного…
Хотите графиков с кучей аналитик вон Яндекс Graphite использует, так как Zabbix слабоват для их кол-ва серверов, именно с точки зрения визуализации.
В Zabbix ничего нет монструазного…
Хотите графиков с кучей аналитик вон Яндекс Graphite использует, так как Zabbix слабоват для их кол-ва серверов, именно с точки зрения визуализации.
Когда параметров мало, собственные скрипты кажутся проще, чем zabbix.
Когда показателей становится хотя бы тысяча, приготовить zabbix уже проще, чем не закопаться в своих костылях.
Когда data-item'ов миллион — требуется серьезная оптимизация производительности :)
Когда показателей становится хотя бы тысяча, приготовить zabbix уже проще, чем не закопаться в своих костылях.
Когда data-item'ов миллион — требуется серьезная оптимизация производительности :)
Ну речь же идет про конкретную задачу, поэтому вопрос и возник…
у человека уже есть датацентр, в котором наверняка уже есть система мониторинга, в которую нужно было добавить матрицу термометров, я так понял задачу.
Если бы я себе дома мониторил температуру в холодильнике — zabbix конечно черезчур.
Кстати, тут в каком-то очередном посте про умный дом человек рассказывал, что он в пол закатал около 20 термодатчиков в одной комнате — собирался мониторить сквозняки :)
Если бы я себе дома мониторил температуру в холодильнике — zabbix конечно черезчур.
Кстати, тут в каком-то очередном посте про умный дом человек рассказывал, что он в пол закатал около 20 термодатчиков в одной комнате — собирался мониторить сквозняки :)
Жесть ))
Во-первых дата-центр не один ;)
+ куча всяческих узлов связи и серверных.
И планировалось не только мониторить температуру, а вообще инженерную инфраструктуру, и чтоб все это пищало и слало всем смс-ки, письма, будило бы операторов ДЦ из динамиков, то есть был рассмотрен потенциал развития системы и лучше Zabbix мне кажется ничего нет, на данный момент из open source.
+ куча всяческих узлов связи и серверных.
И планировалось не только мониторить температуру, а вообще инженерную инфраструктуру, и чтоб все это пищало и слало всем смс-ки, письма, будило бы операторов ДЦ из динамиков, то есть был рассмотрен потенциал развития системы и лучше Zabbix мне кажется ничего нет, на данный момент из open source.
У нас теперь другая проблема — определить порог «важности» алертов. Просыпаться просто так никому не хочется, но и не знать что происходит — тоже не вариант.
А чем Вас триггеры не устраивают?
1. Все зависит от системы и как быстро в ней растут параметры: если температура за последние 5 минут поднялась на 2 градуса, то просто информейшен — ничего не происходит
2. если на 10 — уже ворнинг, можно просыпаться
3. дальше алерт с вызовом пожарных :)
1. Все зависит от системы и как быстро в ней растут параметры: если температура за последние 5 минут поднялась на 2 градуса, то просто информейшен — ничего не происходит
2. если на 10 — уже ворнинг, можно просыпаться
3. дальше алерт с вызовом пожарных :)
Я вцелом говорю, о системном мониторинге — когда много данных различного порядка (не только температуры).
Это проще, когда есть четко-определенные отделы, которые сами для себя определяют пороги алертов. Когда людей не сотни, и обязанности перекликаются между друг другом возникает сложность в том, кто должен получить алерт и о чем, а также какой порог срабатывания.
Если конкретно — сейчас вот, например, прошивка на RAID контроллере устарела по мнению контроллера, как расценивать эту ошибку?
Для меня мониторинг — это не только настройка самого мониторинга, но и глубокий анализ деятельности админов/девелоперов/бизнес-отдела, для того чтобы их жизнь была не алертовым адом (и, как результат, фильтрами всех писем от zabbix/nagios в папку «alerts»), а реальной системой, когда смс/email от сервера мониторинга означает «Нужно бежать и чинить».
Спасибо за статью, очень здорово! Особенно понравилось как Вы «бочку» использовали в качестве корпуса :)
Это проще, когда есть четко-определенные отделы, которые сами для себя определяют пороги алертов. Когда людей не сотни, и обязанности перекликаются между друг другом возникает сложность в том, кто должен получить алерт и о чем, а также какой порог срабатывания.
Если конкретно — сейчас вот, например, прошивка на RAID контроллере устарела по мнению контроллера, как расценивать эту ошибку?
Для меня мониторинг — это не только настройка самого мониторинга, но и глубокий анализ деятельности админов/девелоперов/бизнес-отдела, для того чтобы их жизнь была не алертовым адом (и, как результат, фильтрами всех писем от zabbix/nagios в папку «alerts»), а реальной системой, когда смс/email от сервера мониторинга означает «Нужно бежать и чинить».
Спасибо за статью, очень здорово! Особенно понравилось как Вы «бочку» использовали в качестве корпуса :)
> Если конкретно — сейчас вот, например, прошивка на RAID контроллере устарела по мнению контроллера, как расценивать эту ошибку?
А это ошибка или ворнинг?
Все триггеры расцениваются наверно, не от класса критичности, а порожденными экшенами, то есть «чего делать то»:
1. Если в системе возникло событие никак не влияющую на систему, то есть в рамках допустимых значений НОРМЫ системы, норма ессно высчитывается, то есть это некое отклонение от среднего нормы, то это информация, то есть потом мы будем знать при анализе когда система начала выходить из нормального состояния. ДЕЛАТЬ НИЧЕГО НЕ НАДО.
2. Возникает единожды или уже периодически выход за диапазон НОРМЫ процесса, тут информационное, но рекомендующую уже проанализировать систему, либо что-то сделать чтобы вернуть процесс в диапозон нормы, либо раздвинуть диапазон НОРМЫ, так как после анализа, может оказаться, что условия системы изменились.
Здесь без человеческого анализа «лучшее враг хорошего» скорее никак.
3. Ну и третий — это хоть единственное срабатывание, в диапазоне, в котором мы точно понимаем, что это экстренная ситуация
Ваш случай, это подплан номера 2, если система работает, с такой же стабильностью как и прежде, но есть вариант возможного улучшения, то тут человеческий анализ, либо обновить прошивку и считать чувствительность триггера нормальной, либо внести это событие внутрь нормы процесса и триггер реагировать его не будет.
Вы меня простите тут за ночные умствования, развлекаюсь :)
Я рад, что оказалась статья полезной.
Использовать «бочку» не моя идея, а кто создавал прототип, в котором было только 15 датчиков для теста и для графиков использовался какой-то ужас от digitemp :)
А это ошибка или ворнинг?
Все триггеры расцениваются наверно, не от класса критичности, а порожденными экшенами, то есть «чего делать то»:
1. Если в системе возникло событие никак не влияющую на систему, то есть в рамках допустимых значений НОРМЫ системы, норма ессно высчитывается, то есть это некое отклонение от среднего нормы, то это информация, то есть потом мы будем знать при анализе когда система начала выходить из нормального состояния. ДЕЛАТЬ НИЧЕГО НЕ НАДО.
2. Возникает единожды или уже периодически выход за диапазон НОРМЫ процесса, тут информационное, но рекомендующую уже проанализировать систему, либо что-то сделать чтобы вернуть процесс в диапозон нормы, либо раздвинуть диапазон НОРМЫ, так как после анализа, может оказаться, что условия системы изменились.
Здесь без человеческого анализа «лучшее враг хорошего» скорее никак.
3. Ну и третий — это хоть единственное срабатывание, в диапазоне, в котором мы точно понимаем, что это экстренная ситуация
Ваш случай, это подплан номера 2, если система работает, с такой же стабильностью как и прежде, но есть вариант возможного улучшения, то тут человеческий анализ, либо обновить прошивку и считать чувствительность триггера нормальной, либо внести это событие внутрь нормы процесса и триггер реагировать его не будет.
Вы меня простите тут за ночные умствования, развлекаюсь :)
Я рад, что оказалась статья полезной.
Использовать «бочку» не моя идея, а кто создавал прототип, в котором было только 15 датчиков для теста и для графиков использовался какой-то ужас от digitemp :)
Сейчас это ворнинг, Вы все верно говорите, как раз в подпланах номера 2 кроется проблема, где нужно делать анализ. Но беда в том, что этих ворнингов накапливается столько, что психологически для админов они перестают быть ворнингами, и становятся нормой, что не есть хорошо, а анализ делать… Ну кто его сделает кроме меня? :)
Выходит что при текущей загруженности моих человекочасов нужно попросту отключать ненужные проверки, до тех пор пока не возникнет потребность их мониторить…
Выходит что при текущей загруженности моих человекочасов нужно попросту отключать ненужные проверки, до тех пор пока не возникнет потребность их мониторить…
Ну да пока приходиться мерится, что пока нет:
Tony Stark: Any military victims?
Jarvis: Not according to public records, sir.
Tony Stark: Bring up the thermogenic signatures again, factor in three thousand degrees.
Jarvis: The oracle cloud has completed analysis. Accessing satellites and plotting the last twelve months of thermogenic occurrence now.
)))
Tony Stark: Any military victims?
Jarvis: Not according to public records, sir.
Tony Stark: Bring up the thermogenic signatures again, factor in three thousand degrees.
Jarvis: The oracle cloud has completed analysis. Accessing satellites and plotting the last twelve months of thermogenic occurrence now.
)))
Может быть надо было запараллелить провода?
Где? Для чего?
Я не очень хорошо понимаю электронику, поэтому называется «как шмогли» :)
Я не очень хорошо понимаю электронику, поэтому называется «как шмогли» :)
Запаралелить провода питания. 3 земли, 3 питания, 2 данных.
Так они же и так параллельно подключены, использование нескольких проводов не сильно повлияет, ведь длина то останется. Тут если есть проблема с питанием проще источник питания на половину сети отдельный воткнуть ( с общей землей).
Не. Проще посмотреть как народ делает длинные сети, а не придумывать свой велосипед.
Обычно около мастера сети ставится блок питания на 12-18В, а в каждом датчике собирается схемка из нескольких деталей с линейным стабилизатором типа 78L05 или LP2950. Стоимость каждого датчика рублей на 15-20 от силы возрастает, но никаких проблем со стабильностью не будет.
Обычно около мастера сети ставится блок питания на 12-18В, а в каждом датчике собирается схемка из нескольких деталей с линейным стабилизатором типа 78L05 или LP2950. Стоимость каждого датчика рублей на 15-20 от силы возрастает, но никаких проблем со стабильностью не будет.
А зачем вы включение с паразитным питанием импользуете? Трехпроводная схема стабильнее работает.
С паразитным? Стабилизатор около каждого датчика как раз для нормального питания нужен.
Только сейчас обратил внимание, что у автора на первой картинке схема с паразитным питанием. Сурово для 128 датчиков, с учетом того, что одновременно из всей сети при таком включении можно опрашивать только один датчик.
Только сейчас обратил внимание, что у автора на первой картинке схема с паразитным питанием. Сурово для 128 датчиков, с учетом того, что одновременно из всей сети при таком включении можно опрашивать только один датчик.
Про глюки на длинных сетях смотрим: Сайт DigiTemp. А именно Long Wire runs (glitches).
Да и на коротких сетях не повредит в конце линии поставить такое. Избавит от появления барабашек в сети :)
Да и на коротких сетях не повредит в конце линии поставить такое. Избавит от появления барабашек в сети :)
О, спасибо!
Так и думал, что есть какая-то «нашлепка», но в электронике не бум, так что usb-хаб c питанием спас, а то было мучение с барабашками :)
Так и думал, что есть какая-то «нашлепка», но в электронике не бум, так что usb-хаб c питанием спас, а то было мучение с барабашками :)
А не подскажите как подключить диод Шоттки, когда DS18B20 подключают к GPIO Raspberry Pi? У ds18b20 3 контакта, а у Шоттки всего 2. Подключаю DS18B20 последовательно с помощью переходника RJ45 на RJ45, как у автора, но использую 3 жилы витой пары. Вот и не могу понять какие контакты DS18B20 через Шоттки пускать… Кажется DATA + GND (данные + земля)?..
Никак не могу понять как у гугла об этом спросить…
Заранее спасибо!
Никак не могу понять как у гугла об этом спросить…
Заранее спасибо!
Глюки при паразитном питании бывают часто, поэтому необходим накопитель у каждого датчика. Вот например, проверенная схема, работающая стабильно. SR560 конечно излишен (установил то, что было), достаточно менее мощного диода Шоттки.
а зачем RG45?
переходники RG11-RG11 есть, провода дешевле в три раза. не проще ли было собрать эту схему по телефонному кабелю, или есть какой-то ньюанс?
переходники RG11-RG11 есть, провода дешевле в три раза. не проще ли было собрать эту схему по телефонному кабелю, или есть какой-то ньюанс?
Для 1wire под linux лучше использовать owfs.
Более продвинутая штука, чем digitemp. И проблема с несколькими подсетями решилась бы.
Более продвинутая штука, чем digitemp. И проблема с несколькими подсетями решилась бы.
3 дня назад домой поставил датчик температуры ds1821 (с программируемым термостатом) к котлу, не понравились механические.
По поводу ds18b20 — хороший дешёвый вариант. Около 3$ за штуку.
По поводу ds18b20 — хороший дешёвый вариант. Около 3$ за штуку.
Нечто подобное мы делали в теплицах с узбекскими колхозниками. Но кроме мониторинга было еще управляющее воздействие: когда температура или влажность выходили за допустимые границы, звенел звонок, узбекские дежурные бежали и проверяли параметры по приборам (термометр) и либо открывали форточку на потолке, дергая за веревку, либо запускали «турбину». а еще мы разрабатывали приложение для смартфона для управления рабочими, но этот проект провалился, т.к. сотрудники не поддавались обучению и потеряли все смартфоны.
> но этот проект провалился, т.к. сотрудники не поддавались обучению и потеряли все смартфоны.
я лежу :))))
вы учить не умеете вы их на стажировку в KFC или Burger King отправили им там быстро IQ подняли :)
А зачем рабочий в этой схеме, то есть не понятно зачем ему вообще бежать проверять термометр, если у оператора есть это на графике, а к турбине нельзя прикрутить какой нить юнипинг с розеткой, а к форточке шаговый двигатель, тогда можно было бы и уровень открытия регулировать :)
я лежу :))))
вы учить не умеете вы их на стажировку в KFC или Burger King отправили им там быстро IQ подняли :)
А зачем рабочий в этой схеме, то есть не понятно зачем ему вообще бежать проверять термометр, если у оператора есть это на графике, а к турбине нельзя прикрутить какой нить юнипинг с розеткой, а к форточке шаговый двигатель, тогда можно было бы и уровень открытия регулировать :)
Там общий уровень развития колхозников очень низкий. Раз в неделю приезжал хозяин теплицы и объяснял своим колхозникам как не надо работать. выглядело это как в сериале с Джамшутом и Равшаном. Колхозники плохо изъяснялись по русский, и кроме как колхозниками они никем быть не могли.
Что касается автоматики — то с этим было очень сложно. Дело в том, что теплицы были одноразовыми: представьте теплицу в километр длиной и метров 400 шириной, которая сделана из брусков и обтянута полиэтиленом. строиться такая теплица на один сезон. в потолке деревянные форточки с веревкой, для открывания/закрывания. поскольку площадь теплиц большая (17Га), то автоматических форточек нужно очень много, а это довольно дорого, а ставить несколько штук никакого смысла нет. с термогенераторами примерно такая же штука — проще узбекскому колхознику подбежать, открыть вентиль и чиркнуть зажигалкой, чтобы ее запустить, чем какую-то сложную автоматизацию придумывать.
А вот мониторинг — просто спасение, поскольку колхозники сами ничего делать не будут, пока их не напнешь. вот такая история.
Что касается автоматики — то с этим было очень сложно. Дело в том, что теплицы были одноразовыми: представьте теплицу в километр длиной и метров 400 шириной, которая сделана из брусков и обтянута полиэтиленом. строиться такая теплица на один сезон. в потолке деревянные форточки с веревкой, для открывания/закрывания. поскольку площадь теплиц большая (17Га), то автоматических форточек нужно очень много, а это довольно дорого, а ставить несколько штук никакого смысла нет. с термогенераторами примерно такая же штука — проще узбекскому колхознику подбежать, открыть вентиль и чиркнуть зажигалкой, чтобы ее запустить, чем какую-то сложную автоматизацию придумывать.
А вот мониторинг — просто спасение, поскольку колхозники сами ничего делать не будут, пока их не напнешь. вот такая история.
Я еще помню с этим клиентом такую историю: мы отправили аналитика, для того, чтобы он проанализировал проблемы и предложил ИТ решения. вернулся аналитики и рассказывает, какие он услышал проблемы:
— комбайнер залил мало солярки и уехал в поле, там солярка у него кончилась, пришлось отправлять туда на лошади мужика с соляркой
или
— в прошлом году выписали рабочих из Узбекистана, а среди них попалась проститутка, так у нас почти все 120 рабочих сифилисом заболели и мы остались без рабочих
и все в том же духе.
— комбайнер залил мало солярки и уехал в поле, там солярка у него кончилась, пришлось отправлять туда на лошади мужика с соляркой
или
— в прошлом году выписали рабочих из Узбекистана, а среди них попалась проститутка, так у нас почти все 120 рабочих сифилисом заболели и мы остались без рабочих
и все в том же духе.
Можете доработать свой протокол для отправки показаний в облачное хранилище показаний для публичного и/или приватного доступа для дальнейшего доступа через API?
Для собственных нужд Вы смотрю также использовали digitemp, принципиально ли оно отличается от бюджетного беспроводного wifi подключения датчиков описанного здесь?
Для собственных нужд Вы смотрю также использовали digitemp, принципиально ли оно отличается от бюджетного беспроводного wifi подключения датчиков описанного здесь?
Я практически ничего не понял, что Вы хотите?
Какой протокол? Зачем Вам нужна температура какого-то ЦОД :)?
Какой протокол? Зачем Вам нужна температура какого-то ЦОД :)?
Различные виды протоколов передачи показаний тут.
Интересны дополнительные способы решения задач мониторинга, кроме тех что уже описаны и в проекте и на Хабре неоднократно.
Температура в ЦОД лишь 1 из многих способов ее применения в приватном доступе для дальнейшего мониторинга к примеру с Android.
Интересны дополнительные способы решения задач мониторинга, кроме тех что уже описаны и в проекте и на Хабре неоднократно.
Температура в ЦОД лишь 1 из многих способов ее применения в приватном доступе для дальнейшего мониторинга к примеру с Android.
Простите, спустя 7 лет ссылка поменялась на описание протоколов передачи показаний:
narodmon.ru/#devdoc
narodmon.ru/#devdoc
Sign up to leave a comment.
Мониторинг температуры гермозоны с помощью 1-wire датчиков и Zabbix 2