zabbix má Discovery které automaticky vytváří nové zařízení, ale nevím jak to funguje na SNMP. má to i hromadné změny, skupiny.

Na sběr bych se toho nebál. můžeš si pustit SNMP workerů kolik chceš. limit bude ram, cpu nebo network.

SAMGARR: ok diky za tip, chapu ze je rozmerem celkem atypicky usecase

RATTKIN: no jde o to, ze spolehat se na dokumentaci je v takovem to pripade malo.. tohle chce referencni reseni

pracuju s icingou ci nagiosem a mam reseni kde dohleduju radove nekolik desitek tisic citacu, vcetne distribuovanyho monitoringu pomoci satelitů, ale to je porad nekde uplne jinde...

CHOROBA: hw zdroje resp. naklady na ne zas nejsou tak limitujici...

limitujici vidim /jak je tu uvadeno/:
- sber a ta parelizace snmp
- db backend, nad kterym idealni potrebuju delat dotazy a nejakou archivni agregaci dat
(samozrejmne pokud by bylo resenim mit treba 10x virtual ktery, kazdy obhospadri 5k device á 200 citacu a pak to sestohuju v centralni db a tam s tim pracuju, tak to vyhovuje)

ale reseni kde to budu mit sber v 10 nodech lokalne v RRD je nadraka. A troufam si rict to by mi to mozna nakonec i utahlo tech 10 satelitů icingy/nagiosu. chce to i nejakej inteligentni provisining novych zarizeni a vyrazeni scriptem atd. Nejakej reporting nad tim atd...

taky u opensource je důležité hledisko jaký je použitá technologie, případně jestli je to technologie, kterou se chceš učit

TBC: U zabbixu jde prakticky o skalovani databaze pro zapis. A pokud se ti nechce zacit primym testovanim zkus IRC zabbixu, vzdycky tam je nejaky vyvojar ochotny vyvojar.
Prometheus jsem doporucoval protoze je dimenzovany 100k zapisu/s a vic.

TBC: a podle čeho jiného? u open source projektu je dobrá dokumentace velká výhoda.

zatím se nikdo z nyxáků neozval, kdo by měl milion snmp zařízení.
tak ještě zkusit nějaké zahraniční fóra (stackexchange) a pak placený konzultant, ale ten ti opensource nedoporučí ;-)

zalezi i co mas na to za masinu/masiny/rozpocet. od toho bych se odpichnul
obecne mi prijde, ze vic drbani bude s cacti, musi se vic nastavovat a ladit, ale zase rozhodne zere min zdroju nez zabbix , tedy jeden server ti utahne vic polleru a zpracuje vic citacu/grafu.

ja honil na 2Xeon s 8G ram asi 5000+ devices s par 10k grafu.
nska mam na distribuovanym reseni 23000+ zarizeni a grafu asi tak 100k

RATTKIN: škoda, no rozhodovat se na muj usecase podle dokumentace, to by bylo trochu nezodpovedne :)

TBC: mám agenty, SNMP i VMware přes ipmi. všechno funguje. když těch zařízení budou miliony, tak by to chtělo nějaký sizing guide.
já nemám škálu co tu hledáš, ale můj zabbix má 1 cpu a 20 giga disk :)

tady je trochu popsaný snmp https://www.zabbix.com/documentation/3.0/manual/config/items/itemtypes/snmp

tohle je o škálování:
Scalable Zabbix – Lessons on hitting 9400 NVPS | Zabbix Weblog
http://blog.zabbix.com/scalable-zabbix-lessons-on-hitting-9400-nvps/2615/

já jiný monitoring neznám, ale rozhodoval bych se podle toho kdo má lepší dokumentaci na tvůj usecase

RATTKIN: no jde o to ze potrebuji sbirat na desitkach tisich zarizeni SNMP citace (hw boxy), takze potrebuju volat paralene... jinak bych se nedozil nez to vyparsuje... ty to nekde takto nasazeny mas, nebo pouzivat agenty na os?

TBC: zabbix má trendy, kdy zahodí staré data z databáze hodnot a uchová pouze trendy v samostané databázi pro historii.
plno hodnot zabbix sbírá po 30 sekund nebo po minutě. není to problém.

paraleliazce to je jako co? můžeš mít proxy servery kde se to sbírá a počítají se preprocesy, může být jeden na každé site a pak to jde do centrální databáze.
frontend může taky být samostatný server.

TBC: ale zajima mne i prakticka zkusenost, neco jsou neurcite proklamovany moznosti a neco jinyho je konkretni zkusenost s vlastnim provozem

RATTKIN: no predstavuji si idealne po 5ti minutach treba 1 mesic, po 3 mesicich uchovavat jen prumer za hodinu a po roce treba prumer za den, ostatni viz zadani...

gro pro zabbix bude asi schopnsot parelniho pollingu .. to umi CACTI jak psal DANYSEK

TBC: u zabbixu je hlavní metrika výkonu kolik je hodnot za vteřinu.
miliony čítačů, to je asi zajímavé pro velikost databáze na disku, ale taky záleží na délce retence.

KUTNY: Odpoved je:
All templates/Cisco_Catalyst_Discovery - Discovery list/Network Interfaces - zalozka filters - pridat filtr {#IFDESCR} matches Ethernet

spine rozhodne. ale v ty novy verzi 1.x uz to umi vic s pollerama paralelne a taky rrd proxy

CHOROBA: jen to chce tahat spis spis uz cacti-spine poller.

todle umi cacti