Что такое log pass
Где посмотреть и как читать логи с ошибками сервера
Блоги, форумы, посадочные страницы и другие интернет-ресурсы представляют собой совокупность графического, текстового, аудио- и видео-контента, размещенного на веб-страницах в виде кода. Чтобы обеспечить к ним доступ пользователей через интернет, файлы размещают на серверах. Это аппаратное обеспечение (персональный компьютер или рабочая станция), на жестком диске которого и хранится код. Ключевые функции выполняются без участия человека, что актуально для всех типов оборудования, включая виртуальный выделенный сервер. Но это не означает, что контроль не осуществляется. Большинство событий, которые происходят при участии оборудования, пользователей и софта, включая ошибки, логи сервера фиксируют и сохраняют. Из этой статьи вы узнаете, что они собой представляют, зачем нужны, и как их читать.
Что такое логи
Это текстовые файлы, которые хранятся на жестком диске сервера. Создаются и заполняются в автоматическом режиме, в хронологическом порядке. В них записываются:
Посмотреть логи сервера может каждый, у кого есть к ним доступ, но непосвященному обывателю этот набор символов может показаться бессмысленным. Интерпретировать записи и получить пользу после прочтения проще профессионалу.
Классификация логов
Для каждой разновидности софта предусмотрены соответствующие файлы. Все логи сервера могут храниться на одном диске или даже на отдельном сервере. Существует довольно много разновидностей логов, вот наиболее распространенные:
Записи в системные журналы выполняет установленный софт.
Зачем нужны логи
Анализ логов сервера — неотъемлемая часть работы системного администратора или веб-разработчика. Обрабатывая их, специалисты получают массу полезных сведений. Используются в следующих целях:
После изучения информации можно получить точную статистику в виде сводных цифр, информацию о юзерах, выявить поведенческие закономерности пользовательских групп.
Как мы работаем с логами (сбор, хранение, анализ при помощи Graylog)
Всем привет! В этой статье мы хотим поделиться нашим опытом использования полезной платформы Graylog, которая ежедневно помогает собирать, надежно хранить и анализировать логи с десятков серверов, окутанных заботой нашей поддержки 🙂
Это первая часть статьи, в которой мы собрали в одном месте информацию, которая поможет установить и настроить Graylog, плюс, расскажем почему мы остановились имено на этой платформе.
Вторая часть, которая появится совсем скоро, будет содержать примеры использования и их реализацию.
Какую задачу мы решали?
Можно долго рассуждать о важности серверных логов и привести много примеров ситуаций, в которых они жизненно необходимы, но так как речь пойдет именно о сторонней системе и ее особенностях, то выделим ряд важных моментов:
Удобно, когда все логи хранятся в одном месте.
Круто, когда есть отчеты и возможность автоматически их проанализировать.
Полезно, когда логи можно посмотреть даже при “упавшем” сервере или после того как злоумышленник “прибрался” за собой.
Бесценно, когда о возникшей ошибке в логах будет оповещение.
Сформулировали задачу так:
“Подобрать бесплатное open source решение для сбора и анализа логов, не перегруженное функционалом, производительное, простое в установке и использовании.”
Почему Graylog?
Это не единственная и, возможно, далеко не самая лучшая платформа, но она широко распространена, прошла проверку временем и все еще поддерживается разработчиками.
Но, начать мы решили с анализа “конкурентов”.
Альтернативы
Splunk
Классный, модный, современный Splunk соответствует подавляющему большинству потребностей и скорее всего, может даже больше.
Но есть три момента, которые не понравились:
В нужной конфигурации решение платное.
Это закрытое решение.
Компания, без объяснений причин покинула рынок РФ.
Но, если вас это не смущает, немного полезной информации по платформе:
С этим “претендентом” не получилось, идем дальше.
Например, тут и тут его часто сравнивают с ELK, который и рассмотрим.
Что же пошло не так?
Некоторые фишки все же платные, например, уведомления и контроль доступа (однако, после некоторых событий часть данного функционала стала бесплатной).
Систему сложно настроить, “из коробки” она работать не будет.
Еще нужно упомянуть Open Distro, которая развивается на базе ELK, но полностью бесплатная, что не отменяет ресурсоемкость и сложность в настройке.
Немного полезной информации:
Инструкция по установке и настройке (eng).
Остановились на Graylog
Это open source решение.
Бесплатная версия имеет все необходимое.
Функционал небольшой, что удобно, ничего лишнего (для наших задач).
“Из коробки” решение уже работает, нужны минимальные настройки.
По сравнению с ELK ресурсоемкость значительно ниже.
Далее, мы предлагаем лонгрид по настройке и установке Graylog.
Установка и базовые настройки Graylog
В примере используем CentOS 8.
Prerequisites
Обновления обязательны, также установим пакеты для удобства работы, top-ы, etc.
смотрим где лежат сертификаты (пока самоподписанные)
кладём crt и key файлы в /etc/cockpit/ws-certs.d/
Firewall
(настройки будут индивидуальными для вашей сети, все команды даны для примера)
Кокпит должен быть доступен только админам, снаружи ему делать нечего. Создадим зону для интранета и добавим нужные адреса подсетей:
После добавления/удаления перезагрузим сервис:
Проконтролируем, что все правила верные:
SELinux
(настраиваем, а не отключаем его. )
Устанавливаем пакеты, если ещё не установлены, разрешаем апачу подключения:
Проверяем порты 9000, 9200, 27017:
Elastic Search
Импортируем ключ репозитория, добавляем конфигурационный файл репозитория, устанавливаем (вместо vim можно использовать nano, mcedit или любой другой редактор по вашему выбору):
Чтобы Elasticsearch работал с Graylog, необходимо установим имя кластера “graylog”:
Запускается довольно долго, в зависимости от конфигурации сервера или виртуальной машины. Проверяем:
Файлы Elasticsearch расположены здесь:
MongoDB
Добавляем конфигурационный файл репозитория:
Файлы MongoDB расположены здесь:
Graylog
Ссылки на оригинальную документацию:
Graylog не запускается самостоятельно (об этом есть сообщение в процессе установки).
Сначала настраиваем, потом пробуем запускать.
Генерируем хеш пароля:
Параметры эластика только для первого запуска, дальше конфигурация будет производиться уже из веб-интерфейса грейлога:
Также полезно будет настроить Email transport:
Download files → В секции GeoLite2 City → Get Permalinks (1, 2)
В Services → Manage License Keys (3)
Нажимаем «Generate new license key» создастся новый License Key. На email придёт уведомление о создании ключа.
Лицензия активируется в течение 5 минут.
Подставляем в ссылки, полученные на первом шаге ключ, полученный на втором шаге, загружаем файл с базой и файл контрольной суммы:
Проверяем целостность архива:
Установка GeoLite2 Database выполнена.
Немного ждём, затем смотрим логи запуска:
Возникают из-за того что установлена версия Enterprise, но нет соответствующей лицензии.
Заходим браузером, проверяем что веб-интерфейс доступен, можем залогиниться в веб-интерфейс:
Нас встречает мини-учебник по настройке:
NGINX
Создаём конфиг nginx, размещаем файлы сертификатов в /etc/nginx/ssl (у нас будут в одном файле сертификат + ключ):
Если получили ошибку:
То это из-за SELinux. Исправляем:
Немного реконфигурим Graylog:
Теперь Graylog слушает только на локалхосте, если открывали порт 9000, то необходимости в нём больше нет:
Размер БД
Установим размер индекса, так как виртуальный сервер имеет ограниченный объём диска.
System → Indices → Default index set → Edit
В Index Rotation Configuration:
В Index Retention Configuration:
Итого общий размер индексов будет не более 32GiB
Подведем итоги
Если вы дочитали и все еще с нами, то на этом закончим первую часть, где мы разобрали чем нам приглянулся Graylog и как можно его установить / настроить.
Надеемся, что наш опыт будет вам полезен.
Вопросы в комментариях приветствуются 🙂
Во второй части мы расскажем, как используя Graylog можно собирать системные логи и логи веб-сервера.
Дата-центр ITSOFT — размещение и аренда серверов и стоек в двух дата-центрах в Москве. За последние годы UPTIME 100%. Размещение GPU-ферм и ASIC-майнеров, аренда GPU-серверов, лицензии связи, SSL-сертификаты, администрирование серверов и поддержка сайтов.
Собираем, парсим и отдаём логи с помощью Logstash
Так уж сложилось, что по долгу работы мне приходится много времени уделять логам. Это и участие в выработке правил и политик сбора/хранения/использования логов, это и разбор разных инцидентов и обнаружение аномалий. За сутки наши программы, сервисы и серверы генерируют ОЧЕНЬ большое количество логов. И потребность копания в логах растёт постоянно.
Мне довелось поработать с коммерческими лог-менеджмент продуктами типа ArcSight, RSA Envision, Q1 Labs. У этих продуктов есть как плюсы, так и минусы. Но в статье речь пойдёт не о них.
Речь будет о Logstash.
Что же такое Logstash? Зачем он нужен? Что он умеет?
Logstash — это орудие для сбора, фильтрации и нормализации логов. Оно является бесплатным и open source приложением. Тип лицензии Apache 2.0.
Первой моё знакомство с LS (Logstash) произошло более года назад, и с того времени я очень плотно на него подсел. Мне нравится его идея и возможности. Для меня Logstash — это подобие мясорубки. Неважно что заходит в неё, но после не сложных манипуляций, на выходе всегда красиво и понятно оформленная информация.
Формат конфигурационного файла Logstash’а прост и понятен. Он состоит из трёх частей:
Входных, фильтрующих и выходных (или выходящих?) блоков может быть любое количество. Всё зависит от ваших потребностей и возможностей железа.
Пустые строки и строки начинающиеся с # — Logstash игнорирует. Так что комментирование конфигурационных файлов не вызовет никаких проблем.
1. INPUT
Пример конфигурации, для работы с локальными лог-файлами:
Построчное описание настроек:
тип/описание лога. При использовании нескольких входных блоков, удобно их разделять для последующих действий в filter или output.
указывается путь к лог-файлам, которые подлежат обработке. Путь должен быть абсолютным (/path/to/logs/), а не относительным (../../some/other/path/).
исключает из обработки файлы с соответствующими расширениями.
ждёт появления новых сообщений в конце файла. При обработки уже имеющихся логов, можно выставить «beginning», тогда обработка логов будет происходить построчно с начала файлов.
как часто (в секундах) проверять файлы на изменения. При больших значения, уменьшится частота системных вызовов, но так же увеличится время чтения новых строк.
время (в секундах) через которое будет обновлён список обрабатываемых файлов указанных в path.
Пример конфигурации, для работы с логами удалённых сервисов:
Построчное описание настроек:
тип/описание лога.
время (в секундах), по истечении которого не активное tcp соединение будет закрыто. Значение -1 — соединение всегда будет открыто.
в этом случае Logstash становится сервером, и начинает слушать на 192.168.3.12:3337. При установке mode => «client» Logstash будет присоединятся к удалённому ip:port для забора логов.
2. FILTER
В данном блоке настраиваются основные манипуляции с логами. Это может быть и разбивка по key=value, и удаление ненужных параметров, и замена имеющихся значений, и использование geoip или DNS запросов для ип-адресов или названий хостов.
На первый взгляд применение фильтров может показаться сложным и нелогичным, но это не совсем так.
Пример конфигурационного файла для основной нормализации логов:
Построчное описание настроек:
тип/описание лога. Здесь надо указать тот тип (type), который прописан в блоке input для которого будет происходить обработка.
путь к каталогу, содержащим шаблоны обработки логов. Все файлы находящиеся в указанной папке будут загружены Logstash, так что лишние файлы там не желательны.
указывается шаблон разборки логов. Шаблон можно использовать либо в конфигурационном файле, либо из файла шаблонов. Что бы не путаться, я для каждого формата логов создаю отдельный шаблонный файл.
С помощью grok фильтра можно структурировать большую часть логов — syslog, apache, nginx, mysql итд, записанных в определённом формате.
Logstash имеет более 120 шаблонов готовых регулярных выражений (regex). Так что написание фильтров для обработки большинства логов не должно вызвать особого страха или недопонимания.
Формат шаблонов относительно простой — NAME PATTERN, то есть построчно указывается имя шаблона и ему соответствующее регулярное выражение. Пример:
Можно использовать любой ранее созданный шаблон:
Шаблоны можно так же и комбинировать:
Допустим формат логов у нас следующий:
55.3.244.1 GET /index.html 15824 0.043
Среди готовых шаблонов, к счастью уже имеются некоторые регулярные выражения и не надо придумывать колёсное транспортное средство, приводимое в движение мускульной силой человека через ножные педали или через ручные рычаги (это я про велосипед если что).
С данным примером лога достаточно pattern записать в виде «%
После обработки наша строка будет выглядеть следующим образом:
client: 55.3.244.1
method: GET
request: /index.html
bytes: 15824
duration: 0.043
Со списком готовых grok-шаблонов можно познакомиться здесь.
Пример конфигурационного файла для изменения/удаления записей из логов:
Построчное описание настроек:
тип/описание лога. Указывается тип (type) логов с которыми будет происходить обработка.
удаление всех данных имеющих название поля client. Возможно указание нескольких названий полей.
переименование название поля HOSTORIP в client_ip.
замена всех «/» на «_» в поле messages.
добавление нового поля «sample1» со значением «from %
Пример конфигурационого файла:
Построчное описание настроек:
тип/описание лога. Указывается тип (type) логов с которыми будет происходить обработка.
временная метка события. Важная настройка для дальнейшей возможности сортировки или выборки логов. Если в логах время указано в unix timestamp (squid), то следует использовать match => [ «timestamp», «UNIX» ]
Пример конфигурационного файла для обработки логов в формате key=value:
Построчное описание настроек:
тип/описание лога. Указывается тип (type) логов с которыми будет происходить обработка.
использовать символы «=» и «:» для разделения ключа-значения.
название поля в котором искать ‘ключ=значение’. По умолчанию разбивка будет происходить для всей строки лога.
использовать символы «\t?&» для разделения ключей. \t — знак табулятора
Пример конфигурационного файла для «склеивания» многострочных логов (например Java stack trace):
Построчное описание настроек:
тип/описание лога. Указывается тип (type) логов с которыми будет происходить обработка.
при соответствии шаблону «pattern» строка принадлежит предыдущей (previous) строке.
3. OUTPUT
Пример конфигурационного файла для вывода логов в standard output:
указывается формат исходящего сообщения. Допустимо использование переменных после grok-фильтрации.
Пример конфигурационого файла для записи логов в файл:
интервал записи исходящих сообщений. Значение 0 будет записывать каждое сообщение.
файл исходящих сообщений будет сжат Gzip.
путь и название файла куда будут сохраняться исходящие сообщения. Можно использовать переменные. В данном примере, для каждого уникального IP адреса будет создана своя папка и сообщения будут записываться в файл соответствующий переменной %
формат исходящего сообщения.
Пример конфигурационного файла для записи логов в базу Elasticsearch:
название кластера указанного в cluster.name в настроечном файле Elasticsearch.
указывает какую базу Elasticsearch использовать внутреннюю или стороннюю.
транспортный port Elasticsearch.
IP адрес Elasticsearch
название индекса куда будут записываться логи.
Данный плагин можно использовать для алертов. Минус в том, что любые изменения уведомлений (в принципе как и любых других настроек) требуют перезапуск logstash программы, но разработчик говорит, что возможно в будущем этого не придётся делать.
Пример конфигурационого файла:
если у вас хватило сил дочитать до этих строк, значит вы можете сами определить смысл этих 3х настроек 🙂
тема письма уведомления. Можно использовать переменные. Например %
способ отсылки письма. Возможен один вариант из двух — smtp или sendmail.
стандартные настройки почтовых параметров.
«response errors» — название алерта (записывается в переменную %
4. Итого
Создаём файл habr.conf:
В новом терминальном окне пишем:
echo «Logs are cool!» | nc localhost 11111
Смотрим результат в окне где запущен Logstash. Если там появилось секретное послание, значит всё работает.
Как читать логи сервера и что это такое?
Логи – это инструмент, при помощи которого можно отслеживать рабочий процесс сервера или сайта. Поэтому знать, как читать логи это полезное умение для выявления сбоев в работе ПО, быстрого и результативного реагирования на другие проблемы (выявление злонамеренных действий), эффективного анализа рабочий процесс, противодействия DDoS-атакам.
Содержание:
Что такое логи и зачем они нужны
Логи (log) – это специальные текстовые файлы, в которых в хронологическом порядке фиксируется информация обо всех действиях программы или пользователей. Проще говоря, это журнал регистрации всех событий происходивших в системе:
Логи доступа указывают на уязвимые места сайта (в случае взлома), помогают собирать статистику посещаемости, узнавать откуда проводились запросы и какие ресурсы ссылаются на этот сайт, оценивать популярность страниц. По файлам ошибок проще найти источник проблемы и оперативно устранить баги и сбои. Журналы сервера (server logs) облегчают контроль рабочего процесса серверной машины.
В файлах логов записывается и отслеживается история работы всего программного комплекса. Поэтому специалисты рекомендуют периодически просматривать их, даже если никаких подозрительных моментов не произошло. И тем более немедленно обратиться к ним, если резко возросло количество ошибок, посыпался спам или заметно увеличилась нагрузка на сервер.
Типы логов и где их найти
Месторасположение логов зависит от используемого ПО, настроек, прописанного админом пути. Чаще всего server logs сохраняются в var/log/. Однако, не все сервисы помещают файлы регистрации в эту директорию. В любом случае, можно уточнить такую информацию у веб-хостера.
У дистрибутивов Linux CentOS или Fedora логи серверной машины лежат в /var/log/. Там можно найти:
Лог ошибок MySQL ($hostname.err) хранится в /var/lib/mysql/. Для Debian или Ubuntu местоположение логов аналогично, за исключением log file ошибок MySQL: /mysql/error.log. А также – логи веб сервера Apache сохраняются по пути /var/log/apache2.
У ОС Windows дружной метод структурирования log-файлов. События делятся на несколько уровней:
Их можно отсортировать или отфильтровать и выбрать необходимое. 
Запуск и отключение логов осуществляется с административной панели. Как правило, доступ через раздел «журнал» или «логи». При этом стоит учитывать, что файлы не сохраняются годами. Поэтому, при необходимости посмотреть log, это нужно сделать своевременно.
Какая информация хранится в логах и как ее интерпретировать?
Для большинства пользователей содержимое log-файлов это бессмысленный набор символов. Как читать логи, чтобы понять, что в них зашифровано?
Строка access.log сервера содержит:
Как правило, такой информации достаточно, чтобы проанализировать ситуацию и сделать нужные выводы. Например, заблокировать бота, который создал чрезмерную нагрузку на сайт.
Файл ошибок (error.log) регистрирует моменты, когда что-то пошло не так. Из них можно узнать:
Конечно, даже после расшифровки, данных логов еще нужно проанализировать. Для этого существует различное ПО, которое помогает отрабатывать данные из логов – Weblog Expert, WebAlyzer, Analog, Webtrends, Awstats, SpyLOG Flexolyzer и другие платные и бесплатные программы.
Что такое логи logs файл(ы) сайта и зачем они нужны?
log file, лог-файл, логи, logs.
Возможно, вам встречались эти слова?
Хочу рассказать, что это такое и зачем они нужны.
Иногда бывает, нужно посмотреть:
1) ошибки, которые возникали при обращении к сайту;
2) Кто и сколько раз приходил на сайт;
3) Параметры посещений (каким браузером и откуда был выполнен переход и.т.д.);
В общем, нужна статистика сайта.
Конечно, есть современные системы статистики, такие как Google Analytics и Яндекс.Метрика, которые позволяют получать эти данные в удобном виде.
Но, бывают ситуации, что на некоторых сайтах эти системы не установлены, а получить статистику все равно нужно.
Например, произошла какая-то критическая ситуация с сайтом и вам нужно выяснить что произошло, а никаких систем статистики на сайте не было.
Практически на любом сайте, по умолчанию, существуют специальные текстовые файлы, в которые записывается вся информация о посещения и ошибках, которые были на вашем сайте.
Эти файлы и называются логами (log file, log-файлами, лог-файлы, логи).
В общем, логи – это текстовые файлы, в которых хранится информация о посещениях, параметрах посещений вашего сайта и ошибках, которые возникали на нем.
Имя файла логов, для наглядности и чтобы можно было понять их назначение, состоит из двух частей:
Т.е. указывается назначение файла и добавляется приставка «_log».
Данные о посещениях
Логи создаются серверным программным обеспечением. Этим они отличаются от систем Яндекс.Метрика и Google Аналитика, которые работают на основе Javascript-кода. Этот код встраивается на веб-страницы и передается браузером посетителя (клиентом) в базу данных систем статистики, которая хранится уже не на вашем сайте, а на сервере статистики.
Чтобы оставить сообщение, зарегистрируйтесь/войдите на сайт через:
Или зарегистрируйтесь через социальные сети: