Incorrect order for application insights #64
Comments
|
Hey @Viper61x23, thanks for your feedback. There was a fix related to a large app insights log that is truncated (into two logs). In the fix I have merged the two logs together. This is way probably you experience this behavior. In the new version, could you check if you see this message (The report shows a combination of two Application Insight entities) next to the App insights Id? If you see it indicates that the VS code combined to reports into one. There can be an issue with the merging process. But, let's start by checking if some of the logs are combined. Yoel |
|
Hi @yoelhor yes it does indeed show that there are combined entries. So based on my picture in the original post all the entries with step numbers indicate it is a combined entry. Also the ones with the mixed up steps, i.e. the last two lines in the bottom picture has the JSON parse error. Nigel. Nigel. |
Observations from testing: - The application insights does not return the results in the same order as viewing in Azure Portal application insights when the times are identical - A single application insights entity can span more than 2 write entries, sometime we need to combine 3 or 4 together - Sometimes application insights entities can have the extact same time (and therefore shoud NOT be combined) Fixes applied: - Add the id to the sort of the api call, that way all entries that are to be combined will be next to each other in the array - The logic for combining the step labels to be display did not take into account the order of the two entries to be combined - Moved the text "The report shows......" to only be added after the last entry is combined (in cases where 3 or 4 application insights entries) - To handle where there are 3 or 4 entries to combine, after we combine the first 2 we move back up the loop (i--) again and check if there are more entries that need to be combined for this entry e.g. When 4 entries to combine, [A, B, C, D] [A + B, delete B, i-- [AB + C, delete C, i-- [ABC + D, delete D, i-- [ABCD] no action
I have noticed that the later versions > 1.2.106 do not put the logs in the correct order.
I have a custom policy with a SubJourney. With v1.2.106 it looks like this:
The SubJourney covers covers the steps 2,3,4 (9:22:08) and 9,10,11 (9:22:48) - As you can see step 9 is not in the right order but it is on it own entry so that is generally fine.
When I update to anything > 1.2.106 the order is a mess, here is the order for the same transaction on 1.3.
When the order is messed up it is impossible to trace though as the logs do not seem to contain all the data for each step.
Is this caused by having SubJourneys?
The text was updated successfully, but these errors were encountered: