Difference between revisions of "Synaps/Architecture"
Line 5: | Line 5: | ||
== Synaps Architecture == | == Synaps Architecture == | ||
− | Synaps API is frontend of the system. It uses RabbitMQ for asynchronous processing | + | Synaps API is frontend of the system. It uses RabbitMQ for asynchronous processing. The messages are passed to Synaps Strom. |
− | Synaps Storm is a topology implementation which is aimed to run on the Twitter Storm, real-time distributed stream processing system. Synaps Storm is based on the message driven architecture. Most of the messages are came from RabbitMQ. It notifies using Notification Queue | + | Synaps Storm is a topology implementation which is aimed to run on the Twitter Storm, real-time distributed stream processing system. Synaps Storm is based on the message driven architecture. Most of the messages are came from RabbitMQ. It notifies using Notification Queue so that other notification system can interoperate with the queue. |
− | Both Synaps API and Storm | + | Both Synaps API and Synaps Storm are use Cassandra no-sql database to store persistent data. |
Following is Architecture of Synaps. | Following is Architecture of Synaps. | ||
Line 60: | Line 60: | ||
== Synaps Storm Subsystem description == | == Synaps Storm Subsystem description == | ||
− | |||
− | |||
Following is simple diagram of Synaps Storm topology. | Following is simple diagram of Synaps Storm topology. | ||
Line 69: | Line 67: | ||
=== [[PutMetricData]] message processing === | === [[PutMetricData]] message processing === | ||
− | This | + | This is the most important part of Synaps. When the Put''''''Metric''''''Data message is received via message queue, it reads its in-memory sliding windows or database to aggregate its datapoints and evalutate status of its alarms. If the status is changed, it sends action message to notification queue. |
[[Image:Synaps$$Architecture$SynapsStorm-[[PutMetricData]].jpg]] | [[Image:Synaps$$Architecture$SynapsStorm-[[PutMetricData]].jpg]] | ||
Line 75: | Line 73: | ||
=== [[PutMetricAlarm]] message processing === | === [[PutMetricAlarm]] message processing === | ||
− | When the | + | When the Put''''''Metric''''''Alarm message is received via message queue, it find its metric and update its in-memory alarm data and update it into database. |
[[Image:Synaps$$Architecture$SynapsStormPeriodicMonitoring.jpg]] | [[Image:Synaps$$Architecture$SynapsStormPeriodicMonitoring.jpg]] | ||
Line 81: | Line 79: | ||
=== [[PeriodicMonitoring]] message processing === | === [[PeriodicMonitoring]] message processing === | ||
− | ‘check_spout’ generates | + | ‘check_spout’ generates Periodic''''''Monitoring message every 1 minute. When the message is generated, it checks their alarms which are not evaluated recently by Put''''''Metric''''''Data message. |
[[Image:Synaps$$Architecture$SynapsStormPutMetricAlarm.jpg]] | [[Image:Synaps$$Architecture$SynapsStormPutMetricAlarm.jpg]] |
Revision as of 12:51, 13 October 2012
<<TableOfContents()>>
Note: This page is to share architectural information of Synaps temporarily. When the Synaps is open sourced, this page will be moved into its documentation page.
Synaps Architecture
Synaps API is frontend of the system. It uses RabbitMQ for asynchronous processing. The messages are passed to Synaps Strom.
Synaps Storm is a topology implementation which is aimed to run on the Twitter Storm, real-time distributed stream processing system. Synaps Storm is based on the message driven architecture. Most of the messages are came from RabbitMQ. It notifies using Notification Queue so that other notification system can interoperate with the queue.
Both Synaps API and Synaps Storm are use Cassandra no-sql database to store persistent data.
Following is Architecture of Synaps.
File:Synaps$$Architecture$SynapsSystemOverview.jpg
following is an example of integration.
Externally, Synaps interoperates with agents which inputs metric data periodically, such as VMMON which can get information from VM Hyperisor with libvirt library and Nova API, and custom agent also.
Synaps Notification is a program to send E-mail or SMS.
File:Synaps$$Architecture$IntegratedSystemOverview.jpg
following is an example of deployment.
File:Synaps$$Architecture$SynapsDeployment.jpg
Synaps API Subsystem description
Synaps API is WSGI based Web Server which provides AWS CloudWatch compatible API.
Asynchrous request processing
Requests below are processed asynchrously.
- Delete'Alarms
- Put'Metric'Alarm
- Put'Metric'Data
For example,
File:Synaps$$Architecture$SynapsAPI-PutMetricData.jpg
Synchrous request processing
Requests below are processed synchrously.
- Describe'Alarm'History
- Describe'Alarms
- Describe'Alarms'For'Metric
- Disable'Alarm'Actions
- Enable'Alarm'Actions
- Get'Metric'Statistics
- List'Metrics
- Set'Alarm'State
For example,
File:Synaps$$Architecture$SynapsAPI-GetMetricStatistics.jpg
Synaps Storm Subsystem description
Following is simple diagram of Synaps Storm topology.
File:Synaps$$Architecture$SynapsStorm-Topology.jpg
PutMetricData message processing
This is the most important part of Synaps. When the Put'Metric'Data message is received via message queue, it reads its in-memory sliding windows or database to aggregate its datapoints and evalutate status of its alarms. If the status is changed, it sends action message to notification queue.
[[Image:Synaps$$Architecture$SynapsStorm-PutMetricData.jpg]]
PutMetricAlarm message processing
When the Put'Metric'Alarm message is received via message queue, it find its metric and update its in-memory alarm data and update it into database.
File:Synaps$$Architecture$SynapsStormPeriodicMonitoring.jpg
PeriodicMonitoring message processing
‘check_spout’ generates Periodic'Monitoring message every 1 minute. When the message is generated, it checks their alarms which are not evaluated recently by Put'Metric'Data message.