@@ -86,33 +86,33 @@ At a minimum, every instrumentation metadata file should include a `description`
8686
8787Some example descriptions:
8888
89- * This instrumentation enables SERVER spans and metrics for the ActiveJ HTTP server.
89+ * This instrumentation enables HTTP server spans and HTTP server metrics for the ActiveJ HTTP server.
9090* This instrumentation provides context propagation for Akka actors, it does not emit any telemetry
9191 on its own.
9292* The Alibaba Druid instrumentation generates database connection pool metrics for druid data sources.
93- * The Apache Dubbo instrumentation provides CLIENT and SERVER spans
94- for Apache Dubbo RPC calls. Each call produces a span named after the Dubbo
95- method, enriched with standard RPC attributes (system, service, method), network
96- attributes, and error details if an exception occurs.
93+ * The Apache Dubbo instrumentation provides RPC client spans and RPC server spans for Apache Dubbo
94+ RPC calls. Each call produces a span named after the Dubbo method, enriched with standard RPC
95+ attributes (system, service, method), network attributes, and error details if an exception
96+ occurs.
9797
9898Some notes when writing descriptions:
9999
100100* You don't always need to explicitly name the instrumentation, and you can start with "This
101101 instrumentation..."
102102* Prefer the convention of using the word "enables" when describing what the instrumentation does,
103- "This instrumentation enables SERVER spans and metrics for the ActiveJ" instead of something like
104- "This instrumentation provides SERVER spans and metrics for the ActiveJ".
103+ "This instrumentation ** enables** HTTP server spans and HTTP server metrics for the ActiveJ" instead
104+ of something like "This instrumentation ** provides** HTTP server spans and HTTP server metrics for the ActiveJ".
105105* Explicitly state whether the instrumentation generates new telemetry (spans, metrics, logs).
106106 * If it doesn't generate new telemetry, clearly explain what it's purpose is, for example whether it
107107 augments or enriches existing telemetry produced by other instrumentations (e.g., by adding
108108 attributes or ensuring context propagation).
109+ * When describing the functionality of the instrumentation and the telemetry, specify using
110+ [ semantic convention categories] ( https://opentelemetry.io/docs/specs/semconv/ ) when possible
111+ (e.g., "database client spans", "RPC server metrics", "consumer messaging spans").
109112* Do not include specific method names, class names, or other low-level implementation details in
110113 the description unless they are essential to understanding the purpose of the instrumentation.
111114* It is not usually necessary to include specific library or framework version numbers in the
112115 description, unless that context is significant in some way.
113- * When an instrumentation generates spans, be specific about the SpanKind (e.g., SERVER, CLIENT,
114- PRODUCER, CONSUMER, INTERNAL).
115- * Capitalize SpanKind values (e.g., SERVER, CLIENT) when used in descriptions.
116116
117117
118118### Configurations
0 commit comments