Yes, I don’t need generic agents or any postmaster filters other than the SystemMonitoring postmaster filter.
I use a generic agent to move the Nagios alerts into a different Queue. I use the additional postmaster filters to set X-OTRS-LOOP header to prevent auto responses. Both of these functions are working fine and I don’t believe interfere in any way with the operation of SystemMonitoring. The dynamic fields are present and data is properly populated to them in the backend. No CMDB or CI is in place. Cheers Rob. From: otrs-boun...@otrs.org [mailto:otrs-boun...@otrs.org] On Behalf Of Leonardo Certuche Sent: 02 December 2015 16:39 To: User questions and discussions about OTRS. Subject: Re: [otrs] SystemMonitoring Hello Rob, As far as I understand, you don't need generic agent jobs or postmaster filters to have this working. Did you create the 3 dynamic fields required for this functionality? If you want to keep the default sysconfig entry as it comes, those fields must be named TicketFreeText1 for storing the name of the device affected, TicketFreeText2 for the name of the service affected and ArticleFreeText1 for the state of the event. Then publish those fields on AgentTicketZoom so you can actually know their values. Bonus points if the name of the device is the same name of one of your configuration items (CI) on the CMDB. That way your ticket will be linked with the affected CI and its operational state will change. I know my comment is not related with the acknowledge feature but hopefully there is valuable information for you here. On 2 December 2015 at 11:24, Rob Shears <r...@phonovation.com<mailto:r...@phonovation.com>> wrote: My next challenge is proper configuration of SystemMonitoring. Hopefully I’m not getting something as obvious as my last issue incorrect here. OTRS 4.0.13 SystemMonitoring 4.0.2 I have the incoming tickets sorting fine. I am using the post-postmaster filter, as I use a postmaster filter to set some variables (X-OTRS-LOOP etc). I have a GenericAgent Job running to grab the tickets, stick em in a queue and set the priorities. I can file additional alerts to the correct ticket. I cannot get OTRS to even attempt to acknowledge the alert, no failures, no log errors, just no attempt from OTRS at all to send the http acknowledgement. I adjusted the trigger event in the SystemConfig section to TicketQueueUpdate, from TicketLockUpdate, to match our requirements, but there is no difference in how OTRS is acting with either. It simply will not trigger the acknowledgement event. While I keep working away (the acknowledgement doesn’t even work from the command line but I’ll solve that one!), anyone have any ideas on what could be going wrong, to cause OTRS to not even attempt the acknowledgement? Cheers Rob Shears --------------------------------------------------------------------- OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
--------------------------------------------------------------------- OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
