# Intrument some classes or methods instead of profiling sampling

**URL:** <https://discuss.elastic.co/t/intrument-some-classes-or-methods-instead-of-profiling-sampling/227735>\
**Category:** APM\
**Tags:** java\
**Created:** [April 13, 2020, 6:28am UTC](https://discuss.elastic.co/t/intrument-some-classes-or-methods-instead-of-profiling-sampling/227735 "2020-04-13T06:28:03Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![CoderLan](https://avatars.discourse-cdn.com/v4/letter/c/b487fb/32.png) [@CoderLan](https://discuss.elastic.co/u/CoderLan)\
**Post date:** [April 13, 2020, 6:28am UTC](https://discuss.elastic.co/t/intrument-some-classes-or-methods-instead-of-profiling-sampling/227735/1 "2020-04-13T06:28:03Z")

</div>

Java agent supports many technologies instrumentations , but not all.

In the latest release version 1.15.0, creating spans for any method executions can be enabled, but the sampling is inaccurate because the interval of sampling can not be setting too low.

In addition, the profiling only supports the configuration by class level, and the method level will be better.

so how about intrument the methods which are configured, and creating spans for their executions, instead of profiling sampling ?

---

<div class="post-metadata">

**Author:** ![felixbarny](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/felixbarny/32/27341_2.png) [@felixbarny](https://discuss.elastic.co/u/felixbarny)\
**Post date:** [April 14, 2020, 6:50am UTC](https://discuss.elastic.co/t/intrument-some-classes-or-methods-instead-of-profiling-sampling/227735/2 "2020-04-14T06:50:30Z")

</div>

You can certainly do that via the [`trace_methods`](https://www.elastic.co/guide/en/apm/agent/java/current/config-core.html#config-trace-methods) configuration option. But be sure to read the caveats as this options is generally not recommended to use for a large number of methods or for fast executing ones.

Out of curiosity, why is the accuracy of the sampling profiler not enough for you? Sure, it's only accurate up to [`profiling_inferred_spans_sampling_interval`](https://www.elastic.co/guide/en/apm/agent/java/current/config-profiling.html#config-profiling-inferred-spans-sampling-interval) but shouldn't that be enough to identify slow methods?

---

<div class="post-metadata">

**Author:** ![CoderLan](https://avatars.discourse-cdn.com/v4/letter/c/b487fb/32.png) [@CoderLan](https://discuss.elastic.co/u/CoderLan)\
**Post date:** [April 14, 2020, 8:37am UTC](https://discuss.elastic.co/t/intrument-some-classes-or-methods-instead-of-profiling-sampling/227735/3 "2020-04-14T08:37:45Z")

</div>

Sampling profiler can identify slow methods, but it can not show how slow it is. If intrumenting methods is supported, it would be the better choise.

the [`trace_methods`](https://www.elastic.co/guide/en/apm/agent/java/current/config-core.html#config-trace-methods) configuration option is ok, thank you!

---

<div class="post-metadata">

**Author:** ![felixbarny](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/felixbarny/32/27341_2.png) [@felixbarny](https://discuss.elastic.co/u/felixbarny)\
**Post date:** [April 14, 2020, 8:57am UTC](https://discuss.elastic.co/t/intrument-some-classes-or-methods-instead-of-profiling-sampling/227735/4 "2020-04-14T08:57:58Z")

</div>

Both have their tradeoffs but for production usage I'd strongly recommend the sampling profiler over trace\_methods.

---

<div class="post-metadata">

**Author:** ![CoderLan](https://avatars.discourse-cdn.com/v4/letter/c/b487fb/32.png) [@CoderLan](https://discuss.elastic.co/u/CoderLan)\
**Post date:** [April 15, 2020, 1:44am UTC](https://discuss.elastic.co/t/intrument-some-classes-or-methods-instead-of-profiling-sampling/227735/5 "2020-04-15T01:44:06Z")

</div>

Why? The trace\_methods is archieved through the instrumentation of some methods while application startup? it might be cheaper , i think.

---

<div class="post-metadata">

**Author:** ![felixbarny](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/felixbarny/32/27341_2.png) [@felixbarny](https://discuss.elastic.co/u/felixbarny)\
**Post date:** [April 15, 2020, 5:41am UTC](https://discuss.elastic.co/t/intrument-some-classes-or-methods-instead-of-profiling-sampling/227735/6 "2020-04-15T05:41:44Z")

</div>

For trace\_methods, there is an overhead that is associated with each instrumented method. Let's assume the overhead is 1µs. If you instrument methods that are executed millions of times within a single request and normally just take 1ns, you'll see massive overhead.  
While this may sound like an extreme example, it's not uncommon that methods are executed in a tight loop. We've got several reports from users that their performance degraded as a result of overusing trace\_methods. While it's a great tool it's also easy to shoot yourself in the foot with it.

See also this blog post: [https://www.elastic.co/blog/from-distributed-tracing-to-distributed-profiling-with-elastic-apm](https://www.elastic.co/blog/from-distributed-tracing-to-distributed-profiling-with-elastic-apm)

---

<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:** [May 6, 2020, 1:41am UTC](https://discuss.elastic.co/t/intrument-some-classes-or-methods-instead-of-profiling-sampling/227735/7 "2020-05-06T01:41:48Z")

</div>

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