Как включить логи Скайрим

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

Что такое журнал IIS?

Ведение журнала IIS — это ведение журнала на стороне сервера, которое включено для группы URL-адресов. Журналы IIS имеют фиксированный текстовый формат ASCII и не могут быть настроены. Там можно получить много ценной информации, когда вы ищите источник проблем на вашем веб-сервере. Очень частая ситуация, веб-приложение получает ошибку 5хх, не всегда по коду понятно, в чем причина, что делать, куда смотреть. Лично я такие обращения получаю от разработчиков раз в месяц стабильно.

Что делать если не запускается установщик игры? [Решение проблемы]

Расположение журналов IIS

По умолчанию логи IIS после установки располагаются по пути:

%SystemDrive%inetpublogsLogFiles

Данную папку вы можете посмотреть в проводнике Windows. В папке LogFiles вы найдете папки с именами в формате:

Число в конце имени папки соответствует идентификатору сайта. Таким образом, W3SVC2 соответствует идентификатору сайта 2.

Чтобы узнать ID у сайта вам нужно перейти в его дополнительные свойства.

Размер журналов будет зависеть от интенсивности записи в них и можете спокойно достигать по 500 МБ.

Так же вы можете посмотреть ошибки по пути:

%SystemDrive%WindowsSystem32LogFilesHTTPERR

Что делать, если вы не можете найти файлы логов IIS?

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

Найдите интересующий вас сайт, после чего кликните по иконке «Logging».

1.6 Log файл и команды для работы с ими | Linux для начинающих

В разделе «Directory» вы увидите, где у вас лежат логи Internet Information Services. При желании вы можете это поменять. Обратите внимание на формат ведения журнала, по умолчанию будет W3C.

W3C используется для централизованного формата файла журнала W3C, для регистрации информации обо всех сайтах на сервере. Этот формат обрабатывается HTTP.sys и представляет собой настраиваемый текстовый формат ASCII, что означает, что вы указываете регистрируемые поля. Укажите поля, которые регистрируются в диалоговом окне «W3C Logging Fields», щелкнув «Select Fields» на странице Ведение журнала. Поля разделены пробелами, а время записывается в формате всемирного координированного времени (UTC).

По мимо текущих журналов, вы можете еще отслеживать ошибки и предупреждения IIS в логах просмотра событий. Так в журнале «Система» вы можете активировать фильтр с источником WAS. В результате вы получите много ценной информации по поиску проблем на IIS или его пулах.

Еще есть три дополнительных журнала, но они требуют активации, так как по умолчанию они не ведут запись.

• ✅ IIS-CentralCertificateProvider
• ✅ IIS-Configuration
• ✅ IIS-Logging

⚙️Как найти файлы журналов IIS в Azure

1. Файлы журналов IIS автоматически сохраняются в облачных службах Azure .
2. Доступ к файлам журнала с помощью удаленного рабочего стола для подключения к определенному серверу. Там файлы хранятся по пути, похожему на этот: C:Resourcesdirectory..DiagnosticStoreLogFilesWebW3SVC

Службы приложений Azure :

1. Убедитесь, что ведение журнала веб-сервера включено.
2. Настройте ведение журнала веб-сервера для сохранения в файловой системе.
3. Файлы расположены в папке: D:homeLogFileshttpRawLogs через консоль KUDU.

Как узнать расположение логов IIS с помощью PowerShell

Get-Website yoursite | % < Join-Path ($_.logFile.Directory -replace ‘%SystemDrive%’, $env:SystemDrive) «W3SVC$($_.id)» >
Get-Website yoursite | % < $_.logFile.Directory, $_.id >

или для всех сайтов

(Get-Website * | % < $_.logFile.Directory>);ls $GetIISLogsW3SVC1*

Чтобы получить бонусные баллы, добавьте | iiк первой команде, которую нужно открыть в Проводнике, или | gciк просмотру содержимого папки.

Как удобно изучать логи IIS

Где хранятся трассировки IIS

Если вы включите трассировки на сайте, то посмотреть соответствующие журналы можно по пути указанному в дополнительных свойствах сайта. Вам потребуется раздел «Failed Request Tracing». В моем случае это:

%SystemDrive%inetpublogsFailedReqLogFiles

Как настроить расписание создания логов IIS

Если вы хотите настроить по какому расписанию должны создаваться журналы логов IIS, то вам это нужно сделать через диспетчер. Данная настройка делается, как на уровне всех сайтов, так и на уровне отдельного сайта. Найдите значок «Logging».

В разделе «Log File Rollover» выберите один из следующих вариантов. Расписание: для создания нового файла журнала на основе одного из следующих значений:

• Ежечасно (Hourly): новый файл журнала создается каждый час.
• Ежедневно (Daily): каждый день создается новый файл журнала.
• Еженедельно (Weekly): каждую неделю создается новый файл журнала.
• Ежемесячно (Monthly): каждый месяц создается новый файл журнала.

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

Выберите «Использовать местное время для именования и смены (Use local time for file naming and rollover)» файлов журнала, чтобы указать, что для именования файлов журнала и времени смены файлов журнала используется время локального сервера. Если этот параметр не выбран, используется всемирное координированное время (UTC).

Как выбрать поля W3C для регистрации

Для того, чтобы сделать для себя нужный список полей, которые должны появляться в логах Internet Information Services. Вы должны на уровне сервера или сайта нажать кнопку «Select Fiels» в разделе «Format»

• Дата (дата): дата, когда произошел запрос.
• Время (время): время по всемирному координированному времени (UTC), когда был получен запрос.
• IP-адрес клиента (c-ip): IP-адрес клиента, отправившего запрос.
• Имя пользователя (cs-username): имя аутентифицированного пользователя, который получил доступ к вашему серверу. Анонимные пользователи обозначаются дефисом.
• Имя службы (s-sitename): номер экземпляра сайта, выполнившего запрос.
• Имя сервера (s-computername): имя сервера, на котором была создана запись в файле журнала.
• IP-адрес сервера (s-ip): IP-адрес сервера, на котором была создана запись в файле журнала.
• Порт сервера (s-port): номер порта сервера, настроенный для службы.
• Метод (cs-метод): запрошенное действие, например, метод GET.
• Основа URI (cs-uri-stem): универсальный идентификатор ресурса или цель действия.
• Запрос URI (cs-uri-query): запрос, если таковой имеется, который пытался выполнить клиент. Запрос универсального идентификатора ресурса (URI) необходим только для динамических страниц.
• Состояние протокола (sc-status): код состояния HTTP или FTP.
• Подстатус протокола (sc-substatus): код подстатуса HTTP или FTP.
• Состояние Win32 (sc-win32-status): код состояния Windows.
• Отправлено байтов (sc-bytes): количество байтов, отправленных сервером.
• Получено байтов (cs-bytes): количество байтов, полученных сервером.
• Затраченное время (time-taken): продолжительность действия в миллисекундах.
• Версия протокола (cs-версия): версия протокола, которую использовал клиент.
• Хост (cs-host): имя хоста, если есть.
• Пользовательский агент (cs(UserAgent)): тип браузера, который использовал клиент.
• Cookie (cs(Cookie)): содержимое отправленного или полученного файла cookie, если таковой имеется.
• Referrer (cs(Referrer)): сайт, который последний раз посещал пользователь. Этот сайт предоставил ссылку на текущий сайт.

Как очищать старые логи IIS

Дополнительные ссылки

• https://learn.microsoft.com/en-us/iis/manage/provisioning-and-managing-iis/configure-logging-in-iis
• https://learn.microsoft.com/en-us/iis/manage/provisioning-and-managing-iis/managing-iis-log-file-storage

Популярные Похожие записи:

• Конвертирование формата evtx в log
• Get-ClusterLog и поиск ошибок в Failover Clusters
• Набор администрирования AD RMS SP2 Administration Toolkit
• Как вручную изменить сервер администрирования Kaspersky в агенте
• Ошибка HTTP Error 503. The service is unavailable
• Как посмотреть логи windows

Источник: pyatilistnik.org

Как включить журналы базы данных

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

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

В этой статье я объясню все, что вам нужно знать о журналах (логах) PostgreSQL, начиная с того, как их включить и заканчивая тем, как их легко форматировать и анализировать.

Что такое журналы PostgreSQL?

Журналы PostgreSQL — текстовые файлы, в которых отображается информация о том, что в данный момент происходит в вашей системе баз данных. Это включает в себя сведения о том, кто имеет доступ и к какому компоненту, какие ошибки произошли, что изменилось в настройках, какие запросы находятся в процессе выполнения и какие транзакции выполняются.

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

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

Местоположение журнала PostgreSQL

