Add exception tag in DefaultMongoCommandTagsProvider about micrometer

[shakuzen]

Thanks for the quick response. We'll aim to get this included in 1.14 then.

[shakuzen]

Thanks for opening the issue. I think you're the first person to ask for it, but we could certainly consider this enhancement. Not directly related to what you mentioned, but another consideration is that our MongoDB client instrumentation still doesn't use the Observation API (see the docs if you're not familiar). I think we'd like to have an instrumentation of the MongoDB client that does, but we need to check whether such instrumentation would be hosted in the Micrometer repo (as the current instrumentation is) or if it will be in the MongoDB client repo.
Also note if you're using Spring Data MongoDB, that has its own instrumentation based on the Observation API; see their docs.

[hadjiski]

@shakuzen thanks for the quick reply, I am aware of the observation offered by spring data for the mongo commands, but it appears a bit cumbersome at the moment. Compared to the spring data repository observation, the one for commands is not capable of extending the DefaultMongoHandlerObservationConvention to easily customize the tags, because it is package private, rather one should copy&paste the content and implement directly GlobalObservationConvention<MongoHandlerContext> to be able to be added to the ObservationRegistryCustomizer. This was probably addressed in this issue.
Maybe we can wait for Spring boot to pick it

Spring Data MongoDB currently has the most up-to-date code to support Observability in your MongoDB application. These changes, however, haven’t been picked up by Spring Boot (yet)

Overall the whole configuration is a bit awkward, whereas the DefaultMongoCommandTagsProvider is just working out of the box, just without the exception ;)

[hadjiski]

@shakuzen do you think it can go into 1.13.0 by 13 of May?
Since it only requires:
Tag.of("exception", (event instanceof CommandFailedEvent failed) ? getExceptionName(failed.getThrowable()) : "none")
or
Tag.of("error", (event instanceof CommandFailedEvent failed) ? getExceptionName(failed.getThrowable()) : "none")
depending on which convention you are following

by having such helper methods e.g.

private String getExceptionName(Throwable error) {
        return this.getSimpleClassName(error.getClass());
    }

    private String getSimpleClassName(Class<?> type) {
        String simpleName = type.getSimpleName();
        return !StringUtils.hasText(simpleName) ? type.getName() : simpleName;
    }

[shakuzen]

do you think it can go into 1.13.0 by 13 of May?

Typically, we would not merge enhancements for a feature release after a release candidate has been made available. 1.13.0-RC1 is already out. The proposed change sounds low risk enough, but the workaround - provide your own tags provider extending the default one - is also easy enough. Could you not use a custom tags provider until 1.14.0 if we included this enhancement there? Would you also be interested in contributing a pull request for this?

[hadjiski]

Thanks for letting me know, I agree with you and there is no urgency for 1.13, it was just an informational question. As of the PR contribution, currently I am not able to involve myself on that level 😐