The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Выпуск системы мониторинга Zabbix 5.2, opennews (??), 27-Окт-20, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


31. "Выпуск системы мониторинга Zabbix 5.2"  +1 +/
Сообщение от Онаним (?), 27-Окт-20, 21:02 
Лучший мониторинг для здоровенных сетей и сервисов, где менеджер-ориентированные сервисы встают сначала колом, потом раком, и превращаются в unmanageable. И никаких альтернатив ему нет, там, где Zabbix вывезет без проблем в рамках 1-2-3 серверов, коммерческие монстрики потребуют целой стойки.
Ответить | Правка | Наверх | Cообщить модератору

36. "Выпуск системы мониторинга Zabbix 5.2"  +1 +/
Сообщение от Тимофей (??), 27-Окт-20, 21:15 
Да он для сетей вообще не предназначен. Построить зависимость хост от хоста не возможно на нем. Это гребанная поделка.
Ответить | Правка | Наверх | Cообщить модератору

37. "Выпуск системы мониторинга Zabbix 5.2"  +1 +/
Сообщение от Онаним (?), 27-Окт-20, 21:20 
В таких сетях, о которых я, зависимость хоста от хоста имеет немножко другой уровень. En masse.
Там не СЕРВИС, а целая фигова туча сервисов, которую ты задолбаешься в других системах описывать.
И есть уровни этого сервиса - пользователи там, пользователи сям, бэкбон там-сям, кора там-сям.
Хелпдеску надо несколько тысяч SLA хостов видеть.
Зависимости все строятся прекрасно снаружи, если правильно расставлять теги.
Триггеры выгребаются через API.
Кастомные проверки и интеграции подвязываются.
Шаблоны на каждый тип хоста, которых сотни. Которые могут прийти из CRM, а могут просто прийти, потому что вон тот партнёр, с которым вообще нет интеграции, подключил очередного пользователя.
etc.
Ответить | Правка | Наверх | Cообщить модератору

50. "Выпуск системы мониторинга Zabbix 5.2"  +/
Сообщение от Аноним (17), 28-Окт-20, 02:29 
> Зависимости все строятся прекрасно снаружи, если правильно расставлять теги.

Это не ты тот тип которому было мало 9999 зависимостей у триггера?

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

Ответить | Правка | Наверх | Cообщить модератору

55. "Выпуск системы мониторинга Zabbix 5.2"  +/
Сообщение от Онаним (?), 28-Окт-20, 09:07 
> Это не ты тот тип которому было мало 9999 зависимостей у триггера?

Угу, он самый :D

У нас голосовой софтсвитч с кучей клиентских транков. Выгрести нагрузку по транкам можно только полностью по всем, из специфичной консольной утилиты свитча, а дальше её надо препроцессить и делить на инфу по транкам. Транков давно больше 10000. Раньше делил скриптом, и запихивал через sender, когда появились dependent items - правильнее делить препроцессингом, соответственно пошли в эту сторону.

> Я так понял у вас мониторинг настраивается через апи, данные выгребаются тоже
> через апи, а заббикс выступает только ui интерфейсом для Хелпдеска и
> складированием метрик. Учитывая что в двух последних функциях он проигрывает графане
> и прометеусу, то не понятно зачем вам вообще заббикс.

Manager-oriented мониторинги не осилят 400000 метрик без отдельной стойки, это мы уже поняли, когда.
Графану с инфлюксом когда попробовали - инфлюкс просто лёг на агрегации. Ладно, фиг с ним, прекратили поток - мб потом оптимизируем. Попробовали отрисовать скрин для хелпдеска с парой сотен графиков. Тут уже легла графана, потому что кеширования у неё никакого, попутно проложив инфлюкс.

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

Ответить | Правка | Наверх | Cообщить модератору

57. "Выпуск системы мониторинга Zabbix 5.2"  +/
Сообщение от Онаним (?), 28-Окт-20, 09:32 
Как пример триггера для HD: есть клиент, у которого наземная линия и бэкап через 4G.
IP у наземки и мобилки одинаковый, простым пингом не отделаешься.
Есть две RADIUS-сессии на двух разных железках.
Надо выгрести состояние этих двух RADIUS-сессий и сопоставить с пингом для клиента.
В итоге выдать хелпдеску не только жив ли клиент, но и не сидит ли он на бэкапе.
Или клиент мёртв, а сессии живы, тоже не нормально.
Сложности особой нет, но вот таких вот вывертов очень много требуется.
Ответить | Правка | Наверх | Cообщить модератору

58. "Выпуск системы мониторинга Zabbix 5.2"  +/
Сообщение от Онаним (?), 28-Окт-20, 09:34 
По RADIUS сессиям своя отдельная тема, выгребать их надо оптом, а не per check, потому что чеков много :D
Ответить | Правка | Наверх | Cообщить модератору

122. "Выпуск системы мониторинга Zabbix 5.2"  +/
Сообщение от Аноним (17), 31-Окт-20, 01:59 
> Нам больше интересны сложные триггеры от этих метрик, которые техподдержка способна оценить в реальном времени. Бывает что падает целый район города из-за пропадания питания в таковом. Бывает что падают BGP-сессии. Очень много чего бывает, монолитного определения целостности сервиса нет.

И как выкручиваетесь? Крутится скрипт и разруливает зависимости между всеми триггерами?

Ответить | Правка | К родителю #55 | Наверх | Cообщить модератору

124. "Выпуск системы мониторинга Zabbix 5.2"  +/
Сообщение от Онаним (?), 31-Окт-20, 08:38 
> И как выкручиваетесь? Крутится скрипт и разруливает зависимости между всеми триггерами?

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


Ответить | Правка | Наверх | Cообщить модератору

56. "Выпуск системы мониторинга Zabbix 5.2"  +1 +/
Сообщение от Онаним (?), 28-Окт-20, 09:19 
Web морда кстати не для хелпдеска в основном, а для доступа к конфигурации.
Очень много (почти всё, связанное с клиентами) сделано через API, но инфраструктурные хосты в CRM добавляются в т.ч. вручную, шаблоны шаблонятся. Морда для хелпдеска и не только хелпдеска у нас своя специфичная: https://pasteboard.co/JxH9rNc.png
Ответить | Правка | К родителю #50 | Наверх | Cообщить модератору

81. "Выпуск системы мониторинга Zabbix 5.2"  +/
Сообщение от Алексей (??), 28-Окт-20, 13:06 
Интересно! В 5.2 можно получить очень похожий интерфейс: сохраняем фильтры для быстрого переключения и с помощью ролей оставляем доступ лишь к странице Monitoring->Problems.
Ответить | Правка | Наверх | Cообщить модератору

52. "Выпуск системы мониторинга Zabbix 5.2"  +/
Сообщение от Аноним (17), 28-Окт-20, 02:37 
Сколько у вас хостов и nvps?
Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

53. "Выпуск системы мониторинга Zabbix 5.2"  +/
Сообщение от Онаним (?), 28-Окт-20, 08:58 
> Сколько у вас хостов и nvps?

Number of hosts 15715
Number of templates 126    
Number of items    638258
Number of triggers 439417
Number of users 36
Required server performance, new values per second 1914.19    

Ответить | Правка | Наверх | Cообщить модератору

71. "Выпуск системы мониторинга Zabbix 5.2"  +/
Сообщение от пох. (?), 28-Окт-20, 10:13 
> Required server performance, new values per second 1914.19

и кто это у вас обеспечивает, можно подробностей? А то я все жду, когда мой mysql лопнет.

Ответить | Правка | Наверх | Cообщить модератору

75. "Выпуск системы мониторинга Zabbix 5.2"  +2 +/
Сообщение от Онаним (?), 28-Окт-20, 10:30 
Немножко можно. Если что конкретно интересно - спрашивайте.

--- xl info (XenServer)

release                : 4.19.0+1
machine                : x86_64
nr_cpus                : 12
threads_per_core       : 1
cpu_mhz                : 2095.137
total_memory           : 47810
free_memory            : 10811
xen_caps               : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64
xen_scheduler          : credit
xen_commandline        : watchdog ucode=scan crashkernel=256M,below=4G console=vga vga=mode-0x0311 dom0_max_vcpus=1-4 dom0_mem=3072M,max:3072M xpti=0 spec-ctrl=no pv-l1tf=0 smt=0 mds=0 md-clear=0

--- Zabbix+MariaDB VM cpuinfo

Старичок из старой партии. В перспективе AMD EPYC Zen2/Zen3.

vendor_id       : GenuineIntel
cpu family      : 6
model           : 85
model name      : Intel(R) Xeon(R) Silver 4116 CPU @ 2.10GHz
stepping        : 4
cpu MHz         : 2095.070
cache size      : 16896 KB
siblings        : 12
cpu cores       : 12

