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

Главная

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

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


посмотреть текст работы


скачать работу можно здесь


полная информация о работе


весь список подобных работ


Нужна помощь с учёбой? Наши эксперты готовы помочь!
Нажимая на кнопку, вы соглашаетесь с
политикой обработки персональных данных

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
Размещено на http://www.allbest.ru/
1. Быстрое развертывание и конфигурация, не требующие построения массивных деревьев здоровья сервиса;
2. Модификация состава и настроек уже существующих командных «мониторов»;
3. Пользовательский интерфейс, который позволит в реальном времени наблюдать состояние сервиса и получать необходимую информацию;
4. Хранение исторических данных работы сервиса мониторинга для сбора статистики и последующего анализа.
Для достижения поставленной цели необходимо выполнить следующие задачи:
1. Изучить существующие алгоритмы и подходы к организации мониторинга систем для применения этих практик в разрабатываемой службе мониторинга;
2. Проанализировать существующие шаблоны проектирования и способы взаимодействия компонентов информационной инфраструктуры;
3. На основе полученного анализа выявить основные компоненты для мониторинга и составить требования к функционалу системы;
4. Разработать архитектуру системы мониторинга;
5. Разработать компоненты системы мониторинга: базу данных и сервис мониторинга;
6. Проверить работу компонентов системы на примере сценариев взаимодействия с системой.
1. Пользователь заводит обращение в системе при помощи специальной онлайн системы, звонка и сообщения;
2. Сотрудник первой линии регистрирует обращение в системе, определяет его тип и конкретный сервис, к которому относится заявка;
3. Сотрудник первой линии выполняет инструкции для данного типа обращения: предоставляет пользователю поддержку самостоятельно или передает (эскалирует) заявку в соответствующую команду на второй линии поддержки;
4. Если заявка была передана сотрудникам второй линии, они могут провести более детальную диагностику и оказать более широкий спектр услуг пользователю. Сотрудники этой линии могут также решать инциденты посредством привлечения сотрудников смежных команд. Под смежными командами понимаются системные администраторы, специалисты (в том числе разработчики) по конкретному программному обеспечению, администраторы платежных систем и т.д.
В больших организациях принято разделение службы технической поддержки на уровни. В основном для Service Desk характерно выделение трех уровней поддержки:
1. Первый уровень . Первый уровень технической поддержки включает в себя диспетчеров, которые занимаются регистрацией запросов в системе и предоставлением поддержки в простых случаях, которые можно покрыть стандартными инструкциями. Для внутренней службы поддержки организации в основном это предоставление доступа к корпоративным системам, настройка рабочего места нового сотрудника, иногда установка ПО. Сотрудники этого уровня поддержки обладают общими знаниями о сервисах компании, поэтому при возникновении сложных задач и запросов они передают их соответствующим специалистам на более высокий уровень. Однако перед передачей заявок инженерам второй линии поддержки сотруднику первого уровня необходимо собрать детальную диагностику у пользователя и всю необходимую информации согласно типу заявки и сервиса.
2. Второй уровень . Сотрудники второго уровня являются специалистами в конкретной системе или продукте и имеют доступ к некоторым её внутренним компонентам, например, базам данных, web API, логам системы и т.д. Для инженеров второй линии поддержки характерно решение усложненных технических задач, требующих проведения более глубокой аналитики. Специалисты второго уровня также имеют определенных инструкций по работе с системой и по выполнении заявок на обслуживание, требующих конфигурации определенных параметров внутри сервиса. Сотрудники второй линии поддержки помогают младшей линии в решении нестандартных обращений и запросов, требующих наличия определенного уровня доступа к элементам информационной инфраструктуры компании и поддерживаемого продукта.
3. Третий уровень . На самом последнем уровне поддержки сотрудники занимаются исследованием наиболее сложных и ранее неизвестных проблем в работе систем, зачастую это специалисты в конкретной технологии. На этом уровне поддержки специалисты могут передавать проблемы в команды разработки программного обеспечения или внешним производителям.
Иногда в структуре технической поддержки выделяют четвертый уровень, который предполагает поддержку сторонних поставщиков (вендоров) физических элементов цифровой инфраструктуры или технологий разработки. В этом случае отношения между внутренней поддержкой и последней линией регулируются на основе договора об уровне услуг (SLA).
В зависимости от особенностей предоставляемого компанией сервиса задачи сотрудников второй и третьей лини могут смешиваться, возможны ситуации, когда определенная команды поддержки не может быть явно отнесена к одному из уровней на основе представленного описания. Поэтому в рамках данной работы предполагается, что сотрудники экспертных линий выполняют (или могут выполнять) следующие задачи:
1. Конфигурация определенных параметров системы для выполнения заявок на обслуживание пользователей;
2. Проведение сетевой диагностики при возникновении инцидентов доступности сервиса;
3. Чтение и модификации данных в БД поддерживаемого приложения;
4. Проведение анализа проблем и исследования логики обработки запросов за счет доступ к Web API поддерживаемого приложения;
5. Анализ логов отдельных компонентов для исследования проблем и сбоев в работе системы;
6. Получение информации из веб интерфейса системы;
7. Предоставление доступа пользователей к участкам системы, если это требует конфигурации настроек безопасности системы;
8. Передача кейсов в команды разработки, если это требует исправления ошибок в программном коде, аппаратной части сервиса или анализа кода приложения;
9. Получение нотификации от администраторов системы о проблемах или сбоях, выявленных при помощи системы автоматизированного мониторинга.
1.3 Ш аблоны проектировани я информационных систем
Качество предоставляемых услуг, в данном случае качество ИТ сервисов, является их неотъемлемым свойством. На сегодняшний день существует достаточно большое количество метрик, которые могут быть использованы для определения качества программного обеспечения. Как уже было отмечено в работе, на рынке информационных технологий все подобные метрики закрепляются в формальном договоре об уровне предоставляемых услуг между поставщиком и заказчиком приложения (системы). Например, в роли этих метрик могут выступать время загрузки страницы с контентом или количество пользовательских запросов, которые должен обрабатывать сервер за определенный временной интервал. Все эти аспекты должны быть учтены при проектировании информационной системы.
В частности, перед архитектором сервиса и командой разработки стоит задача достичь максимальных показателей таких измерений, как масштабируемость, доступность и производительность.
Под масштабируемостью понимается способность системы выдерживать пиковые нагрузки без потери эффективности. Компания-заказчик планирует увеличить штат сотрудников в несколько раз: это приведет к росту количества пользователей и, соответственно, увеличит количество запросов к сервису. Бизнес проводит масштабную маркетинговую акцию по продаже продукции, что повлечет за собой резкое увеличение числа клиентов, желающих приобрести товары онлайн. В обоих случаях система должна иметь способность расширяться до определенного числа пользователей или выдерживать нагрузку на самом её пике, иначе это находит своё прямое отражение в прибыли компании и производительности её бизнес-процессов. Однако это не говорит о том, что при увеличении масштаба системы приходится прибегать к пересмотру SLA. Как правило, такие нагрузки должны быть учтены заранее и значения метрик приводятся в виде диапазонов значений при различных условиях.
Доступность - это способность системы быть постоянно доступной конечным пользователям без потери основных функций. Важно донести до заказчика, что невозможно обеспечить стопроцентную доступность сервисов.
Выделяют два основных вида причин «бездействия» системы: плановые и внеплановые. Например, на этапе внедрения система может поставляться отдельными компонентами, при этом необходимо начать обучение пользователей заранее и поэтапно. В момент поставки новой функциональности может появиться необходимость в плановом отключении тех компонентов, что уже были предоставлены заказчику ранее. К плановым остановкам работы системы можно также отнести исправление ошибок в предыдущих поставках, которые были выявлены конечными пользователями или тестировщиками, обновление программного обеспечения или профилактические работы. К внеплановым перебоям относятся проблемы с сетевым обеспечением, оборудованием, инциденты безопасности, сбои в приложениях и программном обеспечении, а также природные катастрофы. Все перечисленные риски и аспекты учитываются бизнесом при планировании доступности системы, составлении требований, определении критичных процессов, транзакций и функций. На этом этапе планирования составляются схемы отката, архивирования и бэкапирования данных. Ранее было отмечено, что метрики в формальном договоре - это, как правило, диапазоны значений. Для компонентов системы, сбои в которых могут оказывать наибольшее влияние на бизнес и стратегию, значения этих метрик могут быть более узкими и жесткими.
Отдельную роль в проектировании занимает оптимизация производительности, в особенности, если речь идет о веб приложениях. Скорость обслуживания пользователей посредством информационных ресурсов крайне важна для бизнеса. На сегодняшний день требования к времени обработки пользовательских запросов крайне высокие. Чем быстрее у клиента загружается страница, обрабатывается транзакция, выполняется поисковой запрос, тем больше конкурентное преимущество компании. Это напрямую влияет на впечатление пользователя от использования сервиса и удовлетворенность качеством, повышает вероятность того, что он снова вернется на этот ресурс или приобретет на нем товар (если речь идет о торговой онлайн площадке).
Для решения задач по обеспечению доступности, масштабируемости и оптимизации производительности существует достаточно большое количество подходов к организации взаимодействия компонентов как между собой внутри системы, так и с внешними сервисами и интерфейсами. Для последующего использования в построении универсальной модели системы мониторинга необходимо рассмотреть несколько наиболее распространенных шаблонов (моделей). Выбор именно этих решений напрямую связан с функциями и задачами, которые находятся в компетенции инженеров поддержки, которые были рассмотрены в предыдущем разделе.
В современной среде разработки пользовательских сервисов и приложений перед специалистами в основном стоит задача написания объектно-ориентированного кода и создания такой архитектуры. Множество современных технологий, платформ и языков программирования построены именно на принципах ООП. В первую очередь такой подход позволяет масштабировать системы, а также в большинстве случаев упрощает анализ кода и процедуры пополнения функциональности сервиса, кроме того такие системы являются более производительными и эффективными. Одним из основных аспектов ООП является разделение системы на части и назначение функционального наполнения каждой из них, то есть ответ на вопросы «что?» и «для чего?». За более чем сорокалетнюю историю технологии было разработано множество готовых решений наиболее распространенных задач, которые возникают перед разработчиками. Для моделирования и определения функциональности службы мониторинга необходимо рассмотреть следующие шаблоны проектирования:
1) Подписчик-издатель ( pub - sub pattern )
a) Описание: шаблон проектирования, при котором компоненты взаимодействуют между собой посредством передачи сообщений через шину. Этот шаблон является примером реализации параллельной обработки запроса от клиента несколькими системами.
b) Принцип работы: в системе выделяются «издатель» (publisher) и «подписчик» (subscriber). Издатель публикует сообщения в виртуальные очереди или разделы. Сообщения делятся на классы. Подписчики забирают сообщения из одного или нескольких разделов и обрабатывают их.
c) Реализация в службе мониторинга: чаще всего такой подход подразумевает использование готовых шин (интеграторов) между подписчиками и издателями. Примером такого решения является технология компании Microsoft - Azure Service Bus. Отправители и подписчики могут обмениваться информацией, как посредством очередей, так и при помощи разделов. Необработанные сообщения помещаются в специальную очередь - Dead-Letter Queue. Служба мониторинга получает количество сообщений и их класс из этой очереди.
a) Описание: шаблон проектирования, для которого характерно наличие интерфейса более высокого уровня для обеспечения доступа к подсистемам. При помощи такой архитектуры от пользователя скрыта сложность реализации подсистем. Фасад обеспечивает возможность упрощенного доступа к функционалу сервиса через единый интерфейс.
b) Принцип работы: клиент осуществляет работу с системой через Фасад, который выполняет передачу запроса нужному компоненту в подсистемах. В случае если необходимо обеспечить работу между несколькими системами, выделяется класс «обертка» для основной системы. При помощи этого класса другие системы могут взаимодействовать с компонентами основной без доступа к ее внутренней архитектуре.
c) Реализация в службе мониторинга: взаимодействие с системой может осуществляться при помощи очереди событий или отправки SOAP запросов к сервису. Мониторинг может осуществляться за счет проверки количества и типов событий в очередях в БД. Также возможна генерация SOAP запросов, отправка их на сервис и проверка возвращаемого значения или кода ошибки.
a) Описание: шаблон Adapter, как и Faзade, предполагает создание «обертки» для подсистем с целью обеспечения доступа к их компонентам. Основное отличие между этими шаблонами заключается в том, что Adapter не предусматривает создание нового интерфейса, а лишь преобразование существующего к необходимому виду. Этот шаблон применяется в случае, если нет возможности повторно использовать ранее созданный код.
b) Принцип работы: между существующим пользовательским интерфейсом и некоторым классом, реализующем необходимые функции, вводится класс-«обертка» (адаптер). Класс-адаптер реализует пользовательский интерфейс и в него добавляется ссылка на экземпляр функционального класса. Адаптер отвечает за перенаправление пользовательских запросов в функциональный класс.
c) Реализация в службе мониторинга: интерфейс может обмениваться информацией с адаптером при помощи SOAP запросов. В этом случае также возможна генерация SOAP запросов, отправка их на сервис и проверка возвращаемого значения или кода ошибки.
4) Push и Pull модель (push and pull patterns)
a) Описание: наиболее распространенные модели взаимодействия пользователя с сервисом. При использовании pull-модели пользователь самостоятельно опрашивает сервис и получает от него ответ. При использовании push-модели сервис обрабатывает события и уведомляет клиента об изменениях без пользовательского запроса.
i) Pull -модель . Клиент отправляет запрос на сервер. Сервер обрабатывает сообщение и возвращает синхронный ответ.
ii) Push -модель . Сервис самостоятельно уведомляет клиента об изменениях на заданном адресе. Это позволяет снизить частоту клиентских запросов, но отличается сложностью реализации из-за асинхронности событий.
c) Реализация в службе мониторинга: при реализации шаблона Push изменения могут фиксироваться на уровне базы данных сервиса. Сервис создает запись с изменением статуса события и задачу на его отправку. Отдельный модуль отвечает за сбор этих задач и нотификацию пользователей. Служба мониторинга может собирать данные об очереди задач в базе данных и их статусе. За счет этого инженеры смогут выявлять сбои в работе сборщика задач.
5) Распределение нагрузки на систему ( workload distribution )
a) Описание: для высоко нагруженных систем часто применяется паттерн распределения нагрузки. Реализация архитектурного шаблона заключается в использовании балансировщиков нагрузки (balancers) и переносе задач на отдельные компоненты систем.
b) Принцип работы: балансеры распределяют пользовательские запросы между виртуальными компонентами или зеркалами баз данных, тем самым позволяя системе обрабатывать большее количество событий. Другим важным моментом является выявление отдельных функций и задач, которые система может обрабатывать в определенные интервалы времени. Для этого в системе можно настроить расписания и автоматизировать выполнение задачи по нему - настроить задания (jobs).
c) Реализация в службе мониторинга: служба мониторинга может проверять работоспособность и доступность отдельных заданий за счет получения даты последнего успешно обработанного события и сравнения с расписанием в задании.
6) Сервисно-ориентированная архитектура ( SOA )
a) Описание: в основе сервисно-ориентированной архитектуры лежит набор компонентов, которые осуществляют взаимодействие при помощи стандартизированных протоколов. Чаще всего такой подход используется для реализации веб-сервисов.
b) Принцип работы: основными составляющими в SOA являются пользователь, поставщик и реестр сервисов. Пользователь обращается в реестр при помощи запроса - SOAP, HTTP, WSDL и т.д. Реестр обрабатывает запрос на основе соглашения об интерфейсе и перенаправляет его к нужному компоненту сервиса. Сервис обрабатывает событие и передает ответ обратно в реестр. Реестр возвращает пользователю результат обработки его сообщения. Поставщик отвечает за поддержку веб интерфейсов сервисов для интеграции и регистрацию сервиса в реестре.
c) Реализация в службе мониторинга: служба мониторинга может направлять запросы на основе различных протоколов к реестру и сравнивать полученный ответ с ожидаемым результатом.
Большинство шаблонов разработки предполагают использование очередей событий и, для веб сервисов, обмен сообщениями на основе таких протоколов, как SOAP, HTTP и WSDL. Это говорит о необходимости реализации в службе мониторинга возможности выполнять SQL запросы на серверах и анализировать полученный набор данных, а также отправлять запросы на основе перечисленных протоколов на веб ресурсы с последующим извлечением результата из полученного ответа.
Для анализа запросов и ответов службе мониторинга необходимо уметь работать с XML дейтаграммами. Так как в большинстве случаев разработчики стремятся увеличить производительность системы и скорость обработки событий, при возможности все чаще используется формат JSON. Это говорит о необходимости извлекать данные из запросов также и в таком формате.
1.4 Уровни системы мониторинга информационной инфраструктуры
В своей книге «Проектирование высокопроизводительных, масштабируемых и доступных бизнес Web приложений» Кумар Ш. («Architecting High Performing, Scalable and Available Enterprise Web Applications», 2015) приводит рекомендации по проектированию системы мониторинга, в основе которой лежат наиболее распространенные практики и подходы к обеспечению доступности и производительности систем. Автор акцентирует внимание на том, что часто один и тот же паттерн может одновременно применяться для обеспечения производительности, доступности и масштабируемости веб приложения. Например, при использовании подхода «распределенной нагрузки» и внедрении «балансировщиков» нагрузки (balancers) архитектор сервиса решает задачу повышения производительности и уровня доступности при обработке запросов. При выходе из строя какого-либо из компонентов, пользователи могут быть временно переключены на работу с одним из доступных компонентов без потери основного функционала системы и нарушения бизнес-процессов.
Представленная в книге модель системы мониторинга разделена на два уровня: мониторинг внутренних систем и служб и мониторинг с внешней стороны (со стороны пользователя). Мониторинг внутренних систем направлен на проверку состояние физических компонентов, баз данных, служб и исполнение метрик SLA на уровне баз данных и загрузки компонентов приложения, в то время как мониторинг с внешней стороны предполагает анализ исполнения метрик производительности и доступности сервиса со стороны конечных пользователей в режиме реального времени.
На этапе внутреннего анализа система мониторинга может посылать запросы веб-приложению, серверу или базе данных и анализировать полученный ответ. Например, любой HTTP-response код, отличный от 200, может стать сигналом о наличии ошибок в приложении и сбоях. Также пользователи системы мониторинга могут следить за использованием памяти серверами, базами данных и веб приложениями, и, в случае превышения порогового значения, получать нотификацию. Уведомления системы, отчеты о производительности сервисов и отложенные задания (scheduled jobs) являются неотъемлемыми компонентами службы мониторинга на внутреннем уровне, так как предоставляют пользователям возможность интегрировать её с процессами конкретной организации или команды.
Для мониторинга компонентов со стороны инженеров поддержки конкретного приложения необходимо также рассмотреть такие функции службы, как мониторинг исполнения метрик SLA в режиме реального времени и анализ логов систем. В мониторинге исполнения метрик SLA выделяется два направления: уровень представления приложения клиентам и уровень выполнения бизнес функций. На первом уровне пользователь системы имеет возможность анализировать производительность приложения при загрузке отдельных веб страниц сервиса, на втором - выполнять конкретный запрос к сервису или базе данных и измерять время обработки. При анализе файлов для логирования событий систем может осуществляться поиск конкретной записи, наличие которой говорит о потенциальных сбоях в работе системы.
Мониторинг внешней производительности системы должен быть наиболее тщательно проработан, так как наличие ошибок на этом уровне проверки говорит о том, что сбои в системе оказывают непосредственно влияния на конечных пользователей и невозможности предоставить ИТ услугу в требуемом качестве. Для организации этого уровня мониторинга могут использоваться различные готовые решения и инструменты:
1. Google analytics для анализа времени загрузки страницы, ответа страницы и проходящего через сервис трафика;
2. Инструменты мониторинга производительности приложения ( Application Performance Monitoring , APM ), которые построены на базе географически распределённых ботов мониторинга;
3. Инструменты real - user monitoring (RUM), основанные на подходе пассивного мониторинга системы.
На сегодняшний день выделяют две основных группы методов мониторинга трафика в сети: активные и пассивные. При активном мониторинге происходит анализ передачи пакетов, пропускной способности канала обмена данными и маршрутов, по которым идут пакеты, между двумя точками. Активные методы применяют такие утилиты сетевой диагностики, как ping, tracert и iperf. Пассивные методы напротив анализируют информацию об одной точке в сети, перехватывая идущие по каналу пакеты, и не создают дополнительную нагрузку и трафик к тем, что уже есть в сети. Они занимаются сбором информации о времени между прохождением пакетов, трафике, количестве переданных битов и протоколах передачи данных. Обе группы методов в отдельности имеют ряд существенных недостатков. Например, активные методы создают лишнюю нагрузку и трафик в сети, не всегда можно гарантировать точность таких измерений, в то время как пассивные методы могут производить только оффлайн анализ собранных измерений и не имеют инструментов эффективного анализа больших данных. Именно по этой причине на практике чаще всего применяются комбинации описанных методов.
Возвращаясь к перечисленным инструментам внешнего мониторинга, стоит отметить, что RUM решения являются наиболее распространенными на сегодняшний день, так как имеют достаточно большой набор доступного функционала. Они позволяют анализировать использование и трафик веб страниц приложения, получать статистику производительности и выявлять основные тренды загрузки сервиса, собирать статистические данные по географическим регионам, для различных браузеров и устройств, измерять скорость загрузки медиа контента системы (изображения, видео и звук), а также ошибки при загрузке страниц и JavaScript'ов.
Однако из всего перечисленного функционала в своей работе инженеры технической поддержки чаще сталкиваются с задачами осуществления сетевой диагностики и недоступности страниц и их контента. Утилиты сетевой диагностики, перечисленные для активных методов, удобнее использовать из командной строки Windows, а не стороннего интерфейса, для анализа пакетов в сети также существуют удобные готовые решения (например, wireshark). Для автоматизации получения данных по доступности веб страниц реализуемая система мониторинга должна уметь отправлять HTTP запросы к веб станицам и анализировать полученный ответ, распознавать ошибки при загрузке JavaScript'ов и уведомлять об этом пользователей службы в интерфейсе.
Современные системы автоматизированного мониторинга такие, как Nagios, могут формировать выходные данные по конкретному участку мониторинга и публиковать результаты в виде XML дейтаграмм в файлы на файловом ресурсе. Служба мониторинга должна реализовывать функционал считывания данных из XML и JSON файлов по заданным параметрам и анализировать полученные значения атрибутов и элементов. За счет этого пользователи службы мониторинга смогут визуализировать результаты основных систем без необходимости их реализации в собственном инструменте.
Отсюда, функционал службы мониторинга может быть дополнен следующим образом:
1. Измерение времени обработки запроса в базе данных и сравнение с пороговым значением метрики;
2. Измерение времени загрузки веб страницы и сравнение с пороговым значением метрики;
3. Поиск значения в файле с логами приложения и нотификация пользователя о наличии значения в интерфейсе;
4. Отправка HTTP запроса к веб ресурсу и анализ кода ответа веб ресурса;
5. Анализ ошибок при загрузке JavaScript'ов на веб странице приложения;
6. Анализ значений элементов в формате XML и JSON на различных ресурсах для работы с выходными данными основных систем мониторинга.
2.1 Архитектура системы мониторинга
На основе анализа современных подходов к организации мониторинга компонентов информационной инфраструктуры, способов интеграции компонентов систем и задач, решаемых инженерами экспертных линий поддержки можно составить требования к реализуемым типам проверок разрабатываемой системы и их свойствам.
Проверка времени выполнения SQL запроса на сервере
Система выполняет заданный запрос на базе данных MS SQL Server и получает статистические данные о результатах выполнения. В качестве итогового значения система анализирует значение времени выполнения запроса.
В качестве дополнительных параметров могут быть получены другие статистические значения выполнения запроса на сервере. Список таких значений и их ключей описан в статье библиотеки MSDN - « Статистика поставщика для SQL Server » [ URL : https://msdn.microsoft.com/ru-ru/library/7h2ahss8(v=vs.110).aspx].
Проверка итогового значения SQL запроса на сервере
Система выполняет запрос к базе данных MS SQL Server, получает значение параметра из определенного столбца по его имени и анализирует результат. Запрос должен возвращать не более одной строки (значения последующих строк не анализируются).
Для выполнения запроса пользователь указывает имя столбца, значение которого необходимо проанализировать и путь к файлу со скриптом для выполнения. Файл должен храниться на той же машине, с которой запускается инструмент мониторинга.
Запрос пользователя может возвращать несколько столбцов. Для анализа значений дополнительных параметров необходимо указать имена столбцов.
Система загружает данные в формате XML из файла на файловом сервере или локальном компьютере пользователя. В полученной структуре данных выполняется поиск необходимого элемента XML и анализ его значения.
Для поиска элемента в структуре XML пользователь указывает путь в формате XPath и перечисляет namespaces . Необходимо указать явно все namespaces , которые присутствуют в элементах документа на пути к искомому атрибуту .
В качестве дополнительных параметров может выполняться поиск других атрибутов в полученной XML структуре. Для этих атрибутов также требуется указать путь в формате XPath .
Значение атрибута XML с веб страницы
Система загружает данные в формате XML с веб страницы. В полученной структуре данных выполняется поиск необходимого элемента XML и анализ его значения.
Свойства запроса и дополнительные параметры аналогичны категории «Значение атрибута XML из файла».
Система загружает данные в формате JSON из файла на файловом сервере или локальном компьютере пользователя. В полученной структуре данных выполняется поиск необходимого элемента и анализ его значения.
Для поиска элемента в структуре JSON пользователь указывает путь к элементу формате JSONPath .
Маркетинговая составляющая сферы социальных сетей. Описание системы мониторинга запросов потребителей. Общая характеристика систем технической поддержки (Service desk, Help desk). Начальная страничка интерфейса поддержки при возникновении проблемы. дипломная работа [2,5 M], добавлен 25.10.2015
Анализ и сравнение существующих систем тьюторской поддержки. Методологии разработки программного обеспечения. Разработка web-ориентированной системы тьюторской поддержки самостоятельной работы студента. Выбор архитектуры программных средств разработки. курсовая работа [1,1 M], добавлен 05.01.2013
Классификация систем поддержки принятия решений. Сравнительный анализ методик для оценки рисков розничного кредитования. Структура системы поддержки принятия решений, формирование начальной базы знаний. Проектирование базы данных информационной системы. дипломная работа [1,9 M], добавлен 10.07.2017
Значение Информационных технологий. Традиционные проблемы взаимодействия. Принципы организации и возможности автоматизированной Диспетчерской службы. Основные преимущества компьюте
Разработка службы мониторинга для решения проблемы обеспечения экспертных линий поддержки дипломная работа. Программирование, компьютеры и кибернетика.
Сочинение По Картине Брюллова Всадница
Реферат: Биофизик Чижевский и его учение об аэроионах
Реферат по теме Этимология тюркского слова temir "железо"
Реферат: Перевірка виконання прийнятих рішень за наслідками перевірки
Дипломная Работа На Тему Металлический Каркас Склада
Курсовая Работа На Тему Розрахунок Скрубера
Реферат по теме История создания Санкт Петербурга
Реферат: Канада. Скачать бесплатно и без регистрации
Реферат: Культура эпохи Возрождения 4
Реферат: Компоненты тренировочной нагрузки бегуна на средние дистанции. Скачать бесплатно и без регистрации
Контрольная работа по теме Правовое регулирование отношений, связанных с вступлением в брак
Технические Условия Реферат
Қашықтасың Туған Жер Әл Фараби Өлеңі Эссе
Краткое Эссе На Тему Идеальное Государство
Психологические Аспекты Продуктивности Группы Реферат
Сочинение На Тему Вечная Классика 11 Класс
Реферат: Золотая пропорция критерий гармонии и красоты
Тоғызқұмалақ Реферат Қазақша
Сборник Контрольных Работ По Русскому Языку
Учебное пособие: Методические указания к изучению дисциплины и контрольные задания для студентов заочной формы обучения Специальность: 080105 Финансы и кредит
Содержание калькулирования и его роль в управлении производством - Бухгалтерский учет и аудит курсовая работа
Сравнение трудового договора и гражданско-правового - Государство и право реферат
Построение базы данных "Абитуриент" для учебного заведения - Программирование, компьютеры и кибернетика курсовая работа