В чем разница между StatsD и Riemann? и какой из них лучше работает в крупномасштабных распределенных системах? у нас есть распределенная платформа, построенная на Java, и мы хотим отслеживать показатели приложения и, возможно, некоторые предупреждения. Мы понимаем, что инструменты не бесплатны, поэтому в идеале мы ищем хорошо масштабируемую среду мониторинга приложений, которая может добавить наименьшую стоимость инструментов к нашей платформе/приложениям и иметь возможность выполнять все виды агрегирования и так далее. Я также понимаю, что мы можем построить что-то, что будет комбинацией обоих, но я не могу придумать, почему? поскольку оба, похоже, выполняют агрегацию и т. д., но я не могу определить, какой из них лучше подходит или почему один работает лучше, чем другой. Будет большим подспорьем, если кто-то поделится своим опытом использования этих инструментов в отрасли.
В чем разница между StatsD и Riemann? и какой из них лучше работает в большой распределенной системе?
Ответы (2)
У меня нет точных данных о statsd, но сообщение Brubeck на Github предполагает, что они теряли около 40% своих событий statsd при — я предполагаю, что эти графики в секундах — 25 000 событий в секунду. Их замена для statsd в C выдает 4,3 миллиона событий в секунду. http://githubengineering.com/brubeck/
Riemann не будет конкурировать с этим на основе пакетов, но в пакетах, скажем, 10-100 метрик/сообщение, я слышал, что несколько производственных пользователей сообщают о 10 миллионах событий/сек. В отличие от statsd, Riemann масштабируется на все доступные ядра — в тестах я загрузил оба сетевых интерфейса и все 48 ядер на своей машине — но фактическая производительность будет зависеть от конкуренции и того, что вы делаете со своими потоками. Может быть намного медленнее. Все зависит.
По сравнению со statsd, Riemann имеет гораздо более богатую модель событий и выполняет произвольные вычисления. Небольшая конфигурация Riemann может воспроизвести функциональность statsd, но Riemann действительно сияет, когда вам нужны многомерные свертки, обнаружение перехода состояния, интеграция со всеми видами других служб хранения и оповещения, подавление флуктуаций, управление потоком и т. д. и т. д. и т. д.
Цена этого — работа на языке программирования — Clojure — который может быть незнаком вашей команде, и необходимость более тщательно продумывать область действия, состояние и, если вы пишете свои собственные потоки, параллелизм. Riemann также не так широко распространен, что может быть недостатком с точки зрения поддержки библиотеки и найма персонала.
Лучше всего работает Brubeck, который совместим со Statsd (написан на C), поэтому вы можете использовать те же клиентские библиотеки Statsd для подключения к нему.
Brubeck написан на C, Statsd написан на Node.js. И, как объяснил Github в своей статье, они считают Node.js чужой технологией и постепенно заменили любой Node. js, которые у них были. Один из них был statsd из-за проблем с производительностью.
Вторым по производительности будет Riemann (однако для него нужны собственные клиентские библиотеки). Statsd будет самым медленным.
