diff --git a/.github/actions/skip/action.yml b/.github/actions/skip/action.yml index 2e6de66d1..9f6c7f52e 100644 --- a/.github/actions/skip/action.yml +++ b/.github/actions/skip/action.yml @@ -30,6 +30,8 @@ inputs: ".asf.yaml" ".dlc.yaml" ".licenserc.yaml" + "docs/menu.yml" + ".github/actions/skip/action.yml" runs: using: "composite" steps: diff --git a/docs/en/concepts-and-designs/README.md b/docs/en/concepts-and-designs/README.md index e0a98b14d..5db232b19 100644 --- a/docs/en/concepts-and-designs/README.md +++ b/docs/en/concepts-and-designs/README.md @@ -18,6 +18,8 @@ SkyWalking already support. - Backend - [Overview](backend-overview.md). Provides a high level introduction about the OAP backend. - [Observability Analysis Language](oal.md). Introduces the core languages, which is designed for aggregation behaviour definition. + - [Meter Analysis Language](mal.md). Introduces the way to let the user analyze and aggregate meter data in OAP streaming system. + - [Log Analysis Language](lal.md). Introduces the Domain-Specific Language (DSL) to analyze logs. - [Query in OAP](../protocols/README.md#query-protocol). A set of query protocol provided, based on the Observability Analysis Language metrics definition. - UI - [Overview](ui-overview.md). A simple brief about SkyWalking UI. diff --git a/docs/en/concepts-and-designs/backend-overview.md b/docs/en/concepts-and-designs/backend-overview.md index 429a9e83c..a60b3aaed 100644 --- a/docs/en/concepts-and-designs/backend-overview.md +++ b/docs/en/concepts-and-designs/backend-overview.md @@ -1,34 +1,17 @@ # Observability Analysis Platform -OAP(Observability Analysis Platform) is a new concept, which starts in SkyWalking 6.x. OAP replaces the -old SkyWalking whole backend. The capabilities of the platform are following. +We define SkyWalking as an Observability Analysis Platform, which provides a full observability to the services running +either in brown zone, or green zone, even hybrid. -## OAP capabilities -OAP accepts data from more sources, which belongs two groups: **Tracing** and **Metrics**. +## Capabilities +SkyWalking covers all 3 fields of observability, including, **Tracing**, **Metrics** and **logging**. - **Tracing**. Including, SkyWalking native data formats. Zipkin v1,v2 data formats and Jaeger data formats. - **Metrics**. SkyWalking integrates with Service Mesh platforms, such as Istio, Envoy, Linkerd, to provide observability from data panel -or control panel. Also, SkyWalking native agents can run in metrics mode, which highly improve the -performance. +or control panel. Also, SkyWalking native agents can run in metrics mode, which highly improve the performance. +- **Logging**. Including the logs collected from disk or through network. Native agent could bind the tracing context with logs automatically, +or use SkyWalking to bind the trace and log through the text content. -At the same time by using any integration solution provided, such as SkyWalking log plugin or toolkits, -SkyWalking provides visualization integration for binding tracing and logging together by using the -trace id and span id. - -As usual, all services provided by gRPC and HTTP protocol to make integration easier for unsupported ecosystem. - -## Tracing in OAP -Tracing in OAP has two ways to process. -1. Traditional way in SkyWalking 5 series. Format tracing data in SkyWalking trace segment and span formats, -even for Zipkin data format. The OAP analysis the segments to get metrics, and push the metrics data into -the streaming aggregation. -1. Consider tracing as some kinds of logging only. Just provide save and visualization capabilities for trace. - -Also, SkyWalking accepts trace formats from other project, such as Zipkin, Jaeger, OpenCensus. -These formats could be processed in the two ways too. - -## Metrics in OAP -Metrics in OAP is totally new feature in 6 series. Build observability for a distributed system based on metrics of connected nodes. -No tracing data is required. - -Metrics data are aggregated inside OAP cluster in streaming mode. See about [Observability Analysis Language](oal.md), -which provides the easy way to do aggregation and analysis in script style. \ No newline at end of file +There are 3 powerful and native language engines to focus on analyzing observability data from above fields. +1. [Observability Analysis Language](oal.md) processes the native traces and service mesh data. +1. [Meter Analysis Language](mal.md) does metrics calculation for native meter data, and adopts stable and widely used metrics system, such as Prometheus and OpenTelemetry. +1. [Log Analysis Language](lal.md) focuses on log contents and collaborate with Meter Analysis Language. \ No newline at end of file diff --git a/docs/en/concepts-and-designs/overview.md b/docs/en/concepts-and-designs/overview.md index 613e98521..072bf208c 100644 --- a/docs/en/concepts-and-designs/overview.md +++ b/docs/en/concepts-and-designs/overview.md @@ -7,9 +7,9 @@ It is a modern APM, specially designed for cloud native, container based distrib 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#, Node.js, Go, PHP and Nginx LUA. (with calls out for Python and C++ SDK contributions). -In multilanguage, continuously deployed environments, cloud native infrastructures grow more powerful but also more complex. +In multi-language, 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. +such as Istio/Envoy and Linkerd, allowing users to understand 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: @@ -25,7 +25,7 @@ Service/Service Instance/Endpoint and to set alarm rules. In addition, you can integrate 1. Other distributed tracing using SkyWalking native agents and SDKs with Zipkin, Jaeger and OpenCensus. -1. Other metrics systems, such as Prometheus, Sleuth(Micrometer). +1. Other metrics systems, such as Prometheus, Sleuth(Micrometer), OpenTelemetry. ## Architecture SkyWalking is logically split into four parts: Probes, Platform backend, Storage and UI. @@ -33,15 +33,12 @@ SkyWalking is logically split into four parts: Probes, Platform backend, Storage - **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. The analysis includes - SkyWalking natives traces and metrics, 3rd party, including Istio and Envoy telemetry, Zipkin trace format, etc. You even can - customize aggregation and analysis by using [Observability Analysis Language for native metrics](oal.md) and [Meter System for extension metrics](meter.md). +- **Platform backend** supports data aggregation, analysis and streaming process covers traces, metrics, and logs. - **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 customizable web based interface allowing SkyWalking end users to visualize and manage SkyWalking data. + ElasticSearch, H2, MySQL, TiDB, InfluxDB, or implement your own. Patches for new storage implementors welcome! +- **UI** is a highly customizable web based interface allowing SkyWalking end users to visualize and manage SkyWalking data. ## What is next? - Learn SkyWalking's [Project Goals](project-goals.md) -- FAQ, [Why doesn't SkyWalking involve MQ in the architecture?](../FAQ/why_mq_not_involved.md) +- FAQ, [Why doesn't SkyWalking involve MQ in the architecture in default?](../FAQ/why_mq_not_involved.md) diff --git a/docs/en/setup/backend/backend-receivers.md b/docs/en/setup/backend/backend-receivers.md index 6e68632d7..3edf3bd56 100644 --- a/docs/en/setup/backend/backend-receivers.md +++ b/docs/en/setup/backend/backend-receivers.md @@ -14,7 +14,7 @@ We have following receivers, and `default` implementors are provided in our Apac 1. **receiver-otel**. See [details](#opentelemetry-receiver). Receiver for analyzing metrics data from OpenTelemetry 1. **receiver-meter**. See [details](backend-meter.md). Receiver for analyzing metrics in SkyWalking native meter format. 1. **receiver-browser**. gRPC services to accept browser performance data and error log. -1. **receiver-log**. gRPC services accept log data. +1. **receiver-log**. Receiver for native log format. Read [Log Analyzer](log-analyzer.md) for advanced features. 1. **configuration-discovery**. gRPC services handle configurationDiscovery. 1. **receiver-event**. gRPC services to handle events data. 1. **receiver-zabbix**. See [details](backend-zabbix.md). @@ -67,9 +67,11 @@ receiver-browser: default: sampleRate: ${SW_RECEIVER_BROWSER_SAMPLE_RATE:10000} -receiver-log: - selector: ${SW_RECEIVER_LOG:default} - default: +log-analyzer: + selector: ${SW_LOG_ANALYZER:default} + default: + lalFiles: ${SW_LOG_LAL_FILES:default} + malFiles: ${SW_LOG_MAL_FILES:""} configuration-discovery: selector: ${SW_CONFIGURATION_DISCOVERY:default} diff --git a/docs/en/setup/backend/backend-setup.md b/docs/en/setup/backend/backend-setup.md index c262b1462..a51fa9a6a 100755 --- a/docs/en/setup/backend/backend-setup.md +++ b/docs/en/setup/backend/backend-setup.md @@ -115,7 +115,8 @@ to improve the meaning of the metrics. And learn how to write your own conversion rules. 1. [Meter Analysis](backend-meter.md). Set up the backend analysis rules, when use [SkyWalking Meter System Toolkit](../service-agent/java-agent/README.md#advanced-features) or meter plugins. -1. [Spring Sleuth Metrics Analysis](spring-sleuth-setup.md). Configure the agent and backend to receiver metrics from micrometer. +1. [Spring Sleuth Metrics Analysis](spring-sleuth-setup.md). Configure the agent and backend to receiver metrics from micrometer. +1. [Log Analyzer](log-analyzer.md) ## Telemetry for backend OAP backend cluster itself underlying is a distributed streaming process system. For helping the Ops team, diff --git a/docs/en/setup/backend/log-analyzer.md b/docs/en/setup/backend/log-analyzer.md new file mode 100644 index 000000000..4a0830133 --- /dev/null +++ b/docs/en/setup/backend/log-analyzer.md @@ -0,0 +1,15 @@ +## Log Analyzer + +Log analyzer supports native log data. OAP could use Log Analysis Language to +structurize log content through parse, extract, and save logs. +Also the analyzer leverages Meter Analysis Language Engine for further metrics calculation. + +```yaml +log-analyzer: + selector: ${SW_LOG_ANALYZER:default} + default: + lalFiles: ${SW_LOG_LAL_FILES:default} + malFiles: ${SW_LOG_MAL_FILES:""} +``` + +Read [Log Analysis Language](../../concepts-and-designs/lal.md) documentation to learn log structurize and metrics analysis. \ No newline at end of file diff --git a/docs/menu.yml b/docs/menu.yml index 126f19296..0910abe35 100644 --- a/docs/menu.yml +++ b/docs/menu.yml @@ -43,12 +43,18 @@ catalog: path: "/en/concepts-and-designs/backend-overview" - name: "Observability Analysis Language" path: "/en/concepts-and-designs/oal" + - name: "Meter Analysis Language" + path: "/en/concepts-and-designs/mal" + - name: "Log Analysis Language" + path: "/en/concepts-and-designs/lal" - name: "Query in OAP" path: "/en/protocols/readme#query-protocol" - name: "UI" catalog: - name: "Overview" path: "/en/concepts-and-designs/ui-overview" + - event: "Event" + path: "/en/concepts-and-designs/event/" - name: "Setup" path: "/en/setup/readme" @@ -70,7 +76,6 @@ catalog: path: "/en/setup/service-agent/java-agent/readme#bootstrap-class-plugins" - name: "Advanced reporters" path: "/en/setup/service-agent/java-agent/readme#advanced-reporters" - - name: "Plugin development guide" path: "/en/setup/service-agent/java-agent/readme#plugin-development-guide" - name: "Agent plugin tests and performance tests" @@ -91,26 +96,22 @@ catalog: catalog: - name: "Send Envoy metrics to SkyWalking with / without Istio" path: "/en/setup/envoy/metrics_service_setting" - - name: "Backend, UI and CLI setup document" + - name: "Backend, UI and CLI" path: "/en/setup/backend/backend-ui-setup" catalog: - - name: "Backend setup document" + - name: "Backend setup" path: "/en/setup/backend/backend-setup" catalog: - name: "Configuration Vocabulary" path: "/en/setup/backend/configuration-vocabulary" - name: "Overriding settings" path: "/en/setup/backend/backend-setting-override" - - name: "IP and port setting" path: "/en/setup/backend/backend-ip-port" - - name: "Backend init mode startup" path: "/en/setup/backend/backend-init-mode" - - name: "Cluster management" path: "/en/setup/backend/backend-cluster" - - name: "Deploy in kubernetes" path: "/en/setup/backend/backend-k8s" - name: "Choose storage" @@ -149,15 +150,14 @@ catalog: path: "/en/setup/backend/backend-meter" - name: "Spring Sleuth Metrics Analysis" path: "/en/setup/backend/spring-sleuth-setup" + - name: "Log Analyzer" + path: "/en/setup/backend/log-analyzer" - name: "UI setup document" path: "/en/setup/backend/ui-setup" - - name: "CLI setup document" path: "https://github.com/apache/skywalking-cli" - - name: "UI Introduction" path: "/en/ui/readme" - - name: "Contributing Guides" path: "/en/guides/readme" catalog: @@ -169,10 +169,8 @@ catalog: path: "/en/guides/How-to-build" - name: "Agent plugin development guide" path: "/en/guides/Java-Plugin-Development-Guide" - - name: "Protocols" path: "/en/protocols/readme" - - name: "FAQs" path: "/en/FAQ/readme"