ºÝºÝߣ

Editor's Notes

1. This is a sample Title ºÝºÝߣ with Picture ideal for including a dark picture with a brief title and subtitle. A selection of pre-approved title slides are available in the HPE Title ºÝºÝߣ Library. The location of the library will be communicated later. To insert a slide with a different picture from the HPE Title ºÝºÝߣ Library: Open the file HPE_16x9_Title_ºÝºÝߣ_Library.pptx From the ºÝºÝߣ thumbnails pane, select the slide with the picture you would like to use in your presentation and click Copy (Ctrl+C) Open a copy of the new HPE 16x9 template (Standard or Events) or your current presentation In the ºÝºÝߣ thumbnails pane, click Paste (Ctrl+V) A Paste Options clipboard icon will appear. Click the icon and select Keep Source Formatting. (Ctrl+K)
2. Monasca Session ??? ??? ?? ??? ?? ?????. Monasca ? ???, ? Architecture, ??? Monasca ? ???? ?? Helion OpenStack ? Architecture ?, Helion OpenStack ??? Monitoring ?? ??? monitoring console ? ?? ?? ??? ?????.
3. Monitoring solutions have been around for decades, but in many respects they fail to address the requirements of monitoring large-scale public and private clouds. Traditionally, performance, scalability and data retention have been limited to hundreds of systems. In a large-scale cloud service thousands of physical servers and hundreds of thousands of virtual machines (VMs) and containers need to be monitored, resulting in hundreds of terabytes of monitoring data. The original monitoring source data needs to be stored in an on-line, queryable, lossless form at data retention periods greater than thirteen months. Such long data retention periods are necessary for SLAs, business continuity, and analytics. Inventory elasticity is important because cloud infrastructure is constantly evolving with VMs and services continually being created and destroyed monitoring systems must be dynamic enough to understand the difference between a VM be purposely destroyed versus a VM that is in a failed state. Self-service models that empower teams to easily add new resources and monitor them independently of the monitoring teams involvement is necessary. Most solutions assume a static infrastructure that requires new services to be registered with the server prior to being monitored. This results in the monitoring team/server being the bottleneck. Extensibility is critical, but is often limited. Run-time configurability is necessary to be able to tune the system over time by allowing alarms to be dynamically adjusted, which in many systems is not supported. Generalization of alarm definitions/templates is necessary to describe and manage alarms in a one-to-many relationship in order to avoid having to manually declare each alarm even though they may share many common attributes and differ in only one, such as hostname. Spammy alerts and alert fatigue is a common short-coming of every thresholding system. Many operations teams receive thousands of alerts on a weekly basis. Improvements in run-time configurability and generalizing alarm definitions can help to address spammy alerts. Anomaly detection based on non-parametric statistics and machine learning is required as a more fundamental change.
4. Monasca is a highly performant, scalable, fault-tolerant and extensible micro-services messages bus based architecture. It uses a REST API for high-speed metrics processing and querying and has a streaming alarm engine and notification engine. All of the major components are linked using?Kafka. Every component in the system is built with High Availability (HA) in mind and can be scaled either horizontally or vertically to allow for monitoring of very large?systems. The?Monasca API?is the gateway for all interaction with Monasca. In a typical scenario?metrics?are collected by the?Monasca Agent?running on a system and sent to the Monasca API. The API then published the metrics to the Kafka queue. From here the?Monasca Persister?(metric ? Alarm ??? Kafka ?? Read ??, Metric DB ? ????? ??), consumes metrics and writes them to ourMetrics database. The?Monasca Threshold Engine?also consumes the metrics and uses them to evaluate?alarms. At this point the metrics are in our system and can be queried using the Monasca API, either directly or through one of our other components, such as the Horizon plugin or the?Monasca CLI. When the Threshold Engine evaluates the metrics against the alarms it can create alarm state transition events. These are published back to Kafka and are read by both the persister and?Notification Engine. The Persister writes the alarm transitions to the DB for future retrieval. The notification engine will send a notification of the configured type for appropriate state transitions. In addition to the components discussed above we also have a configuration database used for storing information such as alarm definitions and notification methods. This database can be either MySQL or PostgreSQL.
5. Advantages of message bus architecture Enables a micro-services foundation Load-balancing, scalability, system maintenance (new deploys) Handle different loads Extensibility: Easily add new components/services: HP Operations Manager i (OMi) BSM Connector for HP Helion Monasca Consumes alarm state transition messages from Kafka Multi-site replication of data And there is more... Pagination (? ?? ?? ??? ??) is supported via offset and limit query parameters The Agent Forwarder buffers metrics for a short time to increase the size of the http request body (number of metrics) sent to the Monasca API. The Monasca API caches auth tokens in-memory to reduce the round-trip authorization requests to Keystone If network connectivity between the Agent and API occurs the Agent will buffer metrics and send when connectivity is restored Metrics are submitted using a ¡°agent¡± role, which only allows metrics to be POST¡¯d to the metrics endpoint Multi-site replication for metrics can be done by running two persisters simultaneously, sending to different metrics databases System can handle failure of any component or node
6. Monasca-statsd daemon : statsd engine capable of handling dimensions associated with metrics submitted by a client that supports them. Also supports metrics from the standard statsd client. (udp/8125)
7. The Helion platform provides a turnkey monitoring system that is ready to use immediately after cloud installation. This saves operators time and money by eliminating the need for a separate monitoring infrastructure and from having to manage complex network configurations. All aspects of the monitoring system are certified with HP Linux for Helion and Helion OpenStack and they are supported by HP. This saves operators set up time and lowers costs because operators do not need to stand up separate infrastructure or certify additional-plug ins with the Helion environment. HP Helion OpenStack monitoring ships with many integration points and can easily snap into existing data center management tooling and infrastructure. It ships with supported connectors with HPSW OMi and technical preview connectors for Ops A, Splunk, and ArcSight. The Helion OpenStack 2.0 documentation contains documented triage and resolution steps for common issues. This knowledge is based on years of OpenStack software operations experience from operating HP¡¯s public cloud services. Reduces time to production Simplifies start up experaince
8. We are monitoring all of the OpenStack core service availability and performance metrics. We are collecting log events from all OpenStack core services and most of the shared services. For a complete listing of alarms and monitored services please see the Helion documentation Monasca/alarms.