Часто встречающиеся проблемы и пути их устранения#

Порядок контроля компонентов Platform V Audit SE (AUD) и методы решения их проблем#

Контроль Apache Ambari и HDFS#

Контроль того, с какой скоростью заканчивается место на HDFS.

Необходим инфраструктурный мониторинг или регулярный контроль метрики для HDFS в Apache Ambari.

  1. Выставить оповещение при заполнении 60% места на HDFS. Для этого:

    1. Выполнить анализ роста нагрузки за последние два месяца: Для этого можно выполнить команды на HDFS, указав правильные месяцы hdfs dfs -du -h -s /events_avro/2020-12* hdfs dfs -du -h -s/events_avro/2020-11* В результате выполнения будет размер папок на HDFS по суткам (чистые данные и отреплицированные). Оценить скорость заполнения, рассчитать на сколько дней хватит оставшегося хранилища.

      Если хранилища хватит менее чем на полгода, то необходимо:

      1. Если нагрузка росла равномерно и была запланирована, то необходимо заказать серверы с ролью DataNode по характеристикам идентичные включенным в кластер. Количество серверов должно быть таким, чтобы свободного места хватило минимум на полгода. При учете дискового пространства новых серверов учитывать их, разделив на 3 (фактор репликации на HDFS).

      2. После получения серверов, включить их в кластер Hadoop, выполнить рестарт кластера (временно будет прекращен доступ на чтение данных через UI).

      3. Установить на новых серверах роль HDFSDataNode.

      4. Запустить процедуру ребаланса HDFS.

    2. Определить, не было ли резкого роста нагрузки: Если наблюдался резкий рост, то необходимо определить причины этого роста:

      1. Внедрение новых серверов АС, подключенных к Platform V Audit SE (AUD).

      2. Внедрение новой функциональности АС, которая повлекла рост нагрузки на Platform V Audit SE (AUD). При необходимости, отключить аудит этих АС.

      3. Определить модули, от которых идет максимальная нагрузка. Это можно сделать с помощью запросов к Solr через SolrServer WEB UI. Критерий поиска: с фасетным поиском по module (включить флаг facet и заполнить поле facet.field значением module). Результаты поиска необходимо сообщить владельцу Platform V Audit SE (AUD) для дальнейших выяснений причин нагрузки модулей из верхней части списка.

  2. Выставить оповещение при заполнении 80%.

    Действия аналогичны оповещению о 60% с той лишь разницей, что сначала требуется заказать серверы, а затем выполнять анализ.

Контроль проблем с серверами Hadoop#

Контроль процесса утилизации RAM на NameNode. Требуется, чтобы не возникло ограничение записи на HDFS.

Необходим инфраструктурный мониторинг или контроль метрики RAM для серверов с ролью NameNode, Secondary NameNode, StandBy NameNode в Apache Ambari.

Необходимо выставить предупреждение при достижении 80% использования RAM серверов Hadoop.

Действия по решению проблемы:

  • Обратиться к владельцу Platform V Audit SE (AUD) для получения утилиты уплотнения файлов данных на HDFS.

  • Это позволит множество маленьких файлов уплотнить в большие (приведет к уменьшению количества файлов HDFS) и, как следствие, использование RAM сервисом HDFS NameNode.

Контроль Kafka#

  1. Контроль того, справляется ли Kafka со входящим потоком и хватает ли дискового пространства.

    Для этого нужно выставить регулярные оповещения при заполнении 60% или 80% дисков.

    Выполнить следующие действия:

    1. Определить топики, содержащие максимальный объем данных. Определить значение retention.hours для данных топиков. Совместно с владельцем Platform V Audit SE (AUD) рассмотреть возможность временного уменьшения значения retention.hours для данных топиков.

    2. Определить, что дает максимальную нагрузку. Если идет нагрузка идет на топики вида audit-global-*, то нужно выполнить запрос к Solr через SolrServer WEB UI, с фасетным поиском по module (включить флаг facet и заполнить поле facet.field значением module). Результаты поиска необходимо сообщить владельцу Platform V Audit SE (AUD) для дальнейших выяснений причин нагрузки модулей из верхней части списка. Если нагрузка идет на другие топики, то необходимо совместно с владельцем Platform V Audit SE (AUD) определить критерии для выполнения анализа.

    3. Если нагрузка возросла планово, то выполнить заказ серверов для добавления в кластер Corax, по характеристикам аналогичные имеющимся. После получения дополнительных серверов с ПО Kafka той же версии, необходимо сконфигурировать server.properties аналогично имеющимся брокерам.

  2. Контроль входящего потока сообщений (tps, ГБ/сутки)

    Если есть превышение tps сверх заявленного по SLA (5000 tps), то требуется:

    1. Анализ метрик брокеров Kafka.

    2. Превышение метрики tps на панели «SLA»

    Выяснить утилизацию HDD, CPU, RAM. Совместно с владельцем Platform V Audit SE (AUD) рассмотреть включение throttling. Рассмотреть необходимость заказа дополнительных серверов. Само по себе превышение tps не является плохим индикатором, нужно смотреть метрики характеризующие пропускную способность сервиса и наполнение хранилища.

  3. Контроль исходящего потока сообщений (количество в единицу времени, lags)

    Контроль доступен на панели «Метрики компонента Pipeline» Если метрики CurrentLagPerFlumeNode превышают значение 3.000.000. Выполнить следующие действия:

    1. Предоставить логи всех сервисов Flume и значение метрики tps с панели «SLA» для владельца Platform V Audit SE (AUD) для сравнения скорости чтения и записи в Kafka.

    2. Наблюдать в течение суток состояние метрики на панели «Метрики компонента Pipeline» метрики CurrentLagPerFlumeNode. Определить минимальное и максимальное значение.

Контроль проблем с процессорами, оперативной памятью серверов для компонентов Platform V Audit SE (AUD)#

Контроль утилизации CPU, RAM серверов Hadoop, Kafka.

При срабатывании инфраструктурной метрики, предоставить владельцу Platform V Audit SE (AUD) соответствующие графики этой метрики.

Приоритетный порядок контроля серьезных проблем в компонентах Platform V Audit SE (AUD)#

В таблице приведены компоненты Platform V Audit SE (AUD) в приоритетном порядке их контроля при возникновении в них фатальных проблем:

Порядок контроля компонентов Platform V Audit SE (AUD)

Компонент Platform V Audit SE (AUD)

Приоритет

Комментарий

Kubernetes

0

При недоступности proxy-приложения Platform V Audit SE (AUD) в Kubernetes нет возможности регистрировать события аудита, работа АС блокируется

Kafka (Kafka) и ZooKeeper (Kafka)

1

При регистрации синхронных событий работа модуля блокируется. Асинхронные события некоторое время могут сохраняться в локальном буфере. Далее возможна потеря событий Platform V Audit SE (AUD). Старт модулей, использующих Platform V Audit SE (AUD) невозможен

Сервисы Hadoop:
•ZooKeeper;
•Flume;
•Solr;
•Hive;
•HBase

2

При возникновении проблем с сервисами некоторое время события накапливаются в Kafka. Далее события Platform V Audit SE (AUD) будут утеряны

Kubernetes, интерфейс пользователя

3

Недоступен UI модуля. Регистрация событий происходит в штатном режиме (при недоступном UI события аудита продолжают регистрироваться. Просмотр событий доступен через панель управления СУБД)

Рекомендации при ошибках и сбоях Platform V Audit SE (AUD)#

Общие рекомендации по анализу администратором проблем в Platform V Audit SE (AUD)#

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

Модуль (клиентская АС) не может записать данные в Platform V Audit SE (AUD) Ошибка не приводит к нарушению конфиденциальности и целостности информации, но приводит к нарушению доступности информации.

Шаги анализа: По проблемному модулю по его конфигурации выяснить, в какую Kafka он регистрирует события аудита.

Примеры проблем/сбоев Platform V Audit SE (AUD), их диагностика и рекомендации по устранению#

Ошибка установки SSL соединения (клиентский модуль не подключается к Kafka, закрытой SSL)#

Ошибка не приводит к нарушению конфиденциальности и целостности информации, но приводит к нарушению доступности информации.

Проверить контейнер с сертификатом (jks).

В промышленном SSL сертификате есть поле — Extended Key Usage, у которого может быть значение «Для клиентской аутентификации», «Для серверной аутентификации» или сразу оба. Сертификат, с которым клиент подключается к Kafka Platform V Audit SE (AUD), должен быть для клиентской аутентификации (либо для обеих). В противном случае Kafka при SSL handshake разорвет соединение с ошибкой вида «Сертификат не предназначен для клиентской аутентификации». Можно проверить это поле на машине с linux командой keytool –keystore keystore_name.jks –list –v.

События от прикладного модуля не пишутся в Platform V Audit SE (AUD)#

Ошибка не приводит к нарушению конфиденциальности и целостности информации, но приводит к нарушению доступности информации.

  1. Проверьте параметры, с которыми стартовала клиентская часть Platform V Audit SE (AUD). Если на стенде SSL, то убедитесь, что сертификат включен в ACL Kafka Platform V Audit SE (AUD). Детальное описание параметров есть в документации.

  2. Зайдите в UI Platform V Audit SE (AUD) и выполните поиск с пустой поисковой строкой. Убедитесь, что есть хотя бы одно свежее событие. Если свежих событий нет, то проблема общая для всех модулей. Информация о действиях в этом случае расположена ниже.

  3. Выполните поиск в UI Platform V Audit SE (AUD) в формате Lucene по тексту module:audit. Убедитесь, что событие поиска из п.2 записано в Platform V Audit SE (AUD).

Если проблема с событиями только от одного модуля, то:

  1. Требуются логи сервера этого модуля.

  2. Требуются логи с Kafka с сервисов Flume-Solr-Event, Flume-Operation.

  3. Выполнить поиск в UI Solr с помощью запроса module:"MODULENAME", отсортировав по времени createdAt DESC

  4. Выполнить поиск по подстроке module:\"MODULENAME в Hue по Hbase в таблицах audit_invalid_events, audit_invalid_operations.

    В таблице в строке поиска написать запрос (точка в начале запроса обязательна):

    .*{SingleColumnValueFilter('payload', 'payload', =, 'substring:IDмодуля')}

    Если нужно вывести более 1 события или операции, то в конце запроса напишите +10

  5. Проанализировать содержимое топиков audit-global-events, audit-global-operations на наличие событий и операций от модуля MODULENAME.

    Необходимо искать ошибки записи в Kafka.

    В логах Flume необходимо искать ошибки валидации событий.

Если проблема для событий по всем модулям, то необходимо проверять pipeline.

  1. Проверить работоспособность Kafka Platform V Audit SE (AUD).

  2. Зайти в Apache Ambari и проверить состояние сервисов. Наиболее важные: Flume*, Solr, ZooKeeper, Hbase, Hive, HDFS. Устранить неисправности.

  3. Проверить версию агентов Flume. Поиск в Apache Ambari по логам Flume* подстроки version с уровнем INFO.

  4. Проверить конфигурационные файлы Flume. Могут быть ошибки конфигурации.

  5. Проверить параметры конфигурации клиентских модулей Platform V Audit SE (AUD).

  6. Проверить доступность Kafka Platform V Audit SE (AUD). Можно по логам прикладного модуля смотреть сообщения от клиентского модуля Platform V Audit SE (AUD).

Данные регистрируются с большой задержкой#

Ошибка не приводит к нарушению конфиденциальности и целостности информации, но приводит к нарушению доступности информации.

Нужно смотреть offsets consumer audit-events-solr на Kafka Platform V Audit SE (AUD). Если они большие, то проблема с вычиткой данных из Kafka.

В первую очередь нужно посмотреть версию агентов Flume. Поиск в Apache Ambari по логам Flume подстроки version с уровнем INFO. Она должна быть актуальная.

Далее требуется посмотреть логи Flume-Solr-Event. Скорее всего, в них обнаружится много ошибок обработки.

Далее необходимо проверить, что в solr/configs/audit-events отсутствует файл schema.xml. Если файл есть, необходимо удалить эту схему в ZooKeeper, удалить в Solr коллекцию и выполнить скриптами обновление Hadoop.

Обращайтесь к администраторам соответствующего стенда.

Не удается найти данные по модулю#

Ошибка не приводит к нарушению конфиденциальности, целостности или доступности информации.

  1. UI Platform V Audit SE (AUD) предоставляет возможность поиска по событиям. Убедитесь, что вы ищете именно события. При этом в Platform V Audit SE (AUD) еще регистрируется сущность «операция», которая является группирующей для событий.

  2. Поиск в UI Platform V Audit SE (AUD) имеет три режима, каждый из которых обладает своими особенностями. Например, в режиме Lucene спецсимволы имеют свое предназначение. В поиске «По словам» происходит дробление фразы на слова и поиск выполняется по И. В поиске «По фразе целиком» ищется точное вхождение фразы. Ознакомьтесь с документацией по поиску, чтобы убедиться в том, что ваши ожидания соответствуют поисковому алгоритму.

  3. Бывает, что данные пишут в один стенд (среду), а искать их пытаются на другом.

Модуль не смог стартовать, ошибка Error occurred while sender.sending metamodel#

Ошибка не приводит к нарушению конфиденциальности и целостности информации, но приводит к нарушению доступности информации.

Полный текст ошибки:

_"Caused by: <...>.AuditTransportException: Error occurred while sender.sending metamodel_
_Caused by: <...>.AuditTransportException: Could not send data to topic audit-***-metamodels_
_Caused by: java.util.concurrent.ExecutionException: shade.org.apache.kafka.common.errors.TimeoutException: Failed to update metadata after 60000 ms._
_Caused by: shade.org.apache.kafka.common.errors.TimeoutException: Failed to update metadata after 60000 ms.",_

Пример ошибки из лога:

