Масштаб компании никак не связан с величиной отдела.
Где-то весь отдел – это 40 человек с группами по компонентам.
Где-то — 2 человека.
Делать по-другому не сложно, и можно наворотить целый комбайн, который потом нужно будет поддерживать.
Можно написать свой мониторинг.
Мой посыл в том, что большое и сложное решение не всегда нужно небольшой команде эксплуатации.
Есть задача, а то, как она решается (сложно или просто) – большого значения не имеет.
Статья в стиле «мы молодцы, сделали вот такую крутую штуку под свои нужды и потребности, но вам она ни к чему и использовать у себя вы не сможете» вызвала бы диссонанс у кого-то ещё.
Можно. Есть и просто приложения для отправки пушей. Пуши общаются через сервер, да и телефон в два счёта можно превратить в вибрирующую коробочку.
На мобильном мы используем или SMS, или почту (там тоже есть пуши :), или HipChat/Telegram если мы про мессенджеры.
Речь как раз про то, что поллить апи заббикса не нужно зачастую.
Это долго, тяжело, и не всегда оправдано.
Завтра умрёт этот клиент (хотя я не уверен, что он прям развивается) — что делать?
А для Linux есть аналог?
«Мучал» — не совсем корректное описание для данного решения. Написано оно было давно и не менялось.
У нас есть дашборд для отрисовки проблем. В статей же речь идёт об уведомлении и привлечении внимания.
А по поводу «поллинга заббикса» — поделитесь, какая у вас нагрузка. Сколько триггеров, хостов, и тд. Так можно и до «зачем клиент написали, ведь есть стандартный дашборд» дойти.
Не поймите меня неправильно, но даже при открытии Хабра используется IP адрес.
И когда мы подключаемся к локальной сети — нам выдаётся айпишник.
Который можно использовать :)
Там в середине статьи есть спойлер, в котором описано, как можно обойтись без этого знания.
В качестве "регистрации" десктопа используется ssh -> who -> запись айпишника в файл. Нас мало, это нужно буквально десяти людям. Делать какую-то систему регистрации/авторизации под это дело — долго, и вообще странно.
А если это надо одному человеку, который может статикой прибить свой айпишник в офисном dhcp — вообще проблемы отпадают.
Точно так же можно сказать и про SMS: ведь никого не смущает необходимость знать номер, чтобы отправить сообщение. А в некоторых случаях ещё и разрешение владельца на отправку сообщений.
В конце поста есть список победителей со списком вопросов.
Чем понравились – перекрёстное субъективное мнение всех участников ответов: каждый голосовал за вопросы, которые ему понравились, в итоге образовался топ-3, это они :)
Привет! К сожалению, билеты уже всё, но на вопрос, конечно, отвечу.
Наши инструменты – не серебряная пуля, не универсальны.
Zabbix – уже позволяет много автоматизировать и кастомизировать в зависимости от окружения и потребностей.
Насколько я могу судить – людей с такими же проблемами и задачами, как у нас – единицы.
Чтобы открывать и выкладывать в открытый доступ – нужно либо много исправлять (времени нет), либо изначально делать с учётом на паблик (но никогда не знаешь, что получится в итоге).
Мы же решаем задачи, а не создаём сервисы.
Как-то так.
Но мы постараемся!
P.S. Оповещения для Telegram делались именно с расчётом на открытость и массовое использование, универсально для всех и каждого. Делается в свободное время и начинал его как pet project на зимних каникулах :)
Спасибо за вопрос и пищу для размышлений – возможно, станет темой для доклада на следующем митапе :)
Применение Zabbix возможно в современном стеке технологий.
Теперь подробнее и по порядку.
Мы используем Заббикс не только для инфраструктуры: серверы, диски, сеть, память, проц; но и для приложений: работоспособность сервисов, внутренние метрики [время ответа, cpu usage per instance, свежесть данных в них, наличие бэкапов [для всех или выборочно] сервисов.
Сервисы – различные, как опенсорсные, так и внутренние. Например, nginx, php-fpm MySQL, Tarantool. Внутренние, понятное дело, называть не буду, смысла нет.
Под каждый сервис – обычно заводится мониторинг с нуля (очень-очень редко берём готовые шаблоны из паблика, да и то – сильно правим их). Во-первых, мы всегда можем и должны ответить на вопрос “что это и зачем”, во-вторых, есть правила, по которым мы всё добавляем более или менее однообразно.
“Заббикс ничего не умеет” – у нас очень много кастомных скриптов, которые проверяют всё подряд. Заббикс умеет запускать эти скрипты с разными шаблонными параметрами.
Чтобы каждый раз ручками не кликать в интерфейсе – используем API, в основном для заведения хостов, (благо, библиотек полно) и LLD (low level discovery), для заведения айтемов/триггеров.
Как мониторим
Обычно: идём на порт демона и опрашиваем его.
Редко: идём в файловую систему (например, демон пишет дампы каждый час, они важны, надо проверять работоспособность), в случае с контейнерами – тяжелее добраться до файлов (пути не очевидные, либо добраться нужно через docker), но это возможно (и мы так делаем).
Иногда: сходить в базу, населектить значения. Например, очередь в MySQL – SELECT COUNT(*). Или сходить по определённому урлу – nginx status page.
По поводу контейнеров: контейнер для нас (мониторинга) – просто сервис. Точнее, все наши сервисы (или почти все) живут в контейнерах, поэтому нам особой разницы нет, что мы мониторим: сервис, запущенный через systemd, или сервис, который живёт в контейнере. Нам важно то, как мы его мониторим – это обсуждается, как уже говорил, для каждого сервиса отдельно (или дорабатывается в процессе эксплуатации)
Как мы узнаём о том, что и где мониторить? Написали свою дискаверилку всего-всего, которая умеет добавлять хосты, писать адекватные логи, линковать с нужными шаблонами, класть их в нужные группы и выдавать необходимые права (если используете Zabbix и его внутреннюю дискаверилку хостов – точно натыкались на её непрозрачную работу). Суть работы простая – проверяем «где должно быть», смотрим в заббиксе «где уже есть», недостающие создаём и цепляем к шаблонам, лишние удаляем.
Чаще всего дискаверим (для сервисов) из DNS и PuppetDB (если интересно об этом, тут Антон Турецкий banuchka может прокомментировать откуда Puppet знает про сервисы, да и он вроде уже рассказывал на Хайлоаде).
Отдельно про DNS – повелось давно, чтобы можно было переносить сервисы без изменения каких-либо конфигов: перекинул сервис/контейнер, перекинул dns запись, код пошёл к новому хосту. И мониторинг – обращаемся по DNS имени, не нужно менять ничего в нашей системе. По сути, на один инстанс сервера имеется одна DNS запись.
Далее – два варианта:
цепляем целиком хост (dns алиас) к шаблону
цепляем шаблон с low level discovery к имеющемуся хосту: lld приходит на хост, проверяет, какие сервисы должны быть на хосте и уже мониторит их пачками (таким образом, при переезде сервисов у нас один набор проверок удаляется на одном реальном хосте и появляется на другом, lld же)
Очень редко – бывает, что нужно мониторить работу контейнера, но это укладывается в первый вариант «понять, где нужно проверять работоспособность и прицепить нужный шаблон к нужному хосту».
Схема в первом случае выглядит так:
<шаблон> –> (дискавери работает) –> <хост для сервиса> –> , , …
Схема во втором случае:
<шаблон> –> (дискавери работает) –> <хост, где живут сервисы/контейнеры> –> (low level дискавери работает) –> , , , , …
Выводы
У нас есть своя дискаверилка – прицепить туда Consul не составляет большого труда (нет, сейчас не используем, он у нас в качестве эксперимента и/или используется только для инфраструктурных сервисов)
Контейнеры мониторить можно, разными способами. Но мы мониторим не контейнеры, а сервисы – это важно понимать (ок, если надо контейнеры – мониторим, как описал выше)
Точно знаю, что есть много людей, которые говорят, что «заббикс не предназначен для мониторинга контейнеров!!!11 в моём прометеусе это делается из коробки!!1» (или тулзами, которые умеют взаимодействовать с ним)
В целом – да.
Но если у вас уже есть одна система (как у нас) и она работает давно, и вам не хочется поддерживать несколько систем мониторинга – заббикс можно научить работать с тем, что вам нужно.
Не устану повторять, что Zabbix – это просто платформа, а не готовое решение. Ровно как и Prometheus – вам нужно будет настроить его, прежде чем катить в прод.
P.S. Как-то рассказывал, как мы скрестили заббикс и аппликейшен/бизнес метрики: www.youtube.com/watch?v=QhFpVc_iHKA так что, возможно всё :)
Трансляции не будет, но вы можете оставить список вопросов на meetup.com, думаю, ребята с радостью ответят после доклада, чтобы вопросы-ответы попали в запись.
Ещё немножко подолью масла.
Запустились в Москве, открыли интернет-магазин.
Ну, думаю, выберу номер, закажу, заберу.
Выбрал, заказал.
Приходит письмо:
Мы получили Ваш заказ. Подтвержденные в заказе номера бронируются за клиентом на 3 календарных дня.
Еду на следующий день (в офис на Сущевском), а мне там говорят «знаете, у нас проблемы с интернет-магазином, мы не можем выдать ваш заказ, но вы можете оставить ваш номер и имя, мы вам обязательно перезвоним, когда всё наладится».
Оставил номер и имя.
Было это 23 и 24 октября соответственно (дата заказа и дата похода в офис).
Либо у них уже три недели не работает интернет-магазин (о чём на сайте они так и не написали).
Либо они плевали на то, что кто-то что-то там заказал через него.
Либо они потеряли листочек, куда записывали мои данные.
Собственно, три дня давно прошло, а значит я потерял номер, который выбирал. Ну и они так и не перезвонили и не написали.
Что там с мобильной связью, так же всё плохо?
Где-то весь отдел – это 40 человек с группами по компонентам.
Где-то — 2 человека.
Делать по-другому не сложно, и можно наворотить целый комбайн, который потом нужно будет поддерживать.
Можно написать свой мониторинг.
Мой посыл в том, что большое и сложное решение не всегда нужно небольшой команде эксплуатации.
Есть задача, а то, как она решается (сложно или просто) – большого значения не имеет.
Статья в стиле «мы молодцы, сделали вот такую крутую штуку под свои нужды и потребности, но вам она ни к чему и использовать у себя вы не сможете» вызвала бы диссонанс у кого-то ещё.
Смотря под каким углом посмотреть.
Вот только звуковое сопровождение в оупен-спэйсе — зло. :)
Ссылка ведёт на 3.0 – потому что это последний мажорный LTS релиз (вроде бы, но не суть)
:)
На мобильном мы используем или SMS, или почту (там тоже есть пуши :), или HipChat/Telegram если мы про мессенджеры.
Это долго, тяжело, и не всегда оправдано.
Завтра умрёт этот клиент (хотя я не уверен, что он прям развивается) — что делать?
А для Linux есть аналог?
«Мучал» — не совсем корректное описание для данного решения. Написано оно было давно и не менялось.
У нас есть дашборд для отрисовки проблем. В статей же речь идёт об уведомлении и привлечении внимания.
А по поводу «поллинга заббикса» — поделитесь, какая у вас нагрузка. Сколько триггеров, хостов, и тд. Так можно и до «зачем клиент написали, ведь есть стандартный дашборд» дойти.
Не поймите меня неправильно, но даже при открытии Хабра используется IP адрес.
И когда мы подключаемся к локальной сети — нам выдаётся айпишник.
Который можно использовать :)
Там в середине статьи есть спойлер, в котором описано, как можно обойтись без этого знания.
В качестве "регистрации" десктопа используется ssh -> who -> запись айпишника в файл. Нас мало, это нужно буквально десяти людям. Делать какую-то систему регистрации/авторизации под это дело — долго, и вообще странно.
А если это надо одному человеку, который может статикой прибить свой айпишник в офисном dhcp — вообще проблемы отпадают.
Точно так же можно сказать и про SMS: ведь никого не смущает необходимость знать номер, чтобы отправить сообщение. А в некоторых случаях ещё и разрешение владельца на отправку сообщений.
А пожалуйста: https://github.com/ableev/Zabbix-in-Telegram :)
Но отправить сообщение в мессенджер — это "через десятые руки" + задержка получения + надо открыть + надо увидеть более критичное.
Чем понравились – перекрёстное субъективное мнение всех участников ответов: каждый голосовал за вопросы, которые ему понравились, в итоге образовался топ-3, это они :)
Наши инструменты – не серебряная пуля, не универсальны.
Zabbix – уже позволяет много автоматизировать и кастомизировать в зависимости от окружения и потребностей.
Насколько я могу судить – людей с такими же проблемами и задачами, как у нас – единицы.
Чтобы открывать и выкладывать в открытый доступ – нужно либо много исправлять (времени нет), либо изначально делать с учётом на паблик (но никогда не знаешь, что получится в итоге).
Мы же решаем задачи, а не создаём сервисы.
Как-то так.
Но мы постараемся!
P.S. Оповещения для Telegram делались именно с расчётом на открытость и массовое использование, универсально для всех и каждого. Делается в свободное время и начинал его как pet project на зимних каникулах :)
Спасибо за вопрос и пищу для размышлений – возможно, станет темой для доклада на следующем митапе :)
Применение Zabbix возможно в современном стеке технологий.
Теперь подробнее и по порядку.
Как мониторим
Обычно: идём на порт демона и опрашиваем его.
Редко: идём в файловую систему (например, демон пишет дампы каждый час, они важны, надо проверять работоспособность), в случае с контейнерами – тяжелее добраться до файлов (пути не очевидные, либо добраться нужно через docker), но это возможно (и мы так делаем).
Иногда: сходить в базу, населектить значения. Например, очередь в
MySQL – SELECT COUNT(*). Или сходить по определённому урлу – nginx status page.По поводу контейнеров: контейнер для нас (мониторинга) – просто сервис. Точнее, все наши сервисы (или почти все) живут в контейнерах, поэтому нам особой разницы нет, что мы мониторим: сервис, запущенный через systemd, или сервис, который живёт в контейнере. Нам важно то, как мы его мониторим – это обсуждается, как уже говорил, для каждого сервиса отдельно (или дорабатывается в процессе эксплуатации)
Как мы узнаём о том, что и где мониторить?
Написали свою дискаверилку всего-всего, которая умеет добавлять хосты, писать адекватные логи, линковать с нужными шаблонами, класть их в нужные группы и выдавать необходимые права (если используете Zabbix и его внутреннюю дискаверилку хостов – точно натыкались на её непрозрачную работу). Суть работы простая – проверяем «где должно быть», смотрим в заббиксе «где уже есть», недостающие создаём и цепляем к шаблонам, лишние удаляем.
Чаще всего дискаверим (для сервисов) из DNS и PuppetDB (если интересно об этом, тут Антон Турецкий banuchka может прокомментировать откуда Puppet знает про сервисы, да и он вроде уже рассказывал на Хайлоаде).
Отдельно про DNS – повелось давно, чтобы можно было переносить сервисы без изменения каких-либо конфигов: перекинул сервис/контейнер, перекинул dns запись, код пошёл к новому хосту. И мониторинг – обращаемся по DNS имени, не нужно менять ничего в нашей системе. По сути, на один инстанс сервера имеется одна DNS запись.
Далее – два варианта:
Очень редко – бывает, что нужно мониторить работу контейнера, но это укладывается в первый вариант «понять, где нужно проверять работоспособность и прицепить нужный шаблон к нужному хосту».
Схема в первом случае выглядит так:
<шаблон> –> (дискавери работает) –> <хост для сервиса> –> , , …
Схема во втором случае:
<шаблон> –> (дискавери работает) –> <хост, где живут сервисы/контейнеры> –> (low level дискавери работает) –> , , , , …
Выводы
У нас есть своя дискаверилка – прицепить туда Consul не составляет большого труда (нет, сейчас не используем, он у нас в качестве эксперимента и/или используется только для инфраструктурных сервисов)
Контейнеры мониторить можно, разными способами. Но мы мониторим не контейнеры, а сервисы – это важно понимать (ок, если надо контейнеры – мониторим, как описал выше)
Точно знаю, что есть много людей, которые говорят, что «заббикс не предназначен для мониторинга контейнеров!!!11 в моём прометеусе это делается из коробки!!1» (или тулзами, которые умеют взаимодействовать с ним)
В целом – да.
Но если у вас уже есть одна система (как у нас) и она работает давно, и вам не хочется поддерживать несколько систем мониторинга – заббикс можно научить работать с тем, что вам нужно.
Не устану повторять, что Zabbix – это просто платформа, а не готовое решение. Ровно как и Prometheus – вам нужно будет настроить его, прежде чем катить в прод.
P.S. Как-то рассказывал, как мы скрестили заббикс и аппликейшен/бизнес метрики: www.youtube.com/watch?v=QhFpVc_iHKA так что, возможно всё :)
Запустились в Москве, открыли интернет-магазин.
Ну, думаю, выберу номер, закажу, заберу.
Выбрал, заказал.
Приходит письмо:
Еду на следующий день (в офис на Сущевском), а мне там говорят «знаете, у нас проблемы с интернет-магазином, мы не можем выдать ваш заказ, но вы можете оставить ваш номер и имя, мы вам обязательно перезвоним, когда всё наладится».
Оставил номер и имя.
Было это 23 и 24 октября соответственно (дата заказа и дата похода в офис).
Либо у них уже три недели не работает интернет-магазин (о чём на сайте они так и не написали).
Либо они плевали на то, что кто-то что-то там заказал через него.
Либо они потеряли листочек, куда записывали мои данные.
Собственно, три дня давно прошло, а значит я потерял номер, который выбирал. Ну и они так и не перезвонили и не написали.
Что там с мобильной связью, так же всё плохо?
Alex_Morozov – возможно, будет интересно.