[plaid]

господа коллеги, подскажите пожалуйста какие ОС и железо выбрать под zabbix+postgresql, опыта ни в какой ОС нет(кроме windows, конечно)

учусь с нуля

сеть небольшая, но в будущем возможно расширится(если это как то влияет на выбор)

Edited May 24, 2018 by plaid

[TheUser]

12 минут назад, plaid сказал:

господа коллеги, подскажите пожалуйста какие ОС и железо выбрать под zabbix+postgresql, опыта ни в какой ОС нет(кроме windows, конечно)

учусь с нуля

сеть небольшая, но в будущем возможно расширится(если это как то влияет на выбор)

 

ОС - Debian/Ubuntu последних версий

Железо - в зависимости от нагрузки. Сколько узлов будет мониторить ваш Zabbix?

[plaid]

49 минут назад, TheUser сказал:

ОС - Debian/Ubuntu последних версий

Железо - в зависимости от нагрузки. Сколько узлов будет мониторить ваш Zabbix?

10-15

[TheUser]

7 минут назад, plaid сказал:

10-15

Возьмите десктоп который не жалко.

[plaid]

1 минуту назад, TheUser сказал:

Возьмите десктоп который не жалко.

то есть допустим какой нибудь целерон с 2 гб оперативы и 500гб хватит?

[s.lobanov]

9 минут назад, plaid сказал:

то есть допустим какой нибудь целерон с 2 гб оперативы и 500гб хватит?

10-15 узлов по какому-нибудь стандратному шаблоны с дефолтным временем хранения - хватит

[plaid]

разве сервер комплектации офисного компьютера может выдержать такие нагрузки?

[s.lobanov]

да, может

[EShirokiy]

У меня одно время работал Celeron + 1 или 2 гига оперативы, сначала тестил, потом как то оно внезапно ушло в продакшен. Крутилось 350 хостов и около 1000 метрик. Оно конечно тупило, но работало. 

[Ilya Evseev]

Не совсем по теме, но на мой взгляд, важно:

Если не хотите через N лет получить помойку, в которой перемешаны настройки железа и кучи сервисов,

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

 

Если разбираться лень или некогда, можете начать с Proxmox, но в нём много лишнего: https://ru.wikipedia.org/wiki/Proxmox_Virtual_Environment

[alexmern]

Виртулка 10GB RAM, 4 ядра, 60GB HDD мониторит 600+ cвитчей (графики со всех портов) и не жужжит.

[megahertz0]

У нас вот такой конфиг работает года 3, мощи вполне хватает:

Скрытый текст

 

root@zabbix:/home/megahertz# ./inxi -F
System:    Host: zabbix Kernel: 3.2.0-4-amd64 x86_64 bits: 64 Console: tty 0
           Distro: Debian GNU/Linux 7 (wheezy)
Machine:   Type: Desktop System: Supermicro product: X9SCL/X9SCM v: 0123456789 serial: 0123456789
           Mobo: Supermicro model: X9SCL/X9SCM v: 1.11A serial: ZM13BS001768 BIOS: American Megatrends v: 2.0b
           date: 09/17/2012
CPU:       Topology: Quad Core model: Intel Xeon E3-1240 V2 bits: 64 type: MT MCP L2 cache: 8192 KiB
           Speed: 3401 MHz min/max: 1600/3401 MHz Core speeds (MHz): 1: 3401 2: 1600 3: 1600 4: 1600 5: 1600
           6: 1600 7: 1600 8: 1600
Graphics:  Card-1: Matrox Systems MGA G200eW WPCM450 driver: N/A
           Display: server: No display server data found. Headless server? tty: 172x59
           Message: Unable to show advanced data. Required tool glxinfo missing.
Audio:     Message: No PCI card data found.
           Sound Server: ALSA v: 1.0.24
Network:   Card-1: Intel 82579LM Gigabit Network Connection driver: e1000e
           IF: eth0 state: up speed: 100 Mbps duplex: full mac: 00:25:90:da:ea:79
           Card-2: Intel 82574L Gigabit Network Connection driver: e1000e
           IF: eth1 state: down mac: 00:25:90:da:ea:78
           IF-ID-1: eth0.12 state: up speed: 100 Mbps duplex: full mac: 00:25:90:da:ea:79
           IF-ID-2: eth0.169 state: up speed: 100 Mbps duplex: full mac: 00:25:90:da:ea:79
           IF-ID-3: eth0.50 state: up speed: 100 Mbps duplex: full mac: 00:25:90:da:ea:79
Drives:    HDD Total Size: 1.00 TiB used: 156.33 GiB (15.3%)
           ID-1: /dev/sda vendor: Western Digital model: WD5000HHTZ-04N21V0 size: 465.76 GiB
           ID-2: /dev/sdb vendor: Western Digital model: WD5000HHTZ-04N21V0 size: 465.76 GiB
           ID-3: /dev/sdc vendor: Intel model: SSDSC2BA100G3 size: 93.16 GiB
RAID:      Device-1: md0 type: mdraid status: active raid: mirror report: 2/2 UU Components:
           online: sda1~c0 sdb1~c1
Partition: ID-1: / size: 45.83 GiB used: 6.41 GiB (14.0%) fs: ext4 dev: /dev/dm-0
           ID-2: /boot size: 937.0 MiB used: 37.6 MiB (4.0%) fs: ext4 dev: /dev/dm-2
           ID-3: swap-1 size: 7.45 GiB used: 530.7 MiB (7.0%) fs: swap dev: /dev/dm-1
Sensors:   System Temperatures: cpu: 24.0 C mobo: 29.0 C
           Fan Speeds (RPM): cpu: 0 mobo: 5212 fan-1: 4856 fan-3: fan-4: 4945 fan-5: 5056
Info:      Processes: 262 Uptime: 952d 13h 06m Memory: 15.68 GiB used: 11.58 GiB (73.8%) Init: SysVinit
           runlevel: 2 Shell: bash inxi: 3.0.10

Мониторит 1100+ узлов (свитчи в основном и около 40 серверов):

 

В Zabbix нагрузка на сервер определяется по количеству NVPS (New Values per Second). Реально один сервер с конифгом как выше может прожевать 6-8к NVPS, а то и выше. Это весьма большой объем данных. В основном все упирается в БД. Поэтому общие рекомендации по поводу Zabbix сводятся к тому, что нужно иметь быструю БД, т.е. побольше памяти (в идеале чтобы БД помещалась целиком) и быстрые диски. Поэтому если вы планируете мониторить что-то более-менее серьезное, то сразу купите какой-нибудь БУ сервер типа Supermicro на Ксеоне E55xx/56xx и SSD под базу. Благо надежные SSD стоят сейчас недорого.

 

Но это, опять же, если у вас БД будет весить хотя бы 20 гб и Zabbix будет обрабатывать 0,5-1к NVPS. Если будете мониторить пару десятков узлов с хранением статистики в пределах полугода-года, то пойдет любая тачка с любым распространенным Линуксом (Debian/Ubuntu/CentsOS) свежей версии, процом типа Core-i3 и 4 Гб памяти. Желательно еще подтюнить БД под возможности железа.

 

Хорошее представление о масштабировании Zabbix дает вот эта статья, рекомендую с ней ознакомиться.

[st_re]

ну именно заливать в базу может ССД и не надо, оно както справляется при нашей базе (Required server performance, new values per second 2370.86) , а вот показать одновременно графики со всех портов коммутатора вообще не вариант оказалось без ССД. данные сильно размазаны по диску и даже аппаратный рейд с 15к дисками не в состоянии так быстро надергать головами туда-сюда.. объем памяти конечно хорошо, но если вы пару дней не интересовались полугодовым трафиком по этому коммутатору, то в памяти ничего интересного не будет.  ССД 1 штука с тем же справляется.

 

Ну и да, базу надо шардировать, и данные грохать удалением шардов а не удалением записей..

[megahertz0]

34 минуты назад, st_re сказал:

ну именно заливать в базу может ССД и не надо, оно както справляется при нашей базе (Required server performance, new values per second 2370.86) , а вот показать одновременно графики со всех портов коммутатора вообще не вариант оказалось без ССД. данные сильно размазаны по диску и даже аппаратный рейд с 15к дисками не в состоянии так быстро надергать головами туда-сюда.. объем памяти конечно хорошо, но если вы пару дней не интересовались полугодовым трафиком по этому коммутатору, то в памяти ничего интересного не будет.  ССД 1 штука с тем же справляется.

Чем покупать 15к диски, железный рейд и все такое проще купить пару SSD и жить спокойно. По деньгам даже дешевле выйдет при IOPS большем в десятки раз.

[Ilya Evseev]

43 минуты назад, st_re сказал:

Ну и да, базу надо шардировать, и данные грохать удалением шардов а не удалением записей..

Шардировать или партицировать?

Если второе, то немного напрягает, что вместо функциональности из коробки Заббикс предлагает городить полусамодельные костыли: https://www.zabbix.org/wiki/Docs/howto/mysql_partition

Хотя альтернативы при большом числе метрик всё равно нет.

[st_re]

4 минуты назад, Ilya Evseev сказал:

Шардировать или партицировать?

 

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

 

 

[megahertz0]

MySQL 5.7 насколько мне известно научился бить таблицы на партишены своими силами.

[st_re]

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