
Алексей
31.08.2017
15:17:16
пром он про то что на каждый инстанс запускается отдельный опрос.
по идеологии так
тоесть надо 1-2к процессов.

Paul
31.08.2017
15:17:30

Google

Алексей
31.08.2017
15:18:12
200мсек железяки видимо за пределами своей сети. так что snmpv3 и вот это вот всё да ?

yuyu
31.08.2017
15:22:27
ибо такое натянуть на пром будет очень не очень
Потому и спросил, прежде чем лоб расшибать ?
Реально вопрос другой: разыскивается производительный параллельный (ака многопоточный, асинхронный) snmp поллер с вменяемой конфигурацией и без миллиона зависимостей для скармливания собранного в timeseries DB (например, в КХ или инфлакс).

Paul
31.08.2017
15:22:43
тоесть надо 1-2к процессов.
ну можно, наверное, и иначе сделать. Но тут сам экспортер переписывать надо. А когда я его в прошлый раз смотрел, он был написан на коленке левой рукой

Алексей
31.08.2017
15:23:02
правда у нас чуть чуть меньше миллиона зависимостей
но итог кх и графана

yuyu
31.08.2017
15:24:03

Алексей
31.08.2017
15:42:31
у нас это в нокпроджект да. на счет не быстрый хз.
если период опроса 5 минут то собирать надо
2000 железяк*1000interface /300 сек = 6к метрик в секунду. прямо скажем не дофига вобще

Uncel
31.08.2017
15:47:25
Был такой хтонический костыль
https://github.com/mteg/braa/blob/master/README
( когда надо поллить сотни тысяч cpe )

Google

Dmitry
31.08.2017
15:50:16
snmp у NOC’а достаточно быстрый
по крайней мере - собрать сотню тысяч метрик в секунду особого труда не представляет

Edouard
31.08.2017
15:55:24

yuyu
31.08.2017
16:53:22

Andor
31.08.2017
16:59:49
У вас там 200мс в локальной сети?

yuyu
31.08.2017
17:10:42

Andor
31.08.2017
17:14:25
А можно ли снмп экспортер поставить поближе к железкам?
Чтобы между ними был поменьше лаг

yuyu
31.08.2017
17:14:45
https://github.com/mteg/braa/blob/master/README
Судя по README - стрёмная самоделка. Они сами там пишут что заточено на скорость, а compliance - не их забота.
https://github.com/tobez/snmp-query-engine/blob/master/manual.mdwn - по концепту вот это интересно выглядит, и вроде бы в TELIA это работало. Но проект уже года 3-4 как не подаёт признаков жизни.

Uncel
31.08.2017
17:16:08

Andor
31.08.2017
17:16:22
Если хочешь более-менее быстро собирать метрики - нвдо
Или очень много мест?

yuyu
31.08.2017
17:29:36
Или очень много мест?
Да дело не в местах - 10 или 100 - разница уже небольшая. Просто лишний админский гемор. Известно же, что вполне реально с обычного ноута >100K oids/minute опросить - так зачем огород городить.
Изначальный вопрос был о поиске поллера, которому удобно задавать список хостов, того, с них надо получить, а потом полученное clickhouse/graphite/influxdb/prometheous. В идеале бы ещё и теги/метаданные по дороге навесить, чтобы кроме ifIndex был ifDescr+ifAlias, например. А если ещё и counter в rate мог пересчитывать - вообще бы цены не было.
Может где и есть awesome-snmp-poller list. Я не нашёл.

Andor
31.08.2017
17:44:00
Как оно может собирать метрики быстрее ртт?
Я не гуру снмп, может что-то не понимаю

Anatoliy
31.08.2017
17:47:33
параллельно?

Dmitry
31.08.2017
17:48:24
естественно, какая-та часть либо валяется, либо не отвечает

Google

Dmitry
31.08.2017
17:49:25
железо - обычные x86-64

yuyu
31.08.2017
17:56:46
железо - обычные x86-64
По масштабам прокатывает, засада, что, насколько я понимаю, из NOC поллер в отдельный пакет без остального комбайна с 100500 зависимостей легко не выделить. Он же за собой и базу захочет потянуть и ещё кучу всего. А хочется просто более-менее standalone поллер, которому скормил конфиг и забыл. Ну и время от времени конфиг перечитывать.

Nik
31.08.2017
19:53:48
А есть здесь люди, которые пилили экспортеры для прометеуса?

Andor
31.08.2017
20:17:11
Есть

Nik
31.08.2017
20:29:00
Есть
А можешь немного пояснить по типам данных, я тут смотрю уже часов 6 и не понимаю

Andor
31.08.2017
20:31:16
Вопрос в чём?

