Introduction
This article discusses the services in the Logsign cluster architecture.
Cluster Architecture
Cluster architecture or cluster structures are server clusters configured to work together or in redundancy for the same purpose with specific configurations. Note the word "redundant" here, as the most important criteria of cluster architecture is to have redundant systems.
Cluster structures are not unique to Logsign and are used in many systems. Two or more servers, called "nodes", are required to create a cluster architecture. In Logsign Cluster Structure, there are three servers, and Logsign configures the cluster architecture on three servers.
Cluster provides availability, reliability, and scalability. Logsign Cluster Architecture has an "ACTIVE/ACTIVE" working structure, and in this structure, load balancing and backup are at the forefront.
Information about the services in Logsign is as follows.
Logsign-api:
It is the service that the Logsign user interface runs on. It serves as a bridge between the interface templates and the backend.
Zookeeper:
It is the service where all the configurations used in Logsign are kept. (Report, Alarm, User Information, Dashboard Conf, Profiles, Settings...)
Syslog-collector:
These are syslog services on Logsign. It collects logs coming from IPs that have been added to Logsign as a syslog source by listening to UDP port 514 and TCP Port 515 sends them to the parser.
Logsign-poller:
Logs do not always come to us. In some cases, we go to the source and retrieve the logs. This service allows the services of the sources from which we retrieve logs to work. Services connected to the poller service are:
Logsign-poller-oracle:
It works when an oracle database is added to the Logsign source list. It connects to the specified oracle source with the given conf. and retrieves the data and sends it to the parser.
Logsign-poller-mssql:
It works when an mssql database is added to the Logsign source list. It connects to the specified mssql source with the given conf. and retrieves the data and sends it to the parser.
Logsign-poller-wmi:
It works when a WMI (Windows Management Instrumentation) source is added to the Logsign source list. It connects to the specified WMI source with the given conf. and reads the data and sends it to the parser.
Logsign-poller-sftp:
It works when an sftp (SSH (Secure Shell) File Transfer Protocol) source is added to the Logsign source list. It connects to the specified sftp source with the given conf. using the SSH protocol and reads the data and sends it to the parser.
Logsign-poller-smb:
Fileshare-sambashare It works when an smb (Server Message Block (Linux = Samba)) source is added to the Logsign source list. It connects to the specified smb source with the given conf. and reads the data and sends it to the parser.
Logsign-persist:
After the data coming to Logsign goes through the parser mechanism, it is posted to this service. It is the service that writes the parsed version (human_readable) and the original version (raw (5651 for)) collected.EXTENSION (raw, json, parquet).day.month.year in the /opt/var/log.
Logsign-postprocess:
It controls the services and their queues to be used for operations (alarm, alarmflow, bucket, offline, data-export) after the data is prepared in every way and written to the necessary places. The services that work in connection with this are:
Logsign-bucket-worker:
It appears as a list in the alarm module on Logsign's interface. According to the conf of the created lists, it caches the data between certain periods and produces an alarm if the condition is met by this cached data
Logsign-offline-worker: A service that controls the Reindex and Export operations and the Schedule Report feature from a compressed archive.
Logsign-data-export-worker: A service that ensures the PDF and EXCEL export feature of reports and the export part of Schedule Report work on the Logsign interface.
Logsign-alarmflow-worker: A service that combines Bucket and Alarm to produce alarms based on cached data. It includes the 6th and 7th type of alarms.
Logsign-maintenance: A service that controls the management of the system in general. It controls the Cluster services, stats, redundancy, socket-watcher, and other related services.
Logsign-health-check: A service that runs the scripts of predetermined scenarios at specific intervals to provide information about the general condition of services in the Logsign system.
Logsign-security-automation-worker: A service that removes temporary blocking from blocked objects when the time comes.
Logsign-action-rule-worker: A service that applies movements on the action rules using response actions.
Logsign-integration-engine: A service that ensures communication between API and products found in response resources.