_19:48:43,022 INFO [stdout] (ServerService Thread Pool -- 155) <...>.AuditTransportException: Could not send data to topic audit-currency-rates-metamodels_
_19:48:43,022 INFO [stdout] (ServerService Thread Pool -- 155) at <...>.service.transport.impl.AuditClientKafkaProducer.sendSync(AuditClientKafkaProducer.java:172)_
_19:48:43,022 INFO [stdout] (ServerService Thread Pool -- 155) at <...>.service.transport.impl.AuditClientKafkaProducer.send(AuditClientKafkaProducer.java:150)_
_19:48:43,022 INFO [stdout] (ServerService Thread Pool -- 155) at <...>.service.transport.impl.AuditClientKafkaProducer.sendMetamodel(AuditClientKafkaProducer.java:99)_
_19:48:43,022 INFO [stdout] (ServerService Thread Pool -- 155) at <...>.AuditClientFactoryImpl.sendMetamodel(AuditClientFactoryImpl.java:210)_
_19:48:43,022 INFO [stdout] (ServerService Thread Pool -- 155) at <...>.AuditClientFactoryImpl.<init>(AuditClientFactoryImpl.java:81)_
_19:48:43,022 INFO [stdout] (ServerService Thread Pool -- 155) at <...>.cfg.Configuration.buildAuditClientFactory(Configuration.java:37)_
_19:48:43,023 INFO [stdout] (ServerService Thread Pool -- 155) Caused by: java.util.concurrent.ExecutionException: shade.org.apache.kafka.common.errors.TimeoutException: Failed to update metadata after 60000 ms._
_19:48:43,023 INFO [stdout] (ServerService Thread Pool -- 155) at shade.org.apache.kafka.clients.producer.KafkaProducer$FutureFailure.<init>(KafkaProducer.java:1108)_
_19:48:43,023 INFO [stdout] (ServerService Thread Pool -- 155) at shade.org.apache.kafka.clients.producer.KafkaProducer.doSend(KafkaProducer.java:808_)
_19:48:43,023 INFO [stdout] (ServerService Thread Pool -- 155) at shade.org.apache.kafka.clients.producer.KafkaProducer.send(KafkaProducer.java:745)_
_19:48:43,023 INFO [stdout] (ServerService Thread Pool -- 155) at shade.org.apache.kafka.clients.producer.KafkaProducer.send(KafkaProducer.java:634)_
_19:48:43,023 INFO [stdout] (ServerService Thread Pool -- 155) at <...>.service.transport.impl.AuditClientKafkaProducer.sendSync(AuditClientKafkaProducer.java:166)_
_19:48:43,023 INFO [stdout] (ServerService Thread Pool -- 155) ... 111 common frames omitted_

Диагностика и решение:

Причина ошибки в том, что отсутствует связь с Kafka Platform V Audit SE (AUD).

  1. Проверить наличие топика, в который отправляется метамодель.

  2. Проверить наличие живого лидера партиции.

  3. Проверить по серверу старые перекрытия, что прописаны актуальные для Kafka.

  4. Необходимо убедиться, что в артефакте audit2-client прописаны корректные параметры подключения к Kafka Platform V Audit SE (AUD).

  5. Если параметры корректные, необходимо убедиться в том, что Kafka Platform V Audit SE (AUD) работает.

EmptyTagValueKeyException и ConcurrentModificationException в Platform V Audit SE (AUD) при запуске ПМ#

Ошибка не приводит к нарушению конфиденциальности и целостности информации, но приводит к нарушению доступности информации.

Неработоспособность метрик Platform V Audit SE (AUD).

Решение:

Перепроверить идентификаторы module, передаваемые в фабрику Platform V Audit SE (AUD). При наличии двух и более работающих модулей с одинаковым названием возникает конфликт при публикации клиентских метрик.

В веб-интерфейсе Platform V Audit SE (AUD) отображается ошибка 503 Сервер не отвечает#

Ошибка не приводит к нарушению конфиденциальности и целостности информации, но приводит к нарушению доступности информации.

При нажатии на Подробно выводится ошибка:

Не удалось выполнить операцию, т.к. не удалось зарегистрировать событие аудита о выполнении операции. {"code":"503.2","message":"Transport is not available, uuid_error = 87c1e0bc-92e5-4bdf-8a00-efeb0e5c5665","description":null}

Решение:

