какие системы используются для прикладного мониторинга в банке

Компания “ИнтерТраст” внедрила в ВТБ решение прикладного мониторинга системы документационного обеспечения на основе стека открытых технологий

Разработанная система централизованного мониторинга для прикладного администратора системы документационного обеспечения (СДО) банка ВТБ позволила реализовать режим проактивного реагирования на инциденты, повысить прозрачность работы системы, а также существенно снизить риски администраторов.

Система CompanyMedia используется в банке ВТБ с 2005 года. В настоящий момент в системе документационного обеспечения банка (СДО), построенной на базе CompanyMedia, работает более 60 000 пользователей, система поддерживает большой документопоток — ежемесячно по делопроизводству создается более 1 000 000 документов, одновременно в системе работают в секунду происходит При этом банком предъявляются высокие требования к отказоустойчивости системы в каждом ее компоненте. Для бесперебойной работы системы развернута отказоустойчивая инфраструктура для задач взаимодействия пользователей с системой с применением серверов проксирования, балансировки запросов, защиты информации, полнотекстового поиска, интеграционных маршрутов, бэкапирования и пр.

Проект такого масштаба требует больших ресурсов для поддержки и администрирования системы, как со стороны компании «ИнтерТраст», так и со стороны банка. Администраторам необходимо отслеживать не только базовую информацию о работе серверов (такую как, например, потребление ресурсов оперативной памяти и процессорного времени), но и проводить более тонкую аналитику: сколько времени тратится на выполнение бизнес сценариев, какова динамика производительности системы и профиль нагрузки, есть ли заметные отклонения в каком-либо компоненте системы от утвержденных нефункциональных требований и т. д. На все это накладывается аспект географической распределенности пользователей, работающих в системе: от Петропаловска-Камчатского до Калининграда, и, фактически, работы в режиме доступности системы 24 часа в сутки.

В такой ситуации вопрос проактивного реагирования на различного рода ошибки встает очень остро. Специалисты компании «ИнтерТраст» совместно с ДИТ ВТБ пришли к выводу о необходимости создания центральных мониторов и консоли жизнедеятельности системы, которые позволяют следить в режиме реального времени за нужными параметрами инфраструктуры и своевременно выявлять проблемы в функционировании системы. Для решения этих задач была создана система прикладного мониторинга, которая перед внедрением в банке ВТБ была развернута и протестирована в рамках инфраструктуры компании «ИнтерТраст».

Реализованная специалистами «ИнтерТраст» централизованная система прикладного мониторинга СДО базируется на СПО продуктах и включает в себя две подсистемы. Одна выполняет задачи мониторинга ИТ-инфраструктуры сервисов системы, другая осуществляет мониторинг возникновения ошибок в работе СДО.

Централизованная система прикладного мониторинга позволила кардинально оптимизировать время реакции на возникающие инциденты, классификацию проблем и как следствие повысить качество обслуживания. Большинство ошибок и проблем в работе СДО администраторы могут решать превентивно, благодаря такому комплексу мониторинга.

Система прикладного мониторинга ИТ-инфраструктуры использует два компонента: СПО подсистему Zabbix и визуализатор Grafana. Zabbix запускает своих агентов на каждом сервере и собирает данные по интересующим метрикам в режиме реального времени в единую базу данных. Подсистема Grafana предоставляет возможности анализа этих данных, выводя необходимую для оперативного анализа информацию на единый экран (дашборд), представляя данные в виде удобных для анализа графиков и схем.

Визуализатор позволяет администратору настроить под себя те срезы и графики, которые ему нужны и удобны.

Интерфейс Grafana интерактивный, фактически это очень похоже на OLAP-систему.

Источник

Лекция 11. Тема: Программное обеспечение банковских систем

Тема: Программное обеспечение банковских систем.

Пакеты прикладных программ банковских систем.

1. Автоматизированная система банка.

2. Программное обеспечение автоматизированной системы банка.

