[KIBANA] Programatically get the number of log lines for a saved search (e.g: via curl)?

Elastic Stack Kibana
1

Hi,

We'd like to programmatically access saved searches to count the number of log lines they return by using the ES query and get the count from ES directly. These monitoring saved searches will be created by a separate team therefore any queries with a specific key name in the title would automatically be monitored.

The problem we have is that the Kibana API is quite limited at this point in time:

  1. There is no way to remotely run a query and get results
  2. The "Request" tab from the "Inspect" link returns a valid ES query/filter BUT it does not seem we get this info from the saved object.

Why do we want that?
We'd like to detect issues in the logs by removing all known logs and if an error or an unexpected log line appears then it will trigger an alarm (via a script or polling).

How far did we get ?
We can find the saved searches with a specific key names BUT the blocker is that kibanaSavedObjectMeta.searchSourceJSON is NOT a valid ES query/filter unlike what we find in Request in the web interface.

What are our options? Is it the right approach?
We are running Kibana 6.5.

Details

2

Hi

thank you for reaching out. Your use case, getting an alarm triggered by a certain conditions, sounds like a good case for our alerting solution (it's an xpack plugin in 6.5, https://www.elastic.co/guide/en/elasticsearch/plugins/6.5/alerting.html, much improved in recent versions: https://www.elastic.co/what-is/elasticsearch-alerting )

Using our saved search API for this use case is you would need to convert the saved object you've received by our API to an ES query. So you'd need the information of searchSourceJSON and also you've need the index pattern object that's linked to this saved search. With that information you could build your own ES query for that purpose

Best,
Matthias

3

Hi Matthias,

I will look at the alerting plugin. Thanks for the tip.

However I disagree on searchSourceJSON it is massively different. As said in my original email searchSourceJSON (in 6.5) is not a valid ES query unlike what is shown within the Kibana interface in Inspect/ request. Converting it ourself seems a massive amount of work. I wished what’s in inspect/request would be in the API.

If I find the time tomorrow I’ll post both. It’s like 2 different worlds;)

4

@matw, as promised, I don't think it's "easy" to convert from what the search looks like in .kibanaSavedObjectMeta.searchSourceJSON

  [
    {
      "index": "5ad54880-24f7-11e9-b469-d1317a5b8d09",
      "highlightAll": true,
      "version": true,
      "query": {
        "query": "NOT \"Unable to resolve the time to live\" AND NOT \"No Device found\" AND NOT \"Endpoint is disabled\" AND NOT \"enhancedLogging\" AND NOT *c6e65* AND _exists_:\"severity\"",                                                                             
        "language": "lucene"
      },
      "filter": [
        {
          "$state": {
            "store": "appState"
          },
          "meta": {
            "alias": null,
            "disabled": false,
            "index": "5ad54880-24f7-11e9-b469-d1317a5b8d09",
            "key": "program",
            "negate": false,
            "params": {
              "query": "sns-foobar-wk",
              "type": "phrase"
            },
            "type": "phrase",
            "value": "sns-foobar-wk"
          },
          "query": {
            "match": {
              "program": {
                "query": "sns-foobar-wk",
                "type": "phrase"
              }
            }
          }
        },
        {
          "meta": {
            "index": "5ad54880-24f7-11e9-b469-d1317a5b8d09",
            "type": "phrases",
            "key": "severity",
            "value": "INFO, DEBUG",
            "params": [
              "INFO",
              "DEBUG"
            ],
            "negate": true,
            "disabled": false,
            "alias": null
          },
          "query": {
            "bool": {
              "should": [
                {
                  "match_phrase": {
                    "severity": "INFO"
                  }
                },
                {
                  "match_phrase": {
                    "severity": "DEBUG"
                  }
                }
              ],
              "minimum_should_match": 1
            }
          },
          "$state": {
            "store": "appState"
          }
        }
      ]
    }
  ]

To this ... which is how the search looks like from the Kibana web interface in the Inspect link then Request tab. Looks like a readable ES query (unlike the Kibana SavedObject complex structure)

  "query": {
    "bool": {
      "must": [
        {
          "query_string": {
            "query": "NOT \"Unable to resolve the time to live\" AND NOT \"No Device found\" AND NOT \"Endpoint is disabled\" AND NOT \"enhancedLogging\" AND NOT *6c5cf* AND _exists_:\"severity\"",
            "analyze_wildcard": true,
            "default_field": "*"
          }
        },
        {
          "match_phrase": {
            "program": {
              "query": "sns-foobar-wk"
            }
          }
        },
        {
          "range": {
            "@timestamp": {
              "gte": 1575618254147,
              "lte": 1575619154147,
              "format": "epoch_millis"
            }
          }
        }
      ],
      "filter": [],
      "should": [],
      "must_not": [
        {
          "bool": {
            "should": [
              {
                "match_phrase": {
                  "severity": "INFO"
                }
              },
              {
                "match_phrase": {
                  "severity": "DEBUG"
                }
              }
            ],
            "minimum_should_match": 1
          }
        }
      ]
    }
  },
5

Yes, it's not easy to do this, however it's currently the only way to archive, what you're intending to do. You'd need to convert the searchSourceJSON to a valid ES request, here's the source code how Kibana is doing it:

I'm sorry but there's currently no easy/quick way for you desired solution
Best,
Matthias

6

Thanks @matw
I'll figure out something.

7

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.