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
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
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
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-bounces@otrs.org [mailto:otrs-bounces@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
From: otrs-bounces@otrs.org [mailto:otrs-bounces@otrs.org] On Behalf Of Rob
Shears
Sent: Wednesday, December 2, 2015 11:24 AM
To: User questions and discussions about OTRS.
Yep, Nagios.
Yes, monitoring is enabled (HTTP) via SysConfig and configured.
Nagios certainly supports authenticated HTTP acknowledgement, I'm able to acknowledge alerts with the command listed in OTRS via pasting the HTTP request into a web browser fine.
Cheers
Rob
From: otrs-bounces@otrs.org [mailto:otrs-bounces@otrs.org] On Behalf Of LQ Marshall
Sent: 02 December 2015 16:40
To: 'User questions and discussions about OTRS.'
Subject: Re: [otrs] SystemMonitoring
From: otrs-bounces@otrs.orgmailto:otrs-bounces@otrs.org [mailto:otrs-bounces@otrs.org] On Behalf Of Rob Shears
Sent: Wednesday, December 2, 2015 11:24 AM
To: User questions and discussions about OTRS.
Nothing in the OTRS log. May want to check the otrs' folders for error_logs,
increase logging to get something (think that's LogFile).
Could Nagios server/auth be limited by IP? Firewalling (iptables, etc)? Did
you run the HTTP post from the Nagios server? (Confirming that you checked
the saved Nagios user/pass in OTRS is correct?)
Is an action being performed on the notification ticket to generate the ack?
(I think locking monitor ticket will do, not all actions will.)
Has this ever worked? Backed out of changes? Reinstal the package?
LQM
From: otrs-bounces@otrs.org [mailto:otrs-bounces@otrs.org] On Behalf Of Rob
Shears
Sent: Wednesday, December 2, 2015 12:03 PM
To: User questions and discussions about OTRS.
The OTRS logs don't show a thing, they don't even show an attempt to acknowledge, so it is an internal OTRS issue. Didn't know you could increase the OTRS logging, I'll look into that.
OTRS doesn't try to acknowledge, so it is not a limitation between OTRS/Nagios boxes. There may very well be a problem there but I'm not up to troubleshooting that yet. ;)
SystemMonitoring was reconfigured to acknowledge on TicketQueueUpdate (Rather than TicketLockUpdate) but that made no difference. No attempt is made to acknowledge the alert in either situation, whether I manually perform the appropriate action (queue or lock), or whether a generic agent performs the action.
Never worked, new system, still in dev.
Cheers
Rob.
From: otrs-bounces@otrs.org [mailto:otrs-bounces@otrs.org] On Behalf Of LQ Marshall
Sent: 02 December 2015 17:50
To: 'User questions and discussions about OTRS.'
Subject: Re: [otrs] SystemMonitoring
Nothing in the OTRS log. May want to check the otrs' folders for error_logs, increase logging to get something (think that's LogFile).
Could Nagios server/auth be limited by IP? Firewalling (iptables, etc)? Did you run the HTTP post from the Nagios server? (Confirming that you checked the saved Nagios user/pass in OTRS is correct?)
Is an action being performed on the notification ticket to generate the ack? (I think locking monitor ticket will do, not all actions will.)
Has this ever worked? Backed out of changes? Reinstal the package?
LQM
From: otrs-bounces@otrs.orgmailto:otrs-bounces@otrs.org [mailto:otrs-bounces@otrs.org] On Behalf Of Rob Shears
Sent: Wednesday, December 2, 2015 12:03 PM
To: User questions and discussions about OTRS.
participants (3)
-
Leonardo Certuche -
LQ Marshall -
Rob Shears