Why Build Probe Capabilities Based on OpenTelemetry for Cloud‑Native Observability

Cloud‑native environments bring new challenges to traditional monitoring because large‑scale container deployments cause nodes to grow exponentially, making faults hard to detect and predict. The industry splits observability into five layers; alerting and overview belong to classic monitoring, while proactive discovery is essential for full observability.

Monitoring vs. Observability

Monitoring is an operations‑centric system that defines overall health through metrics and alerts. Observability, built on top of monitoring, adds proactive discovery (debugging, profiling, dependency analysis) to provide deeper insight for developers.

Key differences include:

Core users: monitoring serves ops, observability serves developers.

Dimensions: monitoring looks at external metrics (CPU, load, network), observability also examines internal application dimensions.

Information displayed: monitoring reports that a problem occurred; observability visualizes the root cause and uncertain data.

Core Observability Concepts

The three pillars are:

Traces – distributed request‑level tracing.

Metrics – counters, gauges, histograms (CPU, latency, request count, etc.).

Logs – precise system records.

These pillars were once independent but are now tightly integrated.

Why Choose OpenTelemetry for Probe Development

OpenTelemetry, a CNCF project, provides a vendor‑neutral, standardized framework for collecting, processing, and exporting telemetry (metrics, logs, traces). Its architecture consists of API, SDK, and Collector, supporting multiple languages and plugins.

Probe Development Goals

Support large‑customer custom probe requirements.

Lower integration and deployment costs.

Enrich language ecosystems (e.g., Java bytecode instrumentation, Node.js auto‑instrumentation).

Standardize component protocols to reduce custom integration effort.

Java and Node Open‑Source Framework Comparison

Java probes rely on bytecode enhancement to inject instrumentation at method entry/exit. Node probes use automatic instrumentation plugins based on AOP (e.g., wrapping functions with apply ).

Node.js SDK Probe Practice

1. Initialize the OpenTelemetry Trace SDK with a lightweight provider:

import { BasicTracerProvider } from '@opentelemetry/sdk-trace-base';

// Create tracer provider

const tracerProvider = new BasicTracerProvider(/* options */);

// Add a span processor (exporter)

tracerProvider.addSpanProcessor(/* processor */);

// Register globally

tracerProvider.register(/* options */);

2. Define resource attributes required by Tencent APM:

import { Resource } from '@opentelemetry/resources';

import { SemanticResourceAttributes } from '@opentelemetry/semantic-conventions';

import { ApmResourceAttributes } from './ApmResourceAttributes';

/**

* Get service resource tags for reporting

*/

export const getResource = async (): Promise
=> {

return new Resource({

[SemanticResourceAttributes.SERVICE_NAME]: 'node_simple_server',

[ApmResourceAttributes.APM_TOKEN]: 'oSmwaUrjLIbBiTZiNtSv',

[ApmResourceAttributes.APP_ID]: 'node_simple_server',

[ApmResourceAttributes.SERVER_ID]: 'node_simple_server',

[ApmResourceAttributes.SERVER_OWNER]: 'foo;bar',

});

};

3. Define APM‑specific resource constants:

export const ApmResourceAttributes = {

/** (required) APM token */

APM_TOKEN: 'token',

/** (optional) Module ID */

APP_ID: 'app.id',

/** (optional) Module name */

APP_NAME: 'app.name',

/** (optional) Server ID */

SERVER_ID: 'server.id',

/** (optional) Server name */

SERVER_NAME: 'server.name',

/** (optional) Server owner (semicolon‑separated) */

SERVER_OWNER: 'server.owner',

};

4. Add a span processor that exports traces to the APM collector via gRPC OTLP:

import { OTLPTraceExporter } from '@opentelemetry/exporter-trace-otlp-grpc';

import { SimpleSpanProcessor } from '@opentelemetry/sdk-trace-base';

// Export traces to APM

tracerProvider.addSpanProcessor(

new SimpleSpanProcessor(

new OTLPTraceExporter({

url: 'grpc://ap-guangzhou.apm.tencentcs.com:4317',

concurrencyLimit: 200,

}),

),

);

Supported OpenTelemetry Instrumentation Plugins for Node.js

The following plugins enable automatic instrumentation for popular Node.js libraries and frameworks (each requires version compatibility checks):

@opentelemetry/instrumentation-aws-lambda – AWS Lambda functions.

@opentelemetry/instrumentation-aws-sdk – AWS SDK v2/v3.

@opentelemetry/instrumentation-bunyan – Bunyan logging.

@opentelemetry/instrumentation-pino – Pino logging.

@opentelemetry/instrumentation-winston – Winston logging.

@opentelemetry/instrumentation-http – HTTP/HTTPS.

@opentelemetry/instrumentation-grpc – gRPC.

@opentelemetry/instrumentation-express – Express framework.

@opentelemetry/instrumentation-koa – Koa framework.

@opentelemetry/instrumentation-redis / -ioredis – Redis clients.

@opentelemetry/instrumentation-mongodb – MongoDB driver.

@opentelemetry/instrumentation-pg – PostgreSQL client.

…and many others covering AWS, DNS, Cassandra, Fastify, etc.

APM Architecture and Advantages

The APM system combines a cloud‑native observability backend (metrics storage, alerting, dashboards) with OpenTelemetry‑based probes. Advantages include:

Zero‑configuration, “plug‑and‑play” probes for developers.

Full‑stack monitoring, alerting, and high‑performance visualizations.

AI‑assisted operations (AIOps) that elevate observability through six maturity levels, from manual analysis (Level 0) to fault prediction and change‑impact forecasting (Levels 4‑5).

Overall, the article demonstrates how OpenTelemetry serves as a neutral foundation for building standardized, extensible probe capabilities that empower both developers and operators in cloud‑native environments.