3. Основные положения построения программного обеспечения банка.

4. Необходимость и цель создания системы

5. Принципы построения единой прикладной программной системы (ЭППС) банка.

7. Этапы создания ЭППС. Система антивирусной защиты.

8. Системы пакета прикладных программ банка.

Банковская система, автоматизированная система, аппаратное обеспечение, программное обеспечение, прикладные программы, ядро программы, база данных, справочники, надежность программ, функциональная подсистема, серверы, рабочие станции, межбанковская электронная почта, безопасность программ, контроль прав, антивирусная защита.

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

Системы можно разделить по следующим видам:

· финансовые и платежно-расчетные системы;

· внутрибанковские информационные и управленческие системы;

· межбанковские информационные и управленческие системы;

· специализированное стандартное программное обеспечение.

Единая автоматизированная система банка состоит из трех основных составляющих:

· программное обеспечение системы;

· аппаратное обеспечение системы;

· сетевое обеспечение систем.

Программное обеспечение автоматизированной банковской системы состоит из программных систем и пакетов, которые используются в банках.

Программное обеспечение состоит из следующих частей:

· прикладная программная система, осуществляющая функциональные прикладные задачи банка;

· стандартные программы, обеспечивающие необходимую программную среду для работы прикладных программных систем, использующиеся в качестве инструментов для разработки этих систем, администрирования компьютерного и коммуникационного оборудования;

· системы управления базами данных, обеспечивающие сохранение, сортировку и эффективное представление данных программных систем и данных, используемых пользователями.

Аппаратное обеспечение– это техническое оборудование, которое используется в банковских системах и на котором приводится в действие и используется программное обеспечение. Аппаратное обеспечение состоит из следующих основных частей:

· иные устройства, обеспечивающие вход, выход и сохранение информации.

Основные положения построения программного обеспечения

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

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

На рис. 1 показаны принципы построения системы.

Рис. 1. Принципы построения системы.

Гибридными называются те системы, где задачи осуществляются как посредством крупных систем, объединенных по группам подлежащих разрешению задач, так и посредством отдельных систем. В этом случае при построении их используются единые и идентичные системы.

От принципа построения системы зависит ряд характеристик, таких как, в частности, гибкость системы, её стабильность, безопасность, возможности развития.

Указанным характеристикам в максимальной степени удовлетворяет централизованная система, а в минимальной степени – децентрализованная. Гибридная система рассматривается как переходный вариант от децентрализованной системы к централизованной.

Основными этапами построения централизованной системы являются:

· развитие действующих систем на основе принципа применения единых технологий и систем управления базами данных.

· разработка структуры единой прикладной программной системыи принципов её применения, в том числе внедрение общих принципов организации администрирования и контроля системы;

· формирование ядра единой прикладной программной системы;

· применение единой системы управления базами данных;

· разработка и применение баз данных;

· разработка и применение единых стандартов обмена информацией;

· переработка уже созданных и действующих систем согласно разработанным принципам.

Единая прикладная программная система (ЕППС)

Необходимость создания единой прикладной программной системы (ЕППС) банка обусловливается следующими обстоятельствами:

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

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

· есть проблемы, связанные с применением старых программных продуктов на новых операционных системах и технических средствах;

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

· усложняется получение данных, источниками которых являются различные системы.

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

Создание ЕППС позволит:

· автоматизировать деятельность банка во всех областях на основе единых принципов;

· обеспечить централизованное сохранение данных в одной или нескольких взаимосвязанных базах, управление которыми будет осуществляться из одной и той же системы управления базами данных;

· исключить противоречивость данных, обеспечить их целостность и осуществлять единое централизованное администрирование системы;

· повысить надежность системы, обеспечить в централизованном порядке архивизацию информации и применение резервных возможностей;

· поднять уровень безопасности системы и оперативное контролирование;

· производить динамическое развитие и расширение системы.

Принципы построения системы ЕППС

Принципы построения ЕППС банка следующие:

· использование одной централизованной базы данных (в одной или нескольких БД);

· использование одной общей системы управления базами данных;

· принцип однократного ввода данных;

· единый принцип формирования отчетов;

· модульная структура (в виде отдельных программных компонентов модулей, дает возможность поэтапной обработки, внедрения и развития системы);

· принцип самостоятельной и совместной работы модулей;

· принцип стандартного интерфейса пользователя;

· принцип межмодульного интерфейса (необходимость стандартизации);

· принцип разграничения прав и функций пользователей;

· принцип контроля и мониторинга;

· принцип соответствия международным стандартам.

Ядро единой прикладной программной системы

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

Рис. 2. Четырехуровневая автоматизированная система.

При проектировании программного обеспечения системы предусматривается использование следующих программных пакетов:

· Borland C ++ Builder – проектирование отдельных функциональных подсистем автоматизированной системы рабочего места пользователя, проектирование описаний сетевых интерфейсов;

· Microsoft Visual Studio. Net – проектирование межсистемных функциональных подсистем, информационных систем на основе WEB-технологии, функциональных подсистем защиты данных, описаний сетевых интерфейсов;

· Seagate Cristal Reports – проектирование форматов отчетов, OLAP систем, прикладного сервера отчетов и WEB сопровождающего прикладного сервера.

Деятельность многоуровневой автоматизированной системы обеспечивается следующими частями в рамках разработки которых необходимо провести следующие работы:

· Система информационной безопасности

· спроектировать систему информационной безопасности, руководствуясь требованиями «системы централизованной безопасности, представления и контроля прав»;

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

· Центр управления ЕППС

· спроектировать центральной операционной центр ЕППС – ядро;

· обеспечить взаимодействие с интерфейсами, используемыми в рамках ЕППС;

· информационный поток центра управления и системы управления данными;

· обеспечить использование технологий дифференциальных расчетов;

· спроектировать и ввести механизмы, обеспечивающие надежность и жизнеспособность ЕППС.

· Центр управления данными

· разработать централизованные базу данных и справочники.

· Функциональные подсистемы ЕППС.

Централизованный база данных и справочники

В настоящее время в банках в прикладных системах используются следующие системы управления банком данных:

· MS SQL Server 2000

В настоящее время в области банка данных и управления данными первостепенное значение придается реляционным системам управления данными. На международном рынке сегодня можно выделить системы управления базами данных MS SQL 2000 и Oracle 10G. Данные обеспечивают среднюю и высокую производительность.

Этапы создания единой прикладной программной системы

Создание и развитие ЕППС осуществляется поэтапно, в следующей очередности:

· моделирование процессов, изучение задач и конкретизация потребностей банка (2006 г.);

· проектирование и разработка систем (2006-2008 гг.);

· тестирование и внедрение (2006-2007гг.);

· эксплуатация и развитие (2006-2007 гг.).

На этапе моделирования процессов, изучения задач и конкретизации потребностей банка проводится следующая работа:

· формирование функциональных задач для автоматизации деятельности банка, определение целесообразности автоматизации;

· изучение функциональных задач;

· изучение информационных потоков.

На этапе проектирования и разработки:

· составление технических заданий, которые включают в себя подробное описание функциональных задач, классификацию информации, объяснение применяемых алгоритмов, описание прикладного интерфейса пользователя;

· выбор операционной системы, технологии внедрения системы и программного языка;

· проектирование, оптимизация баз данных;

· выбор аппаратного обеспечения системы;

· выбор сетевого обеспечения системы;

· выбор и описание общей структуры программной системы и её отдельных модулей;

· программирование отдельных модулей.

На этапе тестирования и внедрения проводятся следующие работы:

· разработка и утверждение сценариев и задач тестирования и отладка программных модулей;

· тестирование и отладка программных модулей;

· соединение модулей и тестирование, отладка всей системы;

· внедрение системы в опытную эксплуатацию;

· внедрение системы в промышленную эксплуатацию.

