Индикаторы мониторинга

Сделайте сводку индикаторов мониторинга базы данных MySQL, использованных в предыдущем продукте.

Общий обзор системы мониторинга

Четыре шага обработки данных всей системой мониторинга:

Схема архитектуры системы:

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

Data Collector: Сборщик данных, принять данные мониторинга, полученные от клиента, или получить данные внешнего мониторинга;

Data TransferПреобразователь данных для преобразования собранных данных несовместимой архитектуры в единую модель данных;

Config: Этот модуль в основном предоставляет некоторые метаданные, необходимые для агента, сборщика, анализатора;

Schedule: Полагаться на расписание, главным образом для преобразования периодических задач извлечения и сбора данных в задачи расписания, уменьшения сложности многократной записи распределенного планирования задач и, во-вторых, использования расписания для достижения балансировки нагрузки при распределении периодических задач;

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

MQ: Преобразовать данные, собранные сборщиком данных, в унифицированный формат сообщений, отделить сбор данных и анализ данных для определения разницы в использовании данных, во-вторых, когда кластер Data Analyzer не работает или производительность обработки снижается, MQ может воспроизводить Функция пула буферов данных предотвращает потерю данных, вызванную невозможностью обработки собранных данных в определенной степени.

Data Analyzer: Анализатор данных, выполнение определенной степени расчета и преобразования собранных данных мониторинга, а также выполнение мониторинга и обработки событий в соответствии с соответствующими правилами;

Самостоятельно разработанная система мониторинга должна столкнуться с рядом вариантов:

Читать PDF

245.27 кб

Индикаторы мониторинга операционной устойчивости предприятия

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

Читать PDF

454.52 кб

Выбор индикаторов мониторинга стоимости акционерного капитала

Рязкова С. В.

Читать PDF

571.51 кб

Система индикаторов и мониторинг устойчивого развития региона

Шедько Юрий Николаевич

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

Читать PDF

171.62 кб

Методический инструментарий мониторинга индикаторовкачества жизни

Миннигалеева В. З.

Одна из основных задач современных социальных измерений состоит в построении комплексной информационной системы для получения систематических, достоверных знаний, позволяющих оценить социальное самочувствие человека в условиях нес

Читать PDF

116.31 кб

Мониторинг индикаторов евразийской интеграции

Де Ломберде Филипп

Читать PDF

465.27 кб

Налоговый мониторинг организаций на основе среднеотраслевых индикаторов

Ханафина Ксения Анисовна

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

Читать PDF

293.45 кб

Мониторинг питания жителей Санкт-Петербурга как индикатор качества жизни

Якубова И. Ш., Базилевская Е. М.

Читать PDF

316.89 кб

Использование индикаторов в системе мониторинга кризисных ситуаций в организации

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

Читать PDF

406.46 кб

Экономические индикаторы мониторинга эффективности расходования бюджетных средств

Никифорова А. А.

Реформирование бюджетного процесса, проводимое в Российской Федерации, предполагает переход от планирования бюджетных расходов по нормативному методу к распределению расходов на основе программно-целевого бюджетирования, меняющего

Читать PDF

243.45 кб

Система индикаторов и мониторинг экономической безопасности корпоративных структур

Орешина Елена Юрьевна

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

Читать PDF

712.74 кб

Система индикаторов и мониторинг развития информационного общества и экономики знаний

Чугунов Андрей Владимирович

Развитие информационного общества, формирование экономики знаний, внедрение интерактивных технологий в различные сферы человеческой жизнедеятельности от мобильной связи до электронного правительства вызвало потребности в проведени

Читать PDF

426.14 кб

Индикаторы инновационного развития регионов России для целей мониторинга и управления

Бортник Иван Михайлович, Зинов Владимир Глебович, Коцюбинский Владимир Алексеевич, Сорокина Алла Валерьевна

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

Читать PDF

496.55 кб

Концепция инновационного развития Нижегородской области

Минаева О.Н., Митяков С.Н., Мурашова Н.А.

Работа продолжает цикл статей, посвященных Концепции инновационного развития Нижегородского региона.

Читать PDF

277.56 кб

Мониторинг экономической безопасности региона на основе индикаторов устойчивого развития

Казакова Наталия Александровна, Болвачев Алексей Ильич, Гендон Анжелика Леонидовна, Голубева Галина Феликсовна

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

Читать PDF

7.89 мб

Разработка системы индикаторов оценки, анализа и мониторинга ресурсного потенциала региона

Оборин М.С., Шерешева М.Ю., Шимук О.В.

Предмет. Система индикаторов, позволяющая оценивать, анализировать и проводить мониторинг ресурсного потенциала. Исследование проведено на примере Пермского края, Тульской и Владимирской областей.

Об особенностях осуществления государственного контроля (надзора), муниципального контроля в 2023 году см. Постановления Правительства РФ от 10.03.2022 N 336, от 24.03.2022 N 448.

1. Оценка результативности и эффективности деятельности контрольных (надзорных) органов осуществляется по каждому виду контроля на основе системы показателей результативности и эффективности государственного контроля (надзора), муниципального контроля.

(в ред. Федерального закона от 11.06.2021 N 170-ФЗ)

(см. текст в предыдущей редакции)

2. В систему показателей результативности и эффективности деятельности контрольных (надзорных) органов входят:

1) ключевые показатели видов контроля, отражающие уровень минимизации вреда (ущерба) охраняемым законом ценностям, уровень устранения риска причинения вреда (ущерба) в соответствующей сфере деятельности, по которым устанавливаются целевые (плановые) значения и достижение которых должен обеспечить соответствующий контрольный (надзорный) орган;

2) индикативные показатели видов контроля, применяемые для мониторинга контрольной (надзорной) деятельности, ее анализа, выявления проблем, возникающих при ее осуществлении, и определения причин их возникновения, характеризующих соотношение между степенью устранения риска причинения вреда (ущерба) и объемом трудовых, материальных и финансовых ресурсов, а также уровень вмешательства в деятельность контролируемых лиц.

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

4. Ключевые показатели вида контроля и их целевые значения, индикативные показатели для видов регионального государственного контроля (надзора) утверждаются высшим исполнительным органом государственной власти субъекта Российской Федерации.

5. Ключевые показатели вида контроля и их целевые значения, индикативные показатели для видов муниципального контроля утверждаются представительным органом муниципального образования.

6. В случае, если на ключевые показатели вида контроля влияет деятельность нескольких контрольных (надзорных) органов, для такого вида контроля разрабатываются и утверждаются межведомственные ключевые показатели вида контроля.

7. Не допускается установление ключевых показателей вида контроля, основанных на количестве проведенных профилактических мероприятий и контрольных (надзорных) мероприятий, количестве выявленных нарушений, количестве контролируемых лиц, привлеченных к ответственности, количестве и размере штрафов, наложенных на контролируемых лиц в соответствии с Кодексом Российской Федерации об административных правонарушениях, законами субъектов Российской Федерации об административной ответственности.

8. Контрольные (надзорные) органы ежегодно осуществляют подготовку доклада о виде контроля с указанием сведений о достижении ключевых показателей и сведений об индикативных показателях видов контроля, в том числе о влиянии профилактических мероприятий и контрольных (надзорных) мероприятий на достижение ключевых показателей.

9. На основании докладов о видах контроля федеральным органом исполнительной власти, осуществляющим функции по выработке государственной политики и нормативно-правовому регулированию в области государственного контроля (надзора) и муниципального контроля, ежегодно готовится сводный доклад о государственном контроле (надзоре), муниципальном контроле в Российской Федерации.

10. Требования к подготовке докладов о видах контроля и сводного доклада о государственном контроле (надзоре), муниципальном контроле в Российской Федерации устанавливаются Правительством Российской Федерации.

