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.
Related
I have an application hosted in Azure PAAS. The connection string for the application is stored under 'Configuration' -> 'Connection strings'
My application has a PowerShell instance. I want to iterate through all the Connection strings present under 'Configuration' -> 'Connection strings'
I have seen the Azure document. As my application itself is the app, can there be a way to skip the details like 'subscriptionId', 'resourceGroupName' and 'name'?
This will help to make the code more generic.
As my application itself is the app, can there be a way to skip the
details like 'subscriptionId', 'resourceGroupName' and 'name'?
AFAIK, Its not possible to acquire the connection strings using Rest API, or PowerShell of an Azure web application without providing Resource group name or subscription.
The MS DOCUMENT you have followed is to list the connection strings which is correct but we need to pass those credentials to achieve the same.
If my understanding is correct as its your own application and if its publicly hosted then anyone will not be able to get the resource group name, application name(If you are using custom domain) or subscription details.
Alternatively, we can use the Az cli by providing the resource group only :-
For more information please refer the below links:-
SO THREAD|Get the list of azure web app settings to be swapped using PowerShell
If you are going to use the REST API calls for your code, then the simple answer is just: No.
I think in all cases the answer is going to be no honestly..
You can't drop those unique IDs, because those are required parameters to retrieve the correct data.
If you want to make the code more generic, then you should write the code to retrieve the values for those parameters. Instead of hardcoding the values.
Your powershell code will always need to authenticate, or use a Managed Identity, and the identity used to authenticate will always have the subscriptionid as value in its object. As for the rest, well i think you get the gist of what im suggesting.
I am accessing my configuration stored in Azure Appconfiguration. I am using SDK (Azure.Data.AppConfiguration) from Azure function. Following the example from https://github.com/Azure/azure-sdk-for-net/blob/Azure.Data.AppConfiguration_1.0.2/sdk/appconfiguration/Azure.Data.AppConfiguration/samples/Sample2_HelloWorldExtended.md
I am keep getting 400 error.
Following is my code
var client = new ConfigurationClient(_azureAppConfigurationOptions.ConnectionString);
ConfigurationSetting setting = client.
GetConfigurationSetting(
"appid");
the only difference is i am calling from Azure functions.
Any help or insight is appreciated.
When try to get configuration(app settings) in azure function, you should use this method Environment.GetEnvironmentVariable(xxx).
Please refer to this article for details.
Is it possible to use the cross-resource query (with 2 subscriptions) from the an Application-Insights resource's, Logs(Analytics) blade in the Azure portal?
I've managed to use the full qualified name for the same app I'm using!
i.e. using
app("/subscriptions/sub1/resourceGroups/rg1/providers/microsoft.insights/components/apptelemetry1").requests in apptelemetry1 returns the same result as the query requests. But trying to use a similar query for an app in another subscription doesn't work (I've double checked the resources names many times).
I've Tried using the all of the options listed in app-expression,
cross-workspace-query.
(Resource name, Qualified Name, ID, Azure Resource ID).
The only response I'm getting is: "The following application isn’t available anymore".
Since you cannot use this query app("/subscriptions/sub1/resourceGroups/rg1/providers/microsoft.insights/components/apptelemetry1").requests in the application insights instance apptelemetry1 itself, there must be some problem with the instance apptelemetry1.
You can check if you have the read access to the application.
And if it's still cannot after assign read access, you can submit a support ticket where you can get professional help from Microsoft.
So I'm fairly new to working with Azure and there are some things I can't quite wrap my head around. One of them being the Azure Storage Account.
My web jobs keeps stopping with the following error "Unhandled Exception: System.InvalidOperationException: The account credentials for '[account_name]' are incorrect." Understanding the error however is not the problem, at least that's what I think. The problem lies in understanding why I need an Azure Storage Account to overcome it.
Please read on as I try to take you through the steps taken thus far. Hopefuly the real question will become more clear to you.
In my efforts to deploy a WebJob on Azure we have created the following resources so far:
App Service Plan
App Service
SQL server
SQL database
I'm using the following code snippet to prevent my web job from exiting:
JobHostConfiguration config = new JobHostConfiguration();
config.DashboardConnectionString = null;
new JobHost(config).RunAndBlock();
To my understanding from other sources the Dashboard connection string is optional but the AzureWebJobsStorage connection string is required.
I tried setting the required connection string in portal using the configuration found here.
DefaultEndpointsProtocol=[http|https];AccountName=myAccountName;AccountKey=myAccountKey
Looking further I found this answer that clearly states where I would get the values needed, namely an/my missing Azure Storage Account.
So now for the actualy question: Why do I need an Azure Storage Account when I seemingly have all the resources I need place for the WebJob to run? What does it do? Is it a billing thing, cause I thought we had that defined in the App Service Plan. I've tried reading up on Azure Storage Accounts over here but I need a bit more help understanding how it relates to everything.
From the docs:
An Azure storage account provides resources for storing queue and blob data in the cloud.
It's also used by the WebJobs SDK to store logging data for the dashboard.
Refer to the getting started guide and documentation for further information
The answer to your question is "No", it is not mandatory to use Azure Storage when you are trying to setup and run a Azure web job.
If you are using JobHost or JobHostConfiguration then there is indeed a dependency for Storage accounts.
Sample code snippet is give below.
class Program
{
static void Main()
{
Functions.ExecuteTask();
}
}
public class Functions
{
[NoAutomaticTrigger]
public static void ExecuteTask()
{
// Execute your task here
}
}
The answer is no, you don't. You can have a WebJob run without being tied to an Azure Storage Account. Like Murray mentioned, your WebJob dashboard does use a storage account to log data but that's completely independent.
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}