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


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

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

Следующие 30  »
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)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

9 секретов онлайн-платежей. Часть 7: система Fraud-мониторинга

Четверг, 23 Июня 2016 г. 20:40 (ссылка)

imageПочему отклоняются платежи? Как интернет-магазины защищаются от мошенников? Как определить, настоящей картой вам платят или ворованной? Что обеспечивает защиту e-commerce от фрода? Ответы на эти вопросы вы найдете в седьмой части серии авторских статей «9 секретов онлайн-платежей» от PayOnline.



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



Часть 1. Настройка 3D Secure

Часть 2. Регулярные платежи

Часть 3. Страница выбора способа оплаты

Часть 4. Платежная форма

Часть 5. Мобильные платежи

Часть 6. Оплата в один клик

Часть 7. Система fraud-мониторинга

Часть 8. Возвраты и как их избежать

Часть 9. Настройки платежного сервиса под тип бизнеса



Что такое антифрод и как он работает



Общая схема работы практически любого механизма фрод-мониторинга выглядит следующим образом: в момент совершения оплаты с помощью банковской карты собирается несколько показателей (у каждой антифрод системы они разные) – начиная от IP адреса компьютера и заканчивая статистикой оплат по этой карте. Количество фильтров может превышать сотню (например, у системы электронных платежей PayOnline их более 120). Система имеет набор правил, то есть лимитов фильтров безопасности. Каждый из фильтров проверяет пользователя — его персональные и карточные данные. Цель системы — убедиться в том, что пользователь является реальным владельцем карты, совершающим покупку на сайте. В случае выявления подозрительной активности, то есть превышения какого-либо значения параметра, фильтр автоматически блокирует возможность совершения платежа по этой карте. Рассмотрим процесс работы антифрод системы пошагово.



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




  • Страна, из которой совершается платеж.

  • Страна банка, выпустившего карту.

  • Размер платежа.

  • Количество платежей с карты.

  • Платежная история банковской карты.

  • Профиль среднестатистического плательщика магазина.



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



«Судьба» каждой метки индивидуальна. В графическом виде мы представили жизненный цикл транзакций всех трех типов на Рисунке 1. Далее на нескольких простых примерах мы рассмотрим типовые транзакции всех «цветов» и расскажем, какие проверки определяет транзакциям система fraud-мониторинга в зависимости от уровня риска возникновения фрода.



image

Рисунке 1. «Жизненный цикл» транзакций с разными уровнями риска возникновения мошеннической операции



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



Система мониторинга присваивает транзакции «зеленую» метку. Далее транзакция отправляется на авторизацию с помощью 3-D Secure. А если карта не подписана на сервис одноразовых паролей или банк-эмитент еще не поддерживает данный сервис, запрос на авторизацию этой транзакции будет направлен в процессинговый центр банка-плательщика обычным способом — напрямую.



Средний уровень риска возникновения fraud-а определяет иной путь проверки оплаты на легитимность. Метка «желтого» цвета присваивается транзакциям со средним и выше среднего уровнями риска возникновения мошеннических операций. Например, в российском интернет-магазине покупка оплачивается банковской картой, выпущенной в России, но размер среднего чека заметно превышает средний «по больнице».



Система помечает данную транзакцию «желтой» меткой, и для ее авторизации могут потребоваться дополнительные действия плательщика. Если карта подписана на 3-D Secure, то транзакция (как и в случае с «зеленой» меткой), будет авторизована с использованием одноразового пароля. Однако если плательщик не может воспользоваться этим способом авторизации платежа, то его банковская карта будет автоматически направлена на онлайн-валидацию или ручную проверку.



«Красную» метку система фрод-мониторинга автоматически присваивает транзакциям с высоким уровень риска совершения мошеннических операций. Например, оплата в российском интернет-магазине осуществляется картой, выпущенной в США, а плательщик находится в Испании.



Если платежи с помощью данной банковской карты ранее не совершались через PayOnline, система fraud-мониторинга пометит транзакцию «красной меткой» и переведет ее из автоматического режима авторизации в ручной. Такой платеж будет отправлен на ручную модерацию специалистам департамента рисков. Для аутентификации владельца банковской карты потребуется документальное подтверждение — отсканированное изображение банковской карты и документа, удостоверяющего личность владельца. После предоставления корректных сканов документов операция переводится из «красного» в «зеленый» цвет и направляется на авторизацию в процессинговый центр банка. Сомнительные операции, не прошедшие ручную модерацию, отклоняются во избежание риска возникновения мошеннических операций.



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



Что настораживает систему фрод-мониторинга?



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




  • Оплата по одной карте происходит с различных устройств, идентифицированных различными IP адресами.

  • Обратная ситуация — с одного и того же устройства (IP адреса) производятся операции с помощью большого количества карт.

  • С одной карты совершается несколько неудачных попыток оплаты (вероятно, пользователь не имеет возможности пройти процедуру подтверждения).

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

  • Имя плательщика, указанное на платежной форме, отличается от имени владельца карты.

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



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



Ручная настройка: зачем и кому она нужна



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




  • среднестатистический профиль плательщика,

  • размер среднего чека,

  • уровень рисков в сегменте,

  • особенности реализуемых товаров и услуг (цифровые они или физические).



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



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



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



Собственноручное вмешательство в работу системы может привести к большим потерям — при одобрении мошеннических операций интернет-магазин будет обязан вернуть деньги на карту владельца, даже если товар уже был отгружен мнимому покупателю. Более того, на магазин может быть наложен штраф в зависимости от объемов мошенничества, а при повторении подобных ситуаций — особые санкции от международных платежных систем (МПС).



Плюсы и минусы системы антифрод



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



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



При выборе платежного сервис-провайдера стоит обратить внимание на заявленную конверсию в успешные платежи: сервисы, гарантирующие «100% успешных оплат», скорее всего, либо намеренно переоценивают свой функционал, либо подвергают клиентов риску стать жертвой злоумышленников. Например, уровень конверсии в успешные платежи после «ручной» настройки (или у стандартных интернет-магазинов со стандартной клиентской аудиторией) системы электронных платежей PayOnline варьируется в рамках 93-96% — и это очень хороший показатель для рынка.



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



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



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



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



Для малого и среднего бизнеса разработка собственного антифрода — это неподъемный и не окупающийся проект. Требования к подобным механизмам растут с каждым годом, они учатся более тонко обрабатывать получаемую информацию, учитывая статистику и поведенческие факторы. Чтобы система работала эффективно и соответствовала современным требованиям, необходим штат квалифицированных специалистов и значительные технические мощности. В подавляющем большинстве случаев игрокам электронной коммерции «не по карману» такие постоянные затраты — и мониторинг мошеннических операций делегируются платежным сервис-провайдерам, специализирующимся на анализе и обработке платежных операций. Так, к примеру, деятельность по мониторингу мошеннических платежных операций в PayOnline осуществляет система Fraud Management System (FMS), разработанная нашими специалистами. Она позволяет произвести тонкую настройку безопасности по 140 фильтрам. Если вы заинтересованы в приеме платежей на сайте или в мобильном приложении, защищенных антифрод-системой, смело обращайтесь, проконсультируем и подключим.



В следующей части «9 секретов онлайн-платежей» обсудим еще одну очень важную для любого продавца тему — чардж-бэк: Что делать, если услуга оказана или товар отгружен, а клиент или банк требуют вернуть деньги обратно на карту плательщика? Как можно избежать возвратов? Какие требования обычно предъявляются к сайту интернет-магазина? Скоро в нашем блоге.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/303204/

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

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

Вторник, 14 Июня 2016 г. 15:09 (ссылка)
vsemmoney.ru/topic/3723-eli...s-vyvodom/


ELITE-MONITORING.RU - ХАЙП МОНИТОРИНГ И МОНИТОРИНГ ИГР С ВЫВОДОМ - отправлено в Мониторинги HYIP: Здравствуйте, хотел бы ознакомить вас со своим проектом - Хайп мониторинг. Он довольно сильно окутан энтузиазмом, тем не менее является неплохим советником в омуте финансовых потоков сети интернет. Кстати, возмещение вам партнерского дохода (refback) составляет 90%.

 

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

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

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

Вторник, 14 Июня 2016 г. 15:09 (ссылка)
vsemmoney.ru/topic/3723-eli...s-vyvodom/


ELITE-MONITORING.RU - ХАЙП МОНИТОРИНГ И МОНИТОРИНГ ИГР С ВЫВОДОМ - отправлено в Мониторинги HYIP: Здравствуйте, хотел бы ознакомить вас со своим проектом - Хайп мониторинг. Он довольно сильно окутан энтузиазмом, тем не менее является неплохим советником в омуте финансовых потоков сети интернет. Кстати, возмещение вам партнерского дохода (refback) составляет 90%.

 

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

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

[Из песочницы] Как обмануть GPS Глонасс без вандализма

Среда, 08 Июня 2016 г. 14:49 (ссылка)

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



Во всех случаях нам понадобится компьютер, с постоянным доступом в интернет, на котором мы будем поднимать сервер и прокидывать порты (я использовал nginx+node.js).



Способ первый (без доступа к серверу мониторинга)



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



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



Код вашего сервера
var net = require('net');

var server = net.createServer(function(socket) {

var client = new net.Socket();
client.connect(АдресСервера, '7113', function() {
console.log('Connected');
});

socket.on('data', function(data) {
console.log('> ' + data);
client.write(data);
});

client.on('data', function(data) {
console.log('< ' + data);
socket.write(data);
});

});

server.listen(ВашАдрес, '7113');




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



Способ второй (с доступом к серверу)



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



Способ третий (пропуск конечного трафика через себя)



Если у вас нет прямого доступа к серверу мониторинга, можно пропустить трафик клиентов через себя. И модифицировать передаваемые данные. Для этого я также воспользовался node.js. При помощи модуля http поднимаем сервер:



var server = http.createServer(function(request, response) {...}).listen(80)



Где делаем запрос к серверу:



var proxyRequest = http.request(options)



В качестве параметров указываем адрес, порт и пр. (пример можно посмотреть на гитхабе). И обрабатываем (при необходимости модифицируем ответ сервера):



proxyRequest.on('response', function(proxyResponse) {....}



Вот некоторые способы изменить пробег в программе мониторинга. Если кому интересно, могу написать подробнее.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/302900/

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

Обмен валют. Мониторинг обменников Newll.ru

Воскресенье, 05 Июня 2016 г. 12:26 (ссылка)
newll.ru/?_utl_t=li

Мониторинг обменных пунктов Newll.ru Обмен валют

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

Следующие 30  »

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

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

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