Некоторое время назад потребовалось предоставлять информацию, на предмет использования интернет на рабочем месте. Вообще, я считаю, что это лишнее. Если люди делают свою работу хорошо, зачем ограничивать им интернет. Тем более что в наше время он совсем не дорог. Однако руководство имеет совсем другое мнение. Заковыка состояла в том, что вся инфраструктура построена на windows, а прокси, соответственно, на linux. Файлы логов опубликованы на этом linux при помощи общей папки. Однако, имеющиеся под linux средства анализа и генерации отчетов никого не устроили по непонятным мне причинам. Вероятно потому, что внешний вид отчетов оставляет желать лучшего. Да и работать c html отчетами не удобно. Другое средство - internet access monitor for squid почему-то вело себя совсем неадекватно. Что, учитывая его стоимость и ограничения, совсем не хорошо. Например, поставить его можно только на одно рабочее место. То есть, если несколько человек хотят посмотреть отчеты и при этом, при необходимости, детализировать их там где надо, возникает проблема. Отчеты можно генерировать по расписанию, и рассылать почтой, но вот нужного функционала нет. Мало того, при быстром разрастании базы отчеты строятся “тыщщу лет”. В общем – никакой стабильности.
Поколебамшись, я решил накрутить что-нибудь сам. Идея была в том, чтобы втянуть логи, как есть, в MS SQL Server, и потом обрабатывать их. И вот тут то и появилась первая проблема. Логи формата по-умолчанию, никак не хотели втягиваться стандартным визардом импорта. Верней, втягиваться то они втягивались. Но визард, разбирал их не совсем корректно. А все потому, что отформатированы они, мягко говоря, через одно место. То есть, человеку их, конечно, удобно читать. А вот разобрать их на столбцы простыми кликами мышки оказалось сложнее. В итоге, я решил использовать для этой цели powershell. Дай, думаю, я удалю лишние пробелы, авось втянется. Однако и тут, облом подкрался незаметно… Время обработки одного 300мб файла переваливало за 11 мин. Меня такая ситуация не устраивала в корне.
В общем, поборовшись, какое-то время за скорость я решил вернуться к более традиционным средствам LogParser. Оказалось, что эта утилита умеет не только исполнять простые запросы на sql подобном языке к файлам различных форматов. Она умеет еще кучу всего всякого разного, включая преобразование форматов и запись в таблицы SQL Server. Последнее его свойство я и решил попробовать использовать. Оставалась только одна задача. Поле даты в этих журналах хранится в формате unix timestamp. Соответственно его нужно преобразовать к подходящему формату. И тут на помощь снова приходит logparser. Он подерживает некий набор функций, по работе с данными входных файлов. В общем и целом, без долгих разговоров – вот такой вот простой скрипт:
LogParser.exe" -o:sql -server:SQLSERVER -database:weblog -ignoreIdCols:on -createTable:on -i:TSV -iSeparator:space -nSep:1 -headerRow:off "select TO_TIMESTAMP( ADD( TO_INT(field1), TO_INT(TIMESTAMP('1970','yyyy')) ) ) AS field1, field2, field3, field4, field5, field6, field7, field8, field9, field10 into accesslog from \\gateway\squid\access.log.2"
Этот запрос выбирает данные прямо из логов squid и пишет их в базу ms sql. При этом, в случае отсутствия нужной таблицы первый раз, она создается. Единственный эпизод, после создания имеет смысл изменить имена полей таблицы, а так же типы данных полей, хранящих количество переданых байт и затраченое время на bigint. Это стоит сделать для того, чтобы в дальнейшем упростить запросы к базе, поскольку при агрегировании этих данных может случиться переполнение. Этот скрипт можно запускать по расписанию, допустим, каждый день. Запрос на моих объемах и условиях выполняется 5-6 минут. Думаю, процесс можно значительно ускорить, если разбить процедуру на два этапа. Сначала преобразовывать файл лога в более привычный формат, например csv, а затем втягивать его в базу при помощи bcp. Скорее всего можно достичь скорости, где-то в районе от 30 сек до минуты-двух.
Комментариев нет:
Отправить комментарий