#анализ_логов — Public Fediverse posts

Ответ 200, а денег нет. Что не покажут ни Postman, ни нейросеть

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

https://habr.com/ru/articles/1071444/

#тестирование_API #автотесты #QA #Postman #интеграционное_тестирование #проверка_ответов_API #анализ_логов #OpenAPI #тестирование_без_кода #cicd

Создаем автономный анализатор логов на локальных ИИ моделях

У моего клиента есть пара железных серверов, которые используются для хранения и раздачи статических файлов. Все бы ничего, но любое оборудование требует внимания и регулярного мониторинга. Со временем диски, модули памяти и другие компоненты могут выходить из строя. Причем умирают они не сразу, сначала молча сыплются ошибки в логи, а потом уже поздно что-то предпринимать: даунтайм, kernel panic, fatal error, ретроспектива и панические атаки. Поэтому важно своевременно отслеживать состояние инфраструктуры и реагировать на предупреждения до того, как они перерастут в серьезные инциденты. По-хорошему раз в месяц кто-то должен садиться и изучать логи на аномалии, если нужно — писать тикеты и ждать завершения технических работ с серверами. Вполне логичная и рабочая схема, в которой сама собой напрашивается автоматизация, комплексный сбор логов, выявление узких мест и уведомления в профильные каналы. Но, как ни крути, нужно оптимизировать процессы и резать косты, да и человек не всегда имеет желание следить за показателями. Выражение «искусственный интеллект всех заменит» заиграло новыми красками. Нет, от естественного интеллекта я не отказываюсь, но конкретно анализом «здоровья» этих железных серверов теперь занимается локальная ИИшница. Сейчас покажу, что удалось запилить, как я прикрутил локальную модель и написал нишевого агента под нужды клиента, чисто для анализа логов с железных серверов.

https://habr.com/ru/companies/selectel/articles/1046409/

#selectel #llamacpp #llm #rtx_4090 #анализ_логов #ubuntu #nvidiasmi

Как я приручил Wazuh: от сотен ложных срабатываний к рабочему набору правил

Wazuh – это open-source SIEM, который собирает логи, детектирует подозрительную активность и умеет на неё реагировать. Инструмент хороший, но дефолтный набор правил – как швейцарский нож: вроде и режет, и открывает, а под конкретную задачу всё равно приходится подтачивать. Он рассчитан на «среднюю» инфраструктуру и без адаптации генерирует много шума. Моя задача сводилась к тому, чтобы отделить этот шум от значимых событий, не потеряв при этом сами атаки. В этой статье – методология и грабли, на которые я наступил. Будет полезно тем, кто настраивает Wazuh впервые, и тем, кто хочет разгрузить аналитиков от потока ложных тревог.

https://habr.com/ru/companies/cloud4y/articles/1045138/

#Wazuh #SIEM #SOC #мониторинг_безопасности #ложные_срабатывания #локальные_правила #анализ_логов #обнаружение_вторжений #информационная_безопасность #wazuhlogtest

Технологический журнал 1С: настройка, чтение и поиск проблем производительности

Когда в 1С «просто тормозит», стандартные метрики и журнал регистрации почти бесполезны: они показывают факт, но не причину. Технологический журнал — один из немногих инструментов, который позволяет увидеть, что именно происходит внутри платформы: какие запросы реально выполняются, где возникают блокировки, и на каком участке кода уходит время. В этой статье — без лишней теории: как быстро включить техжурнал, что в нём действительно важно, и как за несколько минут находить медленные запросы и проблемные места в системе.

https://habr.com/ru/companies/otus/articles/1018102/

#1с #технологический_журнал_1С #техжурнал_1С #1С_производительность #диагностика_1С #логирование_1С #DBPOSTGRS #медленные_запросы #блокировки_1С #анализ_логов

Системы мониторинга без процессов — ресурсы на ветер, или Как получить максимум эффективности от использования SIEM

Чтобы автоматизированно проверять и централизованно обрабатывать огромное количество событий о происходящем в инфраструктуре, используется SIEM –– класс решений информационной безопасности, призванный анализировать события ИБ, собираемые c устройств инфраструктуры, выявлять подозрения на инциденты. Но для правильного использования этой системы, а тем более для максимально эффективной ее эксплуатации, необходимо провести ряд организационных мероприятий, направленных на выстраивание правильной работы как специалистов, непосредственно взаимодействующих с SIEM (аналитиков ИБ, технических специалистов и администраторов), так и смежных подразделений организации, отвечающих за блок ИТ. После установки система не становится эффективной сама по себе, и помимо наличия персонала, в чьем ведении она находится, также важны и процессы, которые структурируют и делают более прозрачной и прогнозируемой деятельность по выявлению инцидентов ИБ. В статье я расскажу, какие процессы следует наладить для работы с SIEM, почему это важно, и какие последствия могут быть и, скорее всего, будут, если этого не сделать.

https://habr.com/ru/companies/pt/articles/1014446/

#cybersecurity #soc #сзи #siem #анализ_логов #кибербезопасность #процессы #регламенты

[Перевод] Диагностика неполадок в Linux: эти 4 шага помогут исправить 99% ошибок

Любая неожиданная ошибка в Linux может выбесить. Но хорошая новость в том, что почти каждую проблему в Linux можно решить, если действовать просто и системно. Всего четыре базовых шага, которые подходят почти под любую ситуацию. Главное, оставаться последовательным. Эффективная диагностика в Linux — это системный подход, когда вы проверяете по одному возможному источнику проблемы за раз. В этой статье я разберу основные шаги, которыми чаще всего пользуются системные администраторы, когда Linux выдает ошибку. Этот подход одинаково хорошо работает и на серверах Linux, и на настольных системах и поможет вам справиться с чем угодно — от проблем при загрузке до «упрямых» приложений, которые не хотят нормально запускаться. 4 шага диагностики

https://habr.com/ru/companies/otus/articles/967276/

#линукс #диагностика_Linux #поиск_ошибок #системное_администрирование #логирование #journalctl #dmesg #анализ_логов #сбой_загрузки #неисправности_серверов

ИИ наступает: как системному аналитику остаться незаменимым?

Технологии сейчас слишком стремительно развиваются и оказывают влияние на многие профессии. Я — системный аналитик, и искусственный интеллект всё плотнее проникает в мою профессиональную жизнь. Сначала это даже вызывало опасения. Что ждёт меня в будущем? Сможет ли ИИ заменить меня в профессиональном плане? Можно ли этого избежать и какие новые навыки будут нужны специалистам, чтобы оставаться востребованными? Попробую ответить на эти и другие вопросы. Термин «artificial intelligence» в английском языке означает не столько «интеллект», сколько «умение логически мыслить». Это значит, что ИИ — это не аналог человеческого интеллекта, способного познавать мир и понимать суть вещей (согласно определению Линды Готтфредсон), а лишь система, которая способна делать выводы, решать задачи, понимать сложные концепции, быстро осваивать новое и учиться на основе полученного опыта. Несмотря на впечатляющие возможности искусственного интеллекта в области логического мышления и решения задач, его функционал пока существенно отличается от способностей человеческого интеллекта. Полноценное познание мира и понимание его сути остаются за пределами возможностей ИИ. Однако развитие технологий происходит с невероятной скоростью, и в будущем все может измениться. А чтобы лучше понимать как и что менялось в этом направлении, давайте оглянемся в прошлое.

https://habr.com/ru/companies/raiffeisenbank/articles/913676/

#системный_анализ #системный_аналитик #prompt_engineering #бизнесанализ #трансформация_профессии #анализ_логов #анализ_скриптов #rpaрешения #SelfDriving_Banking

Как мы делали сервис Cloud Logging

Работа без логов, это как вождение автомобиля вслепую. Ехать можно, но недолго и не туда. Почти в каждом проекте логи нужны. И нужны инструменты, которые умеют с ними работать. А с этим исторически у нас была проблема. В облаке Amvera, проекты пользователей, в большинстве своём, небольшие. А инструменты на рынке, такие как Elasticsearch очень требовательны к выделяемым ресурсам и сложны в настройке. Странно поднимать телеграм-бота, который потребляет 100 мб. оперативной памяти и ставить для его логов Elastic на 16 Гб. Логичным решением является создание мультиарендной системы. Когда мы собираем логи в какой-то большой базе данных, и каждому пользователю даём доступ только к его логам. Звучит замечательно, но на практике реализовать это не так легко. На создание приемлемого решения у нас ушло несколько итераций. И мы хотим поделиться опытом, чтобы другие не наступали на наши грабли и могли сделать сразу хорошо.

https://habr.com/ru/companies/amvera/articles/919450/

#cloud_logging #observability #сбор_логов #анализ_логов #поиск_по_логам #mongodb_для_логов #grafana_loki #victorialogs

Threat Hunting изнутри: как охотиться на атакующего

Threat Hunting — это навык находить атакующего там, где нет алертов. А еще это умение выдвигать гипотезу, проверять ее и превращать результат в рабочую экспертизу. А также это системная работа с инфраструктурой, в которой важен контекст, скорость мышления и понимание поведения злоумышленника. Меня зовут Алексей Леднев, я руковожу продуктовой экспертизой PT ESC в Positive Technologies. И сегодня я по кирпичикам разберу профессию Threat Hunter: как она устроена, кто этим занимается, какие ошибки совершают новички, какие навыки обязательны для Threat Hunter и как попасть в профессию.

https://habr.com/ru/companies/pt/articles/911246/

#обнаружение_атак #threat_hunting #security_operation_center #учебный_курс #цепочка_атаки_хакера #обнаружение_атаки #анализ_сетевого_трафика #сигнатуры #threat_intelligence #анализ_логов

Как я ускорил анализ логов в мобильной игре с помощью Python-конвертера

Привет, Хабр! Меня зовут Владлен Кузнецов, я QA Lead в компании, которая разрабатывает мобильные игры. Однажды я потратил более 2 часов, разбирая логи, чтобы локализовать весьма коварный баг с начислением ресурсов. Это был сигнал: пора что‑то менять. В этой статье я расскажу, как мой конвертер логов на Python ускорил для нашей команды анализ логов в разы, и поделюсь советами, как вы можете сделать то же самое. Проблема: утонуть в логах У нас в игре клиентские логи содержат аналитические события (например CurrencyChanged, KeysChanged) и технические записи (инициализация Unity, вызовы Firebase). Один лог может достигать 100 тысяч строк и более, но QA нужны только 1–2% — ключевые события и их параметры. Найти их вручную — это как искать иголку в стоге сена.

https://habr.com/ru/articles/908842/

#qa #qa_automation #логи #python #геймдев #gamedev #автоматизация_тестирования #мобильные_игры #анализ_логов #тестирование

Цена «мусорных» логов: Как некачественная информация чуть не привела к провалу

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

https://habr.com/ru/articles/897810/

#логи #защита_данных #информационная_безопасность #расследование_инцидентов #целостность_данных #анализ_логов

Руководство по выбору SOC: на что обратить внимание

Привет! Меня зовут Михаил Климов, я руководитель команды SOC в компании RED Security. Хочу поговорить про выбор SOC (Security Operation Center) — центра реагирования на инциденты информационной безопасности (ИБ). Вопрос актуален как никогда: в последнее время половина ленты Хабра посвящена кибератакам на бизнес, приняты законы, ужесточающие ответственность компаний за утечку персональных данных. Из-за этого многие директора по информационной безопасности обращаются к вопросу о создании процессов мониторинга событий ИБ в инфраструктуре и максимально быстрого реагирования на возможные кибератаки. Но как выбрать тот самый SOC и определиться с моделью поставок — отдельный вопрос. Я часто сталкиваюсь с тем, что компании начинают строить внутренний центр мониторинга, тратят около года на проект, и все это время защищенность остается на прежнем неудовлетворительном уровне. Затем они понимают, что самостоятельно его реализовать сейчас не могут, и в итоге обращаются к аутсорсингу. И напротив, поработав несколько лет с внешними поставщиками сервисов SOC, переходят к созданию внутреннего центра мониторинга. Как же понять оптимальный вариант поставки для конкретной компании на определенном этапе, чтобы не потратить время и ресурсы впустую, двигаясь методом проб и ошибок? Что правильнее: строить собственный центр реагирования или выбрать одно из готовых решений от многочисленных аутсорсинговых сервис-провайдеров? В этом посте я и мой коллега Ильназ Гатауллин, технический руководитель RED Security SOC, разобрали варианты организации SOC исходя из потребностей и ресурсов бизнеса.

https://habr.com/ru/companies/ru_mts/articles/889196/

#информационная_безопасность #SOC #SIEM #threat_intelligence #mssp #кибератаки #мониторинг_безопасности #реагирование_на_инциденты #анализ_логов #защита_инфраструктуры