Support propagating ID in header for tracing between microservices about swagger-stats HOT 6 OPEN

is it possible to let app to pick additional data from both request and response and add it to reports.
for ex, we have req.rid object in each request which holds our correlation ids.
so it may not be required to create and maintain a new id but just let app put one if it needs.
This can be done quite easily if you choose to add lodash in dependency stack, app may just provide key path(s) as string like 'userinfo.userid' or 'body.userinfo.userid'

app.use(swStats.getMiddleware({
  pickFromReq: ['userinfo.userid', 'dummy.id'],
  pickFromRes: ['body.userinfo.userid'],
}));

Additionally,
it would also be greate if it lets app to add any data, may be with a simple callback to extend rrr.
A callback/hook might even be better as app can even pick its data from req or res or somewhere else and put in rrr directly.

if i can find some time, i will try to create pull request so you can check if it is ok or not.

from swagger-stats.

This sounds good, thank you ! couple of thoughts:

• we can use onResponseFinish callback to do exactly that - app can extend rrr before it gets stored in Elasticsearch
• Need to think about schema how additional attributes will be stored in Elasticsearch

from swagger-stats.

onResponseFinish works perfectly !

i don't have much knowledge about how template works but even if the template is not updated, it should work but new custom fields won't be indexed right?

it tried overriding default schema and it seems working but i am not sure if i miss smt or not.
i will be creating a pull request just for your inspection.

btw, i am definetly lost in test folder :) need guidance so that i won't be ruining your coverage

from swagger-stats.

Also added more comments to #27 ...

even if the template is not updated, it should work but new custom fields won't be indexed right?

Not exactly. Elasticsearch will assign type and index custom field first time it appears. But then if next time custom field with the same name would have different type, it would cause indexing error. This is why it's best to define this in schema upfront - to avoid indexing errors.

btw, i am definetly lost in test folder :) need guidance so that i won't be ruining your coverage

Sure :) I'll try to add more detailed readme to /tests ... As a short description - there are several groups of tests focusing each on specific area:

• 000_baseline.js - test for basic functionality
• 010_swsapistats.js - test for swagger spec initialization
• 100_method.js - test for method-based statistics
• 200_apicore.js - test for api operation - based statistics
• 300_timeline.js - test for timeline - based statistics
• 400_auth.js - authentication tests
• 500_elastic.js - Elasticsearch-specific tests
• /ui - Tests for UI , using karma

Each of tests instantiates one of sample application (from /examples ) and then sends API requests to app and checks that swagger-stats returns correct stats. So these are more integration tests, as they validate everything end-to-end, rather then testing specific modules

from swagger-stats.

Any progress here?

from swagger-stats.

See V1 discussion: #135

from swagger-stats.