Следите за ходом разработки

бизнес на ранней стадии

Мониторинга нет, все вручную пялятся на сервер, операционная система, софт, сеть и так далее.


Предприятие на ранней стадии 

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

среднесрочное предприятие 

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


Предприятия средней и поздней стадии 

Кластерный мониторинг различных решений для мониторинга иностранной помощи.


Мониторинг стал самодостаточным, добавились различные автоматики. Помимо самостоятельной разработки и построения системы мониторинга, он также использует много периферийного мониторинга (мониторинг различных товаров, таких как мониторинг облачных вычислений, мониторинг Baoyoumeng и т. д.)
 для мониторинга развития внутреннего мониторинга + внешнего мониторинга (внутренний мониторинг — это собственная система мониторинга предприятия. Встроенный мониторинг для самостоятельного использования, внешний мониторинг — это коммерческий продукт мониторинга, который использует внешнюю помощь для мониторинга самого внешнего интерфейса продукта и поведения пользователя на более макроуровне)

картина

Текущий и будущий мониторинг
В соответствии с текущим состоянием разработки
будущий мониторинг будет постоянно улучшаться в нескольких

  • Мониторинг точности подлинности

  • Автоматический мониторинг высокоинтегрированной автоматизации

  • Постепенное снижение затрат на мониторинг

  • Интеграция мониторинга и CMDB и разработка самовосстанавливающихся систем

В связи с непрерывным построением интеллектуальной эксплуатации и обслуживания предприятия CMDB становится все более важным средством управления данными об эксплуатации и обслуживании. Традиционное управление конфигурацией имеет такие проблемы, как низкое качество данных, сценарии однократного потребления и неспособность поддерживать бизнес. Продукт управления конфигурацией (CMDB) управляет метаданными эксплуатации и обслуживания ИТ предприятия и обеспечивает правильность данных, а также способствует реализации сценариев потребления данных, связанных с мониторингом эксплуатации и обслуживания, управлением услугами, автоматизацией эксплуатации и обслуживания и анализом операций с настраиваемая и поддерживаемая поддержка данных.

Технологии и инструменты, которые в настоящее время практичны для предприятия

  • Скрипт-мониторинг (в настоящее время компании, которые до сих пор используют самую примитивную форму скрипта для сбора и мониторинга, все еще нередко в
    целях экономии)

  • Инструменты мониторинга с открытым/неоткрытым исходным кодом, такие как: Nagios/Cacti/icinga/Zabbix/Ntop/prometheus/и т. д.

  • Система сигнализации: Pagerduty / самодельная система голосового оповещения / самодельная почтовая система / самодельное SMS-уведомление / различные коммерческие продукты сигнализации

Мониторинг некоторых проблем, с которыми в настоящее время сталкиваются

  • Автоматизации наблюдения по-прежнему недостаточно

  • Редко идеально интегрируется с CMDB

  • Мониторинг по-прежнему требует много рабочей силы

  • Точность и достоверность мониторинга медленно улучшаются

  • Формулировка инструментов и программ мониторинга относительно небрежна.

  • Акцент на самом мониторинге все еще нуждается в улучшении

Идеальное наблюдение будущего

  • Полная самовосстанавливающаяся система мониторинга

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

  • Истинный мониторинг ссылок

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

Например, реальная проблема заключается в том, что новый совместный запрос к базе данных потребляет слишком много системных ресурсов, что приводит к потреблению большого количества ресурсов во всех аспектах и ​​косвенно вызывает различные проблемы со связью.

В результате тревоги на различных уровнях следуют одна за другой, например, тревоги журнала, тревоги медленных запросов, тревоги памяти ЦП базы данных, тревоги накопления каналов TCP уровня программы и тревоги с кодом возврата HTTP 5xx 499.

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

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

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

картина

Система мониторинга и сигнализации Prometheus

Sanfeng, публичная учетная запись: программная система мониторинга и сигнализации Zhang Sanfeng Prometheus

Данные метрик, окончательно полученные prometheus, отображаются в виде K / V. В соответствии со значением ключа мы можем запросить соответствующее значение, но нам нужно получить элемент мониторинга производительности системы (приложения), который мы хотим, вычислив данные, а затем установите соответствующие пороговые значения для сигналов тревоги.