На этапе эксплуатации и развития проводятся следующие работы:

· изучение задач в целях усовершенствования системы.

Система антивирусной защиты

Система антивирусной защиты банка должна соответствовать следующим принципам:

· размещение и использование единой системы антивирусной защиты;

· использование одной и той же системы антивирусной защиты всеми абонентами сети;

· наличие центра управления, системы управления антивирусной защиты;

· передача в реальном времени в центр управления информации о вирусных происхождениях;

· установка в компьютерах и управление антивирусной системой администратором антивирусной защиты;

· периодические обновление программного обеспечения системы антивирусной защиты.

Контрольные вопросы и задания

1. Из каких основных составляющих состоит единая автоматизированная система банка?

2. Чем отличается прикладная программная система банка от стандартных программ?

3. Какие технические средства включают аппаратное обеспечение банка?

4. Рассмотрите принципы построения информационных систем и приведите структуру.

5. Для чего необходима единая прикладная программная система (ЕППС) банка?

6. Перечислите основные этапы построения ЕППС.

7. Что значит технология дифференцированных расчетов?

8. Какие системы управления банком данных используются в прикладных системах банка?

9. Каким принципам должна соответствовать система антивирусной защиты?

10. Что понимают под надежностью и безопасностью автоматизированной системы банка?

11. Что такое сервер и рабочая станция?

Литература: 4, 10, 11, 13.

Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет

Источник

Как устроен прикладной и бизнес-мониторинг сервисов НСПК

НСПК сегодня – это не просто операционно-клиринговый центр для карточных операций, но и современная технологическая платформа для продвижения и развития платёжных инструментов и сервисов, как на территории России, так и за её пределами. НСПК – это платёжная система «Мир», Система быстрых платежей и обработка внутрироссийских операций по картам международных платёжных систем. Мы обеспечиваем миллиарды транзакций в год при отказоустойчивости и доступности на уровне 99,999%.

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

Меня зовут Липкин Иван, в НСПК я руковожу управлением прикладного мониторинга, и сегодня я хочу поделиться опытом построения прикладного и бизнес-мониторинга, полученным нашей командой за несколько лет развития национальных платёжных сервисов.

Идеология

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

Мы считаем, что мониторинг в представленной модели необходимо выстраивать строго сверху вниз, в первую очередь контролируя ключевые показатели бизнес-функций сервиса.

Разделение сервиса на уровни происходит по принципу отнесения снимаемых с него данных к описанным трём категориям:

Бизнес-слой – данные, отражающие активность и опыт конечного пользователя или конечной точки подключения. По ним формируются количественные и качественные метрики оказания сервиса. Например, если говорить про платежную систему “Мир”, то метриками бизнес-уровня будут объемы успешных или неуспешных авторизационных запросов в единицу времени, их разбивка по конечным точкам подключения, типам операций и т.д. Как правило, метрики этого уровня (как и бизнес-лог) индивидуальны для каждого сервиса, их количество и состав формируются из потребностей в каждом конкретном случае.

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

Инфраструктурный слой – данные о работе приложений и оборудования опорной инфраструктуры. Помимо аппаратного, этот слой имеет собственный прикладной подуровень, так как существует целый пласт приложений, обслуживающих инфраструктуру. Тут так же, как и на уровне выше, применяются техники готовых интеграций систем мониторинга с используемым ПО и автоматизация. Мониторинг инфраструктуры, как отдельную большую тему, в этой статье рассматривать не будем, речь пойдёт исключительно про два верхних уровня.

Требования к системе мониторинга

Мониторинг – это служебный сервис, который не зарабатывает деньги в явном виде. При этом все понимают, что без качественного мониторинга невозможно обеспечить требования по уровню доступности, времени восстановления после сбоев, различные SLA перед партнёрами, рынком, регулятором и т.д. Тут и возникает важная задача – максимально покрыть все потребности в мониторинге бизнес-сервисов, минимизировав при этом расходы на создание такой системы.

