Здравствуйте.
Технологий взлома уйма.
В зависимости от того, какие привелегии получил "хакер" при вломе вашей БД - зависит очень много.
Если он получил доступ только на чтение, то захешированные в MD5 пароли ему мало чем помогут, т.к. MD5 не имеет алгоритма обратной расшифровки и хэширование спасёт тем, что взломщик получивший доступ на чтение паролей - самих паролей не получит (есть конечно словарь MD5 хешей, то это другая история).
Вообще для защиты любой БД есть несколько золотых правил:
0. Переименовать дефолтного админа и защитить его сложным паролем.
1. Для каждой БД должен создаваться свой владелец и несколько пользователей с разными наборами привелегий.
2. Ни у одного из пользователей, созданных в п.1 не должно быть прав на изменение таблиц в соседней БД.
Если есть необходимость обновлять соседние БД - делайте это триггером в соседней БД.
3. Каждый внешний веб-сервис должен ходить в БД только с тем набором прав, которых ему достаточно для работы. Т.е. не нужно везде прописывать root и надеяться на лучшее.
В этом случае, если взломщик получит привелегии этого пользователя, то сможет сделать только то, что разрешено этому пользователю. Тогда не выйдет "удалить все и сразу".
Например, для наполнения католога товаров в интернет-магазине может быть отдельный пользователь, с правами на SELECT, INSERT, UPDATE, DELETE в таблице SHOP_PRODUCTS, например. И ничего более.
А пользователи, приходящие в магазин за покупками могут делать SELECT, INSERT, UPDATE, DELETE только в таблицу CUSTOMER_CART. В коде веб-сервиса, естественно должна быть проверка, что покупатель редактирует СВОЮ корзину.
Для показа каталога товаров - отдельный пользователь, имеющий право только на SELECT из таблицы SHOP_PRODUCTS.
А продажу товара может делать отдельный пользователь, с правом только на UPDATE колонки AMOUNT в таблице SHOP_PRODUCTS. Пример:

GRANT SELECT ON shopdb.SHOP_PRODUCTS TO 'trader_bot'@'shophost';
GRANT UPDATE (AMOUNT) ON shopdb.SHOP_PRODUCTS TO 'trader_bot'@'shophost';

И т.п. По принципу "Разделяй и властвуй."
4. Писать запросы с использованием placeholder'ов (подстановку данных), что убережёт от SQL-инъекций.
Пример:

$DB->select('SELECT * FROM tbl WHERE a=? AND b=?', $a, $b);

5. Если и БД и приложение, используещее БД установлены на одном сервере - отключить удалённый доступ к БД и работать через сокеты.
6. Последний, но самый важный - БЕКАПЫ. При удалении всего и вся - нужно откуда-то восстановиться. Делайте бекапы и храните на отдельном сервере (не выставленном наружу).

Некропостинг, конечно, но нашёл этот пост, когда искал решение данного вопроса.
Тем, кто в будущем наткнётся - решение:
В zabbix для Windows есть Zabbix agent-проверки:
"proc_info" - для получения информации о процессе.
"proc.num" - для подсчёта кол-ва процессов, на сервере.
Подробно расписаны в мануале:
proc_info
proc.num
Для большинства unix-систем вместо proc_info используется проверка proc.mem.
Для того, чтобы узнать - поддерживается ли в вашей системе тот или иной элемент данных - сверяйтесь с таблицей в мануале.

В случае автора ключ элемента данных должен выглядеть так:
proc_info[process.exe,wkset,sum]
Данный элемент данных выводит кол-во потребляемой памяти в КБ.
Неудобно? Ставим в настройках элемента данных:
Units (Единица измерения) - B
Use custom multiplier (Пользовательский множитель) - 1024

Через Yandex.API, например.

ts_block существует.