Prometheus metric exporter with top activity

[akardapolov]

Hi!

@sasah have you details about metric exporter? Need to export data from Prometheus to ASH Viewer or vice versa?

Thanks, Alex.

[sasah]

Добрый день! Мы работаем по настройке для своих команд поддержки общих дашбордов на Графана+ Прометеус, где в том числе хочется видеть общее состояние СУБД. В частности хотелось бы видеть то что в ASH Viewer как топ активность и её детали, но без детальной информации по отдельным SQL запросам. Подскажите, пожалуйста, возможно ли экспортировать метрики топ и детальных активностей в формате Прометеус? Но ещё лучше выделить это в отдельный экспортёр. Я бы сделал бы его тут сам если бы Вы помогли с пониманием Ваших алгоритмов построение этих графиков, пока я по исходникам не разобрался.

[sasah]

SELECT n.wait_class as WAIT_CLASS, round(m.time_waited/m.INTSIZE_CSEC,3) as VALUE FROM v$waitclassmetric m, v$system_wait_class n WHERE m.wait_class_id=n.wait_class_id AND n.wait_class != 'Idle'

[sasah]

"select ACTIVITY, DETAIL, count(*) as value" + " from (" + " select DECODE(SESSION_STATE," + " 'ON CPU'," + " 'CPU used'," + " WAIT_CLASS) AS ACTIVITY," + " DECODE(SESSION_STATE," + " 'ON CPU'," + " DECODE(SESSION_TYPE, 'BACKGROUND', 'background', 'user')," + " EVENT) AS DETAIL" + " from V$ACTIVE_SESSION_HISTORY" + " WHERE SAMPLE_TIME > SYSDATE - (1 / 1440))" + " group by ACTIVITY, DETAIL"

[sasah]

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

[akardapolov]

@sasah

если бы Вы помогли с пониманием Ваших алгоритмов построение этих графиков, пока я по исходникам не разобрался

В данный момент хранятся raw и агреггированные данные мониторинга истории активных сессий во встроенной БД.

• raw-данные - в этой сущности, в которой матрица из int-ов хранит данные в табличном виде (по ключу dateId). Сделано так для возможности динамической вставки данных для разных источников (Oracle, Postgres etc) и различном количеством столбцов в разных версиях БД. Ну и снижении объемов хранимых данных тоже.

• агрегированные - по односекундному интервалу здесь. Также хранится агреграция по 15 секундным и одноминутным интервалам, в отдельных сущностях.

Логику заполнения raw и агрегированными данными можно посмотреть здесь и здесь.

Т.е. для raw-данных храним историю активных сессий в табличном виде, для агрегированных - храним данные по ожиданиям (количество по группе ожиданий, класс ожидания - waitClass) для каждого интервала (1, 15 сек. и 1 мин.) + значение параметра (это идентификатор процесса SID + '_' + Serial# или для sqlId - просто его значение) - денормализованные данные ожиданий по ключу dateId + paramId - этот такая простая olap схема.

Далее, это все отображается в Top Activity stacked графике: здесь или при выборке данных по истории активных сессий в top gantt по ID процесса или sqlId (это все выборка по агрегированным данным). Raw данные запрашиваются в GUI примерно вот так.

Самый простой вариант, как мне видится - это (вроде есть в Prometheus возможность хранить данные в своем хранилище) сделать таблицу по агрегированным данным подобного вида, заполнять ее и делать по ней запросы для построения общего графика (не забыть про дополнительные сущности для раскрытия значения ID событий ожиданий, ID процессов). Оттуда же брать данные и для детализации по процессами или sqlId. Думаю в эту сторону копать по поводу отдельного экспортера, но я за отдельный сервис все-таки. Плюсы: работать будет быстро, будет детализация ТОП по процессам, в в одной таблице. Минусы: нет исходных данных.

Второй вариант проще: сливать периодически данные истории активных сессий из Oracle во внутренню БД Prometheus и делать по этим данным те-же запросы. Работать должно быстро, так как можно будет прикрутить к этому всему индексы ES - там можно всякие разные ad-hoc крутить насколько знаю по текстовым данным итд. Хотя объемы данных будут большие, это минус.