1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
|
CloudKitty Concepts
======================
This page provides the definitions for the concepts used in CloudKitty.
It is recommended that you get familiar with them.
Rating
------
It is the process of assigning a `value` to the consumption of computing
resources. CloudKitty uses the concepts of services, which are rated.
Therefore, one can configure services to be collected/monitored, and
then through its processes, we can assign monetary values to the
service consumption.
The `value` assigned can be used to represent a monetary value in any
currency. However, CloudKitty has no native module to execute conversions
and apply any currency rate. The process to map/link a `value` to a real
monetary charge is up to operators when configuring CloudKitty.
Modules
-------
Modules define the rating processes that are enabled. To get to know more about
the rating modules, one should check `rating modules`_ .
.. _rating modules: ../user/rating/index.html
Services
--------
Services define the metrics that are collected in a storage backend, and that
are then rated by CloudKitty. Services need to be defined via API to be
processed later by the rating modules, and configured in the collectors to be
captured. Services are configured to be collected in the ``metrics.yml`` file.
More information about service creation can be found at the `service
configuration page`_.
.. _service configuration page: ../admin/configuration/configuration.html
Groups
------
Groups define sets of services that can be manipulated together. Groups are
directly linked to rating rules, and not to services or fields.
Therefore, if we want to group a set of rules to list them together
or delete them, we can create a group and add them to the group, but
in the end the resources are going to be charged based on the
services, fields and rating rules.
Fields
------
Fields define the attributes that are retrieved together with the service
collection that can be used to activate a rating rule.
PyScripts
---------
It is an alternative method of writing rating rule. When writing a PyScript,
one will be able to handle the complete processing of the rating.
Therefore, there is no need to create services, fields, and groups
in CloudKitty. The PyScript logic should take care of all that.
Rating rules
------------
Rating rules are the expressions used to create a charge (assign a value to
a computing resource consumption). Rating rules can be created with
PyScripts or with the use of fields, services and groups with hashmap
rating rules. You can define a ``start`` and ``end`` dates to the rating rules
(PyScripts and hashmap mappings), which define the period they will be valid
and applied in the rating process. If neither ``start`` or ``end`` dates are
defined, they will be set as the rule's creation date and ``None``
respectively. A ``None`` ``end`` date means the rating rule will last
indefinitely. The ``start`` date cannot be set as a past date, if you really
need to do it, you can force it using a ``force`` flag when creating the rule.
Once the rule starts running (rule's ``start`` > current date), you will not be
able to update the rule anymore, in this case, if you need to change the
rule's value, you will need to delete it and create it again with the new
value.
If we have a hashmap mapping configuration for a service and another
hashmap map configuration for a field that belongs to the same service,
the user is going to be charged twice, one for service and another for
the field that activated a rating rule that is linked to the service.
Rating type
-----------
Rating type is the expression used to determine a service definition in the
collection backend. For instance, one can use the following syntax
in the ``metrics.yml`` file. The entry
``dynamic_pollster.compute.services.instance.status`` is the definition
for rating types. In the example shown here, there are two rating
types being defined, one called ``instance-usage-hours`` and the other
called ``instance-operating-system-license``. The rating types are
configured in CloudKitty API as services. If they are not configured,
they will not be rated by rating rules defined with hashmap. Therefore,
they would be collected, and persisted with value (price) as zero.
.. code-block:: yaml
metrics:
dynamic_pollster.compute.services.instance.status:
- unit: instance
alt_name: instance-usage-hours
description: "compute"
groupby:
- id
- display_name
- flavor_id
- flavor_name
- user_id
- project_id
- revision_start
- availability_zone
metadata:
- image_ref
- flavor_vcpus
- flavor_ram
- operating_system_name
- operating_system_distro
- operating_system_type
- operating_system_version
- mssql_version
extra_args:
aggregation_method: max
resource_type: instance
use_all_resource_revisions: false
- unit: license-hours
alt_name: "instance-operating-system-license"
description: "license"
groupby:
- id
- display_name
- flavor_id
- flavor_name
- user_id
- project_id
- revision_start
- availability_zone
- operating_system_distro
- operating_system_name
metadata:
- image_ref
- flavor_vcpus
- flavor_ram
- operating_system_type
- operating_system_version
extra_args:
aggregation_method: max
resource_type: instance
use_all_resource_revisions: false
|
