Мониторинг данных Кэша Azure для Redis с помощью параметров диагностики
Мақала
Параметры диагностики в Azure используются для сбора журналов ресурсов. Ресурс Azure выдает журналы ресурсов и предоставляет широкие и частые данные об операции этого ресурса. Эти журналы записываются на запрос и также называются журналами плоскости данных. Ознакомьтесь с параметрами диагностики в Azure Monitor , чтобы ознакомиться с рекомендуемыми функциями в Azure. Содержимое этих журналов зависит от типа ресурса. В Кэш Azure для Redis для журнала доступны два варианта:
Журналы подключений регистрируют подключения к кэшу в целях безопасности и диагностики.
Область доступности
Уровень
Базовый, Стандартный и Премиум
"Корпоративный" и Enterprise Flash
Метрики кэша
Да
Да
Журналы подключений
Да
Да
Метрики кэша
Кэш Azure для Redis выдает множество метрик, таких как загрузка сервера и подключения в секунду, которые полезны для журналов. Выбор параметра AllMetrics позволяет регистрировать эти и другие метрики кэша. Вы можете настроить, сколько времени хранятся метрики. См . здесь пример экспорта метрик кэша в учетную запись хранения.
Журналы подключений
Кэш Azure для Redis использует параметры диагностики Azure для регистрации сведений о клиентских подключениях к кэшу. Ведение журнала и анализ этого параметра диагностики помогает понять, кто подключается к вашим кэшам, и узнать метку времени этих подключений. Данные журнала можно использовать для определения области нарушения безопасности и в целях аудита безопасности.
Различия между уровнями Кэш Azure для Redis
Реализация журналов подключений немного отличается от уровней:
Базовые, стандартные и премиум-уровни кэшируют клиентские подключения по IP-адресу, включая количество подключений, исходящих из каждого уникального IP-адреса. Эти журналы не являются накопительными. Они представляют моментальные снимки на определенный момент времени, создаваемые с интервалом в 10 секунд. События проверки подлинности (успешные и неудачные) и события отключения не регистрируются на этих уровнях.
Кэши корпоративного и корпоративного флэш-памяти используют функции событий подключения аудита, встроенные в Redis Enterprise. События аудита подключения позволяют регистрировать все события подключения, отключения и проверки подлинности, включая события проверки подлинности сбоем.
Журналы подключений похожи на уровни, но имеют некоторые отличия. Эти два формата подробно показаны далее в статье.
Внимание
Ведение журнала подключений на уровнях "Базовый", "Стандартный" и "Премиум" опрашивает текущие клиентские подключения в кэше. Те же IP-адреса клиента отображаются снова и снова. Ведение журнала на уровнях Enterprise и Enterprise Flash ориентировано на каждое событие подключения. Журналы происходят только при первом возникновении фактического события.
Предварительные требования и ограничения ведения журнала подключений
Уровни "Базовый", "Стандартный" и "Премиум"
Так как журналы подключений на этих уровнях состоят из моментальных снимков на определенный момент времени каждые 10 секунд, подключения, установленные и удаленные между 10-секундными интервалами, не регистрируются.
События проверки подлинности не регистрируются.
Все параметры диагностики могут занять до 90 минут , чтобы начать поток в выбранное место назначения.
Включение журналов подключений может привести к снижению производительности экземпляра кэша.
Только план ценообразования журналов Аналитики поддерживается при потоковой передаче журналов в Azure Log Analytics. Дополнительные сведения см. на странице цен на Azure Monitor.
Уровни "Корпоративный" и Enterprise Flash
При использовании политики кластеров OSS журналы создаются из каждого узла данных. При использовании корпоративной политики кластера только узел, используемый в качестве прокси-сервера, выдает журналы. Обе версии по-прежнему охватывают все подключения к кэшу. Это просто разница в архитектуре.
Потеря данных (т. е. отсутствие события подключения) является редкой, но возможной. Потеря данных обычно вызвана проблемами сети.
Журналы отключения пока не полностью стабильны и события могут быть пропущены.
Так как журналы подключений на уровнях Enterprise основаны на событиях, будьте осторожны с политиками хранения. Например, если срок хранения равен 10 дней, а событие подключения произошло 15 дней назад, это подключение может по-прежнему существовать, но журнал для этого подключения не сохраняется.
Все параметры диагностики могут занять до 90 минут , чтобы начать поток в выбранное место назначения.
Включение журналов подключений может привести к снижению производительности экземпляра кэша.
Примечание.
Всегда можно использовать команды INFO или CLIENT LIST , чтобы проверить, кто подключен к экземпляру кэша по запросу.
Внимание
При выборе журналов можно выбрать определенные группы категорий или категорий, которые являются предопределенными группами журналов в службах Azure. При использовании групп категорий больше не удается настроить параметры хранения. Если необходимо определить длительность хранения для журналов подключений, выберите элемент в разделе "Категории ".
Назначения журналов
Вы можете включить параметры диагностики для экземпляров Кэша Azure для Redis и отправлять журналы ресурсов в следующие места назначения:
Рабочая область Log Analytics — не обязательно должна находиться в том же регионе, что и отслеживаемый ресурс.
Концентратор событий — параметры диагностики не могут получить доступ к ресурсам концентраторов событий, если включены виртуальные сети. Установите флажок Разрешить доверенным службам Майкрософт обходить этот параметр брандмауэра в концентраторах событий, чтобы предоставить доступ к ресурсам концентраторов событий. Концентратор событий должен находиться в том же регионе, что и кэш.
Партнерское решение — список потенциальных решений для ведения журналов партнеров можно найти здесь
Дополнительные сведения о требованиях к диагностике см. в статье Параметры диагностики.
Вы взимаете обычные тарифы данных для учетной записи хранения и использования концентратора событий при отправке журналов диагностики в любое место назначения. Счет оплачивается в Azure Monitor, а не в Кэше Azure для Redis. При отправке журналов в Log Analytics оплачивается только прием данных в Log Analytics.
Перейдите в учетную запись Кэша Azure для Redis. В разделе Мониторинг слева выберите Параметры диагностики. Затем выберите Добавить параметр диагностики.
В области параметров диагностики выберите ConnectedClientList из категорий.
Дополнительные сведения о зарегистрированных данных см. в разделе "Содержимое журналов подключений".
Выбрав ConnectedClientList, отправьте журналы в предпочитаемое место назначения. Выберите сведения в рабочей области.
Перейдите в учетную запись Кэша Azure для Redis. Откройте область "Параметры диагностики— аудит" в разделе "Мониторинг" слева. Затем выберите Добавить параметр диагностики.
В области "Параметры диагностики — аудит" выберите события подключения из категорий.
Дополнительные сведения о зарегистрированных данных см. в разделе "Содержимое журналов подключений".
Выбрав события подключения, отправьте журналы в предпочитаемое место назначения. Выберите сведения в рабочей области.
Включение ведения журнала подключений с помощью REST API
Эти поля и свойства отображаются в категории журнала ConnectedClientList. В Azure Monitor данные журналов передаются в таблицу ACRConnectedClientList с именем поставщика ресурсов MICROSOFT.CACHE.
Поле или свойство службы хранилища Azure
Свойство журналов Azure Monitor
Description
time
TimeGenerated
Метка времени создания журнала (в формате UTC).
location
Location
Расположение (регион), в котором осуществлялся доступ к экземпляру Кэша Azure для Redis.
category
Н/Д
Доступные категории журналов: ConnectedClientList.
resourceId
_ResourceId
Ресурс Кэша Azure для Redis, для которого включены журналы.
operationName
OperationName
Операция Redis, связанная с записью журнала.
properties
Н/Д
Содержимое этого поля описано в строках, приведенных ниже.
tenant
CacheName
Имя экземпляра Кэша Azure для Redis.
roleInstance
RoleInstance
Экземпляр роли, зарегистрировавший список клиентов.
connectedClients.ip
ClientIp
IP-адрес клиента Redis.
connectedClients.privateLinkIpv6
PrivateLinkIpv6
Адрес IPv6 частной ссылки клиента Redis (если применимо).
connectedClients.count
ClientCount
Число клиентских подключений Redis из связанного IP-адреса.
Пример журнала учетной записи хранения
Если вы отправляете журналы в учетную запись хранения, содержимое журналов будет выглядеть так, как показано ниже.
Эти поля и свойства отображаются в категории журнала ConnectionEvents. В Azure Monitor данные журналов передаются в таблицу REDConnectionEvents с именем поставщика ресурсов MICROSOFT.CACHE.
Поле или свойство службы хранилища Azure
Свойство журналов Azure Monitor
Description
time
TimeGenerated
Метка времени (UTC) при записи журнала событий.
location
Location
Расположение (регион), в котором осуществлялся доступ к экземпляру Кэша Azure для Redis.
category
Н/Д
Доступные категории журналов: ConnectionEvents.
resourceId
_ResourceId
Ресурс Кэша Azure для Redis, для которого включены журналы.
operationName
OperationName
Операция Redis, связанная с записью журнала.
properties
Н/Д
Содержимое этого поля описано в строках, приведенных ниже.
eventEpochTime
EventEpochTime
Метка времени UNIX (количество секунд с 1 января 1970 г.), когда событие произошло в формате UTC. Метка времени можно преобразовать в формат datetime с помощью функции unixtime_seconds_todatetime в рабочей области Log Analytics.
clientIP
ClientIP
IP-адрес клиента Redis. При использовании хранилища Azure IP-адрес — это формат IPv4 или IPv6 приватного канала на основе типа кэша. Если используется Log Analytics, результат всегда находится в IPv4, в качестве отдельного поля IPv6 предоставляется.
Н/Д
PrivateLinkIPv6
Адрес IPv6 клиента Redis (только при использовании Приватный канал и log analytics).
Тип события подключения (new_conn, аутентификации или close_conn).
eventStatus
EventStatus
Результаты запроса проверки подлинности в виде кода состояния (применимо только для события проверки подлинности).
Примечание.
Если используется приватная ссылка, будет зарегистрирован только IPv6-адрес (если вы не выполняете потоковую передачу данных в log analytics). IPv6-адрес можно преобразовать в эквивалентный IPv4-адрес, просмотрев последние четыре байта данных в IPv6-адресе. Например, в адресе IPv6 приватного канала "fd40:8913:31:6810:6c31:200:a01:104", последние четыре байта в шестнадцатеричном формате : "0a", "01", "01" и "04". (Обратите внимание, что начальные нули опущены после каждой двоеточия.) Они соответствуют "10", "1", "1", "1" и "4" в десятичном разряде, что дает нам IPv4-адрес "10.1.1.4".
Пример журнала учетной записи хранения
Если вы отправляете журналы в учетную запись хранения, журнал события подключения выглядит следующим образом: