- Introduction
This document outlines the necessary service checks and backup process after installation of Logsign on Ubuntu 24.04. Ensuring the stability of the system during the upgrade process requires careful monitoring of service statuses, logs, and connections. This guide includes the essential steps to follow in order to prevent potential errors and performance issues.
- Config Backup Export Process via Logsign User Interface
Click Settings -> Data Management -> Config Backup.
If you need to import your config backup file, choose the file in your pc. Click to export button to export the config backup file. It only takes a few minutes.
3. Config Backup Export Process via Logsign CLI
The following steps are followed for the config backup process via the Logsign CLI:
After logging in, switch to the root user:
# sudo bash
b. Upload the previously taken .json backup file to the server.
c. Run the import config command to import the config backup in JSON format from the relevant directory:
#/opt/logsign-venv/bin/logsign-python /opt/logsign-data/scripts/backup.py --export backup.json
4. Config Backup Import Process via Logsign User Interface
Click Settings -> Data Management -> Config Backup.
If you need to import your config backup file, choose the file in your pc. Click import to import the config backup file. It only takes a few minutes.
5. Config Backup Import Process via Logsign CLI
The following steps are followed for the config backup process via the Logsign CLI:
After logging in, switch to the root user:
# sudo bash
b. Upload the previously taken .json backup file to the server.
c. Run the import config command to import the config backup in JSON format from the relevant directory:
#/opt/logsign-venv/bin/logsign-python /opt/logsign-data/scripts/backup.py --import backup.json
6. Exporting & Importing the Data Backup
Logsign data is stored in archive and signed files. These files are in the default daily format. If the backup was taken from a Linux OS, the files can be transferred back to the Logsign server from another location using operations like rsync or scp.
SCP Examples
Copy a file from a remote server:
~$ scp user@IP.address:/path/file_name /local/destination/path/
Copy a directory from a remote server:
~$ scp -r user@IP.address:/path/directory[/] /local/destination/path/
Copy a file to a remote server:
~$ scp /local/path/file_name user@IP.address:/destination/path/
Copy a directory to a remote server:
~$ scp -r /local/path/directory[/] user@IP.address:/destination/path/
e.g. Sending archived data from Logsign to the IP address 1.1.1.1 using the root user, in the databackup file.
# scp -r /opt/var/log/archive root@1.1.1.1:/databackup/
e.g. Sending the archived data from x location to Logsign(2.2.2.2) using the iadmin user, in the archive file.
# scp -r /root/databackup iadmin@2.2.2.2:/opt/var/log/
Rsync Examples
Because Rsync transfers files recursively, you do not need to add the -r
flag. You can use the following commands to transfer the files in an archived
or compressed manner:
- -a or --archive: Like recursion, this option preserves source characteristics, such as permissions.
- -v or --verbose: This option shows you more information during the transfer.
- -z or --compress: With this option, Rsync compresses the file data sent to the destination machine.
Copy a file from a remote server:
~$ rsync [-avz] user@IP.address:/path/file_name /local/destination/path/
Copy a directory from a remote server:
~$ rsync [-avz] user@IP.address:/path/directory[/] /local/destination/path/
Copy a file to a remote server:
~$ rsync [-avz] /local/path/file_name user@IP.address:/destination/path/
Copy a directory to a remote server:
~$ rsync [-avz] /local/path/directory[/] user@IP.address:/destination/path/
Trailing slash on source path
A trailing slash ( / ) on the source path changes the transfer behavior to avoid creating an additional directory level at the destination. With the slash, Rsync copies the directory content without creating a new folder. Without the slash, it creates a new directory with the source directory name. Following are examples with and without the slash:
~$ rsync [-avz] /local/path/directory/ user@IP.address:/destination/path/
~$ rsync [-avz] /local/path/directory user@IP.address:/destination/path/
e.g. Sending archived data from Logsign to the IP address 1.1.1.1 using the root user, in the databackup file.
# rsync -avz –progress /opt/var/log/archive/ root@1.1.1.1:/databackup/
e.g. Sending the archived data from x location to Logsign(2.2.2.2) using the iadmin user, in the archive file.
# rsync -avz –progress /root/databackup iadmin@2.2.2.2:/opt/var/log/
Service Check After Installation Process
-
- Errors and Log Reviewing
Check the latest log records to identify any potential errors:
Use the following commands to check the logs from the past hour and look for any errors:
sudo journalctl -u logsign-api --since "1 hour ago" | tail -50
sudo journalctl -u zookeeper --since "1 hour ago" | tail -50
sudo journalctl -u syslog-collector --since "1 hour ago" | tail -50
sudo journalctl -u elasticsearch --since "1 hour ago" | tail -50
sudo journalctl -u logsign-parser --since "1 hour ago" | tail -50
Watch out for keywords like “error”, “fail”, or “exception” in the logs.
- Current Status of Services
sudo systemctl list-units --type=service
If there are any failed services, examine their status in detail and restart them if necessary.
- High Resource Usage Check
To identify services consuming excessive system resources, use:
Top or htop
Pay special attention to Elasticsearch and other services to ensure they are not overusing CPU or RAM.
By performing these checks, you can ensure that your Logsign system continues to operate smoothly after the upgrade.
- Hadoop Services Check
Hadoop Service Check After Config and Data Backup Import
1. NameNode
journalctl -u hadoop-namenode.service -f
2. DataNode
journalctl -u hadoop-datanode.service -f
3. ZKFC (Zookeeper Failover Controller)
journalctl -u hadoop-zkfc.service -f
4. JournalNode
journalctl -u hadoop-journalnode.service -f