Настраиваем сбор логов windows server в elk stack

Введение

У меня есть целый цикл статей про настройку и эксплуатацию ELK Stack для сбора логов с различных приложений. Так же я подробно рассказал, как установить и настроить ELK Stack себе, если у вас есть под него мощности и компетенции. В целом, там нет чего-то сильно сложного, но тем не менее, все равно необходимо повозиться, чтобы все заработало.

Не обязательно все это разворачивать и настраивать у себя, если хочется просто попробовать продукт, чтобы понять, нужен он вам или нет. Есть сервис — https://cloud.elastic.co, где можно за 2 минуты зарегистрировать и развернуть свой стэк на базе Elasticsearch и Kibana. Отличие от описанного мной способа разворачивания стека в том, что тут не будет Logstash. Во многих случаях можно обойтись без него, так что это не критично. Особенно для того, чтобы просто попробовать.

Итак, прежде чем приступить к настройке, зарегистрируйтесь в облаке и активируйте учетную запись.

Запуск Elastic Stack в Elastic Cloud

При первом входе в личный кабинет у вас будет возможность создать Deployment с Elasticsearch.

Дальше нужно выбрать платформу, где вы хотите произвести установку сервиса, и регион. Я для теста выбрал Google Cloud Platform во Frankfurt. Все остальное оставил по дефолту. Дальше внизу жмете Create Deployment и ждете, когда он развернется. Обычно 2-3 минуты.

Дожидаемся окончание процесса установки и переходим в Kibana.

Логинимся в Kibana с учетными данными, которые указаны в личном кабинете, в Deployment. Username обычно elastic и какой-то пароль. При первом входе вам предложат залить набор демо данных, чтобы посмотреть функционал системы. Если хотите — посмотрите. Я там и так все видел, поэтому отказываюсь :) Буду лить свои логи от apache.

После выбора оказываетесь на главной странице Kibana. По сути Elastic Stack вы уже развернули и он готов принимать данные. Вот так, быстро и просто все настроилось. И DevOps не нужен :)

Можете тут осмотреться и познакомиться с системой.

Настройка Kibana

Файл с настройками Кибана располагается по пути — /etc/kibana/kibana.yml. На начальном этапе можно вообще ничего не трогать и оставить все как есть. По-умолчанию kibana слушает только localhost и не позволяет подключаться удаленно. Это нормальная ситуация, если у вас будет на этом же сервере установлен nginx в качестве reverse proxy, который будет принимать подключения и проксировать их в кибана. Так и нужно делать в продакшене, когда системой будут пользоваться разные люди из разных мест. С помощью nginx можно будет разграничивать доступ, использовать сертификат, настраивать нормальное доменное имя и т.д. Если же у вас это тестовая установка, то можно обойтись без nginx. Для этого надо разрешить Кибана слушать внешний интерфейс и принимать подключения. Измените параметр server.host, Если хотите, чтобы она слушала все интерфейсы, укажите в качестве адреса, например вот так:

server.host: "0.0.0.0"

После этого Kibana надо перезапустить:

systemctl restart kibana.service

Теперь можно зайти в веб интерфейс по адресу http://ubuntu:5601. Kibana В процессе настройки будем подключаться напрямую к Kibana.

Почему Graylog?

Это не единственная и, возможно, далеко не самая лучшая платформа, но она широко распространена, прошла проверку временем и все еще поддерживается разработчиками.

Но, начать мы решили с анализа “конкурентов”.

Альтернативы

Splunk

Классный, модный, современный Splunk соответствует подавляющему большинству потребностей и скорее всего, может даже больше.

Но есть три момента, которые не понравились:

  • В нужной конфигурации решение платное.

  • Это закрытое решение.

  • Компания, без объяснений причин покинула рынок РФ.

Но, если вас это не смущает, немного полезной информации по платформе:

  • Обзорная статья на habr.

  • Сравнение платной и бесплатных версий.

С этим “претендентом” не получилось, идем дальше.

Например, тут и тут его часто сравнивают с ELK, который и рассмотрим.

ELK

Стек продуктов Elasticsearch, Logstash, Kibana, образующий аббревиатуру ELK — это очень популярное и еще более настраиваемое решение, по сравнению с предыдущим. Более того, это решение open source.

Что же пошло не так?

  • Некоторые фишки все же платные, например, уведомления и контроль доступа (однако, после некоторых событий часть данного функционала стала бесплатной).

  • Ресурсоемкость — требуется очень много ресурсов.

  • Систему сложно настроить, “из коробки” она работать не будет.

  • Еще нужно упомянуть Open Distro, которая развивается на базе ELK, но полностью бесплатная, что не отменяет ресурсоемкость и сложность в настройке.

Немного полезной информации:

  • Инструкция по установке и настройке (eng).

  • Цикл статей на habr: часть 1, часть 2, часть 3.

Остановились на Graylog

Двух претендентов отсеяли, остался виновник торжества — Graylog, выделяющийся по следующим причинам:

  • Это open source решение.

  • Бесплатная версия имеет все необходимое.

  • Функционал небольшой, что удобно, ничего лишнего (для наших задач).

  • “Из коробки” решение уже работает, нужны минимальные настройки.

  • По сравнению с ELK ресурсоемкость значительно ниже.

Далее, мы предлагаем лонгрид по настройке и установке Graylog.

Конфигурирование

  • source — содержит информацию об источнике данных;
  • match — содержит информацию о том, куда нужно передавать полученные данные;
  • include — содержит информацию о типах файлов;
  • system — содержит настройки системы.

Source: откуда брать данные

# Принимаем события с порта 24224/tcp
<source>
  type forward
  port 24224
</source>

# http://this.host:9880/myapp.access?json={"event":"data"}
<source>
  type http
  port 9880
</source>
# generated by http://this.host:9880/myapp.access?json={"event":"data"}
tag: myapp.access
time: (current time)
record: {"event":"data"}

Match: что делать с данными

#  Получаем события с порта 24224
<source>
  type forward
  port 24224
</source>

# http://this.host:9880/myapp.access?json={"event":"data"}
<source>
  type http
  port 9880
</source>

#Берём события, помеченные тэгами "myapp.access" 
#и сохраняем их в файле/var/log/fluent/access.%Y-%m-%d
#данные можно разбивать на порции с помощью опции time_slice_format.

<match myapp.access>
  type file
  path /var/log/fluent/access
</match>
  • символ * означает соответствие любой части тэга (если указать <match a.*>, то a.b будет соответствовать заданному условию, а a.b.c — нет);
  • ** означает соответствие любому тэгу (если указать <match **>, то заданному условию будут соответствовать и a, и a.b., и a.b.c);
  • {x, y, z} означает соответствие по крайней мере одному из тэгов, указанных в фигурных скобках (если указать <match {a, b}>, то а и b будут соответствовать заданному условию, а с — нет);
  • фигурные скобки можно использоовать в сочетании с символами * и **, например: <match {a, b}. c.*> или <match {a.*, b}.c>*;
  • <match a b> означает соответствие тэгам a и b одновременно;
  • <match a.** b.*> означает соответствие тэгам a, a.b и a.b.c (первая часть) и b.d (вторая часть).
<match **>
  type blackhole_plugin
</match>

<match myapp.access>
  type file
  path /var/log/fluent/access
</match>

<match myapp.access>
  type file
  path /var/log/fluent/access
</match>

<match **>
  type blackhole_plugin
</match>

Include: объединяем конфигурационные файлы

