Пришлось мне поковыряться с Graphite. Задача была простая, был Graphite запущенный в единичном контейнере на отдельном хосте с открытыми портами, и нужно было это чудо утащить в DC/OS, сохранив все метрики. Вроде бы ничего сложного - настроить persistent volumes, поднять приложение, скопировать старые метрики, перенаправить приложения, whisper-fetch, и все!
Вдоволь намучившись, но таки победив, я нарвался на главный косяк - Graphite в связке со Statsd использует UDP порт для приема метрик. Наши приложения используют как раз его (чтобы краткосрочный отказ Графита не ломал нам все приложения). Но вот беда - на рынке (да и в Гугле) не существует балансировщика со встроенным service discovery, чтобы обрабатывать входящие UDP дейтаграммы и отправлять их в нужный task.
Ставить статичный порт напрямую на хост, говоря task’у запускаться только на этом агенте - харам (Чего я больше всего боюсь? Что сервер сдетонирует и будет потерян навсегда). Попросить разработку переписать отправку метрик на TCP тоже не вариант - TCP балансировщиков внезапно ТОЖЕ нет!
Единственный адекватный вариант - уехать с Графита подальше (в сторону того же DataDog), забыв этот overengineered ад как страшный сон и живя дальше. Дорого, долго, народ не согласится.
Что делает ваш покорный слуга? Делает очень мерзко и некрасиво, поднимая это чудо на отдельном EC2. Чувствую себя грязным после такого.
Идея для домашнего проекта - написать небольшой балансер на базе Nginx, который мониторит Marathon и делает reload веб сервера, если контейнер отвалился и поднялся с новым портом.
Post #323
885