Alipay Mini Program Monitoring
SkyWalking supports Alipay Mini Program monitoring via the SkyAPM mini-program-monitor SDK — the same SDK used for WeChat. The SDK detects the Alipay runtime and adapts the platform tag accordingly; the OAP-side rules then route traffic to the Alipay layer.
Three data streams are captured:
- OTLP logs — JS errors, promise rejections, and AJAX failures (no
pageNotFound— the Alipay base library does not exposemy.onPageNotFound) - OTLP metrics — app launch and first render durations (lifecycle-based approximations on Alipay, not renderer-authoritative) and a delta histogram of outbound request durations
- SkyWalking native trace segments (opt-in) — one
SegmentObjectper sampled outboundmy.request, with answ8header injected on the wire so downstream backend services join the same trace
No new receiver is required — the SDK speaks OTLP/HTTP and the SkyWalking native v3 protocol.
Prerequisites
- mini-program-monitor ≥ v0.4.0 is the recommended baseline. v0.3.x still works but with
the legacy per-device
serviceInstancebehavior (see Compatibility). - SkyWalking OAP with the changes from SWIP-12 — OTLP HTTP receiver enabled (default on core
REST port 12800), the two new component ids registered in
component-libraries.yml, and the four MAL rules underotel-rules/miniprogram/enabled.
OAP Configuration
Append miniprogram/* to enabledOtelMetricsRules and miniprogram to lalFiles and
malFiles in application.yml (preserve the existing defaults — don’t replace them). These
entries are included in the shipped defaults, so this section is only relevant if you have
overridden the defaults via SW_OTEL_RECEIVER_ENABLED_OTEL_METRICS_RULES, SW_LOG_LAL_FILES,
or SW_LOG_MAL_FILES:
receiver-otel:
selector: ${SW_OTEL_RECEIVER:default}
default:
enabledHandlers: ${SW_OTEL_RECEIVER_ENABLED_HANDLERS:"otlp-traces,otlp-metrics,otlp-logs"}
enabledOtelMetricsRules: ${SW_OTEL_RECEIVER_ENABLED_OTEL_METRICS_RULES:"<existing defaults>,miniprogram/*"}
log-analyzer:
selector: ${SW_LOG_ANALYZER:default}
default:
lalFiles: ${SW_LOG_LAL_FILES:"<existing defaults>,miniprogram"}
malFiles: ${SW_LOG_MAL_FILES:"<existing defaults>,miniprogram"}
Native trace segments (/v3/segments) need no additional config — the existing trace receiver
handles them and assigns the ALIPAY_MINI_PROGRAM layer automatically based on the SDK’s
AliPay-MiniProgram componentId (10003).
Mini Program Setup
// app.js
const { init } = require('mini-program-monitor');
App({
onLaunch() {
init({
service: 'my-mini-program',
serviceVersion: 'v1.2.0',
serviceInstance: 'v1.2.0', // version-scoped, recommended pattern
collector: 'https://<oap-or-collector-host>',
platform: 'alipay', // optional — auto-detected from runtime
enable: { tracing: true }, // opt-in: SkyWalking native segments
});
},
});
Security: mini-program SDKs send telemetry from end-user devices over the public internet. See the Security Notice for deployment guidelines.
Metrics
All MAL metrics are prefixed meter_alipay_mp_* (service-scope) or
meter_alipay_mp_instance_* (instance-scope). Endpoint-scoped variants surface as
meter_alipay_mp_endpoint_*.
| Metric | Scope | Source |
|---|---|---|
app_launch_duration |
service / instance / endpoint | App.onLaunch → App.onShow lifecycle delta (approx) |
first_render_duration |
service / instance / endpoint | Page.onLoad → Page.onReady lifecycle delta (approx) |
request_duration_percentile |
service / instance / endpoint | miniprogram.request.duration histogram (P50–P99) |
error_count |
service | LAL-derived counter — log-MAL rule aggregates per exception type |
Precision caveat: on Alipay the perf values come from lifecycle hooks, not the native PerformanceObserver entries WeChat uses (the Alipay base library doesn’t expose them). These are approximations of time-to-interactive, not authoritative renderer timings. Do not compare WeChat and Alipay perf values directly.
WeChat-only metrics (route_duration, script_duration, package_load_duration,
first_paint.time) are absent from Alipay. The Alipay dashboard omits the Navigation row
entirely.
Mini-program native trace segments are client-side (exit-only) — the same shape as browser
JS-agent traces. They flow through OAP’s standard RPCAnalysisListener pipeline and produce
ServiceRelation / ServiceInstanceRelation edges to the backend services the mini-program
calls (so topology shows the outbound dependency), but do not produce
service_cpm / service_resp_time / service_sla / endpoint_cpm / endpoint_resp_time
under the mini-program layer — those come from inbound (entry-span) analysis, which
mini-programs don’t have. The mini-program service / instance / endpoint entities are
created by MAL (OTLP metrics) and LAL (OTLP logs) instead. All request-load / latency
metrics on the dashboard come from the miniprogram.request.duration histogram’s
_count + bucket families.
Error Logs
The LAL rule lal/miniprogram.yaml uses layer: auto mode and dispatches on the
miniprogram.platform resource attribute — one rule file produces both the
WECHAT_MINI_PROGRAM and ALIPAY_MINI_PROGRAM layers. For each error log, the extractor
emits a miniprogram_error_count counter sample, which the log-MAL rule in
log-mal-rules/miniprogram.yaml aggregates into the per-layer error_count metric.
Error categories (exception.type tag):
| Category | Source |
|---|---|
js |
my.onError — unhandled JS errors |
promise |
my.onUnhandledRejection — unhandled promise rejections |
ajax |
my.request failures (network + non-2xx) |
Entities
| SkyWalking Entity | Source | Cardinality | Rationale |
|---|---|---|---|
| Service | service.name |
1 per app | Fleet-wide app health |
| ServiceInstance | service.instance.id (pattern: set to service.version) |
tens per app | Version regression / rollout monitoring |
| Endpoint | miniprogram.page.path |
dozens per app | Which in-app page is slow / error-prone |
Per-device service.instance.id is intentionally not used as an aggregation dimension —
unbounded cardinality means millions of entities on any real user base. The SDK (≥ v0.4.0)
no longer auto-generates a device id; operators set serviceInstance to a version-scoped
value.
Compatibility
- SDK ≤ v0.2.x emits
componentId = 10001(ajax-inherited). Its segments resolve toLayer.GENERALand do not benefit from this integration’s layer / topology work. - SDK ≤ v0.3.x auto-generates
service.instance.id = mp-{random}per session, creating one OAP instance entity per device — usually undesirable. Operators on v0.3.x can avoid this by passinginit({ serviceInstance: serviceVersion })explicitly. - SDK ≥ v0.4.0 leaves
service.instance.idunset by default. The three signal pipelines then handle absence differently: native segments produce a literal-instance entity; OTLP logs and metrics create no instance entity at all. Per-instance dashboards are meaningful only when the operator setsserviceInstance. - The recommended pattern (SDK docs + e2e CI) is to set
serviceInstanceto a version-scoped value.
Dashboards
- Alipay Mini Program in the Mobile menu group — service list landing page.
- Per-service dashboard — launch / render durations (approx), request latency percentile, outbound traffic (load, avg latency, success rate), error count, plus tabs for Instance, Endpoint, Trace, and Log drill-down.
- Per-instance (version) dashboard — same metric set scoped to a release.
- Per-endpoint (page) dashboard — per-page perf, outbound traffic, request latency percentile.
Limitations
- Alipay perf metrics are lifecycle-based approximations, not renderer-authoritative.
- No
pageNotFounderror category — the Alipay base library does not exposemy.onPageNotFound. - WebSocket, memory-warning, and network-status-change signals are not instrumented by the current SDK.
- Device-level per-user aggregation is not supported by design —
serviceInstanceis intended to be a version-scoped identifier.