Update SAMPLE.md
This commit is contained in:
Родитель
4e2e7b1122
Коммит
ba8d387bbd
61
SAMPLE.md
61
SAMPLE.md
|
@ -1,12 +1,22 @@
|
|||
# [Business Commitment](http://aka.ms/caf-manage)
|
||||
#### [home](WELCOME.md)
|
||||
|
||||
# Web and Data Monitoring E2E Example
|
||||
|
||||
## Architecture
|
||||
Application architecture without monitoring.
|
||||
![Architecture](/PNG/todoapp-webapp_data_1.png)
|
||||
|
||||
## Application Criticality and Monitoring Requirements
|
||||
Define application criticality and monitoring requirements.
|
||||
### [Business Commitment](http://aka.ms/caf-manage)
|
||||
|
||||
* **Criticality:** Mission Critical
|
||||
* **Time/Value Impact:** $1m
|
||||
* **Commitment Level:** High Availability Commitment
|
||||
|
||||
# [Monitoring Requirements](http://aka.ms/monitoring-reqs)
|
||||
### [Monitoring Requirements](http://aka.ms/monitoring-reqs)
|
||||
|
||||
## Requirements for health monitoring
|
||||
#### Requirements for health monitoring
|
||||
* An operator should be alerted within seconds if any part of the system is unhealthy.
|
||||
* An operator should be able to ascertain which parts of the system are functioning normally and experiencing problems.
|
||||
* System health should be highlighted through a traffic-light system:
|
||||
|
@ -14,12 +24,12 @@
|
|||
* Yellow for partially healthy.
|
||||
* Green for healthy.
|
||||
|
||||
## Requirements for availability monitoring
|
||||
#### Requirements for availability monitoring
|
||||
* An Operator should be able to view historical availability of each system and subsystem, and use this information to spot any trends.
|
||||
* A monitoring solution should provide an immediate and historical view of the availability or unavailability of each subsystem.
|
||||
* An Operator should be able to examine user actions if these actions fail when they attempt to communicate with a service.
|
||||
|
||||
## Requirements for performance monitoring
|
||||
#### Requirements for performance monitoring
|
||||
* An Operator should have access to:
|
||||
* The response rates for user requests.
|
||||
* The number of concurrent user requests.
|
||||
|
@ -35,7 +45,7 @@
|
|||
* All visualizations should allow an operator to specify a time period. The displayed data might be a snapshot of the current situation and/or a historical view of the performance.
|
||||
* An operator should be able to raise an alert based on any performance measure for any specified value during any specified time interval.
|
||||
|
||||
## Requirements for SLA monitoring
|
||||
#### Requirements for SLA monitoring
|
||||
* An operator should be able to determine at a glance whether the system is meeting the agreed SLAs or not.
|
||||
* The following indicators should be available:
|
||||
* The percentage of service uptime
|
||||
|
@ -47,11 +57,11 @@ All of these indicators should be capable of being filtered by a specified perio
|
|||
* System uptime as presented by health monitoring should indicate the aggregate uptime of each element and not necessarily whether the system has actually halted. Additionally, failures might be isolated. So even if a specific system is unavailable, the remainder of the system might remain available, although with decreased functionality.
|
||||
* For alerting purposes, the system should be able to raise an event if any of the high-level indicators exceed a specified threshold. The lower-level details of the various factors that compose the high-level indicator should be available as contextual data to the alerting system.
|
||||
|
||||
## Requirements for auditing
|
||||
#### Requirements for auditing
|
||||
* An analyst must be able to trace the sequence of relevant control plane change operations.
|
||||
* Data must be available and searchable for a period of 2 years.
|
||||
|
||||
## Requirements for usage monitoring
|
||||
#### Requirements for usage monitoring
|
||||
* To examine system usage, an operator will need access to the following information:
|
||||
* The number of requests that are processed by each subsystem and directed to each resource.
|
||||
* Where users are located.
|
||||
|
@ -59,3 +69,38 @@ All of these indicators should be capable of being filtered by a specified perio
|
|||
* What percentage of users are returning to the system over time.
|
||||
* How system performance affect user behavior.
|
||||
* The performance of individual web pages.
|
||||
|
||||
## Monitoring
|
||||
Monitoring services and features added to application to meet requirements.
|
||||
![Monitoring](/PNG/todoapp-webapp_data_monitoring_3.png)
|
||||
|
||||
## Inventory
|
||||
Inventory of application components using Azure Resource Graph Explorer.
|
||||
* [Azure Resource Graph Explorer](https://docs.microsoft.com/en-us/azure/governance/resource-graph/overview)
|
||||
![Inventory](/PNG/todoapp-webapp_data_monitoring_Inventory_10.png)
|
||||
|
||||
## Web App Monitoring
|
||||
Web App monitoring extract 1.
|
||||
![Web1](/PNG/todoapp-webapp_monitoring_4.png)
|
||||
Web App monitoring extract 2.
|
||||
![Web2](/PNG/todoapp-webapp_monitoring_2_5.png)
|
||||
|
||||
## Data Monitoring
|
||||
Data monitoring extract 1.
|
||||
![Data1](/PNG/todoapp-data_monitoring_6.png)
|
||||
Data monitoring extract 2.
|
||||
![Data2](/PNG/todoapp_data_monitoring_7.png)
|
||||
|
||||
## Service and Resource Health Monitoring
|
||||
Service and Resource health monitoring extract.
|
||||
![SHRH](/PNG/todoapp-webapp_data_monitoring_SHRH_8.png)
|
||||
|
||||
## Cost Monitoring
|
||||
Cost monitoring extract.
|
||||
* [Cost Management and Billing](https://docs.microsoft.com/en-us/azure/cost-management-billing/cost-management-billing-overview)
|
||||
Note: Cost management is covered in the FTA Governance Live session.
|
||||
![Cost](/PNG/todoapp-webapp_data_monitoring_Cost_9.png)
|
||||
|
||||
## Dashboard
|
||||
Sample Azure portal dashboard.
|
||||
![Dashboard](/PNG/todoapp_dashboard.png)
|
||||
|
|
Загрузка…
Ссылка в новой задаче