I’m new to ExtraHop and am poking around an existing implementation. I discovered when looking at the Health I see a Trigger Load by Trigger showing high usage by a simple Trigger that is capturing DB statements.
I suspect there is no limit to the size of the statement think that is the cause of the high load. The trigger is only a few lines long. It is picking up the DB Statement that had been saved in the Flow.store.stmt on the DB_Request trigger.
This is created a Device.MetricAddDetailCount(“db_rsp_count_detail”, Stmt,1) It is also recording the Response time in another Device.MetricAddSampleset(“dp_proc_time”, stmt, processingTime).
Am I on the right track with questioning the size of the contents for the Stmt variable?
Those are good points. I would take a look at what the trigger is assigned to as well. A lot of times you can reduce trigger load by assigning the trigger to only the boxes it needs to inspect instead of an “assign to all”. This way your only looking at conversations you truly care about and not every single database event that comes across the box.
There are several things to look at when implementing triggers:
exceptions, avoid them if possible with defensive programming. More here.
defer execution, don’t do stuff until you need it.
limit trips “into” an object. if you are making multiple calls for an object (i.e., HTTP.tprocess) make that call once and store it in a variable (var proctime = HTTP.tprocess) and use the variable proctime rather than calling HTTP.tprocess repeatedly.
be aggressively lazy, if you are looking for error conditions, make the first thing your trigger does is check for an error:
if ( DB.error ) {
// do stuff
leverage other triggers, if you already have one trigger putting DB.statement (raw SQL) on the Flow.store, you can have multiple triggers “harvest” that Flow.store.