WA
Парни, юзает кто process_exporter?
Size: a a a
2020 August 25
ST
вопрос то где
WA
без докера
WA
как конфиг файл передали
ST
всмысле как, через systemd флагом config.path
ST
ну и дальше регуляркой процессы парсишь по имени
AS
как конфиг файл передали
а в чём сложность ?
WA
да уже понял
WA
чет не проснулся)
WA
спасиб
G
grafana/grafana tagged: v7.1.5
Link: https://github.com/grafana/grafana/releases/tag/v7.1.5
Release notes:
Link: https://github.com/grafana/grafana/releases/tag/v7.1.5
Release notes:
release v7.1.5
I
она нужна для горизонтального масштабирования сркейпинга большого количества таргетов. С помощью нее таргеты можно равномерно разделить на любое количество прометеусов, при этом используя одинаковый конфиг для скрейпинга и меняя в нем только один параметр - значение
regex в action: keep после action: hashmod. См. https://www.robustperception.io/scaling-and-federating-prometheusПравильно понимаю, что если испольвать hashmod для двух прометеев без настройки федерации, то к графане нужно будет подключать два data source? Извиняюсь, что дёрнул старое сообщение.
G
grafana/grafana description changed: v7.1.5
Link: https://github.com/grafana/grafana/releases/tag/v7.1.5
Release notes:
Link: https://github.com/grafana/grafana/releases/tag/v7.1.5
Release notes:
[Download Page](https://grafana.com/grafana/download/7.1.5)More
[What's New Highlights](https://grafana.com/docs/grafana/latest/guides/whats-new-in-v7-1/)
[Release Notes](https://community.grafana.com/t/release-notes-v7-1-x/32967)
### Features / E...
AA
Добрый день!
есть пару сайтов, находящихся где-то на Украине у одного хостера. Наш робот периодами к ним
ходит и собирают с них какую-то инфу. Периодически робот сталкивается с сетевыми ошибками.
Владельцы этих сайтов заинтересованы, чтобы наш робот к ним ходил и не было таких проблем.
Был некоторый пинг-понг между нами и техподдержкой того хостера о том, на чьей же стороне проблема.
В общем мне передали задачу. Было бы довольно просто, если бы проблема воспроизводилась постоянно, но
она очень плавающая (mtr вроде б могла немного прояснить ситуацию).
Т.к. у нас графитовый стек для приема метрик, я настроил плагин ping у collectd. Получаю метрики по
времени отклика и drop rate пингов.
Робот находится в ДЦ одного хостера N. У данного хостера 2 независимых канала, робот ходит через первый.
Получение метрик настроил по следующему принципу: пару серверов (на одном из них работает робот), выходящих в сеть через 1-ый канал ДЦ
хостера N, один сервер - через 2-ой, еще один сервер - находится в хетцнере.
После некоторого наблюдения видно, что drop rate с наших серверов, находящихся в ДЦ хостера N, периодами достигает 20%.
А у сервера, находящегося в hz, потерь практически нет (ну или иногда бывает в пару %).
Хотя наш хостер N и заявляет, что у него 2 совсем независимых канала, но пока метрикам подтверждается, что
проблема есть.
Но теперь встает вопрос - как более полно понять где именно проблема?
Видится, что надо нечто mtr-а, которая будет запускаться периодами и показывать потери/время отклика по каждому
из хопов ведущему к проблемному сайту. Как вообще такие метрики получить?
Понятно, что mtr не является сильно точной методикой проверки, но есть метод лучше?
есть пару сайтов, находящихся где-то на Украине у одного хостера. Наш робот периодами к ним
ходит и собирают с них какую-то инфу. Периодически робот сталкивается с сетевыми ошибками.
Владельцы этих сайтов заинтересованы, чтобы наш робот к ним ходил и не было таких проблем.
Был некоторый пинг-понг между нами и техподдержкой того хостера о том, на чьей же стороне проблема.
В общем мне передали задачу. Было бы довольно просто, если бы проблема воспроизводилась постоянно, но
она очень плавающая (mtr вроде б могла немного прояснить ситуацию).
Т.к. у нас графитовый стек для приема метрик, я настроил плагин ping у collectd. Получаю метрики по
времени отклика и drop rate пингов.
Робот находится в ДЦ одного хостера N. У данного хостера 2 независимых канала, робот ходит через первый.
Получение метрик настроил по следующему принципу: пару серверов (на одном из них работает робот), выходящих в сеть через 1-ый канал ДЦ
хостера N, один сервер - через 2-ой, еще один сервер - находится в хетцнере.
После некоторого наблюдения видно, что drop rate с наших серверов, находящихся в ДЦ хостера N, периодами достигает 20%.
А у сервера, находящегося в hz, потерь практически нет (ну или иногда бывает в пару %).
Хотя наш хостер N и заявляет, что у него 2 совсем независимых канала, но пока метрикам подтверждается, что
проблема есть.
Но теперь встает вопрос - как более полно понять где именно проблема?
Видится, что надо нечто mtr-а, которая будет запускаться периодами и показывать потери/время отклика по каждому
из хопов ведущему к проблемному сайту. Как вообще такие метрики получить?
Понятно, что mtr не является сильно точной методикой проверки, но есть метод лучше?
AS
лучше есть всякие sla пробники. некоторые из них inline и позволяют дополнять полосу до какогото значнения.
AS
однако я бы таки просто мониторил ошибки сбора и в момент когда они растут запускал бы трейсы
AA
запускал бы трейсы - traceroute? кто будет караулить, чтобы их запустить? )
AS
с практической точки зрения у вас всё равно решение будет примерно в том что надо сдать проблему хостеру или провайдеру
AA
лучше есть всякие sla пробники. некоторые из них inline и позволяют дополнять полосу до какогото значнения.
можно чуть развернуть, я не очень понял. Про некие sla пробники понял, а далее - не очень
AS
в графитовском стеке вроде только одна алертилка. мойра же ?