Forum Discussion
Why does the REST API of Application Insights not support to save searches/queries
emileer Got it -- this helps. Assuming you're using Workbooks with queries, the best way to do this is not via REST but with an ARM template from my POV. You can export an existing workbook using the process shown in my screen shot and use, as part of your devops process, an "ARM deployment" task or us PowerShell or the CLI to push this into the subscription/environment with a new App Insights Workspace. You would need the resource ID of the App Insights workspace as shown in my screenshot.
CloudyRyan - thanks ! Your solution will definitely work with workbooks.
There are however some scenarios that cannot use the approach mentioned above.
Here is an example:
- we analyze the application logs and create patterns for error entries (like: startswith("Exception123"), etc.)
- all these patterns are stored in a configuration file (whitelisted_error_patterns.json).
- at deployment time, we create (on the fly) a query that filters out all known error patterns and create an alert if the number of entries is > 0
- if the alert triggers, the service guys just have to click on the link and see in the portal all log entries that are not matched.
With this approach we achieve a total control of the log entries produced by our application.
If it helps, I can give you a short demo on how we us the whole processing chain.
emileer What about creating the alert based on the Azure monitor query on the fly? https://docs.microsoft.com/en-us/rest/api/loganalytics/savedsearches (App Insights is under the umbrella of Azure monitor).
CloudyRyan it is much easier to handle if the alert only references a function and the logic is stored in the function (compared having the logic in the alert).
We do have a pipeline to deploy alerts, and the task is always performed after deploying the queries/functions.
It is also much easier to refine the queries (add new patterns) if they can be accessed directly from the portal.
In AppInsights you can save queries from the portal, but not programmatically via an exposed API (which is strange since internally the API must exist).