Возьмите загрузку процессора в качестве примера

node_cpu — это ключ, возвращаемый node_exporter, который можно использовать для подсчета использования процессора.

Этот ключ представляет собой кумулятивное значение базового среза времени процессора в Linux.

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

Накопленное время использования ЦП также делится на несколько важных типов состояния.

Процессорное время делится на время пользователя (время использования в пользовательском режиме)/системное время (время использования в режиме ядра)/удобное время (время использования удобного распределения значений)/время простоя (время простоя)/IRQ (время прерывания) и т. д.

Загрузка ЦП: сумма всех состояний ЦП, кроме состояния простоя (бездействия)/общее время ЦП, то есть загрузка ЦП = 100%-простой/всего.

node_cpu представляет совокупное значение времени использования каждого ядра процессора и каждого состояния

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

увеличить (): используется для перехвата приращения периода времени для постоянно увеличивающегося значения счетчика, например, увеличение (node_cpu [1m]) представляет собой приращение общего времени процессора в течение одной минуты.

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

sum(): действует как дополнение

sum(увеличить(node_cpu[1m])) означает приращение процессорного времени под всеми ядрами в течение одной минуты

Время использования процессора в состоянии простоя получается путем фильтрации по тегу node_cpu{mode="idel"}.

sum(увеличить(node_cpu{mode="idel"}[1m])) означает приращение процессорного времени всех ядер в состоянии простоя в течение одной минуты

Но запрос в браузере выражений - это данные всех хостов мониторинга.Использование функции sum() означает добавление процессоров всех клиентов к сумме.

by(): значение, сложенное вместе по сумме, разбивается на один слой в соответствии с указанным методом.

by(instance) означает различение разных машин

sum(увеличить(node_cpu{mode="idel"}[1m]))by(instance) представляет приращение процессорного времени всех ядер за одну минуту в состоянии простоя одной машины

sum(увеличить(node_cpu[1m]))by(instance) представляет приращение процессорного времени всех ядер за одну минуту во всех состояниях одной машины

1-sum(увеличить(node_cpu{mode="idel"}[1m]) )by(instance)/sum( увеличить(node_cpu[1m]))by(instance)*100 означает использование всех основных процессоров одного скорость машины

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

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

1. Фильтрация данных

1. Фильтрация тегов

(текстовое примечание под диаграммой Prometheus)

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

Формат: key{label1="value1", label2="value2", … }. Когда метка исходит из собранных данных, экспортеры предоставляют ее по умолчанию или определяют пользователь (например, при запросе node_cpu_seconds_total, node_cpu_seconds_total{cpu ="1", экземпляр = "localhost: 9100", задание = "агент", режим = "пользователь"})

Вы можете указать метку при запросе:

точное совпадение = :node_cpu_seconds_total{mode="idle"}

Нечеткое соответствие ~=:node_cpu_seconds_total{mode=~".*"}

Нечеткое несоответствие !=: node_cpu_seconds_total{mode!="idle.*"}

2. Численная фильтрация

Пример: node_cpu_seconds_total{mode=~".*"} > 6000

node_exporter

1 Мониторинг использования процессора

(1) Сбор linux cpu Prometheus напрямую не возвращает готовый процент процессора, а возвращает кумулятивное значение базового среза времени процессора в системе linux; вместо того, чтобы просматривать использование процессора простым способом через команда top или uptime Rate.

(2) Время ЦП: после включения системы Linux ЦП начинает входить в рабочее состояние. ЦП записывает совокупное количество «времени», используемого в работе, и сохраняет его в операционной системе. Время использования ЦП. в каждом состоянии Accumulates from 0, а node_exporter захватывает накопленные значения времени 8 часто используемых состояний процессора:

время пользователя процессора: время использования пользовательского режима процессора

sys time: время использования состояния системы/ядра

хорошее время: хорошее время использования распределения стоимости

время простоя: время простоя

irq: время прерывания

… и многое другое

(3) Коэффициент использования ЦП относится к различным состояниям ЦП, сумме всех других состояний, кроме простоя, деленной на общее время ЦП: node_cpu_seconds_total — это общее время использования ЦП ЦП от загрузки до текущего ; Следовательно, алгоритм использования процессора: (1 - сумма (увеличение (node_cpu_seconds_total{mode="idle"}[1m])) на (экземпляр) / сумма (увеличение (node_cpu_seconds_total{}[1m])) на (экземпляр)) * 100

Объяснение формулы:

Предположим, система запускается и работает в течение 30 минут (количество ядер временно не учитывать, предположим, что 1 ядро), за это время загрузка процессора следующая: 8 минут в пользовательском режиме + 15 минут в режиме ядра + 0,5 минуты в режиме ввода-вывода. состояние ожидания + 20 минут в состоянии бездействия + 0 минут в других состояниях, затем загрузка ЦП = (сумма времени использования ЦП во всех состояниях, кроме бездействия) / (сумма времени ЦП во всех состояниях), т. е. (пользователь(8мин) + sys(1.5m) + iowa(0.5m) + 0)/(30m))= ((30m) - idle(20m) / (30m))=33,3%, средняя загрузка процессора за эти 30 минут составляет 30%.

(4) Сбор данных в нижней части Prometheus, мониторинг, сформированный по точному алгоритму, является более точным и достоверным.

(5) Разделение формулы расчета использования ЦП

В целом загрузка процессора получается по методу (1-idle/total)*100%:

(1 - сумма (увеличение (node_cpu_seconds_total {mode = "idle"} [1 м])) на (экземпляр) / сумма (увеличение (node_cpu_seconds_total {} [1 м])) на (экземпляр)) * 100

1) Выберите ключ для использования

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

2) Фильтровать время простоя ЦП и общее время ЦП.

node_cpu_seconds_total{mode="idle"}: в это время введите результат выполнения в консоли prometheus и продолжайте увеличивать время простоя ЦП каждого ядра ЦП после фильтрации.

node_cpu_seconds_total{}: введите результат выполнения в консоли prometheus в это время, и общее время использования ЦП каждого ядра ЦП после фильтрации продолжает расти.

3) Получите приращение времени простоя ЦП за одну минуту и ​​приращение общего времени ЦП за одну минуту.

увеличить(node_cpu_seconds_total{mode="idle"}[1m]), в это время введите результат выполнения в Консоли прометея, приращение времени простоя каждого ядра ЦП после фильтрации в течение одной минуты

увеличить(node_cpu_seconds_total{}[1m]), в это время введите результат выполнения в консоль prometheus, и общее время использования ЦП каждого ядра ЦП после фильтрации увеличивается в течение одной минуты

4) Суммируйте инкрементную сумму времени простоя ЦП всех ядер ЦП в течение одной минуты и инкрементную сумму общего времени всех ядер ЦП в течение одной минуты.

sum(increase(node_cpu_seconds_total{mode="idle"}[1m])), в это время результат выполнения, введенный в консоли prometheus, представляет собой отфильтрованное время простоя ЦП каждого ядра ЦП всех отслеживаемых серверов в пределах одной минуты суммы приращений

sum(increase(node_cpu_seconds_total{}[1m])), в это время результат выполнения, введенный в консоли prometheus, представляет собой сумму приращений общего времени использования ЦП в течение одной минуты каждого ядра ЦП всех отслеживаемых серверов после фильтрация

5) Различать суммарное время простоя ЦП и общее время использования ЦП сервером.

sum(increase(node_cpu_seconds_total{mode="idle"}[1m])) by(instance), в это время результат выполнения, введенный в консоль prometheus, состоит в том, что отфильтрованное время простоя ЦП каждого ядра ЦП каждого сервера один Сумма приращений в минутах

sum(increase(node_cpu_seconds_total{}[1m])) by(instance), в это время результат выполнения, введенный в консоли prometheus, представляет собой приращение общего времени использования ЦП каждого ядра ЦП каждого сервера после фильтрации в течение одного минутная сумма

6) Рассчитайте по формуле (1-простой/всего)*100%:

(1 - сумма (увеличение (node_cpu_seconds_total {mode = "idle"} [1 м])) на (экземпляр) / сумма (увеличение (node_cpu_seconds_total {} [1 м])) на (экземпляр)) * 100

(6) Таким же образом найдите загрузку процессора в других состояниях.

