@@ -91,74 +91,12 @@ We advise against trying to change the APIs of those modules, unless you underst
...
@@ -91,74 +91,12 @@ We advise against trying to change the APIs of those modules, unless you underst
The required modules are listed here:
The required modules are listed here:
1.**Core**. Provides the basic and major skeleton of all data analysis and stream dispatch.
1.**Core**. Provides the basic and major skeleton of all data analysis and stream dispatch.
1.**Cluster**. Manages multiple backend instances in a cluster, which could provide high throughputs process
1.**Cluster**. Manages multiple backend instances in a cluster, which could provide high throughput process
capabilities.
capabilities. See [**Cluster Management**](backend-cluster.md) for more details.
1.**Storage**. Makes the analysis result persistent.
1.**Storage**. Makes the analysis result persistent. See [**Choose storage**](backend-storage.md) for more details
1.**Query**. Provides query interfaces to UI.
1.**Query**. Provides query interfaces to UI.
1.**Receiver** and **Fetcher**. Expose the service to the agents and probes, or read telemetry data from a channel.
**Cluster** and **Storage** have provided multiple implementors (providers). See **Cluster management**
See [Receiver](backend-receivers.md) and [Fetcher](backend-fetcher.md) documents for more details.
and **Choose storage** documents in the [link list](#advanced-feature-document-link-list).
Several **receiver** modules are also provided.
Receiver is the module in charge of accepting incoming data requests to the backend. They usually provide
services by some network (RPC) protocols, such as gRPC and HTTPRestful.
The receivers have many different module names. You could
read the **set receivers** document in the [link list](#advanced-feature-document-link-list).
## Configuration Vocabulary
All available configurations in `application.yml` could be found in [Configuration Vocabulary](configuration-vocabulary.md).
## Advanced feature document link list
After understanding the setting file structure, you may learn more about the advanced features.
You may read the advanced feature documents in the following order.
1.[Overriding settings](backend-setting-override.md) in application.yml are supported.
1.[IP and port setting](backend-ip-port.md). Introduces how IP and port are set and used.
1.[Backend init mode startup](backend-init-mode.md). How to initialize the environment and exit graciously.
Read this before you try to initialize a new cluster.
1.[Cluster management](backend-cluster.md). Guides you on how to set the backend server in cluster mode.
1.[Deploy in kubernetes](backend-k8s.md). Guides you on how to build and use the SkyWalking image, and deploy in k8s.
1.[Choose storage](backend-storage.md). As we know, in default quick start, the backend is running with H2
DB. But clearly, it doesn't fit the product env. Here you may find out about the other options available to you.
We also welcome anyone to contribute a new storage implementor.
1.[Set receivers](backend-receivers.md). You may choose receivers according to your requirements. Most receivers
are harmless, including our default receivers. You may set and activate all receivers provided.
1.[Open fetchers](backend-fetcher.md). You may open different fetchers to read metrics from target applications.
These ones work like receivers, except that they are in pull mode. A typical example is Prometheus.
1.[Token authentication](backend-token-auth.md). You may add token authentication mechanisms to prevent `OAP` from receiving untrusted data.
1. Run [trace sampling](trace-sampling.md) at the backend. This sample keeps the metrics accurate, although some of the traces
in storage are not saved based on rate.
1. Follow [slow DB statement threshold](slow-db-statement.md) config document to learn about
how to detect the Slow database statements (including SQL statements) in your system.
1. Official [OAL scripts](../../guides/backend-oal-scripts.md). As you have seen from our [OAL introduction](../../concepts-and-designs/oal.md),
most backend analysis capabilities are based on scripts. Here is a detailed description of the official scripts,
which helps you understand which metrics data are in process, and which could be used in alarm.
1.[Alarm](backend-alarm.md). Alarm provides a time-series based check mechanism. You may set alarm
rules targeting the analysis oal metrics objects.
1.[Advanced deployment options](advanced-deployment.md). If you want to deploy backend in very large
scale and support high payload, you may need this.
1.[Metrics exporter](metrics-exporter.md). Use metrics data exporter to forward metrics data to 3rd party
systems.
1.[Time To Live (TTL)](ttl.md). Since metrics and trace are time series data, TTL settings affect their expiration time.
1.[Dynamic Configuration](dynamic-config.md). Configure the OAP to dynamic from remote service
or 3rd party configuration management systems.
1.[Uninstrumented Gateways](uninstrumented-gateways.md). Configure gateways/proxies that are not supported by SkyWalking agent plugins to reflect the delegation in topology graph.
1.[Apdex threshold](apdex-threshold.md). Configure the thresholds for different services if Apdex calculation is activated in the OAL.
1.[Service Grouping](service-auto-grouping.md). An automatic grouping mechanism for all services based on name.
1.[Group Parameterized Endpoints](endpoint-grouping-rules.md). Configure the grouping rules for parameterized endpoints to improve the meaning of the metrics.
1.[OpenTelemetry Metrics Analysis](backend-receivers.md#opentelemetry-receiver). Activate built-in configurations to convert the metrics forwarded from OpenTelemetry collector, and learn how to write your own conversion rules.
1.[Meter Analysis](backend-meter.md). Set up the backend analysis rules when using [SkyWalking Meter System Toolkit](../service-agent/java-agent/README.md#advanced-features)
or meter plugins.
1.[Spring Sleuth Metrics Analysis](spring-sleuth-setup.md). Configure the agent and backend to receiver metrics from micrometer.
1.[Log Analyzer](log-analyzer.md)
## 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. Follow the [document](backend-telemetry.md) to use it.
At the same time, we provide [Health Check](backend-health-check.md) to get a score for the health status.
> 0 means healthy, and more than 0 means unhealthy.
> less than 0 means that the OAP doesn't start up.
## FAQs
## FAQs
#### Why do we need to set the timezone? And when do we do it?
#### Why do we need to set the timezone? And when do we do it?