Komponenten

Wie in im Abschnitt Architektur beschrieben, besteht eine Microservice aus verschiedenen Komponenten. In diesem Abschnitt sollen diese Komponenten näher in ihrer Funktion und Aufgaben beschrieben werden. Dabei werden insbesondere die Schnittstellen beschrieben, die für die Implementation einer Domain genutzt werden können bzw. müssen.

Share

Logging

Tediga provides logging capabilities to applications to ensure that the data is logged in a consistent manner, which is a prerequisite for later evaluation.

Tedega uses Fluentd Logs for centralized logging. This collects all logs into a uniform form, and stores them in different backends as needed. From there, the logs can then be analyzed using tools such as Elasticsearch or Hadop.

The following categories are logged:

• Requests. All requests to the application are logged. The Includes the url, method (GET, POST, PUT ...) and possible parameters. They are marked in the category REQUEST.
• Processing time. Every request to a service will have the response time logged in milliseconds that a service needs to answer a request. The time adds up to the necessary steps for the answering be carried out. So also possible queries to others services. The category for the processing time is PROCTIME
• Status response. Each request logs the HTTP status of it answer. The category for the status is RETURNCODE
• Reachability. Periodically, each service is will check its connecivity to other hosts and services. Accessibility messages have the category PING.
• Utilization RAM, CPU, memory. We pick up at regular intervals information about the load of RAM, load and storage space in order to detect bottlenecks early. The corresponding category is SYSTEM.
• More information. In addition to the information described above, of course also any other information can be logged as needed. These should then be categorized with CUSTOM.

So that the messages are systematically evaluated in a central location all messages must be in a predefined format. Each Log message has a tag which Fluentd uses to route log messages can be used:

<HOST>. <SERVICE> [. <CONTAINER>]

The actual log message is saved in JSON format:

{
    "type": "INFO",
    "category": null,
    "correlation_id": null,
    "extra_key_depending_on_category": "value"
}

The following table provides information about the most important tags in log messages.

Section	Description
HOST	Name of the computer.
CONTAINER	Name Containers.
SERVICE	Name of the service
CATEGORY	Type of log message.
CORRELATION_ID	When a request first encounters a service, it generates a unique UUID, which is used in all subsequent queries to track related messages across different services. This information is optional because not all messages are generated in services or require such a UUID.
LEVEL	Indicates whether the message is an ERROR, a WARNING, an INFO, or a DEBUG output. The default for a message is INFO.

class tedega_share.logger.Logger(logger, service)

Wrapper around the Python logger to ensure a specific log format.

debug(message, category=None, correlation_id=None)

Write a debug message.

error(message, category=None, correlation_id=None)

Write a error message.

info(message, category=None, correlation_id=None)

Write a info message.

warning(message, category=None, correlation_id=None)

Write a warning message.

tedega_share.logger.init_logger(service, host='fluentd', port=24224)

Will initialise a global Logger instance to log to fluentd.

Tag:String used as tag for fluentd log routing. Host:Host where the fluentd is listening Port:Port where the fluentd is listening

tedega_share.logger.get_logger()

Will return the global Logger instance. Will raise an exception if the Logger is not initialised.

Rückgabe:Logger instance

tedega_share.logger.log_proctime(func)

Decorator to log the processing time of the decorated method.

tedega_share.logger.monitor_connectivity(hosts, interval=60)

Continually check and log the connection to the list of given hosts in the given intervall in seconds.

Hosts:List of tuples (hostname, port) Interval:Check will be executed every X seconds

View

tedega_view.registry.config_view_endpoint(path, method, auth)

tedega_view.server.create_application(modulname, swagger_file='swagger.yaml', run_on_init=None)

Will create a connexion application for the given domain modul in modulname. The method will register all endpoints of the modul and make them available with the definden REST-API given in the swagger_file.

The funtion can optionally run a list of functions when the application is created. This can be used to start background processes like monitoring. The callable are give as a list of tuples. The first element in the tuple is the callable and the second element are the arguments used to call the callable.

Modulname:String of the name of the domain modul/package. Swagger_file:Name of the Swagger config relativ to the given modul/package. Run_on_init:List of callable which are called after the application has been created. Rückgabe:Connexion application.

Storage

tedega_storage.rdbms.init_storage()

tedega_storage.rdbms.get_storage()

tedega_storage.rdbms.scoped_session()

class tedega_storage.rdbms.storage.Storage(engine=None)

Docstring for Storage.