Conversation
63670f2 to
7799dda
Compare
|
Hey @azplanlos, thanks for proposing this feature. It looks like you started your work from an outdated branch and pulled already merged commits. Could you please start from a freshly updated one to avoid noise of older commits and conflicts resolution? Also, could you please:
Than you! |
|
Sure, I'll take care of that. This is still a draft and I'll rebase my work on the 1.10.x branch. To give some more context about this feature: @lbroudoux please let me know if this is an interesting feature and I would add some more unit tests and documentation for this. |
Signed-off-by: Andreas Zöllner <[email protected]>
29f50ec to
c98b8ce
Compare
|
This looks like an interesting feature! Have you think of integration with existing trace systems like the one provided by OpenTelemetry/OpenTracing? |
|
You are totally right, including some more information in tracing totally makes sense too. I'll add the information needed to identify the requests to open telemetry's span information. But in order to conduct automatic testing we will need both ways. |
|
Hey @azplanlos, |
|
This pull request has been automatically marked as stale because it has not had recent activity 😴 It will be closed in 30 days if no further activity occurs. To unstale this pull request, add a comment with detailed explanation. There can be many reasons why some specific pull request has no activity. The most probable cause is lack of time, not lack of interest. Microcks is a Cloud Native Computing Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model. Let us figure out together how to push this pull request forward. Connect with us through one of many communication channels we established here. Thank you for your patience ❤️ |
|
Hey @azplanlos, |
|
Hi Laurent, I‘ll take a look after my summer vacation. Unfortunately I ran out of time before leaving. The feature seems to be stable and is already used internally. But I’ll do some more refactoring and include some more tests before filing the pull request.
Am 26.08.2024 um 12:25 schrieb Laurent Broudoux ***@***.***>:
Hey @azplanlos<https://github.com/azplanlos>,
Any news on this topic? This is still marked as Draft but I definitely think it's an interesting feature.
Need any help on this?
—
Reply to this email directly, view it on GitHub<#1237 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AARE55UDFGSMQSJFTNAMP7TZTL67VAVCNFSM6AAAAABKVGD6KKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMBZHA3TGNRZGI>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
Hey @azplanlos, |
|
PR Summary: This PR enhances logging by tracking and persisting invocation orders for mock requests. Key changes include adding a new InvocationLogEntry model, repositories, and a listener (InvocationAdvancedMetrics) to log and retrieve invocation events, along with updates to various controllers and event constructors to support request IDs and proper ordering of log entries. |
|
|
||
| @Override | ||
| public void onApplicationEvent(@NonNull MockInvocationEvent event) { | ||
| repo.insert(new InvocationLogEntry(event.getTimestamp(), event.getServiceName(), event.getServiceVersion(), |
There was a problem hiding this comment.
Replace event.getTimestamp() with event.getInvocationTimestamp().getTime() to ensure a valid epoch value is passed to the log entry.
repo.insert(new InvocationLogEntry(
event.getInvocationTimestamp().getTime(),
event.getServiceName(),
event.getServiceVersion(),
event.getMockResponse(),
event.getInvocationTimestamp(),
event.getDuration(),
event.getSource().getClass().getSimpleName(),
event.getRequestId()
));
|
Reviewed up to commit:c98b8ce5656774573a7484fb7a4d0394953b7c72 Additional SuggestionOthers- Consider unifying id generation by using invocationTimestamp consistently and remove or clarify the purpose of timestampEpoch field. - Add a getter for the invocation timestamp or update consumers (e.g. InvocationAdvancedMetrics) to use getInvocationTimestamp() for obtaining the epoch millis.Few more points:
|
There was a problem hiding this comment.
Hey there, thanks a lot for the contributIon! A bot has make this one revival to my mind and I wanted to take the time to have a full review. As discussed in the past, this seems to be a super valuable use-case!
I've got some concerns regarding the persistence layer and I would love to have more explanations about the requestIdpart. I think having a live example with detailed use-case explanation could be nice as well. And I'll probably also request help for writing the documentation on that part too 😉
Also - and sorry because it seems to be a lot - could you rebase your branch on the 1.12.x branch from Microcks? This is where the devs happen at the moment.
|
|
||
| import java.util.Date; | ||
|
|
||
| @Document("invocations") |
There was a problem hiding this comment.
I don't think this one is necessary. I prefer to limit the number of dependencies to spring-data stuff to the minimum.
| /** | ||
| * | ||
| */ |
There was a problem hiding this comment.
You can remove unnecessary comments.
|
|
||
| private Set<String> resourcePaths; | ||
| private List<ParameterConstraint> parameterConstraints; | ||
| private String idPath; |
| /** | ||
| * Repository for InvocationLogEntries | ||
| */ | ||
| @NoRepositoryBean |
There was a problem hiding this comment.
This construct and way to define repository is different than the one we used for DailyStatisticRepository. I find it a bit more difficult to understand - especially the InvocationLogRepositoryImpl part with the MongoEntityInformation override.
I think it could be nice to refactor reusing the same pattern here. What do you think?
| private MongoTemplate mongoTemplate; | ||
|
|
||
| public InvocationLogRepositoryImpl(MongoOperations mongoOperations) { | ||
| super(new MongoEntityInformation<>() { |
There was a problem hiding this comment.
See my comment on interface definition.
| * @param limit maximum number of latest results | ||
| * @return list of results ordered by newest entry first | ||
| */ | ||
| @GetMapping(value = "/log/invocations/{service}/{version}") |
There was a problem hiding this comment.
We follow the plural form naming convention, so it should be /logs/invocations/{service}/{version}
| services.update.interval=${SERVICES_UPDATE_INTERVAL:0 0 0/2 * * *} | ||
|
|
||
| mocks.enable-invocation-stats=${ENABLE_INVOCATION_STATS:true} | ||
| mocks.enable-invocation-logs=${ENABLE_INVOCATION_LOGS:true} |
There was a problem hiding this comment.
It would be better to disable this by default and make it explicitly opted-in. At least during the first releases, to be sure we don't have regression issues.
Description
This is a draft of a new functionality I want to suggest. It basically does two things:
If this contribution is an interesting improvement to microcks in general I would try to get it out of draft status and also add some unit tests to check the functionality. And maybe we could look into on how this could be utilized for other controller types as well. Currently we only need this for the REST controller and didn't look into other things.
Related issue(s)