An overview,
1. What is SkyWalking?
Application performance monitoring tool for distributed systems, designed for microservices, cloud native architectures, and container-based (Docker, K8s, Mesos) architectures. Provides integrated solutions for distributed tracking, service grid telemetry analysis, measurement aggregation and visualization.
Official website: skywalking.apache.org/
2. SkyWalking features
Multiple monitoring tools, language probes and Service Mesh
Multi-language automatic probe, Java,.NET Core and Node.js
Lightweight and efficient, no need for big data
Modularization: UI, storage, and cluster management are optional
Support the alarm
Excellent visualization scheme
3. Overall structure
The whole structure is divided into four parts: top, bottom, left and right:
In order to simplify the description, we abandoned Metric indicator correlation and focused on the link correlation function of Tracing.
Upper Agent: Collects link information from applications and sends it to the SkyWalking OAP server. Currently, Tracing data provided by SkyWalking, Zikpin, And Jaeger are supported. Currently, SkyWalking Agent is used to collect SkyWalking Tracing data and transfer it to the server.
The next part of SkyWalking OAP is responsible for receiving Tracing data sent by Agent, analyzing Core, storing it to external Storage, and finally providing Query function.
Right part Storage: Tracing Data store. At present, it supports ES, MySQL, Sharding Sphere, TiDB and H2. We currently use ES, mainly considering the SkyWalking development team’s own production environment using ES.
The left SkyWalking UI is responsible for providing the console, viewing links, and so on
The simple overview principle is as follows:
Mkubernetes version: 1.18.5 Nginx Ingress version: 2.2.8 Helm version: 3.2.4 Persistent Storage driver: This article describes how to deploy SkyWalking into Kubernetes cluster using Helm Charts. Please refer to SkyWalking – Kubernetes
Four methods are currently recommended:
Start the local helm repo using the helm Serve provided by helm 3 use the local chart file to deploy directly from the official repo using the repo function provided by Harbor ❝ Note: Currently, the Chart of Skywalking has not been submitted to the official warehouse, please first refer to the first three ways for deployment
❞ 2.1 Download chart file Skywalking can be directly deployed using the local file. After downloading Skywalking Chart according to the above steps, directly deploy skywalking using the following commands:
Git clone github.com/apache/skyw… cd skywalking-kubernetes/chart helm repo add elastic helm.elastic.co helm dep up skywalking export SKYWALKING_RELEASE_NAME= Skywalking 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] install helm helm install “SKYWALKINGRELEASENAME”skywalking−n”{SKYWALKING_RELEASE_NAME}” Skywalking -n “SKYWALKINGRELEASENAME” Skywalking − N “{SKYWALKING_RELEASE_NAMESPACE}” -f After the installation is completed, we verify the installation situation:
$ kubectl get deployment -n skywalking NAME READY UP-TO-DATE AVAILABLE AGE my-skywalking-oap 2/2 2 2 9m my-skywalking-ui There are three ways to use an Agent in Java
Sidecar mode Mount Agent (recommended) 1. Use the official base image to view the official docker Hub base image. You only need to build the service image From this image, and integrate it directly into Jenkins to make it easier
This method is provided for the following reasons: The official image is a compact image, and it is openJDK. Many commands may not be available, so you need to install the agent package again, which is omitted here.
Since the service is deployed in Kubernetes, Skywalking Agent is used in this way. The advantage of this way is that there is no need to modify the original basic image, nor to rebuild the new service image, but in sidecar mode. By sharing the volume, you can mount files required by the Agent to an existing service image.
3.1, build skywalking agent image building, reference: hub.docker.com/r/prophet/s…
Build with the following dockerfile:
The FROM alpine: 3.8
LABEL maintainer=”[email protected]”
ENV SKYWALKING_VERSION = 8.1.0
The ADD mirrors.tuna.tsinghua.edu.cn/apache/skyw… /
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. The config docker build -t 172.16.106.237 / monitor/skywalking – agent: 8.1.0. After the docker is built, push it to the warehouse.
3.2 Mounting the configuration file using sidecar is 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 to mount the deployment.yaml file of sidecar. Taking nginx as a service as an example, agent is mainly mounted by sharing volume. First, initContainers mount/VMSkywalking /agent in SW-agent-Sidecar through the Skywalk-Agent volume. / vmSkywalking /agent; / vmSkywalking /agent; / vmSkywalking /agent; / vmSkywalking /agent And mount it to the container’s /opt/ Skywalking /agent directory to complete the sharing process.
1. Docker is packaged and pushed to the warehouse to modify the Configuration of Dockerfile and integrate Skywalking Agent:
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”] Run maven package directly to package the project as an image.
Note:
❝ k8s when a Service is created, it creates the corresponding DNS entry. The format of this entry is.. Svc.cluster.local, which means that if the container is used only, it will be resolved as a local service to the namespace. If you want to access across namespaces, you need to use a fully qualified domain name.
❞ 2. Write deployment scripts for YAML version of K8S. Here I take a service 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 then you can run it directly, it can run all the items.
5. After testing and verification, you can go to SkyWalking UI to check whether 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. View the SkyWalking UI
Service: Represents a series or set of workloads that provide the same behavior for requests. When using Agent or SDK, you can define the name of the service. If not, SkyWalking will use the name you define on the platform (say Istio). Here, we can see that the Spring Cloud application’s service is svC-mall-admin, which we defined in the Agent environment variable Service_name.
Service Instance: Each workload in the set above is called an Instance. Just like the 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 Spring Cloud application’s service is UUID@hostname, automatically generated by the Agent.
Endpoint: The request path received by a particular service, such as the HTTP URI path and the class name + method signature of the gRPC service.
Here, we can see one of the endpoints of the Spring Cloud application, the API interface /mall-admin/admin/login.
For more parameters about the Agent, see github.com/apache/skyw…
Click the Topology menu to enter the interface for viewing the topology:
This article explains how to integrate SkyWalking using Kubernetes + Spring Cloud. By the way, downlink monitoring is an essential component of the current microservices system. Distributed tracking, service grid telemetry analysis, measurement aggregation and visualization are still useful. Here we chose Skywalking, for reasons we won’t go into detail here.