Table of contents
10.2.4. <PREVIEW_NOT_IN_PROD> <PREVIEW_NOT_IN_PROD> <PREVIEW_NOT_IN_PROD> <PREVIEW_NOT_IN_PROD>
10.2.5. Pilots Logging system overview
Pilots Loggins system is designed to allow logging of pilot state on every stage of lifecycle, including before installing DIRAC client and starting pilot process.
Each logging entry includes:
current status of the Pilot - has to be one of predefined list of possible states,
additional information about status,
timestamp of logging the status - if there is no timestamp of actual event provided, time of adding entry to database will be used,
source of the logging message to distinguish updates from Pilot itself and other services.

10.2.5.1. Server side
Server elements of Pilots Logging system is build using five elements:
message queue (RabbitMQ) server,
message queue consumer,
DIRAC Client,
DIRAC Service,
database.
10.2.5.1.1. Message queue
Message works as a interface between Pilot and Pilots Logging service. Pilot puts status related messages into queue then messages are handled by message queue consumer.
10.2.5.1.2. Message queue consumer
Consumer registers itself into message queue. When new messages arrive they are handled by callback function. In consumer messages are processed and passed to DIRAC Service using DIRAC Client.
10.2.5.1.3. DIRAC Client
Client handles RPC communication with Service. This is ‘thin-client’, all business logic is in Service.
10.2.5.1.4. DIRAC Service
Service exports functions to be called by Clients. It handles all operations on databases. All server side logic of Pilots Logging system is defined here. Two databases are accessed to gather all required information.
10.2.5.1.5. Database
Database class handles operation on the database. Object-relational mapping is done using SQLAlchemy. Single table stores record for every status reported by Pilot:

10.2.5.2. Pilot side
TBD