CheckMK Notifications as Tickets - Using SystemMonitoring Plugin?

Moderator: crythias

Locked
irony
Znuny newbie
Posts: 1
Joined: 03 Jul 2024, 16:21
Znuny Version: 6.5.6
Real Name: Alan

CheckMK Notifications as Tickets - Using SystemMonitoring Plugin?

Post by irony »

Hello together :D

i would love to connect the Notifications of my CheckMK with Znuny.

- Notifications of Type <anything> should be seen as incidents.
- Notifications of Type OK should be seen as "close the ticket state to successfully closed".
- Each Notification has a unique ServiceID and/or HostID.
- Notifications of the same ServiceID should not resolve in the creation of a new ticket, rather an update of the old one.

basically, just how you would expect it to work.

I have heard there is the SystemMonitoring Plugin, but i am not too familiar with how Postmaster Filter and so on work. Can anyone explain me how to set it up? Basically i expect it to be a Filter, but i don't understand how much of filtering i need to adjust at what position.

I have implemented this via API Call, but it requires User Data in cleartext placed in the script of the monitoring CheckMK instance, which we don't want.
Mails don't require authentification, therefore it's a better solution here.

Thanks for your help in advance!
root
Administrator
Posts: 4249
Joined: 18 Dec 2007, 12:23
Znuny Version: Znuny and Znuny LTS
Real Name: Roy Kaldung
Company: Znuny
Contact:

Re: CheckMK Notifications as Tickets - Using SystemMonitoring Plugin?

Post by root »

Hi,

If you have implemented it via API call there is on solution to remove the UserData from CheckMK: you can add them into the mapping. The only important thing then is that you have to ensure that only CheckMK is using the web service. You can enforce this with Apache configuration by using additional authentication or client IP limitation.

The SystemMonitoring add-on is technically a PostMaster filter that extracts the require parts out of CheckMK's emails.
This are the relevant regular expressions that are used:
  1. StateRegExp -the value of current state in the mail
  2. HostRegExp - the related host
  3. ServiceRegExp - the service
  4. NewTicketRegExp - possible match when a new ticket should be created. (Service is CRITICAL, Host id DOWN)
  5. CloseTicketRegExp - possible match when the ticket should be close (Service is OK, Host is UP)
  6. CloseActionState - the state to be set when a ticket is closed
The setting FromAddressRegExp is to make sure only wanted sender are processed.

- Roy
Znuny and Znuny LTS running on CentOS / RHEL / Debian / SLES / MySQL / PostgreSQL / Oracle / OpenLDAP / Active Directory / SSO

Use a test system - always.

Do you need professional services? Check out https://www.znuny.com/

Do you want to contribute or want to know where it goes ?
Locked