Дмрв проверка: Проверка ДМРВ (датчика массового расхода воздуха): мультиметром, визуально

Содержание

Как проверить дмрв

Автор admin На чтение 5 мин. Просмотров 199

Режим работы ДВС определяется многими факторами – нагрузкой на двигатель, состоянием дороги, загрузкой машины и т.д. Мотору для работы в оптимальных условиях требуется строго определенное соотношение бензина и воздуха. Количество последнего определяется ДМРВ (датчиком массового расхода воздуха), именно под него контроллер управления двигателем рассчитывает, сколько надо бензина. Неисправность датчика нарушает работу мотора, и зачастую возникает проблема, как проверить ДМРВ, чтобы установить окончательный диагноз.

Неисправность ДМРВ, симптомы

О том, что нужна проверка ДМРВ, можно определить по внешним признакам работы двигателя. Симптомы, говорящие о том, что как минимум работоспособность датчика массового расхода воздуха нуждается в проверке, следующие:

появляется на панели приборов транспарант Check Engine;

увеличивается расход бензина;
пропадает динамика при движении автомобиля, машина «тупит»;
не заводится горячий двигатель;
теряется мощность мотора.

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

Чем могут быть вызваны неисправности датчика массового расхода воздуха

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

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

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

Как определить неисправность ДМРВ

Проверка ДМРВ, позволяющая определить его неисправность, может быть выполнена несколькими различными способами.

Надо выполнить отключение датчика от бортовой системы автомобиля, для чего достаточно отстыковать его разъем, как показано на фото. В этом случае контроллер управления двигателем начинает работать в аварийном режиме, при котором определяющим становится положение дроссельной заслонки, а не количество воздуха. Обороты двигателя становятся больше полутора тысяч. После этого можно немного проехать. Если автомобиль стал более резвым, то вполне возможно, что нужна замена ДМРВ.
Использование заведомо исправного датчика, например, взятого у друга или на СТО для проверки, если конечно, такое возможно. Он устанавливается вместо штатного. Когда такая проверка дает положительный результат и автомобиль ведет себя гораздо лучше, то однозначно нужна замена ДМРВ или, как минимум, промывка и чистка датчика.
Проведение визуального осмотра. Для этого снимают ДМРВ и проводят его визуальный осмотр, в первую очередь – внутренних поверхностей и воздуховода. Они должны быть чистыми и сухими, на них не должно быть никаких следов конденсата и масла. При наличии его следов, необходима, как минимум, чистка ДМРВ, после чего датчик может заработать правильно. Ну и надо устранить причины попадания масла.

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

Для этого на панели управления мультиметром задается измерение постоянного напряжения на пределе два вольта. В разъеме датчика надо подключиться к желтому и зеленому проводам. Это будут первый и третий контакты разъема (со стороны лобового стекла). Цвета проводов могут быть и другие, но нумерация контактов будет та же самая.

Включается зажигание, но двигатель не заводится, и проверяются показания ДМРВ. У нового датчика напряжение составляет (0,996-1.01)В. Чем больше его величина, тем хуже состояние ДМРВ. Превышение напряжением величины (1,03-1,04)В свидетельствует о том, что датчик находится в предсмертном состоянии, а напряжение больше 1,05В о том, что ДМРВ пора выбросить и поставить новый.

На видео подробно показано, как проверить датчик. Необходимо отметить, что в некоторых моделях бортовой компьютер выдает напряжение на его выходе.

Чистка датчика массового расхода воздуха

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

Скорее всего, все определяется конструктивными особенностями датчика и правильным выполнением работ. Во всяком случае, когда проводится чистка, нельзя применять:

эфиры;
сжатый воздух;
ватные палочки;
ацетон.

Опять же, по разным отзывам, для этих целей используется жидкость для очистки карбюраторов или WD 40. Как проводится чистка, показано на видео

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

Мне нравится1Не нравится

Что еще стоит почитать

ДМРВ ВАЗ 2114: Проверка, Признаки неисправности, Цена

Вступление

Все автомобили с инжектором обладают некоторым количеством разных датчиков, которые необходимы для бесперебойной и надежной работы двигателя. ВАЗ 2114 не является исключением и так же использует много датчиков в своей системе. Выход одного из датчиков чреват проблемами с двигателем и приводит к его неравномерной работе.

В данной статье подробно рассказывается об одном из датчиков ВАЗ 2114, а именно о ДМРВ. Изучив данную статью, Вы с легкостью определите его неисправность по признакам, а так же сумеете проверить датчик на работоспособность.

Для чего нужен ДМРВ

Датчик массового расхода воздуха предназначен для подсчета воздуха подаваемого в двигатель через впускной коллектор. Воздух смешивается с топливом, образуя топливную смесь, для образования ТС правильной концентрации и смешивании топлива с воздуха в правильных пропорциях и предназначен ДМРВ.

Без ДМРВ или с его отключенным разъемом, двигатель перейдет в аварийный режим работы, о чем будет сигнализировать лампа «checkengine», так же на автомобиле увеличится расход топлива, и пропадут обороты холостого хода. Одним словом двигатель будет работать некорректно.

Из чего состоит

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

Элементы датчика:

Корпус;
Чувствительный элемент;
Сетка;

Признаки неисправности

ДМРВ, как и все датчики при выходе из строя влечет за собой перебои в двигателе характерные его поломке. По данным признакам можно предположить, что неисправен ДМРВ и приступить к его проверке.

Признаки:

Нестабильный холостой ход;
Самопроизвольная остановка двигателя;
Повышенный расход;
Потеря мощности;

Стоимость

Ниже указана таблица со стоимостью датчика ДМРВ на ВАЗ 2114.

Проверка

Лучшая проверка датчика это подключение заведомо исправного от другой машины или нового. Но следует обратить внимание на номер датчика, при покупке или замене номер обязательно должен совпадать в противном случае корректная работа датчика не гарантируется.

Еще проверку можно осуществить с помощью мультиметра, но только на двигателях, в которых не используется система Е-ГАЗ. В двигателях с электронной педалью газа используется специальный частотный датчик, который довольно надежный и не поддается проверке мультиметром. Частотный датчик можно проверить с помощью диагностики через китайский прибор ЕЛМ-327 по каналам АЦП.

Итак, приступаем к проверке датчика с механической педалью газа.

Проверка цепи питания

Сначала необходимо проверить цепь питания. Для этого:

Вынимаем разъем с датчика

Включаем зажигание на автомобиле

Переводим переключатель мультиметра в режим измерения постоянного напряжения пределом в 20В.

Один из щупов мультиметра подключаем к корпусу двигателя, а другой к выводу разъема №2 (на колодке разъема имеется нумерация). Прибор должен показать наличие напряжения не менее 12В.

Затем переставляем щуп с контакта №2, на контакт №4. Прибор должен показать наличие напряжение не менее 5В.

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

Проверка датчика

Проверку ДМРВ необходимо осуществлять с включенным зажиганием и подключенным разъемом.

Для проведения диагностики потребуется иголки от шприца или булавки.

Выставляем на приборе переключатель на измерение постоянного напряжения в пределе до 2000мВ (2В).

Иголки или булавки вставляем в разъем, а именно в 1 и 3 провод (как показано на картинке) и проводим замер между двумя этими контактами. Полученные данные сравниваем с таблицей состояния датчика.

Таблица состояния датчика

Напряжение, (В)	Состояние
0,99…1,01	Идеальное состояние датчика
1,01…1,02	Хорошее состояние датчика
1,02…1,03	Удовлетворительное состояние датчика
1,03…1,04	Датчик на грани, скоро потребуется замена
1,04…1,05	Датчик находится практически в нерабочем состоянии
1,05… и выше	Неисправный датчик, нужна замена

Исходя из этих данных можно сделать вывод о работе датчика.

Замена

Замену датчика провести довольно просто, никаких усилий или сложностей данная работа не вызовет. Для работы понадобиться:

Рожковый ключ на 10мм;
Отвертка «+»

Пошаговый процесс замены

Отключаем минусовую клейму АКБ;

Отключаем разъем с датчика;

Откручиваем хомут крепления гофры к датчику;

Откручиваем два болта крепящих ДМРВ к корпусу фильтра;

Вынимаем датчик и устанавливаем новый в обратной последовательности;

Надеемся, наша статья была Вам полезна.

← Датчики ВАЗ 2115 Холодная печка Лада Калина →

Как проверить датчик массового расхода воздуха: признаки неисправности

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

1 ДМРВ – принцип работы

Работа топливной системы заключается в том, чтобы воздух и бензин поступали в мотор через клапаны в определенном соотношении. Качественное регулирование невозможно без непрерывного и точного измерения объема воздуха.

Датчики массового расхода воздуха бывают разных типов, самыми распространенным из которых являются проволочный и пленочный. Метод измерения такими датчиками основан на том, что сопротивление металлов зависит от их температуры. Чувствительным элементом ДМРВ является платиновая проволока, через которую проходит поток воздуха. Она включена в мост сопротивлений, который всегда должен оставаться в равновесии.

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

Значение напряжения используется в качестве информации электронным блоком управления. Иногда ДМРВ дополняется датчиком температуры входящего воздуха. В таком случае измерение количества воздуха становится еще точнее, так как в расчет берется его плотность.

2 Поломки расходомеров – из-за чего они бывают

Иногда расходомеры выходят из строя. Основных причин поломки всего три:

Загрязнение чувствительного элемента. В потоке воздуха, который проходит через измерительный прибор, могут содержаться различные частицы. Они налипают на проволоку и чувствительность оборудования уменьшается. Проволока нагревается сильнее и в результате этого со временем перегорает.
Механическое повреждение. Чаще всего оно является результатом попытки почистить ДМРВ.
Выработка ресурса. Со временем характеристики измерительного прибора теряются, и определение объема воздуха становится неточным. Это естественное явление для всех измерительных приборов.

3 Признаки неисправности ДМРВ

Последствием поломки датчика расхода являются не присущие нормальной работе автомобиля симптомы:

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

Указанные признаки не на 100% указывают на неисправность ДМРВ. Возможно, причина необычного поведения автомобиля совершенно в другом. Поэтому прежде чем менять расходомер на новый, следует его проверить.

4 Как проверить работоспособность расходомера

Самый простой способ проверить ДМРВ – провести диагностику автомобиля при помощи сканера. Такого устройства у большинства автовладельцев нет, так как его покупка нецелесообразна. Для диагностики ДМРВ без сканера понадобятся:

мультиметр;
электрическая схема ДМРВ;
разъем с проводами.

Алгоритм проверки датчика следующий:

Остоединить разъем от ДМРВ.
Повернуть ключ зажигания в положение ACC.
Проверить на разъеме расходомера, поступает ли питание. Если нет, то следует искать причину в проводке. Если же напряжение есть, то перейти к следующему шагу.
Подключить запасной разъем с проводами.
Подать питание туда, где оно должно быть.
Измерить выходной сигнал с соответствующих проводов согласно схеме. Он должен быть минимального значения в соответствии с градуировкой. Если он отсутствует или выше чем нужно, то датчик неисправен. Если все нормально, то перейти к следующей проверке.
Отсоединить патрубок от дроссельной заслонки.
Завести машину.
Проконтролировать выходной сигнал при холостых оборотах. Если наблюдаются скачки, то ДМРВ подлежит замене.

Проверить точность измерений в обычных условиях невозможно. Делается это только в лаборатории на специальном оборудовании.

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

Как уже говорилось, самой частой причиной поломкой ДМРВ является загрязнение. Пыль попадает на чувствительный элемент, если воздушный фильтр не способен ее удержать. Фильтрующий элемент нужно менять не реже, чем рекомендовано инструкцией по эксплуатации. Если ваш маршрут часто пролегает по сильно запыленной местности, то фильтр нужно менять чаще.

5 Датчик массового расхода воздуха неисправен – что делать?

Неисправный ДМРВ подлежит замене, так как ремонту он не подлежит. Новые расходомеры для современных автомобилей купить не проблема. Цена ДМРВ для моделей ВАЗ, таких как Лада Приора, Лада Калина, Газелей и других отечественных авто относительно невысокая. Сложнее с автомобилями импортного производства.

Например, для Опель Астра, Форд Фокус, Фольксваген Гольф и других оригинальные расходомеры очень дорогие. Большинство автопроизводителей не выпускают ДМРВ. Для них это делают другие компании, такие как Bosch, Siemens, Denso и другие. Поэтому по оригинальному артикулу можно подобрать замену от конвейерного поставщика. К сожалению, даже в этом случае датчики не всегда бывают по приятной цене. Тогда на помощь приходят запчасти, бывшие в использовании.

Проверка датчика массового расхода воздуха занимает не более 10 минут. И если все сделать правильно, то достоверно можно определить его состояние.

Как проверить дмрв на ваз-2110 мультиметром: инструкция с видео

Для чего нужен ДМРВ?

Как известно инжекторные ВАЗ напичканы всевозможными датчиками. Одним из которых является датчик массового расхода воздуха. Как всем известно двигатель работает за счет сгорания в нем топливно-воздушной смеси. И от того насколько эта горючая смесь смешена правильно зависит стабильная работа двигателя.

Так вот для правильного смешивания и был придуман ДМРВ, по народному расходомер. Поломка данного датчика может привести к возрастанию расхода бензина, не стабильной работе двигателя, проблемам при запуске мотора и другими не очень приятными вещами.

ДМРВ используя термоанемометр и используя некоторые алгоритмы высчитывает и следит за массой воздуха, который поступает в цилиндры.

Возможные неполадки при выходе из строя ДМРВ

Начинают плавать холостые обороты двигателя
Происходят некоторые сбои работы двигателя
Ухудшается динамика ВАЗика
Запуск двигателя происходит с проблемами
Возрастает расход топлива

Для того, чтобы провести проверку работоспособности этого датчика нужно сделать несколько действий.

Диагностика неисправностей ДМРВ

Для этого вам потребуется мультиметр. Выставляем на нем 20 В.

На этом этапе советую обзавестись двумя булавками. С помощью их будет удобней измерить данные. Одну вставляем в желтое отверстие, другую – в зеленое. И теперь провода мультиметра подкидываем к булавкам.

Включаем зажигание и смотрим на показания мультиметра. У меня он показал 1,05. Рабочий ДМРВ показывает 0,99-1,00.

Как заменить датчик массового расхода воздуха ВАЗ?

Процесс замены датчика прост как «2*2»:

Глушим двигатель.
Отсоединяем колодку от ДМРВ.
Открутив винты хомутов, выньте шланг выпускной трубы из корпуса воздушного фильтра.
Снимаем датчик.
Ставим новый в обратном порядке.

Когда вы произвели замену датчика массового расхода воздуха, то все перечисленные проблемы должны исчезнуть, надеюсь у вас так и произошло. Для наглядности проверки ДМРВ смотрите видеоролик:

Источник: http://vaz2110-remont.ru/kak-proverit-i-zamenit-dmrv.html

Как продиагностировать ДМРВ ВАЗ 2110 и выполнить его замену

Диагностика неисправностей ДМРВ ВАЗ 2110 и его замена

Стабильная работа двигателя полностью зависит от правильного состава горючей смеси.

Соотношение компонентов топливно-воздушной смеси должно быть оптимальным, для достижения этого эффекта был изобретен ДМРВ (датчик массового расхода топлива, расходомер).

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

Как диагностировать неисправность ДМРВ

самопроизвольно повышаются или понижаются плавающие холостые обороты;
случаются перебои в работе двигателя;
существенно ухудшается динамика;
двигатель плохо запускается или не запускается вообще;
происходит перерасход топлива.

Для подтверждения или опровержения факта выхода из строя ДМРВ следует сделать мультиметром несколько простых тестов.

Самостоятельный анализ неполадок ДМРВ

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

Диагностика неисправностей ДМРВ ВАЗ 2110 и его замена

Чтоб было удобнее, стоит воспользоваться двумя булавками. Их нужно поставить в отверстия желтого и зеленого проводов ДМРВ, подсоединить к ним электроды мультиметра.

Диагностика неисправностей ДМРВ ВАЗ 2110 и его замена

Затем включаем зажигание, после чего измеряем напряжение с помощью мультиметра. В представленном нами примере показатель был равен 1,05. Необходимо знать, что на рабочем ДМРВ указанное значение должно быть в районе 0,99-1,00.

Как заменить ДМРВ в домашних условиях

Заглушить мотор, отключить зажигание.
Отключить разъем датчика.
Отсоединить шланг выпускной трубы, который подключен к корпусу воздушного фильтра (чтобы это сделать, нужно открутить крепежные винты хомутов).
Провести замену неисправного датчика массового расхода топлива.
Произвести сборку в обратном порядке.

Диагностика неисправностей ДМРВ ВАЗ 2110 и его замена

Также ознакомьтесь

Диагностика неисправностей ДМРВ ВАЗ 2110 и его замена

Если после замены ДМРВ ВАЗ 2110 никаких улучшений не произошло, необходимо осуществить более детальную диагностику или обратиться в СТО.

Проверка ДМРВ ВАЗ 2110 на видео:

Стоит ознакомиться:

Источник: https://prostovaz.ru/vaz-2110/kak-prodiagnostirovat-dmrv-vaz-2110-i-vypolnit-ego-zamenu.html

Основные принципы ремонта, замены и обслуживания ДМРВ на ВАЗ 2110

Оптимальная работа силового агрегата в «Десятке» зависит от многих параметров и характеристик, в частности, от качества топливовоздушной смеси.

Для отслеживания правильного отношения при формировании горючей смеси используется в ВАЗ 2110 ДМРВ — датчик массового расхода воздуха.

Подробнее о том, что это за устройство, как произвести его диагностику и замену, вы сможете узнать из этого материала.

Что такое ДМРВ и в чем заключается его принцип действия? Сразу же скажем — путать датчик массового расхода воздуха с контроллером температуры наружного воздуха нельзя, поскольку это два совершенно разных устройства.

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

Сам ДМРВ в «Десятке» располагается за воздушным фильтрующим элементом.

Чтобы двигатель работал в нормальном режиме, при формировании горючей смеси должны четко соблюдаться соотношения веществ — 1:14.

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

Данные о подсчете объема воздушного потока, поступившего в двигатель, поступают на электронный блок управления. В соответствии с полученными данными, ЭБУ вычисляет необходимый объем топлива.

Когда водитель жмет на педаль газа, значительно возрастает объем подающегося воздушного потока, соответственно, это приводит к увеличению расхода бензина.

В том случае, если транспортное средство передвигается равномерно, то порции горючего и воздушного потока, которые попадают в цилиндры, также будут одинаковыми на каждом цикле.

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

Возможные неисправности и способы их устранения

Теперь рассмотрим основные признаки неисправности, которые позволят определить поломку расходомера:

Повышенный расход бензина. В данном случае неполадку можно выявить по показаниям бортового компьютера, если последний вычисляет объем топлива. Если ДМРВ ломается, то расход бензина может возрасти на один литр или больше.
Понижение мощности двигателя по время работы.
Мотор автомобиля стал работать менее стабильно. Машине требуется больше времени для разгона, а иногда двигатель нехарактерно быстро набирает скорость.
Силовой агрегат «Десятки» не запускается либо запускается, но не сразу, через несколько попыток.
Плавающие холостые обороты.

Разумеется, таким симптомы неполадок могут быть связаны и с другими неисправностями, к примеру, свечей, трамблера и других компонентов системы зажигания. Поэтому для того, чтобы точно убедиться в неработоспособности расходомера, придется произвести проверку устройства.

Что касается способов устранения неполадок, то сам ДМРВ обычно не подлежит ремонту, поэтому в большинстве случаев при неполадках в его работе устройство просто меняется.

Бывает такое, что причины обусловлены плохим контактом девайса с бортовой сетью авто, поэтому перед заменой рекомендуем проверить цепь подключения, а также качество контакта устройства с разъемом.

Методы проверки датчика на работоспособность

Как проверить расходомер своими руками? Есть несколько вариантов диагностики, предлагаем ознакомиться с каждым из них (автор видео — канал Бездельник TV).

Отключение

Для начала нужно попробовать отключить расходомер от питания. Чтобы сделать это, нужно завести двигатель и дать ему поработать какое-то время. Далее, от расходомера нужно будет отсоединить штекер — после этого должен активировать аварийный режим работы мотора.

В данном случае расчет объема нужного воздушного потока будет осуществляться в соответствии с положением дроссельной заслонки.

Если после отключения вы заметили, что двигатель стал работать более правильно и при этом он стал более динамичным, то однозначно ДМРВ подлежит замене.

Диагностика с помощью мультиметра

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

Чтобы подключение устройства не вызвало сложностей, необходимо точно знать распиновку девайса:

черно-красный или розовый контакт — это подключение к управляющему модулю;
зеленый — это земля (заземление, масса), подсоединяется к кузову или АКБ;
серо-белый контакт — выходное напряжение;
желтый — используется для подачи тока на вход.

Диагностика мультиметром выполняется так:

Для начала тестер следует включить и установить на нем значение напряжения в 20 вольт, а затем щупы от прибора подсоединяются в соответствующим контактам на штекере.
Чтобы подключение было более удобным, можно использовать булавки, потребуется две штуки. Каждая из них устанавливается в отверстие с зеленым и желтым контактам. Затем к этим булавкам надо будет подключить щупы прибора.
Следующим этапом будет активация зажигания и измерение напряжения. Подробнее о результатах тестирования читайте ниже (автор видео — канал IZO)))LENTA).

На работоспособном девайса уровень напряжения составит в районе 1.01-1.04. Если показания составляют от 1.02 до 1.05 вольт, это говорит о том, что в скором будущем устройство надо будет поменять. Если же полученные показания выше, то расходомер подлежит замене, поскольку он вышел из строя.

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

Визуальный осмотр

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

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

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

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

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

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

Инструкция по замене и установке своими руками

Как произвести замену регулятора в гаражных условиях:

Для начала следует отключить двигатель и зажигание.
Далее, откройте капот и найдите место установки ДМРВ. От регулятора нужно отсоединить штекер с проводкой.
После этого выкрутите болты, которые фиксируют хомуты, и затем отсоедините патрубок впускной магистрали. Эта магистраль подсоединена к корпусу воздушного фильтра.
Выполнив эти действия, необходимо демонтировать расходомер из места установки. Прежде чем произвести монтаж нового ДМРВ, необходимо очистить или промыть место установки. Дальнейшая установка и сборка осуществляется в обратном порядке.

Фотогалерея «Меняем расходомер»

Особенности чистки регулятора

Как почистить регулятор путем промывки? В некоторых случаях очистка действительно помогает продлить срок службы расходомера, этот процесс можно назвать составляющей ремонта. Для очистки можно использовать специализированные средства, предназначенные для конкретно этой цели. Также можно применять и жидкость WD-40 либо средство для очистки карбюратора.

Как промыть расходомер своими руками:

Для начала необходимо демонтировать ДМРВ, подробнее об этом мы рассказали выше.
Когда устройство будет у вас в руках, при помощи очищающего средства нужно будет произвести промывку всех чувствительных компонентов регулятора. В частности, речь идет о проволочной сетке, термосенсоре, а также контактах. При очистке будете максимально внимательны и регулярно следите за уровнем давления струи из баллона. Учтите, что сама струя не должна быть слишком сильной, лучше всего держать баллон на расстоянии примерно 5-10 см от устройства.
Подождите несколько минут, после чего нанесите очистительное средство еще раз, опять немного подождите. Процедура очистки должна осуществляться несколько раз, но как показывает практика, обычно трех раз вполне достаточно для того, чтобы получить необходимый результат.
Затем, в медицинский шприц необходимо залить дистиллят со спиртом (найти можно в любой аптеке). При помощи шприца обработайте все чувствительные компоненты устройства, а также контакты, это позволит их тщательно очистить.

Заключение

Поломка ДМРВ может стать причиной серьезных неполадок в работе автомобильного двигателя. Поэтому каждый автовладелец должен следить за работоспособностью и помнить о сроке службы расходомера. Если в работе ДМРВ появляются первые признаки неполадок, можно попробовать промыть устройство, обычно это помогает на ранней стадии загрязнения.

Загрузка …

Видео «Особенности замены расходомера в гаражных условиях»

Как производится процедура замены и какие моменты при выполнении этой задачи следует учитывать — узнайте из ролика ниже (автор — канал В гараже у Сандро).

Источник: https://avtoklema.com/sensors/vaz-2110-dmrv-3297/

Проверка ДМРВ (датчика массового расхода воздуха): мультиметром, визуально

ДМРВ – один из главных элементов систем впрыска современных автомобилей. Благодаря этому датчику бортовой компьютер подаёт топливно-воздушную смесь, двигатель может работать в оптимальном режиме. Поломка датчика приводит к перерасходу топлива, уменьшению мощности «движка».

Что такое ДМРВ?

ДМРВ – датчик, измеряющий массовый расход воздуха Прибор располагается в воздушном патрубке двигателя между воздушным фильтром и дроссельной заслонкой. Благодаря ему бортовой компьютер определяет объем поступающего в цилиндры воздуха, необходимого для полного сжигания топлива и нормальной работы автомобиля.

Прибор обеспечен чувствительным элементом, состоящим из 2 платиновых нитей диаметром 70 мкм. Одна из них охлаждается проходящим воздухом, а другая является контрольной.

При включении зажигания проволока нагревается, посылая в бортовой компьютер сигнал для открытия дроссельной заслонки и охлаждения элемента.

Попутно открываются форсунки, в результате чего формируется нужное количество топлива в заданном режиме работы мотора.

После выключения двигателя проволока нагревается до 1000 градусов. В результате находящиеся на ее поверхности отложения, частицы сажи и пыли, способные повлиять на чувствительность датчика, полностью сгорают.

Есть устаревшие модели ДМРВ, работающие за счет флюгерной заслонки, а также более современные модификации с пленочно-кремниевыми элементами и платиновым напылением.
Симптомы неисправности датчика массового расхода воздуха
Обычно датчик ломается из-за естественного прогорания или загрязнения поверхности проволоки, которые вызываются несвоевременной заменой воздушного фильтра и из-за экстремальной езды. Неисправность датчика можно определить по ряду признаков:

увеличился расход топлива;
двигатель неустойчиво работает на холостых оборотах;
не заводится мотор;
горит «чек» на дисплее бортового компьютера.

Эти симптомы косвенные. Похожие явления возникают при неисправности топливного насоса, заедающей дроссельной заслонке и погнутом клапане ЕГР. Точную причину поломки может показать лишь диагностика измерителя при помощи мотор-тестера, позволяющего построить и оценить осциллограмму до режима отсечки или при включении зажигания.

Как проверить датчик ДМРВ

Проверка ДМРВ не представляет особой сложности и может быть выполнена несколькими способами:

В движении

Считается самым простым, но наименее эффективным способом диагностики датчика. Отсоедините разъем прибора, заведите двигатель и проедьтесь на машине, следя за тем, чтобы обороты двигателя не падали ниже 1500.

При отключенном расходомере воздуха контроллер начинает работать в аварийном режиме, формируя топливную смесь по положению дроссельной заслонки.

Если так автомобиль быстрее набирает скорость, чем с подключенным ДМРВ, значит, прибор вышел из строя.

Мультиметром

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

Цвета проводов могут различаться, но расположение остается неизменным. Напряжение должно варьировать в диапазоне 0.996…1.01 В, но если цифры превышают верхнее значение, значит, агрегат потребует скорой замены. Показания прибора 1,05 В и выше свидетельствуют о высоком выходном напряжении и о том, что датчик не работает.

Более подробная инструкция проверки ДПРВ мультиметром представлена в видео

Визуально

Снимите ДМРВ, открутив хомут на гофрированном трубопроводе воздухозаборника и два винта на корпусе датчика. Извлеките прибор из воздушного фильтра и осмотрите его поверхность – она должна быть чистой, не иметь следов масла и налета пыли. Наличие загрязнений свидетельствует о том, что платиновые нити или пленочный элемент вышли из строя.

Можно ли восстановить датчик массового расхода воздуха?

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

Прежде чем приступить к работе, ДМРВ аккуратно разбирают, стараясь не повредить уплотнительное кольцо.

Если на мембране или проволоке присутствует грязь, поверхность элементов промывают WD-40 или медицинским спиртом.

Отличный вариант – чистый этиловый спирт, который превосходно очищает платиновые элементы от любых загрязнений и быстро испаряется, не оставляя следов на поверхности.

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

При этом нельзя прикасаться к ним руками или инструментом, чтобы не было механических повреждений.

Главное при очистке внутренних частей ДМРВ – не оборвать контакты, закрепленные гелеобразным компаундом. Поэтому в процессе промывки лучше не использовать продувку сжатым воздухом, не протирать ватными тампонами, не чистить ножом.

Большинство органических растворителей, которые изготавливаются на основе ацетона и сложных эфиров, не пригодны для очистки ДМРВ. Такие составы растворяют компаунд, повреждают пленочную мембрану, оставляют маслянистую пленку на поверхности чувствительных элементов агрегата.

Профилактика – эффективное средство для продления срока службы ДМРВ. Своевременно меняйте воздушный фильтр, следите за состоянием форсунок и уровнем масла в двигателе. Тогда этот дорогой прибор прослужит долго без поломок, и вам не придётся тратиться на его восстановление.

Источник: https://ddcar.ru/blog/elektrika/kak-proverit-dmrv-multimetrom

Проверка ДМРВ своими руками Ваз. — logbook Lada 2110 2005 on DRIVE2

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

Другие симптомы неисправности датчика массового расхода воздуха:1)Появление ошибки Check Engine;2)Повышенный расход топлива;3)Плохо заводится на горячую;4)Машина стало медленно разгоняться;5)Пропала мощность двигателя.

6)И т.д.

Как проверить ДМРВСпособ №1: Отключить ДМРВ.

Отсоединяем разъем датчика и заводим двигатель. Если отключить ДМВР, то контроллер переходит на аварийный режим работы и готовит топливную смесь только по положению дроссельной заслонки. Обороты двигателя должны быть больше 1500об/мин.Пробуем прокатиться. Если по ощущениям автомобиль стал «резвее», то можно говорить о том, что ДМРВ не работает.

Кстати, для ЭБУ Я7.2, М7.9.7. обороты при отключении фишки не поднимаются !

Способ №2: Альтернативная прошивка ЭБУ.

Если штатная прошивка контроллера была заменена на другую, тогда неизвестно, что в ней зашито на случай аварийного режима в способе №1. Попробуйте подсунуть под упор заслонки пластину с 1мм толщиной. Обороты поднимутся. Выдерните фишку с ДМРВ. Если не заглохнет — значит дело в прошивке, а точнее с шагами РХХ при аварийном режиме без ДМРВ.

Способ №3: Проверка ДМРВ мультиметром.

Этот метод действует на датчиках Bosch с каталожными номерами: 0 280 218 004, 0 280 218 037, 0 280 218 116.Включаем тестер в режим измерения постоянного напряжения, выставляем предел измерения 2 Вольта.

Распиновка ДМРВ:1)Желтый (ближний по расположению к лобовому стеклу) — вход сигнала ДМРВ;2)Серо-белый — выход напряжения питания датчиков;3)Зеленый — выход заземление датчиков;4)Розово-черный — к главному реле.

Цвета проводов могут меняться, но расположение выводов остается неизменным.Цвета проводов могут меняться, но расположение выводов остается неизменным.

Включаем зажигание, но не заводим двигатель. Подключаем мультиметр красным щупом к желтому ДМРВ, а черным к зеленому (на массу). Таким образом, мы измеряем напряжение между указанными выводами. Щупы тестера позволяют внедриться сквозь резиновые уплотнители разъёма, вдоль указанных проводков, не нарушая их изоляции.

Использовать иголки и прочие дополнительные соединения не рекомендуется, т.к. они вносят некоторую погрешность в измерения. Снимаем показания с мультиметра.Напряжение на выходе нового датчика 0.996…1.01 Вольта. В процессе эксплуатации оно постепенно меняется, и как правило увеличивается. Чем больше значение этого напряжения, тем больше износ ДМРВ.

ДМРВ напряжение:1.01…1.02 — хорошее состояние датчика.1.02…1.03 — не плохое состояние.1.03…1.04 — ресурс ДМРВ подходит к концу.1.04…1.05 — предсмертное состояние, если негативных симптомов нет, то эксплуатируем дальше.

1.05…и выше — пора заменить ДМРВ.

Кстати, эти же показания можно получить и без тестера, используя бортовой компьютер (группа параметров «напряжения с датчиков», Uдмрв)

Источник: https://www.drive2.com/l/6169790

Как проверить ДМРВ на ВАЗ 2110? | КТО?ЧТО?ГДЕ?

От проверки ДМРВ (датчика массового расхода воздуха, в народе — расходомера) зависит исправное функционирование всей двигательной системы.

Способы проверки ДМРВ на автомобиле ВАЗ 2110

ДМРВ является той деталью, которая фиксирует количество воздуха, поступающего в двигательную систему. От исправной работы этой комплектующей может зависеть «здоровье» автомобиля. Как же проверить ДМРВ на ВАЗ 2110? Существует несколько способов, которые помогают обнаружить поломку:

визуальный осмотр
отключение датчика
проверка мультиметром
прошивка ЭБУ.

Визуальный осмотр

Это самый простой способ, который во многих случаях помогает определить не только степень износа детали, но и её способность нормально функционировать.

Датчик должен быть сухим и чистым. Если заметен налет масла или конденсатной жидкости, это значит, что воздушный фильтр требуется менять более часто.

Возможно и наличие пыли на датчике. В случае загрязнения ДМРВ, как и самого гофра, необходимо:

проверить уровень масла в картере
очистить масло-отбойник вентиляции картера, если он забит
проверить наличие резинового кольца-уплотнителя и вернуть его на место, если он не обнаружен.

Отключение датчика

Отключение датчика помогает определить, является ли он причиной неисправности автомобиля. Это будет видно сразу. Отсоединив разъем датчика, необходимо завести двигатель. При

Как проверить ДМРВ?

Датчик массового расхода определяет количество воздуха, поступающего в двигатель. Неисправность DMRM может привести к отказу двигателя, поэтому при небольшом намеке на неисправность проверьте датчик воздуха. Существует 4 метода проверки исправного состояния ДМРВ на автомобиле ВАЗ.

Способ №1. Отключение DRM

Отключить ДМРВ, отключив контакт и включив двигатель. При этом обороты холостого хода превышают 1500 об / мин, так как контроллер переходит в аварийный режим, а поступление топливной смеси регулируется только специальной дроссельной заслонкой;
Проверяем динамику разгона автомобиля, сделав пробный заезд.В случае нарастающей динамики делаем вывод, что DFID не работает.

Метод № 2. Диагностика мультиметра

Выставляем на мультиметре режим постоянного напряжения и предел измерения 2 Вольта;
Проверяем раздачу DFID:
- Желтый (возле лобового стекла) — сигнальный вход ДМРВ;
- Бело-серый — выходное напряжение, датчики питания;
- Зеленый — выходное напряжение датчика;
- Черно-розовый — на главном реле;
Включить зажигание, не запуская двигатель;
Подключив электрод теста с красной стрелкой к желтому ДМРБ, а черный к зеленому, находим напряжение между этими точками цепи.Щупы мультиметра подключаются через резиновые уплотнения, чтобы предотвратить повреждение изоляции. Также важно помнить, что в соединительном контакте недопустимо использовать металлические иглы и другие предметы, так как это вносит существенное отклонение в показания мультиметра. По величине полученного измерения определяем состояние датчика. Чем выше показания счетчика, тем больше изношен датчик:
- с 1.01 до 1.02 — хорошее состояние
- из 1.02 по 1.03 — состояние удовлетворительное
- от 1.03 до 1.04 — предельное состояние датчика
- от 1.05 и выше — датчик неисправен

Метод № 3. Визуальная диагностика

Открутив гофру, осматриваем внутреннюю поверхность датчика и саму гофру на предмет грязи, конденсата и масляных отложений. Их засорение и может быть причиной неработоспособного состояния датчика.
Полностью вынимаем датчик из корпуса фильтра, предварительно открутив 2 винта на его крышке.Проверьте наличие резинового кольца, не пропускающего воздух. Если его сбить с правильного положения, даже небольшой слой пыли на входной решетке датчика может вызвать повышенный износ.

Метод № 4. Прошивка-альтернатива ЭБУ

Этот метод используется в случае «native & q

Dynamic runtime AV checker, который обеспечивает проверки выполнения в различных антивирусных системах и ОС Windows.

Проверка AV во время выполнения

Этот тип сканирования может помочь вам проверить, обнаруживаются ли ваши файлы динамически антивирусными решениями (или решениями для обеспечения безопасности Интернета) при выполнении всеми типами обнаружения.

Тест операционной системы во время выполнения

Этот тип сканирования может помочь вам проверить работоспособность ваших файлов практически на всех настольных версиях ОС Windows.

Интеллектуальные отчеты

Мы делаем все возможное, чтобы отчеты были действительно умными и удобными. Вы сможете увидеть текущий статус типа обнаружения для каждого антивирусного движка и даже увидеть снимок экрана с обнаружением антивируса.

Различные типы файлов

Наш сервис умеет проверять разные типы файлов: * .exe, *.doc, * .docx, * .xls, * .xlsx, * .pdf, * .js, * .jse, * .vbs и * .hta.

Умные уведомления

Наш сервис может отправлять вам уведомления о завершении любого события. Например, уведомления о пополнении счета, окончании проверки или окончании плана.

Проактивное обнаружение и обнаружение памяти

Наш сервис может показать даже обнаружение памяти и проактивное антивирусное обнаружение. Таким образом, вы сможете видеть все предупреждения и предупреждения от поставщиков антивируса во время тестирования ваших файлов.

Регулярные обновления AV

Наша система автоматически заботится об обновлении антивирусных баз. Автоматическое обновление запускается в безопасном режиме и не прерывает текущие проверки.

Прозрачные планы

Не стесняйтесь выбирать ежедневные, еженедельные, ежемесячные, VIP или тарифные планы. Они доступны из личного кабинета. Еженедельные, ежемесячные и VIP-планы имеют дополнительные возможности.

Отличная масштабируемость

Архитектура нашего сервиса позволяет нам добавлять неограниченное количество внутренних серверов.

Полностью автоматические платежи

Вы можете автоматически пополнять свой счет через торговца BTC. Ваш баланс будет автоматически списан после 1 подтверждения сети. Наша система может сообщить вам, когда будет произведена оплата.

Просмотр функциональных скриншотов

Архитектура нашего сервиса позволяет вам также видеть каждый снимок экрана с каждой тестовой машины во время выполнения ваших файлов. Щелкнув один раз на снимке экрана или обнаружив предварительный просмотр в отчете, вы сможете увидеть полноэкранное изображение выбранного снимка экрана.

Сервисные проверки

Сервисные или демонные проверки

Проверки служб или демонов — это системные процессы, которые выполняются в фоновом режиме и обычно запускаются при загрузке системы. В этой статье базы знаний описано несколько различных вариантов использования:

В разделах ниже приведены примеры выполнения этих проверок с использованием различных методов.

Обслуживание — Запущено

Проверьте, запущена ли служба.

Плагины Nagios

Nagios Plugins не включает служебный плагин, однако linux-nrpe-agent предоставляет check_init_service. Плагин возвращает КРИТИЧЕСКОЕ состояние, если служба не запущена.

Команда:

 ./check_init_service crond

Выход:

 crond (pid 1689) работает ...

NCPA

NPCA включает служебный модуль, который может проверить, запущена ли служба.

Команда:

./check_ncpa.py -H 10.25.14.91 -t Str0ngT0k3n -M services -q service = Spooler, status = running

Выход:

 OK: спулер работает

Имейте в виду, что служебный модуль является безопасным, вы можете преодолеть это с помощью аргумента match =.

Команда:

 ./check_ncpa.py -H 10.25.14.91 -t Str0ngT0k3n -M services -q service = spooler, status = running, match = search

Выход:

 OK: спулер работает

NSClient ++ через check_nt

NSClient ++ включает служебный модуль, который может проверять, запущена ли служба.

Команда:

 ./check_nt -H 10.25.14.10 -p 12489 -s 'Str0ngP @ ssw0rd' -v SERVICESTATE -l Spooler -d SHOWALL

Выход:

 Spooler: запущен

NSClient ++ через check_nrpe

NSClient ++ включает служебный модуль, который может проверять, запущена ли служба.

Команда:

 ./check_nrpe -H 10.25.14.10 -c check_service -a service = спулер

Выход:

 OK: Все 1 услуги в порядке.

WMI

Check WMI Plus включает служебный модуль, который может проверить, запущена ли служба.

Команда:

 ./check_wmi_plus.pl -H 10.25.14.3 -u wmiagent -p Str0ngP @ ssw0rd -m checkservice -a 'Spooler' -c _Total = 1: -c 0

Выход:

 OK - найдено 1 услуг, 1 OK и 0 с проблемами (0 исключено). «Диспетчер очереди печати» (диспетчер очереди печати) работает. | «Общее количество служб» = 1; 1; «Счетчик услуг в рабочем состоянии» = 1; «Состояние проблемы счетчика услуг» = 0; 0; «Количество исключенных услуг» = 0;

SNMP

Проверить, работает ли служба с использованием SNMP, непросто, проверка процесса — лучшее решение, см. Статью базы знаний о проверках процессов.

Сервис — остановлен

Проверьте, не остановлена ли служба.

Плагины Nagios

Nagios Plugins не включает служебный плагин, однако linux-nrpe-agent предоставляет check_init_service. Плагин может только проверять, запущена ли служба, однако вы можете использовать плагин отрицания, чтобы инвертировать результат, возвращаемый плагином (следовательно, «остановлено» имеет состояние ОК).

Команда:

./ negate ./check_init_service crond

Выход:

 crond остановлен

NCPA

NPCA включает служебный модуль, который может проверять, остановлена ли служба.

Название службы:

RemoteAccess

Команда:

 ./check_ncpa.py -H 10.25.14.91 -t Str0ngT0k3n -M service -q service = RemoteAccess, статус = остановлен

Выход:

 OK: RemoteAccess остановлен

Имейте в виду, что служебный модуль является безопасным, вы можете преодолеть это с помощью аргумента match =.

Команда:

 ./check_ncpa.py -H 10.25.14.91 -t Str0ngT0k3n -M service -q service = remoteaccess, status = stop, match = search

Выход:

 OK: RemoteAccess остановлен

NSClient ++ через check_nt

NSClient ++ включает служебный модуль, который может проверять, запущена ли служба. Модуль может только проверять, запущена ли служба, однако вы можете использовать плагин отрицания, чтобы инвертировать результат, возвращаемый плагином (следовательно, сделав CRITICAL состоянием OK).

Название службы:

RemoteAccess

Команда:

 ./negate -s ./check_nt -H 10.25.14.10 -p 12489 -s 'Str0ngP @ ssw0rd' -v SERVICESTATE -l RemoteAccess

Выход:

 OK: удаленный доступ: остановлен, отложен ()

NSClient ++ через check_nrpe

NSClient ++ включает служебный модуль, который может проверить, остановлена ли служба.

Название службы:

RemoteAccess

Команда:

./ check_nrpe -H 10.25.14.10 -c check_service -a service = RemoteAccess "ok = state = 'Stop'" "warning = not state = 'stop'" "critical = not state = 'Stop'" "perf-config = * (игнорируется: истина) "

Выход:

 OK: Все 1 услуги в порядке.

WMI

Check WMI Plus включает служебный модуль, который может проверять, остановлена ли служба. Модуль определяет «хорошую» службу как работающую, а «плохую» — как неработающую, поэтому вы можете определить критичным, когда существует более 0 «хороших» служб.

Название службы:

RemoteAccess

Команда:

 ./check_wmi_plus.pl -H 10.25.14.3 -u wmiagent -p Str0ngP @ ssw0rd -m checkservice -a 'RemoteAccess' -c _NumGood = 0

Выход:

 OK - Найдено 1 служб, 0 OK и 1 с проблемами (0 исключено). «Маршрутизация и удаленный доступ» (RemoteAccess) остановлена. | «Общее количество услуг» = 1; «Счетчик обслуживания в рабочем состоянии» = 0; 0; «Состояние проблемы счетчика услуг» = 1; «Количество исключенных услуг» = 0;

Вот результат при запуске службы RemoteAccess:

 КРИТИЧЕСКИЙ - [Инициировано _NumGood> 0] - Найдено 1 служб, 1 в норме и 0 с проблемами (0 исключено).«Маршрутизация и удаленный доступ» (RemoteAccess) работает. | «Общее количество служб» = 1; «Счетчик услуг в рабочем состоянии» = 1; 0; «Состояние проблемы счетчика услуг» = 0; «Количество исключенных услуг» = 0;

SNMP

Проверить, остановлена ли служба с помощью SNMP, непросто, проверка процесса — лучшее решение, см. Статью базы знаний о проверках процессов.

Множественные службы

Некоторые методы поддерживают одновременную проверку нескольких служб.

Плагины Nagios

Плагин check_init_service не поддерживает проверку нескольких служб.

NCPA

NPCA позволяет вам проверять несколько служб, вот пример, который проверяет некоторые службы, которые работают, а некоторые остановлены.

Название службы:	Спулер (рабочий)
Название службы:	EventLog (работает)
Название службы:	RemoteAccess (остановлен)

Команда:

./check_ncpa.py -H 10.25.14.91 -t Str0ngT0k3n -M service -q service = Spooler, service = EventLog, status = running, service = RemoteAccess, status = stop

Выход:

 OK: спулер запущен, RemoteAccess остановлен, EventLog работает

NSClient ++ через check_nt

NSClient ++ позволяет проверять несколько служб, вот пример, который проверяет наличие двух запущенных служб.

Название службы:	Спулер (рабочий)
Название службы:	EventLog (работает)

Команда:

./ check_nt -H 10.25.14.10 -p 12489 -s 'Str0ngP @ ssw0rd' -v SERVICESTATE -l Spooler, EventLog -d SHOWALL

Выход:

 Спулер: запущен, журнал событий: запущен

NSClient ++ через check_nrpe

NSClient ++ позволяет проверять несколько служб, вот пример, который проверяет наличие двух запущенных служб.

Название службы:	Спулер (рабочий)
Название службы:	EventLog (работает)

Команда:

./ check_nrpe -H 10.25.14.10 -c check_service -a service = Spooler service = EventLog

Выход:

 OK: все 2 услуги в порядке.

WMI

Check WMI Plus позволяет вам проверять несколько служб, вот пример, который проверяет наличие двух запущенных служб.

Название службы:	Спулер (рабочий)
Название службы:	EventLog (работает)

Команда:

./check_wmi_plus.pl -H 10.25.14.3 -u wmiagent -p Str0ngP @ ssw0rd -m checkservice -a 'Spooler | EventLog' -c _Total = 1: -c 0

Выход:

 OK - найдено 2 службы, 2 исправных и 0 с проблемами (0 исключено). «Журнал событий Windows» (журнал событий) работает, «Диспетчер очереди печати» (диспетчер очереди печати) работает. | «Общее количество служб» = 2; 1; «Счетчик услуг в рабочем состоянии» = 2; «Состояние проблемы счетчика услуг» = 0; 0; «Количество исключенных услуг» = 0;

SNMP

Проверить службу с помощью SNMP не так просто, проверка процесса — лучшее решение, см. Статью базы знаний о проверках процессов.

Последние мысли

По любым вопросам, связанным с поддержкой, посетите форумы поддержки Nagios по адресу:

http://support.nagios.com/forum/

Масштабирование и распространение Checkmk | checkmk

1. Введение

Наверное, не все одинаково понимают термин «распределенный мониторинг». На самом деле мониторинг всегда распространяется на несколько компьютеров, если только Система мониторинга — это только сам мониторинг, что было бы бесполезно.

Поэтому в данном руководстве мы всегда говорим о распределенном мониторинге, когда Система мониторинга в целом состоит из более чем одного Checkmk-экземпляра . Существует ряд веских причин для разделения мониторинга на несколько экземпляров:

Производительность : загрузка процессора должна или должна распределяться между несколькими машинами.
Организация : Различные группы должны иметь возможность независимо администрировать свои экземпляры.
Доступность : Мониторинг в одном месте должен функционировать независимо от других.
Безопасность : потоки данных между двумя доменами безопасности должны контролироваться отдельно и точно (DMZ и т. Д.)
Сеть : местоположения, которые имеют только узкополосные или ненадежные соединения, не могут надежно удаленно контролироваться.

Checkmk поддерживает различные процедуры для реализации распределенного мониторинга. Checkmk контролирует некоторые из них, поскольку он в значительной степени совместим или основан на Nagios (если Nagios был установлен как ядро).Также охвачены старый процесс NSCA и несколько более современный mod_gearman. По сравнению с собственной системой Checkmk они не дают никаких преимуществ, а также больше. громоздка в реализации. По этим причинам мы их не рекомендуем.

Процедура, предпочитаемая Checkmk, основана на Livestatus и подразделение конфигурация с использованием WATO. Для ситуаций с очень сильно разделенными сетями, или даже строгая односторонняя передача данных от периферии к центру есть метод, использующий Livedump или CMCDump соответственно.Оба метода можно комбинировать.

2. Распределенный мониторинг с Livestatus

2.1. Основной принцип

Центральный статус

Livestatus — это интерфейс, интегрированный в ядро мониторинга который позволяет другим внешним программам запрашивать данные о состоянии и выполнить команд . Livestatus может быть доступен по сети так что к нему может получить доступ удаленный экземпляр Checkmk. Пользовательский интерфейс Checkmk использует livestatus для объединения всех связанных экземпляров в общий обзор.Тогда это похоже на «Большая» система мониторинга.

На следующей диаграмме схематично показана структура мониторинга с livestatus, распределенным по трем локациям. Главный сайт Checkmk-instance находится на центральном обрабатывающем сайте. Отсюда центральные системы будут управляться напрямую. Кроме того, есть экземпляры Slave Site 1 и Slave Site 2 , которые расположены в другие сети и управляемые их локальными системами:

Особенностью этого метода является то, что статус мониторинга ведомых , а не , постоянно отправляется мастеру.Графический интерфейс всегда извлекает только данные live с удаленных экземпляров, когда это требуется пользователю в центре управления. Затем данные компилируются в централизованное представление. Таким образом, не имеет централизованного хранения данных , что означает, что он предлагает огромные преимущества для увеличения масштаба!

Вот некоторые из преимуществ этого метода:

Масштабируемость : Сам мониторинг не генерирует никакого сетевого трафика между ведущим и ведомыми устройствами. Таким образом можно соединить сотни и более точек.
Надежность : Если сетевое подключение к ведомому устройству не удается, локальный мониторинг, тем не менее, продолжает работать нормально. Нет «дыры» в записи данных, а также нет «застревания» данных. Локальное уведомление по-прежнему будет работать.
Простота : Экземпляры могут быть очень легко включены или удалены.
Гибкость : Подчиненные экземпляры по-прежнему автономны и могут использоваться для работы в своем соответствующем местоположении. Это особенно интересно, если «локации» никогда не разрешать доступ к остальной части мониторинга.

Централизованная конфигурация

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

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

Такая система имеет не только общий обзор состояния, но и общий конфигурации и эффективно «ощущается как большая система».

2.2. Установка распределенного мониторинга

Установка распределенного мониторинга с использованием livestatus / распределенного WATO достигается в следующих этапах:

Сначала установите главный экземпляр, как это обычно делается для одного экземпляра
Установите подчиненные экземпляры и активируйте livestatus через сеть
Интегрируйте подчиненные экземпляры в мастер с помощью распределенного мониторинга WATO-module
Для узлы и службы, укажите, из какого экземпляра они должны отслеживаться
Выполнить обнаружение служб для перенесенных узлов, а затем активировать свежие изменения

Установка главного экземпляра

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

Установка подчиненных экземпляров и включение livestatus через сеть

Подчиненные экземпляры затем генерируются как новые экземпляры обычным способом с omd create. Это, естественно, будет происходить на (удаленном) сервере. предназначен для соответствующего ведомого экземпляра.

Особенности :

Для подчиненных экземпляров используйте идентификаторы , уникальный для распределенного мониторинга.
Checkmk-версии подчиненного устройства разрешено отличаться от версии главного устройства максимум до одного уровня исправления (обозначается цифрой после «p» для стабильных версий). Другие версии могут быть совместимы с , но не обязательно. Информацию о системе нумерации версий Checkmk можно найти в отдельной статье.
Подобно тому, как Checkmk поддерживает несколько экземпляров на сервере, подчиненные экземпляры также могут работать на одном сервере.

Вот пример создания подчиненного экземпляра с именем slave1:

root @ linux #  omd создать slave1 
Добавление / opt / omd / sites / slave1 / tmp в / etc / fstab.Создание временной файловой системы /omd/sites/slave1/tmp...OK
Перезапуск Apache ... ОК
Создал новый сайт slave1 с версией 1.2.8p12.

  Сайт можно запустить с помощью команды omd start slave1.
  Веб-интерфейс по умолчанию доступен по адресу http: // Klappfisch / slave1 /.
  Администратором веб-приложений является omdadmin с паролем omd.
  Пожалуйста, сделайте su-slave1 для администрирования этого сайта.

Самый важный шаг — теперь активировать текущий статус через TCP в сети. Обратите внимание, что текущий статус не является сам по себе безопасным протоколом и должен быть только используется в защищенной сети (защищенная LAN, VPN и т. д.). Появляется включение per omd config как пользователь экземпляра на остановленном сайте:

корень @ Linux #  ~ #  su - slave1  
OMD [mysite]: ~ $ , конфигурация omd

Теперь выберите Распределенный мониторинг :

Установите LIVESTATUS_TCP на «на» и введите доступный номер порта для LIVESTATUS_TCP_PORT , который явно указан на этом сервере. По умолчанию 6557:

После сохранения запустите экземпляр как обычно с omd start:

OMD [slave1]: ~ $  omd start 
Запуск mkeventd...ОК
Запуск Livestatus Proxy-Daemon ... ОК
Запуск rrdcached ... ОК
Запускаем Check_MK Micro Core ... ОК
Запуск выделенного Apache для сайта slave1 ... ОК
Запускаем xinetd ... ОК
Инициализация Crontab ... ОК

Временно сохранить пароль по умолчанию для omdadmin. После того, как раб был подчинен мастеру, все пользователи также будут заменены на тех, кто принадлежит мастеру.

Теперь ведомое устройство готово. Проверьте с помощью netstat, который должен показать, что Порт 6557 открыт. Подключение к этому порту осуществляется экземпляром вспомогательного демона xinetd, который запускается непосредственно в экземпляре:

root @ linux #  netstat -lnp | grep 6557 
tcp 0 0 0.0.0.0: 6557 0.0.0.0:* СЛУШАТЬ 10719 / xinetd

Назначение подчиненных экземпляров мастеру

Конфигурация распределенного мониторинга происходит исключительно на мастера. Требуется модуль WATO Распределенный мониторинг , который служит для управления подключениями к отдельные экземпляры. Для этой функции сам мастер считается экземпляр и уже присутствует в списке:

Используя, теперь определите соединение с первым ведомым устройством:

В базовых настройках важно использовать ТОЧНОЕ имя подчиненного экземпляра — как определено с помощью omd create — как идентификатор сайта.Как всегда псевдоним может быть определенным по желанию, а также быть позже измененным.

Параметры Livestatus определяют, как центральный экземпляр запрашивает статус ведомых устройств через текущий статус. Пример на скриншоте показывает соединение с Connect через TCP метод. Это оптимально для стабильных соединений с короткими периодами задержки. (например, в локальной сети). Обсудим оптимальные настройки для WAN-соединения позже.

Префикс URL-адреса необходим для интеграции других приложений (например,грамм. PNP4Nagios). Мы еще вернемся к этой теме отдельно. Введите здесь HTTP-URL веб-интерфейса ведомого устройства (только часть, предшествующая компонент check_mk /). Если вы в основном получаете доступ к Checkmk по HTTPS, затем замените http здесь на https. Дополнительную информацию можно найти в онлайн-справке или соответствующая статья по HTTPS вместе с Checkmk.

Использование Distributed WATO , как мы обсуждали во введении, необязательно. Активируйте это, если вы хотите настроить ведомое устройство с помощью ведущего устройства.В таком случае выберите точные настройки, как показано на изображении выше.

Правильная настройка Multisite-URL удаленного сайта очень важна. URL-адрес всегда должен заканчиваться на / check_mk /. Соединение с HTTPS есть рекомендуется при условии, что Apache подчиненного экземпляра поддерживает HTTPS. Это должно быть установлено вручную на ведомом устройстве на уровне Linux. Для Checkmk Appliance HTTPS можно настроить с помощью веб-интерфейс настройки. Если вы используете самозаверяющий сертификат, вам потребуется установить флажок Игнорировать ошибки сертификата SSL .

После сохранения маски в обзоре появится второй экземпляр:

Состояние мониторинга (пока) пустого ведомого теперь правильно интегрировано. Login к WATO ведомого по-прежнему требуется для распределенного WATO. Для этого через HTTP мастер обменивается случайно сгенерированным паролем с раб, через который будет происходить все дальнейшее общение. Впоследствии доступ omdadmin к ведомому устройству больше не будет использоваться.

Для входа используйте данные доступа omdadmin и omd (или, соответственно, учетной записи администратора на ведомом устройстве):

Успешный вход будет подтвержден следующим образом:

Если при входе в систему произойдет ошибка, это может быть вызвано рядом причин: например:

Подчиненный экземпляр в настоящее время остановлен.
Multisite-URL удаленного сайта настроен неправильно.
Подчиненное устройство недоступно под именем хоста «от мастера» , указанным в URL-адресе.
Версии Checkmk ведущего и ведомого (слишком) несовместимы.
Введен неверный идентификатор пользователя и / или пароль.

Пункты 1 и 2 можно легко проверить, вручную вызвав URL-адрес ведомого устройства. в вашем браузере.

Когда все прошло успешно, запустите Активировать изменения .Это будет, как всегда, приведу вас к обзору еще не активированных изменений. Одновременно он также покажет состояние соединений livestatus, аналогично состояния WATO-синхронизации отдельных экземпляров:

В столбце Version отображается Livestatus-версия соответствующего сайта. При использовании CMC в качестве ядра Checkmk ( Enterprise Editions ) номер версии ядра (отображается в столбце «Core» ) идентично текущему статусу.Если вы используете Nagios в качестве ядра ( Checkmk Raw Edition), здесь будет отображаться номер версии Nagios.

Следующие символы показывают статус репликации WATO:

	В этом экземпляре есть незавершенные изменения. Конфигурация соответствует мастеру, но не все изменения были активированы. С помощью кнопки Restart можно выполнить целевую активацию для этого экземпляра.
	WATO-конфигурация для этого экземпляра не синхронна и должна переноситься.Конечно, для его активации потребуется перезапуск. Обе функции могут быть выполнены с помощью кнопки Sync & Restart .

В столбце Status отображается состояние соединения livestatus для соответствующий экземпляр можно увидеть. Это показано исключительно для информации поскольку конфигурация передается не через Livestatus, а скорее через HTTP. Возможны следующие значения:

	Экземпляр доступен через Livestatus.
	Экземпляр в настоящее время недоступен. Запросы Livestatus выполняются в Тайм-аут . Это задерживает загрузку страницы. Данные статуса для этого экземпляра не отображается в графическом интерфейсе.
	Экземпляр в настоящее время недоступен, но это связано с настройкой statushost или известен через прокси Livestatus (увидеть ниже). Недоступность не , а не приводит к таймаутам. Данные о состоянии для этого экземпляра не отображаются в графическом интерфейсе.
	Соединение livestatus с этим экземпляром временно деактивировано администратором (хозяином). Настройка соответствует ‘Временно отключить это соединение ‘ в настройках этого соединения.

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

Важно: Не покидайте страницу до завершения синхронизации. завершено во всех случаях — при выходе со страницы синхронизация прерывается.

Указание хостам и папкам, какой экземпляр должен их отслеживать

После установки вашей распределенной среды вы можете начать ее использовать. Фактически вам нужно только указать каждому хосту, с помощью какого экземпляра он должен отслеживаться. Мастер указан по умолчанию.

Обязательный атрибут для этого — «Мониторинг на месте» .Вы можете установить это индивидуально для каждого хоста. Естественно, это также можно сделать на уровне папки:

Выполнение нового обнаружения службы и активация изменений для перенесенных хостов

Добавление хостов работает как обычно — не считая того, что а также обнаружение службы будет запущено с соответствующего ведомого устройства Например, здесь нет особых соображений.

При миграции хостов с одного экземпляра на другой возникает пара моментов, о которых нужно знать. Ни текущего, ни исторического статуса данные с хоста будут перенесены. Только конфигурация хоста сохраняется в WATO. Фактически это как если бы хост был удален из одного экземпляра и только что установленного в другом экземпляре:

Автоматически обнаруженные службы не будут перенесены. Запустите обнаружение службы после миграции.
После перезапуска хосты и службы будут отображать PEND . В результате о существующих проблемах может быть сообщено заново.
Исторические графики будут потеряны. Этого можно избежать, вручную переместив соответствующие RRD-файлы. Расположение файлов можно найти в файлах и каталогах.
Данные о доступности и исторических событиях будут потеряны. К сожалению, их нелегко перенести, поскольку данные в журнале мониторинга состоят из отдельных строк.

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

2.3. Подключение Livestatus с шифрованием

Начиная с версии 1.6.0 Соединения Livestatus между главным и ведомое устройство может быть зашифровано. Для вновь созданных экземпляров больше ничего делать не нужно, Поскольку Checkmk автоматически выполнит необходимые действия. Как только вы затем воспользуетесь конфигурацией omd для активации Livestatus шифрование также автоматически активируется TLS:

Таким образом, конфигурация распределенного мониторинга остается такой же простой, как и это было до сих пор.Для новых подключений к другим экземплярам опция Шифрование будет автоматически включено.

После добавления удаленного экземпляра вы заметите две вещи: во-первых, соединение помечается как зашифрованное этим новым значком. А во-вторых, Checkmk сообщит вам, что ЦС больше не будет доверять удаленному экземпляру. Нажмите, чтобы перейти к сведения об используемых сертификатах. Щелчок по позволяет вам удобно добавить CA через веб-интерфейс. Тогда оба сертификата будут быть внесенным в список доверенных:

Подробная информация об используемых технологиях

Для обеспечения шифрования Checkmk использует программу stunnel вместе с собственный сертификат и собственный центр сертификации (CA) для подписи сертификат.Они будут автоматически сгенерированы индивидуально с помощью новый экземпляр, и поэтому это , а не предопределенных статических центров сертификации или сертификаты. Это очень важный фактор безопасности для предотвращения подделки сертификаты от использования злоумышленниками, потому что любой злоумышленник мог получить доступ к общедоступному ЦС.

Созданные сертификаты также обладают следующими свойствами:

Оба сертификата имеют формат PEM. Подписанные сертификаты для экземпляра также содержат полную цепочку сертификатов.
Ключи используют 2048-битный RSA, а сертификат подписан с использованием SHA512
Сертификат экземпляра действителен в течение 999 лет.

Тот факт, что стандартный сертификат действует так долго, очень эффективно предотвращает возникновение проблем с подключением, которые вы не можете классифицировать. В то же время, конечно, возможно, что после того, как сертификат был скомпрометированный, соответственно, долго открыт для злоупотреблений. Итак, если вы боитесь, что злоумышленник получит доступ к ЦС или к подписанному сертификату экземпляра с его помощью всегда заменяйте оба сертификата (CA и экземпляр)!

Использование собственных сертификатов

В больших средах вы можете в любом случае использовать свои собственные сертификаты.Чтобы заменить поставляемые, просто замените сертификат экземпляра на ваш собственный, и убедитесь, что ЦС, подписавший новый сертификат, тоже доверял.

Переход со старых версий

По причинам совместимости параметр LIVESTATUS_TCP_TLS будет не активируется автоматически после обновления более старой версии до 1.6.0 , так как в новой версии возможно использование только соединение с шифрованием. После обновления, чтобы использовать новый в ваших экземплярах мониторинга, остановите экземпляр и активируйте упомянутый вариант:

OMD [mysite]: ~ $ , конфигурация omd установлена LIVESTATUS_TCP_TLS на

Поскольку сертификаты создавались автоматически во время обновления, затем экземпляр немедленно использует новую функцию шифрования.Так что вы все еще можете получить доступ к экземпляру из мастера, на втором шаге активируйте опцию Encryption в свойствах подключения экземпляра под WATO ➳ Распределенный мониторинг :

Последний шаг, как описано выше — опять же здесь сначала нужно отметить ЦС удаленного экземпляра считается доверенным.

2.4. Особенности распределенной установки

Распределенный мониторинг работает через livestatus, как единая система, но у него есть несколько особых характеристик:

Доступ к контролируемым узлам

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

Указание экземпляра в представлениях

Некоторые из стандартных видов сгруппированы в соответствии с экземпляром, из которого хост будет контролироваться — это относится, например, к Все хосты :

Экземпляр также будет отображаться в деталях хоста или службы:

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

Элемент статуса сайта

Имеется элемент оснастки Site status для боковой панели, который можно добавить с помощью . Это отображает состояние отдельные экземпляры, а также предоставляет возможность щелкнуть по статусу чтобы временно скрыть или показать отдельные сайты. Они будут отмечены значком положение дел. Этим вы также можете отключить экземпляр, который генерирует тайм-ауты, таким образом избегая лишних таймаутов:

Это , а не то же самое, что отключение соединения livestatus с помощью конфигурация подключения в WATO.Здесь «отключение» влияет только на в настоящее время вошедший в систему пользователь и имеет чисто визуальную функцию. При щелчке по имени экземпляра отобразятся все его хосты.

Главный элемент управления

В распределенном мониторинге Главный элемент управления имеет другой вид. Каждый экземпляр имеет собственный глобальный коммутатор :

Хосты Checkmk Cluster

Если вы выполняете мониторинг с помощью Checkmk HA-Cluster, отдельные узлы кластера должен быть назначен тому же экземпляру, что и сам кластер.Это связано с тем, что определение статуса кластеризованных сервисов обращается к кешу файлы, созданные с помощью мониторинга узла. Эти данные находятся локально в соответствующем экземпляре.

Данные Piggyback (например, ESX)

Некоторые подключаемые модули проверки используют данные «Piggyback», например, для распределения данных мониторинга. извлекаются с ESX-хоста на отдельные виртуальные машины. По той же причине как и в случае мониторинга кластера, в распределенном мониторинге «копилка» (несущий) хост как а также его зависимые хосты должны контролироваться из одного и того же экземпляра.В случае ESX это означает, что виртуальные машины должны быть назначены тот же сайт в Checkmk, что и ESX-System, с которого собираются данные мониторинга. Это может означать, что лучше напрямую опросить хост-систему ESX, чем для опроса глобального vCenter. Подробности по этому поводу можно найти в документации по ESX-мониторингу.

Инвентаризация аппаратного и программного обеспечения

Инвентаризация оборудования и программного обеспечения Checkmk также работает в распределенной среды. При этом данные инвентаризации из Каталог var / check_mk / inventory должен регулярно передаваться из рабы мастера.По соображениям производительности пользовательский интерфейс всегда обращается к этому каталогу локально.

В Checkmk Enterprise Editions синхронизация выполняется автоматически на всех сайтах, которые подключаются через прокси Livestatus.

Если вы запускаете инвентаризацию с использованием Checkmk Raw Edition в распределенных системах, каталог должен регулярно дублировать мастер с помощью ваших собственных инструментов (например, с помощью rsync).

Смена пароля

Даже когда все экземпляры контролируются централизованно, вход в систему интерфейс экземпляра вполне возможен и часто также уместен.По этой причине WATO гарантирует, что пароль пользователя всегда одинаков для всех сайтов.

Изменение пароля, сделанное администратором, вступит в силу автоматически, как только как только он станет доступным для всех экземпляров с помощью Активировать изменения .

Изменение, внесенное самим пользователем с помощью боковая панель в их личных настройках работает несколько иначе. Это не может выполнить Активировать изменения , поскольку пользователь, конечно не имеет общих полномочий для этой функции. В таком случае WATO автоматически поделится измененным паролем через все экземпляры — сразу после фактического сохранения.

Как мы все знаем, сети никогда не доступны на 100%. Если во время смены пароля экземпляр недоступен, он не получит новый пароль. Пока администратор успешно не запустит Активировать изменения , или, соответственно, при следующей успешной смене пароля этот экземпляр будет сохранить старый пароль для пользователя. Символ статуса информирует пользователя о статусе пароля. разделение на отдельные экземпляры.

2,5. Привязка существующих инстансов

Как упоминалось выше, существующие экземпляры также могут быть ретроспективно привязаны к распределенному мониторингу.При условии выполнения описанных выше предварительных условий (совместимые версии Checkmk), это будет выполнено точно так же, как для настройка нового раба. Поделиться livestatus с TCP, затем добавьте экземпляр в модуль распределенного мониторинга — и все готово!

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

Если вы хотите перенять существующие хосты и, возможно, правила, потребуются три шага:

Схема сопоставления тегов хоста
Скопируйте WATO-каталоги
Отредактируйте характеристики в родительской папке

1.Теги хоста

Само собой разумеется, что теги хоста, используемые в подчиненном устройстве, также должны быть известны. мастеру, чтобы их можно было перенести. Проверьте их перед переносом и добавьте недостающие теги в мастер вручную. Здесь важно, чтобы идентификаторы тегов совпадали — заголовок тега не имеет значения.

2. WATO-справочники

Затем переместите хосты и правила в центральный WATO на главном устройстве. Это работает только для хостов и правил в подкаталогах (т. Е. Не в «Главный каталог» ).Хосты в основном каталоге нужно сначала просто переместить в подкаталог ведомого устройства с помощью WATO.

Фактическая миграция может быть осуществлена простым копированием соответствующие каталоги. Каждый каталог хоста в WATO соответствует каталог в etc / check_mk / conf.d / wato /. Их можно скопировать с помощью инструмента по вашему выбору (например, scp) из привязанный сайт к тому же месту в главном устройстве. Если каталог с таким именем там уже существует, просто переименуйте его. Обратите внимание, что пользователи и группы Linux также используются главным сайтом.

После копирования хосты должны появиться в центральном WATO мастера — а также правила, которые вы создали в этих папках. Характеристики папок также будут включены при копировании. Их можно найти в папке в скрытом файле .wato.

3. Единовременное редактирование и сохранение

Таким образом, атрибуты функций родительской папки мастера правильно унаследован, в качестве последнего шага после миграции родительский характеристики папок должны быть открыты и сохранены один раз — Таким образом, атрибуты будут определены заново.

2.6. Глобальные настройки для конкретного экземпляра

Централизованная конфигурация через WATO означает, что, прежде всего, все экземпляры имеют общую и (кроме хостов) одинаковую конфигурацию. Однако какова ситуация, когда в отдельных случаях требуются разные Глобальные настройки? Примером может служить настройка CMC Максимальное количество одновременных проверок Checkmk . Может случиться так, что для особенно маленький или особенно большой экземпляр.

Для таких случаев существует глобальная настройка для конкретного экземпляра. Это достигается с помощью символа в Распределенный мониторинг WATO-модуль:

С помощью этого символа вы найдете выбор всех глобальных настроек — хотя все, что вы здесь определите, будет эффективно только для выбранного экземпляра. Значение, которое отличается от стандарта, будет выделено визуально, и это будет применяться только к этому экземпляру:

Примечание : Настройки для конкретного объекта Master только косвенно возможно — поскольку, конечно же, конфигурацию определяет мастер.В ситуации, когда ТОЛЬКО настройки мастера расходятся, для всех остальных сайтов необходимо будет выполнить настройки для конкретного сайта, чтобы «ВОЗВРАТИТЬ» их к «значениям по умолчанию».

2.7. Распределенная консоль событий

Консоль событий обрабатывает syslog-сообщения, ловушки SNMP и другие типы событий асинхронного характера.

До версии 1.2.8, в распределенной среде рекомендованная процедура — управлять только одним экземпляром в консоли событий — и этот в главном экземпляре.Здесь вы направляете все проводимые мероприятия.

Эта установка имеет тот недостаток, что события хоста должны быть отправлены другому экземпляру, а не экземпляру, который их активно отслеживает. Следствием этого является то, что при генерации уведомлений от события console, информация о хосте является неполной, поскольку локальный Checkmk не знает о них. С одной стороны, это касается определения контактных групп хостов, и, с другой стороны, также к событиям, в которых исходный хост определяется только его IP-адресом, а настоящее имя хоста отсутствует.В таком случае правила уведомления, содержащие условия, связанные с имена хостов не могут работать.

Начиная с версии 1.4.0i1 Checkmk также предоставляет возможность запуск распределенной консоли событий. Тогда каждый экземпляр будет работать самостоятельно обработка событий, которая фиксирует события от всех хостов, контролируется с экземпляра. Таким образом, события будут отправлены , а не . центральная система, скорее они останутся в экземплярах и будут извлекаться только централизованно.Это выполняется так же, как для активных состояний через Livestatus, и работает как с Checkmk Raw Edition, так и с Checkmk Enterprise Edition.

Для преобразования в распределенную консоль событий по новой схеме требуется следующие шаги:

В настройках подключения для WATO-Replication активируйте опцию EC ( Реплицировать конфигурацию консоли событий на этот сайт, )
Переключите местоположение системного журнала и назначения ловушек SNMP для затронутых хостов на подчиненное устройство.Это самая трудоемкая задача.
Если вы используете Проверить состояние события в наборе правил консоли событий , переключите его обратно на Подключитесь к локальной консоли событий .
Если вы используете набор правил пересылки консоли событий Logwatch, переключите его аналогично на локальную консоль событий.
В консоли событий Настройки переключите Доступ к состоянию события через TCP обратно на Нет доступа через TCP .

2.8. PNP4Nagios

В Checkmk Raw Edition используется PNP4Nagios Open-Source-Projekt используется для графического отображения значений производительности. У него есть собственный веб-интерфейс, интегрированный в Checkmk. Используя это, в некоторых местах будет встроена отдельная графика, а в других местоположениям будет предоставлена полная страница, включая собственную навигацию:

При распределенном мониторинге всегда находятся базы данных производительности (Round-Robin-Databases или RRD). локально на подчиненных сайтах.Это очень важно, потому что непрерывная передача таким образом избегается передача всех данных о производительности мастеру — и результирующего сетевого трафика. Кроме того, все другие преимущества распределенного мониторинга через livestatus сохраняются, как описано в начале.

PNP4Nagios, к сожалению, не имеет совместимого интерфейса для доступа к графикам в livestatus. Поэтому Checkmk просто извлекает отдельные графики или, соответственно, полные веб-сайты от PNP4Nagios через HTTP по стандартным URL-адресам.Для этого используются два метода:

Данные PNP4Nagios извлекаются непосредственно из браузера пользователя
Данные PNP4Nagios извлекаются из главного устройства и затем пересылаются пользователю

1. Получение через браузер пользователя

Первый метод очень прост в реализации. Для соответствующих сайтов настроить префикс URL-адреса в атрибутах соединения и установить для него значение URL-адрес, используемый для доступа к этому экземпляру — хотя без / check_mk /:

Checkmk встроит графики в графический интерфейс, чтобы браузер мог получить PNG-изображения графиков или, соответственно, фреймы веб-сайта от PNP4Nagios по этому URL.Укажите URL-адрес таким образом, как он работает с браузером приложения. Доступ к ведомому устройству от ведущего — , а не .

Метод URL, описанный выше, настраивается быстро и легко, но у него есть несколько небольшие недостатки:

Поскольку браузер извлекает данные PNP4Nagios с другого хоста в Checkmk-GUI, cookie сеанса Checkmk не будет отправлен. Таким образом, пользователь должен сделать новый логин для очень подчиненного экземпляра. При первом доступе к графику появится экран входа в систему.
На самом деле подчиненный сервер может быть недоступен из браузера пользователя — скорее, только из главного. В таком случае этот метод не работает.
Префикс URL-адреса должен иметь значение либо http: // , либо — https: // . В этом случае выбор, сделанный пользователем, больше не будет работать.

2. Получение через мастер

Лучшее решение этой проблемы — получить данные PNP4Nagios из мастер, а не из самого браузера пользователя.Для этого создайте правило прокси на главном Apache-сервере. Это направит PNP4Nagios запрашивает по HTTP или HTTPS правильный подчиненный сервер. Важно: это необходимо сделать на Apache операционной системы, , а не , который работает на экземпляре. По этой причине требуется root-разрешение.

Предварительным условием для этой настройки является то, что все идентификаторы экземпляров Checkmk в вашем сети являются явными, поскольку Apache должен использовать Slave-ID, чтобы решить на какой сервер следует перенаправить.

Предположим следующий пример:

ID	IP-адрес	Состояние	Checkmk URL
главный	10.15.18.223	местный	http://10.15.18.223/master/check_mk/
ведомый1	10.1.1.133	Порт 6557	http://10.1.1.133/slave1/check_mk/

Теперь в настройках подключения просто установите / slave1 / в качестве префикса URL:

При этом запросы к PNP4Nagios сначала отправляются мастеру по URL-адресу / slave1.Если экземпляр slave1 случайно работает на том же сервер в качестве мастера, теперь вы закончите, и правило прокси не потребуется, поскольку данные могут быть доставлены напрямую.

В общем случае, когда ведомое устройство работает на другом хосте, вам потребуется root-разрешение и вы должны создать конфигурации файл для общесистемного сервера Apache. Путь к этому файлу будет зависеть от вашего дистрибутива Linux:

Распределение	Путь
RedHat, CentOS	/ и т.д. / httpd / conf.d / check_mk_proxy.conf
SLES, Debian, Ubuntu	/etc/apache2/conf.d/check_mk_proxy.conf

