Побьют меня за мой язык, но скажу следующий тезис. Системный администратор - это высококвалифицированная(ый) уборщица(к). Т.е. это та должность которая непосредственно не влияет на функционирование проекта. К чему я это? А к тому, что на вверенной тебе территории ты должен знать что происходит, и уделять при этом как можно меньше сил. Это от того, что сделаешь ли ты на 5+ или на 3-, никто в компании об этом не узнает, до момента когда всё не рухнет(т.е. станет совсем грязно - прим. уборщицы(ка)). Т.е. непосредственный твой начальник - это возглас работников "шо за нах(WTF)". Т.е. следить за всем приходится всегда тебе.
А что мы знаем о средствах слежения. Бинокль, радио метки, радарные комплексы... не чего-то они мне ни как не помогают. Следим мы по статусу WTF(см. выше). Т.к. 24 часа в сутки мониторить серваки не возможно, то кто-то это должен делать за тебя. Можно нанать пару китайцев или индусов (да именно так работают в крупных компаниях), но у нас бюджет. Да и время реакции в 15-30 минут не критично.
В общем какие бывают статусы. Они и по жизни всегда такие.
1. Всё в порядке (зеленый).
2. Внимание, стоит насторожиться (желтый).
3. Пришла маленькая сибирская лисичка (красный).
Самый важный статус для нас, это желтый. Т.к. если все работает, то это хорошо, если не работает, то уже как правило поздно.
По этому принципу и работают большинство служб мониторинга. Т.е. сервер периодично опрашивает объект на предмет каких-либо данных, и на основании какого-то критерия выставляет статус, а так же информирует пользователя о смене статуса.
Что нужно часто смотреть на серверах.
1. Не контролируемы рост процессов, на боевом сервере это скорее негативный показатель, т.к. обычно процессы сильно не растут. Причина и почему это случается, что зависит от самого процесса. Например в проектах базирующихся на fork-процессах, часто при новом подключении клиент порождается процесс-ребенок который выполнив все необходимые функции будет закрыт. Если например закончится место на жестком диске, то процесс может "зависнуть" и ждать освобождение места. А клиенты-то прибывают.
2. Свободное место в оперативной памяти под фактические процессы. Часто оперативная память используется не полностью. И всё работает шустро, но как только вы уйдете в свап (файл или раздел на ЖД, который нужен в случае переполнения памяти), то всё ооооооочеееееень затормозит.
3. Сетевой ответ от сервера и качество сигнала - без комментариев.
4. Место на разделах - если закончится, то начинается апокалипсис.
5. Шаблонный ответ от необходимых сервисов. Тут несколько вариантов, а точнее ступеней.
Ступень первая - сканирование открытого порта. Позволяет узнать вообще работает или не работает сервис. Например сканировать 80 порт на предмет ответа веб-сервера.
Ступень вторая - подключение к порту, снятие данных и сравнение данных. В случае с веб-сервером можно спокойно создать файл index.html в котором будет "it works". И проверять, есть ли "it works" или нет.
Ступень третья - имитация деятельности. В общем самая сложная штука, напоминает тесты при создании программ. Сложно, но позволяет проводить контроль практически любых событий.
Что важно помнить, что служба мониторинга должна отрабатывать ключевые события. Т.е. не надо смотреть всё и вся, а только то, что нужно, иначе усложнишь себе жизнь.
А так же надо помнить, что не все события и ошибки можно отловить. Например, у меня , после обновления, странным образом упал недавно dbmail, причем по всем характеристикам системы он был в рабочем состоянии, а из-за него почта не принималась.
Что касательно уведомлений, то тут всё просто. Лучше всего - банальный смс. Ну или email, если телефон отслеживает статус почты. А теперь вспомним про пейджеры. Они в этом плане удобнее телефонов, т.к. по последнему иногда ещё и разговариваешь.
Уведомления, в идеальном случае, лучше делать нескольким людям. На всякий случай.
Так же можно завести тикет систему, где можно открыть задание для персонала по исправлению ошибки.
В следующий раз я расскажу про службу мониторинга nagios.
А что мы знаем о средствах слежения. Бинокль, радио метки, радарные комплексы... не чего-то они мне ни как не помогают. Следим мы по статусу WTF(см. выше). Т.к. 24 часа в сутки мониторить серваки не возможно, то кто-то это должен делать за тебя. Можно нанать пару китайцев или индусов (да именно так работают в крупных компаниях), но у нас бюджет. Да и время реакции в 15-30 минут не критично.
В общем какие бывают статусы. Они и по жизни всегда такие.
1. Всё в порядке (зеленый).
2. Внимание, стоит насторожиться (желтый).
3. Пришла маленькая сибирская лисичка (красный).
Самый важный статус для нас, это желтый. Т.к. если все работает, то это хорошо, если не работает, то уже как правило поздно.
По этому принципу и работают большинство служб мониторинга. Т.е. сервер периодично опрашивает объект на предмет каких-либо данных, и на основании какого-то критерия выставляет статус, а так же информирует пользователя о смене статуса.
Что нужно часто смотреть на серверах.
1. Не контролируемы рост процессов, на боевом сервере это скорее негативный показатель, т.к. обычно процессы сильно не растут. Причина и почему это случается, что зависит от самого процесса. Например в проектах базирующихся на fork-процессах, часто при новом подключении клиент порождается процесс-ребенок который выполнив все необходимые функции будет закрыт. Если например закончится место на жестком диске, то процесс может "зависнуть" и ждать освобождение места. А клиенты-то прибывают.
2. Свободное место в оперативной памяти под фактические процессы. Часто оперативная память используется не полностью. И всё работает шустро, но как только вы уйдете в свап (файл или раздел на ЖД, который нужен в случае переполнения памяти), то всё ооооооочеееееень затормозит.
3. Сетевой ответ от сервера и качество сигнала - без комментариев.
4. Место на разделах - если закончится, то начинается апокалипсис.
5. Шаблонный ответ от необходимых сервисов. Тут несколько вариантов, а точнее ступеней.
Ступень первая - сканирование открытого порта. Позволяет узнать вообще работает или не работает сервис. Например сканировать 80 порт на предмет ответа веб-сервера.
Ступень вторая - подключение к порту, снятие данных и сравнение данных. В случае с веб-сервером можно спокойно создать файл index.html в котором будет "it works". И проверять, есть ли "it works" или нет.
Ступень третья - имитация деятельности. В общем самая сложная штука, напоминает тесты при создании программ. Сложно, но позволяет проводить контроль практически любых событий.
Что важно помнить, что служба мониторинга должна отрабатывать ключевые события. Т.е. не надо смотреть всё и вся, а только то, что нужно, иначе усложнишь себе жизнь.
А так же надо помнить, что не все события и ошибки можно отловить. Например, у меня , после обновления, странным образом упал недавно dbmail, причем по всем характеристикам системы он был в рабочем состоянии, а из-за него почта не принималась.
Что касательно уведомлений, то тут всё просто. Лучше всего - банальный смс. Ну или email, если телефон отслеживает статус почты. А теперь вспомним про пейджеры. Они в этом плане удобнее телефонов, т.к. по последнему иногда ещё и разговариваешь.
Уведомления, в идеальном случае, лучше делать нескольким людям. На всякий случай.
Так же можно завести тикет систему, где можно открыть задание для персонала по исправлению ошибки.
В следующий раз я расскажу про службу мониторинга nagios.
Комментариев нет:
Отправить комментарий