coralogix/opentelemetry-skills
OpenTelemetry Collector deployment, instrumentation (Java/Python/Node.js/.NET/Go), and OTTL pipeline transforms for Coralogix — coralogix exporter config, Helm chart selection, Kubernetes topology, ECS/EKS/GKE deployments, SDK setup, APM transactions, and OTTL cardinality/PII/routing.
92
96%
Does it follow best practices?
Impact
92%
1.10xAverage score across 127 eval scenarios
Advisory
Suggest reviewing before use
associated-boundaries.mdskills/opentelemetry/opentelemetry-semantic-conventions/references/
Associated Information and Ownership Boundaries
Semantic-convention diagnosis is often incomplete if it stops at the attribute name. Coralogix products also depend on collection topology, generated metrics, product-specific routing, or signal maturity. This page keeps those boundaries explicit without making this skill own every implementation detail.
Rule of thumb
This skill should answer:
- Which Coralogix surface is affected.
- Which signal shape the surface consumes.
- Which attributes, labels, proto fields, or scopes are relevant.
- Where a compatibility bridge must happen conceptually.
- Which adjacent skill owns the exact implementation.
It should not write full collector pipelines, SDK setup, OTTL transforms, Coralogix routing configuration, or profiling setup unless the answer needs a tiny illustrative snippet to explain the scope.
Common boundary cases
| Case | Semconv diagnosis | Owner for implementation |
|---|---|---|
| Continuous Profiling proto changes | OTel profiles proto versions and resource enrichment can affect product identity, including ProfilesDictionary and profile attribute indices, but profiles are still a separate signal with unstable proto details. | Profiling workflow / opentelemetry-collector. |
| Profiles app/subsystem identity | The same resource-scope principles apply, but profile attributes may be dictionary/indexed through ProfilesDictionary rather than normal resource attributes. | Profiling workflow / core routing owner. |
| Javaagent HTTP metrics vs Tomcat/JMX metrics | Javaagent HTTP server metrics use HTTP semconv attributes; Tomcat runtime metrics require JMX scraping. | opentelemetry-instrumentation or opentelemetry-collector. |
| TraceID load balancing | Tail sampling and often spanmetrics need consistent traceID routing in multi-gateway topologies; spans from one trace must reach the same gateway before stateful trace-aware processing. | opentelemetry-collector. |
| APM overview empty despite traces | APM overview may require spanmetrics, transaction enrichment, and server/consumer span kinds. | Semconv for span kind/labels; collector/instrumentation for processors and sampler wiring. |
cx.application.name / cx.subsystem.name | These are Coralogix routing attributes, not upstream OTel semconv. Final answers should say core owns routing configuration, while semconv only diagnoses resource-scope visibility. | core, with semconv only noting resource-scope visibility. |
| OTTL bridge syntax | This skill picks bridge location and source/target scope. If the user asks for exact set(...), context, or where-clause syntax, name source and destination scopes and hand off instead of inventing full OTTL. | opentelemetry-ottl. |
Handoff wording
Use direct handoff language:
- "Semconv diagnosis: the value is at log-record scope, but the exporter
reads resource scope. Use
opentelemetry-ottlto write the copy-up statement." - "Semconv diagnosis: the generated RED metric label changed after
spanmetrics. Use
opentelemetry-collectorfor the metrics-pipeline processor placement." - "Semconv diagnosis: AI Center needs GenAI span attributes and trace
archive path. Use
opentelemetry-instrumentationfor library setup and collector/ingestion owners for archive routing." - "Semconv diagnosis: multiple gateways are splitting one trace before
tail sampling and
spanmetrics; use traceID routing / load-balancing exporter configuration fromopentelemetry-collector."
What not to do
- Do not classify every collector wiring issue as semantic conventions.
- Do not tell customers to downgrade instrumentation when a compatibility bridge or product support for both names is the right path.
- Do not hide product-specific constraints behind generic upstream OTel language. If Coralogix currently reads a mirror name or generated label, say so and name the boundary.
.claude-plugin
.codex-plugin
.cursor-plugin
evals
scenario-1
scenario-2
scenario-3
scenario-4
scenario-5
scenario-6
scenario-7
scenario-8
scenario-9
scenario-10
scenario-11
scenario-12
scenario-13
scenario-14
scenario-15
scenario-16
scenario-17
scenario-18
scenario-19
scenario-20
scenario-21
scenario-22
scenario-23
scenario-24
scenario-25
scenario-26
scenario-27
scenario-28
scenario-29
scenario-30
scenario-31
scenario-32
scenario-33
scenario-34
scenario-35
scenario-36
scenario-37
scenario-38
scenario-39
scenario-40
scenario-41
scenario-42
scenario-43
scenario-44
scenario-45
scenario-46
scenario-47
scenario-48
scenario-49
scenario-50
scenario-51
scenario-52
scenario-53
scenario-54
scenario-55
scenario-56
scenario-57
scenario-58
scenario-59
scenario-60
scenario-61
scenario-62
scenario-63
scenario-64
scenario-65
scenario-66
scenario-67
scenario-68
scenario-69
scenario-70
scenario-71
scenario-72
scenario-73
scenario-74
scenario-75
scenario-76
scenario-77
scenario-78
scenario-79
scenario-80
scenario-81
scenario-82
scenario-83
scenario-84
scenario-85
scenario-86
scenario-87
scenario-88
scenario-89
scenario-90
scenario-91
scenario-92
scenario-93
scenario-94
scenario-95
scenario-96
scenario-97
scenario-98
scenario-99
scenario-100
scenario-101
scenario-102
scenario-103
scenario-104
scenario-105
scenario-106
scenario-107
scenario-108
scenario-109
scenario-110
scenario-111
scenario-112
scenario-113
scenario-114
scenario-115
scenario-116
scenario-117
scenario-118
scenario-119
scenario-120
scenario-121
scenario-122
scenario-123
scenario-124
scenario-125
scenario-126
scenario-127
skills
opentelemetry
opentelemetry-collector
references
opentelemetry-instrumentation
opentelemetry-ottl