Телеметрический выход счетчика это: Качество или цена – Энергетика и промышленность России – № 5 (57) май 2005 года – WWW.EPRUSSIA.RU

Содержание

Записки IoT-провайдера. Проклятие импульсного выхода / Хабр

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



Начнем с теории.

Импульсный выход (ИВ) — это два контакта, которые выходят из прибора учета. Внутри счетчика может стоять геркон или некое подобие реле. Замыкание происходит механически. Между контактами периодически возникает падение сопротивления. Одно падение — один импульс. Данная схема вообще не требует какой-либо электроники внутри счетчика, только на устройстве съема.

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

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

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

Водосчетчик «пропустил» через себя кубический метр воды. Вес его импульса — 0,1 м3. Это значит, что в процессе прохождения воды мы зафиксируем 10 импульсов. Зная вес, легко посчитать сколько ресурсов намотал тот или иной прибор.

Звучит просто?

Пока да. Проблемы начинаются в процессе эксплуатации.

Съем показаний обеспечивают специальные модули — счетчики импульсов (СИ). Они могут быть проводные или беспроводные, с батарейкой или от 220. Но смысл один — счетчик импульсов — это обычный конвертер из одного интерфейса в другой. Посчитав замыкания контактов, СИ передает эту информацию на сервер. Каким путем уже дело десятое.

Так где же кроется проклятье?

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

Такая ли это большая проблема?

Если вы подключаете установленный прибор учета, то нужно просто переписать начальные показания счетчика. Внести эту поправку в ваш интерфейс и работать дальше. Все просто?

Нет. Тут начинаются подводные камни:

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

2) Человеческий фактор №2. К сожалению, не все обладают прямыми руками из плеч. Если провода от ИВ некачественно смонтированы в клеммной колодке счетчика импульсов, то может начаться такая неприятная штука, как погрешность замера. С одинаковой вероятностью это может внести ошибку как в большую, так и в меньшую сторону.

3) Пресловутый вес импульса. Отлично, если он нанесен на сам прибор учета гравировкой. Неплохо, если он вообще есть на приборе. Но часто заветная цифра оказывается только в документации. Если речь про уже установленные приборы учета, высока вероятность, что документацию потеряли или она «где-то там». Гугление вам не поможет, у многих приборов учета в общих паспортах указаны только возможные веса. На на конкретный прибор надо смотреть конкретный паспорт. Которого нет. И тут начинается игра «угадай вес импульса по опыту».


Пример хорошего счетчика. Вес импульса на корпусе, на самом видном месте.

4) Дополнительные внешние факторы. К примеру, слишком длинный кабель от прибора учета к счетчику импульсов. Или кабель высокого напряжения в одном стояке. Все это может вызывать погрешности в подсчетах. А для ИВ на открытом коллекторе еще важна полярность подключения — дополнительная возможность ошибиться.

Казалось бы — все проблемы так или иначе связаны с качеством монтажа. Ну или техкартой монтажа. Ограничь длину кабеля, распиши где его можно прокладывать. Сделай все качественно с первого раза, наконец!

На практике огрехи монтажа неизбежны. Но если мы используем ModBus и RS-485 такие проблемы очень легко отловить автоматизированной системой. У нас либо есть связь со счетчиком, либо нет. Если связь есть, то счетчик нам передаст свои показания, на табло смотреть не обязательно (за редким исключением глюков самого счетчика).

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

Да, друзья. Двадцать первый век, умные приборы учета. Но если они оснащены ИВ, то им обязательно нужна сверка через какое-то время. Хотя бы раз, но нужна.

Что это значит для эксплуатации? Это значит, что сверка должна быть заложена в ваши расходы. И нельзя использовать импульсный выход на том приборе учета, к которому больше не сможешь попасть.

Если мы подключаем общедомовой прибор учета по заказу Управляющей Компании, то у нас все хорошо. УК кровно заинтересована в правильной работе телеметрии и разумеется пустит нас свериться недельки через две. Мы сделаем вывод, что у нас все хорошо, внесем коррективы или перемонтажим.

Но вот что делать, если прибор учета стоит в квартире абонента?

Даже самый кристально чистый пользователь никогда не окажется дома в нужное вам время. Представьте себе задачу — сверить показания счетчиков многоквартирного дома? Квартир этак на сто? Сколько времени на это уйдет?

А теперь помножьте это на любовь некоторых пользователей к «волшебным магнитам» или «жукам» в щитке. Вы сами даете ему в руки инструмент обмана. Он выдерет провод из счетчика, скажет, что запнулся и в квартиру для ремонта вас не пустит. Что делать?

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

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

С другими типами счетчиков (промышленными, общедомовыми) ситуация легче, но и тут ИВ должен быть крайней мерой.

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

Счетчик Энергомера СЕ101. Выдает 3200 импульсов на киловатт-час.

Таким образом, если через прибор учета пройдет 1 кВтч, то за час мы должны успеть насчитать 3200 импульсов. А если десять? Тогда цифра станет уже больше, 32000 импульсов.

Это почти десять импульсов в секунду.

Реально ли их посчитать без ошибки?

Обратимся к технической документации. Счетчик импульсов с LoRaWAN модулем от Веги (СИ-11) умеет улавливать до 200 Гц. Это значит, что в секунду он может зарегистрировать 200 импульсов.

Контрольный прибор СИ-206-Д2 улавливает до 30 импульсов в секунду.

Энергомера СЕ101 рассчитана на ток до 100 А (максимальное значение ряда моделей), т.е. за час она сможет «протащить» до 22 кВт. Тут мы уже близки к критическим значениям. Но это квартирный электросчетчик, а проводка обычной квартиры столько не выдержит. Реальные цифры будут далеки от пороговых значений.

А производители осознают реальную «пропускную способность» своих приборов и подбирают веса в соответствие с возможностями счетчиков импульсов.

Закончить хотелось бы так. Импульсный выход — это ОЧЕНЬ дешевый интерфейс, который подкупает дешевизной производителей и потребителей. Но вот беда. Много от сэкономленного придется потратить на эксплуатацию. Стоит ли оно того?

P. S. Сразу после выкладки эту статью заминусовали. Я понял, что часть мыслей была раскрыта некорректно, потому сделал правки и более подробно описал некоторые вещи. В таком виде ее и оставляю. Для многих тема будет казаться мелочной и не стоящей. Но, судя по планам производителей и интеграторов, они видят за импульсным выходом будущее. Хотелось бы посеять хоть какие-то сомнения в их уверенность.

Описание устройства Пульсар 2М. Технические характеристики и маркировка. АСКУЭ яЭнергетик

  • Сделано в России
  • Автономное питание от встроенной литиевой батареи
  • Энергонезависимый архив
  • Открытый протокол обмена
  • Выходные интерфейсы: RS485
  • Адаптированы для работ в составе автоматизированной системы учета «Пульсар»
  • Возможность регистрации давления и передачи данных по GPRS от встроенной литиевой батареи
  • Возможность исполнения для затапливаемых помещений IP68
  • Считывание данных с приборов учета без доступа в дом, квартиру
  • Гарантийный срок прибора 6 лет

Регистратор импульсов 2-канальный используется в процессе технологического учета потребления энергоресурсов. Функционирует в качестве вторичного преобразователя в системе АСКУЭ «Пульсар».

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

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

По сути, это микропроцессорное устройство, в пластиковом корпусе.

Вариант крепления счетчика импульсов регистратор Пульсар на стене. Первичные преобразователи и интерфейсные соединения подключаются посредством винтовых клемников, которые располагаются внутри корпуса, через специальный, полностью герметизированный кабельный ввод. Фиксация данных и конфигурация прибора осуществляется с помощью персонального компьютера. Обмен данных с прибором происходит дистанционно по открытому протоколу. Подключение к ПК обеспечивает преобразователь RS485/USB.

Счетчик импульсов 2-канальный передает на компьютер:

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

Конфигурация устройства состоит в определении даты, времени и настройки программного оборудования.

Технические данные  
Число входных каналов 2
Тип импульсных датчиков герконовый, транзисторный, активный (потенциальный)
Минимальная длительность импульса, мс 10
Частота импульсов, Гц, не более 50 (по требованию заказчика – до 2000)
Температура окружающей среды, °С от -10 до +50 (по отдельному заказу от -40 до +70)
Степень защиты корпуса IP54
Глубина архива 1080 часов, 180 суток, 24 месяца
Точность хода внутренних часов, секунд/сутки 5
Габаритные размеры, мм 65х60х60
Обмен информацией c внешними устройствами интерфейс RS 485
Период работы (учет импульсов) от встроенного элемента питания, лет не менее 10
Напряжение внешнего питания, необходимое для передачи данных 7-25В
SMS-оповещение в случае отключения нет
Межповерочный интервал, лет 6
  • Регистратор Пульсар 2-канальный питается от батареи, обеспечивает постоянство работы учета времени и подсчета импульсов.
  • Срок работы батареи 6 лет.
  • Тип датчика: герконовый, транзисторный, либо активный.
  • Продолжительность импульса — 0,25 мс.
  • Мощность сигналов при работе со счетчиками с активным выходом не превышает 3 В. Пассивный выход поддерживает сигналы большего напряжения.

Использоваться регистратор Пульсар 2-канальный может при рабочей температуре от —10 до +50°С.

Размеры устройства — 65 × 60 × 60 мм.

Уровень защищенности корпуса — IP68.

Масса — 200 грамм.

РЭ ПУЛЬСАР 2-кан.

Система АСКУЭ. Что это и как работает. Электронный счетчик

Инженеры-энергетики еще в прошлом веке начали проектировать эффективные системы, способные самостоятельно контролировать потребление электрической энергии. В настоящее время такую систему называют автоматической системой контроля учета электроэнергии, сокращенно система АСКУЭ.

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

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

Инженеры не остановились на этом, и постоянно совершенствовали эту систему. Стали разрабатываться электронные счетчики, установка которых дает более качественные показатели расхода энергии. Далее появилась сотовая связь, которая обеспечила условия функционирования системы АСКУЭ по беспроводной технологии. Это значительно повысило эффективность эксплуатации этой системы и быстрый доступ к ее информационным данным.

Для чего служит система АСКУЭ

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

Условия качественной работы системы АСКУЭ
  • У всех потребителей электрической энергии необходимо установить наиболее современные приборы учета, а именно, электронные счетчики.
  • Полученную информацию от электронных счетчиков в виде цифровых сигналов концентрировать в сумматорах, которые являются специальными блоками, обладающими большим объемом памяти.
  • Организовать внутри системы связь, позволяющую отправлять отчеты потребителям и организациям, снабжающим электрической энергией.
  • Создать центры по обработке полученной информации. Для этого их следует оснастить современной вычислительной техникой и программным обеспечением.
Организация системы АСКУЭ

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

Первый уровень

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

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

В системе имеется приемник цифрового сигнала, обладающего сопротивлением 12 кОм. Существуют некоторые ограничения передатчика цифрового сигнала, что ограничивает число приемников сигнала. Поэтому стандартный интерфейс способен принимать электронные сигналы всего от 32 датчиков, что является недостатком.

Второй уровень

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

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

Третий уровень

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

Электронные счетчики являются сложными электронными устройствами. Они применяются для учета расхода энергии, и имеют такое устройство, что могут быстро подключиться к системе АСКУЭ. Но существуют старые счетчики, не способные подключаться к системе контроля. Для решения этой проблемы в качестве дополнительного оборудования можно установить специальный оптический порт, способный считывать данные и передавать их на компьютер. Такой порт можно устанавливать на подключенном функционирующем счетчике.

В системах контроля над расходом электроэнергии кроме электронных счетчиков могут применяться индукционные виды счетчиков. Если посмотреть на маркировку индукционного счетчика, то в ней может иметься буква «Д», что означает пригодность этих моделей для работы в системе АСКУЭ. В таких счетчиках имеется импульсный датчик с возможностью телеметрического выхода, который и передает данные по двухпроводной связи.

Но вряд ли стоит применять старые счетчики индукционного типа, они уже свое отработали, и привязать их к современной системе контроля уже становится сложнее. Такие виды лучше использовать для учета потребления энергии отдельных участков, не входящих в систему контроля АСКУЭ.

Электронные счетчики

Система АСКУЭ включает в себя основные элементы – электронные счетчики, которые являются преобразователями аналогового сигнала в импульсную частоту, учет которых дает объем израсходованной электрической энергии.

Основным достоинством этих современных приборов является отсутствие движущихся деталей, в отличие от индукционных счетчиков. Они также обеспечивают широкие пределы входных величин напряжения, дают возможность быстрой организации систем учета с несколькими тарифами, позволяют увидеть количество израсходованной энергии за любой прошедший период, измеряют мощность, сочетаются с оборудованием АСКУЭ и обладают многими другими полезными функциями.

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

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

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

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

Оптический порт дает возможность считывать данные со счетчика и служит для установки параметров счетчика.

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

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

Система АСКУЭ работает по сложной схеме, состоит из разных уровней. Чтобы обеспечить эффективность и точность ее работы, требуется правильно связать между собой все уровни, и применять только новые современные приборы, привлекать для настройки квалифицированных мастеров.

Похожие темы:

Телепорт-12И – преобразователь интерфейсов с Изюминкой!

04.09.2012

Совсем недавно наша компания выпустила в свет устройство под названием Телепорт-12. Данный преобразователь интерфейсов RS232/RS485 в Ethernet является необходимым «кирпичиком» в «ЛИНЕЙКЕ 12», поэтому мы реализовали его со всем усердием. Однако не оставляет мысль о некоей «безликости» созданного девайса. Дело в том, что подобных устройств на рынке немало. А походить на другие «железки» – это как-то не «по-технотрониковски». Поэтому подспудно хотелось найти некую «изюминку», которая бы отличала именно наше решение.

Как нам кажется, находка состоялась! Мы выпускаем новый прибор под названием Телепорт-12И. В этом изделии совмещены две функции:

  • проброс (конвертация) данных из интерфейса RS232/RS485 в Ethernet;

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

В каких случаях может применяться такой гибрид?

1. Учёт электроэнергии.

Специалисты, отвечающие за данную задачу на предприятиях связи, отлично знают состояние «парка» счётчиков электроэнергии на сегодняшний момент. Как правило, существует принятое и утвержденное решение о повсеместной замене счётчиков на современные интеллектуальные приборы с интерфейсом RS485. Однако, объектов много, финансирование крайне нерегулярное и процесс замены явно затянется на годы. Между тем, задача автоматизировать хотя бы процесс снятия показаний со счётчиков очень актуальна. В самом деле, невозможно мириться с непроизводительными затратами людских ресурсов и ГСМ на «дедовскую» технологию объезда множества объектов и записей на бумажке. И тут возникает дилемма. Не ждать замены счётчика, закупить контроллер с импульсным входом? А что делать, когда счётчик заменят? Выбрасывать купленный контроллер и заменять его на новый прибор с RS485? Как нетрудно догадаться, Телепорт-12И избавит наших уважаемых Заказчиков от этих, поистине «гамлетовских», сомнений. Он решит насущную проблему на существующем счётчике и не будет нуждаться в замене в перспективе.

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

Хочется подчеркнуть, что при переходе на счётчик с RS485 импульсный вход преобразователя интерфейсовТелепорт-12И не окажется бесполезным. В ходе возможной организации АСКУЭ коммерческий учёт будет организован через 485-ый порт счётчика, в то время, как телеметрический выход счётчика, подключенный на импульсный вход описываемого контроллера, по-прежнему может задействоваться для технического учёта, более оперативного и «заточенного» исключительно в интересах потребителя. 

И ещё. В некоторых случаях решение о закупке оборудования для автоматизированного снятия показаний со счётчиков принимается в крайне сжатые сроки. Поэтому совершенно нет возможности произвести обследование объектов (которые при этом могут быть «разбросаны» на десятки километров друг от друга) и получить точные сведения о количестве и типе счётчиков. Согласитесь, удобно в подобной ситуации приобрести одно устройство, которое подойдёт для трансляции данных с любых типов счётчиков как с импульсным выходом, так и с интерфейсом RS232/RS485/CAN – Телепорт-12И! Здесь не ошибёшься: пригодится та или другая его функция, а то и обе!

2. Учёт тепла и воды.

Вполне вероятна комбинация, когда на узле учёта одновременно установлен прибор учёта тепла с RS485 и прибор учёта холодной воды с импульсным выходом. Наш «кентавр» решит обе задачи.

