Сколько форматов баннеров в RTB-трафике

Универсальная классификация рекламных форматов баннеров

• баннеры-башни (Towers);
• баннеры-квадраты (Squares);
• баннеры-перетяжки (Leaderboards).

Нажмите, если формула не отображается.

$\$\$display\$\$\backslash begin\{equation\}\; k\_\{i\}=\backslash left(\backslash frac\{3\}\{4\}\backslash right)^\{i\},\; i=-2,-1,0,1,2.\; \backslash end\{equation\}\$\$display\$\$$

Нажмите, если формула не отображается

Как устроены адаптивные баннеры AdWords

• для класса Tower: Tower 1 и Tower 2 (визуально различаются только используемыми шрифтами, поэтому далее не будем выделять Tower 2 отдельно);
• для класса Square: Square 1, Square 2, Square 3, Square 4;
• для класса Leaderboard: Leaderboard 1 (пример — на первом рисунке в статье), Leaderboard 2, Leaderboard 3.

Обработка результатов наблюдений

• Площадь рекламного блока $$;
• Угол наклона $$;
• Ширина $$;
• Высота $$.

Нажмите, если формулы не отображаются

template_names = ['leaderboard1', 'leaderboard2', 'leaderboard3', 'square1', 'square2', 'square3', 'square4', 'tower1'];
function getTemplate(w, h) {
  var wdh = w/h,
    wh = w*h;
  if (wdh >= 0.7000456) {
    if (wdh >= 2.499373) {
      if (wh >= 32399) {
        if (wdh >= 4.501131) {
          return template_names[0]; //leaderboard1 - bannerA
        } else {
          return template_names[1]; //leaderboard2 - bannerB
        }
      };
      return template_names[2]; //leaderboard3 - smallBanner
    } else {
      if (wdh < 1.200121) {
        if (wdh >= 0.8999545) {
          if (w < 781.5) {
            if (wh < 32399.5) {
              return template_names[5];// "square3"; //smallSquare
            } else {
              return template_names[6];//"square4"; //square191
            }
          } else {
            if (wdh >= 0.9995005) {
              return template_names[5];//"square3"; //smallSquare
            } else {
              return template_names[7];//"tower1"; //towerB
            }
          }
        } else {
          if (wh < 32399) {
              return template_names[5]; //"square3"; //smallSquare
          } else {
              return template_names[4]; //"square2"; //squareC
          }
        }
      } else {
        if (h< 174.5) {
          if (wdh >= 2.002874 && wh >= 32392.5) {
            return template_names[1];//"leaderboard2"; //bannerB
          }
          return template_names[5];//"square3"; //smallSquare
        } else {
          if (w < 601.5 && wdh < 1.531339) {
              return template_names[3];//"square1"; //squareA
          }
          return template_names[4];//"square2"; //squareC
        }
      }
    }
  } else {
      return template_names[7];//"tower1"; //towerA + towerB
  }
}

и визуализацией сырых измерений.

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

Визуализация сырых результатов измерений

Схематичное представление шаблонов

Шаблоны из класса Leaderboard

	Leaderboard 1 для рекламного блока 480x70
	Leaderboard 2 для рекламного блока 400x125
	Leaderboard 3 для рекламного блока 400x100. Показан второй кадр с описанием

Шаблоны из класса Square

Square 1 для рекламного блока 300x300	Square 2 для рекламного блока 150x215	Square 3 для рекламного блока 215x250	Square 4 для рекламного блока 250x250

Шаблоны из класса Tower

Реализации шаблона Tower

Использование мультиформатного баннера в RTB

Заключение

Сколько форматов баннеров в RTB-трафике

Универсальная классификация рекламных форматов баннеров

• баннеры-башни (Towers);
• баннеры-квадраты (Squares);
• баннеры-перетяжки (Leaderboards).

Нажмите, если формула не отображается.

$\$\$display\$\$\backslash begin\{equation\}\; k\_\{i\}=\backslash left(\backslash frac\{3\}\{4\}\backslash right)^\{i\},\; i=-2,-1,0,1,2.\; \backslash end\{equation\}\$\$display\$\$$

Нажмите, если формула не отображается

Как устроены адаптивные баннеры AdWords

• для класса Tower: Tower 1 и Tower 2 (визуально различаются только используемыми шрифтами, поэтому далее не будем выделять Tower 2 отдельно);
• для класса Square: Square 1, Square 2, Square 3, Square 4;
• для класса Leaderboard: Leaderboard 1 (пример — на первом рисунке в статье), Leaderboard 2, Leaderboard 3.

Обработка результатов наблюдений

• Площадь рекламного блока $$;
• Угол наклона $$;
• Ширина $$;
• Высота $$.

Нажмите, если формулы не отображаются