11. Сводный доклад о государственном контроле (надзоре), муниципальном контроле в Российской Федерации ежегодно не позднее 1 июля направляется Правительством Российской Федерации в Государственную Думу и Совет Федерации Федерального Собрания Российской Федерации, а также размещается для всеобщего сведения на официальном сайте Правительства Российской Федерации в сети “Интернет”.

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

[Параллельный номер]

show global status like ‘Threads_running’;

【Тупик】

способ 1:Просмотрите последнюю информацию о тупиках:

show engine innodb status;

Метод 2: используйте инструмент Percona pt-deadlock-logger

1. Включите глобальный переключатель тупиковой печати.

set global innodb_print_all_deadlocks=on;

2. Используйте инструмент pt-deadlock-logger.

Результаты отслеживаемых взаимоблокировок можно вывести в файл, указанную таблицу или на печать интерфейса. Чтобы

pt-deadlock-logger h = IP базы данных, u = имя пользователя базы данных, p = пароль базы данных

Вывод очень подробный:

server: адрес сервера базы данных, то есть хост базы данных, созданный тупиковой ситуацией

ts: отметка времени, когда была обнаружена взаимоблокировка.

thread: идентификатор потока, который вызвал тупик, этот идентификатор совпадает с идентификатором потока в списке процессов show

txn_id: идентификатор транзакции Innodb

txd_time: время выполнения транзакции до проверки взаимоблокировки

пользователь: имя пользователя, выполняющего преобразование

hostname: имя хоста клиента

ip: ip клиента

db: имя БД, в которой произошла тупиковая ситуация.

tbl: имя таблицы, в которой произошел тупик

idx: имя индекса, вызвавшего взаимоблокировку (в приведенной выше демонстрации первичный ключ, который мы использовали напрямую, добавлена ​​блокировка записи)

lock_type: тип блокировки (блокировка записи, блокировка промежутка, блокировка следующего ключа)

lock_mode: режим блокировки (S, X)

wait_hold: ждать ли освобождения блокировки, обычно взаимоблокировки – это два ожидания

жертва: была ли сессия принесена в жертву и прекратилось ли выполнение

query: оператор SQL, вызвавший взаимоблокировку

【Индекс QPS】

show global status where variable_name in (‘Queries’, ‘uptime’);

QPS = (Queries2 -Queries1) / (uptime2 – uptime1)

【Задержка ведущий-ведомый】

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

Метод 2: используйте инструмент Percona pt-heartbeat

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

–daemonize Фоновое выполнение.

–interval = 1 Время выполнения по умолчанию – 1 секунда.

Параметр –monitor предназначен для непрерывного мониторинга и вывода результатов

Дальнейшее чтение

Xiaomi открытый сокол:

Netease мониторинга на уровне предприятия:

Используйте метрики для мониторинга производительности приложений:

Углубленное введение в предварительную обработку базы данных временных рядов:

Шесть, план запроса данных мониторинга

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

• Запрос исходных данных (таких как данные мониторинга бизнеса)
• Запросы для операций агрегации данных временных рядов (таких как данные мониторинга системы)

Расчет и анализ отображения индикатора мониторинга:

Логика расчета пользовательских журналов в мониторинге – это определяемый пользователем метод расчета (потому что это бизнес-мониторинг), который в основном состоит из числа строк, суммы значений столбца, среднего значения столбца, максимального значения значений столбца и значения столбца. Найдите минимальное значение: крупномасштабный дисплей данных не объединяет данные, показывая собранные необработанные данные (исходные данные делятся на секунды и минуты), если вам нужно выполнить вычисления, это делается с помощью функции агрегирования внешнего интерфейса Бизнес обработка.

2 Классификация агрегации данных

В процессе мониторинга данных мы часто анализируем одну машину или несколько (кластерных) машин, и каждый анализ добавляет понятие времени, например, использовать ли точки необработанных данных или несколько Комбинация точек формирует новую точку. Поэтому мы разделяем вычисление анализа данных на два измерения, одно из которых – «машинное» измерение (пространственная агрегация), и одно временное измерение (агрегация времени): в метрической модели мы определяются двумя методами, один из которых является агрегатором, а другой – вниз образец.

Агрегатор: используется для описания метода агрегации сбора данных в один и тот же момент времени, например, загрузка ЦП кластера, среднее значение использования ЦП всеми компьютерами в кластере в определенное время, следует отметить, что при По мере того, как размер кластера увеличивается, нам также необходимо произвести выборку из этого набора данных и затем выполнить агрегированные вычисления.

Образец с понижением: используется для описания метода агрегирования данных в нескольких временных точках, например, машина собирает данные об использовании ЦП каждые 5 секунд. Когда отображаются окончательные данные, они должны отображаться в точке 1 минуты, затем В этом наборе данных будет 12 элементов данных без потери данных. Нам нужно объединить эти 12 элементов данных в один элемент данных.

3 Метод агрегирования данных

Метод агрегирования данных, как правило, можно разделить на «предварительную агрегацию» и «постагрегацию»; ранняя агрегация может вызвать расширение данных, но может повысить скорость ответа при доступе к запросу. Хотя агрегация снижает определенные затраты на хранение во время доступа, она может замедлить ответ скорость.

Большинство систем мониторинга обычно поддерживают предварительную агрегацию (архивацию) обработки данных (например, тренды таблиц архива данных zabbix), поскольку общий цикл сбора необработанных данных относительно мал, например, минуты, поэтому представлению, отображающему долгосрочные данные, необходимо сканировать слишком много данных. , Отображение относительно медленное. Если данные архивируются в почасовые и суточные данные, эффективность данных с большим промежутком времени значительно повышается, при предварительной обработке данных на основе Metric обычно используется механизм предварительной агрегации потоков для сокращения данных Обработка точности, такая как продукт AliPass DBPass, заранее снизит временную точность данных индикатора, разделенную на 6 значений точности: 1 секунда, 5 секунд, 15 секунд, 1 минута, 5 минут, 15 минут.

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

4 Алгоритм расчета данных

При сборе и расчете данных клиента мы обычно сталкиваемся с необходимостью агрегирования данных, которое в основном основано на агрегации данных автономного измерения. Например, мы ожидаем, что данные будут собираться в течение фиксированного периода. Если в каждом диапазоне периодов имеется несколько данных Точка (D1, D2, D3), как мы вычисляем, чтобы получить данные точки?

Обычно есть следующие методы расчета:

• Случайная выборка
• Раздвижное окно
• Скользящее временное окно;
• Случайная выборка с экспоненциальным затуханием (EWMA);

Java-реализация EWMA может относиться к:EWMA.java Алгоритм EWMA поддерживает коллекцию фиксированного размера и считает, что веса элементов в коллекции различны. Вес элементов показывает экспоненциальный спад с расстоянием элементов от текущего времени. Основная цель состоит в том, чтобы решить дискретные точки в наборе данных и сгладить кривую данных. Например, текущая логика вычислений Load1, Load5 и Load15 использует алгоритм EWMA;

5 API запроса данных

MySQL5.7 и новее:

Чтобы облегчить запрос индикаторов блокировки, MySQL объединяет две таблицы для построения представления.sys.innodb_lock_waits, Оператор запроса можно значительно упростить.

[Показатель попадания в кеш]

Общее количество запросов пула буферов innodb:

show global status like ‘innodb_buffer_pool_read_requests’;

Номер запроса Innodb с диска:

show global status like ‘innodb_buffer_pool_reads’;

План анализа данных

Существующие модули анализа данных системы мониторинга в основном делятся на две категории:

• Пакетная модель
• Модели потоковой обработки (Spark Streaming, Storm, Flink);

Вывод: учитывая, что на этом этапе нам требуется меньше узлов развертывания, простая топология и ограниченное время цикла НИОКР, мы в настоящее время принимаем решение для потоковой обработки. После получения данных они напрямую отправляются на сервер для анализа и обработки;

