Differences

This shows you the differences between two versions of the page.

--- сервис_zabbix [2026/02/11 11:58]
val [Вычисляемые элементы]
+++ сервис_zabbix [2026/04/15 16:24] (current)
val
@@ Line 1571: / Line 1571: @@
 </code><code>
 server.corp1.un:~# /root/zab_set_map_name.sh 2 "ISP 1"
+</code>
+===== zabbix Services sla best practice именования tag =====
+<code>
+В Zabbix существует два основных типа тегов, которые критически важны для корректной работы SLA, и их часто путают. Ниже представлена лучшая практика именования для каждого типа, основанная на опыте сообщества и официальной документации.
+### 1. Теги проблем (Problem Tags) — Связь Триггера и Сервиса
+Это теги, которые вы добавляете в **Trigger**. Когда триггер срабатывает, Zabbix смотрит на эти теги, чтобы понять, к какому именно Service (Сервису) относится проблема .
+**Главное правило**: Тег должен уникально идентифицировать конкретный экземпляр сервиса (например, конкретный веб-сервер или БД), чтобы вы могли рассчитывать SLA для каждого компонента отдельно .
+*   **Имя тега**: Используйте осмысленное имя, например `problem_tag`, `service` или `target`. Избегайте общих названий вроде `tag`.
+*   **Значение тега**: Лучшая практика — использовать макрос `{HOST.NAME}` в комбинации с именем приложения. Это автоматически создаст уникальный идентификатор при клонировании триггеров на разные хосты.
+**Пример именования:**
+> **Имя:** `service`
+> **Значение:** `{HOST.NAME}_nginx`
+*   *Результат:* Для хоста `web01` тег превратится в `web01_nginx`. Для хоста `db01` тег превратится в `db01_postgres` .
+### 2. Теги сервиса (Service Tags) — Связь Сервиса и SLA
+Это теги, которые вы добавляете в конфигурацию **Service** (в дереве Services > Services). Они нужны для того, чтобы движок SLA знал, какие сервисы включать в отчет .
+**Главное правило**: Используйте бизнес-классификацию, а не технические детали. Тег должен отвечать на вопрос: "К какому бизнес-домену или команде относится этот сервис?" .
+**Пример именования:**
+*   **Имя:** `SLA_Scope`
+*   **Значение:** `Critical_Payment_System`
+*   **Имя:** `Team`
+*   **Значение:** `Backend_API`
+### 3. Механизм наследования и фильтрации (Best Practice End-to-End)
+Лучший способ построения архитектуры — цепочка: **Trigger (Problem Tag)** -> **Service (Problem Tags match)** -> **Service (Service Tag)** -> **SLA (Service Tags match)**.
+Вот пошаговый пример того, как настроить SLA для приложения "CRM":
+.  **На триггере (Trigger):**
+    *   `problem_tag`: `{HOST.NAME}_crm_app`
+.  **На дочернем сервисе (Child Service) — например, "CRM_Web_01":**
+    *   *Вкладка Problem Tags:* Имя `problem_tag`, Значение `web01_crm_app` (чтобы поймать проблему).
+    *   *Вкладка Tags:* Имя `application`, Значение `crm` .
+.  **На родительском сервисе (Parent Service) — например, "CRM System":**
+    *   *Вкладка Tags:* Имя `application`, Значение `crm` (тег наследуется или прописывается явно).
+.  **В конфигурации SLA отчета:**
+    *   *Вкладка Service tags:* Имя `application`, Значение `crm` .
+### 4. Ключевые правила и ограничения
+.  **Регистр символов:** Имена и значения тегов чувствительны к регистру (`PROBLEM` != `problem`). Выберите один формат (например, `snake_case` или `lowercase`) и придерживайтесь его везде .
+.  **Уникальность для SLA:** Если вы хотите, чтобы downtime одного сервера не валил весь SLA, убедитесь, что значения тегов проблем для разных хостов уникальны (используйте `{HOST.NAME}`). Если вы хотите считать SLA для кластера в целом (например, "хотя бы один из трех жив"), делайте тег общим .
+.  **Стандартизация названий:** Избегайте пробелов и спецсимволов. Рекомендуемый формат: `category:subcategory` или `scope:value` (например, `env:production`, `tier:critical`). Это облегчает фильтрацию в Grafana или через API .
+### Итоговая схема (Cheat Sheet)
+| Сущность | Поле | Best Practice Значение | Назначение |
+| :--- | :--- | :--- | :--- |
+| **Trigger** | Имя Tag | `service` | Тип проверки |
+| **Trigger** | Значение | `{HOST.NAME}_nginx` | Связка "хост + роль" |
+| **Service** | Problem Tags | Имя:`service` Знач:`web01_nginx` | Какой триггер слушать |
+| **Service** | Service Tags | Имя:`app` Знач:`frontend` | Для группировки в отчете |
+| **SLA** | Service Tags | Имя:`app` Знач:`frontend` | Какие сервисы включить в отчет |
 </code>

Методические материалы Лохтурова Вячеслава

User Tools

Site Tools

Differences

Page Tools