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

image

Привет %username%,

Сегодня я хотел бы рассказать про достаточно тривиальную задачу сбора логов с децентрализованных Squid proxy серверов и подводные камни с которыми мы столкнулись.

Что имеем:

  1. Squid-hq
  2. Squid-br1
  3. Squid-br2
  4. Squid-br3
  5. Squid-br4
  6. Squid-db

Как видно из списка, в наличии 5 серверов squid proxy в разных удаленых офисах, и 1 база данных для сбора логов. Все OS CentOS 7.3, squid proxy от 3.3.8 до 3.5.26, Squid-db — с установленной mariadb 5.6

Из того что удалось найти это перловые скрипты и схема, собственно их и берем за основу:

  1. Ставим зависимости на сервера squid proxy:
    yum install perl perl-Readonly* perl-URI perl-YAML perl-DBI perl-Carp perl-DBD-mysql
  2. После чего раскладываем по местам скрипты и конфиг для подключения к базе:

    cp log_mysql_daemon.pl /usr/libexec/squid/log_mysql_daemon.pl

    Даем права:

    chmod +x /usr/libexec/squid/log_mysql_daemon.pl
    chown squid:squid /usr/libexec/squid/log_mysql_daemon.pl


  3. Далее создаем конфиг файл для подключения скрипта к базе:

    vi /etc/squid/log_mysql_daemon.conf

    host: "<database-ip>"
    database: "squid_log"
    table: "access_log"
    user: "squid"
    pass: "<squid-passwd>"


  4. Создаем базу, импортируем схему и создаем юзера:

    mysql -p
    create database squid_log;
    CREATE USER 'squid'@'%' IDENTIFIED BY '<squid-passwd>';
    GRANT ALL PRIVILEGES ON squid_log.* TO 'squid'@'<Squid-hq-ip>';
    GRANT ALL PRIVILEGES ON squid_log.* TO 'squid'@'<Squid-br1-ip>';
    GRANT ALL PRIVILEGES ON squid_log.* TO 'squid'@'<Squid-br2-ip>';
    GRANT ALL PRIVILEGES ON squid_log.* TO 'squid'@'<Squid-br3-ip>';
    GRANT ALL PRIVILEGES ON squid_log.* TO 'squid'@'<Squid-br4-ip>';
    exit

    cat log_mysql_daemon-table.sql log_mysql_daemon-views.sql | mysql -p squid_log



  5. Переходим на сторону зла squid proxy конфига

    Добавляем конфигурацию для демона

    vi /etc/squid/squid.conf
    acl dontLog http_status 403 407
    logformat squid_mysql %ts.%03tu %6tr %>a %Ss %03Hs %<st %rm %ru %un %Sh %<A %mt squid-hq
    access_log /var/log/squid/access.log squid
    access_log daemon:/etc/squid/log_mysql_daemon.conf squid_mysql !dontLog
    logfile_daemon /usr/libexec/squid/log_mysql_daemon.pl


    Разбираем:
    acl dontLog http_status 403 407 — опциональная строка, убирает ошибки из лога идущих в базу данных связаные с эрор кодами 403, 407. База будет расти в геометрической прогресии, а для репортинга не будет нести никакой ценности

    logformat squid_mysql %ts.%03tu %6tr %>a %Ss %03Hs %<st %rm %ru %un %Sh %<A %mt squid-hq — задаем формат логу, одно из важных условий для множественных squid серверов последнее значение с названием сервера с которого приходят логи. В оригинальных скриптах функционал отсутствует поэтому подкручиваем эту строку и сам скрипт следующим образом:

    в /usr/libexec/squid/log_mysql_daemon.pl в настройку колонок добавляем squid-server

    # fields that we should have in the database table
    # this list depends on the log format configuration
    my @required_fields = qw(
    id
    time_since_epoch
    response_time
    client_src_ip_addr
    squid_request_status
    http_status_code
    reply_size
    request_method
    request_url
    username
    squid_hier_status
    server_ip_addr
    mime_type
    squid_server
    );


    access_log /var/log/squid/access.log squid — Оставляем локальные логи для отладок и случаев проблем с базой, у них включен ротейшен поэтому лишним не будет

    access_log daemon:/etc/squid/log_mysql_daemon.conf squid_mysql !dontLog — собственно сама строка к конфигурации демона. Обратите внимание что !dontLog отменяет логирование 403,407 только для базы данных, так что в случае отладки можно легко использовать локальные логи

    logfile_daemon /usr/libexec/squid/log_mysql_daemon.pl — путь к перловому демону

  6. Перечитываем конфиги squid proxy

    squid reconfigure
    squid -k reconfigure


    и получаем желаемый результат:
    image

    Доступные таблицы и вьюшки:
    image

Заключение:


Как видно, данные теперь находятся централизованно в базе данных и легко доступны для обработки. Далее планируем написать фронтэнд для фильтрации и экспорта данных (репортинга). В целом статья написана и собрана из разных источников, к сожалению нигде не смог найти все вместе, поэтому считаю целесообразым оставить это здесь.

Было ли бы вам интересно почитать продолжения цикла статей про Squid Proxy?

Similar posts

AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 32

    +3
    А почему MySQL? Почему не ELK?
      0
      Как-то взор пал на протоптанную дорогу MySQL, имел опыт ELK в graylog, надо подумать
      0
      А что мешало сделать несколько табличек в БД, это бы уменьшило в итоге базу и облегчило написание запросов?
      к примеру вынести из access_log данные по src_ip, user, url, method и т.д. в отдельные таблички?
      Просто при большом кол-во пользователей, БД будет долговато строить отчеты
        0
        Честно говоря, оптимизацией базы пока не занимались, пользователей много, но долгих запросов пока не наблюдали, за идею спасибо, учтём :)
        0
        Большое спасибо! Сам задумывался над централизацией хранения (для трёх нод всего). Очень бы хотелось узнать про то какие-нибудь современные средства по анализу логов :) (к вопросу о том, что интересует в Squid)
        Ещё, извините за полный offtop, задам вопрос ко всем присутствующим (с просьбой о помощи): у всех ли корректно basic-авторизация Squid работает в Microsoft Edge (в Windows 8/10)? Наткнулся на эти «грабли» и никак не могу победить. Chrome, Mozilla — все отлично, а MS IE, Edge — ошибка. В качестве «первого хелпера» — Kerberos-авторизация.
          0
          Рад что оказалось полезным :)

          Хм, ntlm + ldap полет нормальный, странно, а в чем именно проблема? что логи говорят? какая версия squid?
            +1
            Не используйте базу в качестве централизированного хранилища для логов, выше уже рекомендовали ELK — это действительно стоящий внимания инструмент. В качестве альтернативы можно предложить Graylog — он мне показался более простым для старта, но менее гибким чем ELK.
            0
            Наверное off-topic, но не поделитесь причиной использования Proxy в ваших офисах?

            NB Я знаю Squid и его плюшки (почти 20 лет занимаюсь, среди прочего, одним из наших проксей). Недавно просматривал его статистику за последних несколько месяцев. Через этот сервер ~3500 пользователей тянут в среднем 2Tb в сутки. Сейчас период отпусков/каникул но выборка все равно достаточно репрезентативная. Судя по логам, количество эффективно кешируемого трафика тает на глазах (все в криптованных тоннелях). Собственно тенденция просматривается давно откуда решение убирать прокси. У вас все видимо не так. Мне интересно в чем ваша специфика…
              0
              Фактически давно отказались от cache функционала — не имеет смысла, поэтому основном назначение распередление доступов в зависимости от AD групп
                0
                а можно конфиг в личку? интереса для. что для фильтрации squidguard? а как https фильтруется?
                  0
                  увы, слишком многое нужно маскировать в конфигах :) ну собственно, никакого космического корабля )
                0
                Как вариант могу предположить, что скоро трафик опять подорожает. Тогда кеширование сможет помочь (но только если кешировать через MITM https трафик. Как раз для корпоративных пользователей внедрение корневого сертификата не представляет проблемы.
                  0
                  Не знаю как в ваших краях а у нас линии и так не дешевые. Стоимость гигабитной линии для организаций (уточнение целевого уровня доступности: с резервированием, 2+ аплинка, и т. д.) исчисляется в десятках тысяч евро в год. 10Gb уже сотни тысяч. Но цены помаленьку падают. С другой стороны цены для SOHO раз в 100-150 ниже — вполне могут и вырасти. Тем не менее не думаю что это экономически оправдает прокси…

                  PS MITM: мне лично сильно не нравятся подобные решения. Все что ухудшает безопасность — плохое решение за которое, рано или поздно, приходиться платить…
                0
                acl dontLog http_status 403 407 — опциональная строка, убирает ошибки из лога

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

                Сразу же пришла в голову «уязвимость»:
                инсайдер может сливать данные на свой веб-сервер, принимающий файл и отдающий ошибку :)
                Как вариант — логировать это в текстовый файл, с анализом аномалий (резкое увеличение размера файла, большой размер запроса/ответа)
                  0
                  да, именно поэтому оставил параллельно логирование в локальные файлы, ибо бывает нужен дебаг, ну и не мешает периодически поглядывать в аксес логи, бывали случаи high cpu из-за chrome request > clients*.google.com
                  +1
                  Что будет если сервак с Mysql приляжет от того что места в /var/lib/mysql закончилось?
                  Где настройка хотя бы одно слейва?
                  Будьте готовы резать БД каждый месяц
                    0
                    Для этого есть Zabbix который мониторит и базу и место в /var/lib/mysql

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

                      В целом больше нужен репортинг, выше предложи ELK — возможно будем думать в эту сторону
                      0
                      Даешь веб фронтенд!
                        0
                        скоро, в разработке :)
                        0
                        И это в 21 веке?
                        практичнее использовать rsyslog + graylog.
                        Доставка логов будет за минимальное время, нагрузка на сервис минимальна и что-то искать значительно проще.
                          0
                          Испрользовал эту связку для логирования серверов и нетворк оборудывания, graylog понравился — удобно, конекторы, grok и тд, но были существенные проблемы с производительностью — поэтому с jvm как-то связываться не хотелось, да и иногда велосипед интереснее :)
                            0
                            Для jvm нужно помощнее железо и побольше памяти, у себя в легкую просасываем 500 сообщений в секунду.
                            Никаких проблем с доезжаем логов или производительностью нет.
                          0
                          Мне казалось, хранить логи в БД — не самый лучший вариант. Почему не использовать какое-нибудь специфическое решение. Например, influxdb или graphit с последующим натягиванием какой-нибудь grafana?

                          На какой объем логов вы рассчитываете?
                            0
                            Пока что замеряю количество логов, за 3 дня 750 мб — что не критично, дальше будет видно
                              0
                              з.ы. 403/407 не учитываются, поэтому складируется «чистые» логи для репортинга
                              0
                              Против influxdb основной аргумент — кластеризация там за деньги.
                                0
                                или там за деньги, или в mysql шаридинг вручную и неизвестно, что «дешевле» :)
                                но при таких объемах можно и правда не дергаться… 80Гиг за год — это не много…
                                  0
                                  retention таких данных много меньше чем год, так что беспокоиться особо не за что :)
                                    0
                                    Есть куча всего кроме mysql. Я конечно не веду к тому, что продукт не имеет права требовать деньги.
                                0

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

                                Only users with full accounts can post comments. Log in, please.