Логирование Вконтакте что это

Логи – это инструмент, при помощи которого можно отслеживать рабочий процесс сервера или сайта. Поэтому знать, как читать логи это полезное умение для выявления сбоев в работе ПО, быстрого и результативного реагирования на другие проблемы (выявление злонамеренных действий), эффективного анализа рабочий процесс, противодействия DDoS-атакам.

Содержание:

1. Что такое логи и зачем они нужны?
2. Типы логов и где их найти
3. Какая информация хранится в логах и как ее интерпретировать

Что такое логи и зачем они нужны

Логи (log) – это специальные текстовые файлы, в которых в хронологическом порядке фиксируется информация обо всех действиях программы или пользователей. Проще говоря, это журнал регистрации всех событий происходивших в системе:

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

Логи и мониторинг: best practice / Олег Бервинов

Логи доступа указывают на уязвимые места сайта (в случае взлома), помогают собирать статистику посещаемости, узнавать откуда проводились запросы и какие ресурсы ссылаются на этот сайт, оценивать популярность страниц. По файлам ошибок проще найти источник проблемы и оперативно устранить баги и сбои. Журналы сервера (server logs) облегчают контроль рабочего процесса серверной машины.
В файлах логов записывается и отслеживается история работы всего программного комплекса. Поэтому специалисты рекомендуют периодически просматривать их, даже если никаких подозрительных моментов не произошло. И тем более немедленно обратиться к ним, если резко возросло количество ошибок, посыпался спам или заметно увеличилась нагрузка на сервер.

Типы логов и где их найти

Месторасположение логов зависит от используемого ПО, настроек, прописанного админом пути. Чаще всего server logs сохраняются в var/log/. Однако, не все сервисы помещают файлы регистрации в эту директорию. В любом случае, можно уточнить такую информацию у веб-хостера.
У дистрибутивов Linux CentOS или Fedora логи серверной машины лежат в /var/log/. Там можно найти:

• файл регистрации ошибок error.log;
• данные о доступах log;
• основной системный журнал syslog;
• файл загрузки ОС dmesg;
• журнал nginx.

Лог ошибок MySQL ($hostname.err) хранится в /var/lib/mysql/. Для Debian или Ubuntu местоположение логов аналогично, за исключением log file ошибок MySQL: /mysql/error.log. А также – логи веб сервера Apache сохраняются по пути /var/log/apache2.
У ОС Windows дружной метод структурирования log-файлов. События делятся на несколько уровней:

• предупреждение – Warning;
• подробности (System и EventData);
• ошибка – Error;
• сведения – Information;
• критический – Critical.

Что такое лог (log) программы

Их можно отсортировать или отфильтровать и выбрать необходимое.

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

Какая информация хранится в логах и как ее интерпретировать?

Для большинства пользователей содержимое log-файлов это бессмысленный набор символов. Как читать логи, чтобы понять, что в них зашифровано?
Строка access.log сервера содержит:

• адрес ресурса;
• IP-адрес пользователя;
• дата и время посещения, часовой пояс;
• GET/POST – запрос на получение или отправку данных;
• к какой странице обращались;
• протокол пользователя (как зашел на ресурс);
• код отклика сервера;
• число переданных байтов;
• информация о посетителе (боте) – устройство, ОС, другие данные.

Как правило, такой информации достаточно, чтобы проанализировать ситуацию и сделать нужные выводы. Например, заблокировать бота, который создал чрезмерную нагрузку на сайт.
Файл ошибок (error.log) регистрирует моменты, когда что-то пошло не так. Из них можно узнать:

• когда произошла ошибка (дата, время), ее тип и IP-адрес пользователя;
• тип события;
• где находится сам файл и строка с сообщением

Конечно, даже после расшифровки, данных логов еще нужно проанализировать. Для этого существует различное ПО, которое помогает отрабатывать данные из логов – Weblog Expert, WebAlyzer, Analog, Webtrends, Awstats, SpyLOG Flexolyzer и другие платные и бесплатные программы.

НАС ВЫБРАЛИ БОЛЕЕ 4000 КЛИЕНТОВ!

Нам доверяют свои проекты более 80 человек каждый день!

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

Использование ClickHouse в VK, или Зачем мы написали KittenHouse

В начале года мы решили научиться хранить и читать отладочные логи ВКонтакте более эффективно, чем раньше. Отладочные логи — это, к примеру, логи конвертации видео (в основном вывод команды ffmpeg и список шагов по предварительной обработке файлов), которые иногда бывают нам нужны лишь спустя 2-3 месяца после обработки проблемного файла.

На тот момент у нас было 2 способа хранения и обработки логов — наш собственный logs engine и rsyslog, которые мы использовали параллельно. Стали рассматривать другие варианты и поняли, что нам вполне подходит ClickHouse от Яндекса — решили его внедрять.

В этой статье я расскажу о том, как мы начали использовать ClickHouse ВКонтакте, на какие грабли при этом наступили, и что такое KittenHouse и LightHouse. Оба продукта выложены в open-source, ссылки в конце статьи.

Задача сбора логов

Требования к системе:

1. Хранение сотен терабайт логов.
2. Хранение месяцами или (редко) годами.
3. Высокая скорость записи.
4. Высокая скорость чтения (чтение происходит редко).
5. Поддержка индексов.
6. Поддержка длинных строк (>4 Кб).
7. Простота эксплуатации.
8. Компактное хранение.
9. Возможность вставки с десятков тысяч серверов (UDP будет плюсом).

Возможные решения

Давайте вкратце перечислим варианты, которые мы рассматривали, и их минусы:

Logs Engine

Наш самописный микросервис для логов.

– Умеет отдавать только последние N строк, которые помещаются в RAM.
– Не очень компактное хранение (нет прозрачного сжатия).

Hadoop

– Не во всех форматах есть индексы.
– Скорость чтения могла быть и выше (зависит от формата).
– Сложность настройки.
– Нет возможности вставки с десятков тысяч серверов (нужна Kafka или аналоги).

Rsyslog + файлы

– Нет индексов.
– Низкая скорость чтения (обычный grep/zgrep).
– Архитектурно не поддерживаются строки >4 Кб, по UDP ещё меньше (1,5 Кб).
± Компактное хранение достигается путем logrotate по крону

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

LSD + файлы

– Нет индексов.
– Низкая скорость чтения (обычный grep/zgrep).
– Не особо расчитан на вставку с десятков тысяч серверов.
± Компактное хранение достигается путем logrotate по крону.

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

ElasticSearch

– Проблемы с эксплуатацией.
– Нестабильная запись.
– Нет UDP.
– Плохое сжатие.

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

ElasticSearch прежде всего предназначен для полнотекстового поиска и относительно частых запросов на чтение. Нам же важнее стабильная запись и возможность более-менее быстро прочитать наши данные, причём по точному совпадению. Индекс у ElasticSearch заточен под полнотекстовый поиск, и занимаемый объём на диске довольно велик по сравнению с gzip оригинального содержимого.

ClickHouse

По большому счёту, единственное, что нас не устраивало в ClickHouse — отсутствие общения по UDP. По факту, из перечисленных вариантов оно было только у rsyslog, но при этом rsyslog не поддерживал длинные строки.

По остальным критериям ClickHouse нам подошел, и мы решили использовать его, а проблемы с транспортом решить в процессе.

Зачем нужен KittenHouse

Как Вы, наверное, знаете, ВКонтакте работает на PHP/KPHP, с «движками» (микросервисами) на C/C++ и немножко на Go. У PHP нет концепции «состояния» между запросами, кроме, возможно, общей памяти и открытых соединений.

Поскольку у нас десятки тысяч серверов, с которых мы хотим иметь возможность отправлять логи в ClickHouse, держать открытым соединения из каждого PHP-worker’а было бы накладно (на каждый сервер может приходиться по 100+ воркеров). Поэтому нам нужен какой-то прокси между ClickHouse и PHP. Мы назвали этот прокси KittenHouse.

KittenHouse, v1

Сначала решили попробовать как можно более простую схему, чтобы понять, будет наш подход работать или нет. Если Вам на ум при решении этой задачи приходит Kafka, то Вы не одиноки. Мы, однако, не хотели использовать дополнительные промежуточные сервера — в этом случае можно было легко упереться в производительность этих серверов, а не самого ClickHouse. К тому же, мы собирали логи и нам нужна была предсказуемая и небольшая задержка вставки данных. Схема выглядит следующим образом:

На каждом из серверов ставится наш локальный прокси (kittenhouse), и каждый инстанс держит строго одно HTTP-соединение с нужным ClickHouse-сервером. Вставка осуществляется в буферные таблицы, поскольку в MergeTree часто вставлять не рекомендуется.

Возможности KittenHouse, v1

Первая версия KittenHouse умела довольно мало, однако для тестов этого было достаточно:

• Общение через наш RPC (TL Scheme).
• Поддержание 1 TCP/IP соединения на сервер.
• Буферизация в памяти по умолчанию, с ограниченным размером буфера (остальное выбрасывается).
• Возможность записи на диск, в этом случае есть гарантия доставки (не менее одного раза).
• Интервал вставки — раз в 2 секунды.

Первые проблемы

С первой проблемой мы столкнулись, когда «погасили» ClickHouse сервер на несколько часов и потом включили обратно. Ниже можно видеть load average на сервере после того, как он «поднялся»:

Объясняется это довольно просто: у ClickHouse модель работы по сети — thread per connection, поэтому при попытке сделать INSERT с тысячи узлов одновременно, началась очень сильная конкуренция за ресурсы CPU и сервер еле отвечал. Тем не менее, все данные в конечном счёте вставились и ничего не упало.

Для решения этой проблемы мы поставили nginx перед ClickHouse и, в целом, это помогло.

Дальнейшее развитие

В процессе эксплуатации столкнулись ещё с некоторым количеством проблем, в основном связанных не с ClickHouse, а с нашим способом его эксплуатации. Вот ещё грабли, на которые мы наступили:

Большое количество «кусков» у Buffer таблиц приводит к частым сбросам буфера в MergeTree

В нашем случае было 16 кусков буфера и интервал сброса раз в 2 секунды, а таблиц 20 штук, что давало до 160 вставок в секунду. Это периодически очень плохо сказывалось на производительности вставки — появлялось много фоновых слияний и утилизация дисков достигала 80% и выше.

Решение: увеличили интервал сброса буфера по умолчанию, уменьшили число кусков до 2.

Nginx отдает 502, когда заканчиваются соединения с upstream

Само по себе это не является проблемой, но в сочетании с частым сбросом буфера это давало достаточно высокий фон 502 ошибок при попытке вставки в любую из таблиц, а также при попытке выполнить SELECT.

Решение: написали свою reverse proxy с использованием библиотеки fasthttp, которая группирует вставку по таблицам и очень экономно расходует соединения. Также она различает SELECT и INSERT и имеет раздельные пулы соединений для вставки и для чтения.

Начала заканчиваться память при интенсивной вставке

У библиотеки fasthttp есть свои достоинства и недостатки. Один из недостатков — то, что запрос и ответ полностью буферизуются в памяти перед тем, как отдать управление обработчику запроса. У нас это выливалось в то, что если вставка в ClickHouse «не успевала», то буферы начинали расти и в конечном итоге заканчивалась вся память на сервере, что приводило к убийству reverse proxy по OOM. Коллеги нарисовали демотиватор:

Решение: патчинг fasthttp для поддержки стриминга тела POST-запроса оказался непростой задачей, поэтому решили использовать Hijack() соединения и апгрейдить соединение на свой протокол, если пришел запрос с HTTP-методом KITTEN. Поскольку сервер должен ответить MEOW в ответ, если понимает этот протокол, вся схема называется протоколом KITTEN/MEOW.

Мы читаем только из 50 случайных соединений одновременно, поэтому, благодаря TCP/IP, остальные клиенты «ждут» и мы не расходуем память на буферы, пока до соответствующих клиентов не дошла очередь. Это сократило потребление памяти минимум в 20 раз, и больше подобных проблем у нас не было.

ALTER таблиц может идти долго, если есть долгие запросы

У ClickHouse неблокирующий ALTER — в том смысле, что он не мешает выполняться как SELECT-запросам, так и INSERT-запросам. Но ALTER не может начаться, пока не закончили исполняться запросы в эту таблицу, отправленные до ALTER.

Если у вас на сервере есть фон «долгих» запросов в какие-нибудь таблицы, то вы можете столкнуться с ситуацией, что ALTER на эту таблицу не будет успевать выполняться за дефолтный таймаут в 60 секунд. Но это не значит, что ALTER не пройдет: он выполнится, как только закончат выполняться те самые SELECT-запросы.

Это означает, что вы не знаете, в какой на самом деле момент времени произошел ALTER, и у вас нет возможности автоматически пересоздать Buffer-таблицы, чтобы их схема всегда была одинаковой. Это может приводить к проблемам при вставке.

Решение: Планируем в итоге полностью отказаться от использования буферных таблиц. В целом, у буферных таблиц есть сфера применения, мы пока используем их и не испытываем огромных проблем. Но сейчас мы наконец дошли до момента, когда проще реализовать функциональность буферных таблиц на стороне reverse proxy, чем продолжать мириться с их недостатками. Примерная схема будет выглядеть вот так (пунктирной линией показана асинхронность ACK на INSERT).

Чтение данных

Допустим, мы разобрались со вставкой. Как читать эти логи из ClickHouse? К нашему сожалению, удобных и простых в эксплуатации инструментов для чтения сырых данных (без построения графиков и прочего) из ClickHouse мы не нашли, поэтому написали своё решение — LightHouse. Его возможности довольно скромные:

• Быстрый просмотр содержимого таблиц.
• Фильтрация, сортировка.
• Редактирование SQL-запроса.
• Просмотр структуры таблицы.
• Показ примерного количества строк и занимаемого на диске места.

Просмотр структуры таблицы

Фильтрация содержимого

Результаты

ClickHouse — практически единственная open-source база данных, которая «прижилась» ВКонтакте. Мы довольны скоростью её работы и готовы мириться с недостатками, о которых ниже.

Сложности в работе

В целом, ClickHouse — очень стабильная база данных и очень быстрая. Однако, как и с любым продуктом, особенно таким молодым, есть особенности в работе, которые нужно учитывать:

• Не все версии одинаково стабильны: не обновляйтесь на продакшене сразу на новую версию, лучше подождать несколько bugfix-релизов.
• Для оптимальной производительности крайне желательно настраивать RAID и некоторые другие вещи согласно инструкциям. Об этом недавно был доклад на highload.
• Репликация не имеет встроенных ограничений по скорости и может вызывать существенную деградацию производительности сервера, если её не ограничивать самим (но это обещают исправить).
• В Linux есть неприятная особенность механизма работы виртуальной памяти: если вы активно пишете на диск и данные не успевают сбрасываться, в какой-то момент сервер полностью «уходит в себя», начинает активно сбрасывать page cache на диск и практически полностью блокирует процесс ClickHouse. Это иногда происходит при больших мержах, и за этим нужно следить, например периодически сбрасывать буферы самим или делать sync.

Open-source

KittenHouse и LightHouse теперь доступны в open-source в нашем github-репозитории:

• KittenHouse: github.com/vkcom/kittenhouse
• LightHouse: github.com/vkcom/lighthouse

Юрий Насретдинов, разработчик в отделе backend-инфраструктуры ВКонтакте

• clickhouse
• vk
• очередной велосипед
• почему не kafka

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

Логгеры в программиро­ва­нии: что это и зачем

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

Что такое логгер

Логгер — это специальный модуль, библиотека или отдельная программа, которая реагирует на события в программе и записывает всё, что там происходит. Эти записи называются логами, и чаще всего это обычный текстовый файлик. Когда что-то в программе идёт не так, разработчик смотрит лог и ищет, в какой момент и где возникла проблема.

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

Где может храниться лог

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

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

Также логи могут отправляться в другую программу, например в систему мониторинга и аналитики.

Как работает логгер

Логгер ничего не делает сам по себе, и, чтобы в лог попала какая-то запись, программист должен добавить в программу команду типа такой:

«Запиши в лог: в часов минут к серверу подключился новый пользователь с адресом »

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

После этого мы получаем доступ к логгеру и можем что-нибудь отправить в лог:

debug(‘Такой-то модуль загрузился’)

На самом деле мы уже много раз использовали логгер в своих проектах. Например, мы выводили промежуточные результаты в разных алгоритмах сортировки на JavaScript, чтобы посмотреть, как код работает изнутри. Для этого мы писали команду console.log() — она выводит наше сообщение в консоль.

Уровни логирования

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

• Debug — когда мы пишем в лог сообщения, что стартовала какая-то функция или мы получили ответ от сервера.
• Info — информация о разовых ситуациях, например: считали базу данных при запуске, установили соединение с сервером, начали работу.
• Warning — ещё не ошибка, но происходит что-то странное: сервер не ответил, пользователь ввёл не тот пароль, вместо данных пришли нули.
• Error — ошибки в работе программы. Обычно их отлавливают с помощью исключений.

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

logger.info(‘Запустился модуль проверки лицензии, ждём ответ’)

При желании можно даже вести лог каждого уровня в своём отдельном файле, но такое бывает нечасто. Проще держать всё в одном файле и фильтровать.

А можно сделать свой логгер и им пользоваться в проектах?

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

Если ваш логгер решает какую-то совсем простую задачу, то можно обойтись и console.log() или записью той же строчки в файл. А для более сложных проектов проще использовать уже готовый логгер: скорее всего, у него будет больше возможностей.

Лучше не тратить время на разработку того, что уже есть, а сосредоточиться на задачах, которые ещё никто не решил.

Что дальше

Теперь, когда мы знаем о логгерах достаточно, попробуем применить их в разных проектах — сначала на JavaScript, а потом на Python.

Источник: thecode.media