2 Анализ точек мониторинга

Пользователи могут сконфигурировать индикаторы мониторинга для определения пороговых значений по системным индикаторам, которые им небезразличны. Например, выберите партию машин и обратите внимание на загрузку ЦП, превышающую 90%. Затем система мониторинга должна выставить эти партии машин с загрузкой ЦП, превышающей 90% во время упражнения. Индикаторы найдены и преобразованы в события событий. Это похоже на модель системы охранной сигнализации в системе мониторинга.

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

Каждый модуль Data Analyzer будет содержать коллекцию наборов правил. Коллекция наборов правил хранит интересующие правила после того, как они вступят в силу. После того, как данные мониторинга достигают механизма анализа, механизм анализа использует механизм фильтрации, чтобы определить, было ли выполнено правило. Если правило выполнено, то Согласно правилам и данным, формируются данные события Event, которые используются для описания того, что индикатор мониторинга достигает порогового значения индикатора мониторинга. В последующем обзоре события индекса в библиотеке событий могут быть агрегированы и проанализированы для формирования необходимого отчета о заключении.

Механизм регистрации и обновления правил:

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

Текущее правило – метод хранения в памяти. Когда система запускается, загрузите полный эффективный индекс фокуса из базы данных, влияние каждой машины должно поддерживать часть данных в памяти. Если машине не удается обновить данные, это принесет В случае согласованности данных мы рассмотрим перемещение этой части данных на общедоступное внешнее устройство быстрого хранения, такое как Redis.

Мы называем порог сконфигурированного пользователем фокуса на системных индикаторах «тревогами». При оценке условий тревоги и процесса хранения основными моделями предметной области являются: Хосты, Метрики, триггеры, функции, элементы, события, действия;

• хосты: хранит информацию о контролируемом хосте;
• метрики: хранить отслеживаемые метрики данных;
• items: Хранить информацию о конфигурации поддерживаемых элементов мониторинга.
• триггеры: хранить информацию, связанную с триггером;
• события: хранить данные события;
• действия: сохранить действия, которые необходимо предпринять при срабатывании триггера (больше не входит в объем исследований и разработок);

Модель расчета триггера:

Примеры моделей расчета:

Агрегатная функция в триггере:

• макс максимальная
• минимум минимум
• Средний средний

Объектами модели предметной области, участвующими в области анализа индикаторов мониторинга, являются:

• items
• triggers
• events
• actions

Модель данных и отношения следующие:

Соотношение между группой ресурсов и триггером составляет 1: n, элемент мониторинга и триггер 1: 1, а триггер и событие 1: 1.

【Индекс TPS】

show global status where variable_name in (‘com_insert’ , ‘com_delete’ , ‘com_update’, ‘uptime’);

Количество транзакций TC ≈’com_insert’ , ‘com_delete’ , ‘com_update’

TPS  ≈ (TC2 -TC1) / (uptime2 – uptime1)

[Медленный запрос]

способ 1:Включить журнал медленных запросов。my.inf

slow_query_log=on
slow_query_log_file = Каталог хранения
long_query_time = 0,1 секунды
log_queries_not_using_indexes=on

Примечание: он действует только для новых подключений и действует в реальном времени.Используйте команду set global для настройки вышеуказанных элементов конфигурации. Чтобы

select * from information_schema.’processlist’;

Три, программа сбора данных

Проблемы сбора данных:

• Различные источники данных
• Большой объем данных
• Быстро изменить
• Как обеспечить надежную производительность сбора данных
• Как избежать дублирования данных
• Как обеспечить качество данных

1 Схема сбора

В настоящее время существует два широко используемых метода сбора данных:

Схема сбора существующей системы мониторинга:

Принципиальная схема активного мониторинга (Push):

Сервер предоставляет адрес доменного имени, который принимает запросы данных, клиент отправляет данные на сервер, а сервер отвечает за анализ и хранение данных;

Принципиальная схема пассивного мониторинга (Pull):

Основные функции агента:

• LogFinder: может возвращать данные мониторинга в интервале в соответствии с запрошенным интервалом времени;
• LogQuery: может найти позицию журнала в соответствии со смещением;
• LogCompression: поддержка сжатия данных журнала;

Эта часть может относиться к логике реализации LogAgent.

• Легкий;
• Масштабируемость;
• Поддержка системы мониторинга (ОС), бизнес-мониторинга (Агент)
• Агент поддержки автоматической регистрации и активной отчетности статических данных;
• Контролируемые элементы контролируются для включения и выключения с помощью функции переключателя (необычно установленного);
• Необходимо иметь возможности накопления данных;
• Необходимо иметь возможность расширять несколько источников данных;

Клиент записывает данные индикатора, записывая журнал локального диска, а сервер извлекает данные клиенту путем активного извлечения;

2 Распределенное планирование задач

Мы используем сервер для извлечения логов, поэтому нам нужна среда для периодического планирования нескольких узлов для извлечения логов. В настоящее время служба распределенного планирования времени Alibaba Group имеет scheduleX и Quartz с открытым исходным кодом. Учитывая необходимость независимого вывода служб для сокращения зависимых компонентов, мы выбрали Quartz после оценки рабочей нагрузки интеграции распределенных постоянных задач Quartz. В настоящее время пружина имеет встроенный кварц, чтобы упростить использование кварца. Необходимо не только планировать мониторинг сбора данных, но также требовать распределенных сервисов планирования задач в таких сценариях, как синхронизация запуска упражнений и синхронизация открытия упражнений, поэтому он предоставляет универсальный набор, независимый от бизнеса. API сервиса распределенного планирования необходим. Интерфейс на основе пружинного кварца инкапсулирует унифицированную службу интерфейса службы распределенного планирования SchedulerService, эта часть представляет собой отдельный модуль.

3 Метрический индекс данных

Журналы, напечатанные клиентом, не имеют метрического формата, и данные, собранные с помощью данных журнала, должны быть преобразованы в унифицированный метрический формат преобразователем Transfer;

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

• Индикаторы мониторинга ОС системы;
• Показатели эффективности приложений;

Метрическое значение индекса мониторинга системы:

Метрическое значение показателей мониторинга производительности приложений:

Где устройство хранит agentId, а транзакция хранит имя запроса;

Соглашение об именовании метрик

4 Преобразование данных

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

【Статус ведущего-ведомого】

Во-вторых, архитектура системы мониторинга отрасли

【Количество подключений】

show global status like ‘Threads_connected’;

Максимальное количество подключений:

show global status like ‘max_connections’;

Решение для хранения данных

Мы делим типы данных на пять категорий:

• Данные индикатора метрики (разделенные на сервер и контейнер)
  Определение: метрика описывает значение индикатора в определенный момент времени. Теги можно использовать для разделения тегов метаданных, например, индикаторов мониторинга системы ОС;
• Определение: метрика описывает значение индикатора в определенный момент времени. Теги можно использовать для разделения тегов метаданных, например, индикаторов мониторинга системы ОС;
• Данные о событии (включая: систему, сбор данных Docker)
  Определение: событие записывает конкретную информацию, которая происходит в определенное время в системе, такую ​​как выдача правил, запуск и остановка сбоев, установка и удаление MkKit, а также события, генерируемые конфигурацией правила триггера Metric;
• Определение: событие записывает конкретную информацию, которая происходит в определенное время в системе, такую ​​как выдача правил, запуск и остановка сбоев, установка и удаление MkKit, а также события, генерируемые конфигурацией правила триггера Metric;
• Записывать данные журнала времени выполнения
  Определение: данные событий могут быть помечены в соответствии с потребностями бизнеса для упрощения их анализа и анализа во время анализа, а события записываются в текст для обогащения контекстной информации.
