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

Панели мониторинга

Информационные панели Log Analytics помогают нам визуализировать все наши сохраненные поиски по журналам, предоставляя нам единую линзу для просмотра нашей среды. Для начала перейдите к обзору OMS, нажав кнопку «Обзор» на левой навигационной панели:

Слева вы увидите плитку My Dashboard. Нажмите на нее, чтобы перейти к панели управления:

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

В представлении «Моя панель управления » просто нажмите шестеренку настройки в верхней части страницы, чтобы войти в режим настройки:

Панель, которая открывается в правой части страницы, показывает все сохраненные поиски журнала нашей рабочей области:

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

Хорошо, это не совсем та визуализация, которую я искал… Давайте посмотрим, сможем ли мы это изменить. В представлении «Моя панель управления» нажмите шестеренку настройки в верхней части страницы, чтобы еще раз войти в режим настройки. Затем нажмите «Изменить»:

Затем выберите плитку, которую хотите отредактировать, в этом случае я собираюсь отредактировать только что добавленную плитку. Правая панель меняется на редактирование и предоставляет выбор опций:

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

Немного поработав с сохраненным поиском, график выглядит намного лучше:

Также можно настроить основную консоль с помощью View Designer, что позволяет нам создавать пользовательские представления в консоли OMS, содержащие различные визуализации данных в репозитории OMS. Например, мы можем включить аналогичный график для нашего сервера Exchange в основную консоль, при нажатии на которую мы перейдем к представлению (панель управления/консоль) с дополнительной информацией об этом конкретном сервере:

Оповещения

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

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

Действия веб-перехватчика позволяют нам вызывать внешний процесс с помощью одного HTTP-запроса POST. Вызываемая служба должна поддерживать веб-перехватчики и определять, как она будет использовать любые получаемые данные. Мы также можем вызвать REST API, который специально не поддерживает веб-перехватчики, если запрос имеет формат, понятный API. В качестве примера можно привести использование веб-перехватчика в ответ на оповещение, которое использует такую службу, как Slack, для отправки сообщения с подробностями оповещения.

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

1. На странице обзора OMS щелкните Поиск по журналу.
2. Либо создайте новый поисковый запрос журнала, либо выберите сохраненный поиск журнала. Допустим, я хочу получать уведомления об остановке службы транспорта Exchange. Для этого я создаю следующий поиск:

Type=Event EventID=7036 (Computer="EXAIO.domain.com") "Служба транспорта Microsoft Exchange остановлена".

3. Щелкните Оповещение в верхней части страницы, чтобы открыть экран «Добавить правило оповещения»:

4. Настройте свойства оповещения, такие как частота, описание, получатели и т. д.:

5. Щелкните Сохранить, чтобы завершить правило оповещения. Он начнет работать немедленно.

Чтобы предупредить об одном событии, мы устанавливаем количество результатов больше 0, а частоту и временное окно — 5 минут (минимально допустимый). Это будет запускать запрос каждые 5 минут и проверять наличие одного события, которое было создано с момента последнего запуска запроса. Более высокая частота может привести к задержке времени между сбором события и созданием оповещения.

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

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

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

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

Type=Perf ObjectName=Processor CounterName="% процессорного времени" InstanceName=_Total CounterValue>90

Затем мы устанавливаем пороговое значение для правила оповещения . Недостатком этих типов предупреждений является то, что записи о производительности собираются каждые 30 минут независимо от частоты, с которой мы собираем каждый счетчик. Таким образом, временное окно меньше 30 минут может не возвращать никаких записей. Установка временного окна на 30 минут гарантирует, что мы получим одну запись для каждого подключенного источника, представляющую среднее значение за это время.

Мы также можем найти все записи журнала, которые (должны были) сгенерировать предупреждение, выполнив следующий запрос:

Тип = Alert SourceSystem = OMS

Решения

Как упоминалось ранее в этой серии статей, решения Log Analytics расширяют возможности Log Analytics. В основном они работают в облаке и обеспечивают анализ данных, собранных в репозитории OMS. Мы можем использовать решения, например, для предоставления сводки о текущих действиях пользователей в Office 365 (как мы вскоре увидим), оценки риска и работоспособности Active Directory, просмотра состояния антивируса и защиты от вредоносных программ на серверах, выявления отсутствующих системных обновлений., и многое другое. Они также могут определять новые типы собираемых записей, которые можно анализировать с помощью поиска по журналам или с помощью дополнительного пользовательского интерфейса, предоставляемого решением на панели мониторинга OMS.

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

Чтобы добавить решение с помощью Галереи решений:

1. На странице Обзор в OMS щелкните плитку Галерея решений:

2. На странице Галерея решений OMS узнайте о каждом доступном решении. Щелкните имя решения, которое вы хотите добавить в OMS. Для этой статьи давайте добавим решение Office 365 (обратите внимание, что оно все еще находится в стадии бета-тестирования):

3. На странице решения отображается подробная информация о нем. Нажмите Добавить:

4. На странице обзора в OMS появится новая плитка для этого решения:

Как видите, это конкретное решение требует дополнительной настройки. После того, как мы нажмем на нее, у нас появятся варианты подключения к Office 365:

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

Как только мы предоставим свои учетные данные, нас попросят авторизовать решение для выполнения определенных действий, таких как чтение действий и данных о работоспособности из нашего клиента Office 365:

После принятия решение подключается к нашему тенанту:

В первый раз решению может потребоваться до 4 часов, чтобы получить данные, поэтому нам нужно подождать…

После сбора данных плитка Office 365 в главной консоли отображает количество действий, из которых была собрана информация:

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

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

К сожалению, на данном этапе кажется, что собираются только действия Azure. Все, что я делал в Exchange, записывалось как действие Azure:

Если мы нажмем «Действия Azure Active Directory», мы вернемся к поиску с запросом, который возвращает все эти действия, например:

Type=OfficeActivity OfficeWorkload=AzureActiveDirectory | измерить count() по операции

Отсюда, если мы нажмем операцию «Удалить пользователя», мы сможем точно увидеть, что произошло. В данном случае пользователь Nuno удалил пользователя с именем User3:

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

Или другие действия, такие как удаление пользователей из групп рассылки. В этом примере пользователь Nuno удалил пользователя Test из группы рассылки IT:

Другие решения

В Log Analytics есть много других полезных решений. Мы можем легко отследить отсутствие обновлений на компьютерах или рабочих станциях:

Например, если мы нажмем «Критические обновления», мы сможем развернуть детали, чтобы получить более подробную информацию о них:

Мы можем увидеть, каких именно обновлений не хватает:

И получите обзор того, сколько обновлений на самом деле отсутствует на каждой машине:

А также их возраст:

Другие решения позволяют отслеживать все изменения в среде:

Или получить обзор безопасности:

Существует также одно решение для оценки репликации Active Directory (AD) и другое для оценки риска и работоспособности AD:

Мобильное приложение Log Analytics

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

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

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

Заворачиваем…

В этой серии статей мы рассмотрели новую службу Log Analytics в Azure и то, как мы можем использовать ее вместе с Exchange локально и через Интернет. Это все еще довольно новая технология, но она уже действительно мощная! С несколькими настройками и исправлениями он станет серьезным соперником в мире сбора/мониторинга/оповещения.

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