4 Webhook
Descripción general
El tipo de medio webhook es útil para realizar llamadas HTTP utilizando código JavaScript personalizado para una integración sencilla con software externo como sistemas de helpdesk, chats o mensajería. Puede optar por importar una integración proporcionada por Zabbix o crear una integración personalizada desde cero.
Integraciones
Las siguientes integraciones están disponibles, lo que permite utilizar tipos de medios de webhook predefinidos para enviar notificaciones de Zabbix a:
- brevis.one
- Discord
- Event-Driven Ansible
- Express.ms messenger
- GitHub
- GLPi
- iLert
- iTop
- Jira
- Jira Service Management
- ManageEngine ServiceDesk
- Mantis Bug Tracker
- Mattermost
- MS Teams
- MS Teams Workflows
- LINE
- Opsgenie
- OTRS CE
- Pagerduty
- Pushover
- Redmine
- Rocket.Chat
- ServiceNow
- SIGNL4
- Slack
- SolarWinds
- SysAid
- Telegram
- TOPdesk
- VictorOps
- Zammad
- Zendesk
Además de los servicios listados aquí, Zabbix puede integrarse con Spiceworks (no se requiere webhook). Para convertir las notificaciones de Zabbix en tickets de Spiceworks, cree un tipo de medio de correo electrónico e introduzca la dirección de correo electrónico de la mesa de ayuda de Spiceworks (por ejemplo, help\@zabbix.on.spiceworks.com) en la configuración de perfil de un usuario de Zabbix designado.
Configuración
Para empezar a utilizar una integración de webhook:
- Localice el archivo .yaml requerido en el directorio
templates/mediade la versión de Zabbix descargada o descárguelo del repositorio git de Zabbix. - Importe el archivo en su instalación de Zabbix. El webhook aparecerá en la lista de tipos de medios.
- Configure el webhook siguiendo las instrucciones del archivo Readme.md (puede hacer clic en el nombre del webhook arriba para acceder rápidamente al Readme.md).
Para crear un webhook personalizado desde cero:
- Vaya a Alertas > Tipos de medios.
- Haga clic en Crear tipo de medio.
La pestaña Tipo de medio contiene varios atributos específicos para este tipo de medio:

Todos los campos obligatorios están marcados con un asterisco rojo.
Los siguientes parámetros son específicos para el tipo de medio webhook:
| Parámetro | Descripción |
|---|---|
| Parámetros | Especifique las variables del webhook como pares de atributo y valor. Para los webhooks preconfigurados, la lista de parámetros varía según el servicio. Consulte el archivo Readme.md del webhook para la descripción de los parámetros. Para los nuevos webhooks, se incluyen por defecto varias variables comunes (URL:<vacío>, HTTPProxy:<vacío>, To:{ALERT.SENDTO}, Subject:{ALERT.SUBJECT}, Message:{ALERT.MESSAGE}), puede mantenerlas o eliminarlas. Los parámetros del webhook admiten macros de usuario, todas las macros que se admiten en las notificaciones de problemas y, adicionalmente, las macros {ALERT.SENDTO}, {ALERT.SUBJECT} y {ALERT.MESSAGE}. Si especifica un proxy HTTP, el campo admite la misma funcionalidad que en el campo de configuración del item HTTP proxy. La cadena del proxy puede ir precedida de [scheme]:// para especificar el tipo de proxy que se utiliza (por ejemplo, https, socks4, socks5; consulte la documentación). |
| Script | Introduzca el código JavaScript en el editor modal que se abre al hacer clic en el campo de parámetro o en el icono de lápiz junto a él. Este código realizará la operación del webhook. El script es un código de función que acepta pares de parámetros y valores. Los valores deben convertirse en objetos JSON utilizando el método JSON.parse(), por ejemplo: var params = JSON.parse(value);.El código tiene acceso a todos los parámetros, puede realizar peticiones HTTP GET, POST, PUT y DELETE, admitir métodos adicionales como CONNECT, PATCH, HEAD, OPTIONS y TRACE, y tiene control sobre las cabeceras HTTP y el cuerpo de la petición. El script debe contener un operador return, de lo contrario no será válido. Puede devolver el estado OK junto con una lista opcional de etiquetas y valores de etiquetas (ver opción Procesar etiquetas) o una cadena de error. Los eventos de recuperación (ya sea generados automáticamente o como resultado de un cierre manual) son creados por el server e incluyen las etiquetas de evento resueltas (incluyendo etiquetas heredadas de templates, hosts y triggers). Los scripts de webhook se ejecutan después de que se crea la alerta; por lo tanto, las etiquetas devueltas por un script de webhook se añaden sólo después de la creación inicial de la alerta y no estarán presentes en las macros {EVENT.TAGS} y {EVENT.RECOVERY.TAGS} del mensaje inicial de problema o del mensaje de recuperación inmediato.Nota: Se recomienda utilizar variables locales (por ejemplo, var local = 1) en lugar de globales (por ejemplo, global = 1) para garantizar que cada script opere sobre sus propios datos y evitar colisiones entre llamadas simultáneas (ver problemas conocidos).Consulte también: Guía de desarrollo de webhooks, Ejemplos de scripts de webhook, Objetos JavaScript adicionales. |
| Timeout | Tiempo de espera de ejecución de JavaScript (1-60s, por defecto 30s). Se admiten sufijos de tiempo, por ejemplo, 30s, 1m. |
| Procesar etiquetas | Marque la casilla para procesar los valores de las propiedades JSON devueltas como etiquetas. Estas etiquetas se añaden a las etiquetas de problema existentes. Tenga en cuenta que al utilizar etiquetas de webhook, el webhook debe devolver un objeto JSON que contenga al menos un objeto de etiquetas vacío: var result = {tags: {}};Ejemplos de etiquetas que se pueden devolver: jira-id:prod-1234, responsable:John Smith, procesado:<sin valor> |
| Incluir entrada en el menú de eventos | Marque la casilla para incluir una entrada en el menú de eventos que enlace a un ticket externo creado. Se incluirá una entrada para cada webhook que esté habilitado y tenga marcada esta casilla. Tenga en cuenta que si los parámetros Nombre de la entrada del menú y URL de la entrada del menú contienen alguna macro {EVENT.TAGS.<tag name>}, sólo se incluirá una entrada si estas macros pueden resolverse (es decir, el evento tiene estas etiquetas definidas). Si se marca, el webhook no debe utilizarse para enviar notificaciones a diferentes usuarios (considere crear un usuario dedicado en su lugar) y no debe utilizarse en múltiples acciones de alerta para un solo evento de problema. |
| Nombre de la entrada del menú | Especifique el nombre de la entrada del menú. Se admite la macro {EVENT.TAGS.<tag name>}. Este campo sólo es obligatorio si se marca Incluir entrada en el menú de eventos. |
| URL de la entrada del menú | Especifique la URL subyacente de la entrada del menú. Se admite la macro {EVENT.TAGS.<tag name>}. Este campo sólo es obligatorio si se marca Incluir entrada en el menú de eventos. |
Consulte parámetros comunes de tipo de medio para obtener detalles sobre cómo configurar los mensajes por defecto y las opciones de procesamiento de alertas.
Incluso si un webhook no utiliza mensajes por defecto, aún deben definirse las plantillas de mensajes para los tipos de operación utilizados por este webhook.
Pruebas
Para probar un tipo de medio webhook configurado:
- Localice el webhook relevante en la lista de tipos de medios.
- Haga clic en Probar en la última columna de la lista (se abrirá una ventana de prueba).
- Edite los valores de los parámetros del webhook según sea necesario. Reemplace las macros por valores de ejemplo; de lo contrario, las macros no se resolverán y la prueba fallará.
- Haga clic en Probar.
Reemplazar o eliminar valores en la ventana de prueba afecta solo al procedimiento de prueba; los valores reales de los atributos del webhook permanecerán sin cambios.

Para ver las entradas del registro de pruebas del tipo de medio sin salir de la ventana de prueba, haga clic en Abrir registro (se abrirá una nueva ventana emergente).

Si la prueba del webhook es exitosa:
- Se muestra el mensaje "Prueba de tipo de medio exitosa.".
- La respuesta del servidor aparece en el campo gris Respuesta.
- El tipo de respuesta (JSON o Cadena) se especifica debajo del campo Respuesta.
Si la prueba del webhook falla:
- Se muestra el mensaje "La prueba del tipo de medio falló.", seguido de detalles adicionales sobre el fallo.
Medios de usuario
Una vez que el tipo de medio esté configurado, vaya a la sección Usuarios > Usuarios y asigne el medio webhook a un usuario existente o cree un nuevo usuario para representar el webhook. Los pasos para configurar medios de usuario para un usuario existente, siendo comunes para todos los tipos de medios, se describen en la página Tipos de medios.
Si un webhook utiliza etiquetas para almacenar el ID de ticket\mensaje, evite asignar el mismo webhook como medio a diferentes usuarios, ya que hacerlo puede causar errores en el webhook (esto aplica a la mayoría de los webhooks que utilizan la opción Incluir entrada en el menú de eventos). En este caso, la mejor práctica es crear un usuario dedicado para representar el webhook:
- Después de configurar el tipo de medio webhook, vaya a la sección Usuarios > Usuarios y cree un usuario Zabbix dedicado para representar el webhook, por ejemplo, con el nombre de usuario Slack para el webhook de Slack. Todas las configuraciones, excepto los medios, pueden dejarse con sus valores predeterminados, ya que este usuario no iniciará sesión en Zabbix.
- En el perfil del usuario, vaya a la pestaña Medios y agregue un webhook con la información de contacto requerida. Si el webhook no utiliza un campo Enviar a, introduzca cualquier combinación de caracteres admitidos para evitar los requisitos de validación.
- Conceda a este usuario al menos permisos de lectura permisos a todos los equipos para los que deba enviar las alertas.
Al configurar una acción de alerta, agregue este usuario en el campo Enviar a usuarios en los detalles de la operación; esto indicará a Zabbix que utilice el webhook para las notificaciones de esta acción.
Configuración de acciones de alerta
Las acciones determinan qué notificaciones deben enviarse a través del webhook. Los pasos para configurar acciones que involucren webhooks son los mismos que para todos los demás tipos de medios, con estas excepciones:
- Si un webhook utiliza etiquetas de webhook para almacenar el ID de ticket\mensaje y gestionar operaciones de actualización\resolución, evite usar el mismo webhook en múltiples acciones de alerta para un solo evento de problema. Si {EVENT.TAGS.<nombre de etiqueta>} existe y se actualiza en el webhook, su valor resultante será indefinido. Para evitar esto, utilice un nuevo nombre de etiqueta en el webhook para almacenar los valores actualizados. Esto se aplica a los webhooks de Jira, Jira Service Desk, Mattermost, Opsgenie, OTRS, Redmine, ServiceNow, Slack, Zammad y Zendesk proporcionados por Zabbix y a la mayoría de los webhooks que utilizan la opción Incluir entrada de menú de evento. Sin embargo, tenga en cuenta que un solo webhook puede usarse en múltiples operaciones o pasos de escalamiento de la misma acción, así como en diferentes acciones que no se activarán por el mismo evento de problema debido a diferentes condiciones.
- Al usar un webhook en acciones para eventos internos, asegúrese de marcar la casilla Mensaje personalizado y definir un mensaje personalizado en la configuración de la operación de la acción. De lo contrario, no se enviará una notificación.