Я пытаюсь использовать аналитические данные о приложении, чтобы отслеживать счетчик количества активных потоков в моем приложении. У меня есть 2 цели:
- Показывать текущее (или, по крайней мере, недавнее) количество активных потоков на панели инструментов
- Активируйте своего рода предупреждение, если количество превышает определенный лимит.
Эти потоки могут быть довольно долгоживущими, а иногда и кратковременными. Таким образом, число может иногда меняться, скажем, 100 раз в секунду, а иногда оставаться неизменным в течение многих часов.
Я пытался отследить этот счет активных потоков как метрику аналитики приложения. Я увеличиваю счетчик в своем приложении при открытии нового потока и уменьшаю его при закрытии. При каждом изменении я использую клиент телеметрии примерно так
var myMetric = myTelemetryClient.GetMetric("Metricname");
myMetric.TrackValue(myCount);
Когда я запрашиваю значения своих показателей с помощью Kusto, я вижу, что из-за этих кластеров активности в течение 10-секундного периода значения моих показателей агрегируются. Что касается моей тревоги, я могу смириться с этим, поскольку могу смотреть на максимальное значение агрегата. Но я не могу представить панель мониторинга количества активных потоков, так как у меня нет возможности узнать количество активных потоков между моими точками измерения. Я знаю минимальное значение, максимальное и среднее значение, но я не знаю последнего значения совокупного периода, и, поскольку оно может быть где-то между 0 и 1000, это не поможет.
Итак, решение, которое у меня есть, не соответствует моим потребностям, я подумал о нескольких изменениях:
- Добавление запланированной помпы к моему компоненту счетчика, который будет отправлять текущее значение счетчика каждые 5 минут. Но мне не нравится, что мне нужно добавить поток для каждого из этих счетчиков.
- Добавление таймера для отправки текущего значения один раз, через 5 минут после последнего изменения. Обратный отсчет сбрасывается при каждом изменении счетчика. Это имеет ту же проблему, что и выше, и требует чрезмерного объема работы по сбросу счетчика, когда он может изменяться тысячи раз в секунду.
В конце концов, я не думаю, что мои потребности настолько экзотичны, поэтому мне интересно, неправильно ли я использую аналитику приложений.
Есть ли способ изменить поведение метрики в соответствии с моими целями? Я ценю то, что перед отправкой данных выполняется предварительная агрегация, чтобы снизить затраты на загрузку, но это мешает мне решить простую проблему. Подходит ли для этого метрика? Есть ли альтернативные подходы к аналитике приложений?