• Определение: данные событий могут быть помечены в соответствии с потребностями бизнеса для упрощения их анализа и анализа во время анализа, а события записываются в текст для обогащения контекстной информации.
• Данные сердцебиения
  Определение: периодический отчет о состоянии, такой как информация пульса оператора, состояние процесса и т. Д .;
• Определение: периодический отчет о состоянии, такой как информация пульса оператора, состояние процесса и т. Д .;
• Данные трассировки
  Определение: записать информацию трассировки запроса на ввод ошибки;
• Определение: записать информацию трассировки запроса на ввод ошибки;

2 Решение для хранения данных

Данные мониторинга представляют собой данные временного ряда.В связи с огромным количеством отслеживаемых объектов носитель данных должен поддерживать высокую пропускную способность записи, хорошую масштабируемость, быстрое чтение последних данных, несколько типов данных и несколько типов. Методы сканирования и другие характеристики, в настоящее время основными методами хранения являются SQL и NoSQL. Для сравнения, NoSQL имеет преимущества в пропускной способности и масштабируемости хранения данных, а SQL имеет преимущества в поддержке типов данных и разнообразия сканирования.

В целом, данные мониторинга больше подходят для использования последовательных носителей, таких как OpenTSDB, HiTSDB и т. Д. По разным причинам мы временно используем Mysql, Mysql может в определенной степени упростить нашу архитектуру, ускорить работу бизнеса.

Без сжатия: 100 машин одновременно собирают до 30 дней, занимая 49 ГБ пространства (один расчёт 1 КБ, хранение раз в 5 секунд).

5.3 Распространенные решения для хранения в отрасли

Cassandra InfluxDB MongoDB OpenTSDB KairosDB HBase

4 Спецификация хранения индекса мониторинга

Следуйте метрическим спецификациям;

Метрика состоит из двух частей: метрического ключа и метрического тега:

• ключ метрики: это строка, разделенная точками на английском языке, используемая для характеристики значения этого индикатора
• метрический тег: он определяет различные размеры срезов этого индикатора, один или несколько
  ключ тега: имя, используемое для описания измерениязначение тега: значение, используемое для описания измерения
• ключ тега: имя, используемое для описания измерения
• значение тега: значение, используемое для описания измерения

Формат данных метрики выглядит следующим образом:

• ключ метрики: хранит ключ текущей метрики
• метрическая метка: хранит метку текущей метрики
• значение метрики: хранит текущее значение метрики
• отметка времени: хранит текущую отметку времени
• метаданные: хранить мета-информацию о текущем индикаторе

В спецификации Metric для мультитенантного проекта в облаке мы добавили два поля, пространство имен и область действия, для классификации метрики: одно с точки зрения пользователя, а другое с точки зрения набора функций, формируя свойства объекта MetricObject. Описание выглядит следующим образом:

MetricType Тип метрики (ссылка:http://metrics.dropwizard.io/4.0.0/getting-started.html)：

• СЧЕТЧИК: для кумулятивных данных, отражающих монотонно возрастающую взаимосвязь данных со временем, например общее количество HTTP-запросов, полученных Tomcat
• ГАБАРИТ: Используется для переходных данных, указывающих мгновенное положение индикатора в текущее время, отражающих взаимосвязь данных, колеблющихся со временем вверх, таких как загрузка системы, использование памяти JVM
• METER: используется для измерения показателей скорости изменения, отражающих взаимосвязь между скоростью роста данных во времени, такой как QPS интерфейса
• ГИСТОГРАММА: используется для измерения распределенных данных, отражающих статистическое распределение данных во времени

Решение для хранения тегов:

Поскольку текущим техническим выбором решений для хранения в производственной среде является использование Mysql для хранения метрических данных, Mysql не поддерживает структуру без схемы, поэтому невозможно динамически расширять ключ-значение тегов. Мы используем режим фиксированного столбца Mysql, предоставляя встроенные теги для достижения Та же цель: ключ в тегах – это имя столбца в Mysql, а значение поля – значение тегов;

Встроенное поле тега:

Mysql модель данных выглядит следующим образом: