Notifications via Jira

This is a machine translation based on the English version of the article. It might or might not have already been subject to text preparation. If you find errors, please file a GitHub issue that states the paragraph that has to be improved.

1. Introduction

Si vous utilisez le logiciel Jira pour la gestion de projets, le développement logiciel ou le suivi des bogues, avec les éditions commerciales, vous pouvez envoyer des notifications depuis Checkmk vers Jira et y créer ou mettre à jour des tickets. Cette fonctionnalité est disponible pour les produits Jira Work Management (anciennement Jira Core), Jira Software et Jira Service Management (anciennement Jira Service Desk).

Les options suivantes sont prises en charge :

Créer des tickets pour les problèmes d'ordinateur hôte et de service.
Créer des tickets avec une priorité définie.
Créer des tickets avec une étiquette définie.
Définir des liens vers les ordinateurs hôtes/services dans Checkmk à partir des tickets Jira générés.
Définir une résolution dans le ticket lorsque les conditions d'OKs sont remplies.

Pour configurer la connexion entre Checkmk et Jira, créez d'abord de nouveaux champs dans Jira et définissez des identifiants Jira.

Configurez ensuite la méthode de notification pour Jira dans Checkmk, en saisissant les identifiants Jira qui ont été créés et lues. Vous gagnerez en flexibilité si vous utilisez également des attributs utilisateur personnalisés. Au lieu de saisir les identifiants Jira directement dans la méthode de notification, vous pouvez définir certains identifiants Jira en tant qu’attributs utilisateur personnalisés. Cela permet aux utilisateurs individuels de créer facilement des tickets dans divers projets JIRA.

2. Configuration de Jira

Lorsqu’il interagit avec Jira, Checkmk doit savoir quelles notifications ont déjà donné lieu à la création d’un ticket et lesquelles ne l’ont pas fait. Pour ce faire, vous devez créer deux champs dits « personnalisés » dans Jira : l’un pour les notifications relatives aux tickets d’ordinateurs hôtes, et l’autre pour les tickets de service.

Afin de pouvoir identifier correctement les tickets d’hôte et de service, les identifiants de ces tickets doivent être uniques. C’est le cas si votre instance Jira ne reçoit des notifications que d’un seul site Checkmk, car le noyau de supervision d’un site Checkmk garantit l’unicité. Or, dans le cadre d’une supervision distribuée, plusieurs sites Checkmk peuvent envoyer des notifications si la configuration des notifications décentralisées a été activée. Si votre instance Jira reçoit des notifications provenant de plusieurs sites Checkmk, l’unicité est très probablement compromise — au plus tard lorsque l’ID d’un ticket d’ordinateur hôte a déjà été utilisé par un autre site Checkmk. Dans une telle configuration, vous avez besoin d’un autre champ personnalisé pour le site Checkmk concerné, ce qui permet à nouveau une attribution unique.

Pour la configuration dans Checkmk, vous avez besoin des ID Jira des champs personnalisés que vous avez créés — ainsi que de ceux de certains autres champs ; au total, les éléments suivants sont donc requis :

ID du projet
ID du type de ticket
ID de priorité (facultatif)
ID du champ personnalisé de l'ordinateur hôte
ID du champ personnalisé du service
ID du champ personnalisé de l'instance (facultatif)
ID de transition (flux de travail) (facultatif)

La grande majorité de ces identifiants peut être lue à l'aide du script ci-dessous via l'une des API REST de Jira. Les administrateurs Jira peuvent également récupérer les identifiants via l'interface graphique de Jira, y compris ceux qui ne peuvent pas être récupérés via l'API et donc via le script.

2.1. Configuration des champs personnalisés dans Jira

Vous pouvez découvrir comment créer des champs personnalisés dans Jira dans la documentation de Jira, y compris l’affectation du champ aux écrans dits « d’incident » dans Jira.

Lors de la création des champs requis pour Checkmk, veuillez tenir compte des points suivants concernant le type de champ. Vous êtes libre de nommer vos champs comme vous le souhaitez. Toutefois, les noms de champs indiqués dans le tableau ci-dessous correspondent au script qui vous permettra de lire les identifiants Jira dans la section suivante intitulée « Détermination des identifiants Jira à l’aide d’un script externe ».

Champ personnalisé Type de champ Nom

Champ personnalisé	Type de champ	Nom
Champ personnalisé de l'ordinateur hôte	`Text field (single line)`	`CMK_HOST_FIELD` (exemple)
Champ personnalisé du service	`Text field (single line)`	`CMK_SVC_FIELD` (exemple)
Champ personnalisé de l'instance (facultatif)	`Text field (single line)`	`CMK_SITE_FIELD` (exemple)

Champ personnalisé de l'ordinateur hôte

Text field (single line)

CMK_HOST_FIELD (exemple)

Champ personnalisé du service

Text field (single line)

CMK_SVC_FIELD (exemple)

Champ personnalisé de l'instance (facultatif)

Text field (single line)

CMK_SITE_FIELD (exemple)

L'Text field (single line) du type de champ pour les « Champs personnalisés de l'hôte » et les « Champs personnalisés du service » est obligatoire à partir de la version 2.4.0 de Checkmk si vous souhaitez tester les notifications Jira ou les générer via l'Event Console. Si vous avez déjà configuré ces champs en tant qu'« Number field » dans des versions antérieures de Checkmk, vous pouvez continuer à les utiliser tant que vous souhaitez uniquement envoyer des notifications pour les incidents liés aux ordinateurs hôtes et aux services à l'aide de la méthode de notification Jira, comme décrit dans cet article.

Assurez-vous également que l'utilisateur Jira utilisé par Checkmk pour créer des tickets, c'est-à-dire celui saisi dans la règle de notification Checkmk, dispose d'un accès en lecture et en écriture à ces champs personnalisés.

2.2. Détermination des identifiants Jira à l'aide d'un script externe

Vous pouvez interroger les ID de manière collective à l'aide du script suivant, qui utilise l'API REST de Jira.

Remplacez JIRA_USERNAME, JIRA_PASSWORD, PROJECT_KEY et https://jira.server.your-domain.de par vos valeurs correspondantes. Vous pouvez également déterminer l'PROJECT_KEYe à partir de l'interface graphique de Jira sans avoir besoin de droits d'administrateur.

Si vous utilisez un produit Jira Cloud, le script n'est pas authentifié à l'aide d'un mot de passe, mais à l'aide d'un jeton API. Vous trouverez des informations générales et des instructions pour créer un jeton API dans la documentation Jira. Dans Jira, vous pouvez copier le jeton API généré dans le presse-papiers et le coller dans le script suivant à la place de JIRA_PASSWORD.

example_script.py

#!/usr/bin/env python3

import requests
import sys
import urllib3
urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning)

user = "JIRA_USERNAME"
password = "JIRA_PASSWORD"
project_key = "PROJECT_KEY"
jira_instance = "https://jira.server.your-domain.de"
custom_field_1 = "CMK_HOST_FIELD"
custom_field_2 = "CMK_SVC_FIELD"
custom_field_3 = "CMK_SITE_FIELD" # don't edit if field is not used

def handle_response(user, password, jira_instance, what):
    url = "%s/rest/api/2/%s" % (jira_instance, what)
    sess = requests.Session()
    sess.auth = (user, password)
    response = sess.get(url, verify=False)

    return response

sys.stdout.write("=== IDs for project %s ===\n" % project_key)
infotext = ""
for section, id_name in [ ("Project_ID", "project"),
                          ("Issue", "issuetype"),
                          ("Priority", "priority"),
                          ("Field", "field"),
                        ]:

    json_response = handle_response(user,password,jira_instance,id_name).json()
    if id_name == "project":
        infotext = ""
        for project in json_response:
            if project["key"] == project_key:
                infotext += "%s\n\n" % project.get("id", "Project ID not found")
        if not infotext:
            infotext += "Project ID not found, project name existing?\n\n"
    else:
        types = ""
        for line in json_response:
            if id_name == "field":
                if line["name"].lower() == custom_field_1.lower() or \
                    line["name"].lower() == custom_field_2.lower() or \
                    line["name"].lower() == custom_field_3.lower():
                    types += "%s: %s\n" % (line["name"], line["id"].split("_")[1])
            else:
                types += "%s: %s\n" % (line["name"], line["id"])

        infotext += "=== %s types\n%s\n" % (section, types)

sys.stdout.write(infotext)

Copier le contenu du fichier dans le presse-papiers

Contenu du fichier copié avec succès dans le presse-papiers !

L'accès en écriture au presse-papiers a été refusé !

La sortie du script ressemblera à ceci :

=== IDs for project MY_PROJECT ===
10401

=== Issue types
Test case: 10600
Epic: 10000
Task: 10003
Sub-task: 10004
Bug: 10006
Story: 10001
Feedback: 10200
New Feature: 10005
Support: 10500
Improvement: 10002

=== Priority types
Blocker: 1
High: 2
Medium: 3
Low: 4
Lowest: 5
Informational: 10000
Critical impact: 10101
Significant impact: 10102
Limited impact: 10103
Minimal impact: 10104

=== Field types
CMK_HOST_FIELD: 11400
CMK_SVC_FIELD: 11401
CMK_SITE_FIELD: 11403

2.3. Détermination des identifiants Jira à l'aide de l'interface graphique

Au lieu d'exécuter des scripts, vous pouvez également extraire les identifiants via l'interface graphique de Jira, mais pour cela, vous devez vous connecter à Jira avec un compte administrateur. Atlassian, l'éditeur de Jira, a décrit cette procédure à l'aide de l'exemple de l'identifiant de projet dans sa propre documentation.

Les ID des autres champs et types de tickets peuvent être consultés en effectuant l'édition de l'élément correspondant dans l'interface graphique de l'administrateur Jira. L'ID correspond alors généralement à la dernière valeur affichée dans la barre d'adresse de votre navigateur.

3. Configuration de Checkmk

Vous avez déjà appris comment configurer les notifications Checkmk de manière générale dans l'article consacré aux notifications.

Pour utiliser les notifications Jira, procédez comme suit dans Checkmk :

Si vous souhaitez utiliser des attributs utilisateurs personnalisés, vous pouvez les créer pour les ID Jira suivants : ID du projet (jiraproject), ID du type de ticket (jiraissuetype), ID de priorité (jirapriority) et ID de transition (jiraresolution). Les noms que vous saisissez comme « Name » d’un attribut sont indiqués entre parenthèses. Vous créez un attribut utilisateur personnalisé via Setup > Users > Custom user attributes > Add attribute :

Assurez-vous que la case à cocher «Make this variable available in notifications » est cochée pour tous ces attributs utilisateur personnalisés créés pour Jira.
Dans les propriétés d’un utilisateur, vous pouvez ensuite saisir dans ces attributs les identifiants Jira dont cet utilisateur est responsable.
Pour chaque attribut utilisateur personnalisé, laissez le champ de l’identifiant Jira associé vide dans la règle de notification créée lors des étapes suivantes. Ces champs sont ensuite remplis avec les attributs utilisateur personnalisés.
Créer de nouveaux paramètres pour Jira avec Setup > Events > Notifications > Parameters for notification methods > Parameters for Jira > Add parameter.
Dans le champ JIRA URL, saisissez l'URL de votre instance Jira, par exemple jira.server.your-domain.com.
Dans la zone « Authentication », vous enregistrez les données d'accès du compte Jira : nom d'utilisateur/mot de passe ou jeton pour les produits Jira Cloud.
Pour Project ID et Issue type ID, vous avez besoin des identifiants précédemment identifiés dans Jira, par exemple « 10401 » pour l'ID du projet et « 10006 » pour le type de ticket « Bug ».
Pour Host custom field ID, Service custom field ID et (facultatif) Site custom field ID, saisissez les identifiants des champs personnalisés que vous avez créés dans Jira.
Pour pouvoir créer un lien direct vers Checkmk à partir de n'importe quel ticket généré, saisissez sous Monitoring URL l'URL de votre instance Checkmk, par exemple : https://mycmkserver/mysite/, en veillant à inclure la barre oblique finale (/).

Vous disposez également, entre autres, des paramètres facultatifs suivants :

Avec l'option « Priority ID », vous pouvez définir la priorité avec laquelle les tickets sont créés dans Jira. Vous pouvez saisir ici l'un des « types de priorité » lus dans le script, de « 1 » à « 5 ».
Vous pouvez modifier les descriptions générées pour les problèmes d’ordinateur hôte et de service dans les tickets via les options « Summary for host notifications » et « Summary for service notifications ».
Vous pouvez utiliser l'option Label pour définir si vous souhaitez transmettre des étiquettes lors de la création de tickets dans Jira. Si vous activez Label sans saisir de valeur, l'option monitoring sera définie.
Checkmk inscrit la valeur de l'étiquette dans le champ « labels » de Jira ; cela ne fonctionne que si ce champ existe dans votre application Jira, ce qui est le cas avec Jira Software, mais pas avec Jira Service Desk par exemple.
Attach graphs ajoute des graphiques associés avec l'état actuel aux nouveaux tickets.
Si vous souhaitez également qu’un identifiant (Resolution) soit saisi dans le ticket Jira lors de la notification d’un changement d’état vers « OK » dans Checkmk, vous pouvez le définir sous « Activate resolution with following resolution transition ID ».
Pour pouvoir déterminer l’identifiant correct ici, vous devez également disposer de droits d’administrateur dans Jira. Revenez dans la zone « Issues » et cliquez sur « Workflows ». Cliquez ensuite sur « View » dans la ligne du flux de travail standard du projet Jira que vous utilisez. Si un organigramme s'affiche, modifiez l'affichage en cliquant sur « Text ». Vous pourrez lire l'ID souhaité dans la colonne « Transitions (id) ».
La section « Set optional timeout for connections to JIRA » vous permet de configurer le timeout des connexions à Jira. Si vous ne saisissez rien ici, la valeur par défaut de 10 secondes s'appliquera.

Lorsque vous utilisez la case « Contact selection » ci-dessous, veuillez tenir compte des points suivants :

Lors de la sélection des contacts, assurez-vous que les notifications ne sont envoyées qu’à un seul contact, par exemple en sélectionnant un seul utilisateur. Avec les méthodes de notification pour les systèmes de tickets, etc., la sélection des contacts sert uniquement à spécifier que des notifications sont envoyées. Cependant, les notifications ne sont pas envoyées à l'utilisateur sélectionné, mais au système de tickets. Notez qu'une sélection de contacts via des groupes de contacts, tous les contacts d'un objet ou similaire génère généralement plusieurs notifications identiques pour un événement, qui aboutissent alors deux, trois fois, voire plus souvent dans le système de tickets.
Si la première condition est remplie, mais que l'utilisateur est utilisé dans plusieurs règles de notification pour la même méthode, seule la dernière règle s'applique dans chaque cas. Il est donc conseillé de créer un utilisateur fonctionnel distinct pour chacune de ces règles de notification.
Le thème de la sélection des contacts est quelque peu différent lorsque vous utilisez des attributs utilisateur personnalisés, car ceux-ci sont destinés à attribuer des identifiants Jira différents à différents utilisateurs. Par conséquent, dans ce cas, vous souhaiterez généralement informer plusieurs contacts, à savoir les utilisateurs auxquels vous avez attribué les attributs personnalisés. Si ces utilisateurs utilisent des identifiants Jira différents, aucune notification identique ne sera générée.

Vous trouverez des informations sur la manière de tester la nouvelle méthode de notification dans l'article consacré aux règles de notification.

4. Options de diagnostic

Si aucun ticket n'apparaît dans Jira après avoir configuré la règle de notification dans Checkmk, veuillez consulter le fichier journal associé ~/var/log/notify.log. Jira renvoie généralement des messages d'erreur très utiles à cet endroit, qui peuvent réellement vous aider à diagnostiquer le problème. Nous vous présentons ci-dessous quelques exemples.

Message d'erreur : Impossible de créer un ticket, code de réponse JIRA 400, le champ « étiquettes » ne peut pas être défini.

Il se peut que votre produit Jira ne dispose pas d'étiquettes. Désactivez simplement l'utilisation des étiquettes dans votre règle de notification dans Checkmk en décochant « Label ».

Message d'erreur : Impossible de créer un ticket, code de réponse JIRA 400, « b’project is required ».

Ce message d'erreur indique que l'ID que vous avez saisi dans la règle de notification pour le champ en question (ici : ID du projet) est incorrect.

Message d'erreur : Impossible de résoudre https://jira.serveur.your-domain.de/browse/ISSUE-123, code de réponse JIRA 500, « Erreur interne du serveur ».

Si vous recevez ce message d'erreur alors qu'un ticket dans Jira est censé être clôturé automatiquement par Checkmk, ou respectivement passer à un autre statut, cela peut indiquer que l'ID de transition que vous avez saisi n'est pas correct. L'ID de transition se trouve dans la règle de notification, dans le champ « Activate resolution with following resolution transition ID ». En règle générale, vous devriez vérifier à nouveau cet ID dans l'interface web de Jira.

Last modified: Tue, 13 Jan 2026 10:21:29 GMT via commit 12d6e597a

Sur cette page

1. Introduction
2. Configuration de Jira
3. Configuration de Checkmk
4. Options de diagnostic

3.1. Serveur et VMs

3.2. Appliance, conteneur, cloud

3.3. Mises à jour

4.1. Serveur

4.2. Instances

5.1. Hôtes

5.2. Services

5.3. Les règles

5.4. Éléments de configuration communs

5.5. Utilisateurs et permissions

5.6. Notifications

5.7. Évènements

6.1. Supervision avec agents

6.2. Supervision avec extensions d’agents

6.3. Supervision via API

6.4. Supervision de bout en bout

7.1. Généralités

7.2. Commandes dans les vues

8.1. Analyse

8.2. Pronostic

11.1. APIs for automation

11.2. Développement de plugins de supervision

12.1. Le Checkmk Micro Core (CMC)

Notifications via Jira

1. Introduction

2. Configuration de Jira

2.1. Configuration des champs personnalisés dans Jira

2.2. Détermination des identifiants Jira à l'aide d'un script externe

2.3. Détermination des identifiants Jira à l'aide de l'interface graphique

3. Configuration de Checkmk

4. Options de diagnostic

Message d'erreur : Impossible de créer un ticket, code de réponse JIRA 400, le champ « étiquettes » ne peut pas être défini.

Message d'erreur : Impossible de créer un ticket, code de réponse JIRA 400, « b’project is required ».

Message d'erreur : Impossible de résoudre https://jira.serveur.your-domain.de/browse/ISSUE-123, code de réponse JIRA 500, « Erreur interne du serveur ».