First and most important thing is, SkyWalking backend startup behaviours are driven by config/application.yml. Understood the setting file will help you to read this document.
The default startup scripts are /bin/oapService.sh(.bat). Read start up mode document to know other options of starting backend.
The core concept behind this setting file is, SkyWalking collector is based on pure modularization design. End user can switch or assemble the collector features by their own requirements.
So, in application.yml, there are three levels.
selector is optional and can be omitted.Example:
storage: selector: mysql # the mysql storage will actually be activated, while the h2 storage takes no effect h2: driver: ${SW_STORAGE_H2_DRIVER:org.h2.jdbcx.JdbcDataSource} url: ${SW_STORAGE_H2_URL:jdbc:h2:mem:skywalking-oap-db} user: ${SW_STORAGE_H2_USER:sa} metadataQueryMaxSize: ${SW_STORAGE_H2_QUERY_MAX_SIZE:5000} mysql: properties: jdbcUrl: ${SW_JDBC_URL:"jdbc:mysql://localhost:3306/swtest"} dataSource.user: ${SW_DATA_SOURCE_USER:root} dataSource.password: ${SW_DATA_SOURCE_PASSWORD:root@1234} dataSource.cachePrepStmts: ${SW_DATA_SOURCE_CACHE_PREP_STMTS:true} dataSource.prepStmtCacheSize: ${SW_DATA_SOURCE_PREP_STMT_CACHE_SQL_SIZE:250} dataSource.prepStmtCacheSqlLimit: ${SW_DATA_SOURCE_PREP_STMT_CACHE_SQL_LIMIT:2048} dataSource.useServerPrepStmts: ${SW_DATA_SOURCE_USE_SERVER_PREP_STMTS:true} metadataQueryMaxSize: ${SW_STORAGE_MYSQL_QUERY_MAX_SIZE:5000} # other configurations
storage is the module.selector selects one out of the all providers listed below, the unselected ones take no effect as if they were deleted.default is the default implementor of core module.driver, url, ... metadataQueryMaxSize are all setting items of the implementor.At the same time, modules includes required and optional, the required modules provide the skeleton of backend, even modularization supported pluggable, removing those modules are meaningless, for optional modules, some of them have a provider implementation called none, meaning it only provides a shell with no actual logic, typically such as telemetry. Setting - to the selector means this whole module will be excluded at runtime. We highly recommend you don't try to change APIs of those modules, unless you understand SkyWalking project and its codes very well.
List the required modules here
For Cluster and Storage have provided multiple implementors(providers), see Cluster management and Choose storage documents in the link list.
Also, several receiver modules are provided. Receiver is the module in charge of accepting incoming data requests to backend. Most(all) provide service by some network(RPC) protocol, such as gRPC, HTTPRestful.
The receivers have many different module names, you could read Set receivers document in the link list.
All available configurations in application.yml could be found in Configuration Vocabulary.
After understand the setting file structure, you could choose your interesting feature document. We recommend you to read the feature documents in our following order.
OAP receiving untrusted data.OAP backend cluster itself underlying is a distributed streaming process system. For helping the Ops team, we provide the telemetry for OAP backend itself. Follow document to use it.
At the same time, we provide Health Check to get a score for the health status.
0 means healthy, more than 0 means unhealthy and less than 0 means oap doesn't startup.
SkyWalking provides downsampling time series metrics features. Query and storage at each time dimension(minute, hour, day, month metrics indexes) related to timezone when doing time format.
For example, metrics time will be formatted like YYYYMMDDHHmm in minute dimension metrics, which format process is timezone related.
In default, SkyWalking OAP backend choose the OS default timezone. If you want to override it, please follow Java and OS documents to do so.
SkyWalking provides browser UI, CLI and GraphQL ways to support extensions. But some users may have the idea to query data directly from the storage. Such as in ElasticSearch case, Kibana is a great tool to do this.
In default, due to reduce memory, network and storage space usages, SkyWalking saves based64-encoded id(s) only in the metrics entities. But these tools usually don‘t support nested query, or don’t work conveniently. In this special case, SkyWalking provide 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 open this feature.
This feature wouldn't provide any new feature to the native SkyWalking scenarios, just for the 3rd party integration.