You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@skywalking.apache.org by wu...@apache.org on 2022/04/23 04:00:04 UTC
[skywalking] branch master updated: Documentation grammar enhancements (#8935)
This is an automated email from the ASF dual-hosted git repository.
wusheng pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/skywalking.git
The following commit(s) were added to refs/heads/master by this push:
new d2fcd83018 Documentation grammar enhancements (#8935)
d2fcd83018 is described below
commit d2fcd83018b2e48b1bc2746db4b3e3354da8453b
Author: Superskyyy <Su...@outlook.com>
AuthorDate: Fri Apr 22 23:59:58 2022 -0400
Documentation grammar enhancements (#8935)
---
CHANGES.md | 0
docs/en/setup/backend/backend-alarm.md | 82 +++++++++++-----------
docs/en/setup/backend/backend-cluster.md | 18 ++---
docs/en/setup/backend/backend-docker.md | 6 +-
docs/en/setup/backend/backend-health-check.md | 2 +-
docs/en/setup/backend/backend-init-mode.md | 6 +-
docs/en/setup/backend/backend-ip-port.md | 6 +-
docs/en/setup/backend/backend-k8s-monitoring.md | 11 ++-
docs/en/setup/backend/backend-k8s.md | 10 +--
docs/en/setup/backend/backend-load-balancer.md | 14 ++--
docs/en/setup/backend/backend-meter.md | 4 +-
docs/en/setup/backend/backend-setting-override.md | 6 +-
docs/en/setup/backend/backend-setup.md | 44 ++++++------
docs/en/setup/backend/backend-start-up-mode.md | 14 ++--
docs/en/setup/backend/backend-storage.md | 46 ++++++------
docs/en/setup/backend/backend-telemetry.md | 20 +++---
docs/en/setup/backend/backend-token-auth.md | 12 ++--
docs/en/setup/backend/backend-vm-monitoring.md | 6 +-
docs/en/setup/backend/backend-zabbix.md | 2 +-
docs/en/setup/backend/dynamic-config-apollo.md | 10 +--
docs/en/setup/backend/dynamic-config-configmap.md | 5 +-
docs/en/setup/backend/dynamic-config-consul.md | 4 +-
docs/en/setup/backend/dynamic-config-etcd.md | 8 +--
docs/en/setup/backend/dynamic-config-nacos.md | 14 ++--
docs/en/setup/backend/dynamic-config-service.md | 6 +-
docs/en/setup/backend/dynamic-config-zookeeper.md | 2 +-
docs/en/setup/backend/dynamic-config.md | 8 +--
docs/en/setup/backend/dynamical-logging.md | 8 +--
docs/en/setup/backend/endpoint-grouping-rules.md | 18 ++---
docs/en/setup/backend/grpc-security.md | 12 ++--
docs/en/setup/backend/kafka-fetcher.md | 12 ++--
docs/en/setup/backend/log-analyzer.md | 16 ++---
docs/en/setup/backend/metrics-exporter.md | 6 +-
docs/en/setup/backend/mq.md | 6 +-
docs/en/setup/backend/opentelemetry-receiver.md | 2 +-
docs/en/setup/backend/prometheus-metrics.md | 8 +--
docs/en/setup/backend/service-auto-grouping.md | 2 +-
docs/en/setup/backend/slow-db-statement.md | 4 +-
docs/en/setup/backend/trace-sampling.md | 19 ++---
docs/en/setup/backend/ui-setup.md | 6 +-
docs/en/setup/backend/uninstrumented-gateways.md | 12 ++--
docs/en/setup/backend/zipkin-trace.md | 5 +-
docs/en/setup/envoy/als_setting.md | 10 +--
docs/en/setup/envoy/examples/metrics/README.md | 5 +-
docs/en/setup/envoy/metrics_service_setting.md | 14 ++--
docs/en/setup/istio/README.md | 14 ++--
docs/en/setup/service-agent/agent-compatibility.md | 8 +--
docs/en/setup/service-agent/browser-agent.md | 2 +-
docs/en/setup/service-agent/server-agents.md | 30 ++++----
docs/en/setup/service-agent/virtual-database.md | 9 ++-
docs/en/ui/README.md | 27 ++++---
51 files changed, 295 insertions(+), 326 deletions(-)
diff --git a/CHANGES.md b/CHANGES.md
deleted file mode 100644
index e69de29bb2..0000000000
diff --git a/docs/en/setup/backend/backend-alarm.md b/docs/en/setup/backend/backend-alarm.md
index 2a64e2674b..1dc48259d7 100644
--- a/docs/en/setup/backend/backend-alarm.md
+++ b/docs/en/setup/backend/backend-alarm.md
@@ -1,9 +1,9 @@
# Alarm
-Alarm core is driven by a collection of rules, which are defined in `config/alarm-settings.yml`.
-There are three parts in alarm rule definition.
+The alarm core is driven by a collection of rules defined in `config/alarm-settings.yml.`
+There are three parts to alarm rule definitions.
1. [Alarm rules](#rules). They define how metrics alarm should be triggered and what conditions should be considered.
-1. [Webhooks](#webhook). The list of web service endpoints, which should be called after the alarm is triggered.
-1. [gRPCHook](#grpchook). The host and port of the remote gRPC method, which should be called after the alarm is triggered.
+1. [Webhooks](#webhook). The list of web service endpoints, which should be called after an alarm is triggered.
+1. [gRPCHook](#grpchook). The host and port of the remote gRPC method, which should be called after an alarm is triggered.
## Entity name
Defines the relation between scope and entity name.
@@ -21,31 +21,31 @@ Defines the relation between scope and entity name.
An alarm rule is made up of the following elements:
- **Rule name**. A unique name shown in the alarm message. It must end with `_rule`.
- **Metrics name**. This is also the metrics name in the OAL script. Only long, double, int types are supported. See the
-[list of all potential metrics name](#list-of-all-potential-metrics-name). Events can be also configured as the source
-of alarm, please refer to [the event doc](../../concepts-and-designs/event.md) for more details.
-- **Include names**. Entity names which are included in this rule. Please follow the [entity name definitions](#entity-name).
-- **Exclude names**. Entity names which are excluded from this rule. Please follow the [entity name definitions](#entity-name).
+[list of all potential metrics name](#list-of-all-potential-metrics-name). Events can also be configured as the source
+of Alarm. Please refer to [the event doc](../../concepts-and-designs/event.md) for more details.
+- **Include names**. Entity names that are included in this rule. Please follow the [entity name definitions](#entity-name).
+- **Exclude names**. Entity names that are excluded from this rule. Please follow the [entity name definitions](#entity-name).
- **Include names regex**. A regex that includes entity names. If both include-name list and include-name regex are set, both rules will take effect.
-- **Exclude names regex**. A regex that excludes entity names. If both exclude-name list and exclude-name regex are set, both rules will take effect.
-- **Include labels**. Metric labels which are included in this rule.
-- **Exclude labels**. Metric labels which are excluded from this rule.
+- **Exclude names regex**. A regex that excludes entity names. Both rules will take effect if both include-label list and include-label regex are set.
+- **Include labels**. Metric labels that are included in this rule.
+- **Exclude labels**. Metric labels that are excluded from this rule.
- **Include labels regex**. A regex that includes labels. If both include-label list and include-label regex are set, both rules will take effect.
-- **Exclude labels regex**. A regex that exclude labels. If both the exclude-label list and exclude-label regex are set, both rules will take effect.
-- **Tags**. Tags are key/value pairs that are attached to alarms. Tags are used to specify distinguishing attributes of alarms that are meaningful and relevant to users. If you would like to make these tags searchable on the SkyWalking UI, you may set the tag keys in `core/default/searchableAlarmTags`, or through system environment variable `SW_SEARCHABLE_ALARM_TAG_KEYS`. The key `level` is supported by default.
+- **Exclude labels regex**. A regex that excludes labels. Both rules will take effect if both exclude-label list and exclude-label regex are set.
+- **Tags**. Tags are key/value pairs that are attached to alarms. Tags are used to specify distinguishing attributes of alarms that are meaningful and relevant to users. If you want to make these tags searchable on the SkyWalking UI, you may set the tag keys in `core/default/searchableAlarmTags` or through the system environment variable `SW_SEARCHABLE_ALARM_TAG_KEYS`. The key `level` is supported by default.
-*Label settings are required by the meter-system. They are used to store metrics from the label-system platform, such as Prometheus, Micrometer, etc.
+*Label settings are required by the meter system. They are used to store metrics from the label-system platform, such as Prometheus, Micrometer, etc.
The four label settings mentioned above must implement `LabeledValueHolder`.*
- **Threshold**. The target value.
For multiple-value metrics, such as **percentile**, the threshold is an array. It is described as: `value1, value2, value3, value4, value5`.
-Each value may serve as the threshold for each value of the metrics. Set the value to `-` if you do not wish to trigger the alarm by one or more of the values.
-For example in **percentile**, `value1` is the threshold of P50, and `-, -, value3, value4, value5` means that there is no threshold for P50 and P75 in the percentile alarm rule.
+Each value may serve as the threshold for each value of the metrics. Set the value to `-` if you do not wish to trigger the Alarm by one or more of the values.
+For example, in **percentile**, `value1` is the threshold of P50, and `-, -, value3, value4, value5` means that there is no threshold for P50 and P75 in the percentile alarm rule.
- **OP**. The operator. It supports `>`, `>=`, `<`, `<=`, `==`. We welcome contributions of all OPs.
- **Period**. The size of metrics cache in minutes for checking the alarm conditions. This is a time window that corresponds to the backend deployment env time.
- **Count**. Within a period window, if the number of times which **value** goes over the threshold (based on OP) reaches `count`, then an alarm will be sent.
-- **Only as condition**. Indicates if the rule can send notifications, or if it simply serves as an condition of the composite rule.
-- **Silence period**. After the alarm is triggered in Time-N, there will be silence during the **TN -> TN + period**.
-By default, it works in the same manner as **period**. The same alarm (having the same ID in the same metrics name) may only be triggered once within a period.
+- **Only as condition**. Indicates if the rule can send notifications or if it simply serves as a condition of the composite rule.
+- **Silence period**. After the alarm is triggered at Time-N (TN), there will be silence during the **TN -> TN + period**.
+By default, it works in the same manner as **period**. The same Alarm (having the same ID in the same metrics name) may only be triggered once within a period.
### Composite rules
**NOTE**: Composite rules are only applicable to alarm rules targeting the same entity level, such as service-level alarm rules (`service_percent_rule && service_resp_time_percentile_rule`). Do not compose alarm rules of different entity levels, such as an alarm rule of the service metrics with another rule of the endpoint metrics.
@@ -134,9 +134,9 @@ The metrics names are defined in the official [OAL scripts](../../guides/backend
[MAL scripts](../../concepts-and-designs/mal.md), the [Event](../../concepts-and-designs/event.md) names can also serve
as the metrics names, all possible event names can be also found in [the Event doc](../../concepts-and-designs/event.md).
-Currently, metrics from the **Service**, **Service Instance**, **Endpoint**, **Service Relation**, **Service Instance Relation**, **Endpoint Relation** scopes could be used in Alarm, and the **Database access** scope is same as **Service**.
+Currently, metrics from the **Service**, **Service Instance**, **Endpoint**, **Service Relation**, **Service Instance Relation**, **Endpoint Relation** scopes could be used in Alarm, and the **Database access** scope is the same as **Service**.
-Submit an issue or a pull request if you want to support any other scopes in alarm.
+Submit an issue or a pull request if you want to support any other scopes in Alarm.
## Webhook
The Webhook requires the peer to be a web container. The alarm message will be sent through HTTP post by `application/json` content type. The JSON format is based on `List<org.apache.skywalking.oap.server.core.alarm.AlarmMessage>` with the following key information:
@@ -152,27 +152,27 @@ The Webhook requires the peer to be a web container. The alarm message will be s
See the following example:
```json
[{
- "scopeId": 1,
- "scope": "SERVICE",
- "name": "serviceA",
- "id0": "12",
- "id1": "",
+ "scopeId": 1,
+ "scope": "SERVICE",
+ "name": "serviceA",
+ "id0": "12",
+ "id1": "",
"ruleName": "service_resp_time_rule",
- "alarmMessage": "alarmMessage xxxx",
- "startTime": 1560524171000,
+ "alarmMessage": "alarmMessage xxxx",
+ "startTime": 1560524171000,
"tags": [{
"key": "level",
"value": "WARNING"
}]
}, {
- "scopeId": 1,
- "scope": "SERVICE",
- "name": "serviceB",
- "id0": "23",
- "id1": "",
+ "scopeId": 1,
+ "scope": "SERVICE",
+ "name": "serviceB",
+ "id0": "23",
+ "id1": "",
"ruleName": "service_resp_time_rule",
- "alarmMessage": "alarmMessage yyy",
- "startTime": 1560524171000,
+ "alarmMessage": "alarmMessage yyy",
+ "startTime": 1560524171000,
"tags": [{
"key": "level",
"value": "CRITICAL"
@@ -243,10 +243,10 @@ wechatHooks:
- https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=dummy_key
```
-## Dingtalk Hook
+## DingTalk Hook
Follow the [Dingtalk Webhooks guide](https://ding-doc.dingtalk.com/doc#/serverapi2/qf2nxq/uKPlK) and create new Webhooks.
-For security purposes, you can config an optional secret for an individual webhook URL.
-The alarm message will be sent through HTTP post by `application/json` content type if you have configured Dingtalk Webhooks as follows:
+You can configure an optional secret for an individual webhook URL for security purposes.
+The alarm message will be sent through HTTP post by `application/json` content type if you have configured DingTalk Webhooks as follows:
```yml
dingtalkHooks:
textTemplate: |-
@@ -263,8 +263,8 @@ dingtalkHooks:
## Feishu Hook
Follow the [Feishu Webhooks guide](https://www.feishu.cn/hc/zh-cn/articles/360024984973) and create new Webhooks.
-For security purposes, you can config an optional secret for an individual webhook URL.
-If you would like to direct a text to a user, you can config `ats` which is the feishu's user_id and separated by "," .
+You can configure an optional secret for an individual webhook URL for security purposes.
+If you want to direct a text to a user, you can configure `ats`, which is Feishu's user_id and separated by "," .
The alarm message will be sent through HTTP post by `application/json` content type if you have configured Feishu Webhooks as follows:
```yml
feishuHooks:
@@ -305,4 +305,4 @@ which will override the settings in `alarm-settings.yml`.
In order to determine whether an alarm rule is triggered or not, SkyWalking needs to cache the metrics of a time window for
each alarm rule. If any attribute (`metrics-name`, `op`, `threshold`, `period`, `count`, etc.) of a rule is changed,
-the sliding window will be destroyed and re-created, causing the alarm of this specific rule to restart again.
+the sliding window will be destroyed and re-created, causing the Alarm of this specific rule to restart again.
diff --git a/docs/en/setup/backend/backend-cluster.md b/docs/en/setup/backend/backend-cluster.md
index a2032f2456..501e659eb0 100644
--- a/docs/en/setup/backend/backend-cluster.md
+++ b/docs/en/setup/backend/backend-cluster.md
@@ -1,8 +1,8 @@
# Cluster Management
-In many product environments, the backend needs to support high throughput and provide HA to maintain robustness,
+In many production environments, the backend needs to support high throughput and provide high availability (HA) to maintain robustness,
so you always need cluster management in product env.
-NOTICE, cluster management doesn't provide service discovery mechanism for agents and probes. We recommend agents/probes using
+NOTICE, cluster management doesn't provide a service discovery mechanism for agents and probes. We recommend agents/probes using
gateway to load balancer to access OAP clusters.
The core feature of cluster management is supporting the whole OAP cluster running distributed aggregation and analysis for telemetry data.
@@ -37,10 +37,10 @@ cluster:
- `hostPort`, `baseSleepTimeMs` and `maxRetries` are settings of Zookeeper curator client.
Note:
-- If `Zookeeper ACL` is enabled and `/skywalking` exists, you must make sure that `SkyWalking` has `CREATE`, `READ` and `WRITE` permissions. If `/skywalking` does not exist, it will be created by SkyWalking and all permissions to the specified user will be granted. Simultaneously, znode grants the READ permission to anyone.
+- If `Zookeeper ACL` is enabled and `/skywalking` exists, you must ensure that `SkyWalking` has `CREATE`, `READ` and `WRITE` permissions. If `/skywalking` does not exist, it will be created by SkyWalking, and all permissions to the specified user will be granted. Simultaneously, znode grants READ permission to anyone.
- If you set `schema` as `digest`, the password of the expression is set in **clear text**.
-In some cases, the OAP default gRPC host and port in core are not suitable for internal communication among the OAP nodes.
+In some cases, the OAP default gRPC host and port in the core are not suitable for internal communication among the OAP nodes.
The following settings are provided to set the host and port manually, based on your own LAN env.
- internalComHost: The registered host and other OAP nodes use this to communicate with the current node.
- internalComPort: the registered port and other OAP nodes use this to communicate with the current node.
@@ -62,7 +62,7 @@ zookeeper:
## Kubernetes
-The require backend clusters are deployed inside Kubernetes. See the guides in [Deploy in kubernetes](backend-k8s.md).
+The required backend clusters are deployed inside Kubernetes. See the guides in [Deploy in kubernetes](backend-k8s.md).
Set the selector to `kubernetes`.
```yaml
@@ -82,9 +82,9 @@ cluster:
```
Same as the Zookeeper coordinator,
-in some cases, the OAP default gRPC host and port in core are not suitable for internal communication among the OAP nodes.
+in some cases, the OAP default gRPC host and port in the core are not suitable for internal communication among the OAP nodes.
The following settings are provided to set the host and port manually, based on your own LAN env.
-- internalComHost: The registed host and other OAP nodes use this to communicate with the current node.
+- internalComHost: The registered host and other OAP nodes use this to communicate with the current node.
- internalComPort: The registered port and other OAP nodes use this to communicate with the current node.
@@ -106,7 +106,7 @@ cluster:
```
Same as the Zookeeper coordinator,
-in some cases, the OAP default gRPC host and port in core are not suitable for internal communication among the oap nodes.
+in some cases, the OAP default gRPC host and port in the core are not suitable for internal communication among the OAP nodes.
The following settings are provided to set the host and port manually, based on your own LAN env.
- internalComHost: The registered host and other OAP nodes use this to communicate with the current node.
- internalComPort: The registered port and other OAP nodes use this to communicate with the current node.
@@ -130,7 +130,7 @@ nacos:
```
Same as the Zookeeper coordinator,
-in some cases, the OAP default gRPC host and port in core are not suitable for internal communication among the OAP nodes.
+in some cases, the OAP default gRPC host and port in the core are not suitable for internal communication among the OAP nodes.
The following settings are provided to set the host and port manually, based on your own LAN env.
- internalComHost: The registered host and other OAP nodes use this to communicate with the current node.
- internalComPort: The registered port and other OAP nodes use this to communicate with the current node.
diff --git a/docs/en/setup/backend/backend-docker.md b/docs/en/setup/backend/backend-docker.md
index a0a34c6b1f..23ec3959cf 100644
--- a/docs/en/setup/backend/backend-docker.md
+++ b/docs/en/setup/backend/backend-docker.md
@@ -3,13 +3,13 @@
## Start a `standlone` container with `H2` storage
```shell
-docker run --name oap --restart always -d apache/skywalking-oap-server:8.8.0
+docker run --name oap --restart always -d apache/skywalking-oap-server:9.0.0
```
## Start a `standlone` container with ElasticSearch 7 as storage whose address is `elasticsearch:9200`
```shell
-docker run --name oap --restart always -d -e SW_STORAGE=elasticsearch -e SW_STORAGE_ES_CLUSTER_NODES=elasticsearch:9200 apache/skywalking-oap-server:8.8.0
+docker run --name oap --restart always -d -e SW_STORAGE=elasticsearch -e SW_STORAGE_ES_CLUSTER_NODES=elasticsearch:9200 apache/skywalking-oap-server:9.0.0
```
# Configuration
@@ -19,7 +19,7 @@ We could set up environment variables to configure this image. They are defined
# Extend image
If you intend to override or add config files in `/skywalking/config`, `/skywalking/ext-config` is the location for you to put extra files.
-The files with the same name will be overridden, otherwise, they will be added in `/skywalking/config`.
+The files with the same name will be overridden; otherwise, they will be added to `/skywalking/config`.
If you want to add more libs/jars into the classpath of OAP, for example, new metrics for OAL. These jars can be mounted into `/skywalking/ext-libs`, then
`entrypoint` bash will append them into the classpath. Notice, you can't override an existing jar in classpath.
diff --git a/docs/en/setup/backend/backend-health-check.md b/docs/en/setup/backend/backend-health-check.md
index 85caae5b36..5c718cceeb 100644
--- a/docs/en/setup/backend/backend-health-check.md
+++ b/docs/en/setup/backend/backend-health-check.md
@@ -1,6 +1,6 @@
# Health Check
-Health check intends to provide a unique approach to check the health status of the OAP server. It includes the health status
+Health check intends to provide a unique approach to checking the health status of the OAP server. It includes the health status
of modules, GraphQL, and gRPC services readiness.
> 0 means healthy, and more than 0 means unhealthy.
diff --git a/docs/en/setup/backend/backend-init-mode.md b/docs/en/setup/backend/backend-init-mode.md
index 480b43aeaf..669ec6cacf 100644
--- a/docs/en/setup/backend/backend-init-mode.md
+++ b/docs/en/setup/backend/backend-init-mode.md
@@ -1,16 +1,16 @@
# Init mode
The SkyWalking backend supports multiple storage implementors. Most of them would automatically initialize the storage,
-such as Elastic Search or Database, when the backend starts up at first.
+such as Elastic Search or Database, when the backend starts up first.
But there may be some unexpected events that may occur with the storage, such as
-`When multiple Elastic Search indexes are created concurrently, these backend instances would start up at the same time.`,
+`When multiple Elastic Search indexes are created concurrently, these backend instances would startup at the same time.`,
When there is a change, the APIs of Elastic Search would be blocked without reporting any exception.
This often happens on container management platforms, such as k8s.
This is where you need the **Init mode** startup.
## Solution
-Only one single instance should run in the **Init mode** before other instances start up.
+Only a single instance should run in the **Init mode** before other instances start up.
And this instance will exit graciously after all initialization steps are done.
Use `oapServiceInit.sh`/`oapServiceInit.bat` to start up backend. You should see the following logs:
diff --git a/docs/en/setup/backend/backend-ip-port.md b/docs/en/setup/backend/backend-ip-port.md
index cd6363dbb2..419e53b127 100644
--- a/docs/en/setup/backend/backend-ip-port.md
+++ b/docs/en/setup/backend/backend-ip-port.md
@@ -13,16 +13,14 @@ core:
There are two IP/port pairs for gRPC and HTTP REST services.
- Most agents and probes use gRPC service for better performance and code readability.
-- Some agents use REST service, because gRPC may be not supported in that language.
+- Some agents use REST service because gRPC may not be supported in that language.
- The UI uses REST service, but the data is always in GraphQL format.
## Note
### IP binding
-For users who are not familiar with IP binding, note that once IP binding is complete, the client could only use this IP to access the service. For example, if `172.09.13.28` is bound, even if you are
+For users unfamiliar with IP binding, note that once IP binding is complete, the client could only use this IP to access the service. For example, if `172.09.13.28` is bound, even if you are
in this machine, you must use `172.09.13.28`, rather than `127.0.0.1` or `localhost`, to access the service.
### Module provider specified IP and port
The IP and port in the core module are provided by default. But it is common for some module providers, such as receiver modules, to provide other IP and port settings.
-
-
diff --git a/docs/en/setup/backend/backend-k8s-monitoring.md b/docs/en/setup/backend/backend-k8s-monitoring.md
index b1bf085c07..0f354d0df8 100644
--- a/docs/en/setup/backend/backend-k8s-monitoring.md
+++ b/docs/en/setup/backend/backend-k8s-monitoring.md
@@ -1,5 +1,5 @@
# Kubernetes (K8s) monitoring
-SkyWalking leverages K8s kube-state-metrics and cAdvisor for collecting metrics data from K8s, and leverages OpenTelemetry Collector to transfer the metrics to
+SkyWalking leverages K8s kube-state-metrics (KSM) and cAdvisor for collecting metrics data from K8s. It leverages OpenTelemetry Collector to transfer the metrics to
[OpenTelemetry receiver](opentelemetry-receiver.md) and into the [Meter System](./../../concepts-and-designs/meter.md). This feature requires authorizing the OAP Server to access K8s's `API Server`.
## Data flow
@@ -11,12 +11,11 @@ SkyWalking leverages K8s kube-state-metrics and cAdvisor for collecting metrics
1. Setup [kube-state-metric](https://github.com/kubernetes/kube-state-metrics#kubernetes-deployment).
2. cAdvisor is integrated into `kubelet` by default.
3. Set up [OpenTelemetry Collector ](https://opentelemetry.io/docs/collector/getting-started/#kubernetes). For details on Prometheus Receiver in OpenTelemetry Collector for K8s, refer to [here](https://github.com/prometheus/prometheus/blob/main/documentation/examples/prometheus-kubernetes.yml).
-For a quick start, we have provided a full example of configuration and recommended version , you can refer to [showcase](https://github.com/apache/skywalking-showcase/tree/main/deploy/platform/kubernetes/feature-kubernetes-monitor).
+For a quick start, we have provided a complete example of configuration and recommended version; you can refer to [showcase](https://github.com/apache/skywalking-showcase/tree/main/deploy/platform/kubernetes/feature-kubernetes-monitor).
4. Config SkyWalking [OpenTelemetry receiver](opentelemetry-receiver.md).
## Kubernetes Cluster Monitoring
-K8s cluster monitoring provide monitoring of the status and resources of the K8s Cluster, including the whole
-cluster and each node. K8s cluster as a `Service` in OAP, K8s node as a `Instance` in OAP, and land on the `Layer: K8S`.
+K8s cluster monitoring provides monitoring of the status and resources of the whole cluster and each node. K8s cluster as a `Service` in OAP, K8s node as an `Instance` in OAP, and land on the `Layer: K8S`.
### Kubernetes Cluster Supported Metrics
| Monitoring Panel | Unit | Metric Name | Description | Data Source |
@@ -51,7 +50,7 @@ cluster and each node. K8s cluster as a `Service` in OAP, K8s node as a `Instanc
| Network I/O| KB/s | k8s_node_network_receive<br />k8s_node_network_transmit | The network receive and transmit | cAdvisor |
## Kubernetes Service Monitoring
-K8s Service Monitoring provide observe service status and resources from Kubernetes.
+K8s Service Monitoring provides observabilities into service status and resources from Kubernetes.
K8s Service as a `Service` in OAP and land on the `Layer: K8S_SERVICE`.
### Kubernetes Service Supported Metrics
@@ -67,7 +66,7 @@ K8s Service as a `Service` in OAP and land on the `Layer: K8S_SERVICE`.
| Pod Terminated | | k8s_service_pod_status_terminated | The pods and containers which are currently in the terminated status, with reasons shown | K8s kube-state-metrics |
| Pod Restarts | | k8s_service_pod_status_restarts_total | The number of per container restarts related to the pods | K8s kube-state-metrics |
-## Customizing
+## Customizations
You can customize your own metrics/expression/dashboard panel.
The metrics definition and expression rules are found in `/config/otel-oc-rules/k8s-cluster.yaml，/config/otel-oc-rules/k8s-node.yaml, /config/otel-oc-rules/k8s-service.yaml`.
The K8s Cluster dashboard panel configurations are found in `/config/ui-initialized-templates/k8s`.
diff --git a/docs/en/setup/backend/backend-k8s.md b/docs/en/setup/backend/backend-k8s.md
index 561d638be8..60fbdbe36a 100644
--- a/docs/en/setup/backend/backend-k8s.md
+++ b/docs/en/setup/backend/backend-k8s.md
@@ -1,9 +1,9 @@
-# Deploy SkyWalking backend and UI in kubernetes
+# Deploy SkyWalking backend and UI in Kubernetes
Before you read Kubernetes deployment guidance, please make sure you have read `Quick Start` and `Advanced Setup` documents.
-Most SkyWalking OAP settings are controlled through System environment variables when apply helm deployment.
+Most SkyWalking OAP settings are controlled through System environment variables when applying helm deployment.
Follow instructions in the [deploying SkyWalking backend to Kubernetes cluster](https://github.com/apache/skywalking-kubernetes)
- to deploy oap and ui to a kubernetes cluster.
-
-Please read the Readme file.
\ No newline at end of file
+ to deploy OAP and UI to a Kubernetes cluster.
+
+Please refer to the Readme file.
diff --git a/docs/en/setup/backend/backend-load-balancer.md b/docs/en/setup/backend/backend-load-balancer.md
index 07ad23d53a..6436326808 100644
--- a/docs/en/setup/backend/backend-load-balancer.md
+++ b/docs/en/setup/backend/backend-load-balancer.md
@@ -1,14 +1,12 @@
# Backend Load Balancer
-When set the Agent or Envoy connecting to OAP server directly as in default, OAP server cluster would face the problem
-of OAP load imbalance. This issue would be very serious in high traffic load scenarios. Satellite is recommended to be
-used as a native gateway proxy, to provide load balancing capabilities for data content before the data from Agent/Envoy
-reaches the OAP. The major difference between Satellite and other general wide used proxy(s), like Envoy, is that,
-Satellite would route the data accordingly to contents rather than connection, as gRPC streaming is used widely in
-SkyWalking.
+When setting the Agent or Envoy to connect to the OAP server directly as in default, the OAP server cluster would face the problem
+of load imbalance. This issue would be severe in high-traffic load scenarios. [SkyWalking Satellite](https://github.com/apache/skywalking-satellite) is recommended to be
+used as a native gateway proxy to provide load balancing capabilities for data content before the data from Agent/ Envoy
+reaches the OAP. The major difference between Satellite and other general wide used proxy(s), like Envoy, is that it would route the data accordingly to contents rather than connection, as gRPC streaming is used widely in SkyWalking.
Follow instructions in the [Setup SkyWalking Satellite](https://skywalking.apache.org/docs/#SkyWalkingSatellite)
-to deploy Satellite and connect your application to the satellite.
+to deploy Satellite and connect your application to the Satellite.
[Scaling with Apache SkyWalking](https://skywalking.apache.org/blog/2022-01-24-scaling-with-apache-skywalking/) blog
-introduces the theory and technology details how to set up load balancer for the OAP cluster.
\ No newline at end of file
+introduces the theory and technology details on how to set up a load balancer for the OAP cluster.
\ No newline at end of file
diff --git a/docs/en/setup/backend/backend-meter.md b/docs/en/setup/backend/backend-meter.md
index 032e41b849..1e48ded8de 100644
--- a/docs/en/setup/backend/backend-meter.md
+++ b/docs/en/setup/backend/backend-meter.md
@@ -22,8 +22,8 @@ kafka-fetcher:
### Manual Meter API
-Custom metrics may be collected by Manual Meter API.
-Custom metrics collected cannot be used directly, they should be configured in `meter-analyzer-config` configuration files, which is described in next part.
+Custom metrics may be collected by the Manual Meter API.
+Custom metrics collected cannot be used directly; they should be configured in the `meter-analyzer-config` configuration files described in the next part.
The receiver adds labels with `key = service` and `key = instance` to the collected data samples,
and values from service and service instance name defined in SkyWalking Agent,
diff --git a/docs/en/setup/backend/backend-setting-override.md b/docs/en/setup/backend/backend-setting-override.md
index 2e95e63ad8..bd97474445 100644
--- a/docs/en/setup/backend/backend-setting-override.md
+++ b/docs/en/setup/backend/backend-setting-override.md
@@ -44,9 +44,5 @@ then the value of `restHost` here will be overwritten to `172.0.4.12`; otherwise
Placeholder nesting is also supported, like `${REST_HOST:${ANOTHER_REST_HOST:127.0.0.1}}`.
In this case, if the `REST_HOST ` environment variable does not exist, but the ```REST_ANOTHER_REST_HOSTHOST```
-environment variable exists and its value is `172.0.4.12`, then the value of `restHost` here will be overwritten to `172.0.4.12`;
+environment variable exists, and its value is `172.0.4.12`, then the value of `restHost` here will be overwritten to `172.0.4.12`;
otherwise, it will be set to `127.0.0.1`.
-
-
-
-
diff --git a/docs/en/setup/backend/backend-setup.md b/docs/en/setup/backend/backend-setup.md
index 3fcebdb756..22b47aca12 100755
--- a/docs/en/setup/backend/backend-setup.md
+++ b/docs/en/setup/backend/backend-setup.md
@@ -1,15 +1,14 @@
# Backend setup
SkyWalking's backend distribution package consists of the following parts:
-1. **bin/cmd scripts**: Located in the `/bin` folder. Includes startup linux shell and Windows cmd scripts for the backend
- server and UI startup.
+1. **bin/cmd scripts**: Located in the `/bin` folder. Includes startup Linux shell and Windows cmd scripts for the backend server and UI startup.
2. **Backend config**: Located in the `/config` folder. Includes settings files of the backend, which are:
* `application.yml`
* `log4j.xml`
* `alarm-settings.yml`
-3. **Libraries of backend**: Located in the `/oap-libs` folder. All dependencies of the backend can be found in it.
+3. **Libraries of backend**: Located in the `/oap-libs` folder. All dependencies of the backend can be found there.
4. **Webapp env**: Located in the `webapp` folder. UI frontend jar file can be found here, together with its `webapp.yml` setting file.
@@ -17,16 +16,16 @@ SkyWalking's backend distribution package consists of the following parts:
Requirement: **JDK8 to JDK17 are tested**. Other versions are not tested and may or may not work.
-Before you start, you should know that the main purpose of quickstart is to help you obtain a basic configuration for previews/demo. Performance and long-term running are not our goals.
+Before you begin, you should understand that the main purpose of the following quickstart is to help you obtain a basic configuration for previews/demos. Performance and long-term running are **NOT** among the purposes of the quickstart.
-For production/QA/tests environments, see [Backend and UI deployment documents](ui-setup.md).
+**For production/QA/tests environments, see [Backend and UI deployment documents](ui-setup.md).**
You can use `bin/startup.sh` (or cmd) to start up the backend and UI with their default settings, set out as follows:
- Backend storage uses **H2 by default** (for an easier start)
- Backend listens on `0.0.0.0/11800` for gRPC APIs and `0.0.0.0/12800` for HTTP REST APIs.
-In Java, DotNetCore, Node.js, and Istio agents/probes, you should set the gRPC service address to `ip/host:11800`, and ip/host should be where your backend is.
+In Java, DotNetCore, Node.js, and Istio agents/probes, you should set the gRPC service address to `ip/host:11800`, and IP/host should be where your backend is.
- UI listens on `8080` port and request `127.0.0.1/12800` to run a GraphQL query.
### Interaction
@@ -35,25 +34,25 @@ Before deploying Skywalking in your distributed environment, you should learn ab
<img src="https://skywalking.apache.org/doc-graph/communication-net.png"/>
-- All native agents and probes, either language based or mesh probe, use the gRPC service (`core/default/gRPC*` in `application.yml`) to report data to the backend. Also, the Jetty service is supported in JSON format.
-- UI uses GraphQL (HTTP) query to access the backend also in Jetty service (`core/default/rest*` in `application.yml`).
+- Most native agents and probes, including language-based or mesh probes, use gRPC service (`core/default/gRPC*` in `application.yml`) to report data to the backend. Also, the Jetty service is supported in JSON format.
+- UI uses GraphQL (HTTP) query to access the backend, also in Jetty service (`core/default/rest*` in `application.yml`).
## Startup script
The default startup scripts are `/bin/oapService.sh`(.bat).
-Read the [start up mode](backend-start-up-mode.md) document to learn about other ways to start up the backend.
+Read the [start up mode](backend-start-up-mode.md) document to learn other ways to start up the backend.
## application.yml
-SkyWalking backend startup behaviours are driven by `config/application.yml`.
-Understanding the setting file will help you read this document.
-The core concept behind this setting file is that the SkyWalking collector is based on pure modular design.
-End users can switch or assemble the collector features according to their own requirements.
+SkyWalking backend startup behaviours are driven by `config/application.yml`. Understanding the settings file will help you read this document.
+
+The core concept behind this setting file is that the SkyWalking collector is based on a pure modular design.
+End-users can switch or assemble the collector features according to their unique requirements.
In `application.yml`, there are three levels.
1. **Level 1**: Module name. This means that this module is active in running mode.
-1. **Level 2**: Provider option list and provider selector. Available providers are listed here with a selector to indicate which one will actually take effect. If there is only one provider listed, the `selector` is optional and can be omitted.
-1. **Level 3**. Settings of the provider.
+1. **Level 2**: Provider option list and provider selector. Available providers are listed here with a selector to indicate which one will actually take effect. If only one provider is listed, the `selector` is optional and can be omitted.
+1. **Level 3**. Settings of the chosen provider.
Example:
@@ -87,7 +86,7 @@ At the same time, there are two types of modules: required and optional. The req
Even though their modular design supports pluggability, removing those modules does not serve any purpose. For optional modules, some of them have
a provider implementation called `none`, meaning that it only provides a shell with no actual logic, typically such as telemetry.
Setting `-` to the `selector` means that this whole module will be excluded at runtime.
-We advise against trying to change the APIs of those modules, unless you understand the SkyWalking project and its codes very well.
+We advise against changing the APIs of those modules unless you understand the SkyWalking project and its codes very well.
The required modules are listed here:
1. **Core**. Provides the basic and major skeleton of all data analysis and stream dispatch.
@@ -99,22 +98,21 @@ capabilities. See [**Cluster Management**](backend-cluster.md) for more details.
## FAQs
#### Why do we need to set the timezone? And when do we do it?
-SkyWalking provides downsampling time series metrics features.
+SkyWalking provides downsampling time-series metrics features.
Query and store at each time dimension (minute, hour, day, month metrics indexes)
related to timezone when time formatting.
-For example, metrics time will be formatted like YYYYMMDDHHmm in minute dimension metrics,
-which is timezone related.
+For example, metrics time will be formatted like yyyyMMddHHmm in minute dimension metrics, which is timezone-related.
-By default, SkyWalking's OAP backend chooses the OS default timezone.
-If you want to override it, please follow the Java and OS documents.
+By default, SkyWalking's OAP backend chooses the **OS default timezone**.
+Please follow the Java and OS documents if you want to override the timezone.
#### How to query the storage directly from a 3rd party tool?
SkyWalking provides different options based on browser UI, CLI and GraphQL to support extensions. But some users may want to query data
directly from the storage. For example, in the case of ElasticSearch, Kibana is a great tool for doing this.
-By default, in order to reduce memory, network and storage space usages, SkyWalking saves based64-encoded ID(s) only in metrics entities.
-But these tools usually don't support nested query, and are not convenient to work with. For these exceptional reasons,
+By default, SkyWalking saves based64-encoded ID(s) only in metrics entities to reduce memory, network and storage space usages.
+But these tools usually don't support nested queries and are not convenient to work with. For these exceptional reasons,
SkyWalking provides a config to add all necessary name column(s) into the final metrics entities with ID as a trade-off.
Take a look at `core/default/activeExtraModelColumns` config in the `application.yaml`, and set it as `true` to enable this feature.
diff --git a/docs/en/setup/backend/backend-start-up-mode.md b/docs/en/setup/backend/backend-start-up-mode.md
index 50d5b1b247..80432bf887 100644
--- a/docs/en/setup/backend/backend-start-up-mode.md
+++ b/docs/en/setup/backend/backend-start-up-mode.md
@@ -1,21 +1,19 @@
# Start up mode
-In different deployment tools, such as k8s, you may need different startup modes.
-We provide two other optional startup modes.
+You may need different startup modes in different deployment tools, such as k8s.
+We provide two additional optional startup modes.
## Default mode
-The default mode carries out tasks to initialize as necessary, starts to listen, and provide services.
+The default mode carries out tasks to initialize as necessary, starts to listen, and provides services.
Run `/bin/oapService.sh`(.bat) to start in this mode. This is also applicable when you're using `startup.sh`(.bat) to start.
## Init mode
-In this mode, the OAP server starts up to carry out initialization, and then exits.
-You could use this mode to initialize your storage (such as ElasticSearch indexes, MySQL, and TiDB tables),
-as well as your data.
+In this mode, the OAP server starts up to carry out initialization and then exits.
+You could use this mode to initialize your storage (such as ElasticSearch indexes, MySQL, and TiDB tables) as well as your data.
Run `/bin/oapServiceInit.sh`(.bat) to start in this mode.
## No-init mode
-In this mode, the OAP server starts up without carrying out initialization. Rather, it watches out for the ElasticSearch indexes, MySQL, and TiDB tables,
-starts to listen, and provide services. In other words, the OAP server would anticipate having another OAP server to carry out the initialization.
+In this mode, the OAP server starts up without carrying out initialization. Rather, it watches out for the ElasticSearch indexes, MySQL, TiDB and other storage tables, starts listening and provides services. In other words, the OAP server would anticipate having another OAP server carrying out the initialization.
Run `/bin/oapServiceNoInit.sh`(.bat) to start in this mode.
diff --git a/docs/en/setup/backend/backend-storage.md b/docs/en/setup/backend/backend-storage.md
index 2e82b4e00c..abdb00234b 100644
--- a/docs/en/setup/backend/backend-storage.md
+++ b/docs/en/setup/backend/backend-storage.md
@@ -1,5 +1,5 @@
# Backend storage
-The SkyWalking storage is pluggable. We have provided the following storage solutions, which allows you to easily
+The SkyWalking storage is pluggable. We have provided the following storage solutions, which allow you to easily
use one of them by specifying it as the `selector` in `application.yml`：
```yaml
@@ -19,7 +19,7 @@ Natively supported storage:
## H2
-Activate H2 as storage, set storage provider to **H2** In-Memory Databases. Default in distribution package.
+Activate H2 as storage, set storage provider to **H2** In-Memory Databases. Default in the distribution package.
Please read `Database URL Overview` in [H2 official document](http://www.h2database.com/html/features.html).
You can set the target to H2 in **Embedded**, **Server** and **Mixed** modes.
@@ -38,7 +38,7 @@ storage:
## OpenSearch
OpenSearch storage shares the same configurations as ElasticSearch.
-In order to activate OpenSearch as storage, set storage provider to **elasticsearch**.
+In order to activate OpenSearch as storage, set the storage provider to **elasticsearch**.
## ElasticSearch
@@ -47,8 +47,8 @@ License (SSPL), which is incompatible with Apache License 2.0. This license chan
version 7.11. So please choose the suitable ElasticSearch version according to your usage.
Since 8.8.0, SkyWalking rebuilds the ElasticSearch client on top of ElasticSearch REST API and automatically picks up
-correct request formats according to the server side version, hence you don't need to download different binaries
-and don't need to configure different storage selector for different ElasticSearch server side version anymore.
+correct request formats according to the server-side version, hence you don't need to download different binaries
+and don't need to configure different storage selectors for different ElasticSearch server-side versions anymore.
For now, SkyWalking supports ElasticSearch 6.x, ElasticSearch 7.x, ElasticSearch 8.x, and OpenSearch 1.x, their
configurations are as follows:
@@ -108,9 +108,9 @@ storage:
### Daily Index Step
Daily index step(`storage/elasticsearch/dayStep`, default 1) represents the index creation period. In this period, metrics for several days (dayStep value) are saved.
-In most cases, users don't need to change the value manually, as SkyWalking is designed to observe large scale distributed systems.
+In most cases, users don't need to change the value manually, as SkyWalking is designed to observe large-scale distributed systems.
But in some cases, users may want to set a long TTL value, such as more than 60 days. However, their ElasticSearch cluster may not be powerful enough due to low traffic in the production environment.
-This value could be increased to 5 (or more), if users could ensure a single index could support the metrics and traces for these days (5 in this case).
+This value could be increased to 5 (or more) if users could ensure a single index could support the metrics and traces for these days (5 in this case).
For example, if dayStep == 11,
1. Data in [2000-01-01, 2000-01-11] will be merged into the index-20000101.
@@ -119,11 +119,11 @@ For example, if dayStep == 11,
`storage/elasticsearch/superDatasetDayStep` overrides the `storage/elasticsearch/dayStep` if the value is positive.
This would affect the record-related entities, such as trace segments. In some cases, the size of metrics is much smaller than the record (trace). This would improve the shards balance in the ElasticSearch cluster.
-NOTE: TTL deletion would be affected by these steps. You should set an extra dayStep in your TTL. For example, if you want to have TTL == 30 days and dayStep == 10, you are commended to set TTL = 40.
+NOTE: TTL deletion would be affected by these steps. You should set an extra dayStep in your TTL. For example, if you want to have TTL == 30 days and dayStep == 10, you are recommended to set TTL = 40.
### Secrets Management File Of ElasticSearch Authentication
The value of `secretsManagementFile` should point to the secrets management file absolute path.
-The file includes username, password, and JKS password of the ElasticSearch server in the properties format.
+The file includes the username, password, and JKS password of the ElasticSearch server in the properties format.
```properties
user=xxx
password=yyy
@@ -133,7 +133,7 @@ trustStorePass=zzz
The major difference between using `user, password, trustStorePass` configs in the `application.yaml` file is that the **Secrets Management File** is being watched by the OAP server.
Once it is changed manually or through a 3rd party tool, such as [Vault](https://github.com/hashicorp/vault),
the storage provider will use the new username, password, and JKS password to establish the connection and close the old one. If the information exists in the file,
-the `user/password` will be overrided.
+the `user/password` will be overridden.
### Advanced Configurations For Elasticsearch Index
You can add advanced configurations in `JSON` format to set `ElasticSearch index settings` by following [ElasticSearch doc](https://www.elastic.co/guide/en/elasticsearch/reference/current/index-modules.html)
@@ -155,11 +155,11 @@ You could add the following configuration to `elasticsearch.yml`, and set the va
thread_pool.index.queue_size: 1000 # Only suitable for ElasticSearch 6
thread_pool.write.queue_size: 1000 # Suitable for ElasticSearch 6 and 7
-# When you face query error at trace page, remember to check this.
+# When you face a query error on the traces page, remember to check this.
index.max_result_window: 1000000
```
-We strongly recommend that you read more about these configurations from ElasticSearch's official document, since they have a direct impact on the performance of ElasticSearch.
+We strongly recommend that you read more about these configurations from ElasticSearch's official documentation since they directly impact the performance of ElasticSearch.
### ElasticSearch with Zipkin trace extension
@@ -184,13 +184,13 @@ storage:
```
### About Namespace
-When namespace is set, all index names in ElasticSearch will use it as prefix.
+When a namespace is set, all index names in ElasticSearch will use it as the prefix.
## MySQL
-Active MySQL as storage, set storage provider to **mysql**.
+Activate MySQL as storage, and set storage provider to **mysql**.
**NOTE:** MySQL driver is NOT allowed in Apache official distribution and source codes.
-Please download MySQL driver on your own. Copy the connection driver jar to `oap-libs`.
+Please download the MySQL driver on your own. Copy the connection driver jar to `oap-libs`.
```yaml
storage:
@@ -208,12 +208,12 @@ storage:
maxSizeOfBatchSql: ${SW_STORAGE_MAX_SIZE_OF_BATCH_SQL:2000}
asyncBatchPersistentPoolSize: ${SW_STORAGE_ASYNC_BATCH_PERSISTENT_POOL_SIZE:4}
```
-All connection-related settings, including URL link, username, and password are found in `application.yml`.
-Only part of the settings are listed here. See the [HikariCP](https://github.com/brettwooldridge/HikariCP) connection pool document for full settings.
+All connection-related settings, including URL link, username, and password, are found in `application.yml`.
+Only part of the settings is listed here. See the [HikariCP](https://github.com/brettwooldridge/HikariCP) connection pool document for full settings.
To understand the function of the parameter `rewriteBatchedStatements=true` in MySQL, see the [MySQL official document](https://dev.mysql.com/doc/connector-j/8.0/en/connector-j-connp-props-performance-extensions.html#cj-conn-prop_rewriteBatchedStatements).
## TiDB
-Tested TiDB Server 4.0.8 version and MySQL Client driver 8.0.13 version are currently available.
+Tested TiDB Server 4.0.8 version, and MySQL Client driver 8.0.13 version is currently available.
Activate TiDB as storage, and set storage provider to **tidb**.
```yaml
@@ -254,10 +254,10 @@ storage:
duration: ${SW_STORAGE_INFLUXDB_DURATION:1000} # the time to wait at most (milliseconds)
fetchTaskLogMaxSize: ${SW_STORAGE_INFLUXDB_FETCH_TASK_LOG_MAX_SIZE:5000} # the max number of fetch task log in a request
```
-All connection related settings, including URL link, username, and password are found in `application.yml`. For metadata storage provider settings, refer to the configurations of **H2/MySQL** above.
+All connection-related settings, including URL link, username, and password, are found in `application.yml`. For metadata storage provider settings, refer to **H2/MySQL** configurations above.
## PostgreSQL
-PostgreSQL jdbc driver uses version 42.3.2. It supports PostgreSQL 8.2 or newer.
+PostgreSQL JDBC driver uses version 42.3.2. It supports PostgreSQL 8.2 or newer.
Activate PostgreSQL as storage, and set storage provider to **postgresql**.
```yaml
@@ -278,8 +278,8 @@ storage:
maxSizeOfBatchSql: ${SW_STORAGE_MAX_SIZE_OF_BATCH_SQL:2000}
asyncBatchPersistentPoolSize: ${SW_STORAGE_ASYNC_BATCH_PERSISTENT_POOL_SIZE:4}
```
-All connection-related settings, including URL link, username, and password are found in `application.yml`.
-Only part of the settings are listed here. Please follow [HikariCP](https://github.com/brettwooldridge/HikariCP) connection pool document for full settings.
+All connection-related settings, including URL link, username, and password, are found in `application.yml`.
+Only part of the settings is listed here. Please follow [HikariCP](https://github.com/brettwooldridge/HikariCP) connection pool document for full settings.
## IoTDB
IoTDB is a time-series database from Apache, which is one of the storage plugin options.
@@ -297,7 +297,7 @@ storage:
sessionPoolSize: ${SW_STORAGE_IOTDB_SESSIONPOOL_SIZE:8} # If it's zero, the SessionPool size will be 2*CPU_Cores
fetchTaskLogMaxSize: ${SW_STORAGE_IOTDB_FETCH_TASK_LOG_MAX_SIZE:1000} # the max number of fetch task log in a request
```
-All connection related settings, including host, rpcPort, username, and password are found in `application.yml`. Please ensure the IoTDB version >= 0.12.3.
+All connection-related settings, including host, rpcPort, username, and password, are found in `application.yml`. Please ensure the IoTDB version >= 0.12.3.
## More storage extension solutions
Follow the [Storage extension development guide](../../guides/storage-extention.md)
diff --git a/docs/en/setup/backend/backend-telemetry.md b/docs/en/setup/backend/backend-telemetry.md
index bc57a6ee94..49333d28ee 100644
--- a/docs/en/setup/backend/backend-telemetry.md
+++ b/docs/en/setup/backend/backend-telemetry.md
@@ -1,6 +1,5 @@
# Telemetry for backend
-The OAP backend cluster itself is a distributed streaming process system. To assist the Ops team,
-we provide the telemetry for the OAP backend itself.
+The OAP backend cluster itself is a distributed streaming process system. To assist the Ops team, we provide the telemetry for the OAP backend itself, also known as self-observability (so11y)
By default, the telemetry is disabled by setting `selector` to `none`, like this:
@@ -20,10 +19,10 @@ You may also set `Prometheus` to enable them. For more information, refer to the
## Self Observability
### Static IP or hostname
-SkyWalking supports collecting telemetry data into OAP backend directly. Users could check them out through UI or
+SkyWalking supports collecting telemetry data into the OAP backend directly. Users could check them out through UI or
GraphQL API.
-Add the following configuration to enable self-observability related modules.
+Add the following configuration to enable self-observability-related modules.
1. Set up prometheus telemetry.
```yaml
@@ -34,7 +33,7 @@ telemetry:
port: 1543
```
-2. Set up prometheus fetcher.
+2. Set up Prometheus fetcher.
```yaml
prometheus-fetcher:
@@ -45,8 +44,8 @@ prometheus-fetcher:
3. Make sure `config/fetcher-prom-rules/self.yaml` exists.
-Once you deploy an oap-server cluster, the target host should be replaced with a dedicated IP or hostname. For instances,
-there are three OAP servers in your cluster. Their host is `service1`, `service2`, and `service3` respectively. You should
+Once you deploy an OAP server cluster, the target host should be replaced with a dedicated IP or hostname. For instance,
+if there are three OAP servers in your cluster, their hosts are `service1`, `service2`, and `service3`, respectively. You should
update each `self.yaml` to switch the target host.
service1:
@@ -91,7 +90,7 @@ staticConfig:
...
```
### Service discovery on Kubernetes
-If you deploy an oap-server cluster on Kubernetes, the oap-server instance (pod) would not have a static IP or hostname. We can leverage [OpenTelemetry Collector](https://opentelemetry.io/docs/collector/getting-started/#kubernetes) to discover the oap-server instance, and scrape & transfer the metrics to OAP [OpenTelemetry receiver](opentelemetry-receiver.md).
+If you deploy an OAP server cluster on Kubernetes, the oap-server instance (pod) would not have a static IP or hostname. We can leverage [OpenTelemetry Collector](https://opentelemetry.io/docs/collector/getting-started/#kubernetes) to discover the oap-server instance, and scrape & transfer the metrics to OAP [OpenTelemetry receiver](opentelemetry-receiver.md).
On how to install SkyWalking on k8s, you can refer to [Apache SkyWalking Kubernetes](https://github.com/apache/skywalking-kubernetes).
@@ -151,7 +150,7 @@ For the full example for OpenTelemetry Collector configuration and recommended v
___
**NOTE**: Since Apr 21, 2021, the **Grafana** project has been relicensed to **AGPL-v3**, and is no longer licensed for Apache 2.0. Check the LICENSE details.
-The following Prometheus + Grafana solution is optional, rather than recommended.
+The following Prometheus + Grafana solution is optional rather than recommended.
## Prometheus
Prometheus is supported as a telemetry implementor, which collects metrics from SkyWalking's backend.
@@ -188,6 +187,3 @@ telemetry:
### Grafana Visualization
Provide the Grafana dashboard settings.
Check [SkyWalking OAP Cluster Monitor Dashboard](grafana-cluster.json) config and [SkyWalking OAP Instance Monitor Dashboard](grafana-instance.json) config.
-
-
-
diff --git a/docs/en/setup/backend/backend-token-auth.md b/docs/en/setup/backend/backend-token-auth.md
index 78c62b5f03..591e60dbb3 100644
--- a/docs/en/setup/backend/backend-token-auth.md
+++ b/docs/en/setup/backend/backend-token-auth.md
@@ -3,14 +3,14 @@
7.0.0+
## Why do we need token authentication after TLS?
-TLS is about transport security, which makes sure that a network can be trusted.
+TLS is about transport security, ensuring a trusted network.
On the other hand, token authentication is about monitoring **whether application data can be trusted**.
## Token
-In the current version, token is considered a simple string.
+In the current version, a token is considered a simple string.
### Set Token
-1. Set token in agent.config file
+1. Set token in `agent.config` file
```properties
# Authentication active is based on backend setting, see application.yml for more details.
agent.authentication = ${SW_AGENT_AUTHENTICATION:xxxx}
@@ -26,7 +26,7 @@ receiver-sharing-server:
```
## Authentication failure
-The Skywalking OAP verifies every request from the agent, and only allows requests whose token matches the one configured in `application.yml` to pass through.
+The Skywalking OAP verifies every request from the agent and only allows requests whose token matches the one configured in `application.yml` to pass through.
If the token does not match, you will see the following log in the agent:
```
@@ -35,8 +35,8 @@ org.apache.skywalking.apm.dependencies.io.grpc.StatusRuntimeException: PERMISSIO
## FAQ
### Can I use token authentication instead of TLS?
-No, you shouldn't. Of course it's technically possible, but token and TLS are used for untrusted network environments. In these circumstances,
+No, you shouldn't. Of course, it's technically possible, but token and TLS are used for untrusted network environments. In these circumstances,
TLS has a higher priority. Tokens can be trusted only under TLS protection, and they can be easily stolen if sent through a non-TLS network.
### Do you support other authentication mechanisms, such as ak/sk?
-Not for now. But we welcome contributions on this feature.
+Not for now. But we welcome contributions to this feature.
diff --git a/docs/en/setup/backend/backend-vm-monitoring.md b/docs/en/setup/backend/backend-vm-monitoring.md
index 9a6ac3cc02..b0aa5874a2 100644
--- a/docs/en/setup/backend/backend-vm-monitoring.md
+++ b/docs/en/setup/backend/backend-vm-monitoring.md
@@ -1,7 +1,7 @@
# Linux Monitoring
-SkyWalking leverages Prometheus node-exporter to collect metrics data from the VMs, and leverages OpenTelemetry Collector to transfer the metrics to
+SkyWalking leverages Prometheus node-exporter to collect metrics data from the VMs and leverages OpenTelemetry Collector to transfer the metrics to
[OpenTelemetry receiver](opentelemetry-receiver.md) and into the [Meter System](./../../concepts-and-designs/meter.md).
-VM entity as a `Service` in OAP, and on the `Layer: OS_LINUX`.
+VM entity as a `Service` in OAP and on the `Layer: OS_LINUX`.
## Data flow
1. The Prometheus node-exporter collects metrics data from the VMs.
@@ -38,4 +38,4 @@ The metrics definition and expression rules are found in `/config/otel-oc-rules/
The dashboard panel confirmations are found in `/config/ui-initialized-templates/os_linux`.
## Blog
-For more details, see blog article [SkyWalking 8.4 provides infrastructure monitoring](https://skywalking.apache.org/blog/2021-02-07-infrastructure-monitoring/).
+For more details, see the blog article [SkyWalking 8.4 provides infrastructure monitoring](https://skywalking.apache.org/blog/2021-02-07-infrastructure-monitoring/).
diff --git a/docs/en/setup/backend/backend-zabbix.md b/docs/en/setup/backend/backend-zabbix.md
index 4c5f6a182a..015ce8afb3 100644
--- a/docs/en/setup/backend/backend-zabbix.md
+++ b/docs/en/setup/backend/backend-zabbix.md
@@ -25,7 +25,7 @@ are located at `$CLASSPATH/zabbix-rules`.
The file is written in YAML format, defined by the scheme described below. Square brackets indicate that a parameter is optional.
An example for Zabbix agent configuration could be found [here](../../../../test/e2e-v2/cases/vm/zabbix/zabbix_agentd.conf).
-You could find details on Zabbix agent items from [Zabbix Agent documentation](https://www.zabbix.com/documentation/current/manual/config/items/itemtypes/zabbix_agent).
+You can find details on Zabbix agent items from [Zabbix Agent documentation](https://www.zabbix.com/documentation/current/manual/config/items/itemtypes/zabbix_agent).
### Configuration file
diff --git a/docs/en/setup/backend/dynamic-config-apollo.md b/docs/en/setup/backend/dynamic-config-apollo.md
index 27d7946958..8642fd55db 100755
--- a/docs/en/setup/backend/dynamic-config-apollo.md
+++ b/docs/en/setup/backend/dynamic-config-apollo.md
@@ -1,6 +1,6 @@
# Dynamic Configuration Apollo Implementation
-[Apollo](https://github.com/ctripcorp/apollo/) is also supported as Dynamic Configuration Center (DCC). To use it, please configure as follows:
+[Apollo](https://github.com/ctripcorp/apollo/) is also supported as a Dynamic Configuration Center (DCC). To use it, please configure it as follows:
```yaml
configuration:
@@ -15,7 +15,7 @@ configuration:
## Config Storage
### Single Config
-Single configs in apollo are key/value pairs:
+Single configs in Apollo are key/value pairs:
| Key | Value |
|-----|-----|
@@ -25,7 +25,7 @@ e.g. The config is:
```
{agent-analyzer.default.slowDBAccessThreshold}:{default:200,mongodb:50}
```
-The config in apollo is:
+The config in Apollo is:
| Key | Value |
|-----|-----|
@@ -34,7 +34,7 @@ The config in apollo is:
### Group Config
-Group config in apollo are key/value pairs as well, and the key is composited by configKey and subItemKey with `.`.
+Group config in Apollo are key/value pairs as well, and the key is composited by configKey and subItemKey with `.`.
| Key | Value |
|-----|-----|
@@ -48,7 +48,7 @@ e.g. The config is:
|{productAPI-v1}:{value of productAPI-v1}
|{productAPI-v2}:{value of productAPI-v2}
```
-The config in apollo is:
+The config in Apollo is:
| Key | Value |
|-----|-----|
diff --git a/docs/en/setup/backend/dynamic-config-configmap.md b/docs/en/setup/backend/dynamic-config-configmap.md
index 8e1e8a290f..51f06cd29a 100755
--- a/docs/en/setup/backend/dynamic-config-configmap.md
+++ b/docs/en/setup/backend/dynamic-config-configmap.md
@@ -1,6 +1,6 @@
# Dynamic Configuration Kuberbetes Configmap Implementation
-[configmap](https://kubernetes.io/docs/concepts/configuration/configmap/) is also supported as Dynamic Configuration Center (DCC). To use it, please configure as follows:
+[configmap](https://kubernetes.io/docs/concepts/configuration/configmap/) is also supported as a Dynamic Configuration Center (DCC). To use it, please configure it as follows:
```yaml
configuration:
@@ -47,8 +47,7 @@ data:
```
## Config Storage
-The configs is configmap data items as the above example shows. we can organize the configs
-in 1 or more configmap files.
+The configs are configmap data items, as the above example shows. we can organize the configs in 1 or more configmap files.
### Single Config
Under configmap.data:
```
diff --git a/docs/en/setup/backend/dynamic-config-consul.md b/docs/en/setup/backend/dynamic-config-consul.md
index 817fdc12b5..1b694d52ff 100755
--- a/docs/en/setup/backend/dynamic-config-consul.md
+++ b/docs/en/setup/backend/dynamic-config-consul.md
@@ -1,6 +1,6 @@
# Dynamic Configuration Consul Implementation
-[Consul](https://github.com/rickfast/consul-client) is also supported as Dynamic Configuration Center (DCC). To use it, please configure as follows:
+[Consul](https://github.com/rickfast/consul-client) is also supported as a Dynamic Configuration Center (DCC). To use it, please configure it as follows:
```yaml
configuration:
@@ -43,7 +43,7 @@ Group config in Consul are key/value pairs as well, but according to the level
| configKey/subItemkey2 | subItemValue2 |
| ... | ... |
-If use Consul UI we can see keys organized like folder:
+If we use Consul UI, we can see keys organized like a folder:
```
configKey
-- subItemkey1
diff --git a/docs/en/setup/backend/dynamic-config-etcd.md b/docs/en/setup/backend/dynamic-config-etcd.md
index f1d9478a31..9d2463c328 100755
--- a/docs/en/setup/backend/dynamic-config-etcd.md
+++ b/docs/en/setup/backend/dynamic-config-etcd.md
@@ -1,6 +1,6 @@
# Dynamic Configuration Etcd Implementation
-[Etcd](https://github.com/etcd-io/etcd) is also supported as Dynamic Configuration Center (DCC). To use it, please configure as follows:
+[Etcd](https://github.com/etcd-io/etcd) is also supported as a Dynamic Configuration Center (DCC). To use it, please configure it as follows:
```yaml
configuration:
@@ -14,7 +14,7 @@ configuration:
password: ${SW_CONFIG_ETCD_password:}
```
-**NOTE**: Only the v3 protocol is supported since 8.7.0.
+**NOTE**: Since 8.7.0, only the v3 protocol is supported.
## Config Storage
### Single Config
@@ -37,7 +37,7 @@ If `namespace = /skywalking` the config in etcd is:
### Group Config
-Group config in etcd are key/value pairs as well and the key is composited by configKey and subItemKey with `/`.
+Group config in etcd are key/value pairs as well, and the key is composited by configKey and subItemKey with `/`.
| Key | Value |
|-----|-----|
@@ -57,4 +57,4 @@ If `namespace = /skywalking` the config in etcd is:
|-----|-----|
| /skywalking/core.default.endpoint-name-grouping-openapi/customerAPI-v1 | value of customerAPI-v1 |
| /skywalking/core.default.endpoint-name-grouping-openapi/productAPI-v1 | value of productAPI-v1 |
-| /skywalking/core.default.endpoint-name-grouping-openapi/productAPI-v2 | value of productAPI-v2 |
\ No newline at end of file
+| /skywalking/core.default.endpoint-name-grouping-openapi/productAPI-v2 | value of productAPI-v2 |
diff --git a/docs/en/setup/backend/dynamic-config-nacos.md b/docs/en/setup/backend/dynamic-config-nacos.md
index 73562b12d7..90a8461809 100755
--- a/docs/en/setup/backend/dynamic-config-nacos.md
+++ b/docs/en/setup/backend/dynamic-config-nacos.md
@@ -1,6 +1,6 @@
# Dynamic Configuration Nacos Implementation
-[Nacos](https://github.com/alibaba/nacos) is also supported as Dynamic Configuration Center (DCC). To use it, please configure as follows:
+[Nacos](https://github.com/alibaba/nacos) is also supported as a Dynamic Configuration Center (DCC). To use it, please configure it as follows:
```yaml
configuration:
@@ -31,7 +31,7 @@ e.g. The config is:
```
{agent-analyzer.default.slowDBAccessThreshold}:{default:200,mongodb:50}
```
-If `group = skywalking` the config in nacos is:
+If `group = skywalking`, the config in Nacos is:
| Data Id | Group | Config Value |
|-----|-----|-----|
@@ -46,20 +46,20 @@ If `group = skywalking` the config in nacos is:
| subItemkey2 | {group} | subItemValue2 |
| ... | ... | ... |
-Notice: If you add/remove a subItem, you need to add/remove the subItemKey from the group which the subItem belongs:
+Notice: If you add/remove a subItem, you need to add/remove the subItemKey from the group to which the subItem belongs:
| Data Id | Group | Config Value | Config Type |
|-----|-----|-----|-----|
| configKey | {group} | subItemkey1</br>subItemkey2</br>... | TEXT |
-We separate subItemkeys by `\n` or `\r\n`, trim leading and trailing whitespace, if you set the config by `Nacos UI` each subItemkey should in a new line:
+We separate subItemkeys by `\n` or `\r\n`, trim leading and trailing whitespace; if you set the config by `Nacos UI`, each subItemkey should be in a new line:
```
subItemValue1
subItemValue2
...
```
-If you set the config by `API` each subItemkey should separated by `\n` or `\r\n`:
+If you set the config by `API`, each subItemkey should be separated by `\n` or `\r\n`:
```
configService.publishConfig("test-module.default.testKeyGroup", "skywalking", "subItemkey1\n subItemkey2"));
```
@@ -70,7 +70,7 @@ e.g. The config is:
|{productAPI-v1}:{value of productAPI-v1}
|{productAPI-v2}:{value of productAPI-v2}
```
-If `group = skywalking` the config in nacos is:
+If `group = skywalking`, the config in Nacos is:
| Data Id | Group | Config Value | Config Type |
|-----|-----|-----|-----|
@@ -78,5 +78,3 @@ If `group = skywalking` the config in nacos is:
| customerAPI-v1 | skywalking | value of customerAPI-v1 |
| productAPI-v1 | skywalking | value of productAPI-v1 |
| productAPI-v2 | skywalking | value of productAPI-v2 |
-
-
diff --git a/docs/en/setup/backend/dynamic-config-service.md b/docs/en/setup/backend/dynamic-config-service.md
index 6824cc4f1a..90279e59e3 100755
--- a/docs/en/setup/backend/dynamic-config-service.md
+++ b/docs/en/setup/backend/dynamic-config-service.md
@@ -1,7 +1,7 @@
# Dynamic Configuration Service, DCS
[Dynamic Configuration Service](../../../../oap-server/server-configuration/grpc-configuration-sync/src/main/proto/configuration-service.proto)
is a gRPC service which requires implementation of the upstream system.
-The SkyWalking OAP fetches the configuration from the implementation (any system), after you open the implementation like this:
+The SkyWalking OAP fetches the configuration from the implementation (any system) after you open the implementation like this:
```yaml
configuration:
@@ -14,7 +14,7 @@ configuration:
```
## Config Server Response
-`uuid`: To identify whether the config data changed, if `uuid` is the same not required to respond the config data.
+`uuid`: To identify whether the config data changed, if `uuid` is the same, it is not required to respond to the config data.
### Single Config
Implement:
```
@@ -64,4 +64,4 @@ groupConfigTable {
value: "value of productAPI-v2"
}
}
-```
\ No newline at end of file
+```
diff --git a/docs/en/setup/backend/dynamic-config-zookeeper.md b/docs/en/setup/backend/dynamic-config-zookeeper.md
index e2b7279a06..db8ace032a 100755
--- a/docs/en/setup/backend/dynamic-config-zookeeper.md
+++ b/docs/en/setup/backend/dynamic-config-zookeeper.md
@@ -1,5 +1,5 @@
# Dynamic Configuration Zookeeper Implementation
-[Zookeeper](https://github.com/apache/zookeeper) is also supported as Dynamic Configuration Center (DCC). To use it, please configure as follows:
+[Zookeeper](https://github.com/apache/zookeeper) is also supported as a Dynamic Configuration Center (DCC). To use it, please configure it as follows:
```yaml
configuration:
diff --git a/docs/en/setup/backend/dynamic-config.md b/docs/en/setup/backend/dynamic-config.md
index b233bcf1cb..f8c95a4be5 100755
--- a/docs/en/setup/backend/dynamic-config.md
+++ b/docs/en/setup/backend/dynamic-config.md
@@ -1,8 +1,9 @@
# Dynamic Configuration
SkyWalking Configurations are mostly set through `application.yml` and OS system environment variables.
-At the same time, some of them support dynamic settings from upstream management system.
-Currently, SkyWalking supports the 2 types of dynamic configurations: Single and Group.
+At the same time, some of them support dynamic settings from an upstream management system.
+
+Currently, SkyWalking supports two types of dynamic configurations: Single and Group.
This feature depends on upstream service, so it is **DISABLED** by default.
@@ -40,7 +41,7 @@ Supported configurations are as follows:
|configuration-discovery.default.agentConfigurations| The ConfigurationDiscovery settings. | See [`configuration-discovery.md`](https://github.com/apache/skywalking-java/blob/20fb8c81b3da76ba6628d34c12d23d3d45c973ef/docs/en/setup/service-agent/java-agent/configuration-discovery.md). |
## Group Configuration
-Group Configuration is a config key that corresponds to a group sub config items. A sub config item is a key value pair. The logic structure is:
+Group Configuration is a config key corresponding to a group sub config item. A sub config item is a key-value pair. The logic structure is:
```
{configKey}: |{subItemkey1}:{subItemValue1}
|{subItemkey2}:{subItemValue2}
@@ -68,4 +69,3 @@ Supported configurations are as follows:
- [Apollo Implementation](./dynamic-config-apollo.md)
- [Kuberbetes Configmap Implementation](./dynamic-config-configmap.md)
- [Nacos Implementation](./dynamic-config-nacos.md)
-
diff --git a/docs/en/setup/backend/dynamical-logging.md b/docs/en/setup/backend/dynamical-logging.md
index 50766a25ff..03bb2419ae 100644
--- a/docs/en/setup/backend/dynamical-logging.md
+++ b/docs/en/setup/backend/dynamical-logging.md
@@ -1,7 +1,7 @@
# Dynamical Logging
The OAP server leverages `log4j2` to manage the logging system. `log4j2` supports changing the configuration
-at runtime, but you have to update the XML configuration file manually, which could be time-consuming and prone to manmade mistakes.
+at runtime, but you have to manually update the XML configuration file, which could be time-consuming and prone to man-made mistakes.
Dynamical logging, which depends on dynamic configuration, provides us with an agile way to update all OAP `log4j`
configurations through a single operation.
@@ -10,14 +10,13 @@ The key of the configuration item is `core.default.log4j-xml`, and you can selec
to store the content of `log4j.xml`. In the booting phase, once the core module gets started, `core.default.log4j-xml`
would come into the OAP log4j context.
-If the configuration is changed after the OAP has started, you have to wait for a while for the changes to be applied.
-The default value is `60` seconds, which you could change through `configuration.<configuration implement>.peroid` in `application.yaml`.
+If the configuration is changed after the OAP startup, you have to wait for a while for the changes to be applied. The default value is `60` seconds, which you could change through `configuration.<configuration implement>.peroid` in `application.yaml`.
If you remove `core.default.log4j-xml` from the configuration center or disable the configuration module, `log4j.xml` in the `config` directory would be affected.
> Caveat: The OAP only supports the XML configuration format.
-This is an example on how to config dynamical logging through a ConfigMap in a Kubernetes cluster. You may set up other configuration
+This is an example of configuring dynamical logging through a ConfigMap in a Kubernetes cluster. You may set up other configuration
clusters following the same procedures.
```yaml
@@ -47,4 +46,3 @@ metadata:
name: skywalking-oap
namespace: default
```
-
diff --git a/docs/en/setup/backend/endpoint-grouping-rules.md b/docs/en/setup/backend/endpoint-grouping-rules.md
index 1802b332d8..5f21613fdf 100644
--- a/docs/en/setup/backend/endpoint-grouping-rules.md
+++ b/docs/en/setup/backend/endpoint-grouping-rules.md
@@ -2,7 +2,7 @@
In most cases, endpoints are detected automatically through language agents, service mesh observability solutions,
or meter system configurations.
-There are some special cases, especially when REST style URI is used, where the application codes include the parameter in the endpoint name,
+There are some special cases, especially when REST-style URI is used, where the application codes include the parameter in the endpoint name,
such as putting order ID in the URI. Examples are `/prod/ORDER123` and `/prod/ORDER456`. But logically, most would expect to
have an endpoint name like `prod/{order-id}`. This is a specially designed feature in parameterized endpoint grouping.
@@ -52,19 +52,19 @@ info:
2. All OpenAPI definition documents are located in the `openapi-definitions` directory, with directories having at most two levels. We recommend using the service name as the subDirectory name, as you will then not be required to set `x-sw-service-name`. For example:
```
├── openapi-definitions
-│ ├── serviceA
-│ │ ├── customerAPI-v1.yaml
-│ │ └── productAPI-v1.yaml
-│ └── serviceB
-│ └── productAPI-v2.yaml
+│ ├── serviceA
+│ │ ├── customerAPI-v1.yaml
+│ │ └── productAPI-v1.yaml
+│ └── serviceB
+│ └── productAPI-v2.yaml
```
3. The feature is enabled by default. You can disable it by setting the `Core Module` configuration `${SW_CORE_ENABLE_ENDPOINT_NAME_GROUPING_BY_OPAENAPI:false}`.
### Rules match priority
We recommend designing the API path as clearly as possible. If the API path is fuzzy and an endpoint name matches multiple paths, SkyWalking would select a path according to the match priority set out below:
-1. The exact path being matched.
+1. The exact path is matched.
E.g. `/products or /products/inventory`
-2. The path which has less variables.
+2. The path with fewer variables.
E.g. In the case of `/products/{var1}/{var2} and /products/{var1}/abc`, endpoint name `/products/123/abc` will match the second one.
3. If the paths have the same number of variables, the longest path is matched, and the vars are considered to be `1`.
E.g. In the case of `/products/abc/{var1} and products/{var12345}/ef`, endpoint name `/products/abc/ef` will match the first one, because `length("abc") = 3` is larger than `length("ef") = 2`.
@@ -287,7 +287,7 @@ Here are some use cases:
### Initialize and update the OpenAPI definitions dynamically
Use [Dynamic Configuration](dynamic-config) to initialize and update OpenAPI definitions, the endpoint grouping rules from OpenAPI
-will re-create by new config.
+will re-create by the new config.
## Endpoint name grouping by custom configuration
diff --git a/docs/en/setup/backend/grpc-security.md b/docs/en/setup/backend/grpc-security.md
index ace9488337..f1b55e7271 100644
--- a/docs/en/setup/backend/grpc-security.md
+++ b/docs/en/setup/backend/grpc-security.md
@@ -28,10 +28,10 @@ We need the following files:
## TLS on OAP servers
-By default, the communication between OAP nodes and the communication between receiver and probe share the same gRPC server. That means once you enabling SSL for receivers and probes, the OAP nodes will enable it too.
+By default, the communication between OAP nodes and the communication between receiver and probe share the same gRPC server. That means once you enable SSL for receivers and probes, the OAP nodes will enable it too.
-**NOTE**: SkyWalking **does not** support to enable mTLS on `OAP server nodes communication`. That means you have to enable `receiver-sharing-server` for enabling mTLS on communication between probes ang OAP servers. More details see [Enable mTLS mode on gRPC receiver](#enable-mtls-mode-on-grpc-receiver).
+**NOTE**: SkyWalking **does not** support enabling mTLS on `OAP server nodes communication`. That means you have to enable `receiver-sharing-server` for enabling mTLS on communication between probes and OAP servers. More details see [Enable mTLS mode on gRPC receiver](#enable-mtls-mode-on-grpc-receiver).
You can enable gRPC SSL by adding the following lines to `application.yml/core/default`.
@@ -46,7 +46,7 @@ gRPCSslTrustedCAPath: /path/to/ca.crt
`gRPCSslKeyPath` and `gRPCSslCertChainPath` are loaded by the OAP server to encrypt communication. `gRPCSslTrustedCAPath`
helps the gRPC client to verify server certificates in cluster mode.
-> There is a gRPC client and server in every OAP server node. The gRPC client comunicates with OAP servers in cluster mode. They are sharing the core module configuration.
+> There is a gRPC client and server in every OAP server node. The gRPC client communicates with OAP servers in cluster mode. They are sharing the core module configuration.
**When new files are in place, they can be loaded dynamically, and you won't have to restart an OAP instance.**
@@ -62,13 +62,13 @@ gRPCSslKeyPath: /path/to/server.pem
gRPCSslCertChainPath: /path/to/server.crt
```
-Since `recevier-sharing-server` only receives data from an external source, it doesn't need a CA at all. But you have to configure the CA for the clients, such as [Java agent](http://github.com/apache/skywalking-java), [Satellite](http://github.com/apache/skywalking-satellite). If you port to Java agent, refer to [the Java agent repo](http://github.com/apache/skywalking-java) to configure java agent and enable TLS.
+Since `receiver-sharing-server` only receives data from an external source, it doesn't need a CA at all. But you have to configure the CA for the clients, such as [Java agent](http://github.com/apache/skywalking-java), [Satellite](http://github.com/apache/skywalking-satellite). If you port to the Java agent, refer to [the Java agent repo](http://github.com/apache/skywalking-java) to configure the Java agent and enable TLS.
-**NOTE**: change the `SW_RECEIVER_GRPC_PORT` as non-zore to enable `receiver-sharing-server`. And the port is open for the clients.
+**NOTE**: change the `SW_RECEIVER_GRPC_PORT` as non-zero to enable `receiver-sharing-server`. And the port is open for the clients.
### Enable mTLS mode on gRPC receiver
-Since 8.8.0, SkyWalking supports enable mutual TLS authentication for transporting between clients and OAP servers. To enable `mTLS` mode for gRPC channel requires [Sharing gRPC Server](backend-expose.md) enabled, as the following configuration.
+Since 8.8.0, SkyWalking has supported mutual TLS authentication for transporting between clients and OAP servers. Enable `mTLS` mode for the gRPC channel requires [Sharing gRPC Server](backend-expose.md) enabled, as the following configuration.
```yaml
receiver-sharing-server:
diff --git a/docs/en/setup/backend/kafka-fetcher.md b/docs/en/setup/backend/kafka-fetcher.md
index 9e0215e067..dfb9bda304 100644
--- a/docs/en/setup/backend/kafka-fetcher.md
+++ b/docs/en/setup/backend/kafka-fetcher.md
@@ -1,11 +1,11 @@
# Kafka Fetcher
-The Kafka Fetcher pulls messages from the Kafka Broker to learn about what agent is delivered. Check the agent documentation for details. Typically, tracing segments, service/instance properties, JVM metrics, and meter system data are supported. Kafka Fetcher can work with gRPC/HTTP Receivers at the same time for adopting different transport protocols.
+The Kafka Fetcher pulls messages from the Kafka Broker to learn about what agents have delivered. Check the agent documentation for details on how to enable the Kafka reporter. Typically, tracing segments, service/instance properties, JVM metrics, and meter system data are supported (depending on the agent implementation). Kafka Fetcher can work with gRPC/HTTP Receivers simultaneously for adopting different transport protocols.
-Kafka Fetcher is disabled by default. To enable it, configure as follows.
+Kafka Fetcher is disabled by default. To enable it, configure it as follows.
-Namespace aims to isolate multi OAP cluster when using the same Kafka cluster.
-If you set a namespace for Kafka fetcher, the OAP will add a prefix to topic name. You should also set namespace in the property named `plugin.kafka.namespace` in `agent.config`.
+Namespace aims to isolate multi OAP clusters when using the same Kafka cluster.
+If you set a namespace for Kafka fetcher, the OAP will add a prefix to the topic name. You should also set the namespace in the property named `plugin.kafka.namespace` in `agent.config`.
```yaml
kafka-fetcher:
@@ -34,7 +34,7 @@ kafka-fetcher:
consumers: ${SW_KAFKA_FETCHER_CONSUMERS:1}
```
-In the cluster mode, all topics have the same number of partitions. Set `"isSharding"` to `"true"` and assign the partitions to consume for the OAP server. Use commas to separate multiple partitions for the OAP server.
+In the cluster mode, all topics have the same number of partitions. Set `"isSharding"` to `"true"` and assign the partitions to consume for the OAP server. Use commas to separate multiple partitions for the OAP server.
The Kafka Fetcher allows you to configure all the Kafka producers listed [here](http://kafka.apache.org/24/documentation.html#consumerconfigs) in property `kafkaConsumerConfig`. For example:
```yaml
@@ -73,7 +73,7 @@ kafka-fetcher:
```
## Other Fetcher Plugins
-There are other transporter plugins. You could find these plugins from 3rd party repositories.
+There are other transporter plugins. You can find these plugins from 3rd party repositories.
* [Pulsar Fetcher Plugin](https://github.com/SkyAPM/transporter-plugin-for-skywalking/blob/main/docs/en/pulsar/Pulsar-Fetcher.md)
diff --git a/docs/en/setup/backend/log-analyzer.md b/docs/en/setup/backend/log-analyzer.md
index 7e7ac27435..40edd87981 100644
--- a/docs/en/setup/backend/log-analyzer.md
+++ b/docs/en/setup/backend/log-analyzer.md
@@ -13,7 +13,7 @@ or [HTTP JSON array](../../protocols/Log-Data-Protocol.md#http-api).
#### Filebeat
Filebeat supports using Kafka to transport logs. Open [kafka-fetcher](kafka-fetcher.md#kafka-fetcher) and enable configs `enableNativeJsonLog`.
-Take the following filebeat config yaml as an example to set up Filebeat:
+Take the following Filebeat config YAML as an example to set up Filebeat:
- [filebeat.yml](../../../../test/e2e-v2/cases/kafka/log/filebeat.yml)
#### Fluentd
@@ -35,9 +35,9 @@ Read the doc on [Skywalking Exporter](https://github.com/open-telemetry/opentele
### Java agent's toolkits
Java agent provides toolkits for
-[log4j](https://github.com/apache/skywalking-java/blob/20fb8c81b3da76ba6628d34c12d23d3d45c973ef/docs/en/setup/service-agent/java-agent/Application-toolkit-log4j-1.x.md),
-[log4j2](https://github.com/apache/skywalking-java/blob/20fb8c81b3da76ba6628d34c12d23d3d45c973ef/docs/en/setup/service-agent/java-agent/Application-toolkit-log4j-2.x.md), and
-[logback](https://github.com/apache/skywalking-java/blob/20fb8c81b3da76ba6628d34c12d23d3d45c973ef/docs/en/setup/service-agent/java-agent/Application-toolkit-logback-1.x.md)
+[log4j](https://github.com/apache/skywalking-java/blob/main/docs/en/setup/service-agent/java-agent/Application-toolkit-log4j-1.x.md),
+[log4j2](https://github.com/apache/skywalking-java/blob/main/docs/en/setup/service-agent/java-agent/Application-toolkit-log4j-2.x.md), and
+[logback](https://github.com/apache/skywalking-java/blob/main/docs/en/setup/service-agent/java-agent/Application-toolkit-logback-1.x.md)
to report logs through gRPC with automatically injected trace context.
[SkyWalking Satellite sidecar](https://github.com/apache/skywalking-satellite) is a recommended proxy/side that
@@ -45,9 +45,9 @@ forwards logs (including the use of Kafka MQ to transport logs). When using this
and enable configs `enableNativeProtoLog`.
Java agent provides toolkits for
-[log4j](https://github.com/apache/skywalking-java/blob/20fb8c81b3da76ba6628d34c12d23d3d45c973ef/docs/en/setup/service-agent/java-agent/Application-toolkit-log4j-1.x.md#print-skywalking-context-in-your-logs),
-[log4j2](https://github.com/apache/skywalking-java/blob/20fb8c81b3da76ba6628d34c12d23d3d45c973ef/docs/en/setup/service-agent/java-agent/Application-toolkit-log4j-2.x.md#print-skywalking-context-in-your-logs), and
-[logback](https://github.com/apache/skywalking-java/blob/20fb8c81b3da76ba6628d34c12d23d3d45c973ef/docs/en/setup/service-agent/java-agent/Application-toolkit-logback-1.x.md#print-skywalking-context-in-your-logs)
+[log4j](https://github.com/apache/skywalking-java/blob/main/docs/en/setup/service-agent/java-agent/Application-toolkit-log4j-1.x.md#print-skywalking-context-in-your-logs),
+[log4j2](https://github.com/apache/skywalking-java/blob/main/docs/en/setup/service-agent/java-agent/Application-toolkit-log4j-2.x.md#print-skywalking-context-in-your-logs), and
+[logback](https://github.com/apache/skywalking-java/blob/main/docs/en/setup/service-agent/java-agent/Application-toolkit-logback-1.x.md#print-skywalking-context-in-your-logs)
to report logs through files with automatically injected trace context.
Log framework config examples:
@@ -66,7 +66,7 @@ To explore how to enable the reporting features for your use cases, please refer
## Log Analyzer
Log analyzer of OAP server supports native log data. OAP could use Log Analysis Language to
-structure log content through parsing, extracting, and saving logs.
+structure log content through parsing, extracting and saving logs.
The analyzer also uses Meter Analysis Language Engine for further metrics calculation.
```yaml
diff --git a/docs/en/setup/backend/metrics-exporter.md b/docs/en/setup/backend/metrics-exporter.md
index e7ef3d53a9..2b497861ac 100644
--- a/docs/en/setup/backend/metrics-exporter.md
+++ b/docs/en/setup/backend/metrics-exporter.md
@@ -1,9 +1,9 @@
# Metrics Exporter
SkyWalking provides the essential functions of metrics aggregation, alarm, and analysis.
-In the real world, many may want to forward their data to a 3rd party system for an in-depth analysis or otherwise.
+In many real-world scenarios, users may want to forward their data to a 3rd party system for further in-depth analysis.
**Metrics Exporter** has made that possible.
-Metrics exporter is an independent module that has to be manually activated.
+The metrics exporter is an independent module that has to be manually activated.
Right now, we provide the following exporters:
1. gRPC exporter
@@ -77,5 +77,5 @@ Return the expected metrics name list with event type (incremental or total). Al
Return empty list, if you want to export all metrics in the incremental event type.
### Export implementation
-Stream service. All subscribed metrics will be sent here based on the OAP core schedule. Also, if the OAP is deployed as cluster,
+Stream service. All subscribed metrics will be sent here based on the OAP core schedule. Also, if the OAP is deployed as a cluster,
this method will be called concurrently. For metrics value, you need to follow `#type` to choose `#longValue` or `#doubleValue`.
diff --git a/docs/en/setup/backend/mq.md b/docs/en/setup/backend/mq.md
index 61b75595bb..32dec4e16a 100644
--- a/docs/en/setup/backend/mq.md
+++ b/docs/en/setup/backend/mq.md
@@ -1,12 +1,12 @@
# Message Queue performance and consuming latency monitoring
-Message Queue server plays an important role in today's distributed system, in order to reduce the length and latency of
-blocking RPC, and eventually improve user experience. But in this async way, the measure for queue consuming traffic and
+Message Queue server plays an essential role in today's distributed system to reduce the length and latency of
+blocking RPC and eventually improve user experience. But in this async way, the measure for queue consuming traffic and
latency becomes significant.
Since 8.9.0, SkyWalking leverages native tracing agent and [**Extension Header
Item** of SkyWalking Cross Process Propagation Headers Protocol v3](../../protocols/Skywalking-Cross-Process-Propagation-Headers-Protocol-v3.md#extension-header-item)
-, to provide performance monitoring for Message Queue system.
+To provide performance monitoring for the Message Queue systems.
In default, we provide `Message Queue Consuming Count` and `Message Queue Avg Consuming Latency` metrics for service and
endpoint levels.
diff --git a/docs/en/setup/backend/opentelemetry-receiver.md b/docs/en/setup/backend/opentelemetry-receiver.md
index 4447e1fc68..b6b3c58648 100644
--- a/docs/en/setup/backend/opentelemetry-receiver.md
+++ b/docs/en/setup/backend/opentelemetry-receiver.md
@@ -36,4 +36,4 @@ for identification of the metric data.
|k8s-node| Metrics of K8s cluster | otel-oc-rules/k8s-node.yaml | cAdvisor & K8s kube-state-metrics -> OpenTelemetry Collector --OC format--> SkyWalking OAP Server |
|k8s-service| Metrics of K8s cluster | otel-oc-rules/k8s-service.yaml | cAdvisor & K8s kube-state-metrics -> OpenTelemetry Collector --OC format--> SkyWalking OAP Server |
-Note: You can also use OpenTelemetry exporter to directly transport the metrics to SkyWalking OAP. See [OpenTelemetry Exporter](./backend-meter.md#opentelemetry-exporter).
+**Note**: You can also use OpenTelemetry exporter to transport the metrics to SkyWalking OAP directly. See [OpenTelemetry Exporter](./backend-meter.md#opentelemetry-exporter).
diff --git a/docs/en/setup/backend/prometheus-metrics.md b/docs/en/setup/backend/prometheus-metrics.md
index 918f0630e2..f14113c871 100644
--- a/docs/en/setup/backend/prometheus-metrics.md
+++ b/docs/en/setup/backend/prometheus-metrics.md
@@ -1,5 +1,5 @@
# Prometheus Fetcher
-Prometheus fetcher reads metrics from Prometheus endpoint, and transfer the metrics into SkyWalking native format for the MAL engine.
+Prometheus fetcher reads metrics from the Prometheus endpoint and transfers the metrics into SkyWalking native format for the MAL engine.
## Configuration file
Prometheus fetcher is configured via a configuration file. The configuration file defines everything related to fetching
@@ -14,10 +14,10 @@ A full example can be found [here](../../../../oap-server/server-starter/src/mai
Generic placeholders are defined as follows:
-* `<duration>`: This is parsed into a textual representation of a duration. The formats accepted are based on
- the ISO-8601 duration format `PnDTnHnMn.nS` with days considered to be exactly 24 hours.
+* `<duration>`: This is parsed into a textual representation of a duration. The accepted formats are based on
+ the ISO-8601 duration format `PnDTnHnMn.nS` with days of exactly 24 hours.
* `<labelname>`: A string matching the regular expression \[a-zA-Z_\]\[a-zA-Z0-9_\]*.
-* `<labelvalue>`: A string of unicode characters.
+* `<labelvalue>`: A string of Unicode characters.
* `<host>`: A valid string consisting of a hostname or IP followed by an optional port number.
* `<path>`: A valid URL path.
* `<string>`: A regular string.
diff --git a/docs/en/setup/backend/service-auto-grouping.md b/docs/en/setup/backend/service-auto-grouping.md
index 1c3cb6c945..a0d493f82c 100644
--- a/docs/en/setup/backend/service-auto-grouping.md
+++ b/docs/en/setup/backend/service-auto-grouping.md
@@ -9,7 +9,7 @@ Therefore, since version 8.3.0, the SkyWalking OAP has generated the groups base
### ${service name} = [${group name}::]${logic name}
If the service name includes double colons (`::`), the literal string before the colons is taken as the group name.
-In the latest GraphQL query, the group name has been provided as an option parameter.
+In the latest GraphQL query, the group name has been provided as an optional parameter.
> getAllServices(duration: Duration!, group: String): [Service!]!
RocketBot UI dashboards (`Standard` type) support the `group name` for default and custom configurations.
diff --git a/docs/en/setup/backend/slow-db-statement.md b/docs/en/setup/backend/slow-db-statement.md
index 0e7c96b5df..4a4a914644 100644
--- a/docs/en/setup/backend/slow-db-statement.md
+++ b/docs/en/setup/backend/slow-db-statement.md
@@ -1,7 +1,7 @@
# Slow Database Statement
-Slow Database statements are crucial in order for you to identify bottlenecks of a system which relies on the database.
+Slow Database statements are crucial for you to identify bottlenecks of a system which relies on databases.
-Slow DB statements are based on sampling. Right now, the core samples the top 50 slowest every 10 minutes.
+Slow DB statements are based on sampling. Right now, the core samples are the top 50 slowest every 10 minutes.
Note that the duration of these statements must be slower than the threshold.
Here's the format of the settings (in milliseconds):
diff --git a/docs/en/setup/backend/trace-sampling.md b/docs/en/setup/backend/trace-sampling.md
index 02172255b0..c27efc60ed 100644
--- a/docs/en/setup/backend/trace-sampling.md
+++ b/docs/en/setup/backend/trace-sampling.md
@@ -1,9 +1,10 @@
# Trace Sampling at server side
An advantage of a distributed tracing system is that detailed information from the traces can be obtained. However, the downside is that these traces use up a lot of storage.
-If you enable the trace sampling mechanism at the server side, you will find that the metrics of the service, service instance, endpoint, and topology all have the same accuracy as before. The only difference is that they do not save all traces into storage.
+
+If you enable the trace sampling mechanism at the **server-side**, you will find that the service metrics, service instance, endpoint, and topology all have the same accuracy as before. The only difference is that they do not save all traces in storage.
Of course, even if you enable sampling, the traces will be kept as consistent as possible. Being **consistent** means that once the trace
-segments have been collected and reported by agents, the backend would do their best not to split the traces. See our [recommendation](#recommendation)
+segments have been collected and reported by agents, the backend would make its best effort not to split the traces. See our [recommendation](#recommendation)
to understand why you should keep the traces as consistent as possible and try not to split them.
## Set the sample rate
@@ -25,7 +26,7 @@ default:
# The sample rate precision is 1/10000. 10000 means 100% sample in default.
rate: 10000
# Default trace latency time that replaces the 'agent-analyzer.default.slowTraceSegmentThreshold'
- # Setting this threshold about the latency would make the slow trace segments sampled if they cost more time, even the sampling mechanism activated. The default value is `-1`, which means would not sample slow traces. Unit, millisecond.
+ # Setting this threshold about the latency would make the slow trace segments sampled if they cost more time, even the sampling mechanism is activated. The default value is `-1`, which would not sample slow traces. Unit, millisecond.
duration: -1
#services:
# - name: serverName
@@ -36,10 +37,10 @@ default:
`duration.rate` allows you to set the sample rate to this backend.
The sample rate precision is 1/10000. 10000 means 100% sample by default.
-`forceSampleErrorSegment` allows you to save all error segments when sampling mechanism is activated.
-When sampling mechanism is activated, this config would cause the error status segment to be sampled, ignoring the sampling rate.
+`forceSampleErrorSegment` allows you to save all error segments when the sampling mechanism is activated.
+This config will cause the error status segment to be sampled when the sampling mechanism is activated, ignoring the sampling rate.
-`default.duration` allows you to save all slow trace segments when sampling mechanism is activated.
+`default.duration` allows you to save all slow trace segments when the sampling mechanism is activated.
Setting this threshold on latency (in milliseconds) would cause slow trace segments to be sampled if they use up more time, even if the sampling mechanism is activated. The default value is `-1`, which means that slow traces would not be sampled.
**Note:**
@@ -52,9 +53,9 @@ When you set the different rates, let's say:
* Backend-Instance**A**.sampleRate = 35
* Backend-Instance**B**.sampleRate = 55
-Assume the agents have reported all trace segments to the backend. 35% of the traces at the global level will be collected and saved in storage consistently/completely together with all spans. 20% of the trace segments which are reported to Backend-Instance **B** will be saved in storage, whereas some trace segments may be missed, as they are reported to Backend-Instance**A** and ignored.
+Assume the agents have reported all trace segments to the backend. 35% of the traces at the global level will be collected and saved in storage consistently/completely together with all spans. 20% of the trace segments reported to Backend-Instance **B** will be saved in storage, whereas some trace segments may be missed, as they are reported to Backend-Instance**A** and ignored.
# Note
-When you enable sampling, the actual sample rate may exceed sampleRate. The reason is that currently all error/slow segments will be saved; meanwhile, the upstream and downstream may not be sampled. This feature ensures that you have the error/slow stacks and segments, although it is not guaranteed that you would have the whole traces.
+When you enable sampling, the actual sample rate may exceed sampleRate. The reason is that currently, all error/slow segments will be saved; meanwhile, the upstream and downstream may not be sampled. This feature ensures that you have the error/slow stacks and segments, although it is not guaranteed that you would have the whole traces.
-Note also if most of the access have failed or are slow, the sampling rate would be close to 100%. This may cause the backend or storage clusters to crash.
+Note that if most of the accesses have failed or are slow, the sampling rate would be close to 100%. This may cause the backend or storage clusters to crash.
diff --git a/docs/en/setup/backend/ui-setup.md b/docs/en/setup/backend/ui-setup.md
index 48be2a76b2..2121cec314 100644
--- a/docs/en/setup/backend/ui-setup.md
+++ b/docs/en/setup/backend/ui-setup.md
@@ -5,7 +5,7 @@ SkyWalking UI distribution is already included in our Apache official release.
Startup script is also in `/bin/webappService.sh`(.bat). UI runs as an OS Java process, powered-by Zuul.
## Settings
-Settings file of UI is `webapp/webapp.yml` in distribution package. It has three parts.
+The settings file of UI is `webapp/webapp.yml` in the distribution package. It has three parts.
1. Listening port.
1. Backend connect info.
@@ -34,7 +34,7 @@ spring:
## Start with Docker Image
-Start a container to connect oap server whose address is `http://oap:12800`.
+Start a container to connect OAP server whose address is `http://oap:12800`.
```shell
docker run --name oap --restart always -d -e SW_OAP_ADDRESS=http://oap:12800 apache/skywalking-ui:8.8.0
@@ -46,4 +46,4 @@ We could set up environment variables to configure this image.
### SW_OAP_ADDRESS
-The address of OAP server. Default value is `http://127.0.0.1:12800`.
\ No newline at end of file
+The address of your OAP server. The default value is `http://127.0.0.1:12800`.
\ No newline at end of file
diff --git a/docs/en/setup/backend/uninstrumented-gateways.md b/docs/en/setup/backend/uninstrumented-gateways.md
index 073cefcb21..4f46b04e45 100755
--- a/docs/en/setup/backend/uninstrumented-gateways.md
+++ b/docs/en/setup/backend/uninstrumented-gateways.md
@@ -1,9 +1,9 @@
# Uninstrumented Gateways/Proxies
-The uninstrumented gateways are not instrumented by SkyWalking agent plugin when they are started,
+The uninstrumented gateways are not instrumented by the SkyWalking agent plugin when they start,
but they can be configured in `gateways.yml` file or via [Dynamic Configuration](dynamic-config.md). The reason why they can't register
-to backend automatically is that there're no suitable agent plugins. For example, there are no agent plugins for Nginx, haproxy, etc.
-So in order to visualize the real topology, we provide a way to configure the gateways/proxies manually.
+to backend automatically is that there are no suitable agent plugins. For example, there are no agent plugins for Nginx, HAProxy, etc.
+So to visualize the real topology, we provide a way to configure the gateways/proxies manually.
## Configuration Format
@@ -13,10 +13,10 @@ The configuration content includes gateway names and their instances:
gateways:
- name: proxy0 # the name is not used for now
instances:
- - host: 127.0.0.1 # the host/ip of this gateway instance
- port: 9099 # the port of this gateway instance, defaults to 80
+ - host: 127.0.0.1 # the host/IP of this gateway instance
+ port: 9099 # the port of this gateway instance defaults to 80
```
-**Note**: The `host` of the instance must be the one that is actually used at client side. For example,
+**Note**: The `host` of the instance must be the one that is actually used on the client-side. For example,
if instance `proxyA` has 2 IPs, say `192.168.1.110` and `192.168.1.111`, both of which delegate the target service,
and the client connects to `192.168.1.110`, then configuring `192.168.1.111` as the `host` won't work properly.
diff --git a/docs/en/setup/backend/zipkin-trace.md b/docs/en/setup/backend/zipkin-trace.md
index 35f6c9c769..450769aa76 100644
--- a/docs/en/setup/backend/zipkin-trace.md
+++ b/docs/en/setup/backend/zipkin-trace.md
@@ -1,8 +1,7 @@
## Zipkin receiver
-The Zipkin receiver makes the OAP server work as an alternative Zipkin server implementation. It supports Zipkin v1/v2 formats through HTTP service.
+The Zipkin receiver makes the OAP server work as an alternative Zipkin server implementation. It supports Zipkin v1/v2 formats through the HTTP service.
Make sure you use this with `SW_STORAGE=zipkin-elasticsearch` option to activate Zipkin storage implementation.
-Once this receiver and storage are activated, SkyWalking's native traces would be ignored, and SkyWalking wouldn't analyze topology, metrics, and endpoint
-dependency from Zipkin's trace.
+Once this receiver and storage are activated, SkyWalking's native traces would be ignored, and SkyWalking wouldn't analyze topology, metrics, and endpoint dependency from Zipkin's trace.
Use the following config to activate it.
```yaml
diff --git a/docs/en/setup/envoy/als_setting.md b/docs/en/setup/envoy/als_setting.md
index 7cc5206c0b..bc8d0fb9b7 100644
--- a/docs/en/setup/envoy/als_setting.md
+++ b/docs/en/setup/envoy/als_setting.md
@@ -9,7 +9,7 @@ The solution was initialized and first implemented by [Sheng Wu](https://github.
and [Dhi Aurrahman](https://github.com/dio) on May 17, 2019, and was presented at [KubeCon China 2019](https://kccncosschn19eng.sched.com/event/NroB/observability-in-service-mesh-powered-by-envoy-and-apache-skywalking-sheng-wu-lizan-zhou-tetrate).
Here is a [video recording of the presentation](https://www.youtube.com/watch?v=tERm39ju9ew).
-SkyWalking is the first open source project that introduced an ALS-based solution to the world. This solution provides a new take on observability with a lightweight payload on the service mesh.
+SkyWalking is the first open-source project that introduced an ALS-based solution to the world. This solution provides a new take on observability with a lightweight payload on the service mesh.
## Enable ALS and SkyWalking Receiver
@@ -51,7 +51,7 @@ envoy-metric:
## Example
-Here's an example on installing Istio and deploying SkyWalking by Helm chart.
+Here's an example of installing Istio and deploying SkyWalking by Helm chart.
```shell
istioctl install \
@@ -84,9 +84,9 @@ result, it stops the loop.
### `k8s-mesh`
-`k8s-mesh` uses the metadata from Kubernetes cluster, hence in this analyzer OAP needs access roles to `Pod`, `Service`, and `Endpoints`.
+`k8s-mesh` uses the metadata from Kubernetes clusters, hence in this analyzer, OAP needs access roles to `Pod`, `Service`, and `Endpoints`.
-The [blog](https://skywalking.apache.org/blog/2020-12-03-obs-service-mesh-with-sw-and-als/) illustrates the details of how it works, and a step-by-step tutorial to apply it into the `bookinfo` application.
+The [blog](https://skywalking.apache.org/blog/2020-12-03-obs-service-mesh-with-sw-and-als/) illustrates the details of how it works and a step-by-step tutorial to apply it to the `bookinfo` application.
### `mx-mesh`
@@ -94,7 +94,7 @@ The [blog](https://skywalking.apache.org/blog/2020-12-03-obs-service-mesh-with-s
This analyzer requires Istio to enable the metadata exchange plugin (you can enable it by `--set values.telemetry.v2.enabled=true`,
or if you're using Istio 1.7+ and installing it with profile `demo`/`preview`, it should already be enabled).
-The [blog](https://skywalking.apache.org/blog/obs-service-mesh-vm-with-sw-and-als/) illustrates the details of how it works, and a step-by-step tutorial to apply it into the [Online Boutique](https://github.com/GoogleCloudPlatform/microservices-demo) system.
+The [blog](https://skywalking.apache.org/blog/obs-service-mesh-vm-with-sw-and-als/) illustrates the details of how it works and a step-by-step tutorial on applying it to the [Online Boutique](https://github.com/GoogleCloudPlatform/microservices-demo) system.
### `persistence`
diff --git a/docs/en/setup/envoy/examples/metrics/README.md b/docs/en/setup/envoy/examples/metrics/README.md
index 9e67c900ca..eb8ae15b7c 100644
--- a/docs/en/setup/envoy/examples/metrics/README.md
+++ b/docs/en/setup/envoy/examples/metrics/README.md
@@ -1,13 +1,13 @@
# Sending Envoy Metrics to SkyWalking OAP Server Example
-This is an example of sending [Envoy Stats](https://www.envoyproxy.io/docs/envoy/v1.19.1/intro/arch_overview/observability/statistics) to SkyWalking OAP server
+This is an example of sending [Envoy Stats](https://www.envoyproxy.io/docs/envoy/v1.19.1/intro/arch_overview/observability/statistics) to the SkyWalking OAP server
through Metric Service [v2](https://www.envoyproxy.io/docs/envoy/v1.18.2/api-v2/config/metrics/v2/metrics_service.proto) and [v3](https://www.envoyproxy.io/docs/envoy/v1.19.1/api-v3/config/metrics/v3/metrics_service.proto).
## Running the example
The example requires `docker` and `docker-compose` to be installed in your local system. It fetches images from Docker Hub.
-Note that in this setup, we override the [`log4j2.xml`](log4j2.xml) config to set the `org.apache.skywalking.oap.server.receiver.envoy` logger level to `DEBUG`. This enables us to see the messages sent by Envoy to SkyWalking OAP server.
+Note that in this setup, we override the [`log4j2.xml`](log4j2.xml) config to set the `org.apache.skywalking.oap.server.receiver.envoy` logger level to `DEBUG`. This enables us to see the messages sent by Envoy to the SkyWalking OAP server.
You can also find the Envoy Metric Service V3 API example in [docker-compose-envoy-v3-api.yaml](./docker-compose-envoy-v3-api.yaml)
```
@@ -112,4 +112,3 @@ skywalking_1 | }
$ # To tear down:
$ make down
```
-
diff --git a/docs/en/setup/envoy/metrics_service_setting.md b/docs/en/setup/envoy/metrics_service_setting.md
index 8356c19fa8..4ad232ff43 100644
--- a/docs/en/setup/envoy/metrics_service_setting.md
+++ b/docs/en/setup/envoy/metrics_service_setting.md
@@ -1,19 +1,19 @@
-# Send Envoy metrics to SkyWalking with / without Istio
+# Send Envoy metrics to SkyWalking with/without Istio
Envoy defines a gRPC service to emit metrics, and whatever is used to implement this protocol can be used to receive the metrics.
SkyWalking has a built-in receiver that implements this protocol, so you can configure Envoy to emit its metrics to SkyWalking.
-As an APM system, SkyWalking does not only receive and store the metrics emitted by Envoy, but it also analyzes the topology of services and service instances.
+As an APM system, SkyWalking not only receives and stores the metrics emitted by Envoy but also analyzes the topology of services and service instances.
-**Attention:** There are two versions of Envoy metrics service protocol currently:
+**Attention:** There are two versions of the Envoy metrics service protocol currently:
[v2](https://www.envoyproxy.io/docs/envoy/v1.18.2/api-v2/api/v2/core/grpc_service.proto#envoy-api-msg-core-grpcservice) and
[v3](https://www.envoyproxy.io/docs/envoy/v1.18.2/api-v3/config/metrics/v3/metrics_service.proto). SkyWalking (8.3.0+) supports both of them.
## Configure Envoy to send metrics to SkyWalking without Istio
-Envoy can be used with / without Istio. This section explains how you can configure the standalone Envoy to send metrics to SkyWalking.
+Envoy can be used with/without Istio. This section explains how you can configure the standalone Envoy to send metrics to SkyWalking.
-In order to let Envoy send metrics to SkyWalking, we need to feed Envoy with a configuration that contains `stats_sinks`, which in turn includes `envoy.metrics_service`.
+To let Envoy send metrics to SkyWalking, we need to feed Envoy with a configuration that contains `stats_sinks`, which in turn includes `envoy.metrics_service`.
This `envoy.metrics_service` should be configured as a [`config.grpc_service`](https://www.envoyproxy.io/docs/envoy/v1.18.2/api-v2/api/v2/core/grpc_service.proto#envoy-api-msg-core-grpcservice) entry.
The noteworthy parts of the config are shown below:
@@ -52,7 +52,7 @@ The comprehensive static configuration can be found [here](config.yaml).
Note that Envoy can also be configured dynamically through [xDS Protocol](https://github.com/envoyproxy/envoy/blob/v1.18.2/api/xds_protocol.rst).
-As mentioned above, SkyWalking also builds the topology of services from the metrics, since Envoy also carries service metadata along with the metrics. To feed Envoy such metadata, see the other part of the configuration as follows:
+As mentioned above, SkyWalking also builds the topology of services from the metrics since Envoy also carries service metadata along with the metrics. To feed Envoy such metadata, see the other part of the configuration as follows:
```yaml
node:
@@ -88,7 +88,7 @@ istioctl manifest install -y \
Note:
`proxyStatsMatcher` is only supported by `Istio 1.8+`.
-We recommend using `inclusionRegexps` to reserve specific metrics which need to be analyzed, in order to reduce memory usage and avoid CPU overhead.
+We recommend using `inclusionRegexps` to reserve specific metrics that need to be analyzed to reduce memory usage and avoid CPU overhead.
For example, OAP uses these metrics:
```shell
diff --git a/docs/en/setup/istio/README.md b/docs/en/setup/istio/README.md
index bfcdb55139..36d8aefc99 100644
--- a/docs/en/setup/istio/README.md
+++ b/docs/en/setup/istio/README.md
@@ -4,7 +4,7 @@ This document provides instructions on transporting Istio's metrics to the SkyWa
## Prerequisites
-Istio should be installed in the Kubernetes cluster. Simply follow the steps in [Getting Started in Istio](https://istio.io/docs/setup/getting-started/).
+Istio should be installed in a Kubernetes cluster. Simply follow the steps in [Getting Started in Istio](https://istio.io/docs/setup/getting-started/).
## Deploying SkyWalking backend
@@ -14,12 +14,12 @@ Refer to [OpenTelemetry receiver](../backend/opentelemetry-receiver.md) to inges
## Deploying OpenTelemetry Collector
-OpenTelemetry Collector is the location where Istio telemetry sends metrics, which is then processed and sent to SkyWalking
+OpenTelemetry Collector is the location where Istio telemetry sends metrics, which are then processed and shipped to SkyWalking
backend.
-Follow the steps in [Getting Started in OpenTelemetry Collector](https://opentelemetry.io/docs/collector/getting-started/) to deploy this collector. There are several components available in the collector, and they could be combined for different use cases.
- For the sake of brevity, we use the Prometheus receiver to retrieve metrics from Istio control and data plane,
- then send them to SkyWalking by OpenCensus exporter.
+To deploy this collector, follow the steps in [Getting Started in OpenTelemetry Collector](https://opentelemetry.io/docs/collector/getting-started/). Several components are available in the collector, and they could be combined for different use cases.
+
+For the sake of brevity, we use the Prometheus receiver to retrieve metrics from Istio control and data plane, then send them to SkyWalking by OpenCensus exporter.
#### Prometheus Receiver
Refer to [Prometheus Receiver](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/150692dbbceb3ff0df75c912e835f1feaac0be93/receiver/prometheusreceiver/README.md)
@@ -54,7 +54,7 @@ Try to fix it using the solution described in the issue.
#### OpenCensus exporter
Follow [OpenCensus exporter configuration](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/a08903f05d3a544f548535c222b1c205b9f5a154/exporter/opencensusexporter/README.md)
-to set up a connection between OpenTelemetry Collector and OAP cluster. `endpoint` is the address of OAP gRPC service.
+to set up a connection between OpenTelemetry Collector and OAP cluster. `endpoint` is the address of the OAP gRPC service.
## Observing Istio
@@ -62,4 +62,4 @@ Open Istio Dashboard in SkyWaling UI by clicking `Dashboard` -> `Istio`. You can
generated by Istio metrics. You may also view them through `swctl` and set up alarm rules based on them.
-NOTE: If you would like to see metrics of Istio managed services, including topology, you may try our [ALS solution](../envoy/als_setting.md).
+Note: If you would like to see metrics of Istio managed services, including topology, you may try our [ALS solution](../envoy/als_setting.md).
diff --git a/docs/en/setup/service-agent/agent-compatibility.md b/docs/en/setup/service-agent/agent-compatibility.md
index 02c62bba58..5157115d98 100644
--- a/docs/en/setup/service-agent/agent-compatibility.md
+++ b/docs/en/setup/service-agent/agent-compatibility.md
@@ -1,6 +1,6 @@
# Compatibility
-SkyWalking 8.0+ uses v3 protocols. Agents don't have to keep the same versions as the OAP backend.
+SkyWalking 8.0+ uses v3 protocols. Agents don't have to keep the identical versions as the OAP backend.
## SkyWalking Native Agents
@@ -14,7 +14,7 @@ SkyWalking 8.0+ uses v3 protocols. Agents don't have to keep the same versions a
## Ecosystem Agents
-All following agent implementations are a part of SkyWalking ecosystem. All the source codes and their distributions
+All following agent implementations are a part of the SkyWalking ecosystem. All the source codes and their distributions
don't belong to the Apache Software Foundation.
|OAP Server Version|DotNet|Go2sky|cpp2sky|PHP agent|
@@ -23,8 +23,8 @@ don't belong to the Apache Software Foundation.
8.4.0+ | \> = 1.0.0 | \> = 0.4.0 | All | \> = 3.0.0|
9.0.0+ | \> = 1.0.0 | \> = 0.4.0 | All | \> = 3.0.0|
-All these projects are maintained by their own communities, please reach them if you face any compatibility issue.
+All these projects are maintained by their own communities, and please reach them if you face any compatibility issues.
___
-All above compatibility are only references, if you face `unimplemented` error, it means you need to upgrade OAP backend
+All above compatibility are only references, and if you face an `unimplemented` error, it means you need to upgrade the OAP backend
to support newer features in the agents.
diff --git a/docs/en/setup/service-agent/browser-agent.md b/docs/en/setup/service-agent/browser-agent.md
index 8e5bd2f701..64f86e146c 100644
--- a/docs/en/setup/service-agent/browser-agent.md
+++ b/docs/en/setup/service-agent/browser-agent.md
@@ -3,7 +3,7 @@
It has these features:
- Provides metrics and error collection to SkyWalking backend.
-- Lightweight. No browser plugin required. A simple JavaScript library.
+- Lightweight. A simple JavaScript library. No browser plugin is required.
- Browser serves as a starting point for the entire distributed tracing system.
See Client JS [official doc](https://github.com/apache/skywalking-client-js#quick-start) for more information.
diff --git a/docs/en/setup/service-agent/server-agents.md b/docs/en/setup/service-agent/server-agents.md
index b3f657b51a..ac140d4b65 100644
--- a/docs/en/setup/service-agent/server-agents.md
+++ b/docs/en/setup/service-agent/server-agents.md
@@ -1,35 +1,31 @@
# Server Agents
-Server agents in various languages provide auto-instrumentation or/and manual-instrumentation(APIs-based) mechanism to
-integrate with target services. They support collecting traces, logs, metrics and events by using SkyWalking's native
-format, and maximum the analysis capabilities of SkyWalking OAP server.
+Server agents in various languages provide auto-instrumentation or/and manual-instrumentation(APIs-based) mechanisms to
+integrate with target services. They support collecting traces, logs, metrics, and events using SkyWalking's native
+format and maximize the analysis capabilities of the SkyWalking OAP server.
## Installing language agents in services
-- [Java agent](http://github.com/apache/skywalking-java). Learn how to install the Java agent in your service without
- affecting your code.
+- [Java agent](https://skywalking.apache.org/docs/skywalking-java/latest/en/setup/service-agent/java-agent/readme/). Learn how to install the Java agent in your service without affecting your code.
-- [LUA agent](https://github.com/apache/skywalking-nginx-lua). Learn how to install the Lua agent in Nginx + LUA module
- or OpenResty.
+- [LUA agent](https://github.com/apache/skywalking-nginx-lua). Learn how to install the Lua agent in Nginx + LUA module or OpenResty.
- [Kong agent](https://github.com/apache/skywalking-kong). Learn how to install the Lua agent in Kong.
-- [Python Agent](https://github.com/apache/skywalking-python). Learn how to install the Python Agent in a Python
- service.
+- [Python Agent](https://skywalking.apache.org/docs/skywalking-python/latest/en/setup/cli/). Learn how to install the Python Agent in a Python service without affecting your code.
-- [Node.js agent](https://github.com/apache/skywalking-nodejs). Learn how to install the NodeJS Agent in a NodeJS
- service.
+- [Node.js agent](https://github.com/apache/skywalking-nodejs). Learn how to install the NodeJS Agent in a NodeJS service.
-- [Rust agent](https://github.com/apache/skywalking-rust). Learn how to integrate the rust agent in a rust service.
+- [Rust agent](https://github.com/apache/skywalking-rust). Learn how to integrate the Rust agent with a rust service.
-The following agents and SDKs are compatible with SkyWalking's data formats and network protocols, but are maintained by
+The following agents and SDKs are compatible with SkyWalking's data formats and network protocols but are maintained by
third parties. See their project repositories for guides and releases.
-- [SkyAPM .NET Core agent](https://github.com/SkyAPM/SkyAPM-dotnet). See .NET Core agent project document for more
+- [SkyAPM .NET Core agent](https://github.com/SkyAPM/SkyAPM-dotnet). See .NET Core agent project documentation for more
details.
-- [SkyAPM PHP agent](https://github.com/SkyAPM/SkyAPM-php-sdk). See PHP agent project document for more details.
+- [SkyAPM PHP agent](https://github.com/SkyAPM/SkyAPM-php-sdk). See PHP agent project documentation for more details.
-- [SkyAPM Go SDK](https://github.com/SkyAPM/go2sky). See go2sky project document for more details.
+- [SkyAPM Go SDK](https://github.com/SkyAPM/go2sky). See go2sky project documentation for more details.
-- [SkyAPM C++ SDK](https://github.com/SkyAPM/cpp2sky). See cpp2sky project document for more details.
+- [SkyAPM C++ SDK](https://github.com/SkyAPM/cpp2sky). See cpp2sky project documentation for more details.
diff --git a/docs/en/setup/service-agent/virtual-database.md b/docs/en/setup/service-agent/virtual-database.md
index fcef2ca042..7acb158eff 100644
--- a/docs/en/setup/service-agent/virtual-database.md
+++ b/docs/en/setup/service-agent/virtual-database.md
@@ -1,11 +1,10 @@
# Virtual Database
-Virtual databases represents the database nodes detected by [server agents' plugins](server-agents.md). The performance
-metrics of the databases are also from Database client side perspective.
+Virtual databases represent the database nodes detected by [server agents' plugins](server-agents.md). The performance
+metrics of the databases are also from the Database client-side perspective.
-For example, JDBC plugins(MySQL, PostgreSQL, Mariadb, MSSQL) in the Java agent could detect the latency of SQL
-performance, as well as SQL statements. As a result, in this dashboard, SkyWalking would show database traffic, latency,
-success rate and sampled slow SQLs powered by backend analysis capabilities.
+For example, JDBC plugins(MySQL, PostgreSQL, MariaDB, MSSQL) in the Java agent could detect the latency of SQL
+performance and SQL statements. As a result, SkyWalking would show database traffic, latency, success rate, and sampled slow SQLs powered by backend analysis capabilities in this dashboard.
The Database access span should have
- It is an **Exit** span
diff --git a/docs/en/ui/README.md b/docs/en/ui/README.md
index e063a90530..9429d0c4cd 100644
--- a/docs/en/ui/README.md
+++ b/docs/en/ui/README.md
@@ -1,39 +1,36 @@
# Introduction to UI
-The SkyWalking official UI provides the default and powerful visualization capabilities for SkyWalking to observe
-full-stack application.
+The SkyWalking official UI provides the default and powerful visualization capabilities for SkyWalking to observe full-stack applications.
<img src="https://skywalking.apache.org/ui-doc/9.0.0/home.png"/>
-The left side menu lists all available supported stack, with default dashboards.
+The left side menu lists all available supported stacks with default dashboards.
-Follow `Official Dashboards` menu explores all default dashboards about how to monitor different tech stacks.
+Follow the `Official Dashboards` menu to explore all default dashboards on their ways to monitor different tech stacks.
## Custom Dashboard
-Besides, official dashboards, **Dashboards** provides customization to end users to add new tabs/pages/widgets, and
+Besides official dashboards, **Dashboards** provide customization capabilities to end-users to add new tabs/pages/widgets, and
flexibility to re-config the dashboard on your own preference.
The dashboard has two key attributes, **Layer** and **Entity Type**. Learn these two concepts first before you begin any
-customization. Also, trace, metrics, log analysis are relative to OAL, MAL, and LAL engines in SkyWalking kernel. You
-should learn them first too.
+customization. Also, trace, metrics, and log analysis are relative to OAL, MAL, and LAL engines in the SkyWalking kernel. It would help if you
+learned them first, too.
-Service and All entity type dashboard could be set as root(`set this to root`), which mean this dashboard would be used
-as the entrance of its layer. If you have multiple root dashboards, UI could choose one randomly(Don't recommend doing
+Service and All entity type dashboard could be set as root(`set this to root`), which means this dashboard would be used
+as the entrance of its Layer. If you have multiple root dashboards, UI will choose one randomly (We don't recommend doing
so).
-**Notice, dashboard editable is disabled on release, set system env(**SW_ENABLE_UPDATE_UI_TEMPLATE=true**) to activate
-them.** Before you save the edited dashboard, it is just stored in memory, closing tab would LOSE the change
-permanently.
+**Notice, dashboard editable is disabled on release; set system env(**SW_ENABLE_UPDATE_UI_TEMPLATE=true**) to activate
+them.** Before you save the edited dashboard, it is just stored in memory. Closing a tab would **LOSE** the change permanently.
## Settings
-Settings provide language, server time zone, and auto-fresh option. These settings are stored in browser local
-storage. Unless you clear them manually, those would not change.
+Settings provide language, server time zone, and auto-fresh options. These settings are stored in the browser's local storage. Unless you clear them manually, those will not change.
## FAQ
### Login and Authentication
SkyWalking doesn't provide login and authentication as usual for years. If you need, a lot of Gateway solutions have
-provides well-established solutions, such as Nginx ecosystem.
\ No newline at end of file
+provides well-established solutions, such as the Nginx ecosystem.