We have Linux monitoring, metrics collected by Prometheus and Zabbix agents. Some people in the community are asking about monitoring Windows OS, which is not very popular in service backend deployment, but still have some.
If someone new to SkyWalking or anything, want to take a reference from existing Linux monitoring and add this feature. We are welcome to accept.

Requirement - what kind of business use case are you trying to solve?

Hello team, in PR jaegertracing/jaeger#2798 the tls connection is enabled in collector, it would be good to support configuring cipher for it.

It would be similar to the fluentd tls settings in https://docs.fluentd.org/configuration/transport-section#tls-setting, you can config the ciphers fi

Hi team
I've tried out SigNoz with Spring boot micro-services which are already integrated with Zipkin. In the dashboard, I can see the /webjars and /swagger endpoints. It would be great to have some 'skip pattern' to avoid un-desired URLs. Thanks!

Over time we have added a lot of endpoints to Tempo's HTTP API, including /metrics /shutdown /config /memberlist etc. While a few of these provide information that is useful in debugging and monitoring, there are others that are used to perform administrative tasks, for instance the shutdown one, and should probably not be defined at root (/). As we start working towards a stable release

After the merge of this PR: open-telemetry/opentelemetry-dotnet#1548

We should create more unit tests just like open-telemetry/opentelemetry-dotnet#1537 to validate the full behavior.

Tracking issue, similar to jaegertracing/jaeger#2645

Done:

• #548
• #549
• #550

Remaining:

• publish crossdock images
• remove .travis.yml
• update build badge in README
• change required checks to new GH jobs

The current getting started guide assumes the user will be starting using the SDK building block packages like tracing, node, and metrics. In the future, it is expected most users will use the SDK package as a starting point and it would be better for the getting started guide to reflect that.

Cannot use same trace ID accross different node of microservices

On the document of https://opentracing.io/docs/overview/tracers/#propagating-a-trace-with-inject-extract, there is a concept of inject and extract. This is working fine with http carrier. Yet, I cannot reproduce this with Text Map carrier.

Please create a doc for u

@thegryfon noticed that in community axios implementations, some leak contexts and you wouldn't necessarily know until a second root trace is attempted.

here's an example scenario I think tests could cover:

there is no parent trace in scope
create a client request
create a second client request
verify that both client requests are root spans

Is your feature request related to a problem? Please describe.

The .. module has a conditional dependency on the parseurl library. This library is not an agent dependency. However, if parseurl is present then the agent will use it instead of it's own home grown URL parsing.

We've had users report that this conditional `re