Проекты наши обычно региональные, и заказчики, как правило — министерства. Но, помимо госсектора, нашими системами пользуются и частные организации. С ними проблем практически нет.
Так вот, основные проекты — региональные, а с ними порой бывают проблемы. Например, с производительностью, когда в регионах от 20к наших драгоценных пользователей в период выкатывания нового функционала на продуктовые серверы. Это боль…
Зовут меня Руслан и занимаюсь я сопровождением информационных систем «БАРС Груп» и разработкой бота-убийцы для жестоких серийных DBA. Пост не для слабонервных — много букв и картинок.
Некоторые наши приложения работают на СУБД Oracle. Есть проекты и на СУБД PostgreSQL. У Oracle есть замечательная штука — сбор статистики нагрузки на СУБД, которая подсвечивает имеющиеся проблемы и даже дает рекомендации для устранения — Automatic Workload Repository (AWR). В один момент (а именно в момент боли), разработчики постоянно просили собрать AWR-отчеты для анализа производительности. Мы честно шли на сервер СУБД, собирали отчеты, тащили их к себе и отправляли на анализ в производство. Раза после 5-го это стало напрягать… после 10-го — вызывать раздражение…
Однажды один из моих коллег высказал мысль — все, что делается больше одного раза, должно быть автоматизировано. До момента раздражения, если честно, я об этом не задумывался и пытался автоматизировать все, что можно автоматизировать, но часто это не было востребовано и носило скорее исследовательский, нежели прикладной характер.
И тут я подумал: «Не нужны админы для генерации отчета...». Ведь собрать отчет — это выполнить sql-скрипт @$ORACLE_HOME/rdbms/admin/awrrpt.sql и забрать отчет с сервера к себе… Ах да, мы же не пускаем разработку на прод.
Тогда я нагуглил нужную информацию, создал на тестовой базе функцию из статьи, дернул скрипт и чудо — отчет собрался и его можно сохранить локально. Создал функции там, где часто нужны были AWR-отчеты, рассказал разработчикам, как пользоваться.
Примерно в это время на досуге я, пообщавшись с @BotFather, создал себе Телеграм-бота, просто так, для развлечения. Прикручивал туда простенький функционал — показать текущее время, курс валют, погоду, научил его отправлять комплименты моей жене (тогда еще девушке) по расписанию. Пожалуй, на тот момент отправка комплиментов была наиболее востребованным функционалом моего бота, жена оценила.
Так. Разработчики пишут нам в Телеграм, мы отправляем отчет им в Телеграм… А что, если писать они будут не нам, а боту? Ведь так всем будет лучше, отчет будет получен быстрее, а самое главное — мимо нас. Так родилась идея первого востребованного функционала для моего бота.
Я приступил к реализации. Сделал, как сумел, на PHP (собственно приложение наше на PHP, в нем я больше разбираюсь, чем в том же Python). Кодер из меня так себе, поэтому свой код я не покажу :)
Бот живет в нашей корпоративной сети, у него есть доступ к определенным проектам, в том числе к целевым базам. Чтобы не заморачиваться с параметрами в команде или с меню, прикрутил этот функционал к групповому чату с уведомлениями мониторинга. Так бот сразу знает, на какой БД собирать отчет.
Получив команду вида /awr N, где N — количество полных часов, за которые нужен отчет (по умолчанию — 1 час), хоть за неделю, если БД не перезапускалась, бот немедленно приступает к работе, собирает отчет, публикует его в виде веб-страницы и тут же (почти тут же) выдает ссылку на так необходимый отчет.
Переходим по ссылке и вот он, AWR-отчет:
Как и предполагалось, разработчики справились с такой генерацией отчетов, кто-то даже поблагодарил.
Оценив удобство команды, такую же захотели руководители проектов из других регионов, т. к. они больше всехполучают люлей от заказчика переживают за производительность и доступность систем. Добавил бота и к остальным чатам. До сих пор пользуются, и я рад этому.
Позже коллеги из ЦИТ прознали про то, как мы собираем отчеты, тоже захотели. В наши чаты добавлять их не стал, создал отдельный чат с генерацией отчетов по расписанию и по запросу.
Есть у нас и другие приложения, на PHP в связке с PostgreSQL. Реализовал сбор отчета pgBadger для нуждающихся по тому же принципу — в групповых чатах. Поначалу пользовались, но потом перестали. Функционал выпилил за ненадобностью.
В нашем отделе есть ночные дежурства и, соответственно, имеется график. Он находится в гугл-таблицах. Не всегда удобно искать ссылку, открывать график, искать себя… Один из бывших коллег тоже игрался со своим Телеграм-ботом и внедрил в чат нашего отдела уведомления о начале дежурной смены для сотрудников отдела. Бот парсит график, определяет дежурного по текущей дате и, по расписанию или по запросу, сообщает, кто сегодня дежурный. Получилось здорово, удобно. Правда, мне не очень нравился формат сообщений. Также для сотрудников другого отдела (например, БЦ «Медицина») не очень нужна информация о дежурных в других направлениях, но нужно знать, кто дежурный в «Медицине» на случай проблем. Решил «позаимствовать» функционал, но изменить то, что мне не нравилось. Сделал удобный для себя и для других формат сообщений, убрав излишнюю информацию.
После «пробы пера» автоматизации посредством Телеграм-бота появилось много различных идей, но хотелось делать строго нужные вещи. Решил вести статистику по обращениям. Для доступа к проектам наших заказчиков у нас реализован так называемый «прыжковый сервер» или сервер пробросов. На нем поднимаются VPN-соединения, далее через ssh к нам в локальную сеть пробрасываются порты приложений, БД и прочие вспомогательные пробросы, для удобства доступа к проектам наших сотрудников, без заморочек с VPN-подключениями. Достаточно настроить VPN-подключение до нашей корпоративной сети.
Статистика обращений подсказала, что часто, после падения какого-то из туннелей (в случае сетевых проблем, по таймауту, например), обращаются по поводу восстановления доступа к проекту. В большинстве случаев достаточно просто перезапустить подключение и все становится хорошо. А давайте-ка вы будете сами это делать. Вот и команда есть:
«Проваливаешься» в нужный пункт меню, выбираешь свой проект, ждешь минутку и все счастливы и довольны…
При получении команды, легким движениемруки байтов и битов, бот подключается к серверу пробросов, заранее зная, какой проброс нужно перезапустить, и делает свое дело — восстанавливает подключение к проекту. Написал инструкцию, чтобы самостоятельно решали подобные вопросы. А к нам обращались лишь в случае, если предоставленный инструмент не работает…
Далее статистика показала, что часто нужно конвертировать ЭЦП Крипто Про в pem-формат(Base64) для различных интеграций, а их у нас достаточно много. Задача: берешь контейнер, копируешь его на компьютер с Windows с установленой утилитой P12FromGostCSP(к слову, платной), конвертируешь его в pfx, а уже pfx конвертируешь с помощью OpenSSL(c поддержкой ГОСТового шифрования) в pem. Не очень удобно, а хочется по щелчку пальцев.
Гугл опять пришел на выручку. Нашел утилиту какого-то доброго человека. Собрал, как написано в README — заработало. Научил бота работать с утилитой и получил практически моментальное конвертирование.
К моменту окончательной реализации вышел приказ о переходе на новый формат шифрования — gost-2012. Насколько помню, утилита в тот момент работала только со старым ГОСТом (2001), возможно это была вообще другая похожая утилита другого доброго человека, не помню точно.
После перехода на новый ГОСТ, функционал у бота убрал из соображений безопасности. Реализовал его в docker-контейнере.
Для конвертации необходимо исходный контейнер (директория вида xxx.000) разместить в директории /srv/in, а забирать готовый pem — в /srv/out.
Для конвертации выполнить:
Однажды в нашу фирму устроился оооочень крутой Oracle DBA, с большииииим опытом в администрировании СУБД и в разработке. И сходу у него не задалось с ssh-подключением до серверов СУБД: то подключиться не знает куда и как, то доступы непонятно описаны, то пробросить к себе что то нужное не получается. Ну мы и рады помочь, рассказали как подключаться, пробросили для него Enterprise Manager. А вот с ssh все равно не заладилось. Один из коллег объяснил это просто: DBA-чистокровка :) Решили, если нужно будет что-то подкрутить на сервере, сделаем это сами.
EM бывает падает под большой нагрузкой, а перезапустить его… нужно подключаться по ssh и перезапускать через терминал. «Админы это хорошо умеют,» — решил наш новый коллега. Большие нагрузки на СУБД у нас не редкость, нередки стали и просьбы о перезапуске EM. Дальше тот же сценарий: напряжение, раздражение и поиск решения проблемы. Так в тех же групповых чатах появились команды: /emstop и /emstart.
В случае сильной конкуренции на базе, а такое иногда бывает, необходимо быстро разгрузить БД. Самый быстрый способ — убить проблемный процесс… Для этого подключаемся по ssh, kill -9 … Бот поможет!
Алексей оценил команду и дал ей ласковое название — «Килялка» или ружье.
Однажды, посмотрев, как Алексей старается и страдает, вводя каждый раз /kill xxx для каждого из процессов, я решил добавить «многоствольности» нашему ружью:
Так-то лучше! Все для тебя, Алексей, только работай, дорогой!
Естественно, к такой важной команде был ограничен доступ по user_id — «защита от дурака». Завидев, как Леша ловко прибивает процессы на сервере БД, несколько человек попробовали ввести команду с рандомным номером процесса, но моего умного бота не обманешь, он тут же ответил отказом.
Ну и на всякий случай, сделал команду:
/alertlog <кол-во строк> — получить указанное количество строк alertlog'a
Бот дергает alertlog и отправляет его на наш сервис, типа pastebin, называется pyste, а в чат запроса отправляет ссылку на пасту.
Дальше поступил запрос на мониторинг реальной производительности нашего приложения. До сих пор техподдержка проекта руками собирала эти данные. Не дело! Наши доблестные тестировщики разработали тест-кейсы для этого. Получаемый лог теста не очень удобно читать, неискушенный пользователь долго будет разбираться и не факт, что выделит нужную информацию. Да и мы не любим делать руками то, что можно делать не руками… Новая задача для бота!
Команда /checks выдает незамысловатое и недвусмысленное меню, в этот раз наши ребята научились пользоваться этой командой без инструкции!
При выборе нужного пункта, вместо меню появляется уведомление о начале теста, чтобы нетерпеливые пользователи не запускали 100500 раз наш тест:
В зависимости от выбранного пункта меню запускается определенный тест из нашей сети, а именно с машины, где живет бот (там предварительно настроен jmeter, размещены нужные тесты...) или сразу из ЦОДа(с подготовленной машины рядом с приложением), чтобы при тестировании исключить сетевые задержки, ну или свести их к минимуму.
После завершения теста и получения лога, бот парсит его и выдает результат в «человекочитаемом» виде:
Функционал «зашел» и желающие руководители проектов получили такую функцию для своих регионов. А одна сердобольная Руководитель проекта заявила: «Хочу иметь статистику по времени!» Кто-то из ЦИТа ей подсказал, что было бы удобно мониторить это все в Zabbix. Zabbix, так Zabbix…
Подумалось, что нужно подготовиться к необходимости тиражирования решения… Оформил задумку в docker-контейнер. В контейнере по расписанию (раз в 10 минут) запускается jmeter, складывает лог в определенном месте, php парсит его и выдает нужные данные в виде web-странички. Zabbix с помощью ключа web.page.get получает эту страничку, регуляркой выбирает нужные данные для определенных зависимых элементов и строит график.
Думается, получилось не плохо. Наблюдая график, мы, во-первых, видим примерную скорость работы приложения, а в случае обнаружения пиков на графике, примерно знаем, где «затык». Все просто. Пока оказалось востребовано лишь для одного региона, но я уже готов растиражировать для желающих.
Статистика по однотипным задачам не так давно подкинула еще идеи для упрощения и облегчения труда. На некоторых проектах, на серверах приложений есть необходимость устанавливать ключевые контейнеры Крипто Про, их много, и срок действия ЭЦП со временем истекает. Иногда в день «прилетает» по 2 задачи. Но использовать бота для этих целей я посчитал небезопасным и решил, что сделаю функционал непосредственно в приложении. Естественно с авторизацией и проверкой прав доступа. В случае наличия необходимых привилегий, будет доступен дополнительный пункт меню для работы с ЭЦП, установка, удаление, просмотр информации и прочее… В данный момент функционал в процессе разработки. Как оказалось, это не очень сложно, нужно слегка почитать имеющиеся инструкции, посмотреть примеры кода, поспрашивать более опытных в разработке коллег, ну и делать. В процессе исследования, появились идеи для добавления в приложение. Наполеоновских планов строить не буду — есть разработка, пусть каждый занимается своим делом. Но пока интересно — делаю сам.
Как я говорил, родилось много различных идей использования нашего бота и не только — в целом, скажем так, идей для «точек автоматизации», многие из них забылись, так как я не успел их записать. Теперь я стараюсь записывать все, что приходит в голову, и остальным рекомендую поступать так же.
А вот Алексей не забывает подкидывать свои хотелки. Из последних:
/kill_sql SQL_ID — убить все сессии с таким SQL_ID запросом
/kill_block — убить коренную блокирующую сессию
/show_em — показать картинку производительности EM
Хитрец, хочет DBAшить с телефона =)
Вот так мы и работаем на благо Родины!
А как вы избавляете себя от рутинных и неинтересных задач?
Надеюсь чтиво получилось интересным, а может кому-то даже полезным, и я не успел утомить читателя… Удачи всем нам.
Так вот, основные проекты — региональные, а с ними порой бывают проблемы. Например, с производительностью, когда в регионах от 20к наших драгоценных пользователей в период выкатывания нового функционала на продуктовые серверы. Это боль…
Зовут меня Руслан и занимаюсь я сопровождением информационных систем «БАРС Груп» и разработкой бота-убийцы для жестоких серийных DBA. Пост не для слабонервных — много букв и картинок.
/awr
Некоторые наши приложения работают на СУБД Oracle. Есть проекты и на СУБД PostgreSQL. У Oracle есть замечательная штука — сбор статистики нагрузки на СУБД, которая подсвечивает имеющиеся проблемы и даже дает рекомендации для устранения — Automatic Workload Repository (AWR). В один момент (а именно в момент боли), разработчики постоянно просили собрать AWR-отчеты для анализа производительности. Мы честно шли на сервер СУБД, собирали отчеты, тащили их к себе и отправляли на анализ в производство. Раза после 5-го это стало напрягать… после 10-го — вызывать раздражение…
Однажды один из моих коллег высказал мысль — все, что делается больше одного раза, должно быть автоматизировано. До момента раздражения, если честно, я об этом не задумывался и пытался автоматизировать все, что можно автоматизировать, но часто это не было востребовано и носило скорее исследовательский, нежели прикладной характер.
И тут я подумал: «Не нужны админы для генерации отчета...». Ведь собрать отчет — это выполнить sql-скрипт @$ORACLE_HOME/rdbms/admin/awrrpt.sql и забрать отчет с сервера к себе… Ах да, мы же не пускаем разработку на прод.
Тогда я нагуглил нужную информацию, создал на тестовой базе функцию из статьи, дернул скрипт и чудо — отчет собрался и его можно сохранить локально. Создал функции там, где часто нужны были AWR-отчеты, рассказал разработчикам, как пользоваться.
Примерно в это время на досуге я, пообщавшись с @BotFather, создал себе Телеграм-бота, просто так, для развлечения. Прикручивал туда простенький функционал — показать текущее время, курс валют, погоду, научил его отправлять комплименты моей жене (тогда еще девушке) по расписанию. Пожалуй, на тот момент отправка комплиментов была наиболее востребованным функционалом моего бота, жена оценила.
Так. Разработчики пишут нам в Телеграм, мы отправляем отчет им в Телеграм… А что, если писать они будут не нам, а боту? Ведь так всем будет лучше, отчет будет получен быстрее, а самое главное — мимо нас. Так родилась идея первого востребованного функционала для моего бота.
Я приступил к реализации. Сделал, как сумел, на PHP (собственно приложение наше на PHP, в нем я больше разбираюсь, чем в том же Python). Кодер из меня так себе, поэтому свой код я не покажу :)
Бот живет в нашей корпоративной сети, у него есть доступ к определенным проектам, в том числе к целевым базам. Чтобы не заморачиваться с параметрами в команде или с меню, прикрутил этот функционал к групповому чату с уведомлениями мониторинга. Так бот сразу знает, на какой БД собирать отчет.
Получив команду вида /awr N, где N — количество полных часов, за которые нужен отчет (по умолчанию — 1 час), хоть за неделю, если БД не перезапускалась, бот немедленно приступает к работе, собирает отчет, публикует его в виде веб-страницы и тут же (почти тут же) выдает ссылку на так необходимый отчет.
Переходим по ссылке и вот он, AWR-отчет:
Как и предполагалось, разработчики справились с такой генерацией отчетов, кто-то даже поблагодарил.
Оценив удобство команды, такую же захотели руководители проектов из других регионов, т. к. они больше всех
Позже коллеги из ЦИТ прознали про то, как мы собираем отчеты, тоже захотели. В наши чаты добавлять их не стал, создал отдельный чат с генерацией отчетов по расписанию и по запросу.
/pgBadger
Есть у нас и другие приложения, на PHP в связке с PostgreSQL. Реализовал сбор отчета pgBadger для нуждающихся по тому же принципу — в групповых чатах. Поначалу пользовались, но потом перестали. Функционал выпилил за ненадобностью.
/duty
В нашем отделе есть ночные дежурства и, соответственно, имеется график. Он находится в гугл-таблицах. Не всегда удобно искать ссылку, открывать график, искать себя… Один из бывших коллег тоже игрался со своим Телеграм-ботом и внедрил в чат нашего отдела уведомления о начале дежурной смены для сотрудников отдела. Бот парсит график, определяет дежурного по текущей дате и, по расписанию или по запросу, сообщает, кто сегодня дежурный. Получилось здорово, удобно. Правда, мне не очень нравился формат сообщений. Также для сотрудников другого отдела (например, БЦ «Медицина») не очень нужна информация о дежурных в других направлениях, но нужно знать, кто дежурный в «Медицине» на случай проблем. Решил «позаимствовать» функционал, но изменить то, что мне не нравилось. Сделал удобный для себя и для других формат сообщений, убрав излишнюю информацию.
/tnls
После «пробы пера» автоматизации посредством Телеграм-бота появилось много различных идей, но хотелось делать строго нужные вещи. Решил вести статистику по обращениям. Для доступа к проектам наших заказчиков у нас реализован так называемый «прыжковый сервер» или сервер пробросов. На нем поднимаются VPN-соединения, далее через ssh к нам в локальную сеть пробрасываются порты приложений, БД и прочие вспомогательные пробросы, для удобства доступа к проектам наших сотрудников, без заморочек с VPN-подключениями. Достаточно настроить VPN-подключение до нашей корпоративной сети.
Статистика обращений подсказала, что часто, после падения какого-то из туннелей (в случае сетевых проблем, по таймауту, например), обращаются по поводу восстановления доступа к проекту. В большинстве случаев достаточно просто перезапустить подключение и все становится хорошо. А давайте-ка вы будете сами это делать. Вот и команда есть:
«Проваливаешься» в нужный пункт меню, выбираешь свой проект, ждешь минутку и все счастливы и довольны…
При получении команды, легким движением
/ecp_to_pem
Далее статистика показала, что часто нужно конвертировать ЭЦП Крипто Про в pem-формат(Base64) для различных интеграций, а их у нас достаточно много. Задача: берешь контейнер, копируешь его на компьютер с Windows с установленой утилитой P12FromGostCSP(к слову, платной), конвертируешь его в pfx, а уже pfx конвертируешь с помощью OpenSSL(c поддержкой ГОСТового шифрования) в pem. Не очень удобно, а хочется по щелчку пальцев.
Гугл опять пришел на выручку. Нашел утилиту какого-то доброго человека. Собрал, как написано в README — заработало. Научил бота работать с утилитой и получил практически моментальное конвертирование.
К моменту окончательной реализации вышел приказ о переходе на новый формат шифрования — gost-2012. Насколько помню, утилита в тот момент работала только со старым ГОСТом (2001), возможно это была вообще другая похожая утилита другого доброго человека, не помню точно.
После перехода на новый ГОСТ, функционал у бота убрал из соображений безопасности. Реализовал его в docker-контейнере.
Dockerfile, вдруг кому надо:
FROM ubuntu:16.04
RUN apt update && apt -y install git sudo wget unzip gcc g++ make && \
cd /srv/ && git clone https://github.com/kov-serg/get-cpcert.git && \
cd get-cpcert && chmod +x *.sh && ./prepare.sh && ./build.sh && \
mkdir -p /srv/{in,out} && \
echo '#!/bin/bash' > /srv/getpem.sh && \
echo 'cd /srv/get-cpcert' >> /srv/getpem.sh && \
echo './get-cpcert /srv/in/$CONT.000 $PASS > /srv/out/$CONT.pem' >> /srv/getpem.sh && \
chmod +x /srv/getpem.sh ENTRYPOINT /srv/getpem.shДля конвертации необходимо исходный контейнер (директория вида xxx.000) разместить в директории /srv/in, а забирать готовый pem — в /srv/out.
Для конвертации выполнить:
docker run -t -i -e CONT='<имя директории с контейнером(без ".000")>' -e PASS='<пароль для контейнера>' -v /srv/in:/srv/in -v /srv/out:/srv/out --name ecptopem <адрес нашего репозитория>/med/ecptopem:latest /emstop и /emstart
Однажды в нашу фирму устроился оооочень крутой Oracle DBA, с большииииим опытом в администрировании СУБД и в разработке. И сходу у него не задалось с ssh-подключением до серверов СУБД: то подключиться не знает куда и как, то доступы непонятно описаны, то пробросить к себе что то нужное не получается. Ну мы и рады помочь, рассказали как подключаться, пробросили для него Enterprise Manager. А вот с ssh все равно не заладилось. Один из коллег объяснил это просто: DBA-чистокровка :) Решили, если нужно будет что-то подкрутить на сервере, сделаем это сами.
EM бывает падает под большой нагрузкой, а перезапустить его… нужно подключаться по ssh и перезапускать через терминал. «Админы это хорошо умеют,» — решил наш новый коллега. Большие нагрузки на СУБД у нас не редкость, нередки стали и просьбы о перезапуске EM. Дальше тот же сценарий: напряжение, раздражение и поиск решения проблемы. Так в тех же групповых чатах появились команды: /emstop и /emstart.
/kill
В случае сильной конкуренции на базе, а такое иногда бывает, необходимо быстро разгрузить БД. Самый быстрый способ — убить проблемный процесс… Для этого подключаемся по ssh, kill -9 … Бот поможет!
Алексей оценил команду и дал ей ласковое название — «Килялка» или ружье.
Однажды, посмотрев, как Алексей старается и страдает, вводя каждый раз /kill xxx для каждого из процессов, я решил добавить «многоствольности» нашему ружью:
Так-то лучше! Все для тебя, Алексей, только работай, дорогой!
Естественно, к такой важной команде был ограничен доступ по user_id — «защита от дурака». Завидев, как Леша ловко прибивает процессы на сервере БД, несколько человек попробовали ввести команду с рандомным номером процесса, но моего умного бота не обманешь, он тут же ответил отказом.
/alertlog
Ну и на всякий случай, сделал команду:
/alertlog <кол-во строк> — получить указанное количество строк alertlog'a
Бот дергает alertlog и отправляет его на наш сервис, типа pastebin, называется pyste, а в чат запроса отправляет ссылку на пасту.
/checks
Дальше поступил запрос на мониторинг реальной производительности нашего приложения. До сих пор техподдержка проекта руками собирала эти данные. Не дело! Наши доблестные тестировщики разработали тест-кейсы для этого. Получаемый лог теста не очень удобно читать, неискушенный пользователь долго будет разбираться и не факт, что выделит нужную информацию. Да и мы не любим делать руками то, что можно делать не руками… Новая задача для бота!
Команда /checks выдает незамысловатое и недвусмысленное меню, в этот раз наши ребята научились пользоваться этой командой без инструкции!
При выборе нужного пункта, вместо меню появляется уведомление о начале теста, чтобы нетерпеливые пользователи не запускали 100500 раз наш тест:
В зависимости от выбранного пункта меню запускается определенный тест из нашей сети, а именно с машины, где живет бот (там предварительно настроен jmeter, размещены нужные тесты...) или сразу из ЦОДа(с подготовленной машины рядом с приложением), чтобы при тестировании исключить сетевые задержки, ну или свести их к минимуму.
После завершения теста и получения лога, бот парсит его и выдает результат в «человекочитаемом» виде:
Сбор метрик
Функционал «зашел» и желающие руководители проектов получили такую функцию для своих регионов. А одна сердобольная Руководитель проекта заявила: «Хочу иметь статистику по времени!» Кто-то из ЦИТа ей подсказал, что было бы удобно мониторить это все в Zabbix. Zabbix, так Zabbix…
Подумалось, что нужно подготовиться к необходимости тиражирования решения… Оформил задумку в docker-контейнер. В контейнере по расписанию (раз в 10 минут) запускается jmeter, складывает лог в определенном месте, php парсит его и выдает нужные данные в виде web-странички. Zabbix с помощью ключа web.page.get получает эту страничку, регуляркой выбирает нужные данные для определенных зависимых элементов и строит график.
Думается, получилось не плохо. Наблюдая график, мы, во-первых, видим примерную скорость работы приложения, а в случае обнаружения пиков на графике, примерно знаем, где «затык». Все просто. Пока оказалось востребовано лишь для одного региона, но я уже готов растиражировать для желающих.
Доработка приложений
Статистика по однотипным задачам не так давно подкинула еще идеи для упрощения и облегчения труда. На некоторых проектах, на серверах приложений есть необходимость устанавливать ключевые контейнеры Крипто Про, их много, и срок действия ЭЦП со временем истекает. Иногда в день «прилетает» по 2 задачи. Но использовать бота для этих целей я посчитал небезопасным и решил, что сделаю функционал непосредственно в приложении. Естественно с авторизацией и проверкой прав доступа. В случае наличия необходимых привилегий, будет доступен дополнительный пункт меню для работы с ЭЦП, установка, удаление, просмотр информации и прочее… В данный момент функционал в процессе разработки. Как оказалось, это не очень сложно, нужно слегка почитать имеющиеся инструкции, посмотреть примеры кода, поспрашивать более опытных в разработке коллег, ну и делать. В процессе исследования, появились идеи для добавления в приложение. Наполеоновских планов строить не буду — есть разработка, пусть каждый занимается своим делом. Но пока интересно — делаю сам.
Планы
Как я говорил, родилось много различных идей использования нашего бота и не только — в целом, скажем так, идей для «точек автоматизации», многие из них забылись, так как я не успел их записать. Теперь я стараюсь записывать все, что приходит в голову, и остальным рекомендую поступать так же.
А вот Алексей не забывает подкидывать свои хотелки. Из последних:
/kill_sql SQL_ID — убить все сессии с таким SQL_ID запросом
/kill_block — убить коренную блокирующую сессию
/show_em — показать картинку производительности EM
Хитрец, хочет DBAшить с телефона =)
Вот так мы и работаем на благо Родины!
А как вы избавляете себя от рутинных и неинтересных задач?
Надеюсь чтиво получилось интересным, а может кому-то даже полезным, и я не успел утомить читателя… Удачи всем нам.
