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.

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

Update opentelemetry base #2

Closed
wants to merge 1 commit into from
Closed

Update opentelemetry base #2

wants to merge 1 commit into from

Conversation

tuturiffic
Copy link

@tuturiffic tuturiffic commented Apr 18, 2024

Description: Minor updates to allow the receiver to build with newer (v0.97.0+) versions of opentelemetry-collector

Link to tracking Issue: Related to:

Testing: Most of the testing has been focused on being able to produce a build. Prior to these changes, the ocb was failing with, cannot use metadata.Type (untyped string constant "githubactions") as component.Type value in argument to receiver.NewFactory. After the changes, the ocb is successfully completing a build.

I also ran the standard set of Go tests. They are failing with the same error after these changes.

Documentation: The documentation changes are automatically generated via make generate. No manual documentation changes were made.

A simplified ocb configuration that can be used to test:

dist:
  name: otelcol-tuturiffic
  otelcol_version: "0.98.0"
  version: "gha"
  output_path: /tmp/otelcol

exporters:
  - gomod: go.opentelemetry.io/collector/exporter/otlpexporter v0.98.0

receivers:
  - gomod: go.opentelemetry.io/collector/receiver/otlpreceiver v0.98.0
  - gomod: github.com/open-telemetry/opentelemetry-collector-contrib/receiver/githubactionsreceiver v0.0.0

replaces:
  - github.com/open-telemetry/opentelemetry-collector-contrib/receiver/githubactionsreceiver => github.com/tuturiffic/opentelemetry-collector-contrib/receiver/githubactionsreceiver update-opentelemetry-base

@tuturiffic tuturiffic marked this pull request as ready for review April 18, 2024 16:34
Newer releases of the collector require that components specify their
scope.
@@ -1,4 +1,5 @@
type: githubactions
scope_name: otelcol/githubactionsreceiver
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This one line is effectively the only changed I've made at this point, everything else is auto-generated.

@tuturiffic
Copy link
Author

Recent changes appear to have made this unnecessary: I've been able to built a 0.98.0 distribution using the feat-add-githubactionseventreceiver branch directly.

@tuturiffic tuturiffic closed this Apr 26, 2024
@tuturiffic tuturiffic deleted the update-opentelemetry-base branch April 26, 2024 18:33
tuturiffic pushed a commit to tuturiffic/opentelemetry-collector-contrib that referenced this pull request Dec 16, 2024
… Histo --> Histogram (open-telemetry#33824)

## Description

This PR adds a custom metric function to the transformprocessor to
convert exponential histograms to explicit histograms.

Link to tracking issue: Resolves open-telemetry#33827

**Function Name**
```
convert_exponential_histogram_to_explicit_histogram
```

**Arguments:**

- `distribution` (_upper, midpoint, uniform, random_)
- `ExplicitBoundaries: []float64`

**Usage example:**

```yaml
processors:
  transform:
    error_mode: propagate
    metric_statements:
    - context: metric
      statements:
        - convert_exponential_histogram_to_explicit_histogram("random", [10.0, 20.0, 30.0, 40.0, 50.0, 60.0, 70.0, 80.0, 90.0, 100.0]) 
```

**Converts:**

```
Resource SchemaURL: 
ScopeMetrics #0
ScopeMetrics SchemaURL: 
InstrumentationScope  
Metric #0
Descriptor:
     -> Name: response_time
     -> Description: 
     -> Unit: 
     -> DataType: ExponentialHistogram
     -> AggregationTemporality: Delta
ExponentialHistogramDataPoints #0
Data point attributes:
     -> metric_type: Str(timing)
StartTimestamp: 1970-01-01 00:00:00 +0000 UTC
Timestamp: 2024-07-31 09:35:25.212037 +0000 UTC
Count: 44
Sum: 999.000000
Min: 40.000000
Max: 245.000000
Bucket (32.000000, 64.000000], Count: 10
Bucket (64.000000, 128.000000], Count: 22
Bucket (128.000000, 256.000000], Count: 12
        {"kind": "exporter", "data_type": "metrics", "name": "debug"}
```

**To:**

```
Resource SchemaURL: 
ScopeMetrics #0
ScopeMetrics SchemaURL: 
InstrumentationScope  
Metric #0
Descriptor:
     -> Name: response_time
     -> Description: 
     -> Unit: 
     -> DataType: Histogram
     -> AggregationTemporality: Delta
HistogramDataPoints #0
Data point attributes:
     -> metric_type: Str(timing)
StartTimestamp: 1970-01-01 00:00:00 +0000 UTC
Timestamp: 2024-07-30 21:37:07.830902 +0000 UTC
Count: 44
Sum: 999.000000
Min: 40.000000
Max: 245.000000
ExplicitBounds #0: 10.000000
ExplicitBounds krzko#1: 20.000000
ExplicitBounds krzko#2: 30.000000
ExplicitBounds krzko#3: 40.000000
ExplicitBounds krzko#4: 50.000000
ExplicitBounds krzko#5: 60.000000
ExplicitBounds open-telemetry#6: 70.000000
ExplicitBounds open-telemetry#7: 80.000000
ExplicitBounds open-telemetry#8: 90.000000
ExplicitBounds open-telemetry#9: 100.000000
Buckets #0, Count: 0
Buckets krzko#1, Count: 0
Buckets krzko#2, Count: 0
Buckets krzko#3, Count: 2
Buckets krzko#4, Count: 5
Buckets krzko#5, Count: 0
Buckets open-telemetry#6, Count: 3
Buckets open-telemetry#7, Count: 7
Buckets open-telemetry#8, Count: 2
Buckets open-telemetry#9, Count: 4
Buckets open-telemetry#10, Count: 21
        {"kind": "exporter", "data_type": "metrics", "name": "debug"}
```

### Testing

- Several unit tests have been created. We have also tested by ingesting
and converting exponential histograms from the `statsdreceiver` as well
as directly via the `otlpreceiver` over grpc over several hours with a
large amount of data.

- We have clients that have been running this solution in production for
a number of weeks.

### Readme description:

### convert_exponential_hist_to_explicit_hist

`convert_exponential_hist_to_explicit_hist([ExplicitBounds])`

the `convert_exponential_hist_to_explicit_hist` function converts an
ExponentialHistogram to an Explicit (_normal_) Histogram.

`ExplicitBounds` is represents the list of bucket boundaries for the new
histogram. This argument is __required__ and __cannot be empty__.

__WARNING:__

The process of converting an ExponentialHistogram to an Explicit
Histogram is not perfect and may result in a loss of precision. It is
important to define an appropriate set of bucket boundaries to minimize
this loss. For example, selecting Boundaries that are too high or too
low may result histogram buckets that are too wide or too narrow,
respectively.

---------

Co-authored-by: Kent Quirk <kentquirk@gmail.com>
Co-authored-by: Tyler Helmuth <12352919+TylerHelmuth@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant