diff --git a/docs/en/concepts-and-designs/overview.md b/docs/en/concepts-and-designs/overview.md index a6636046e02d66c448c141c2c517d83c5f5ca7f6..7104761169332b32d374ee058afba39724c962fe 100644 --- a/docs/en/concepts-and-designs/overview.md +++ b/docs/en/concepts-and-designs/overview.md @@ -1,43 +1,44 @@ # Overview -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. +SkyWalking: an open source observability platform used to collect, analyze, aggregate and visualize data from services and cloud native +infrastructures. SkyWalking provides an easy way to maintain a clear view of your distributed systems, even across Clouds. +It is a modern APM, specially designed for cloud native, container based distributed systems. ## 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 Node.js. 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 general, it provides observability capabilities for **service**(s), **service instance**(s), **endpoint**(s). - -The concepts of Service, Instance and Endpoint are used everywhere today, so let's make it clear about what they mean in SkyWalking first. - -- **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 these, you can have distributed tracing from SkyWalking native agents and SDKs, also by using Zipkin, Jaeger +SkyWalking provides solutions for observing and monitoring distributed systems, in many different scenarios. First of all, +like traditional approaches, SkyWalking provides auto instrument agents for services, such as Java, C# +and Node.js. Skywalking also offers a community contributed manual instrument SDK for Go (with calls out for Python and +C++ SDK contributions). In multilanguage, continuously deployed environments, cloud native infrastructures grow more powerful +but also more complex. SkyWalking's service mesh receiver allows SkyWalking to receive telemetry data from service mesh frameworks +such as Istio/Envoy and Linkerd, allowing users to understanding the entire distributed system. + +SkyWalking provides observability capabilities for **service**(s), **service instance**(s), **endpoint**(s). The terms Service, +Instance and Endpoint are used everywhere today, so it is worth defining their specific meanings in the context of SkyWalking: + +- **Service**. Represents a set/group of workloads which provide the same behaviours for incoming requests. You can define the service + name when you are using instrument agents or SDKs. SkyWalking can also use the name you define in platforms such as Istio. +- **Service Instance**. Each individual workload in the Service group is known as an instance. Like `pods` in Kubernetes, it + doesn't need to be a single OS process, however, if you are using instrument agents, an instance is actually a real OS process. +- **Endpoint**. A path in a service for incoming requests, such as an HTTP URI path or a gRPC service class + method signature. + +SkyWalking allows users to understand the topology relationship between Services and Endpoints, to view the metrics of every +Service/Service Instance/Endpoint and to set alarm rules. + +In addition, you can integrate distributed tracing useing SkyWalking native agents and SDKs with Zipkin, Jaeger and OpenCensus. ## Architecture -The SkyWalking is logically split into four parts: Probes, Platform backend, Storage and UI. +SkyWalking is logically split into four parts: Probes, Platform backend, Storage and UI. -- 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 course, 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. +- **Probe**s collect data and reformat them for SkyWalking requirements (different probes support different sources). +- **Platform backend**, supports data aggregation, analysis and drives process flow from probes to the 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). +- **Storage** houses SkyWalking data through an open/plugable interface. You can choose an existing implementation, such as + ElasticSearch, H2 or a MySQL cluster managed by Sharding-Sphere, or implement your own. Patches for new storage implementors + welcome! +- **UI** a highly customizale web based interface allowing SkyWalking end users to visualize and manage SkyWalking data. ## What is next?