kazusa
/
skywalking-java
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Polish the document 'overview and core concepts' (#1485)

This commit is contained in:
crystaldust 2018-07-23 19:19:38 +08:00 committed by 吴晟 Wu Sheng
parent 4d56a63bd2
commit eabf9a7da2
1 changed files with 18 additions and 19 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

37
docs/en/concepts-and-designs/overview.md
View File

@ -1,44 +1,43 @@
# Overview
SkyWalking: an open source observability platform to collect, analysis, aggregate and visualize data from services and cloud native
infrastructures. SkyWalking provide an easy way to keep you have clear view about your distributed system, even across Cloud.
It is more like an modern APM, especially designed for cloud native, container based and distributed system.
SkyWalking: an open source observability platform to collect, analyze, aggregate and visualize data from services and cloud native
infrastructures. SkyWalking provides an easy way to keep you have a clear view of your distributed system, even across Cloud.
It is more like a modern APM, specially designed for cloud native, container based and distributed system.
## Why use SkyWalking?
SkyWalking provides solutions for observing and monitoring distributed system, in many different scenarios. First of all,
like traditional ways, SkyWalking provides auto instrument agents for service, such as Java, C#
and NodeJS. At same time, provide manual instrument SDKs for Go(Not yet), C++(Not yet).
and NodeJS. At the same time, it provides manual instrument SDKs for Go(Not yet), C++(Not yet).
Also with more languages required, risks in manipulating codes at runtime, cloud native infrastructures grow
more powerful, SkyWalking could use Service Mesher infra probes to collect data for understanding the whole distributed system.
In generally, it provides observability capabilities for **service**(s), **service instance**(s), **endpoint**(s).
In general, it provides observability capabilities for **service**(s), **service instance**(s), **endpoint**(s).
Service, instance and endpoint concepts are using everywhere in today, so let's be clear what we mean these in SkyWalking first.
The concepts of Service, Instance and Endpoint are used everywhere today, so let's be clear about what they mean in SkyWalking first.
- **Service**. Represent a set/group of workloads to provide same behaviours for incoming requests. You can define the service
name when you are using instrument agents or SDKs. Or SkyWalking use the name you defined in platform, such as from Istio.
- **Service Instance**. Each one workload in the Service group, named as instance. Like `pods` in Kubernetes, this does't need
to be a single process in OS. Also if you are using instrument agents, instance is actually a real process in OS.
- **Service**. Represent a set/group of workloads to provide the same behaviours for incoming requests. You can define the service
name when you are using instrument agents or SDKs. Or SkyWalking uses the name you defined in platform such as Istio.
- **Service Instance**. Each one workload in the Service group is named as an instance. Like `pods` in Kubernetes, it doesn't need
to be a single process in OS. Also if you are using instrument agents, an instance is actually a real process in OS.
- **Endpoint**. It is a path in the certain service for incoming requests, such as HTTP URI path or gRPC service class + method
signature.
By using SkyWalking, you can have the topology relationship between Services and Endpoints, metrics of every Service, Service
Instance and Endpoint and set alarm rules.
In addition to all there, you can have distributed tracing from SkyWalking native agents and SDKs, also by using Zipkin, Jaeger
In addition to all these, you can have distributed tracing from SkyWalking native agents and SDKs, also by using Zipkin, Jaeger
and OpenCensus.
## Architecture
The SkyWalking is logically split into four parts: Probes, Platform backend, Storage, UI.
The SkyWalking is logically splittd into four parts: Probes, Platform backend, Storage and UI.
<img src="https://skywalkingtest.github.io/page-resources/6_overview.png"/>
- The **Probe**s are different based on different sources. They collects data and reformat them in SkyWalking requirements.
- THe **Platform backend** is a backend, supported cluster for sure. It is for aggregation, analysis and driving process flow
from probe to UI. Also it provide the pluggable capabilities for incoming formats(like Zipkin's), storage implementors and cluster
management. You even can customize aggregation and analysis by using [Observability Analysis Language](oal.md).
- The **Probe**s are different based on different sources. They collect data and reformat them in SkyWalking requirements.
- The **Platform backend** is a backend, supported cluster for sure. It is for aggregation, analysis and driving process flow
from probe to UI. It also provides the pluggable capabilities for incoming formats(like Zipkin's), storage implementors and cluster
management. You even can customize aggregation and analysis by using [Observability Analysis Language](oal.md).
- The **Storage** is open. You can, either choose an existed implementor, such as ElasticSearch, H2 or MySQL cluster managed by
Sharding-Sphere, or implement your own. Of source, we are very welcome to have your contributions for new storage implementors.
- THe **UI** is cool and very powerful for end user of SkyWalking platform. UI is customizable too, because
you need match the backend if you do customize too.
Sharding-Sphere, or implement your own. Of source, we are very appreciated to have your contributions for new storage implementors.
- The **UI** is cool and very powerful for SkyWalking end users. It is also customizable to match your customized backend.
## What is next?