В прошлом посте мы забирали данные из 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—
и вот там можно миксовать запросы.
уж не знаю актуально или нет, но если датасурс MSSQL то можно использовать технологию Linked Server и тогда можно будет писать запрос который сможет спокойно забирать данные из двух разных инстансов (серверов)
Спасибо за инфу, буду тестить)
Friend, your post is very good, but I’m facing a problem, I’ve tried all the scripts and I can’t get the query to bring me in graph form, just in table form, would you know how to guide me in what I’m doing wrong?
Друг, ваш пост очень хорош, но у меня возникла проблема: я перепробовал все сценарии, и я не могу получить запрос, чтобы вывести меня в виде графика, только в виде таблицы, вы бы знали, как помочь мне в том, что я делаю неправильно?
Drug, vash post ochen’ khorosh, no u menya voznikla problema: ya pereproboval vse stsenarii, i ya ne mogu poluchit’ zapros, chtoby vyvesti menya v vide grafika, tol’ko v vide tablitsy, vy by znali, kak pomoch’ mne v tom, chto ya delayu nepravil’no?