AS
даёшь statsd семантику в vm(на самом деле нет)
Size: a a a
2019 December 17
A
Ну мне понравилась концепция ханикомб где все это евенты и как отобразишь то и будет - логи, метрики, трейсы. Не прочь такое в опенсорс увидеть, но подозреваю мне скажут "возьми кликхаус и собери себе сам" :)
GG
Ну мне понравилась концепция ханикомб где все это евенты и как отобразишь то и будет - логи, метрики, трейсы. Не прочь такое в опенсорс увидеть, но подозреваю мне скажут "возьми кликхаус и собери себе сам" :)
Мне кажется, что это слишком дорого, как любое универсальное решение
BG
это и есть капец дорого (
AV
container_network_transmit_bytes_total - container_network_transmit_bytes_total offset 24hлучше использовать
increase(container_network_transmit_bytes_total[24h]), т.к. offset не учитывает сбросы счетчика в 0 aka counter resets, которые могут возникнуть при перезагрузке сервиса или компа, эспортирующего эту метрикуGG
лучше использовать
increase(container_network_transmit_bytes_total[24h]), т.к. offset не учитывает сбросы счетчика в 0 aka counter resets, которые могут возникнуть при перезагрузке сервиса или компа, эспортирующего эту метрикуспасибо
2019 December 18
AV
@valyala а вот такой вопрос
есть событие вида "http{...tags} <latency>", скорость генерации примерно 100 в секунду с распределением таймстампа в пределах последних 5 минут (то есть балком заливаю 60k метрик)
стандартная практика - аггрегировать в "http_bucket{...tags, le=[10...]} <count>" теряя в разрешении
предположим я хочу получить максимальное разрешение и возможность гибких выборок потому что пока не знаю какая именно инфа оттуда потребуется
это нормальная практика слать в vm сразу события или оно на такое не расчитано и вообще "плохая практика"? как примерно будет расти потребление памяти и цпу на больших датасетах при условии что диски не проблема? надо ли что-то будет подоптимизировать?
есть событие вида "http{...tags} <latency>", скорость генерации примерно 100 в секунду с распределением таймстампа в пределах последних 5 минут (то есть балком заливаю 60k метрик)
стандартная практика - аггрегировать в "http_bucket{...tags, le=[10...]} <count>" теряя в разрешении
предположим я хочу получить максимальное разрешение и возможность гибких выборок потому что пока не знаю какая именно инфа оттуда потребуется
это нормальная практика слать в vm сразу события или оно на такое не расчитано и вообще "плохая практика"? как примерно будет расти потребление памяти и цпу на больших датасетах при условии что диски не проблема? надо ли что-то будет подоптимизировать?
Можно попробовать, но это не совсем нормальная практика для tsdb, в т.ч. и для вм. Лучше складывать показания в гистограммы вроде вот этих - https://medium.com/@valyala/improving-histogram-usability-for-prometheus-and-grafana-bc7e5df0e350 , после чего пушить эти гистограммы в вм с фиксированной частотой вроде 1 раз в 10 секунд. Такие гистограммы позволяют потом смотреть распределение latency на произвольном диапазоне времени с шагом меньше 50% . Например, если latency в пределах от 1 до 10 секунд, то на выходе получим 18 бакетов для следующих диапазонов latency:
(1..1.5], (1.5..2], ... (9.5..10]. Это покрывает большинство потребностей при мониторинге.A
спасибо
YZ
Кто нибудь сталкивался с ошибкой в postgres_exporter? файл на месте есть, овнер совпадает с юзером от которого запускается эскпортер, права 644.
Пробовал как относительный так и абсолютный путь. Рофл еще в том, что если попробовать поднять —log.level - экспортер не стартует.
Но если запускать ручками - стартует корректно.
Экспортер запускатеся как systemd-unit
Пробовал как относительный так и абсолютный путь. Рофл еще в том, что если попробовать поднять —log.level - экспортер не стартует.
Но если запускать ручками - стартует корректно.
Экспортер запускатеся как systemd-unit
level=error msg="Failed to reload user queries: ... no such file or directory" source="postgres_exporter.go:1426"
YZ
[Unit]
Description=PostgreSQL Exporter
After=network.target
[Service]
User=prometheus
Group=prometheus
WorkingDirectory=/opt/prometheus
Environment=DATA_SOURCE_NAME=postgresql://monitoring:...@127.0.0.1:5432/monitoring?sslmode=disable
ExecStart=/opt/prometheus/bin/postgres_exporter \
--auto-discover-databases \
--exclude-databases="template0,template1" \
--extend.query-path="/opt/prometheus/conf/postgres_exporter/queries.yaml"
LimitNOFILE=65535
[Install]
WantedBy=multi-user.target
T
Кто нибудь сталкивался с ошибкой в postgres_exporter? файл на месте есть, овнер совпадает с юзером от которого запускается эскпортер, права 644.
Пробовал как относительный так и абсолютный путь. Рофл еще в том, что если попробовать поднять —log.level - экспортер не стартует.
Но если запускать ручками - стартует корректно.
Экспортер запускатеся как systemd-unit
Пробовал как относительный так и абсолютный путь. Рофл еще в том, что если попробовать поднять —log.level - экспортер не стартует.
Но если запускать ручками - стартует корректно.
Экспортер запускатеся как systemd-unit
level=error msg="Failed to reload user queries: ... no such file or directory" source="postgres_exporter.go:1426"
systemctl status -lGG
Кто нибудь сталкивался с ошибкой в postgres_exporter? файл на месте есть, овнер совпадает с юзером от которого запускается эскпортер, права 644.
Пробовал как относительный так и абсолютный путь. Рофл еще в том, что если попробовать поднять —log.level - экспортер не стартует.
Но если запускать ручками - стартует корректно.
Экспортер запускатеся как systemd-unit
Пробовал как относительный так и абсолютный путь. Рофл еще в том, что если попробовать поднять —log.level - экспортер не стартует.
Но если запускать ручками - стартует корректно.
Экспортер запускатеся как systemd-unit
level=error msg="Failed to reload user queries: ... no such file or directory" source="postgres_exporter.go:1426"
что значит, что руками стартует?
GG
от какого пользователя? окружение какое? может тебе нужно ЕЩЕ какую-то переменную накинуть
GG
ну, не бывает чудес...
YZ
что значит, что руками стартует?
если стартануть вот так - все стартует
$ DATA_SOURCE_NAME=postgresql://monitoring:...@127.0.0.1:5432/monitoring?sslmode=disable /opt/prometheus/bin/postgres_exporter --auto-discover-databases --exclude-databases="template0,template1" --log.level="debug" --extend.query-path="conf/postgres_exporter/queries.yaml"
GG
может переменная криво разворачивается?
GG
там же собачка
YZ
DATA_SOURCE_NAME работает корректно.
экспортер не видит --extend.query-path
и валится с ошибкой без каких-либо подробностей, если в systemd-unit засунуть —log.level="debug"
экспортер не видит --extend.query-path
и валится с ошибкой без каких-либо подробностей, если в systemd-unit засунуть —log.level="debug"
GG
укажи там абсолютный путь
GG
и еще