search

MicrosoftDocs / azure-docs

Open source documentation of Microsoft Azure
https://docs.microsoft.com/azure
Creative Commons Attribution 4.0 International
10.23k stars 21.41k forks source link

Azure teams are over-referencing this page in response to numerous deprecations #58112

Closed atrauzzi closed 3 years ago

atrauzzi commented 4 years ago

Can we please see other versions of this page outside of the Python ecosystem? It really is turning out to be unhelpful when people are asking about alternatives and they get sent over to this very terse example in a single language.

For myself, I'd prefer to see something about how I can get traces out of PHP and into Azure monitor. Particularly using open and standard formats and not by having to install any Azure-specific SDKs to my projects or making Azure-specific calls to instrument my code.

Is there no Metrics/Insights forwarder that I can send OpenCensus/OpenTelemetry data to?

This really feels half-baked.

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

BhargaviAnnadevara commented 4 years ago

@atrauzzi Thanks for the feedback. I have assigned the issue to the content author to evaluate and update as appropriate.

assign:reyang

PRMerger10 commented 4 years ago

reyang is not a valid GitHub ID, or is not a collaborator on this repo.

BhargaviAnnadevara commented 4 years ago

@reyang Unable to assign the issue to you. Could you please take a look?

reyang commented 4 years ago

@lzchen @ramthi need to replace my alias with yours for https://github.com/MicrosoftDocs/azure-docs/blob/master/articles/azure-monitor/app/opencensus-python.md.

atrauzzi commented 4 years ago

I think you guys are going to have to take a more holistic look at this. This isn't about a single document. But the availability of this document has resulted in other parts of the Azure ecosystem treating it as the canonical reference to answer just about any question about adding instrumentation and targeting Monitor. When really it's not very helpful for a number of reasons.

BhargaviAnnadevara commented 4 years ago

@atrauzzi Thank you for the insights. We understand the confusion this is causing and will do our best to make the content clearer. Looping in @mrbullwinkle to provide any inputs and evaluating overall content enhancements.

atrauzzi commented 4 years ago

I think it's particularly important to address the lack of some kind of agent/forwarder option for portable formats.

The concern right now is that Azure is attempting to provoke a lock-in scenario by forcing people to install haphazardly maintained SDKs.

mrbullwinkle commented 4 years ago

adding @DawgFan

mrbullwinkle commented 4 years ago

RE: comment from @reyang: > @lzchen @ramthi need to replace my alias with yours for https://github.com/MicrosoftDocs/azure-docs/blob/master/articles/azure-monitor/app/opencensus-python.md.

the metadata has now been updated to point to lzchen the change is merged internally and will go-live between 10-11 AM UTC-7.

mattmccleary commented 4 years ago

@atrauzzi I wasn't aware this had become a canonical reference for Open Source instrumentation. Who is directing you to this document -- we can align internally.

This is only meant to cover our Python-OC scenario, which is our first SDK that uses a widely adopted open source standard. We are in the process of re-basing our SDKs in Open Telemetry (the next incarnation of OC), but as you note, it's half-baked (meaning work in progress).

I believe your specific ask is to provide Azure Monitor support for the https://github.com/open-telemetry/opentelemetry-collector. This would enable the scenario you reference (PHP + Agent/Forwarder).

We plan to invest in this scenario over the next six months (though not using the OT Collector but a similar concept). In the meantime, your option is the unsupported AI PHP SDK (which yes does create vender lock, which is not ideal or what we hope to provide in the near future).

I'm working on creating an Azure OT blog post and OT early adopter community so we can be more proactive about these sorts of communications.

atrauzzi commented 4 years ago

@DawgFan - Hey Matt, thanks for jumping in, nice to meet you as well.

My apologies, I've only just started tracking the incidences this morning (out of frustration as I was looking for options) in a gist as I start gathering more meta-info on this topic.

Just now however during an Azure Monitor AMA, I was directed again to the python specific implementation: https://techcommunity.microsoft.com/t5/azure-monitor-monthly/pure-standards-based-instrumenting/m-p/1499295#M66 -- In this case, I did imply that I didn't want to take any Azure-specific dependencies, that I'd like to build off of the standard wire protocols and I'd like to use the otel collector as a forwarder.

On the following note:

...though not using the OT Collector but a similar concept...

I know by convention, I can't presume it, but there is a (commendably! :tada:) emphasized connection between Microsoft and OpenTelemetry. I feel like not offering forwarding via the community-standard project is a contradictory take on being involved with the community and forcing people to install an Azure-specific-something risks eroding the merit and trustworthiness of Microsoft's participation.

Moreover, it doesn't put Azure on equal footing with potential competitors like Honeycomb, who seem to grasp the architectural potential of a pluggable, community maintained collector by creating their own exporter.

On this, I - and likely many others if you gave this issue detailed and candid visibility (rather than tucked inside of a doc improvement issue like this) - urge you to reconsider any architecture that doesn't put the community standard tools first.

What really is the difference between an Azure-only forwarder, and an Azure-only otel exporter and who does it help to avoid such? In my view, splintering like this undermines the value of OpenTelemetry by forcing people to either accept cruft and run both, or to pick one.

The remainder of your observations are correct. :smile: -- If I do any kind of instrumentation in my PHP app (even using OpenCensus), I want to send it to OpenTelemetry and have it thunk the wire formats for me. Then as per my "ask", have a first-party maintained Azure Metrics exporter that I only need to configure within a container already in my core infra definitions.

Thinking about all the mothballed tracing initiatives I've had to cross just to get to this point, this not only insulates Azure, but also keeps you competitive (see Honeycomb reference, they get it) and increases the appeal of Azure Monitor by making it easy and simpler to adopt.

Open to having a side conversation about this BTW! Obviously getting out of scope of the current ticket.

mattmccleary commented 4 years ago

@atrauzzi We're have a sign-up form for those interested in being early adopters of OT. We hope to turn it into a community, where we discuss new stuff and get feedback.

Would you be interested? https://aka.ms/AzMonOT/

atrauzzi commented 4 years ago

Heck yeah!

mrbullwinkle commented 3 years ago

Closing out this issue.

mrbullwinkle commented 3 years ago

please-close