Из коробки PostgreSQL будет показывать журналы в stderr, что не очень удобно, так как они будут смешиваться с другими процессами, которые также ведут логирование в stderr. Чтобы PostgreSQL мог создавать собственные логи, необходимо включить параметр logging_collector . Когда вы это сделаете, журналы начнут отправляться в стандартное местоположение, определенное вашей ОС. Ниже приведены директории журналов по умолчанию для нескольких различных операционных систем:

• Система на базе Debian: e/var/log/postgresql/postgresql-x.x.main.log. X.x.
• Система на базе Red Hat: /var/lib/pgsql/data/pg_log
• Windows: C:Program FilesPostgreSQL9.3datapg_log

Чтобы поменять место хранения файлов журнала при включенном сборщике (коллекторе) логов, вы можете использовать параметр log_directory для указания пользовательского каталога.

Обратите внимание, что иногда ведение журнала может быть затруднительно в PostgreSQL. Коллектор логов не позволит потерять ни одного сообщения журнала, поэтому при высокой нагрузке он может блокировать процессы сервера, что приведет к проблемам. Вместо него можно использовать системный журнал (syslog), так как он позволяет отбрасывать некоторые сообщения и не блокирует систему. Чтобы отключить коллектор логов, вы можете настроить опцию на off:

logging_collector off

В зависимости от условий использования, вам может понадобиться изменить местоположение журналов PostgreSQL. Обычно используются такие варианты, как запись в syslog, CSV, Windows Event и Docker, о которых речь пойдет ниже.

Syslog

Вы можете легко настроить PostgreSQL на ведение журнала в syslog. Вам нужно сделать это на демоне syslog с помощью следующей конфигурации:

local0.* /var/log/postgresql

Вы можете использовать такие параметры, как syslog_facility , syslog_indent , syslog_sequence_number в конфигурационном файле PostgreSQL для форматирования логов.

CSV лог

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

csvlog /log/postgresql.csv

Вы также можете создать таблицу дополнительно к журналам, а затем использовать SQL для запроса по определенным условиям.

Журнал событий Windows

Для систем PostgreSQL, работающих под Windows, вы можете отправлять логи в журнал событий (event) Windows, используя следующую конфигурацию:

log_destination = ‘stderr, eventlog’

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

regsvr32 pgsql_library_directory/pgevent.dll

Docker

В настоящее время многие инструменты и базы данных запускаются как Docker-приложения, включая PostgreSQL. Вы также можете легко запустить Docker-версию PostgreSQL на Kubernetes или любой другой платформе оркестрации контейнеров.

Однако в таких случаях не стоит вносить изменения непосредственно в поды или контейнеры, поскольку эти изменения могут быть потеряны при перезапуске подов. Вместо этого необходимо передавать конфигурации во время запуска этих контейнеров.

Чтобы включить логирование, необходимо передать конфигурации с помощью ConfigMaps в Kubernetes. Читайте этот блог, чтобы развернуть PostgreSQL на Kubernetes и включить/выключить различные настройки.

Что важно записывать в журнал?

Запись большого количества информации в журнал может привести к пустой трате времени, если вы не сможете определить, какие логи важны, а какие нет. Очень важно уменьшить шум в журналах, чтобы ускорить отладку — это также сэкономит ваше время и ресурсы для их хранения.

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

Пороговые значения для медленного запроса

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

Чтобы включить эту функцию, необходимо отредактировать файл postgresql.conf . Найдите строку log_min_duration_statement и настройте ее в соответствии с вашими потребностями. Например, приведенный ниже оператор будет регистрировать все запросы, которые выполняются более 1 секунды:

log_min_duration_statement = 1000

После этого сохраните файл и перезагрузите PostgreSQL. Ваши настройки будут применены, и вы сможете увидеть логи медленных запросов в файлах журнала PostgreSQL.

Вы также можете задать эти параметры динамически с помощью интерфейса запросов PostgreSQL, выполнив следующую команду:

ALTER DATABASE db SET log_min_duration_statement = ‘1000ms’;

Время выполнения оператора

Вы можете легко регистрировать продолжительность выполнения каждого оператора в PostgreSQL. Для этого добавьте приведенный ниже оператор в свою конфигурацию, чтобы включить протоколирование каждого оператора:

log_statement all

Другим вариантом решения этой задачи является запуск следующего оператора PostgreSQL:

ALTER DATABASE db SET log_statement = ‘all’;

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

Вместо этого, возможно, вы захотите вести журнал по типу запроса, например, DDL или MOD. DDL состоит из операторов CREATE, ALTER и DROP, а MOD включает в себя DDL плюс другие операторы модификации.

Семплинг

При включенном семплинге вы можете записывать в журнал примеры операторов, которые переходят определенный порог. Если ваш сервер генерирует огромное количество журналов в связи с различными событиями, то вы не захотите регистрировать все, что выходит за порог. Можно делать это выборочно. Это помогает поддерживать меньший объем ввода/вывода при логировании и уменьшить шум в журналах, что облегчает определение того, какие типы операторов вызывают проблему.

Этими порогами и выборкой можно управлять с помощью таких параметров в файле postgresql.conf, как log_min_duration_sample , log_statement_sample_rate и log_transaction_sample_rate . Обратитесь к документации PostgreSQL, чтобы узнать, как правильно их использовать. У вас также есть возможность внести данные изменения через командную строку PostgreSQL.

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

Уровни журналов PostgreSQL

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

• DEBUG1, DEBUG2, DEBUG3. DEBUG5: Предоставляет разработчикам более подробную информацию.
• INFO: Извлекает конкретные данные, запрошенные пользователем, подобно вербозному выводу
• NOTICE: Предлагает пользователям полезную информацию, например, об усечении идентификатора.
• WARNING: Выдает предупреждения о вероятных проблемах
• ERROR: Регистрирует ошибки, включая те, которые вызывают прерывание любой команды.
• LOG: Регистрирует данные, например, активность контрольных точек, что может быть полезно для администратора.
• FATAL: Возникает при ошибках, которые привели к прерыванию текущего сеанса работы.
• PANIC: Возникает при ошибках, которые приводят к прерыванию всех сеансов базы данных.

Если вы отправляете журналы в Windows eventlog (журнал событий) или syslog (системный журнал), уровень серьезности (log-severity) журнала будет изменен следующим образом:

• DEBUG1. DEBUG5 будут преобразованы в DEBUG в syslog и INFORMATION в eventlog.
• INFO будет INFO в syslog и INFORMATION в eventlog.
• NOTICE будет NOTICE в syslog и INFORMATION в eventlog.
• WARNING будет NOTICE в syslog и WARNING в eventlog.
• ERROR будет WARNING в syslog и ERROR в eventlog.
• LOG будет INFO в syslog и INFORMATION в eventlog.
• FATAL будет ERR в syslog и ERROR в eventlog.
• PANIC будет CRIT в syslog и ERROR в eventlog.

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

Типы журналов

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

Журналы, специфичные для администратора, помогают управлять сервером PostgreSQL. Если сервер работает неправильно, они могут указать причину этого и помочь в устранении неполадок.

Существует два типа журналов, специфичных для администратора:

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

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

• Журналы запросов показывают все запросы, которые были сделаны на сервере; вы можете увидеть зарегистрированные запросы, если у вас включен log_statement.
• Журналы транзакций — это записи всех событий, происходящих с базой данных; они соответствуют стандарту WAL (write ahead log), который не предназначен для чтения человеком. WAL — это способ хранения записей всех действий, выполняемых с базой данных, и может быть использован для восстановления после аварии. Плагин pg_receivexlog может отображать журналы транзакций, передаваемые вашим сервером PostgreSQL.
• Журналы соединений полезны для выявления любых нежелательных подключений к серверу. Вы можете включить log_connections в файле postgresql.conf для фиксации каждой попытки подключения к серверу; log_disconnections позволит вам увидеть всех клиентов, которые отключились от сервера.
• Журналы ошибок помогут вам определить, создают ли какие-либо из ваших запросов нежелательные проблемы на сервере; log_in_error_statement управляет уровнем важности регистрации сообщений об ошибках.
• Журналы аудита и доступа очень важны с точки зрения администратора. Первые показывают изменения, внесенные в базу данных, а вторые определяют, кто какие запросы делал; их можно включить с помощью конфигурации log_statement или плагина PostgreSQL, например, pgAudit.

Большинство из этих типов журналов находятся в стандартных местах хранения по умолчанию или там, куда вы их определите в файле postgresql.conf. Есть также несколько проектов с открытым исходным кодом, которые я люблю использовать вместе с PostgreSQL для лучшего анализа журналов, например pgBadger.

Просто вести журнал — это еще не все случаи. Вам также нужно подумать о том, как вы будете архивировать или выполнять ротацию журналов. PostgreSQL поддерживает ротацию журналов, о которой пойдет речь в следующем разделе.

Ротация журналов PostgreSQL

PostgreSQL может выполнять ротацию журналов с помощью некоторых базовых параметров конфигурации. Благодаря таким параметрам, как log_rotation_age, log_rotation_size и log_truncate_on_rotation, вы можете легко настроить, в какой момент вы хотите произвести ротацию журналов. Например:

log_rotation_age 60 #default unit is minutes, this will rotate logs every log_rotation_age 300 #rotate the logs after the time mentioned.

Вы также можете использовать CLI для настройки этой конфигурации.

Как уже говорилось, изучение журналов — необходимый шаг в выявлении проблем, а для этого нужно понимать форматирование журналов. В PostgreSQL вы можете легко определить формат журнала в соответствии с вашими потребностями.

Как форматировать журналы

В PostgreSQL есть возможность использовать формат CSV и сгенерировать CSV файл, который можно использовать для добавления логов в таблице, и в дополнение к всему использовать SQL.

Кроме того, параметр log_line_prefix позволяет форматировать начало каждой строки журнала в файле postgresql.conf или через командную строку. Настраиваемые параметры включают имя приложения, имя пользователя, имя базы данных, удаленный хост, тип бэкенда, идентификатор процесса и т.д. Весь список параметров доступен в документации PostgreSQL. Например:

Приведенный префикс log_line_prefix означает, что журналы будут начинаться со времени в миллисекундах, затем идентификатор процесса, имя пользователя, имя базы данных и имя приложения.

Форматирование журнала, пороговые значения, семплинг, уровни и типы журналов — все это поможет вам в процессе дебаггинга. Но в идеале вам нужен инструмент, который позволяет агрегировать и анализировать все эти журналы и просматривать результаты через одну панель, а не заходить на каждый сервер. Одним из таких инструментов является Sematext. Давайте рассмотрим, как вы можете получить преимущества от ведения журналов PostgreSQL с помощью Sematext.

Ведение журналов PostgreSQL с помощью Sematext

Sematext Logs — это решение для управления журналами и их мониторинга, которое позволяет вам объединять журналы из различных источников данных вашей инфраструктуры в одном месте для просмотра и анализа.

Sematext обладает функцией автоматического обнаружения сервисов, поэтому вам просто нужно установить агент Sematext на свои серверы, выполнить базовую настройку, и ваши журналы PostgreSQL начнут в него стекаться. Они будут представлены на интуитивно понятной, готовой к использованию информационной панели (дашборд). Вы даже можете легко создать собственный дашборд, настроить оповещения и отправлять их по различным каналам передачи уведомлений, таким как Gmail, Slack или PagerDuty.

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

Sematext Logs (журналы) являются частью Sematext Cloud (облако), полнофункционального решения для ведения журналов и мониторинга, которое позволяет вам получить возможность обзора и интеграции всей вашей ИТ-среды. Помимо баз данных, оно поддерживает интеграцию с широким спектром инструментов, включая HAProxy, Apache Tomcat, JVM и Kubernetes. Кроме того, вы получаете поддержку деплоя Kubernetes, поэтому вам будет проще контролировать свою установку в среде Kubernetes.

Заключение

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

Вы можете отслеживать журналы различными способами, например, используя less или tail для файлов журналов, но это будет сложно сделать, если журналы разбросаны по нескольким файлам и машинам. Вам нужны журналы в одном месте, и такое решение, как Sematext Logs, может помочь вам достичь этого.

В преддверии старта курса «Observability — мониторинг, логирование, трейсинг» хотим порекомендовать два абсолютно бесплатных вебинара от OTUS, файла с уведомлением, а также строка, на которой оно находится.

Если говорить просто, то в данном случае мы имеем сообщение о том, что первого октября, в 18:23, 2019-го года, произошла ошибка, связанная с модулем контактов.

Разумеется, даже после расшифровки, полученные данные не так просто проанализировать. Именно поэтому, для удобной обработки данных из логов сервера, используется различное программное обеспечение. К таким программам относятся: Awstats, Webtrends, WebAlyzer, и многие другие.

Сегодня существует множество платных и бесплатных вариантов программ, для обработки и анализа лог-файлов.