Файл состоит из пяти строк для каждого экземпляра привязанного ведомого устройства. В следующем примере замените имя экземпляра (здесь slave1) и URL экземпляра (здесь http://10.1.1.133/slave1/). Обратите внимание, что для Apache имеет значение , заканчивается ли URL-адрес. с косой чертой (/) или без:

/etc/apache2/conf. /.+ / slave1 /(.*) http://10.1.1.133/slave1/ 1 доллар [P]

Это правило сообщает Apache, что все URL-адреса, начинающиеся с / slave1, являются для получения через обратный прокси-сервер с URL-адреса http://10.1.1.133/slave1.

Важно : не забудьте активировать конфигурацию. Для SLES, Debian и Ubuntu выполните это с помощью:

root @ linux #  /etc/init.d/apache2 перезагрузить

RedHat и CentOS требуют:

root @ linux #  / etc / init.d / httpd перезагрузка

Если все было сделано правильно, PNP4Nagios теперь должен иметь доступ к графикам.

2.9. Logwatch

Checkmk включает плагин mk_logwatch, с помощью которого под Linux и Windows вы можете отслеживать текстовые файлы журналов, особенно журнал событий Windows. Этот плагин предоставляет специальную веб-страницу в графическом интерфейсе пользователя, на которой обнаруженные сообщения можно просмотреть и подтвердить:

До версии Checkmk 1.2.8 для этой страницы требовался локальный доступ к сохраненным сообщениям журнала.Это установило плагин на подчиненное устройство, с которого соответствующий сервер отслеживался. Однако в распределенном мониторинге мастер не имеет прямого доступа к этим файлам. Решение такое же, как и с PNP4Nagios: Веб-страница журнала регистрации подчиненного сервера встраивается и извлекается из подчиненного сервера отдельно по протоколу HTTP.

Конфигурация, необходимая для этого, идентична конфигурации, используемой при настройке Поднимите Checkmk для PNP4Nagios. Если это уже настроен, интерфейс Logwatch будет автоматически работать правильно.

Начиная с версии 1.4.0i1 Проверьте веб-страницу Logwatch исключительно использует Livestatus для передачи и больше не требует HTTP. В этом случае настройка HTTP или правила прокси требуется только для пользователей. из Checkmk Raw Edition для PNP4Nagios.

2.10. NagVis

Программа с открытым исходным кодом NagVis визуализирует данные о состоянии мониторинга на картах, диаграммах и других схемах собственного производства. NagVis интегрирован в Checkmk и может использоваться немедленно.Доступ проще всего через элемент боковой панели NagVis Maps . Интеграция NagVis в Checkmk описана в отдельной статье.

NagVis поддерживает распределенный мониторинг через Livestatus в значительной степени так же, как это делает Checkmk. Ссылки на отдельные сайты именуется как бэкэндов . Серверные ВМ автоматически настраиваются Checkmk правильно, так что один может сразу начать создание NagVis-диаграмм — также в распределенный мониторинг.

Выберите правильный бэкэнд для каждого объекта, который вы размещаете на диаграмме — я.е., экземпляр Checkmk, из которого нужно отслеживать объект. NagVis не может найти хост или службу автоматически, прежде всего по соображениям производительности. Поэтому, если вы перемещаете хосты на другое ведомое устройство, вам нужно будет обновить соответственно графики NagVis.

Подробную информацию о бэкэндах можно найти в документации здесь: NagVis.

3. Нестабильное или медленное соединение

Общий обзор состояния в пользовательском интерфейсе позволяет всегда быть доступным и надежный доступ ко всем подключенным экземплярам.Единственная загвоздка в том, что представление может отображаться только тогда, когда все экземпляры ответили. Это всегда сначала запрос Livestatus отправляется (например, «Список всех служб, состояние которых не соответствует OK .»). Представление может быть отображено только после того, как последний экземпляр ответил.

Досадно, когда экземпляр вообще не отвечает. Чтобы терпеть кратковременные отключения (например, из-за перезапуска сайта или потери TCP-пакета) графический интерфейс ожидает заданного время до объявления экземпляра, а затем продолжает обработку ответов с остальных сайтов.Это приводит к «зависанию» графического интерфейса. По умолчанию таймаут составляет 10 секунд.

Если это время от времени случается в вашей сети, вы должны настроить либо хосты статуса или (что еще лучше) прокси Livestatus.

3.1. Статус хозяев

Конфигурация хостов состояния — рекомендуемая процедура с Checkmk Raw Edition для надежного распознавания неисправных соединений. Идея проста: главный экземпляр активно отслеживает подключение к каждый отдельный раб.По крайней мере, тогда у нас будет доступна система мониторинга! Тогда графический интерфейс будет знать о недоступных экземплярах и может немедленно исключить и пометьте их как. Таким образом минимизируются таймауты.

Вот как настроить хост статуса для соединения:

Добавьте хост, на котором запущен подчиненный экземпляр, к главному в мониторинге.
Введите это как статус хоста в соединении с подчиненным устройством:

Неудачное соединение с подчиненным экземпляром теперь может привести только к кратковременному зависанию графического интерфейса пользователя — а именно до тех пор, пока мониторинг не распознает его.Уменьшая интервал подтверждения статуса хоста с шестидесяти секунд по умолчанию к, например, пять секунд, вы можете минимизировать продолжительность зависания.

Если вы настроили хост статуса, существуют и другие возможные состояния для соединений:

	Компьютер, на котором запущен подчиненный экземпляр, сейчас недоступен для мониторинг, потому что маршрутизатор не работает (статус хоста находится в состоянии UNREACH ).
	Хост статуса, который контролирует соединение с ведомой системой, не пока не проверено мониторингом (он все еще имеет состояние PEND ).
	Состояние хоста статуса имеет недопустимое значение (этого никогда не должно происходить).

Во всех трех случаях соединение с экземпляром будет исключено и, таким образом, тайм-ауты будут исключены.

3.2. Постоянные соединения

С помощью флажка Use persistent connections вы можете запросить графический интерфейс для постоянного поддержания установленных соединений Livestatus с подчиненными экземплярами в «активном» состоянии и продолжать использовать их для запросов.Специально для стыковок с более длительным пакетным обслуживанием (например, межконтинентального), это может сделать графический интерфейс заметно более отзывчивым.

Поскольку графический интерфейс Apache используется несколькими независимыми процессами, соединение требуется для каждого процесса Apache-Client, выполняющегося одновременно. Если у вас много одновременных пользователей, убедитесь, что конфигурация имеет достаточное количество соединений Livestatus в ядре подчиненного сервера Nagios. Они настраиваются в файле etc / mk-livestatus / nagios.cfg.По умолчанию — двадцать (num_client_threads = 20).

По умолчанию Apache настроен в Checkmk так, что разрешает до 128 одновременные подключения пользователей. Это настраивается в следующем разделе файла etc / apache / apache.conf:

и т. Д. / Apache / apache.conf


StartServers 1
MinSpareServers 1
MaxSpareServers 5
ServerLimit 128
MaxClients 128
MaxRequestsPerChild 4000

Это означает, что при высокой нагрузке может запускаться до 128 процессов Apache, которые затем также генерировать и поддерживать до 128 соединений Livestatus.Недостаточно высокое значение num_client_threads может привести к ошибкам или очень медленное время отклика в графическом интерфейсе.

Для подключений к LAN или к быстрым WAN-сетям мы рекомендуем , а не использование постоянных соединений.

3.3. Прокси-сервер livestatus

С Livestatusproxy функция Checkmk Enterprise Editions сложный механизм обнаружения мертвых соединений. Кроме того, это особенно оптимизирует производительность соединений. с длительным временем приема-передачи.Преимущества прокси livestatus:

Очень быстрое проактивное обнаружение неотвечающих экземпляров
Локальное кэширование запросов, доставляющих статические данные
Постоянные TCP-соединения, которые требуют меньшего количества циклов и, следовательно, позволяют гораздо быстрее отвечать на удаленные экземпляры (например, США ⇄ Китай)
Точный контроль максимального количества требуемых соединений livestatus
Обеспечивает инвентаризацию оборудования / программного обеспечения в распределенных средах

Установка

Установить прокси livestatus очень просто.По умолчанию он активирован в CEE — что можно увидеть при запуске сайта:

OMD [master]: ~ $  omd start 
Запуск mkeventd ... ОК
  Запуск прокси-демона Livestatus ... ОК 
Запуск rrdcached ... ОК
Запускаем Check_MK Micro Core ... ОК
Запуск выделенного Apache для сайта slave1 ... ОК
Запускаем xinetd ... ОК
Инициализация Crontab ... ОК

Выберите настройку « Использовать Livestatus Proxy-Daemon » для подключения к ведомые устройства вместо «Подключиться через TCP»:

Детали для хоста и порта как всегда.На ведомом устройстве нельзя вносить никаких изменений. В Количество открытых каналов введите количество параллельных TCP-соединения прокси должен установить и поддерживать до целевого сайта.

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

Если графический интерфейс должен ждать дольше Тайм-аут ожидания свободного канала для канала, он будет прерван с ошибкой, и пользователь получит сообщение об ошибке. В таком случае количество подключений следует увеличить. Однако имейте в виду что на удаленном (ведомом) должно быть разрешено достаточное количество параллельных входящих соединений — по умолчанию установлено 20. Этот параметр можно найти в глобальных параметрах в разделе Ядро мониторинга ➳ Максимальное количество одновременных подключений Livestatus .

Регулярное сердцебиение обеспечивает постоянно активный мониторинг соединений непосредственно на уровне протокола. В процессе прокси регулярно отправляет простой Запрос Livestatus, на который ведомое устройство должно ответить в течение заданного времени (по умолчанию: 2 секунды). С этим методом ситуация, когда целевой сервер и TCP-порт действительно доступен, но ядро мониторинга больше не отвечает, также будет обнаружен.

Если ответ не появится, все соединения будут объявлены «мертвыми», и после этого будет заново установлено время «восстановления» (по умолчанию: 4 секунды).Все это происходит в упреждающем режиме — т.е. без пользователю откройте GUI-окно. Таким образом можно быстро обнаружить сбои, а с помощью восстановления соединения могут быть немедленно восстановлены и в лучшем случае доступны до пользователь даже замечает отключение.

Caching гарантирует, что на статические запросы нужно только один раз ответить ведомым устройством, и с этого момента можно без промедления отвечать прямо и на местном уровне. Примером этого является список контролируемых хостов, требуемый Quicksearch .

Диагностика ошибок

Прокси-сервер Livestatus имеет собственный файл журнала. который можно найти в var / log / liveproxyd.log. На правильно настроенном ведомом с пятью каналами (стандарт) это будет выглядеть примерно так:

var / log / liveproxyd.log

2016-09-19 14: 08: 53.310197 ---------------------------------------- ------------------
2016-09-19 14: 08: 53.310206 Запуск демона Livestatus Proxy-Daemon ...
2016-09-19 14: 08: 53.310412 Настроено 1 сайт
2016-09-19 14: 08: 53.310469 Удаление оставшегося unix socket / omd / sites / master / tmp / run / liveproxy / slave1
2016-09-19 14:08:53.310684 Канал Slave1 / 5 успешно подключен
2016-09-19 14: 08: 53.310874 Ведомый канал 1/6 успешно подключен
2016-09-19 14: 08: 53.310944 Подчиненный канал 1/7 успешно подключен
2016-09-19 14: 08: 53.311009 Подчиненный канал 1/8 успешно подключен
2016-09-19 14: 08: 53.311071 Канал slave1 / 9 успешно подключен

Прокси-сервер Livestatus регулярно записывает свое состояние в файл var / log / liveproxyd.state:

var / log / liveproxyd.state

Текущее состояние:
[slave1]
  Состояние: готово
  Последний сброс: 19.09.2016 14:08:53 (125 секунд назад)
  Последняя перезагрузка сайта: 2016-09-19 14:08:45 (134 сек назад)
  Последнее неудачное соединение: 1970-01-01 01:00:00 (1474287059 секунд назад)
  Кешированные ответы: 1
  Последнее обновление инвентаря: 1970-01-01 01:00:00 (1474287059 секунд назад)
  PID обновления инвентаря: Нет
  Каналы:
      5 - готово - клиент: нет - с: 2016-09-19 14:10:38 (20 секунд назад)
      6 - готово - клиент: нет - с: 2016-09-19 14:10:43 (15 секунд назад)
      7 - готово - клиент: нет - с: 2016-09-19 14:10:48 (10 секунд назад)
      8 - готово - клиент: нет - с: 2016-09-19 14:10:53 (5 секунд назад)
      9 - готово - клиент: нет - с: 2016-09-19 14:10:33 (25 секунд назад)
  Клиенты:
  Стук сердца:
    Получено сердцебиение: 24
    следующий в 0.2 с

И когда экземпляр в настоящий момент остановлен, состояние будет выглядеть так:

var / log / liveproxyd.state

----------------------------------------------
Текущее состояние:
[slave1]
  Состояние:  начиная с 
  Последний сброс: 19.09.2016 14:12:54 (10 сек назад)
  Последняя перезагрузка сайта: 2016-09-19 14:12:54 (10 сек назад)
  Последний раз не удалось подключиться: 19.09.2016 14:13:02 (2 секунды назад)
  Кешированные ответы: 0
  Последнее обновление инвентаря: 1970-01-01 01:00:00 (1474287184 секунды назад)
  PID обновления инвентаря: Нет
  Каналы:
  Клиенты:
  Стук сердца:
    получено сердцебиение: 0
    следующий в -5.2 с

Здесь состояние «запускается». Таким образом, прокси пытается установить соединение. Каналов пока нет. В этом состоянии на запросы к сайту будет дан ответ с ошибкой.

4. Livedump и CMCDump

4.1. Мотивация

Описанная концепция распределенного мониторинга с помощью Checkmk до сих пор в большинстве случаев является хорошим и простым решением. Однако для этого требуется доступ к сети от ведущего к ведомым . Бывают ситуации, когда доступ либо невозможен, либо нежелательно, потому что, например:

ведомые устройства находятся в сети вашего клиента, к которой у вас нет доступа
ведомые устройства находятся в зоне безопасности, доступ к которой строго запрещен
ведомые устройства не имеют постоянного сетевого подключения и фиксированных IP-адресов

Распределенные мониторинг с помощью Livedump, или соответственно CMCDump использует совершенно другой подход.Во-первых, ведомые устройства так подключены, что работают полностью независимо от мастер и управляются децентрализованно . Распределенный WATO будет обойден.

Все узлы и службы ведомого устройства будут затем реплицированы как копий на ведущем устройстве. Livedump / CMCDump может помочь, создав копию конфигурации ведомых устройств. который затем можно загрузить в мастер.

Теперь во время мониторинга на каждом ведомом устройстве будет сохранена копия текущего состояния. записывается в файл с заданными интервалами (например,грамм. каждую минуту). Он будет передан мастеру с помощью пользовательского метода и будет сохранен там как обновление статуса. Никакого конкретного протокола не было предоставлено или указано для этой передачи данных. Можно использовать любой протокол автоматической передачи. Использование scp не обязательно — возможен даже перевод по электронной почте!

Такая установка отличается от «обычного» распределенного мониторинга следующим образом:

Актуализация состояний и данных производительности в мастере будет отложена.
Расчет доступности на ведущем устройстве даст минимально разные результаты по сравнению с расчетом на ведомом устройстве.
Изменения состояния, которые происходят быстрее, чем интервал актуализации, будут невидимы для мастера.
Если ведомое устройство «мертв», состояния на ведущем устройстве станут устаревшими — службы будут «устаревшими», но, тем не менее, все еще будут видны.

Данные о производительности и доступности за этот период времени будут «потеряны» (но они все равно будут доступны на ведомом устройстве).

Команды на ведущем устройстве, такие как время простоя и подтверждения , не могут быть переданы на ведомое устройство .
Мастер никогда не может получить доступ к подчиненным.
Доступ к деталям файла журнала для Logwatch невозможен.
Консоль событий не будет поддерживаться Livedump / CMCDump.

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

Кстати Livedump / CMCDump можно использовать одновременно наряду с распределенным мониторингом через Livestatus без проблем. Некоторые экземпляры просто подключаются напрямую через Livestatus — другие используют Livedump. Livedump также может быть добавлен к одному из ведомых устройств Livestatus.

4.2. Установка Livedump

Если вы устанавливаете Checkmk Raw Edition (или CEE с ядром Nagios), используйте инструмент Liveump .Название происходит от Livestatus и Дамп статуса . Из Checkmk Версия 1.2.8p12 liveump находится прямо в пути поиска и поэтому доступен как команду. В более старых версиях вы можете найти его в ~ / share / doc / check_mk / treasures / liveump / livingump.

Сделаем следующие предположения …

… подчиненный экземпляр полностью настроен и активно контролирует хосты и службы
… главный экземпляр запущен и работает
… по крайней мере один хост отслеживается локально на главном устройстве (поскольку главный контролирует себя).

Перенос конфигурации

Сначала создайте на ведомом устройстве копию конфигураций его хоста и службы в Формат Nagios-конфигурации. Также перенаправьте вывод Liveump -TC в файл:

OMD [slave1]: ~ $  Liveump -TC> config.cfg

Начало файла будет выглядеть примерно так:

нагиос.cfg

define host {
    имя жилой
    используйте check_mk_default
    регистр 0
    active_checks_enabled 0
    passive_checks_enabled 1

}

define service {
    имя liveump-service
    регистр 0
    active_checks_enabled 0
    passive_checks_enabled 1
    check_period 0x0

}

Передайте файл мастеру (например, с помощью scp) и сохраните его там в файл ~ / etc / nagios / conf.d / directory — здесь Nagios ожидает найти данные конфигурации для хостов и сервисов. Выберите имя файла, которое заканчивается на .cfg, например ~ / etc / nagios / conf.d / config-slave1.cfg. Если возможен SSH-доступ от ведомого к ведущему, это можно сделать, например, как показано ниже:

OMD [slave1]: ~ $  scp config.cfg [email protected]: etc / nagios / conf.d / config-slave1.cfg 
[email protected] пароль:
config.cfg 100% 8071 7,9 КБ / с 00:00

Теперь войдите в мастер и активируйте изменения:

OMD [master]: ~ $ 90 489 смк -R 
Генерация конфигурации для ядра (типа nagios)...ОК
Проверка конфигурации Nagios ... ОК
Предварительная компиляция проверок хоста ... ОК
Перезапуск ядра мониторинга ... ОК

Теперь все подчиненные хосты и службы должны появиться в главном экземпляре — изначально с состоянием PEND , которое они пока сохранят:

Примечание :

С параметром -T в liveump определения шаблонов создаются в Livedump, из которого он черпает конфигурацию. Без этих Nagios невозможно запустить. Однако может присутствовать только один из них.Если вы импортируете конфигурацию с другого ведомого устройства, не должен использовать параметр -T для !
Дамп конфигурации также возможен на ядре CMC, для импорта которого требуется Nagios. Если CMC работает на вашем главном устройстве, используйте CMCDump.
Копирование и передача конфигурации должны повторяться для каждого изменения хостов или служб на ведомом устройстве.

Перенос статуса

Как только хосты будут видны в мастере, нам нужно будет настроить (обычную) передачу состояния мониторинга ведомых устройств.Снова создайте файл с liveump, но на этот раз без второстепенных вариантов:

OMD [slave1]: ~ $  Liveump> состояние

Этот файл содержит состояния всех хостов и служб в формате, который Nagios может читать прямо из результатов проверки. Начало этого файла выглядит примерно так:

состояние

host_name = myserver666
check_type = 1
check_options = 0
reschedule_check
задержка = 0,13
start_time = 1475521257.2
finish_time = 1475521257.2
return_code = 0
output = OK - 10.1.5.44: rta 0,005 мс, потеря 0% | rta = 0,005 мс; 200,000; 500,000; 0; pl = 0%; 80; 100 ;; rtmax = 0,019 мс ;;;; rtmin = 0,001 мс ;;;;

Скопируйте этот файл на мастер в каталог ~ / tmp / nagios / checkresults. Важно: Имя этого файла должно начинаться с буквы c и состоять из семи символов. С scp это будет выглядеть примерно так:

OMD [slave1]: ~ $  состояние scp [email protected]: tmp / nagios / checkresults / caabbcc 
[email protected] пароль:
состояние 100% 12 КБ 12.5 КБ / с 00:00

Наконец, создайте пустой файл на главном сервере с тем же именем и расширением .ok. Благодаря этому Nagios будет знать, что файл состояния был полностью передан и может теперь читайте в:

OMD [master]: ~ 90 489 долл. США touch tmp / nagios / checkresults / caabbcc.ok

Статус хостов / сервисов подчиненных теперь будет немедленно обновлен на главном устройстве:

С этого момента статус должен передаваться регулярно. Livedump, к сожалению, не поддерживает эту задачу, и вам придется написать сценарий самостоятельно.Скрипт liveump-ssh-recv можно найти в ~ / share / check_mk / doc / treasures / liveump, который вы можете использовать для получения обновлений Livedump (в том числе из конфигурации) на мастере по SSH. Подробности об этом можно найти в самом скрипте.

Дамп конфигурации и состояния также можно ограничить с помощью фильтров Livestatus. Например, вы можете ограничить хосты членами группы хостов mygroup:

OMD [подчиненный]: ~ $  Liveump -H "Фильтр: host_groups> = mygroup"> состояние

Дополнительная информация о Livedump — в частности, как передавать данные через зашифрованная электронная почта — ее можно найти в файле README в Каталог ~ / share / doc / check_mk / treasures / liveump.

4.3. Реализация CMCDump

CMCDump для Checkmk Micro Core, что и Livedump предназначен для Nagios — и, таким образом, это инструмент выбора для Checkmk Enterprise Editions. В отличие от Livedump, CMCDump может реплицировать полный статус хостов и сервисов (у Nagios нет необходимых интерфейсов для этой задачи).

Для сравнения: Livedump передает следующие данные:

Текущие состояния — т.е. PEND , OK , WARN , CRIT , UNKNOWN , UP , DOWN или UNREACH
Выход из
Данные производительности

CMCDump дополнительно синхронизирует:

Вывод long из подключаемого модуля
Состояние объекта в данный момент колеблется
Отметки времени для выполнения последней проверки и последнего изменения состояния
Продолжительность выполнения проверки
Задержка выполнение проверки
Порядковый номер текущей попытки проверки и текущее состояние «жесткое» или «мягкое»
подтверждено, если присутствует
Находится ли объект в настоящее время на плановом обслуживании.

Это обеспечивает более точное отображение результатов мониторинга. При импорте статуса CMC не просто имитирует выполнение проверки, скорее, используя интерфейс, разработанный для этой задачи, он передает точный статус. Помимо прочего, это означает, что в любое время операционный центр может видеть были ли проблемы подтверждены или введено ли время обслуживания.

Установка почти идентична установке Livedump, но проще, так как нет необходимости беспокоиться о возможных повторяющихся шаблонах или похожие.

Копия конфигурации делается командой cmcdump -C. Сохраните этот файл на мастер в etc / check_mk / conf.d /. Необходимо использовать расширение файла .mk:

OMD [slave1]: ~ $  cmcdump -C> config.mk 
OMD [slave1]: ~ $  scp config.mk [email protected]: etc / check_mk / conf.d / slave1.mk

Активируйте конфигурацию на мастере:

OMD [master]: ~ $ 90 489 cmk -O

Как и в случае Livedump, хосты и службы теперь будут отображаться на главном сервере в PEND состояние.Однако вы увидите по символу, который мы имеют дело с теневым объектом . Таким образом можно отличить от объекта, за которым ведется мониторинг, непосредственно на главном или «нормальном» подчиненном экземпляре:

Обычная генерация статуса достигается с помощью cmcdump без дополнительные аргументы:

OMD [slave1]: ~ $  cmcdump> состояние 
OMD [slave1]: ~ $  scp state [email protected]: tmp / state_slave1

Чтобы импортировать статус в мастер, содержимое файла должно быть записано в tmp / run / live UNIX-Socket с помощью инструмента unixcat.

OMD [master]: ~  $ unixcat tmp / run / live

Если у вас есть соединение от ведомого к мастеру через SSH без пароля все три команды можно объединить в одну — и даже не создается временный файл:

OMD [slave1]: ~ $ 90 489 cmcdump | ssh [email protected] "unixcat tmp / run / live"

Это действительно так просто! Но, как уже упоминалось, ssh / scp — это это не единственный метод передачи файлов, а конфигурация или статус также могут быть переданы по электронной почте или другому желаемому протоколу.

5. Уведомления в распределенных средах

5.1. Централизованный или децентрализованный?

В распределенной среде возникает вопрос — из какого экземпляра следует уведомления (например, электронные письма) отправляются: от отдельных ведомых устройств или от мастера? Есть аргументы в пользу обеих процедур.

Аргументы для отправки с рабов:

Более простая установка
Локальное уведомление по-прежнему возможно, если ссылка на мастер недоступна
Также работает с Checkmk Raw Edition

Аргументы для отправки от мастера:

Уведомления могут обрабатываться централизованно (например,грамм. быть перенаправлены в систему тикетов)
Подчиненные экземпляры не требуют настройки для электронной почты или SMS
Для отправки SMS через оборудование это требуется только один раз — на главном сервере

5.2. Децентрализованное уведомление

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

Просто убедитесь, что соответствующая услуга была правильно проведена. установлен на экземплярах — что смарт-хост был определен для электронной почты для пример — другими словами такая же процедура, как для настройки отдельного экземпляра Checkmk.

5.3. Централизованные уведомления

Основы

Выпуск Checkmk Enterprise Edition обеспечивает встроенный механизм централизованных уведомлений. которые можно активировать индивидуально для каждого ведомого экземпляра.Такие ведомые устройства затем направляют все уведомления ведущему устройству для дальнейшей обработки. Таким образом, централизованное уведомление не зависит от того, мониторинг настроен стандартно, или с CMCDump, или используя сочетание этих процедур. Технически говоря, центральному серверу уведомлений даже не нужно быть «хозяином». Эту задачу может взять на себя любой экземпляр Checkmk.

Если ведомый экземпляр настроен на «пересылку», все уведомления будут пересылаются прямо мастеру, как бы из ядра — эффективно в необработанном формате .После этого будут оценены правила уведомления, которые фактически решат кого и как следует уведомить. Необходимые сценарии уведомлений будут вызваны на главном сервере.

Активация спулера аварийных сигналов

Первым шагом для реализации централизованного уведомления является активация диспетчер очереди уведомлений (mknotifyd) на всех участвующих экземплярах. Это вспомогательный процесс, который требуется как для мастера, так и для на рабах . В более новых версиях Checkmk спулер уведомлений автоматически активируется.Пожалуйста, проверьте это с помощью конфигурации omd и активируйте если нужно. Этот пункт можно найти в разделе Распределенный мониторинг ➳ MKNOTIFYD .

Статус omd должен отображать процесс mknotifyd:

OMD [mysite]: ~ $ 90 489, статус OMD 
OMD [master]: статус ~ $ omd
mkeventd:  работает 
liveproxyd:  работает 
  mknotifyd:  работает  
rrdcached:  работает 
cmc:  работает 
apache:  работает 
crontab:  работает 
-----------------------
Общее состояние:  работает

Только когда активен диспетчер очереди уведомлений, точка Уведомления ➳ Буферизация уведомлений находится в глобальных настройках WATO.

Настройка TCP-соединений

Ведомый и (уведомляющий) диспетчер очереди уведомлений обмениваются данными с друг друга по TCP. Уведомления отправляются от ведомого к ведущему. Хозяин подтверждает подчиненным, что уведомления были получены, которые предотвращает потерю уведомлений даже при разрыве TCP-соединения.

Существует два варианта построения TCP-соединения:

TCP-соединение настроено от ведущего к ведомому.Здесь ведомым является TCP-сервер .
TCP-соединение настроено от ведомого к ведущему. Здесь мастером является TCP-сервер .

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

Поскольку ведомое устройство и ведущее устройство требуют разных глобальных настроек, необходимо выполнить специфичные для сайта настройки для всех ведомых устройств. Настройка мастера выполняется с использованием обычных глобальных настроек. Это связано с тем, что Checkmk в настоящее время не поддерживает никаких конкретных настроек. для локального экземпляра (= главный экземпляр). Обратите внимание — эти настройки будут автоматически унаследованы всеми ведомыми устройствами для которые не определены конкретных настроек.

Давайте сначала рассмотрим пример, в котором мастер устанавливает TCP-соединения. рабам.

Шаг 1: На ведомом отредактируйте глобальные настройки для конкретного экземпляра Уведомления ➳ Конфигурация диспетчера очереди уведомлений и активировать Принимать входящие TCP-соединения . TCP-порт 6555 будет рекомендован для входящих соединений. Если нет возражений, примите эти настройки.

Шаг 2: Теперь, аналогично, в подменю Буферизация уведомлений только на ведомом выбираем опцию Перенаправить на удаленный сайт с помощью диспетчера очереди уведомлений .

Шаг 3: Теперь на главном сервере — т.е. в обычных глобальных настройках — настройте подключение к ведомому устройству (а затем к дополнительным ведомым устройствам по мере необходимости):

Шаг 4. Установите глобальную настройку Буферизация уведомлений на Асинхронная локальная доставка диспетчером очереди уведомлений , так что главный сообщения также будут обрабатываться через тот же центральный диспетчер очереди печати.

Шаг 5: Активируйте изменения.

Установление соединения от ведомого

Если TCP-соединение должно устанавливаться от ведомого извне, процедура идентична, отличается только от описания выше на просто меняя роли хозяина и раба.

Также возможно сочетание двух процедур. В таком случае мастер должен быть установлен так, чтобы он слушал входящие соединения, а также подключение к подчиненным экземплярам. Однако во всех отношениях хозяин / раб только один из пары может установить соединение!

Тестирование и диагностика

Диспетчер очереди тревог записывает журнал в файл var / log / mknotifyd.log. В конфигурации диспетчера очереди печати уровень журнала может быть повышен, чтобы получила.При стандартном уровне логирования на мастере должно быть что-то вроде этого:

var / log / mknotifyd.log

2016-10-04 17:19:28 [5] ------------------------------------- ----------------------------
2016-10-04 17:19:28 [5] Запуск диспетчера очереди уведомлений Check_MK версии 1.2.8p12
2016-10-04 17:19:28 [5] Подробность журнала: 0
2016-10-04 17:19:28 [5] Демонизирован с PID 31081.
2016-10-04 17:19:28 [5]  Успешно подключился к 10.1.8.44:6555

Всегда файл var / log / mknotifyd.файл состояния содержит текущий статус спулер и все его подключения:

мастер: var / log / mknotifyd.state (Auszug)

Подключение: 10.1.8.44:6555
Тип: исходящий
Состояние: установлено
Сообщение о состоянии: успешно подключено к 10.1.8.44:6555
С: 1475594368 (2016-10-04 17:19:28, 140 сек назад)
Время подключения: 0,000 сек.

Версия того же файла также присутствует на ведомом устройстве.Там соединение будет выглядеть примерно так:

подчиненное устройство: var / log / mknotifyd.state (Auszug)

Подключение: 10.22.4.12:56546
Тип: входящий
Состояние: установлено
С: 1475594368 (2016-10-04 17:19:28, 330 сек назад)

Для тестирования выберите любую отслеживаемую ведомую службу и установите ее вручную. на CRIT с командой Fake check results .

Теперь на master должно появиться входящее уведомление в файл журнала уведомлений (notify.журнал):

мастер: var / log / notify.log

2016-10-04 17:27:57 ---------------------------------------- ------------------------------
2016-10-04 17:27:57 Получил файл спула 68c30b35 (myserver123; Check_MK) с удаленного хоста для локальной доставки.

То же событие на ведомом устройстве будет выглядеть так:

подчиненное устройство: var / log / notify.log

2016-10-04 17:27:23 ---------------------------------------- ------------------------------
2016-10-04 17:27:23 Получено необработанное уведомление (myserver123; Check_MK) контекст с 71 переменной
2016-10-04 17:27:23 Создание спулфайла: / omd / sites / slave1 / var / check_mk / notify / spool / f3c7dea9-0e61-4292-a190-785b4aa46a64

В глобальных настройках, а также в обычном журнале уведомлений (notify.журнал) вы также можете изменить журнал диспетчера очереди уведомлений на более высокий уровень.

Контроль намотки

После того, как вы все настроите, как описано, вы заметите, что на мастере и соответственно на рабах будет найдена новая служба, которая обязательно должна попадать в мониторинг. Это контролирует пул аварийных сигналов и его TCP-соединения. Таким образом, каждое соединение будет контролироваться дважды: один раз ведущим и один раз ведомым:

6. Файлы и каталоги

6.1. Файлы конфигурации

Путь	Описание
и т. Д. / Check_mk / multisite.d / sites.mk	Здесь WATO хранит конфигурацию подключений к отдельным экземплярам. Если интерфейс «зависает» из-за ошибки в конфигурации, чтобы он стал неработоспособным, вы можете редактировать нарушающую запись прямо в файле. Однако, если прокси-сервер livestatus активирован, впоследствии потребуется отредактируйте и сохраните хотя бы одно соединение через WATO, так как только это действие будет для этого демона должна быть создана подходящая конфигурация.
и т. Д. / Check_mk / liveproxyd.mk	Конфигурация прокси Livestatus. Этот файл будет недавно создан WATO с каждым изменением конфигурации распределенного мониторинга.
и т. Д. / Check_mk / mknotifyd.d / wato / global.mk	Конфигурация диспетчера очереди уведомлений. Этот файл будет создан от WATO при сохранении глобальных настроек.
и т. Д. / Check_mk / conf.d / distribution_wato.mk	Это генерируется на ведомых устройствах распределенным WATO и гарантирует, что ведомый контролирует только свои собственные хосты.
и т. Д. / Nagios / conf.d /	Место хранения созданных заказчиком файлов конфигурации Nagios с хостами и Сервисы. Они необходимы для использования Livedump. на мастера.
и т. Д. / Mk-livestatus / nagios.cfg	Конфигурация Livestatus для использования Nagios в качестве ядра. Здесь вы можете настроить максимально допустимое количество одновременных подключений.
и т. Д. / Check_mk / conf.d /	Конфигурация хостов и правил для Checkmk.Хранить файлы конфигурации которые генерируются здесь CMCDump. Только подкаталог wato / управляется и будет отображаться в WATO.
var / check_mk / autochecks /	Для служб, обнаруженных при обнаружении служб. Они всегда хранятся локально на ведомом устройстве.
var / check_mk / rrds /	Расположение циклической базы данных для архивирования данных о производительности при с использованием формата Checkmk-RRD (по умолчанию в Enterprise Editions )
var / pnp4nagios / perfdata /	Расположение базы данных Round-Robin с форматом PNP4Nagios ( Checkmk Raw Edition)
var / log / liveproxyd.журнал	Файл журнала для прокси Livestatus.
var / log / liveproxyd.state	Текущее состояние прокси Livestatus в удобочитаемой форме. Этот файл обновляется каждые 5 секунд.
var / log / notify.log	Файл журнала для системы уведомлений Checkmk.
var / log / mknotifyd.log	Файл журнала для диспетчера очереди уведомлений.
var / log / mknotifyd.state	Текущее состояние диспетчера очереди уведомлений в читаемой форме.Этот файл обновляется каждые 20 секунд.

Элементы обнаружения и контроля хоста

1. Введение

Услуги — это реальная «сущность» системы мониторинга. Каждый представляет собой важный винтик в вашем сложном ИТ-ландшафте. Полезность полного мониторинга стоит или падает в зависимости от того, насколько точно и полезно услуги был настроен. Наконец, мониторинг должен надежно уведомлять всякий раз, когда проблема где-то становится очевидной, но обязательно должна минимизировать ложные или бесполезные срабатывания сигнализации.

Checkmk, возможно, демонстрирует свои самые сильные стороны при настройке служб: он обладает непревзойденной и очень мощной системой для автомата обнаружение и настройка сервисов . С Checkmk нет необходимости определять каждую услугу с помощью шаблонов и индивидуальных распределений. Checkmk может автоматически и надежно определять список услуг, которые необходимо отслеживается, и в первую очередь, поддерживает его в актуальном состоянии . Это не только экономит много времени — это также делает мониторинг точным .Это гарантирует своевременное внесение ежедневных изменений в процессинговый центр. покрыты и что ни одна важная услуга не остается незамеченной.

Обнаружение сервисов в Checkmk основано на важном базовом принципе: разделение , что от , как :

Какие нужно отслеживать? → Система / var на хосте lnxsrv015
Как нужно контролировать? → при 90% занятом пространстве WARN при 95% CRIT

Что автоматически обнаруживается при обнаружении службы.это комбинация имени хоста (lnxsrv015), проверка плагин (df: проверка системы данных в Linux) и элемент (/ var). Отметьте плагины, которые могут создавать максимум одну службу на хост не требует элемента (например, подключаемый модуль проверки загрузки ЦП). В результаты обнаружения службы представлены в таблице, как показано ниже:

Хост	Контрольный плагин	Товар
lnxsrv015	df	/
lnxsrv015	df	/ вар
lnxsrv015	процессор.util
…	…	…
приложение01cz2	hr_fs	/
…	…	…

как — таким образом, пороговые значения / параметры проверки для человека services — настраивается независимо через правила. Вы можете например, определите правило, которое контролирует все системы данных с точкой монтирования / var, и пороговые значения 90% / 95%, не задумываясь о где даже существует такая система данных.Это то, что делает настройку с Checkmk так просто и понятно!

Некоторые службы нельзя установить с помощью автоматического обнаружения. Среди этих например, проверки, запрашиваемые для определенных HTTP-сайтов. Они созданы через правила, о которых вы можете узнать ниже.

2. Хост-услуги в WATO

2.1. Включение нового хоста

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

с помощью кнопки или в деталях хоста в WATO
с помощью символа в списке хостов в папке в WATO
через запись Edit services в контекстном меню службы хоста Check_MK Discovery

Когда хост был недавно добавлен, его услуги еще не были настроен, и поэтому все обнаруженные службы отображаются в Неопределившиеся услуги (в настоящее время не отслеживаются Категория :

Обычный метод — просто сохранить с помощью by an Активировать изменения — после этого хост будет в мониторинге.

2.2. Добавление недостающих сервисов

Для хоста, который уже отслеживается, этот список выглядит иначе. Вместо из нерешенных услуг (в настоящее время не отслеживаются , вы увидите отслеживаемых услуг . Если Checkmk обнаруживает на хосте что-то, что не контролируется, однако должен контролироваться , тогда список будет выглядеть что-то вроде этого:

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

2.3. Исчезнувшие услуги

В обрабатывающих центрах вещи могут не только появиться заново, но и исчезнуть. Экземпляр базы данных может быть прекращен, LUN отключен, файл система удалена и т. д. Checkmk автоматически распознает такие сервисы как исчезло . Например, в Списке услуг это будет выглядеть так:

Самый простой способ отказаться от этих услуг — щелкнуть кнопка, которая появляется в таком случае. Внимание : Причина исчезновения, конечно, может быть связана с проблема! Исчезновение файловой системы также может означать, что из-за ошибка не может быть установлена. Мониторинг ведь есть для таких случаи! Вам следует удалять службу только тогда, когда вы действительно знаете, что это нет больше требует мониторинга.

2.4. Удаление ненужных сервисов

Вам не обязательно отслеживать все, что находит Checkmk. В Разумеется, открытие работает целенаправленно и может исключить многое ненужные данные заранее.Тем не менее, откуда Checkmk может знать, например, что конкретный экземпляр базы данных был настроен только «для экспериментов», а не в производстве? Отказаться от таких сервисов можно двумя способами:

Временное отключение услуг

Просто установите флажки для служб, мониторинг которых не требуется, и отключить их или установить в статус Затрудняюсь ответить / Новый с. И естественно, не забываем обычный Активировать изменения …

Это, однако, предназначено только для временных и небольших действий, поскольку услуги, выделенные таким образом, будут выделены как , отсутствующие Checkmk, и проверка открытия (которую мы покажем вы позже ниже) тоже будете недовольны.В любом случае это было бы просто быть слишком много работы и непрактично в среде с x-тысячами Сервисы…

Безвозвратное отключение услуг

Гораздо элегантнее и надежнее постоянно игнорировать службы с помощь из набора правил Disabled services . Здесь нельзя только исключить из мониторинга отдельные сервисы, но и сформулировать правила например «Я не хочу отслеживать службы, начиная с , резервное копирование на хост myhost.

Вы можете получить доступ к правилу через WATO ➳ Host & Service Parameters ➳ Monitoring Configuration.

После того, как вы сохранили правила и вернетесь к списку служб хоста, вы будет видеть отключенные службы в разделе Отключенные службы .

2,5. Освежающие услуги

Есть ряд подключаемых модулей, замечающих вещей во время обнаружения. Например, плагин для сетевых интерфейсов проверяет скорость, установленную на интерфейс во время открытия.Зачем? Чтобы предупредить вас в если это меняется! Когда интерфейс иногда установлен на 10 Мбит, а иногда и на 1 Гбит — это скорее показатель неисправного автосогласования.

Что происходит, когда это изменение желательно и должно быть принято как ОК от сейчас на?

Либо — убрать услугу через чекбокс (нужно будет сохранить после удаление) и повторно добавить его позже.

Или — нажмите — с этим все хоста услуги будут обновлены и определены заново.Это, естественно, намного проще, но только если вы не хотите, чтобы отдельные службы находились в состоянии ошибки.

2.6. Особые условия с SNMP

Есть несколько специальных функций для устройств, которые контролируются через SNMP. Вы можете узнать об этом в статье о SNMP.

3. Массовое обнаружение — одновременное обнаружение на нескольких хостах

Если вы хотите выполнить обнаружение нескольких хостов одним действием, вы можете упростить работу с WATO Массовые операции.Во-первых, выберите хосты, на которых должно быть обнаружено выполнено. Для этого есть несколько вариантов:

В папке установите флажки для отдельных хостов и нажмите
Поиск хостов с поиском хостов, а затем нажмите в результатах поиска
Щелкните в папке

С третьим вариантом вы также можете выполнить рекурсивное обнаружение службы во всех подпапках. Во всех трех вышеперечисленных вариантах следующий шаг будет приведет вас к следующему диалогу:

В Mode вы найдете точно такие же параметры, как и в сервисе WATO список, который мы обсуждали ранее.

В разделе Selection вы снова можете управлять выбором хоста. Это в первую очередь разумно, если вы выбрали их через папку, а не через флажки. Большинство параметров предназначены для ускорения открытия:

Включать только те узлы, которые не смогли выполнить предыдущее обнаружение	Хосты, для которых ранее обнаружение службы с помощью массовых операций не удалось (например, потому что хост был недоступен в то время), помечаются с символом.Эта опция позволяет открытие будет повторяться только для этих хостов.
Включить только узлы с неудачной проверкой обнаружения	Это ограничивает обнаружение такими хостами, для которых Ошибка обнаружения. Когда ты работаешь с Discovery Check — это хороший способ значительно ускорить обнаружение много хозяев. Комбинация с Refresh all services (tabula rasa) однако в этом случае опция не имеет смысла, поскольку может исказить статус существующих услуг.
Исключить узлы, на которых агент недоступен	Недоступные узлы вызывают длительные задержки во время обнаружения из-за таймауты подключения. Это может сильно повлиять на эффективность открытия большее количество хостов. Если хосты уже в мониторинге — а это знает, что хосты DOWN — вы можете обойти их здесь и таким образом избежать таймауты.

Параметры производительности предопределены так, что Full Scan всегда выполняется на устройствах SNMP.Если вас не интересуют новые плагины обнаружение можно значительно ускорить, если не выбирать эту опцию. Работа без данных кеша рекомендуется только в исключительных случаях. Особенно для хостов, которые контролируются с помощью агентов Checkmk — как назло это — может случиться так, что сообщения журнала «потребляются» при обнаружении, а не получить производственный чек.

10, установленное в Количество хостов для одновременной обработки означает, что десять хостов всегда обрабатываются за одно действие.Это достигается внутри с HTTP-запросом. Если вы столкнулись с проблемами тайм-аута из-за некоторых хостов требуется много времени для обнаружения, вы можете попробовать установить это число ниже (в ущерб общему затраченному времени).

Как только вы подтвердите диалог, начнется процедура, и вы сможете наблюдать за его прогрессом:

4. Проверить параметры в сервисах

Многие подключаемые модули проверки можно настроить с помощью параметров. Самый распространенный Практика — это установка порогов для WARN и CRIT .Параметры могут однако составить гораздо сложнее, как показано в этом примере контроль температуры с помощью Checkmk:

Параметр проверки для услуги состоит из трех частей:

Каждый плагин имеет значение по умолчанию для параметра.
Некоторые плагины устанавливают значения во время обнаружения (см. Выше).
Параметры могут быть установлены с помощью правил.

Параметры из правил имеют приоритет над параметрами, установленными при обнаружении, и эти параметры в свою очередь имеют приоритет над значениями по умолчанию.Для сложных параметров, в которых отдельные подпараметры устанавливаются с помощью флажков (как в случае с температурой например), эти правила приоритета применяются отдельно для каждого подпараметра. Итак, если вы установите только один подпараметр с помощью правил, остальные сохранят свои соответствующие значения по умолчанию. Таким образом можно, например, активировать тренд. расчет температур по одному правилу и по другому набору правил пороговое значение температуры для физического сенсорного устройства. Полный набор параметров будет затем составлен из обоих правил.

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

5. Настройка обнаружения службы

Ранее мы показали, как можно настроить обнаружение служб для подавления отображения нежелательных служб.Кроме того, есть дополнительные наборы правил для ряда плагинов. которые влияют на поведение обнаружения с помощью этих подключаемых модулей. Не только есть ли настройки для без элементов , есть также те, которые активно находите предметы или собирайте их в группы. Именование предметов иногда также является проблемой — например, для тех коммутаторов, где вы можете выбрать на описании или псевдониме, которое будет использоваться в качестве элемента (который будет использоваться в имя службы) вместо идентификатора интерфейса.

Все наборы правил, относящиеся к обнаружению сервисов, можно найти в Параметры хоста и служб ➳ Параметры обнаруженных служб ➳ Обнаружение — автоматическое обнаружение служб .Не путайте эти наборы правил с наборами, предназначенными для параметризации актуальные услуги. Фактически у ряда плагинов есть два набора правил — один за открытие и один за параметры. Вот несколько примеров.

5.1. Мониторинг процессов

Для Checkmk было бы мало смысла просто определять службу для мониторинга каждый процесс, найденный на хосте. Большинство процессов либо не представляют интереса или присутствуют только временно. По крайней мере, есть сотни процессы, запущенные на типичном сервере Linux.

Следовательно, для услуг мониторинга вам необходимо работать с Ручные проверки или — и это намного больше элегантный — с помощью набора правил Обнаружение процесса , чтобы сообщить службе обнаружение, какие процессы следует искать. Таким образом вы всегда можете разрешить автоматическое включение мониторинга, когда определенно интересный процесс находится на хосте.

На следующем изображении показано правило из набора правил Обнаружение процесса , которое ищет процессы, выполняющие программу / usr / sbin / apache2.В этом примере сервис ( Захватить пользователя из найденных процессов ) будет создается для каждого пользователя операционной системы, для которого такой процесс находится. Сервис будет называться Apache% u, где% u будет заменено именем пользователя. Для порога количество процессов экземпляры будут установлены на 1/1 (минимум) и 30/60 (максимум) соответственно:

Обратите внимание, что предопределенные пороговые значения называются Параметры по умолчанию для обнаруженных служб . Вы можете назначить их, а также все другие сервисы — через правила.Напоминаем: приведенные выше правила настраивают сервис открытие — какой . Если услуги присутствуют впервые цепочка правил Состояние и количество процессов отвечает за пороги.

Тот факт, что вы можете устанавливать пороговые значения во время обнаружения, помогает удобство. Однако есть одна загвоздка: изменения только в правиле обнаружения вступят в силу с следующее открытие . Если вы измените пороги, вы нужно будет запустить новое открытие.Если, однако, вы используете правило только для Откройте для себя услуги (, что ) и набор правил Состояние и количество процессов для как , то у вас не будет Эта проблема.

Чтобы отслеживать определенные или отдельные процессы на хосте Windows, у вас просто есть указать имя файла (включая расширение) без пути в поле Исполняемый . Вы можете найти все эти имена на вкладке сведений в Windows. Например, диспетчер задач. В правиле Process Discovery это могло выглядеть так: это для процессов svchost:

Дополнительную информацию об обнаружении процессов можно найти в интерактивной справке. для этого набора правил.

5.2. Сервисы мониторинга под Windows

Обнаружение и параметризация мониторинга служб Windows аналогичен процессам и управляется наборами правил Windows Service Discovery ( what ) и Windows Services ( how ) соответственно. Вот пример правила, которое отслеживает две службы:

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

5.3. Мониторинг портов коммутатора

Checkmk использует ту же логику для мониторинга сетевых интерфейсов на серверах и порты на коммутаторах Ethernet. С портами коммутатора существующие варианты для управление обнаружением сервисов особенно интересно, хотя (в отличие от процессов и служб Windows) обнаружение изначально функционирует без правил.То есть по умолчанию Checkmk автоматически контролирует все физические порты, которые в настоящее время находятся в рабочем состоянии. Применимый набор правил называется Network Interface and Switch Port Discovery и предлагает многочисленные параметры настройки, которые кратко описаны здесь:

Следующие параметры являются наиболее важными:

Использование описания или псевдонима в именах служб
Ограничение или расширение типов или имен контролируемых интерфейсов

6.Настройка услуг вручную

В некоторых случаях автоматическое обнаружение службы не имеет смысла. Это всегда так, если вы хотите добиться соблюдения специальное руководство . Как мы видели в предыдущей главе, вы можете разрешить мониторинг служб Windows для автоматической настройки, когда они найдены. Что происходит, когда отсутствие такой услуги представляет проблему? Например:

Определенный антивирусный сканер должен быть установлен на каждом хосте Windows.
NTP должен быть настроен на каждом хосте Linux.

В таких случаях вы можете установить услуги вручную. Отправная точка для этого — Manual Checks WATO модуль. В основе этого лежит набор наборов правил, которые имеют точно такие же имена, как и наборы правил, используемые для настройки параметров для этих проверок.

Однако правила отличаются в двух пунктах:

Это правила для хостов , а не для сервисов. Службы будут созданы в соответствии с правилами
Поскольку обнаружение не происходит, вы должны выбрать подключаемый модуль проверки, который будет использоваться для проверки

В следующем примере показано тело Состояние синхронизации времени NTP Правило под Ручные проверки :

Здесь, помимо пороговых значений, устанавливается подключаемый модуль проверки (например,грамм. хрония или ntp.time). Для подключаемых модулей проверки, которым требуется элемент, вы также должны укажите их. Например, это необходимо для oracle_processes плагин, который требует, чтобы отслеживались детали SID базы данных:

Определенная таким образом ручная служба будет установлена на всех хостах для которые применяются эти правила. Теперь будет три возможных условия для собственно мониторинг:

Хост установлен правильно, а служба — OK .
Агент уведомляет, что запрошенная служба не запускается или имеет проблему. Затем служба помечает CRIT или UNKNOWN .
Агент не предоставляет никакой информации, например, потому что NTP даже не установлен. Затем служба остается в PEND , а служба Checkmk переходит в WARN с уведомлением об отсутствии соответствующего раздела в данных агента.

Вам никогда не понадобится большинство наборов правил в Ручные проверки модуля , они только присутствуют для полноты картины.Наиболее частые случаи ручных проверок:

Мониторинг служб Windows (набор правил: Службы Windows )
Мониторинг процессов (набор правил: Состояние и количество процессов )

7. Проверка обнаружения

Во введении мы обещали, что Checkmk не только определяет список сервисов автоматически, он может также поддерживать его в актуальном состоянии . Это также естественно иметь возможность вручную запустить массовое обнаружение для время от времени все хозяева.

7.1. Автоматическая проверка неконтролируемых услуг

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

Подробную информацию о неконтролируемых или пропавших без вести услугах можно найти в Длинный вывод плагина проверки в деталях сервиса:

Список серверов хоста в WATO можно легко получить через Discovery Проверьте контекстное меню с помощью записи Edit services .

Если ваш экземпляр был обновлен с более старой версии, вы должны установить эту проверку вручную. Установка и параметризация Discovery Проверка очень просто выполняется с помощью набора правил Periodic service discovery Rule set. В области параметров правила у вас есть следующая установка параметры:

Для устройств SNMP, наряду с интервалом, в котором должна выполняться проверка, и состояние мониторинга для случаев неконтролируемых или исчезнувших услуг, вы также можете выбрать, должно ли выполняться сканирование по протоколу SNMP.

7.2. Автоматическое добавление услуг

Недостающие услуги могут быть автоматически добавлены к проверке обнаружения. К этому и активируйте опцию Автоматически обновлять конфигурацию службы , что сделает доступными дополнительные параметры.

Наряду с дополнениями в Mode вы также можете удалить лишнее. служб, или даже удалить все существующие службы и выполнить полностью новый открытие ( Обновить ). Оба варианта следует использовать осторожно! Исчезнувший сервис может указать на проблему! Программа Discovery Check просто удалит такие услуга и убаюкивает вас мыслью, что все в порядке.Обновление особенно рискованно. Например, проверка портов переключения займет только порты, которые включены в мониторинг. Порты со статусом «не работает» будут восприниматься как исчезнувшие и быстро удаляться из Discovery Check!

Необходимо рассмотреть еще одну проблему: добавление услуг или даже автоматический Активировать изменения может отвлекать вас — администратора — когда вы выполнение конфигурации. Теоретически может случиться так, что пока вы работая над правилами и настройками, в этот момент активируется проверка обнаружения ваши изменения.WATO может только всегда активировать все изменения! Для того, чтобы чтобы избежать таких ситуаций, вы можете перенести время для этой функции, на ночь например. На изображении выше показан пример этого.

Обнаружение и активация группы для настроек до гарантирует, что не каждая недавно обнаруженная услуга сразу вызывает Активировать изменения — скорее будет указанное время ожидания, чтобы несколько изменений могут быть активированы одним действием.Даже если открытие check установлен на интервал в два часа и более, это относится только к каждому хосту отдельно. Проверки не выполняются одновременно для каждого хоста, что это хорошо, так как проверка обнаружения требует значительно больше ресурсов чем обычная проверка.

8. Пассивные услуги

Пассивные сервисы — это те сервисы, которые Checkmk не инициирует активно, а путем проверки регулярно поступают результаты из внешних источников. Это обычно происходит через командный канал ядра.Вот пошаговая процедура для создание пассивного сервиса:

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

На изображении также показано, как можно проверить, регулярно ли проводятся проверки. получила. Если они не появляются дольше десяти минут, служба будет автоматически помечена как НЕИЗВЕСТНО .

После Активировать изменения новая услуга начнет свою жизнь в PEND состояние:

Отправка результата проверки теперь происходит в командной строке через эхо команды PROCESS_SERVICE_CHECK_RESULT в ~ / tmp / run / nagios.cmd командный канал.

Синтаксис соответствует обычным соглашениям Nagios, включая текущий отметка времени в квадратных скобках. В качестве аргумента с нужной вам командой имя хоста (например, myhost) и имя выбранной службы (например, BAR). Два последующих аргумента снова являются статусом (0 … 3) и выход плагина. Отметка времени создано с помощью $ (date +% s):

OMD [mysite]: ~ $  echo "[$ (date +% s)] PROCESS_SERVICE_CHECK_RESULT; myhost; BAR; 2; Произошло что-то плохое"> ~ / tmp / run / nagios.cmd

Сервис сразу показывает свой новый статус:

Если вы знакомы с инструментом Nagios NSCA , вы можете продолжить используя его также с Checkmk.

Сначала вам нужно разрешить одну зависимость, установив libmcrypt на свой Checkmk сервер.

Debian / Ubuntu

root @ linux #  apt-get install libmcrypt4

Red Hat / CentOS

root @ linux #  yum install libmcrypt

SLES

root @ linux #  zypper установить libmcrypt

После этого вы можете активировать приемник NSCA с помощью omd config и при необходимости измените конфигурацию NSCA, которая находится в разделе etc / nsca / nsca.cfg:

OMD [mysite]: ~ $  omd stop 
OMD [mysite]: ~ $  Конфигурация omd устанавливает NSCA на 
OMD [mysite]: ~ $  набор конфигурации omd NSCA_TCP_PORT 5667 
OMD [mysite]: ~ $ 90 489 vim и т. Д. / Nsca / nsca.cfg 
OMD [mysite]: ~ $  omd start

Теперь система готова к приему результатов пассивной проверки через NSCA.

9. Обнаружение службы в командной строке

Графический интерфейс в порядке, но старая добрая командная строка иногда все еще практично — будь то автоматизация или просто возможность опытного пользователя работать быстро.Обнаружение службы можно запустить с помощью cmk -I команда в командной строке. Есть пара переменных в этот процесс. Для всех этих случаев рекомендуется использовать параметр -v, чтобы вы можете видеть, что происходит. Без -v Checkmk ведет себя как хорошо старый традиционный Unix — пока все в порядке, ничего не говорит.

С помощью простого «-I» найдите всех хостов по новым службам:

OMD [mysite]: ~ $ 90 489 cmk -vI 
коммутатор-cisco-c4000:
Ничего нового

коммутатор-cisco-c4500:
Ничего нового

коммутатор-cisco-c4500-2:
Ничего нового

коммутатор-cisco-c4500-3:
 Ничего нового

С -I вы также можете ввести одно или несколько имен хостов по порядку только открывать их.Это дополнительно имеет второй эффект — тогда как an -I на всех хостах в основном работает только с кешированными данными , Checkmk всегда работает с свежими данными с явно назначенного хоста!

OMD [mysite]: ~ $ 90 489 cmk -vI myhost123

Кроме того, вы можете фильтровать с помощью тегов:

OMD [mysite]: ~ $  cmk -vI @mytag

Это приведет к обнаружению всех хостов с тегом хоста mytag. Фильтрация с помощью тегов доступна для всех параметров cmk, которые принимают несколько хостов.

Используя параметры —cache и, соответственно, —no-cache, вы может явно определять использование кеша.

Дополнительные выходы можно получить с помощью второй -v. На основе SNMP устройства, вы даже можете увидеть каждый OID, полученный с устройства:

OMD [mysite]: ~ $ 90 489 cmk -vvI myswitch223 
Обнаружение сервисов на myswitch223:
myswitch223:
 Сканирование SNMP:
       Получение OID .1.3.6.1.2.1.1.1.0: выполнение SNMP GET из .1.3.6.1.2.1.1.1.0 на коммутаторе
=> ['Управляемый коммутатор 24G'] OCTETSTR
Управляемый коммутатор 24G
       Получение OID.1.3.6.1.2.1.1.2.0: выполнение SNMP GET из .1.3.6.1.2.1.1.2.0 на коммутаторе
=> ['.1.3.6.1.4.1.11863.1.1.3'] OBJECTID
.1.3.6.1.4.1.11863.1.1.3
       Получение OID .1.3.6.1.4.1.231.2.10.2.1.1.0: выполнение SNMP GET для .1.3.6.1.4.1.231.2.10.2.1.1.0 на коммутаторе
=> [None] NOSUCHOBJECT
не удалось.
       Получение OID .1.3.6.1.4.1.232.2.2.4.2.0: выполнение SNMP GET для .1.3.6.1.4.1.232.2.2.4.2.0 на коммутаторе
=> [None] NOSUCHOBJECT
не удалось.

Полное обновление услуг (tabula rasa) может быть выполнено с двойной -II:

OMD [mysite]: ~ $  cmk -vII myhost123 
Обнаружение сервисов на myhost123:
myhost123:
      1  цп.грузы
      1  процессорных ниток
      6  cups_queues
      3  df
      1  diskstat
      3  ядро
      1  kernel.util
      3  livestatus_status
      1  lnx_if
      1  lnx_thermal

Вы также можете ограничить все это одним плагином проверки. Для этого опция —checks =, и она должна быть помещена перед именем хоста:

OMD [mysite]: ~ $  cmk -vII --checks = df myhost123 
Обнаружение сервисов на myhost123:
myhost123:
      3  df

Когда вы закончите, вы можете активировать изменения с помощью cmk -O (cmk -R с Nagios Core):

OMD [mysite]: ~ $ 90 489 cmk -O 
Генерация конфигурации для ядра (типа cmc)...ОК
Конфигурация упаковки ... ОК
Перезагрузка ядра мониторинга ... ОК

А при обнаружении ошибки при обнаружении …

OMD [mysite]: ~ $  cmk -vII --checks = df myhost123 
    ПРЕДУПРЕЖДЕНИЕ:  Исключение в функции обнаружения типа проверки 'df': глобальное имя 'bar' не определено
  ничего

… с дополнительной —debug вы можете создать подробный Python стековая трассировка места неисправности:

OMD [mysite]: ~ $  cmk --debug -vII --checks = df myhost123 
Обнаружение услуг на сегодня:
Cегодня:
Отслеживание (последний вызов последний):
  Файл "/ omd / sites / heute / share / check_mk / modules / check_mk.py ", строка 5252, в 
    do_discovery (имена хостов, check_types, visible_I == 1)
  Файл "/omd/sites/heute/share/check_mk/modules/discovery.py", строка 76, в do_discovery
    do_discovery_for (имя хоста, check_types, only_new, use_caches, on_error)
  Файл "/omd/sites/heute/share/check_mk/modules/discovery.py", строка 96, в do_discovery_for
    new_items = discover_services (имя хоста, check_types, use_caches, do_snmp_scan, on_error)
  Файл "/omd/sites/heute/share/check_mk/modules/discovery.py", строка 677, в discover_services
    для элемента строка параметров в discover_check_type (hostname, ipaddress, check_type, use_caches, on_error):
  Файл "/ omd / sites / heute / share / check_mk / modules / discovery.py ", строка 833, в discover_check_type
    Discover_items = discovery_function (информация)
  Файл "/ omd / sites / heute / share / check_mk / check / df", строка 91, в inventory_df
    foo = bar
NameError: глобальное имя bar не определено

9.1. Обзор опций

Подведем итоги — все возможности вкратце:

cmk -I	Откройте для себя новые услуги
cmk -II	Удалить и заново открыть все службы (tabula rasa)
-v	Подробно: отображать хосты и обнаруженные службы
-vv	Очень подробный: отображать точный протокол всех операций
—checks = foo	Выполнить обнаружение (а также tabula rasa) только для указанного подключаемого модуля проверки
@foo	Выполнить обнаружение (а также tabula rasa) только для хостов с указанным тегом
— кэш	Принудительное использование данных кэша (обычно используется по умолчанию, только если хост не указан)
— без кеширования	Получить свежие данные (обычно по умолчанию, только если указано имя хоста)
— отладка	Отмена в случае ошибки и отображение полной трассировки стека Python
cmk -O	Активировать изменения ( Enterprise Editions с CMC в качестве ядра)
cmk -R	Активировать изменения ( Raw Edition с Nagios в качестве ядра)

9.2. Сохранение в файлы

результат обнаружения службы — таким образом, как объяснялось ранее, таблицы имен хостов, проверочные плагины, элементы и идентифицированные параметры — можно можно найти в папке var / check_mk / autochecks. Здесь на каждый host есть набор данных, в котором хранятся автоматически обнаруженные службы. Если вы не повредите синтаксис Python этого набора данных, вы можете изменить или удалить отдельные строки вручную. При удалении набора данных удаляются все службы и снова помечает их как квази «неконтролируемые».

var / check_mk / autochecks / myhost123.mk

[
  ('cpu.loads', Нет, cpuload_default_levels),
  ('cpu.threads', Нет, Thread_default_levels),
  ('diskstat', u'SUMMARY ', diskstat_default_levels),
  ('ядро', u'Контекстные переключатели ', kernel_default_levels),
  ('ядро', u'Основные ошибки страницы ', kernel_default_levels),
  ('ядро', u'Процесс создания ', kernel_default_levels),
  ('kernel.util', Нет, {}),
  ('livestatus_status', u'stable ', {}),
  ('lnx_if', u'2 ', {' состояние ': [' 1 '],' скорость ': 0}),
  ('lnx_thermal', u'Zone 0 ', {}),
  ('мем.linux ', Нет, {}),
  ('mknotifyd', u'today ', {}),
  ('mknotifyd', u'stable ', {}),
  ('mounts', u '/', [u'data = order ', u'errors = remount-ro', u'latime ', u'rw']),
  ('ntp.time', Нет, ntp_default_levels),
  ('omd_apache', u'stable ', Нет),
  ('tcp_conn_stats', Нет, tcp_conn_stats_default_levels),
  ('время безотказной работы', Нет, {}),
]

10. Группы услуг

10.1. Зачем нужны сервисные группы?

Итак, вы узнали, как включать службы в мониторинг. Теперь нет смысла смотреть на списки тысяч сервисов и / или всегда должны пройти просмотры хоста.Например, если вы хотите просмотреть всю файловую систему или обновлять сервисы вместе, вы можете просто собирать группы таким же образом, как и с группами узлов.

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

10.2. Создание сервисных групп

Сервисные группы можно найти по адресу WATO ➳ Host & Service Groups . По умолчанию здесь отображаются группы узлов сети, поэтому сначала нажмите. Там вы найдете аналогичное меню, с помощью которого можно определить группы услуг:

Создать сервисную группу просто: Создайте группу через и присвоить имя, которое нельзя впоследствии изменить, а также значимый псевдоним:

10.3. Добавление услуги в сервисную группу

Для присвоения услуг группам услуг необходим набор правил найдено в WATO ➳ Параметры хоста и службы ➳ Группировка .Теперь используйте для создания нового правила в нужной папке. Сначала вы указываете, какой группе услуг назначить услуги, например, myservicegroup или его псевдоним My Service Group 1.

Самое интересное теперь следует в разделе Условия . С одной стороны, вы можете использовать папки, теги хоста и явные имена хостов, чтобы установить ограничения за пределами услуг. Во-вторых, вы называете услуги, которые хотите сгруппировать, такие как Filesystem и myservice для создания набора файловых систем.Спецификация услуг размещается здесь в виде регулярные выражения. Это позволяет точно определять группы.

10.4. Проверка сервисных групп для услуги

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

10,5. Использование сервисных групп

Как уже упоминалось, сервисные группы используются в нескольких местах: просмотры, Карты, уведомления и обработчики предупреждений NagVis.Для новых представлений важно использовать Servicegroups в качестве источника данных. Конечно, виджет Views также содержит предопределенные представления для групп услуг, например четкое резюме:

Щелкнув по названию группы услуг, вы получите полный обзор всех услуг соответствующей группы.

Если вы используете группы обслуживания на картах NagVis, вы получите сводку обслуживания группы, открываемые в меню при наведении курсора на один значок:

При использовании групп услуг в уведомлениях и обработчики предупреждений, они доступны как условия / фильтры, из которых вы можете использовать один или несколько:

11.Подробнее о Check plug-ins

11.1. Краткое описание их функциональности

Проверочные плагины необходимы для создания сервисов в Checkmk. Каждая служба использует подключаемый модуль проверки для определения своего статуса, создания / поддержки показателей и т. Д. При этом такой плагин может создавать одну или несколько служб для каждого хоста. Чтобы можно было различать несколько служб из одного и того же плагина, необходим элемент Item . Например, для службы Filesystem / var элементом является текст / var. В случае подключаемых модулей, которые могут создавать не более одной службы на хост, Использование ЦП), например, элемент пуст и не отображается.

11.2. Доступные плагины проверки

Список всех доступных подключаемых модулей проверки можно найти в разделе WATO ➳ Проверить подключаемые модули . Здесь можно искать отдельные плагины, отфильтрованные по различным категориям:

Для каждого плагина будут показаны три столбца информации: описание услуги (Тип of Check), имя подключаемого модуля проверки (Plug-in Name) и его совместимых источников данных (Agents):

CC Checker — Бесплатная проверка кредитных карт

Mr-Checker
Щиток приборов
Содержимое Блог
Facebook
термины
Приборная панель
Присоединяйтесь к нашей группе Telegram
Проверка карты
Другие инструменты
Метод
Контейнер для мусора
Генератор кредитных карт
Получите бесплатные кредитные карты

Панель управления — Mr-checker Объявление
3
# Около Детали
.

Как проверить дмрв

Неисправность ДМРВ, симптомы

Чем могут быть вызваны неисправности датчика массового расхода воздуха

Как определить неисправность ДМРВ

Чистка датчика массового расхода воздуха

Что еще стоит почитать

ДМРВ ВАЗ 2114: Проверка, Признаки неисправности, Цена

Вступление

Для чего нужен ДМРВ

Из чего состоит

Признаки неисправности

Стоимость

Проверка

Проверка цепи питания

Проверка датчика

Замена

Пошаговый процесс замены

Как проверить датчик массового расхода воздуха: признаки неисправности

1 ДМРВ – принцип работы

Похожие статьи

2 Поломки расходомеров – из-за чего они бывают

3 Признаки неисправности ДМРВ

4 Как проверить работоспособность расходомера

5 Датчик массового расхода воздуха неисправен – что делать?

Как проверить дмрв на ваз-2110 мультиметром: инструкция с видео

Для чего нужен ДМРВ?

Возможные неполадки при выходе из строя ДМРВ

Диагностика неисправностей ДМРВ

Как заменить датчик массового расхода воздуха ВАЗ?

Как продиагностировать ДМРВ ВАЗ 2110 и выполнить его замену

Как диагностировать неисправность ДМРВ

Самостоятельный анализ неполадок ДМРВ

Как заменить ДМРВ в домашних условиях

Также ознакомьтесь

Проверка ДМРВ ВАЗ 2110 на видео:

Основные принципы ремонта, замены и обслуживания ДМРВ на ВАЗ 2110

Возможные неисправности и способы их устранения

Методы проверки датчика на работоспособность

Отключение

Диагностика с помощью мультиметра

Визуальный осмотр

Инструкция по замене и установке своими руками

Фотогалерея «Меняем расходомер»

Особенности чистки регулятора

Заключение

Видео «Особенности замены расходомера в гаражных условиях»

Проверка ДМРВ (датчика массового расхода воздуха): мультиметром, визуально

Что такое ДМРВ?

В движении

Мультиметром

Визуально

Можно ли восстановить датчик массового расхода воздуха?

Проверка ДМРВ своими руками Ваз. — logbook Lada 2110 2005 on DRIVE2

Как проверить ДМРВ на ВАЗ 2110? | КТО?ЧТО?ГДЕ?

Способы проверки ДМРВ на автомобиле ВАЗ 2110

Визуальный осмотр

Отключение датчика

Как проверить ДМРВ?

Способ №1. Отключение DRM

Метод № 2. Диагностика мультиметра

Метод № 3. Визуальная диагностика

Метод № 4. Прошивка-альтернатива ЭБУ

Dynamic runtime AV checker, который обеспечивает проверки выполнения в различных антивирусных системах и ОС Windows.

Проверка AV во время выполнения

Тест операционной системы во время выполнения

Интеллектуальные отчеты

Различные типы файлов

Умные уведомления

Проактивное обнаружение и обнаружение памяти

Регулярные обновления AV

Прозрачные планы

Отличная масштабируемость

Полностью автоматические платежи

Просмотр функциональных скриншотов

Сервисные проверки

Обслуживание — Запущено

Плагины Nagios

NCPA

NSClient ++ через check_nt

NSClient ++ через check_nrpe