Я хотел бы настроить statsd / graphite, чтобы я мог регистрировать приложения JS, работающие на устройствах HTML (т. Е. Не в изолированной среде LAN, и, возможно, с большим объемом входящих данных, которые я не контролирую напрямую).
Мои ограничения:
- точка входа должна говорить HTTP: это решается с помощью простого прокси HTTP-to-UDP-statsd (например, httpstatsd на github)
- должен противостоять отказу единственного сервера (чтобы сражаться с законом Мерфи :)
- должен быть горизонтально масштабируемым: веб-масштаб, детка! :)
- архитектура должна быть максимально простой (и дешевой)
- мои серверы виртуальные машины
- файлы данных будут храниться на устройстве файловой системы (с NFS)
- У меня есть аппаратные балансировщики нагрузки tcp / udp
Короче говоря, путь к данным: [клиент] - (http) -> [http2statsd] - (udp) -> [statsd] - (tcp) -> [графит] - (nfs) -> [filer]
Мои выводы пока:
- легко масштабировать часть http2statsd (демоны без сохранения состояния)
- масштабирование части statsd не кажется простым (я полагаю, что в конечном итоге я получу некогерентные значения в графите для агрегированных данных, таких как sum, avg, min, max ...). Если только HTTP-демон не выполняет последовательное хеширование, чтобы осколить ключи. Может быть, идея ... (но тогда есть вопрос HA)
- масштабирование графитовой части может быть сделано с помощью шардинга (с использованием углеродного реле) (но это также не решает вопрос HA). Очевидно, что несколько экземпляров шепота не должны записывать один и тот же файл NFS.
- масштабирование части файла не является частью вопроса (но чем меньше IO, тем лучше :)
- масштабирование веб-приложения кажется очевидным (хотя я не проверял), поскольку они читают только общие данные NFS
Поэтому мне было интересно, есть ли у кого-нибудь опыт и лучшие практики, которыми можно поделиться для надежного развертывания statsd / graphite?
http
high-availability
scalability
graphite
statsd
David142
источник
источник
Ответы:
Есть прокси-сервер statsd с согласованным хэшированием, который позволяет распределять трафик statsd между несколькими агрегаторами statsd, каждый из которых использует свой собственный набор имен метрик. Это важнейший элемент масштабируемости в вашей архитектуре, позволяющий масштабировать процессы statsd.
Графит также сложен, но, надеюсь, вам не понадобится бесконечный масштаб, и он может сделать просто точный шардинг с помощью сервиса или другого статического параметра.
Самым сложным является масштабирование веб-приложения, и оно во многом зависит от того, какие запросы у вас самые тяжелые. Однако вы всегда можете предварительно агрегировать данные для самых сложных графиков и избавиться от большей части нагрузки.
Я использовал HostedGraphite в течение достаточно долгого времени, чтобы избежать всей этой боли, эти парни реализовали свой собственный Riak-бэкэнд для Carbon и сделали там все масштабирование.
источник