# APM service map showing less data in more time

**URL:** <https://discuss.elastic.co/t/apm-service-map-showing-less-data-in-more-time/285795>\
**Category:** APM\
**Tags:** ui\
**Created:** [October 4, 2021, 9:03am UTC](https://discuss.elastic.co/t/apm-service-map-showing-less-data-in-more-time/285795 "2021-10-04T09:03:20Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![multimaster](https://avatars.discourse-cdn.com/v4/letter/m/b77776/32.png) [@multimaster](https://discuss.elastic.co/u/multimaster)\
**Post date:** [October 4, 2021, 9:03am UTC](https://discuss.elastic.co/t/apm-service-map-showing-less-data-in-more-time/285795/1 "2021-10-04T09:03:20Z")

</div>

Hi,

We have APM set up for a series of Java services and we have found a rather curious behavior.

For some timespan, the service map of a particular service shows some relations with other monitorized services, this is OK:

 ![Sin título2](https://us1.discourse-cdn.com/elastic/original/3X/e/2/e2377e713a7f97479ec57e49c969dba22f2414e9.png)

If we change the timespan to make it wider, but also containing the previous timespan, the service map show less relations:

 ![Sin título](https://us1.discourse-cdn.com/elastic/original/3X/b/e/be49e7fae8a9252138488010fcb45e586fc092f0.png)

¿Why the original relations are missing? ¿Does the service map have a limit in how many transactions uses to be built? ¿Does it use the most common transactions or the most repeated?

**Kibana version** : 7.14.1

**Elasticsearch version** : 7.14.1

**APM Server version** : 7.14.1

**APM Agent language and version** : Java 1.x

Greetings

---

<div class="post-metadata">

**Author:** ![dgieselaar](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dgieselaar/32/46947_2.png) [@dgieselaar](https://discuss.elastic.co/u/dgieselaar)\
**Post date:** [October 4, 2021, 3:10pm UTC](https://discuss.elastic.co/t/apm-service-map-showing-less-data-in-more-time/285795/2 "2021-10-04T15:10:56Z")

</div>

Hi @multimaster! The service map uses a sampling strategy to detect connections. Selecting a larger time range might lead to some connections being missed due to the fact we cannot inspect all traces one-by-one. However, I'm not sure if that is the case here, to be honest. It might be something else.

In both cases, are you looking at the global service map? And is there anything peculiar about the service that _is_ displayed in both cases?

---

<div class="post-metadata">

**Author:** ![multimaster](https://avatars.discourse-cdn.com/v4/letter/m/b77776/32.png) [@multimaster](https://discuss.elastic.co/u/multimaster)\
**Post date:** [October 4, 2021, 4:27pm UTC](https://discuss.elastic.co/t/apm-service-map-showing-less-data-in-more-time/285795/3 "2021-10-04T16:27:03Z")

</div>

Then it must be the sampling strategy. Because the throughput was much higher in the prior hours (11-13:30) and this throughput was likely coming off someplace else which is not those services. So then, the service map misses the transactions coming from the monitorized services due to low volume compared to all the traffic. Starting 13:30, we can see it as the other traffic fades away.

 ![Sin título3](https://us1.discourse-cdn.com/elastic/original/3X/6/2/627a006abc1d0cfe50052f4f0b19a75327655676.png)

We were seeing this specific service service map. In the others service's service map as well as the global one, we can see all the relations OK.

This sampling strategy, how does it work? Is it completely random? I mean, it might lead to different results if you put another request for the same timespan? What is the chance to miss some transactions?

Thanks for the quick answer

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [October 25, 2021, 12:28pm UTC](https://discuss.elastic.co/t/apm-service-map-showing-less-data-in-more-time/285795/4 "2021-10-25T12:28:03Z")

</div>

This topic was automatically closed 20 days after the last reply. New replies are no longer allowed.
