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.

The PR #2913 opened by dependabot brought a new version of github.com/go-openapi/strfmt, which seems to have a few API incompatibilities with the previous version. This ticket is about making the necessary changes so that we can upgrade to a newer version.

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

Providing a single click Heroku deploy option may be a good idea to make it easy to test SigNoz for developers.

Tasks

• Check if current SigNoz docker can run in Heroku free tier and the compute requirements are served in the free tier of Heroku. Goal is not to test with high load but to get the application up and running with sample Hot ROD application

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.

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

Our traces contain data that is covered by GDPR (european user privacy regulations) and, thus developers do not have direct access to all traces. If an error occurs, relevant traces has to be filtered out and the relevant ones are forwarded to the developer.

Another use case:
It would be nice to just attach files with

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