Формирование используемого для мониторинга стека приложений зачастую становится довольно непростой задачей. В общем виде можно описать следующие требования, характеризующие систему:

Компактность
Конечно, хотелось бы иметь стек, покрывающий все домены обратной связи с сервисом (метрики, логи, прикладные трассы для профилирования запросов и мониторинга приложений). На рынке существуют десятки разных систем, работающих по каждому домену, но «заводить зоопарк» не хочется никому. С другой стороны, очевидно, что не существует универсальных решений, способных одинаково эффективно работать со всеми видами данных с сервиса.

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

Гибкость
Система должна уметь получать данные от сервисов в разных режимах (push\pull), иметь богатый набор экспортёров данных и встроенные механизмы интеграции с современным ПО. То есть любая поставленная перед мониторингом задача должна решаться максимально быстро и, по возможности, штатными средствами, без долгих интеграционных процессов или разработки.

Открытость
Идеально, если весь используемый стек – это open source. Но тут нужно представить известную картинку с тремя пересекающимися кругами – цена, качество и время. Эта характеристика имеет свои плюсы и минусы, не всегда имеется время и профессиональный ресурс для решения всего спектра задач с использованием открытого ПО. Здесь мы за здравый баланс, но с прицелом на идеал — open source и компетенции его «приготовления».

В настоящее время нам удалось достичь определённой гармонии в совмещении всех этих требований. За последние несколько лет сервис качественно изменялся по форме, содержанию и задачам, но обо всем по порядку.

Хронология развития прикладного стека

В 2015 году, когда всё только начиналось, мониторинг представлял собой всего лишь один элемент – Zabbix, функциональных возможностей которого очень быстро стало не хватать. Во-первых, появилась потребность в централизованном сборе и хранении логов. Во-вторых, возникла необходимость визуализации и контроля качества прикладного авторизационного трафика. Очевидно, что решить такие задачи с помощью одного только Zabbix было невозможно и в инфраструктуру мониторинга добавился стек ELK (Elasticsearch, Logstash, Kibana), который прекрасно решает вопрос с централизованным сбором логов, и Grafana, хорошо справляющаяся с визуализацией данных. В итоге к середине 2016 года в стек уже входит: Zabbix, ELK, Grafana и много Perl-a.

По мере развития сервисов меняются требования и к контролю операционных процессов. В 2016 году описательной аналитики ELK + Grafana становится недостаточно. Возникают задачи по анализу тысяч метрик и не визуально на видео-стенах, а в фоновом режиме системы с использованием статистических анализаторов с динамическими базовыми линиями. Так же необходимо было обеспечить возможности быстрого реагирования на нештатные ситуации и оценки степени их воздействия на бизнес. Возникает потребность в платформе операционной и бизнес-аналитики, в которой можно делать сложные параметризованные отчеты, которыми бы пользовалась дежурная служба, выдавая коммуникацию с подготовленной по инциденту статистикой как внутри компании, так и внешним потребителям (на рынок).

В конце 2017 года мы открываем внутренний проект по выбору платформы операционной аналитики, и в фокусе нашего внимания оказывается Splunk.

В 2018 году Splunk уже внедрён в систему прикладного мониторинга НСПК. На текущий момент он по-прежнему остается аналитическим ядром в стеке, осуществляющим комплексный анализ данных, что позволяет фиксировать даже незначительные случаи деградации в процессах.

Все бы хорошо, но в начале 2019 года Splunk уходит с российского рынка, вынуждая нас искать альтернативу. Такой альтернативой видится ELK++ — привычный нам стек, но с определёнными расширениями (про ++ дальше).

Уход Splunk из России не означает, что им нельзя пользоваться. У нас имеется постоянная лицензия, ограниченная только объёмом индексируемых данных в сутки. Понятно, что со временем это станет проблемой, поэтому у нас имеется стратегия по миграции на альтернативное решение.

Архитектура и прикладной стек

