On Thursday, October 4, 2018 at 12:51:33 AM UTC+10, [email protected] wrote: > > Hello, > > > I have some issues setting up grpc++ and Opencensus. > > Before anything else, I have built grpc_opencensus_plugin(and its > dependencies) with Cmake. Could I have missed something regarding some kind > of static init? Dynamic linking? >
There's no init other than registering exporters, which is sounds like you've done. > > Anyway, the prometheus stats are correctly exported, but I can not get the > traces to work(both stdout and zipkin). > The traces are correctly logged/exported, but they always have the same > “Parent SpanId: 30c6ffffff7f0000”. > > > Based on the stacktrace below, I can confirm one of CensusContext’s > constructors is indeed called for each request, but it calls > StartSpanWithRemoteParent instead of StartSpan. > That part makes sense. The server-side span is a child span of the client-side span. > The result is that in zipkin, I basically have only one “meta span” for > the whole duration of the server. That span is typically 200-300s, > depending on how often I restart the server(local dev server). > > > Example: I start something in the client, a span with 2-3 requests appears > in zipkin. Then 5 minutes later, I do something else client side and the > same span will be modified, and now have a duration of 300s. > > > grpc::CensusContext::CensusContext(grpc::CensusContext * this, >> absl::string_view name, const opencensus::trace::SpanContext & parent_ctxt) >> (....grpc/src/cpp/ext/filters/census/context.h:54) >> >> grpc::GenerateServerContext(absl::string_view tracing, absl::string_view >> stats, absl::string_view primary_role, absl::string_view method, >> grpc::CensusContext * context) >> (....grpc/src/cpp/ext/filters/census/context.cc:34) >> >> grpc::CensusServerCallData::OnDoneRecvInitialMetadataCb(void * user_data, >> grpc_error * error) >> (....grpc/src/cpp/ext/filters/census/server_filter.cc:113) >> >> exec_ctx_run(grpc_closure * closure, grpc_error * error) >> (....grpc/src/core/lib/iomgr/exec_ctx.cc:40) >> >> grpc_closure_run(const char * file, int line, grpc_closure * c, >> grpc_error * error) (....grpc/src/core/lib/iomgr/closure.h:258) >> >> recv_initial_metadata_ready(void * arg, grpc_error * error) >> (....grpc/src/core/ext/filters/deadline/deadline_filter.cc:298) >> >> exec_ctx_run(grpc_closure * closure, grpc_error * error) >> (....grpc/src/core/lib/iomgr/exec_ctx.cc:40) >> >> grpc_closure_run(const char * file, int line, grpc_closure * c, >> grpc_error * error) (....grpc/src/core/lib/iomgr/closure.h:258) >> >> hs_recv_initial_metadata_ready(void * user_data, grpc_error * err) >> (....grpc/src/core/ext/filters/http/server/http_server_filter.cc:289) >> >> exec_ctx_run(grpc_closure * closure, grpc_error * error) >> (....grpc/src/core/lib/iomgr/exec_ctx.cc:40) >> >> grpc_core::ExecCtx::Flush(grpc_core::ExecCtx * this) >> (....grpc/src/core/lib/iomgr/exec_ctx.cc:134) >> >> pollset_work(grpc_pollset * pollset, grpc_pollset_worker ** worker_hdl, >> grpc_millis deadline) (....grpc/src/core/lib/iomgr/ev_epollex_linux.cc:1195) >> >> pollset_work(grpc_pollset * pollset, grpc_pollset_worker ** worker, >> grpc_millis deadline) (....grpc/src/core/lib/iomgr/ev_posix.cc:313) >> >> grpc_pollset_work(grpc_pollset * pollset, grpc_pollset_worker ** worker, >> grpc_millis deadline) (....grpc/src/core/lib/iomgr/pollset.cc:48) >> >> cq_next(grpc_completion_queue * cq, gpr_timespec deadline, void * >> reserved) (....grpc/src/core/lib/surface/completion_queue.cc:1030) >> >> grpc_completion_queue_next(grpc_completion_queue * cq, gpr_timespec >> deadline, void * reserved) >> (....grpc/src/core/lib/surface/completion_queue.cc:1106) >> >> grpc::CompletionQueue::AsyncNextInternal(grpc::CompletionQueue * this, >> void ** tag, bool * ok, gpr_timespec deadline) >> (....grpc/src/cpp/common/completion_queue_cc.cc:56) >> >> grpc::CompletionQueue::Next(grpc::CompletionQueue * this, void ** tag, >> bool * ok) (....grpc/include/grpcpp/impl/codegen/completion_queue.h:171) >> >> ServerImpl::HandleRpcs(ServerImpl * this) >> (.../grpc_servers/api_server_async.cpp:105) >> >> ServerImpl::Run(ServerImpl * this, const std::__cxx11::string & >> server_address) (.../grpc_servers/api_server_async.cpp:69) >> > > > What can I do to have 1 span per request? > > Should I instrument the route manually? But in that case what is the point > of the census plugin? > > Should this come from the client? > > > PS: I don’t know if that is relevant, but I’m using the async > routes(unary, not streaming). > > PS2: the stats(prometheus) works fine > > PS3: client is grpc-java, android > What trace context is the client sending? The behavior you describe is consistent with the client always sending the same span id to the server (which would be a bug) -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/grpc-io. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/8af4ffab-18f3-4b20-9591-cb35640f0dd9%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
