Случайны выбор дневника Раскрыть/свернуть полный список возможностей
"
         + ""
         //+ ""
         ;
        
      });

      showData.empty();

      if (items.length) {
        var content = '' + items.join('') + '';
        var list = $('


Найдено 3244 сообщений
Cообщения с меткой

мониторинг - Самое интересное в блогах

Следующие 30  »
rss_rss_hh_new

Жизнь проекта на production: советы по эксплуатации

Понедельник, 29 Августа 2016 г. 17:04 (ссылка)

image



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



И ведь это только фронтенд, а есть ещё бекенд и база данных. Везде разные законы и логика. Подробнее об эксплуатации highload-проектов в докладе Николая Сивко (Head Hunter) с конференции HighLoad++ Junior.





Жизнь проекта на production: советы по эксплуатации



Николай Сивко (okmeter.io)



Я хочу рассказать вам про эксплуатацию. Да, конференция «HighLoad» больше про разработку, про то, как справляться с высокими нагрузками и т.д. и т.п.– мне такую вводную организаторы дали, но я хочу поговорить про отказоустойчивость, потому что, на мой взгляд, это тоже важно.



Начинать надо с постановки задачи — определения того, чего мы хотим.







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



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







Надо себя сразу ограничить в желаниях, т.е. сделать четыре девятки, пять девяток сразу не стоит. Будем опираться на все, что нам предлагают дата-центры — у них разный уровень сертификации, сертифицируется дизайн дата-центра, т.е. насколько там все отказоустойчиво, и мы, наверное, не будем пытаться запрыгнуть дальше чем TIER III, т.е. восемь минут простоя в месяц, 99-98% uptime нам сойдет. Т.е. резервировать дата-центр мы пока не будем.







В реальности, когда дата-центр сертифицирован чуть ниже, чем TIER III (вернее, я не помню, какой порядок), то по факту дата-центры в современном мире работают достаточно хорошо. Т.е. в Москве найти дата-центр, который стабильно работает из года в год, как говориться, без единого разрыва, не составляет труда. Можно погуглить, можно поспрашивать отзывы. В итоге вы куда-то встали и поставили свое железо. А вот все, что ломается внутри дата-центра — это более вероятные поломки, т.е. ломается железо, ломается софт. Тот софт, который писали не вы, ломается чуть реже, потому что есть комьюнити, бывает, есть вендор, который следит за отказоустойчивостью, а вот софт, который писали вы, скорее всего, ломается чаще.







Нужно с чего-то начать. Допустим, есть dedicated сервер за 20 тыс. рублей в месяц, от этого будем плясать. На нем у нас в кучу собрано все: фронтенд, бэкенд, база, какие-то вспомогательные сервисы, memcashed, очередь с асинхронными тасками и обработчики, которые их выгребают и делают. Вот? будем с этим работать, причем, по порядку.







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



Сразу скажу — починить все нереально. Если бы можно было починить все, там был бы 100% uptime, и все это было бы не нужно. Но давайте попробуем все, что сможем, быстро закрыть.







Соответственно, как устроен среднестатистический проект, начиная с 2000-го года? Есть бэкенд, есть фронтенд, memcashed часто, но это не принципиально, очередь сообщений, обработчики и база. Если есть что-то еще, что мы не покрыли, примерно понимая алгоритм, можете сами сделать.







Фронтенд. Для чего он нужен? Он принимает все входящие запросы, занимается тем, что обслуживает медленных клиентов, как-то оптимизируя нагрузку на наш более жирный бэкенд, отдает статику самостоятельно с диска, занимается тем, что обслуживает Transport Layer Security, в данном случае, к сайтам применительно https, проксирует запросы на бэкенды, занимается балансировкой между бэкендами, иногда там есть встроенный кэш.







Что может произойти? Может тупо сломаться железка, на которой у вас Nginx или другой фронтендовый сервер. Может умереть сам Nginx или что-то на этой машине по разным причинам. Может все затупить, например, вы уперлись в ресурсы, уперлись в диск и т.д. И по итогам все тормозит. Давайте начнем это решать.







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



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







Есть способы с этим тоже чего-то сделать. Первый, самый примитивный, что можно сделать, не обладая никакими навыками — это DNS round robin. Просто для своего домена указываете несколько IP, один IP одного фронтенда, другой — другого, и все работает.



Проблема тут в том, что DNS не знает о том, работает сервер, который вы там прописали, или нет. Если вы даже научите DNS знать об этом и не отдавать в ответе битый IP, все равно есть кэш DNS’a, есть криво настроенные кэши у провайдеров разных и т.д. В общем, не стоит закладываться на то, что вы быстро поменяете DNS. Реальность такова, что даже если у вас низкий TTL в DNS прописан, все равно будут клиенты ломиться на неработающий IP.



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



Проблема тут какая? Вам от провайдера нужно добиться, чтобы оба сервера были в одном Ethernet-сегменте, чтобы они могли перекидываться служебными heartbeat’ами и прочее.



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







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







Примерно вот так это работает через Cisco. Это куски конфига. Вы анонсируете один IP-адрес, и у него два маршрута — через один сервер и через другой. На каждом фронтенде на lowback интерфейсе висит целевой IP? и как-то обеспечена логика проверки чеков. Cisco сама умеет проверять статус маршрутизатора, допустим она может проверить CB-коннект на Nginx’овский порт или еще как-то, или просто банально ping. Тут все просто, вряд ли у кого-то в маленьком проекте есть роутер свой.







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



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







Примерно вот такая картинка очень показательна. Вы видите по оси Y запросы в секунду к вашему сайту. В данном случае около 500 запросов в секунду идет. В нормальной ситуации есть медленные запросы — они помечены красным — это запросы, которые дольше секунды обрабатываются. Зеленые — это те, которые быстрее 500 мс, желтые — это что-то по серединке, и черное — это ошибки. Т.е. сразу вы видите, как работает ваш сайт — так же, как 5 минут назад или нет. Тут два красных выброса — это, как раз, проблемы. Это тормозил сайт, где-то на глаз 30-40% пользовательских запросов были тупящими.







Итого, по этим метрикам можно настроить алерты, которые будут однозначно говорить, как работает ваш сайт — хорошо или плохо. Для примера вот такие пороги. Т.е. если для сайта с 200 запросами в секунду ошибок больше 10 запросов в секунду, то это критикал алерт. Если процент медленных запросов, которые больше секунды, больше пяти, допустим, то это тоже критикал алерт.



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







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







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







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







Начинаем думать и закрывать.



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







Чтобы оградить себя от большого количества запросов на каждый бэкенд, нужно понять, каков предел производительности бэкенда и настроить лимиты в нем самом. Допустим, в apache есть предел, который вы можете настроить, т.е., например, «Я беру только 200 параллельных запросов, больше не беру. Если больше пришло, я отдаю «503» — это внятный статус, что я сейчас больше не могу запрос обслужить». Тем самым мы показываем балансировщику или в нашем случае фронтенду, что запрос можно отправить на другой сервер. Тем самым вы не страдаете перегрузом — если ваша система целиком перегружена, вы отдаете пользователю «503» — внятную ошибку типа «Чувак, не могу». Это вместо того, чтобы все запросы затупили и повисли в ожидании, а клиенты вообще не понимали, что происходит.



Также момент, который все забывают. В проектах, которые развиваются стремительно, забывают проверять таймауты на все, т.е. ставить таймауты. Если вход вашего бэкенда идет куда-то наружу, допустим в memcashed базу, нужно ограничивать, сколько вы будете ждать ответа. Нельзя ждать вечно. Вы, ожидая, допустим, ответа postgress, занимаете коннекшн с ним, занимаете какие-то ресурсы, и нужно вовремя отвалиться, сказать: «Все, я больше ждать не могу» и отдать ошибку наверх. Тем самым вы исключаете ситуации, когда у вас все тупит, в логах ничего нет, потому что все операции in progress, и вы не понимаете, что происходит. Нужно ограничивать таймауты и очень трепетно к ним относиться, тогда вы получите более управляемую систему.







Балансировка. В данном случае просто. Если у вас на фронтенде стоит Nginx, то просто прописываете несколько upstream’ов. Опять же про таймауты — для локалки коннекшн таймаут должен быть не секунды, а десятки миллисекунд, а то и меньше, надо смотреть на свою ситуацию. Говорите, в каких случаях запросы повторять на соседний сервер. Ограничиваете количество ретраев, чтобы не вызвать шторм. Большой вопрос — ретраить ли запросы на модификацию данных, посты и т.д. Вот, с Nginx свежих версий, они не ретраят по умолчанию такие запросы как POST, т.е. не идемпотентные запросы. И это, в принципе, хорошо, эту ручку все долго ждали и, наконец, она появилась. Там можно настроить другое поведение, если вы хотите ретраить посты.







Про бэкенд — тоже пытаемся заодно покрыть его мониторингом. Мы хотим понимать, жив ли процесс, открыт ли listen socket TCP’шный, который мы ждем, что сервис обслуживает, отвечает ли он на какую-то специальную ручку, проверяющую его статус, сколько сервис потребляет ресурсов, сколько он использует CPU, сколько он зааллоцировал памяти, насколько он сидит в swap, количество файлов-дескрипторов, которые он открыл, количество операций ввода/вывода на диск, в штуках, в трафике и т.д., чтобы понимать, больше он потребляет или как обычно. Это очень важно понимать, причем это важно понимать во времени, чтобы сравнивать с предыдущими периодами.



Специфичные runtime метрики для Java — это состояние heap, использование мемори пулов, garbage collection, сколько там их в штуках было, сколько их было в занимаемых секундах, в секунду и т.д.



Для Python там свои, для GO’шки — свои, для всего, что связано с runtime, там свои отдельные метрики.







Вам нужно понимать, чем был занят бэкенд, сколько он запросов принял. Это можно отстреливать в лог, это можно отстреливать в statsd, тайминги по каждому запросу, нужно понимать, сколько времени тратилось на тот или иной запрос, сколько было ошибок. Часть этих метрик, в принципе, видит фронтенд, потому что он для бэкенда выступает клиентом, и он видит, была ли ошибка, или был нормальный ответ. Он видит, сколько он ждал ответа. Обязательно мы должны мерить и логировать, сколько бэкенд ждал всех сервисов, которые от него снаружи стоят, т.е. это база, memcashed, nosql, если он работает с очередью, сколько заняло поставить задачу в очередь. И время, которое заняли какие-то ощутимые куски CPU, допустим, рендеринг шаблона. Т.е. мы в лог пишем: «Я рендерю такой шаблон, у меня это заняло 3 мс», все. Т.е. мы видим и можем сравнивать эти метрики.







Тут пример того, как мы меряем CPU usage ruby в одном из проектов. Это сводный график по всем хостам, их тут девять бэкендов. Сразу видно, есть у нас тут какое-то аномальное потребление ресурсов или нет.







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







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







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







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



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



Умер сервис, ну, postgress прибило oom killer’ом или mysql — тоже нам нужно как-то понимать, что такое происходит.



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



Из-за того, что вы прислали в 10 раз больше запросов, чем расчетные, допустим, прислал там трафик какой-то и т.д.



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







Попробуем с этим чего-то сделать.



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



Основная нагрузка большинства проектов — чтение. В принципе, если вы обеспечите read only постоянную, стабильную работу вашего сайта, то ваше начальство или вы будете безмерно рады. Это уже в 100500 раз лучше, чем ничего, чем падать.







Можно в реплику сразу сгружать все SELECT’ы, не чувствительные к replication lag. Что это такое? Данные на реплику попадают не сразу, а с определенной задержкой в зависимости от разных причин, начиная от пропускной способности каналов, заканчивая тем, насколько реплика там поблочилась. Запросы, которые запрашивают анонимные пользователи, состояние, допустим, каталог — они не чувствительны к replication lag. Если данные задержаться и попадут пользователю неактуальные, ничего плохого не произойдет. А если пользователь заполняет свой профиль и жмет submit на форму, а вы ему показываете данные, которые еще не изменились, допустим, взяли их с реплики, то это уже проблема. В таком случае SELECT надо делать с мастера. Но большинство нагрузки все равно идет на реплику. И приложения нужно обучать тому, что есть реплика, что она отстает, при этом, вы помимо отказоустойчивости решаете задачу масштабирования по нагрузке на операцию чтения.



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



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







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



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



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



Если еще есть реплики, их нужно переключить на новый мастер и, если вы старый сервер хотите куда-то пристроить, потом включите его в виде реплики.







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



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



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



Попутно, мы замеряем время. Время нам нужно замерять, чтобы гарантировать, что с подобной проблемой мы справляемся за 30 или за 15 минут, или суммарный downtime получается полторы минуты, после того, как человек пришел, открыл ноутбук, за-ssh’шился и погнали.



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







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



Бэкапы, опять же, у разных баз данных делаются по-разному. Есть полные бэкапы, которые делаются, как правило, не каждую секунду, есть возможность бэкап, который ежедневный dump или ежедневную копию датафайлов догнать с помощью write ahead log или bin log или еще чего-то… Эти bin log’и нужно копировать в сторонку аккуратненько.



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



Бэкап лучше копировать в другой ДЦ, потому что, если вы собираетесь из него восстанавливаться, а он только в удаленном ДЦ, который на самом деле находится через Атлантику от вашего — это долгое копирование. Лучше держать и там, и там. Т.е. в случае, если ваш ДЦ жив, и вы хотите восстановиться, вы становитесь копией, которая уже при вас. Если ваш ДЦ помер, вы будете восстанавливаться у другого хостера, который где-то, и там уже придется ждать, что поделать?







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



Дальше вам нужно уметь понимать, чем занята база прямо сейчас и чем она была занята 5 минут назад. Лучше всего это смотреть в терминах запросов. Где-то это реально снять, где-то нереально, допустим в postrgess можно понимать, какие запросы жрут CPU, какие запросы создают нагрузку на диск. Если вы все-таки настроили репликацию, вам нужно понимать, насколько она отстает, потому что от этого может зависеть, если она у вас в среднем в году отстает на 500 мс, то, может быть, стоит считать, что репликейшин лага нет? Но если вам очень хочется для какого-нибудь специфического случая, если реплика сильно отстала, а репликация разломалась, вы должны обязательно знать об этом и починить. Надо понимать, сколько идет запросов, больше или меньше на базу, чтобы сравнивать два периода, потому что если вы выпустили кривой код, который делает в два раза больше запросов, они отжирают в два раза больше CPU, то вы сразу это увидите и будете чинить.



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







Мониторинг запросов по postgress выглядит примерно так. Тут есть спайки — это какой-то аномальный запрос. Вы на него смотрите, принимаете решение, что с ним делать, как оптимизировать, как заменять и т.д.







Мониторинг репликации выглядит примерно так. Т.е. есть четыре сервера, один там сейчас задизейблен, отстают они по-разному, бывают какие-то выбросы, что репликация отстает на 800 мс, но в среднем они на 50 мс отстают.







Итожим по базам.



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



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



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



Если мы говорим, что нам приходят в релизе новые запросы, то мы это детектим за 3 минуты, чиним еще откатом, это занимает 5 минут, итого мы обещаем за 8 минут закрыть эти проблемы. Вообще, любой бизнес это устроит. Это, типа, «я умею побеждать эту проблему в течение 15 минут» — это хороший аргумент для того, чтобы доказать вашему руководству, что вы ситуацию контролируете.







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



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







Может, как всегда, сломаться железка, может умереть сервис, может тормозить сеть от бэкенда до memcached, или где-то там что-то затупить из-за нехватки ресурсов. Быстренько попробуем закрыть.







Мemcached всегда ставят несколько, клиент умеет знать про все, он умеет ходить во все. Там есть какой-то алгоритм шардирования, разные они есть. Если умирает один, происходит что-то, клиент переживает эту ситуацию, он, допустим, идет в новую базу и по новой группе серверов раскладывает, сетит в кэш новые значения. Обязательно нужно настраивать таймаут, потому что ситуация, когда тупит memcached редка, а ситуация, когда тупит сеть, более вероятна.



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







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



И всегда надо понимать, эффективен ли кэш. Т.е. вы все-таки делаете, как правило, лишний поход по сети, и если кэш неэффективен, то, вообще, на хрена это делать? Надо мерить, и понимать, насколько это эффективно.







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







Таким образом первые две проблемы мы закрыли. К сожалению, такие вещи, как memcached, они ничего не говорят про latency про себя… Предполагают, что они такие супер-быстрые, там память устроена максимально эффективно, и они всегда отдают быстро. А по сути, надо это как-то мерить и единственный способ это померить — это считать, сколько мы ждали кэша на бэкенде. Мы в предыдущем разделе как раз этим занимались. Важно считать. На самом memcached вы не сможете это посчитать, поэтому из кода, который его юзает, как-то отстреливайте таймеры.



Нехватка ресурсов — тут просто мониторингом закрыли. Так, тут тоже навели порядок.







Давайте еще очереди рассмотрим. Очередь для чего нужна? Для того чтобы не делать какие-то задачи прямо сейчас, а отложить их, чтобы кто-то пришел потом, взял задачку и доделал. Как правило, это самое частое применение Message Queue. Есть publisher — это тот, кто задачу в очередь кладет, есть consumer — это тот, кто выгребает и потом делает какую-то работу и т.д.







Давайте риски выписывать.



Железка сломалась. Мы хотим во что бы то ни стало пользователю отдать «ок», значит, нам нужно придумать как-то, как эту проблему обходить.



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



Умер сам сервис — нужно понимать, что с этим делать.



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



Или тормозит из-за нехватки ресурсов.







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



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







Есть кейсы, когда в очередь хотят положить очень важное сообщение, допустим, про деньги. И здесь не хочется варианта, когда умер сервер и унес с собой 10 млн. необработанных таких сообщений. Что тут можно сделать? Можно писать в несколько брокеров и убирать дубли на этапе обработки. Т.е. делать выполнение тасков идемпотентной операцией, и если вы ее сделаете больше одного раза то, типа, хорошо. Или иметь, допустим, раз в сутки механизм, вычислительный очень тяжелый, который лопатит данные, но он восстанавливает состояние, проверяет, все ли было доставлено. Допустим, вы пишете в очередь, чтобы как можно быстрее исполнить заказ, но на самом деле вы в базе пишете какой-то еще транзакционный лог, который это делает, а очередь у вас так, оптимизация. В этом случае у вас раз в сутки запускается скрипт, который все это сканит, и приводит состояние в желательное.



Два таких кейса, что делать при этих случаях?







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







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







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







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







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







Про облака. Облака — это модно. У облаков есть плюсы в том, что есть балансировщики, которые, в принципе, решают задачу, балансируют между фронтендом. У Амазона есть Load Balancing, допустим. Есть готовые сервисы очередей, машину новую создать — это вопрос минут. В случае дедиков машину получать у таких хостеров, где на потоке вам могут в течение 5 минут выдать машину, но все-таки SLA они гарантируют пару дней.



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







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







Резюмируем все, что я сегодня рассказывал.



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



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



Контакты



Николай Сивко, nsv@okmeter.io. Блог компании OKMeter на Хабре.



Дополнительная информация



Не хватает информации? Или не ясно, в какой момент подключать те или иные советы Николая? Всё это мы будем подробно разбирать на мастер-классе Романа Ивлиева 6 сентября.


Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/308756/

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Как и что можно проверять облачными сервисами? Обзор сервиса ХостТрекер. Часть 2

Вторник, 16 Августа 2016 г. 09:00 (ссылка)

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









Все ли дело в наборе функций?



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



Мелочь, а приятно



Описывая регулярные проверки, желательно сразу отметить некоторые полезные прилагаемые функции. К ним относится мониторинг срока действия домена и SSL сертификата. Такие, вроде бы, мелочи, доставляют огромные неудобства когда проявляются в неожиданное время. Эти функции появились в ХостТрекере, когда как всегда внезапно «закончился» один из наших личных доменов. Но подобные проблемы возникают даже у больших компаний, так как продление доменов/сертификатов всегда упирается в человеческий фактор, о надежности которого здесь распространятся не будем. Некоторые примеры мы собрали и описали вот здесь. Поэтому оповещение, что данный домен необходимо продлить, которое попадет не только в папку спам, где уже прописался ваш хостер благодаря непрерывному потоку маркетинговых писем, а и в папку о падениях вашего сайта (не говоря уж о возможности СМС оповещения), конечно же, является крайне полезным.

Другой интересной функцией является проверка доменов в черных списках DNSBL. Эти списки независимы и формируются каждый по своему алгоритму и созданы, главным образом, для фильтрации подозрительных субъектов. Каждый администратор может настроить свой веб-сервер, например, не получать письма от серверов, перечисленных в определенном списке. Это помогает бороться со спамом, распространением вредоносного ПО, ддос-атаками и другими проблемами. Но все эти списки имеют свои алгоритмы, и нет гарантии, что в результате случайных обстоятельств ваш сайт там не окажется. Более того, статистика показывает, что такое регулярно происходит даже с самыми безобидными сайтами. Например, никто не даст гарантию, что на соседнем с вами айпишнике не пропишется местный Король Спама, вследствие чего весь диапазон будет занесен в неблагонадежные. Во что это может выплеснуться? Письма от вас перестанут приходить клиентам, сайт станет хуже отображаться в поисковиках… Ну и так далее по нарастающей. А узнаете вы об этом, когда изменения станут критическими, а порой, увы, и необратимыми. Поэтому функция контроля и оповещения о попадании в наиболее популярные черные списки также является весьма востребованной.





Проверка контента



Вот это хороший пример того, как использование функции может превзойти все ожидания разработчиков. Ранее мы упоминали несколько подобных случаев. Дело в том, что множество вещей сейчас имеет веб-интерфейс. А для еще большего множества его можно написать без особых сложностей. Поэтому кроме основной задумки — проверки, подгрузилась ли страница целиком, путем простого парсинга, — открылись новые просторы. Подстраиваясь под разных клиентов, эта функция стала максимально универсальной: может искать сразу много слов, или же лишь одно из списка. Или наоборот — реагировать на появление определенных фраз. Также может выдавать в ошибку строку, в которой содержится ключевое слово. Например, многие делают страницу статусов: «Server 1 OK» и так далее. Если он вдруг станет «Error», тогда в сообщении придет «Server 1 Error» — вся диагностика уже проведена, можно сразу приступать к устранению.



А что, если сервер ДОЛЖЕН прилечь?



Кроме оповещений о падении сайтов, ХостТрекер выполняет еще одну важную функцию – собирает статистику по каждому проверяемому сайту. Во времена, когда различные кнопки на сайтах еще были популярными – кнопка ХостТрекера также нередко появлялась рядом с показателями посещаемости, прогнозом погоды и другими, безусловно, очень важными вещами. Сейчас же есть возможность вставить виджет, хотя кнопка тоже все еще доступна для любителей ретро. Кроме того, статистика часто является показателем для руководства: хорошо ли работает сайт и отдел его администрирования? Поэтому еще одной полезной функцией является планирование технических работ. Даже самые стабильные сайты и сервера должны время от времени обновляться или перезагружаться. И при этом не хочется терять пресловутые «девятки» в показателях аптайма. Планирование технических работ позволяет достигнуть двух целей (вместе или раздельно): не присылать оповещения об ошибках и не записывать ошибки во время определенного интервала времени в статистику. Конечно, это все равно попахивает читерством, но запланированный простой, тем более, в нерабочее для целевой аудитории время – вполне можно простить, с нашей точки зрения. Тем не менее, проверки во время технических работ все так же идут, и исправно пишутся в лог, поэтому могут быть полезными для вебмастеров и администраторов: лог позволяет определить, сколько именно длилось обновление или перезагрузка, какие ошибки при этом выдавались (то есть прослеживается весь процесс: сервер некоторое время недоступен, потом возвращает ошибку приложения, затем другую ошибку и т.д.), какие «тормоза» при этом наблюдались и тому подобное.



Технические работы можно запланировать как единоразово, так и на регулярной основе. Например, если каждую ночь делается бэкап, или каждый четверг – новый релиз. Единственное условие – расписание технических работ должно быть составлено не позже, чем за 12 часов до ближайшей приостановки сайта/сервера. Это сделано для того, чтобы на технические работы не списывались внезапно возникшие неожиданности, и статистика, предоставляемая ХостТрекером, оставалась достоверной.



Вместо эпилога



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

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

Но мы все равно очень рады читать все ваши замечания, так как на Хабре не редкость уловить что-то полезное для себя даже между строк.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/307784/

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Из песочницы] Поднимаем микро мониторинг на icinga2 с минимальными затратами

Понедельник, 08 Августа 2016 г. 14:35 (ссылка)

Иногда есть желание контролировать ситуацию в разнородных сетях, отдельных хостах за натом или просто мониторить компьютеры родителей или друзей, но ресурсов для этого почти нет. Будем искать решение с помощью icinga2. Сейчас у VDS провайдеров есть предложения VDS серверов в минимальных конфигурациях за смешные деньги. Что ж, воспользуемся этим.



Например, сервер с одним ядром, 512 Мб оперативной памяти и диском на 10 Гб обойдется всего в 90 рублей в месяц. Установим icinga2 на такой сервер. Но для экономии ресурсов не будем хранить данные и вместо стандартного веб-интерфейса (icingaweb2) сделаем свой который будет обращаться к API icinga2.



Установка icinga2 уже не однократно описывалась и не вызывает больших трудностей. Вкратце пробежимся по основным этапам установки. Будем устанавливать на ubuntu.



wget -O - http://debmon.org/debmon/repo.key 2>/dev/null | apt-key add -
echo 'deb http://debmon.org/debmon debmon-jessie main' >/etc/apt/sources.list.d/debmon.list
apt-get update
apt-get install icinga2




Запускаем визард:



icinga2 node wizard


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



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

service icinga2 reload




Если что-то пошло не так, смотрим что не нравится нашей системе и разбираемся с ошибками:



service icinga2 checkconfig




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



image



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



icinga2 pki ticket --cn TS01E.PSHOME.local




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



icinga2 node list
icinga2 node update-config
service icinga2 reload


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



Приступаем к дополнительным настройкам конфигурации. В первую очередь пропишем свой email в файле /etc/icinga2/conf.d/users.conf, на который будут приходить оповещения:



object User "icingaadmin" {
  import "generic-user"
  display_name = "Icinga 2 Admin"
  groups = [ "icingaadmins" ]
  email = "icingaadmin@yandex.ru"
}
object UserGroup "icingaadmins" {
  display_name = "Icinga 2 Admin Group"
}




Настроим smtp на сервере, если это еще не сделано:



apt-get install ssmtp


Укажем почту для пользователя из под которого работает icinga2:

echo nagios:icingarobot@yandex.ru >> /etc/ssmtp/revaliases




Примерное содержимое файла /etc/ssmtp/ssmtp.conf для отправки почты через smtp Яндекса:



root=postmaster
mailhub=smtp.yandex.ru:465
hostname=icinga-failover
FromLineOverride=YES
AuthUser=icingarobot@yandex.ru
AuthPass=password
UseTLS=YES




Так как у нас мониторинг не сохраняет данные, нам нужно что-то более оперативное, чем email. Настроим pushover. Для этого создадим скрипт /etc/icinga2/scripts/pushovernotify.sh:



#!/bin/sh
curl -F "token=$PUSHOVERTOKEN" \
-F "user=$PUSHOVERUSER" \
-F "title=$PUSHOVERTITLE" \
-F "message=$PUSHOVERMESSAGE" \
-F "html=$PUSHOVERHTML" \
https://api.pushover.net/1/messages
exit 0




Добавим в файл /etc/icinga2/conf.d/commands.conf следующие строки:



object NotificationCommand "pushover-host-notification" {
import "plugin-notification-command"
command = [ SysconfDir + "/icinga2/scripts/pushovernotify.sh" ]
env = {
    PUSHOVERUSER = "$user.vars.pushover_user$"
    PUSHOVERTOKEN = "$user.vars.pushover_token$"
    PUSHOVERTITLE = "Icinga2 Host Notification"
    PUSHOVERMESSAGE = " $notification.type$ $host.display_name$ $host.state$ $icinga.long_date_time$"
    PUSHOVERHTML = "1"
  }
}

object NotificationCommand "pushover-service-notification" {
  import "plugin-notification-command"
  command = [ SysconfDir + "/icinga2/scripts/notifybypushover2.sh" ]
  env = {
    PUSHOVERUSER = "$user.vars.pushover_user$"
    PUSHOVERTOKEN = "$user.vars.pushover_token$"
    PUSHOVERTITLE = "Icinga2 Service Notification"
    PUSHOVERMESSAGE = " $notification.type$ $host.display_name$ $service.display_name$ $service.state$ $icinga.long_date_time$"
    PUSHOVERHTML = "1"
  }
}




Добавим в файл /etc/icinga2/conf.d/templates.conf следующие строки:



template Notification "pushover-host-notification" {
  command = "pushover-host-notification"
  states = [ Up, Down ]
  types = [ Problem, Acknowledgement, Recovery, Custom,
        FlappingStart, FlappingEnd,
        DowntimeStart, DowntimeEnd, DowntimeRemoved ]
        period = "24x7"
}
template Notification "pushover-service-notification" {
  command = "pushover-service-notification"
  states = [ OK, Warning, Critical, Unknown ]
  types = [ Problem, Acknowledgement, Recovery, Custom, FlappingStart, FlappingEnd, DowntimeStart, DowntimeEnd, DowntimeRemoved ]
  period = "24x7"
}




Добавим в файл /etc/icinga2/conf.d/notifications.conf следующие строки:



apply Notification "pushover-icingaadmin" to Host {
 import "pushover-host-notification"
  user_groups = host.vars.notification.mail.groups
  users = host.vars.notification.mail.users 
  assign where host.vars.notification.mail
  interval = 0 // disable re-notification
}
apply Notification "pushover-icingaadmin" to Service {
  import "pushover-service-notification"
  user_groups = host.vars.notification.mail.groups
  users = host.vars.notification.mail.users
  assign where host.vars.notification.mail
  interval = 0 // disable re-notification
}




Добавим ключи pushover в файле /etc/icinga2/conf.d/users.conf

object User "icingaadmin" {
  import "generic-user"
  display_name = "Icinga 2 Admin"
  groups = [ "icingaadmins" ]
  email = "icingaadmin@yandex.ru"
  vars.pushover_user = "1111111111111111111111111111111"
  vars.pushover_token = "1111111111111111111111111111111"
}




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



Итак, рисуем веб-морду для запросов к API icinga2. Визард настройки так-же создал файл /etc/icinga2/conf.d/api-users.conf из которого берем имя пользователя и пароль для доступа к api. Проект веб интерфейса состоит из страницы отображающей список всех хостов и страницы детальных сведений отдельного хоста. Из ходя из предположений, что размещение веб интерфейса может быть на отдельном сервере, используем написанный на скорую руку php скрипт для проксирования кросс-доменных запросов.

Текст скрипта icinga-proxy.php:





Список всех хостов хочется видеть в актуальном состоянии и желательно без перезагрузки страницы, для этого воспользуемся jQuery.GetJSON().



Текст скрипта icinga-get-host.js:
$(document).ready(function () {

  $('#get-data').click(function () {
    var showData = $('#show-data');


    var www_path = "";
    var json_url = 'icinga-proxy.php?domain=' + domainFilter.value;

    $.getJSON(json_url, function (data) {
                
      var data0 = data.results;
       var items = data0.map(function (item) {
          
        var hostdown = item.attrs.state;
        var icon_image_src = item.attrs.icon_image;
        var hostdown_bage;
        var hostdown_bage_span;

          if (hostdown == 1) {
              
                hostdown_bage = "";
                hostdown_bage_span = "
";
                icon_image_src = item.attrs.icon_image.slice(0, -4) + "_gray.png";

            } else {
              
              hostdown_bage = "";
              hostdown_bage_span = "";

                if (item.attrs.icon_image) {
                    icon_image_src = item.attrs.icon_image;
 

                } else {
                    icon_image_src = "img/my/dot.png";
                }

          }
          
        return "
"
         + "
" + item.attrs.display_name + "
"
         + hostdown_bage_span + "
"
         + hostdown_bage + hostdown_bage_span + item.attrs.display_name  + "
" + item.attrs.vars.domain_name + "" + item.attrs.vars.os + "
').html(content);
        showData.append(list);
      }
    });

    showData.text('Loading the JSON file.');
  });


$('#get-data').click();

setInterval(function(){$('#get-data').click();},60*1000);

});




Репозиторий проекта веб интерфейса можно найти здесь.



С применением стилей Material Design Lite наш веб интерфейс будет выглядеть так:



Список хостов
Список хостов



Список хостов с отображением не доступности одного из них
Список хостов с отображением не доступности одного из них



Детальная информация по хосту
Детальная информация по хосту





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



Ссылки



Официальная документация icinga2 — Установка

Официальная документация icinga2 — API
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/307358/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
vsemmoney

ELMONITOR.RU - ХАЙП МОНИТОРИНГ - Мониторинги HYIP - Форум о заработке в интернете и инвестициях

Среда, 27 Июля 2016 г. 09:38 (ссылка)
vsemmoney.ru/topic/4228-elm...onitoring/


ELMONITOR.RU - ХАЙП МОНИТОРИНГ - отправлено в Мониторинги HYIP: Что ж, приветствую на превью обзоре моего хайп мониторинга - ELMonitor.ru



- актуальное и лучшее из сет...

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Мониторинг проектов с помощью месенджера на примере Nagios и Telegram, с разбором факапов из жизни Highload 24x7

Суббота, 24 Июля 2016 г. 00:09 (ссылка)



Рисунок: Маргарита Закиева





Что будет под катом:




  • Базовые настройки Nagios в связке с Telegram.

  • Общая концепция нашего с коллегами мониторинга проектов.

  • Разбор граблей, на которые мы успели наступить при работе с этой системой.



Наша статья будет полезна для тех, кто:




  • Недоволен информативностью своего текущего мониторинга.

  • Испытывает ежедневную боль ниже спины с оповещениями о проблемах.





Эта статья не про «Telegram Bot API»



Настраивать связку, о которой пойдёт речь, мы начали ещё за месяц до публичного релиза API, поэтому с самого начала для отправки алярмов с сервера мониторинга был использован «Telegram CLI for Linux». Статья, в первую очередь, посвящена именно этому консольному клиенту. В конце статьи мы подробно объяснили, почему не стали отказываться от него в пользу новшеств из мира ботов.



Кто мы и чем занимаемся



Мы — дружная команда «Operations» компании МедиаТех. Админить приходится десятки серверов, это могут быть как VPS, так и «железные» сервера, в том числе в Colocation, а разбросаны они по всему миру. Правильная и эффективная работа с мониторингом — наш основной приоритет.



Общая концепция



У нас вообще нет людей в штате, в обязанности которых входило бы ночью не спать и следить за мониторингом, зато мы имеем один зарегистрированный на «левую» SIM-карту аккаунт, от чьего имени отправляем сообщения и некое количество:





  • Инстансов Nagios — это никак не связано с реализацией отправки уведомлений, просто мы хотим подчеркнуть, что с несколькими Nagios одновременно, всё работает без каких-либо сбоев.



Факап №0 — Не замониторить мониторинг

Рано или поздно вы столкнётесь с тем фактом, что мониторинг тоже может сломаться, а узнать об этом хочется сразу, а не в понедельник, после выходных. В то же время, логично проверять некоторые сервисы «изнутри», а другие, например статус ответа вашего сайта по HTTP — «снаружи». Чтобы «убить двух зайцев одним камнем» настройте себе ещё один Nagios у другого провайдера и распределите нужные вам проверки между двумя мониторингами, не забыв настроить проверку check_nagios одного инстанса на другой и зеркально наоборот. Надеюсь для вас, так же как и для нас, одновременное падения двух провайдеров в разных странах — сценарий крайне маловероятный.

Как выглядит наш мониторинг мониторинга








  • Настроенных уведомлений для сервисов — ключевой момент здесь — это настройка в месенджер только самых важных уведомлений, скорее всего это будет CRITICAL нотисы по самым ключевым метрикам на самых важных хостах. Остальное, например, WARNING или хосты-песочницы настраиваются на отправку сообщений вне той схемы, которая описана в данной статье. Это может быть, например, почта или «личка» c роботом в том же Телеграме.



Факап №1 — Отправлять нотификации, которые требуют немедленного вмешательства в систему, для исправления проблемы в тот же чат, что и те алярмы, которые могут подождать или вообще вскоре пропадут, после автоматической починки сервиса.

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

Типичный канал, на который реагирует дежурный








  • Системных администраторов, которые по очереди приступают к ежедневному «дежурству» на мониторинге, которое длится сутки с 23:00 до 23:00. Администратор, который находится на дежурстве, должен включить (или не выключать) уведомления для канала, который настроен как адресат по умолчанию для критических алярмов из Nagios.



Факап №2 — Реагировать на нотификации по принципу «кто первый увидел».

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

Настройка уведомлений на телефоне или планшете








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



Факап №3 — Полагаться только на дежурного.

Горький опыт показал нам, что авария в вашем ДЦ может случиться одновременно с отключением доступа в интернет у дежурного системного администратора дома. Несмотря на то, что мобильный интернет есть у всех, по-умолчанию смартфон у всех подключен к домашнему Wi-Fi и то, что доступа в глобальную паутину там нет его не волнует, «палочки то все три». Впрочем, админ может оказаться недоступен и из-за более простых и линейных жизненных сценариев.

Резервные каналы, для которых у всех всегда включены уведодмления








  • Тематических каналов. Системный администратор может устранить далеко не все неисправности, обнаруженные мониторингом, например, ошибки в логах приложения или специфичные дедлоки в базе данных. Концепция «разбудить системного администратора, чтобы он разбудил бекенд разработчика» нам кажется неправильной, поэтому под такие уведомления отдельно созданы «тематические» каналы, ответственность за которые несут не системные администраторы, а другие профильные специалисты.



Факап №4 — Отправлять уведомления от робота в чаты, где проходят рабочие обсуждения.

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

В качестве примера демонстрирую скриншот с «резервными» каналами и одним тематическим, посвящённом базе данных.

Тематический канал, посвящённый базе данных







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



Отправляем Nagios уведомления в Telegram.



Установка и первый запуск консольного клиента


Даже если вы найдёте telegram-cli в репозиториях своего дистрибутива(например RPMfusion Repository для CentOS) или готовый пакет на просторах интернета, настоятельно рекомендуем самостоятельно «собрать и скомпилять», благо данная процедура детально рассмотрена прямо на github страничке проекта для многих *nix систем.

Примечание для любителей Fedora и CentOS
для Fedora 20 и CentOS 6, необходимо предварительно самостоятельно скомпилировать libjansson, которого не оказалось в стандартных репах.



После успешной компиляции бинарника, необходимо создать в системе пользователя с логином «telegramd», для того, чтобы после первого запуска клиента у вас в системе создалась директория /home/telegramd/.telegram-cli, внутри которой клиент после подтверждения своей авторизации будет хранить служебные файлы, например, полученный приватный ключ с серверов Telegram.



Почему имя пользователя именно 'telegramd'
telegramd — именно такое дефолтное имя пользователя используется клиентом, если вы запускаете его в системе от имени суперпользователя, в документации такой информации мы не нашли, зато подсмотрели её в «main.c».



Как не потерять доступ к аккаунту, зарегистрированному на «левую симку»
Достаточно бекапить ту самую папку «.telegram-cli», которая упомянута ранее. Перенеся её на другой сервер, Telegram сразу будет запускать с нужной вам авторизацией и настройками.



И так, у вас в руках телефон с симкой, на которую будем регистрировать Телеграм, а на компьютере открыта консоль сервера с мониторингом.

adduser telegramd # --disabled-login
./bin/telegram-cli -k tg-server.pub


Следуем инструкциям на экране и попадаем в консольный телеграм




Теперь можно добавить кого-нибудь в «contact_list» по его номеру телефона, насколько нам известно — это единственный способ занести пользователя в «контакты» так, чтобы в последствии отправлять туда уведомления из Nagios. Сделать это можно из консоли или из любого другого клиента, включая Telegram Web-version, разумеется, предварительно авторизовавшись там с тем же телефонным номером, который вы только что использовали. Для отправки сообщений в общий чат или канал на стороне «робота» вообще ничего делать не нужно, достаточно позаботиться о том, чтобы он был администратором, если вы отправляете сообщения в «канал».

add_contact +79991112233 My Contact
quit


Настройка клиента под отправку алертов


Теперь у нас есть настроенный консольный клиент с одним контактом для отправления туда нотификаций. Для удобства использования обернём это в скрипт на баше.

/usr/local/bin/telegram.sh
#!/bin/bash
#This script helps integrate Nagios instances
#with telegrams chats or channels.
sendFunc()
{
"$tgBinPath" `
`--rsa-key "$tgKeyPath" `
`--wait-dialog-list `
`--exec "$tgSendCmd $contactName $messageText" `
`--disable-link-preview `
`--logname "$mesLogFile" `
`>> $mesLogFile
}
#Path setup
tgSendCmd="msg"
tgDir="/usr/local/bin"
tgBinPath=""$tgDir"/telegram-cli"
tgKeyPath=""$tgDir"/tg-server.pub"
logDir="/var/log/telegram"
#dont forget to setup log rotation
mesLogFile=""$logDir"/telegram.log"
#Parse arguments
contactName="$1"
messageText="$2"
sendFunc #send telegram message
exit $?




Настраиваем права в системе (проверено в Debian 8 jessie)
mkdir -p /var/log/telegram
chown telegramd:nagios /var/log/telegram -R
chmod 770 /var/log/telegram -R
chown telegramd:nagios /usr/local/bin/t*
chmod +x /usr/local/bin/t*
chown telegramd:nagios /home/telegramd/ -R
chmod 770 /home/telegramd/ -R
ln -s /home/telegramd/.telegram-cli/ /var/lib/nagios/.telegram-cli




Отправим «foo» сообщение для «My Contact»
/usr/local/bin/telegram.sh My_Contact foo # обратите внимание на нижнее подчёркивание




Отправим «bar» в канал«Monitoring»
/usr/local/bin/telegram.sh Monitoring bar


Отправляем уведомление из Nagios


Описание команд основано на классическом шаблоне для Jabber. В тексте сообщения используется #ИМЯ_МОНИТОРИНГА, таким образом, оно становится хэш-тегом в тексте сообщения, для нас это удобно.

Определение контакта для конфига Nagios
define contact{

name telegram-contact

service_notification_period 24x7

host_notification_period 24x7

service_notification_options u,c,r,f ; Обратите внимание, уведомления типа "Warning" отправляться не будут

host_notification_options d,u,r,f

service_notification_commands service-notify-by-telegram

host_notification_commands host-notify-by-telegram

register 0

}



define contact{

contact_name telegramonlycrucial

use telegram-contact

alias Telegram OnlyCrucial

address1 Monitoring ; Название канала

}





Определение команд для конфига Nagios
define command{

command_name host-notify-by-telegram

command_line /usr/local/bin/telegram.sh $CONTACTADDRESS1$ "***** #Nagios_Instance_Name ***** Host $HOSTNAME$ is $HOSTSTATE$ - Info: $HOSTOUTPUT$"

}

define command{

command_name service-notify-by-telegram

command_line /usr/local/bin/telegram.sh $CONTACTADDRESS1$ "***** #Nagios_Instance_Name ***** $NOTIFICATIONTYPE$ $HOSTNAME$ $SERVICEDESC$ $SERVICESTATE$ $SERVICEOUTPUT$ $LONGDATETIME$"

}





Последний штрих — замониторить сам Телеграм


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


  1. Каждую минуту запускаем клиент, в котором запрашиваем список контактов, после — проверяем код выхода из клиента, если всё хорошо — это всегда должен быть ноль. (Делается отдельным bash скриптом, мы думаем у вас не возникнет проблем в написании своей реализации такой проверки)

  2. Проверяем, что в логе отправки сообщений нету строк, содержащих «FAIL», именно это ключевое слово свидетельствует о том, что при отправке уведомлений что-то идёт не так. (Мы используем для этой проверки check_logfiles)

  3. Проверяем, что экземпляры telegram-cli не подвисли, а в системе не появляется всё больше и больше экземпляров этого процесса, которые стремятся оставить ваш сервер без оперативной памяти. (Для такого мониторинга отлично подойдёт стандартный check_procs)






Факап №5 — Не замониторить локального агента отправки уведомлений в Telegram.

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




Почему локальный неофициальный клиент, вместо официального API в облаке?


1. telegram-cli регулярно обновляется, поэтому работает он стабильно и имеет весь нужный нам функционал.

2. За API всё равно нужно следить, например во время релиза Bot Api 2.0 с ним были замечены сбои, в то время, как обычный клиент работал исправно.

3. Так как мы не используем никакое общение с нашим роботом и не управляем с его помощью мониторингом, нас просто устраивает текущее решение. Работает — не трогай.



Нераскрытые возможности Телеграм в связке мониторингом


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

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

Вот как, к примеру, как у нас реализован механизм «резервных» каналов, здесь представлена упрощенная версия кода, для того, чтобы вам проще было в нём разобраться.



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



Удачи с мониторингом ваших проектов и большого аптайма вам, коллеги!
Original source: habrahabr.ru.

https://habrahabr.ru/post/306272/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Перевод] Анонс публичной бета-версии NGINX Amplify

Понедельник, 11 Июля 2016 г. 12:04 (ссылка)





Мы рады представить бесплатную бету NGINX Amplify, нашего нового инструмента для мониторинга NGINX и NGINX Plus. Используя NGINX Amplify, вы сможете отслеживать и контролировать NGINX и приложения, которые он обслуживает. Новый инструмент позволит быстро решать проблемы с производительностью и доступностью отдельных сервисов и инфраструктуры в целом. На текущий момент он включает в себя гибко настраиваемую панель мониторинга с механизмом оповещений, а также систему автоматических рекомендаций по оптимизации производительности и улучшению безопасности.



Узнать больше и увидеть NGINX Amplify в действии можно записавшись на онлайн вебинар, который пройдет 13 июля в 20:00 по московскому времени.



Также, вы можете начать бесплатно использовать NGINX Amplify прямо сейчас пройдя регистрацию.





Легкий доступ к ключевым показателям производительности в настраиваемой панели мониторинга NGINX Amplify



Установка проста и не отнимет больше 5 минут. C NGINX Amplify вы получите:




  • Рекомендации по безопасности и оптимизации – NGINX Amplify тщательно анализирует вашу конфигурацию NGINX и советует изменения для повышения производительности и безопасности. Каждая рекомендация содержит номер строки с цитируемой директивой, описание проблемы и способ её устранения.

  • Мониторинг в реальном времени – NGINX Amplify это единая панель мониторинга всех ваших серверов с NGINX. Она собирает сотни различных метрик из NGINX, лог-файлов и операционной системы, предоставляя гибко настраиваемый интерфейс для их отображения (на картинке выше). Метрики могут быть агрегированы с целого кластера NGINX серверов для общей оценки или отфильтрованы вплоть до уникального интерфейса. Мониторинг работает как с бесплатной версией NGINX, так и с коммерческой, NGINX Plus, где пользователям доступны дополнительные метрики.

  • Настраиваемые оповещения – NGINX Amplify отправляет сообщение, когда система требует внимания. Любая метрика, собираемая в NGINX Amplify, может являться критерием для отправки оповещений. К примеру, сообщение может быть сгенерировано когда количество ошибок с кодами 5хх превысило установленную вами границу.



Учитывая нашу уникальную позицию в роли веб-сервера, прокси и балансировщика для веб-сервисов, мы считаем, что NGINX Amplify является прекрасным дополнением к существующим средствам мониторинга доступности и производительности. NGINX Amplify работает с использованием небольшого агента с открытым исходным кодом, который установливается на каждый сервер с NGINX. Агент самостоятельно собирает различные метрики для анализа и визуализации. Эти данные объединяются с той информацией, которая собирается самим NGINX (или NGINX Plus), чтобы представить целостную картину того, как функционирует ваш веб-сервис.



Мы приглашаем всех пользователей NGINX и NGINX Plus зарегистрироваться и извлечь выгоду из возможности анализировать и лучше контролировать свои веб-сервисы. Присоединившись к открытому бета-тестированию NGINX Amplify, уже через несколько минут вы получите визуализацию ключевых показателей и действенные советы по улучшению производительности и безопасности ваших сервисов.



Результаты закрытого бета-тестирования



NGINX Amplify был доступен для приватного тестирования с ноября прошлого года. Энтузиасты NGINX и те, кто испытывал наибольшую потребность в подобного рода мониторинге, стали первыми, кто присоединился к бета-тестерованию. И с переходом к фазе публичной беты мы рассчитываем на быстрый рост пользовательской базы.



Вот что первые пользователи могут сказать об NGINX Amplify:

“… [в одном случае] наше соединение с сетью пострадало и сервера были на короткий промежуток времени отрезаны от интернета. Наш собственный мониторинг не заметил проблемы, и если бы NGINX Amplify не обнаружил и не оповестил нас, мы бы даже не знали об этом факте.”
“Страница Reports (отчеты) полезна своим кратким обзором настроек сервера, а статический анализ помог нам выявить недостающие параметры конфигурации.”
“NGINX Amplify помог мне быстро решить проблемы благодаря секции Static analysis (статический анализ) на странице Reports.”


Подробнее о возможностях NGINX Amplify



Рекомендации по производительности и безопасности



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





NGINX Amplify анализирует вашу конфигурацию NGINX и дает советы по улучшению



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



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



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



Мониторинг в реальном времени



C NGINX Amplify вы можете вывести все необходимые метрики на единую панель на вкладке Dashboards (приборная панель). Среди показателей вам доступны:




  • Индивидуальные метрики – например, количество используемого процессорного времени каждым сервером;

  • Агрегированные метрики – такие, как общая пропускная способность по всем серверам с NGINX;

  • Метрики, относящиеся к производительности приложений, включая время ответа.



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





В NGINX Amplify вы можете создавать свои собственные панели мониторинга с необходимыми показателями



NGINX Plus собирает дополнительные метрики, связанные с производительностью бекенда. Пользователи NGINX Plus получают приемущества от визуализации этих метрик в NGINX Amplify и возможности просмотра их за предыдущие промежутки времени:




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

  • Работоспособность каждого бекенда, включая количество ошибок и как часто сервер испытывал проблемы;

  • Время работы, объем трафика и прочая критическая информация.



Оповещения



Вы можете настроить оповещения на странице Alerts (оповещения), так что NGINX Amplify оповестит вас когда система будет не в порядке. NGINX Amplify собирает широкий набор метрик с системы, которые могут быть использованы как критерии для генерации оповещения.





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



Одно из оповещений на снимке настроено так, что NGINX Amplify отправит письмо на me@example.com когда процессор будет занят более чем на 95% в течение 10 и более минут, что может служить сигналом того, что сервер перегружен. Вы можете указать любой почтовый адрес, например перенаправить сообщение в сервис PagerDuty. После первичного оповещения, NGINX Amplify будет отправлять дайджест каждые 30 минут по всем обнаруженным ошибкам до тех пор, пока все проблемы не будут устранены.



Резюме



NGINX является одним из самых критичных компонентов в инфраструктуре обслуживания ваших сервисов. NGINX Amplify поможет отследить то, что NGINX и ваши приложения функционируют исправно, в том числе на пике нагрузки. Мы приглашаем всех зарегистрироваться сегодня на бесплатное открытое бета-тестирование и оставить свои отзывы, используя кнопку Intercom в правом нижнем углу после входа в NGINX Amplify.
Original source: habrahabr.ru.

https://habrahabr.ru/post/305384/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
kosromole

Пять поколений систем спутникового мониторинга транспорта

Пятница, 08 Июля 2016 г. 18:15 (ссылка)
asupro.com/gps-gsm/fuel/fiv...sport.html


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



Пять поколений систем спутникового мониторинга транспорта

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

systemd: getty-подобный сервис для htop

Суббота, 02 Июля 2016 г. 16:47 (ссылка)

htop — это интерактивная программа для наблюдения за процессами; она — альтернатива программы top. Каждый, кто работает за машиной с линуксом на борту, хоть раз использовал её: будь то поиск процесса (и его последующее убийство) или тщательный мониторинг используемых ресурсов.





Для удобства это программу можно держать всегда запущенной: в отдельном окне терминала, в его вкладках или на каком-нибудь рабочем столе. Но есть ещё одно решение: запускать его на фиксированном VT, на который можно в любой момент переключиться. Преимущество такого подхода заключается в чистом окружении и независимости от иксов/терминала.



Это возможно (и правильно) сделать с помощью системы инициализации, потому что мы фактичесски хотим получить специальный getty-подобный сервис для htop.



Как запускаются VT1, ..., VT6?



agetty — это такая программа, которая открывает порт tty, выдаёт prompt для аутентификации и передаёт последующее управление другой программе — login.



$ which agetty login | xargs ls -l
-rwxr-xr-x 1 root root 44104 Sep 29 05:21 /usr/bin/agetty
-rwxr-xr-x 1 root root 35968 Sep 29 05:21 /usr/bin/login


Традиционные системы инициализации Linux конфигурируются на запуск фиксированного количества agetty при загрузке. В большинстве случаев рождаются шесть инстансов для шести VT: от tty1 до tty6 соответственно. В systemd используется другой подход.




  • Первый — динамический. Инстанс сервиса getty@.service запускается по требованию. То есть только в том случае, если нам нужен какой-то конкретный VT. За это отвечает logind, который при переключении на ttyN запускает сервис autovt@ttyN.service, который является симлинком на getty@.service. Такая логика работает для tty2-tty6.

  • Второй — статический. Конкретный инстанс сервиса getty@.service втягивается автоматически через getty.target, что даёт нам всегда запущенный getty на tty1.



systemctl cat getty@.service покажет содержимое этого сервиса. Рассматривать подробно мы его не собираемся, поскольку это для нас не столь важно.



Соответственно, если предположить, что у нас есть некий htop@.service, то и добавить его в автозагрузку можно двумя путями: либо сделать симлинк под именем autovt@ttyN.service — тогда при переключении на выбранный VT htop будет запускаться вместо getty, либо отключить getty@ttyN.service и вместо него включить htop@ttyN.service — это даёт нам всегда запущенный htop на фиксированном VT.



Пишем собственный getty-подобный юнит



Теперь переходим в /etc/systemd/system — одна из директорий, где располагаются юниты, — и создаём собственный сервис:



$ "$EDITOR" htop@.service


Наличие суффикса (@) означает, что стартует не сам по себе сервис, а один из его инстансов. А суффикс передаётся в него парамметром (%i и %I).



Выше уже было отмечено, что содержимое getty@.service для нас не столь важно. Всё так, потому что его можно заинклюдить в наш сервис:



.include /usr/lib/systemd/system/getty@.service


Если учесть, что наш сервис getty-подобный, то эта конструкция избавляет нас от лишнего копирования кода.



Секция User



Здесь описываются общие парамметры, применимые к любому типу юнита.



[Unit]
Description=htop on %I
Documentation=man:htop(1)


Здесь всё прозрачно: директива Description задаёт краткое описание юнита, а Documentation путь к документации. %I — имя инстанса. Важно заметить, что обе переменные, задающие имя инстанса, различны по значению: %I — тоже самое, что и %i, но она не экранирует escape-последовательности.



Секция Service



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



[Service]
Environment=
Environment=TERM=linux HOME=/root
ExecStart=
ExecStart=/usr/bin/htop
StandardInput=tty-fail
StandardOutput=tty


Необходимые унаследованные значения директив мы оставим в покое, а некоторые нам необходимо сбросить (задаём для них пустое значение) и определить самостоятельно. К таковым относятся Environment — задание переменных, и ExecStart, — собственно, запуск процесса.



StandardInput=tty-fail
StandardOutput=tty


— это указание systemd запускать htop подсоединённым напрямую к терминалу.



Можно, кстати, добавить не мгновенный запуск, а с ожиданием ввода. Для этого создаём простой скрипт на баше:



#!/bin/bash

echo "Press a key to launch $(basename "$1")"
read
exec "$@"


Всё что он делает — ожидает ввода и запускает какую-то программу (которой будет являться htop в нашем случае). Помещаем куда угодно, называем как угодно, делаем его исполняемым (chmod +x) и правим ExecStart в нашем сервисе:



ExecStart=/etc/systemd/scripts/run_wait /usr/bin/htop


Ограничиваем права



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



Создаём копии нашего сервиса и скрипта к нему:



$ cd /etc/systemd
$ cp system/htop@.service system/htop_secure@.service
$ cp scripts/run_wait scripts/run_wait_su


И редактируем каждый из них. Для сервиса в секции Service изменяем значение Environment и задаём имя пользователя с его группой:



User=kalterfive
Group=users
Environment=TERM=linux


А в скрипте обращаемся к su(1):



#!/bin/bash
echo "Press a key to launch $(basename "$1")"
read
exec su -c "$@"


Установка сервиса



Теперь наш сервис готов, осталось только добавить его в автозагрузку:



$ systemctl daemon-reload
$ systemctl disable getty@tty2.service
$ systemctl enable htop@tty2.service


Первая команда обновляет менеджер конфигурации systemd, а вторая создаёт симлинк на наш сервис в getty.target.wants.



Заключение



Теперь перезагружаемся (либо вручную убиваем getty@ и включаем htop@ для инстанса tty2), переключаемся на второй VT и наблюдаем успешно запущенный htop. Продемонстрированный трюк задевает лишь малую часть systemd, как системы инициализации, от всего простора его возможностей, как универсального plumbing layer-а — набора программ для решения совершенно разных задач. Успехов!




Original source: habrahabr.ru.

https://habrahabr.ru/post/304594/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество

Следующие 30  »

<мониторинг - Самое интересное в блогах

Страницы: [1] 2 3 ..
.. 10

LiveInternet.Ru Ссылки: на главную|почта|знакомства|одноклассники|фото|открытки|тесты|чат
О проекте: помощь|контакты|разместить рекламу|версия для pda