I am trying to get metric definition for resource using Azure rest api "https://management.azure.com/{resourceUri}/providers/microsoft.insights/metricDefinitions?api-version=2018-01-01".
But I get error response stating "metricDefinitions contains multiple copies of the extension api 'providers/microsoft.insights/metricdefinitions'".
Any idea what's wrong.
Related
Following couple of Questions I understand that the LUIS Authoring resource has a limit of 1000/month for testing in luis.ai and generating the Json view format.
LUIS gives 403 error “Out of call volume quota.” when testing in portal with using Authoring Resource F0
LUIS gives 403 response with "Out of call volume quota."
All the instances we have can be created within the Authoring resource only, while within the app / instance we can have a prediction resource. Currently, I have added prediction resource within my app, but I am not able to get through this error. Is there any other settings change that I should follow to make this happen? (include or use the prediction key etc.)
Thanks in Advance.
I was given a link to an OpenAPI 3.0.1 definition hosted on SwaggerHub, and was told to deploy it. On the Terraform side, I see way too many resources that confuse me, I'm not sure which one to use. What's the most straightforward way to deploy an API gateway via Terraform that's already all configured in an OpenAPI definition? Is there a resource that would simply let me provide an OpenAPI definition URL to the API gateway, or would I have to copy paste the actual JSON somewhere?
The AWS API Gateway service has two main usage patterns:
Directly specify individual resources, methods, requests, integrations, and responses as individual objects in the API Gateway API.
Submit an OpenAPI definition of the entire API as a single unit and have API Gateway itself split that out into all of the separate objects in API Gateway's data model.
Since the underlying API supports both models, it can be hard to see initially which parts are relevant to each usage pattern. The Terraform provider for AWS follows the underlying API design, and so that confusion appears there too.
It sounds like you are intending to take the second path I described above, in which case the definition in Terraform is comparatively straightforward, and in particular it typically involves only a single Terraform resource to define the API itself. (You may need to use others to "deploy" the API, etc, but that seems outside of the scope of your current question.)
The api_gateway_rest_api resource type is the root resource type for defining an API Gateway REST API, and for the OpenAPI approach is the only one required to define your entire API surface, by specifying the OpenAPI definition in its body argument:
resource "aws_api_gateway_rest_api" "example" {
name = "example"
body = file("${path.module}/openapi.json")
}
In the above example I've assumed that you've saved the API definition in JSON format in an openapi.json file in the same directory as the .tf file which would contain the resource configuration. I'm not familiar with SwaggerHub, but if there is a Terraform provider available for it which has a data source for retrieving the definition directly from that system then you could potentially combine those, but the principle would be the same; it would only be the exact expression for the body argument that would change.
The other approach with the resources/etc defined explicitly via the API Gateway API would have a separate resource for each of API Gateway's separate object types describing an API, which makes for a much more complicated Terraform configuration. However, none of those need be used (and indeed, none should be used, to avoid conflicts) when you have defined your API using an OpenAPI specification.
NOTE: The above is about API Gateway REST APIs, which is a separate offering from "API Gateway v2", which offers so-called "HTTP APIs" and "WebSocket APIs". As far as I know, API Gateway v2 doesn't support OpenAPI definitions and therefore I've assumed you're asking about the original API Gateway, and thus "REST APIs".
I am getting this error while trying to invoke azure function through the data factory. Snap of the error is attached.
I then again tried with the same parameters, and the next instance of execution just worked fine.
I just wanted to know if this problem is from azure server side or due to from my code.
Any help would be appreciated.
Call to provided Azure function 'OnCopySuccess' failed with
status-'InternalServerError' and message - 'Invoking Azure function
failed with HttpStatusCode - InternalServerError.
Has nothing to do with Azure DataFactory, it fails because of the Azure Functions, HAs from the error you will not be able to detect any issues so, you may examine the output of your azure function app using logs in kudu, in addition to the monitor of the azure function.
In addition, kudu log files are more timely than the Azure function's monitor.
Simply navigate to this website's address.
Click on the URL https://yourfunctionappname.scm.azurewebsites.net/DebugConsole
Go To: LogFiles\Application\Functions\Function\yourtriggername
The log files can then be found. The log file in Kudu is real-time, whereas the monitor takes a while to show (typically 5 minutes).
HTTP Function is supposed to actually return an HTTP result, See the Original Post - So you might check your Azure Function Code.
I'm trying to build a small program to change the autoscale settings for our Azure WebApps, using the Microsoft.WindowsAzure.Management.Monitoring and Microsoft.WindowsAzure.Management.WebSites NuGet packages.
I have been roughly following the guide here.
However, we are interested in scaling WebApps / App Services rather than Cloud Services, so I am trying to use the same code to read the autoscale settings but providing a resource ID for our WebApp. I have already got the credentials required for making a connection (using a browser window popup for Active Directory authentication, but I understand we can use X.509 management certificates for non-interactive programs).
This is the request I'm trying to make. Credentials already established, and an exception is thrown earlier if they're not valid.
AutoscaleClient autoscaleClient = new AutoscaleClient(credentials);
var resourceId = AutoscaleResourceIdBuilder.BuildWebSiteResourceId(webspaceName: WebSpaceNames.NorthEuropeWebSpace, serverFarmName: "Default2");
AutoscaleSettingGetResponse get = autoscaleClient.Settings.Get(resourceId); // exception here
The WebApp (let's call it "MyWebApp") is part of an App Service Plan called "Default2" (Standard: 1 small), in a Resource Group called "WebDevResources", in the North Europe region. I expect that my problem is that I am using the wrong names to build the resourceId in the code - the naming conventions in the library don't map well onto what I can see in the Azure Portal.
I'm assuming that BuildWebSiteResourceId is the correct method to call, see MSDN documentation here.
However the two parameters it takes are webspaceName and serverFarmName, neither of which match anything in the Azure portal (or Google). I found another example which seemed to be using the WebApp's geo region for webSpaceName, so I've used the predefined value for North Europe where our app is hosted.
While trying to find the correct value for serverFarmName in the Azure Portal, I found the Resource ID for the App Service Plan, which looks like this:
/subscriptions/{subscription-guid}/resourceGroups/WebDevResources/providers/Microsoft.Web/serverfarms/Default2
That resource ID isn't valid for the call I'm trying to make, but it does support the idea that a 'serverfarm' is the same as an App Service Plan.
When I run the code, regardless of whether the resourceId parameters seem to be correct or garbage, I get this error response:
<string xmlns="http://schemas.microsoft.com/2003/10/Serialization/">
{"Code":"SettingNotFound","Message":"Could not find the autoscale settings."}
</string>
So, how can I construct the correct resource ID for my WebApp or App Service Plan? Or alternatively, is there a different tree I should be barking up to programatially manage WebApp scaling?
Update:
The solution below got the info I wanted. I also found the Azure resource explorer at resources.azure.com extremely useful to browse existing resources and find the correct names. For example, the name for my autoscale settings is actually "Default2-WebDevResources", i.e. "{AppServicePlan}-{ResourceGroup}" which I wouldn't have expected.
There is a preview service https://resources.azure.com/ where you can inspect all your resources easily. If you search for autoscale in the UI you will easily find the settings for your resource. It will also show you how to call the relevant REST Api endpoint to read or update that resorce.
It's a great tool for revealing a lot of details for your deployed resources and it will actually give you an ARM template stub for the resource you are looking at.
And to answer your question, you could programmatically call the REST API from a client with updated settings for autoscale. The REST API is one way of doing this, the SDK another and PowerShell a third.
The guide which you're following is based on the Azure Service Management model, aka Classic mode, which is deprecated and only exists mainly for backward compatibility support.
You should use the latest
Microsoft.Azure.Insights nuget package for getting the autoscale settings.
Sample code using the nuget above is as below:
using Microsoft.Azure.Management.Insights;
using Microsoft.Rest;
//... Get necessary values for the required parameters
var client = new InsightsManagementClient(new TokenCredentials(token));
client.AutoscaleSettings.Get(resourceGroupName, autoScaleSettingName);
Besides, the autoscalesettings is a resource under the "Microsoft.Insights" provider and not under the "Microsoft.Web" provider, which explains why you are not able to find it with your serverfarm resourceId.
See the REST API Reference below for getting the autoscale settings.
GET
https://management.azure.com/subscriptions/{subscription-id}/resourceGroups/{resource-group-name}/providers/microsoft.insights/autoscaleSettings/{autoscale-setting-name}?api-version={api-version}
I've been looking around and I can't find a concise example around getting this metric. I've installed WindowsAzure.Management.Compute and now I don't know where to begin. How can this be done?
I would recommend you to take a look at Azure Resource Explorer: https://resources.azure.com. You could find the instances request URL as following:
For the Authorization header please have a look at this article. We can use C# HttpRequest to write the code. Here is the result I tested in fildder.
the endpoint:
https://management.azure.com/subscriptions/<subscription id>/resourceGroups/jatestgroup/providers/Microsoft.Web/sites/testcore1/instances?api-version=2015-08-01
Result:
We can calculate the instance number from the response json. In addition, it will need a long time in this rest API to show all instances when scale the instance in azure portal.
[Update]
According with my comment, I tested with the article:http://blog.amitapple.com/post/2014/03/access-specific-instance/#.V9tLKyh95hF
The following is my result:
Please download the library at here. Refer to this article for more information about Windows Azure Management Certificates.
Here is the code snipped:
var cert = new X509Certificate2();
cert.Import(Convert.FromBase64String(""));
var _client = new Microsoft.WindowsAzure.Management.WebSites.WebSiteManagementClient(new Microsoft.WindowsAzure.CertificateCloudCredentials("****", cert));
var ids= await _client.WebSites.GetInstanceIdsAsync("EastAsiawebspace", "testcore1");
You cannot get the instance count from within one instance of the Web App. But you can get it from the portal, or from the Azure ARM API (it's the numberOfWorkers property on the Web Hosting Plan object).
Also, note that WindowsAzure.Management.Compute does not apply to Azure Web App.