масштабирование statsd с несколькими серверами

Я сейчас занимаюсь той же проблемой. Выполнение простой балансировки нагрузки между несколькими statsds, очевидно, не работает, потому что ключи с одинаковыми именами окажутся в разных statsds и, таким образом, будут неправильно агрегированы.

Но есть несколько вариантов использования statsd в среде, которую необходимо масштабировать:

• используйте выборку на стороне клиента для метрик счетчика, как описано в документации statsd (т. е. вместо отправки каждого события в statsd, отправьте только каждое 10-е событие и заставьте statsd умножить его на 10). Недостатком является то, что вам нужно вручную установить соответствующую частоту дискретизации для каждой из ваших метрик. Если вы выберете слишком мало значений, ваши результаты будут неточными. Если вы сэмплируете слишком много, вы убьете свой (единственный) экземпляр statsd.

• создайте собственный балансировщик нагрузки, который разбивает данные по имени метрики на разные statsds, тем самым избегая проблемы неработающей агрегации. Каждый из них мог писать напрямую в Graphite.

• создайте клиент statsd, который подсчитывает события локально и отправляет их в statsd только в совокупности. Это значительно снижает трафик, поступающий в statsd, а также делает его постоянным (до тех пор, пока вы не добавите больше серверов). Пока период, с которым вы отправляете данные в statsd, намного меньше, чем собственный период сброса statsd, вы также должны получать такие же точные результаты.

• Вариант последнего пункта, который я с большим успехом реализовал в рабочей среде: используйте первый слой из нескольких (в моем случае локальных) statsd, которые, в свою очередь, объединяются в один центральный statsd, который затем общается с графит. Первый слой statsds должен иметь гораздо меньшее время сброса, чем второй. Для этого вам понадобится серверная часть statsd-to-statsd. Поскольку я столкнулся именно с этой проблемой, я написал одну, которая пытается максимально эффективно использовать сеть: https://github.com/juliusv/ne-statsd-backend

Как бы то ни было, statsd, к сожалению, не предназначен для управляемого масштабирования (нет, я не считаю настройку частоты дискретизации вручную «управляемой»). Но обходные пути, описанные выше, должны помочь, если вы застряли с этим.

Большинство реализаций, которые я видел, используют метрики для каждого сервера, например: <env>.applications.<app>.<server>.<metric>

При таком подходе вы можете иметь локальные экземпляры statsd на каждой машине, локально работать с UDP и позволить statsd публиковать свои агрегаты в графите.

Если вам действительно не нужны метрики для каждого сервера, у вас есть два варианта:

1. Объедините связанные показатели на уровне визуализации (например: , настроив графити на сделай так)
2. Используйте агрегацию углерода, чтобы позаботиться об этом.

Если у вас есть доступ к аппаратному балансировщику нагрузки, такому как F5 BigIP (я полагаю, существуют программные реализации OSS, которые делают это), и у вас есть имя хоста каждого хоста в ваших метриках (т. foo.bar.baz" и агрегируя их на уровне Graphite), вы можете использовать балансировку нагрузки с привязкой к исходному адресу - она ​​отправляет весь трафик с одного исходного адреса на один и тот же узел назначения (в пределах разумного тайм-аута). Таким образом, пока имя каждой метрики исходит только от одного исходного хоста, это приведет к желаемому результату.