OpenSearch для 1Сников. Как использовать бесплатный ElasticSearch, не теряя времени, нервы и качество

Меня зовут Айдар Сафин. Я главный разработчик в центре экспертизы 1С Magnit Tech. Хочу рассказать, как мы в Магните используем бесплатный OpenSearch для обработки сотен гигабайт логов из 1С.

 

До появления OpenSearch мы для анализа технологических журналов 1С использовали:

• Notepad++.

• Скрипты с регулярными выражениями.

• Обработки 1С для работы с техжурналом 1С.

Это было долго, сложно и не очень удобно.

С появлением OpenSearch анализ технологических журналов у нас стал легкодоступен практически всем: администраторам 1С, разработчикам и даже аналитикам. Ранее детальный произвольный анализ техжурнала был легкодоступен практически только экспертам.

OpenSearch позволяет анализировать информацию на основе логов техжурнала 1С – создавать из нее дашборды, визуализации и мониторы с алертингами.

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

Сама тема «ElasticSearch + 1С» в сообществе 1С-ников развивается уже много лет, но я хочу поделиться опытом компании Magnit Tech и показать несколько новых фишек, которые еще не рассматривались:

• Расскажу о наших кейсах анализа данных на основе техжурнала в OpenSearch.

• Рассмотрим установку OpenSearch в Docker на Debian Linux.

• Поговорим о том, как в OpenSearch настроить доменную аутентификацию.

• Посмотрим, как настроить алертинг встроенными средствами OpenSearch без использования дополнительных инструментов.

 

Опыт Магнита

 

В Магните на OpenSearch настроено 14 дашбордов, 42 визуализации и 10 мониторов с алертингами.

 

 

Сама инфраструктура у нас построена следующим образом:

• У нас есть 72 сервера приложений 1С.

• На всех этих серверах включен сбор логов техжурнала – они складываются в локальную папку.

• На каждом сервере приложений запущена служба Filebeat, которая анализирует логи из этой папки и отправляет новые изменения на сервер OpenSearch.

• На сервере OpenSearch данные из логов нормализуются и записываются во внутреннюю базу данных – в так называемые «индексы», которые являются аналогом таблицы в реляционной СУБД.

 

Сами характеристики серверов приложений 1С я приводить не буду, они соответствуют стандартным рекомендациям. Более интересно поделиться характеристиками сервера, на котором работает сам OpenSearch. На нем у нас:

• 8 ядер процессора по 3 ГГц каждое.

• 110 ГБ оперативной памяти.

• Размер индексов на диске составляет 1,5 ТБ.

Загрузка оперативной памяти у нас стабильно составляет 80%, а процессора – в среднем 50%.

И при том, что устаревшая информация из индексов OpenSearch периодически автоматически вычищается, ежедневно в индексах появляется до 100 ГБ новой информации.

 

Правильная настройка сбора технологического журнала

 

Прежде, чем анализировать техжурнал в OpenSearch, его нужно правильно настроить. Причем это правило справедливо не только для OpenSearch, но и для любого анализа техжурналов 1С.

При настройке технологического журнала 1С нужно ограничить по времени события DBPOSTGRS, DBMSSQL, SDBL, SCALL, TLOCK.

Если этого не сделать, то:

• Во-первых, на относительно большом проекте логи в течение нескольких минут могут вырасти до десятков и даже сотен гигабайт.

 

• Во-вторых, может просесть производительность операций ввода-вывода. Мы сделали специальный тест – здесь он выполняется и для левой, и для правой части графика. В обоих случаях включен сбор техжурнала, но слева он включен правильно, а справа – неправильно (включен сбор на все события без ограничений по времени).

 

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

 

Кейс №1: ADMIN action monitor

 

У нас стояла задача – при любых изменениях настроек в кластере серверов 1С администраторам 1С нужно отправлять оповещение на почту и в Telegram.

 

Технологический журнал 1С позволяет отследить следующие события:

• изменение параметров рабочего сервера;

• изменение требований назначения функциональности;

• удаление или попытка удаления базы.

Все эти примеры относятся к событию технологического журнала ADMIN.

Поэтому для отслеживания этих событий первое, что мы должны сделать – это включить сбор логов по событию ADMIN, добавить в ТЖ тег <event>, содержащий <eq property=”Name» value=”ADMIN» />

 

 

Обратите внимание, что в шаблоне файла logcfg.xml также есть настройка для получения записей подсистемы мониторинга кластера – сбор логов по событию ATTN, о нем я расскажу в другом кейсе, но нужно обратить внимание, что он включается здесь.

 

 

Когда я рассказывал про нашу инфраструктуру, я говорил, что Filebeat анализирует новые логи и отправляет их на сервер OpenSearch, где они записываются во внутреннюю базу данных – в так называемые индексы.

Если мы зайдем в OpenSearch Dashboards и перейдем в раздел Index Management –> Indices, то увидим здесь специальный индекс techlog-admin – события технологического журнала ADMIN собираются именно в него.

 

Если бы мы открыли файл лога технологического журнала в Notepad++ и попытались его проанализировать, то увидели бы в тексте события ADMIN свойства Func=dropInfoBase либо Func=setServiceAssociationRule.

 

 

В OpenSearch все это анализировать и смотреть гораздо удобнее.

Напомню, наша задача – создать монитор, который будет отслеживать изменения настроек в кластере 1С по событию ADMIN, и отправлять оповещение на почту и в Telegram администраторам 1С.

Но, прежде чем создать монитор, мы должны убедиться, что наши данные присутствуют в OpenSearch. Для этого мы можем зайти в специальный раздел Discover (Обнаружитель) и установить здесь отбор:

• период – last 7 days, последние семь дней;

• event – ADMIN, событие технологического журнала ADMIN;

• уточняем, что свойство события Func одно из:

  • dropInfoBase – удаление информационной базы;

  • setServiceAssociationRule – изменения требования назначения функциональности.

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

Кроме этого, желательно выбрать для результата только нужные поля (Selected Fields), чтобы у нас не вываливались все поля технологического журнала

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

 

 

Далее мы переходим в раздел Alerting и на закладке Monitors создаем ADMIN action monitor.

 

 

При создании или изменении монитора в его настройках у нас есть специализированное поле Query, где мы в формате JSON с помощью доменно-ориентированного языка запросов (DSL) пишем запрос, который будет выбирать данные из наших индексов в OpenSearch.

Ключевое, что мы здесь должны указать – это установить:

"match_phrase": {
	"event": {
		"query": "ADMIN",
		"slop": 0,
		"zero_terms_query": "NONE",
		"boost": 1
	}

А ниже мы аналогичным образом перечисляем все нужные нам значения свойств Func – добавляем такую же секцию с "query": "dropInfoBase" и т.д.

Таким образом мы строим запрос отбора событий ADMIN из наших индексов в OpenSearch.

 

 

В нижней части настроек монитора есть разделы Triggers и Actions – триггеры и действия.

Создаем триггер и в поле Trigger condition Info указываем его состояние, например:

ctx.results[0].hits.total.value > 0

Такое условие означает, что этот триггер сработает, если запрос, который мы указали в Query, вернет одно или несколько событий. Чтобы он не срабатывал вхолостую, нужно настроить Actions, действия.

В данном случае у нас настроено два действия:

1. Custom webhook: inform in TG – информировать в Telegram.

2. Email notification: inform_Admins – отправлять на почту.

Actions относятся к алертингу, и про их настройку я расскажу чуть позже.

 

 

В результате на вкладке Alerts раздела Alerting мы можем смотреть статистику – когда админам были отправлены оповещения на почту и в Telegram.

 

Кейс №2: Usage CPU by Server/base

 

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

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

 

Кейс №3: Дашборд CALL

 

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

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

Мы открыли в OpenSearch наш дашборд CALL и увидели, что одна форма объекта документа за 17 вызовов потребила очень большое количество оперативной памяти. Стали разбираться и увидели, что причина действительно была в ней.

 

На этом дашборде также есть статистика вызовов CALL по процессору и операциям ввода-вывода – таким образом он позволяет нам понять проблемы с утилизацией процессора и оперативной памяти.

 

Кейс №4: Дашборд TLOCK_analytics

 

С помощью дашборда TLOCK_analytics мы отслеживаем топ таблиц по блокировкам.

 

 

Здесь можно смотреть статистику по блокировкам в разрезе сервера, базы, либо в целом по всем серверам и всем базам. Видно, какие конкретно таблицы в топе по блокировкам.

 

Если перемотать этот дашборд чуть ниже, можно увидеть более детальную информацию:

• период;

• пользователь, у которого возникла эта блокировка;

• таблица;

• и, что немаловажно, значение WaitConnections – идентификатор соединения, ожидание которого вызвало эту блокировку.

Прямо отсюда понимаем причину блокировки и дальше можем что-то с этим делать.

 

Кейс №5: Discover событий ATTN

 

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

 

 

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

Мы обратились к OpenSearch. Сначала отловили эту ошибку по дате и времени, а потом поставили в Discovery отбор по event: ATTN, и стали смотреть все ATTN, предшествующие этой ошибке.

В результате увидели событие, которое срабатывает при превышении объема памяти, указанного в настройке рабочего сервера «Безопасный расход памяти за один вызов». Но хостом в этом событии являлся не тот сервер, где падали сеансы, а сервер лицензирования.

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

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

Вывод: мониторить события ATTN – хорошая практика, она позволяет понять, что не так с вашим сервером приложений 1С.

 

Кейс №6: Импортозамещение

 

Мы активно переводим наши базы с MS SQL на Postgres, и в этом нам частично помогают эти две визуализации:

• PG_migration_top_query

• Max count SDBL events

 

Для визуализации PG_migration_top_query настроен отбор по событию DBMSSQL и выводится топ запросов по параметрам Count и Sum of duration.

 

А вторая визуализация Max count SDBL events – такая же, только отбором по событию SDBL.

Эти две визуализации нам помогают проводить аудит, когда мы принимаем решение о переводе конфигурации с MS SQL на Postgres.

 

Кейс №7: Жалобы пользователей

 

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

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

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

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

OpenSearch позволил нам решить эту проблему очень быстро и легко.

 

Как установить и использовать OpenSearch в Docker

 

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

• OpenSearch – это бесплатный приемник ElasticSearch.

• OpenSearch Dashboards – это преемник Kibana, почти то же самое, что Kibana.

Как ставить OpenSearch на Windows, я показывать не буду, потому что это достаточно просто. Более интересно показать, как его ставить в Docker на Debian Linux.

Первое, что нужно сделать – выполнить важные настройки хоста. Если вы это не сделаете, то ваши контейнеры Docker могут либо перестать работать, либо начнут работать нестабильно, либо в какой-то момент они просто перестанут запускаться.

С помощью команды

sudo swapoff -a

отключаем подкачку памяти.

Далее увеличим количество памяти, доступного для OpenSearch, отредактировав файл конфигурации sysctl:

sudo nano /etc/sysctl.conf

В файл sysctl нужно добавить (или изменить) параметр vm.max_map_count, установив ему желаемое значение, например:

vm.max_map_count=262144

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

sudo sysctl -p

Проверяем, что значение vm.max_map_count изменилось, командой:

cat /prop/sys/vm/max_map_count

Вторым шагом мы ставим Docker и Docker-compose. Здесь тоже ничего сложного нет. В качестве способов установки можно использовать инструкции:

• Инструкция установки docker

• Инструкция установки docker-compose

Третий шаг – подготовка файла docker-compose.yml.

Например, мы взяли стандартный docker-compose.yml из документации и модифицировали его, потому что у нас возник ряд кейсов.

 

 

Поясню, что мы тут поменяли:

• В качестве образа OpenSearch мы используем
  opensearchproject/opensearch:latest
  Предупрежу, что указывать latest желательно только на непродуктивной среде, а если будете указывать на продуктивной, лучше зафиксировать конкретную версию, например, указать
  opensearchproject/opensearch:2.9.0

• Добавили инструкцию:
  restart: always
  чтобы докер-контейнер openSearch автоматически восстанавливался после падения или перезагрузки хоста.

• Следующая важная настройка здесь:
  compatibility.override_main_response_version=true
  Она включает совместимость OpenSearch с разными версиями Filebeat. Если ее не указать, то у вас OpenSearch с некоторыми версиями Filebeat OSS работать не будет.

• Настройка:
  plugins.security.restapi.roles_enabled=["all_access"]
  означает, что мы включаем API-доступ к плагинам безопасности. Это позволяет расширить способы настройки через API самого OpenSearch.

• И строкой:
  "OPENSEARCH_JAVA_OPTS=-Xms88g -Xmx88g"
  мы можем указать, сколько оперативной памяти можно расходовать нашему OpenSearch. В нашем случае мы установили для него лимит 88 гигабайт.

Полный файл docker-compose.yml вы можете взять из нашего репозитория magnit-opensearch-1c на GitHub.

 

Еще из интересного: в файле docker-compose.yml есть раздел volumes. Здесь мы указываем, какие папки и файлы мы прокидываем из контейнера на хост. Эти папки и файлы мы будем использовать на хосте, а не внутри контейнера.

• К примеру, мы здесь пробрасываем путь к папке data. Слева указывается путь к ней на хосте, к примеру:
  var/elk/data
  а справа – внутри контейнера
  usr/share/opensearch/data
  Мы таким образом подменяем, выносим ее на хост.

• Задаем пути к конфигурационным файлам: config.yml, roles_mapping.yml, internal_users.yml.

• Выносим на хост хранилище ключей opensearch.keystore.

• И хранилище Java – jdk-lib-security

 

Кроме этого, мы выносим на хост конфигурационный файл jvm.options – у нас используется корпоративный прокси, и чтобы отправлять оповещение в Telegram через прокси, мы указываем эти настройки в файле jvm.options.

 

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

Четвертый шаг – запускаем контейнеры через docker-compose.

И после того, как мы сконфигурировали docker-compose.yml мы запускаем его из папки, где он находится, командой:

docker-compose up -d

При первом запуске образы, прописанные в docker-compose.yml, будут скачаны и установлены с указанными для них там же параметрами.

 

Обновление конфигурационного файла для уже подключенного контейнера

 

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

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

docker ps

 

Выводится список всех контейнеров и их ID. Далее пишем команду:

docker exec -it [ID_контейнера] /bin/bash

Таким образом мы подключаемся именно к корню контейнеров.

 

Если мы что-то поменяли в конфигурационных файлах, нужно выполнить специальный скрипт. Если мы этого не сделаем – просто изменим что-то в конфигурационных файлах yml и перезапустим хост – никакие изменения в OpenSearch не попадут. Нужно выполнить специальный скрипт securityadmin.sh, указав для него в качестве значения параметра -f путь к конфигурационному файлу внутри контейнера:

/usr/share/opensearch/plugins/opensearch-security/tools/securityadmin.sh -f \
/usr/share/opensearch/config/opensearch-security/config.yml -icl -nhnv \
-cacert /usr/share/opensearch/config/root-ca.pem \
-cert /usr/share/opensearch/config/kirk.pem \
-key /usr/share/opensearch/config/kirk-key.pem \

Только после этого наши изменения попадут в специальные служебные индексы OpenSearch, которые связаны с настройками.

 

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

./securityadmin.sh \
-cd /usr/share/opensearch/config/opensearch-security/ -icl -nhnv \
-cacert ../../../config/root-ca.pem \
-cert ../../../config/kirk.pem \
-key ../../../config/kirk-key.pem

Так же пишем: securityadmin.sh -cd и путь к каталогу, конфигурационные файлы которого должны быть применены к настройкам OpenSearch.

 

Доменная аутентификация в OpenSearch

 

Расскажу, как реализовать доменную аутентификацию в OpenSearch.

 

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

Чтобы организовать в OpenSearch доменную аутентификацию, нужно отредактировать файлы config.yml и roles_mapping.yml – по умолчанию они находятся в каталоге:

/usr/share/opensearch/config/opensearch-security

 

 

Прежде чем редактировать config.yml, вы должны точно понимать структуру вашего Active Directory. В частности, у нас был случай: не могли понять, почему не работает авторизация, выяснилось, что пользователь находился в другой папке AD.

Возможности отладки параметров LDAP зависят от используемой ОС:

• На Windows-машине можно воспользоваться специальной утилитой NetTools. Там есть LDAP Browser и LDAP Search, где вы можете посмотреть структуру вашего Active Directory и понять, как вам нужно будет задавать строки соединения с Active Directory через LDAP.

• Если вы работаете с Linux-машиной или просто хотите отлаживать на хосте, то вы можете воспользоваться LDAPUtils. Это консольная утилита, которая все делает в командном режиме. Например, там тоже есть команда LDAP Search.

 

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

Первый файл – config.yml. Здесь редактируем раздел ldap, устанавливая:

http_enabled: true
transport_enabled: true.

А также задаем для этого типа аутентификации порядок:

order: 1

Это нужно, потому что OpenSearch поддерживает несколько видов аутентификации, а мы хотим, чтобы доменка шла первой.

 

После этого в файле config.yml в качестве параметра hosts указываем сам сервер LDAP и его порт через двоеточие.

Так как все запросы отправляются из-под сервисной учетной записи, в параметрах bind_dn и password задаем данные сервисной учетной записи.

В bind_dn указываем:

• CN – имя сервисной учетной записи,

• а сам путь в Active Directory через LDAP мы пишем в иерархическом виде справа налево:

  • справа в параметрах DC – имя домена,

  • потом в параметрах OU – папку и подпапку (Users – это та папка, в которой у нас лежит сервисная учетная запись).

 

Далее в файле config.yml задаем параметры аутентификации:

• userbase – в нем мы указываем конкретно ту верхнеуровевую папку, где лежат все наши пользователи. Если у вас верхнеуровневая папка означает организацию и делится потом на подпапки по всем отделам, то нужно указать именно самую верхнюю папку, и запрос LDAP будет искать во всех вложенных.

• usersearch – фактический запрос LDAP, который выполняет подключаемый модуль безопасности при попытке аутентификации пользователя. Переменная {0} будет заменена на тот логин, который будет уже вводиться при аутентификации в OpenSearch – в поле, где вводятся логин и пароль.

 

Теперь рассмотрим, какие настройки нужно сделать для файла roles_mapping.yml.

Здесь мы просто сопоставляем группы Active Directory с ролями в Elastic (Elastic и OpenSearch – это, по сути, одно и то же).

Например, сопоставляем роль all_access в OpenSearch с группой в Active Directory 1c_elastic_admins.

all_access:
reserved: false
backend_roles:
- "admin"
- "1c_elastic_admins"

Таким же образом делается сопоставление и с группами с ограничением доступа.

 

Алертинг

 

Когда мы рассматривали кейс ADMIN action monitor, я обещал рассказать про настройку Action и раздел Alerting.

OpenSearch позволяет настраивать оповещения без использования сторонних фреймворков только с помощью своих собственных средств.

 

Первый шаг – настроим оповещения на почту, создадим отправителя и зададим его данные.

Заходим в Notifications –> Email senders –> Create SMTP sender.

Указываем данные email, хост, порт и метод шифрования – обычно, TLS.

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

Для этого по очереди выполняем две команды. Первая:

./bin/opensearch-keystore add \
opensearch.notifications.core.email.<sender_name>.username

Вторая:

./bin/opensearch-keystore add \
opensearch.notifications.core.email.<sender_name>.password

Только после этого у нас будут работать оповещения.

Кроме этого, мы должны в само хранилище Java jdk добавить корневой и промежуточный сертификаты почтового сервера. Это также нужно сделать двумя командами:

/usr/share/opensearch/jdk/bin/keytool -import -trustcacerts -alias root -cacerts -file /usr/share/opensearch/data/RootCA.crt

/usr/share/opensearch/jdk/bin/keytool -import -trustcacerts -alias intermediate -cacerts -file /usr/share/opensearch/data/CorpCA.crt

В процессе импорта команда запросит ввести пароль.

Для хранилища cacerts пароль по умолчанию: changeit.

На вопрос «Trust this certificate?» отвечаем yes.

 

Следующий шаг – создание в OpenSearch группы получателей.

Этого можно не делать, но для удобства лучше сделать, потому что обычно бывает, например, группа «Админы 1С», группа «ЗУП» и так далее. Мы можем сразу их задать.

Заходим в Create recipient group, задаем имя группы – допустим, «Администраторы ЗУП» – и перечисляем все их email. И потом мы сможем выбирать эту группу уже в каналах.

 

Следующий шаг – мы создаем канал для отправки почты.

Раньше в Open Distro для этой цели использовались destination, в OpenSearch появилось нововведение, ввели каналы. Но, по сути, это то же самое, что destinations.

Для создания канала мы должны зайти в Notifications –> Channels –> Create channel.

Сюда вводим имя канала, например «Сопровождение 1С; Администраторы», выбираем тип – email и ставим переключатель SMTP sender.

 

После того как мы создали канал, мы можем вернуться к самому монитору и его Actions.

Настроим Action, который относится к отправке почты.

• Мы здесь пишем его имя – например, Inform_Admins

• В поле Channels выбираем только что созданный канал

• В поле Message subject задаем тему письма – например, «На сервере 1С выполнено действие ADMIN».

• А в поле Message – сам текст письма.

 

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

 

Настроим второй Action – для оповещений в Telegram.

Первое, что мы делаем – так же создаем канал. Заходим в Notifications –> Channels –> Create channel.

• Тип канала выбираем – Custom webhook,

• Method – POST

• Ставим переключатель Webhook URL.

• В сам Webhook URL вставляем обращение к боту, который будет доставлять оповещение, через API Telegram. Чтобы получить эту строку, мы должны в Telegram создать бота, определить его Webhook URL, вставить его сюда и в конце добавить команду sendMessage. Таким образом, когда у нас сработает триггер и выполнится Action, вызовется эта строка.

 

Далее мы возвращаемся к монитору и здесь уже настраиваем Action – действие для отправления в Telegram.

• Здесь мы пишем имя – допустим, Inform in TG.

• И выбираем только что созданный канал.

 

В поле Message вставляем сообщение в формате JSON с двумя полями:

• text – сюда вставляется текст, похожий на то, что мы писали для почты;

• chat_id – ID канала, который используется для мониторинга серверов.

Когда срабатывает триггер и Action для Telegram, то OpenSearch понимает, что нужно вызвать этот Webhook URL, а Telegram-бот понимает, что ему нужно отправить это сообщение в тот чат, который указан в chat_id.

 

 

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

 

Материалы и ссылки

 

Мы рассмотрели, как можно эффективно использовать OpenSearch.

Еще раз продублирую все ссылки, которые я приводил в публикации:

• У нас на GitHub есть репозиторий magnit-opensearch-1c. В частности, там есть пример настройки технологических журналов, полная версия docker-compose.yml, а также ряд конфигурационных файлов к настройке Filebeat, OpenSearch и OpenSearch Dashboard.

• Query DSL – описание DSL-формата запросов для поиска данных в документации OpenSearch

• LDAP/LDAPutils – документация к консольной утилите для отладки параметров LDAP на Linux.

• Установка docker на Linux Debian

• Установка docker-compose на Linux Debian

 

Вопросы и ответы

 

Вы рассказывали, что когда у одного из пользователей медленно работала форма списка, вам пришлось идти к нему на рабочее место и смотреть его настройки формы. Было бы удобнее, если бы в Elastic загружались и сами запросы, чтобы вы уже по запросу увидели, что там либо сортировка странная стоит, либо отбор, не попадающий в индекс. И дополнительно можно было бы еще добавить логи СУБД, чтобы сразу видеть план – почему это плохо работает.

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

Основную проблему мы увидели в OpenSearch, а решение – в 1С, открыв настройки формы.

Для каких целей использовался Docker?

Сам OpenSearch у нас установлен в Docker на Linux. Но это не значит, что без Docker работать не будет – наоборот, без Docker было бы слишком просто.

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

Какое минимальное ограничение вы ставите по длительности SDBL, DBPOSTGRS и так далее?

10 тысяч, т.е. 10 миллисекунд.

Из-за этого не теряется какой-нибудь пласт коротких, но часто выполняющихся запросов? Прецедентов не было?

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

У вас настройки технологического журнала как-то автоматически рассылаются по серверам приложений? Вообще настройки технологического журнала единые на все сервера приложений или каждый настраивается отдельно?

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

Но вообще на разных серверах настройки немного отличаются – в основном, путями, куда складываются логи. А в целом шаблон примерно одинаковый.

Это настраивается вручную, для каждого сервера приложений индивидуально?

Можно сказать, что да.

При ваших настройках алертинг в Telegram-канал или на почту не спамит? Насколько это вообще информативно?

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

А события ATTN, к примеру?

Оповещения у нас только по событиям ADMIN, по ATTN я показывал конкретный кейс, где мониторинг этого события помог нам найти проблему.

Но на самом деле, даже если по ATTN будет событие «Превышение критического объема памяти» или «Превышение временного объема», это не будет спамом – это почти авария, которую нужно пойти и решить.

Насколько я понял из доклада, до этого у вас все крутилось Open Distro. Инфраструктура как-то поменялась?

ElasticSearch и все его трансформации в open source мы прошли – изначально мы использовали классический ElasticSearch, потом у нас был Open Distro, а потом мы сделали миграцию в OpenSearch.

Docker мы начали использовать, уже когда перешли на OpenSearch.

Как долго происходил переезд с Open Distro на OpenSearch? Есть там какие-то грабли?

Грабли есть. Например, я говорил, что в OpenSearch вместо Destinations появились Notifications и Channels. Но вообще, если включить API к плагинам безопасности, то с его помощью можно много чего перетащить из Open Distro в OpenSearch.

Есть ли возможность как-то отправлять в Telegram или на почту графики и дашборды?

В OpenSearch расширенные возможности по сравнению с Open Distro, его достаточно хорошо улучшили. В том числе, там есть эта возможность.

Альтернативы ElasticSearch рассматривали, например, Clickhouse?

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

 

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TECH EVENT.