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

Поскольку устранение неполадок начинается с того, что база данных находится в затруднении, нам сначала необходимо определить, какова фактическая проблема (неисправность). Одно из наших действий в отношении этого - вход в файлы журнала и трассировки, связанные с экземпляром базы данных. В средах Real Application Cluster (RAC) это становится более сложным и утомительным, так как существует множество файлов журнала (трассировки), связанных с кластеризацией, а также экземпляров базы данных, которые будут иметь полезные данные о проблеме. Представьте, что вам сообщили, что существует проблема с базой данных RAC, работающей в системе Exadata, работающей на 6 вычислительных узлах. Какие файлы журналов следует проверять в первую очередь, на каком узле и на что следует обратить внимание, чтобы понять, что происходит?

Интеллектуальный мониторинг

Что, если система мониторинга была бы немного умнее и просто показывала бы вам на одной странице соответствующие выдержки из всех файлов журналов (файлов трассировки) одновременно? Это может быть полезно, чтобы помочь вам быстро понять, что на самом деле происходит в данный момент, а также поможет в последующем анализе основных причин.

Используемая теория

Поэтому одна вещь, которая, как я думал, может быть полезной и попытаться сделать концептуальным решением, - это модель машинного обучения / глубинного обучения, называемая sequence to sequence (seq2seq). Обычно она используется для перевода языка, суммирования текста, распознавания речи и автоматического ответа на вопросы. В этом случае моя идея заключается в использовании так называемой конфигурации автокодера.

Говоря о ML  и DL, на очень высоком уровне, модели последовательности изучают последовательности (чисел, текста, звука ..) и могут предсказать следующий элемент в последовательности. Модель Seq2seq учится представлять последовательность в виде вектора меньшей размерности (заданной датчиком), в то время как декодер учится генерировать другую последовательность из этого вектора. Поэтому механизму перевода задается ряд предложений (последовательностей) на одном языке и другом. Для autoencoder мы даем ему то же предложение, что и источник и цель, поэтому он в основном учится воссоздавать предложения, подобные тем, которые были даны во время обучения.

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

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

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

Чтобы сделать вывод более полезным, я использовал алгоритм кластеризации ML, называемый Mean Shift, чтобы автоматически группировать те строки журнала, которые произошли примерно в одно и то же время (используя метку времени из журнала). Мы можем рассматривать сгруппированные таким образом кластеры как отдельные инциденты, которые произошли в течение некоторого времени (отметка времени центральной точки в конкретном кластере журнальных строк). Группировка может быть улучшена путем группировки определенными словами или фразами с использованием того же алгоритма.

Реализация базовой концепции

Чтобы быстрее экспериментировать с этим, я использовал сервис ML / DL в AWS под названием SageMaker, который предлагает предварительно построенный алгоритм Seq2Seq с возможностью использования из коробки:

Я экспериментировал с использованием файлов трассировки присоединенной процедуры  Oracle High Availability Service (ohasd.trc), но он должен иметь возможность работать с любым файлом журнала или трассировки (конечно, его нужно обучить «понимать» этот тип файла).

Обучение модели

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

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

Нам нужно разделить файл ohasd.trc для обучения и проверки:

head -n 32750 ohasd.trc > ohasd.trc.train
tail -n 8188 ohasd.trc > ohasd.trc.test

Затем маркируйте файлы трассировки (разделяйте отдельные слова и преобразуйте их в числа), чтобы их можно было усвоить моделью se2seq. AWS предоставляет для этого скрипт python, но я его модифицировал, поэтому он просто использует маркеры, которые не содержат специальных символов и чисел, поэтому для модели ML будет легче обучаться (у них будет меньше предметов в словаре и предложения будут меньше, чтобы модели seq2seq было легче их воссоздать):

python3 create_vocab_proto.py

Мы загружаем файлы на S3, поэтому SageMaher может его использовать.

Учебное задание с этими параметрами можно создать и запустить:

…

