Ian Bennett
My feedback
-
21 votes
Monitoring solutions available for Managed Instance are summarized in this article: http://aka.ms/mi-monitoring
An error occurred while saving the comment Ian Bennett
supported this idea
·
-
6 votesIan Bennett
supported this idea
·
-
373 votes
Upvotes: 8
<=-=Mar 5 2017 2:42PM=-=>Thanks for this idea. This is a valid requirement and I hope that it will get more votes. Currently we cannot confirm when it will be added, but it is in our backlog.
<=-=May 22 2017 5:03AM=-=>would like it very much, particularly since you already have the CONCAT / GREATEST() a variable number of paramenters and does something with it…
<=-=Jun 5 2017 12:31PM=-=>GREATEST / LEAST functions would be fantastic addition.
<=-=Nov 14 2017 3:42PM=-=>The workarounds using CROSS APPLY or CASE expressions are difficult to manage and read. I’d love to see these implemented.
Ian Bennett
supported this idea
·
-
38 votes
Thanks for the feedback, keep votes coming!
Ian Bennett
supported this idea
·
-
147 votesIan Bennett
supported this idea
·
-
52 votes
An error occurred while saving the comment Ian Bennett
commented
@Andrew, OAuth is fine if you don't want to provide any user functionality such as per API security, self-service, per user monitoring etc. To do that, you have to either pay a fortune or get your internal users to sign up with personal microsoft accounts which is a bit tacky.
Ian Bennett
shared this idea
·
-
3 votesIan Bennett
supported this idea
·
-
6 votes
An error occurred while saving the comment Ian Bennett
commented
Agree that there needs to be some way to organise related Logic Apps. I have to use 3 Logic Apps just for overnight scheduling of lights at one site (1 to turn lights on, 1 to dim at a later time, 1 to turn off). If I am to roll this out in ernest I would likely end up with thousands of Logic Apps which will be a nightmare to manage, so am having to look at other solutions.
Ian Bennett
supported this idea
·
-
6 votesIan Bennett
shared this idea
·
-
4 votesIan Bennett
shared this idea
·
-
1 voteIan Bennett
shared this idea
·
-
3 votesIan Bennett
shared this idea
·
-
1 voteIan Bennett
shared this idea
·
-
779 votes
Update on this item.
Bytecode implementation is now targeting the first half of 2020 to provide stability and performance improvements in the platform.
Apologies for the delay. We are continuing to work on this. Will announce here when this becomes available.
Thanks.
Ian Bennett
supported this idea
·
-
18 votes
This capability is not on our road map today but we do provide query metrics using our SDK’s. You can read more about what we provide here, https://docs.microsoft.com/azure/cosmos-db/sql-api-sql-query-metrics#query-execution-metrics.
Thank you for your suggestion.
An error occurred while saving the comment Ian Bennett
commented
By "monitor" I mean individual queries and the focus on this suggestion was actually meant to be on the "killing" part. Its not hard to end up with rogue queries chewing up the RUs.
Ian Bennett
shared this idea
·
-
1 voteIan Bennett
shared this idea
·
-
22 votes
An error occurred while saving the comment Ian Bennett
commented
A trigger based on "Number of requests exceeded capacity" metric would be useful too. Logic flow might look something like if number of requests exceeds capacity > n then increase RU throughput by 10% with a maximum of x RUs.
Ian Bennett
shared this idea
·
-
1 voteIan Bennett
shared this idea
·
-
1,845 votes
We’re excited to announce that we are making this a lot easier with our preview of Autopilot. With Autopilot, Azure Cosmos DB will automatically manage and scale the RU/s of your containers based on the usage. This eliminates the need for custom scripting to change RU/s and makes it easier to handle bursty, unpredictable workloads.
You can try out Autopilot in your Cosmos accounts by going to the Azure Portal and enabling the feature in the “Preview Features” blade.
An error occurred while saving the comment Ian Bennett
commented
For partitioned collections it would be good if autoscale would work on a per partition basis to keep costs down. RU allocation across every partition can be inefficient as in the following examples.
1. RU allocation applies to all replicas. Using node.js SDK, it is not possible to direct queries to secondary replicas so that RU goes largely unused.
2. In some use cases it can be better for performance to only use 1 or 2 partitions at a time for read/writes but over time data is spread across all partitions. In this case the RU for all partitions not being actively used at the time are largely unused.
An error occurred while saving the comment Ian Bennett
commented
My suggestions are, in order of preference:
1. Allow setting of a max RU/s limit and auto scale between lowest possible and up to that limit
2. Bring back RU/m.
3. Allow scheduling of RU/s settings from the Portal (I know this can already be done in a convoluted fashion with command line).Ian Bennett
supported this idea
·
-
172 votesIan Bennett
supported this idea
·
Azure SQL Analytics is like Perfmon. Sure it can give you a lot of info but what do you see on everyone's desktop? - Task Manager, because it gives you the main information you need with 2 clicks - not 2 weeks of training, configuration and analysis. Handy, easy to use management tools have played an important part in the success of SQL Server and it is sad to see them being devalued by MS.