Анализ журналов Exchange с помощью Azure Log Analytics (часть 3)

• Анализ журналов Exchange с помощью Azure Log Analytics (часть 4)

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

До сих пор мы рассматривали некоторые источники данных, такие как журналы событий Windows, журналы производительности и журналы информационных служб Интернета (IIS). Другой курс данных — Custom Logs, который позволяет нам собирать события из файлов журналов на компьютерах с Windows и Linux, отличных от компьютеров по умолчанию. После сбора мы можем разобрать каждую запись в журнале на отдельные поля с помощью Custom Fields.

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

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

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

Для этого мы просто заходим в Preview Features и включаем функцию Custom Logs:

Как только это будет сделано, мы можем начать добавлять наши таможенные журналы. Нажмите «Добавить+», чтобы открыть мастер создания настраиваемых журналов:

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

Мастер анализирует образец файла и отображает записи, которые он идентифицирует в этом файле, для проверки:

Затем Log Analytics будет использовать разделитель, который мы указываем для идентификации каждой записи. Новая строка — это разделитель по умолчанию, который используется для файлов журнала, содержащих одну запись в строке. Если строка начинается с даты и времени в одном из доступных форматов, мы можем указать разделитель Timestamp, который поддерживает записи, занимающие более одной строки. Однако журналы отслеживания сообщений Exchange начинаются с « », который еще не является поддерживаемым форматом, поэтому мы должны использовать новую строку:

Здесь нужно иметь в виду две вещи:

1. Если используется разделитель меток времени, свойство каждой записи, хранящейся в OMS, будет заполнено датой/временем, указанными для этой записи в файле журнала. Если используется новый разделитель строк, заполняется датой и временем, когда Log Analytics собрала запись;
2. В настоящее время Log Analytics обрабатывает дату и время, полученные из журнала, с помощью разделителя метки времени как UTC. Вскоре это будет изменено для использования часового пояса в агенте.

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

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

Поскольку Exchange создает несколько файлов журналов, иногда более одного в день, нам необходимо использовать подстановочный знак. Начнем с выбора Windows, введите « » в качестве пути для наших журналов и нажмите кнопку + плюс.

Наконец, мы указываем имя и описание журнала. Указываемое нами имя будет использоваться для типа журнала (как мы увидим, когда начнем анализировать собранные нами журналы) и всегда будет заканчиваться на , чтобы отличить его от пользовательского журнала:

Теперь у нас есть наш первый настраиваемый журнал:

Появление исходных данных из нового пользовательского журнала в Log Analytics может занять до одного часа. Как только он начнет собирать данные из пользовательского журнала, его записи будут доступны при поиске по журналу.

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

Тем не менее, мы можем отслеживать сообщения. Например, мы можем искать электронные письма с определенной темой, ища тему в виде строки в поле RawData, например, выполнив следующий запрос:

Или проверьте DELIVER:

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

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

Как только информация из наших журналов отслеживания сообщений начинает собираться, вся необходимая информация находится в свойстве RawData, как мы уже видели. Чтобы разобрать его, мы начинаем с нажатия … слева от поля RawData, а затем выбираем Извлечь поля из «MessageTrackingLogs_CL»:

Откроется мастер извлечения полей, и выбранная нами запись отобразится в столбце «Основной пример». Пользовательское поле будет определено для тех записей с одинаковыми значениями в выбранных свойствах. Мы выделяем текст, которым мы хотим заполнить настраиваемое поле, указываем имя для поля (символы _CF будут добавлены автоматически) и выполняем начальное извлечение:

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

Когда мы создаем настраиваемое поле, Log Analytics должен понимать, какие данные использовать для заполнения его значения. Он использует технологию Microsoft Research под названием FlashExtract для быстрой идентификации этих данных. Вместо того, чтобы требовать от нас предоставления явных инструкций, Log Analytics узнает о данных, которые мы хотим извлечь, из предоставленных нами примеров. Как мы только что видели, с полем это прекрасно работает, и Log Analytics может извлечь его из всех записей журнала. К сожалению, это не происходит со всеми другими полями, скорее всего, из-за характера этих журналов, где информация в журналах не является постоянной во всех его записях. Например, если мы попытаемся разобрать поле :

Он не соответствует всем типам в журналах отслеживания сообщений:

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

Из-за характера этих журналов нам придется выполнять эти ручные сопоставления для многих полей, и все же это не будет на 100% полезно… Однако это не относится ко всем типам журналов, а также к пользовательским журналам и Пользовательские поля отлично работают в других случаях!

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

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

Как и прежде, мы создаем наш пользовательский журнал и указываем Log Analytics его местоположение на нашем сервере:

Через некоторое время мы можем увидеть поступающую информацию:

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

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

Как только это будет сделано, все наши поля будут правильно заполнены:

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

Поиск и анализ журналов

Функция поиска в журнале Log Analytics такова, что я мог бы написать несколько статей, просто написав обо всех замечательных вещах, которые она может сделать. Это настолько мощно! Но давайте постараемся быть краткими и приятными.

Поиск OMS Log Analytics доступен как на портале Azure, так и на веб-сайте Operations Management Suite. Оба они позволяют выполнять поиск на одном уровне, поэтому давайте продолжим работу с порталом OMS. Для начала мы либо нажимаем на увеличительное стекло с левой стороны, либо используем кнопку поиска журнала на панели инструментов:

В окне поиска нам дается несколько примеров для начала:

Давайте выберем Компьютеры с доступной памятью более 2 Гб, чтобы посмотреть, что он возвращает:

На левой боковой панели мы можем выбрать, нужны ли нам данные за последние 6 часов, 1 день, 7 дней или пользовательский диапазон, а также выбрать серверы для анализа. На правой панели вверху у нас есть выполненный поиск:

Type=Perf ObjectName=Memory CounterName="Доступные МБ" | измерить avg(CounterValue) с интервалом компьютера 30MINUTE | где Совокупная стоимость>2000»

Это дает нам представление о том, как работают поисковые запросы. В середине у нас есть графическое представление этих данных. Используя поисковый запрос, мы можем легко обновить его до интервала в 5 минут и вместо этого вернуть компьютеры с оперативной памятью более 1 ГБ, что возвращает один дополнительный компьютер:

Мы также можем нажать «Таблица», чтобы просмотреть те же данные в формате таблицы вместо диаграммы:

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

Например, запрос об ошибке на следующем снимке экрана возвратил 24 000 записей о событиях (собранных Управлением журналом), 2000 записей MessageTrackingLogs_CL (сгенерированных нашим пользовательским журналом) и пять записей ConfigurationChange (захваченных отслеживанием изменений). Мы также можем увидеть увеличение количества событий этого типа с течением времени:

Эти фильтры на самом деле не являются типами/классами объектов. — это просто тег, или свойство, или строка/имя/категория, прикрепленная к фрагменту данных. Некоторые документы в системе помечены как Type:ConfigurationAlert, а некоторые помечены как Type:Perf или Type:Event и так далее. В каждом результате поиска, документе, записи или записи отображаются все необработанные свойства и их значения для каждой из этих частей данных, и мы можем использовать эти имена полей, чтобы указать в фильтре, когда мы хотим получить только те записи, в которых поле имеет данное значение.

Мы можем использовать либо двоеточие (:), либо знак равенства (=) после имени поля и перед значением. Это означает, что Type:Event и Type=Event одинаковы, мы можем выбрать стиль, который нам больше нравится.

Таким образом, если в записях Type=Perf есть поле с именем «CounterName», то мы можем написать такой запрос, как Type=Perf CounterName=»% процессорного времени». Это даст нам только данные о производительности, где имя счетчика производительности — «% процессорного времени»:

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

Итак, мы можем быть более конкретными и использовать InstanceName=_Total в запросе или просто щелкнуть слева, и он автоматически добавится в наш запрос:

Хорошо, у нас все еще есть более одного графика для одного и того же компьютера! Хм… На этот раз проблема в том, что мы получаем информацию из , но есть 3 объекта с этим счетчиком:

Нас интересует только процессор, поэтому мы выбираем его, и он снова добавляется в наш запрос:

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

Более простой запрос для получения тех же данных будет выглядеть так: «Type=Perf (ObjectName=Processor)»?

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

Я даю ему имя и категорию и нажимаю «Сохранить»:

Теперь, если мы нажмем значок «Избранное» вверху:

Мы получаем список предопределенных запросов, а также тот, который мы только что сохранили:

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

Мы также можем использовать диапазонные запросы в наших поисках. Это означает, что мы можем предоставить начальный и конечный диапазон значений в последовательности. Например, если нам нужны события из журнала событий приложений, где EventID больше или равен 1008, но не больше 1009 (это события Exchange FastSearch), то следующий запрос вернет их:

Type=Event EventLog="Application" EventID:[1008..1009]

Слева мы видим, что 23 000 — это предупреждающие события, а еще 23 000 — информационные.

Этот поиск представляет нам еще один метод визуализации данных: minify. Этот метод агрегирует данные таким образом, что мы можем видеть, сколько событий произошло для каждого объекта. Например, используя minify, мы видим, что ошибка « произошла 690 для базы данных MDB01:

MEASURE — еще одна полезная команда для поиска в Log Analytics. Это позволяет нам применять статистические к нашим данным и агрегировать результаты, сгруппированные по заданному полю. Есть несколько статистических функций, которые поддерживает Measure, одна из них — . Используя эту функцию, мы можем, например, точно узнать, сколько событий ошибок произошло на один компьютер за последние 7 дней, используя запрос:

Тип=событие EventLevelName=ошибка | Измерение счетчика () с помощью компьютера

Или по например:

Просто нажав на 10006, мы можем легко получить все эти события и посмотреть, в чем проблема:

В следующем примере мы выбираем счетчик производительности CPU Total Time и усредняем по Computer. Затем мы сужаем результаты только до последних 6 часов:

Type=Perf ObjectName:Processor InstanceName:_Total CounterName:"% процессорного времени" TimeGenerated>NOW-6HOURS | Измерение среднего (счетного значения) по компьютеру

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

Тип = Источник события = "Microsoft-Exchange-ManagedAvailability"

Если мы не уверены в имени журнала событий, мы можем ввести , и Log Analytics отобразит все имена журналов, которые мы собираем в данный момент. Все, что нам нужно сделать, это нажать на тот, который мы хотим проанализировать:

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

Вывод

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

В следующей и последней части мы рассмотрим информационные панели, оповещения и решения.

• Анализ журналов Exchange с помощью Azure Log Analytics (часть 4)