Логи серверов на Windows

У логов серверов на Windows, изначально более удобный и структурированный вывод информации, в виде простой и понятной таблицы.

Существует несколько уровней событий:

• Подробности;
• Сведения;
• Предупреждение;
• Ошибка;
• Критический.

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

Логи SQL сервера

На сегодняшний день, базы данных SQL, являются наиболее распространенным способом работы с большими объемами информации. В первую очередь, логи sql сервера, стоит изучить, если вы не уверены в том, что какие-то процессы были успешно завершены. Этими процессами могут быть:

• Резервное копирование;
• Восстановление данных;
• Массовые изменения;
• Различные скрипты, и программы для обработки данных.

Для того, чтобы просмотреть записи в логах, можно использовать SQL Server Management Studio, либо другой, удобный вам редактор текстов. Записи распределены по журналам следующих типов:

• Сбор данных;
• Database Mail;
• SQL Сервер;
• События Windows;
• Журнал заданий;
• Коллекция аудита;
• SQL Сервер, агент.

Для того, чтобы получить доступ к журналам, необходимо иметь права «securityadmin».

Как включить или выключить запись логов сервера?

Для того, чтобы осуществить эту операцию, нужно зайти в административную панель вашего хостера. Как правило, в основном меню есть раздел «Журнал», или «Логи», в котором можно включить или выключить запись данных о предоставленном доступе, ошибках, и т.п.

Где находятся логи сервера?

Расположение журналов, зависит в первую очередь от используемой вами операционной системы.

Логи серверов с CentOS, или Fedora, хранятся в дирректории «/var/log/».

• Журнал ошибок – «error.log»;
• Журнал nginx – «nginx»;
• Журнал доступов – «log»;
• Основной журнал – «syslog»;
• Журнал загрузки системы – «dmesg».

Логи ошибок, связанных с работой MySQL, находятся в директории «/var/lib/mysql/», в файле «$hostname.err».

Для операционных систем Debian и Ubuntu, логи сервера располагаются в папке «/var/log/», в файлах:

• Nginx — журнал nginx;
• /mysql/error.log – журнал ошибок для баз данных MySQL;
• Syslog – основной журнал;
• Dmesg – загрузка системы, драйвера;
• Apache2 – журнал веб-сервера Apache.

Как видите, у всех ОС, основанных на Linux, логи сервера, как правило имеют одинаковые названия, и директории.

С логами для Windows server, дело обстоит несколько иначе. Если нужно просмотреть журналы, необходимо войти в систему, нажать клавиши «Win» и «R», после чего откроется окно просмотра событий, где есть возможность подобрать интересующие нас логи.

Если вы хотите посмотреть логи PowerShell, то необходимо открыть программу и ввести команду: «Get-EventLog -Logname ‘System’».

Все данные будут выведены в виде удобной таблицы.

Пример работы с логами сервера

Представьте себе, что вы внезапно обнаружили существенное увеличение нагрузки на ваш сервер, связанное с внешними воздействиями. Сервисы аналитики начинают регистрировать рекорды посещаемости, и можно было бы радоваться, но видно, что эти «пользователи» не совершают действий, которых от них ждут, неважно что это – изучение контента, или покупки на сайте.

Можно потратить много времени на выяснения причины, а можно просто посмотреть логи доступа и проверить, с каких IP, и кто заходил на ваш сайт, в выбранные промежуток времени. Вполне вероятно, что вы обнаружите большое количество переходов с нескольких IP-адресов, которые делались автоматически, то есть ваш сайт попал под DDoS-атаку.

В этом случае, можно заблокировать доступ к сайту с выбранных IP, и в дальнейшем расширять этот список, при необходимости.

Вывод

На сегодняшний день, log-файлы сервера, являются крайне удобным инструментом, который позволяет отслеживать работу сайта, выявлять баги и ошибки, злонамеренных пользователей, противодейстWowать DDoS-атакам.

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

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

У систем, основанных на Linux, как правило примерно одинаковое расположение файлов с логами, что существенно упрощает работу с ними.

У Windows Server, есть свой собственный графический интерфейс для чтения логов, который весьма удобен, и позволяет быстро получить необходимую информацию.

Alex Bernatsky

SEO-эксперт, вебмастер с 2009 года, CEO компании CyberShark. За время работы в сфере создания и продвижения сайтов протестировал более сотни хостингов.

Источник: hostingfanatic.com