template_names = ['leaderboard1', 'leaderboard2', 'leaderboard3', 'square1', 'square2', 'square3', 'square4', 'tower1'];
function getTemplate(w, h) {
  var wdh = w/h,
    wh = w*h;
  if (wdh >= 0.7000456) {
    if (wdh >= 2.499373) {
      if (wh >= 32399) {
        if (wdh >= 4.501131) {
          return template_names[0]; //leaderboard1 - bannerA
        } else {
          return template_names[1]; //leaderboard2 - bannerB
        }
      };
      return template_names[2]; //leaderboard3 - smallBanner
    } else {
      if (wdh < 1.200121) {
        if (wdh >= 0.8999545) {
          if (w < 781.5) {
            if (wh < 32399.5) {
              return template_names[5];// "square3"; //smallSquare
            } else {
              return template_names[6];//"square4"; //square191
            }
          } else {
            if (wdh >= 0.9995005) {
              return template_names[5];//"square3"; //smallSquare
            } else {
              return template_names[7];//"tower1"; //towerB
            }
          }
        } else {
          if (wh < 32399) {
              return template_names[5]; //"square3"; //smallSquare
          } else {
              return template_names[4]; //"square2"; //squareC
          }
        }
      } else {
        if (h< 174.5) {
          if (wdh >= 2.002874 && wh >= 32392.5) {
            return template_names[1];//"leaderboard2"; //bannerB
          }
          return template_names[5];//"square3"; //smallSquare
        } else {
          if (w < 601.5 && wdh < 1.531339) {
              return template_names[3];//"square1"; //squareA
          }
          return template_names[4];//"square2"; //squareC
        }
      }
    }
  } else {
      return template_names[7];//"tower1"; //towerA + towerB
  }
}

и визуализацией сырых измерений.

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

Визуализация сырых результатов измерений

Схематичное представление шаблонов

Шаблоны из класса Leaderboard

	Leaderboard 1 для рекламного блока 480x70
	Leaderboard 2 для рекламного блока 400x125
	Leaderboard 3 для рекламного блока 400x100. Показан второй кадр с описанием

Шаблоны из класса Square

Square 1 для рекламного блока 300x300	Square 2 для рекламного блока 150x215	Square 3 для рекламного блока 215x250	Square 4 для рекламного блока 250x250

Шаблоны из класса Tower

Реализации шаблона Tower

Использование мультиформатного баннера в RTB

Заключение

Сколько форматов баннеров в RTB-трафике

Универсальная классификация рекламных форматов баннеров

• баннеры-башни (Towers);
• баннеры-квадраты (Squares);
• баннеры-перетяжки (Leaderboards).

Нажмите, если формула не отображается.

$\$\$display\$\$\backslash begin\{equation\}\; k\_\{i\}=\backslash left(\backslash frac\{3\}\{4\}\backslash right)^\{i\},\; i=-2,-1,0,1,2.\; \backslash end\{equation\}\$\$display\$\$$

Нажмите, если формула не отображается

Как устроены адаптивные баннеры AdWords

• для класса Tower: Tower 1 и Tower 2 (визуально различаются только используемыми шрифтами, поэтому далее не будем выделять Tower 2 отдельно);
• для класса Square: Square 1, Square 2, Square 3, Square 4;
• для класса Leaderboard: Leaderboard 1 (пример — на первом рисунке в статье), Leaderboard 2, Leaderboard 3.

Обработка результатов наблюдений

• Площадь рекламного блока $$;
• Угол наклона $$;
• Ширина $$;
• Высота $$.

Нажмите, если формулы не отображаются

template_names = ['leaderboard1', 'leaderboard2', 'leaderboard3', 'square1', 'square2', 'square3', 'square4', 'tower1'];
function getTemplate(w, h) {
  var wdh = w/h,
    wh = w*h;
  if (wdh >= 0.7000456) {
    if (wdh >= 2.499373) {
      if (wh >= 32399) {
        if (wdh >= 4.501131) {
          return template_names[0]; //leaderboard1 - bannerA
        } else {
          return template_names[1]; //leaderboard2 - bannerB
        }
      };
      return template_names[2]; //leaderboard3 - smallBanner
    } else {
      if (wdh < 1.200121) {
        if (wdh >= 0.8999545) {
          if (w < 781.5) {
            if (wh < 32399.5) {
              return template_names[5];// "square3"; //smallSquare
            } else {
              return template_names[6];//"square4"; //square191
            }
          } else {
            if (wdh >= 0.9995005) {
              return template_names[5];//"square3"; //smallSquare
            } else {
              return template_names[7];//"tower1"; //towerB
            }
          }
        } else {
          if (wh < 32399) {
              return template_names[5]; //"square3"; //smallSquare
          } else {
              return template_names[4]; //"square2"; //squareC
          }
        }
      } else {
        if (h< 174.5) {
          if (wdh >= 2.002874 && wh >= 32392.5) {
            return template_names[1];//"leaderboard2"; //bannerB
          }
          return template_names[5];//"square3"; //smallSquare
        } else {
          if (w < 601.5 && wdh < 1.531339) {
              return template_names[3];//"square1"; //squareA
          }
          return template_names[4];//"square2"; //squareC
        }
      }
    }
  } else {
      return template_names[7];//"tower1"; //towerA + towerB
  }
}

и визуализацией сырых измерений.

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

Визуализация сырых результатов измерений

Схематичное представление шаблонов

