Ad Widget

Collapse

правильная структура шаблонов

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • d00m178
    Junior Member
    • Jun 2016
    • 12

    #1

    правильная структура шаблонов

    всем привет.

    нужна помощь в формировании правильной структуры для шаблонов.
    ситуация такая - есть несколько серверов.
    например:
    s1 s2 s3 ...

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

    app1: port 101
    app2 : port 102
    ...
    app10 : port 110

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

    http://s1:101/metrics выведет JSON с метриками, например:

    metric1 : value
    metric2 : value
    и т.д..

    сейчас у меня есть самодельные шаблоны для сервисов, типа:
    template service 101
    template service 102 и так далее.
    в каждом из них есть item который проверяет жив ли этот сервис - net.tcp.service[tcp,,101] и триггер на эту проверку.
    таким образом я добавляю этот шаблон на свои сервера s1-s3 и мониторю состояние этих портов.
    то есть десяток шаблонов уже добавил для этого.

    дальше, чтобы снимать значения метрик, у меня на сервере есть питон скрипт который получает имя метрики и отдает значение, например:
    # script.py metric1
    12345
    этот скрипт указан в UserParameters в конфиге агента.

    сделал еще один шаблон для метрик, в котором есть item-ы для каждой нужной метрики: key == script[имя_метрики].
    вот эти items и получают значения метрик.
    получается, что мне для каждого сервиса надо создавать кучу items для этих метрик, хотя key будет практически одинаковый для всех метрик и всех портов.

    и тут возникает проблема - не добавить такой шаблон на другие хосты, так как Template cannot be linked to another template more than once even through other templates.

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

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

    в общем такой сложно-запутанный вопрос.. как лучше структурировать такие шаблоны, мож кто подскажет..
  • Semiadmin
    Senior Member
    • Oct 2014
    • 1625

    #2
    Привет.
    Вопрос автообнаружения метрик на форуме неоднократно обсуждался. Это против концепции Zabbix, но теоретически возможно.
    Графики строиться будут, но как создать прототип триггера для всего этого многообразия? Разве что с самыми общими функциями типа nodata или diff.
    Что бы делал я в вашем случае:
    1. Сделал бы шаблон, применяемый к каждому серверу s. В нем LLD, находящее сервисы - пара макросов для app и port(или URL).
    Как их искать - парсинг некоего списка, вывода netstat или еще как - отдельный вопрос.
    2. Вероятно, есть некий исчерпывающий список возможных метрик. Если нет - постарался бы его составить. Если есть числовые и текстовые метрики, разделил бы на 2 списка.
    3. Экспортировал бы шаблон в xml. При помощи, например, awk распарсил бы этот список и сделал фрагмент xml-файла шаблона, отвечающий за прототипы айтемов в LLD, содержащий прототипы для всех возможных метрик. Добавил бы этот фрагмент в xml шаблона, импортировал.
    Т.к. на хосте (s) будет несколько сервисов (app) с одинаковыми метриками (metric), ключ прототипа айтема придется сделать сложным, напр. script[{#URL},metric], имя - {#APP} metric. Вероятно, придется скорректировать питоновский скрипт.
    4. Применил бы шаблон к хостам. После того, как все заработает, массово отключил бы все айтемы, оказавшиеся неподдерживаемыми (если, конечно, выполнение питоновского скрипта для отсутствующей в json метрики приводит к этому результату).
    В 3.2 это легко сделать через веб-интерфейс, в более ранней версии попробовал бы через API.

    Comment

    Working...