You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At minimum, configuring this processor involves specifying an array of attribute keys to be used to group spans, log records, or metric datapoints together, as in the following example:
456
457
458
+
.Example of the OpenTelemetry Collector custom resource when using the Group-by-Attributes Processor
457
459
[source,yaml]
458
460
----
459
461
# ...
@@ -511,7 +513,7 @@ config:
511
513
<3> See the following table "Values for the `context` field".
512
514
<4> Optional: Conditions for performing a transformation.
513
515
514
-
.Configuration example
516
+
.Example of the OpenTelemetry Collector custom resource when using the Transform Processor
515
517
[source,yaml]
516
518
----
517
519
# ...
@@ -572,6 +574,356 @@ config:
572
574
|Returns errors up the pipeline and drops the payload. Implicit default.
573
575
574
576
|===
577
+
578
+
[id="tail-sampling-processor_{context}"]
579
+
== Tail Sampling Processor
580
+
581
+
The Tail Sampling Processor samples traces according to user-defined policies when all of the spans are completed. Tail-based sampling enables you to filter the traces of interest and reduce your data ingestion and storage costs.
582
+
583
+
:FeatureName: The Tail Sampling Processor
584
+
include::snippets/technology-preview.adoc[]
585
+
586
+
This processor reassembles spans into new batches and strips spans of their original context.
587
+
588
+
[TIP]
589
+
====
590
+
* In pipelines, place this processor downstream of any processors that rely on context: for example, after the Kubernetes Attributes Processor.
591
+
* If scaling the Collector, ensure that one Collector instance receives all spans of the same trace so that this processor makes correct sampling decisions based on the specified sampling policies. You can achieve this by setting up two layers of Collectors: the first layer of Collectors with the Load Balancing Exporter, and the second layer of Collectors with the Tail Sampling Processor.
592
+
====
593
+
594
+
.Example of the OpenTelemetry Collector custom resource when using the Tail Sampling Processor
595
+
[source,yaml]
596
+
----
597
+
# ...
598
+
config:
599
+
processors:
600
+
tail_sampling: # <1>
601
+
decision_wait: 30s # <2>
602
+
num_traces: 50000 # <3>
603
+
expected_new_traces_per_sec: 10 # <4>
604
+
policies: # <5>
605
+
[
606
+
{
607
+
<definition_of_policy_1>
608
+
},
609
+
{
610
+
<definition_of_policy_2>
611
+
},
612
+
{
613
+
<definition_of_policy_3>
614
+
},
615
+
]
616
+
# ...
617
+
----
618
+
<1> Processor name.
619
+
<2> Optional: Decision delay time, counted from the time of the first span, before the processor makes a sampling decision on each trace. Defaults to `30s`.
620
+
<3> Optional: The number of traces kept in memory. Defaults to `50000`.
621
+
<4> Optional: The expected number of new traces per second, which is helpful for allocating data structures. Defaults to `0`.
622
+
<5> Definitions of the policies for trace evaluation. The processor evaluates each trace against all of the specified policies and then either samples or drops the trace.
623
+
624
+
You can choose and combine policies from the following list:
625
+
626
+
* The following policy samples all traces:
627
+
+
628
+
[source,yaml]
629
+
----
630
+
# ...
631
+
policies:
632
+
[
633
+
{
634
+
name: <always_sample_policy>,
635
+
type: always_sample,
636
+
},
637
+
]
638
+
# ...
639
+
----
640
+
641
+
* The following policy samples only traces of a duration that is within a specified range:
<1> The provided `5000` and `10000` values are examples. You can estimate the desired latency values by looking at the earliest start time value and latest end time value. If you omit the `upper_threshold_ms` field, this policy samples all latencies greater than the specified `threshold_ms` value.
657
+
658
+
* The following policy samples traces by numeric value matches for resource and record attributes:
<1> This policy definition supports both exact and regular-expression value matches. The provided `10` value in the `cache_max_size` field is an example.
724
+
725
+
* The following policy samples traces by the rate of spans per second:
726
+
+
727
+
[source,yaml]
728
+
----
729
+
# ...
730
+
policies:
731
+
[
732
+
{
733
+
name: <rate_limiting_policy>,
734
+
type: rate_limiting,
735
+
rate_limiting: {spans_per_second: 35} # <1>
736
+
},
737
+
]
738
+
# ...
739
+
----
740
+
<1> The provided `35` value is an example.
741
+
742
+
* The following policy samples traces by the minimum and maximum number of spans inclusively:
743
+
+
744
+
[source,yaml]
745
+
----
746
+
# ...
747
+
policies:
748
+
[
749
+
{
750
+
name: <span_count_policy>,
751
+
type: span_count,
752
+
span_count: {min_spans: 2, max_spans: 20} # <1>
753
+
},
754
+
]
755
+
# ...
756
+
----
757
+
<1> If the sum of all spans in the trace is outside the range threshold, the trace is not sampled. The provided `2` and `20` values are examples.
758
+
759
+
* The following policy samples traces by `TraceState` value matches:
<1> Allocates percentages of spans according to the order of applied policies. For example, if you set the `100` value in the `max_total_spans_per_second` field, you can set the following values in the `rate_allocation` section: the `50` percent value in the `policy: <composite_policy_1>` section to allocate 50 spans per second, and the `25` percent value in the `policy: <composite_policy_2>` section to allocate 25 spans per second. To fill the remaining capacity, you can set the `always_sample` value in the `type` field of the `name: <composite_policy_3>` section.
921
+
922
+
[role="_additional-resources"]
923
+
.Additional resources
924
+
* link:https://opentelemetry.io/blog/2022/tail-sampling/[Tail Sampling with OpenTelemetry: Why it’s useful, how to do it, and what to consider] (OpenTelemetry Blog)
0 commit comments