Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[work in progress] [apm] Clarify how data is populated in the APM Infrastructure tab #4692

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from
Draft

[work in progress] [apm] Clarify how data is populated in the APM Infrastructure tab #4692

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
35 changes: 34 additions & 1 deletion docs/en/observability/apm/troubleshooting/common-problems.asciidoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -17,6 +17,7 @@ This section describes common problems you might encounter when using APM Server
* <<troubleshooting-unknown-route>>
* <<troubleshooting-fields-unsearchable>>
* <<service-map-rum-connections>>
* <<troubleshooting-apm-infra-data>>

[float]
[[apm-no-data-indexed]]
Expand Down Expand Up @@ -282,10 +283,42 @@ If the service map is not showing an expected connection between the client and
it's likely because you haven't configured
{apm-rum-ref}/distributed-tracing-guide.html[`distributedTracingOrigins`].


This setting is necessary, for example, for cross-origin requests.
If you have a basic web application that provides data via an API on `localhost:4000`,
and serves HTML from `localhost:4001`, you'd need to set `distributedTracingOrigins: ['https://localhost:4000']`
to ensure the origin is monitored as a part of distributed tracing.
In other words, `distributedTracingOrigins` is consulted prior to the APM agent adding the
distributed tracing `traceparent` header to each request.

// This info is not confirmed, but hopefully provides a structure
// for product/dev to react to and follow!
[float]
[[troubleshooting-apm-infra-data]]
== No data shown in the infrastructure tab

If you don't see any data in the *Infrastructure* tab for a selected service in the Applications UI,
there are a few possible causes and solutions.

// Does it make sense to include something like this?
*If you also do _not_ see the data in the* <<view-infrastructure-metrics,*Infrastructure inventory*>>

Refer to the <<troubleshooting-infrastructure-monitoring,Infrastructure troubleshooting docs>>.

*If you _do_ see the data in the* <<view-infrastructure-metrics,*Infrastructure inventory*>>

// Why this happens
It's likely that there is a problem correlating APM and infrastructure data. The `host.hostname`
field value in the APM data and the `host.name` field value in infrastructure data are used to
correlate data, and the queries used to correlate the data are case sensitive.

// Potential fix?
To fix this, make sure these two fields match exactly.

// From https://www.elastic.co/guide/en/observability/current/analyze-hosts.html#analyze-hosts-troubleshooting
For example, if the APM agent is not configured to use the correct host name,
the host name might be set to the container name or the Kubernetes pod name.
To get the correct host name, you need to set some additional configuration options,
specifically `system.kubernetes.node.name` as described in <<apm-api-kubernetes-data>>.

// Are there other reasons why this can happen?
// How can users fix the issue?
21 changes: 19 additions & 2 deletions docs/en/observability/apm/view-and-analyze/drill-down/infrastructure.asciidoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,11 +4,28 @@
beta::[]

The *Infrastructure* tab provides information about the containers, pods, and hosts
that the selected service is linked to.
that the selected service is linked to:

// Does it make sense to add this here?
* *Pods*: Uses the `kubernetes.pod.name` from the <<apm-data-model-metrics,APM metrics data streams>>.
* *Containers*: Uses the `container.id` from the <<apm-data-model-metrics,APM metrics data streams>>.
* *Hosts*: If the application is containerized--if the APM metrics documents include `container.id`--
the `host.name` is used from the infrastructure data streams (filtered by `container.id`).
If not, `host.hostname` is used from the APM metrics data streams.

[role="screenshot"]
image::./images/infra.png[Example view of the Infrastructure tab in Applications UI in Kibana]

IT ops and software reliability engineers (SREs) can use this tab
to quickly find a service's underlying infrastructure resources when debugging a problem.
Knowing what infrastructure is related to a service allows you to remediate issues by restarting, killing hanging instances, changing configuration, rolling back deployments, scaling up, scaling out, and so on.
Knowing what infrastructure is related to a service allows you to remediate issues by restarting, killing hanging instances, changing configuration, rolling back deployments, scaling up, scaling out, and so on.

// Link to troubleshooting so we can keep
// troubleshooting content centralized
[TIP]
.Why is the infrastructure tab empty?
====
If there is no data in the Application UI's infrastructure tab for a selected service,
you can read more about why this happens and how to fix it in the
<<troubleshooting-apm-infra-data,troubleshooting docs>>.
====
Loading