Мы привели всего два примера удачного использования устройства Телепорт-12И. Не сомневаемся, что наши уважаемые Заказчики найдут ещё немало своих вариантов! Важно подчеркнуть, что созданный гибрид не выглядит искусственным и, что немаловажно, не приводит к существенному удорожанию конечного изделия по сравнению, скажем, с Телепорт-12.

Водомеры с импульсным выходом: плюсы, минусы

Законодательство об энергосбережении ставит перед системой ЖКХ задачу наладить достоверный учет потребляемых энергоресурсов: электричества, тепла, газа и воды. Актуальность приобретают системы точного дистанционного учета водопотребления с возможностью автоматического мониторинга, что исключает влияние человеческого фактора на достоверность показаний.

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

Содержание

  1. Что такое импульсный счетчик воды и зачем он нужен
  2. Принцип работы импульсных счетчиков воды
    1. Алгоритм снятия и передачи показаний с импульсных счетчиков
  3. Где применимы импульсные водомеры
  4. Чем отличается импульсный счетчик воды от обычного
    1. Плюсы импульсных счетчиков
    2. Минусы импульсных счетчиков
  5. Использование счетчиков воды с импульсным выходом для АСКУВ
  6. Прогрессивная разработка для автоматизированного учета

Что такое импульсный счетчик воды и зачем он нужен

Импульсный водомер – распространенное решение для централизованных пунктов учета в жилом секторе. Он служит для точной фиксации объема потребленного ресурса в режиме реального времени.

Типичный импульсный счетчик воды.

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

Управляющие компании и РСО видят в импульсных водосчетчиках эффективное решение для обеспечения точности снятия показаний с возможностью их передачи в базу данных автоматизированной системы контроля и учета воды (АСКУВ). Рассмотрим, как работают счетчики горячей и холодной воды с импульсным выходом.

Принцип работы импульсных счетчиков воды

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

Расходомер приводится в действие крыльчаткой, вращающейся под напором воды.

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

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

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

Главное конструктивное отличие импульсного водомера от обычного мокроходного счетчика состоит в его оснащении маломощным магнитом и герметическим контактом (герконом), который замыкается при воздействии на него магнитным полем. В момент совершения полного оборота счетного механизма геркон подает электрический импульс, который, считывается внешним устройством и подается на сигнальный пульт.

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

Где применимы импульсные водомеры

Анализ данных о том, кто подключает импульсный счетчик, показал, что эти электронные приборы учета пользуются спросом там, где от своевременности и точности переданных показаний зависит не только экономический эффект работы, но затрагиваются имущественные интересы граждан. Своевременные и точные показания импульсных счетчиков выгодны управляющим компаниям (УК) для расчетов с ресурсоснабжающими организациями (РСО). И самим ресурсникам в случае прямых расчетов с жильцами.

 

Интеллектуальные приборы учета дают возможность экономить, считать потребленные ресурсы и платить только за них
Андрей Чибис, заместитель министра строительства и ЖКХ РФ.

 

Предприимчивые сотрудники УК, устав от сбора показаний в режиме «посмотрел – записал – передал», находят альтернативные способы проверить показания и наладить автоматизацию учета. Например, в ТСЖ “Радуга” (г. Лермонтов Ставропольского края) показания водомеров фотографируют при помощи веб-камер, затем распознают компьютерной программой и отсылают в РСО. На форумах работников ЖКХ публикуют и другие креативные идеи. Например, предлагают устанавливать на счетчики оптические считыватели скорости вращения гребенки, которые делает из старых компьютерных мышей с оптоприводом – это та самая красная лампочка, которая по факту является видеокамерой с минимальным разрешением.

Чем отличается импульсный счетчик воды от обычного

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

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

Михаил Мень, министр строительства и ЖКХ РФ

Плюсы импульсных счетчиков

  • Передают информацию о потреблении воды автоматически и дистанционно.
  • Подходят для подключения к более сложной системе обработки информации, например, АСКУВ.
Для того, чтобы наладить автоматическую диспетчеризацию данных с импульсного водомера, достаточно подключить к нему коммутационный кабель или модем-транслятор, передающий сигнал по каналам GSM или LPWAN.

Минусы импульсных водосчетчиков

  • Геркон со временем выходит из строя, и водомер перестает считать расход воды с требуемой точностью и достоверностью.
  • Информация, полученная с водосчетчика может полноценно обрабатываться и передаваться только при дополнительном запуске радио- или цифрового сигнала.
  • Требуется антимагнитная защита, так как устройство легко блокируется неодимовым магнитом, и только АСКУВ способна достоверно отследить факт воздействия на прибор внешним магнитным полем для остановки счетного механизма.
  • Самостоятельно счетчики с импульсным выходом не имеют обратной связи с потребителем воды, и ему приходится контролировать собственный расход «на глаз».

Использование счетчиков воды с импульсным выходом для АСКУВ

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

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

Прогрессивная разработка для автоматизированного учета

На смену импульсным счетчикам воды приходят комбинированные устройства: счетчик + транслятор. Компания «СТРИЖ» приняла вызов тех, кто предлагает купить «импульсники», продолжать воровать воду у соседей, обманывать управляющую компанию или ТСЖ.

Мы оснащаем узлы учета инновационным счетчиком «СТРИЖ АКВА-1» со встроенным модемом. Этот универсальный прибор учета работает автономно, дистанционно контролирует актуальное состояние водопотребления в реальном времени и, в случае несанкционированного вмешательства в свою работу, шлет сигнал тревоги посредством СМС, сообщением в Telegram и в личный кабинет. Прибор не требует интеграции в АСКУВ, так как является ее аналогом, причем, менее затратным.


Как снизить ОДН и собирать показания счетчиков воды онлайн

 

УЗНАТЬ ПОДРОБНЕЕ

 


В продолжение статьи:

ОДН в 2017 году: формулы расчета, нормативы и тарифы начисления оплаты

Большой ОДН на воду: причины и методы снижения

 Точку в истории высокого ОДН поставят счетчики воды с удаленной передачей показаний

Как работает умный электросчетчик с передачей данных по сети LoRaWAN

Учет ресурсов вручную отходит в прошлое: поставщики электроэнергии в США, Китае и Западной Европе уже более десяти лет получают показания автоматически. Для этого используют умные устройства и беспроводные способы передачи данных.

В этой статье мы расскажем о преимуществах удаленного учета электричества по технологии LoRaWAN®.

Почему учет данных вручную теряет актуальность

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

  • Несвоевременное поступление показаний. Абоненты забывают сообщить показания в установленный день.
  • Затрудненный доступ к счетчикам. Пользователи могут отсутствовать дома во время прихода контролера или не впустить его в жилье.
  • Ошибки. Иногда потребители отправляют неверные данные или оператор — ошибается при внесении показаний в базу данных.
  • Неточность. Старые счетчики класса точности «2» (в особенности это касается индукционных счетчиков) менее чувствительны к малым токам — например, зарядке телефона или нахождению электроприбора в режиме ожидания. Поэтому такие приборы учета могут присылать заниженные данные о потреблении, и поставщик, соответственно, не получит полный объем оплаты за предоставленные ресурсы.
  • Хищения. Некоторые модели счетчиков можно замедлить, остановить и даже настроить на работу в обратном режиме.

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

Как работает умный электросчетчик

Все умные функции прибора учета обеспечивает встроенный радиомодуль. Это устройство считывает импульсы, которые генерирует электросчетчик, и сохраняет их в энергонезависимой памяти. Радиомодули отправляют данные счетчиков ресурсным компаниям по защищенным беспроводным каналам связи (мобильная связь, 3G- или Wi-Fi-соединение).
У разных моделей умных электросчетчиков функции могут различаться. Однако все они работают по одному принципу: считывают показания с прибора учета и передают данные на сервер. Рассмотрим, как работает умный электросчетчик на примере многотарифных приборов учета MTX производства TeleTec.

На материнской плате счетчика установлен LoRaWAN®-модуль. Этот девайс считает количество импульсов, пропорциональное количеству затраченной электроэнергии. Данные сохраняются в памяти прибора учета, раз в сутки радиомодуль передает их базовой станции по беспроводной технологии LoRaWAN®.
С базовой станции данные поступают на сервер: количество импульсов переводится в киловатт⋅часы и суммируется с предыдущими показаниями. Поставщики ресурсов связываются с сервером, получают доступ к данным и возможность обрабатывать их в удобных программах.

Как LoRaWAN®-модули передают данные

Технология LoRaWAN® позволяет передавать данные по радиоволнам, без использования проводов. Это особенно удобно для подключения частных домов, гаражей и других отдельно стоящих объектов.

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

Какие преимущества дают умные электросчетчики

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

Преимущество:

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

Польза:

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

 

Преимущество:

Позволяют поставщику удаленно отключить от сети неплательщика и снова предоставить ему услуги энергопоставки, когда он погасит долг предприятию.

Польза:

Контроль поставки энергии должникам и возможность мотивировать их оплачивать ресурсы.

 

Преимущество:

Размещают данные о потреблении в трех временных тарифных регистрах.

Польза:

Абоненты могут планировать работу электроприборов с учетом экономичных тарифов.

 

Преимущество:

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

Польза:

Гарантия того, что потребители не смогут повлиять на работу счетчика с помощью магнита. Защита от хищений.

 

Преимущество:

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

Польза:

Потребители не смогут незаметно вскрыть корпус счетчика и подключить к нему какие-либо устройства. Защита от хищений.

 

Преимущество:

Точный учет электроэнергии, учет слабых токов.

Польза:

ОСМД и управляющие компании получат точные данные и смогут выставить жильцам счета за всю потребленную энергию. 

 

Преимущество:

Максимальная сила тока — до 120 А. 

Польза: 

Потребители смогут подключать большее количество электроприборов, не перегружая сеть.

 

Преимущество:

Межповерочный интервал от 10 до 16 лет. Гарантийный срок — 5 лет.

Польза:

Гарантия качества продукта. Редкие поверки счетчиков снизят затраты поставщика электроэнергии и сделают эксплуатацию приборов учета более комфортной для потребителей.

 

Преимущество:

Энергонезависимая память. 

Польза:

Сохранение данных при отключении электроэнергии.

 

Где используют умные электросчетчики

Умные счетчики можно устанавливать в квартирах, частных домах и небольших гаражах: для таких объектов следует выбирать модели однофазных электросчетчиков, работающие в сетях с напряжением 220 вольт. Для предприятий и зданий с большим потреблением электроэнергии подойдут трехфазные умные счетчики, предназначенные для сетей с напряжением 380 вольт.

Можно ли превратить старый аналоговый счетчик в умный?

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

Такое устройство подключают к электросчетчику, вводят в базу данных сведения об абоненте и показания его счетчика. После настройки модуль будет автоматически считывать показания и отправлять их в систему учета.
Под брендом Jooby Infomir производит LoRaWAN®-модули с двумя импульсными выходами: это позволяет превратить обычный электросчетчик в умный.

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

opentelemetry-spec / datamodel.md на главной · open-telemetry / opentelemetry-spec · GitHub

Статус : Смешанный

Содержание

Обзор

Статус : Стабильный

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

Популярные существующие форматы данных метрик могут быть однозначно переведены в Модель данных OpenTelemetry для метрик без потери семантики или точности. Перевод из форматов экспозиции Prometheus и Statsd явно указано.

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

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

событий => поток данных => таймсерии

Статус : Стабильный

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

Этот протокол был разработан в соответствии с требованиями OpenCensus Metrics. система, в частности, чтобы соответствовать ее концепции представлений метрик. Просмотры реализовано в модели данных OpenTelemetry Metrics за счет поддержки данных преобразование на пути сбора.

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

  1. Временная реагрегация: показатели, которые собираются с высокой частотой, могут быть повторно агрегируются в более длинные интервалы, что позволяет предварительно рассчитанные или используемые вместо исходных данных метрики.
  2. Пространственная повторная агрегация: показатели, созданные с нежелательными параметрами, могут повторно агрегироваться в показатели с меньшим количеством измерений.
  3. Дельта-кумулятивная: метрики, которые вводятся и выводятся с дельта-темпоральностью. освободить клиента от сохранения состояния высокой мощности. Использование дельт позволяет последующим сервисам нести затраты на преобразование в совокупные timeseries, или отказаться от стоимости и рассчитать ставки напрямую.

Потоки данных OpenTelemetry Metrics спроектированы таким образом, чтобы эти преобразования может применяться автоматически к потокам одного типа при соблюдении условий изложены ниже. Каждый поток данных OTLP имеет внутреннюю разложимая агрегатная функция делая его семантически четко определенным для объединения точек данных в обоих временных и пространственные размеры.Каждая точка данных OTLP также имеет две значимые временные метки. которые в сочетании с внутренней агрегацией позволяют выполнять стандартные преобразования метрических данных для каждой из основных точек модели, в то время как обеспечение того, чтобы результат имел предполагаемое значение.

Как и в OpenCensus Metrics, данные метрик могут быть преобразованы в одну или несколько Представления, просто выбрав интервал агрегации и желаемые размеры. Один поток данных OTLP может быть преобразован в несколько выходных таймсерий с помощью настройка различных представлений, и может применяться необходимая обработка представлений внутри SDK или внешним сборщиком.

Примеры использования

Модель метрических данных разработана на основе ряда «основных» сценариев использования. В то время как этот список не является исчерпывающим, он предназначен для представления объема и широта использования метрик OTel.

  1. OTel SDK экспортирует разрешение 10 секунд в один коллектор OTel, используя совокупная темпоральность для клиента с отслеживанием состояния, сервера без состояния:
    • Коллектор передает исходные данные в пункт назначения OTLP
    • Сборщик повторно агрегатируется на более длительные интервалы без изменения размеров
    • Collector объединяется в несколько отдельных представлений, каждое с подмножеством доступные размеры, выходы в то же место назначения
  2. OTel SDK экспортирует разрешение 10 секунд в один коллектор OTel, используя дельта темпоральность для клиента без состояния, сервера с отслеживанием состояния:
    • Коллектор повторно объединяется с разрешением 60 секунд
    • Коллектор преобразует дельту в кумулятивную временность
  3. OTel SDK экспортирует разрешение 10 секунд (например.грамм. ЦП, задержка запроса) и Разрешение 15 минут (например, при комнатной температуре) на один коллектор OTel. Сборщик экспортирует потоки вверх по потоку с агрегацией или без нее.
  4. Несколько SDK OTel, работающих локально, каждый экспортирует разрешение 10 секунд, каждый сообщает единственному (локальному) сборщику OTel.
    • Коллектор повторно объединяется с разрешением 60 секунд
    • Collector выполняет повторную агрегацию, чтобы исключить идентификацию отдельных SDK (например, отдельные service.instance.id значений)
    • Выходы коллектора в пункт назначения OTLP
  5. Пул коллекторов OTel получают OTLP и экспортируют Prometheus Remote Write
    • Коллектор присоединяется к обнаружению службы с метрическими ресурсами
    • Коллектор вычисляет «вверх», маркер устаревания
    • Коллектор наносит отдельный внешний ярлык
  6. Сборщик
  7. OTel получает Statsd и экспортирует OTLP
    • С дельта-темпоральностью: коллектор без сохранения состояния
    • С кумулятивной временностью: коллектор с отслеживанием состояния
  8. OTel SDK экспортирует напрямую в серверную часть 3P

Они считаются «основными» сценариями использования, используемыми для анализа компромиссов и проектирования. решения в рамках модели данных метрик.

Сценарии использования, выходящие за рамки

Модель данных метрик НЕ предназначена быть идеальным розеточным камнем метрик. Вот набор вариантов использования, которые, хотя и не будут полностью поддерживаться, не за основные проектные решения:

  • Использование OTLP в качестве промежуточного формата между двумя несовместимыми форматами
    • Импорт статистики => Prometheus PRW
    • Импорт collectd => Прометей PRW
    • Импорт очистки конечной точки Prometheus => [statsd push | собирать | opencensus]
    • Импорт OpenCensus “oca” => любой формат, отличный от OC или OTel
  • TODO: определить другие.

Описание модели

Статус : Стабильный

OpenTelemetry фрагментирует метрики на три взаимодействующие модели:

  • Модель событий, показывающая, как инструментарий сообщает метрические данные.
  • Модель Timeseries, представляющая, как серверные ВМ хранят данные метрики.
  • Модель Metric Stream, определяющая O pen T e L emetry P rotocol (OTLP) представление того, как потоки метрических данных обрабатываются и передаются между Модель событий и хранилище таймсерий.Это указанная модель в этом документе.

Модель событий

Модель событий – это место, где происходит запись данных. Его фундамент сделан из Инструменты, которые используются для записи данных наблюдений через события. Эти необработанные события затем каким-то образом преобразуются перед отправкой в ​​некоторые другая система. Метрики OpenTelemetry разработаны таким образом, что один и тот же инструмент и события могут использоваться по-разному для создания потоков метрик.

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

Примечание. На рисунке выше показано, как один прибор может преобразовывать события в более одного типа метрического потока. Есть предостережения и нюансы, когда и как это сделать. Обозначены приборная и метрическая конфигурация. в спецификации API метрик.

Хотя OpenTelemetry обеспечивает гибкость в преобразовании инструментов в метрические потоки, инструменты определены таким образом, что разумный дефолт отображение может быть предоставлено.Точный Инструменты OpenTelemetry подробно описаны в API. Технические характеристики.

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

Timeseries Модель

В этой низкоуровневой модели данных метрик Timeseries определяется сущностью состоящий из нескольких свойств метаданных:

  • Название в метрической системе
  • Атрибуты (размеры)
  • Вид точки (целое число, с плавающей запятой и т. Д.)
  • Единица измерения

Первичные данные каждого временного ряда упорядочены (временная метка, значение) в точках, с один из следующих типов значений:

  1. Счетчик (монотонный, накопительный)
  2. Калибр
  3. Гистограмма
  4. Экспоненциальная гистограмма

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

Примечание: Prometheus – не единственная возможная модель таймсерий для OpenTelemetry. для сопоставления, но используется в качестве справочного материала в этом документе.

Модель данных протокола OpenTelemetry

Модель данных протокола OpenTelmetry состоит из потоков данных Metric. Эти потоки, в свою очередь, состоят из метрических точек данных. Потоки метрических данных могут быть преобразованы непосредственно в таймсерии и иметь одну и ту же идентичность характеристики для таймсерии. Метрический поток идентифицируется по:

  • Исходный Ресурс
  • Имя метрического потока .
  • Прикрепленный Атрибут s
  • Тип точки метрического потока.

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

Примечание: один и тот же ресурс , имя и атрибут , но разные типы точек выход из OpenTelemetry SDK считается “состоянием ошибки”, которое ДОЛЖНО обрабатываться SDK.

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

Основные виды баллов:

  1. Сумма
  2. Калибр
  3. Гистограмма
  4. Экспоненциальная гистограмма

Сравнивая модели данных потока данных метрики OTLP и моделей данных таймсерий, OTLP делает не отображать 1: 1 из своих типов точек в точки временного ряда. В OTLP сумма баллов может представлять монотонный счет или немонотонный счет. Это означает, что сумма OTLP либо переводится в счетчик таймсерий, когда сумма монотонна, либо Калибровка, когда сумма не монотонна.

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

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

Метрические точки

Статус : Стабильный

Суммы

Сумм в OTLP состоят из:

  • An Aggregation Temporality delta или кумулятивная.
  • Флаг, обозначающий, является ли сумма монотонный. В этом случае метрики, это означает, что сумма номинально увеличивается, что мы предполагаем без потеря общности.
    • Для дельта-монотонных сумм это означает, что читателю СЛЕДУЕТ ожидать неотрицательных ценности.
    • Для кумулятивных монотонных сумм это означает, что читатель ДОЛЖЕН ожидать значений которые не меньше предыдущего значения.
  • Набор точек данных, каждая из которых содержит:
    • Независимый набор пар имя-значение атрибута.
    • Временное окно ( (начало, конец) ), для которого вычислялась сумма.
      • Временной интервал включает время окончания.
      • В поле Значение указано
      • раз, время эпохи UNIX в наносекундах с момента 00:00:00 UTC 1 января 1970 г.
      • (необязательно) набор экзаменов (см. Примеры).

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

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

Существуют различные компромиссы между использованием дельта и кумулятивного агрегирования в различные варианты использования, например:

  • Обнаружение перезапуска процесса
  • Расчет ставок
  • Метрическая отчетность на основе выталкивания и вытягивания

OTLP поддерживает обе модели и позволяет API, SDK и пользователям определять лучший компромисс для их варианта использования.

Калибр

манометр в OTLP представляет собой значение выборки в данный момент времени. Поток Gauge состоит из:

  • Набор точек данных, каждая из которых содержит:
    • Независимый набор пар имя-значение атрибута.
    • Значение выборки (например, текущая температура процессора)
    • Отметка времени, когда значение было выбрано ( time_unix_nano )
    • (необязательно) Отметка времени ( start_time_unix_nano ), которая наилучшим образом представляет первый возможный момент, когда измерение может быть записано.Это обычно устанавливается на отметку времени при запуске системы сбора метрик.
    • (необязательно) набор экзаменов (см. Примеры).

В OTLP точка в потоке Gauge представляет событие последней выборки для данное временное окно.

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

Приборы

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

Приборы

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

Гистограмма

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

Гистограммы состоят из следующего:

  • An Aggregation Temporality delta или кумулятивная.
  • Набор точек данных, каждая из которых содержит:
    • Независимый набор пар имя-значение атрибута.
    • Временное окно (из (начало, конец) ), для которого была объединена гистограмма.
      • Временной интервал включает время окончания.
      • Значения времени указаны в наносекундах, начиная с эпохи UNIX. (00:00:00 UTC 1 января 1970 г.).
    • Подсчет ( единиц ) всей совокупности точек на гистограмме.
    • Сумма ( сумма ) всех значений гистограммы.
    • (необязательно) Минимум ( мин ) всех значений на гистограмме.
    • (необязательно) Максимум ( максимум ) всех значений на гистограмме.
    • (опция) Серия ковшей с:
      • Явные граничные значения. Эти значения обозначают нижнюю и верхнюю границы для ведер, и не будет ли данное наблюдение записано в этом ведро.
      • Подсчет количества наблюдений, попавших в этот сегмент.
    • (необязательно) набор экзаменов (см. Примеры).

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

Временность агрегации также влияет на поля min и max. Мин. и max более полезны для дельта-темпоральности, поскольку значения, представленные Суммарные минимальные и максимальные значения будут стабилизироваться по мере записи большего количества событий. Кроме того, можно преобразовать min и max из Delta в Cumulative, но не из Суммарно к Дельте. При преобразовании из кумулятивного в дельта минимальные и максимальные значения могут быть отброшенным или захваченным в альтернативном представлении, таком как датчик.

Подсчет ведра не является обязательным.Гистограмма без ведер показывает население только с точки зрения суммы и подсчета, и может быть интерпретировано в виде гистограммы с одним сегментом покрытия (-Inf, + Inf) .

Верхние границы сегмента являются включительными (за исключением случая, когда верхняя граница равна + Inf), в то время как нижние границы корзины исключают. То есть, ведра выражают количество значений, которые больше, чем их нижние граница и меньше или равна их верхней границе. Импортеры и экспортеры, работающие с данными OpenTelemetry Metrics, предназначены для игнорируйте эту спецификацию при переводе в гистограмму и обратно форматы, использующие инклюзивные нижние границы и исключающие верхние границы.Изменение инклюзивности и исключительности границ является примером наихудшая ошибка гистограммы; пользователи должны выбрать границы гистограммы так что ошибка наихудшего случая находится в пределах их допустимости ошибок.

Экспоненциальная гистограмма

Статус : экспериментальный

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

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

Экспоненциальная шкала

Разрешение экспоненциальной гистограммы характеризуется параметр, известный как шкала , с большими значениями шкала предлагает большая точность.Границы сегмента экспоненциальной гистограммы: расположен в целых степенях основания , также известный как “рост коэффициент », где:

Символ ** в этих формулах обозначает возведение в степень, таким образом 2 ** x читается как «Два в степени x », обычно вычисляется выражение вроде math.Pow (2.0, x) . Вычислено базовых значений для выбранные шкалы показаны ниже:

Масштаб База Выражение
10 1.00068 2 ** (1/1024)
9 1,00135 2 ** (1/512)
8 1,00271 2 ** (1/256)
7 1,00543 2 ** (1/128)
6 1.01089 2 ** (1/64)
5 1.02190 2 ** (1/32)
4 1.04427 2 ** (1/16)
3 1.09051 2 ** (1/8)
2 1,18921 2 ** (1/4)
1 1,41421 2 ** (1/2)
0 2 2 ** 1
-1 4 2 ** 2
-2 16 2 ** 4
-3 256 2 ** 8
-4 65536 2 ** 16

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

Экспоненциальные корзины

Бакет ExponentialHistogram, обозначенный индексом , подписанный целое число, представляет значения в генеральной совокупности, которые больше или равно основанию ** индекс и меньше основанию ** (индекс + 1) .Обратите внимание, что ExponentialHistogram указывает нижнюю границу, в то время как явная граница Гистограмма определяет верхнюю границу включительно.

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

Каждый диапазон точки данных ExponentialHistogram использует плотный представление сегментов, где выражается диапазон сегментов как одно значение смещения , целое число со знаком и массив подсчета значения, где элемент массива i представляет количество ведра для ведра index смещение + i .

Для заданного диапазона, положительного или отрицательного:

  • Индекс ведра 0 отсчет измерений в диапазоне [1, основание)
  • Положительные индексы соответствуют абсолютным значениям, большим или равным основанию
  • Отрицательные индексы соответствуют абсолютным значениям меньше 1
  • Имеется ковшей масштаба 2 ** между последовательными степенями 2.

Например, при масштабе = 3 существует 2 ** 3 сегментов между 1 и 2.Обратите внимание, что нижняя граница для индекса ковша 4 в масштабе = 3 гистограмма отображается в нижнюю границу для индекса сегмента 2 в Масштаб = 2 гистограмма и отображается на нижней границе для индекса сегмента 1 (т. Е. Основание ) в масштабе = 1 гистограмме – это примеры идеальное подмножество.

масштаб = 3 индекс ковша нижняя граница уравнение
0 1 2 ** (0/8)
1 1.09051 2 ** (1/8)
2 1,18921 2 ** (2/8), 2 ** (1/4)
3 1,29684 2 ** (3/8)
4 1,41421 2 ** (4/8), 2 ** (2/4), 2 ** (1/2)
5 1,54221 2 ** (5/8)
6 1,68179 2 ** (6/8)
7 1.83401 2 ** (7/8)
Нулевой счет

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

Ожидания производителей

Дизайн ExponentialHistogram позволяет выражать значения которые слишком велики или малы для представления в 64-битном “двойном” формат с плавающей запятой. Определенные значения для шкалы , хотя и значимы, не обязательно полезны.

Диапазон данных, представленных экспоненциальной гистограммой, определяет какие шкалы можно с пользой применить.Независимо от масштаба производители СЛЕДУЕТ гарантировать, что индекс любого закодированного сегмента попадает в диапазон 32-битного целого числа со знаком. Эта рекомендация применяется к ограничить ширину целых чисел, используемых в стандартных конвейерах обработки, таких как как коллектор OpenTelemetry. Протокол проводного уровня может быть расширен для индексов 64-битных сегментов в будущем выпуске.

Производители используют функцию сопоставления для вычисления индексов корзины. Продюсеры предполагается, что поддерживают числа с плавающей запятой двойной ширины IEEE с 11-битная экспонента и 52-битная мантисса.Псевдокод ниже для отображение значений в экспоненты относится к следующим константам:

 const (
    // SignificandWidth - это размер двойной точности IEEE 754
    // значение с плавающей запятой.
    SignificandWidth = 52
    // ExponentWidth - это размер двойной точности IEEE 754
    // показатель степени с плавающей запятой.
    ExponentWidth = 11

    // SignificandMask - это маска для мантиссы IEEE 754
    // значение с плавающей запятой двойной точности: 0xFFFFFFFFFFFFF.
    SignificandMask = 1 << SignificandWidth - 1

    // ExponentBias - смещение экспоненты, указанное для кодирования
    // показатель степени с плавающей запятой двойной точности IEEE 754: 1023.ExponentBias = 1 << (ExponentWidth-1) - 1

    // ExponentMask устанавливается в 1 для битов IEEE 754
    // показатель степени с плавающей запятой: 0x7FF0000000000000.
    ExponentMask = ((1 << ExponentWidth) - 1) << SignificandWidth
) 

Следующие варианты функции сопоставления были подтверждены эталонные реализации.

Нулевой масштаб: извлечь экспоненту

Для нулевой шкалы индекс значения равен его нормализованному основанию-2. экспонента, означающая значение экспоненты в дробной части с основанием 2 Представительство 1._significand_ * 2 ** _ exponent_ . Нормальный IEEE 754 значения с плавающей запятой двойной ширины имеют индексы в диапазоне [-1022, +1023] и субнормальные значения имеют индексы в диапазоне [-1074, -1023] . Это может быть записано как:

 // GetExponent извлекает нормализованную дробную экспоненту по основанию 2.
// Пусть значение будет представлено как `1.significand x 2 ** exponent`,
// это возвращает `экспоненту`. Не определено для значений 0, Inf или NaN.
func GetExponent (значение float64) int32 {
    rawBits: = математика.Float64bits (значение)
    rawExponent: = (int64 (rawBits) & ExponentMask) >> SignificandWidth
    rawSignificand: = rawBits & SignificandMask
    if rawExponent == 0 {
        // Обработка субнормальных значений: rawSignificand не может быть нулевым
        // если значение не равно нулю.
        rawExponent - = int64 (битыLeadingZeros64 (rawSignificand) - 12)
    }
    вернуть int32 (rawExponent - ExponentBias)
} 
Отрицательная шкала: извлечь и сдвинуть экспоненту

Для отрицательных шкал индекс значения равен нормированному экспонента по основанию 2 (как в случае GetExponent () выше) смещена вправо по по шкале .Обратите внимание, что из-за расширения знака этот сдвиг выполняется правильное округление отрицательных индексов. Это может быть записано как:

 return GetExponent (значение) >> -scale 
Все шкалы: используйте функцию логарифмирования

Для любого масштаба используется встроенный натуральный логарифм. функция. Множитель, равный 2 ** масштаб / дюйм (2) оказывается полезным (где ln () - натуральный логарифм), например:

 scaleFactor: = math.Log2E * math.Exp2 (масштаб)
    вернуть int64 (math.Floor (math.Log (значение) * scaleFactor)) 

Обратите внимание, что в приведенном выше примере кода Голанга встроенная функция math.Log2E определяется как 1 / ln (2) .

Положительная шкала: используйте справочную таблицу

Для положительных масштабов были продемонстрированы методы поисковой таблицы. которые могут точно вычислить индекс за постоянное время из таблица поиска с O (шкала 2 **) записей.

Рекомендации производителя

На самом низком или высоком конце 64-битной плавающей запятой IEEE диапазон ковша может быть только частично представлен плавающим формат числа точек.При сопоставлении числа в этих сегментах производитель может правильно вернуть индекс такой частично представимое ведро. Это считается нормальным состоянием.

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

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

Ожидания потребителей
Ожидается, что индексы сегментов

ExponentialHistogram будут отображаться в сегменты где могут быть представлены как верхняя, так и нижняя границы с использованием значений с плавающей запятой двойной ширины IEEE 754. Потребители МОГУТ вокруг непредставимой границы частично представимого ведра индекс до ближайшего представимого значения.

Потребителям СЛЕДУЕТ отклонять данные экспоненциальной гистограммы со шкалой , и индексы ведра, которые выходят за пределы этого представления или выходят за его пределы. Потребители, отклоняющие такие данные, ДОЛЖНЫ предупреждать пользователя об ошибке. регистрация того, что данные вне допустимого диапазона были получены.

Сводка (устаревшая)

Сводка точки данных метрики передают итоги квантилей, например Какая 99-я процентная задержка моего HTTP-сервера. В отличие от других типов точек в OpenTelemetry, итоговые точки не всегда могут быть объединены в значимую способ.Этот тип точки не рекомендуется для новых приложений и существует для совместимости с другими форматами.

Сводка состоит из следующего:

  • Набор точек данных, каждая из которых содержит:
    • Независимый набор пар имя-значение атрибута.
    • Отметка времени, когда значение было выбрано ( time_unix_nano )
    • (необязательно) Отметка времени ( start_time_unix_nano ), обозначающая время начала коллекции наблюдений для резюме.
    • Подсчет количества наблюдений в совокупности точки данных.
    • Сумма значений в генеральной совокупности.
    • Набор значений квантилей (в строго возрастающем порядке), состоящий из:
      • Квантиль распределения в интервале [0,0, 1,0] . Для Например, значение 0,9 будет представлять 90-й процентиль.
      • Значение квантиля. Это ДОЛЖНО быть неотрицательным.