Шаблоны из класса Leaderboard

	Leaderboard 1 для рекламного блока 480x70
	Leaderboard 2 для рекламного блока 400x125
	Leaderboard 3 для рекламного блока 400x100. Показан второй кадр с описанием

Шаблоны из класса Square

Square 1 для рекламного блока 300x300	Square 2 для рекламного блока 150x215	Square 3 для рекламного блока 215x250	Square 4 для рекламного блока 250x250

Шаблоны из класса Tower

Реализации шаблона Tower

Использование мультиформатного баннера в RTB

Заключение

Сколько форматов баннеров в RTB-трафике

Универсальная классификация рекламных форматов баннеров

• баннеры-башни (Towers);
• баннеры-квадраты (Squares);
• баннеры-перетяжки (Leaderboards).

Нажмите, если формула не отображается.

$\$\$display\$\$\backslash begin\{equation\}\; k\_\{i\}=\backslash left(\backslash frac\{3\}\{4\}\backslash right)^\{i\},\; i=-2,-1,0,1,2.\; \backslash end\{equation\}\$\$display\$\$$

Нажмите, если формула не отображается

Как устроены адаптивные баннеры AdWords

• для класса Tower: Tower 1 и Tower 2 (визуально различаются только используемыми шрифтами, поэтому далее не будем выделять Tower 2 отдельно);
• для класса Square: Square 1, Square 2, Square 3, Square 4;
• для класса Leaderboard: Leaderboard 1 (пример — на первом рисунке в статье), Leaderboard 2, Leaderboard 3.

Обработка результатов наблюдений

• Площадь рекламного блока $$;
• Угол наклона $$;
• Ширина $$;
• Высота $$.

Нажмите, если формулы не отображаются

template_names = ['leaderboard1', 'leaderboard2', 'leaderboard3', 'square1', 'square2', 'square3', 'square4', 'tower1'];
function getTemplate(w, h) {
  var wdh = w/h,
    wh = w*h;
  if (wdh >= 0.7000456) {
    if (wdh >= 2.499373) {
      if (wh >= 32399) {
        if (wdh >= 4.501131) {
          return template_names[0]; //leaderboard1 - bannerA
        } else {
          return template_names[1]; //leaderboard2 - bannerB
        }
      };
      return template_names[2]; //leaderboard3 - smallBanner
    } else {
      if (wdh < 1.200121) {
        if (wdh >= 0.8999545) {
          if (w < 781.5) {
            if (wh < 32399.5) {
              return template_names[5];// "square3"; //smallSquare
            } else {
              return template_names[6];//"square4"; //square191
            }
          } else {
            if (wdh >= 0.9995005) {
              return template_names[5];//"square3"; //smallSquare
            } else {
              return template_names[7];//"tower1"; //towerB
            }
          }
        } else {
          if (wh < 32399) {
              return template_names[5]; //"square3"; //smallSquare
          } else {
              return template_names[4]; //"square2"; //squareC
          }
        }
      } else {
        if (h< 174.5) {
          if (wdh >= 2.002874 && wh >= 32392.5) {
            return template_names[1];//"leaderboard2"; //bannerB
          }
          return template_names[5];//"square3"; //smallSquare
        } else {
          if (w < 601.5 && wdh < 1.531339) {
              return template_names[3];//"square1"; //squareA
          }
          return template_names[4];//"square2"; //squareC
        }
      }
    }
  } else {
      return template_names[7];//"tower1"; //towerA + towerB
  }
}

и визуализацией сырых измерений.

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

Визуализация сырых результатов измерений

Схематичное представление шаблонов

Шаблоны из класса Leaderboard

	Leaderboard 1 для рекламного блока 480x70
	Leaderboard 2 для рекламного блока 400x125
	Leaderboard 3 для рекламного блока 400x100. Показан второй кадр с описанием

Шаблоны из класса Square

Square 1 для рекламного блока 300x300	Square 2 для рекламного блока 150x215	Square 3 для рекламного блока 215x250	Square 4 для рекламного блока 250x250

Шаблоны из класса Tower

Реализации шаблона Tower

Использование мультиформатного баннера в RTB

Заключение

Введение

Расширение бизнеса

1. Документация для регистрации в налоговой;
2. Документация для открытия расчетного счета (обязательно, если это ООО);
3. Круглая печать;
4. Электронная подпись для сдачи отчетности;

«Начать может и один человек, без лицензии»

1. Покупка межсетевого экрана и его настройка;
2. Покупка антивируса;
3. Покупка охранного оборудования;
4. Ежемесячные затраты на охрану;

Осуществление предпринимательской деятельности без специального разрешения (лицензии), если такое разрешение (такая лицензия) обязательно (обязательна), — влечет наложение административного штрафа:

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

Мы будем просто передавать документы

Постановление Правительства РФ от 16.04.2012 N 313 (ред. от 18.05.2017)

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

22. Передача защищенных с использованием шифровальных (криптографических) средств информационных систем.

23. Передача защищенных с использованием шифровальных (криптографических) средств телекоммуникационных систем.

24. Передача средств изготовления ключевых документов.

С Вами говорит ФСБ