include config.d/*.conf
# абсолютный путь к файлу
include /path/to/config.conf

# можно указывать и относительный путь
include extra.conf

# маска
include config.d/*.conf

# http
include http://example.com/fluent.conf

Сбор и анализ логов Windows Fileserver

Для файлового сервера настраиваем сбор логов в ELK Stack точно так же, как я показал выше. Для визуализации данных я настроил отдельный дашборд в Kibana со следующей информацией:

  • Имена пользователей, которые обращаются к файлам (поле event_data.SubjectUserName)
  • Типы запросов, которые выполняются (поле file_action)
  • Список доступа к файлам (формируется из сохраненного фильтра поиска)

Возможно, кому-то будет актуально выводить на дашборд еще и информацию об именах файлов, к которым идет доступ. Информация об этом хранится в поле event_data.ObjectName. Лично я не увидел в этом необходимости.

Подготовка

Скопируем логи 1с с Windows сервера на Ubuntu с помощью утилиты rsync, входящей в пакет cygwin.com На стороне сервера Ubuntu настраиваем сервис rsync

apt-get install rsync

Настраиваем параметры в /etc/rsyncd.conf

uid = user
gid = root
use chroot = yes
max connections = 50
pid file = /var/run/rsyncd.pid
log file = /var/log/rsync.log


path = /home/files/       # каталог логов
hosts allow = 192.168.0.1 # адрес сервера 1с
hosts deny = *
#list = true
read only = false
#auth users = s1
#secrets file = /etc/rsyncd.secrets

Создаем bat file на сервере 1с

set BACKUP_DIR=E:\1c\complex\syslog\
cd /d %BACKUP_DIR%
C:\cygwin64\bin\rsync.exe -avz --inplace --append --chmod=u=rw --log-file=c:\bat\rsync.log ./*.mlg [email protected]::share/1c/ 

Обязательно указываем параметр — копировать только изменения для уменьшения трафика. И чтобы не перезаписывать весь файл, иначе в ELK данные будут дублироваться. запускаем

C:\cygwin64\bin\rsync.exe -avz --inplace --append --chmod=u=rw --log-file=c:\bat\rsync.log ./*.mlg [email protected]::share/1c/
sending incremental file list
1cv7.mlg

sent 298 bytes  received 35 bytes  666.00 bytes/sec
total size is 68,683,437  speedup is 206,256.57

Проверяем файл в каталоге назначения на сервере Ubuntu Добавляем задание в планировщик заданий с периодом 5 минут.

Обработка сообщений

  • Все сообщения приходят из Input (их может быть много) и попадают на обработку в привязанный к нему RuleSet. Если это явно не задано, то сообщения попадут в RuleSet по-умолчанию. Все директивы обработки сообщений, не вынесенные в отдельные RuleSet-блоки, относятся именно к нему. В частности, к нему относятся все директивы из традиционного формата конфигов:
  • к Input привязан список парсеров для разбора сообщения. Если явно не задано, будет использоваться список парсеров для разбора традиционного формата syslog
  • Парсер выделяет из сообщения свойства. Самые используемые:
    • — сообщение
    • — сообщение целиком до обработки парсером
    • , — DNS имя и IP адрес хоста-отправителя
    • , — facility в числовой и текстовой форме
    • , — то же для severity
    • — время из сообщения
    • — поле TAG
    • — поле TAG с отрезанным id процесса: ->
    • весь список можно посмотреть тут
  • RuleSet содержит список правил, правило состоит из фильтра и привязанных к нему одного или нескольких Actions
  • Фильтры — логические выражения, с использованием свойств сообщения. Подробнее про фильтры
  • Правила применяются последовательно к сообщению, попавшему в RuleSet, на первом сработавшем правиле сообщение не останавливается
  • Чтобы остановить обработку сообщения, можно использовать специальное discard action: или в легаси-формате.
  • Внутри Action часто используются шаблоны. Шаблоны позволяют генерировать данные для передачи в Action из свойств сообщения, например, формат сообщения для передачи по сети или имя файла для записи. Подробнее про шаблоны
  • Как правило, Action использует модуль вывода(«om…») или модуль изменения сообщения(«mm…»). Вот некоторые из них:
    • omfile — вывод в файл
    • omfwd — пересылка по сети, через udp или tcp
    • omrelp — пересылка по сети по протоколу RELP
    • onmysql, ompgsql, omoracle — запись в базу
    • omelasticsearch — запись в ElasticSearch
    • omamqp1 — пересылка по протоколу AMQP 1.0
    • весь список модулей вывода

5 Octopussy

Я даю ноль из десяти наименованию продукта, но Octopussy может быть хорошим выбором, если ваши потребности просты, и вы задаетесь вопросом о том, что же такое суета, связанная с конвейерами, приемом, агрегацией и т. д

По моему мнению, Octopussy покрывает потребности большинства продуктов (оценочная статистика бесполезна, но, если бы мне пришлось угадывать, я бы сказал, что в реальном мире она учитывает 80% случаев использования)

У Octopussy нет отличного пользовательского интерфейса:

но он компенсирует скорость и отсутствие раздувания.

Исходный код доступен на GitHub, как и ожидалось, и я думаю, что он заслуживает серьезного изучения.

Быстрый поиск в справочниках по наименованию, с использованием svcsvc.dll

По аналогии с http://infostart.ru/public/14286/, недавно узнал что в svcsvc.dll несколько обновился функционал, в частности был добавлен метод AddString().
В прилагаемом коде показан запрос, реализованный методами ВК 1SQlite, т.е. только для DBF.
Это только пример. Т.е. если например у справочника отсутствует поле «Наименование», то скорее всего будет ошибка.
Тем не менее критика приветствуется)))
Необходимые ВК: 1SQlite, FORMEX, svcsvc.dll (отсюда: http://www.1cpp.ru/forum/YaBB.pl?num=1373266553).

p.s.
Спасибо огромное уважаемому ADirks за все эти прекрасные плюшки, и помощь в их освоении)))

Архитектура

Надежность – одно из ключевых требований, предъявляемых к используемым системам

По этой причине ELK был установлен в отказоустойчивой конфигурации: нам важно быть уверенными, что логи продолжат собираться в случае недоступности части серверов

Количество VM Назначение Используемое ПО
2 Балансировщики нагрузки Keepalived + HAproxy + nginx
4 Получение и обработка входящих журналов Logstash
3 Master-ноды кластера Elasticsearch Elasticsearch
6 Data-ноды кластера Elasticsearch Elasticsearch
1 Пользовательский интерфейс Kibana

Так выглядит архитектура нашей инсталляции ELK:

Настройка Elasticsearch

Настройки Elasticsearch находятся в файле /etc/elasticsearch/elasticsearch.yml. На начальном этапе нас будут интересовать следующие параметры:

path.data: /var/lib/elasticsearch # директория для хранения данных
network.host: 127.0.0.1 # слушаем только локальный интерфейс

По-умолчанию Elasticsearch слушает все сетевые интерфейсы. Нам это не нужно, так как данные в него будет передавать logstash, который будет установлен локально

Обратите внимание на параметр path.data для директории с данными. Чаще всего индексы будут занимать значительное место

Если останется меньше 10% свободного места elasticsearch уходит в глухой read-only и вывести сервис из этого состояния – ещё та задача. Подумайте заранее, где вы будете хранить логи. Остальные настройки — дефолтные. После изменения настроек, перезапустите службу:

systemctl restart elasticsearch.service

Смотрим, что получилось:

netstat -tulnp | grep 9200
tcp6 0 0 127.0.0.1:9200 :::* LISTEN 14130/java

Elasticsearch работает на локальном интерфейсе — слушает ipv6, про ipv4 ни слова. Но его он тоже слушает, так что все в порядке. Переходим к установке kibana.

Работаем с журналами посредством запросов SQL

Утилита Log Parser появилась на свет в начале «нулевых» и с тех пор успела обзавестись официальной графической оболочкой. Тем не менее актуальности своей она не потеряла и до сих пор остается для меня одним из самых любимых инструментов для анализа логов. Загрузить утилиту можно в Центре Загрузок Microsoft, графический интерфейс к ней ― в галерее Technet. О графическом интерфейсе чуть позже, начнем с самой утилиты.

О возможностях Log Parser уже рассказывалось в материале «LogParser — привычный взгляд на непривычные вещи», поэтому я начну с конкретных примеров.

Для начала разберемся с текстовыми файлами ― например, получим список подключений по RDP, заблокированных нашим фаерволом. Для получения такой информации вполне подойдет следующий SQL-запрос:

Посмотрим на результат:

Смотрим журнал Windows Firewall.

Разумеется, с полученной таблицей можно делать все что угодно ― сортировать, группировать. Насколько хватит фантазии и знания SQL.

Log Parser также прекрасно работает с множеством других источников. Например, посмотрим откуда пользователи подключались к нашему серверу по RDP.

Работать будем с журналом TerminalServices-LocalSessionManager\Operational.

Данные будем получать таким запросом:

Смотрим, кто и когда подключался к нашему серверу терминалов.

Особенно удобно использовать Log Parser для работы с большим количеством файлов журналов ― например, в IIS или Exchange. Благодаря возможностям SQL можно получать самую разную аналитическую информацию, вплоть до статистики версий IOS и Android, которые подключаются к вашему серверу.

В качестве примера посмотрим статистику количества писем по дням таким запросом:

Если в системе установлены Office Web Components, загрузить которые можно в Центре загрузки Microsoft, то на выходе можно получить красивую диаграмму.

Выполняем запрос и открываем получившуюся картинку…

Любуемся результатом.

Следует отметить, что после установки Log Parser в системе регистрируется COM-компонент MSUtil.LogQuery. Он позволяет делать запросы к движку утилиты не только через вызов LogParser.exe, но и при помощи любого другого привычного языка. В качестве примера приведу простой скрипт PowerShell, который выведет 20 наиболее объемных файлов на диске С.

Ознакомиться с документацией о работе компонента можно в материале Log Parser COM API Overview на портале SystemManager.ru.

Благодаря этой возможности для облегчения работы существует несколько утилит, представляющих из себя графическую оболочку для Log Parser. Платные рассматривать не буду, а вот бесплатную Log Parser Studio покажу.

Интерфейс Log Parser Studio.

Основной особенностью здесь является библиотека, которая позволяет держать все запросы в одном месте, без россыпи по папкам. Также сходу представлено множество готовых примеров, которые помогут разобраться с запросами.

Вторая особенность ― возможность экспорта запроса в скрипт PowerShell.

В качестве примера посмотрим, как будет работать выборка ящиков, отправляющих больше всего писем:

Выборка наиболее активных ящиков.

При этом можно выбрать куда больше типов журналов. Например, в «чистом» Log Parser существуют ограничения по типам входных данных, и отдельного типа для Exchange нет ― нужно самостоятельно вводить описания полей и пропуск заголовков. В Log Parser Studio нужные форматы уже готовы к использованию.

Помимо Log Parser, с логами можно работать и при помощи возможностей MS Excel, которые упоминались в материале «Excel вместо PowerShell». Но максимального удобства можно достичь, подготавливая первичный материал при помощи Log Parser с последующей обработкой его через Power Query в Excel.

Контроль событий ИБ

В мае текущего года мы решали задачу прохождения сертификации PCI DSS — стандарту безопасности данных индустрии платежных карт. Одним из требований соответствия данному стандарту является наличие системы контроля событий информационной безопасности. На момент прохождения сертификации стек ELK уже работал и собирал данные с большей части эксплуатируемого оборудования, поэтому было принято решение использовать его в качестве системы контроля событий ИБ. В ходе подготовки к аудиту, для всех системных компонентов Техносерв Cloud была настроена отправка в ELK событий безопасности, в том числе следующих:

• любой доступ к данным заказчиков;
• все действия, совершенные с использованием административных полномочий, на серверах и сетевом оборудовании облачной платформы;
• любой доступ к журналам регистрации событий системных компонентов Техносерв Cloud;
• любой доступ пользователей к системным компонентам платформы;
• добавление, изменение и удаление учетных записей;
• запуск и остановка системных компонентов платформы;
• создание и удаление объектов системного уровня.

Для демонстрации наличия перечисленных выше событий в системе были подготовлены представления Kibana. На скриншотах ниже видны попытки доступа пользователей на наши сервера и записи о выполнении команд из-под sudo.

Зафиксированные неуспешные попытки доступа

Выполнение команд от имени суперпользователя

Кратко про конфигурационные файлы

  1. Networks и volumes были взяты из исходного docker-compose.yml (тот где целиком стек запускается) и думаю, что сильно здесь на общую картинку не влияют.
  2. Мы создаём один сервис (services) logstash, из образа docker.elastic.co/logstash/logstash:6.3.2 и присваиваем ему имя logstash_one_channel.
  3. Мы пробрасываем внутрь контейнера порт 5046, на такой же внутренний порт.
  4. Мы отображаем наш файл настройки каналов ./config/pipelines.yml на файл /usr/share/logstash/config/pipelines.yml внутри контейнера, откуда его подхватит logstash и делаем его read-only, просто на всякий случай.
  5. Мы отображаем директорию ./config/pipelines, где у нас лежат файлы с настройками каналов, в директорию /usr/share/logstash/config/pipelines и тоже делаем её read-only.

logstash_one_channel | Unable to retrieve license information from license server {:message=>«Elasticsearch Unreachable: [http://elasticsearch:9200/]logstash_one_channel | Pipeline started successfully logstash_one_channel | logstash_one_channel | X-Pack is installed on Logstash but not on Elasticsearch. Please install X-Pack on Elasticsearch to use the monitoring feature. Other features may be available.logstash_one_channel | logstash_one_channel | ogstash_one_channel | Attempted to resurrect connection to dead ES instance, but got an error. {:url=>«elasticsearch:9200/», :error_type=>LogStash::Outputs::ElasticSearch::HttpClient::Pool::HostUnreachableError, :error=>«Elasticsearch Unreachable: [http://elasticsearch:9200/] elasticsearch»}logstash_one_channel | logstash_one_channel | Attempted to resurrect connection to dead ES instance, but got an error. {:url=>«elasticsearch:9200/», :error_type=>LogStash::Outputs::ElasticSearch::HttpClient::Pool::HostUnreachableError, :error=>«Elasticsearch Unreachable: [http://elasticsearch:9200/] elasticsearch»}elasticsearch

Настраиваем пересылку логов в Mikrotik

Теперь настраиваем в роутере хранение логов на удаленном сервере. Для этого заходим в раздел System -> Logging, выбираем закладку Actions, два раза щелкаем по строчке remote. Открывается окно настроек. В нем вводим адрес удаленного сервера сбора логов. Порт на свое усмотрение либо оставляем по-умолчанию, либо меняем на свой. Больше ничего добавлять не надо.

Дальше в разделе Rules создаем необходимое правило хранения:

Все готово. Теперь все наши логи будут храниться на удаленном сервере. Необходимо не забыть настроить ротацию логов, дабы в один прекрасный день они не заняли все свободное место.

Если вы используете ELK Stack для централизованного сбора логов, то у меня есть статья по отправке логов mikrotik в elk stack.

Напоминаю, что данная статья является частью единого цикла статьей про Mikrotik.

Помогла статья? Подписывайся на telegram канал автора

Рекомендую полезные материалы по схожей тематике:

Онлайн курсы по Mikrotik

Если у вас есть желание научиться работать с роутерами микротик и стать специалистом в этой области, рекомендую пройти курсы по программе, основанной на информации из официального курса MikroTik Certified Network Associate. Помимо официальной программы, в курсах будут лабораторные работы, в которых вы на практике сможете проверить и закрепить полученные знания. Все подробности на сайте .

Стоимость обучения весьма демократична, хорошая возможность получить новые знания в актуальной на сегодняшний день предметной области. Особенности курсов:

  • Знания, ориентированные на практику;
  • Реальные ситуации и задачи;
  • Лучшее из международных программ.
  • Инструкция о том, как быстро выполнить настройку mikrotik.
  • Использование протокола Layer7 для блокировки сайтов средствами Микротик.
  • Настройка простых правил фаервола для защиты локальной сети.
  • Создание единой wifi сети из множества точек доступа mikrotik с помощью capsman.
  • 2 провайдера и 2 wan интерфейса для создания отказоустойчивой связи с интернет.

Заключение

Онлайн курс «DevOps практики и инструменты»

Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, научиться непрерывной поставке ПО, мониторингу и логированию web приложений, рекомендую познакомиться с онлайн-курсом «DevOps практики и инструменты» в OTUS. Курс не для новичков, для поступления нужны базовые знания по сетям и установке Linux на виртуалку. Обучение длится 5 месяцев, после чего успешные выпускники курса смогут пройти собеседования у партнеров.

Проверьте себя на вступительном тесте и смотрите программу детальнее по .

Онлайн курс «DevOps практики и инструменты»

Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, научиться непрерывной поставке ПО, мониторингу и логированию web приложений, рекомендую познакомиться с онлайн-курсом «DevOps практики и инструменты» в OTUS. Курс не для новичков, для поступления нужны базовые знания по сетям и установке Linux на виртуалку. Обучение длится 5 месяцев, после чего успешные выпускники курса смогут пройти собеседования у партнеров.

Проверьте себя на вступительном тесте и смотрите программу детальнее по .

Заключение

Я привел частный случай настройки хранения логов с удаленных устройств. Решение в лоб. В простых случаях этого достаточно. Лично мне удобно смотреть информацию в текстовых файлах. Это требуется редко, сделано на всякий случай для расследования инцидентов, если таковые возникают. Эту же задачу, к примеру, можно решить с помощью заббикс. Я уже показывал, как мониторить с помощью zabbix лог файлы. Приведенное решение легко переделать в хранение логов.

Для более удобного сбора и последующего просмотра информации существуют готовые решения с написанными веб панелями. Я посмотрел на некоторые из них. Что-то мне показалось слишком сложным в настройке, где-то веб интерфейс не понравился. Для себя остановился на приведенном варианте.

Онлайн курс Основы сетевых технологий

Теоретический курс с самыми базовыми знаниями по сетям. Курс подходит и начинающим, и людям с опытом. Практикующим системным администраторам курс поможет упорядочить знания и восполнить пробелы. А те, кто только входит в профессию, получат на курсе базовые знания и навыки, без воды и избыточной теории. После обучения вы сможете ответить на вопросы:

  • На каком уровне модели OSI могут работать коммутаторы;
  • Как лучше организовать работу сети организации с множеством отделов;
  • Для чего и как использовать технологию VLAN;
  • Для чего сервера стоит выносить в DMZ;
  • Как организовать объединение филиалов и удаленный доступ сотрудников по vpn;
  • и многое другое.

Уже знаете ответы на вопросы выше? Или сомневаетесь? Попробуйте пройти тест по основам сетевых технологий. Всего 53 вопроса, в один цикл теста входит 10 вопросов в случайном порядке. Поэтому тест можно проходить несколько раз без потери интереса. Бесплатно и без регистрации. Все подробности на странице .

Заключение

Вот таким относительно простым и эффективным способом можно облегчить управление файловыми серверами, особенно когда их много. Я раньше и представить не мог, что можно так удобно собрать всю информацию с логов и вывести в наглядном виде. А потом еще и фильтровать все это по нужным параметрам практически на лету.

В следующей статье расскажу, как сделать то же самое, только для файловых серверов на windows. Там примерно такой же dashboard будет, но сбор и анализ логов другие.

Онлайн курс «DevOps практики и инструменты»

Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, научиться непрерывной поставке ПО, мониторингу и логированию web приложений, рекомендую познакомиться с онлайн-курсом «DevOps практики и инструменты» в OTUS. Курс не для новичков, для поступления нужны базовые знания по сетям и установке Linux на виртуалку. Обучение длится 5 месяцев, после чего успешные выпускники курса смогут пройти собеседования у партнеров.

Проверьте себя на вступительном тесте и смотрите программу детальнее по .

Рейтинг
( Пока оценок нет )
Понравилась статья? Поделиться с друзьями:
Техноарена
Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: