Настройка клиента
Устанавливаем и запускаем rsyslog по инструкции, . После приступаем к настройке клиента.
Все логи
Для начала можно настроить отправку всех логов на сервер. Создаем конфигурационный файл для rsyslog:
vi /etc/rsyslog.d/all.conf
Добавляем:
*.* @@192.168.0.15:514
* где 192.168.0.15 — IP-адрес сервера логов. *.* — перенаправлять любой лог.
Перезапускаем rsyslog:
systemctl restart rsyslog
Для определенных категорий
Если необходимо отправлять только определенные категории логов, создаем конфигурационный файл для соответствующей, например:
vi /etc/rsyslog.d/kern.conf
Добавим строку:
kern.* @@192.168.0.15:514
Перезапускаем сервис логов:
systemctl restart rsyslog
Возможные категории для логов (facility):
| № | Категория | Описание |
|---|---|---|
| kern | Сообщения, отправляемые ядром | |
| 1 | user | Пользовательские программы |
| 2 | Почта | |
| 3 | daemon | Сервисы (демоны) |
| 4 | auth | Безопасность/вход в систему/аутентификация |
| 5 | syslog | Сообщения от syslog |
| 6 | lpr | Логи печати |
| 7 | news | Новостные группы (usenet) |
| 8 | uucp | Unix-to-Unix CoPy (копирование файлов между компьютерами) |
| 9 | cron | Планировщик заданий |
| 10 | authpriv | Безопасность/вход в систему/аутентификация — защищенный режим |
| 11 | ftp | Логи при передачи данных по FTP |
| 12 | ntp | Лог службы синхронизации времени (существует не везде) |
| 13 | security, log audit | Журнал аудита (существует не везде) |
| 14 | console, log alert | Сообщения, отправляемые в консоль (существует не везде) |
| 15 | solaris-cron, clock daemon | Cron в solaris (существует не везде) |
| 16-23 | local0 — local7 | Зарезервированы для локального использования. Уровень серьезности определяется числом от 0 до 7. |
Для определенного уровня
Если мы хотим передавать только сообщения об ошибках, добавляем строку в файл конфигурации rsyslog:
vi /etc/rsyslog.d/erors.conf
*.err @@192.168.0.15:514
Перезапускаем сервис логов:
systemctl restart rsyslog
Возможные уровни логов:
Возможные категории для логов (severity):
№
Уровень
Расшифровка
emerg
Система не работает (PANIC)
1
alert
Серьезная проблема, требующая внимания
2
crit
Критическая ошибка
3
err
Ошибка (ERROR)
4
warning
Предупреждение (WARN)
5
notice
Важное информационное сообщение
6
info
Информационное сообщение
7
debug
Отладочная информация
Аудит определенного лог-файла
Мы можем настроить слежение за изменением определенного лога и передавать их на сервер. Для этого нужно настроить и сервер, и клиента.
Настройка клиента
Создаем новый конфигурационный файл:
vi /etc/rsyslog.d/audit.conf
$ModLoad imfile
$InputFileName /var/log/audit/audit.log
$InputFileTag tag_audit_log:
$InputFileStateFile audit_log
$InputFileSeverity info
$InputFileFacility local6
$InputRunFileMonitor
*.* @@192.168.0.15:514
* в данном примере мы будем отслеживать изменения лог-файла /var/log/audit/audit.log; нас интересуют события от уровня info и выше; все события будет отмечены категорией local6 и переданы на сервер 192.168.0.15.
Перезапускаем сервис на клиенте:
systemctl restart rsyslog
Настройка сервера (фильтрация сообщений)
На сервере нам нужно фильтровать все сообщения категории local6 (такую категорию мы выбрали, когда настроили клиента) и перенаправлять их в нужных нам файл. Открываем на редактирование конфигурационный файл rsyslog:
vi /etc/rsyslog.conf
Создаем новый шаблон для захвата логов:
$template HostAudit, «/var/log/rsyslog/%HOSTNAME%/audit.log»
local6.* ?HostAudit
* в данном примере мы создаем шаблон HostAudit; rsyslog будет принимать логи категории local6 и сохранять в файле /var/log/rsyslog/<имя компьютера, откуда пришел лог>/audit.log.
Перезапускаем сервер:
systemctl restart rsyslog
Лог определенного приложения
Некоторые приложения умеют отправлять лог напрямую на syslog. Например, nginx (начиная с версии 1.7.1). Для этого открываем конфигурационной файл (основной или конфиг виртуального домена):
vi /etc/nginx/nginx.conf
Добавляем или редактируем соответствующие настройки для логов:
…
access_log syslog:server=192.168.0.15:514 info;
error_log syslog:server=192.168.0.15:514 warn;
error_log /var/log/nginx/error.log warn;
…
* в данном примере мы настроили хранение логов для nginx на сервере 192.168.0.15. Для ошибок также сохраняется локальный лог в файле /var/log/nginx/error.log.
Проверяем корректность конфигурационного файла nginx:
nginx -t
Перезапускаем сервис:
systemctl restart nginx
Настройка syslog для удаленного логирования
Было бы очень удобно, если бы логи со всех серверов сети собирались на одной машине. Здесь бы были все важные сообщения об ошибках и неполадках. Вы могли бы все это очень быстро проанализировать. Отправить лог на удаленный сервер достаточно просто, для этого достаточно указать @ и ip адрес удаленной машины, на которой запущен rsyslog:
Здесь 514 — это порт, на котором слушает rsyslog. Настройка rsyslog на прием логов заключается в запуске сервиса с модулями imtcp и imudp. Далее, все что нужно для того чтобы получить логи с определенной машины, отфильтровать их из общего потока с помощью фильтров:
Без фильтров, сообщения с разных машин будут писаться в один общий лог системы linux в зависимости от того как вы их распределите.
Установка и настройка MySQL
— Устанавливаем Percona Server по инструкции разработчика:
— Перезагружаем сервер:
sudo reboot
— Настраиваем Percona Server:
sudo cp /etc/mysql/my.cnf /etc/mysql/my.cnf_old sudo cp /etc/mysql/percona-server.conf.d/mysqld.cnf /etc/mysql/my.cnf sudo nano /etc/mysql/my.cnf
— Содержание /etc/mysql/my.cnf для сервера с 6Gb ОЗУ:
user = mysql pid-file = /var/run/mysqld/mysqld.pid socket = /var/run/mysqld/mysqld.sock # PATHS basedir = /usr datadir = /var/lib/mysql tmpdir = /dev/shm lc-messages-dir = /usr/share/mysql explicit_defaults_for_timestamp local-infile = 0 # NETWORK bind-address = 127.0.0.1 port = 3306 connect_timeout = 60 wait_timeout = 28800 max_connections = 2048 max_allowed_packet = 64M max_connect_errors = 1000 # LOGS log_error = /var/log/mysql/error.log slow_query_log_file = /var/log/mysql/slow.log slow_query_log = 1 long_query_time = 20 # Recommended in standard MySQL setup sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_ALL_TABLES # Disabling symbolic-links is recommended to prevent assorted security risks symbolic-links=0 # limits tmp_table_size = 256M max_heap_table_size = 128M # innodb innodb_data_home_dir = /var/lib/mysql innodb_file_per_table = 1 innodb_status_file = 1 innodb_buffer_pool_size = 4G innodb_buffer_pool_instances = 8 innodb_flush_method = O_DIRECT innodb_io_capacity = 800 innodb_flush_log_at_trx_commit = 0 innodb_support_xa = ON innodb_log_file_size = 128M innodb_log_buffer_size = 64M # other stuff sync_binlog = 0 event_scheduler = 1 query_cache_type = 0 query_cache_size = 0
— Применяем настройки:
sudo service mysql restart
rsyslog в картинках
После всего прочтенного хотелось бы все это лицезреть в понятном виде. Попробую ка я все это обрисовать.
В данной схеме я постарался отобразить схему движения сообщения «сквозь» логику работы демона rsyslogd. Давайте попробуем разобраться в последовательности. Итак, сообщение пришло в систему с помощью одного из модулей ввода (сеть, файл, /dev/log …) — оранжевая сноска. Далее, сообщения выстраиваются в главную очередь (если не хватает системных ресурсов ). Очереди rsyslogd это отдельная тема), но для типового понимания этой информации достаточно. Далее, сообщения поступают в обработчик, который использует модули парсинга — фиолетовая сноска. После данного этапа, мессаджи сверяются с фильтрами (читай — с селекторами источник.приоритет), заданными в правилах. Если сообщение подпадает под селектор, то перед применением действия к сообщению применяется соответствующий шаблон (если шаблон для действия не указан, то применяется шаблон по умолчанию, либо тот, который задан в глобальных параметрах). Ну и применяется соответствующее действие. На основании действия, сообщение может быть направлено в соответствующее место, если это место требует применения модуля (например, ommysql, ompgsql), то используются соответствующий модуль вывода.
Вот, собственно и вся схема.
V – Маршрутизация журналов Linux в ElasticSearch
Напоминаем, что мы перенаправляем журналы из rsyslog в Logstash, и эти журналы будут переданы в ElasticSearch в значительной степени автоматически.
а — Маршрутизация от Logstash до ElasticSearch
Перед маршрутизацией журналов из rsyslog в Logstash очень важно настроить пересылку журналов между Logstash и ElasticSearch. Для этого мы собираемся создать файл конфигурации для Logstash и точно сказать ему, что делать
Для этого мы собираемся создать файл конфигурации для Logstash и точно сказать ему, что делать.
Чтобы создать файлы конфигурации Logstash, перейдите в /etc/logstash/conf.d и создайте файл logstash.conf.
Внутри добавьте следующее содержимое:
input {
udp {
host => "127.0.0.1"
port => 10514
codec => "json"
type => "rsyslog"
}
}
# Конвейер фильтра здесь остается пустым, форматирование не выполняется..
filter { }
# Каждый журнал будет перенаправлен в ElasticSearch. Если вы используете другой порт, вы должны указать его здесь..
output {
if == "rsyslog" {
elasticsearch {
hosts =>
}
}
}
Примечание : в этом руководстве мы используем вход UDP для Logstash, но если вы ищете более надежный способ передачи журналов, вам, вероятно, следует использовать вход TCP . Формат почти такой же, просто измените строку UDP на TCP.
Перезапустите службу Logstash.
$ sudo systemctl restart logstash
Чтобы убедиться, что все работает правильно, введите следующую команду:
$ netstat -na | grep 10514 udp 0 0 127.0.0.1:10514 0.0.0.0:*
Logstash теперь прослушивает порт 10514.
b — Маршрутизация от rsyslog к Logstash
Как описано ранее, rsyslog имеет набор различных модулей, которые позволяют ему передавать входящие журналы в широкий набор пунктов назначения.
Rsyslog может преобразовывать журналы с помощью шаблонов . Это именно то, что мы ищем, поскольку ElasticSearch ожидает на входе JSON, а не строки syslog RFC 5424.
Чтобы пересылать журналы в rsyslog, перейдите в /etc/rsyslog.d и создайте новый файл с именем 70-output.conf.
Внутри вашего файла напишите следующее содержимое:
# This line sends all lines to defined IP address at port 10514 # using the json-template format. *.* @127.0.0.1:10514;json-template
Теперь, когда у вас есть пересылка журналов, создайте файл 01-json-template.conf в той же папке и вставьте следующее содержимое:
template(name="json-template"
type="list") {
constant(value="{")
constant(value="\"@timestamp\":\"") property(name="timereported" dateFormat="rfc3339")
constant(value="\",\"@version\":\"1")
constant(value="\",\"message\":\"") property(name="msg" format="json")
constant(value="\",\"sysloghost\":\"") property(name="hostname")
constant(value="\",\"severity\":\"") property(name="syslogseverity-text")
constant(value="\",\"facility\":\"") property(name="syslogfacility-text")
constant(value="\",\"programname\":\"") property(name="programname")
constant(value="\",\"procid\":\"") property(name="procid")
constant(value="\"}\n")
}
Как вы, наверное, догадались, для каждого входящего сообщения rsyslog будет интерполировать свойства журнала в сообщение в формате JSON и перенаправить его в Logstash, прослушивая порт 10514.
Перезапустите службу rsyslog и убедитесь, что журналы правильно перенаправляются в ElasticSearch.
Примечание : журналы будут пересылаться в индексе с именем logstash- *.
$ sudo systemctl restart rsyslog
$ curl -XGET 'http://localhost:9200/logstash-*/_search?q=*&pretty'
{
"took": 2,
"timed_out": false,
"_shards": {
"total": 1,
"successful": 1,
"skipped": 0,
"failed": 0
},
"hits": {
"total": {
"value": 10000,
"relation": "gte"
},
"max_score": 1,
"hits":
}
}
Пришло время создать нашу последнюю дашборд в Кибане.
Overall System Setup¶
In this paper, I concentrate on the server side. If you are thinking
about interactive syslog message review, you probably want to centralize
syslog. In such a scenario, you have multiple machines (the so-called
clients) send their data to a central machine (called server in this
context). While I expect such a setup to be typical when you are
interested in storing messages in the database, I do not describe how to
set it up. This is beyond the scope of this paper. If you search a
little, you will probably find many good descriptions on how to
centralize syslog. If you do that, it might be a good idea to do it
securely, so you might also be interested in my paper on ssl-encrypting
syslog message
transfer.
No matter how the messages arrive at the server, their processing is
always the same. So you can use this paper in combination with any
description for centralized syslog reporting.
Запуск демона syslogd
Запуск демона протоколирования запускаются на этапе инициализации системы посредством скрипта /etc/rc.d/init.d/syslog, однако для того, чтобы задать параметры запуска, нет необходимости корректировать этот скрипт — начиная с версии 7.2, опции запуска считываются из отдельного конфигурационного файла /etc/sysconfig/syslog (/etc/default/syslog в debian).
Вот некоторые возможные параметры запуска демона syslogd:
- -a /folder/socket — указание дополнительного слушающего сокета (не забудьте предварительно создать сокет)
- -d — отладочный режим. При этом демон не переходит в фоновый режим и выдает все сообщения на текущий терминал;
- -f имя-конфигурационного-файла. Задает имя альтернативного конфигурационного файла, который будет использоваться вместо заданного по умолчанию /etc/syslog.conf;
- -l список-хостов — задание списка хостов, имена которых не должны записываться с указанием полного доменного имени (FQDN — Full Qwalified Domain Name);
- -m минут — запущенный без этой опции sysklogd через каждые 20 минут записывает в протокол сообщения категории mark (временные отметки). С помощью опции -m можно либо изменить интервал между отметками, либо вовсе отменить выдачу таких сообщений;
- -p socket — задание альтернативного сокета UNIX (вместо прослушиваемого по умолчанию /dev/log);
- -r — разрешение принимать сообщения от удаленных хостов;
- -x — запрет определения имени хоста по его адресу для предотвращения зависания при работе на одном хосте с сервером DNS.
- -v — показать версию и закончить работу
После запуска демона syslogd создается файл статуса /var/lock/subsys/syslog нулевой длины, и файл с идентификационным номером процесса /var/run/syslogd.pid.
С помощью командыkill -SIGNAL `cat /var/run/syslogd.pid`
можно послать демону syslogd один из следующих сигналов: SIGHUP — перезапуск демона; SIGTERM — завершение работы; SIGUSR1 — включить/выключить режим отладки.
Вообще-то в системе запускаются два демона протоколирования — syslogd и klogd. Оба демона входят в состав пакета sysklogd.
Демон klogd отвечает за журналирование событий, происходящих в ядре системы. Необходимость в отдельном демоне klogd объясняется тем, что ядро не может использовать стандартную функцию syslog. Дело в том, что стандартные библиотеки С (включая ту библиотеку, в которой находится функция syslog) предназначены для использования только обычными приложениями. Поскольку ядро тоже нуждается в функциях журналирования, в него включены свои библиотеки, недоступные приложениям. Поэтому ядро использует свой собственный механизм генерации сообщений.
Демон klogd предназначен для организации обработки этих сообщений. В принципе он может производить такую обработку полностью самостоятельно и независимо от syslogd, например, записывая эти сообщения в файл, но в большинстве случаев используется принятая по умолчанию настройка klogd, при которой все сообщения от ядра пересылаются тому же демону syslogd.
Закроем доступ к сайту Loganalyzer паролем
— Создадим файл htaccess
sudo nano /var/www/html/loganalyzer/.htaccess
AuthName "Need password" AuthType Basic AuthUserFile /etc/apache2/.htpasswd.loganalyzer require valid-user
— Добавим пользователя в указанный файл /etc/apache2/.htpasswd.loganalyzer
sudo htpasswd -c /etc/apache2/.htpasswd.loganalyzer user New password: Re-type new password: Adding password for user user
— Добавим поддержку htaccess для сайта:
В файл etc/apache2/sites-available/default-ssl.conf добавим следующие строки:
<Directory /var/www/html/loganalyzer> AllowOverride ALL </Directory>
— Применяем настройки:
sudo service apache2 restart
Веб интерфейс для rsyslog
В качестве веб-интерфейса будем настраивать Loganalizer от adiscon. Установка веб интерфейса довольно проста. Заключается в скачивании архива, распаковке в каталог веб сервера и запуск графического мастера настройки. Итак, отсюда (http://loganalyzer.adiscon.com/downloads) качаем архив с файлами (Например: http://download.adiscon.com/loganalyzer/loganalyzer-3.5.6.tar.gz). Перед настройкой, конечно же должен быть установлен Web сервер и модуль php5 (aptitude install apache2 libapache2-mod-php5). А да, еще php5-gd для отображения отчетов.
~ # # Скачиваем архив: ~ # wget http://download.adiscon.com/loganalyzer/loganalyzer-3.5.6.tar.gz ~ # # распаковываем архив: ~ # tar xf loganalyzer-3.5.6.tar.gz
В текущем каталоге появится каталог loganalyzer-3.5.6, который содержит некоторую информацию, достойную прочтения:
~ # ls -l итого 12 drwxr-xr-x 3 root root 4096 Сен 20 22:51 . drwx------ 13 root root 4096 Сен 20 23:01 .. drwxrwxr-x 5 root root 4096 Сен 10 17:26 loganalyzer-3.5.6 ~ # ls -l loganalyzer-3.5.6/ итого 112 -rw-rw-r-- 1 root root 41186 Сен 10 17:26 ChangeLog drwxrwxr-x 2 root root 4096 Сен 20 23:01 contrib -rw-rw-r-- 1 root root 35497 Сен 10 17:26 COPYING drwxrwxr-x 2 root root 4096 Сен 10 17:34 doc -rw-rw-r-- 1 root root 8449 Сен 10 17:26 INSTALL drwxrwxr-x 14 root root 4096 Сен 10 17:34 src ~ # # из каталога src нам необходимо скопировать содержимое в /var/www/loganalyzer: ~ # mkdir /var/www/loganalyzer ~ # cp -r loganalyzer-3.5.6/src/* /var/www/loganalyzer ~ # # далее,необходимо создать пустой файл конфигурации, ~ # # который будет заполнен автоматически - установщиком ~ # touch /var/www/loganalyzer/config.php ~ # # зададим права на запись (после установки эти права можно убрать) ~ # chmod 666 /var/www/loganalyzer/config.php
Далее, пытаемся зайти на http://10.0.0.1/loganalyzer и видим чудо:
жмахаем here
Видим, для чего мы давали права 666, нажимаем Next
Здесь выбираем желаемые настройки. Отдельного внимания требует параметр Enable User Database. Если выбрать его, то будет создана отдельная база для хранения настроек Веб-интерфейса. Так же, будет доступна возможность создавать пользователей и группы. Жмем next.
Странно, но куда то пропало 6 шагов. (это потому что на прошлом шаге мы не выбрали хранение настроек в базе). На данном шаге выбираем источник сообщений (файл, sql) и указываем соответствующие параметры.
Это все. Ниже пару скриншотов того, что получилось:
Есть маленькое дополнение — веб сервер не имеет доступа к обычным файлам в каталоге /var/log/. Поэтому, журнал может не отображаться. Чтобы решить данную проблему, необходимо добавить пользователя www-data в группу adm:
~ # usermod -G adm www-data
Кроме Loganalyzer существует так же — Logzilla, обладающая тем же функционалом. Ее тоже стоит попробовать установить, если есть желание.
Включение SSL
— Создадим сертификаты:
sudo mkdir /etc/apache2/certs cd /etc/apache2/certs sudo openssl req -new -x509 -days 3650 -sha1 -newkey rsa:2048 -nodes -keyout server.key -out server.crt sudo chmod 0600 server.key
— Включаем поддержку SSL в Apache2:
sudo a2enmod ssl sudo a2enmod alias sudo service apache2 restart
— Добавим в конфигурацию /etc/apache2/sites-available/default-ssl.conf пути к сертификатам:
SSLEngine on SSLProtocol all -SSLv2 SSLCertificateFile /etc/apache2/certs/server.crt SSLCertificateKeyFile /etc/apache2/certs/server.key
— Включаем сайт:
sudo a2ensite default-ssl sudo service apache2 restart
— Настроим редирект с http на https:
Добавим в конфигурацию /etc/apache2/sites-available/000-default.conf
<VirtualHost *:80> Redirect / https://10.1.1.52/loganalyzer/ </VirtualHost>
— Применяем настройки:
sudo service apache2 restart
Background¶
In many cases, syslog data is simply written to text files. This
approach has some advantages, most notably it is very fast and
efficient. However, data stored in text files is not readily accessible
for real-time viewing and analysis. To do that, the messages need to be
in a database. There are various ways to store syslog messages in a
database. For example, some have the syslogd write text files which are
later feed via a separate script into the database. Others have written
scripts taking the data (via a pipe) from a non-database-aware syslogd
and store them as they appear. Some others use database-aware syslogds
and make them write the data directly to the database. In this paper, I
use that “direct write” approach. I think it is superior, because the
syslogd itself knows the status of the database connection and thus can
handle it intelligently (well … hopefully ;)). I use rsyslogd to
accomplish this, simply because I have initiated the rsyslog project with
database-awareness as one goal.
Reserved Template Names¶
Template names beginning with “RSYSLOG_” are reserved for rsyslog use.
Do NOT use them if, otherwise you may receive a conflict in the future
(and quite unpredictable behaviour). There is a small set of pre-defined
templates that you can use without the need to define it:
-
RSYSLOG_TraditionalFileFormat — the “old style” default log file
format with low-precision timestamps -
RSYSLOG_FileFormat — a modern-style logfile format similar to
TraditionalFileFormat, both with high-precision timestamps and
timezone information -
RSYSLOG_TraditionalForwardFormat — the traditional forwarding format
with low-precision timestamps. Most useful if you send messages to
other syslogd’s or rsyslogd below version 3.12.5. -
RSYSLOG_SysklogdFileFormat — sysklogd compatible log file format. If
used with options: ,
,
, the log format will conform to sysklogd log format. -
RSYSLOG_ForwardFormat — a new high-precision forwarding format very
similar to the traditional one, but with high-precision timestamps
and timezone information. Recommended to be used when sending
messages to rsyslog 3.12.5 or above. -
RSYSLOG_SyslogProtocol23Format — the format specified in IETF’s
internet-draft ietf-syslog-protocol-23, which is assumed to become
the new syslog standard RFC. This format includes several
improvements. The rsyslog message parser understands this format, so
you can use it together with all relatively recent versions of
rsyslog. Other syslogd’s may get hopelessly confused if receiving
that format, so check before you use it. Note that the format is
unlikely to change when the final RFC comes out, but this may happen. -
RSYSLOG_DebugFormat — a special format used for troubleshooting
property problems. This format is meant to be written to a log file.
Do not use for production or remote forwarding.
ЗАПУСК MARIADB GALERA
После успешной настройки всех нод нам останется только запустить кластер Galera на первой ноде. Перед тем как мы сможем запустить кластер, вам нужно убедиться, что сервис MariaDB остановлен на всех серверах:
Дальше запустите скрипт создания нового кластера:
Проверить запущен ли кластер и сколько к нему подключено машин можно командой:
Сейчас там только одна машина, теперь перейдите на другой сервер и запустите ноду там:
Вы можете проверить прошел ли запуск успешно и были ли какие-либо ошибки командой:
Затем, выполнив ту же команду, вы убедитесь, что новая нода была автоматически добавлена к кластеру:
Чтобы проверить как работает репликация просто создайте базу данных на первой ноде:
Затем посмотрите действительно ли она была добавлена на всех других:
Как видите, действительно база данных автоматически появляется на другой машине. Репликация данных mysql работает.
Централизованный сервер rsyslog в Debian
Давайте рассмотрим простой конфиг централизованного сервера rsyslog, который будет сортировать файлы логов по ip адресу источника сообщения. Редактировать файлы можно с помощью vim или другого текстового редактора. ip адрес сервера rsyslog примем за 10.0.0.1, на него необходимо натравить всех . Для корректной работы rsyslogd необходимо разрешить получение syslog сообщений из сети, подключив соответствующий модуль и задав правило, т.к. по умолчанию, UDP и TCP транспорт на сервере отключен (приведу только измененные\добавленные строки):
~ # cat /etc/rsyslog.conf <...> ################# #### MODULES #### ################# <...> # раскомментируем параметры подключения модуля, позволяющего собирать информацию по UDP: $ModLoad imudp # раскомментируем номер порта для сервера - можно заменить на свой (не забудьте о клиентах) $UDPServerRun 514 # раскомментируем параметры подключения модуля, позволяющего собирать информацию по TCP (по жаланию): #$ModLoad imtcp # раскомментируем номер порта для сервера (по желанию - можно заменить на свой (не забудьте о клиентах) #$InputTCPServerRun 514 ########################### #### GLOBAL DIRECTIVES #### ########################### <...> ############### #### RULES #### ############### <...> # удаленное журналирвание # Зададим шаблон создания имен файлов (на основании IP адреса клиента) $template FILENAME,"/var/log/%fromhost-ip%/syslog.log" # Укажем сохранять сообщения от любого источника (*) с любым приоритетом (*) в файл, заданный шаблоном # Например, клиенты (10.0.0.2,10.0.0.3...) будут раскладываться в соответствующие каталоги /var/log/10.0.0.2/syslog.log *.* ?FILENAME # как вариант, возможно рассмотреть вот такой вид сортировки: # шаблон, раскидывающий по имени хоста, году, месяц, дню # $template RemoteHost,"/var/log/%HOSTNAME%/%$YEAR%/%$MONTH%/%$DAY%/syslog.log" # правило, использующее шаблон # *.* ?RemoteHost
После задания указанных параметров, необходимо перезапустить\перечитать конфигурационный файл (service rsyslog restart). При этом, netstat нам должен показать, что сислог стал слушать соответствующий порт:
~ # netstat -nap | grep 514 udp 0 0 0.0.0.0:514 0.0.0.0:* 21017/rsyslogd
Конечно, мы можем не указывать параметры хранения, а лишь раскомментировать параметры $ModLoad imudp и $UDPServerRun 514, тогда rsyslogd будет размещать сообщения в стандартных выходных файлах (messages, syslog, etc), согласно правил по умолчанию. Необходимо учитывать, что указание только загрузки модуля (например $ModLoad imudp) недостаточно для приема сообщений по сети. Обязательно нужно указывать так же и соответствующий порт для прослушки (например, $UDPServerRun 514).
Заключение
В этой статье я познакомил вас с ключевым словом , рассказал о том, что означают данные, которые выводятся в результате его работы и как вы можете их использовать для оптимизации запросов. Использовать в реальном приложении это будет более полезно, чем на демонстрационной базе данных из этой статьи. Почти всегда вы будете объединять несколько таблиц вместе, и использовать
Простое добавление индексов нескольким полям обычно не приносит выгоды, поэтому в процессе составления запросов особое внимание надо уделять самим запросам
Перевод – Земсков Матвей
Оригинал статьи: http://phpmaster.com/using-explain-to-write-better-mysql-queries/
