Skip to content
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

Component Model contains metric spec #226

Open
barnettZQG opened this issue Oct 18, 2019 · 6 comments
Open

Component Model contains metric spec #226

barnettZQG opened this issue Oct 18, 2019 · 6 comments

Comments

@barnettZQG
Copy link
Member

barnettZQG commented Oct 18, 2019

We have been working on the definition and implementation of the application specification, and we are very excited to find Like-minded organization.

Here's a question we're thinking about and discuss it with you.

For components, each component can have its own resource-layer-common and business-layer-customized monitoring metrics. There is a consensus in cloud-native systems to define metric based on the Prometheus specification. Components should be allowed to define endpoints of their own exposure metrics. The platform layer's metrics servers can be unitedly collected and applied to components of automated operations processes, such as automatic scaling and monitoring visualization.

Such as:

metrics:
    - path: "/metric"
       port: 8080
       type: prometheus
@hongchaodeng
Copy link
Member

I don't get the question. Could you provide more examples on the problems?

@resouer
Copy link
Member

resouer commented Oct 19, 2019

ref #153, i.e. Developer has opinion to Traits

/cc @technosophos

@vturecek
Copy link
Member

@barnettZQG is the idea that components would define the output format of metric data, or the inverse, where a component can specify an endpoint to consume metric data in a specific format?

@xiang90
Copy link
Contributor

xiang90 commented Oct 24, 2019

@vturecek

I agree that first one is important, but both metric format and the endpoint are needed. Then the external service can collect the metrics automatically from the given component.

@barnettZQG
Copy link
Member Author

@hongchaodeng @vturecek
The component defines the endpoint of standard monitoring metrics. The main thing is to expose the business metrics of different business services. For example, The API service exposes the API requests per second. But it must follow a certain specification to facilitate the collection of a unified metrics collection platform, such as Prometheus.

However, for some resource metrics, such as memory, CPU, etc., only the component definition needs to be enabled for collection. Data is typically obtained by an external platform such as Kubernetes.

and so. The monitoring metrics section defined in the component model might look like this:

metric:
    - enable_resource_metric: true
    - custom_metric_endpoint:
       - path: "/metric"
          port: 8080
          type: prometheus

@hongchaodeng
Copy link
Member

Great! Thanks for explanation!

In the ComponentSchematic type, the parameters section is the place to define those dev input.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants