btpd
API

btp_configure

  • path - полный путь к файлу конфигурации

Создает и конфигурирует клиента к btp. Конфигурация в формате JSON. Эта функция должна быть вызвана первой.

btp_create_meter

  • script - имя скрипта (может быть "" )
  • service - имя сервиса
  • server - имя сервера
  • op - операция
  • count - количество операций (count на графиках) за измеряемый промежуток времени (Опционально, по умолчанию 1)
  • write_size - размер входных данных (в попугаях) либо размер json-запроса в байтах (Опционально, по умолчанию 0)
  • Возвращает
    - возвращает идентификатор измерителя (таймера)
    Создает объект для измерения времени обработки запроса к внешним системам или длительной операции. По завершению операции идентификатор, который вернул этот метод, нужно передать в btp_release_meter. Интервал между вызовами этих функций будет отображаться на графиках в перцентелях. Если название метрики определяется только в конце измеряемого интервала, то нужно использовать аналогичную пару btp_create_meter2 btp_release_meter2

Если за измеряемый интервал времени было произведено несколько операций, то их количество передаем в параметре count (зеленый график в бтп). Не имеет особого смысла использовать эту возможность для оптимизации сетевого траффика, так так текущая реализация умеет производить агрегацию данных аналогично серверу бтп. Можно вызвать в цикле миллион раз пару btp_create_meter - btp_release_meter, данные отправятся на сервер уже в агрегированном (компактом) состоянии только при финальном автоматическом вызове btp_pushout после завершения работы скрипта.

При замере запросов к JSONRPC-демонам или другим внешним системам, в параметре write_size можно передать размер запроса в байтах. Если этот параметр не нулевой, то будет создан еще один график с именем операции op:write (op название операции) где в перцентилях будут показаны размеры (например в размер байтах запроса JSONRPC к демону), а count будет дублировать основной count (число запросов), тогда по галочке "мощность" можно будет отсортировать скрипты по траффику. В конфигурации можно задать, чтобы эти графики размеров отправлялись на отдельный сервер бтп. Так же будет создан график op:traff (не реализовано) аналогичный op:write, но на графике count будет суммарный траффик за интервал (например на минутном графике это суммарный трафик за минуту)

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

Для замера входящего трафика (размеры ответов на запросы) значения передаются в btp_release_meter параметром read_size (к моменту вызова этого метода вы уже знаете размер ответа на запрос)

При вызове btp_create_meter("script1", "service1", "server1", "op1") будут созданы три метрики (как и раньше):

script~~script1~~service1~~server1~~op1
service~~service1~~server1~~op1
service~~service1~~op1

Если первым параметром передать пустую строку btp_create_meter("", "service1", "server1", "op1") (без скрипта), то две:

service~~service1~~server1~~op1
service~~service1~~op1

Такой формат нужен только для корректного отображения списка доступных графиков на http://btp.stat1.lan/, но сам сервер не налагает ограничений на формат ключей. Для отправки в произвольном формате ключа первые три параметра нужно задать пустой строкой:

btp_create_meter("", "", "", "любое имя")

Для работы с ключами произвольного формата нужен отдельный инстанс сервера БТП и клиент который может с ним работать. Недопустимо в таком формате отправлять данные на сервер с графиками с которым заработает http://btp.stat1.lan/

Если задан ненулевой параметр write_size то будут автоматом созданы еще шесть метрик:

script~~script1~~service1~~server1~~op1:write
service~~service1~~server1~~op1:write
service~~service1~~op1:write
script~~script1~~service1~~server1~~op1:traff
service~~service1~~server1~~op1:traff
service~~service1~~op1:traff

А если задан ненулевой параметр read_size в btp_release_meter то еще три:

script~~script1~~service1~~server1~~op1:read
service~~service1~~server1~~op1:read
service~~service1~~op1:read

При этом если write_size==0, а read_size!=0 то метрики **:traff*** также будут созданы. Как видно, что если так делать как в предыдущей версии расширения то, потенциально, трафик может увеличиться в четыре раза (а на самом деле и более), но в данном решении:

  • Первичная агрегация производится на клиенте
  • JSON-объекты передаются в виде JSON-массивов (имена полей не передаются, но визуальная читабельность сохраняется)
  • Специальным образом производится упаковка имен, т.е вместо script~~script1~~service1~~server1~~op1:read передаем 1~2~3~4~5, а легенда в отдельном массиве ["script","script1","service1","server1","op1:read"] для всех метрик в пакете, где очень много дублирующихся сущностей
  • Метрики с размерами отправляем на отдельный сервер

btp_create_meter2

  • count - количество операций (count на графиках) за измеряемый промежуток времени (Опционально, по умолчанию 1)
  • write_size - размер входных данных (в попугаях) либо размер json-запроса в байтах (Опционально, по умолчанию 0)
  • Возвращает
    - возвращает идентификатор измерителя (таймера) Создает безымянный объект для измерения времени, имена задаються в btp_release_meter2. Работает аналогично btp_create_meter, но не принимает имена для метрики (они будут заданы btp_release_meter2)

btp_release_meter

  • id - идентификатор измерителя, который был получен при создании btp_create_meter
  • read_size - размер выходных данных (в попугаях) либо размер json-ответа на запрос в байтах (Опционально, по умолчанию 0)

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

btp_release_meter2

  • id - идентификатор измерителя, который был получен при создании btp_create_meter2
  • script - имя скрипта (может быть "" )
  • service - имя сервиса
  • server - имя сервера
  • op - операция
  • read_size - размер выходных данных (в попугаях) либо размер json-ответа на запрос в байтах (Опционально, по умолчанию 0)

Завершает измерение временного интервала, задает имена и записывает результат в соответствующие метрики. Данные не отправляются на сервер до вызова btp_pushout, а также могут быть специальным образом агрегированы. Работает аналогично btp_release_meter, но принимает имена для метрики, т.е. на момент вызова btp_create_meter2 они еще небыли известны

btp_pushout

Отправляет все данные на сервер одним или несколькими пакетами udp. Вызывается автоматически при завершении работы скрипта.

btp_add_time, btp_add_size, btp_add_value

  • script - имя скрипта (может быть "" )
  • service - имя сервиса
  • server - имя сервера
  • op - операция
  • value - интервал времени, размер или произвольное значение
  • count - количество операций (count на графиках)

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

  • btp_add_time - в параметре value нужно передавать интервал времени в микросекундах. Данные для основного сервера БТП
  • btp_add_size - в параметре value размер в попугаях. На графиках count - суммарный размер за интервал, в перцентилях - размеры в попугаях. Данные для размерного сервера БТП
  • btp_add_value - аналогично btp_add_size, но параметр в count число операций (как и в обычных графиках)