Incident Detector Won't Detect ANY incidents

[DeanMoiler]

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

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

[RJSunderman]

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.

[DeanMoiler]

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.

[EricIronside · Accepted solution]

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.

[DeanMoiler]

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!

[RJSunderman]

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

[DeanMoiler]

Hi @RJSunderman ,

Thank you for the clarification regarding copying and using dedicated GE definitions. Having seen the perils of losing configuration I will implement this to make the GE service more robust.

I'd spotted the GUID issue in relation to the duplicate definitions and agree that your method of copying the autogenerated and using a fixed GE definition should stop this from happening, so another reason to use fixed GE definitions once generated.

Thanks for the clarification and for providing a bit more background to the processes and the why's around the issues presenting. It all makes sense now!

I'll go and force fixed GE definition use rather than automatic to ensure the environment works consistently.

Dean