--- Zabbix+MariaDB VM memory

MemTotal:       32843324 kB
MemFree:          921164 kB
MemAvailable:   13662648 kB
Buffers:          236856 kB
Cached:         13794504 kB
SwapCached:        53508 kB
Active:         24584872 kB
Inactive:        5396760 kB

--- Zabbix VM s/w versions

Linux ... 5.4.17-2011.6.2.el8uek.x86_64 #2 SMP Thu Sep 3 13:38:27 PDT 2020 x86_64 x86_64 x86_64 GNU/Linux

mysql  Ver 15.1 Distrib 10.5.5-MariaDB, for Linux (x86_64) using readline 5.1

Таблички history%/trends% пока лежат в TokuDB, но поскольку TokuDB всё (и это блин полный Ц и беда), смотрим в стороны, пока ничего особо не глянулось, начали собирать TokuDB для 10.5 сами. MariaDB 10.4 в котором TokuDB ещё есть из коробки - работает не хуже.

zabbix_server (Zabbix) 5.0.4
Revision 69c0ad3686 28 September 2020, compilation time: Sep 28 2020 15:30:12

--- Хранилка - локальные SSD, RAID 6 на 4 устройства. Samsung MZ7KM960HMJP0D3 (PM863)

Пробовали на iSCSI SAN (Dell/Compellent SCv, SSD-only), latency приличная, но хуже не становится. Оставили локальное потому что мониторинг не должен зависеть от состояния сетевого SAN.

<VD>
Virtual Drive: 1 (Target Id: 1)
RAID Level          : Primary-6, Secondary-0, RAID Level Qualifier-3
Size                : 1.745 TB
Sector Size         : 512
Parity Size         : 1.745 TB
Strip Size          : 1.0 MB
Number Of Drives    : 4
Span Depth          : 1
Current Cache Policy: WriteBack, ReadAhead, Direct, No Write Cache if Bad BBU

<SSD>

Raw Size: 894.252 GB [0x6fc81ab0 Sectors]
Sector Size:  512
Firmware state: Online, Spun Up
Device Firmware Level: GD57
Inquiry Data:       S3BVNX0JA16095MZ7KM960HMJP0D3                             GD57

Ответить | Правка | Наверх | Cообщить модератору

90. "Выпуск системы мониторинга Zabbix 5.2"  +/
Сообщение от пох. (?), 28-Окт-20, 15:09 
Ясно, спасибо, нам есть еще куда расти экстенсивно.

Ответить | Правка | Наверх | Cообщить модератору

123. "Выпуск системы мониторинга Zabbix 5.2"  +/
Сообщение от Аноним (17), 31-Окт-20, 02:04 
Это же не очень много, у нас 3к nvps, иногда упираемся в постгрю, потюним базу - работаем дальше, но думаем уйти от заббикса.
Ответить | Правка | К родителю #71 | Наверх | Cообщить модератору

125. "Выпуск системы мониторинга Zabbix 5.2"  +/
Сообщение от пох. (?), 31-Окт-20, 11:01 
мне с одной стороны столько не надо, а с другой - бюджет ограничен, nvme диски под базу мне не дадут. Поэтому важно представлять, сколько мы еще можем переварить до того как все развалится под собственным весом. Я пару раз наблюдал, было не очень смешно.

Ответить | Правка | Наверх | Cообщить модератору

136. "Выпуск системы мониторинга Zabbix 5.2"  +/
Сообщение от Онаним (?), 01-Ноя-20, 09:54 
Ну у нас допустим nvps вообще роли не играет, конкретный сервер спокойно вытянет еще раз 5 по столько же.
У нас основная нагрузка на БД, как ни странно - обработка сложных триггеров, которым нужна хистори за прошлые сутки, например. Эти прорежаем. Где тротлингом, где интервалом.
Ответить | Правка | К родителю #123 | Наверх | Cообщить модератору

54. "Выпуск системы мониторинга Zabbix 5.2"  +/
Сообщение от Онаним (?), 28-Окт-20, 09:00 
Это один сервер.
У него на периметре три небольших прокси, одна из-за изоляции сети, две - для балансировки нагрузки от пинг и snmp-чекеров на ядро, их по 64 процесса на каждой проксе.
Впрочем, количество хостов писать - дело неблагодарное, уже сегодня их станет ещё на десятку больше.
Ответить | Правка | К родителю #52 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру