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.
This is a WIP/POC that introduces a new endpoint
/v2/intake
which accepts data in thendjson
format.It shows how we can have both v1 and v2 until we deprecate v1. There is still quite some work to do on this before i would consider it merge ready, but it should allow us to start testing agents against a v2 intake APM Server. Crucially, we need to test that the performance improvements we expected in the agent and server actually exist.
Each entity (error, transaction, span) should be on its own line. They need to have a
_type
that is one oferror
,transaction
,span
. There's also theheader
type, which should be the first object in the stream. See the example payload.You can test it by running:
there a quite a few changes in here. Reading this list should help mentally decode the PR:
TransformContext
. This structure holds things like service, process etc.. Things that are shared between transformations. The implementation is not pretty (caching the transformation result) and needs some love, but i think it's a step in the right direction.config.Config
toconfig.TransformConfig
.TransformConfig
depends on the the endpoint, apm-server config etc. In the future we should consider if it makes sense to mergeTransformConfig
andTransformContext
.map[string]interface{}
to a struct (for exampleDecodeProcess
)map[string]interface{}
(DecodeUserData
)I've renamed (ii) to
extractors
and separated the augmentation into a separate thing.Transform
functions forerrors
,transactions
andspans
return abeat.Event
directly now. They used to return just amapStr
.processor/error/generated-schemas/error.go
for example). I needed to separate the generated schemas out from the payloads so entities could be validated independently.timestamp
and atransaction.id
. This was required when they no longer are nested under transactions in the API. Still missing: validating the presence of these fields when using intake v2