Когда система работает не так, как ожидается, или не работает вообще, главный способ понять, что происходит – это проанализировать логи. Логи так же полезны для определения показателей работы системы. В этой статье описан один из вариантов анализа и организации системы логирования, используемой в системе принятия кредитного решения на базе SAS RTDM.
При работе с ПО SAS RTDM используются несколько видов логов – часть из них системные, часть определяется самостоятельно в зависимости от задачи.
1. Системные логи
Формируются службами SAS RTDM в виде текстовых файлов и по умолчанию складируются в папки в \Config\Lev1
Чаще всего используются системные логи (в скобках указаны пути к логам по умолчанию):
- Engine Server (C:\SAS\Config\Lev1\Web\Logs)
- Stored Process Server (C:\SAS\Config\Lev1\SASApp\StoredProcessServer\Logs)
- Object Spawner (C:\SAS\Config\Lev1\ObjectSpawner\Logs)
Этих видов логов обычно хватает чтобы определить причины ошибок, возникающих при работе сервисов задеплоенных на Engine Server и на StoredProcessServer .
Степенью детализации логов можно управлять через их конфиги. Стоит заметить, что выбор уровня детализации – это всегда компромисс между объемом записываемой них информации и негативными эффектами расширения логирования, такими как быстрое заполнение дискового пространства и замедление работы системы (из-за увеличения количества записываемых на жесткий диск данных). Обычно используется уровень TRACE, который логирует только ошибки и предупреждения (warnings). В некоторых случаях иногда временно поднимает его до INFO, например, когда система начинает работать нестандартно, а на уровне TRACE не очевидно, почему так происходит.
Конфиги представлены в виде xml файлов, параметры для управления – в виде тегов. Например, чтобы увеличить детализацию логов для Object Spawner нужно в файле \SASConfig\Lev1\ObjectSpawner\logconfig.xml изменить
<!-- Application message logger -->
<logger name="App">
<level value="Trace"/>
</logger>
на
<!-- Application message logger -->
<logger name="App">
<level value="Info"/>
</logger>
Файлы с логами формируются в разрезе дней. То есть, когда начинается новый день, в название текущего файла добавляется дата, когда в него записывалась информация, и начинается новый файл.
«+»: можно мониторить состояние системы даже без пользовательского логирования
«-»: записи в них недружелюбны к человеку, чтобы что-то в них понять потребуется время.
2. Пользовательские логи
В зависимости от задач формируются разные виды логов и с разной степенью детализации. Как правило все логи формируются в разрезе вызовов конкретных сервисов, и каждый лог можно найти по соответствующему уникальному id вызова сервиса. Это гораздо удобнее, чем искать нужную информацию в огромной простыне текста.
Рассмотрим логирование в базу данных и логирование в текстовые файлы.
2.1. Логирование в базу данных
Для воспроизведения работы системы и для определения ее узких мест делается инсерт в базу данных после завершения работы каждого модуля системы. Таким образом мы можем определить, на каком этапе, например, упала обработка вызова, без поиска информации в системных логах SAS. Логирование времени выполнения каждого этапа в базе данных также используется для определения самых «тяжелых» участков кода и их последующей оптимизации.
«+»: наиболее простой доступ к данному типу логов – через sql-запросы. Построение аналитики или мониторинга на базе этих логов возможно сразу, без дополнительного парсинга, поэтому отсутствует лаг между созданием лога и записью информации из него в БД
«-»: далеко не всю информацию можно записать в БД (например, ошибки подключения к этой БД или синтаксические ошибки SAS-кода)
2.2. Логирование в текстовые файлы
Только в логах sas-кода можно увидеть следующую информацию:
- значения, принимаемые макро-переменными
- код, сгенерированный макросами,
- код запросов, направленных на исполнение в базу данных и т.д.
По умолчанию SAS не записывает свой лог в файл, редирект логов настраивается через процедуру PROC PRINTTO.
Как правило выполняется логирование каждого вызова сервиса в отдельный файл, название которого содержит уникальный id вызова. Если один вызов обрабатывается в несколько потоков, то каждый поток логируется в отдельный файл, чтобы избежать обращение к заблокированному другим потоком файлу логирования.
Пример.
В начале sas-кода:
/*&SAS_LOG_PATH - путь к папке с логами*/
/*&id - идентификатор вызова*/
filename log_file '&SAS_LOG_PATH.\&id..log';
proc printto log=log_file;
run;
В конце sas-кода:
proc printto;
run;
Шаг PROC PRINTTO в конце кода закрывает файл с логом (и тем самым его разблокирует) а также делает обратный редирект лога в местоположение по умолчанию.
«+»: хранится информация о выполнении sas-кода, которую легко зрительно анализировать и использовать для отладки кода и исправления ошибок.
«-»: хранится информация только о sas-коде, так блоки, созданные в SAS Customer Intelligence Studio (CIS), не содержат sas-код и не смогут быть залогированы пользователем в текстовые файлы. Для определения ошибок в блоках CIS-диаграмм нужно использовать системное логирование SAS.
Ни один тип логирования не перекрывается полностью другими типами. Поэтому мы используем их все.
Мониторинг логов
Для оперативного реагирования на появление ошибок можно внедрить мониторинга логов, которую условно делят на две части:
- Парсинг текстовых логов в базу данных
- Оповещение заинтересованных лиц по e-mail о найденных в логах ошибках.
Обычно парсятся как системные, так и пользовательские логи с помощью регулярных выражений. При нахождении в логе ошибки происходит insert в БД с указанием названия файла логов, даты, id вызова (если логи пользовательские) и/или текстом ошибки.
Исполняемый файл (батник) с кодом парсера запускается каждый час с помощью Task Scheduler (мы работаем на ОС Windows Server 2008).
В системе мониторинга указываются типы алертов и список рассылки. Все таблицы с логами проверяются, и если в них обнаружены ошибки (или другие аномалии), то происходит рассылка на заинтересованных лиц, в первую очередь, на поддержку и разработчиков системы.
Таким образом, подобная организация логирования позволяет оперативно выявлять большинство проблем и аномалий в работе SAS RTDM, что критично для системы принятия кредитного решения банка.
