Ну в писанине каждый делает, что хочет... только вот потом приходят не совсем понимающие, видят "правильно" и начинают думать, что это действительно правильно. Называйте вещи своими именами - просто удобно.
Еще не забываем, что ArrayList оперирует типом object, отсюда объект сразу создается не на стеке, а в куче, потому что используется упаковка (для объекто ладно, но для типов значений - камон Карл), отсюда еще куча всего вытекает... Ну блин, там что нет своих массивов? Ну это точно не правильный способ для VBA
я как-то экспериментировал с логстэшем пару лет назад - дул в него где-то 70k записей в секунду, умирал быстро и надолго. То же количество раскидывал раундробином в мастера и все было норм. И я склоняюсь к следующему: все что по середине между поставщиками логов и мастерами эластика - узкое место. Препарсинг должен быть сделан в виде агента, типа как у егеря, где это возможно, ну а там где нет, то подойдет ваша схема
Проблема не в том, какие метрики нужны и не в том, что закинуть в query. Необходимо инстанс сопоставить с тем именем, который понятный людям, но это не PID, не имя процесса, не бинарь - это имя сайта или пула, имя службы, консоли и того сложнее, ибо бинарь зачастую не коррелирует с названием приложения.
Все сводится к одной хотелке - соответствие инстанса и процесса должно быть атомарной операцией. Я бы тоже по возможности избегал сбор performance по процессу через категорию process. И, конечно, самый простой способ переложить это на плечи программиста, ибо ему доступно все это из домена приложения, но все-равно в таком подходе все сводится к дорогому "NtQuerySystemInformation", будь то точка входа .net.process или более низко уровневое api. Можно пойти по пути ETW,начать отлавливать переключения контекста между потоками и калькулировать performance, но это значительно увеличит кодовую базу.
Я выбрал реактивный подход, когда ETW не генерит события какой-то определенное время после последнего события, то запускается процесс пересборки коллекторов, это минимизировало количество ошибок, но иногда можно наблюдать скачи того же CPU в 100000%
Ох… шлак. В системе хватает всякого API, начиная от реестра до агрегированной обертки PDH, а если этого мало, то ETW в помощь. Все это необходимо сводить к максимальной автоматизации — проще написать под себя, что-то стороннее подходит только для ручного просмотра
Да эта тема «что выбрать» уже замусолена до дыр: писать для себя — выбирай любое; писать для конторы — легаси никто переделывать не будет, а новое — где взять время на изучение.
Ну и остается заказчик, где и возможен вариант наткнуться на незнакомую штуку.
web — это помойка технологий… клиенту ваще пофиг, что у вас там под капотом, лишь бы удобно было. Так что каждый волен выбирать сам — левая или правая :D. Мне вот правая больше нравиццо.
которые больше не публикуются, если это тип каунтер, то понятно, а если гаудж, то фризится последнее значение
да этого добра на каждом углу, добавили что ли traceql
там, где много ole и activex, там где жопа с типизацией, но это мое личное мнение, я бы больше его нигде не использовал
Ну в писанине каждый делает, что хочет... только вот потом приходят не совсем понимающие, видят "правильно" и начинают думать, что это действительно правильно. Называйте вещи своими именами - просто удобно.
Еще не забываем, что ArrayList оперирует типом object, отсюда объект сразу создается не на стеке, а в куче, потому что используется упаковка (для объекто ладно, но для типов значений - камон Карл), отсюда еще куча всего вытекает... Ну блин, там что нет своих массивов? Ну это точно не правильный способ для VBA
я как-то экспериментировал с логстэшем пару лет назад - дул в него где-то 70k записей в секунду, умирал быстро и надолго. То же количество раскидывал раундробином в мастера и все было норм. И я склоняюсь к следующему: все что по середине между поставщиками логов и мастерами эластика - узкое место. Препарсинг должен быть сделан в виде агента, типа как у егеря, где это возможно, ну а там где нет, то подойдет ваша схема
все по книге 😁
Давно делал прям идентичную штуку, там все на AT - https://habr.com/ru/post/261387/
как по мне, это уже не DI, а извращенный локатор сервисов.
пока язык хорошо выполняет свои задачи, на нем будут писать, но ничто не вечно под луной 😂
К тем, что описано в статье, нет... Но есть еще категории, где такой же инстанс.
Проблема не в том, какие метрики нужны и не в том, что закинуть в query. Необходимо инстанс сопоставить с тем именем, который понятный людям, но это не PID, не имя процесса, не бинарь - это имя сайта или пула, имя службы, консоли и того сложнее, ибо бинарь зачастую не коррелирует с названием приложения.
Все сводится к одной хотелке - соответствие инстанса и процесса должно быть атомарной операцией. Я бы тоже по возможности избегал сбор performance по процессу через категорию process. И, конечно, самый простой способ переложить это на плечи программиста, ибо ему доступно все это из домена приложения, но все-равно в таком подходе все сводится к дорогому "NtQuerySystemInformation", будь то точка входа .net.process или более низко уровневое api. Можно пойти по пути ETW,начать отлавливать переключения контекста между потоками и калькулировать performance, но это значительно увеличит кодовую базу.
Я выбрал реактивный подход, когда ETW не генерит события какой-то определенное время после последнего события, то запускается процесс пересборки коллекторов, это минимизировало количество ошибок, но иногда можно наблюдать скачи того же CPU в 100000%
А так, вы все верно пишите.
Ну и остается заказчик, где и возможен вариант наткнуться на незнакомую штуку.