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

Есть большая файлопомойка с фильмами, клипами и музыкой, открытая по локалке через 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 и смены дескрипторов (дублирование/закрытие/переоткрытие), сомневаюсь, что я смогу учесть все краевые случаи.

Возможно, я изобретаю велосипед и не знаю о существовании готового решения?
В какую сторону следует копать? Что посоветуете, господа?
  • Вопрос задан
  • 412 просмотров
Пригласить эксперта
Ответы на вопрос 3
vechnoe
@vechnoe
Tornado, Django, Postgres, Asyncio, Clojure
Возможно стоит отказаться от Samba и написать свою обертку вокруг файлопомойки (какое количество у вас файлов? сколько всего пользователей? какой средний размер файла?).

Допустим, написать веб-интерфейс для отображения файлов/каталогов. Хранить множество файлов лучше не в файловой системе (вам же не хранить нужно, а отдавать), а использовать что-то типа Seaweed FS. Поверх можно проксировать запросы и сохранять статистику в БД.
Ответ написан
leahch
@leahch
Я мастер на все руки, я козлик Элек Мэк :-)
В линуксе есть прекрасный механизм наблюдения за файлами и директориями inotify. Так что можно не уходить с самбы и не писать свою fs на fuse.
https://ru.m.wikipedia.org/wiki/Inotify
Ответ написан
попробуйте vfs-модули самой самбы, по крайней мере по их логам сможете собрать статистику по популярности файлов
Ответ написан
Ваш ответ на вопрос

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

Войти через TM ID
Похожие вопросы