WMS ID: 11184 - Updated lab with new screenshots up our updated UI re…

…moved conflicts and uppercase folders (#385)

* Updated_Screenshots_2024_Copyright

* 5-21-24-alarm-update

* May_2024_Update_Lab1-4

* Updates_1:54PM_5_24_2024

* Final_Changes_05_24_2024

* Update Manifest JSON lab7 and lab8

* correct manifest json 5-28-24

* Apply missing manifest json update 5-28-24

* Completed_First_Run_Metric_Extension_MD_05_29_24

* First_Draft_Import_OCI_Services_05_29_24

* Updated_4-4-import.png

* Final-work-5-30-24

* Enterprise-Summary-Updates-5-31-24

* Discovery-updates-5-31-24

* Updated-alarms-lab-5-31-24

* Reviewed-metric-extensions-and-import-oci-also-updated-references-to-home-pages

Changed all reference from homepages to home pages

* Updates-Marco-Review-06-04-24

* RevampHomePageEdits

* RevampHomePageEdit2

* ReviewedUpdatesForChanges

* removed old image folders

* Another folder deleted to cleanup files

* Merge branch 'main' into main

oci-stack-monitoring-fundamentals/homepages/homepages.md

@@ -41,31 +41,48 @@ Estimated time: 10 minutes
 
 	From the Concurrent Manager homepage, you can easily review the health and performance of this resource. Each resource in Stack Monitoring has a homepage that provides a central place to review status, performance, alarms, configuration and topology. At the top of the page, Stack Monitoring reports the current status, (Up, Down, Not Reporting). The color and shape of the status indicator will update depending on the resource status and type. Should you find a resource in a down state, the homepage will display a large **red** box with the status of **Down**. Stack Monitoring also provides a **Current Status** date and time. For example, if this Concurrent Manager goes down, Stack Monitoring will provide a timestamp of when the status switched from **Up** to **Down**.
 
-	We can see a count of open alarms by severity. Clicking an alarm count will open the Alarms tab below. We'll cover the **Alarms** tab in more detail later.
+	If a resource has a child resource, the Related resources widget will report the status of each of the children. In this example, two resources are up, and one resource, Concurrent Processing CPNode does not have a status.
 
-	![Concurrent Manager homepage](images/1-3-home.png " ")
+	We can see a count of open alarms by severity **1 Warning** and **1 Critical**. Clicking an alarm count will open the Alarms slide-out to give you more details including the latest value of the alarm breaching the threshold. We'll cover the **Alarms** slide-out in more detail later.
+
+	Stack Monitoring also provides quick access to critical metrics, these metrics differ by resource type. Here we can see **Completed Concurrent Requests** with an Errored state occur at an average rate of .36, and that the Capacity Utilization of Concurrent Managers is 100%. 
+
+
+	![Concurrent Manager homepage, highlighting current status, open alarms, and top metrics](images/1-3-home.png " ")
 
 ## Task 2: Review the Performance menu including, alarms, charts and tables
 
-1. Review performance charts
+1. Review key metric
 
-	A Concurrent Manager homepage provides a list of charts curated for the EBS Concurrent Manger. Stack Monitoring provides a large set of metrics out-of-the-box and are collected immediately after the discovery completes. The performance charts by default display the **Last 60 Minutes**. When investigating issues, it helps to review the performance change over a longer period of time. To extend the time frame click the drop-down and choose **Last 24 Hours**. All charts will now display data from the last 24 hours.
+	A Concurrent Manager homepage provides a list of **Key metrics** curated for each resource type, for example here the EBS Concurrent Manger. Stack Monitoring provides a large set of metrics out-of-the-box and are collected immediately once the discovery completes. The performance charts by default display the **Last 60 Minutes**. When investigating issues, it helps to review the performance change over a longer period of time. To extend the time frame click the drop-down and choose **Last 24 Hours**. The time period shown can be further adjusted by **sliding the time picker throughout the time period** shown to dive deeper into a performance problem. In the image below we can see the time period is the 24 hours, however, once we identified the anomaly we further reduced the time period to show only data between 5-6:45PM.
 
 	Imagine that you have identified a spike in the number of concurrent requests that have been completed with errors. Using the **Completed Concurrent Requests**, hover over a point in time within that chart. Stack Monitoring will display the metric, dimension, timestamp, and value. If the metric has anomaly detection enabled, and the metric has only one dimension, Stack Monitoring will display the upper and lower boundary and if the current value is anomalous. For metrics with more than one dimension, clicking a dimension in the chart legend will hide/show dimensions allowing you to view the baseline for each dimension. When hovering over a data point in a chart, Stack Monitoring will also show metric details of every other chart on the page during that timestamp. Should you identify another area of concern, highlighting the metric will display the value of all other metrics on the page at the same time. For example, when you need to troubleshoot and correlate two metrics like a spike in errors using **Completed Concurrent Requests** and **Capacity Utilization of Concurrent Managers** to determine if the concurrent manager has reached 100% capacity and related to the errors observed.
 
-	![Concurrent Manager performance charts, highlighting % of requests completed with errors](images/2-1-home.png " ")
+	The **Key metrics** can be reordered to prioritize the metrics that are important to you. To reorder the charts or hide a chart, click **Configure charts**. 
 
-2. Review metric tables
+	![Concurrent Manager key metric charts, highlighting anomalous performance](images/2-1-home.png " ")
 
 	Stack Monitoring uses **Tables** to report all dimensions of a metric. Let's navigate to tables to view all of the data points. Select the **Tables** tab. Charts provide a metrics highest utilized metric dimension. **Tables** provide the latest collection value for every dimension of a metric. In this example let's review the **Concurrent Processing Component Status**. Click the **triangle** to expand the row and display the metrics table. Here we see the count all dimensions of the metric Concurrent Processing Component Status. The dimensions include: Scheduled, Running, PendingStandBy, PendingNormal, InactiveOnHold, and InactiveNoManager. 
 
-	![Concurrent Manager tables, highlighting concurrent requests by status](images/2-2-home.png " ")
+	![Configure Key Metric Charts](images/2-2-home.png " ")
+
+	In the image below we can now see **User With Most Pending Requests** is listed first, and **Capacity Utilization of Concurrent Managers** is no longer shown on the charts. To put the metrics back in their original order, if you choose, once again click **Configure charts**.
+
+	![Configure Key Metric Charts with udpated view](images/2-3-home.png " ")
+
+2. Review all metrics
+
+	Stack Monitoring uses **All metrics** to report all dimensions of a metric. Let's navigate to **All metrics** to view all of the data points. Select the **All metrics** tab. Key metrics provide either the top 5 or bottom 5 utilized metric dimensions. **All metrics** provide the latest collection value for every dimension of a metric. In this example let's review the **Concurrent Processing Component Status**. Click the **triangle** to expand the row and display the metrics table. Here we see the count all dimensions of the metric Concurrent Processing Component Status. The dimensions include: Scheduled, Running, PendingStandBy, PendingNormal, InactiveOnHold, and InactiveNoManager. 
+
+	Select the **Alarms** link in the left menu.
+
+	![Concurrent Manager all metrics, highlighting concurrent requests by status](images/2-4-home.png " ")
 
 3. Review open alarms
 
 	Select the **Alarms** tab. Using the **Alarms** view we can see a detailed list of open alarms that includes the alarm Severity, Trigger Time, Resource Name, Metric Name, Dimension of the metric, Alarm Name and **Current Value**. In the previous lab you learned that clicking an alarm **Name** will open a new tab within OCI's Monitoring Service. Now let's review the configuration details of a resource.
 
-	![Concurrent Manager open alarms](images/2-3-home.png " ")
+	![Concurrent Manager alarm slide-out](images/2-5-home.png " ")
 
 ## Task 3: Review configuration details of the resource
 
@@ -94,4 +111,4 @@ Estimated time: 10 minutes
 	* Ana McCollum, Senior Director of Product Management, Enterprise and Cloud Manageability,  
 	* Steven Lemme, Senior Principal Product Manager,  
 	* Anand Prabhu, Sr. Member of Technical Staff
-* **Last Updated By/Date** - Aaron Rimel, June 2024
+* **Last Updated By/Date** - Aaron Rimel, June 2024

oci-stack-monitoring-fundamentals/metric-extensions/metric-extensions.md

@@ -114,4 +114,4 @@ For more information on Metric Extensions, see **[Metric Extensions](https://doc
 	* Ana McCollum, Senior Director of Product Management, Enterprise and Cloud Manageability,  
 	* Steven Lemme, Senior Principal Product Manager,  
 	* Anand Prabhu, Sr. Member of Technical Staff
-* **Last Updated By/Date** - Aaron Rimel, June 2024
+* **Last Updated By/Date** - Aaron Rimel, June 2024

oci-stack-monitoring-fundamentals/together/together.md

@@ -86,7 +86,7 @@ Estimated time: 10 minutes
 
 	![EBS homepage highlighting details of all open alarms of the EBS application](images/4-2-together.png " ")
 
-	Clicking **Charts** provides quick visibility into the health of the EBS application. Let's begin by expanding the chart time displayed from the **Last 60 Minutes** to **Last 24 Hours**.
+	Scrolling down to review **Key metrics** provides quick visibility into the health and performance of the EBS application. Let's begin by expanding the chart time displayed from the **Last 60 Minutes** to **Last 24 Hours**.
 
 	Using the chart **Executed Programs by Running Time** you can easily gain insight into the five longest-running programs. In the screenshot below, we can see the job execution times have remained steady, outside of a small jump. Should you see any long running spikes, an admin can use their domain knowledge to pinpoint a job that is running longer than expected. Again using the screenshot below, the **Completed Requests by Application** chart illustrates how busy a job is to the overall jobs running. The chart **Active User Sessions By Responsibility** in the screenshot below, shows a spike in active user **NULL_KEY** and should be investigated.
 
@@ -136,4 +136,4 @@ For more information and full range of capabilities of the Stack Monitoring solu
 	* Ana McCollum, Senior Director of Product Management, Enterprise and Cloud Manageability,  
 	* Steven Lemme, Senior Principal Product Manager,  
 	* Anand Prabhu, Sr. Member of Technical Staff
-* **Last Updated By/Date** - Aaron Rimel, June 2024
+* **Last Updated By/Date** - Aaron Rimel, June 2024