Рубрика «logs» - 2

Ещё раз о хранении логов в Zabbix - 1

Тема сбора и хранения логов в Zabbix поднималась уже не раз. И не два. Если не учитывать, что это не вполне корректный подход, серьёзно нагружающий базу, у таких способов есть еще один существенный недостаток – они хранят логи целиком. И если в случае с логами роутеров или Linux с этим можно как-то смириться, то event-log Windows начинает доставлять много страданий, как серверу Zabbix, так и системному администратору, который решится его собирать и хранить. Ниже — о решении этой проблемы. Читать полностью »

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

less установлен у всех, все привыкли с ним работать, знают о базовых вещах, как поиск вперед-назад, фильтрация по &, переход в конец(G) файла, переход в начало(g) и так далее.

А так же, все уже смирились с тем, что в любой момент, при добавлении фильтра less может подвиснуть на неопределенный срок, выводить по строчке в 5 секунд и так далее. В конечном счете, особенно при считывании логов с stdin — приходится быть аккуратным. Фильтр может сработать, а может и не сработать

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

Для начала небольшое демо (2.2mb):

Заголовок спойлера

slit — новое слово в мире PAGERов, либо как тратить меньше времени на просмотр логов - 1

Тем кто уже готов: github.com/tigrawap/slit
Кто нет, прошу под кат…
Читать полностью »

Spunk + Check Point, пример анализа логов вашего фаервола - 1

Если Вы не удовлетворены стандартными отчетами и средствами аналитики от Check Point, если Ваш Smart Event виснет и грузит ваш сервер, если отчеты Smart Event кажутся Вам несколько неинформативными… То почему бы не создать свои?

Spunk + Check Point, пример анализа логов вашего фаервола - 2

Сегодня мы расскажем как загрузить логи Check Point в Splunk, какие могут быть отчеты, и как, отфильтровать данные, чтобы лишний раз не грузить систему и уменьшить лицензию. И да, если Ваша компания не очень большая — то вы можете спокойно обойтись бесплатной лицензией.
Читать полностью »

Уважаемые читатели. Это вторая статья из цикла по базам данных.
Решил сделать некоторое оглавление по планируемым статьям этого цикла:

  1. Как сделать разный часовой пояс в разных базах данных на одном сервере.
  2. Как вести логи изменений данных пользователями в базе данных, сохраняя их в другой базе данных, для того чтобы основная база данных не забивалась мусором и не росла.
  3. Как создать свою файловую систему на основе blob полей в базе данных. Почему это удобно. Вопросы эффективности хранения файлов: как получить максимальное быстродействие и при этом минимальное занимаемое место.

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

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

Итак начнем.

База данных firebird 3.

Формулировка задачи следующая: необходимо писать подробные логи изменений данных пользователями в базе данных (insert, update, delete), но при этом писать их в другой базе данных на другом сервере. Необходимо это для того чтобы размер основной базы данных не рос как на дрожжах, ее удобно было бекапить, ресторить, чтобы она работала быстро, не накапливала мусора, не содержала лишней и редконужной информации.
Читать полностью »

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

Соответственно для реализации такой системы перед администратором ставятся задачи: во-первых, каким образом эти логи собирать, во-вторых, каким образом с ними удобно и централизованно работать. Благодаря достаточно развитой связке ELK (Elasticsearch + Logstash + Kibana), уже не раз описанной на Хабре, у администратора имеются инструменты для удобного поиска и отображения всей присутствующей в логах информации. Поэтому ответ на вторую задачу имеется изначально, и остается лишь решить задачу по сбору логов.

Так как в моем случае требованием к системе было отсутствие клиента на серверах, и то, что логи требовалось вытаскивать с Windows-серверов, то в качестве инструмента сбора был выбран родной для Windows — powershell.
Исходя из этого была составлена следующая модель сбора и отображения информации из логов: логи удаленно собираются с серверов powershell-скриптом, после чего складываются в виде файлов на хранилище, далее средствами ELK (Elasticsearch + Logstash + Kibana) происходит их обработка и отображение.

Пример работы всей связки представлен на изображении:

Централизованый сбор Windows event логов, без установки агента, с последующей визуазизацией средствами ELK - 1
Читать полностью »

Введение

У одного из наших клиентов возникла задача вынести логи из большинства корпоративных приложений и их баз данных «куда-нибудь» — уж больно с ними много возни: растут как на дрожжах, чисти их периодически, а к некоторым еще и доступ должен быть обеспечен в течение многих лет, да еще и анализ хочется проводить системным образом. Конечно же, вынести логи – это не первичная цель, и по совокупности требований мы выбрали Hadoop, версию от Cloudera (CDH 5).

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

Как одно из решений — использовать поисковый модуль SolrCloud, который входит в комплект Hadoop от Cloudera. В Cloudera «из коробки» входят тулзы для выгрузки данных из баз данных приложений и их индексации пачкой (не построчно). Однако такой способ оказался хоть и рабочим, но более трудоемким и непредсказуемым в настройке, чем, скажем, если бы мы использовали Impala для выборки данных. Поэтому я решил поделиться как мы это делали, в надежде сэкономить время тем, кто столкнется с похожей задачей.

Эта статья описывает детали настройки, а также встреченные в процессе работы особенности.
Читать полностью »

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

Речь пойдет о сервисе для SEO специалистов и/или рядовых вебмастеров. BotHunter является системой пассивного наблюдения (в реальном режиме времени) за юзерагентами на вашем сайте. Примеры интерфейсов см. ниже, либо в DEMO аккаунте на сайте системы (в demo режиме ограниченный функционал). Читаем далее

Инструмент контроля за поведениеем роботов на вашем сайте

Читать полностью »

Приветствую.

Нет так давно передо мной встала задача пробежаться по старым логам apache. Надо было сделать выборку по нескольким IP адресам, отыскать некоторые аномалии и попытки SQL-injection'ов. Логов было не так много, порядка миллиона строк и можно было спокойно всё сделать стандартным набором grap-awk-uniq-wc итд.

Поскольку я уже какое-то (больше года) время пользуюсь связкой Logstash-Elasticsearch-Kibana для анализа-просмотра всевозможных логов, то решил ей воспользоваться и в данной ситуации.

Краткое описание основных компонентов системы.

Logstash — бесплатная open-source программа на java для сбора и нормализации логов. Может принимать логи либо с локальных файлов, либо через tcp/udp порты. На момент написания статьи разных входных (input) фильтров насчитывается 26. Есть даже входной модуль, для сбора сообщений из twitter'а или irc.

Elasticsearch — бесплатный open-source поисковый сервер основанный на Apache Lucene. Быстрый, легко настраиваемый и очень масштабируемый.

Kibana — веб-интерфейс написанный на ruby, для отображения данных из Elasticsearch. Простая настройка, но множество функций — поиск, графики, stream.

Читать полностью »

Существует разные техники отладки: кто-то зарывается в отладчик, кто-то медитирует, ожидая просветления, кто-то судорожно меняет код в надежде на удачу, но почти ни кто не откажется от файла в котором будет сохранены последние мгновения жизни процесса, что происходило, в каких нитях, на каких ядрах, в какое время. Заботливо и педантично сохраненная отладочная информация может сохранить многие рабочие часы, особенно если речь идет о отладке драйвера и аппаратного обеспечения с которым он работает. Ну, а в случае когда ошибка случайная и воспроизводиться на 1 системе из 20 в течении недели, то без отладочной информации медитация может затянуться.
В данной статье пойдет речь об утилитах, помогающих в перехвате отладочных сообщений драйверов, работающих на нескольких машинах одновременно и передаче сообщений на сервер для сохранения и анализа.

Читать полностью »

Вы не любите смотреть логи в консоли или вам не позволяют их любить, а следить за ходом дел как-то нужно?

PuperGrep — просмотрщик логов в браузере, который работает как tail -F, grep и подсвечивает самое интересное в вашем браузере. Или даже на вашем android, iPhone или iPad.

Скриншот PuperGrep

Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js