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 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
podsin 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 and OpenCensus.
The SkyWalking is logically split into four parts: Probes, Platform backend, Storage and UI.
- The Probes 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.
- 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.
- Learn SkyWalking's Project Goals
- FAQ, Why doesn't SkyWalking involve MQ in the architecture?