Потребность в аналитике журнала приложений

Одним из самых больших препятствий в восстановлении службы для сбойного приложения является просмотр файлов журнала и определение причин сбоя приложения. Одна из причин популярности таких инструментов, как vi и grep для идентификации сбоев приложений, заключается в том, что многие приложения не следуют четко определенным рекомендациям при записи информации журнала. В большинстве случаев ведение журналов приложений считается чрезмерной нагрузкой для групп разработчиков, и это действие в основном выполняется просто как «галочка в коробке». Разработчикам приложений важно понимать, что они должны предоставлять системным администраторам достаточную информацию, которая позволит быстрее решать проблемы и восстанавливать службы. Простое включение таких пакетов, как log4j и вывод некоторого текста, не очень полезно.

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

Основы аналитики журнала приложений

Поскольку система ручного сканирования файлов журналов не масштабируется, нам нужно лучшее решение. Нам необходимо внедрить автоматизацию и способность выявлять сбои по мере их возникновения. Сегодня доступно много инструментов для анализа файлов журналов и создания отчетов из них. Некоторыми инструментами являются Splunk, Fluentd, Logstask, Elasticsearch, Kibana, Google Analytics, SiteCatalyst, Papertrail, Airbrake, Exceptional, Logscape и loggly. Хотя автоматическое исправление может быть конечной целью, мы можем, по крайней мере, стремиться создать систему, которая будет генерировать оповещение по электронной почте или регистрировать заявку на обслуживание при обнаружении сбоя.

Чтобы иметь возможность внедрять автоматизацию, связанную с журналами приложений и генерировать отчеты или оповещения или тикеты, мы считаем, что разработчики приложений должны реализовать два столпа (как мы их называем) ведения журнала приложений — «Аннотированные данные» и «Поиск». , Реализуя эти столпы, предприятия могут включить аналитику журналов приложений для своих журналов приложений. Первоначально аналитика может ограничиваться созданием оповещений, отправкой электронной почты и / или созданием билетов. Со временем аналитическое решение может с уверенностью предсказать возникновение значимых событий.

Аннотированные данные

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

error connecting to database

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

Error: error in database connection, errortype: database, table: department, module: purchase

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

В качестве другого примера рассмотрим «полуаннотированный» журнал, приведенный ниже. Мы называем этот пример «полуаннотированным», поскольку сообщение об ошибке не содержит отметку времени. Следовательно, будет невозможно найти эту запись на основе продолжительности. Нам нужно будет специально искать поле бизнес-единицы или IP-адрес источника.

error at SynchronizeDCM() method, for BusinessUnit = 20807 and SourceIP = 10.25.7.1

Это сообщение было аннотировано, чтобы включать намного больше информации об ошибке.

ERROR, 2012-12-09 06:06:18, Type: Application, Error message: Failed to execute the command 'UpdateCommand' for table 'ShoppingCart'; the transaction was rolled back. Ensure that the command syntax is correct.

Поиск

При работе с объемными наборами данных самым простым механизмом поиска данных является их поиск. Если вы не уверены, вам нужно только посмотреть на популярность поисковой системы Google. Подобно тому, что намеревается сделать Google — проиндексировать всю информацию в мире — наша цель должна заключаться в том, чтобы проиндексировать (сделать доступным для поиска) все журналы приложений.

При представлении с аннотированным текстом данные легко анализируются и сохраняются в виде документов или в базе данных, что облегчает поиск. Хотя базы данных использовались для хранения информации журнала, они не очень хорошо подходят для задачи поиска. Что нам нужно, это поисковая система. Apache Lucene — популярная поисковая система, которая может использоваться для этой цели. В последнее время Elasticsearch приобрел большую популярность как и поисковая система с открытым исходным кодом. Splunk — еще один инструмент, который очень популярен в области анализа журналов приложений.

Splunk

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

Elasticsearch

Хотя Elasticsearch не входит в ту же лигу, что и Splunk, он также становится заметной альтернативой Splunk с открытым исходным кодом. Elasticsearch обычно развертывается как часть стека инструментов ELK, где E обозначает Elasticsearch, L обозначает Logstash (анализатор журнала), а K обозначает Kibana (визуализация).

Elasticsearch, поисковая система с открытым исходным кодом, построена на основе Apache Lucene ™. Это библиотека полнотекстового поиска. Lucene — это сложная, продвинутая, высокопроизводительная и полнофункциональная библиотека для поисковых систем. Elasticsearch использует Lucene внутренне для всей своей индексации и поиска, но стремится упростить полнотекстовый поиск, скрывая сложности Lucene за простым, последовательным, RESTful API. Elasticsearch также поддерживает следующие функции

• Распределенное хранилище документов в режиме реального времени, где каждое поле проиндексировано и доступно для поиска
• Распределенная поисковая система с аналитикой в ​​реальном времени
• Он способен масштабироваться до сотен серверов и петабайт структурированных и неструктурированных данных.

Вывод

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