Monitoring Data Aggregator Clause Samples

The Monitoring Data Aggregator clause establishes the process and responsibilities for collecting, consolidating, and managing monitoring data from various sources within a system or project. Typically, this clause outlines which party is responsible for aggregating data, the types of data to be included (such as performance metrics or security logs), and the frequency or method of aggregation. By centralizing monitoring information, the clause ensures that all relevant data is accessible for analysis, reporting, or compliance purposes, thereby improving oversight and enabling timely responses to issues.
Monitoring Data Aggregator. Regarding the main workflow of the Monitoring Data Aggregator (MDA), it can be subdivided into four fundamental courses of action: 1. receiving the monitoring spec from NSSO, containing critical information about which metrics will be monitored and from them which will be aggregated following a specific method (for instance, average, sum, or standard deviation), the associated business ID flow, the network slice ID, among others; 2. collecting values of the metrics from resources (at this stage, this module collects from OSM); 3. performing metric aggregations within an aggregation step; 4. pushing encrypted hashed data into a ▇▇▇▇▇ topic after signing the collected metrics. Concerning the communication paradigm, exercised by the MDA prototype, it supports simultaneously a request/response and a publish/subscribe setup. Regarding the first one, it is based on FastAPI [28], a Python framework that enables the use of a REST interface, and it will be exploited and employed by modules such as Vertical Slicer to create/enable monitoring specs with the metrics that will be monitored. It is worth mentioning that the endpoints prepared for the request/response paradigm are described on the following readme page: ▇▇▇▇▇://▇▇▇▇▇▇.▇▇▇/5GZORRO/mda/blob/main/README.md. Furthermore, the API description is available as an OpenAPI JSON file at ▇▇▇▇▇://▇▇▇▇▇▇.▇▇▇/5GZORRO/mda/blob/main/doc/openapi.json. The latter paradigm is used by MDA itself, publishing monitoring data to a ▇▇▇▇▇ topic, received on the monitoring specs. This component has been implemented using Python v3, leveraging the following tools and libraries: • FastAPI [28], for the REST interface; • ▇▇▇▇▇-python [29], for the ▇▇▇▇▇ producer; • Psycopg2 [30], the PostgreSQL driver for Python; • RSA [31], for encrypt operations; • Timeloop [32], to run periodic tasks after a certain interval; • Sqlalchemy [33], SQL toolkit, and Object Relational Mapper. The GitHub repository of the MDA module is: ▇▇▇▇▇://▇▇▇▇▇▇.▇▇▇/5GZORRO/mda. For the current version, the monitoring specification including the monitoring endpoint has been updated, where MDA fetches the metric values, and a context object containing the slice ID, the resource ID, and the parent resourceID of this last one. For more information, a wiki page linked to the GitHub repository describes these fields: ▇▇▇▇▇://▇▇▇▇▇▇.▇▇▇/5GZORRO/mda/wiki/Monitoring-Spec-Example. The module is deployed in a Kubernetes cluster as the target virtualization technology, facilit...
View Source

