@metrics_ru

Страница 248 из 681
Алексей
31.08.2017
15:17:16
пром он про то что на каждый инстанс запускается отдельный опрос.

по идеологии так

тоесть надо 1-2к процессов.

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к процессов.
ну можно, наверное, и иначе сделать. Но тут сам экспортер переписывать надо. А когда я его в прошлый раз смотрел, он был написан на коленке левой рукой

yuyu
31.08.2017
15:24:03
200мсек железяки видимо за пределами своей сети. так что snmpv3 и вот это вот всё да ?
Не, 200мс на свой сети, секьюрити не на первом месте, v2 сойдёт.

правда у нас чуть чуть меньше миллиона зависимостей
Если "у нас" - это в @nocproject, то это многовато - целый комбайн ради поллера. Ну и питон сам по себе не быстрый...

Алексей
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’а достаточно быстрый

по крайней мере - собрать сотню тысяч метрик в секунду особого труда не представляет

yuyu
31.08.2017
16:53:22
по крайней мере - собрать сотню тысяч метрик в секунду особого труда не представляет
На каком железе? 100К/сек - это не показательно. 100К с одной железки, которая рядом и быстро отвечает и 100К = 10К х 1000 железок далеко (а то ещё и отвечающих не всегда) - совсем другое же.

https://github.com/mteg/braa/blob/master/README
Спс, это я видел. А в продакшене кто-то это пробовал?

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

yuyu
31.08.2017
17:10:42
У вас там 200мс в локальной сети?
Разумеется не локалка ?

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 как не подаёт признаков жизни.

Чтобы между ними был поменьше лаг
И получить ещё одну распределённую систему там, где вроде без неё можно обойтись. Оно надо?

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
дело в том, что анализировать-то потоки трафика я буду ОТЗЕРКАЛЕННЫЕ коммутатором на отдельный порт, воткнутый в отдельный сервер, без влияния на сам сервис радиуса

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

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

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

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

yuyu
01.09.2017
12:03:28
логи радиуса включить - доп нагрузка на сервер с радиусом логи радиуса анализировать локально - доп нагрузка на сервер с радиусом итого - пока решил отбирать радиус-трафик чем-либо на базе либпкап, результат направить в промежуточный код, который ведет учет сессий, далее держать в памяти счетчики, и эти счетчики уже получать заббикс-агентом
Ну тогда pmacctd - самое то. Он пакеты заснифферит, выдернет нужные поля, может по выбранным ключам агрегировать в памяти и потом выгружать (в файлы, базу, кафку и т.п.) или держать в своих imt таблицах в памяти, а их уже можно опрашивать со стороны когда надо.

Страница 248 из 681