Представленная схема – это упрощённый (сутейный) вариант, фактическая же схема гораздо сложнее. Приложения имеют кластерную архитектуру, все развёрнуто в нескольких дата-центрах и экземпляров системы тоже несколько. Но все сигналы и общий контроль выведены на консоли и видеостены дежурной службы в ситуационных центрах, тем самым глобальная картина по сервисам и их состояниям формируется в едином «центре управления полётами».

Но вернемся к архитектуре. Как видно на схеме, система условно раскладывается на четыре слоя: источники данных, транспорт, хранение\анализ и клиентская часть.

Источники данных и транспорт

Ключевую роль в сборе и транспортировке данных играют компоненты ELK-stack, Zabbix, а также брокер Kafka с клиентской библиотекой обработки потоков Kafka Streaming (очень важно, что это полностью open source). Богатый набор экспортёров данных Beats data shippers и input\output плагинов Logstash покрывает практически весь набор потребностей по снятию данных с объектов мониторинга. Также Logstash выступает в качестве посредника между шиной или конечной аналитической системой и системой алертинга — Zabbix. Таким образом Logstash выполняет функции агрегатора метрик и планировщика запросов в сторонние API, откуда получает результаты сложной аналитики данных (например, из Splunk) для передачи их в Zabbix.

Zabbix, по такому же принципу, использует готовые шаблоны для экспорта метрик с сервиса. Иногда одну и туже задачу можно решить, как средствами ELK, так и Zabbix. В зависимости от ситуации, выбор делается в пользу того или иного приложения в стеке.

Чтобы отдавать в несколько конечных аналитических систем одни и те же данные, в транспортном слое присутствует Apache Kafka. Брокер получает данные как от Logstash, так и через собственные коннекторы Kafka Connect или напрямую от приложений, которые подключаются к Producer API Kafka. Использование единой шины решает ряд проблем. В качестве потребителя можно поставить любое хранилище данных и со стороны транспорта ничего менять не нужно. Получается своего рода стандарт, где любая новая потребность в данных решается просто, используя готовые «рельсы».

На слое транспорта происходит ещё и трансформация данных. Несложные преобразования и обогащения делаются на Logstash — формирование новых вычислительных атрибутов в данных, «приклеивание» справочников и т.д. Более сложные концепции обработки потоков реализуются в Kafka Streaming. Пока у нас имеется только одно приложение, обрабатывающее поток бизнес-лога авторизационных систем, формируя на лету модель данных для мониторинга. Но мы активно работаем в этом направлении, усиливая компетенции в области инженерии данных.

Как отдельное направление мониторинга, но полностью интегрированное в стек, Elastic развивает APM (application performance monitoring — профилирование запросов и мониторинг приложений), который мы пробуем применять под задачи сбора и анализа прикладных трасс. В транспортном слое этот элемент представлен APM-агентом (в нашем случае java) и APM-сервером, в задачи которого входит обработка данных от агентов и подготовка их для передачи в Elasticsearch.

Конечные аналитические системы

Аналитическим ядром системы является Splunk — готовое коробочное решение: база данных, язык взаимодействия с данными и пользовательский интерфейс.

Это очень гибкий и универсальный инструмент, особенностью которого можно назвать сильный высокоуровневый язык SPL (search processing language). Он сочетает в себе возможности SQL и Unix pipeline syntax. На этом языке можно очень быстро писать аналитические запросы к данным, а в сочетании с UI — конструировать сложнейшие параметрические отчёты.

Все настраивается так, чтобы дежурный затратил минимум сил и получил максимум понимания по инциденту. Вот пример панели для расчёта статистики по инциденту на авторизационном сервисе. На панели есть вся необходимая информация о затронутых эквайрерах, эмитентах, платежных системах и т.д. Можно все это фильтровать в зависимости от ситуации и проблемы.

