Mx51 feature/uds support #167
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is the codepath used by Report() / ReportAt(), which is the fast path for
reporting stats in v4. Skipping the sort saves us some work:
benchmark old ns/op new ns/op delta
BenchmarkTagsBufferSortSorted-12 107 49.3 -53.93%
BenchmarkTagsBufferSortUnsorted-12 270 271 +0.37%
While users are less likely to have already-sorted stat tags in this case
(because the tagsBuffer tag slice is built on every call and doesn't retain its
sort between calls the way that you would retain sorted engine tags if you were
calling stats.Incr() without tags often), it can show up in benchmarks and guide
users toward this little cheat by passing in their tags in sorted order.
The `go vet` command in Go 1.16 reports a warning for inappropriate use of reflect.StringHeader. golang/go#40701 Its use in prometheus/metric.go to convert a byte array to a string in place began to trigger the warning. That code has been replaced with a safer variant that avoids the `vet` warning and still converts the array without allocating new memory. https://stackoverflow.com/a/66865482 Additionally, the CircleCI test now uses a pinned influxdb image of 1.8.9. The 2.x influxdb Docker images require authentication to use. Co-authored-by: Collin Van Dyck <collin@segment.com>
The Datadog client now has the ability to send histogram metrics as the
Datadog-specific distribution metric type. The Datadog client
configuration has a new `DistributionPrefixes` item which specifies the
prefixes of metric names that, when reported as histograms to the stats
library, are to be sent as distributions instead. For example, when the
prefix list is set to `{ "dist_" }`, then any histogram metric whose
name begins with "dist_" is sent as a distribution; all other histograms
are sent as ordinary histograms, as before.
The default configuration sends no histograms as distributions.
This PR adds a first version of an OpenTelemetry handler. This handler implement the otlp protocol with an HTTP Client. There are few caveats with the current implementation: - It only supports HTTP but GRPC should be easy enough to add later if needed. - The client is written in a fire-and-forget fashion, meaning that metrics will be sent once even if there is a failure when sending the request. - The handler only support backends which expect cumulative values such as Prometheus.
… no semantic code changes
Co-authored-by: Kevin Burke <kevin.burke@segment.com>
It looks like functions had been renamed in some files but not others, breaking tests for darwin (though it's unclear why darwin tests are valuable for this package).
Add golang.org/x/exp/slices dependency. This is allocation-free and has comparable speed to prior approach. stdlib and slices package Sort functions also use insertion sort for small inputs, and as such a local insertion sort optimization has not been needed since at least 1.18.
golang.org/x/exp/slices has comparable allocation-free sorting, which we can use while reducing our code. Neither Datadog nor Prometheus appear to retain or handle multiple tags with the same name on the same metric, so this package deduplicates at time of sort (latest tag wins). If any metric systems we use do tolerate and provide useful behavior when provided duplicate tag/label names, and the practice is justified, that would be a reason to revert or adjust this deduplication behavior.
autofixed changes. no other updates
Co-authored-by: Kevin Burke <kevin.burke@segment.com>
* fix: upgrade the x/exp package, and updated tagIsLess function * fix the test * tagIsLess -> tagCompare * revert dependency versions: attempt to fix subpackage failure
https://app.snyk.io/org/segment-pro/project/c9a18e75-de8c-4229-ad8d-2ca5c8f8cfbb/pr-check/15c5a32a-73c7-4cff-930d-39be988384cf Vulnerable version of gopkg.in/yaml.v3 introduced through: Introduced through: github.com/segmentio/archive-transformer-service@0.0.0 › github.com/segmentio/stats@v4.6.5 › github.com/stretchr/testify@v1.8.0 › github.com/stretchr/objx@v0.4.0 › github.com/stretchr/testify@v1.7.1 › gopkg.in/yaml.v3@v3.0.0-20200313102051-9f266ea9e77c
v1.0.3 of fasthash corrected a potential segfault issue. segmentio/fasthash@9dc1b83 This is detectable using -race or -gcflags=all=-d=checkptr when running code that imports this lib. Co-authored-by: Dean Karn <dean@clearbit.co>
On tip (the Go 1.22 code freeze), Go reports that `compareTag` has the wrong method signature: ``` type func(a Tag, b Tag) int of tagCompare does not match inferred type func(a Tag, b Tag) bool for func(a E, b E) bool ``` Fix this by using the correct method signature.
Builds are currently failing because something is running Node 16 which is no longer supported.
Previously they would fail with an anticipated error; instead, skip the failing test on Darwin.
While the metrics are set in the correct order, the use of a HTTP server to receive them means that the metrics can be received on the server side in any order, which fails the tests 1 time out of 200, potentially higher. This means we can't rely on any ordering on the server side in the test, and need to manually sort events.
Currently it just fails the main branch because it's not a requirement of a passing build.
We turned on the linter to lint the "main" branch and any release branches, but we never actually fixed any of the issues reported by the linter. This is an attempt to do so. A lot of red herrings but some legitimate errors. Not strictly reported by the linter, but replace "syscall" uses with "x/sys/unix", as is recommended.
Mostly it's complaining about x/net but take the opportunity to update all dependencies.
Several Docker images used by Segment do not work reliably on Mac M1 laptops, which use the ARM chipset. Commonly, these are images that were built several years ago, before M1 laptops were in widespread use, and behave unpredictably when run on an ARM chipset. The simplest workaround is to ensure that the Docker environment is always running on x86. This change should ensure that employees with M1 laptops will be able to reliably start and run Docker containers on this repository.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.