Задать вопрос

Как организовать общесистемный мониторинг чтения определенных файлов с контролем объемов прочитанного?

Есть большая файлопомойка с фильмами, клипами и музыкой, открытая по локалке через Samba. Люди заходят, смотрят, слушают... Для приведения помойки в порядок требуется собрать такую статистику по просмотру/прослушиванию: как часто происходил доступ к каждому конкретному файлу, какой процент объема файла был прочитан за одну сессию доступа в среднем (досмотрел ли человек клип до конца, или до середины, или вырубил сразу как только понял суть). Проблема еще и в том, что при простом заходе в сетевой каталог в Dolphin, Nautilus и любом графическом просмотрщике начинают генерироваться миниатюры, то есть идет доступ на чтение, так же как при открытии в плеере. Бороться с этим планирую путем фильтрации логов по ratio = read_size / total_file_size, для этого опять же нужно знать объем прочитанного за одну сессию доступа.
Уточню: Целью является не контроль доступа со стороны пользователей, а контроль за ресурсами, путем сбора статистики их востребованности.

С начала я смотрел в сторону написания собственного FUSE-драйвера (еще не приходилось таким заниматься) для прозрачного прозрачного пропускания запросов с логгированием. Но остаются вопросы о производительности такого решения и подводных камнях при использовании Samba поверх FUSE.

Потом задумался об использовании auditd и написании скрипта, который бы парсил вывод /var/log/audit/audit.log (точнее процесс (один на всю систему) можно прикрутить к dispatcher в auditd.conf). Но, во-первых, это очень некрасиво, так как требует рутовых прав на любое изменение параметров мониторинга, и сам скрипт запускается под рутом (очень нехорошо). Но главная проблема в том, что лог syscall дает слишком низкий уровень абстракции, то есть придется самостоятельно следить за всеми открытыми дескрипторами и каждым file poiter, чтобы получить на выходе лог вида:
Reading from: "./movie.mkv"; offset: 0x78563; length: 0x89332
Нужно держать внутри аналог указателя к каждому дескриптору каждого процесса и двигать его после каждой операции (кроме read, еще учитывать write, fseek, может еще что), нельзя пропускать (нераспознанным, например) ни один syscall. При этом придется соблюдать слишком много правил расчета file poiter и смены дескрипторов (дублирование/закрытие/переоткрытие), сомневаюсь, что я смогу учесть все краевые случаи.

Возможно, я изобретаю велосипед и не знаю о существовании готового решения?
В какую сторону следует копать? Что посоветуете, господа?
  • Вопрос задан
  • 442 просмотра
Подписаться 4 Оценить Комментировать
Пригласить эксперта
Ответы на вопрос 2
leahch
@leahch Куратор тега Linux
3D специалист. Dолго, Dорого, Dерьмово.
В линуксе есть прекрасный механизм наблюдения за файлами и директориями inotify. Так что можно не уходить с самбы и не писать свою fs на fuse.
https://ru.m.wikipedia.org/wiki/Inotify
Ответ написан
попробуйте vfs-модули самой самбы, по крайней мере по их логам сможете собрать статистику по популярности файлов
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы