You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[HPE GreenLake for Private Cloud Enterprise](https://www.hpe.com/us/en/greenlake/private-cloud-enterprise.html) delivers a modern private cloud to support your app workloads with bare metal, containers, and virtual machines (VMs) running in any combination across your edges, colocations, and data centers. It combines self-service resource access for developers with consumption and performance transparency for IT. Within this modern application environment, having a robust application performance monitoring (APM) tool is becoming essential. It can help IT professionals to ensure that deployed applications meet the performance, reliability and valuable user experience required by developers, partners and customers.
14
14
15
-
In [the first blog post](https://developer.hpe.com/blog/get-started-with-application-performance-monitoring-tools-overview/), we walked through some of the best APM tools, described their key features and discussed in details their strengths and weaknesses.
15
+
In [the first blog post](https://developer.hpe.com/blog/get-started-with-application-performance-monitoring-tools-overview/), I walked through some of the best APM tools, and I described their key features and discussed in details their strengths and weaknesses.
16
16
17
-
In this blog post, we will start choosing one APM tool, *Apache SkyWalking*, and describe the detailed process how to set it up in HPE GreenLake for Private Cloud Enterprise for monitoring and alerting customer applications.
17
+
In this blog post, I will start choosing one APM tool, *Apache SkyWalking*, and describe the detailed process how to set it up in HPE GreenLake for Private Cloud Enterprise for monitoring and alerting customer applications.
18
18
19
19
## Apache SkyWalking
20
20
@@ -26,7 +26,7 @@ Apache SkyWalking is lightweight and scalable. It can be easily set up as a *sel
26
26
27
27
## Set up Apache SkyWalking for Application Monitoring
28
28
29
-
We will take the approach to setting up the Apache SkyWalking as a *self-managed* APM tool within the Kubernetes cluster created in HPE GreenLake for Private Cloud Enterprise. This mainly takes into account the security concerns in HPE GreenLake product environment.
29
+
I will take the approach to setting up the Apache SkyWalking as a *self-managed* APM tool within the Kubernetes cluster created in HPE GreenLake for Private Cloud Enterprise. This mainly takes into account the security concerns in HPE GreenLake product environment.
After running above commands, the Apache SkyWalking is installed to the Kubernetes cluster's namespace *skywalking*. It creates the *elasticsearch* as the `StatefulSet`, running a pod on each worker node. It runs the Apache SkyWalking OAP with replicas as 2 to provide high availability.
58
+
After running above commands, the Apache SkyWalking is installed to the Kubernetes cluster's namespace *skywalking*. It creates the *elasticsearch* as the `StatefulSet` object, running a pod on each worker node. It runs the Apache SkyWalking Observability Analysis Platform (OAP) with replicas as 2 to provide high availability.
59
59
60
-
It should be noted that the last option *elasticsearch.sysctlInitContainer.enabled=false* is necessary. Otherwise, it will try to set up *vm.max_map_count* using a privileged container during *elasticsearch* installation. It will violate the existing *PodSecurityPolicy* deployed in the HPE GreenLake environment. It therefore will fail the Helm install.
60
+
It should be noted that the last option *elasticsearch.sysctlInitContainer.enabled=false* is necessary. Otherwise, it will try to set up *vm.max_map_count* using a privileged container during *elasticsearch* installation. It will violate the existing *PodSecurityPolicy* deployed in the HPE GreenLake for Private Cloud Enterprise environment. It therefore will fail the Helm install.
61
61
62
-
We can check the detailed Apache SkyWalking installation by typing the following *kubectl* command:
62
+
You can check the detailed Apache SkyWalking installation by typing the following *kubectl* command:
63
63
64
64
```markdown
65
65
$ kubectl get all -n skywalking
@@ -93,7 +93,7 @@ NAME COMPLETIONS DURATION AGE
93
93
job.batch/skywalking-es-init 1/1 7m27s 8m6s
94
94
```
95
95
96
-
We can edit the deployed SkyWalking UI service *skywalking_ui* and change its type from *ClusterIP* to *NodePort*. The service will be automatically mapped to gateway host with an assigned port.
96
+
You can edit the deployed SkyWalking UI service *skywalking_ui* and change its type from *ClusterIP* to *NodePort*. The service will be automatically mapped to gateway host with an assigned port.
The SkyWalking UI can then be accessed in the browser by typing the address *gl2-caas.gl-hpe.local:10037*:
126
+
As shown in the ***Annotations*** section of the service description above, the SkyWalking UI can then be accessed in the browser by typing the address *gl2-caas.gl-hpe.local:10037*:
127
127
128
128
129
129
130
-
### Deploy a Sample SpringBoot Application
130
+
### Deploy a sample application: *SpringBoot*
131
131
132
-
As the first demo application, create a *SpingBoot* Web app that provides a REST endpoint **/message** to print some nice message. Then generate a *jar*file *springboot-k8s-demo.jar* to the target folder:
132
+
As the first demo application, create a *SpingBoot* Web app that provides a REST endpoint **/message** to print some nice message. Then generate a *jar*package using the [Apache Maven](https://maven.apache.org/what-is-maven.html) command *mvn* with the *pom.xml* file:
133
133
134
134
```markdown
135
135
├── Dockerfile
@@ -142,9 +142,58 @@ As the first demo application, create a *SpingBoot* Web app that provides a R
<relativePath/> <!-- lookup parent from repository -->
156
+
</parent>
157
+
<groupId>com.javatechie</groupId>
158
+
<artifactId>springboot-k8s-demo</artifactId>
159
+
<version>0.0.1-SNAPSHOT</version>
160
+
<name>springboot-k8s-demo</name>
161
+
<description>Demo project for Spring Boot</description>
162
+
<properties>
163
+
<java.version>1.8</java.version>
164
+
</properties>
165
+
<dependencies>
166
+
<dependency>
167
+
<groupId>org.springframework.boot</groupId>
168
+
<artifactId>spring-boot-starter-web</artifactId>
169
+
</dependency>
170
+
171
+
<dependency>
172
+
<groupId>org.springframework.boot</groupId>
173
+
<artifactId>spring-boot-starter-test</artifactId>
174
+
<scope>test</scope>
175
+
</dependency>
176
+
</dependencies>
177
+
178
+
<build>
179
+
<plugins>
180
+
<plugin>
181
+
<groupId>org.springframework.boot</groupId>
182
+
<artifactId>spring-boot-maven-plugin</artifactId>
183
+
</plugin>
184
+
</plugins>
185
+
<finalName>springboot-k8s-demo</finalName>
186
+
</build>
187
+
188
+
</project>
189
+
190
+
$ mvn compile
191
+
$ mvn package
192
+
$ ls target/springboot-k8s-demo.jar
193
+
target/springboot-k8s-demo.jar
145
194
```
146
195
147
-
By building a *Docker* image using the generated *jar* file, this*SpringBoot* app can be easily deployed as a containerized application to the Kubernetes cluster.
196
+
You can see the *jar* package *springboot-k8s-demo.jar* is built to the *target* folder. By building a *Docker* image using this generated *jar* file, the*SpringBoot* Web app can be easily deployed as a containerized application to the Kubernetes cluster.
148
197
149
198
Apache SkyWalking provides a list of agents for instrumenting applications. A specific agent per programming language can be used for building into corresponding service which collects application data and exports them to the SkyWalking OAP server.
### Monitor SpringBoot Application from SkyWalking UI
220
+
### Monitor SpringBoot application from SkyWalking UI
172
221
173
-
After build the Docker image *guopingjia/springboot-k8s-demo:pce* and push it to the *DockerHub* registry, we deploy the *SpringBoot* Web app to the Kubernetes cluster:
222
+
After build the Docker image *guopingjia/springboot-k8s-demo:pce* and push it to the *DockerHub* registry, we deploy the *SpringBoot* Web app to the Kubernetes cluster with the *deployment.yaml* manifest file:
174
223
175
224
```markdown
176
225
$ cat deployment.yaml
@@ -199,21 +248,23 @@ spec:
199
248
$ kubectl apply -f deployment.yaml
200
249
```
201
250
202
-
Upon the Web app gets deployed, the built-in Java agent will start collecting application data and post it to the SkyWalking OAP. All the application metrics will be available in the SkyWalking UI, under _General Service_ tab:
251
+
Upon the Web app gets deployed, the built-in Java agent will start collecting application data and post it to the SkyWalking OAP. All the application metrics will be available in the SkyWalking UI, under *General Service* tab:
203
252
204
253
205
254
206
-
Below is the *SpingBoot* Web app topology map:
255
+
Below is the *SpringBoot* Web app topology map:
207
256
208
257
209
258
210
-
### Deploy a Multi-tier Application
259
+
### Deploy a multi-tier application
211
260
212
-
As the second demo application, we will deploy a multi-tier *music* application, available as part of [Apache SkyWalking showcase application](https://github.com/apache/skywalking-showcase). This multi-tier music application consists of a frontend app server and its UI, backend gateway service, recommendation service and songs service, together with a *H2* database. Each microservice is coding with different programming languages, *NodeJS*, *React*, *Spring*, *Python*, etc.
261
+
As the second demo application, I will deploy a multi-tier *music* application, available as part of [Apache SkyWalking showcase application](https://github.com/apache/skywalking-showcase). This multi-tier music application consists of a frontend app server and its UI, backend gateway service, recommendation service and songs service, together with a *H2* database. Each microservice is implemented with different programming language, *NodeJS*, *React*, *Spring*, *Python*, etc.
213
262
214
263
215
264
216
-
In order to monitor this multi-tier *music* application from Apache SkyWalking, we need to pick up the SkyWalking agent per programming language and rebuild corresponding service to instrument the application to the SkyWalking OAP server.
265
+
In order to monitor this multi-tier *music* application from Apache SkyWalking, you need to pick up the SkyWalking agent per programming language and rebuild corresponding service to instrument the application to the SkyWalking OAP server.
266
+
267
+
You can rebuild the *Docker* image per service using the agent version file _**Dockerfile**_ in each service's folder from the multi-tier *music* application repo:
217
268
218
269
```markdown
219
270
├── app
@@ -254,7 +305,7 @@ In order to monitor this multi-tier *music* application from Apache SkyWalkin
254
305
└── src
255
306
```
256
307
257
-
After image files are rebuilt with the agents, the multi-tier *music* application can be deployed to the K8s cluster:
308
+
After image files are rebuilt with the agents, the multi-tier *music* application can be deployed to the Kubernetes cluster:
258
309
259
310
```markdown
260
311
$ envsubst < resources.yaml | kubectl create -f -
@@ -269,9 +320,9 @@ deployment.apps/app-deployment created
269
320
deployment.apps/loadgen-deployment created
270
321
```
271
322
272
-
### Monitor Multi-tier Application from SkyWalking UI
323
+
### Monitor multi-tier application from SkyWalking UI
273
324
274
-
When the multi-tier *music* app gets deployed, the agents built with each microservice will start collecting application data and post it to the SkyWalking OAP. The multi-tier *music* application metrics will be available in the SkyWalking UI, under _General Service_ tab:
325
+
When the multi-tier *music* app gets deployed, the agents built with each microservice will start collecting application data and post it to the SkyWalking OAP. The multi-tier *music* application metrics will be available in the SkyWalking UI, under *General Service* tab:
275
326
276
327
277
328
@@ -283,42 +334,49 @@ You can also check the following multi-tier *music* application trace page. It's
283
334
284
335
285
336
286
-
### Application Alerting
337
+
### Application alerting
287
338
288
-
Apache SkyWalking provides an alerting mechanism to measure application performance according to a list of pre-defined metrics, e.g., _service_resp_time_, _database_access_resp_time_, and _service_sla_. It will trigger alerting when some metrics reach its pre-defined thresholds. We can define new metrics or customize the existing metrics with new thresholds.
339
+
Apache SkyWalking provides an alerting mechanism to measure application performance according to a list of pre-defined metrics, e.g., *service\_resp\_time*, *database\_access\_resp\_time*, and *service\_sla*. It will trigger alerting when some metrics reach its pre-defined thresholds. You can define new metrics using Observability Analysis Language (OAL) or customize the existing metrics with new thresholds.
289
340
290
-
Here is the alarms page from SkyWalking UI showing all the triggered alerting for deployed multi-tier *music*app:
341
+
Here is the alarms page from SkyWalking UI showing all the triggered alerts for deployed multi-tier *music*application:
291
342
292
343
293
344
294
345
The alarms page shows *Successful rate of service agent::app is lower than 80% in 2 minutes of last 10 minutes*. It indicates issue from the frontend app server in multi-tier *music* application.
295
346
296
-
The alerts are triggered by the following metric alerting rule _service_sla_:
347
+
Apache SkyWalking configures the alerting using a collection of alerting rules located in */skywalking/config/alarm-settings.yml* from the SkyWalking OAP pod. You can check the content by running the following command:
Comparing to the output of the _alarm-settings.yml_, you can see the alerts from the alarms page are triggered by the following metric alerting rule *service\_sla*:
297
354
298
355
```markdown
299
-
service_sla_rule:
300
-
# Metrics value need to be long, double or int
301
-
metrics-name: service_sla
302
-
op: "<"
303
-
threshold: 8000
304
-
# The length of time to evaluate the metrics
305
-
period: 10
306
-
# How many times after the metrics match the condition, will trigger alarm
307
-
count: 2
308
-
# How many times of checks, the alarm keeps silence after alarm triggered, default as same as period.
309
-
silence-period: 3
310
-
message: Successful rate of service {name} is lower than 80% in 2 minutes of last 10 minutes
356
+
service_sla_rule:
357
+
# Metrics value need to be long, double or int
358
+
metrics-name: service_sla
359
+
op: "<"
360
+
threshold: 8000
361
+
# The length of time to evaluate the metrics
362
+
period: 10
363
+
# How many times after the metrics match the condition, will trigger alarm
364
+
count: 2
365
+
# How many times of checks, the alarm keeps silence after alarm triggered, default as same as period.
366
+
silence-period: 3
367
+
message: Successful rate of service {name} is lower than 80% in 2 minutes of last 10 minutes
311
368
```
312
-
We can go to the frontend app by clicking the service `agent::app` from SkyWalking UI Service page. From the below service `agent::app` overview page, it shows **Success Rate 66.66%**.
369
+
370
+
You can go to the frontend app by clicking the service `agent::app` from SkyWalking UI Service page. From the below service `agent::app` overview page, it shows **Success Rate 66.66%**.
313
371
314
372
315
373
316
-
We may check further the service's trace page and try to figure out the root cause for this issue.
374
+
You may check further the service's trace page and try to figure out the root cause for this issue.
317
375
318
-
376
+
319
377
320
378
## Conclusion
321
379
322
380
This blog post took the Apache SkyWalking as the application performance monitoring (APM) tool and showed the detailed process to set it up, as a *self-managed* environment in HPE GreenLake for Private Cloud Enterprise, for monitoring and alerting applications. Using the instrumentation of multiple supported agents from Apache SkyWalking, the application workloads can be easily monitored through the integrated Apache SkyWalking UI, with nice application topology map, tracing details and real-time alarms for any application performance issues.
323
381
324
-
In the next blog, we will show you how to use Apache SkyWalking for Kubernetes monitoring in HPE GreenLake for Private Cloud Enterprise.
382
+
In [the next blog post of the series](https://developer.hpe.com/blog/set-up-apache-skywalking-for-k8s-monitoring-in-hpe-greenlake-for-private-cloud-enterprise/) , I will show you how to use Apache SkyWalking APM tool for monitoring of Kubernetes clusters provisioned on HPE GreenLake for Private Cloud Enterprise.
0 commit comments