Am using Appdynamics to monitor my application hosted in IIS.
I have installed necessary dotnet agent in server and am getting the related metrics, but what I couldn't get is if the application is running or stopped. I couldn't figure how to configure if an application is up or not. Same case with the application pool.
All I can see is if their is no load on the server the AppServerAgent status is 0, but this cannot be used to check application is down or not.
Even tried to keep the HealthRules to check AppAvailability
RuleConfig
But couldn't get the desired results.
You can check if the agent is reporting / up by using the "Availability" metric in your Heath Rules (Agent > App > Availability).
In terms of Application Monitoring, AppDynamics monitors Business Transactions primarily. You will need to configure appropriate Business Transaction detection rules to have these register.
You can then set Health Rules based on any Business Transaction activity (which effectively represents Application activity).
Related
Would like to use Application insights especially, "Azure live metrics stream" feature on existing PROD Azure service fabric workloads to do performance analysis.Is service fabric has built-in integration with Azure Application Insights?
Is it possible do it in code less manner like how Application insights can be enabled via portal for web Apps/Azure functions? If not, why?
Then, how to do it code based manner? Any reference to do code changes would be helpful.
What is the difference between code less & code based monitoring? When to choose one over another? Our requirement is to study performance of application (deployed on various nodes of PROD service fabric cluster) under different load.
Please clarify above list of queries.
Is service fabric has built-in integration with Azure Application Insights?
You could leverage Windows Azure Diagnostics (WAD) extension to sink SF cluster logs and/or Perf metrics into App Insights - Configuring Application Insights with WAD
There is no way to monitor an application running in SF via AppInsights without a small amount of coding.
Then, how to do it code based manner? Any reference to do code changes would be helpful.
Here you go - Monitor and diagnose an ASP.NET Core application on Service Fabric using Application Insights.
What is the difference between code less & code based monitoring? When to choose one over another? Our requirement is to study performance of application (deployed on various nodes of PROD service fabric cluster) under different load.
As I said, to monitor your app you have to code. Although it's super simple. Other from that, here is a general recommendation - Event analysis and visualization with Application Insights:
It is recommended to use EventFlow and WAD as aggregation solutions,
because they allow for a more modular approach to diagnostics and
monitoring, i.e. if you want to change your outputs from EventFlow, it
requires no change to your actual instrumentation, just a simple
modification to your config file. If, however, you decide to invest in
using Application Insights and are not likely to change to a different
platform, you should look into using Application Insights' new SDK for
aggregating events and sending them to Application Insights. This
means that you will no longer have to configure EventFlow to send your
data to Application Insights, but instead will install the
ApplicationInsight's Service Fabric NuGet package.
Here is the link to the best practices - Monitoring and diagnostics on SF platform.
We have a web application that is using the IHostedService.
There is an example of this here
And the method we employed is detailed here
The goal was to have an application that continually ran background tasks. So we could schedule in jobs that run automatically at set times. This application is separate from all our other applications, so it's not visited by our user base.
So we needed a way for this application to run all the time on Azure.
We tried to set up an App Service for the application on Azure, but it seems that the application does not continually run. Things seem to run locally ok, but on Azure, I have to stop and restart the service before it kicks in the IHostedService tasks.
Is there a way on Azure to keep the application alive and running?
Ok, so in the App Settings in Azure, there is a setting Always On this worked for us. :)
We also found out from Azure support, that if you are on the lowest tier in their offered packages, this is treated as a "Development" environment and will only have limited up-time. As a result, we could expect the application to go offline when we reached that limit.
We argued that there should have been something more obvious in the dashboard for us to know this.
Once we upgraded to a Standard tier, the application stayed online.
Also, if you are running a hosted service and it hits an unhandled exception, this stops the service. You need to make sure you are handling exceptions for this to work.
I have a long running console application, using while(true)... structure
It implemented by using Net Core
What type of Azure App Service I should create to host that application ?
Decision tree for Azure compute services
Azure offers a number of ways to host your application code. The term compute refers to the hosting model for the computing resources that your application runs on. The following flowchart will help you to choose a compute service for your application. The flowchart guides you through a set of key decision criteria to reach a recommendation.
Treat this flowchart as a starting point. Every application has unique requirements, so use the recommendation as a starting point. Then perform a more detailed evaluation, looking at aspects such as:
Feature set
Service limits
Cost
SLA
Regional availability
Developer ecosystem and team skills
Compute comparison tables
I recommend reading this guide afterwards
Criteria for choosing an Azure compute service
Another great entry point for developers concerned with a similar question
.NET application architecture
You have to use "Azure App Service as a WebJob"
To deploy the .NET Core console application to an Azure App Service Web App Web Job access the Azure portal and navigate to the Azure App Service where you will host the WebJob.
Clicking on the Add button renders the blade
Once the WebJob is successfuly uploaded, it will render in the WebJob blade. Click on it and you will see the Run button. As this WebJob is a manually triggered job, you must click on the Run button in order for the job logic within the .NET Core console application to run.
After starting the .NET Core WebJob, click on the Logs link and a new browser tab is opened and you can see the most current state of the WebJob
I remember reading that the DNN platform edition struggles with the MS Azure web app environment in regards to the scheduler tasks.
this quote comes for this DNN connect blog
The DNN Platform / Community scheduler does not support Azure Web
Sites as the server names running the web site are ever changing as
Azure scales up and down, or upgrades underlying machines. There is a
solution for Evoq.
I am getting the following scheduler errors in my DNN instances on Azure:
THREAD ID:59
TYPE:DotNetNuke.Services.Search.SearchEngineScheduler,DOTNETNUKE
EXCEPTION:Lock obtain timed out:
NativeFSLock#D:\home\site\wwwroot\App_Data\Search\write.lock
It is happening A LOT. THis is on a 08.00.04 version
I am also getting the following error on a 08.00.01 version
TYPE:DotNetNuke.Services.Scheduling.PurgeScheduleHistory, DOTNETNUKE
EXCEPTION:Execution Timeout Expired. The timeout period elapsed prior
to completion of the operation or the server is not responding.
My question is whether dnn platform's scheduler works properly in the azure web app environment, and what version saw this delivered. This will help me in getting these errors resolved.
Thanks
We often host Test and QA Evoq environments in Azure and the machine names do change, therefore require us to reactivate licensing. But these are on the Free or Shared pricing tiers. I believe if you move to Basic and above, the environment should be dedicated. You can also confirm with DNN Corp on this because their own OnDemand hosting uses Azure.
The Search write-lock error I have seen on other environments so I don't believe it's an Azure problem necessarily. For this issue, restart the app pool and delete all files in the App_Data\Search folder. Then start the site, go to Settings > Site Settings > Search and click the Re-index Content button. Then start the Site Crawler job from the scheduler. Ensure in Site Settings > Servers > Server Settings > Web Servers, that only the current server name is there -- delete any old server names. In Settings > Scheduler, edit the Search: Site Crawler task. In the Servers textbox, you can enter the name of the server so that it ensures it only runs on that server to ensure no overlap in processing (thinking it's in webfarm mode).
I am trying to implement SignalR hubs on my REST service (ASP.NET Web Api) hosted on azure. I've been reading some common stuff related to SignalR and I came to this one that it is server bound. You can check here. Which means that in order to be able to scale it on multiple server instancs I have to do some additional stuff. So, then, I started to ask myself "How many instances do I currently have running of my REST service on Azure? How do I know that?"
So, what I did was - I navigated to azure portal and opened my service > Process explorer
Does that mean than my web app scales automatically and I currently have 2 instances of my web api runing? I think it clearly says that there's currently only one instaces of it running 2 processes but how do I know if it will scale some time in the future?
No, your photo shows your app process and Kudu, which is a management interface you can access at https://yourappname.scm.azurewebsites.net.
You can see the instance count in your app's App Service Plan. If it is on Free or Shared, there can only be one. If it is Basic/Standard/Premium, it is one by default. If you haven't setup auto-scale, it won't scale to more than 1 instance unless you tell it to.