Related to Monitoring Data Aggregator

  • Monitoring System In each case in which the Custodian has exercised delegated authority to place Assets with a Foreign Custodian, the Custodian shall establish a system, to re-assess or re-evaluate selected Foreign Custodians, at least annually in accordance with Rule 17f-5(c)(3).

  • System Logging The system must maintain an automated audit trail which can 20 identify the user or system process which initiates a request for PHI COUNTY discloses to 21 CONTRACTOR or CONTRACTOR creates, receives, maintains, or transmits on behalf of COUNTY, 22 or which alters such PHI. The audit trail must be date and time stamped, must log both successful and 23 failed accesses, must be read only, and must be restricted to authorized users. If such PHI is stored in a 24 database, database logging functionality must be enabled. Audit trail data must be archived for at least 3 25 years after occurrence.

  • Contractor Sales Reporting Vendor Management Fee Contractor Reports Contract Sales Reporting. Contractor shall report total Contract sales quarterly for this Cooperative Purchasing Agreement to Enterprise Services, as set forth below. Contract Sales Reporting System. Contractor shall report quarterly Contract sales in Enterprise Services’ Contract Sales Reporting System. Enterprise Services shall provide Contractor with a login password and a vendor number. The password and vendor number shall be provided to the Sales Reporting Representative(s) listed on Contractor’s Bidder Profile. Data. Each sales report must identify every authorized Purchaser by name as it is known to Enterprise Services and its total combined sales amount invoiced during the reporting period (i.e., sales of an entire agency or political subdivision, not its individual subsections). The “Miscellaneous” option may be used only with prior approval by Enterprise Services. Upon request, Contractor shall provide contact information for all authorized Purchasers specified herein during the term of the Contract. If there are no Contract sales during the reporting period, Contractor must report zero sales. Due dates for Contract Sales Reporting. Quarterly Contract Sales Reports must be submitted electronically by the following deadlines for all Contract sales invoiced during the applicable calendar quarter: Vendor Management Fee. Contractor shall pay to Enterprise Services a vendor management fee (“VMF”) of 1.25 percent on the purchase price for all Cooperative Purchasing Agreement sales (the purchase price is the total invoice price less applicable sales tax) under this Cooperative Purchasing Agreement. The sum owed by Contractor to Enterprise Services as a result of the VMF is calculated as follows: Amount owed to Enterprise Services = Total Contract sales invoiced (not including sales tax) x .0125. The VMF must be rolled into Contractor’s current pricing. The VMF must not be shown as a separate line item on any invoice unless specifically requested and approved by Enterprise Services. Enterprise Services shall invoice Contractor quarterly based on Contract sales reported by Contractor. Contractor is not to remit payment until Contractor receives an invoice from Enterprise Services. Payments must be received within thirty (30) calendar days of the invoice issue date from Enterprise Services. Contractor’s VMF payment to Enterprise Services must reference the invoice number. Contractor’s VMF payment to Enterprise Services must reference this Contract number, the year and quarter for which the VMF is being remitted, and Contractor’s name as set forth in this Contract, if not already included on the face of the check. Contractor’s failure to report accurate total net Contract sales, to submit a timely Contract sales report, or to remit timely payment of the VMF to Enterprise Services, shall be cause for Enterprise Services, at its discretion, to suspend Contractor or terminate this Contract or exercise remedies provided by law. Without limiting any other available remedies, the parties agree that Contractor’s failure to remit to Enterprise Services timely payment of the VMF shall obligate Contractor to pay to Enterprise Services, to offset the administrative and transaction costs incurred by the State to identify, process, and collect such sums, the sum of $200.00 or twenty-five percent (25%) of the outstanding amount, whichever is greater, or the maximum allowed by law, if less. Enterprise Services reserves the right, upon thirty (30) calendar days advance written notice, to increase, reduce, or eliminate the VMF for subsequent purchases, and reserves the right to renegotiate Contract pricing with Contractor when any subsequent adjustment of the VMF might justify a change in pricing. Annual Contract Sales Report. Contractor shall provide to Enterprise Services a detailed annual Contract sales report. Such report shall include, at a minimum, the following: The Goods and/or Services sold and provided (including, as applicable, category or another identifier); Services purchased by Purchaser; and Contract price. This report must be provided in an electronic format that can be read by Microsoft (MS) Excel. Such report is due within thirty (30) calendar days of the annual anniversary of the effective date of this Contract.

  • Monitoring Services IDT staff shall, using methods that include face-to-face and other contacts with the member, monitor the services a member receives. This monitoring shall ensure that: a. The member receives the services and supports authorized, arranged for and coordinated by the IDT staff; b. The services and supports identified in the MCP as being provided by natural and community supports are being provided; and c. The quality of the services and supports received is adequate and still necessary to continue to meet the needs and preferences of the member and support the member’s outcomes identified in the MCP.

  • STATEWIDE CONTRACT MANAGEMENT SYSTEM If the maximum amount payable to Contractor under this Contract is $100,000 or greater, either on the Effective Date or at any time thereafter, this section shall apply. Contractor agrees to be governed by and comply with the provisions of §§▇▇-▇▇▇-▇▇▇, ▇▇-▇▇▇-▇▇▇, ▇▇-▇▇▇-▇▇▇, and ▇▇- ▇▇▇-▇▇▇, C.R.S. regarding the monitoring of vendor performance and the reporting of contract information in the State’s contract management system (“Contract Management System” or “CMS”). Contractor’s performance shall be subject to evaluation and review in accordance with the terms and conditions of this Contract, Colorado statutes governing CMS, and State Fiscal Rules and State Controller policies.