FAQ: Hide calls to 10.0.0.1 in Application Map

[robinmanuelthiel]

Shall we hide the calls to the Kubernetes API Server (10.0.0.1) from the Application Map? It makes it very confusing if every service calls this endpoint. Of course, technically they do, but I don't need that information on the Application Map and it's overloaded then. What do you think?

[xiaomi7732]

Hi @robinmanuelthiel thanks for the suggestion.

I agree with you that it doesn't always make sense to show it on the app map. However, I also don't think we are in a position to make the call.

If the user want, they could be easily reach it by creating a telemetry processor.

Since it is not strictly K8s related, I am afraid I don't think it fits into scope of this repo.

What do you think?

[robinmanuelthiel]

In which scenarios do you think it makes sense to show these calls? As it's not my application, that is calling the Kubernetes API but just the Application Insights package which is gathering additional information from the API to function properly, I can't think of many use-cases where there is a benefit for a developer who is looking at the Application Map.

[xiaomi7732]

Hi @robinmanuelthiel, for discussion, I wasn't arguing with you about the scenario. I actually agree with you it doesn't make sense.

But, I do want to argue:

1. That the focus for this library is to get the info from K8s, put it on to the telemetry. It is not to cover the trace on the way.
2. You have admitted too, the query to the main node actually happened.
3. It is the user's call to hide it or not, at the end of the day. And if they do agree with us, there is a simple code, that applies to all application insights telemetries, they could write to hide the node - they don't need this library to do it for them.

[robinmanuelthiel]

Good points, I agree, that the library shouldn't hide a call that is actually happening. What's your opinion on documenting somewhere prominently here in this repo (maybe in an FAQ section) how to filter this traffic out using a telemetry processor?

[xiaomi7732]

@robinmanuelthiel I like the idea of documenting. So far, we have been making use of issues exactly like this one, fully context with discussions, plus tags, plus pins for FAQ. For example:

I could quickly do it for this issue too. Suggestion?

Thanks again for the discussion!

[robinmanuelthiel]

Personally, I like the idea of using and pinning issues for that, as they are very searchable but AFAIK one can only pin a limited amount of issues in GitHub. As a user, I would be surprised to find documentation in form of issues and rather search for it in a Wiki or Markdown doc.

Also, if this project ever gets documented in the official Microsoft docs, issues won't work anymore.

So I am unsure if issues for FAQ is a good thing or not in general, but if that is how you deal with that kind of stuff in this project, it's a good place for this.

I would also like a hint or mention in the main Readme, that FAQs can be found here in the issues, so people know, where to search for quick answers.

[xiaomi7732]

I hear you about the documentation. Let me try wiki. And we can always reshape when needed.

[xiaomi7732]

Put up a simple page:
https://github.com/microsoft/ApplicationInsights-Kubernetes/wiki/FAQ

Link added from WikiHome and Readme.md.