побочные эффекты statsd, возможно, вызывают дополнительное время ожидания

Question

Я использую statsd клиента Datadog для записи продолжительности определенного ответа сервера.Когда я отвечал на эти ответы, я использовал довольно много пользовательских тегов.Так что я нахожусь в процессе уменьшения количества пользовательских тегов.

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

Согласно Datadog и Etsy (которые первоначально выпустили statsd ), эти методы, которые записывают эти метрики, не блокируются.Тем не менее, они должны использовать некоторые дополнительные потоки для выполнения этого.

В чем может быть проблема?Возможны ли побочные эффекты при использовании этого клиента?

Answer 1

Я нашел ответ на справочном форуме Datadog: "Как отображать процентили в Datadog" .

• Внесение изменений для увеличения сложности тега (добавление дополнительных тегов, чтобы быть более конкретным ) приведет к изменениям в поведении свернутой метрики визуализации
  • EX: тогда как до изменения METRIC_NAME.avg (без каких-либо тегов) будет агрегировать по всем необработаннымpoints (statsd берет все необработанные точки данных, агрегирует их, а затем отправляет по одному потоку метрик), добавляя тег tag like region (US, EU), заставляет statsd объединять необработанные точки данных в два региона, объединять их и отправлять через двапотоки.Это означает, что при отображении METRIC_NAME.avg AVG * означает совокупность по двум потокам, а не по одному

Таким образом, суть заключается в том, что сама латентность не "t, но агрегирование по нескольким потокам (где каждый поток соответствует каждому пользовательскому тегу) заставило график отображать другую форму.

Answer 2

Я не могу говорить конкретно о реализации Java, но в клиенте CSharp возможность отправлять эти данные в Datadog осуществляется на 127.0.0.1 через UDP-порт 8125. Он находится в том же потоке, что и исполняемый код, а неасинхронный.Все усилия вашего процесса завершаются после отправки UDP-сообщения - оно запускается и сразу же забывается.

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

У вас есть дополнительная информация, демонстрирующая это поведение?Исходя из того, что я знаю, это не похоже на побочный эффект материала Datadog / StatsD.