Consolidate pages

Author: cdpark

.openpublishing.redirection.json

@@ -3483,6 +3483,16 @@
             "redirect_url": "/azure/service-fabric/monitor-service-fabric",
             "redirect_document_id": false
         },
+        {
+            "source_path_from_root": "/articles/service-fabric/service-fabric-diagnostics-event-generation-perf.md",
+            "redirect_url": "/azure/service-fabric/monitor-service-fabric-reference#performance-metrics",
+            "redirect_document_id": false
+        },
+        {
+            "source_path_from_root": "/articles/service-fabric/service-fabric-diagnostics-event-generation-app.md",
+            "redirect_url": "/azure/service-fabric/monitor-service-fabric#application-monitoring",
+            "redirect_document_id": false
+        },
         {
             "source_path_from_root": "/articles/virtual-desktop/partners.md",
             "redirect_url": "https://azuremarketplace.microsoft.com/marketplace/apps?page=1&search=azure%20virtual%20desktop",

articles/service-fabric/monitor-service-fabric-reference.md

@@ -18,7 +18,7 @@ See [Monitor Service Fabric](monitor-service-fabric.md) for details on the data
 Azure Monitor doesn't collect any platform metrics or resource logs for Service Fabric. You can monitor and collect:
 
 - Service Fabric system, node, and application events. For the full event listing, see [List of Service Fabric events](service-fabric-diagnostics-event-generation-operational.md).
-- Windows performance counters on nodes and applications. For the list of performance counters, see [Performance metrics](service-fabric-diagnostics-event-generation-perf.md).
+- Windows performance counters on nodes and applications. For the list of performance counters, see [Performance metrics](#performance-metrics).
 - Cluster, node, and system service health data. You can use the [FabricClient.HealthManager property](/dotnet/api/system.fabric.fabricclient.healthmanager) to get the health client to use for health related operations, like report health or get entity health.
 - Metrics for the guest operating system (OS) that runs on a cluster node, through one or more agents that run on the guest OS.
 
@@ -27,9 +27,74 @@ Azure Monitor doesn't collect any platform metrics or resource logs for Service
   > [!NOTE]
   > The Azure Monitor agent replaces the previously-used Azure Diagnostics extension and Log Analytics agent. For more information, see [Overview of Azure Monitor agents](/azure/azure-monitor/agents/agents-overview).
 
+## Performance metrics
+
+Metrics should be collected to understand the performance of your cluster as well as the applications running in it. For Service Fabric clusters, we recommend collecting the following performance counters.
+
+### Nodes
+
+For the machines in your cluster, consider collecting the following performance counters to better understand the load on each machine and make appropriate cluster scaling decisions.
+
+| Counter Category | Counter Name |
+| --- | --- |
+| Logical Disk | Logical Disk Free Space |
+| PhysicalDisk(per Disk) | Avg. Disk Read Queue Length |
+| PhysicalDisk(per Disk) | Avg. Disk Write Queue Length |
+| PhysicalDisk(per Disk) | Avg. Disk sec/Read |
+| PhysicalDisk(per Disk) | Avg. Disk sec/Write |
+| PhysicalDisk(per Disk) | Disk Reads/sec |
+| PhysicalDisk(per Disk) | Disk Read Bytes/sec |
+| PhysicalDisk(per Disk) | Disk Writes/sec |
+| PhysicalDisk(per Disk) | Disk Write Bytes/sec |
+| Memory | Available MBytes |
+| PagingFile | % Usage |
+| Processor(Total) | % Processor Time |
+| Process (per service) | % Processor Time |
+| Process (per service) | ID Process |
+| Process (per service) | Private Bytes |
+| Process (per service) | Thread Count |
+| Process (per service) | Virtual Bytes |
+| Process (per service) | Working Set |
+| Process (per service) | Working Set - Private |
+| Network Interface(all-instances) | Bytes recd |
+| Network Interface(all-instances) | Bytes sent |
+| Network Interface(all-instances) | Bytes total |
+| Network Interface(all-instances) | Output Queue Length |
+| Network Interface(all-instances) | Packets Outbound Discarded |
+| Network Interface(all-instances) | Packets Received Discarded |
+| Network Interface(all-instances) | Packets Outbound Errors |
+| Network Interface(all-instances) | Packets Received Errors |
+
+### .NET applications and services
+
+Collect the following counters if you are deploying .NET services to your cluster. 
+
+| Counter Category | Counter Name |
+| --- | --- |
+| .NET CLR Memory (per service) | Process ID |
+| .NET CLR Memory (per service) | # Total committed Bytes |
+| .NET CLR Memory (per service) | # Total reserved Bytes |
+| .NET CLR Memory (per service) | # Bytes in all Heaps |
+| .NET CLR Memory (per service) | Large Object Heap size |
+| .NET CLR Memory (per service) | # GC Handles |
+| .NET CLR Memory (per service) | # Gen 0 Collections |
+| .NET CLR Memory (per service) | # Gen 1 Collections |
+| .NET CLR Memory (per service) | # Gen 2 Collections |
+| .NET CLR Memory (per service) | % Time in GC |
+
+### Service Fabric's custom performance counters
+
+Service Fabric generates a substantial amount of custom performance counters. If you have the SDK installed, you can see the comprehensive list on your Windows machine in your Performance Monitor application (Start > Performance Monitor).
+
+In the applications you are deploying to your cluster, if you are using Reliable Actors, add counters from `Service Fabric Actor` and `Service Fabric Actor Method` categories (see [Service Fabric Reliable Actors Diagnostics](service-fabric-reliable-actors-diagnostics.md)).
+
+If you use Reliable Services or Service Remoting, we similarly have `Service Fabric Service` and `Service Fabric Service Method` counter categories that you should collect counters from, see [monitoring with service remoting](service-fabric-reliable-serviceremoting-diagnostics.md) and [reliable services performance counters](service-fabric-reliable-services-diagnostics.md#performance-counters).
+
+If you use Reliable Collections, we recommend adding the `Avg. Transaction ms/Commit` from the `Service Fabric Transactional Replicator` to collect the average commit latency per transaction metric.
+
 [!INCLUDE [horz-monitor-ref-logs-tables](~/reusable-content/ce-skilling/azure/includes/azure-monitor/horizontals/horz-monitor-ref-logs-tables.md)]
 
-### Service Fabric Clusters
+### Service Fabric clusters
 Microsoft.ServiceFabric/clusters
 
 - [AzureActivity](/azure/azure-monitor/reference/tables/AzureActivity#columns)
@@ -44,4 +109,3 @@ Microsoft.ServiceFabric/clusters
 - See [Monitor Service Fabric](monitor-service-fabric.md) for a description of monitoring Service Fabric.
 - See [Monitor Azure resources with Azure Monitor](/azure/azure-monitor/essentials/monitor-azure-resource) for details on monitoring Azure resources.
 - See [List of Service Fabric events](service-fabric-diagnostics-event-generation-operational.md) for the list of Service Fabric system, node, and application events.
-- See [Performance metrics](service-fabric-diagnostics-event-generation-perf.md) for the list of Windows performance counters on nodes and applications.

articles/service-fabric/monitor-service-fabric.md

@@ -31,10 +31,6 @@ You can monitor how your applications are used, the actions taken by the Service
 
 [Service Fabric Explorer](service-fabric-visualizing-your-cluster.md), a desktop application for Windows, macOS, and Linux, is an open-source tool for inspecting and managing Azure Service Fabric clusters. To enable automation, every action that can be taken through Service Fabric Explorer can also be done through PowerShell or a REST API.
 
-### Application Insights
-
-Application Insights integrates with Service Fabric to provide Service Fabric specific metrics and tooling experiences for Visual Studio and Azure portal. Application Insights provides a comprehensive out-of-the-box logging experience. For more information, see [Event analysis and visualization with Application Insights](service-fabric-diagnostics-event-analysis-appinsights.md).
-
 ## Application monitoring
 
 Application monitoring tracks how features and components of your application are being used. You want to monitor your applications to make sure issues that impact users are caught. The responsibility of application monitoring is on the users developing an application and its services since it is unique to the business logic of your application. Monitoring your applications can be useful in the following scenarios:
@@ -45,9 +41,24 @@ Application monitoring tracks how features and components of your application ar
 * What is happening within the services running inside my containers?
 
 The great thing about application monitoring is that developers can use whatever tools and framework they'd like since it lives within the context of your application! You can learn more about the Azure solution for application monitoring with Azure Monitor Application Insights in [Event analysis with Application Insights](service-fabric-diagnostics-event-analysis-appinsights.md).
+
 We also have a tutorial with how to [set this up for .NET Applications](service-fabric-tutorial-monitoring-aspnet.md). This tutorial goes over how to install the right tools, an example to write custom telemetry in your application, and viewing the application diagnostics and telemetry in the Azure portal.
 
-For more information on application monitoring, see [Application logging](service-fabric-diagnostics-event-generation-app.md).
+### Application logging
+
+Instrumenting your code is not only a way to gain insights about your users, but also the only way you can know whether something is wrong in your application, and to diagnose what needs to be fixed. Although technically it's possible to connect a debugger to a production service, it's not a common practice. So, having detailed instrumentation data is important.
+
+Some products automatically instrument your code. Although these solutions can work well, manual instrumentation is almost always required to be specific to your business logic. In the end, you must have enough information to forensically debug the application. Service Fabric applications can be instrumented with any logging framework. This section describes a few different approaches to instrumenting your code, and when to choose one approach over another.
+
+- **Application Insights SDK**: Application Insights has a rich integration with Service Fabric out of the box. Users can add the AI Service Fabric nuget packages and receive data and logs created and collected viewable in the Azure portal. Additionally, users are encouraged to add their own telemetry in order to diagnose and debug their applications and track which services and parts of their application are used the most. The [TelemetryClient](/dotnet/api/microsoft.applicationinsights.telemetryclient) class in the SDK provides many ways to track telemetry in your applications. For more information, see [Event analysis and visualization with Application Insights](service-fabric-diagnostics-event-analysis-appinsights.md).
+
+    Check out an example of how to instrument and add application insights to your application in our tutorial for [monitoring and diagnosing a .NET application](service-fabric-tutorial-monitoring-aspnet.md)
+
+- **EventSource**: When you create a Service Fabric solution from a template in Visual Studio, an **EventSource**-derived class (**ServiceEventSource** or **ActorEventSource**) is generated. A template is created, in which you can add events for your application or service. The **EventSource** name **must** be unique, and should be renamed from the default template string MyCompany-<solution>-<project>. Having multiple **EventSource** definitions that use the same name causes an issue at run time. Each defined event must have a unique identifier. If an identifier is not unique, a runtime failure occurs. Some organizations preassign ranges of values for identifiers to avoid conflicts between separate development teams. For more information, see [Vance's blog](/archive/blogs/vancem/introduction-tutorial-logging-etw-events-in-c-system-diagnostics-tracing-eventsource) or the [MSDN documentation](/previous-versions/msp-n-p/dn774985(v=pandp.20)).
+
+- **ASP.NET Core logging**: It's important to carefully plan how you will instrument your code. The right instrumentation plan can help you avoid potentially destabilizing your code base, and then needing to reinstrument the code. To reduce risk, you can choose an instrumentation library like [Microsoft.Extensions.Logging](https://www.nuget.org/packages/Microsoft.Extensions.Logging/), which is part of Microsoft ASP.NET Core. ASP.NET Core has an [ILogger](/dotnet/api/microsoft.extensions.logging.ilogger) interface that you can use with the provider of your choice, while minimizing the effect on existing code. You can use the code in ASP.NET Core on Windows and Linux, and in the full .NET Framework, so your instrumentation code is standardized.
+
+For examples on how to use these suggestions, see [Add logging to your Service Fabric application](service-fabric-how-to-diagnostics-log.md).
 
 ## Platform (cluster) monitoring
 
@@ -86,9 +97,7 @@ Now that we've covered the diagnostics in your application and the platform, how
 * Am I utilizing my hardware efficiently? Do you want to use your hardware at 90% CPU or 10% CPU. This comes in handy when scaling your cluster, or optimizing your application's processes.
 * Can I predict infrastructure issues proactively? - many issues are preceded by sudden changes (drops) in performance, so you can use performance counters such as network I/O and CPU utilization to predict and diagnose the issues proactively.
 
-A list of performance counters that should be collected at the infrastructure level can be found at [Performance metrics](service-fabric-diagnostics-event-generation-perf.md).
-
-Service Fabric also provides a set of performance counters for the Reliable Services and Actors programming models. If you are using either of these models, these performance counters can information to ensure that your actors are spinning up and down correctly, or that your reliable service requests are being handled fast enough. For more information, see [Monitoring for Reliable Service Remoting](service-fabric-reliable-serviceremoting-diagnostics.md#performance-counters) and [Performance monitoring for Reliable Actors](service-fabric-reliable-actors-diagnostics.md#performance-counters).
+A list of performance counters that should be collected at the infrastructure level can be found at [Performance metrics](monitor-service-fabric-reference.md#performance-metrics).
 
 Azure Monitor Logs is recommended for monitoring cluster level events. After you configure the [Log Analytics agent](service-fabric-diagnostics-oms-agent.md) with your workspace, you can collect:
 

articles/service-fabric/service-fabric-best-practices-applications.md

@@ -70,7 +70,7 @@ Service Fabric Reliable Actors enables you to easily create stateful, virtual ac
 
 
 ## Application diagnostics
-Be thorough about adding [application logging](./service-fabric-diagnostics-event-generation-app.md) in service calls. It will help you diagnose scenarios in which services call each other. For example, when A calls B calls C calls D, the call could fail anywhere. If you don't have enough logging, failures are hard to diagnose. If the services are logging too much because of call volumes, be sure to at least log errors and warnings.
+Be thorough about adding [application logging](monitor-service-fabric.md#application-logging) in service calls. It will help you diagnose scenarios in which services call each other. For example, when A calls B calls C calls D, the call could fail anywhere. If you don't have enough logging, failures are hard to diagnose. If the services are logging too much because of call volumes, be sure to at least log errors and warnings.
 
 ## Design guidance on Azure
 * Visit the [Azure architecture center](/azure/architecture/microservices/) for design guidance on [building microservices on Azure](/azure/architecture/microservices/).

articles/service-fabric/service-fabric-best-practices-monitoring.md

@@ -35,7 +35,7 @@ Generally, a watchdog is a separate service that watches health and load across
 
 ## Next steps
 
-* Get started instrumenting your applications: [Application level event and log generation](service-fabric-diagnostics-event-generation-app.md).
+* Get started instrumenting your applications: [Application level event and log generation](monitor-service-fabric.md#application-logging).
 * Go through the steps to set up Application Insights for your application with [Monitor and diagnose an ASP.NET Core application on Service Fabric](service-fabric-tutorial-monitoring-aspnet.md).
 * Learn more about monitoring the platform and the events Service Fabric provides for you: [Platform level event and log generation](service-fabric-diagnostics-event-generation-infra.md).
 * Configure Azure Monitor logs integration with Service Fabric: [Set up Azure Monitor logs for a cluster](service-fabric-diagnostics-oms-setup.md)

articles/service-fabric/service-fabric-diagnostics-event-aggregation-wad.md

@@ -299,7 +299,7 @@ To collect performance counters or event logs, modify the Resource Manager templ
 
 ## Collect Performance Counters
 
-To collect performance metrics from your cluster, add the performance counters to your "WadCfg > DiagnosticMonitorConfiguration" in the Resource Manager template for your cluster. See [Performance monitoring with WAD](service-fabric-diagnostics-perf-wad.md) for steps on modifying your `WadCfg` to collect specific performance counters. Reference [Service Fabric Performance Counters](service-fabric-diagnostics-event-generation-perf.md) for a list of performance counters that we recommend collecting.
+To collect performance metrics from your cluster, add the performance counters to your "WadCfg > DiagnosticMonitorConfiguration" in the Resource Manager template for your cluster. See [Performance monitoring with WAD](service-fabric-diagnostics-perf-wad.md) for steps on modifying your `WadCfg` to collect specific performance counters. Reference [Performance metrics](monitor-service-fabric-reference.md#performance-metrics) for a list of performance counters that we recommend collecting.
 
 If you are using an Application Insights sink, as described in the section below, and want these metrics to show up in Application Insights, then make sure to add the sink name in the "sinks" section as shown above. This will automatically send the performance counters that are individually configured to your Application Insights resource.