Разработка комплекса анализа ошибок в корпоративных информационных системах (стр. 1 из 2)
Разработка комплекса анализа ошибок в корпоративных информационных системах
А.Ю. Крайнов, А. А. Смагин
Ульяновский государственный университет
Введение
Сопровождение комплекса программных продуктов, функционирующих на отдельно взятом предприятии и составляющих его корпоративную информационную систему (КИС), — один из важнейших процессов управления его инфраструктурой. Неотъемлемой частью процесса сопровождения программного обеспечения (ПО) является сбор и консолидация данных об ошибках, возникающих в процессе его работы.
Источниками данных об ошибках могут быть как пользователи ПО, так и средства мониторинга вычислительных систем. В работе [1] для сопровождения ПО (в том числе для проведения мониторинга и организации обратной связи) был предложен подход на основе программных агентов. В работе [2] указанный подход был применён авторами при создании системы сбора и анализа протоколов, генерируемых ПО.
Целью настоящей работы является разработка концепции и структуры централизованной системы сбора и консолидации данных об ошибках в работе КИС.
Система анализа протоколов
Разработанный макет системы анализа протоколов [2] включает программный агент, систему управления бизнес-правилами и базу прецедентов ошибок (рис. 1). В его функции входит:
сбор программных протоколов;
идентификация ошибок на основе последовательностей записей протокола;
поиск аналогов ошибок в базе прецедентов;
управление обратной связью с пользователем.
Вместе с тем для создания полноценной системы сбора и анализа ошибок как части комплекса сопровождения программного обеспечения необходимо расширить функционал системы за счёт:
расширения средств сбора сведений об ошибках;
расширения адаптационных возможностей системы;
включения функций обеспечения безопасности передаваемых данных;
интеграции с корпоративной базой знаний.
Расширение средств сбора данных об ошибках
Сбор протоколов (англ. logcollection) представляет собой процесс исследования накопления и записей, сформированных программным продуктом, с цельюих последующего анализа и может быть двух видов:
активный: средства сбора интегрированы с подсистемой протоколирования и, как следствие, могут работать в режиме реального времени;
пассивный: средства сбора производят сканирование уже записанных протоколов через определённые интервалы времени.
Несмотря на эффективность активных средств анализа, их применение на практике затруднено из-за различий в языках программирования, использованных для разработки ПО. Для решения этой проблемы можно использовать специализированные средства сбора протоколов, такие как Apache Flume, Lilith, log.io или Log Expert.
Зачастую анализ протоколов не может выявить всех проблем в работе ПО. В этом случае можно воспользоваться средствами мониторинга процесса выполнения приложений.
Рис. 1. Структура системы анализа протоколов
Предметная область, занимающаяся исследованием возможностей и средств наблюдения за выполнением приложений, называется управлением производительностью приложений (англ. Application performance management) [3]. Для сбора дополнительных данных о производительности программ в программной инженерии разработаны следующие методы:
Профилирование (англ. profiling). Это процесс сбора низкоуровневых характеристик выполняемой программы. Обычно применяется на стадии разработки ПО для выявления проблем в производительности. Существует два основных вида профилирования: (а) событийное — основанное на механизмах перехвата событий, встроенных в язык программирования; (б) статистическое — основанное на сканировании контекста выполнения программы через определённые интервалы времени.
Инструментирование (англ. instrumentation). Это процесс анализа производительности программы, происходящий благодаря внедрению в программный код специальных блоков, собирающих данные о процессе её выполнения.
Анализ процесса выполнения (англ. runtime intelligence). Это комплексный процесс исследования статистики использования пользователями одного или нескольких программных продуктов. Связан с областью бизнес-аналитики и, как правило, применяется в корпоративных системах.
Не все перечисленные методы могут быть применены при разработке агента системы сопровождения. При выборе подходящих средств должны быть выполнены следующие условия:
оригинальный программный продукт не должен быть изменён указанными средствами ни на этапе разработки, ни на этапе выполнения;
применение указанных средств не должно приводить к нестабильной работе продукта.
Применение указанных средств не должно приводить к существенному падению производительности рабочей станции.
Полезную информацию о причинах возникшей ошибки может дать также наблюдение за окружением нестабильно работающей программы, например, аппаратными ресурсами, сервисами операционной системы, загрузкой сети. Подобная информация может быть получена при использовании средств мониторинга сетевыхресур- сов (англ. network monitorin gsystems).
Данный класс систем предназначен, в первую очередь, для отслеживания статуса серверов и сетевого оборудования. Большинство систем данного класса поддерживают также мониторинг рабочих станций, включая наблюдение за использованием жёсткого диска, памяти, процессорного времени и т. д. Примерами подобным систем являются Cacti, Nagios, Pandora FMS, Zabbix, Zenoss.
Традиционными средствами сбора описаний ошибок и заявок на модификацию ПО от пользователей являются системы отслеживания ошибок (англ. Bug tracking systems) [4]. Большинство подобных системы не выполняют каких-либо сложных бизнес-процессов, требующих высокой производительности и надёжности, а являются, фактически расширенными веб-интерфейсами к базам данных, хранящим информацию о запросах.
Как следствие, их функциональность практически одинакова; различия могут наблюдаться в следующем:
удобство пользовательского интерфейса;
перечень состояний (этапов обработки) запросов на модификацию;
перечень полей, описывающих запрос на модификацию;
перечень способов добавления запросов на модификацию.
Примерами подобных систем являются Bugzilla, Fossil, Mantis, Redmine, Trac.
Повышение адаптационной способности системы
На эффективность системы анализа ошибок, выражающуюся в сокращении трудозатрат её пользователей и снижении потребляемых аппаратных ресурсов (в первую очередь — пропускной способности сети передачи данных), влияет также возможность системы к адаптации под изменяющиеся условия рабочей среды.
Последовательности событий, приводящие к ошибкам, могут автоматически выявляться на основе методов ассоциации, широко применяющихся в настоящее время для анализа рыночной корзины (англ. market basket analysis) [5, с. 281]. Автоматически созданные таким образом правила далее могут предоставляться пользователю для утверждения.
Полнота и детализированность данных, принимаемых системой анализа ошибок, сильно влияет на качество принимаемых ей решений. Очевидно, отслеживание записей только наивысшего уровня критичности (“ERROR”) не позволит в полной мере применить методы анализа цепочек событий. Включение наблюдения за наименее критичными записями (“TRACE”) сильно увеличит нагрузку на сеть. Решение этой проблемы заключается в создании “толстого клиента”, когда программным агентом будет осуществляться предварительная фильтрация явно бесполезных записей протоколов.
Очевидно также, что это потребует внедрения средств сетевой синхронизации для поддержании в актуальном состоянии локальных баз знаний агентов. В качестве таких средств могут выступить системы управления конфигурацией (англ. configuration management software). Данный класс систем предназначен для автоматизированного управления настройками рабочих станций, серверов и прочих узлов локальной (как правило, корпоративной) сети. Подобные системы могут быть выполнены в 2-х вариантах:
клиент-серверном, где клиентская часть представляет собой агента, периодически обращающегося к серверу за информацией об обновлениях конфигурации;
децентрализованном, где каждый узел может выступать в виде источника конфигурации.
Большинство популярных систем управления конфигурацией являются кроссплатформен- ными. Примерами систем управления конфигурацией являются Chef, Opsi, Puppet, Smart Frog, Spacewalk.
Текстовые сообщения, поступившие через систему обратной связи программного агента или систему отслеживания ошибок, часто содержат важную информацию для идентификации и анализа ошибки. Вместе с тем автоматический анализ сообщений от пользователей, как правило, затруднён по следующим причинам:
пользователь может дать неправильное или неполное описание ошибки;
отчёты об ошибках, выраженные в текстовом виде, сложно классифицировать.
Первая проблема может частично решаться путём фиксации набора полей, которые должен заполнить пользователь, после чего проверять данные на достаточность и корректность.
Для решения второй проблемы могут применяться различные методы интеллектуального анализа текстов (англ. Text mining)[6], в частности, алгоритмы извлечения информации (англ. Information extraction). Применение подобных технологий, однако, требует проведения специальных исследований по предметной области. В то же время для анализа текстовых пояснений к событиям, автоматически сгенерированных программой-источником ошибки, можно использовать более простые подходы, например, извлечение фрагментов с помощью регулярных выражений.
Повышение безопасности
Распределённый характер информационной системы предъявляет усиленные требования к обеспечению безопасности как системы в целом, так и отдельных её компонентов.
Данные, пересылаемые как внутри рабочей станции (при взаимодействии сокетов), так и по сетевым каналам (например, при отправке сообщений JMS), могут содержать конфиденциальные данные. Необходимо предусмотреть средства криптографической защиты этих данных, а также защиты компонентов системы (в первую очередь, программного агента) от перехвата управления.