1. Да, лицензия нужна;
2. Для ее получения нам необходимо обучить всего одного человека;
3. Необходимые виды деятельности для работы с УЦ "*******" в качестве партнера — 21, 22, 23, 24;

Предпринимателям

• сбор всех данных за раз, полученных в JSON от консольной утилиты счетчика электроэнергии Меркурий 236
• сбор показателей S.M.A.R.T. жестких дисков и SSD, полученных в табличном виде от smartmontools.

А в чем была собственно проблема?

• медленные запуски утилит каждый раз, на каждый нужный элемент данных
• обращение к ресурсу (диск, порт, счетчик, API приложения) на каждый элемент данных
• парсинг результата нужно было делать внешними скриптами/утилитами
• а если потом нужно было поправить парсинг – приходилось опять обновлять UserParameters или скрипты
• кроме всего прочего, одновременные запросы от нескольких Zabbix pollers приводили к ошибке при обращении, например, к последовательному порту.

• В Zabbix 3.4 источником данных может выступать другой элемент данных, который называется родительским или мастер-элементом. Такой элемент может, например, содержать массив данных в формате JSON, XML или фривольном текстовом формате.
• В момент поступления новых данных в родительский элемент, остальные элементы данных, которые называются зависимыми, обращаются к родительскому элементу и при помощи таких функций препроцессинга как JSON path, XPath или Regex выделяют из текста нужную метрику.

Меркурий 236

{
                "U": {
                               "p1": 0.35,
                               "p2": 0.35,
                               "p3": 226.86
                },
                "I": {
                               "p1": 0.00,
                               "p2": 0.00,
                               "p3": 0.39
                },
                "CosF": {
                               "p1": 0.00,
                               "p2": 0.00,
                               "p3": 0.60,
                               "sum": 0.60
                },
                "F": 50.00,
                "A": {
                               "p1": 41943.03,
                               "p2": 41943.03,
                               "p3": 41943.03
                },
                "P": {
                               "p1": 0.00,
                               "p2": 0.00,
                               "p3": 53.45,
                               "sum": 53.45
                },
                "S": {
                               "p1": 0.00,
                               "p2": 0.00,
                               "p3": 89.83,
                               "sum": 89.83
                },
                "PR": {
                               "ap": 120.51
                },
                "PR-day": {
                               "ap": 86.00
                },
                "PR-night": {
                               "ap": 34.51
                },
                "PY": {
                               "ap": 0.00
                },
                "PT": {
                               "ap": 0.04
                }
}

Настроим запуск утилиты mercury236 из Zabbix

UserParameter=mercury236[],/etc/zabbix/scripts/mercury236 $1 $2

Настроим получение наших метрик счетчика

• Тип: Зависимый элемент данных
• Основной элемент данных: mercury-get

• Тип: Зависимый элемент данных
• Основной элемент данных: mercury-get

• будем использовать нотацию с квадратными скобками, так как в пути JSON есть дефис
• препроцессинг может быть многошаговым, например здесь результата первого шага умножим на 1000, чтобы получить Вт*ч из кВт*ч

Доведем наш шаблон до ума

Что получилось

• переиспользовали хорошую программку и не тратили время на написание своей реализации сбора данных по протоколу Меркурий
• UserParameter остался, но схлопнулся до простого вызова. По сути можно даже system.run[] использовать
• cкрипты-обертки тоже не писали. Всё распарсили через JSON path в шаблоне
• cчетчик не мучали сильно, один запрос – все нужные нам данные разом.

Smartctl и smartmontools

• избыточные запуски утилиты smartctl, а она в свою очередь каждый раз обращалась к контроллеру жесткого диска
• пришлось делать отдельный парсинг для Linux и Windows. Особенно больно с этим сейчас работать в Win: (for /F… так… экранируем двойные кавычки еще кавычками…. Аааа!!!!)

• smartctl нам JSON не возвращает
• дисков в сервере может быть различное количество, поэтому нам нужно использовать низкоуровневое обнаружение(LLD).

Упрощаем UserParameters

UserParameter=uHDD[], sudo smartctl -A $1| grep -i "$2"| tail -1| cut -c 88-|cut -f1 -d' '
UserParameter=uHDD.model.[],sudo smartctl -i $1 |grep -i "Device Model"| cut -f2 -d: |tr -d " "
UserParameter=uHDD.sn.[],sudo smartctl -i $1 |grep -i "Serial Number"| cut -f2 -d: |tr -d " "
UserParameter=uHDD.health.[],sudo smartctl -H $1 |grep -i "test"| cut -f2 -d: |tr -d " "
UserParameter=uHDD.errorlog.[],sudo smartctl -l error $1 |grep -i "ATA Error Count"| cut -f2 -d: |tr -d " "
UserParameter=uHDD.discovery,sudo /etc/zabbix/scripts/smartctl-disks-discovery.pl

UserParameter=uHDD.A[],sudo smartctl -A $1
UserParameter=uHDD.i[],sudo smartctl -i $1
UserParameter=uHDD.health[],sudo smartctl -H $1
UserParameter=uHDD.discovery,sudo /etc/zabbix/scripts/smartctl-disks-discovery.pl