create_training_params = {
       ..
       "HyperParameters": {
       "max_seq_len_source": "20",
       "max_seq_len_target": "20",
       "optimized_metric": "bleu",
       "batch_size": "256",        "checkpoint_frequency_num_batches": "1000",
       "rnn_num_hidden": "512",
       "num_layers_encoder": "3",
       "num_layers_decoder": "3",
       "num_embed_source": "512",
       "num_embed_target": "512",
       "checkpoint_threshold": "3"

Как видно, мы оптимизируем метрику BLEU, которая используется для сравнения двух предложений для их сходства. После создания и запуска учебного задания можно создать конечную точку, чтобы эта модель могла использоваться по запросу HTTP из любого места, и нам не нужно устанавливать библиотеки python ML на фактическом сервере базы данных. Конечные точки запускаются на экземпляр ec2 в фоновом режиме (которым мы не управляем), но нам выставлен счет до тех пор, пока конечная точка работает для этого экземпляра ec2.

Некоторые результаты

Мы создали скрипт, который будет читать строки из файла ohasd.rc и отправлять их в созданную конечную точку. Конечная точка SageMaker может использоваться так же, как и обычный вызов API REST с использованием http.

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

Алгоритм по-прежнему показал довольно много строк журнала, что, по его мнению, необычно, поэтому сделать вывод более полезным, как упоминалось ранее, можно с использованием Mean Shift (используется библиотека scythit-learn python). Он сгруппировал строки с близлежащей меткой времени, поэтому в основном события, произошедшие рядом друг с другом, предположительно принадлежат к одному и тому же инциденту. Столбец «Cluster n:» указывает, к какой группе (кластеру) строк относятся строки - значение, к которому относится связанное событие, где «n» - номер этой группы.

Аномалии, обнаруженные и сгруппированные в  Cluster 0, похоже, не являются чем-то, что может нас волновать, поэтому мы можем дополнительно обучать классификатор, чтобы просто игнорировать аномалии. Для “Cluster 2” ASM, похоже, снижается. Это может развиваться и далее, поэтому система автоматически суммирует в заметке на высоком уровне, о том, что произошло, или даже дает некоторые основные причины, поэтому, когда DBA подключается к устранению неполадок, он или она будет знать, где начать и что происходит:

Cluster 0: |ORIG: | 2018-01-02 17:47:21.379 :OHASDMAIN:57868352:  OHASD params []
Cluster 0: |ORIG: | 2018-01-02 17:47:21.379 :OHASDMAIN:57868352:  Socket cleanup:0x49bde30
Cluster 0: |ORIG: | 2018-01-02 17:47:21.379 :OHASDMAIN:57868352:  Got [0] potential names
Cluster 0: |ORIG: | 2018-01-02 17:47:21.383 :  OCRRAW:57868352: proprioo: for disk 0 (/u01/grid/cdata/localhost/ip-172-31-86-123.olr), id match (1), total id sets, (1) need recover (0), my votes (0), total votes (0), commit_lsn (1), lsn (1)
Cluster 0: |ORIG: | 2018-01-02 17:47:21.383 :  OCRRAW:57868352: proprioo: my id set: (1777565868, 1028247821, 0, 0, 0)
Cluster 0: |ORIG: | 2018-01-02 17:47:21.383 :  OCRRAW:57868352: proprioo: 1st set: (1777565868, 1028247821, 0, 0, 0)
Cluster 0: |ORIG: | 2018-01-02 17:47:21.383 :  OCRRAW:57868352: proprioo: 2nd set: (0, 0, 0, 0, 0)
Cluster 0: |ORIG: | 2018-01-02 17:47:21.387 :  OCRAPI:57868352: a_init:18: Thread init successful
Cluster 0: |ORIG: | 2018-01-02 17:47:21.387 :  OCRAPI:57868352: a_init:19: Client init successful
Cluster 0: |ORIG: | 2018-01-02 17:47:21.388 :OHASDMAIN:57868352:  Version compatibility check passed: Software Version: 12.2.0.1.0 Release Version: 12.2.0.1.0 Active Version: 12.2.0.1.0
Cluster 0: |ORIG: | 2018-01-02 17:47:21.392 : CRSMAIN:57868352:  Logging level for Module: GIPCBASE 0
Cluster 0: |ORIG: | 2018-01-02 17:47:21.396 :   CRSPE:57868352: ...done : 0
Cluster 0: |ORIG: | 2018-01-02 17:47:21.396 :OHASDMAIN:57868352:  Initializing ubglm...

Cluster 2: |ORIG: | 2018-02-02 13:00:44.538 :    AGFW:2113812224: {0:7:16} Verifying msg rid = ora.asm ip-172-31-86-123 1
Cluster 2: |ORIG: | 2018-02-02 13:00:44.538 :    AGFW:2113812224: {0:7:16} Received state LABEL change for ora.asm ip-172-31-86-123 1 [old label  = Started, new label = Abnormal Termination]
Cluster 2: |ORIG: | 2018-02-02 13:00:44.538 :   CRSPE:2101204736: {0:7:16} State change received from ip-172-31-86-123 for ora.asm ip-172-31-86-123 1
Cluster 2: |ORIG: | 2018-02-02 13:00:44.539 :   CRSPE:2101204736: {0:7:16} Processing unplanned state change for [ora.asm ip-172-31-86-123 1]
Cluster 2: |ORIG: | 2018-02-02 13:00:44.539 :   CRSPE:2101204736: {0:7:16} Scheduled local recovery for [ora.asm ip-172-31-86-123 1]
Cluster 2: |ORIG: | 2018-02-02 13:00:44.540 :   CRSPE:2101204736: {0:7:16} RI [ora.asm ip-172-31-86-123 1] new internal state: [CLEANING] old value: [STABLE]
Cluster 2: |ORIG: | 2018-02-02 13:00:44.540 :   CRSPE:2101204736: {0:7:16} state change vers moved to 6 for RI:ora.asm ip-172-31-86-123 1
Cluster 2: |ORIG: | 2018-02-02 13:00:44.540 :   CRSPE:2101204736: {0:7:16} Sending message to agfw: id = 50979
Cluster 2: |ORIG: | 2018-02-02 13:00:44.540 :   CRSPE:2101204736: {0:7:16} CRS-2679: Attempting to clean 'ora.asm' on 'ip-172-31-86-123'
Cluster 2: |ORIG: | 2018-02-02 13:00:44.547 :    AGFW:2113812224: {0:7:16} ora.orcl.db 1 1 received state from probe request. Old state = ONLINE, New state = ONLINE
Cluster 2: |ORIG: | 2018-02-02 13:00:44.547 :    AGFW:2113812224: {0:7:16} ora.orcl.db 1 1 received state from probe request. Old state = ONLINE, New state = ONLINE
Cluster 2: |ORIG: | 2018-02-02 13:00:44.547 :   CRSPE:2101204736: {0:7:17} ora.DATA.dg ip-172-31-86-123 1: uptime exceeds uptime threshold , resetting restart count
Cluster 2: |ORIG: | 2018-02-02 13:00:44.547 :   CRSPE:2101204736: {0:7:17} Scheduled local recovery for [ora.DATA.dg ip-172-31-86-123 1]
Cluster 2: |ORIG: | 2018-02-02 13:00:44.552 :    AGFW:2113812224: {0:7:17} ora.orcl.db 1 1 received state from probe request. Old state = ONLINE, New state = ONLINE
Cluster 2: |ORIG: | 2018-02-02 13:00:46.551 :    AGFW:2113812224: {0:7:18} Verifying msg rid = ora.orcl.db 1 1
Cluster 2: |ORIG: | 2018-02-02 13:00:46.551 :    AGFW:2113812224: {0:7:18} Received state LABEL change for ora.orcl.db 1 1 [old label  = Open,HOME=/u01/app/oracle/product/12.2.0/db, new label = Abnormal Termination,HOME=/u01/app/oracle/product/12.2.0/db]
Cluster 2: |ORIG: | 2018-02-02 13:00:46.552 :   CRSPE:2101204736: {0:7:18} State change received from ip-172-31-86-123 for ora.orcl.db 1 1

No Comments