Но действительно важную и сложную аналитическую задачу Splunk решает в фоновом режиме — непрерывное обнаружение аномалий. Постоянно работающие статистические анализаторы выдают сигналы об аномальном поведении метрик контролируемого операционного процесса. В основе лежит алгоритм median absolute deviation, а ключевая особенность подхода заключается в том, что алгоритм в моменте применяется к десяткам тысяч метрик, анализируя многомерные временные ряды.

Есть довольно интересные приемы, когда нужно контролировать не интенсивность сигналов, а окна их отсутствия — мы называем этот подход «определение уровня тишины». В его основе также лежат статистические приемы. По исследуемым метрикам на исторических данных замеряются максимальные окна отсутствия сигналов внутри интересующих нас временных диапазонов (сутки или какие-то их части). Из значений этих окон строится медиана, и дальше мы в режиме реального времени измеряем «уровень тишины». Если он превышает медиану с определенным коэффициентом, то включается триггер. Такие же подходы применяются в разных сервисах НСПК, мы отслеживаем активность участников на предмет получения всего необходимого объёма данных от них к нам и на качество получения этих данных конечными точками подключения.

Еще один пример интересного анализа — это оценка объёма потерь по недополученным данным с использованием алгоритма прогнозирования временного ряда. Представьте ситуацию, когда банк «ломается» и перестает отправлять запросы в НСПК. В этом случае на мониторах видим просадку трафика и нам необходимо оценить количество данных, которое мы недополучаем, чтобы уведомить об этом участника или руководство компании (если речь идёт о крупном игроке рынка). В Splunk есть целое приложение с набором алгоритмов ML (в частности Forecast time series), которые делают прогноз трафика в системе и позволяют определить объем потерь.

Алгоритмы прогнозирования временных рядов также используются в методиках расчёта доступности сервисов. Когда происходит инцидент, то ключевая метрика (или метрики) производительности сервиса начинает деградировать, причем деградации бывают двух видов — полная (Рис.1) или частичная (Рис.2). Очевидно, что считать временем недоступности сервиса весь интервал инцидента при частичной деградации — это неправильно, потому что сервис свою задачу выполнял (в каком-то процентном отношении). Но деградация была и повлияла на определённую часть конечных пользователей. Splunk позволяет очень просто подсчитать область между прогнозом и фактом и сконвертировать это значение во время полной недоступности сервиса.

Описанные выше примеры показывают, как быстро и удобно можно делать сложное в Splunk, но есть с ним и определенные трудности. В паре cо Splunk работает Elasticsearch, который в стратегическом смысле видится как альтернатива, а в тактическом смысле — имеет определенные преимущества перед ним. Ещё он выступает в роли резервной системы, если со Splunk что-то идет не так.

Сначала расскажу про плюсы с точки зрения аналитика и бизнес-заказчика. Сейчас для меня ключевым преимуществом Elasticsearch перед Splunk является то, что он умеет делать обновление документов в индексе. Отсутствие этой возможности в Splunk порождает на практике ряд трудностей. Например, в сервисе 3-D Secure имеется довольно сложный сценарий прохождения аутентификационных запросов. За одной бизнес-транзакцией стоит с десяток событий, предшествующих ей. Чтобы понимать качество оказания сервиса все события не нужны, только последние – те, на которых конечные пользователи перестали взаимодействовать с сервисом. Elasticsearch делает обновление документов в индексе по ключевому полю, что дает на выходе нужный вид данных (последние статусы) и «на порядок» меньший объем хранимых данных, следовательно, быстрее и легче начинают работать статистические выборки. Splunk не «умеет» делать обновления записей, такова идеология решения, все индексируется как отдельные события. Чтобы вернуть только последние статусы, нужно делать дедупликацию событий по ключевому полю с сортировкой по времени, что при значительных RPS (количество запросов в секунду) вычислительно затратно.

Для некоторых сервисов возможность обновления данных крайне важна, и здесь очевидно преимущество Elasticsearch.

