В данной статье будет рассмотрены варианты взаимодействия Splunk (платформа для сбора данных из различных источников) и Jira (система управления задачами и проектами).
Существует как минимум два варианта взаимодействия Splunk (платформа для сбора данных из различных источников) и Jira (система управления задачами и проектами):
Первый – при определённых условиях Splunk создаёт заявку в Jira, с которой уже разбираются сотрудники соответствующих отделов.
Второй – Splunk подключается к Jira и забирает оттуда заявки. Сегодня мы как раз настроим такое взаимодействие при помощи REST API.
Хочу написать пару слов зачем так делать. В нашей компании есть идея реализации «одной кнопки» или incident\event management, что бы руководство могло видеть состояние всех компонентов информационной системы (например: состояние антивирусной защиты, количество критических и\или просроченных задач и т.д.) в любой момент времени. На данный момент для этого необходимо собрать руководителей отдела, те собирают информацию с сотрудников\смотрят старые письма, открывают различные service desk системы и т.д. Безусловно, ни одно решение не сможет учесть всех нюансов и показывать 100% картину, однако показать чисто техническую сторону вполне возможно.
Эту систему, как вы уже поняли, я строю на базе Splunk и одним из компонентов будет dashboard (отчёт) со сводными данными с Jira сервера.
Установка аддона для Splunk
- Качаем Add-on for JIRA (https://splunkbase.splunk.com/app/1438/)
- Заходим на веб-страницу Splunk SPLUNKSERVER:8000/en-GB/manager/launcher/apps/local (либо на стартовой странице нажимаем на шестерёнку в верхнем левом углу) и нажимаем кнопку “Install app from file”, выбираем файл скаченный в П.1, нажимаем “Upload”, соглашаемся на перезапуск сервиса Splunk. У меня Splunk установлен в папку по умолчанию /opt/splunk, если у вас не так – учтите это.
- Подключаемся по SSH к нашему Splunk серверу и выполняем следующие команды:
sudo mkdir /opt/splunk/etc/apps/jira/local
sudo cp /opt/splunk/etc/apps/jira/default/jira.conf /opt/splunk/etc/apps/jira/local/ — копируем файл конфигурации который будет использоваться нашим приложением что бы на крайний случай в папке default остался изначальная версия
*В файле /opt/splunk/etc/apps/jira/local/jira.conf мы можем задать проект и параметры для поиска по умолчанию
sudo cp /opt/splunk/etc/apps/jira/bin/config.ini.sample /opt/splunk/etc/apps/jira/bin/config.ini – аналогично с файлом конфигурации подключения, здесь задаём параметры подключения к Jira серверу:
hostname = myjiraserver
username = user
password = password
- перезапускаем Splunk: /opt/splunk/bin/splunk restart
Теперь у нас есть подключение к Jira и мы можем отправлять запросы при помощи JQL (JIRA Query Language):
| jirarest jqlsearch «updated >= -1d» – так мы получим заявки которые были обновлены за последние сутки.
Тут надо отметить один момент – данные не индексируются, а лишь выводятся, из чего следует:
- мы не можем производить модификацию посредствам props.conf \ transforms.conf
- мы не сможем пользоваться встроенным модификатором времени (возможно получится сделать отдельную переменную и манипулировать ею)
- у нас не будет истории изменений заявок
- поиск будет происходить сравнительно медленнее, чем из индекса Splunk
- зато мы сэкономим лицензию т.к. такие запросы не «тарифицируются» =)
Я выбрал второй путь – единовременная индексация всей базы Jira при помощи выгрузки в csv файл и скрипт в Splunk который регулярно находит обновлённые заявки (новые тоже обладают данным полем, просто оно аналогично дате создания) и выгружает их в тот же csv файл.
Подключение и выгрузка базы Jira
- выгружаем всю базу в csv-файл /opt/splunk/var/run/splunk/csv/jirabase.csv
| jirarest jqlsearch «»
| outputcsv jirabase
- Splunk по умолчанию будет неверно определять время, нам необходимо что бы он его брал из поля Updated. Так же при очень длинных событиях Splunk будет их разбивать, что нам совсем не нужно. Подготовим правильный sourcetype, для этого в файле /opt/splunk/etc/apps/search/local/props.conf добавим следующее:
[Jira]
DATETIME_CONFIG =
INDEXED_EXTRACTIONS = csv
NO_BINARY_CHECK = false
SHOULD_LINEMERGE = false
TIME_FORMAT = %Y-%m-%dT%H:%M:%S.%3N%z
TIME_PREFIX = Updated\’: u\’
TRUNCATE = 100000
category = Custom
disabled = false
pulldown_type = 1
- Укажем Splunk файл куда выгружена вся база и его же будем в дальнейшем использовать для обновлённых событий:
- Setting -> Data inputs -> Local inputs -> Files & directories -> Add new и указываем /opt/splunk/var/run/splunk/csv/jirabase.csv
- Next
- Выбираем подготовленный sourcetype (Jira)
- Next
- Создаём и задаём индекс для хранения (я назвал его Jira)
- Review
- Submit
Теперь у нас есть индекс с перекачивавшей из Jira базой заявок. Следующий шаг — создание скрипта (поиска) который будет регулярно добавлять в csv файл обновлённые заявки
Создание регулярного поиска новых заявок
- Setting -> Searches, reports, and alerts -> NewУказываем Search name
- Указываем Search:
| jirarest jqlsearch «updated >= -1d»
| search NOT [search index=jira earliest=-2d | stats latest(Updated) by Key | table Key, latest(Updated) | rename «latest(Updated)» as Updated]
| outputcsv jirabase
- Ставим галочку Schedule this search и Run every – minute
- Save
Что делает наш поиск:
- Subsearch (тот что в []) получает заявки обновлённые за последних два дня в нашей базе (если Splunk сервер будет отключен на какое-то время мы не потеряем ничего)
- Находим в Jira заявки которые обновлялись за последний день (т.к. возможна небольшая рассинхронизация во времени и понятие «дня» по моим наблюдениям немного разнятся, самый надёжный способ – это взять данные с запасом поэтому мы берём за 2 дня из Splunk базы и за 1 из Jira). | stats latest(Updated) мы используем потому что в базе у нас будет появляться новое событие при каждом обновлении заявки, а нам важно лишь время последнего обновления.
- Исключаем результаты из второго пункта результаты первого и выгружаем в CSV файл, за которым уже наблюдает Splunk.
Для проверки можно использовать два поиска:
| jirarest jqlsearch «updated >= -1d» | table Key, Updated | sort –Updated
и
index=jira earliest=-1d | stats latest(Updated) by Key | table Key, latest(Updated) | rename latest(Updated) as Updated | sort –Updated
Если всё хорошо, то результаты должны быть идентичные.
Создание панели
Завершающий этап – создание dashboard (панели) где мы сделаем два простых элемента для составления наглядной картины текущего состояния:
- SPLUNKSERVER:8000/en-GB/app/search/dashboards
- Create New Dashboard, вводим имя и нажимаем Create Dashboard
- Переходим в режим правки исходного кода:
[spoiler title=’код панели’ style=’default’ collapse_link=’true’]
<dashboard>
<label>Заявки Jira</label>
<row>
<panel>
<title>Открытые заявки по проекту</title>
<chart>
<search>
<query>index=jira
| search Status=Open OR Reopened OR In Progress
| search [search index=jira | stats latest(Updated) by Key | rename latest(Updated) AS Updated | table Key, Updated]
| table Key, latest(Updated), Project, Priority
| chart count(Key) by Project </query>
<earliest>0</earliest>
<latest></latest>
</search>
<option name=»charting.axisTitleX.visibility»>collapsed</option>
<option name=»charting.axisTitleY.visibility»>collapsed</option>
<option name=»charting.axisY.scale»>linear</option>
<option name=»charting.chart»>pie</option>
<option name=»charting.chart.showDataLabels»>all</option>
<option name=»charting.chart.stackMode»>stacked</option>
<option name=»charting.drilldown»>none</option>
<option name=»charting.layout.splitSeries»>0</option>
</chart>
</panel>
</row>
<row>
<panel>
<title>Список</title>
<table>
<search>
<query>index=jira
| eval crdate=strftime(_time, «%d %b %Y %H:%M:%S»)
| eval ud=strptime(Updated, «%Y-%m-%dT%H:%M:%S.%3N%z»)
| eval ud2=strftime(ud, «%d %b %Y %H:%M:%S»)
| search [search index=jira | stats latest(Updated) by Key | rename latest(Updated) AS Updated | table Key, Updated]
| table Project, Key, Priority, Creator_Name, crdate, ud2, Assignee_Name, Description, Status
| sort -crdate
| rename Key as «Номер заявки», Project as «Проект», Priority as «Критичность», Creator_Name as «Создал заявку», crdate as «Дата создания», ud2 as «Дата последнего обновления», Assignee_Name as «Ответственный», Description as «Текст заявки», Status as «Статус»</query>
</search>
<option name=»count»>20</option>
<option name=»dataOverlayMode»>none</option>
<option name=»drilldown»>row</option>
<option name=»rowNumbers»>false</option>
<option name=»wrap»>true</option>
<drilldown>
<link target=»_blank»>
<![CDATA[https://JIRASERVER/browse/$row.Номер заявки$]]>
</link>
</drilldown>
</table>
[/spoiler]
Ссылка в <drilldown> позволяет нам переходить на заявку на Jira сервере, при желании посмотреть её полноценно.
Выглядит эта панель так:
Теперь мы можем свободно манипулировать данными и представлять их как нам угодно.
В следующей статье я расскажу, как подключить CheckPoint к Splunk, какие при этом возникают проблемы и как они были решены.
Очень полезно, ждем продолжения. И один вопрос в догонку, а в системах SIEM разве нету этой возможности («одной кнопки»)?
в статье походу рассматривается именно контакт с джирой для удобств
Прелесть SPLUNK в возможности подключения практически любых ресурсов, можно хоть WEB-страницу отслеживать, парсить и добавлять в общий «котёл». Плюс есть возможность обогащения данными, в контексте статьи это могут быть запросы в AD (или свой справочник в формате csv) для добавления номера телефона сотрудника. Я обязательно распишу эту тему в следующей статье.
Благодарю за ответ, и жду продолжения! )
отличная статья! удобное и современное решение.
Спасибо за комментарий! Splunk — определённо user-friendy ПО.
а какая альтернатива есть спланку? баян, но он же дорогой
на хабре была статья как сделать аналог на бесплатном ПО, но нужно понимать что первичная настройка и поддержка такой системы трудоёмкая задача. бесплатных 500 МБ вполне достаточно для базовой системы, если понимать что от неё конкретно надо. Например у меня реализована возможность отслеживать авторизации на win\linux машинах, в день это максимум 10-20МБ логов, при том что можно уменьшить отфильтровав ненужные поля.