Updating Imaged Refer

labs/shipped-application-level-policy/3.md

@@ -25,7 +25,7 @@ Your app started running.
 
 1. Select a metric, apply a condition to it, and select an action when the condition is met.
 
-    ![](posts/files/shipped-application-level-policy/assets/9.PNG)
+    ![](posts/files/shipped-application-level-policy/assets/9.png)
 
 1. Click **Add**.   
 The policy is added. This policy indicates that when memory use is greater than 75%, then Scale Up the container from 1 to 2. When memory use is greater than 75% within 2 containers, then scale up by another 1 container, that is, from 2 to 3 containers. Scaling up will stop from here because 3 is the maximum container specified.

labs/shipped-application-level-policy/4.md

@@ -2,25 +2,25 @@
 
 We have deployed app up and running on test env.
 
-![](assets/13.PNG)
+![](posts/files/shipped-application-level-policy/assets/13.PNG)
 
 We can specify the no of MB's by which we can start memory leak in app to see how policy response to our app.
 
 So we are adding 2 and click on update button, once done we will click on resume (it resume app with memory leak.)
 
-![](assets/14.PNG)
+![](posts/files/shipped-application-level-policy/assets/14.PNG)
 
 As we can see memory leak has been increasing. As Memory leak reached 75% of policy, we will get alert, in shipped ui.
 
 We can see alert under Run page > 
 
-![](assets/15.PNG)
+![](posts/files/shipped-application-level-policy/assets/15.PNG)
 
 After reach to threshold we have stopped memory leak and capture the below output.
 
-![](assets/16.PNG)
+![](posts/files/shipped-application-level-policy/assets/16.PNG)
 
 
 Below are the related metrics graphs
 
-![](assets/17.PNG)
+![](posts/files/shipped-application-level-policy/assets/17.PNG)