В прошлом посте мы забирали данные из OperationsManager базы SCOM’a, чтобы что-то нарисовать в Grafana и у нас получился примерно вот такой вот дашборд:
В этом посте разберемся, как сделать Drill Down, чтобы при клике на панель мы могли провалиться в другой дашборд, где бы была уже собрана более детальная информация по конкретному сервису/серверу. В Grafana это называется Data link и появилось с версии 6.3. Grafana может передать в другой дашборд любую переменную с именем вашего сервиса, отметкой времени и т.д., а мы уже эту переменную обработаем в новом дашборде. В нашем случае это будет объект в SCOM’е или проще — FQDN-имя сервера. Про встроенные переменные можно почитать в документации Global Built-in Variables.
Но перед тем как приступить к построению дашбордов, нам необходимо решить, а какие данные и откуда будем тянуть. Здесь есть ряд нюансов. В System Center Operations Manager есть две базы: OperationsManager и OperationsManager Data Warehouse. SCOM пишет данные одновременно и в одну, и в другую, но вот хранятся они там по-разному, а это будет очень сильно влиять на то, как ваши графики будут отображаться. Если мы берём базу OperationsManager, то данные мониторинга, событий, алёрты, метрики и прочее хранятся всего 7 дней. Определяется это в консоли SCOM’a — Administration — Settings — Database Grooming или в powershell: Get-SCOMDatabaseGroomingSetting и Set-SCOMDatabaseGroomingSetting.
Понимаете к чему я веду? Когда вы захотите посмотреть метрики за месяц, то будет примерно такая картина.
Ага, все верно, данные за 7 дней и всё. Но где же остальные данные? Они хранятся в базе Data Warehouse, но с ними другие приколы. Если мы возьмем один и тот же сервер и сравним одну и ту же метрику, например нагрузка на CPU, то увидим примерно следующее.
Вот данные из баз OperationsManager и Data Warehouse. Видно, что в левой части данные хранятся согласно правилам сбора, а в правой части — среднее значение за час.
Но почему так? Смысл в том, что данные в Data Warehouse не складываются просто абы как, а агрегируются в уникальные Datasets, которые представляют разные типы данных (события, алёрты, метрики и т.д.), которые еще имеют разный тип агрегации (raw, hourly, daily). Т.к. в данном запросе я «селектнул» из Perf.vPerfHourly, то и данные представлены часовым «шагом». Но вы скажите: «эй, там же есть raw (сырые) данные, а давай мы дёрнем из них и все будут счастливы». Raw данные хранятся 10 дней и менять это значение не имеет смысла, т.к. метрики это одна из самых прожорливых вещей в Data Warehouse.
То, сколько хранить данные в Data Warehouse можно посмотреть и изменить. Самый простой вариант это либо DWDataRP от Kevin Holman, либо SCOM DataWarehouse Grooming Settings. Я думаю, что те, кто сталкивался с чисткой базы Data Warehouse знакомы с этими тулзами.
Какой из всего этого можно сделать вывод? Если мы хотим построить график из данных в базе Data Warehouse, то у нас всё равно будут средние данные за час.
Например, вот данные в промежутке между 3-мя и 6-ью утра, есть какое-то изменение по CPU, но на самом деле данные выглядят вот так (см. ниже).
У нас нет плавного роста с 3-х утра, а есть ровный скачок в 4:15, далее 30 минутная нагрузка и полный спад. Просто, чтобы вы понимали с какими нюансами придётся столкнуться, если вы вдруг захотите что-то проанализировать. Всё не так очевидно. ;)
Ладно, пора приступить к созданию дашборда. Первым делом добавить новый Datasource. В этом посте написано, как создать, только там мы добавляли доступ к базе OperationsManager, а здесь добавляем OperationsManagerDW.
Открываем Grafana и создаем новый дашборд, название придумайте сами.
В меню Variables создадим новую переменную hostname с типом Constant.
Если вы хотите использовать данные из OperationsManager, тогда смело открывайте первый пост и забирайте все запросы для метрик производительности из него, а вот для Data Warehouse будет всё ниже.
Получаем список хостов из группы All Windows Computers.
|
1 2 3 4 5 6 |
select vManagedEntity.Displayname from vManagedEntity join vRelationship on vRelationship.TargetManagedEntityRowId = vManagedEntity.ManagedEntityRowId join vManagedEntity vme on vme.ManagedEntityRowId = vRelationship.SourceManagedEntityRowId where vme.DisplayName = 'All Windows Computers' |
Получив список агентов, можно посмотреть, что у нас хранится в Perf.vPerfHourly и как называются счетчики.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
SELECT distinct --vManagedEntity.Path, vPerformanceRule.ObjectName, vPerformanceRule.CounterName, vPerformanceRuleInstance.InstanceName FROM Perf.vPerfHourly AS vph INNER JOIN vPerformanceRuleInstance ON vPerformanceRuleInstance.PerformanceRuleInstanceRowId = vph.PerformanceRuleInstanceRowId INNER JOIN vManagedEntity ON vph.ManagedEntityRowId = vManagedEntity.ManagedEntityRowId INNER JOIN vPerformanceRule ON vPerformanceRuleInstance.RuleRowId = vPerformanceRule.RuleRowId WHERE vManagedEntity.Path = 'fqdn.domain.com' order by vPerformanceRule.ObjectName |
Когда получили список ObjectName и CounterName для нашего хоста, можно уже вытащить их значения из DataWarehouse.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
SELECT Perf.vPerfHourly.DateTime as time, Perf.vPerfHourly.AverageValue, vManagedEntity.DisplayName, vPerformanceRule.ObjectName, vPerformanceRule.CounterName FROM Perf.vPerfHourly INNER JOIN vPerformanceRuleInstance ON Perf.vPerfHourly.PerformanceRuleInstanceRowId = vPerformanceRuleInstance.PerformanceRuleInstanceRowId INNER JOIN vPerformanceRule ON vPerformanceRuleInstance.RuleRowId = vPerformanceRule.RuleRowId INNER JOIN vRelationship ON Perf.vPerfHourly.ManagedEntityRowId = vRelationship.TargetManagedEntityRowId INNER JOIN vManagedEntity ON vRelationship.SourceManagedEntityRowId = vManagedEntity.ManagedEntityRowId WHERE vManagedEntity.DisplayName = 'fqdn.domain.com' AND vPerformanceRule.ObjectName like 'Processor Information' AND vPerformanceRule.CounterName = '% Processor Time' ORDER BY Perf.vPerfHourly.DateTime DESC |
Так, я думаю, что теперь логика понятна, как вытаскивать метрики из базы, осталось совсем немного доработать запрос в Grafana, чтобы когда мы переходили с первого дашборда, нам отображались метрики для нужного нам хоста.
Открываем Grafana и создаем новую панель. Наш запрос в Grafana теперь будет выглядеть вот так. $__timeEpoch(Perf.vPerfHourly.DateTime) — объяснит графане, что это datetime, Perf.vPerfHourly.AverageValue as value — это значение, vManagedEntity.DisplayName in(‘$hostname’) — примет в переменную $hostname значение из первого дашборда.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
SELECT $__timeEpoch(Perf.vPerfHourly.DateTime), Perf.vPerfHourly.AverageValue as value, vManagedEntity.DisplayName as path FROM Perf.vPerfHourly INNER JOIN vPerformanceRuleInstance ON Perf.vPerfHourly.PerformanceRuleInstanceRowId = vPerformanceRuleInstance.PerformanceRuleInstanceRowId INNER JOIN vPerformanceRule ON vPerformanceRuleInstance.RuleRowId = vPerformanceRule.RuleRowId INNER JOIN vRelationship ON Perf.vPerfHourly.ManagedEntityRowId = vRelationship.TargetManagedEntityRowId INNER JOIN vManagedEntity ON vRelationship.SourceManagedEntityRowId = vManagedEntity.ManagedEntityRowId WHERE vManagedEntity.DisplayName in('$hostname') AND vPerformanceRule.ObjectName like 'VMGuest-cpu' AND vPerformanceRule.CounterName = '% Processor Time' and $__timeFilter(Perf.vPerfHourly.DateTime) group by vManagedEntity.DisplayName, Perf.vPerfHourly.DateTime, Perf.vPerfHourly.AverageValue ORDER BY Perf.vPerfHourly.DateTime ASC |
Ну, и теперь набирайтесь терпения, т.к. вам надо создать столько панелей, сколько вы хотите, для всех метрик, которые вам нужны. Да, придется немного посидеть с sql-запросами. После того, как вы создали все нужные вам панели, необходимо настроить линк с первого дашборда в ваш новый.
Открываем наш первый дашборд, выбираем Health State и нажимаем Edit.
Переходим в General, нас интересует Panel Links, вбиваем Title, затем URL на наш второй дашборд и добавляем к нему ?var-hostname=${hostname}
Теперь при клике на красно-желто-зеленый прямоугольник, вас будет перебрасывать в новый дашборд, где вы можете собрать сколько угодно графиков, но уже по конкретному сервису/серверу/приложению. На самом деле, одними графиками дело не обходится, если очень хочется, то можно нарисовать хоть весь статус вашего Distributed Application, понавытаскивать данные в какие-то таблички, подцепить логи и т.д. Если вы дошли до этого места и что-то попробовали, то обязательно поделитесь в комментариях, как все прошло, возможно, что у вас есть какой-то свой опыт и вы хотели бы поделиться им.
И еще один момент про который я хотел бы написать — это как запустить графану «на попробовать». ;) Самый просто вариант взять любой windows хост, хоть клиентскую Windows 10, поставить себе Docker Desktop for Windows. После установки выполнить несколько простых манипуляций: — создать volume для хранения настроек графаны, которую вы запустите в контейнере; — запустить контейнер. Всё.
|
1 2 3 4 5 6 7 8 9 10 11 12 |
# создаём volume docker volume create grafana-storage # запускаем grafana docker run \ -d \ -p 3000:3000 \ --name=grafana \ -v grafana-storage:/var/lib/grafana \ grafana/grafana |
Вуаля, открываем браузер, идем на localhost:3000, стандартный admin/admin и наслаждаемся.
зыж docker start grafana, чтоб просто запустить контейнер.
зыж спасибо, что дочитали до конца. ;) Лайк. Шер. Алишер. Фидбек в комментарии. Peace.
После первой статьи развернул у себя и настроил дашборды для серверов. Также у меня в SCOM завернут мониторинг принтеров Xerox, делал новый MP, т.к. официальный MP от Xerox работает только с SCOM 2007 или у тех, кто с него апгрейдился. В SCOM 2012 класса такого нет. Но через Grafana и SCOM сделал только отображение состояния принтера и алерты по замятию и т.д. Потом подцепил принтеры через telegraf и допилил дашборд с состоянием расходки.
А далее понеслось по наклонной: дашборд для squid с логами из elasticsearch и т.д. Очнулся по уши в DevOPs
После первого поста сделал борд на основе scom групп, внутри которых сервера. Это несколько облегчает фильтрацию и отображение. Можно отображать сразу все необходимые метрики по серверам.
Было бы круто иметь один датасурс в графане для предоставления метрик из scom, но в моем случае это два инстанса и запросы объединить не получается + постоянно приходится пилить борды для двх и оп ДБ (двойная работа). Есть мысли у кого-нибудь как сливать данные в одну бд и отдавать в графану?
За Drill down отдельный РЕСПЕКТ!
пока хз ;)
Самый просто вариант, если базы на одном сервере живут, то можно просто добавить датасурс sql сервера, а в запросах использовать use OperationsManager; или use OperationsManagerDW; Тогда на одном графике будет два значения отрисовывать.
точно можно выбирать разные датасорсы в переменных, но я пока не придумал, как это можно использовать.
а, я нашёл, mixed запросы, в выпадающем меню внизу есть —Mixed—
и вот там можно миксовать запросы.
Спасибо за инфу, буду тестить)