Incident Detector Won't Detect ANY incidents

151
5
Jump to solution
08-20-2021 09:32 AM
DeanMoiler
New Contributor III

Hey Everyone,

 

I'm working with both Test & Production instances of GeoEvent server, of which I'm using an incident detector to fire Started and Ended emails when the statements are evaluated.

 

It's been working fine and had been working with simple statements like:

Opening:

  Status = 'Off'

Closing:

   Status = "On'

With the Off and On valued being generated by the GeoEvent Service itself, so erroneous white spaces aren't a likely culprit here.

 

For some reason these are no longer working in the Production environment, to the point where I cannot get an incident to fire for simple tasks in a newly created GeoEvent Service such as:

 

Opening:

  OBJECTID >0

Closing:

OBJECTID IS NULL

DeanMoiler_0-1629476706351.png

 

I cannot for the life of me figure out how to get the incident detector to detect any incidents at all. I can see in the event sampler that events are hitting the incident detector, but are never meeting an opening condition.

 

Is there anything obvious that I'm missing that could affect the incident detector in such a way?

 

Thanks!

 

Dean

Tags (3)
0 Kudos
1 Solution

Accepted Solutions
EricIronside
Esri Regular Contributor

Hey @DeanMoiler  

One thing to check is to make sure your GeoEvent Definition has a field tagged as TRACK_ID.  The Incident Detector will not create any incidents if the GeoEvent Definition doesn't have a TRACK_ID set.  

I know when you create an input and allow it to create the incoming GeoEvent Defintion, it doesn't set the TRACK_ID automatically for you.  You should make a copy of the GeoEvent Definition it created, set the TRACK_ID, TIME_START, and GEOMETRY tags, then switch your input to use that known definition. Once you do that, your Incident Detector should start working.

View solution in original post

5 Replies
RJSunderman
Esri Regular Contributor

Hello Dean --

My apologies that your inquiry has not received any responses.  Have you opened an ticket on this with Esri Technical Support?  I would like to have these sort of issues tracked.  While I have not had a problem configuring Incident Detector in deployment I have set up for regression testing, I did have someone reach out to me that was having a problem with their deployment and configuration which I was unable to reproduce.

If this is still an issue for you, and you are so inclined, please work with Esri Technical Support to try and establish a reproducible case.

0 Kudos
DeanMoiler
New Contributor III

Hi RJ, thanks for getting back to me,

and not a problem, it is a rather specific query, and I have managed to solve it, though had not yet updated geonet!

This was also raised with Esri  NL technical for your reference in case you'd like to track the details for troubleshooting.

0 Kudos
EricIronside
Esri Regular Contributor

Hey @DeanMoiler  

One thing to check is to make sure your GeoEvent Definition has a field tagged as TRACK_ID.  The Incident Detector will not create any incidents if the GeoEvent Definition doesn't have a TRACK_ID set.  

I know when you create an input and allow it to create the incoming GeoEvent Defintion, it doesn't set the TRACK_ID automatically for you.  You should make a copy of the GeoEvent Definition it created, set the TRACK_ID, TIME_START, and GEOMETRY tags, then switch your input to use that known definition. Once you do that, your Incident Detector should start working.

View solution in original post

DeanMoiler
New Contributor III

Hi @EricIronside ,

I believe that you're spot on with the issue.

I'd performed an administrative reset (as defined in another post by @RJSunderman  separately) on geoevent, in order to solve the issue causing the geoevent manager to not appear (which seems to be related to copying of SSL certificate keystore) and it appears that the TRACK_ID designation on the GE Definitions weren't imported/exported as part of the xml backup. Not sure if this is by design, or is just understood, or was a bug, but is a good one to know can occur.

In the case of this geoevent definition, as they must have automatically regenerated the first time events were run after the site configuration was imported, the TRACK_ID was not set on the regenerated definitions. Strangely the GE Definitions would be duplicated also, so possible something to do with site export/import.

I'm guessing based on your comments above, that it would be better practice to clone the automatically created GE definition and set the TRACK_ID, and to not use the automatically generated definitions in the GE Service as the above issues can occur.

Once the TRACK_ID value was set on the GE definitions, the Incident Detector started working again.

Thanks!

 

 

0 Kudos
RJSunderman
Esri Regular Contributor

Hey Dean --

What you indicate regarding copying a GeoEvent Definition which has been generated for you to apply tags or event to adjust data types is the better practice. I often have to adjust a GeoEvent Definition to specify that a numeric value be handled as a Long, or even as a Date when receiving epoch values, rather than allowing the more generic numeric type of Double data type to be used.

Considering the application of a TRACK_ID tag, event definitions generated for you by an inbound connector or processor cannot accurately guess which field might hold a unique record identifier, so the TRACK_ID tag is not applied when generating a new GeoEvent Definition.

I've also seen what you mention with duplicate GeoEvent Definitions being created especially when an XML snapshot of a configuration is loaded and what I refer to as "managed GeoEvent Definitions" are part of the snapshot. Frequently an input configured to create a GeoEvent Definition will create a new GeoEvent Definition when receiving data for the first time following an administrative reset and configuration import.

The "duplicate" event definition created has the same schema and even the same name as the event definition captured by the snapshot. But the underlying GUID for the two event definitions is different which can lead to other problems. The less you allow components you configure to create GeoEvent Definitions for you on-the-fly the more distinct and specific your configuration becomes -- which tends to improve resiliency and overall solution reliability. Auto-generated GeoEvent Definitions can be useful, but should always be replaced with copies you have tailored specifically for your configuration and operations. Auto-generated GeoEvent Definitions are really just best guesses for an event record's data structure and the guesses are generally good, but rarely 100% matches of what you want.

-- RJ

0 Kudos