Showing posts with label dashboard. Show all posts
Showing posts with label dashboard. Show all posts

Monday 30 October 2023

Thoughts on Logging and Monitoring

Overview:  I mainly work in the Microsoft stack, so my default for logging as Azure Monitor.  Log Analytics/Workspace and Application Insights fall under the term Azure Monitor.  

Going forward MS are storing App Insight logging data within a Log analytics instance.

There are 4 options for displaying/analysis logs in Azure:

  1. Azure Dashboards
  2. Power BI
  3. Grafana
  4. Workspaces

SIEM tools take in logs from various sources such as Azure Log Analytics, Defender, other vendors Prometheus logs or Open Telemetry.  

Grafana can be used on most SIEMS including Dynatrace, NewRelic, Microsoft Sentinel, or Azure Monitor.  Grafana supports PromQL and has fantastic dashboarding.

Tuesday 20 June 2023

App Insights for Power Platform - Part 7 - Monitoring Azure Dashboards

Series

App Insights for Power Platform - Part 1 - Series Overview 

App Insights for Power Platform - Part 2 - App Insights and Azure Log Analytics 

App Insights for Power Platform - Part 3 - Canvas App Logging (Instrumentation key)

App Insights for Power Platform - Part 4 - Model App Logging

App Insights for Power Platform - Part 5 - Logging for APIM 

App Insights for Power Platform - Part 6 - Power Automate Logging

App Insights for Power Platform - Part 7 - Monitoring Azure Dashboards (this post)

App Insights for Power Platform - Part 8 - Verify logging is going to the correct Log analytics

App Insights for Power Platform - Part 9 - Power Automate Licencing

App Insights for Power Platform - Part 10 - Custom Connector enable logging

App Insights for Power Platform - Part 11 - Custom Connector Behaviour from Canvas Apps Concern

Overview: Azure Dashboards are excellent but, if you want beautiful dashboards use the Azure Grafana service or Power BI dashboards.

It's always difficult to identify KPI's and graphs to allow support and stakeholders to quickly digest monitoring information.  An option is to have an overview for the PM, PO, Business owners,,, and a separate set of dashboards for support.

Identify What is important?  End-to-end testing is always nice especially if running CI to detect abnormalities.

For instance, this Azure Dashboard, fires of a Canvas App recorded Test (done using test studio) and shows the speed (performance) of the run, i then warn the user if the performance is too slow.  I also grab the oldest successful run from 7 days ago to check if performance is considerably different.  

Power automate has it's own logging, but integrating log entries when a error occurs via Log analytics, allows me to see if any of my workflows have a problem.  This is discussed in part 6 of the logging series on Flows.

Azure services are often used when building solutions using the Power Platform.  The most common are Functions, App Services, APIM, Service Bus, maybe sendgrid.  So we need to know that they are working, and help the user see performance or issues.  Here are a couple of examples.





Series

App Insights for Power Platform - Part 1 - Series Overview 

App Insights for Power Platform - Part 2 - App Insights and Azure Log Analytics 

App Insights for Power Platform - Part 3 - Canvas App Logging (Instrumentation key)

App Insights for Power Platform - Part 4 - Model App Logging

App Insights for Power Platform - Part 5 - Logging for APIM 

App Insights for Power Platform - Part 6 - Power Automate Logging

App Insights for Power Platform - Part 7 - Monitoring Azure Dashboards (this post)

App Insights for Power Platform - Part 8 - Verify logging is going to the correct Log analytics

App Insights for Power Platform - Part 9 - Power Automate Licencing

App Insights for Power Platform - Part 10 - Custom Connector enable logging

App Insights for Power Platform - Part 11 - Custom Connector Behaviour from Canvas Apps Concern


Saturday 11 April 2015

Empty Developer Dashboard in SP2013

Problem: No data is showing up on the developer dashboard in SharePoint 2013.

Initial Hypothesis:  My initial thoughts where around the SSL cert issue on the VM or potentially Fiddler causing the dev dashboard to be empty.  after looking at the ULS a good developer could see the Usage and Health Data Collection Service Application was not working.

http://www.wictorwilen.se/sharepoint-2013-developer-dashboard-shows-no-data-issue

Resolution: Once the Usage SSA was configured, the dashboard started working.

Saturday 26 October 2013

The Developer Dashboard in SharePoint 2013

Overview:  The Developer Dashboard is a great tool added to SharePoint in the 2010 version.  SharePoint 2013 has additional features and a new look.  This post explores the new developer dashboard.
SharePoint 2013 Dev dashboard, note the new tabs that have been added.
 







Tuesday 4 January 2011

Developer dashboard custom scoped monitoring

Problem: You have poor performing code how do you identify the bottleneck.
Initial Hypothesis: Use the SPMonitoredScope to determine how long code takes to execute.
Resolution: Turn on the developer dashboard, deploy your custom code that includes monitored code.
Exampleusing Microsoft.SharePoint.Utilities 
using (new SPMonitoredScope(“My Scope Name”))
{
   doSomeWork();    //  Shows in the ULS and the Developer dashboard
}
Tip: You can't use SPMonitorScope in sandbox solution code.  If you try us 'SPMonitorScope' your VS project won't compile and you will get the error: 'Microsoft.SharePoint.Utilities.SPMonitoredScope' is inaccessible due to its protection level.

More Info:
Post explaining how to turn on the developer dashboard
MSDN about using SPMonitorScope (like stopwatch in .NET)

Friday 5 November 2010

Dropdownbox population options for custom SharePoint applications

Problem: I need to populate combo boxes and drop down list boxes on a customised SharePoint page using a web part.  The web part has 5 of these lists that are populated choice fields.

Initial Hypothesis: I could use the Enum generated by Linq to SharePoint for the choice field options but to change the available options would require me to re-generate the SPMetal proxy.  I could use lookup lists and then use Linq to SharePoint but this is pretty heavy for simple choice columns.  So I chose to use the SP Server-side Object Model, this is not too heavy as it is only looking up the columns and looping thru the choices however I have 5 drop down lists doing this repeatedly for a lot of users.  So although it is working it could be better if the results were cached for a minute.  This would allow choice options to be change and the using a cache duration of 1 minute, the longest the wait would be is 60 seconds before users see the updated lists.

Resolution: I cached my list item collections, on the page I had 5 choice fields.  By adding the caching I am getting a 36% performance increase in my Page Request response time.  So not as good a return as I was expecting but still a considerable improvement. 

Test Information:
I used a sample of 10 items per request type.  The 10 pages requested each for the cached list item collections and the un-cached version.  I excluded the 1st page request for warm up. 
All the results were pretty consistent.
The testing was done on a local development machine.
Developer Dashboard showing improved response times using cacheing.
Code to cache list item collections:
HttpContext.Current.Cache.Insert(keyname, null, DateTime.Now.AddMinutes(1), Cache.NoSlidingExpiration)

Saturday 31 July 2010

Best Practice Sharepoint 2010 coding tips

1.> SharePoint Dispose Checker Tool - Run the SP Dispose Checker Tool on all custom code you write.
SPSite & SPWeb object has a big load and we need to ensure dispose is always called. 2 easiest ways to ensure Site and web objects are always disposed are shown below:
SPSite site;
try
{
site = new SPSite("http://demo1"); // Create the SPSite object
...
}
finally
{
if (site != null) // Check if the SPSite object exists
{
site.Dispose(); // Clean up the SPSite object as it has not be disposed of
}
}

Alternatively I prefer to use using statements
using (SPSite site = new SPSite(http://demo1/))
{

.... // SPSite.Dispose method will be called always
}
Run the SPDisposeCheck tool on all code before deploying outside of you development environment, this can be automated into VS 2010.
2.> Have at least 3 environments i.e. don't send code from the developers machine straight into production. Sandboxed solutions alleviates this risk to some degree but use a UAT, pre-prod, QA environment. Your deployment environment must mimic production as closely as possible i.e. ensure there is a separate SQL DB, all versions of software are identical, load balancing is setup. Have documented change control. Try perform changes through scripts not manual changes if possible. Web.config changes need to be replicated to all servers on the farm so doing the change manually is not the best option. Change the web.config via code to ensure it is done through the configuration database so they are changed on all web.config's in the farm.
3.> Error handling, catch errors as specifically as possible, die gracefully and appropriately, log the errors, check the production error logs periodically.
4.> Deploy code using wsp solutions. Ensure code is not in debug mode when compiled, it runs slower and potentially can crash/holdup your production environment. Implement CAS, deploy to bins if possible and apply CAS security policies to custom coding. Perform peer code reviews, it ensures coding standards are being followed, developers learn from each other, bugs are often picked up pre-testing and it increases team members knowledge that reduces maintenance costs.
5.> Develop using source control no matter how smal the dev project is. Preferably TFS 2010 but VSS 2005 is even fine, failing this use CVS, IMB/rationals ClearCase for source control. Also have bug tracking with TFS the integration is excellent between the bugs and the source control. I.e. use TFS if possible.
6.> SharePoint projects are often very good candidates to SCRUM or other agile methodologies. Use them if it's appropriate. Traditional formal SDLC / waterfall approaches tend to work well on the larger SharePoint projects.
7.> Use the developer dashboard.
8.> Unit testing - don't test SharePoints API, test your custom code. In MOSS Type Mock isolator was a great product for SharePoint I presume this is still the way to go. Andrew Woodward is a good blogger on SP unit testing.

Friday 4 June 2010

SharePoint 2010 Developer dashboard

Overview: Developer dashboard allows you to see all calls made from a page under the page in the browser. This allows you to identify poorly performing code & bottle necks. You can see the call stack and the time it takes to perform each call.
OOTB the developer dashboard it turned off. Turn it on using an stsadm cmd or powershell cmd.

Developer dashboard can be setup to allow only certain users to view the stats, this means other users don't suffer the additional resource calls but the developer/administrator can view poorly performing code & page statistics.

Stsadm Method:
1.> Open a cmd prompt running as an administrator
2.> go to: c:\program files\common files\microsoft shared\web server extensions\14\bin and
3.> run the following cmd:
stsadm -o setproperty -pn developer-dashboard -pv ondemand
Cmd prompt to turn on the developer dashboard
4.> In the browser click the developer dashboard icon in the top right of the page, as shown below. On the page you can now see the page call information.

Web Services Using the Object Model (Web Serives) Method:
SPWebService cs = SPWebService.ContentService;
cs.DeveloperDashboardSettings.DisplayLevel = SPDeveloperDashboardLevel.On;
cs.DeveloperDashboardSettings.Update();
 
Powershell Method:
$db =[Microsoft.SharePoint.Administration.SPWebService]::ContentService.DeveloperDashboardSettings;
$db.DisplayLevel = 'On';
$db.TraceEnabled = $true;
$db.Update()