Search forward slash through Discover dashboard

OpenSearch
1

Versions (relevant - OpenSearch/Dashboard/Server OS/Browser):

OPenSearch v 2.13.0/Dashboard/Ubuntu/Edge

Describe the issue:

I’m trying to search pattern “www.xyz.com/” in the message field in all events in documents in my index. I want exact match for “www.xyz.com/”. I don’t want “www.xyz.com/path1” or “www.xyz.com/path2/ab.js” etc. Only exact “www.xyz.com/”. I tried many search queries and I found that the match for / character is not working.
Here are the queries that I tried,

In DQL,

Query 1

message:"\"requestUrl\":\"www.xyz.com/\""

Query 2
message:"\"requestUrl\":\"www.xyz.com/\"" AND NOT message:"\"requestUrl\":\"www.xyz.com/*\""

Query 3
message:"\"requestUrl\":\"www.xyz.com\/\""

Lucene
Query 1
message:/\"requestUrl\":\"www\.xyz\.com\/\"$/

I tried a few more combinations but the gist of the matter is / slash is not matching and I’m not able to filter out events/documents with my exact need.

ANy help would be helpful. I went through the documentation but it wasn’t helpful.



**Configuration**:



**Relevant Logs or Screenshots**:
2

I’m not an expert on this, but I think you need to take a look at the Text Analysis documentation to understand how OpenSearch is analyzing your text entries. Generally speaking, if you’re using the default analyzer, OpenSearch will break up your queries based on word boundaries. Word boundaries include spaces (like you would expect) but also many special characters including slashes.

We can test this with the Analyze API (which can be used under Dev Tools on OpenSearch Dashboards).

Take a look at this field that I have named “AD.Subject.SamAccountName” stored in an index named “.ds-log_win_microsoft-windows-security-auditing-000166”

GET .ds-log_win_microsoft-windows-security-auditing-000166/_analyze?pretty
{
  "field": "AD.Subject.SamAccountName",
  "text": "hello/how/are/you"
}

When I run this, I get text analysis that looks like this:

{
  "tokens": [
    {
      "token": "hello",
      "start_offset": 0,
      "end_offset": 5,
      "type": "<ALPHANUM>",
      "position": 0
    },
    {
      "token": "how",
      "start_offset": 6,
      "end_offset": 9,
      "type": "<ALPHANUM>",
      "position": 1
    },
    {
      "token": "are",
      "start_offset": 10,
      "end_offset": 13,
      "type": "<ALPHANUM>",
      "position": 2
    },
    {
      "token": "you",
      "start_offset": 14,
      "end_offset": 17,
      "type": "<ALPHANUM>",
      "position": 3
    }
  ]
}

You’ll notice that OpenSearch removed all the slashes and I’m left with just the words.

If I rerun the query though, but instead use the .keyword field, you’ll notice that it changes:

GET .ds-log_win_microsoft-windows-security-auditing-000166/_analyze?pretty
{
  "field": "AD.Subject.SamAccountName.keyword",
  "text": "hello/how/are/you"
}

{
  "tokens": [
    {
      "token": "hello/how/are/you",
      "start_offset": 0,
      "end_offset": 17,
      "type": "word",
      "position": 0
    }
  ]
}

OpenSearch is evaluating this as one string, keeping the slashes. This is the purpose of the keyword - searching text without analysis. The downside is that the search has to be exact, and has to be case sensitive.