Информация

Дата основания
Местоположение
Россия
Сайт
miran.ru
Численность
51–100 человек
Дата регистрации

Блог на Хабре

Обновить

Мониторинг вашей инфраструктуры с помощью Grafana, InfluxDB и CollectD

Блог компании Дата-центр «Миран»Системное программированиеСетевые технологииСерверное администрирование
Рейтинг +7
Количество просмотров 7,6k Добавить в закладки 66 Читать комментарии 8
Комментарии 8
Чем обусловлен выбор collectd вместо «родного» для influxdb телеграфа?
Почему выбрали Influxdb? Рассматривали ли альтернативы, тот же Prometheus / VictoriaMetrics?
influxdb и prometheus всё таки разные, используют разные методы отправки метрик (push vs pull)
прометей умеет и то и то.
хмм, это с каких пор завезли? Я помню решалось в виде прослойки телеграфа или чего то подобного, которое держит метрики и отдаёт прометею при запросе.
Вопрос схожий выше, почему в конце цепочки не kafka + grafana?

Не знаю почему автор выбрал, но я снёс телеграф потому что он жрёт намного больше чем ресурсов чем collectd. Впрочем, по сравнению с netdata collectd тоже тот ещё монстр, особенно если сэмплинг идёт каждую секунду.

Давайте представим, что у нас есть несколько расположенных на разных материках устройств. Каким образом мы будем обрабатывать переменную «time»? Станем ли мы привязывать все данные ко времени по Гринвичу, или мы зададим каждому узлу свой часовой пояс? Если данные сохраняются в разных часовых поясах, каким образом нам корректно отобразить их на графиках? Как можно видеть, проблемы возникают одна за другой.

Простите, вы это серьезно? Это было проблемой лет 20 назад, да и то не везде.

Впрочем, вспоминая, сколько мне приходилось почти на каждом проекте воевать с бэкенд-разработчиками, норовившими отдавать время в REST API не в UTC, а локальное, я уже ничему не удивляюсь.

P.S. Хотя нет, вот сейчас бросил взгляд на календарь — и снова удивился, 2021 г. же на дворе.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.