Перезапуск SSH-сервера
После применения изменений необходимо выполнить перезагрузку SSH, чтобы система начала работать с новой конфигурацией. Введите следующую команду, чтобы перезапустить демон SSH:
systemctl reload sshd
Перед тем, как покинуть сервер, рекомендуется проверить, правильно ли он настроен.
Закройте и откройте терминал, чтобы в нем создать новое соединение с нашим сервером. Однако, в данном случае вместо входа в профиль «root», используйте уже созданный «demo».
К настроенному удаленному серверу можно подключиться командой (Замените логин и IP-адрес своими):
* IP-адрес дан в качестве примера, на его место нужно подставить актуальный.
Теперь введите пароль своего нового пользователя, чтобы войти систему с его привилегиями. Не забывайте, что перед запуском команды с правами администратора нужно вначале прописывать слово «sudo»:
sudo command_to_run
Если все прошло как нужно, остается завершить сеанс командой:
exit
Что касается входа через Windows, для перезапуска сервера также можно использовать клиент Putty, где после авторизации останется ввести выше предложенные команды.
Таким образом, базовая настройка VPS-сервера с установленной Centos 7 или CentOS 8 завершена успешно.
Почему для того, чтобы моя сетевая Ethernet-карта заработала, мне необходимо залогиниться и самому её задействовать?
.. и почему, если сравнивать с распостранённой практикой, имена сетевых интерфейсов названы «неверно»? Ведь это нарушает правило Unix «не изменять ожиданиям».
Поставщик ПО добавил NetworkManager к конфигурации по умолчанию, и сетевые интерфейсы (каким-то необъяснимым образом) по умолчанию неактивны. Это можно исправить во время процесса установки на этапе, когда установщик предлагает вам настроить язык/клавиатуру/устройство хранения/ПО в основном окне установщика, сделав вашу сетевую карту активной. Для этого вам необходимо нажать «Network & Hostname» («Сеть и имя хоста»), выбрать то сетевое Ethernet соединение, которое вы хотите изменить, и нажать кнопку «Off» в верхнем правом углу. Если исходить из того, что вы можете использовать DHCP, то ваше сетевое соединение перейдёт в состояние получение сетевого адреса. Если же вам необходимо вручную задать сетевые настройки, нажмите «Configure», после чего введите и сохраните нужные значения. Для того, чтобы изменения вступили в силу, скорее всего будет необходимо отключить, а потом включить только что настроенный сетевой интерфейс. Нажмите «Done». Помимо вышеуказанного способа, сетевое соединение после установки можно настроить при помощи «NetworkManager» (располагается в «System; Preferences; Network Connections», либо нажмите ПКМ по маленькому значку сети в области уведомлений, после чего — «Edit Connections»).
Если же вы не используете NetworkManager, то аналогичный результат можно достигнуть, измененив файл конфигурации соответствующего сетевого интерфейса (как правило это /etc/sysconfig/network-scripts/ifcfg-eth0): «ONBOOT=no» на «ONBOOT=yes». В случае использования DHCP может потребоваться добавить строку «BOOTPROTO=dhcp». Для статического IP потребуется «BOOTPROTO=static».
Если предположить, что имя сетевого устройства — eth0, то изменение строчки ONBOOT может быть осуществленно (от имени root) следующим образом:
# cd /etc/sysconfig/network-scripts/ # sed -i -e 's@^ONBOOT="no@ONBOOT="yes@' ifcfg-eth0
Касательно «изменённых ожиданий»: в предыдущем примере используется «традиционное» именование сетевого интерфейса: eth0. Однако возможны и другие названия, как например em1, p3p1 и пр. Нравится это или нет, но эта концепция именования — дальнейший пусть развития Linux. Это было описано раннее в «тестовом дистрибутиве» вендора ПО. Смотрите так же Dell’s writeup и blog post
Добавление CentOS 7 в домен Windows
Здесь нужно быть очень внимательным. Это сложный и не любимый мной момент, так как все очень сильно привязано к версиям системы и софта. Порой какой-нибудь точки или регистра достаточно, чтобы ничего не работало. Так вышло и у меня, когда я готовил этот материал.
Я без проблем ввел компьютер в домен, прошел все проверки, но потом в squid напрочь отказывалась работать ntlm авторизация. Все на вид выглядело нормально, но не работало. Я несколько раз восстанавливал виртуалку и начинал все сначала, перечитав практически все, что смог найти по теме в рунете и буржунете. В какой-то момент все заработало. Я зафиксировал результат и несколько раз проверил последовательность действий и отточил ее до каждого шага. Проверил несколько раз на чистой системе. По крайней мере на момент написания статьи конфигурация на 100% рабочая, если аккуратно повторить все мои действия. Приступаем.
Сначала остановим и отключим firewalld:
Это не значит, что его не надо настраивать. Сейчас другая тема статьи, для локализации проблем необходимо убрать все, что теоретически может мешать при неправильной настройке. Firewall нужно настраивать и у меня есть подробная инструкция по настройке iptables. Рекомендую с ней ознакомиться и аккуратно настроить iptables, когда все получится со squid.
Установим софт для добавления сервера в домен windows:
Для продолжения настройки вам необходимо знать следующие вещи — FQDN имя контроллера домена, его ip адрес и учетную запись с правами на ввод компьютера в домен.
Первым делом вручную синхронизируем часы компьютера с контроллером домена:
Добавляем наш контроллер в список серверов для обновления в файле /etc/ntp.conf, запускаем ntp и добавляем в автозагрузку:
Синхронизация времени с контроллером домена не является обязательным действием. Но в случае расхождения времени более чем на 5 минут, будут возникать проблемы, которые на первый взгляд будут неочевидными и решать их трудно. Поэтому на всякий случай процедуру лучше провести. Очень подробно о настройке времени в CentOS 7 рассказано отдельно.
Выполняем команду для передачи настроек керберосу:
Команда вся идет в одну строчку. Скопируйте ее сначала в текстовый файл и подредактируйте под свои параметры. Проверьте, что нигде не пропали и не добавились лишние пробелы, либо какие-то еще символы, тире должно быть двойным перед параметром. В данном случае:
- xs — название домена
- winsrv — имя контроллера домена
- winsrv.xs.local — полное имя домена
Вывод после работы команды будет такой:
Это нормально
Обращаю внимание, что SELinux у меня отключен
Теперь заводим машину в домен:
Вводим пароль, ждем некоторое время. Если ошибки не появилось, значит компьютер успешно включен в домен.
Теперь нужно запустить и добавить в автозагрузку winbind:
Проверяем, все ли у нас корректно работает. Для начала проверим наличие доверительной учетной записи сервера на КД:
Все в порядке. Теперь проверяем, может ли наш сервер получать списки пользователей и групп. Первая команда выводит список всех групп домена, вторая — всех пользователей:
Проверим авторизацию пользователя через winbind:
В данном случае control — имя пользователя домена, pass — его пароль. Успешная проверка выглядит так, как у меня.
Теперь запросим билетик кербероса:
Дальше вводите пароль. Если ошибки не выскочило, значит все в порядке. Проверим билет командой:
Все в порядке, проверки прошли. Мы полностью подготовили сервер к авторизации пользователей доменными учетными записями.
Администрирование конфигураций 1С (недокументированные особенности работы)
Многие мои коллеги по работе и по профессии, уверен, сталкиваются с аналогичными ситуациями, когда программа 1С при работе с конфигурацией, мягко говоря, работает «странно». Как говорит один хороший знакомый (к слову, один из авторов УТ 11):
— «вот, ну согласись, нанять пару серьезных методистов — реальных дядечек с реального производства, до начала разработки — единственная ЭЛЕМЕНТАРНАЯ политика, как можно было этого не сделать???? там их НЕТ. Причем это 0 в плане затрат на разработку, там нет ограничений бюджета, это просто самый тупой прокол.»
В этой статье приведу способы лечения пресловутых проколов (за последний месяц).
Предварительная настройка сервера
Любую настройку сервера я рекомендую начинать с обновления:
# yum -y update
После этого я устанавливаю mc, так как привык к нему и постоянно пользуюсь:
# yum -y install mc
Дальше отключаем selinux. Находим файл /etc/sysconfig/selinux и редактируем его:
# mcedit /etc/sysconfig/selinux
Приводим строку с соответствующим параметром к следующему виду:
SELINUX=disabled
Чтобы применить изменения, перезагружаем сервер:
# reboot
Более подробно о базовой настройке сервера CentOS 7 читайте отдельно. Мы же двигаемся дальше.
Теперь настроим сеть. Я очень подробно рассмотрел вопрос настройки сети в CentOS 7 в своем отдельном материале. Рекомендую с ним ознакомиться. Здесь же я кратко выполню необходимые команды, без пояснений.
Сначала удаляем NetworkManager. Он нам не понадобится, выполним все настройки вручную. Иногда он может вызывать непонятные ошибки, я предпочитаю им не пользоваться:
# systemctl stop NetworkManager.service # systemctl disable NetworkManager.service
Теперь включаем классическую службу сети в CentOS 7:
# systemctl enable network.service
Настраиваем сетевые интерфейсы:
# mcedit /etc/sysconfig/network-scripts/ifcfg-eth0 HWADDR=00:15:5D:01:0F:06 TYPE="Ethernet" BOOTPROTO="dhcp" DEFROUTE="yes" PEERDNS="yes" PEERROUTES="yes" NAME="eth0" UUID="4e65030c-da90-4fb8-bde4-028424fe3710" ONBOOT="yes"
# mcedit /etc/sysconfig/network-scripts/ifcfg-eth1 DEVICE=eth1 HWADDR=00:15:5d:01:0f:12 TYPE=Ethernet ONBOOT=yes IPADDR=192.168.10.1 NETMASK=255.255.255.0
Перезапускаем службу сети:
# systemctl restart network.service
Смотрим, что получилось:
# ip a
Вы настраивайте сеть в зависимости от своих условий. Если внешний адаптер получает настройки не по dhcp, как у меня, а в статике, то не забудьте настроить шлюз по-умолчанию и dns сервер. Как это сделать написано в моей статье о сетевых параметрах, ссылку на которую я приводил выше.
Прежде чем двигаться дальше, убедитесь, что вы все верно настроили — на сервере работает интернет, компьютеры из локальной сети пингуют сервер по адресу на eth1.
DHCP
Для автоматического получения IP-адреса от сервера DHCP мы должны задать следующее значение для опции BOOTPROTO в конфигурационном файле:
…
BOOTPROTO=dhcp
…
* в наших примерах выше данный параметр имеет значение static.
Переопределение DNS с помощью dhclient.conf
Также мы можем переопределять настройки для DHCP с помощью конфигурационного файла. Например, если мы хотим, чтобы адреса DNS были заданы определенные, а не полученны от DHCP, открываем конфиг:
vi /etc/dhcp/dhclient.conf
Вставляем запись:
interface «enp0s3»
{
supersede domain-name-servers 8.8.8.8, 8.8.4.4;
}
* где enp0s3 — имя сетевого интерфейса, который будет получать адрес от сервера DHCP. 8.8.8.8, 8.8.4.4 — адреса, которые будут настоены на интерфейсе, независимо от того, какие предложит сервер DHCP.
Или мы можем использовать адреса от DHCP, но сделать приоритетными свои:
interface «enp0s3»
{
prepend domain-name-servers 127.0.0.1;
}
* в данном примере, мы зададим в качестве основного сервера DNS — 127.0.0.1.
Чтобы данный метод сработал в CentOS 8, необходимо открыть файл:
vi /etc/NetworkManager/NetworkManager.conf
В раздел добавить:
dhcp=dhclient
Переопределение DNS в NetworkManager (альтернативный способ)
Метод, описанный выше по переопределению DNS не подходит для NetworkManager без изменения настройки dhcp, так как адреса будут получены и обработаны с помощью встроенных методов. Выше, предоставлено решение в виде настройки dhcp=dhclient, однако мы рассмотрим альтернативный способ, на случай, если кому-то это пригодится.
Создаем файл:
vi /etc/NetworkManager/dispatcher.d/99-resolv.conf.dhclient
#!/bin/bash
sleep 1
rm -f /etc/resolv.conf
echo ‘# Generated by dispatcher’ > /etc/resolv.conf
echo ‘nameserver 127.0.0.1’ >> /etc/resolv.conf
echo » >> /etc/resolv.conf
cat /var/run/NetworkManager/resolv.conf >> /etc/resolv.conf
* в данном примере мы создали скрипт, который сначала добавит нужную нам запись в файл /etc/resolv.conf, а после добавит туда значения, полученные от DHCP
Обратите внимание, что в конкретном примере:
- адрес 127.0.0.1 задается в качестве приоритетного сервера DNS.
- остальные настройки получаем от DHCP, которые NetworkManager помещает в файл /var/run/NetworkManager/resolv.conf.
Разрешаем запуск скрипта:
chmod +x /etc/NetworkManager/dispatcher.d/99-resolv.conf.dhclient
Перезапускаем сеть:
systemctl restart NetworkManager
Через 2 секунды проверяем:
cat /etc/resolv.conf
Настройка сети CentOS 8 через конфигурационные файлы
Первый метод мы с вами разобрали, он подходит всем, кто делает установку системы сам. Теперь ситуация, когда вам передали уже готовую CentOS 8, пусть в установке Minimal, это стандартный нормальный вариант использования CentOS 8, в качестве серверной ОС. Нет графики, нет кучи компонентов, меньше фронт атаки. Подключаемся к вашему терминалу. Первое, что вам необходимо сделать, это посмотреть список и названия всех ваших сетевых интерфейсов, для этого есть команда:
ip a (То же самое, что и ввести ip addr show)
Как видим у меня два сетевых интерфейса ens33 и ens36. У меня почему, то у интерфейса ens33 нет IPv4 адреса, у второго я получил 192.168.253.145, это мой интернет шнурок.
Если у вас один интерфейс и он не получил ни какого IP-адреса, то логично что вы поставить IFCONFIG не сможете, поэтому сразу переходите к редактированию конфигурационных файлов и настройке статического или динамического IP
Пробуем с вами посмотреть текущие сетевые настройки IP адреса, маску, шлюз в более удобном виде, для этого мы использовали утилиту IFCONFIG. Пишем команду:
ifconfig
Но в случае с CentOS 8 Minimal у вас выскочит ошибка «Command not found» или в русском варианте «ifconfig команда не найдена». Нам ее нужно установить
Установка IFCONFIG в CentOS 8
Давайте выясним, в каком пакете у нас идет утилита IFCONFIG, для этого вам необходимо выполнить команду:
yum provides ifconfig
На выходе я получил «Basic networking tools (BaseOS)»
Установим данный пакет, пишем команду:
yum install net-tools
Вас спросят хотите ли вы установить данный пакет net-tools, нажмите «Y». Видим, что все успешно установилось.
Пробуем теперь запустить IFCONFIG. Как видим в таком варианте считывание информации, о настройках сети CentOS 8 куда приятнее.
Давайте теперь я отредактирую сетевые настройки для интерфейса ens33 и задам ему:
- IP — 192.168.31.31
- Маску — 255.255.255.0
- Шлюз — 192.168.31.1
- DNS — 192.168.31.1, 192.168.31.2
- Автоматическое включение при старте CentOS 8
В операционных системах CentOS настройки сетевых интерфейсах лежат по пути /etc/sysconfig/network-scripts/. Давайте посмотрим содержимое Для этого введите:
dir /etc/sysconfig/network-scripts/
Вы увидите конфигурационные файлы ваших сетевых интерфейсов, в моем случае, это ens33 и ens36
Чтобы настроить сеть на интерфейсах CentOS 8, вам необходимо отредактировать нужный конфигурационный файл. Для этого я воспользуюсь встроенным редактором vi. Пишем команду:
vim /etc/sysconfig/network-scripts/ifcfg-ens33
Чтобы начать редактировать файл нажмите клавишу «INSERT»
Далее чтобы задать статический IP-адрес приведите настройки вот к такому виду:
- TYPE=Ethernet
- BOOTPROTO=none (означает задать статические настройки), можно поменять значение на DHCP
- NAME=ens33
- ONBOOT=yes (иначе не будет стартовать при запуске)
- NAME=ens33 мое имя интерфейса
- UUID можно менять при клонировании конфигурационного файла
- IPADDR=192.168.31.31 мой IP-адрес
- PREFIX=24 маска 255.255.255.0
- DNS1=192.168.31.1 мой основной DNS
- DNS2=192.168.31.2 дополнительный DNS
- DOMAIN=root.pyatilistnik.org
- GATEWAY=192.168.31.1 основной шлюз
Чтобы сохранить настройки нажмите ESC, потом введите :wq если нужно выйти без сохранения введите :qa!
Чтобы получать динамический IP-адрес по DHCP, выставите в опции BOOTPROTO=dhcp и удалите пункты DNS, IPADDR, PREFIX, GATEWAY
осталось теперь поднять наш сетевой интерфейс для этого есть несколько методов, самый простой использование ifup введите:
ifup ens33
Как видим, у меня сетевой интерфейс стал в состояние подключено и я вижу через ifconfig его ip адрес.
Проверим через утилиту PING доступность контроллера домена и другого сервера, отлично пакеты ходят.
Ограничение прав суперпользователя
Пользователь root в дистрибутивах Linux обладает неограниченными правами. Однако, не стоит работать под ним постоянно.
При наличии больших возможностей достаточно сделать неверное действие, которое приведет к необратимым последствиям. Поэтому стоит создать дополнительный профиль пользователя, для которого можно установить некоторые ограничения.
Новый пользователь
Для начала создадим дополнительный профиль пользователя с именем «demo»:
adduser demo
Назначим для него пароль (в данном примере — «123»):
passwd 123
Далее, вводим новый пароль и повторяем его после следующего запроса.
Представление дополнительных привилегий
Созданный выше аккаунт «demo» получил стандартные права. В то же время, нам часто придется заниматься глубокой настройкой VPS-сервера, для чего понадобятся root-права.
Чтобы не изменять постоянно стандартный аккаунт на профиль администратора, можно сделать из demo «суперпользователя».
Для запуска команд с правами администратора, перед ними достаточно дописать команду sudo.
Далее – добавим профиль demo в группу «wheel». В CentOS пользователи этой группы могут пользоваться командой sudo. Сделать это можно следующей командой:
# gpasswd -a demo wheel
Все готово – после входа в CentOS как «demo» можно пользоваться расширенными правами, не боясь подвергнуть риску безопасность системы неосторожными действиями.
Запуск Apache 2.4 с модулем 1С внутри Docker контейнера
Про Apache и про Linux слышали, наверное, все. А вот про Docker пока нет, но он сильно набирает популярность последнее время и не зря. Поделюсь своим опытом и дам пошаговую инструкцию настройки веб-сервера Apache с модулем 1С внутри Docker контейнера на Linux хосте. При этом сам сервер 1С может находиться совсем на другой машине и на другой операционной системе
Это не важно, главное чтобы Apache смог достучаться до сервера 1С по TCP. В статье дам подробное пояснение по каждой используемой команде со ссылками на документацию по Docker, чтобы не создавалось ощущение непонятной магии
Также прилагаю git репозиторий с описанием всей конфигурации, можете попробовать развернуть у себя буквально за 10 минут.
Но мне просто надо, чтобы все работало и чтобы я имел возможность ручного изменения конфигурационных файлов
Большинству вариантам установки не требуется чрезмерная сложность, обусловленная взаимодействия с NetworkManager, достаточно ручного изменения конфигурационых файлов. Ниже приведён фрагмент настройки сетевого интерйеса с использованием DHCP без участия NetworkManager: {{{# cat /etc/sysconfig/network-scripts/ifcfg-eth0 DEVICE=»eth0″ BOOTPROTO=dhcp NM_CONTROLLED=»no» PERSISTENT_DHCLIENT=1 ONBOOT=»yes» TYPE=Ethernet DEFROUTE=yes PEERDNS=yes PEERROUTES=yes IPV4_FAILURE_FATAL=yes IPV6INIT=yes IPV6_AUTOCONF=yes IPV6_DEFROUTE=yes IPV6_PEERDNS=yes IPV6_PEERROUTES=yes IPV6_FAILURE_FATAL=no NAME=»eth0″ #}}}
или обычная настройка с использованием ‘статики’:
$ cat /etc/sysconfig/network-scripts/ifcfg-eth0 DEVICE="eth0" HWADDR="00:21:70:10:7E:CD" NM_CONTROLLED="no" ONBOOT="yes" BOOTPROTO=static # BOOTPROTO=dhcp IPADDR=10.16.1.106 NETMASK=255.255.255.0 # # the GATEWAY is sometimes in: /etc/sysconfig/network GATEWAY=10.16.1.1
после чего можно добавить другие распостранённые свойства, как например hostname или DNS-сервера:
$ cat /etc/sysconfig/network HOSTNAME=acme.example.com DNS1=10.16.1.112 DNS2=8.8.8.8 ## DNS2=76.242.0.28 SEARCH=example.com
Эти параметры являются опциональными, т.к. DHCP-сервер сам может оперировать ими. Initscript-ы могут определять такие параметры как Имя компьютера при помощи PTR-записей в правильно настроенной DNS-среде, но некоторым пользователям может потребоваться вручную изменять параметры. Полную документацию по initscript-ам можно найти при помощи:
rpm -qd initsсripts
даже в той среде, где отсутствует man-пакет и его зависимости.
Настройка сети из консоли (командами)
Настройка из консоли будет работать только до перезагрузки системы. Ее удобно применять для временного конфигурирования или проведения тестов.
Назначение IP-адреса или добавление дополнительного к имеющемуся:
ip a add 192.168.0.156/24 dev ens32
* в данном примере к сетевому интерфейсу ens32 будет добавлен IP 192.168.0.156.
Изменение IP-адреса:
ip a change 192.168.0.157/24 dev ens32
* однако, по факту, команда отработает также, как add.
Удаление адреса:
ip a del 192.168.163.157/24 dev ens32
Добавление маршрута по умолчанию:
ip r add default via 192.168.0.1
Добавление статического маршрута:
ip r add 192.168.1.0/24 via 192.168.0.18
Удаление маршрутов:
ip r del default via 192.168.160.1
ip r del 192.168.1.0/24 via 192.168.0.18
Подробнее про управление маршрутами в CentOS.
Часто встречающиеся ошибки 1С и общие способы их решения Промо
Статья рассчитана в первую очередь на тех, кто недостаточно много работал с 1С и не успел набить шишек при встрече с часто встречающимися ошибками. Обычно можно определить для себя несколько действий благодаря которым можно определить решится ли проблема за несколько минут или же потребует дополнительного анализа. В первое время сталкиваясь с простыми ошибками тратил уйму времени на то, чтобы с ними разобраться. Конечно, интернет сильно помогает в таких вопросах, но не всегда есть возможность им воспользоваться. Поэтому надеюсь, что эта статья поможет кому-нибудь сэкономить время.
Установка Filebeat для отправки логов в Logstash
Установим первого агента Filebeat на сервер с nginx для отправки логов веб сервера на сервер с ELK. Ставить можно как из общего репозитория, который мы подключали ранее, так и по отдельности пакеты. Как ставить — решать вам. В первом случае придется на все хосты добавлять репозиторий, но зато потом удобно обновлять пакеты. Если подключать репозиторий не хочется, можно просто скачать пакет и установить его.
Ставим на Centos.
# curl -L -O https://artifacts.elastic.co/downloads/beats/filebeat/filebeat-7.11.0-x86_64.rpm # rpm -vi filebeat-7.11.0-x86_64.rpm
В Debian/Ubuntu ставим так:
# curl -L -O https://artifacts.elastic.co/downloads/beats/filebeat/filebeat-7.11.0-amd64.deb# dpkg -i filebeat-7.11.0-amd64.deb
Или просто:
# yum install filebeat # apt install filebeat
После установки рисуем примерно такой конфиг /etc/filebeat/filebeat.yml для отправки логов в logstash.
filebeat.inputs: - type: log enabled: true paths: - /var/log/nginx/*-access.log fields: type: nginx_access fields_under_root: true scan_frequency: 5s - type: log enabled: true paths: - /var/log/nginx/*-error.log fields: type: nginx_error fields_under_root: true scan_frequency: 5s output.logstash: hosts: xpack.monitoring: enabled: true elasticsearch: hosts: ["http://10.1.4.114:9200"]
Некоторые пояснения к конфигу, так как он не совсем дефолтный и минималистичный. Я его немного модифицировал для удобства. Во-первых, я разделил логи access и error с помощью отдельного поля type, куда записываю соответствующий тип лога: nginx_access или nginx_error. В зависимости от типа меняются правила обработки в logstash. Плюс, я включил мониторинг и для этого указал адрес elastichsearch, куда filebeat передает данные мониторинга напрямую. Показываю это для вас просто с целью продемонстрировать возможность. У меня везде отдельно работает мониторинг на zabbix, так что большого смысла в отдельном мониторинге нет. Но вы посмотрите на него, возможно вам он пригодится. Чтобы мониторинг работал, его надо активировать в соответствующем разделе в Management — Stack Monitoring. И не забудьте запустить elasticsearch на внешнем интерфейсе. В первоначальной настройке я указал слушать только локальный интерфейс.
Запускаем filebeat и добавляем в автозагрузку.
# systemctl start filebeat # systemctl enable filebeat
Проверяйте логи filebeat в дефолтном системном логе. По умолчанию, он все пишет туда. Лог весьма информативен. Если все в порядке, увидите список всех логов в директории /var/log/nginx, которые нашел filebeat и начал готовить к отправке. Если все сделали правильно, то данные уже потекли в elasticsearch. Мы их можем посмотреть в Kibana. Для этого открываем web интерфейс и переходим в раздел Discover. Так как там еще нет индекса, нас перенаправит в раздел Managemet, где мы сможем его добавить.
Вы должны увидеть индекс, который начал заливать logstash в elasticsearch. В поле Index pattern введите nginx-* и нажмите Next Step.
На следующем этапе выберите имя поля для временного фильтра. У вас будет только один вариант — @timestamp, выбирайте его и жмите Create Index Pattern.
Новый индекс добавлен. Теперь при переходе в раздел Discover, он будет открываться по умолчанию со всеми данными, которые в него поступают.
Получение логов с веб сервера nginx на linux настроили. Подобным образом настраивается сбор и анализ любых логов. Можно либо самим писать фильтры для парсинга с помощью grok, либо брать готовые. Вот несколько моих примеров по этой теме:
- Мониторинг производительности бэкенда с помощью ELK Stack
- Сбор и анализ логов samba в ELK Stack
- Дашборд для логов nginx
Теперь сделаем то же самое для журналов windows.