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/intakewhich accepts data in thendjsonformat.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
_typethat is one oferror,transaction,span. There's also theheadertype, 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.Configtoconfig.TransformConfig.TransformConfigdepends on the the endpoint, apm-server config etc. In the future we should consider if it makes sense to mergeTransformConfigandTransformContext.map[string]interface{}to a struct (for exampleDecodeProcess)map[string]interface{}(DecodeUserData)I've renamed (ii) to
extractorsand separated the augmentation into a separate thing.Transformfunctions forerrors,transactionsandspansreturn abeat.Eventdirectly now. They used to return just amapStr.processor/error/generated-schemas/error.gofor example). I needed to separate the generated schemas out from the payloads so entities could be validated independently.timestampand 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