repository·main·Indexed 21 days ago
https://github.com/apache/skywalking-javaA specialized agent providing native tracing, metrics, and logging for Java applications to enable observability in microservices and cloud-native environments. It integrates with the Apache SkyWalking APM system and supports features such as async-profiler task triggering, custom trace ignoring, and OAL (Observability Analysis Language). The agent supports JDK 8+ and provides mechanisms for TLS, namespace, and token-based authentication.
The Spring Gateway Plugin supports Spring Gateway versions 2.x, 3.x, and 4.x. It provides tracing capabilities by:
It automatically supports GlobalFilter and GatewayFilter implementations. However, it cannot transparently trace logic executed within a .then(...) closure in a WebFlux chain.
SkyWalking supports two primary plugin types for data collection:
Counter, Gauge, and Histogram formats.If you are contributing to the main repository, your plugin's data will be verified using the SkyWalking plugin test tool.
In SkyWalking, while RPC server-side names (like RESTful API paths or gRPC service names) are typically treated as entry spans with metrics, a Logic Endpoint is a specialized concept that allows plugins or users to define new endpoints without creating entirely new spans. This allows for more granular analysis of specific logical operations within an existing trace.
Several plugins automatically register logic endpoints using specific naming conventions:
SpringScheduled/${className}/${methodName}.ElasticJob/${jobName}.xxl-job/MethodJob/${className}.${methodName}, xxl-job/ScriptJob/${GlueType}/id/${jobId}, or xxl-job/SimpleJob/${className}.quartz-scheduler/${className}.The Configuration Discovery Service (CDS) provides dynamic configuration for the SkyWalking Java Agent via gRPC. Instead of static files, the agent can receive real-time configuration updates for specific services.
Configurations are structured by service name, where each service can have its own set of key-value pairs. This allows for granular control over agent behavior on a per-service basis.
configurations:
serviceA:
key1: value1
key2: value2
serviceB:
key3: value3The Application Toolkit provides libraries that act as a bridge between your application code and the SkyWalking agent. Use the SkyWalking manual APIs if you need to perform the following tasks directly in your code:
trace id.qps (queries per second) parameter has been removed and replaced with rpm (requests per minute).The repository contains CLAUDE.md files that provide specialized context to Claude Code. These are automatically loaded to assist with specific development areas:
| File | Purpose |
|---|---|
CLAUDE.md (root) | Project overview, build system, architecture, and conventions |
apm-sniffer/apm-sdk-plugin/CLAUDE.md | SDK plugin development guide (V2 API, class matching, testing) |
apm-sniffer/bootstrap-plugins/CLAUDE.md | Bootstrap plugin specifics (JDK class instrumentation) |
The plugin automates context propagation for Kotlin coroutines using the following lifecycle:
Starting from version 9.0.0, Apache SkyWalking uses a predictable naming convention for auxiliary types, fields, and methods to support class re-transformation and hot-swapping alongside other Java agents. All generated names follow the sw$ name trait. This ensures that names remain unchanged even after re-transformation.
Key naming strategies include:
SWAuxiliaryTypeNamingStrategy): <origin_class_name>$<name_trait>$auxiliary$<auxiliary_type_instance_hash>DelegateNamingResolver): <name_trait>$delegate$<class_name_hash>$<plugin_define_hash>$<intercept_point_hash>SWMethodNameTransformer): <name_trait>$original$<method_name>$<method_description_hash>SWImplementationContextFactory): cachedValue$<name_trait>$<origin_class_name_hash>$<field_value_hash>SWImplementationContextFactory): <renamed_origin_method>$accessor$<name_trait>$<origin_class_name_hash>