Differences

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

--- сервис_zabbix [2025/11/27 08:25]
val [Создание своих шаблонов]
+++ сервис_zabbix [2026/04/17 15:16] (current)
val [Настройка уведомлений о событиях]
@@ Line 269: / Line 269: @@
   Report problems to Zabbix administrators->Enable
   ...
+</code>
+=== Настройка уведомлений о срабатывании сервиса ===
+<code>
+Configuration/Alerts->Actions->Service actions
+  Name: Mail Action
+  Conditions: Service equals Corp Mail
+  Operations: Send message to user groups: Zabbix administrators via all media
+  Recovery operations: Notify all involved
 </code>
@@ Line 282: / Line 291: @@
   * [[Сервис OpenFire]] Настройка DNS, Установка, Spark
-  * [[Сервис OpenFire#bash xmpp]]
 <code>
@@ Line 290: / Line 299: @@
 # cat /var/lib/zabbix/.sendxmpprc
-admin@corpX.un Pa$$w0rd
+</code>
+  * [[Сервис OpenFire#bash xmpp]]
+<code>
 # chmod 600 /var/lib/zabbix/.sendxmpprc
@@ Line 301: / Line 313: @@
 logger -t zabbix_xmpp -p local0.info "$1, $2, $3"
+#echo "$(date) $1, $2, $3" >>/tmp/zabbix_xmpp.txt
 to=$1
@@ Line 306: / Line 320: @@
 body=$3
-cat <<EOF | sendxmpp -f /var/lib/zabbix/.sendxmpprc -s "$subject" "$to"
+cat <<EOF | sendxmpp -f /var/lib/zabbix/.sendxmpprc "$to"
+$subject
 $body
 EOF
 </code><code>
-Administration->Media types->Create media type
+Administration/Alerts->Media types->Create media type
   Name: XMPP
   Type: Script
@@ Line 319: / Line 335: @@
     {ALERT.MESSAGE}
   Message teplates
-    Problem
+    Service
-    Problem recovery
+    Service recovery
-    Problem update
+    Service update
 </code>
 <code>
-Administration->Users->student->Media
+Administration->Users->Admin->Media
   Type: XMPP
-  Send to: student@corpX.un
+  Send to: user1@corpX.un
 </code>
@@ Line 695: / Line 711: @@
 </code>
 ==== Вычисляемые элементы ====
+  * [[https://www.zabbix.com/documentation/current/en/manual/config/items/itemtypes/calculated/aggregate]]
 <code>
@@ Line 723: / Line 741: @@
 last(openvpn1:openvpn.server.clients)+last(openvpn2:openvpn.server.clients)+last(openvpn3:openvpn.server.clients)
+#---------------------
+sum(last_foreach(/*/active_meetings.sh["{HOST.CONN}"]?[group="webinars"]))
 </code>
 ==== Web сценарии ====
@@ Line 1564: / Line 1588: @@
 server.corp1.un:~# /root/zab_set_map_name.sh 2 "ISP 1"
 </code>
+===== zabbix Services sla best practice именования tag =====
+В 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` | Какие сервисы включить в отчет |

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

User Tools

Site Tools

Differences

Page Tools