Создаем новые родительские элементы данных

• uHDD.i["{#DISKNAME}"]
• uHDD.health["{#DISKNAME}"]

Настроим получение наших атрибутов S.M.A.R.T. диска

Тестируем, смотрим что получилось

• мы убрали весь парсинг из UserParameters
• нет внешних скриптов (кроме LLD), нет внешних зависимостей, весь парсинг происходит на Zabbix-сервере, там его легко посмотреть и подправить, если нужно
• когда утилита или API не возвращает XML/JSON – не беда, всегда можно попробовать использовать регулярные выражения
• жесткие диски больше не мучаем – сначала достаем весь список параметров S.M.A.R.T., а затем уже на Zabbix-сервере раскладываем его по метрикам.

В завершении

• сбор всех данных за раз, полученных в JSON от консольной утилиты счетчика электроэнергии Меркурий 236
• сбор показателей S.M.A.R.T. жестких дисков и SSD, полученных в табличном виде от smartmontools.

А в чем была собственно проблема?

• медленные запуски утилит каждый раз, на каждый нужный элемент данных
• обращение к ресурсу (диск, порт, счетчик, API приложения) на каждый элемент данных
• парсинг результата нужно было делать внешними скриптами/утилитами
• а если потом нужно было поправить парсинг – приходилось опять обновлять UserParameters или скрипты
• кроме всего прочего, одновременные запросы от нескольких Zabbix pollers приводили к ошибке при обращении, например, к последовательному порту.

• В Zabbix 3.4 источником данных может выступать другой элемент данных, который называется родительским или мастер-элементом. Такой элемент может, например, содержать массив данных в формате JSON, XML или фривольном текстовом формате.
• В момент поступления новых данных в родительский элемент, остальные элементы данных, которые называются зависимыми, обращаются к родительскому элементу и при помощи таких функций препроцессинга как JSON path, XPath или Regex выделяют из текста нужную метрику.

Меркурий 236

{
                "U": {
                               "p1": 0.35,
                               "p2": 0.35,
                               "p3": 226.86
                },
                "I": {
                               "p1": 0.00,
                               "p2": 0.00,
                               "p3": 0.39
                },
                "CosF": {
                               "p1": 0.00,
                               "p2": 0.00,
                               "p3": 0.60,
                               "sum": 0.60
                },
                "F": 50.00,
                "A": {
                               "p1": 41943.03,
                               "p2": 41943.03,
                               "p3": 41943.03
                },
                "P": {
                               "p1": 0.00,
                               "p2": 0.00,
                               "p3": 53.45,
                               "sum": 53.45
                },
                "S": {
                               "p1": 0.00,
                               "p2": 0.00,
                               "p3": 89.83,
                               "sum": 89.83
                },
                "PR": {
                               "ap": 120.51
                },
                "PR-day": {
                               "ap": 86.00
                },
                "PR-night": {
                               "ap": 34.51
                },
                "PY": {
                               "ap": 0.00
                },
                "PT": {
                               "ap": 0.04
                }
}

Настроим запуск утилиты mercury236 из Zabbix

UserParameter=mercury236[],/etc/zabbix/scripts/mercury236 $1 $2

Настроим получение наших метрик счетчика

• Тип: Зависимый элемент данных
• Основной элемент данных: mercury-get

• Тип: Зависимый элемент данных
• Основной элемент данных: mercury-get

• будем использовать нотацию с квадратными скобками, так как в пути JSON есть дефис
• препроцессинг может быть многошаговым, например здесь результата первого шага умножим на 1000, чтобы получить Вт*ч из кВт*ч

Доведем наш шаблон до ума

Что получилось

• переиспользовали хорошую программку и не тратили время на написание своей реализации сбора данных по протоколу Меркурий
• UserParameter остался, но схлопнулся до простого вызова. По сути можно даже system.run[] использовать
• cкрипты-обертки тоже не писали. Всё распарсили через JSON path в шаблоне
• cчетчик не мучали сильно, один запрос – все нужные нам данные разом.

Smartctl и smartmontools

• избыточные запуски утилиты smartctl, а она в свою очередь каждый раз обращалась к контроллеру жесткого диска
• пришлось делать отдельный парсинг для Linux и Windows. Особенно больно с этим сейчас работать в Win: (for /F… так… экранируем двойные кавычки еще кавычками…. Аааа!!!!)

• smartctl нам JSON не возвращает
• дисков в сервере может быть различное количество, поэтому нам нужно использовать низкоуровневое обнаружение(LLD).

Упрощаем UserParameters

UserParameter=uHDD[], sudo smartctl -A $1| grep -i "$2"| tail -1| cut -c 88-|cut -f1 -d' '
UserParameter=uHDD.model.[],sudo smartctl -i $1 |grep -i "Device Model"| cut -f2 -d: |tr -d " "
UserParameter=uHDD.sn.[],sudo smartctl -i $1 |grep -i "Serial Number"| cut -f2 -d: |tr -d " "
UserParameter=uHDD.health.[],sudo smartctl -H $1 |grep -i "test"| cut -f2 -d: |tr -d " "
UserParameter=uHDD.errorlog.[],sudo smartctl -l error $1 |grep -i "ATA Error Count"| cut -f2 -d: |tr -d " "
UserParameter=uHDD.discovery,sudo /etc/zabbix/scripts/smartctl-disks-discovery.pl