Теперь про недостатки. У Elasticsearch нет гибкого аналитического языка взаимодействия с данными, такого как SPL в Splunk. Это ключевая проблема. Elastic предоставляет целую группу языков запросов (DSL, LQS, SQL, EQL), но все это пока очень далеко от возможностей SPL. ELK хорош, как инфраструктура сбора, транспорта и хранения, но мне, как аналитику, нужен язык для работы с данными.

Какое здесь может быть решение? Внешний framework для аналитики. Берем Python pandas и пишем в нём любую сложную обработку, взаимодействуя с Elasticsearch API как с источником данных. Концепция рабочая, но порог вхождения намного выше чем в случае с SPL, нужны другие профессиональные навыки для развития и эксплуатации подобной конструкции.

Когда я писал про альтернативу Splunk, то отметил, что альтернативой будет ELK++, где первый плюс — это аналитика во внешнем framework. Без этого невозможно решать задачи аналогично тому, как мы их решаем в Splunk. Вторым плюсом приставки является подписка — платное расширение функциональности, которое существенно усиливает бесплатный уровень basic. В подписке решаются вопросы ИБ (интеграция с IDM, ролевая модель доступа), alerting, reporting, machine learning, расширенный мониторинг стека и управление pipeline Logstash из Kibana, JDBC\ODBC, cross cluster replication и т.д. Подписка не снимает первого плюса (аналитика во внешнем framework), но при несложных аналитических концепциях (не наш случай) можно обойтись комплектом ELK subscription + BI Tableau.

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

Короткий вывод по слою конечных аналитических систем. Вся самая сложная аналитика делается сейчас в Splunk. Учитывая, что вендор ушел с российского рынка, мы сосредотачиваем усилия на альтернативном решении — ELK++. Почему же ELK, а не что-то другое? Ответ в критерии компактности прикладного стека и задачах: Elastic покрывает все домены обратной связи с сервисом (метрики, логи, прикладные трассы), он легко масштабируется и конфигурируется, имеет богатый набор экспортеров данных и плагинов Logstash, что делает его наиболее универсальным и привлекательным для нас инструментом.

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

К программным интерфейсам относятся Grafana, Kibana, Splunk, Zabbix и Telegram. Splunk и Zabbix для дежурной службы являются основными, Grafana выступает в качестве резерва. Zabbix — центральная консоль событий в системе. Вкладка с триггерами постоянно открыта у каждого дежурного. В Splunk подготовлены все необходимые визуализации для анализа ситуаций по любому сервису, также дается возможность всем линиям работать с данными в режиме ad hoc, так как не всё можно заранее заложить в подготовленные аналитические панели.

Отдельно хочется сказать про маршрутизацию нотификаций в мессенджер, поскольку оказалось, что это очень удобная и эффективная концепция адресной доставки уведомлений по событиям в системе мониторинга и общего управления инцидентами. Как я писал ранее, у нас несколько экземпляров систем мониторинга в закрытых сетевых контурах. Все события, возникающие в Zabbix по разным сервисам, отстреливают уведомления в офисный контур, откуда всё это по средствам скрипта Python маршрутизируется в профильные группы корпмессенджера.

Этот подход сильно сокращает время реакции на инцидент. Было время, когда дежурная служба передавала информацию вручную. Сейчас первая линия контролирует, что все нотификации доходят корректно, отрабатывают инструкции к триггерам (если они определены), отслеживают поведение бизнес-метрик по сервису, занимаются коммуникацией между подразделениями компании, связываются с участниками рынка по инцидентам, эскалируют инциденты на руководство, взаимодействуют с контрагентами по нарушениям SLA и т.д.

Заключение

Хотелось бы закончить статью описанием главных качеств инженера SRE (Site Reliability Engineering). Знакомство с этой концепцией когда-то меня поразило — очень интересная и сильная методология, снимающая абсолютно все барьеры между разработкой и эксплуатацией. В своей работе мы стараемся применять важные и полезные для нас части этой концепции.

«Мониторинг современного программного проекта — это сам по себе программный проект©»

Источник