[Из песочницы] Централизованное хранилище логов для Squid Proxy или как мы логи в базу заворачивали

Комментарии (8)

  • 8 августа 2017 в 19:17

    +2

    А почему MySQL? Почему не ELK?
    • 8 августа 2017 в 19:21

      0

      Как-то взор пал на протоптанную дорогу MySQL, имел опыт ELK в graylog, надо подумать
  • 8 августа 2017 в 20:38

    0

    А что мешало сделать несколько табличек в БД, это бы уменьшило в итоге базу и облегчило написание запросов?
    к примеру вынести из access_log данные по src_ip, user, url, method и т.д. в отдельные таблички?
    Просто при большом кол-во пользователей, БД будет долговато строить отчеты
    • 8 августа 2017 в 20:51

      0

      Честно говоря, оптимизацией базы пока не занимались, пользователей много, но долгих запросов пока не наблюдали, за идею спасибо, учтём :)
  • 8 августа 2017 в 22:00

    0

    Большое спасибо! Сам задумывался над централизацией хранения (для трёх нод всего). Очень бы хотелось узнать про то какие-нибудь современные средства по анализу логов :) (к вопросу о том, что интересует в Squid)
    Ещё, извините за полный offtop, задам вопрос ко всем присутствующим (с просьбой о помощи): у всех ли корректно basic-авторизация Squid работает в Microsoft Edge (в Windows 8/10)? Наткнулся на эти «грабли» и никак не могу победить. Chrome, Mozilla — все отлично, а MS IE, Edge — ошибка. В качестве «первого хелпера» — Kerberos-авторизация.
    • 8 августа 2017 в 22:06

      0

      Рад что оказалось полезным :)

      Хм, ntlm + ldap полет нормальный, странно, а в чем именно проблема? что логи говорят? какая версия squid?

  • 9 августа 2017 в 07:59

    0

    Наверное off-topic, но не поделитесь причиной использования Proxy в ваших офисах?

    NB Я знаю Squid и его плюшки (почти 20 лет занимаюсь, среди прочего, одним из наших проксей). Недавно просматривал его статистику за последних несколько месяцев. Через этот сервер ~3500 пользователей тянут в среднем 2Tb в сутки. Сейчас период отпусков/каникул, но выборка все равно достаточно репрезентативная. Судя по логам, количество эффективно кешируемого трафика тает на глазах (все в криптованных тоннелях). Собственно тенденция просматривается давно откуда решение убирать прокси. У вас все видимо не так. Мне интересно в чем ваша специфика…

    • 9 августа 2017 в 08:00

      0

      Фактически давно отказались от cache функционала — не имеет смысла, поэтому основном назначение распередление доступов в зависимости от AD групп

© Habrahabr.ru