Add support for viewing raw body requests
It would be great to see raw body request on analytics. Good for monitoring restful api calls (for example json payloads)
We are exploring how to implement this feature without compromising privacy. Thank you for all the feedback!
- Matt, Product Manager
Motti Mezei commented
Or some way to turn on network traces on an app service web app.
We want to see this in the sub-calls as part of the end to end transaction details. We have API calls that are received on the server and then in turn make sub- API calls to other APIs like MS Graph API and others. We can see the URL request that is made as the sub-call but not the body of the sub-call which would be really helpful.
Adding my vote to this. If my API generates a 400, I'd like to see what's been sent to it.
How can we troubleshoot failed requests from API Management if we have no ability to see the payload of the failed request?
At the moment I can see the request url but can't see the request body
Alex Martinez Mañé commented
Totally needed. View the json raw payload on azure portal insights monitoring
Please add the ability to query the JSON payload of a PUT/GET request.
raygun.io does this very nicely. should be supported out of the box. I shouldn't have to introduce telemetry initializer to implement something like this. need to view the full header too. also should redact passwords (regex password=)
Please add the ability to query the JSON payload of a PUT request. It would be incredibly helpful.
At the very least, include a few http related properties in a request....like referer and so on
This will greatly helping in debugging many applications. Why is this nor provided by default in App Inisghts?
M Soni commented
Why is this still in "NEED FEEDBACK" while tons of users have provided comments below needing this feature ?
Pankaj Rawat commented
To debug failed request we need JSON payload.
Jon Hudson commented
Has anyone implemented a TelemetryInitializer class for Asp.Net Core 2.0 that can capture the JSON request/response body? I have APIs that work in every environment known to man, until i put them in Azure App Service and every response is 400 Bad Request with no way to diagnose anything. I need help!!!
Karthik Jambulingam commented
Very much needed feature for effective use of App Insights but understand the cost you pay for additional overhead of capturing and storing lot of data so should provide the ability to turn it on/off or do it for failure requests.
Matt F commented
This is badly needed. At the moment I can see the request url but can't see the request body, so I can't figure out what is wrong with the request which is causing my application to blow up.
Alexander Batishchev commented
For requests (to my ASP.NET Web API) I'd like to be able to inspect HTTP request verb, body, headers. Currently I have too write my own initializer.
Martin Altenstedt commented
One scenario that I have seen with customers is request input validation. It would be very useful to see the payload that caused the input validation to return an error response code.
Today, you can easily see all the failed requests in the Azure Portal, but you need to resort to custom event tracing to see the payload that caused the validation error, which seems like a duplicated effort.
I agree that there need to be a way to filter out sensitive input user data from the payload. Also, I would expect to pay some small computational price for the SDK parsing the payload. Sounds like this should be an opt-in function.
I'll also add, that I have created a custom ITelemetryInitializer class that adds request form parameter key/value pairs to request telemetry. I have a dictionary of keys that are considered sensitive and get masked so they don't get written in plain text to AI. It would be nice to get something like this out of the box.
The kinds of scenarios this helps with is that if you get recurring errors, but not all the time, so can't easy determine what the root cause is. If you can see the request body, you can find commonality for the failed/successful requests and see if perhaps all the failures occur with a particular request argument. This helped us a couple of times.
I like Eduard Los' idea about opting-in to specific requests that get the request body logged. Logging the whole body as 1 single property may not be as queryable as splitting out request parameters, but is certainly more applicable across different request types. Maybe multiple options? (LogBodyForPath, LogBodyForRoute, LogFormParametersForPath, LogFormParametersForRoute)
This would be great! However, it would need to be tunable to, for example, mask sensitive data being sent in.