UserParameter=uHDD.A[],sudo smartctl -A $1
UserParameter=uHDD.i[],sudo smartctl -i $1
UserParameter=uHDD.health[],sudo smartctl -H $1
UserParameter=uHDD.discovery,sudo /etc/zabbix/scripts/smartctl-disks-discovery.pl

Создаем новые родительские элементы данных

• uHDD.i["{#DISKNAME}"]
• uHDD.health["{#DISKNAME}"]

Настроим получение наших атрибутов S.M.A.R.T. диска

Тестируем, смотрим что получилось

• мы убрали весь парсинг из UserParameters
• нет внешних скриптов (кроме LLD), нет внешних зависимостей, весь парсинг происходит на Zabbix-сервере, там его легко посмотреть и подправить, если нужно
• когда утилита или API не возвращает XML/JSON – не беда, всегда можно попробовать использовать регулярные выражения
• жесткие диски больше не мучаем – сначала достаем весь список параметров S.M.A.R.T., а затем уже на Zabbix-сервере раскладываем его по метрикам.

В завершении

• сбор всех данных за раз, полученных в JSON от консольной утилиты счетчика электроэнергии Меркурий 236
• сбор показателей S.M.A.R.T. жестких дисков и SSD, полученных в табличном виде от smartmontools.

А в чем была собственно проблема?

• медленные запуски утилит каждый раз, на каждый нужный элемент данных
• обращение к ресурсу (диск, порт, счетчик, API приложения) на каждый элемент данных
• парсинг результата нужно было делать внешними скриптами/утилитами
• а если потом нужно было поправить парсинг – приходилось опять обновлять UserParameters или скрипты
• кроме всего прочего, одновременные запросы от нескольких Zabbix pollers приводили к ошибке при обращении, например, к последовательному порту.

• В Zabbix 3.4 источником данных может выступать другой элемент данных, который называется родительским или мастер-элементом. Такой элемент может, например, содержать массив данных в формате JSON, XML или фривольном текстовом формате.
• В момент поступления новых данных в родительский элемент, остальные элементы данных, которые называются зависимыми, обращаются к родительскому элементу и при помощи таких функций препроцессинга как JSON path, XPath или Regex выделяют из текста нужную метрику.

Меркурий 236

{
                "U": {
                               "p1": 0.35,
                               "p2": 0.35,
                               "p3": 226.86
                },
                "I": {
                               "p1": 0.00,
                               "p2": 0.00,
                               "p3": 0.39
                },
                "CosF": {
                               "p1": 0.00,
                               "p2": 0.00,
                               "p3": 0.60,
                               "sum": 0.60
                },
                "F": 50.00,
                "A": {
                               "p1": 41943.03,
                               "p2": 41943.03,
                               "p3": 41943.03
                },
                "P": {
                               "p1": 0.00,
                               "p2": 0.00,
                               "p3": 53.45,
                               "sum": 53.45
                },
                "S": {
                               "p1": 0.00,
                               "p2": 0.00,
                               "p3": 89.83,
                               "sum": 89.83
                },
                "PR": {
                               "ap": 120.51
                },
                "PR-day": {
                               "ap": 86.00
                },
                "PR-night": {
                               "ap": 34.51
                },
                "PY": {
                               "ap": 0.00
                },
                "PT": {
                               "ap": 0.04
                }
}

Настроим запуск утилиты mercury236 из Zabbix

UserParameter=mercury236[],/etc/zabbix/scripts/mercury236 $1 $2

Настроим получение наших метрик счетчика

• Тип: Зависимый элемент данных
• Основной элемент данных: mercury-get

• Тип: Зависимый элемент данных
• Основной элемент данных: mercury-get

• будем использовать нотацию с квадратными скобками, так как в пути JSON есть дефис
• препроцессинг может быть многошаговым, например здесь результата первого шага умножим на 1000, чтобы получить Вт*ч из кВт*ч

Доведем наш шаблон до ума

Что получилось

• переиспользовали хорошую программку и не тратили время на написание своей реализации сбора данных по протоколу Меркурий
• UserParameter остался, но схлопнулся до простого вызова. По сути можно даже system.run[] использовать
• cкрипты-обертки тоже не писали. Всё распарсили через JSON path в шаблоне
• cчетчик не мучали сильно, один запрос – все нужные нам данные разом.

Smartctl и smartmontools

• избыточные запуски утилиты smartctl, а она в свою очередь каждый раз обращалась к контроллеру жесткого диска
• пришлось делать отдельный парсинг для Linux и Windows. Особенно больно с этим сейчас работать в Win: (for /F… так… экранируем двойные кавычки еще кавычками…. Аааа!!!!)

• smartctl нам JSON не возвращает
• дисков в сервере может быть различное количество, поэтому нам нужно использовать низкоуровневое обнаружение(LLD).

Упрощаем UserParameters

UserParameter=uHDD[], sudo smartctl -A $1| grep -i "$2"| tail -1| cut -c 88-|cut -f1 -d' '
UserParameter=uHDD.model.[],sudo smartctl -i $1 |grep -i "Device Model"| cut -f2 -d: |tr -d " "
UserParameter=uHDD.sn.[],sudo smartctl -i $1 |grep -i "Serial Number"| cut -f2 -d: |tr -d " "
UserParameter=uHDD.health.[],sudo smartctl -H $1 |grep -i "test"| cut -f2 -d: |tr -d " "
UserParameter=uHDD.errorlog.[],sudo smartctl -l error $1 |grep -i "ATA Error Count"| cut -f2 -d: |tr -d " "
UserParameter=uHDD.discovery,sudo /etc/zabbix/scripts/smartctl-disks-discovery.pl

UserParameter=uHDD.A[],sudo smartctl -A $1
UserParameter=uHDD.i[],sudo smartctl -i $1
UserParameter=uHDD.health[],sudo smartctl -H $1
UserParameter=uHDD.discovery,sudo /etc/zabbix/scripts/smartctl-disks-discovery.pl

Создаем новые родительские элементы данных

• uHDD.i["{#DISKNAME}"]
• uHDD.health["{#DISKNAME}"]

Настроим получение наших атрибутов S.M.A.R.T. диска

Тестируем, смотрим что получилось

• мы убрали весь парсинг из UserParameters
• нет внешних скриптов (кроме LLD), нет внешних зависимостей, весь парсинг происходит на Zabbix-сервере, там его легко посмотреть и подправить, если нужно
• когда утилита или API не возвращает XML/JSON – не беда, всегда можно попробовать использовать регулярные выражения
• жесткие диски больше не мучаем – сначала достаем весь список параметров S.M.A.R.T., а затем уже на Zabbix-сервере раскладываем его по метрикам.

В завершении

• сбор всех данных за раз, полученных в JSON от консольной утилиты счетчика электроэнергии Меркурий 236
• сбор показателей S.M.A.R.T. жестких дисков и SSD, полученных в табличном виде от smartmontools.

А в чем была собственно проблема?

• медленные запуски утилит каждый раз, на каждый нужный элемент данных
• обращение к ресурсу (диск, порт, счетчик, API приложения) на каждый элемент данных
• парсинг результата нужно было делать внешними скриптами/утилитами
• а если потом нужно было поправить парсинг – приходилось опять обновлять UserParameters или скрипты
• кроме всего прочего, одновременные запросы от нескольких Zabbix pollers приводили к ошибке при обращении, например, к последовательному порту.

• В Zabbix 3.4 источником данных может выступать другой элемент данных, который называется родительским или мастер-элементом. Такой элемент может, например, содержать массив данных в формате JSON, XML или фривольном текстовом формате.
• В момент поступления новых данных в родительский элемент, остальные элементы данных, которые называются зависимыми, обращаются к родительскому элементу и при помощи таких функций препроцессинга как JSON path, XPath или Regex выделяют из текста нужную метрику.

Меркурий 236

{
                "U": {
                               "p1": 0.35,
                               "p2": 0.35,
                               "p3": 226.86
                },
                "I": {
                               "p1": 0.00,
                               "p2": 0.00,
                               "p3": 0.39
                },
                "CosF": {
                               "p1": 0.00,
                               "p2": 0.00,
                               "p3": 0.60,
                               "sum": 0.60
                },
                "F": 50.00,
                "A": {
                               "p1": 41943.03,
                               "p2": 41943.03,
                               "p3": 41943.03
                },
                "P": {
                               "p1": 0.00,
                               "p2": 0.00,
                               "p3": 53.45,
                               "sum": 53.45
                },
                "S": {
                               "p1": 0.00,
                               "p2": 0.00,
                               "p3": 89.83,
                               "sum": 89.83
                },
                "PR": {
                               "ap": 120.51
                },
                "PR-day": {
                               "ap": 86.00
                },
                "PR-night": {
                               "ap": 34.51
                },
                "PY": {
                               "ap": 0.00
                },
                "PT": {
                               "ap": 0.04
                }
}

Настроим запуск утилиты mercury236 из Zabbix

UserParameter=mercury236[],/etc/zabbix/scripts/mercury236 $1 $2

Настроим получение наших метрик счетчика

• Тип: Зависимый элемент данных
• Основной элемент данных: mercury-get

• Тип: Зависимый элемент данных
• Основной элемент данных: mercury-get

• будем использовать нотацию с квадратными скобками, так как в пути JSON есть дефис
• препроцессинг может быть многошаговым, например здесь результата первого шага умножим на 1000, чтобы получить Вт*ч из кВт*ч

Доведем наш шаблон до ума

Что получилось

• переиспользовали хорошую программку и не тратили время на написание своей реализации сбора данных по протоколу Меркурий
• UserParameter остался, но схлопнулся до простого вызова. По сути можно даже system.run[] использовать
• cкрипты-обертки тоже не писали. Всё распарсили через JSON path в шаблоне
• cчетчик не мучали сильно, один запрос – все нужные нам данные разом.

Smartctl и smartmontools

• избыточные запуски утилиты smartctl, а она в свою очередь каждый раз обращалась к контроллеру жесткого диска
• пришлось делать отдельный парсинг для Linux и Windows. Особенно больно с этим сейчас работать в Win: (for /F… так… экранируем двойные кавычки еще кавычками…. Аааа!!!!)

• smartctl нам JSON не возвращает
• дисков в сервере может быть различное количество, поэтому нам нужно использовать низкоуровневое обнаружение(LLD).

Упрощаем UserParameters

UserParameter=uHDD[], sudo smartctl -A $1| grep -i "$2"| tail -1| cut -c 88-|cut -f1 -d' '
UserParameter=uHDD.model.[],sudo smartctl -i $1 |grep -i "Device Model"| cut -f2 -d: |tr -d " "
UserParameter=uHDD.sn.[],sudo smartctl -i $1 |grep -i "Serial Number"| cut -f2 -d: |tr -d " "
UserParameter=uHDD.health.[],sudo smartctl -H $1 |grep -i "test"| cut -f2 -d: |tr -d " "
UserParameter=uHDD.errorlog.[],sudo smartctl -l error $1 |grep -i "ATA Error Count"| cut -f2 -d: |tr -d " "
UserParameter=uHDD.discovery,sudo /etc/zabbix/scripts/smartctl-disks-discovery.pl

UserParameter=uHDD.A[],sudo smartctl -A $1
UserParameter=uHDD.i[],sudo smartctl -i $1
UserParameter=uHDD.health[],sudo smartctl -H $1
UserParameter=uHDD.discovery,sudo /etc/zabbix/scripts/smartctl-disks-discovery.pl

Создаем новые родительские элементы данных

• uHDD.i["{#DISKNAME}"]
• uHDD.health["{#DISKNAME}"]

Настроим получение наших атрибутов S.M.A.R.T. диска

Тестируем, смотрим что получилось

• мы убрали весь парсинг из UserParameters
• нет внешних скриптов (кроме LLD), нет внешних зависимостей, весь парсинг происходит на Zabbix-сервере, там его легко посмотреть и подправить, если нужно
• когда утилита или API не возвращает XML/JSON – не беда, всегда можно попробовать использовать регулярные выражения
• жесткие диски больше не мучаем – сначала достаем весь список параметров S.M.A.R.T., а затем уже на Zabbix-сервере раскладываем его по метрикам.

В завершении

Portainer

• Сайт; GitHub; Gitter.
• Лицензия: Open Source (zlib License и другие).
• ОС: Linux, Mac OS X, Windows.
• Языки/платформа: Go, JavaScript (Angular).
• Демо-версия (admin / tryportainer).

Kitematic (Docker Toolbox)

• Сайт (+ страница Docker Toolbox); GitHub; форум.
• Лицензия: Open Source (Apache License 2.0).
• ОС: Mac OS X, Windows.
• Языки/платформа: Electron, Node.js, React и AltJS.

Shipyard

• Сайт; GitHub.
• Лицензия: Open Source (Apache License 2.0).
• ОС: Linux, Mac OS X.
• Языки/платформа: Go, Node.js.

DockStation

• Сайт; GitHub (без исходного кода).
• Лицензия: проприетарная.
• ОС: Linux, Mac OS X, Windows.
• Языки/платформа: Electron (Chromium, Node.js).

Simple Docker UI

• GitHub.
• Лицензия: Open Source (MIT License).
• ОС: Linux, Mac OS X, Windows.
• Языки/платформа: Electron, Scala.js (+ React on Scala.js).

Другие варианты

• Rancher — платформа управления контейнерами, обладающая функциями оркестровки и поддержкой Kubernetes. Open Source (Apache License 2.0); работает в Linux; написана на Java. Имеет веб-интерфейс Rancher UI на Node.js.
• Data Pulley — простая утилита, имеющая минимум функций и документации. Open Source (MIT License); работает в Linux (имеется только пакет для Ubuntu); написана на Python. Поддерживает Docker Hub для образов, просмотр логов для контейнеров.
• Panamax — проект, задававшийся целью «сделать деплой сложных контейнеризированных приложений таким простым, как drag-n-drop». Для этого был создан свой каталог шаблонов для деплоя приложений (Panamax Public Templates), результаты из которого показываются при поиске образов/приложений наравне с данными из Docker Hub. Open Source (Apache License 2.0); работает в Linux, Mac OS X, Windows; написан на Ruby. Интегрирован с ОС CoreOS и системой для оркестровки Fleet. Судя по видимой в интернете активности, перестал поддерживаться в 2015 году.
• Dockly — консольный графический интерфейс для управления контейнерами и образами Docker. Open Source (MIT License); написан на JavaScript/Node.js.

Напоследок: как же выглядит GUI в Dockly? Осторожно, GIF на 3,4 Мб!

P.S.

• «Шпаргалка с командами Docker».
• «Play with Docker — онлайн-сервис для практического знакомства с Docker».
• «Vulnerable Docker VM — виртуалка-головоломка по Docker и pentesting».