Comments (8)
ok I have figured that myself
the correct attributes should look like
{
key: 'myParam',
value: 'stringValue',
stringValue: 'foo'
}
so the value needs to point to what has been chosen
from opentelemetry-proto.
ok here are my findings:
- For json over http this is fine
{
key: 'myParam',
value: 'stringValue',
stringValue: 'foo'
}
- For grpc or proto over http I cannot force it to work, however I debugged things with serializing proto and such structure is serialising correctly
{
key: 'myParam',
value: {
stringValue: 'foo'
}
}
Here are my collector files
version: "3"
services:
# Collector
collector:
image: otel/opentelemetry-collector-dev:latest
command: ["--config=/conf/collector-config.yaml", "--log-level=DEBUG"]
networks:
- otelcol
volumes:
- ./collector-config.yaml:/conf/collector-config.yaml
ports:
- "55680:55680"
depends_on:
- zipkin-all-in-one
# Zipkin
zipkin-all-in-one:
image: openzipkin/zipkin:latest
networks:
- otelcol
ports:
- "9411:9411"
networks:
otelcol:
receivers:
otlp:
protocols:
grpc:
http:
exporters:
zipkin:
url: "http://zipkin-all-in-one:9411/api/v2/spans"
processors:
batch:
queued_retry:
service:
pipelines:
traces:
receivers: [otlp]
exporters: [zipkin]
processors: [batch, queued_retry]
From grpc I'm getting error
{
"code": 13,
"metadata": {
"_internal_repr": {},
"flags": 0
},
"details": "grpc: error unmarshalling request: proto: wrong wireType = 2 for field Type"
}
Any suggestions thoughts ?
from opentelemetry-proto.
This should do it:
"attributes":
[
{
"key": "host.hostname",
"value": { "stringValue": "testHost" }
}
]
We have an automated test that verifies it in the Collector: https://github.com/open-telemetry/opentelemetry-collector/blob/2ba9cdcc2b3c7f45288c1152b97e9ec64b9d6706/receiver/otlpreceiver/otlp_test.go#L80
from opentelemetry-proto.
grpc: error unmarshalling request: proto: wrong wireType = 2 for field Type
This may be an indication that you are using incompatible proto versions. There is no "Type" field in the latest proto version anymore.
from opentelemetry-proto.
@tigrannajaryan have the endpoints url changed maybe then ?
from opentelemetry-proto.
This should do it:
"attributes": [ { "key": "host.hostname", "value": { "stringValue": "testHost" } } ]We have an automated test that verifies it in the Collector: https://github.com/open-telemetry/opentelemetry-collector/blob/2ba9cdcc2b3c7f45288c1152b97e9ec64b9d6706/receiver/otlpreceiver/otlp_test.go#L80
The collector indeed accepts this (only json over http) but there aren't values near tags in zipkin, however this:
{
key: 'telemetry.sdk.version',
value: 'stringValue',
stringValue: '0.9.0'
}
works fine and tags in zipkins are shown
from opentelemetry-proto.
it seems like this might be an issue with collector itself I have tested several different version of latest collector docker and none of them works fine - they all have different problems. I have created a new issue, describing errors for only latest
open-telemetry/opentelemetry-collector#1363
from opentelemetry-proto.
Closing this since the issue in the collector is fized
from opentelemetry-proto.
Related Issues (20)
- The comment of schema_url doesn't describe it's purpose.
- Clarify whether OTLP/gRPC codes should cover both client and server HOT 1
- Unclear whether Span.flags represents span's parent or own flags HOT 10
- Fix releasing notes HOT 3
- Allow consumers to use map<string, AnyValue> instead of repeated KeyValue HOT 3
- Generated OpenAPI files wrongly encode enums
- Improve metrics.proto by mentioning Resource Attributes and Scope HOT 1
- How to use Java service to receive data in the OpenTelemetry (Otel) protocol? HOT 4
- Supporting JSON as-is encoding in OTLP HOT 2
- SPAN_FLAGS_TRACE_FLAGS_MASK is not defined HOT 3
- Fail to push limit HOT 5
- Retryable HTTP Statuses should be configurable HOT 3
- Specify version of the proto that introduced a field in the comments
- File Makefile with executable permissions HOT 2
- Fix outdated attribute examples in comments
- Example not available for Exponential Histogram & Summary metric types
- Define relationship between profile messages and pprof HOT 1
- Consider generalizing profile attributes optimization to other signals
- Why is AggregationTemporality redefined pprofextended.proto HOT 2
- profiling spec - definition of common string values HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
š Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. ššš
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ā¤ļø Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from opentelemetry-proto.