Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Objections
Claims 1 and 11 are objected to because of the following informalities: the claims both recite “the selected metrics,” and there is insufficient antecedent basis for this limitation in the claims, as it is unclear what “the selected metrics” is referring to. Prior to the comparison of “the selected metrics”, there is a selection of “one or more stored metrics”. The issue is probably caused by the conflation of “the selected metrics” with the “one or more stored metrics”, even though it is possible that only one stored metric could have been selected, thus making the plural term “the selected metrics” erroneous. The Examiner suggests amending the claims so that each instance of “the selected metrics” is replaced with “the selected one or more metrics”. Appropriate correction is required.
For the purposes of art rejection, the Examiner is treating Claims 1 and 11 such that each instance of “the selected metrics” is replaced with “the selected one or more metrics”.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-2, 4, 6-7, 11-13, 15-16, and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over Venkatram (US 20230185594 A1) in view of Shankar (US 20230059940 A1) and Ghosh (US 20160162339 A1).
Regarding Claim 1, Venkatram teaches a monitoring system comprising:
a memory; and a controller coupled to the memory (
PNG
media_image1.png
488
469
media_image1.png
Greyscale
Venkatram discloses, “In some embodiments, the controller 112 can be a server, such as a web server,” ¶ 0021, and “In FIG. 1A, the controller 112 hosts the container orchestration system 120 (e.g., a container cluster) as an application,” ¶ 0023.
The claimed “controller” is mapped to the disclosed server’s processors enabled by corresponding computer instructions. The claimed “memory” is mapped to the disclosed server’s memory.
Although it is inherent or implied that a server comprises the disclosed processor(s), and “a memory; and a controller coupled to the memory”, the Examiner conducts an obviousness analysis to address the limitation. Venkatram already teaches that a computing device could comprise processors with coupled memory according to paragraphs 22 and 42 (
Venkatram discloses, “The VCIs can be provisioned with processing resources 104 and/or memory resources 106 and can communicate via the network interface 108. The processing resources 104 and the memory resources 108 provisioned to the VCIs can be local and/or remote to the hosts 102… By way of example, the memory resources 106 can include volatile and/or non-volatile memory available to the VCIs 116,” ¶ 0022,
“The hardware, for example, can include a number of processing resources 404 and a number of memory resources 406, such as a machine-readable medium (MRM) or other memory resources 406. The memory resources 406 can be internal and/or external to the machine 448 (e.g., the machine 448 can include internal memory resources and have access to external memory resources),” ¶ 0042.).
Therefore, based on the teaching already provided by Venkatram, it would have been obvious to combine Venkatram’s teaching of a computing device processors with coupled memory, and Venkatram’s teaching of the use of a server, to obtain a teaching that a server may comprise processors that are coupled to memory. Doing so would help allow for using traditional computers and implementing servers to improve reliability and reduce cost.
), the controller configured to:
configure a custom exporter to scrape metrics from each of a plurality of targeted pods in a distributed computing environment (
PNG
media_image2.png
667
626
media_image2.png
Greyscale
Table of Paragraph 31 of Venkatram.
Venkatram discloses, “In some embodiments, the controller 112 can be a server, such as a web server,” ¶ 0021, and “In FIG. 1A, the controller 112 hosts the container orchestration system 120 (e.g., a container cluster) as an application,” ¶ 0023,
“The COS 220 can include a first exporter 222-1 and a second exporter 222-2 (referred to cumulatively as ‘exporters 222’). Though the example of two exporters is discussed herein, embodiments of the present disclosure are not limited to a particular quantity of exporters. The exporters 222 can run on the COS 220 and can collect metrics associated with clusters of the COS 220,” ¶ 0026, “a first query engine configured to communicate a first query for a metric associated with a particular service instance and exported by the first metric exporter, wherein the first query includes a label utilized by the first metric exporter corresponding to a type of the service instance determined based on the mapping,” Claim 9, and “The system of claim 12, wherein the particular service instance is one of: a particular node of the container cluster; a particular pod of the container cluster; a particular container of the container cluster; and a particular namespace of the container cluster,” Claim 13.
Here, the container orchestration system (COS) of the server uses the exporters to scrape (or collect) metrics from a particular service instance of a container cluster, which includes a particular pod of the container cluster.
The exporter is customizable because its associated mapping configuration defines specific labels for it. Two exporters may have respective mapping configurations with different labels.);
collect the metrics from each of the plurality of targeted pods; store the collected metrics in the memory (
Venkatram discloses, “The exporters 222 can run on the COS 220 and can collect metrics associated with clusters of the COS 220… the collected metrics can be sent to the metric store 234. … The metric store 234 can collect and stores the metrics as time series data,” ¶ 0026, “a first query engine configured to communicate a first query for a metric associated with a particular service instance and exported by the first metric exporter, wherein the first query includes a label utilized by the first metric exporter corresponding to a type of the service instance determined based on the mapping,” Claim 9, and “The system of claim 12, wherein the particular service instance is one of: a particular node of the container cluster; a particular pod of the container cluster; a particular container of the container cluster; and a particular namespace of the container cluster,” Claim 13.
A metric is collected from an associated particular service instance. According to Claim 13 of Venkatram, this particular service instance can be a particular pod of the container cluster.
Here, the collected metrics are stored in a metric store. Venkatram does not explicitly disclose the metric store is placed on a memory. However, the Examiner conducts an obviousness analysis to address the limitation of the collected metrics being stored in the memory. Venkatram already teaches that a computing device comprises processors with coupled memory according to paragraphs 22 and 42 (
Venkatram discloses, “The VCIs can be provisioned with processing resources 104 and/or memory resources 106 and can communicate via the network interface 108. The processing resources 104 and the memory resources 108 provisioned to the VCIs can be local and/or remote to the hosts 102… By way of example, the memory resources 106 can include volatile and/or non-volatile memory available to the VCIs 116,” ¶ 0022,
“The hardware, for example, can include a number of processing resources 404 and a number of memory resources 406, such as a machine-readable medium (MRM) or other memory resources 406. The memory resources 406 can be internal and/or external to the machine 448 (e.g., the machine 448 can include internal memory resources and have access to external memory resources),” ¶ 0042.).
Therefore, based on the teaching already provided by Venkatram, it would have been obvious to provide that the metric store is implemented by memory. Doing so would help for faster storage and retrieval of the metrics using memory, than if the metrics were stored in a hard disk drive.);
Venkatram does not teach to:
select one or more stored metrics associated with a pod to be processed; compare the selected metrics with corresponding preconfigured thresholds associated with the pod to be processed;
generate a pre/post method for the pod, wherein the generated pre/post method is based at least upon the comparison between the selected metrics and the preconfigured thresholds associated with the pod; and implement the generated pre/post method on the pod.
However, Shankar teaches to:
select one or more stored metrics associated with a pod to be processed; compare the selected metrics with corresponding preconfigured thresholds associated with the pod to be processed (
Shankar discloses, “The domain name system (DNS) resolver can receive, from a service executing on one or more servers hosting a resource, a performance score of the resource. The performance score can be computed from a plurality of metrics determined from a performance monitoring service executing on the one or more servers in communication with the resource,” Abstract,
“The embodiments described herein enable cloud services to identify metrics that are important to their network instead of having to rely solely on generic network performance data. Based on the metrics, a DNS resolver can identify performance scores of the cloud service hosting the applications,” ¶ 0104,
“The scoring service 520 can be configured to retrieve or receive metrics from the metrics service 514,” ¶ 0149,
“Depending on the metric that is being observed, the scoring service 520 can be configured to classify the calculation of the performance score into at least a fixed metric calculation or a variable metric score calculation. For the fixed metric score calculation, the scoring service 520 can be configured to compare the current value of the fixed metric with a fixed threshold. The fixed threshold can indicate an upper or lower bound of the fixed metric. For example, the CPU usage metric can represent a percentage value of the cloud PoP's 502 CPU consumption, and an upper bound of 95% can be a threshold for the metric relating to CPU consumption,” ¶ 0152.
Here, Shankar teaches selecting a stored metric associated with a server-based resource, and then comparing it with a threshold. After the combination of Venkatram with Shankar, this server-based resource could be a pod of the container cluster from Venkatram, and the threshold, that the metric is compared with, is specified to be specific to each pod, so that each pod has its own threshold.).
Venkatram and Shankar are both considered to be analogous to the claimed invention because they are in the same field of container/pod monitoring. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Venkatram to incorporate the teachings of Shankar and provide to select one or more stored metrics associated with the resource to be processed; compare the selected metrics with corresponding preconfigured thresholds associated with the resource to be processed. Doing so would help allow for determining if the metrics are considered optimal or anomalous, in order to take remedial actions if needed (Shankar discloses, “If the health score from the PHS indicates that the PoP is relatively unhealthy, this information would influence the observed RTT value for a given cloud PoP. The PHS can de-prioritize the unhealthy PoP based on a higher RTT. If the PHS identifies that the PoP is unable to serve any more traffic, the DNS resolver can exclude this PoP from the DNS decisions until it is enabled by the PHS after the health is restored,” ¶ 0015.).
Venkatram in view of Shankar does not teach to generate a pre/post method for the pod, wherein the generated pre/post method is based at least upon the comparison between the selected metrics and the preconfigured thresholds associated with the pod; and implement the generated pre/post method on the pod.
However, Ghosh teaches to generate a pre/post method for the pod, wherein the generated pre/post method is based at least upon the comparison between the selected metrics and the preconfigured thresholds associated with the pod; and implement the generated pre/post method on the pod (
Ghosh discloses, “The management system enables a confidence metric for a stability of tiers of the application workload (or workload pattern) to determine an ideal time to deploy pieces/components or provision portions of that workload pattern, along with providing an estimated time to availability as changes are made to the workload pattern,” ¶ 0013, and “At block 315, the management system generates a set of new operations that must be met by the workload pattern. In an embodiment, the management system generates a set of new operations based on the tier stability metric generated in the process flow 200 and compared to acceptance threshold,” ¶ 0024.
The claimed pre/post method is mapped to the disclosed “set of new operations”, which are generated based on a comparison between a tier stability metric compared with an acceptance threshold. This set of operations is generated and applied to a workload pattern (application workload) so that it must meet them. The workload pattern/application workload is similar to the pod of Venkatram in that it is also deployed.
After the combination of Venkatram in view of Shankar, with Ghosh, the set of operations are generated based on a comparison between selected metrics and corresponding preconfigured thresholds, before being applied to a pod, as specified by Venkatram in view of Shankar. Said set of operations could include, but not be limited to, preventing routing of traffic to the pod, based on Shankar’s teaching of preventing routing of traffic to its resource (Shankar discloses, “For example, the CPU usage metric can represent a percentage value of the cloud PoP's 502 CPU consumption, and an upper bound of 95% can be a threshold for the metric relating to CPU consumption. Responsive to identifying values that are close to or exceed the upper bound, the scoring service 520 can be configured to identify that the client 102 is not to be routed to this cloud PoP 502,” ¶ 0152.).).
Venkatram in view of Shankar, and Ghosh are both considered to be analogous to the claimed invention because they are in the same field of computer resource deployment. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Venkatram in view of Shankar to incorporate the teachings of Ghosh and provide to generate a pre/post method for the pod, wherein the generated pre/post method is based at least upon the comparison between the selected metrics and the preconfigured thresholds associated with the pod; and implement the generated pre/post method on the pod. Doing so would help allow for more efficient usage of the resources by deploying resources based on the metrics (Ghosh discloses, “That is, the management system generates a tier stability metric for each item in the current set of requirements to optimize a churn and prioritize a deployment order for the components of the workload pattern (e.g., the stable components with the higher tier stability metric can be deployed before those with a lower tier stability metric),” ¶ 0018.).
Claim 11 is a method claim corresponding to the monitoring system Claim 1. Therefore, Claim 11 is rejected for the same reasons set forth in the rejection of Claim 1.
Regarding Claim 2, Venkatram in view of Shankar and Ghosh teaches the monitoring system of claim 1, wherein the custom exporter is configured to collect the metrics from each of the plurality of targeted pods after a time period or upon an occurrence of an event (
Shankar discloses, “The monitoring agents 120 and 197 may monitor, measure, collect, and/or analyze data on a predetermined frequency, based upon an occurrence of given event(s) or in real time during operation of network environment 100,” ¶ 0062.
After the combination of Venkatram with Shankar these metrics are collected from each of the selected pods from Venkatram, after a time period or upon an occurrence of an event.).
Venkatram and Shankar are both considered to be analogous to the claimed invention because they are in the same field of distributed data communication. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Venkatram to incorporate the teachings of Shankar and provide wherein the custom exporter is configured to collect the metrics from each of the plurality of targeted pods after a time period or upon an occurrence of an event. Doing so would help allow for detecting if the metrics change over time or follow a periodic pattern; and save storage space and conserve computational resources, compared to the situation where metrics/data are constantly collected (Shankar discloses, “The monitoring agents 120 and 197 may monitor, measure, collect, and/or analyze data on a predetermined frequency, based upon an occurrence of given event(s) or in real time during operation of network environment 100. The monitoring agents may monitor resource consumption and/or performance of hardware, software, and/or communications resources of clients 102, networks 104, appliances 200, and/or 205, and/or servers 106,” ¶ 0062, and “For example, based upon one or more monitored performance conditions or metrics, application delivery system 190 may be dynamically adjusted, periodically or in real time, to optimize application delivery by servers 106 to clients 102, based upon network environment performance and conditions,” ¶ 0063.).
Claim 12 is a method claim corresponding to the monitoring system Claim 2. Therefore, Claim 12 is rejected for the same reasons set forth in the rejection of Claim 2.
Regarding Claim 4, Venkatram in view of Shankar and Ghosh teaches the monitoring system of claim 1, wherein the stored metrics include time-series data (
Venkatram discloses, “The metric store 234 can collect and stores the metrics as time series data. Stated differently, metrics information can be stored with the timestamp at which it was recorded, alongside optional key-value pairs called labels,” ¶ 0026.).
Regarding Claim 6, Venkatram in view of Shankar and Ghosh teaches the monitoring system of claim 1, wherein the controller is further configured to select the one or more stored metrics based on parameters of rules or conditions associated with the pod to be processed (
Shankar discloses, “The metrics aggregator can scrape health metrics based on the scrape targets for the applications. Rules and alerts can define how to pre-compute health related scores and trigger alerts when the metrics satisfy thresholds,” ¶ 0009,
“The embodiments described herein enable cloud services to identify metrics that are important to their network instead of having to rely solely on generic network performance data. Based on the metrics, a DNS resolver can identify performance scores of the cloud service hosting the applications,” ¶ 0104.
Here, Shankar teaches selecting a stored metric associated with a server-based resource, based on rules associated with the stored metric. After the combination of Venkatram with Shankar, this server-based resource could be a pod of the container cluster from Venkatram.).
Venkatram and Shankar are both considered to be analogous to the claimed invention because they are in the same field of container/pod monitoring. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Venkatram to incorporate the teachings of Shankar and provide wherein the controller is further configured to select the one or more stored metrics based on parameters of rules or conditions associated with the pod to be processed. Doing so would help allow for measuring the selected metrics with regards to the rules or conditions, and take remedial action accordingly if the metrics do not satisfy the rules or conditions (Shankar discloses, “For example, the CPU usage metric can represent a percentage value of the server's CPU consumption, and an upper bound of 95% can be a threshold for the metric relating to the CPU consumption. For values closer to or exceeding the upper bound, the PHS can steer network traffic away from this PoP,” ¶ 0012, “If the health score from the PHS indicates that the PoP is relatively unhealthy, this information would influence the observed RTT value for a given cloud PoP. The PHS can de-prioritize the unhealthy PoP based on a higher RTT. If the PHS identifies that the PoP is unable to serve any more traffic, the DNS resolver can exclude this PoP from the DNS decisions until it is enabled by the PHS after the health is restored,” ¶ 0015.).
Regarding Claim 7, Venkatram in view of Shankar and Ghosh teaches the monitoring system of claim 6, wherein the parameters include at least one of central processing unit (CPU) usage, data workload, read error rates, write error rates, and data dependencies (
Shankar discloses, “The metric object can include a metric type, such as performance type, service level indicator (SLI) type, or synthetic type or some combination of the performance type, service level indicator (SLI) type, and synthetic type. The performance type can identify a measurement of the underlying server performance such as packet interface rate, CPU usage, or File I/O operations rate,” ¶ 0010.
Here, CPU usage is used as one of the available metrics.).
Venkatram and Shankar are both considered to be analogous to the claimed invention because they are in the same field of container/pod monitoring. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Venkatram to incorporate the teachings of Shankar and provide wherein the parameters include at least one of central processing unit (CPU) usage, data workload, read error rates, write error rates, and data dependencies. Doing so would help allow for detecting if a measured parameter such as central processing unit (CPU) usage approaches or exceeds a threshold and take remedial action accordingly (Shankar discloses, “For example, the CPU usage metric can represent a percentage value of the server's CPU consumption, and an upper bound of 95% can be a threshold for the metric relating to the CPU consumption. For values closer to or exceeding the upper bound, the PHS can steer network traffic away from this PoP,” ¶ 0012.).
Regarding Claim 13, Venkatram in view of Shankar and Ghosh teaches the method of claim 11, wherein the collected metrics include time-series data (
Venkatram discloses, “The metric store 234 can collect and stores the metrics as time series data. Stated differently, metrics information can be stored with the timestamp at which it was recorded, alongside optional key-value pairs called labels,” ¶ 0026.).
Regarding Claim 15, Venkatram in view of Shankar and Ghosh teaches the method of claim 11, wherein the selecting the one or more stored metrics is based on parameters associated with the pod to be processed (
Shankar discloses, “The metrics aggregator can scrape health metrics based on the scrape targets for the applications. Rules and alerts can define how to pre-compute health related scores and trigger alerts when the metrics satisfy thresholds,” ¶ 0009,
“The embodiments described herein enable cloud services to identify metrics that are important to their network instead of having to rely solely on generic network performance data. Based on the metrics, a DNS resolver can identify performance scores of the cloud service hosting the applications,” ¶ 0104.
Here, Shankar teaches selecting a stored metric associated with a server-based resource, based on rules associated with the stored metric. After the combination of Venkatram with Shankar, this server-based resource could be a pod of the container cluster from Venkatram.).
Venkatram and Shankar are both considered to be analogous to the claimed invention because they are in the same field of container/pod monitoring. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Venkatram to incorporate the teachings of Shankar and provide wherein the selecting the one or more stored metrics is based on parameters associated with the pod to be processed. Doing so would help allow for measuring the selected metrics with regards to the rules or conditions, and take remedial action accordingly if the metrics do not satisfy the rules or conditions (Shankar discloses, “For example, the CPU usage metric can represent a percentage value of the server's CPU consumption, and an upper bound of 95% can be a threshold for the metric relating to the CPU consumption. For values closer to or exceeding the upper bound, the PHS can steer network traffic away from this PoP,” ¶ 0012, “If the health score from the PHS indicates that the PoP is relatively unhealthy, this information would influence the observed RTT value for a given cloud PoP. The PHS can de-prioritize the unhealthy PoP based on a higher RTT. If the PHS identifies that the PoP is unable to serve any more traffic, the DNS resolver can exclude this PoP from the DNS decisions until it is enabled by the PHS after the health is restored,” ¶ 0015.).
Regarding Claim 16, Venkatram in view of Shankar and Ghosh teaches the method of claim 15, wherein the parameters include at least one of central processing unit (CPU) usage, data workload, read error rates, write error rates, and data dependencies (
Shankar discloses, “The metric object can include a metric type, such as performance type, service level indicator (SLI) type, or synthetic type or some combination of the performance type, service level indicator (SLI) type, and synthetic type. The performance type can identify a measurement of the underlying server performance such as packet interface rate, CPU usage, or File I/O operations rate,” ¶ 0010.
Here, CPU usage is used as one of the available metrics.).
Venkatram and Shankar are both considered to be analogous to the claimed invention because they are in the same field of container/pod monitoring. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Venkatram to incorporate the teachings of Shankar and provide wherein the parameters include at least one of central processing unit (CPU) usage, data workload, read error rates, write error rates, and data dependencies. Doing so would help allow for detecting if a measured parameter such as central processing unit (CPU) usage approaches or exceeds a threshold and take remedial action accordingly (Shankar discloses, “For example, the CPU usage metric can represent a percentage value of the server's CPU consumption, and an upper bound of 95% can be a threshold for the metric relating to the CPU consumption. For values closer to or exceeding the upper bound, the PHS can steer network traffic away from this PoP,” ¶ 0012.).
Regarding Claim 18, Venkatram teaches an information handling system comprising:
a memory; and a controller coupled to the memory (
PNG
media_image1.png
488
469
media_image1.png
Greyscale
Venkatram discloses, “In some embodiments, the controller 112 can be a server, such as a web server,” ¶ 0021, and “In FIG. 1A, the controller 112 hosts the container orchestration system 120 (e.g., a container cluster) as an application,” ¶ 0023.
The claimed “controller” is mapped to the disclosed server’s processors enabled by corresponding computer instructions. The claimed “memory” is mapped to the disclosed server’s memory.
Although it is inherent or implied that a server comprises the disclosed processor(s), and “a memory; and a controller coupled to the memory”, the Examiner conducts an obviousness analysis to address the limitation. Venkatram already teaches that a computing device could comprise processors with coupled memory according to paragraphs 22 and 42 (
Venkatram discloses, “The VCIs can be provisioned with processing resources 104 and/or memory resources 106 and can communicate via the network interface 108. The processing resources 104 and the memory resources 108 provisioned to the VCIs can be local and/or remote to the hosts 102… By way of example, the memory resources 106 can include volatile and/or non-volatile memory available to the VCIs 116,” ¶ 0022,
“The hardware, for example, can include a number of processing resources 404 and a number of memory resources 406, such as a machine-readable medium (MRM) or other memory resources 406. The memory resources 406 can be internal and/or external to the machine 448 (e.g., the machine 448 can include internal memory resources and have access to external memory resources),” ¶ 0042.).
Therefore, based on the teaching already provided by Venkatram, it would have been obvious to combine Venkatram’s teaching of a computing device processors with coupled memory, and Venkatram’s teaching of the use of a server, to obtain a teaching that a server may comprise processors that are coupled to memory. Doing so would help allow for using traditional computers and implementing servers to improve reliability and reduce cost.
), the controller configured to:
configure a custom exporter to scrape metrics from each of a plurality of targeted pods in a Kubernetes environment (
PNG
media_image2.png
667
626
media_image2.png
Greyscale
Table of Paragraph 31 of Venkatram.
Venkatram discloses, “In some embodiments, the controller 112 can be a server, such as a web server,” ¶ 0021, and “In FIG. 1A, the controller 112 hosts the container orchestration system 120 (e.g., a container cluster) as an application,” ¶ 0023,
“# Sample Metric - Kubernetes_system_container_memory_major_page_faults {container_name=”kubelet” , host=vrops-telegraf-k8s-fvcvr”, # In above metric, labels/label names are container_name, host, job, namespace, node_name # Provide only the “LABEL NAME” below which possess id/name of Kubernetes resources such as Node, Namespace, Pod, Container,” ¶ 0031,
“The COS 220 can include a first exporter 222-1 and a second exporter 222-2 (referred to cumulatively as ‘exporters 222’). Though the example of two exporters is discussed herein, embodiments of the present disclosure are not limited to a particular quantity of exporters. The exporters 222 can run on the COS 220 and can collect metrics associated with clusters of the COS 220,” ¶ 0026, “a first query engine configured to communicate a first query for a metric associated with a particular service instance and exported by the first metric exporter, wherein the first query includes a label utilized by the first metric exporter corresponding to a type of the service instance determined based on the mapping,” Claim 9, and “The system of claim 12, wherein the particular service instance is one of: a particular node of the container cluster; a particular pod of the container cluster; a particular container of the container cluster; and a particular namespace of the container cluster,” Claim 13.
Here, the container orchestration system (COS) of the server uses the exporters to scrape (or collect) metrics from a particular service instance of a container cluster, which includes a particular pod of the container cluster.
The exporter is customizable because its associated mapping configuration defines specific labels for it. Two exporters may have respective mapping configurations with different labels.);
collect the metrics from each of the plurality of targeted pods; store the collected metrics in the memory (
Venkatram discloses, “The exporters 222 can run on the COS 220 and can collect metrics associated with clusters of the COS 220… the collected metrics can be sent to the metric store 234. … The metric store 234 can collect and stores the metrics as time series data,” ¶ 0026, “a first query engine configured to communicate a first query for a metric associated with a particular service instance and exported by the first metric exporter, wherein the first query includes a label utilized by the first metric exporter corresponding to a type of the service instance determined based on the mapping,” Claim 9, and “The system of claim 12, wherein the particular service instance is one of: a particular node of the container cluster; a particular pod of the container cluster; a particular container of the container cluster; and a particular namespace of the container cluster,” Claim 13.
A metric is collected from an associated particular service instance. According to Claim 13 of Venkatram, this particular service instance can be a particular pod of the container cluster.
Here, the collected metrics are stored in a metric store. Venkatram does not explicitly disclose the metric store is placed on a memory. However, the Examiner conducts an obviousness analysis to address the limitation of the collected metrics being stored in the memory. Venkatram already teaches that a computing device comprises processors with coupled memory according to paragraphs 22 and 42 (
Venkatram discloses, “The VCIs can be provisioned with processing resources 104 and/or memory resources 106 and can communicate via the network interface 108. The processing resources 104 and the memory resources 108 provisioned to the VCIs can be local and/or remote to the hosts 102… By way of example, the memory resources 106 can include volatile and/or non-volatile memory available to the VCIs 116,” ¶ 0022,
“The hardware, for example, can include a number of processing resources 404 and a number of memory resources 406, such as a machine-readable medium (MRM) or other memory resources 406. The memory resources 406 can be internal and/or external to the machine 448 (e.g., the machine 448 can include internal memory resources and have access to external memory resources),” ¶ 0042.).
Therefore, based on the teaching already provided by Venkatram, it would have been obvious to provide that the metric store is implemented by memory. Doing so would help for faster storage and retrieval of the metrics using memory, than if the metrics were stored in a hard disk drive.);
Venkatram does not teach to:
select one or more stored metrics associated with a pod to be processed;
generate a pre/post method for the pod using the selected one or more metrics associated with the pod; and implement the generated pre/post method on the pod.
However, Shankar teaches to:
select one or more stored metrics associated with a pod to be processed (
Shankar discloses, “The domain name system (DNS) resolver can receive, from a service executing on one or more servers hosting a resource, a performance score of the resource. The performance score can be computed from a plurality of metrics determined from a performance monitoring service executing on the one or more servers in communication with the resource,” Abstract,
“The embodiments described herein enable cloud services to identify metrics that are important to their network instead of having to rely solely on generic network performance data. Based on the metrics, a DNS resolver can identify performance scores of the cloud service hosting the applications,” ¶ 0104,
“The scoring service 520 can be configured to retrieve or receive metrics from the metrics service 514,” ¶ 0149.
Here, Shankar teaches selecting a stored metric associated with a server-based resource. After the combination of Venkatram with Shankar, this server-based resource could be a pod of the container cluster from Venkatram.).
Venkatram and Shankar are both considered to be analogous to the claimed invention because they are in the same field of container/pod monitoring. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Venkatram to incorporate the teachings of Shankar and provide to select one or more stored metrics associated with the resource to be processed. Doing so would help allow for determining if the metrics are considered optimal or anomalous, in order to take remedial actions if needed (Shankar discloses, “If the health score from the PHS indicates that the PoP is relatively unhealthy, this information would influence the observed RTT value for a given cloud PoP. The PHS can de-prioritize the unhealthy PoP based on a higher RTT. If the PHS identifies that the PoP is unable to serve any more traffic, the DNS resolver can exclude this PoP from the DNS decisions until it is enabled by the PHS after the health is restored,” ¶ 0015.).
Venkatram in view of Shankar does not teach to generate a pre/post method for the pod using the selected one or more metrics associated with the pod; and implement the generated pre/post method on the pod.
However, Ghosh teaches to generate a pre/post method for the pod using the selected one or more metrics associated with the pod; and implement the generated pre/post method on the pod (
Ghosh discloses, “The management system enables a confidence metric for a stability of tiers of the application workload (or workload pattern) to determine an ideal time to deploy pieces/components or provision portions of that workload pattern, along with providing an estimated time to availability as changes are made to the workload pattern,” ¶ 0013, and “At block 315, the management system generates a set of new operations that must be met by the workload pattern. In an embodiment, the management system generates a set of new operations based on the tier stability metric generated in the process flow 200 and compared to acceptance threshold,” ¶ 0024.
The claimed pre/post method is mapped to the disclosed “set of new operations”, which are generated based on a comparison between a tier stability metric compared with an acceptance threshold. This set of operations is generated and applied to a workload pattern (application workload) so that it must meet them. The workload pattern/application workload is similar to the pod of Venkatram in that it is also deployed.
After the combination of Venkatram in view of Shankar, with Ghosh, the set of operations are generated based on a comparison between selected metrics and corresponding preconfigured thresholds, before being applied to a pod, as specified by Venkatram in view of Shankar. Said set of operations could include, but not be limited to, preventing routing of traffic to the pod, based on Shankar’s teaching of preventing routing of traffic to its resource (Shankar discloses, “For example, the CPU usage metric can represent a percentage value of the cloud PoP's 502 CPU consumption, and an upper bound of 95% can be a threshold for the metric relating to CPU consumption. Responsive to identifying values that are close to or exceed the upper bound, the scoring service 520 can be configured to identify that the client 102 is not to be routed to this cloud PoP 502,” ¶ 0152.).).
Venkatram in view of Shankar, and Ghosh are both considered to be analogous to the claimed invention because they are in the same field of computer resource deployment. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Venkatram in view of Shankar to incorporate the teachings of Ghosh and provide to generate a pre/post method for the pod using the selected one or more metrics associated with the pod; and implement the generated pre/post method on the pod. Doing so would help allow for more efficient usage of the resources by deploying resources based on the metrics (Ghosh discloses, “That is, the management system generates a tier stability metric for each item in the current set of requirements to optimize a churn and prioritize a deployment order for the components of the workload pattern (e.g., the stable components with the higher tier stability metric can be deployed before those with a lower tier stability metric),” ¶ 0018.).
Regarding Claim 19, Venkatram in view of Shankar and Ghosh teaches the information handling system of claim 18, wherein the controller is further configured to collect the metrics from each of the plurality of targeted pods after a time period or an occurrence of a condition (
Shankar discloses, “The monitoring agents 120 and 197 may monitor, measure, collect, and/or analyze data on a predetermined frequency, based upon an occurrence of given event(s) or in real time during operation of network environment 100,” ¶ 0062.
After the combination of Venkatram with Shankar these metrics are collected from each of the selected pods from Venkatram, after a time period or upon an occurrence of an event/condition.).
Venkatram and Shankar are both considered to be analogous to the claimed invention because they are in the same field of distributed data communication. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Venkatram to incorporate the teachings of Shankar and provide wherein the controller is further configured to collect the metrics from each of the plurality of targeted pods after a time period or an occurrence of a condition. Doing so would help allow for detecting if the metrics change over time or follow a periodic pattern; and save storage space and conserve computational resources, compared to the situation where metrics/data are constantly collected (Shankar discloses, “The monitoring agents 120 and 197 may monitor, measure, collect, and/or analyze data on a predetermined frequency, based upon an occurrence of given event(s) or in real time during operation of network environment 100. The monitoring agents may monitor resource consumption and/or performance of hardware, software, and/or communications resources of clients 102, networks 104, appliances 200, and/or 205, and/or servers 106,” ¶ 0062, and “For example, based upon one or more monitored performance conditions or metrics, application delivery system 190 may be dynamically adjusted, periodically or in real time, to optimize application delivery by servers 106 to clients 102, based upon network environment performance and conditions,” ¶ 0063.).
Regarding Claim 20, Venkatram in view of Shankar and Ghosh teaches the information handling system of claim 19, wherein the collected metrics include time-series data (
Venkatram discloses, “The metric store 234 can collect and stores the metrics as time series data. Stated differently, metrics information can be stored with the timestamp at which it was recorded, alongside optional key-value pairs called labels,” ¶ 0026.).
Claims 3 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Venkatram (US 20230185594 A1) in view of Shankar (US 20230059940 A1), Ghosh (US 20160162339 A1), and Ptacek (“Hooking Up Fly Metrics”).
Regarding Claim 3, Venkatram in view of Shankar and Ghosh teaches the monitoring system of claim 2. Venkatram in view of Shankar and Ghosh does not teach wherein the custom exporter is configured to transform the collected metrics into Prometheus Query Language (PromQL) data.
However, Ptacek teaches wherein the custom exporter is configured to transform the collected metrics into Prometheus Query Language (PromQL) data (
Ptacek discloses, “Remember, Fly’s systems are scraping your metrics at some interval and generating vectors of counters, and PromQL’s job is generally to turn those raw values into intelligible time-series information,” Page 5.
Here, collected, raw metrics are transformed into a PromQL format. After the combination of Venkatram in view of Shankar and Ghosh, with Ptacek, the exporter from Venkatram in view of Shankar and Ghosh is configured to transform raw collected metrics into a PromQL format as specified by Ptacek.).
Venkatram in view of Shankar and Ghosh, and Ptacek are both considered to be analogous to the claimed invention because they are in the same field of automated data collection. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Venkatram in view of Shankar and Ghosh to incorporate the teachings of Ptacek and provide wherein the custom exporter is configured to transform the collected metrics into Prometheus Query Language (PromQL) data. Doing so would help allow for multi-dimensional filtering, native time-series handling, and flexible real-time aggregation operations associated with the PromQL format.
Regarding Claim 14, Venkatram in view of Shankar and Ghosh teaches the method of claim 11. Venkatram in view of Shankar and Ghosh does not teach wherein the configuring the custom exporter includes configuring the custom exporter to transform the collected metrics into a Prometheus Query Language (PromQL) data.
However, Ptacek teaches wherein the configuring the custom exporter includes configuring the custom exporter to transform the collected metrics into a Prometheus Query Language (PromQL) data (
Ptacek discloses, “Remember, Fly’s systems are scraping your metrics at some interval and generating vectors of counters, and PromQL’s job is generally to turn those raw values into intelligible time-series information,” Page 5.
Here, collected, raw metrics are transformed into a PromQL format. After the combination of Venkatram in view of Shankar and Ghosh, with Ptacek, the exporter from Venkatram in view of Shankar and Ghosh is configured to transform raw collected metrics into a PromQL format as specified by Ptacek.).
Venkatram in view of Shankar and Ghosh, and Ptacek are both considered to be analogous to the claimed invention because they are in the same field of automated data collection. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Venkatram in view of Shankar and Ghosh to incorporate the teachings of Ptacek and provide wherein the configuring the custom exporter includes configuring the custom exporter to transform the collected metrics into a Prometheus Query Language (PromQL) data. Doing so would help allow for multi-dimensional filtering, native time-series handling, and flexible real-time aggregation operations associated with the PromQL format.
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Venkatram (US 20230185594 A1) in view of Shankar (US 20230059940 A1), Ghosh (US 20160162339 A1), and Yoo (KR 102062576 B1).
Regarding Claim 5, Venkatram in view of Shankar and Ghosh teaches the monitoring system of claim 1. Venkatram in view of Shankar and Ghosh does not teach wherein the custom exporter is configured to transmit the collected metrics for storing in response to a query from a Prometheus server.
However, Yoo teaches wherein the custom exporter is configured to transmit the collected metrics for storing in response to a query from a Prometheus server (
Yoo discloses, “The prometheus server 210 may request the data collected from the exporters 233 and 236, and the exporters 233 and 236 may execute a monitoring script for an item assigned to the exporter. The exporters 233 and 236 may transmit the collected monitoring data 234 and 237 to the prometheus server 210 based on whether a trigger has occurred,” Page 4.).
Venkatram in view of Shankar and Ghosh, and Yoo are both considered to be analogous to the claimed invention because they are in the same field of automated data collection. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Venkatram in view of Shankar and Ghosh to incorporate the teachings of Yoo and provide wherein the custom exporter is configured to transmit the collected metrics for storing in response to a query from a Prometheus server. Doing so would help allow for storing the metrics in a Prometheus database, allowing for fine-tuning the metrics within the database to fix any errors if found (Yoo discloses, “Prometheus is an extensible open source monitoring system that stores all data in a time series database. Prometheus offers a multidimensional data model and a powerful query language that allows system administrators to easily and fine-tune the definition of metrics and generate more accurate reports,” Page 3.).
Claims 8-10 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Venkatram (US 20230185594 A1) in view of Shankar (US 20230059940 A1), Ghosh (US 20160162339 A1), and Filiz (US 11392422 B1).
Regarding Claim 8, Venkatram in view of Shankar and Ghosh teaches the monitoring system of claim 1. Venkatram in view of Shankar and Ghosh does not teach wherein the determined pre/post method includes a combination of a base pre/post method and a derived pre/post method.
However, Filiz teaches wherein the determined pre/post method includes a combination of a base pre/post method and a derived pre/post method (
Filiz discloses, “In some embodiments, the pod scheduler 138 refers to a pre-registered task definition in its code execution request to the serverless container management service 140. The code execution request may also include override fields that override any fields appearing in the pre-registered task definition. For example, the pod scheduler 138 may calculate the resource requirements of a pod, and specify the resource requirements in the code execution request such that any default resource specifications in the pre-registered task definition are replaced with the resource requirements included in the code execution request. The pod scheduler 138 may determine the resource requirements based on (i) the resource requirements specified in the pod specification 134A, (ii) additional information in the pod specification 134A about the execution of the pod such as whether some or all of the containers in the pod are executed in series or in parallel, and (iii) the resource requirements associated with the agents that facilitate the execution of the pod, such as, for example, the initializer, the network proxy, the node agent, and the container runtime illustrated in FIG. 1,” Col 11, Lines 4-23, and “The pre-registered task definition may include a static or default definition of the agents (e.g., KUBERNETES agents) to be executed using the compute capacity acquired by the serverless container management service 140 as part of a task, where the agents can then process the pod specification associated with the pod and launch the pod,” Col 11, Lines 33-38.
Here, Filiz teaches deployment tasks consisting of a base or default deployment task (disclosed “pre-registered task definition”, which is implemented without regards to values or labels of collected metrics), and a derived or pod-specific deployment task (the disclosed “task definition” after the default resource specifications in the original pre-registered task definition are replaced with the resource requirements calculated for the pod).
After the combination of Venkatram in view of Shankar and Ghosh, with Filiz, the pre/post method determined in Venkatram in view of Shankar and Ghosh now consists of a base or default pre/post method or task, and a derived or pod-specific pre/post method or task, as specified by Filiz.).
Venkatram in view of Shankar and Ghosh, and Filiz are both considered to be analogous to the claimed invention because they are in the same field of computer container/pod deployment. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Venkatram in view of Shankar and Ghosh to incorporate the teachings of Filiz and provide wherein the determined pre/post method includes a combination of a base pre/post method and a derived pre/post method. Doing so would help allow for increased flexibility in deploying different pods using the base method for all pods, and a derived method for each individual pod; and/or more efficiently using computing resources.
Claim 17 is a method claim corresponding to the monitoring system Claim 8. Therefore, Claim 17 is rejected for the same reasons set forth in the rejection of Claim 8.
Regarding Claim 9, Venkatram in view of Shankar, Ghosh and Filiz teaches the monitoring system of claim 8, wherein the base pre/post method is implemented on the pod without regard to values or labels of the collected metrics (
Filiz discloses, “In some embodiments, the pod scheduler 138 refers to a pre-registered task definition in its code execution request to the serverless container management service 140. The code execution request may also include override fields that override any fields appearing in the pre-registered task definition. For example, the pod scheduler 138 may calculate the resource requirements of a pod, and specify the resource requirements in the code execution request such that any default resource specifications in the pre-registered task definition are replaced with the resource requirements included in the code execution request. The pod scheduler 138 may determine the resource requirements based on (i) the resource requirements specified in the pod specification 134A, (ii) additional information in the pod specification 134A about the execution of the pod such as whether some or all of the containers in the pod are executed in series or in parallel, and (iii) the resource requirements associated with the agents that facilitate the execution of the pod, such as, for example, the initializer, the network proxy, the node agent, and the container runtime illustrated in FIG. 1,” Col 11, Lines 4-23, and “The pre-registered task definition may include a static or default definition of the agents (e.g., KUBERNETES agents) to be executed using the compute capacity acquired by the serverless container management service 140 as part of a task, where the agents can then process the pod specification associated with the pod and launch the pod,” Col 11, Lines 33-38.
Here, Filiz teaches deployment tasks consisting of a base or default deployment task (disclosed static “pre-registered task definition”, which is implemented without regards to values or labels of collected metrics).
After the combination of Venkatram in view of Shankar and Ghosh, with Filiz, the pre/post method determined in Venkatram in view of Shankar and Ghosh now consists of a base or default pre/post method or task, as specified by Filiz.).
Venkatram in view of Shankar and Ghosh, and Filiz are both considered to be analogous to the claimed invention because they are in the same field of distributed data communication. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Venkatram in view of Shankar and Ghosh to incorporate the teachings of Filiz and provide wherein the base pre/post method is implemented on the pod without regard to values or labels of the collected metrics. Doing so would help allow for reducing complexity of the deployment using the base method for all pods.
Regarding Claim 10, Venkatram in view of Shankar, Ghosh and Filiz teaches the monitoring system of claim 8, wherein the derived pre/post method is based on the selected one or more stored metrics associated with a pod to be processed (
Filiz discloses, “In some embodiments, the pod scheduler 138 refers to a pre-registered task definition in its code execution request to the serverless container management service 140. The code execution request may also include override fields that override any fields appearing in the pre-registered task definition. For example, the pod scheduler 138 may calculate the resource requirements of a pod, and specify the resource requirements in the code execution request such that any default resource specifications in the pre-registered task definition are replaced with the resource requirements included in the code execution request. The pod scheduler 138 may determine the resource requirements based on (i) the resource requirements specified in the pod specification 134A, (ii) additional information in the pod specification 134A about the execution of the pod such as whether some or all of the containers in the pod are executed in series or in parallel, and (iii) the resource requirements associated with the agents that facilitate the execution of the pod, such as, for example, the initializer, the network proxy, the node agent, and the container runtime illustrated in FIG. 1,” Col 11, Lines 4-23, and “The pre-registered task definition may include a static or default definition of the agents (e.g., KUBERNETES agents) to be executed using the compute capacity acquired by the serverless container management service 140 as part of a task, where the agents can then process the pod specification associated with the pod and launch the pod,” Col 11, Lines 33-38.
Here, Filiz teaches deployment tasks consisting of a derived or pod-specific deployment task (the disclosed “task definition” after the default resource specifications in the original pre-registered task definition are replaced with the resource requirements calculated for the pod).
After the combination of Venkatram in view of Shankar and Ghosh, with Filiz, the pre/post method determined in Venkatram in view of Shankar and Ghosh now consists of a derived or pod-specific pre/post method or task, as specified by Filiz.).
Venkatram in view of Shankar and Ghosh, and Filiz are both considered to be analogous to the claimed invention because they are in the same field of distributed data communication. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Venkatram in view of Shankar and Ghosh to incorporate the teachings of Filiz and provide wherein the derived pre/post method is based on the selected one or more stored metrics associated with a pod to be processed. Doing so would help allow for increased flexibility in deploying different pods using a derived method for each individual pod.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Kong (US 20240037001 A1): Large-Scale K8s Cluster Monitoring Method, Apparatus, Device, and Readable Medium
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ANDREW SUN whose telephone number is (571)272-6735. The examiner can normally be reached Monday-Friday 8:00-5:00.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Aimee Li can be reached at (571) 272-4169. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/ANDREW NMN SUN/Examiner, Art Unit 2195
/Aimee Li/Supervisory Patent Examiner, Art Unit 2195
Prosecution Insights