Значения квантилей 0.0 и 1.0 определены как равные минимальному и максимальному значениям соответственно.

Значения квантилей не обязательно должны представлять значения, наблюдаемые между start_time_unix_nano и time_unix_nano и, как ожидается, будут вычислены по сравнению с недавними временными окнами, обычно за последние 5-10 минут.

Образцы

Статус : Стабильный

Образец - это записанное значение, которое связывает контекст OpenTelemetry с событие метрики внутри метрики.Один из вариантов использования - разрешить пользователям ссылаться Сигналы трассировки с метриками.

Образцы состоят из:

  • (необязательно) Трассировка, связанная с записью ( trace_id , span_id )
  • Время наблюдения ( time_unix_nano )
  • Зарегистрированное значение ( значение )
  • Набор отфильтрованных атрибутов ( filter_attributes ), которые обеспечивают дополнительное понимание контекста, когда было сделано наблюдение.

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

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

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

Устройство с одинарной записью

Статус : Стабильный

Все потоки метрических данных в OTLP ДОЛЖНЫ иметь одну логическую запись.Это означает, концептуально, что любые таймсерии, созданные из протокола, ДОЛЖНЫ иметь один исходный источник истины. Практически это означает следующее:

  • Все потоки метрических данных, создаваемые OTel SDK, ДОЛЖНЫ быть глобально уникальными. изготовлены и не содержат дубликатов. Все потоки метрических данных могут быть однозначно идентифицированы каким-то образом.
  • Агрегаты метрических потоков ДОЛЖНЫ быть записаны только из одного логического источник. Примечание. Это означает, что агрегированные потоки метрик должны достигать одного пункта назначения .

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

Несколько устройств записи для потока метрик считается состоянием ошибки, или некорректная система. Получателям СЛЕДУЕТ предполагать, что был предназначен один писатель и исключить перекрытие / дедупликацию.

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

Позаботьтесь о labeldrop и labelkeep , чтобы показатели все еще имеют уникальную метку после удаления меток.

Для OTLP принцип Single-Writer предоставляет способ рассуждать об ошибках. сценарии и предпринять корректирующие действия.Кроме того, это гарантирует, что системы с хорошим поведением могут выполнять манипуляции с потоком метрик без нежелательных ухудшение или потеря видимости.

Темпоральность

Статус : Стабильный

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

Каждая точка данных метрики OTLP имеет две связанные отметки времени.В во-первых, обязательная временная метка связана с наблюдением, момент, когда измерение стало текущим или вступило в силу, и именуется TimeUnixNano . Используется вторая, необязательная метка времени чтобы указать, когда последовательность точек не прерывается, и называется StartTimeUnixNano .

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

  • Кумулятивная временность означает, что последовательные точки данных повторяют начальную отметка времени. Например, с момента начала T0 совокупные точки данных охватывают время диапазоны (T 0 , T 1 ), (T 0 , T 2 ), (T 0 , T 3 ) и так далее.
  • Дельта-темпоральность означает, что последовательные точки данных опережают начальную отметка времени.Например, с момента начала T0, точки дельта-данных охватывают время диапазоны (T 0 , T 1 ), (T 1 , T 2 ), (T 2 , T 3 ) и так далее.

Использование кумулятивной темпоральности для монотонных сумм является обычным явлением, примером которого является Прометей. Системы, основанные на кумулятивных монотонных суммах, естественно более просты, в с точки зрения стоимости добавления надежности. Когда сбор периодически не удается, пробелы в данных, естественно, усредняются по совокупным измерениям.Накопительные данные требуют, чтобы отправитель запомнил все предыдущие измерения, «Предварительная» стоимость памяти пропорциональна количеству элементов.

Использование дельта-темпоральности для метрических сумм также широко, на примере Statsd. Существует связь между трассировкой OpenTelemetry, в которой Span событие обычно переводится в два метрических события (счетчик единиц и время измерение). Дельта-темпоральность позволяет производить выборку и поддерживает изменение стоимости мощности вне процесса.

Сброс и пропуск

Статус : экспериментальный

Когда присутствует поле StartTimeUnixNano , это позволяет потребителю чтобы наблюдать, когда в потоке есть пробелы и перекрывающиеся писатели.При правильном использовании потребитель может наблюдать как временные, так и текущие нарушения принципа единственной записи, а также события сброса. В непрерывная последовательность наблюдений, StartTimeUnixNano всегда соответствует либо TimeUnixNano , либо StartTimeUnixNano других точки в той же последовательности. Для начальных точек в непрерывном последовательность:

  • Когда StartTimeUnixNano меньше TimeUnixNano , новая непрерывная последовательность наблюдений начинается с "истинного" сброса в известное время начала.Ноль значение неявно, нет необходимости записывать начальную точку.
  • Когда StartTimeUnixNano равно TimeUnixNano , новая непрерывная последовательность Наблюдения начинаются со сброса в неизвестное время начала. Начальный наблюдаемое значение записывается, чтобы указать, что непрерывная последовательность наблюдения возобновляются. Эти точки имеют нулевую продолжительность и указывают на то, что ничего не известно о точках, о которых сообщалось ранее, и эти данные могли быть потерянный.

Для последующих точек в непрерывной последовательности:

  • Для точек с темпоральностью дельта-агрегации значение StartTimeUnixNano из каждая точка соответствует TimeUnixNano предыдущей точки
  • В противном случае StartTimeUnixNano каждой точки соответствует StartTimeUnixNano начального наблюдения.

Метрический поток имеет разрыв, где он неявно не определен, где угодно существует диапазон времени, в котором ни одна точка не покрывает этот диапазон с полями StartTimeUnixNano и TimeUnixNano .

Суммарные потоки: обработка неизвестного времени начала

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

Чтобы правильно вычислить вклад первой точки в непрерывная последовательность требует знания, является ли это первой точкой. Неизвестные точки сброса времени запуска появляются с TimeUnixNano , равным StartTimeUnixNano потока точек, в этом случае ставка вклад первой точки считается нулевым. Ранее Ожидается, что последовательность наблюдений даст одинаковые совокупное состояние до перерыва в наблюдениях.

Наличие или отсутствие точки с TimeUnixNano равной StartTimeUnixNano указывает, как считать вклад скорости от первая точка в последовательности.Если первая точка неизвестна потеряна последовательность сброса времени запуска, потребитель этих данных может переоценить вклад второй точки, как это тогда появляется вроде "настоящий" сброс.

Чтобы избежать переоценки, можно использовать различные подходы. Система могла использовать состояние из более раннего в потоке, чтобы разрешить неоднозначность времени начала, Например.

Кумулятивные потоки: вставка истинных точек сброса

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

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

Перекрытие

Статус : экспериментальный

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

Мы определяем три принципа обработки перекрытий:

  • Разрешение (коррекция по точкам падения)
  • Наблюдаемость (возможность передачи данных в серверную часть)
  • Интерполяция (коррекция посредством обработки данных)

Разрешение перекрытия

Когда более одного процесса записывают один и тот же поток данных метрики, точки данных OTLP может показаться, что они накладываются друг на друга.Это состояние обычно возникает из-за неправильной конфигурации, но также может быть результатом запуска идентичных процессов (что указывает на операционную систему или ошибки SDK, например, отсутствующие атрибуты процесса). Когда там являются перекрывающимися точками, приемники ДОЛЖНЫ исключить точки, чтобы не было перекрывает. Какие данные выбирать в перекрывающихся случаях, не указано.

Наблюдаемость перекрытия

Сборщикам OpenTelemetry СЛЕДУЕТ экспортировать телеметрию, когда они наблюдают перекрытие точек в потоках данных, чтобы пользователь мог отслеживать ошибочные конфигурации.

Интерполяция перекрытия

Когда один процесс запускается одновременно с завершением другого, возникает видимость перекрытия можно ожидать очков. В этом случае сборщикам OpenTelemetry СЛЕДУЕТ изменить указывает на переключение, используя интерполяцию для точек данных суммы, чтобы уменьшить зазоры до нулевой ширины в этих случаях без какого-либо перекрытия.

Манипуляции с потоками

Статус : экспериментальный

Ожидает внедрения.

Суммы: дельта-кумулятивное

В то время как OpenTelemetry (и некоторые метрические бэкенды) допускают как Delta, так и Cumulative суммы, которые необходимо сообщить, модель таймсерий, на которую мы нацелены, не поддерживает дельту счетчики.С этой целью необходимо определить преобразование дельты в кумулятивное. чтобы серверные ВМ могли использовать этот механизм.

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

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

Алгоритм распланирован следующим образом:

  • После получения первой точки дельты для данного счетчика мы настраиваем следующий:
    • Новый счетчик, в котором хранится накопленная сумма, установленная на начальный счетчик.
    • Время начала, совпадающее со временем начала первой точки.
    • Время «последнего посещения», совпадающее со временем первой точки.
  • После получения будущих баллов Delta мы делаем следующее:
    • Если следующая точка совпадает с ожидаемым окном следующего раза (см. определение перезапуска по дельте)
      • Обновить время «последнего посещения», чтобы оно соответствовало времени текущей точки.
      • Добавить текущее значение к накопительному счетчику
      • Вывести новую совокупную точку с исходным временем начала и текущим значением. время последнего посещения и количество.
    • , если текущая точка предшествует времени начала, отбросьте эту точку. Примечание: есть алгоритмы, которые могут работать с опоздавшими точками.
    • , если следующая точка НЕ ​​совпадает с ожидаемым окном следующего раза, то сбросить счетчик, выполнив те же действия, как если бы текущая точка была первая увиденная точка.
Суммы: обнаружение проблем с выравниванием

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

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

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

Мы обнаруживаем выравнивание с помощью двух механизмов:

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

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

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

Сноски

[1]: OTLP поддерживает типы точек данных, которые не удовлетворяют этим условиям; они четко определены, но не поддерживают стандартные преобразования метрических данных.

Окончательная подсказка телеметрии PowerShell • Одинокий администратор

Что ж, я знал, что не останусь доволен. На днях я поделился функцией подсказки PowerShell, которая могла отображать телеметрию, например информацию, для нескольких удаленных серверов. Одним из недостатков было ограниченное количество информации, которую я мог отображать.Я переработал эту функцию и получил новую версию, которая отображает дополнительную информацию с помощью нескольких счетчиков производительности. Я также реорганизовал эту функцию, чтобы сделать ее более эффективной. Хочу это увидеть?

Эта версия по-прежнему читает список имен компьютеров. Я все же рекомендую держать этот список кратким. Хотя я изменил отображение подсказок, чтобы у каждого сервера была своя строка.

Эта версия функции вызывает Get-Counter для получения дополнительной информации.

 # определить список счетчиков производительности
$ c = "\ processor (_total) \% процессорного времени",
"\ Physicaldisk (_total) \% дискового времени",
"\ сервер \ всего байтов / сек",
"\ system \ file control operations / sec"


# создать хеш-таблицу счетчиков и значений
get-counter -Counter $ c | select-object -ExpandProperty countersamples |
    foreach-object -Begin {$ counterhash = @ {}} -process {
    $ counterHash.add ($ _. Path.split ("\\") [- 1], [math] :: round ($ _. CookedValue, 2))
}
 

Данные счетчика добавляются к выходным данным для каждого сервера.

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

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

Если вы используете консоль PowerShell только для того, чтобы время от времени запускать команду или просто хотите периодически обновлять данные, это может быть полезно. Однако вы можете переключить эту функцию. Когда вы загружаете приглашение, PowerShell определит глобальную переменную PromptClear со значением $ True. Запустите $ PromptClear = $ False, чтобы выключить паузу и очистить. Верните значение $ True, чтобы снова включить.

К настоящему времени некоторые из вас уже хотят попробовать. Файл размещен на GitHub.

Как вы думаете? Достаточно ли я зашел в эту концепцию? Это практично для кого-нибудь из вас? Что вы сделали, чтобы это работало на вас? Я надеюсь, что вы найдете это полезным или, по крайней мере, почерпнете пару подсказок из кода. Наслаждаться.

Нравится:

Нравится Загрузка ...

Связанные

Телеметрия - документация Apstra 3.3.0

 {
  "Предметы": [
    {
      "действительный": {
        "значение": "отсутствует"
      },
      "anomaly_type": "маршрут",
      "ожидал": {
        "значение": "вверх"
      },
      "id": "547bcbc9-963f-4477-904b-712482aa6428",
      "личность": {
        "anomaly_type": "маршрут",
        "destination_ip": "0.0,0.0 / 0 ",
        "system_id": "000C226"
      },
      "last_modified_at": "2017-06-09T17: 28: 13.773324Z",
      "роль": "неизвестно",
      «серьезность»: «критическая»
    },
    {
      "действительный": {
        "значение": "частичное"
      },
      "anomaly_type": "маршрут",
      "ожидал": {
        "значение": "вверх"
      },
      "id": "92a6804a-42ff-4cbd-a52b-5c6acadc1d23",
      "личность": {
        "anomaly_type": "маршрут",
        "destination_ip": "0.0.0.0/0",
        "system_id": "000C29EA59A7"
      },
      "last_modified_at": "2017-06-09T17: 28: 44.787604Z ",
      "роль": "неизвестно",
      «серьезность»: «критическая»
    },
    {
      "действительный": {
        "значение": "частичное"
      },
      "anomaly_type": "маршрут",
      "ожидал": {
        "значение": "вверх"
      },
      "id": "25886eb7-e629-4f56-9479-686fe1e53c64",
      "личность": {
        "anomaly_type": "маршрут",
        "destination_ip": "0.0.0.0/0",
        "system_id": "000C29E808A1"
      },
      "last_modified_at": "2017-06-09T17: 28: 13.773423Z",
      "роль": "неизвестно",
      «серьезность»: «критическая»
    },
    {
      "действительный": {
        "значение": "частичное"
      },
      "anomaly_type": "маршрут",
      "ожидал": {
        "значение": "вверх"
      },
      "id": "2b7a77ac-fd12-41fe-acfc-a53678b177ed",
      "личность": {
        "anomaly_type": "маршрут",
        "destination_ip": "0.0,0.0 / 0 ",
        "system_id": "000C2982786A"
      },
      "last_modified_at": "2017-06-09T17: 28: 13.773389Z",
      "роль": "неизвестно",
      «серьезность»: «критическая»
    },
    {
      "действительный": {
        "значение": "частичное"
      },
      "anomaly_type": "маршрут",
      "ожидал": {
        "значение": "вверх"
      },
      "id": "50a1e0d6-e483-4bc4-bed8-cbc5666569f8",
      "личность": {
        "anomaly_type": "маршрут",
        "destination_ip": "0.0.0.0/0",
        "system_id": "000C2998C7E7"
      },
      "last_modified_at": "2017-06-09T17: 28: 13.773453Z ",
      "роль": "неизвестно",
      «серьезность»: «критическая»
    },
    {
      "действительный": {
        "значение": "вниз"
      },
      "anomaly_type": "bgp",
      "ожидал": {
        "значение": "вверх"
      },
      "id": "ab9f4273-e86f-456c-8cc7-7115f3aafa45",
      "личность": {
        "anomaly_type": "bgp",
        "destination_asn": "1",
        "destination_ip": "1.1.1.1",
        "source_asn": "65417",
        "source_ip": "10.0.0.5",
        "system_id": "000C226"
      },
      "last_modified_at": "2017-06-09T17: 28: 13.727949Z ",
      "роль": "to_external_router",
      «серьезность»: «критическая»
    }
  ],
  «count»: 6
}
 

показать количество системных ошибок | Руководство пользователя телеметрического интерфейса Junos

Синтаксис

  показать количество системных ошибок 
 

Описание

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

Параметры

Эта команда не имеет параметров.

Требуемый уровень привилегий

admin

Поля вывода

В таблице 1 перечислены поля вывода для команды show system errors count . Поля вывода перечислены в примерном порядке, в котором они появились.

Таблица 1: показать количество системных ошибок Поля вывода

Имя поля

Описание поля

Уровень

Уровень серьезности ошибки.Ценности являются: Незначительный, Большой или Фатальный.

Произошло

Количество ошибок определенного уровня серьезности.

Освобожден

Количество ошибок определенного уровня серьезности. очищено.

Действуют

Количество запусков восстановления для специфическая степень серьезности.

Пример вывода

показать количество системных ошибок

 user @ host>  показать количество системных ошибок 
Уровень Происходит Очищено Действие принято
-------------------------------------------------- -------
 Незначительный: 0 0 0
 Майор: 1 0 1
 Смертельный: 0 0 0
 
Информация о выпуске

Команда

представлена ​​в выпуске ОС Junos 18.2R1.

Телеметрия | Consul от HashiCorp

Search Consul документация

Агент Consul собирает различные показатели времени выполнения о производительности разные библиотеки и подсистемы. Эти показатели суммируются по десятибалльной шкале. секундный (10 с) интервал и сохраняются в течение одной минуты. Интервал - это период времени между экземплярами данных, которые собираются и агрегируются.

Когда телеметрия передается во внешнее хранилище метрик, интервал определяется как интервал очистки этого хранилища.

Чтобы просмотреть эти данные, вы должны послать сигнал процессу Consul: в Unix, это USR1 , а в Windows - BREAK . Как только Консул получит сигнал, он сбрасывает текущую телеметрическую информацию на stderr агента.

Эту телеметрическую информацию можно использовать для отладки или иным образом. получить лучшее представление о том, что делает Консул. Просмотрите Мониторинг и Учебник по метрикам, чтобы узнать, как собирать и интерпретировать данные Consul.

Дополнительно, если телеметрия опции конфигурации предоставлены, телеметрическая информация будет передаваться на сайт статистики или сервер статистики, где его можно агрегировать и сбрасывать в Graphite или любое другое хранилище метрик.Пример конфигурации для Telegraf см. В руководстве «Мониторинг с помощью Telegraf».

Это информацию также можно просмотреть с помощью конечной точки метрик в JSON формат или используя формат Прометей.

Ниже приведен пример вывода дампа телеметрии:

 [2014-01-29 10:56:50 -0800 PST] [G] 'consul-agent.runtime.num_goroutines': 19,000
[2014-01-29 10:56:50 -0800 PST] [G] 'consul-agent.runtime.alloc_bytes': 755960.000
[2014-01-29 10:56:50 -0800 PST] [G] 'consul-agent.runtime.malloc_count': 7550.000
[2014-01-29 10:56:50 -0800 PST] [G] 'consul-agent.runtime.free_count': 4387.000
[2014-01-29 10:56:50 -0800 PST] [G] 'consul-agent.runtime.heap_objects': 3163,000
[2014-01-29 10:56:50 -0800 PST] [G] 'consul-agent.runtime.total_gc_pause_ns': 1151002.000
[2014-01-29 10:56:50 -0800 PST] [G] 'consul-agent.runtime.total_gc_runs': 4.000
[2014-01-29 10:56:50 -0800 PST] [C] 'consul-agent.agent.ipc.accept': Count: 5 Сумма: 5.000
[2014-01-29 10:56:50 -0800 PST] [C] 'consul-agent.agent.ipc.command': Количество: 10 Сумма: 10.000
[2014-01-29 10:56:50 -0800 PST] [C] 'consul-agent.serf.events': Количество: 5 Сумма: 5.000
[2014-01-29 10:56:50 -0800 PST] [C] 'consul-agent.serf.events.foo': Count: 4 Сумма: 4.000
[2014-01-29 10:56:50 -0800 PST] [C] 'consul-agent.serf.events.baz': Количество: 1 Сумма: 1.000
[2014-01-29 10:56:50 -0800 PST] [S] 'consul-agent.memberlist.gossip': Количество: 50 Мин .: 0,007 Среднее: 0,020 Макс .: 0,041 Стандартное отклонение: 0,007 Сумма: 0,989
[2014-01-29 10:56:50 -0800 PST] [S] 'consul-agent.serf.queue.Intent': Count: 10 Сумма: 0,000
[2014-01-29 10:56:50 -0800 PST] [S] 'консул-агент.serf.queue.Event ': Счетчик: 10 Мин .: 0,000 Среднее: 2,500 Макс .: 5.000 Стандартное отклонение: 2,121 Сумма: 25,000
 
  [2014-01-29 10:56:50 -0800 PST] [G] 'consul-agent.runtime.num_goroutines': 19,000 [2014-01-29 10:56:50 -0800 PST] [G] 'consul-agent.runtime.alloc_bytes': 755960.000 [2014-01-29 10:56:50 -0800 PST] [G] 'consul-agent.runtime.malloc_count': 7550.000 [29.01.2014 10:56: 50 -0800 PST] [G] 'consul-agent.runtime.free_count': 4387,000 [2014-01-29 10:56:50 -0800 PST] [G] 'consul-agent.runtime.heap_objects': 3163.000 [2014-01-29 10:56:50 -0800 PST] [G] 'consul-agent.runtime.total_gc_pause_ns': 1151002.000 [2014-01-29 10:56:50 -0800 PST] [G] 'консул -agent.runtime.total_gc_runs ': 4.000 [2014-01-29 10:56:50 -0800 PST] [C]' consul-agent.agent.ipc.accept ': Count: 5 Сумма: 5.000 [2014-01- 29 10:56:50 -0800 PST] [C] 'consul-agent.agent.ipc.command': Счетчик: 10 Сумма: 10.000 [2014-01-29 10:56:50 -0800 PST] [C] ' consul-agent.serf.events ': Счетчик: 5 Сумма: 5.000 [2014-01-29 10:56:50 -0800 PST] [C]' consul-agent.serf.events.foo ': Счетчик: 4 Сумма: 4.000 [2014-01-29 10:56:50 -0800 PST] [C] 'consul-agent.serf.events.baz': Count: 1 Сумма: 1.000 [2014-01-29 10:56:50 -0800 PST] [S] 'consul-agent.memberlist.gossip': Счетчик: 50 Мин .: 0,007 Среднее: 0,020 Макс .: 0,041 Стандартное отклонение: 0,007 Сумма: 0,989 [2014-01-29 10:56:50 -0800 PST] [S ] 'consul-agent.serf.queue.Intent': Count: 10 Сумма: 0,000 [2014-01-29 10:56:50 -0800 PST] [S] 'consul-agent.serf.queue.Event': Count : 10 Мин .: 0,000 Среднее: 2,500 Макс .: 5.000 Стандартное отклонение: 2,121 Сумма: 25,000  

Это некоторые выдаваемые метрики, которые могут помочь вам быстро понять состояние вашего кластера.Также доступна панель управления Grafana, которая поддерживается командой Consul и отображает эти показатели для облегчения визуализации. Полный список показателей Consul см. В Справочнике показателей

»Время транзакции

время, необходимое для завершения обновления магазина KV.
Название метрики Описание Единица Тип
consul.kvs.apply мс таймер
консул.txn.apply Измеряет время, затраченное на выполнение операции транзакции. мс таймер
consul.raft.apply Подсчитывает количество транзакций Raft, примененных в течение интервала. Эта метрика сообщается только по лидеру. транзакций на плоту / интервал счетчик
consul.raft.commitTime Измеряет время, необходимое для фиксации новой записи в журнале Raft на лидере. мс таймер

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

На что обращать внимание: Отклонения (в любом из этих показателей) более чем на 50% от базового уровня за предыдущий час.

»Смена руководства

Название метрики Описание Единица Тип
consul.raft.leader.lastContact Измеряет время с момента последнего контакта с лидером ведомые узлы при проверке аренды лидера. мс таймер
consul.raft.state.candidate Увеличивается всякий раз, когда сервер Consul начинает выборы. выборы counter
consul.raft.state.leader Увеличивается, когда сервер Consul становится лидером. лидеров счетчик

Почему они важны: Обычно в вашем кластере Consul должен быть стабильный лидер. Если происходят частые выборы или смена руководства, это может указывать на проблемы с сетью между серверами Consul или на то, что сами серверы Consul не справляются с нагрузкой.

На что обращать внимание: Для здорового кластера вам нужен lastContact ниже 200 мс, лидер > 0 и кандидат == 0. Отклонения от этого могут указывать на нестабильное лидерство.

»Автопилот

Название метрики Описание Единица Тип
consul.autopilot.healthy Отслеживает общее состояние кластера локального сервера.Если автопилот считает все серверы работоспособными, для него будет установлено значение 1. Если какие-либо из них неработоспособны, это будет равно 0. Все серверы, не являющиеся ведущими, будут сообщать NaN . состояние работоспособности gauge

Почему это важно: Автопилот может показать общее состояние вашего кластера с помощью простого логического значения.

На что обращать внимание: Предупреждать, если здоровый равен 0. Некоторые другие индикаторы неработоспособного кластера:

  • консул.raft.commitTime - Это может помочь отразить скорость государственного магазина изменения, выполняемые агентом. Если это число растет, сервер может возникла проблема из-за неработающих ресурсов на хосте.
  • Показатели смены руководства - Проверить на отклонение от рекомендуемые значения. Это может указывать на неудачные выборы руководства или хлопающие узлы.

»Использование памяти

Название метрики Описание Единица Тип
консул.runtime.alloc_bytes Измеряет количество байтов, выделенных процессом Consul. байтов gauge
consul.runtime.sys_bytes Измеряет общее количество байтов памяти, полученных от ОС. байтов калибр

Почему они важны: Consul хранит все свои данные в памяти. Если Consul использует всю доступную память, произойдет сбой.

На что обращать внимание: Если консул.runtime.sys_bytes превышает 90% от общей доступной системной памяти.

ПРИМЕЧАНИЕ: Этот показатель рассчитывается с использованием пакета времени выполнения Go. MemStats. Это будет результат отличается от использования информации, полученной из вверху . Для большего информацию см. GH-4734.

»Сборка мусора

Название метрики Описание Единица Тип
consul.runtime.total_gc_pause_ns сборка мусора в мире ) приостанавливается с момента запуска Consul. нс gauge

Почему это важно: Пауза сборщика мусора - это событие «остановки мира», означающее, что все потоки времени выполнения блокируются до завершения сборки мусора. Обычно эти паузы длятся всего несколько наносекунд. Но если использование памяти велико, среда выполнения Go может собирать мусор так часто, что начинает замедлять работу Consul.

На что обращать внимание: Предупреждение, если значение total_gc_pause_ns превышает 2 секунды в минуту, критическое, если оно превышает 5 секунд в минуту.

ПРИМЕЧАНИЕ: total_gc_pause_ns - это накопительный счетчик, поэтому для расчета скорости (например, сборщика мусора в минуту), вам нужно будет применить такую ​​функцию, как InfluxDB non_negative_difference () .

»Сетевая активность - Счетчик RPC

Название метрики Описание Единица Тип
consul.client.rpc Приращение RPC при каждом переходе агента Consul в режим ПК запрос к серверу Consul запросов счетчик
консул.client.rpc.exceeded Увеличивается всякий раз, когда агент Consul в режиме клиента делает запрос RPC к серверу Consul, скорость которого ограничивается настройками этого агента, конфигурация . запросов счетчик
consul.client.rpc.failed Увеличивается каждый раз, когда агент Consul в режиме клиента делает запрос RPC к серверу Consul и терпит неудачу. запросов счетчик

Почему они важны: Эти измерения показывают текущую нагрузку, созданную агентом Consul, в том числе когда нагрузка становится достаточно высокой для ограничения скорости.Большое количество RPC, особенно от consul.client.rpce превосходит , что означает, что запросы ограничены по скорости, может означать неправильно настроенный агент Consul.

На что обращать внимание: Внезапные большие изменения в показателях consul.client.rpc (отклонение более чем на 50% от базового уровня). consul.client.rpc.exceeded или consul.client.rpc.failed count> 0, поскольку это означает, что агент ограничен по скорости или не может отправить запрос RPC на сервер Consul

»Raft Replication Проблемы емкости

Название метрики Описание Единица Тип
консул.raft.fsm.lastRestoreDuration Измеряет время, необходимое для восстановления FSM из моментального снимка при перезапуске агента или из лидера, вызывающего installSnapshot. Это индикатор, который сохраняет свое значение, поскольку большинство серверов восстанавливаются только во время перезапусков, которые обычно нечасты. мс калибр
consul.raft.leader.oldestLogAge Количество миллисекунд с момента записи самого старого журнала в хранилище журналов лидера.Это может быть важно для работоспособности репликации, когда скорость записи высока, а моментальный снимок велик, так как последователи могут быть не в состоянии восстановиться после перезапуска, если восстановление занимает больше времени, чем минимальное значение для текущего лидера. Сравните это с consul.raft.fsm.lastRestoreDuration и consul.raft.rpc.installSnapshot для мониторинга. При нормальном использовании это значение шкалы будет линейно расти со временем до тех пор, пока не будет завершен моментальный снимок лидера и не будет усечен журнал. мс калибр
консул.raft.rpc.installSnapshot Измеряет время, необходимое для обработки вызова RPC installSnapshot. Этот показатель должен отображаться только для агентов, которые в настоящее время находятся в состоянии слежения. мс таймер

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

  • Пропускная способность записи высокая (скажем, 500 коммитов в секунду или более) и постоянная
  • Лидер записывает большой снимок каждую минуту или около того
  • Снимок достаточно большой, что занимает значительное время восстановить из диск при перезапуске или от лидера, если ведомый отстает
  • Доступен дисковый ввод-вывод позволяет ведущему записать моментальный снимок быстрее, чем он может восстановлено с диска на ведомом

В этих условиях ведомый после перезапуска может быть не в состоянии наверстать упущенное. репликации и снова стать избирателем, так как восстановление с диска занимает больше времени или лидер, чем лидер берет, чтобы написать новый снимок и усечь его журналы.Серверы сохраняют raft_trailing_logs (по умолчанию 10240 ), даже если их моментальный снимок был более поздним. На лидере обработка 500 коммитов в секунду, что составляет всего около 20 секунд журналов. Предполагая, что лидер может записать снимок и обрезать журналы в менее 20 секунд, "недавние" журналы будут длиться только 20 секунд. доступен на выноске сразу после того, как лидер сделал снимок, и никогда более 80 секунд, если предположить, что он делает снимок и усекает журналы каждые 60 секунд.

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

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

Начиная с Consul 1.5.3 raft_trailing_logs был настраиваемый. Его увеличение позволяет лидеру сохранять больше журналов и давать у фолловеров больше времени, чтобы восстановиться и наверстать упущенное.Компромисс потенциально более медленные добавления, которые в конечном итоге могут повлиять на пропускную способность записи и задержку отрицательно, поэтому не рекомендуется устанавливать его произвольно. Перед консулом 1.10.0 потребовался непрерывный перезапуск, чтобы изменить эту конфигурацию на лидере хотя и поскольку ни один последователь не мог перезапуститься без потери здоровья, это могло означают потерю доступности кластера и необходимость восстановления кластера после потери кворума.

с Consul 1.10.0 raft_trailing_logs сейчас перезагружаемый с помощью consul reload или SIGHUP , что позволяет операторам увеличить без перезапуска лидера или потери лидерства, позволяя кластеру быть восстановился изящно.

Мониторинг этих показателей может помочь избежать или диагностировать это состояние.

На что обращать внимание:

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

Есть два способа восстановить снимок на ведомом устройстве: с диска на при запуске или из лидера во время установки installSnapshot RPC.Только лидер отправляет installSnapshot RPC, если подписчик новый и не имеет состояния, или если это состояние слишком старое, чтобы догнать журналы лидеров.

consul.raft.fsm.lastRestoreDuration показывает время, необходимое для восстановления из любой источник в последний раз, когда это произошло. В большинстве случаев это когда сервер был запущен. Это индикатор, который всегда будет показывать время последнего восстановления. (в Consul 1.10.0 и более поздних версиях), как бы давно это ни было.

консул.raft.rpc.installSnapshot - это временная информация от лидера перспектива, когда он устанавливает новый снимок на последователя. Включает время потратил на передачу данных, а также на их восстановление подписчиком. Поскольку эти события, как правило, нечасты, может потребоваться графическое отображение последнего наблюдаемого значения, например, используя max_over_time с большим диапазоном в Prometheus. В то время как часть восстановления также будет отражена в lastRestoreDuration , это может быть полезно и это тоже нужно соблюдать, поскольку журналы должны покрывать все операция, включая доставку снимка, чтобы подписчики всегда могли поймать безопасно.

Построение графика consul.raft.leader.oldestLogAge на тех же осях, что и два других показатели здесь могут помочь сразу увидеть, если время восстановления опасно сокращается. близко к пределу того, что сохраняет лидер при текущей скорости записи.

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

»Срок действия лицензии

Enterprise

Название метрики Описание Единица Тип
консул.system.licenseExpiration Количество часов до истечения срока действия лицензии Consul Enterprise. часов калибр

Почему они важны:

Это измерение показывает, сколько часов осталось до истечения срока действия лицензии Consul Enterprise. Когда срок действия лицензии истечет, Функции Consul Enterprise перестанут работать. Примером этого является то, что по истечении срока действия создание или изменять ресурсы в пространствах имен, отличных от заданных по умолчанию, или управлять определениями пространств имен самими, даже если чтения из пространства имен ресурсы по-прежнему будут работать.

На что обращать внимание:

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

»Справка по метрикам

Это полный список метрик, созданных Consul.

Метрика Описание Единица Тип
consul.acl.blocked. {Check, service} .deregistration Приращения всякий раз, когда дерегистрация или услуга не удается ) заблокирован ACL. запросы счетчик
consul.acl.blocked. {Check, node, service} .registration Увеличивается всякий раз, когда регистрация не удалась для объекта (проверка, узел или служба), заблокированная ACL. запросы счетчик
consul.api.http Мигрировано с consul.http .. это пример того, сколько времени требуется для обслуживания данного HTTP-запроса для данного глагола и пути. Включает метки для пути и метода . путь не включает такие детали, как имена служб или ключей, для них подчеркивание будет присутствовать в качестве заполнителя (например, path = v1.kv._ ) мс таймер
consul.client .rpc Увеличивается всякий раз, когда агент Consul в режиме клиента делает запрос RPC к серверу Consul. Это дает меру того, насколько данный агент загружает серверы Consul. В настоящее время это генерируется только агентами в клиентском режиме, а не серверами Consul. запрашивает счетчик
consul.client.rpc.exceeded Увеличивается всякий раз, когда агент Consul в режиме клиента делает запрос RPC к серверу Consul, скорость которого ограничена настройками этого агента , ограничивает конфигурацию . Это указывает на то, что злонамеренное приложение делает слишком много запросов к агенту или что необходимо увеличить ограничение скорости. В настоящее время это относится только к агентам в клиентском режиме, но не к серверам Consul. отклоненные запросы счетчик
consul.client.rpc.failed Увеличивается всякий раз, когда агент Consul в режиме клиента делает запрос RPC к серверу Consul и терпит неудачу. запросы счетчик
consul.client.api.catalog_register. Увеличивается всякий раз, когда агент Consul получает запрос регистрации каталога. запросы счетчик
консул.client.api.success.catalog_register. Увеличивается всякий раз, когда агент Consul успешно отвечает на запрос регистрации каталога. запросы счетчик
consul.client.rpc.error.catalog_register. Увеличивается всякий раз, когда агент Consul получает ошибку RPC для запроса реестра каталога. ошибки счетчик
consul.client.api.catalog_deregister. Увеличивается всякий раз, когда агент Consul получает запрос на отмену регистрации в каталоге. запросы счетчик
consul.client.api.success.catalog_deregister. Увеличивается всякий раз, когда агент Consul успешно отвечает на запрос отмены регистрации каталога. запросы счетчик
consul.client.rpc.error.catalog_deregister. Увеличивается всякий раз, когда агент Consul получает ошибку RPC для запроса отмены регистрации каталога. ошибки счетчик
консул.client.api.catalog_datacenters. Увеличивается всякий раз, когда агент Consul получает запрос на включение центров обработки данных в каталог. запросы счетчик
consul.client.api.success.catalog_datacenters. Увеличивается всякий раз, когда агент Consul успешно отвечает на запрос на получение списка центров обработки данных. запросы счетчик
consul.client.rpc.error.catalog_datacenters. Увеличивается всякий раз, когда агент Consul получает ошибку RPC для запроса на перечисление центров обработки данных. ошибки счетчик
consul.client.api.catalog_nodes. Увеличивается всякий раз, когда агент Consul получает запрос на получение списка узлов из каталога. запросы счетчик
consul.client.api.success.catalog_nodes. Увеличивается всякий раз, когда агент Consul успешно отвечает на запрос на получение списка узлов. запросы счетчик
консул.client.rpc.error.catalog_nodes. Увеличивается всякий раз, когда агент Consul получает ошибку RPC для запроса на получение списка узлов. ошибки счетчик
consul.client.api.catalog_services. Увеличивается всякий раз, когда агент Consul получает запрос на перечисление услуг из каталога. запросы счетчик
consul.client.api.success.catalog_services. Увеличивается всякий раз, когда агент Consul успешно отвечает на запрос на получение списка услуг. запросы счетчик
consul.client.rpc.error.catalog_services. Увеличивается всякий раз, когда агент Consul получает ошибку RPC для запроса на перечисление служб. ошибки счетчик
consul.client.api.catalog_service_nodes. Увеличивается всякий раз, когда агент Consul получает запрос на перечисление узлов, предлагающих услугу. запросы счетчик
консул.client.api.success.catalog_service_nodes. Увеличивается всякий раз, когда агент Consul успешно отвечает на запрос о перечислении узлов, предлагающих услугу. запросы счетчик
consul.client.api.error.catalog_service_nodes. Увеличивается всякий раз, когда агент Consul получает ошибку RPC для запроса на перечисление узлов, предлагающих услугу. запросы счетчик
консул. Клиент.rpc.error.catalog_service_nodes. Увеличивается всякий раз, когда агент Consul получает ошибку RPC для запроса на перечисление узлов, предлагающих услугу. ошибки счетчик
консул.client.api.catalog_node_services. Увеличивается всякий раз, когда агент Consul получает запрос на получение списка служб, зарегистрированных на узле. запросы счетчик
консул.client.api.success.catalog_node_services. Увеличивается всякий раз, когда агент Consul успешно отвечает на запрос на получение списка служб в узле. запросы счетчик
консул.client.rpc.error.catalog_node_services. Увеличивается всякий раз, когда агент Consul получает ошибку RPC для запроса на перечисление служб в узле. ошибки счетчик
консул.client.api.catalog_node_service_list Увеличивается всякий раз, когда агент Consul получает запрос на перечисление зарегистрированных служб узла. запросы счетчик
consul.client.rpc.error.catalog_node_service_list Увеличивается всякий раз, когда агент Consul получает ошибку RPC для запроса на перечисление зарегистрированных служб узла. ошибки счетчик
consul.client.api.success.catalog_node_service_list Увеличивается всякий раз, когда агент Consul успешно отвечает на запрос о перечислении зарегистрированных служб узла. запросы счетчик
consul.client.api.catalog_gateway_services. Увеличивается всякий раз, когда агент Consul получает запрос на перечисление служб, связанных со шлюзом. запросы счетчик
consul.client.api.success.catalog_gateway_services. Увеличивается всякий раз, когда агент Consul успешно отвечает на запрос о перечислении служб, связанных со шлюзом. запросы счетчик
consul.client.rpc.error.catalog_gateway_services. Увеличивается всякий раз, когда агент Consul получает ошибку RPC для запроса на перечисление служб, связанных со шлюзом. ошибки счетчик
consul.runtime.num_goroutines Отслеживает количество запущенных горутин и является общим индикатором давления нагрузки.Время от времени он может вспыхивать, но должен вернуться к постоянному значению. количество горутин калибр
consul.runtime.alloc_bytes Измеряет количество байтов, выделенных процессом Consul. Время от времени он может вспыхивать, но должен вернуться к постоянному значению. байт датчик
consul.runtime.heap_objects Измеряет количество объектов, размещенных в куче, и является общим индикатором нехватки памяти.Время от времени он может вспыхивать, но должен вернуться к постоянному значению. количество объектов калибр
consul.state.nodes Измеряет текущее количество узлов, зарегистрированных в Consul. Он отправляется только серверами Consul. Добавлено в v1.9.0. количество объектов калибр
consul.state.services Измеряет текущее количество уникальных услуг, зарегистрированных в Consul, на основе названия услуги.Он отправляется только серверами Consul. Добавлено в v1.9.0. количество объектов калибр
consul.state.service_instances Измеряет текущее количество уникальных экземпляров службы, зарегистрированных в Consul. Он отправляется только серверами Consul. Добавлено в v1.9.0. количество объектов калибр
consul.members.clients Измеряет текущее количество агентов клиентов, зарегистрированных в Consul.Он отправляется только серверами Consul. Добавлено в v1.9.6. количество клиентов калибр
consul.members.servers Измеряет текущее количество агентов сервера, зарегистрированных в Consul. Он отправляется только серверами Consul. Добавлено в v1.9.6. количество серверов калибр
consul.dns.stale_queries Увеличивается, когда агент обслуживает запрос в пределах допустимого порога устаревания. запросы счетчик
consul.dns.ptr_query. Измеряет время, затраченное на обработку обратного DNS-запроса для данного узла. мс таймер
consul.dns.domain_query. Измеряет время, затраченное на обработку запроса домена для данного узла. мс таймер
consul.http ... УСТАРЕЛО В 1.9: отслеживает, сколько времени требуется для обслуживания данного HTTP-запроса для данной команды и пути.Пути не включают такие детали, как имена служб или ключей, для них подчеркивание будет присутствовать в качестве заполнителя (например, consul.http.GET.v1.kv._ ) мс таймер
consul .system.licenseExpiration

Enterprise

Измеряет количество часов, оставшихся до лицензии агента.
часов датчик
консул. Версия Измеряет количество работающих агентов. агенты датчик

»Состояние сервера

Эти показатели используются для мониторинга состояния серверов Consul.

Метрика Описание Единица Тип
consul.acl.apply Измеряет время, необходимое для завершения обновления хранилища ACL. мс таймер
consul.acl.resolveTokenLegacy Измеряет время, необходимое для разрешения токена ACL с использованием устаревшей системы ACL. мс таймер
consul.acl.ResolveToken Измеряет время, необходимое для разрешения токена ACL. мс таймер
consul.acl.ResolveTokenToIdentity Измеряет время, необходимое для преобразования токена ACL в удостоверение. мс таймер
консул.acl.token.cache_hit Увеличивается, если Consul может определить идентификатор токена или устаревший токен из кеша. чтение кеша op счетчик
consul.acl.token.cache_miss Увеличивается, если Consul не может определить идентификатор токена или устаревший токен из кеша. чтение из кэша op счетчик
consul.cache.bypass Подсчитывает, сколько раз запрос обходил кеш, потому что не был предоставлен ключ кеша. счетчик счетчик
consul.cache.fetch_success Подсчитывает количество успешных выборок из кеша. счетчик счетчик
consul.cache.fetch_error Подсчитывает количество неудачных выборок из кеша. счетчик счетчик
consul.cache.evict_expired Подсчитывает количество удаленных записей с истекшим сроком действия. счетчик счетчик
consul.raft.applied_index Представляет примененный индекс плота. index gauge
consul.raft.apply Подсчитывает количество транзакций Raft, происходящих в течение интервала, что является общим показателем нагрузки записи на серверы Consul. рафт транзакций / интервал счетчик
консул.raft.barrier Подсчитывает, сколько раз агент запускал барьер, т. е. сколько раз он отправлял блокирующий вызов, чтобы гарантировать, что у агента есть все ожидающие операции, которые были поставлены в очередь, для применения к FSM агента. . блоков / интервал счетчик
consul.raft.commitNumLogs Измеряет количество журналов, обработанных для приложения к FSM в одном пакете. бревна калибр
консул.raft.commitTime Измеряет время, необходимое для фиксации новой записи в журнале Raft на лидере. мс таймер
consul.raft.fsm.lastRestoreDuration Измеряет время, необходимое для восстановления FSM из моментального снимка при перезапуске агента или из лидера, вызывающего installSnapshot. Это индикатор, который сохраняет свое значение, поскольку большинство серверов восстанавливаются только во время перезапусков, которые обычно нечасты. мс калибр
консул.raft.fsm.snapshot Измеряет время, необходимое конечному автомату для записи текущего состояния моментального снимка. мс таймер
consul.raft.fsm.apply Количество журналов, зафиксированных с последнего интервала. журналы фиксации / интервал счетчик
consul.raft.fsm.enqueue Измеряет количество времени для постановки пакета журналов в очередь для применения автоматом. мс таймер
консул.raft.fsm.restore Измеряет время, необходимое конечному автомату для восстановления своего состояния из моментального снимка. мс таймер
consul.raft.last_index Представляет примененный индекс рафта. index gauge
consul.raft.leader.dispatchLog Измеряет время, необходимое лидеру для записи записей журнала на диск. мс таймер
консул.raft.leader.dispatchNumLogs Измеряет количество журналов, зафиксированных на диске в пакете. журналы калибр
consul.raft.leader.lastContact Измеряет время, в течение которого лидер последний раз смог связаться с подчиненными узлами при проверке аренды лидера. Его можно использовать как меру того, насколько стабильно время Raft и насколько близок лидер к тайм-ауту аренды. Тайм-аут аренды составляет 500 мс, умноженных на raft_multiplier , поэтому это значение телеметрии не должно приближаться к этому. настроенное значение, в противном случае время Raft будет незначительным и, возможно, потребуется настроить, или могут потребоваться более мощные серверы.Для получения более подробной информации см. Руководство по производительности сервера. мс таймер
consul.raft.leader.oldestLogAge Количество миллисекунд с момента записи самого старого журнала в хранилище журналов лидера. Это может быть важно для работоспособности репликации, когда скорость записи высока, а моментальный снимок велик, так как последователи могут быть не в состоянии восстановиться после перезапуска, если восстановление занимает больше времени, чем минимальное значение для текущего лидера. Сравните это с консулом.raft.fsm.lastRestoreDuration и consul.raft.rpc.installSnapshot для мониторинга. При нормальном использовании это значение шкалы будет линейно расти со временем до тех пор, пока не будет завершен моментальный снимок лидера и не будет усечен журнал. Примечание: этот показатель не будет выдан до тех пор, пока лидер не напишет снимок. После обновления до Consul 1.10.0 он не будет отправлен до тех пор, пока после обновления не будет записан самый старый журнал. мс gauge
consul.raft.replication.heartbeat Измеряет время, необходимое для вызова appendEntries на одноранговом узле, так что время ожидания не истекает на периодической основе. мс таймер
consul.raft.replication.appendEntries Измеряет время, необходимое для репликации записей журнала для подписчиков. Это общий показатель нагрузки на серверы Consul, а также производительности связи между серверами. мс таймер
consul.raft.replication.appendEntries.rpc Измеряет время, затрачиваемое на добавление записей RFC, для репликации записей журнала ведущего агента на его ведомых агентов мс таймер
консул.raft.replication.appendEntries.logs Измеряет количество журналов, реплицируемых агенту, чтобы привести его в соответствие с журналами лидера. добавленных журналов / интервал счетчик
consul.raft.restore Подсчитывает, сколько раз агент выполнял операцию восстановления. Здесь под восстановлением понимается действие рафта, использующего внешний снимок для восстановления своего состояния. операция вызвана / интервал счетчик
консул.raft.restoreUserSnapshot Измеряет время, затрачиваемое агентом на восстановление состояния конечного автомата из снимка пользователя мс таймер
consul.raft.rpc.appendEntries Измеряет время, затраченное на обработку файла добавить записи Вызов RPC от агента. мс таймер
consul.raft.rpc.appendEntries.storeLogs Измеряет время, затраченное на добавление любых невыполненных журналов для агента, с момента последнего вызова appendEntries ms timer
консул.raft.rpc.appendEntries.processLogs Измеряет время, затраченное на обработку незавершенных записей журнала агента. мс таймер
consul.raft.rpc.installSnapshot Измеряет время, затраченное на обработку RPC-вызова installSnapshot. Этот показатель должен отображаться только для агентов, которые в настоящее время находятся в состоянии слежения. мс таймер
consul.raft.rpc.processHeartBeat Измеряет время, необходимое для обработки запроса пульса. мс таймер
consul.raft.rpc.requestVote Измеряет время, затраченное на обработку запроса RPC-вызова на голосование. мс таймер
consul.raft.snapshot.create Измеряет время, необходимое для инициализации процесса моментального снимка. мс таймер
consul.raft.snapshot.persist Измеряет время, необходимое для записи текущего моментального снимка, сделанного агентом Consul, на диск. мс таймер
consul.raft.snapshot.takeSnapshot Измеряет общее время, затраченное на создание текущего снимка (создание и сохранение его) агентом Consul. мс таймер
consul.serf.snapshot.appendLine Измеряет время, затрачиваемое агентом Consul на добавление записи в существующий журнал. мс таймер
консул.serf.snapshot.compact Измеряет время, затрачиваемое агентом Consul на сжатие журнала. Эта операция выполняется только тогда, когда снимок становится достаточно большим, чтобы оправдать сжатие. мс таймер
consul.raft.state.candidate Увеличивается всякий раз, когда сервер Consul начинает выборы. Если это значение увеличивается без изменения лидерства, это может указывать на то, что один сервер перегружен или испытывает проблемы с сетевым подключением. попыток выборов / интервал счетчик
consul.raft.state.leader Увеличивается, когда сервер Consul становится лидером. Если происходят частые смены руководства, это может указывать на то, что серверы перегружены и не соответствуют требованиям программного обеспечения в реальном времени для Raft, или на наличие сетевых проблем между серверами. руководство переходов / интервал счетчик
консул.raft.state.follower Подсчитывает, сколько раз агент переходил в режим слежения. Это происходит, когда к кластеру присоединяется новый агент или после окончания выборов лидера. введено состояние ведомого / интервал счетчик
consul.raft.transition.heartbeat_timeout Число раз, когда агент переходил в состояние кандидата после получения сообщений пульса от последнего известного лидера. таймауты / интервал счетчик
консул.raft.verify_leader Подсчитывает, сколько раз агент проверяет, является ли он по-прежнему лидером или нет. проверки / интервал Счетчик
consul.rpc.accept_conn Приращения, когда сервер принимает RPC связь. соединения счетчик
consul.catalog.register Измеряет время, необходимое для завершения операции реестра каталога. мс таймер
консул.catalog.deregister Измеряет время, необходимое для завершения операции отмены регистрации каталога. мс таймер
consul.fsm.register Измеряет время, необходимое для применения операции регистра каталога к конечному автомату. мс таймер
consul.fsm.deregister Измеряет время, необходимое для применения операции отмены регистрации каталога к конечному автомату. мс таймер
консул.fsm.acl. Измеряет время, необходимое для применения данной операции ACL к конечному автомату. мс таймер
consul.fsm.session. Измеряет время, необходимое для применения данной операции сеанса к конечному автомату. мс таймер
consul.fsm.kvs. Измеряет время, необходимое для применения данной операции KV к конечному автомату. мс таймер
консул.fsm.tombstone. Измеряет время, необходимое для применения данной операции захоронения к конечному автомату. мс таймер
consul.fsm.coordinate.batch-update Измеряет время, необходимое для применения данного пакетного обновления координат к конечному автомату. мс таймер
consul.fsm.prepared-query. Измеряет время, необходимое для применения данной подготовленной операции обновления запроса к конечному автомату. мс таймер
consul.fsm.txn Измеряет время, необходимое для применения данного обновления транзакции к FSM. мс таймер
consul.fsm.autopilot Измеряет время, необходимое для применения данного обновления автопилота к конечному автомату. мс таймер
consul.fsm.persist Измеряет время, необходимое для сохранения FSM в моментальный снимок рафта. мс таймер
consul.fsm.intention Измеряет время, необходимое для применения операции намерения к хранилищу состояний. мс таймер
consul.fsm.ca Измеряет время, необходимое для применения операций конфигурации CA к FSM. мс таймер
consul.fsm.ca.leaf Измеряет время, необходимое для применения операции при подписании листового сертификата. мс таймер
consul.fsm.acl.token Измеряет время, необходимое для применения операции токена ACL к FSM. мс таймер
consul.fsm.acl.policy Измеряет время, необходимое для применения операции политики ACL к FSM. мс таймер
consul.fsm.acl.bindingrule Измеряет время, необходимое для применения операции правила привязки ACL к FSM. мс таймер
consul.fsm.acl.authmethod Измеряет время, необходимое для применения метода аутентификации ACL к FSM. мс таймер
consul.fsm.system_metadata Измеряет время, необходимое для применения операции с системными метаданными к конечному автомату. мс таймер
consul.kvs.apply Измеряет время, необходимое для завершения обновления магазина KV. мс таймер
consul.leader.barrier Измеряет время, затраченное на ожидание барьера плота после получения лидерства. мс таймер
consul.leader.reconcile Измеряет время, затраченное на обновление хранилища плота на основе информации о члене крепостного. мс таймер
consul.leader.reconcileMember Измеряет время, затраченное на обновление хранилища плотов для информации одного члена крепостного. мс таймер
consul.leader.reapTombstones Измеряет время, затраченное на очистку надгробий. мс таймер
consul.leader.replication.acl-policy.status Это будет отправлено только ведущим в дополнительном центре обработки данных. Значение будет 1, если последний раунд репликации политики ACL прошел успешно, или 0, если произошла ошибка. здоровый калибр
консул.leader.replication.acl-policy.index Это будет отправлено только ведущим в дополнительном центре обработки данных. Приращения к индексу политик ACL в основном центре обработки данных, которые были успешно реплицированы. index gauge
consul.leader.replication.acl-roles.status Это будет отправлено только ведущим в дополнительном центре обработки данных. Значение будет равно 1, если последний раунд репликации роли ACL прошел успешно, или 0, если произошла ошибка. здоровый калибр
consul.leader.replication.acl-roles.index Это будет отправлено только ведущим в дополнительном центре обработки данных. Увеличение индекса ролей ACL в основном центре обработки данных, которые были успешно реплицированы. index gauge
consul.leader.replication.acl-tokens.status Это будет выдано только ведущим в дополнительном центре обработки данных.Значение будет 1, если последний раунд репликации токена ACL прошел успешно, или 0, если произошла ошибка. здоровый калибр
consul.leader.replication.acl-tokens.index Это будет выдано только ведущим в дополнительном центре обработки данных. Увеличение индекса токенов ACL в основном центре обработки данных, которые были успешно реплицированы. индекс колея
консул. Руководитель.replication.config-entries.status Это будет отправлено только ведущим в дополнительном центре обработки данных. Значение будет 1, если последний раунд репликации записи конфигурации был успешным, или 0, если произошла ошибка. исправный датчик
consul.leader.replication.config-entries.index Это будет отправлено только ведущим в дополнительном центре обработки данных. Увеличение индекса записей конфигурации в основном центре обработки данных, которые были успешно реплицированы. index gauge
consul.leader.replication.federation-state.status Это будет выдано только ведущим в дополнительном центре обработки данных. Значение будет равно 1, если последний раунд репликации состояния федерации прошел успешно, или 0, если произошла ошибка. здоровый калибр
consul.leader.replication.federation-state.index Это будет отправлено только ведущим в дополнительном центре обработки данных.Приращения к индексу состояний федерации в основном центре обработки данных, которые были успешно реплицированы. index gauge
consul.leader.replication.namespaces.status

Enterprise

Это будет выдано только ведущим в дополнительном центре обработки данных. Значение будет 1, если последний раунд репликации пространства имен был успешным, или 0, если произошла ошибка.
здоровый калибр
консул.leader.replication.namespaces.index

Enterprise

Это будет отправлено только ведущим в дополнительном центре обработки данных. Увеличение индекса пространств имен в основном центре данных, которые были успешно реплицированы.
index gauge
consul.prepared-query.apply Измеряет время, необходимое для применения подготовленного обновления запроса. мс таймер
консул.Подготовленный запрос.explain Измеряет время, необходимое для обработки подготовленного запроса объяснения запроса. мс таймер
consul.prepared-query.execute Измеряет время, необходимое для обработки подготовленного запроса на выполнение запроса. мс таймер
consul.prepared-query.execute_remote Измеряет время, необходимое для обработки подготовленного запроса на выполнение запроса, который был перенаправлен в другой центр обработки данных. мс таймер
consul.rpc.raft_handoff Увеличивается, когда сервер принимает RPC-соединение, связанное с Raft. соединения счетчик
consul.rpc.request_error Увеличивается, когда сервер возвращает ошибку из запроса RPC. ошибки счетчик
consul.rpc.request Увеличивается, когда сервер получает запрос RPC, связанный с Consul. запросы счетчик
consul.rpc.query Увеличивается, когда сервер получает запрос чтения RPC, указывая скорость новых запросов чтения. См. В consul.rpc.queries_blocking текущее количество вызовов RPC с блокировкой в ​​полете. Эта метрика была изменена в 1.7.0 и увеличивалась только в начале запроса. Скорость запросов будет ниже, но будет более точной. запросы счетчик
консул.rpc.queries_blocking Текущее количество запросов блокировки в полете, обрабатываемых сервером. запросы датчик
consul.rpc.cross-dc Приращение, когда сервер отправляет (потенциально блокирующий) запрос RPC между центрами обработки данных. запросы счетчик
consul.rpc.consistentRead Измеряет время, затраченное на подтверждение возможности выполнения последовательного чтения. мс таймер
consul.session.apply Измеряет время, затраченное на применение обновления сеанса. мс таймер
consul.session.renew Измеряет время, затраченное на обновление сеанса. мс таймер
consul.session_ttl.invalidate Измеряет время, затраченное на аннулирование истекшего сеанса. мс таймер
консул.txn.apply Измеряет время, затраченное на выполнение операции транзакции. мс таймер
consul.txn.read Измеряет время, затраченное на возврат транзакции чтения. мс таймер
consul.grpc.client.request.count Подсчитывает количество запросов gRPC, отправленных агентом клиента серверу Consul. запросы счетчик
консул.grpc.client.connection.count Подсчитывает количество новых соединений gRPC, открытых агентом клиента на сервере Consul. соединений счетчик
consul.grpc.client.connections Измеряет количество активных соединений gRPC, открытых от агента клиента к любым серверам Consul. соединений калибр
consul.grpc.server.request.count Подсчитывает количество запросов gRPC, полученных сервером. запросы счетчик
consul.grpc.server.connection.count Подсчитывает количество новых подключений gRPC, полученных сервером. соединений счетчик
consul.grpc.server.connections Измеряет количество активных соединений gRPC, открытых на сервере. соединения манометр
consul.grpc.server.stream.count Подсчитывает количество новых потоков gRPC, полученных сервером. поток счетчик
consul.grpc.server.streams Измеряет количество активных потоков gRPC, обрабатываемых сервером. поток датчик
consul.xds.server.streams Измеряет количество активных потоков xDS, обрабатываемых сервером, в разбивке по версиям протокола. поток датчик

»Состояние кластера

Эти показатели дают представление о состоянии кластера в целом.

Отправлено
Метрика Описание Единица Тип
consul. memberlist.degraded.probe Подсчитывает, сколько раз агент выполнял более медленное обнаружение сбоев на другом агенте темп. Агент использует собственную метрику работоспособности в качестве индикатора для выполнения этого действия. (Если его оценка работоспособности низкая, означает, что узел исправен, и наоборот.) зондов / интервал счетчик
консул.memberlist.degraded.timeout Подсчитывает, сколько раз агент был помечен как неработающий узел, не получив при этом достаточного количества подтверждений из случайно выбранного списка узлов агента в членстве агента. вхождение / интервал счетчик
consul.memberlist.msg.dead Подсчитывает, сколько раз агент пометил другого агента как неработающий узел. сообщений / интервал счетчик
консул.memberlist.health.score Описывает восприятие узлом своего собственного здоровья на основе того, насколько хорошо он удовлетворяет требованиям протокола мягкого реального времени. Этот показатель находится в диапазоне от 0 до 8, где 0 означает «полностью исправен». Эта оценка работоспособности используется для масштабирования времени между исходящими зондами, а более высокие оценки переводятся в более длинные интервалы зондирования. Подробнее см. Раздел IV статьи Lifeguard: https://arxiv.org/pdf/1707.00788.pdf оценка калибр
консул.memberlist.msg.suspect Увеличивается, когда агент подозревает, что другой агент потерпел неудачу, при выполнении случайных зондов в рамках протокола сплетен. Это может быть индикатором перегруженности агентов, сетевых проблем или ошибок конфигурации, когда агенты не могут подключиться друг к другу на требуемых портах. получено подозрительных сообщений / интервал счетчик
consul.memberlist.tcp.accept Подсчитывает, сколько раз агент принимал входящее потоковое соединение TCP. принятых соединений / интервал счетчик
consul.memberlist.udp.sent / Received Измеряет общее количество байтов, отправленных / полученных агентом по протоколу UDP. байт отправлено или получено байтов / интервал счетчик
consul.memberlist.tcp.connect Подсчитывает, сколько раз агент инициировал синхронизацию push / pull с другим агентом. push / pull инициировано / интервал счетчик
консул.memberlist.tcp.sent Измеряет общее количество байтов, отправленных агентом по протоколу TCP байт / интервал счетчик
consul.memberlist.gossip Измеряет время, затраченное на сплетни сообщения, которые будут переданы набору случайно выбранных узлов. мс таймер
consul.memberlist.msg_alive Подсчитывает количество активных сообщений, которые агент обработал на данный момент, на основе информации сообщения, предоставленной сетевым уровнем. сообщения / интервал счетчик
consul.memberlist.msg_dead Число мертвых сообщений, обработанных агентом на данный момент, на основе информации о сообщениях, предоставленной сетевым уровнем. сообщения / интервал счетчик
consul.memberlist.msg_suspect Число подозрительных сообщений, обработанных агентом на данный момент, на основе информации о сообщениях, предоставленной сетевым уровнем. сообщения / интервал счетчик
consul.memberlist.probeNode Измеряет время, необходимое для выполнения одного цикла обнаружения сбоя на выбранном агенте. узлов / интервал счетчик
consul.memberlist.pushPullNode Измеряет количество агентов, которые обменивались состоянием с этим агентом. узлов / интервал счетчик
консул.serf.member.failed Увеличивается, когда агент помечен как мертвый. Это может быть индикатором перегруженности агентов, сетевых проблем или ошибок конфигурации, когда агенты не могут подключиться друг к другу на требуемых портах. сбои / интервал счетчик
consul.serf.member.flap Доступно в Consul 0.7 и более поздних версиях, это значение увеличивается, когда агент помечен как мертвый, а затем восстанавливается в течение короткого периода времени. Это может быть индикатором перегруженности агентов, сетевых проблем или ошибок конфигурации, когда агенты не могут подключиться друг к другу на требуемых портах. закрылков / интервал счетчик
consul.serf.member.join Увеличивается, когда агент присоединяется к кластеру. Если агент дал сбой или отказал, этот счетчик также увеличивается при повторном подключении. соединений / интервал счетчик
consul.serf.member.left Увеличивается, когда агент покидает кластер. лист / интервал счетчик
консул.serf.events Увеличивается, когда агент обрабатывает событие. Consul использует события внутри себя, поэтому в телеметрии могут отображаться дополнительные события. Также существуют счетчики для каждого события, генерируемые как consul.serf.events. . событий / интервал счетчик
consul.serf.msgs.sent Эта метрика представляет собой образец количества байтов сообщений, транслируемых в кластер. В заданный интервал времени сумма этой метрики - это общее количество отправленных байтов, а счет - это количество отправленных сообщений. байт сообщения / интервал счетчик
consul.autopilot.failure_tolerance Отслеживает количество серверов для голосования, которые кластер может потерять, продолжая функционировать. серверы калибр
consul.autopilot.healthy Отслеживает общее состояние локального кластера серверов. Если автопилот считает все серверы работоспособными, для него будет установлено значение 1. Если какой-либо из серверов неработоспособен, он будет равен 0.Все серверы, не являющиеся лидерами, сообщат NaN . логический датчик
consul.session_ttl.active Отслеживает активное количество отслеживаемых сеансов. сеансов калибр
consul.catalog.service.query. Приращения для каждого запроса каталога для данной услуги. запросы счетчик
консул.каталог.сервис.query-tag .. Приращения для каждого запроса каталога для данной услуги с данным тегом. запросов счетчик
consul.catalog.service.query-tags .. Приращения для каждого запроса каталога для данной услуги с заданными тегами. запросы счетчик
consul.catalog.service.not-found. Приращения для каждого запроса каталога, в котором данная служба не может быть найдена. запросы счетчик
consul.catalog.connect.query. Приращения для каждого запроса каталога на основе соединения для данной службы. запросы счетчик
consul.catalog.connect.query-tag .. Приращения для каждого запроса каталога на основе соединения для данной услуги с данным тегом. запросы счетчик
консул.catalog.connect.query-tags .. Приращения для каждого запроса каталога на основе соединения для данной услуги с данными тегами. запросы счетчик
consul.catalog.connect.not-found. Приращения для каждого запроса каталога на основе соединения, в котором данная служба не может быть найдена. запросы счетчик

»Метрики встроенного прокси-сервера Connect

Встроенный прокси-сервер Consul Connect по умолчанию настроен на регистрацию метрик в тот же приемник, что и агент, который его запускает.

При работе в этом режиме он выдает некоторые базовые показатели. Они будут расширены в будущем.

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

»Этикетки

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

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

Например, агрегирование по всем восходящим и (т. Е. Исходящим) соединениям, которые имеют метки src и dst , вы можете получить сумму всей пропускной способности в и из данной службы или общее количество соединений между двумя службами.

»Справочник по метрикам

Стандартные метрики времени выполнения экспортируются с помощью метрик. , как с Consul. агент. В таблице ниже описаны дополнительные метрики, экспортируемые прокси.

Метрика Описание Единица Тип
consul.proxy.web.runtime. * Те же показатели времени выполнения, что описаны для агента выше. смешанный смешанный
консул.proxy.web.inbound.conns Показывает текущее количество соединений, открытых из входящих запросов к прокси. Если поддерживается, добавляется метка dst , указывающая имя службы, которую представляет прокси. соединение датчик
consul.proxy.web.inbound.rx_bytes Увеличивается на количество байтов, полученных от входящего клиентского соединения. Если поддерживается, добавляется метка dst , указывающая имя службы, которую представляет прокси. байт счетчик
consul.proxy.web.inbound.tx_bytes Увеличивается на количество байтов, переданных во входящее клиентское соединение. Если поддерживается, добавляется метка dst , указывающая имя службы, которую представляет прокси. байт счетчик
consul.proxy.web.upstream.conns Показывает текущее количество подключений, открытых от прокси-сервера к вышестоящему.Если поддерживается, добавляется метка src , указывающая имя службы, которое представляет прокси, и добавляется метка dst , указывающая имя службы, к которой подключается восходящий поток. соединение калибр
consul.proxy.web.inbound.rx_bytes Увеличивается на количество байтов, полученных от восходящего соединения. Если поддерживается, добавляется метка src , указывающая имя службы, которое представляет прокси, и добавляется метка dst , указывающая имя службы, к которой подключается восходящий поток. байт счетчик
consul.proxy.web.inbound.tx_bytes Увеличивается на количество байтов, переданных восходящему соединению. Если поддерживается, добавляется метка src , указывающая имя службы, которое представляет прокси, и добавляется метка dst , указывающая имя службы, к которой подключается восходящий поток. байт счетчик

Анализ телеметрии функций Azure в Application Insights

  • 6 минут на чтение
Эта страница полезна?

Оцените свой опыт

да Нет

Любой дополнительный отзыв?

Отзыв будет отправлен в Microsoft: при нажатии кнопки отправки ваш отзыв будет использован для улучшения продуктов и услуг Microsoft.Политика конфиденциальности.

Представлять на рассмотрение

В этой статье

Функции Azure интегрируются с Application Insights, чтобы вы могли лучше контролировать свои приложения-функции. Application Insights собирает данные телеметрии, созданные вашим приложением-функцией, включая информацию, которую ваше приложение записывает в журналы. Интеграция Application Insights обычно включается при создании приложения-функции.Если для вашего приложения-функции не задан ключ инструментария, необходимо сначала включить интеграцию с Application Insights.

По умолчанию данные, собранные из вашего приложения-функции, хранятся в Application Insights. На портале Azure Application Insights предоставляет обширный набор визуализаций ваших данных телеметрии. Вы можете детализировать журналы ошибок и запрашивать события и показатели. В этой статье представлены основные примеры того, как просматривать и запрашивать собранные данные. Дополнительные сведения об исследовании данных приложения-функции в Application Insights см. В разделе Что такое Application Insights ?.

Чтобы узнать больше о хранении данных и возможных затратах на хранение, см. Сбор, хранение и хранение данных в Application Insights.

Просмотр телеметрии на вкладке Монитор

При включенной интеграции Application Insights вы можете просматривать данные телеметрии на вкладке Monitor .

  1. На странице приложения функции выберите функцию, которая запускалась хотя бы один раз после настройки Application Insights. Затем выберите Monitor на левой панели.Периодически выбирайте Refresh , пока не появится список вызовов функций.

    Примечание

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

  2. Чтобы просмотреть журналы для вызова конкретной функции, выберите ссылку столбца Дата (UTC) для этого вызова.Выходные данные регистрации для этого вызова появятся на новой странице.

  3. Выберите Выполнить в Application Insights , чтобы просмотреть источник запроса, который извлекает данные журнала Azure Monitor в журнале Azure. Если вы впервые используете Azure Log Analytics в своей подписке, вам будет предложено включить ее.

  4. После включения Log Analytics отображается следующий запрос. Вы можете видеть, что результаты запроса ограничены последними 30 днями (, где timestamp> ago (30d) ), а результаты показывают не более 20 строк ( занимает 20 ).Напротив, список сведений о вызовах для вашей функции - за последние 30 дней без ограничений.

Дополнительные сведения см. В разделе Запрос данных телеметрии далее в этой статье.

Просмотр телеметрии в Application Insights

Чтобы открыть Application Insights из приложения-функции на портале Azure:

  1. Перейдите к своему функциональному приложению на портале.

  2. Выберите Application Insights в разделе Настройки на левой странице.

  3. Если вы впервые используете Application Insights с подпиской, вам будет предложено включить его. Для этого выберите Включить Application Insights , а затем выберите Применить на следующей странице.

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

Следующие области Application Insights могут быть полезны при оценке поведения, производительности и ошибок в ваших функциях:

Расследование Описание
Отказы Создание диаграмм и предупреждений на основе сбоев функций и исключений сервера. Имя операции - это имя функции. Сбои в зависимостях не отображаются, если вы не реализуете настраиваемую телеметрию для зависимостей.
Производительность Анализируйте проблемы производительности, просматривая использование ресурсов и пропускную способность для экземпляров облачной роли . Эти данные о производительности могут быть полезны для сценариев отладки, в которых функции перегружают ваши базовые ресурсы.
Метрики Создавайте диаграммы и предупреждения, основанные на показателях. Метрики включают количество вызовов функций, время выполнения и процент успешных попыток.
Текущие показатели Просматривайте данные метрик по мере их создания почти в реальном времени.

Запрос данных телеметрии

Application Insights Analytics предоставляет вам доступ ко всем данным телеметрии в виде таблиц в базе данных. Аналитика предоставляет язык запросов для извлечения, обработки и визуализации данных.

Выберите Logs , чтобы просмотреть или запросить зарегистрированные события.

Вот пример запроса, который показывает распределение запросов по работнику за последние 30 минут.

  запросов
| где отметка времени> назад (30 мин)
| суммировать count () по cloud_RoleInstance, bin (timestamp, 1m)
| визуализировать временную диаграмму
  

Доступные таблицы показаны на вкладке Схема слева. Вы можете найти данные, сгенерированные вызовами функций, в следующих таблицах:

Стол Описание
следы Журналы, созданные средой выполнения, контроллером масштабирования, и трассировки кода вашей функции.
запроса Один запрос для каждого вызова функции.
исключения Любые исключения, созданные средой выполнения.
customMetrics Количество успешных и неудачных вызовов, процент успешных попыток и продолжительность.
customEvents События, отслеживаемые средой выполнения, например: HTTP-запросы, запускающие функцию.
Производительность Счетчики Информация о производительности серверов, на которых выполняются функции.

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

В каждой таблице некоторые данные, относящиеся к функциям, находятся в поле customDimensions . Например, следующий запрос извлекает все трассировки с уровнем журнала Ошибка .

  следов
| где customDimensions.LogLevel == "Ошибка"
  

Среда выполнения предоставляет поля customDimensions.LogLevel и customDimensions.Category . Вы можете предоставить дополнительные поля в журналах, которые вы пишете в своем коде функции. Пример на C # см. В разделе «Структурированное ведение журнала» в руководстве разработчика библиотеки классов .NET.

Запрос журналов контроллера масштабирования

Эта функция находится в предварительной версии.

После включения ведения журнала контроллера масштабирования и интеграции с Application Insights можно использовать поиск в журнале Application Insights для запроса отправленных журналов контроллера масштабирования.Журналы контроллера весов сохраняются в коллекции трассировок в категории ScaleControllerLogs .

Для поиска всех журналов контроллера весов для текущего функционального приложения в течение указанного периода времени можно использовать следующий запрос:

  следов
| расширить CustomDimensions = todynamic (tostring (customDimensions))
| где CustomDimensions.Category == "ScaleControllerLogs"
  

Следующий запрос расширяет предыдущий запрос, чтобы показать, как получить только журналы, указывающие на изменение масштаба:

  следов
| расширить CustomDimensions = todynamic (tostring (customDimensions))
| где CustomDimensions.Категория == "ScaleControllerLogs"
| где message == "Количество экземпляров изменено"
| расширить Reason = CustomDimensions.Reason
| расширить PreviousInstanceCount = CustomDimensions.PreviousInstanceCount
| расширить NewInstanceCount = CustomDimensions.CurrentInstanceCount
  

Показатели для плана потребления

При выполнении плана потребления стоимость выполнения одной функции измеряется в ГБ-секунд . Стоимость выполнения рассчитывается путем объединения использования памяти со временем выполнения.Чтобы узнать больше, см. Оценка затрат по плану потребления.

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

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

В разделе Monitoring выберите Logs (Analytics) , затем скопируйте следующий запрос телеметрии, вставьте его в окно запроса и выберите Run . Этот запрос возвращает общее использование памяти в каждый момент выборки.

  счетчики производительности
| где name == "Private Bytes"
| отметка времени проекта, имя, значение
  

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

отметка времени [UTC] название значение
12.09.2019, 1:05:14.947 утра байтов частного пользования 209 932 288 90 482
12.09.2019, 1: 06: 14.994 байтов частного пользования 212 189 184 90 482
12.09.2019, 1: 06: 30.010 AM байтов частного пользования 231 714 816 90 482
12.09.2019, 1: 07: 15.040 AM байтов личного пользования 210,591,744
12.09.2019, 1:12: 16.285 байтов частного пользования 216 285 184 90 482
12.09.2019, 1:12:31.376 утра байтов частного пользования 235 806 720 90 482
Определить продолжительность

Azure Monitor отслеживает метрики на уровне ресурсов, которым для функций является приложение-функция. Интеграция Application Insights генерирует метрики для каждой функции. Вот пример аналитического запроса для получения средней продолжительности функции:

  customMetrics
| где имя содержит "Продолжительность"
| расширить averageDuration = valueSum / valueCount
| суммировать averageDurationMilliseconds = avg (averageDuration) по имени
  
название среднее ПродолжительностьМиллисекунды
QueueTrigger AvgDurationMs 16.087
QueueTrigger MaxDurationMs 90,249
Мин. Длительность триггера очереди, мс 8,522

Следующие шаги

Подробнее о мониторинге функций Azure:

Система телеметрии

- обзор

3.14.2.4 Коммуникационные технологии для медицинских приложений

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

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

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

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

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

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

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

Беспроводные биомедицинские телеметрические системы регулируются Федеральной комиссией по связи США (FCC) и FDA. FCC определяет RF, разрешенные для использования при передаче биомедицинских данных, и разрешенные уровни мощности. FDA определяет устойчивость к электромагнитным помехам (EMI) и требования безопасности терапевтических устройств и связанное с ними телеметрическое взаимодействие на системном уровне.Частоты и уровни мощности являются важными параметрами при разработке системы биомедицинской телеметрии. Количество пользователей и их уровни мощности, наряду с искусственным шумом, могут создавать значительные помехи для определенных диапазонов частот. Это одна из причин, по которой FCC создала защищенные полосы частот специально для биомедицинской телеметрии. К ним относятся беспроводная медицинская телеметрическая система (WMTS) для использования в больнице и служба связи с медицинскими имплантатами (MICS) для имплантируемого использования. В телеметрии, не являющейся критически важной для жизни, часто используются незащищенные промышленные, научные и медицинские (ISM) диапазоны.Медицинская часть диапазона ISM связана с радиодиатермией и другим некоммуникационным использованием RF. Диапазон ISM используется во многих промышленных, коммерческих, научных и домашних целях, что может привести к значительным уровням шума и помех на этих диапазонах (например, беспроводные телефоны, Wi-Fi, Bluetooth).

Беспроводные телеметрические системы для ЭКГ в больницах широко распространены. В настоящее время производимые системы используют полосу частот WMTS. Следующий абзац представляет собой отрывок с веб-сайта FCC WMTS, который достаточно хорошо описывает создание этой полосы частот:

До создания WMTS медицинские телеметрические устройства, как правило, могли работать без лицензии на свободных телевизионных каналах 7– 13 (174–216 МГц) и 14–46 (470–668 МГц) или на лицензированной, но вторичной основе для работы частной наземной подвижной радиосвязи в полосе частот 450–470 МГц.Это означало, что операции беспроводной медицинской телеметрии должны были допускать помехи от основных пользователей этих частотных диапазонов, то есть от телевещательных компаний и лицензиатов частной наземной подвижной радиосвязи. Кроме того, если операция беспроводной медицинской телеметрии вызывает помехи для телевидения или частной наземной мобильной радиопередачи, пользователь оборудования беспроводной медицинской телеметрии будет нести ответственность за устранение проблемы, даже если это означает отключение операции медицинской телеметрии.

Федеральная комиссия по связи была обеспокоена тем, что определенные нормативные изменения, включая появление услуги цифрового телевидения (DTV), приведут к более интенсивному использованию этих частот первичными службами, подвергая операции беспроводной медицинской телеметрии более сильным помехам, чем раньше, и, возможно, исключая такие операции полностью во многих случаях. Чтобы гарантировать, что беспроводные медицинские телеметрические устройства могут работать без вредных помех, FCC решила создать WMTS в Отчете и Распоряжении, выпущенном 12 июня 2000 г. (FCC 2006).

Толчок к изменениям пришелся на середину 2000 года после инцидента в Медицинском центре Университета Бейлора, когда трансляция HDTV на короткое время прервала медицинскую телеметрию в части больницы (Baker 2002). Этот инцидент привел к созданию WMTS Федеральной комиссией по связи, а старые системы были выведены из эксплуатации по причине истощения. Присвоение частот каналам в полосе WMTS по-прежнему осуществляется частотным координатором, чтобы гарантировать, что многократное использование полосы частот в пределах больницы не мешает друг другу.

На имплантируемой стороне беспроводной биомедицинской телеметрии - одно из первых применений имплантируемой телеметрии включало контроль частоты стимуляции имплантируемых кардиостимуляторов. Первоначально управление первыми кардиостимуляторами предполагало прокалывание кожи пациента отверткой специальной заточки для регулировки небольшого потенциометра, заключенного в водонепроницаемое уплотнение из силиконовой резины. К большому удовольствию пациентов, простая двусторонняя телеметрическая система с индуктивно связанной частотой 160–190 кГц заменила отвертку и позволила безболезненно регулировать частоту стимуляции кардиостимулятора.Эта телеметрическая система, работающая на небольшом расстоянии всего в несколько дюймов, изначально использовалась компанией Medtronic Inc., начиная с 1960-х годов. Многие производители медицинских имплантатов до сих пор используют эти индуктивно связанные системы малого радиуса действия.

Имплантируемые телеметрические системы, используемые в настоящее время, превращаются в телеметрию с большим радиусом действия, которая включает использование диапазона MICS от 402 до 405 МГц (почти всемирное распределение), диапазонов ISM 902–928 МГц в США и диапазоны 433 и 868 МГц в Европе.

Полоса частот MICS - это полоса сверхмалой мощности, предназначенная для совместного использования между метеорологическими аэростатами (метеорологическими средствами) и медицинскими имплантируемыми устройствами. Эта полоса обеспечивает лицензирование по правилам и защиту от помех со стороны нелицензированных источников помех. Полосы ISM позволяют использовать более высокие уровни мощности, но должны совместно использовать эти полосы с другими устройствами, работающими с гораздо более эффективными антеннами и гораздо большей мощностью, чем имплантированные системы с батарейным питанием. Из-за потерь тела и ограниченного заряда батареи имплантированные передатчики обычно являются самым слабым звеном в линии телеметрии и требуют тихой, защищенной полосы частот для стабильной и эффективной работы.Для этого FCC создала MICS.

Для внешней связи и носимой на теле внешней медицинской телеметрии, которая предназначена для работы вне медицинских учреждений, варианты более ограничены. В первую очередь, частотные решения представлены в части 15 FCC и диапазонах ISM. Использование этих частотных диапазонов осложняется различными международными правилами радиосвязи, которые имеют разные частоты и уровни мощности между США и Европой.

Добавить комментарий

Ваш адрес email не будет опубликован.

Начните вводить, то что вы ищите выше и нажмите кнопку Enter для поиска. Нажмите кнопку ESC для отмены.

Вернуться наверх