1. Рады видеть Вас на русскоязычном форуме TeamSpeak!

    У нас Вы можете скачать последнюю версию:

    Перед регистрацией рекомендуем ознакомиться

    с Правилами форума.

    Присоединяйтесь! Учите и обучайтесь!

    Скрыть объявление
  2. Новая группа "Новичок" на нашем форуме!

    Новые пользователи будут попадать в группу "Новичок".

    Это сделано для того чтобы "Новички" ознакомились с форумом, так как в большинстве случаев проблема с которой вы хотите обратиться уже обсуждалась.

    Перейти в тему обсуждения
    Быстрый переход в группу Пользователь
  3. VPS/VDS и дедикейт сервера в аренду с DDoS защитой

    • Низкий пинг
    • Действующий SLA
    • Рублевые цены без привязки к курсу валют

    Бесплатный тестовый период VPS-OpenVZ

    Попробовать

Сервер Еще один вариант учета статистики пользователей

Принцип основан на триггерах БД. (Перенос темы из вопросов)

  1. VJean

    VJean ǝноɯʚıqж Администратор Знаток

    Регистрация:
    26 июл 2014
    Сообщения:
    1.772
    Симпатии:
    389
    Баллы:
    775
    Данный вариант подразумевает работу с Базой Данных (БД) напрямую. Используется MariaDB. Вариант с SQLite оставлю как домашнее задание.
    Принцип основан на триггерах БД. В данном варианте учитывается входы, смены айпи и трафик. по всем серверам. При желании, и при достаточном кол-ве накопленных данных, можно будет провести корреляции по сменам ника, трафику, ip и(или) id определенного пользователя.

    PHP:
    CREATE TABLE `clients_stat` (
        `
    idINT(10UNSIGNED NOT NULL AUTO_INCREMENT,
        `
    timestampTIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
        `
    client_idINT(11NOT NULL DEFAULT '0',
        `
    server_idINT(10UNSIGNED NULL DEFAULT NULL,
        `
    client_unique_idVARCHAR(40NULL DEFAULT NULL,
        `
    client_nicknameVARCHAR(100NULL DEFAULT NULL,
        `
    client_login_nameVARCHAR(20NULL DEFAULT NULL,
        `
    client_login_passwordVARCHAR(40NULL DEFAULT NULL,
        `
    client_lastconnectedINT(10UNSIGNED NULL DEFAULT NULL,
        `
    client_lastdisconnectedINT(10UNSIGNED NULL DEFAULT NULL,
        `
    client_totalconnectionsINT(10UNSIGNED NULL DEFAULT '0',
        `
    client_month_uploadBIGINT(20UNSIGNED NULL DEFAULT '0',
        `
    client_month_downloadBIGINT(20UNSIGNED NULL DEFAULT '0',
        `
    client_total_uploadBIGINT(20UNSIGNED NULL DEFAULT '0',
        `
    client_total_downloadBIGINT(20UNSIGNED NULL DEFAULT '0',
        `
    client_lastipVARCHAR(20NULL DEFAULT NULL,
        
    PRIMARY KEY (`id`),
        
    INDEX `index_clients_id` (`client_id`),
        
    INDEX `index_clients_serverid` (`server_id`),
        
    INDEX `index_clients_uid` (`client_unique_id`, `server_id`),
        
    INDEX `client_lastip` (`client_lastip`),
        
    INDEX `index_clients_lastconnectedserverid` (`client_lastconnected`, `server_id`, `client_lastdisconnected`),
        
    INDEX `client_nickname` (`client_nickname`)
    )
    COLLATE='utf8mb4_general_ci'
    ENGINE=InnoDB
    ;

    PHP:
    CREATE TRIGGER `clients_before_updateBEFORE UPDATE ON `clients` FOR EACH ROW INSERT INTO clients_stat(
       
    client_idserver_idclient_unique_idclient_nicknameclient_login_nameclient_login_password,
       
    client_lastconnectedclient_totalconnections,
       
    client_month_uploadclient_month_downloadclient_total_uploadclient_total_downloadclient_lastip)
    VALUES (
       NEW.
    client_id, NEW.server_id, NEW.client_unique_id, NEW.client_nickname, NEW.client_login_name, NEW.client_login_password,
       NEW.
    client_lastconnected, NEW.client_totalconnections,
       NEW.
    client_month_upload, NEW.client_month_download, NEW.client_total_upload, NEW.client_total_download, NEW.client_lastip)
    END

    Небольшие уточнения:
    - DDL таблицы clients_stat взят из оригинальной clients.
    - Сам сервер TS3 оперирует INSERT OR UPDATE, поэтому триггер приходится вешать на UPDATE.
    - Отследить дисконнект пользователя данным способом нереально. увы, только ботом.
    - При большом кол-ве соединений и, соответственно, обновлений БД возможна просадка производительности самой Базы. Использовать на свой страх и риск.
    - Работает уже чуть больше полугода #3, на не особо активном сервере NPL, база особо не растет (больше всего за это боялся). Деградации и падения производительности замечено не было.

    Данный вариант можно "проапгрейдить" дальше как дополнение к логам сервера, для учета изменений привилегий, каналов и т.д. т.п.
     
    • Нравится Нравится x 4
  2. hroost

    hroostIcon Voice-Server.ru ATHP Премиум Пользователь

    Регистрация:
    21 фев 2013
    Сообщения:
    222
    Симпатии:
    54
    Баллы:
    455
    мне кажется в промышленных масштабах лучше использовать Elasticsearch, загоняя туда все логи и переваривая под необходимые задачи.
     
  3. VJean

    VJean ǝноɯʚıqж Администратор Знаток

    Регистрация:
    26 июл 2014
    Сообщения:
    1.772
    Симпатии:
    389
    Баллы:
    775
    @hroost ты про текстовые логи? они, как минимум, детальную статистику по трафу дадут ) а тут реалтайм, безовсяких парсингов )
    если честно, тему хостеров и высоконагруженных серверов трогать боязно и не дадут поковырятсо :D
     
    Последнее редактирование: 26 фев 2016
  4. darkangel66

    darkangel66Icon TEAM-HOST.RU ATHP Премиум Пользователь

    Регистрация:
    12 июн 2012
    Сообщения:
    471
    Симпатии:
    201
    Баллы:
    672
    Вот вы знаете... когда то давно давно у меня был проект под большое комюнити и тс с 1000 слотов (реально были случаи когда ребята упирались в потолок а регулярный онлайн 800-930 слотов) с контролем посещаемости КАЖДОГО члена комюнити (более 50000 уникальных человек)
    я долго искал оптимальный выход и в итоге я пришел к выводу что самый оптимальный и не ресурсоемкий подход это :
    - включение логов на сервере ТС
    - самописный парсер логов тс который складывает нужные мне данные в БД мускул + запоминает номер строчки в логе которую от отпарсил в последний цикл, и новый цикл начинается не с начала файла логов а с той строчки которую он запомнил. а каждый тысячный цикл работы парсера происходило очищение текстового файла логов ТС и обнуление счетчика начальной строчки для парсера
    - а дальше всё решается обычными селектами с MySQL

    решение под ту задачу оказалось идеальным, предельно не ресурсоемким и простым.
    --- Сообщение объединено, 26 фев 2016 ---
    кстати забыл добавить... так как я боялся забить IO дисковой системы то под папку логов TS я делал RAM диск на 2 гига.
    и так как текстовый вариант логов регулярно очищался то 2 гигов хватило заглаза (там хватило бы и раз в 10 меньше но лень было менять)
     
  5. hroost

    hroostIcon Voice-Server.ru ATHP Премиум Пользователь

    Регистрация:
    21 фев 2013
    Сообщения:
    222
    Симпатии:
    54
    Баллы:
    455
    Если у нас дойдут руки - внедрим Эластик и смогу поделиться опытом)
     
Загрузка...