Difference between revisions of "Ceilometer/blueprints/pollster-swift"
Line 192: | Line 192: | ||
For polling Swift, there exists 2 way: | For polling Swift, there exists 2 way: | ||
+ | |||
1. Go through swift-proxy as an user with [[ResellerAdmin]] role on one of this tenant, using this tenant to get a token | 1. Go through swift-proxy as an user with [[ResellerAdmin]] role on one of this tenant, using this tenant to get a token | ||
+ | |||
2. Use the ring to determine the right swift-<type>-server and request information from it directly. The swift-account-server can provides number and size of objects stored in all containers, and the number of containers, and the list of container. The swift-container-server can provides number number of objects and size of each container. | 2. Use the ring to determine the right swift-<type>-server and request information from it directly. The swift-account-server can provides number and size of objects stored in all containers, and the number of containers, and the list of container. The swift-container-server can provides number number of objects and size of each container. | ||
Revision as of 11:46, 22 November 2012
pollster-swift blueprint
Use Cases
- Provider wants to retrieve data about swift usage to bill his customers
- Customer wants to monitor his usage of swift
Proposed implementation
The following is a first list of meters that needs to be collected in order to allow billing systems to perform their tasks on swift. This list must be expandable over time and each administrator must have the possibility to enable or disable each meter based on his local needs
Meter name | Priority | Resource ID | Volume unit | Payload | Type | |
o1 | storage.objects | must | swift account id | bytes | Gauge | |
o2 | storage.objects.size | must | swift account id | bytes | Gauge | |
o3 | storage.objects.containers | must | swift account id | number of containers | Number of containers | Gauge |
o4 | storage.objects | may | container name | container | Gauge | |
o5 | storage.objects.size | may | container name | container | Gauge | |
o6 | storage.objects.upload.internal | may | swift account id | number of req | Delta | |
o7 | storage.objects.download.internal | may | swift account id | number of req | Delta | |
o8 | storage.objects.update.internal | may | swift account id | number of req | Delta | |
o9 | storage.objects.delete.internal | may | swift account id | number of req | Delta | |
o10 | storage.objects.upload.size.internal | may | swift account id | bytes | Delta | |
o11 | storage.objects.download.size.internal | may | swift account id | bytes | Delta | |
o12 | storage.objects.update.size.internal | may | swift account id | bytes | Delta | |
o13 | storage.objects.delete.size.internal | may | swift account id | bytes | Delta | |
o14 | storage.objects.upload.external | may | swift account id | number of req | Delta | |
o15 | storage.objects.download.external | may | swift account id | number of req | Delta | |
o16 | storage.objects.update.external | may | swift account id | number of req | Delta | |
o17 | storage.objects.delete.external | may | swift account id | number of req | Delta | |
o18 | storage.objects.upload.size.external | may | swift account id | bytes | Delta | |
o19 | storage.objects.download.size.external | may | swift account id | bytes | Delta | |
o20 | storage.objects.update.size.external | may | swift account id | bytes | Delta | |
o21 | storage.objects.delete.size.external | may | swift account id | bytes | Delta |
The counters o1 to o5 must be implemented through polling of Swift.
For polling Swift, there exists 2 way:
1. Go through swift-proxy as an user with ResellerAdmin role on one of this tenant, using this tenant to get a token
2. Use the ring to determine the right swift-<type>-server and request information from it directly. The swift-account-server can provides number and size of objects stored in all containers, and the number of containers, and the list of container. The swift-container-server can provides number number of objects and size of each container.
Option 1 should be simpler and cleaner in a first time, but puts more load on Keystone. Option 2 could be preferred, if implemented, via an option.
The counters o6 to o21 should be implemented via a Swift middleware counting requests and their size and publishing counters regularly.
To distinguish network, it is suggested that we start this implementation by using a configuration file listing internal networks, which by default should list A, B and C private network class (RFC 1918).