Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Better Error Reporting and Timeout for KQL Query Provider #451

Closed
ashwin-patil opened this issue Jun 18, 2022 · 3 comments · Fixed by #656
Closed

Better Error Reporting and Timeout for KQL Query Provider #451

ashwin-patil opened this issue Jun 18, 2022 · 3 comments · Fixed by #656
Assignees
Labels
accepted The request/issue is accepted for a fix
Milestone

Comments

@ashwin-patil
Copy link
Member

Describe the bug
Currently Msticpy allows to connect to Data Environment such as Sentinel and once connected it can execute KQL queries. In some cases when KQL query returns large set of records the friendly error returned is not informative about and needs more details for user to troubleshoot.

To Reproduce
Steps to reproduce the behavior:

  1. Import msticpy and initialize the query provider
  2. Connect to Sentinel workspace.
  3. Execute query which can return large set of records preferably with set notruncation option from a table such as SecurityEvents, CommonSecurityLog etc.
  4. You may see an error as shown in the below screenshots.
  5. Try to display the dataframe in another cell - optional.

Expected behavior
The Error returned should have clear description what went wrong executing the query.

Screenshots
image

Desktop (please complete the following information):

  • OS: Windows, Linux
  • Browser : Chrome, Edge
  • Version: Edge 102
@ianhelle ianhelle self-assigned this Jul 7, 2022
@ianhelle ianhelle added the accepted The request/issue is accepted for a fix label Jul 7, 2022
@FlorianBracq
Copy link
Collaborator

Hello,

I've been facing this issue too in the past, and the quick and dirty fix I found was:
msticpy\data\drivers\kql_driver.py (l430-431)
update from:

            else:
                err_contents = [f"Unknown error type: {q_info}"]

to

            else:
                if hasattr(result, "dataSetCompletion"):
                    ds_completion = result.dataSetCompletion
                    for completion in ds_completion:
                        if completion.get("HasErrors", False):
                            for one_api_error in completion.get("OneApiErrors", []):
                                error = one_api_error.get("error", {})
                                err_contents.extend(
                                    [
                                        f"StatusDescription {error.get('@message')}",
                                        f"(err_code: {error.get('code')})",
                                    ]
                                )
                else:
                    err_contents = [f"Unknown error type: {q_info}"]

There are 2 types of errors that can be raised: Either the result has more than 500k hits, or is bigger than 64MB https://docs.microsoft.com/en-us/azure/azure-monitor/service-limits

I need to run more checks, but the above code should cover both case.

The error that I don't know how to handle yet is the timeout: if the query runs for more than 10min, the client gets disconnected and kqlmagic does not seem to raise a clear error for that (or I completely missed it, which is highly likely too).

@ianhelle
Copy link
Contributor

ianhelle commented Nov 3, 2022

Should implement Florian's code or defer to #510

@ianhelle ianhelle added this to the Release 2.2.0 milestone Nov 3, 2022
@ianhelle ianhelle modified the milestones: Release 2.2.0, Release 2.3.0 Nov 29, 2022
@ianhelle ianhelle modified the milestones: Release 2.3.0, Release 2.5.0 Feb 7, 2023
@ianhelle ianhelle linked a pull request May 16, 2023 that will close this issue
@ianhelle
Copy link
Contributor

Added ability for use to set custom timeout.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
accepted The request/issue is accepted for a fix
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

3 participants