Comments 32
А почему MySQL? Почему не ELK?
А что мешало сделать несколько табличек в БД, это бы уменьшило в итоге базу и облегчило написание запросов?
к примеру вынести из access_log данные по src_ip, user, url, method и т.д. в отдельные таблички?
Просто при большом кол-во пользователей, БД будет долговато строить отчеты
к примеру вынести из access_log данные по src_ip, user, url, method и т.д. в отдельные таблички?
Просто при большом кол-во пользователей, БД будет долговато строить отчеты
Большое спасибо! Сам задумывался над централизацией хранения (для трёх нод всего). Очень бы хотелось узнать про то какие-нибудь современные средства по анализу логов :) (к вопросу о том, что интересует в Squid)
Ещё, извините за полный offtop, задам вопрос ко всем присутствующим (с просьбой о помощи): у всех ли корректно basic-авторизация Squid работает в Microsoft Edge (в Windows 8/10)? Наткнулся на эти «грабли» и никак не могу победить. Chrome, Mozilla — все отлично, а MS IE, Edge — ошибка. В качестве «первого хелпера» — Kerberos-авторизация.
Ещё, извините за полный offtop, задам вопрос ко всем присутствующим (с просьбой о помощи): у всех ли корректно basic-авторизация Squid работает в Microsoft Edge (в Windows 8/10)? Наткнулся на эти «грабли» и никак не могу победить. Chrome, Mozilla — все отлично, а MS IE, Edge — ошибка. В качестве «первого хелпера» — Kerberos-авторизация.
Рад что оказалось полезным :)
Хм, ntlm + ldap полет нормальный, странно, а в чем именно проблема? что логи говорят? какая версия squid?
Хм, ntlm + ldap полет нормальный, странно, а в чем именно проблема? что логи говорят? какая версия squid?
Не используйте базу в качестве централизированного хранилища для логов, выше уже рекомендовали ELK — это действительно стоящий внимания инструмент. В качестве альтернативы можно предложить Graylog — он мне показался более простым для старта, но менее гибким чем ELK.
Наверное off-topic, но не поделитесь причиной использования Proxy в ваших офисах?
NB Я знаю Squid и его плюшки (почти 20 лет занимаюсь, среди прочего, одним из наших проксей). Недавно просматривал его статистику за последних несколько месяцев. Через этот сервер ~3500 пользователей тянут в среднем 2Tb в сутки. Сейчас период отпусков/каникул но выборка все равно достаточно репрезентативная. Судя по логам, количество эффективно кешируемого трафика тает на глазах (все в криптованных тоннелях). Собственно тенденция просматривается давно откуда решение убирать прокси. У вас все видимо не так. Мне интересно в чем ваша специфика…
NB Я знаю Squid и его плюшки (почти 20 лет занимаюсь, среди прочего, одним из наших проксей). Недавно просматривал его статистику за последних несколько месяцев. Через этот сервер ~3500 пользователей тянут в среднем 2Tb в сутки. Сейчас период отпусков/каникул но выборка все равно достаточно репрезентативная. Судя по логам, количество эффективно кешируемого трафика тает на глазах (все в криптованных тоннелях). Собственно тенденция просматривается давно откуда решение убирать прокси. У вас все видимо не так. Мне интересно в чем ваша специфика…
Фактически давно отказались от cache функционала — не имеет смысла, поэтому основном назначение распередление доступов в зависимости от AD групп
Как вариант могу предположить, что скоро трафик опять подорожает. Тогда кеширование сможет помочь (но только если кешировать через MITM https трафик. Как раз для корпоративных пользователей внедрение корневого сертификата не представляет проблемы.
Не знаю как в ваших краях а у нас линии и так не дешевые. Стоимость гигабитной линии для организаций (уточнение целевого уровня доступности: с резервированием, 2+ аплинка, и т. д.) исчисляется в десятках тысяч евро в год. 10Gb уже сотни тысяч. Но цены помаленьку падают. С другой стороны цены для SOHO раз в 100-150 ниже — вполне могут и вырасти. Тем не менее не думаю что это экономически оправдает прокси…
PS MITM: мне лично сильно не нравятся подобные решения. Все что ухудшает безопасность — плохое решение за которое, рано или поздно, приходиться платить…
PS MITM: мне лично сильно не нравятся подобные решения. Все что ухудшает безопасность — плохое решение за которое, рано или поздно, приходиться платить…
acl dontLog http_status 403 407 — опциональная строка, убирает ошибки из лога
Спасибо за опцию, не знал о такой взможности (соответственно и не искал в документации)
Сразу же пришла в голову «уязвимость»:
инсайдер может сливать данные на свой веб-сервер, принимающий файл и отдающий ошибку :)
Как вариант — логировать это в текстовый файл, с анализом аномалий (резкое увеличение размера файла, большой размер запроса/ответа)
Что будет если сервак с Mysql приляжет от того что места в /var/lib/mysql закончилось?
Где настройка хотя бы одно слейва?
Будьте готовы резать БД каждый месяц
Где настройка хотя бы одно слейва?
Будьте готовы резать БД каждый месяц
А чем обрабатывате логи?
Даешь веб фронтенд!
И это в 21 веке?
практичнее использовать rsyslog + graylog.
Доставка логов будет за минимальное время, нагрузка на сервис минимальна и что-то искать значительно проще.
практичнее использовать rsyslog + graylog.
Доставка логов будет за минимальное время, нагрузка на сервис минимальна и что-то искать значительно проще.
Мне казалось, хранить логи в БД — не самый лучший вариант. Почему не использовать какое-нибудь специфическое решение. Например, influxdb или graphit с последующим натягиванием какой-нибудь grafana?
На какой объем логов вы рассчитываете?
На какой объем логов вы рассчитываете?
Пока что замеряю количество логов, за 3 дня 750 мб — что не критично, дальше будет видно
Против influxdb основной аргумент — кластеризация там за деньги.
Squid, как много в этом слове для it-шника слилось. Хранение логов в реляционной БД — мощно.
Скрипт при отсутствии же связи с БД не дошлет логов и придется ручками перезаливать лог, если это вообще кто-либо будет делать. Как и сообщения rsyslog не всегда доходят до graylog, даже при наличии связи с сервером логов. Прям навеяло, ng_ipacct на freebsd 4.3 с perl-скриптом, который раз в минуту снимал статистику и складывал в mysql.
Если уж логи важны, то стоит локально хранить логи и копировать и(или) реплицировать их на squid_db. Ну или устроить трэш и отправлять логи через MQ (:
Sign up to leave a comment.
Централизованное хранилище логов для Squid Proxy или как мы логи в базу заворачивали