Ошибка сообщает о невозможности записать событие аудита в Kafka. Следует проверить доступность кластера Kafka (на которую нацелен audit client proxy), это наиболее частая проблема. Более подробную информацию можно получить из логов клиентского прокси (обратите внимание, что у каждого pod'a Proxy свои логи и ошибка будет только в логах того пода, который обрабатывал запрос). Ошибку можно найти с помощью uuid_error, который есть в тексте ошибки.

Дополнительно можно проверить конфигурацию в Kubernetes (при наличии доступа):

  1. Home - Search - Resources, в поле поиск ввести ServiceEntry, перейти в kafka-audit -> YAML найти host и port для Kafka.

  2. В Project проверить Config Maps для audit2-client-proxy. YAML -> найти host и port для Kafka.

    Данные host и port для Kafka в п.1 и п.2 должны быть одинаковые.

В веб-интерфейсе Platform V Audit SE (AUD) отображается ошибка 503 Сервер не отвечает#

Ошибка не приводит к нарушению конфиденциальности и целостности информации, но приводит к нарушению доступности информации.

При нажатии на Подробно выводится сообщение:

Не удалось выполнить операцию, т.к. не удалось зарегистрировать событие аудита о выполнении операции. upstream connect error or disconnect/reset before headers. reset reason: connection failure.

Решение:

Ошибка сообщает о невозможности записать событие аудита в Kafka. Следует проверить доступность кластера Kafka (на которую нацелен audit client proxy), это наиболее частая проблема. Более подробную информацию можно получить из логов клиентского прокси (обратите внимание, что у каждого pod'a Proxy свои логи и ошибка будет только в логах того pod, который обрабатывал запрос). Ошибку можно найти с помощью uuid_error, который есть в тексте ошибки.

Дополнительно можно проверить конфигурацию в Kubernetes (при наличии доступа):

  1. Home - Search - Resources, в поле поиск ввести ServiceEntry, перейти в kafka-audit -> YAML, найти host и port для Kafka.

  2. В Project проверить Config Maps для audit2-client-proxy. YAML -> найти host и port для Kafka. Данные host и port для Kafka в п.1 и п.2 должны быть одинаковые.

В веб-интерфейсе Platform V Audit SE (AUD) отображается ошибка 503 Сервер не отвечает#

Ошибка не приводит к нарушению конфиденциальности и целостности информации, но приводит к нарушению доступности информации.

При нажатии на Подробно выводится сообщение:

Ошибка при получении данных из Solr

Решение:

Ошибка сообщает о невозможности получить данные из Solr.

  1. Следует проверить доступность Solr, это наиболее частая проблема.

  2. Необходимо проверить, что конфигурация модуля audit2-admin заполнена корректно.

Более подробную информацию можно получить из логов модуля audit2-admin.

В веб-интерфейсе Platform V Audit SE (AUD) отображается ошибка 408 Превышен таймаут ожидания сервера#

Ошибка не приводит к нарушению конфиденциальности и целостности информации, но приводит к нарушению доступности информации.

При нажатии на Подробно выводится одно из сообщений:

  • Ошибка при получении данных из Solr

  • Нарушен формат взаимодействия с сервером

Решение:

Ошибка сообщает об одной из следующих проблем:

  1. Невозможно получить данные из Solr.

  2. Проблемы с Hadoop.

Для устранений неисправности необходимо выполнить следующие действия:

  1. Проверить доступность Solr, это наиболее частая проблема. Более подробную информацию можно получить из логов Solr.

  2. Если после выполнения п.1 проблема не устранена, проверить в UI Solr наличие aliases.

  3. Если после выполнения п.2 проблема не устранена, выполнить следующее:

    Если на Solr включен SSL, то необходимо проверить, что на серверах, где установлены backend и frontend Platform V Audit SE (AUD), размещены файлы сертификатов Solr. Важно: сертификаты должны быть размещены в папках с правами доступа 555 или выше (755, 777); solr.ssl.keystore.password должен совпадать с паролем, который был задан для ключа, хранящегося в keystore, т.е. при генерации keystore необходимо задать одинаковые пароли для keystore и для key. Настройки с указанием пути размещения файлов сертификатов и пароли указываются в конфигурации модуля audit2-admin.

В веб-интерфейсе Platform V Audit SE (AUD) отображается ошибка 503 Сервер не отвечает#

Ошибка не приводит к нарушению конфиденциальности и целостности информации, но приводит к нарушению доступности информации.

При нажатии на Подробно выводится сообщение:

Не удалось выполнить операцию, т.к. не удалось зарегистрировать событие аудита о выполнении операции. no healthy upstream.

Решение:

Ошибка сообщает о недоступности Proxy. Необходимо проверить доступность Proxy и Pod.

В веб-интерфейсе Platform V Audit SE (AUD) отображается ошибка 503 Сервер не отвечает#

Ошибка не приводит к нарушению конфиденциальности и целостности информации, но приводит к нарушению доступности информации.

При нажатии на Подробно выводится сообщение:

Не удалось выполнить операцию, т.к. не удалось зарегистрировать событие аудита о выполнении операции. I/O error on POST request for "<…>": Remote host closed connection during handshake; nested exception is javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake.

Решение:

Ошибка сообщает о недоступности Proxy.

Необходимо проверить работоспособность Proxy, в частности audit-istio-egress и audit-istio-ingressgw.

В веб-интерфейсе Platform V Audit SE (AUD) отображается ошибка 500 Внутренняя ошибка сервера#

Ошибка не приводит к нарушению конфиденциальности и целостности информации, но приводит к нарушению доступности информации.

При нажатии на Подробно выводится следующее сообщение:

\u041F\u0440\u043E\u0438\u0437\u043E\u0448\u043B\u0430 \u043D\u0435\u0438\u0437\u0432\u0435\u0441\u0442\u043D\u0430\u044F \u043E\u0448\u0438\u0431\u043A\u0430: 403 Forbidden. \u041E\u0431\u0440\u0430\u0442\u0438\u0442\u0435\u0441\u044C \u0432 \u0441\u043B\u0443\u0436\u0431\u0443 \u043F\u043E\u0434\u0434\u0435\u0440\u0436\u043A\u0438.

Решение:

Ошибка 500 сообщает, что доступ запрещен. Необходимо проверить сертификаты в Kubernetes.

В веб-интерфейсе Platform V Audit SE (AUD) нет описаний параметров или описаний событий#

Ошибка не приводит к нарушению конфиденциальности и целостности информации, но приводит к нарушению доступности информации.

Решение:

Причина может быть среди следующих:

  1. Не зарегистрирована метамодель.

  2. Производилась чистка таблицы метамоделей в Hbaseaudit:audit_metamodels. Это нештатная ситуация и недопустимая для любых стендов с потребителями.

  3. Недоступен HBase или таблица метамоделей в HBase.

  4. Метамодель зарегистрирована, но у отправляемого события и у метамодели не совпадают поля module и metamodelVersion.

  5. В метамодели нет события с кодом, с которым вы отправляете событие. Ситуация нештатная и маловероятная.

При отправке метамодели через egress c ОТТ возвращается ошибка HTTP 403#

Ошибка не приводит к нарушению конфиденциальности и целостности информации, но приводит к нарушению доступности информации.

При отправке метамодели через egress c ОТТ возвращается ошибка HTTP 403 feign.FeignException$Forbidden: [403 Forbidden] during [POST] to [<…>] [AuditProxyClient#sendMetamodel(AuditMetamodel)]: [com.<…>.ott.base.api.OttClientException: Hash of body is not valid.]

Решение:

Необходимо поправить фильтры ОТТ, чтобы можно было отправлять метамодель размером 2097152 (2 МБ).

{code}
kind: EnvoyFilter
metadata:
name: audit-istio-auth-filter
{code}
audit-proxy-ingress-template.yaml параметру *max_request_bytes* установить значение 2097152
{code}
kind: EnvoyFilter
metadata:
name: audit-egress-auth-filter
{code}
audit-proxy-egress-template.yml параметру *max_request_bytes* установить значение 2097152

Кроме того, если используются зависимости <artifactId>audit2-proxy-client-ott</artifactId> или <artifactId>audit2-proxy-client</artifactId>, то необходимо убедиться в том, что их версии актуальны.

В HDFS не закрываются файлы / В Hive не отображаются события.#

Ошибка не приводит к нарушению конфиденциальности и целостности информации, но приводит к нарушению доступности информации.

Решение:

  1. Проверить в конфигурации flume-hive для каждого из hdfsSink параметр hdfs.rollInterval = 3600 и rollcount=0 (значит файлы в папке tmp будут закрываться каждый час и перекладываться в /events_proxy_avro/%Y-%m-%d/ или /events_avro/%Y-%m-%d/). Если присутствует настройка idleTimeout = 600, то удалить.

  2. Проверить логи flume-hive на наличие ошибок. Если есть предупреждения/сообщения об отсутствии прав, то дать права администратора командой export HADOOP_USER_NAME=hdfs, добавить flume в группу hive командой sudo usermod -aG hive flume, дать права на папку hdfs dfs -chmod -R 775 /events_proxy_avro.

  3. На папках с датами должны быть права drwxrwxr-x.

    Такие права как drwxr-xr-x не подойдут, будет ошибка в логах flume-hive:

    Renaming file: /events_avro/2021-02-25//…/…/tmp/events_avro_tmp/EventsData-local.1614237644695.avro.tmp failed. Will retry again in 180 seconds.

    org.apache.hadoop.security.AccessControlException: Permission denied: user=flume, access=WRITE, inode="/events_avro/2021-02-25":hive:hive:drwxr-xr-x

У всех клиентов Audit-Proxy приходит ответ 403 Forbidden#

Ошибка не приводит к нарушению конфиденциальности и целостности информации, но приводит к нарушению доступности информации.

У всех клиентов Audit-Proxy приходит ответ 403 Forbidden.

Лог у Ingress pod без ошибок. В sidecar OTT на ingress много ошибок о неправильном токене. При этом с сертификатами все в порядке.

Решение:

Вариант 1:

В терминале пода ingress, контейнер istio-proxy выполнить команду:

curl localhost:15000/config_dump | grep ext_authz -A 10 -B 10

Убедиться, что фильтр один.

Завести заявку на администраторов тестового стенда и на подразделение, ответственное за компонент Istio.

Вариант 2:

Бывает, что у ISTIO для пространства имен Platform V Audit SE (AUD) появляется лишний EnvoyFilter, который отправляет весь трафик с обычного роута на проверку One-Time-Password (OTTS).

Проверить это можно в конфигурации нашего пода ingress. Зайти в его command line, и выполнить команды:

  • Скачать конфигурационный файл:

    curl -X POST 'http://localhost:15000/config_dump' >> /tmp/ingress-config-dump

  • Просмотреть конфигурационный файл:

    vi /tmp/ingress-config-dump

Найти в конфигурационном файле строку kind: EnvoyFilter. Таких строк должно быть столько же, и такие же, как в файле ingress-template.yml для данного стенда.

Чтобы передать данный конфигурационный файл другим людям, необходимо с какой-то физической машины отправить запрос "скачать конфигурацию" прямиком на Pod в OS. Сделать это можно с помощью Kubernetes Client:

  • Для Windows (опционально):

    oc exec <имя_пода> -c istio-proxy "curl -X POST http://localhost:15000/config_dump" 1> /tmp/ingress-config-dump

  • Для Linux:

    oc exec <имя_пода> -c istio-proxy "curl -X POST http://localhost:15000/config_dump" >> /tmp/ingress-config-dump

  • В терминале пода ingress контейнер istio-proxy:

    curl localhost:15000/config_dump | grep ext_authz -A 10 -B 10

Ошибка "Unrecognized SSL message, plaintext connection executing POST"#

Ошибка не приводит к нарушению конфиденциальности и целостности информации, но приводит к нарушению доступности информации.

При регистрации метамодели ошибка: Unrecognized SSL message, plaintext connection executing POST

Решение:

Platform V Audit SE (AUD) слушает порт 443. Нужно настроить Egress так, чтобы запрос пришел по 443 порту. По вопросам конфигурирования Egress следует обращаться к официальной документации или команде поддержке Istio.

Ошибка "TLS error" при регистрации метамодели#

Ошибка не приводит к нарушению конфиденциальности и целостности информации, но приводит к нарушению доступности информации.

При регистрации метамодели ошибка вида:

[2021-07-19T12:35:01.405Z] "POST /v2/metamodel/ HTTP/1.1" 503 UF,URX "-" "TLS error: 336130315:SSL routines:ssl3_get_record:wrong version number" 8287 91 1635 - "-" "Apache-HttpClient/4.5.12 (Java/1.8.0_191)" "689774f4-c8ea-99bb-b069-cba07eef4556" "<IP-адрес>" "<IP-адрес>:8080" outbound|8080||egressgateway-FQDN - <IP-адрес>:8080 <IP-адрес>:51568 - -
[2021-07-19T12:35:03.253Z] "POST /v2/metamodel/ HTTP/1.1" 503 UF,URX "-" "TLS error: 336130315:SSL routines:ssl3_get_record:wrong version number" 8287 91 93 - "-" "Apache-HttpClient/4.5.12 (Java/1.8.0_191)" "43168433-096a-923b-8c07-c45aacf002ca" "<IP-адрес>" "<IP-адрес>:8080" outbound|8080||egressgateway-FQDN - <IP-адрес>:8080 <IP-адрес>:51568 - -

Решение:

mTLS блокирует отправку запроса, необходимо отключить его.

Ошибка AuditSecurityException#

Ошибка не приводит к нарушению конфиденциальности и целостности информации, но приводит к нарушению доступности информации.

Ошибка аудита в логах фабрики: AuditSecurityException: User login wasn't specified:

com.sbt.audit2.security.AuditSecurityException: User login wasn't specified
                at com.sbt.audit2.AuditClientImpl.createOperation(AuditClientImpl.java:354
                at com.sbt.audit2.AuditClientImpl.auditOperation(AuditClientImpl.java:69)
                at ru.sbt.cs.audit.impl.AuditService.audit(AuditService.java:141)
                at ru.sbt.controllers.async.AsyncKafkaTransportControllerEdsAsyncImpl.auditMessage(AsyncKafkaTransportControllerEdsAsyncImpl.java:173)
                at ru.sbt.controllers.async.AsyncKafkaTransportControllerEdsAsyncImpl.sendMessageToCS(AsyncKafkaTransportControllerEdsAsyncImpl.java:152)
                at ru.sbt.controllers.async.AsyncKafkaTransportControllerEdsAsyncImpl.verify(AsyncKafkaTransportControllerEdsAsyncImpl.java:128)
                at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

Решение:

AuditSecurityException: User login wasn't specified.

Ошибка возникает, если нет информации о тикете или логине пользователя при создании операции аудита.

Данная ошибка возникает, если UserProvider, который вы передаете фабрике аудита при ее создании, возвращает null при вызове метода getUserLogin, и реализация UserProvider выполнена не на стороне Platform V Audit SE (AUD).

Ошибка с кодом 403 от UAEX#

Ошибка не приводит к нарушению конфиденциальности и целостности информации, но приводит к нарушению доступности информации.

События регистрируются корректно. При регистрации метамоделей из кода приложения в некоторых случаях возникает ошибка с кодом 403 от UAEX. Код ошибки:

[libprotobuf ERROR external/com_google_protobuf/src/google/protobuf/wire_format_lite.cc:584] String field 'envoy.service.auth.v2.AttributeContext.HttpRequest.body' contains invalid UTF-8 data when serializing a protocol buffer. Use the 'bytes' type if you intend to send raw bytes.
[2021-08-27T08:38:30.382Z] "POST /v1/metamodel HTTP/1.1" 403 UAEX "" 12397 0 1 - "<ip_хоста_с_клиентской_частью>" "Apache-HttpClient/4.5.13 (Java/1.8.0_272)" "ac5e1e2f-d9c9-4f15-9122-4dcac4717668" "audit.example.com" "-" - - <ip_хоста_с_клиентской_частью> <ip_хоста_с_клиентской_частью> - -

Решение:

Наиболее вероятно, в коде происходит конвертация данных в JSON, при конвертации в метамодель подставляются символы в кодировке, отличной от UTF-8.

Для локализации проблемы предложено:

  1. Выполнить curl на endpoint Platform V Audit SE (AUD) с пустым JSON метамодели.

  2. Выполнить curl на endpoint Platform V Audit SE (AUD) с метамоделью в виде JSON.

  3. Выполнить curl на endpoint Platform V Audit SE (AUD) с метамоделью в виде файла из исходников прикладного модуля.

Ошибка при построении дерева операций в пользовательском интерфейсе Platform V Audit SE (AUD)#

Ошибка не приводит к нарушению конфиденциальности и целостности информации, но приводит к нарушению доступности информации.

В UI Platform V Audit SE (AUD) при построении дерева операций получена ошибка:

Получение дерева операций с UUID 114650fd-7fe6-4b0e-9fee-0d8fb1c05bbf завершилось неуспешно: Ошибка при получении данных из HBase.

В логах flume Geo-Local-Flume-Operation и Geo-Remote-Flume-Operation ошибки вида:

[lifecycleSupervisor-1-2] Unable to start SinkRunner: { policy:org.apache.flume.sink.DefaultSinkProcessor@31943000 counterGroup:{ name:null counters:{} } } - Exception follows.
java.lang.IllegalArgumentException: Please call stop before calling start on an old instance.
         at com.google.common.base.Preconditions.checkArgument(Preconditions.java:122)
         at org.apache.flume.sink.hbase2.HBase2Sink.start(HBase2Sink.java:136)

Решение:

  1. Выполнить вход в HUE — HBase.

  2. Проверить наличие таблицы audit:audit_operations.

    При отсутствии данной таблицы не работает функциональность построения дерева операций.

Ошибка java.security.UnrecoverableKeyException#

Ошибка не приводит к нарушению конфиденциальности и целостности информации, но приводит к нарушению доступности информации.

В логах присутствуют записи вида "Caused by: java.security.UnrecoverableKeyException: Cannot recover key"

Решение: Это говорит о некорректно указанном пароле для хранилища. Необходимо проверить конфигурацию.

Ошибка в логах flume-solr#

Ошибка не приводит к нарушению конфиденциальности и целостности информации, но приводит к нарушению доступности информации.

В логах flume-solr ошибка:

[conf-file-poller-0] Sink eventsSolrSink2 has been removed due to an error during configuration
java.lang.IllegalStateException: Sink eventsSolrSink2 is not connected to a channel
        at org.apache.flume.node.AbstractConfigurationProvider.loadSinks(AbstractConfigurationProvider.java:460)
        at org.apache.flume.node.AbstractConfigurationProvider.getConfiguration(AbstractConfigurationProvider.java:106)
        at org.apache.flume.node.PollingPropertiesFileConfigurationProvider$FileWatcherRunnable.run(PollingPropertiesFileConfigurationProvider.java:145)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
        at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:748)

Решение:

Проверить, нет ли в конфигурации flume-solr placeholders {… вместо конкретных значений.

Рекомендации при обращении администратора в техническую поддержку#

При обращении с проблемами Platform V Audit SE (AUD) в техническую поддержку, администратору необходимо собрать следующую информацию:

  1. (обязательно) Логи того сервера, где выполняется модуль, у которого наблюдаются проблемы с Platform V Audit SE (AUD).

  2. (обязательно) Логи Flume, которые можно получить через Kafka (сервис Flume).

Дополнительно администратору при обращении к технической поддержке необходимо указать:

  1. (желательно, но не обязательно) Наименование стенда/среды, где установлен Platform V Audit SE (AUD).

  2. (обязательно) Адрес Apache Ambari, к которому подключен стенд/среда, а также (желательно, но не обязательно) логин и пароль для доступа.

  3. (обязательно) Адрес интерфейса пользователя Platform V Audit SE (AUD), а также (желательно, но не обязательно) логин и пароль для доступа.