CODEWITHSUNDEEP
azure-web-app-serviceazure-application-insightskql
BenjiFB
BenjiFB

Reputation: 4721

How to query string in Kusto (Application Insights)

I've got a C# ASP.NET Core app running in an Azure Web Application. I've got an ILogger which I'm using to log to Application Insights. I write a log like:

        _logger.LogInformation("Acting on order. OrderId: {orderId}, OrderChargeId: {orderChargeId}",
            orderId,
            orderChargeId
        );

In the Azure Portal, Application Insights blade, I can go to Logs for my app, and search successfully. If I do a search like:

traces
| where message like "Acting on order."

I get back expected results, including an item with:

Acting on order. OrderId: 1, OrderChargeId: 1

in the 'message' field. But as soon as I expand my query to:

traces
| where message like "Acting on order. OrderId: 1"

I get back no results (despite seeing a result with the order id 1 in the same timeframe when I use the above search. In fact, I get no results as soon as I expand my query to:

traces
| where message like "Acting on order. O"

or anything longer than that string.

Am I searching incorrectly to find all logs with OrderId: 1? Am I writing my logs incorrectly?

Upvotes: 1

Views: 1987

Answers (1)

David דודו Markovitz
David דודו Markovitz

Reputation: 44921

like is undocumented, and from what I've just tested it seems to act like contains, which should be your last resort when searching with KQL.

Kusto builds a term index consisting of all terms that are three characters or more, and this index is used by string operators such as has, !has, and so on. If the query looks for a term that is smaller than three characters, or uses a contains operator, then the query will revert to scanning the values in the column. Scanning is much slower than looking up the term in the term index.

String operators

For your logs to be effectively searchable, make sure to "mark" them with as few as terms as possible, that will differentiate them from the other logs.
Instead of using multiple terms that can be very common by their own, or too short to be indexed, like Acting on order, prefer using a single term ActingOnOrder.

Be consistent with case-sensitivity and when searching, prefer case sensitive operators over case insensitive ones, e.g., has_cs over has

Make sure that your terms are long enough to be searchable (at least 3 characters), e.g., instead of OrderId equal to 1, start with OrderId equal to 100.

If the searchable text occurs right at the beginning of your log, you can prefer startswith_cs over has_cs.

Upvotes: 1

Related Questions