Ищите меня у одной высокопоставленной особы (c), ну

Имхо, для нормальной системе алертов и правда ничего нет

С мониторингом (набором данных/метрик) всё хорошо, а вот очень извращенное кастомное детектирование аномалий с вменяемым гуи нет

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

поделись :) ?

Завтра спрошу можно ли

спасиб

там реально с докой по роутингу плохо

и с примерами

По коду идешь и смотришь как оно работает. Оно грамотно написано

это тоже задача, вообще-то. Но да, мониторить десть хотсов (а хотя бы и 20!) можно чем угодно. Я когда-то RRDTools мониторил. А собирал данные через net::snmp.

десятки - это не десять и не двадцать. Но - не сотни

https://www.influxdata.com/influxdb-1-0-ga-released-a-retrospective-and-whats-next/

нет повода не выпить.

а

нет, есть повод не выпить. это же инфлюкс.

а что?

Вопрос в бездну, кто чем мониторит solaris 10;11 sparc ?

Я иногда глазами. Достаю раз в год диск, смотрю на него, убираю обратно в коробочку

А это мысль

скорее всего только collectd

Надеюсь оно умеет в зоны и прочие ораклоприколы

нет конечно

Надеюсь оно умеет в зоны и прочие ораклоприколы

?

Костыли-костылики

И всё забезпладно, да

Есть чо купить? — я уже спрашивал ;)

Ca и oracle manager все еще всратые

#мониторинг #начало #термины #overall #concept #terms Часть I. Я обещал полить чутка воды философской про мониторинг. Начну. Как правильно говорят коллеги, давайте определимся с терминами, определениями и общим концептом. Глобально мониторинг состоит из трёх Основных частей. 1 - таблицы состояний и их генерация, 2 - сбор данных для генерации состояний, 3 - нотификация об состояниях и их изменениях, включая визуализацию. В это модель вписываются практически все основные системы последние 20 лет, включая новейшие. Начнем для примера с банальщины - древний nagios. Чекалки нагиоса - это пункт (2), они опрашивают хосты, сервисы, чтотамещё на простейшие состояния. Чекалки реализованы простыми скриптами, которые выдают статус и/или метрики, которые можно записывать (Perfdata в терминах nagios). (1) реализуется внутри нагиоса, они включают всякие "зависимости" (не опрашимваются сервисы, которые "за" точкой в состоянии "я утонула"), иерархические связки (для наглядности, не всегда совпадающие с "зависимостями") и работу с этими состояниями - Acknowledge, Shedule downtime, Disable/Enable checks/notifications. В этой же части реализуется история состояний и выработка стабильного итогового. Нотификации в нагиос (3) включают в себя настройку кому, когда и какие нотификации высылать. Напоминаю, это не описание нагиоса, а попытка показать, что я имел ввиду в модели. Самое главное, на что я хотел обратить внимание - метрики это данные для состояний. Одни из. Итак 1 - ХРАНЕНИЕ СОСТОЯНИЙ И ИХ ИЗМЕНЕНИЙ, ВЫРАБОТКА СТАТУСОВ ПО МЕТРИКАМ ИЛИ СОСТОЯНИЯМ ИЛИ ПО ЗВЕЗДАМ 2 - СБОР И ХРАНЕНИЕ МЕТРИК, СБОР СОСТОЯНИЙ 3 - НОТИФИКАЦИЯ О СОСТОЯНИЯХ, ИХ ИЗМЕНЕНИЯХ

кто какой сборщик метрик для графита использует?

ну или какой посоветуете?

ну и где хранить их для графаны?

кто какой сборщик метрик для графита использует?

Коллектд

Коллектд

nodejs, brrr

nodejs, brrr

вут?

а сорри, перепутал

Э ?

эм, тогда лучше не так, мне нужно сессионно снимать статистику с машин, и строить отчеты с графиками, этапы: 1. Стартуем сбор данных 2. Запускаем полезную нагрузку, ждем окончания работы 3. Останавливаем сбор данных 4. Генерим отчет и графики за сессию

вот такого вот странного хочется, есть идеи как правильно это можно сделать?

метрики: 1. LA 2. CPU 3. MEM 4. DiskIO 5. Network

это тесты гоняеете ?

#мониторинг #начало #термины #overall #concept #terms Часть II. А теперь немного истории. Что хорошо, что плохо и что лучше. Мой предок Бату-хан сжег Козельск, скоро будем праздновать годовщину этого генерального сражения, практически покончившего с сепаратистами... Ой. Не в то окно :) Я буду утрировать, потому что не утрируя тут труд будет на курсовую. Я просто прошу учесть, что конечно же я это осознаю и не надо бездумно меня цитировать в обобщениях. Давным давно, когда Путин только стал Президентом, приложения мониторили отдельно, а сервера отдельно. Собственно приложения мало кто прямо мониторил и там где-то родился заббикс. Бородатые седые пыльные одмины использовали mrtg, nagios и cacti. Проблема была и в том, что серверов не было пачками, и что ОС не очень-то делились метриками - я до сих пор помню, попытки впихивать всё в SNMP (правда вроде только бсдя реально сделала), и в том, что визуализировать это всё не очень удачно получалось по тем технологиям и мощностям. До сих пор есть какие-то виндовые визуализаторы всего. Когда Путин был уже давно Президентом и начали плодится сервера и виртуалки, появился graphite (это полноценный сборщик метрик, со своей базой и визуализатором) и вылез из разработчиков заббикс. Но со взятием метрик всё было по прежнему плохо. Родился даже collectd (это серверная программка, выдеркивающая данные из ОС и могущая их или послать куда-то, или например записать в RRD, у них даже алертинг какой-то есть). Он закрывает много дырок в этом вопросе. Есть ещё разные такие монолитные штуки, например Mmonit (кстати, рекомендую просто посмотреть). А потом ядро Linux вдруг сделало старт ракетой и начало фигачить всякие правильные изменения сотнями. Начали появляться метрики такие, метрики сякие, неймспейсы, чорты в ступе, таро и жрицы. И разрабы полезли в админы. Появился DevOps (в том или ином виду уже наверное лет 6-7). Появились странные для админов идеологии мониторинга только по метрикам. Но зато как грибы пошли расти сборщики этих метрик, базы для метрик, визуализаторы. Т.е. всё то, что раньше было скрипуче и трудновато. Отвечу тут на вопрос @poige по рынку. Всё так меняется, что ни один коммерс не возьмётся бежать за этим. Сложно. А при том, что качество коммерческих решений зачастую даже хуже коммьюнити - ква.

это тесты гоняеете ?

угу, в CI

на еще и на эластик инстансах

в плане просто подключить их на мониторинг не вариант, так как нужно это все собрать воедино :(

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

https://machinezone.github.io/mzbench/ вот такой фремворк где все сразу есть видел

эм, тогда лучше не так, мне нужно сессионно снимать статистику с машин, и строить отчеты с графиками, этапы: 1. Стартуем сбор данных 2. Запускаем полезную нагрузку, ждем окончания работы 3. Останавливаем сбор данных 4. Генерим отчет и графики за сессию

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

А почему просто не пихать в графит, а потом просто в конце приходить к нему в апи и говорить, дай пнг по такой то метрике за такой то период и все ?

как Я понимаю collectd сохраняет данные в rrd? можно просто натравить генератор статических страниц на него, если Я правильно понимаю?

А почему просто не пихать в графит, а потом просто в конце приходить к нему в апи и говорить, дай пнг по такой то метрике за такой то период и все ?

тоже вариант конечно

тоже вариант конечно

в графите агрегацию еще тогда стоит отключить

тоже вариант конечно

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

у меня уже есть мониторинг, а это нужно именно для CI и на динамически создаваемых машинах

которые подключать к мониторингу только мусор генерить

#мониторинг #начало #термины #overall #concept #terms Часть III. Теперь о "горячих точках". Сирия... ой :))) Источники данных. Выбор огромен, но зачастую они все не покрывают всего. collectd, munin, ganglia, экспортеры prometheus, telegraf, snmp-серверы наконец. Как пример непокрытия приведу - чем вы на SmartOS собираете метрики ZFS? А на Ubuntu? А на FreeBSD? Базы метрик. Собственно или "теряются" - influx, prometheus, или агреггируются в жестко позиционные файлы - wisper (это графита база), rrd (было бы не смешно, если бы у неё было развитие и аналог какого-нибудь Carbon графита). Или простите MySQL :))) Проблема огромного количества метрик и их записи на диск, а потом анализа. Дашборд. Это важно. Админы хотят automation для мониторинга production. А разработчики хотят как раз "дать Васе руками добавить" для тестов и стейджинга. Конфликт интересов. Собственно битва за заббикс и алертинг внутри графиков - это всё про дашборд, а не про мониторинг. Нотификации. Роутинг. Расписание. Отмена. Кому, сколько, когда, какие. Пока лучше nagios/icinga2/shinken это никто не делает. Состояния собственно хостов и зависимости. Вот тут провал. Или метрики, или состояния. В одном одмины стоят на своём, в другом разрабы. И это пока пропасть. И люди очень часто именно в этом месте путают - ведь анализ метрик в итоге тоже порождает состояние и/или статус. И это глубокое недопонимание сторон

Завтра спрошу можно ли

Можно?

Фуф

Фуф

Хорошо вышло, opentsdb забыл )

Полный бред

Как раз для коммерческого — лафа

Рынок

Игорь, поделитесь как и чем вы делаете мониторинг сейчас?

Хорошо вышло, opentsdb забыл )

Не забыл. Нельзя забыть о том, чего не знал ;)

Поэтому всякие там data dog'и и newrelic'и и вылезли

Как раз для коммерческого — лафа

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

Игорь, поделитесь как и чем вы делаете мониторинг сейчас?

Как все, всяким говном и палками

Но надоело.

Поэтому всякие там data dog'и и newrelic'и и вылезли

Это про девелоперов

Как все, всяким говном и палками

Кстати + ) Вместе с "надоело" :)

Вон там пацаны из окметра постоянно пиарятся

Отечественный софт, все дела

Так. Стоп. БЛЯТЬ!!! :)))) Я капсом в следующий раз буду писать. Мониторинг - это про состояния и статусы. И метрики только _ЧАСТЬ_ исходников для этого.

Это основополагающий принцип модели

эм, тогда лучше не так, мне нужно сессионно снимать статистику с машин, и строить отчеты с графиками, этапы: 1. Стартуем сбор данных 2. Запускаем полезную нагрузку, ждем окончания работы 3. Останавливаем сбор данных 4. Генерим отчет и графики за сессию

прометей + ноде_експортер 1. запустил node_exporter'ы 2. запустил прометей с пустым датадиром <тут пошла нагрузка> 3. остановил node_exporter'ы 4. profit

прометей + ноде_експортер 1. запустил node_exporter'ы 2. запустил прометей с пустым датадиром <тут пошла нагрузка> 3. остановил node_exporter'ы 4. profit

ок, а можно потом сгенерить статический html с графичками?

Ага, там дашгенератор есть

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

Но статику можно получить от графаны же

Там есть снапшоты

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

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

заббикс победит ведь? ?))

Нет. Просто обзор "что это". Тезисно возможности и их реализация. Тезисно плюсы и минусы. Всё

ну, тогда всё равно самому придётся смотреть все системы

Но статику можно получить от графаны же

это сколько тулов мне срастить надо?

Пром + нодеекспортер+ графана

о, нормально, жить можно

с таким вариантом, на каждом инстансе мне можно сделать 1. колектд 2. графит 3. графана перед стартом тестов просто запоминать timestamp лить данные с помощью колектд в графит и рисовать графики графаной после окончания нагрузки делать api запрос к графане и генерить снапшот дашборда, этот снапшот как репорт аттачить к результатам тестов

2 и 3 можно на 1м инстансе

при этом, 2 и 3 можно вынести на отдельный тазик

угу

или плюнуть и написать свой генератор отчетов по rrdb собранным collectd

что лениво, да

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

что лениво, да

да забейте вы.

я уже посмотрел апи нетдаты, она умеет графики экспортировать