LINUX.ORG.RU

Использую на работке telegraf(мониторинг) + influxdb(где хранить, можно какой-нибудь прометеус вместо него использовать) + grafana(графики в вебе, можно хронограф, более навороченый, у нас его фаервол не пускает) + kapacitor(когда нужны алерты, в целом графана их тоже умеет, только более ограничено).

Для дома netdata зашла, там сразу все, удобно года надо одну машину мониторить

Dred ★★★★★ ()

На работе как основной мониторинг статусов используется https://saymon.info/

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

l0stparadise ★★★★★ ()

netdata influxdb grafana, ну и shinken. алерты навешаны на нетдату и на графану

Novell-ch ★★★★★ ()

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

Для мониторинга на работе zabbix, дома munin.

shell-script ★★★★★ ()
Ответ на: комментарий от shell-script

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

cnupm ()

А чем заббикс плох?

Pyzia ★★★★ ()

icinga - стильненько и стабильненько.

dada ★★★★★ ()
Ответ на: комментарий от Dred

Возможно прикрутить grafon'у к уже существующему nagios'у+PNP4Nagios без пересборки всей системы мониторинга?

anonymous ()
Ответ на: комментарий от Dred

Та ну, для графиков хронограф дно полное. Как морда к капаситору - отлично. А так для графиков ничего лучше графаны нет сейчас.

PunkoIvan ★★★ ()
Ответ на: комментарий от Pyzia

Тем, что это днище абсолютное. Настройка через вебуй, серьёзно?

Лучше уж старый добрый Nagios + Thruk в качестве вебморды. Live Status позволяет делать всякие очень интересные вещи.

Не знаю, кому нужен zabbix, когда всё остальное лучше него.

PunkoIvan ★★★ ()

Модно - прометей. Надёжно - zabbix.

Hanuken ()

Для метрик Prometheus + Alertmanager + Grafana

Для логов ELK Elastic Stack, наверное.

deadNightTiger ★★★★ ()
Последнее исправление: deadNightTiger (всего исправлений: 1)
Ответ на: комментарий от PunkoIvan

И что это за остальное и чем же оно лучше?

Deleted ()
Ответ на: комментарий от Deleted

Nagios - хранить конфиги банально лучше текстом, практичнее. Можно полностью управлять через консоль.

TICK - графики, нотификации, куча всего из коробки.

Sensu, Icinga - всё вот это вот лучше заббикса :)

Не нравится в заббиксе - настройка через гуй, база данных, xml.

Нравится - автодискавери.

PunkoIvan ★★★ ()
Ответ на: комментарий от shell-script

дома munin.

Что можно дома мониторить? Что вы дома мониторите?

anonymous ()
Ответ на: комментарий от anonymous

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

shell-script ★★★★★ ()
Ответ на: комментарий от PunkoIvan

старый добрый Nagios

Который не умеет в горизонтальное расширение и всего при нескольких сотнях хостов превращается в тыкву.

shell-script ★★★★★ ()

Более пяти лет назад пробовал Nagios, познал дзен ,пока все настроил как надо. В настоящий момент развернул Zabbix, настроил правила автодискавери для сетевого оборудования + через GPO раскидал на сервера подготовленый агент. Как итог За два дня работы (с подготовкой сервера и конфигурацией агента) Zabbix мониторит более 150 сетевых устройств + около 50 серверов. Все уже со своими шаблонами, комплексными экранами и настроенными аляртами. Единственое думаю еще прикрутить парсер, для полного феншуя. Из недостатков по сравнению с обзервиумом, не строит сам карту на основе LLDP. Хотя может быть скриптами можно и допилить.

Не возьмусь говорить это модно или нет, но по мне так функционально и лично мне удобно.

IMP ()

Да добавлю что база крутиться отдельно на Оракле. Поэтому по производительности проблем нет.

IMP ()
Ответ на: комментарий от shell-script

Поллеры (пассивные чеки), NSCA, NRPE - 15к хостов, 200к+ чеков.

Серьёзно, история успеха. Реальный продакшн в кровавом энтерпрайзе.

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

Поллеров - 31 штука.

Нотификации по смс и пейджердьюти.

PunkoIvan ★★★ ()
Ответ на: комментарий от IMP

Как только пойдете в микросервисы типа Mezos, Kubernetis. Как только пойдут облака типа AWS с эласитити (т.е. счас 10 instances, тут бах и уже 20, и раз - уже 5), Вот тогда вы проклянете свой Zabbix. Что там из плюсов? Автодискавери? Распределенная инфраструктура, 100 серверов в Usa, 200 в UK, и все в разных VPC, да еще с перекрытиями по IP адресам. Как будите дискаверить? А если это вообще сервис типа SQS? А сервисы в k8s? Все изменения делать руками или через restAPI? А как же парадигма инфраструктура как код? Пример - выкатываем новый релиз, у нас добавляется Apache (ну вот все работало в nginx) и в новом релизе нам нужно добавить и его мониторинг. Могу я залить в git конфиги и данные, что с выкатом пакета релиза начать мониторить новые сервисы сразу же, причем конфиги взять вот эти? А если откат сделать? Чё, лезть уже удалять зареганные сервисы? Т.е. инфраструктура как код - не работает. Графики убогие. Нельзя их использовать для инвестигаций как в grafana или kibana.

Итого из недостатков Zabbix 1. Работа через базу. Забываем про гибкость, никакой инфраструктуры как код. 2. Плохая работа с динамическими энвайроментами. Да что там плохая - все через пачку скриптов, и жутко не надежно. 3. Ненужный ныне автодискавери. Если только у вас не завод, где просто нужно 100 серваков смотреть. 4. Не информативные графики, не позволяющие делать анализ ситуаций типа вот тут цпу вырос, ага а тут по сетке проблемы в этот же момент. Только не говорите, что можно grafana прикрутить. Нафига крутить если можно сразу туда гнать всё. 5. Разработка рф. Уже идет в минус. Продайте в европу или сша проект с заббиксом. Могут быть проблемы. Да, бесплатный, да нормальный, но кто-его знает, вдруг там кгб дописало чего... может и смешно, но случаи уже слышал.

icinga2 без агентов, сбор сразу в grafana через нативный плагин. или prometheus. плюс ELK.

derangeer ()
Ответ на: комментарий от derangeer

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

1. База данных быть должна, ибо хистори вы где будете хранит? Анализ статистики никто не отменял.

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

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

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

5. Вот тут вообще странно слышать такое. Ибо если готовится проект, то изачально составляется ТЗ под которое заббикс либо подходит либо изначально предпологается что-то другое. Поэтому размышления изначально не верны. Только если вы продаете не проект а ПО или проект без согласованного ТЗ, то это уже отдельная песня и не нужно тут сваливать все на вендора =)

А что касаемо графаны так она и в Заббиксе есть. Только вот честно я не увидел в ней практического смысла. Ибо красота графиков мне не нужна, информативность графиков добивается не хуже чем в графене с помощью комплексных экранов в шаблонах. Которые использую только при анализе тикетов. А постоянно смотреть на них у меня нет ни времени ни желания, в лучшем случаи отображение интерактивной карты с тригерами по обьектами или линкам между ними. Для всего остального есть оповещение (смс,жабер,мейл).

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

IMP ()
Ответ на: комментарий от IMP

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

1. База данных быть должна, ибо хистори вы где будете хранит? Анализ статистики никто не отменял. ---- что конкретно вы там храните? Лог того, что cpu был 100%? и что вам это даёт? ну знаете вы что цпу был таким вчера, а сейчас он нормально 1% жрет? алерт вам пришел, а анализ всего проще делать в grafana. Сбор же логов типа nginx - проще в ELK. Только не говорите, что вы в забикс их шлете. Т.е. я не понимаю вообще, что можно логировать в МОНИТОРИНГЕ. Мониторинг это - алерт система, которая должна лишь знать, что происходит. Т.е. это посути лампочка, с веревочкой. Давление выросло - лампочка загорелась, веревочка дернулась - телеграмма ушла. Что логировать? Письма пришло, остальное в систему логирования.

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

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

4. Комплексные экраны - ну если они могут как Grafana динамически настраиваться, растягиваться, и прочее. А, нет, не могут. да и не могут они храниться как код (конфиг файл) https://www.youtube.com/watch?v=BC_YRNpqj5k

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

В итогде вся инфраструктура граммотно настраивается один раз и потом только отслеживается наличие бэкапов, что справедливо для любой системы. у меня нет инфраструктуры ))) вы никогда не слышали про динамические среды? у меня сегодня 2 сервера в проде может быть, а завтра 2000. какой один раз? У меня до десяти DEV environments, причем завтра они могут быть пересозданы за полчаса, я же написал выше - у меня не завод с 100 серверами.

derangeer ()
Ответ на: комментарий от IMP

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

derangeer ()
Ответ на: комментарий от derangeer

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

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.