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

[Softer]

А почему MySQL? Почему не ELK?

[iRandom]

Как-то взор пал на протоптанную дорогу MySQL, имел опыт ELK в graylog, надо подумать

[Deq56]

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

[iRandom]

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

[whitedruid]

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

[iRandom]

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

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

[erlioniel]

Не используйте базу в качестве централизированного хранилища для логов, выше уже рекомендовали ELK — это действительно стоящий внимания инструмент. В качестве альтернативы можно предложить Graylog — он мне показался более простым для старта, но менее гибким чем ELK.

[tbp2k5]

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

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

[iRandom]

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

[Godless]

а можно конфиг в личку? интереса для. что для фильтрации squidguard? а как https фильтруется?

[iRandom]

увы, слишком многое нужно маскировать в конфигах :) ну собственно, никакого космического корабля )

[mihmig]

Как вариант могу предположить, что скоро трафик опять подорожает. Тогда кеширование сможет помочь (но только если кешировать через MITM https трафик. Как раз для корпоративных пользователей внедрение корневого сертификата не представляет проблемы.

[tbp2k5]

Не знаю как в ваших краях а у нас линии и так не дешевые. Стоимость гигабитной линии для организаций (уточнение целевого уровня доступности: с резервированием, 2+ аплинка, и т. д.) исчисляется в десятках тысяч евро в год. 10Gb уже сотни тысяч. Но цены помаленьку падают. С другой стороны цены для SOHO раз в 100-150 ниже — вполне могут и вырасти. Тем не менее не думаю что это экономически оправдает прокси…

PS MITM: мне лично сильно не нравятся подобные решения. Все что ухудшает безопасность — плохое решение за которое, рано или поздно, приходиться платить…

[mihmig]

acl dontLog http_status 403 407 — опциональная строка, убирает ошибки из лога

Спасибо за опцию, не знал о такой взможности (соответственно и не искал в документации)

Сразу же пришла в голову «уязвимость»:
инсайдер может сливать данные на свой веб-сервер, принимающий файл и отдающий ошибку :)
Как вариант — логировать это в текстовый файл, с анализом аномалий (резкое увеличение размера файла, большой размер запроса/ответа)

[iRandom]

да, именно поэтому оставил параллельно логирование в локальные файлы, ибо бывает нужен дебаг, ну и не мешает периодически поглядывать в аксес логи, бывали случаи high cpu из-за chrome request > clients*.google.com

[smartlight]

Что будет если сервак с Mysql приляжет от того что места в /var/lib/mysql закончилось?
Где настройка хотя бы одно слейва?
Будьте готовы резать БД каждый месяц

[iRandom]

Для этого есть Zabbix который мониторит и базу и место в /var/lib/mysql

А в общем да, опитимизация базы нужна, сделаем — отпишу часть 2ую :)

[k3NGuru]

А чем обрабатывате логи?

[iRandom]

Пока ни в чем, в проекте

В целом больше нужен репортинг, выше предложи ELK — возможно будем думать в эту сторону

[sfhg]

Даешь веб фронтенд!

[iRandom]

скоро, в разработке :)

[pessom]

И это в 21 веке?
практичнее использовать rsyslog + graylog.
Доставка логов будет за минимальное время, нагрузка на сервис минимальна и что-то искать значительно проще.

[iRandom]

Испрользовал эту связку для логирования серверов и нетворк оборудывания, graylog понравился — удобно, конекторы, grok и тд, но были существенные проблемы с производительностью — поэтому с jvm как-то связываться не хотелось, да и иногда велосипед интереснее :)

[pessom]

Для jvm нужно помощнее железо и побольше памяти, у себя в легкую просасываем 500 сообщений в секунду.
Никаких проблем с доезжаем логов или производительностью нет.

[Doktor3lo]

Мне казалось, хранить логи в БД — не самый лучший вариант. Почему не использовать какое-нибудь специфическое решение. Например, influxdb или graphit с последующим натягиванием какой-нибудь grafana?

На какой объем логов вы рассчитываете?

[iRandom]

Пока что замеряю количество логов, за 3 дня 750 мб — что не критично, дальше будет видно

[iRandom]

з.ы. 403/407 не учитываются, поэтому складируется «чистые» логи для репортинга

[Ipeacocks]

Против influxdb основной аргумент — кластеризация там за деньги.

[Doktor3lo]

или там за деньги, или в mysql шаридинг вручную и неизвестно, что «дешевле» :)
но при таких объемах можно и правда не дергаться… 80Гиг за год — это не много…

[iRandom]

retention таких данных много меньше чем год, так что беспокоиться особо не за что :)

[Ipeacocks]

Есть куча всего кроме mysql. Я конечно не веду к тому, что продукт не имеет права требовать деньги.

[ckpunT]

Squid, как много в этом слове для it-шника слилось. Хранение логов в реляционной БД — мощно.
Скрипт при отсутствии же связи с БД не дошлет логов и придется ручками перезаливать лог, если это вообще кто-либо будет делать. Как и сообщения rsyslog не всегда доходят до graylog, даже при наличии связи с сервером логов. Прям навеяло, ng_ipacct на freebsd 4.3 с perl-скриптом, который раз в минуту снимал статистику и складывал в mysql.
Если уж логи важны, то стоит локально хранить логи и копировать и(или) реплицировать их на squid_db. Ну или устроить трэш и отправлять логи через MQ (: