Fix dead link checker (#161)
This commit is contained in:
parent
cc42b50047
commit
72bc256418
|
|
@ -19,6 +19,8 @@
|
|||
"fallbackRetryDelay": "1000s",
|
||||
"aliveStatusCodes": [
|
||||
200,
|
||||
301,
|
||||
302,
|
||||
401
|
||||
]
|
||||
}
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ jobs:
|
|||
timeout-minutes: 30
|
||||
steps:
|
||||
- uses: actions/checkout@v2
|
||||
- run: sudo npm install -g markdown-link-check@3.8.7
|
||||
- run: sudo npm install -g markdown-link-check@3.10.0
|
||||
- run: |
|
||||
for file in $(find . -name "*.md"); do
|
||||
markdown-link-check -c .dlc.json -q "$file"
|
||||
|
|
|
|||
|
|
@ -31,7 +31,7 @@ Find the [demo](https://skywalking.apache.org/#demo) and [screenshots](https://s
|
|||
# Contact Us
|
||||
* Mail list: **dev@skywalking.apache.org**. Mail to `dev-subscribe@skywalking.apache.org`, follow the reply to subscribe the mail list.
|
||||
* Send `Request to join SkyWalking slack` mail to the mail list(`dev@skywalking.apache.org`), we will invite you in.
|
||||
* Twitter, [ASFSkyWalking](https://twitter.com/ASFSkyWalking)
|
||||
* Twitter, [ASFSkyWalking](https://twitter.com/AsfSkyWalking)
|
||||
* QQ Group: 901167865(Recommended), 392443393
|
||||
* [bilibili B站 视频](https://space.bilibili.com/390683219)
|
||||
|
||||
|
|
|
|||
|
|
@ -50,9 +50,9 @@ This step is only for testing purpose. If your env is correctly set, you don't n
|
|||
|
||||
- Set version number as x.y.z, and tag as **v**x.y.z (The version tag must start with **v**. You will find out why this is necessary in the next step.)
|
||||
|
||||
_You could do a GPG signature before preparing for the release. If you need to input the password to sign, and the maven doesn't provide you with the opportunity to do so, this may lead to failure of the release. To resolve this, you may run `gpg --sign xxx` in any file. This will allow it to remember the password for long enough to prepare for the release._
|
||||
_You could do a GPG signature before preparing for the release. If you need to input the password to sign, and the maven doesn't provide you with the opportunity to do so, this may lead to failure of the release. To resolve this, you may run `gpg --sign xxx` in any file. This will allow it to remember the password for long enough to prepare for the release._
|
||||
|
||||
## Stage the release
|
||||
## Stage the release
|
||||
```
|
||||
./mvnw release:perform -DskipTests -Pall
|
||||
```
|
||||
|
|
@ -70,7 +70,7 @@ This script takes care of the following things:
|
|||
1. Use `v` + `RELEASE_VERSION` as tag to clone the codes.
|
||||
2. Complete `git submodule init/update`.
|
||||
3. Exclude all unnecessary files in the target source tar, such as `.git`, `.github`, and `.gitmodules`. See the script for more details.
|
||||
4. Execute `gpg` and `shasum 512` for source code tar.
|
||||
4. Execute `gpg` and `shasum 512` for source code tar.
|
||||
5. Use maven package to build the agent tar.
|
||||
6. Execute `gpg` and `shasum 512` for binary tar.
|
||||
|
||||
|
|
@ -251,7 +251,7 @@ Downloads:
|
|||
http://skywalking.apache.org/downloads/
|
||||
|
||||
Twitter:
|
||||
https://twitter.com/ASFSkyWalking
|
||||
https://twitter.com/AsfSkyWalking
|
||||
|
||||
SkyWalking Resources:
|
||||
- GitHub: https://github.com/apache/skywalking-java
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
# Plugin Development Guide
|
||||
This document describes how to understand, develop and contribute a plugin.
|
||||
This document describes how to understand, develop and contribute a plugin.
|
||||
|
||||
There are 2 kinds of plugin:
|
||||
1. [Tracing plugin](#tracing-plugin). Follow the distributed tracing concept to collect spans with tags and logs.
|
||||
|
|
@ -19,7 +19,7 @@ SkyWalking has supported OpenTracing and OpenTracing-Java API since 2017. Our co
|
|||
There are three types of span:
|
||||
|
||||
1.1 EntrySpan
|
||||
The EntrySpan represents a service provider. It is also an endpoint on the server end. As an APM system, our target is the
|
||||
The EntrySpan represents a service provider. It is also an endpoint on the server end. As an APM system, our target is the
|
||||
application servers. Therefore, almost all the services and MQ-consumers are EntrySpan.
|
||||
|
||||
1.2 LocalSpan
|
||||
|
|
@ -28,10 +28,10 @@ nor a service (e.g. HTTP service) provider/consumer.
|
|||
|
||||
1.3 ExitSpan
|
||||
The ExitSpan represents a client of service or MQ-producer. It is named the `LeafSpan` in the early versions of SkyWalking.
|
||||
For example, accessing DB through JDBC and reading Redis/Memcached are classified as an ExitSpan.
|
||||
For example, accessing DB through JDBC and reading Redis/Memcached are classified as an ExitSpan.
|
||||
|
||||
### ContextCarrier
|
||||
In order to implement distributed tracing, cross-process tracing has to be bound, and the context must propagate
|
||||
In order to implement distributed tracing, cross-process tracing has to be bound, and the context must propagate
|
||||
across the process. This is where the ContextCarrier comes in.
|
||||
|
||||
Here are the steps on how to use the **ContextCarrier** in an `A->B` distributed call.
|
||||
|
|
@ -67,7 +67,7 @@ See the following examples, where we use the Apache HTTPComponent client plugin
|
|||
```
|
||||
|
||||
### ContextSnapshot
|
||||
Besides cross-process tracing, cross-thread tracing has to be supported as well. For instance, both async process (in-memory MQ)
|
||||
Besides cross-process tracing, cross-thread tracing has to be supported as well. For instance, both async process (in-memory MQ)
|
||||
and batch process are common in Java. Cross-process and cross-thread tracing are very similar in that they both require propagating
|
||||
context, except that cross-thread tracing does not require serialization.
|
||||
|
||||
|
|
@ -96,7 +96,7 @@ Create LocalSpan according to the operation name (e.g. full method signature).
|
|||
```java
|
||||
public static AbstractSpan createExitSpan(String endpointName, ContextCarrier carrier, String remotePeer)
|
||||
```
|
||||
Create ExitSpan according to the operation name (e.g. service name, uri) and the new **ContextCarrier** and peer address
|
||||
Create ExitSpan according to the operation name (e.g. service name, uri) and the new **ContextCarrier** and peer address
|
||||
(e.g. ip+port, hostname+port).
|
||||
|
||||
### AbstractSpan
|
||||
|
|
@ -165,7 +165,7 @@ The value should be an integer. The response code of OAL entities corresponds to
|
|||
#### Tag keys `db.statement` and `db.type`.
|
||||
The value of `db.statement` should be a string that represents the database statement, such as SQL, or `[No statement]/`+span#operationName if the value is empty.
|
||||
When the exit span contains this tag, OAP samples the slow statements based on `agent-analyzer/default/maxSlowSQLLength`.
|
||||
The threshold of slow statement is defined in accordance with `agent-analyzer/default/slowDBAccessThreshold`.
|
||||
The threshold of slow statement is defined in accordance with `agent-analyzer/default/slowDBAccessThreshold`.
|
||||
Check **Slow Database Statement** document of OAP server for details.
|
||||
|
||||
#### Extension logic endpoint: Tag key `x-le`
|
||||
|
|
@ -184,7 +184,7 @@ The value of `x-le` should be in JSON format. There are two options:
|
|||
{
|
||||
"logic-span": true
|
||||
}
|
||||
```
|
||||
```
|
||||
|
||||
### Advanced APIs
|
||||
#### Async Span APIs
|
||||
|
|
@ -271,8 +271,8 @@ Example:
|
|||
```java
|
||||
@Override
|
||||
protected ClassMatch enhanceClassName() {
|
||||
return byName("org.apache.catalina.core.StandardEngineValve");
|
||||
}
|
||||
return byName("org.apache.catalina.core.StandardEngineValve");
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
|
|
@ -318,7 +318,7 @@ tomcat-7.x/8.x=TomcatInstrumentation
|
|||
"foo.Bar"
|
||||
};
|
||||
}
|
||||
|
||||
|
||||
// The plugin is activated only when the foo.Bar#hello method exists.
|
||||
@Override
|
||||
protected List<WitnessMethod> witnessMethods() {
|
||||
|
|
@ -330,10 +330,10 @@ tomcat-7.x/8.x=TomcatInstrumentation
|
|||
```
|
||||
For more examples, see [WitnessTest.java](../../../../../apm-sniffer/apm-agent-core/src/test/java/org/apache/skywalking/apm/agent/core/plugin/witness/WitnessTest.java)
|
||||
|
||||
|
||||
|
||||
|
||||
### Implement an interceptor
|
||||
As an interceptor for an instance method, it has to implement
|
||||
As an interceptor for an instance method, it has to implement
|
||||
`org.apache.skywalking.apm.agent.core.plugin.interceptor.enhance.InstanceMethodsAroundInterceptor`
|
||||
```java
|
||||
/**
|
||||
|
|
@ -464,18 +464,18 @@ Every plugin could declare one or more classes to represent the config by using
|
|||
could initialize this class' static field through System environments, System properties, and `agent.config` static file.
|
||||
|
||||
The `#root()` method in the `@PluginConfig` annotation requires declaring the root class for the initialization process.
|
||||
Typically, SkyWalking prefers to use nested inner static classes for the hierarchy of the configuration.
|
||||
Typically, SkyWalking prefers to use nested inner static classes for the hierarchy of the configuration.
|
||||
We recommend using `Plugin`/`plugin-name`/`config-key` as the nested classes structure of the config class.
|
||||
|
||||
**NOTE**: because of the Java ClassLoader mechanism, the `@PluginConfig` annotation should be added on the real class used in the interceptor codes.
|
||||
**NOTE**: because of the Java ClassLoader mechanism, the `@PluginConfig` annotation should be added on the real class used in the interceptor codes.
|
||||
|
||||
In the following example, `@PluginConfig(root = SpringMVCPluginConfig.class)` indicates that initialization should
|
||||
In the following example, `@PluginConfig(root = SpringMVCPluginConfig.class)` indicates that initialization should
|
||||
start with using `SpringMVCPluginConfig` as the root. Then, the config key of the attribute `USE_QUALIFIED_NAME_AS_ENDPOINT_NAME`
|
||||
should be `plugin.springmvc.use_qualified_name_as_endpoint_name`.
|
||||
```java
|
||||
public class SpringMVCPluginConfig {
|
||||
public static class Plugin {
|
||||
// NOTE, if move this annotation on the `Plugin` or `SpringMVCPluginConfig` class, it no longer has any effect.
|
||||
// NOTE, if move this annotation on the `Plugin` or `SpringMVCPluginConfig` class, it no longer has any effect.
|
||||
@PluginConfig(root = SpringMVCPluginConfig.class)
|
||||
public static class SpringMVC {
|
||||
/**
|
||||
|
|
@ -509,12 +509,12 @@ public class SpringMVCPluginConfig {
|
|||
Java agent plugin could use meter APIs to collect metrics for backend analysis.
|
||||
|
||||
* `Counter` API represents a single monotonically increasing counter which automatically collects data and reports to the backend.
|
||||
```java
|
||||
import org.apache.skywalking.apm.agent.core.meter.MeterFactory;
|
||||
```java
|
||||
import org.apache.skywalking.apm.agent.core.meter.MeterFactory;
|
||||
|
||||
Counter counter = MeterFactory.counter(meterName).tag("tagKey", "tagValue").mode(Counter.Mode.INCREMENT).build();
|
||||
counter.increment(1d);
|
||||
```
|
||||
Counter counter = MeterFactory.counter(meterName).tag("tagKey", "tagValue").mode(Counter.Mode.INCREMENT).build();
|
||||
counter.increment(1d);
|
||||
```
|
||||
1. `MeterFactory.counter` creates a new counter builder with the meter name.
|
||||
1. `Counter.Builder.tag(String key, String value)` marks a tag key/value pair.
|
||||
1. `Counter.Builder.mode(Counter.Mode mode)` changes the counter mode. `RATE` mode means the reporting rate to the backend.
|
||||
|
|
@ -547,6 +547,7 @@ histogram.addValue(3);
|
|||
1. `Histogram.addValue(double value)` adds value into the histogram, and automatically analyzes what bucket count needs to be incremented. Rule: count into [step1, step2).
|
||||
|
||||
# Plugin Test Tool
|
||||
|
||||
The [Apache SkyWalking Agent Test Tool Suite](https://github.com/apache/skywalking-agent-test-tool) is an incredibly useful test tool suite that is available in a wide variety of agent languages. It includes the mock collector and validator. The mock collector is a SkyWalking receiver, like the OAP server.
|
||||
|
||||
You could learn how to use this tool to test the plugin in [this doc](Plugin-test.md). This is a must if you want to contribute plugins to the SkyWalking official repo.
|
||||
|
|
@ -560,6 +561,6 @@ Please follow these steps:
|
|||
1. Follow this guide to develop. Make sure comments and test cases are provided.
|
||||
1. Develop and test.
|
||||
1. Provide the automatic test cases. Learn `how to write the plugin test case` from this [doc](Plugin-test.md)
|
||||
1. Send a pull request and ask for review.
|
||||
1. Send a pull request and ask for review.
|
||||
1. The plugin committers will approve your plugins, plugin CI-with-IT, e2e, and the plugin tests will be passed.
|
||||
1. The plugin is accepted by SkyWalking.
|
||||
1. The plugin is accepted by SkyWalking.
|
||||
|
|
|
|||
Loading…
Reference in New Issue