none
Не получается указать список полей для лога RRS feed

  • Вопрос

  • Решил я давеча немного уменьшить размер лога моего ISA. Конфигурация следующая:

    ISA 2004 Ent на Windows 2003 Ent SP1. Логи складываются в SQL 2005, который стоит на другом сервере Windows 2000 SP4.

    Удалил я из таблицы Webproxylog несколько ненужных мне полей и соответственно отключил их на вкладке "Fields" в "Configure Web Proxy Logging". В результате при первом же обращении к прокси служба Microsoft Firewall останавливается с сообщением о невозможности записи в лог.
    Переключаю лог на W3C формат и вижу, что отключенные мною записи в него не пишутся. Включаю снова SQL logging - не работает. Ладно, добавляю поля обратно - все равно не работает, но уже с сообщением о несоответствии типов полей. Это видимо выдает выражение "insert into ... select from ... " в процедуре sp_batch_insert.
    Пришлось вставлять все поля обратно в нужном порядке. Сейчас все работает по старому, причем те поля, которые у меня отключены на вкладке Fields, исправно пишутся в логи.
    Собственно вопрос. Почему вкладка Fields не работает для логов на SQL? И можно ли как-то задать список полей для записи в лог?

    Кстати, этот эксперимент стоил мне нескольких часов ночного рабочего времени, затраченных на backup, restore, удаление и вставку полей базы размером 30Gb :-(

    5 марта 2007 г. 12:12

Ответы

  • Триггер и хранимамя процедура все же разные вещи. Стандартную лучше не трогать, а привязать свой тригер к своей базе.

    Раз вы сами убедились на тесте, что Fields не работает, то считайте, что это by design

    Замечу еще, что прямое логирование на удаленный SQL сервер, на мой взгляд, не очень удачная схема работы, т.к. в случае проблем с доступом к SQL или проблем с сервером SQL прокси-сервер останавливается. Мое предложение: писать логи локально в текстовые файлы (выбор полей работает и локальные отчеты), а в базу данных логи грузить с помощью, например, Log Parser 2.2 по шедулеру. Все это работает быстро и надежно. К тому же текстовые файлы можно легко просматривать и выполнять в них поиск.

    6 марта 2007 г. 12:17
    Модератор

Все ответы

  • Делайте вставку через insert-триггер  базы данных - в нем можно отсечь все не нужное и выполнить предобработку.
    6 марта 2007 г. 4:14
    Модератор
  • Это понятно. Процедура sp_batch_insert насколько я понял как раз и выполняет роль такого триггера. Кстати, я правильно понимаю, что ISA сам , by design, вызывает эту процедуру при вставке? Потому что это просто SP, она не является триггером.

    Вопрос был в том, почему не работает вкладка Fields. Или это тоже by design?

    6 марта 2007 г. 9:29
  • Триггер и хранимамя процедура все же разные вещи. Стандартную лучше не трогать, а привязать свой тригер к своей базе.

    Раз вы сами убедились на тесте, что Fields не работает, то считайте, что это by design

    Замечу еще, что прямое логирование на удаленный SQL сервер, на мой взгляд, не очень удачная схема работы, т.к. в случае проблем с доступом к SQL или проблем с сервером SQL прокси-сервер останавливается. Мое предложение: писать логи локально в текстовые файлы (выбор полей работает и локальные отчеты), а в базу данных логи грузить с помощью, например, Log Parser 2.2 по шедулеру. Все это работает быстро и надежно. К тому же текстовые файлы можно легко просматривать и выполнять в них поиск.

    6 марта 2007 г. 12:17
    Модератор
  •  sie написано:

    Триггер и хранимамя процедура все же разные вещи. Стандартную лучше не трогать, а привязать свой тригер к своей базе.

    Процедура sp_batch_insert как раз не стандартная. Она создается скриптами из поставки ISA, которые создают таблицы для логов. И создается естественно в базе логов.

     sie написано:

    Замечу еще, что прямое логирование на удаленный SQL сервер, на мой взгляд, не очень удачная схема работы, т.к. в случае проблем с доступом к SQL или проблем с сервером SQL прокси-сервер останавливается. Мое предложение: писать логи локально в текстовые файлы (выбор полей работает и локальные отчеты), а в базу данных логи грузить с помощью, например, Log Parser 2.2 по шедулеру. Все это работает быстро и надежно. К тому же текстовые файлы можно легко просматривать и выполнять в них поиск.

    Насчет LogParser - спасибо, подумаю. Правда, для меня это не столь актуально, т.к. SQL сервер помимо логов ISA выполняет еще несколько, причем очень важных функций. Так что его доступность для моей сети гораздо важнее доступности ISA. Сейчас я просто шедулером раз в 15 минут проверяю, запущена ли служба Firewall, и если нет, запускаю ее. Случаи останова были, но лишь вследствие кратковременной недоступности SQL. Повторный запуск службы решает проблему.

    7 марта 2007 г. 11:27
  • Процедура sp_batch_insert для меня стандартная как раз потому, что создается скриптом из дистрибутива ISA Те, которые идут в составе MS SQL - системные, а написанные мной - пользовательские. Ну мы поняли терминалогию друг друга

    Зачем шедулер?!   Есть прекрасная возможность настройки ISA - Monitoring - Alerts - Configure, которая позволяет выполнять целый ряд действий при остановке сервиса Firewall в том числе его запуск.

    Либо идем в Services - свойства сервиса Microsoft Firewall - Recovery и настраиваем там перезапуск сервиса.

    7 марта 2007 г. 12:46
    Модератор
  • Через services не получится. Я первым делом попробовал так настроить. Recovery отрабатывает при аварийном останове службы, но при недоступности лога ISA останавливается корректно. Кстати, алертом и останавливается. Поэтому recovery не срабатывает.

    Отключать останов службы в алерте я не стал. Мне проще было написать батник

    sc query fwsrv | find /i "running" || net start fwsrv

    всего делов-то

    9 марта 2007 г. 8:26
  • Вот еще в тему http://www.isaserver.org/tutorials/Fix_for_ISA_stall_when_ODBC_data_source_is_unavailable.html

    Если при недоступности SQL сервис Firewall останавливается с алертом "Invalid ODBC log credential", то можно его использовать для периодического перезапуска  сервиса.

    12 марта 2007 г. 7:08
    Модератор