us: (sum(increase(node_cpu_seconds_total{mode="user"}[1m])) by(instance) / sum(increase(node_cpu_seconds_total{}[1m])) by(instance)) * 100

sy: (сумма (увеличение (node_cpu_seconds_total {mode = "system"} [1 м])) на (экземпляр) / сумма (увеличение (node_cpu_seconds_total {} [1 м])) на (экземпляр)) * 100

ni: (сумма (увеличение (node_cpu_seconds_total {mode = "nice"} [1 м])) на (экземпляр) / сумма (увеличение (node_cpu_seconds_total {} [1 м])) на (экземпляр)) * 100

id: (сумма (увеличение (node_cpu_seconds_total {mode = "idle"} [1 м])) на (экземпляр) / сумма (увеличение (node_cpu_seconds_total {} [1 м])) на (экземпляр)) * 100

wa: (sum(increase(node_cpu_seconds_total{mode="iowait"}[1m])) by(instance) / sum(increase(node_cpu_seconds_total{}[1m])) by(instance)) * 100

привет: (сумма (увеличение (node_cpu_seconds_total {mode = "irq"} [1 м])) на (экземпляр) / сумма (увеличение (node_cpu_seconds_total {} [1 м])) на (экземпляр)) * 100

si: (сумма (увеличение (node_cpu_seconds_total {mode = "softirq"} [1 м])) на (экземпляр) / сумма (увеличение (node_cpu_seconds_total {} [1 м])) на (экземпляр)) * 100

st: (сумма (увеличение (node_cpu_seconds_total {mode = "украсть"} [1 м])) на (экземпляр) / сумма (увеличение (node_cpu_seconds_total {} [1 м])) на (экземпляр)) * 100

То есть использование процессора, запрашиваемое командой top:

(7) В производственной среде высокая загрузка ЦП более 70-80% обычно вызвана высокой нагрузкой ЦП пользователя в пользовательском режиме. Использование ЦП в пользовательском режиме тесно связано с запуском приложения.Когда на сервере запущено большое количество процессов для параллельной обработки задач, и процессы часто переключаются между страницами, потребление ЦП в пользовательском режиме является самый большой.

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

Во многих случаях, когда использование ввода-вывода на жестком диске сервера слишком велико, ЦП будет ждать возврата ввода-вывода, чтобы ввести время ожидания ЦП типа interuptable, поэтому также необходим мониторинг iowait ЦП.

пользователь: (сумма (увеличение (node_cpu_seconds_total {mode = "user"} [1 м])) на (экземпляр) / сумма (увеличение (node_cpu_seconds_total {} [1 м])) на (экземпляр)) * 100

iowait: (сумма (увеличение (node_cpu_seconds_total {mode = "iowait"} [1 м])) на (экземпляр) / сумма (увеличение (node_cpu_seconds_total {} [1 м])) на (экземпляр)) * 100

Порог для мониторинга ЦП, установленный на уровне 99% или 100%: в общем, сервер с использованием ЦП на уровне 80–90% все еще может обрабатывать запросы, но скорость будет ниже; когда загрузка ЦП находится в диапазоне 98–100 %, то весь сервер практически теряет доступность. (Очень важна оптимизация под linux систему, управляйте сервером через различные параметры ядра и программные параметры, старайтесь не допускать загрузки процессора до 99%-100%)

Мониторинг Прометея (1)

Sanfeng, публичный аккаунт: мониторинг программного обеспечения Zhang Sanfeng Prometheus (1)

Мониторинг Прометея (2)

Sanfeng, публичная учетная запись: мягкий мониторинг Zhang Sanfeng Prometheus (2)

Мониторинг Прометея (3)

Sanfeng, публичный аккаунт: мониторинг мягкого Zhang Sanfeng Prometheus (3)

Мониторинг Прометея (4)

Sanfeng, публичная учетная запись: мягкий мониторинг Zhang Sanfeng Prometheus (4)

распределенная теория

Sanfeng, публичный аккаунт: мягкая распределенная теория Zhang Sanfeng

Добавьте WeChat в коммуникационную группу микросервиса WeChat и обратите внимание, что микросервис входит в групповую коммуникацию.

картина

Обратите внимание на софт паблик-аккаунта Zhang Sanfeng 
картина