Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in / Register
  • N noc
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 441
    • Issues 441
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 27
    • Merge requests 27
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Container Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • External wiki
    • External wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • noc
  • noc
  • Issues
  • #1498
Closed
Open
Issue created Jan 22, 2021 by Dmitry Volodin@dvOwner

Labels

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

  • Теги не структурированы и создаются as-is.
  • Теги не группируются.
  • Пользователь может создать произвольный тег.
  • У тегов отсутсвует назначение, все теги равноправны.
  • Теги глобальны, нет возможность ограничить область экспозиции тега (например - pm, datastream).
  • У тегов отсутсвует описание, оно должно храниться где-то во внешней документации.
  • Теги, импортированые через ETL могут пересекаться и иметь разную семантику.
  • Все теги в UI представлены одинаково, нет различия по форме и цвету. Визуальные анализ длинной сосиски с тегами может быть затруднен.
  • Механизм стекирования тегов неявный. Не описаны, например, правила сложения тегов из объекта и профиля.
  • Справочник тегов неявный. Для поддержания имеющегося справочника тегов используется отдельный криптический обработчик при сохранении.

Предлагаемое решение

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

  • Метки являются отдельной сущностью в базе (first class citizen)
  • Метки могут иметь ограниченную область применения (например, быть привязаны к проекту).
  • Метки не создаются автоматически.
  • Метки могут иметь разные стили оформления.
  • Метки могут иметь отдельное описание.
  • Метки могут быть объединены во взаимоисключающие группы (scoped labels), когда может быть назначена только одна метка из группы.

Предлагается создать отдельный справочник Label вида:

  • name - уникальное имя
  • description - описание
  • fg_color1 - цвет шрифта 1-го элемента
  • bg_color1 - цвет фона 1-го элемента
  • fg_color2 - цвет шрифта 2-го элемента
  • bg_color2 - цвет фона 2-го элемента
  • remote_system - ссылка на внешнюю систему (для импортированых меток)
  • remote_id - id или название тега во внешней системе
  • enable_agent - Метка может быть применена для агента
  • enable_agent_profile - метка может быть применена для профиля агента
  • enable_service - Метка может быть применена для сервиса
  • enable_service_profile - метка может быть применена для профиля сервиса
  • enable_worflow - метка может быть использована в worflow
  • enable_worflow_state - метка может быть использована в состоянии worflow
  • expose_datastream - показывать метку в datastream
  • expose_metric - включать метку в метрики
  • expose_alarm - включать метку в аварии
  • expose_managed_object - включать метку в объект
  • expose_interface - включать метку в интерфейс

Ссылка на метки осуществляется по уникальному имени.

Scoped Labels - группа меток, из которых только одна может быть активна в данный момент. Части в scoped labels разделяются символом ::. scope могут быть вложенными (несколько разделителей).

Примеры:

  • mylabel - простая метка
  • myscope::mylabel - метка mylabel в scope myscope
  • myscope1::myscope2::mylabel - метка mylabel в scope myscope1::myscope2.

Для добавления меток к модели используются два поля:

  • labels - список строк - метки, привязанные к объекту непосредственно
  • effective_labels - полный эффективный список метрик (включая унаследованные из профиля)

Эффективные метки

Строятся в порядке приоритета (вхождение слева более приоритетно). Для scoped labels остается только первое вхождение из scope.

Сущность Порядок заимствования меток Признак заимствования
Agent Agent, Agent Profile
Service Service, Service Profile, Service Parent
Коллектор агента Service, Agent expose_metric
Administrative Domain Administrative Domain, Administrative Domain Parent
Managed Object Managed Object, Managed Object Profile, Administative Domain expose_managed_object
Alarm Alarm, Interface, Managed Object expose_alarm
Interface Interface, Interface Profile, Managed Object expose_interface

Передача тегов

В PM

В метрики агента попадают только эффективные метки с признаком expose_metric. Коллектор агента использует метки агента и сервиса, metrics discovery - метки объекта и интерфейса

В Аварии

В аварии попадают только эффективные метки с признаком expose_alarm

В datastream

В аварии попадают только эффективные метки с признаком expose_datastream

Edited Jan 23, 2021 by Dmitry Volodin
Assignee
Assign to
Time tracking