Nik
31.08.2017
20:32:35
Ща открою ноут сформулирую, минуту
Смотрю на https://prometheus.io/docs/concepts/metric_types/
(что хочу мониторить - количество евентов в минуту)
И смотрю в экзамплы стандартной го либы
Думаю что мне нужны наверно гистограммы

Nik
31.08.2017
20:38:58
(потому что остальное как то не ложатся, или я их плохо понял)
Но у гисттгграмм какие то бакеты несчастные, и он суммирует результаты.
Отдаю я количество евентов в минуту, которые были каждого типа
Каким типом данных в go-либе правильнее пользоваться
Очень смутила странная хрень вида NewHistogramVec которая отличается чем от обычной гистограммы, но я пока не понял чем.
Победил таки, используя NewGaugeVec.
Вопрос - можно ли в либе "github.com/prometheus/client_golang/prometheus"
отключить стандартные метрики вида go_*

Mihail
31.08.2017
21:57:20
А чем count не подходит?

Google

Mihail
31.08.2017
21:57:31
Бери от него rate
Ну или gauge, хотя тут count больше подходит, потому что он может только расти

Admin
ERROR: S client not available

Nik
31.08.2017
21:59:48
а у меня может и расти и падать
Приложуха отдает количество операций за минуту

Алексей
31.08.2017
22:00:35
плохо что она такое отдает.

Nik
31.08.2017
22:00:42
ну тут софт не мой
так что ничего не поделать
моде дело было подключиться к ней и воровать существующие метрики, что бы после передать их в мониторинг

Oleg
01.09.2017
02:58:56
/stat@combot

Combot
01.09.2017
02:58:56
combot.org/chat/-1001068522817

Andor
01.09.2017
06:25:09
А что за софтина?

Nik
01.09.2017
07:10:44
А что за софтина?
Написанная левыми чуваками Платформа, реализующая определенную бизнес логику. Мне ее Админить и могиторить. По сути - управляющая шина на сях + компоненты на яве, реализующие конечные Функции

vladimir
01.09.2017
08:05:21
Все привет, никто не встречался с тем, что в графане, в тектовых графах, переводы строк не работают?
хм проблема в firefox. в chrome все ок

Vsevolod
01.09.2017
10:30:07
народ, решал кто задачу мониторинга времени ответа радиус-серверов путем анализа зеркалированного трафика?

Sergey
01.09.2017
10:46:20
Это который morror в nginx?

Алексей
01.09.2017
10:46:48
нет это который с порт коммутатора

yuyu
01.09.2017
11:54:27
народ, решал кто задачу мониторинга времени ответа радиус-серверов путем анализа зеркалированного трафика?
А поконкретнее: на что смотреть хотите, насколько поток большой?
Если в лоб, то сниффер типа tcpdump, результат на самописный скрипт и потом в базу.
Ещё в голову, например, такой toolchain пришёл:
mirror трафик принимать на pmacct, в конфиге которого отфильтровывать нужные flows c помощью pcap_filter, агрегировать их по интересующим полям и складировать в базу.
Но я pmacct в L2 режиме не юзал и в детали не вникал, может и не подойдёт...
И чем просто анализ логов самого радиуса не прокатывает?

Google

Vsevolod
01.09.2017
11:58:46
И чем просто анализ логов самого радиуса не прокатывает?
логи радиуса включить - доп нагрузка на сервер с радиусом
логи радиуса анализировать локально - доп нагрузка на сервер с радиусом
итого - пока решил отбирать радиус-трафик чем-либо на базе либпкап, результат направить в промежуточный код, который ведет учет сессий, далее держать в памяти счетчики, и эти счетчики уже получать заббикс-агентом

Vladimir
01.09.2017
11:59:21
логи радиуса увозить с радиуса и анализировать где-нибудь далеко-далеко
не факт что включенные логи будут тяжелее чем pcap :)

Vsevolod
01.09.2017
12:00:20
дело в том, что анализировать-то потоки трафика я буду ОТЗЕРКАЛЕННЫЕ коммутатором на отдельный порт, воткнутый в отдельный сервер, без влияния на сам сервис радиуса

yuyu
01.09.2017
12:00:26

Uncel
01.09.2017
12:02:40
Странное решение конечно, вариант с логами самый простой

Vsevolod
01.09.2017
12:02:42
мне так удобнее - у меня уже есть сервер, куда зеркалируется ВЕСЬ трафик узла связи. я на нем веду запись разговоров, сигнального обмена, радиус-обмена и тп

Vladimir
01.09.2017
12:03:04

Vsevolod
01.09.2017
12:03:20
коммутатор у нас прожует и не поперхнется, там все норм

Vladimir
01.09.2017
12:03:22
ну и как по мне анализ трафика сложнее анализа логов

yuyu
01.09.2017
12:03:28