И уточнение под чтением данных (Б): когда в любой момент времени пользователи заходят в панель админки (или что там у вас будет) через API и видят там результаты агрегации данных. Но необязательно только чтение. Просто по этому пути не должно быть сбора данных от агентов, с которых идет сбор текстовых данных.
И даже это API не обязан быть на том же стеке технологий, как API при сбора данных в режиме записи (А).
DevMan,
это субъективно. Я уже неоднократно замечал за вами ликвидацию тегов, которые стоило оставить как есть. Не стоит злоупотреблять своими полномочиями...
DevMan,
Автор вполне резонно отметил тег OpenServer. Ведь речь не просто об установке Mysql, а внутри этой экосистемы.
Вот у меня есть подозрение, что есть какие-то настройки OpenServer касательно оной проблемы.
beduin01,
Выше про мониторинг приложения. А дополнительно нужно смотреть средства мониторинга Postgresql. Должно показывать как работает сама СУБД и напрягают ли ее вообще запросы. А если напрягают, то может и IOPS растет.
beduin01, APM - это класс программ для мониторинга производительности. Для каждого стека технологий может быть другим. Показывает обычно графики потребления памяти, производительности SQL запросов и прочее. NewRelic и др.
Но можно заменить это частично схожими проверками. Просто замерять таймером любые операции, как с БД, а также отмечать "маркерами" во времени начало и окончание операций, отправляя метрики и статистики.
Метрики можно отправлять по протоколу StatsD и другим.
Метрики: продолжительность замера, счетчики для маркеров и пр.
Затем в Grafana все наглядно смотреть. Будет видно где области "тишины", а где пики при отправке и обработке.
