1. What is Skywalking? Application performance monitoring tool for distributed systems, designed for microservices, cloud native and container-based (Docker, K8S, MESOS) architectures. Provides distributed tracking, service grid telemetry analysis, measurement aggregation and visualization integrated solutions.

Website address: http://skywalking.apache.org/

2. The SkyWalking feature

Multiple monitoring methods, language probes and Service Mesh

Multi-language automatic probes, Java,.NET Core and Node.js

Lightweight and efficient, no need for big data

Modular, UI, storage, cluster management mechanisms are optional

Support the alarm

Excellent visualization

3. Overall structure



The whole structure is divided into four parts: upper, lower, left and right:

In order to simplify the description, we have dropped Metric related features in favor of Tracing link related features.

Agent: collects link information from the application and sends it to the Skywalking OAP server. Tracing data information provided by Skywalking, Zikpin, Jaeger and others is currently supported. At present, we use the Skywalking Agent to collect the Skywalking Tracing data and pass it to the server. The next part of Skywalking OAP is responsible for receiving the Tracing data information sent by the Agent, then conducting Analysis Core, storing it in the external Storage, and finally providing the function of Query.

The right section Storage: Tracing data store. At present, it supports ES, MySQL, Sharding Sphere, TIDB and H2. We are currently using ES, with the Skywalking development team’s own production in mind

The left part of Skywalking UI: responsible for providing the console, view the link and so on simple overview principle for the following figure:! [Uppass…] (a)

Mkubernetes version: 1.18.5 Nginx Ingress version: 2.2.8 HELM version: 3.2.4 Persistent Storage Driver: This article focuses on how to deploy SkyWalking to a Kubernetes cluster using Helm Charts. For documentation, see SkyWalking – Kubernetes

The four recommended methods so far:

Start the local Helm repo with the Helm serve provided by Helm 3 Deploy with the local chart file Deploy directly from the official repo using the repo functionality provided by Harbor (not yet satisfied) ❝ Note: Currently, the chart of Skywalking has not been submitted to the official warehouse. Please refer to the first three ways for deployment

You can deploy Skywalking directly from your local file. After downloading the Skywalking Chart file, use the following command to deploy:

git clone https://github.com/apache/sky… cd skywalking-kubernetes/chart helm repo add elastic https://helm.elastic.co helm dep up skywalking export Export SKYWALKING_RELEASE_NAMESPACE=default Modify the values – my – es. Yaml:

oap:

image:

Tag: 8.1.0- ES7 # Set the right tag according to the existing Elasticsearch version

storageType: elasticsearch7

ui:

image:

Tag: 8.1.0

elasticsearch:

enabled: false

config: # For users of an existing elasticsearch cluster,takes effect when elasticsearch.enabled is false

host: elasticsearch-client
port:
  http: 9200
user: "elastic"         # [optional]
password: "admin@123"     # [optional]

Helm install “${SKYWALKING_RELEASE_NAME}” skywalking -n “${SKYWALKING_RELEASE_NAMESPACE}” \ -f ./skywalking/values-my-es. yAML: /skywalking/values-my-es. yAML:

$ kubectl get deployment -n skywalking NAME READY UP-TO-DATE AVAILABLE AGE my-skywalking-oap 2/2 2 2 9m my-skywalking-ui Skywalking Agent Java using Agent, provides the following three ways for you to choose

1. Use the base image provided by the official Docker Hub to view the base image provided by the official Docker Hub. You only need to build the service image From this image, which is more convenient to integrate directly into Jenkins

The reason for this is that the official image belongs to the thinned image, and is OpenJDK. Many commands may not have it, so you need to install it again. I will skip it here.

Since the service is deployed in Kubernetes, the advantage of using Skywalking Agent in this way is that there is no need to modify the original base image, and no need to rebuild a new service image, but in Sidecar mode. By sharing the volume, the relevant files required by the agent are mounted into the existing service image.

3.1, build skywalking agent image building, reference: https://hub.docker.com/r/prop…

Build with the following dockerfile:

The FROM alpine: 3.8

LABEL maintainer=”zmailto:[email protected]”

ENV SKYWALKING_VERSION = 8.1.0

ADD http://mirrors.tuna.tsinghua…. ${SKYWALKING_VERSION}/apache-skywalking-apm-${SKYWALKING_VERSION}.tar.gz /

RUN tar -zxvf /apache-skywalking-apm-${SKYWALKING_VERSION}.tar.gz && \

mv apache-skywalking-apm-bin skywalking && \ mv /skywalking/agent/optional-plugins/apm-trace-ignore-plugin* /skywalking/agent/plugins/ && \ echo -e "\n# Ignore Path" >> /skywalking/agent/config/agent.config && \ echo "# see https://github.com/apache/skywalking/blob/v8.1.0/docs/en/setup/service-agent/java-agent/agent-optional-plugins/trace-ign ore-plugin.md" >> /skywalking/agent/config/agent.config && \ echo 'trace.ignore_path=${SW_IGNORE_PATH:/health}' >> /skywalking/agent/config/agent.config

Docker build -t 172.16.106.237 / monitor/skywalking – agent: 8.1.0. After the Docker build is completed, push it to the warehouse.

SideCar mount sample configuration file as follows:

apiVersion: apps/v1

kind: Deployment

metadata:

name: demo-skywalking

spec:

replicas: 1

selector:

matchLabels:
  app: demo-skywalking

strategy:

rollingUpdate:
  maxSurge: 1
  maxUnavailable: 0
type: RollingUpdate

template:

metadata: labels: app: demo-skywalking spec: initContainers: - name: init-skywalking-agent image: 172.16.106.237 / monitor/skywalking - agent: 8.1.0 command: - the 'sh' - '- c' - 'the set - the ex; mkdir -p /vmskywalking/agent; cp -r /skywalking/agent/* /vmskywalking/agent; ' volumeMounts: - mountPath: /vmskywalking/agent name: skywalking-agent containers: - image: Nginx :1.7.9 ImagePullPolicy: Always name: Nginx Ports: -ContainerPort: 80 Protocol: TCP Volumemounts: -MountPath: /opt/skywalking/agent name: skywalking-agent volumes: - name: skywalking-agent emptyDir: {}

The above is the deployment file for mounting sidecar. Taking nginx as a service example, it is mainly to mount agent by sharing volume. First, initContainers are mounted with /vmskywalking/agent in SW-agent-sidecar through skywalking-agent volume. /vmskywalking/agent. After this is done, nginx starts up with the skywalking-agent volume mounted. Mounting it to the container’s /opt/skywalking/agent directory completes the sharing process.

1. Docker is packaged and pushed to the warehouse to modify the configuration of Dockerfile, and Skywalking Agent is integrated:

FROM insideo/centos7-java8-build VOLUME /tmp ADD mall-admin.jar app.jar RUN bash -c ‘touch /app.jar’ RUN ln -snf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime && echo Asia/Shanghai > /etc/timezone ENTRYPOINT [“java”,”-Dapp.id=svc-mall-admin”,”-javaagent:/opt/skywalking/agent/skywalking-agent.jar”,”-Dskywalking.agent.service_na me=svc-mall-admin”,”-Dskywalking.collector.backend_service=my-skywalking-oap.skywalking.svc.cluster.local:11800″,”-jar”, “-dspring.profiles. Active =prod”,” -djava.security. egd=file:/dev/./urandom”,”/app.jar”] -dspring.profiles. Active =prod”,” -djava.security. egd=file:/dev/. Running the Maven Package directly packages the project as an image.

Note:

When ❝ k8s creates a Service, it creates the corresponding DNS entry. The format of this entry is

.

.svc.cluster.local, which means that if the container only uses

, it will resolve to the local service into the namespace. If you want to access across namespaces, you need to use a fully qualified domain name.

❞ 2. Write a deployment script for the YAML version of K8S. Here I take one of the services as an example:

apiVersion: apps/v1

kind: Deployment

metadata:

name: svc-mall-admin

spec:

replicas: 1

selector:

matchLabels:
  app: svc-mall-admin

strategy:

rollingUpdate:
  maxSurge: 1
  maxUnavailable: 0
type: RollingUpdate

template:

metadata: labels: app: svc-mall-admin spec: initContainers: - name: init-skywalking-agent image: 172.16.106.237 / monitor/skywalking - agent: 8.1.0 command: - the 'sh' - '- c' - 'the set - the ex; mkdir -p /vmskywalking/agent; cp -r /skywalking/agent/* /vmskywalking/agent; ' volumeMounts: - mountPath: /vmskywalking/agent name: skywalking-agent containers: - image: 172.16.106.237/mall_repo/mall-admin:1.0 imagePullPolicy: Always name: mall-admin ports: -containerport: 8180 protocol: TCP volumeMounts: - mountPath: /opt/skywalking/agent name: skywalking-agent volumes: - name: skywalking-agent emptyDir: {}

apiVersion: v1

kind: Service

metadata:

name: svc-mall-admin

spec:

ports:

- name: http
  port: 8180
  protocol: TCP
  targetPort: 8180

selector:

app: svc-mall-admin

And then it’s ready to run, and it’s going to run everything.

Five, the test verification is complete, you can go to Skywalking UI to check whether the link collection is successful.

1. Test the application API

First, request the API provided by the Spring Cloud application. Because we need to trace the link.

2. Check the Skywalking UI



Insert the picture description here

Here, we’ll see three very important concepts in Skywalking:

Services: Represents a series or set of workloads that provide the same behavior for a request. When using Agent or SDK, you can define the name of the service. If not, Skywalking will use the name you defined on the platform (for example, Istio). Here, we can see that the Spring Cloud application service is SWC-mall-admin, which we defined in the Agent environment variable service_name.

Service Instance: Each workload in the above set of workloads is called an Instance. Like pods in Kubernetes, a service instance is not necessarily a process on the operating system. But when you use an Agent, a service instance is actually a real process on the operating system. Here, we can see that the service of Spring Cloud application is UUID@hostname, which is automatically generated by the Agent.

Endpoint: The request path received for a particular service, such as the HTTP URI path and the GRPC service’s class name + method signature.

Here, we can see an endpoint for the Spring Cloud application, which is the API interface /mall-admin/admin/login.

More agent parameters introduced reference: https://github.com/apache/sky…

Click the menu of “Topology” to enter the interface to view the topology diagram:

Click the “Trace” menu to enter the interface for viewing link data:

This paper introduces in detail how to use Kubernetes + Spring Cloud to integrate Skywalking. By the way, downlink monitoring is an essential component in the current micro-service system. Distributed tracking, service grid telemetry analysis, measurement aggregation and visualization are still quite useful. We chose Skywalking here, but we won’t go into details about why and how to play it.