Aggregation based comparison in Watch condition and hard-coded variables

Watch: Compare Vs Script condition

If you need to do comparisons with aggregation buckets in watchers, then instead of this:

"condition": {
  "compare": {
    "ctx.payload.aggregations.agg1.buckets.0.doc_count": {
      "gte": 5
    }
  }
}

please prefer this, as this takes care of "Index out of bound" exceptions:

"condition": {
  "script": {
    "source": "return (ctx.payload.aggregations.agg1.buckets.size() > 0 && ctx.payload.aggregations.agg1.buckets.0.doc_count >= params.threshold)",
    "lang": "painless",
    "params": {
      "threshold": 5
    }
  }
}

Hard-coded variables in scripts

• ElasticSearch throws circuit_breaking_exception error when it sees more than 15 new dynamic scripts within a minute.
• Sometimes this error is also thrown when master goes down abruptly.
• This is so because, it has to compile every new/unique script it sees and this is a CPU hog.
• You can change the settings dynamically by setting

  script.max_compilations_rate

  to a larger value, whose default value is 15/minute.
• It then caches the compiled script, but there is an upper limit of 100 or 65,535 bytes, whichever is lower. You can configure the size of this cache by using the

  script.cache.max_size setting

  and the size of stored scripts can be changed by setting

  script.max_size_in_bytes

  setting to increase that soft limit, but if scripts are really large then a native script engine should be considered.
• By default, scripts do not have a time-based expiration, but you can change this behaviour by using the

  script.cache.expire

  setting.

Solution

• For ElasticSearch, an script with threshold value of 5 is different to another script with threshold 10. But if we parameterize a changing variable, then it will be a single script compiled and kept in cache with parameters injected at run time.
• Just to be clear, hard-coded variables are different than hard-coded constants. You don't need to parameterize hard-coded constants.