Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: add spec files for entity modeling #68
feat: add spec files for entity modeling #68
Changes from all commits
0dba5fb
b3dbda4
ed083a0
cd2cc83
5ea583c
5e8aae9
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had the some doubt when writing the prometheus parser, I do not know if we can assume we have only one service.
As we discussed today we might have a single exporter returning two (or more "services"). In that case either we will have multiple file or we need to change the structure to something like:
In this case we would not follow cloud integration structure
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for bring this up. If for some reason the same exporter exposes metrics from different services we can define a spec file for each of the service and keep the same structure.
The service will be picked from the metric prefix and treated as defined in the corresponding spec file.
I'm thinking about that this solution could also work for the exporter related metrics like go_ or the ones related to the host where the exporter runs like process_
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@gsanchezgavier To be clear, you're saying that in the case of 2 or more services for the same exporter we will create a file for each one? If that is your idea, I just worry about how it will impact external contributors, especially customers. It may be difficult to explain that, even with documentation, and the more files we have the harder it gets to contribute. We should really try to reduce the number of files required to make an exporter work.
I'm not sure we need to follow the exact same structure of the cloud integrations, especially if it doesn't work well for us.
Just my 2cts
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that we should try as much as possible to have one file per integration.
Either we follow the cloud integration approach adding more services with the
---
ES:
Or we can change the structure allowing arrays of services in one yaml. We will need to change a bit the automatic tool but then we will be free to diverge when needed
ES:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@morecar needs your opinion here. I think cloud int. also splits some specs files for some integrations.
I also want to mention that i think having 2 different services in one exporter don't looks like a good prometheus best practice.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we may need to look into some more exporters to get an idea of the number of "services" that they expose.
On the other hand we can just assume that 1 exporter = 1 service. For example Redis has metrics that start with very different "prefixes": redis_ , process_ , go_ . If we ignore the go prefix (which the exporter can be configured to not return), the metrics all belong to the Redis service, just with different entities. I'm not sure about other exporters but I'm guessing it may be the same.
In summary, I would not make services an array. If we find we need more than one service for one exporter we can use the first option, having multiple services on the same file
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sounds good to me