Monitoring¶
Data for monitoring¶
Comparison of data formats for Clickhouse and InfluxDB:
InfluxDB: Each event is presented as a “point” in a time series. The structure of a point includes:
series name
start event time
tags, indexed data in storage, dictionary: keys - string tag names, values - string, integer, float
fields, non indexed data in storage, dictionary: keys - string tag names, values - string, integer, float
Clickhouse: In Clickhouse, the data structure resembles that of a traditional SQL table. Each event is represented as a record, where:
The `time` field contains the record’s creation timestamp;
The `data` field contains a JSON object with all the information that would otherwise be distributed across tags and fields in InfluxDB.
Important: In Clickhouse, there is no differentiation between “tags” and “fields”—all data is consolidated into a single JSON object within the data field.
Monitoring series¶
The structure and the meaning of each monitoring series remain consistent. However, for Clickhouse, data from tags and fields are merged into a single JSON object under the data field. Below are examples for each series:
Requests series.
Triggered on every request. Each point contains a data about corresponding request (execution time and etc).
InfluxDB:
Requests series tags¶ tag name
description
service
“luna-python-matcher” or “luna-matcher-proxy”
route
concatenation of a request method and a request resource (e.g. POST:/matcher/faces)
status_code
HTTP status code of the response
Requests series fields¶ fields
description
request_id
request ID
execution_time
request execution time
ClickHouse JSON `data` field Example:
{ "service": "luna-python-matcher", "route": "POST:/matcher/faces", "status_code": 200, "request_id": "1536751345,6a5c2191-3e9b-f5a4-fc45-3abf43625c5f", "execution_time": 120 }
‘matching_process’ series.
Triggered on every match action. Each point contains data about matching performance.
InfluxDB:
matching_process series tags¶ tag name
description
service
“luna-python-matcher” or “luna-matcher-proxy”
matching_type
type of matching
matching_candidate
candidate for matching (events_candidates, faces_candidates, attributes_candidates)
matching_process series additional tags¶ tag name
resource
description
service
matcher
match_face
preferred matcher
luna-matcher-proxy
matcher
match_body
preferred matcher
luna-matcher-proxy
matching_process series fields¶ fields
description
request_id
request id
matching_time
time taken to perform matching
matching_process series additional fields¶ fields
matching_type
description
service
list_batch_size
match_face
list count used for cached list matching
luna-python-matcher
load_descriptor_time
match_body
time taken to load descriptor before matching *
luna-python-matcher
load_descriptor_time
match_face
time taken to load descriptor before matching *
luna-python-matcher
enrich_match_result_time
match_face
time taken to enrich cached list matching result with data
luna-python-matcher
enrich_match_result_time
match_face
time taken to enrich matching result with data
luna-matcher-proxy
enrich_match_result_time
match_body
time taken to enrich matching result with data
luna-matcher-proxy
ClickHouse JSON `data` field Example:
{ "service": "luna-python-matcher", "matching_type": "face_matching", "matching_candidate": "faces_candidates", "matcher": "match_face", "request_id": "1536751345,6a5c2191-3e9b-f5a4-fc45-3abf43625c5f", "matching_time": 20, "list_batch_size": 1000, "load_descriptor_time": 15, "enrich_match_result_time": 5 }
* For events reference showed only if events_ids or external_ids not specified in candidates filters
‘Errors’ series.
Triggered on failed request. Each point contains error_code of luna error.
InfluxDB:
Errors series tags¶ tag name
description
service
“luna_python_matcher” or “luna-matcher-proxy”
route
concatenation of a request method and a request resource (POST:/matcher)
status_code
http status code of response
error_code
luna error code
Errors series fields¶ fields
description
request_id
request id
ClickHouse JSON `data` field Example:
{ "service": "luna-python-matcher", "route": "POST:/sdk", "status_code": 400, "error_code": 13037, "request_id": "1536751345,6a5c2191-3e9b-f5a4-fc45-3abf43625c5f", }
Every handler can add additional tags or fields.
Database¶
You can refer to documentation for influx database and clickhouse database to compare the databases and choose what benefit your needs more. Note that clickhouse might be the better choice for aggregation You can setup your database credentials in configuration file in section “monitoring”.
Classes¶
Module contains points for monitoring.
- class luna_python_matcher.crutches_on_wheels.cow.monitoring.points.BaseMonitoringPoint(eventTime)[source]¶
Abstract class for points
- eventTime¶
event time as timestamp
- Type:
float
- abstract property fields: Dict[str, int | float | str]¶
Get fields from point. We supposed that fields are not indexing data
- Returns:
dict with fields.
- abstract property tags: Dict[str, int | float | str]¶
Get tags from point. We supposed that tags are indexing data
- Returns:
dict with tags.
- class luna_python_matcher.crutches_on_wheels.cow.monitoring.points.BaseRequestMonitoringPoint(requestId, resource, method, requestTime, service, statusCode)[source]¶
Base class for point which is associated with requests.
- requestId¶
request id
- Type:
str
- route¶
concatenation of a request method and a request resource
- Type:
str
- service¶
service name
- Type:
str
- statusCode¶
status code of a request response.
- Type:
int
- property fields: Dict[str, int | float | str]¶
Get fields
- Returns:
“request_id”
- Return type:
dict with following keys
- property tags: Dict[str, int | float | str]¶
Get tags
- Returns:
“route”, “service”, “status_code”
- Return type:
dict with following keys
- class luna_python_matcher.crutches_on_wheels.cow.monitoring.points.DataForMonitoring(tags=<factory>, fields=<factory>)[source]¶
Class fo storing an additional data for monitoring.
- class luna_python_matcher.crutches_on_wheels.cow.monitoring.points.InfluxFormatter[source]¶
Format any point filed into inline format
- class luna_python_matcher.crutches_on_wheels.cow.monitoring.points.MonitoringPointInfluxFormatBuilder(name, bases, namespace, /, **kwargs)[source]¶
Complement point class with explicit fields formatting function for the sake of better performance
To perform type format building target class must have ‘fields’ property return value annotated with TypedDict.
Target class might be configured via ‘Config’ class. Available options:
extraFields: whether class should handle additional fields or not
>>> from typing import TypedDict >>> >>> class MonitoringFields(TypedDict): ... field1: str ... field2: int ... field3: float ... field4: bool >>> >>> class BasePoint(BaseMonitoringPoint, metaclass=MonitoringPointInfluxFormatBuilder): ... ... def __init__(self, fields: dict): ... self._fields = fields ... ... @property ... def tags(self): ... return {} ... ... @property ... def fields(self) -> MonitoringFields: ... return self._fields ... >>> class TestPointNoExtra(BasePoint): ... ... class Config: ... extraFields = False ... >>> class TestPointWithExtra(BasePoint): ... class Config: ... extraFields = True >>> >>> >>> point1 = TestPointNoExtra({"field1": "data", "field2": 1, "field3": 1.0, "field4": False}) >>> point2 = TestPointWithExtra({"field1": "data", "field2": 1, "field3": 1.0, "field4": False, "extra": True}) >>> print(point1.convertFieldsToInfluxLineProtocol()) field1="data",field2=1i,field3=1.000000,field4=False >>> print(point2.convertFieldsToInfluxLineProtocol()) field1="data",field2=1i,field3=1.000000,field4=False,extra=True
- classmethod buildInfluxFormats(annotations, extraFields)[source]¶
Build map with influx formats for corresponding fields
- Return type:
dict
- Parameters:
annotations (dict) – point fields type annotations
extraFields (bool) – whether point uses extra fields or not
- Returns:
dict of fields with their format
- static convertFieldsToInfluxLineProtocolNoExtra(point)[source]¶
Convert point fields into influx line protocol format without extra fields
- class luna_python_matcher.crutches_on_wheels.cow.monitoring.points.RequestErrorMonitoringPoint(requestId, resource, method, errorCode, service, requestTime, statusCode, additionalTags=None, additionalFields=None)[source]¶
Request monitoring point is suspended for monitoring requests errors (error codes)
- errorCode¶
error code
- Type:
int
- additionalTags¶
additional tags which was specified for the request
- Type:
dict
- additionalFields¶
additional fields which was specified for the request
- Type:
dict
- property fields: Dict[str, int | float | str]¶
Get fields.
- Returns:
dict with base fields and additional tags
-
series:
str
= 'errors'¶ series “errors”
- property tags: Dict[str, int | float | str]¶
Get tags.
- Returns:
dict with base tags, “error_code” and additional tags
- class luna_python_matcher.crutches_on_wheels.cow.monitoring.points.RequestMonitoringPoint(requestId, resource, method, executionTime, requestTime, service, statusCode, additionalTags=None, additionalFields=None)[source]¶
Request monitoring point is suspended for monitoring all requests and measure a request time etc.
- executionTime¶
execution time
- Type:
float
- additionalTags¶
additional tags which was specified for the request
- Type:
dict
- additionalFields¶
additional fields which was specified for the request
- Type:
dict
- property fields: Dict[str, int | float | str]¶
Get fields.
- Returns:
dict with base fields, “execution_time” and additional tags
-
series:
str
= 'requests'¶ series “request”
- property tags: Dict[str, int | float | str]¶
Get tags.
- Returns:
dict with base tags and additional tags
- luna_python_matcher.crutches_on_wheels.cow.monitoring.points.getRoute(resource, method)[source]¶
- Return type:
str
Get a request route, concatenation of a request method and a request resource :param resource: resource :param method: method
- Returns:
{resource}”
- Return type:
“{method}
- luna_python_matcher.crutches_on_wheels.cow.monitoring.points.monitorTime(monitoringData, fieldName)[source]¶
Context manager for timing execution time.
- Parameters:
monitoringData – container for saving result
fieldName – field name
Module implement base class for monitoring
- class luna_python_matcher.crutches_on_wheels.cow.monitoring.manager.LunaMonitoringManager(settings, name, pluginManager)[source]¶
Monitoring manager. Sends data to the monitoring storage and monitoring plugins. .. attribute:: settings
monitoring storage settings
- class luna_python_matcher.crutches_on_wheels.cow.monitoring.manager.MonitoringSettings(*args, **kwargs)[source]¶
Monitoring settings protocol
Module contains classes for sending a data to an influx monitoring.
- class luna_python_matcher.crutches_on_wheels.cow.monitoring.influx_adapter.InfluxMonitoringAdapter(settings, flushingPeriod)[source]¶
Influx 2.x adaptor. Suspended to send points to an influxdb
- bucket¶
influx bucket name
- Type:
str
- addPointsToBuffer(points)[source]¶
Add points to buffer.
- Return type:
None
- Parameters:
points – points
- static convertFieldsToInfluxLineProtocol(fields)[source]¶
Convert field value to influx line protocol format
- Return type:
str
- Parameters:
fields – dict with values to convert
- Returns:
line protocol string