#логирование — Public Fediverse posts

Почему ваши логи бесполезны и как это починить за полчаса

Когда продакшен падает в три часа ночи, строка ERROR Something went wrong не помогает никому. В статье разбираем, почему привычные текстовые логи быстро превращаются в шум при реальной нагрузке, как перейти на structured logging, зачем каждому запросу нужен request_id и как настроить нормальные JSON‑логи в Python и Go без лишней инфраструктуры.

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

#structured_logging #структурированные_логи #JSONлоги #логирование #request_id #observability #OpenTelemetry #structlog #slog #диагностика_ошибок

Trace Points в C++: диагностика production-систем без перезапуска

Одна из самых неприятных особенностей production-проблем заключается в том, что они почти никогда не происходят тогда, когда разработчик готов их исследовать. Во время разработки всё работает. На тестовом стенде тоже всё выглядит нормально. Логи кажутся вполне достаточными, а диагностическая информация — продуманной и аккуратно организованной. Но затем в production внезапно появляется странная проблема: соединение иногда сбрасывается без видимой причины, один запрос из нескольких тысяч начинает вести себя иначе, сервер под высокой нагрузкой неожиданно входит в reconnect loop или где-то глубоко внутри системы начинает происходить что-то, что невозможно воспроизвести локально. И почти всегда в этот момент выясняется одна и та же неприятная вещь: логов, которые уже есть в системе, недостаточно. Именно здесь традиционное логирование начинает постепенно ломаться. Большинство систем логирования до сих пор построены вокруг довольно простой идеи: заранее решить, какие сообщения должны писаться постоянно. Разработчик добавляет INFO, WARNING, DEBUG, иногда каналы или категории, после чего приложение отправляется в production с надеждой, что этих логов когда-нибудь хватит для диагностики. Иногда действительно хватает. Но реальные production-системы имеют неприятную привычку ломаться не там и не так, как ожидалось. Более того, проблемы часто возникают именно в тех участках кода, которые казались совершенно неинтересными во время разработки. Первой реакцией обычно становится мысль: “давайте включим DEBUG logging”. На небольших проектах это ещё может работать вполне нормально. Однако в больших системах DEBUG-логи очень быстро превращаются в проблему сами по себе. Они начинают занимать гигабайты, полезная информация тонет в шуме, растёт нагрузка на диск, а иногда и само логирование начинает заметно влиять на производительность и тайминги приложения.

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

#logging_c++ #tracepoint #debugging #c++ #логирование #отладка_кода

Логи, которые реально помогают: как дебажить продакшен-бота

Знакомая ситуация: бот вроде бы работает. Люди тыкают кнопки, получают ответы, всё хорошо. Но иногда случается странное. Прилетает сообщение в поддержку: «Бот не отвечает». Или ещё хуже: «Бот выдал какую‑то ошибку и всё». Вы бежите к терминалу, поднимаете историю... и ничего не видите. Ни ошибки, ни стека, ни даже намёка на то, где именно всё сломалось. Вы просто слепы. Без нормальных логов вы не понимаете ровно ничего: обработчик не сработал, API молчит, база данных упала или вы просто забыли зарегистрировать хендлер. Спойлер: я через это проходил, и не раз. Читать далее...

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

#python #logging #логирование #программирование #ошибки

Логи, которые реально помогают: как дебажить продакшен-бота

Знакомая ситуация: бот вроде бы работает. Люди тыкают кнопки, получают ответы, всё хорошо. Но иногда случается странное. Прилетает сообщение в поддержку: «Бот не отвечает». Или ещё хуже: «Бот выдал какую‑то ошибку и всё». Вы бежите к терминалу, поднимаете историю... и ничего не видите. Ни ошибки, ни стека, ни даже намёка на то, где именно всё сломалось. Вы просто слепы. Без нормальных логов вы не понимаете ровно ничего: обработчик не сработал, API молчит, база данных упала или вы просто забыли зарегистрировать хендлер. Спойлер: я через это проходил, и не раз. Читать далее...

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

#python #logging #логирование #программирование #ошибки

Логи, которые реально помогают: как дебажить продакшен-бота

Знакомая ситуация: бот вроде бы работает. Люди тыкают кнопки, получают ответы, всё хорошо. Но иногда случается странное. Прилетает сообщение в поддержку: «Бот не отвечает». Или ещё хуже: «Бот выдал какую‑то ошибку и всё». Вы бежите к терминалу, поднимаете историю... и ничего не видите. Ни ошибки, ни стека, ни даже намёка на то, где именно всё сломалось. Вы просто слепы. Без нормальных логов вы не понимаете ровно ничего: обработчик не сработал, API молчит, база данных упала или вы просто забыли зарегистрировать хендлер. Спойлер: я через это проходил, и не раз. Читать далее...

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

#python #logging #логирование #программирование #ошибки

Логи, которые реально помогают: как дебажить продакшен-бота

Знакомая ситуация: бот вроде бы работает. Люди тыкают кнопки, получают ответы, всё хорошо. Но иногда случается странное. Прилетает сообщение в поддержку: «Бот не отвечает». Или ещё хуже: «Бот выдал какую‑то ошибку и всё». Вы бежите к терминалу, поднимаете историю... и ничего не видите. Ни ошибки, ни стека, ни даже намёка на то, где именно всё сломалось. Вы просто слепы. Без нормальных логов вы не понимаете ровно ничего: обработчик не сработал, API молчит, база данных упала или вы просто забыли зарегистрировать хендлер. Спойлер: я через это проходил, и не раз. Читать далее...

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

#python #logging #логирование #программирование #ошибки

Как читать логи, когда их слишком много

Эпоха монолитов прошла, и сейчас логи больше путают, чем помогают. Несколько сервисов, несколько журналов и противоречащие друг другу строки — ни одной очевидной причины в этом монотонном расследовании. Но поиск можно сузить, а ответ почти всегда находится в цепочке событий. Команды, лайфхаки и список утилит — под катом. Предупрежу, в статье МНОГО БУКВ, поэтому можно сразу перейти к Linux, Windows или к инструментам (они в самом конце). Читать

https://habr.com/ru/companies/ruvds/articles/1028288/

#логи #логирование #log #debug #info #error #warn #linux #windows #ruvds_статьи

Как читать логи, когда их слишком много

Эпоха монолитов прошла, и сейчас логи больше путают, чем помогают. Несколько сервисов, несколько журналов и противоречащие друг другу строки — ни одной очевидной причины в этом монотонном расследовании. Но поиск можно сузить, а ответ почти всегда находится в цепочке событий. Команды, лайфхаки и список утилит — под катом. Предупрежу, в статье МНОГО БУКВ, поэтому можно сразу перейти к Linux, Windows или к инструментам (они в самом конце). Читать

https://habr.com/ru/companies/ruvds/articles/1028288/

#логи #логирование #log #debug #info #error #warn #linux #windows #ruvds_статьи

Как читать логи, когда их слишком много

Эпоха монолитов прошла, и сейчас логи больше путают, чем помогают. Несколько сервисов, несколько журналов и противоречащие друг другу строки — ни одной очевидной причины в этом монотонном расследовании. Но поиск можно сузить, а ответ почти всегда находится в цепочке событий. Команды, лайфхаки и список утилит — под катом. Предупрежу, в статье МНОГО БУКВ, поэтому можно сразу перейти к Linux, Windows или к инструментам (они в самом конце). Читать

https://habr.com/ru/companies/ruvds/articles/1028288/

#логи #логирование #log #debug #info #error #warn #linux #windows #ruvds_статьи

Как хакеры обошли 2FA и захватили облачную инфраструктуру

В последние годы гибридная инфраструктура стала стандартом де‑факто. Компании перевозят критичные сервисы в Azure, AWS,Google Cloud или Yandex.Cloud но оставляют on‑prem AD как точку доверия.Практически всегда многофакторная аутентификация (MFA) включена для доступа к административной учетной записи облака, считая ее непреодолимым барьером. В этом материале я разберу кейс из практики расследований,котором злоумышленники не взламывали 2FA,им не пришлось, вместо этого они нашли способ легально войти в облако под сессией уже авторизованного администратора. Техника называется Shadow RDP.

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

#APT #логирование #расследование_инцидентов #расследование_кибератак

[Перевод] Почему observability-данные теряют ценность ещё при сборе

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

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

#observability #логирование #наблюдаемость #трассировка #метрики #кардинальность #DevOps_практики #качество_данных

[Перевод] Почему observability-данные теряют ценность ещё при сборе

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

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

#observability #логирование #наблюдаемость #трассировка #метрики #кардинальность #DevOps_практики #качество_данных

[Перевод] Почему observability-данные теряют ценность ещё при сборе

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

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

#observability #логирование #наблюдаемость #трассировка #метрики #кардинальность #DevOps_практики #качество_данных

[Перевод] Почему observability-данные теряют ценность ещё при сборе

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

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

#observability #логирование #наблюдаемость #трассировка #метрики #кардинальность #DevOps_практики #качество_данных

Дизайн логгера: что важно на самом деле

Когда логирование попадает в реальную систему, довольно быстро становится понятно, что это не про API и не про удобство вызова. Это про постоянный компромисс. С одной стороны, хочется, чтобы система работала максимально быстро: любое логирование — это накладные расходы, и в нормальном режиме его стараются минимизировать. С другой стороны, как только возникает проблема, внезапно оказывается, что либо логов недостаточно, либо они есть, но в таком виде, что восстановить картину происходящего невозможно. В этот момент становится очевидно, что задача логгера — не просто “писать строки” максимально быстро, а помогать удерживать баланс между производительностью и диагностируемостью. Первая проблема, которая всплывает практически сразу, связана не со скоростью, а со структурой. Лог начинает отражать структуру кода, а не структуру происходящего. Есть бизнес-логика, есть библиотеки, есть множество параллельных операций, и каждая из них пишет что-то своё. В итоге лог превращается в поток сообщений, где перемешаны разные задачи, и вместо “обработки конкретного запроса” мы видим просто последовательность вызовов. На небольшом проекте это ещё можно терпеть, но в серверной системе такая картина быстро становится непригодной для анализа. Естественное желание — привязать лог не к месту вызова, а к самой задаче. Самый прямой путь — передавать контекст через параметры (например, инстанс логгера), но довольно быстро это начинает протекать через весь код и превращается в обязательный шум в сигнатурах. Гораздо более устойчивый подход — привязать контекст к потоку выполнения. В библиотеке logme это делается через thread channel:

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

#логирование #логирование_C++ #системы_логирования #дизайн_логгера #logging #C++_logging

Тихий убийца: Деградация производительности без явных ошибок

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

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

#troubleshooting #утечки_памяти #производительность #деградация_системы #observability #мониторинг #логирование #трассировка #профилирование #узкие_места

Разбираем хаос в Linux‑логах: journald, rsyslog и файлы

“Где мои логи — в /var/log/messages, /var/log/syslog или только в journalctl?” — этот вопрос рано или поздно задает себе каждый инженер, который вынужден переключаться между разными дистрибутивами: Ubuntu, CentOS, Alpine, корпоративные Unix системы. Типичный сценарий: вы заходите на сервер, ищете /var/log/messages, а его или нет, или он есть, но journalctl показывает гораздо больше событий, чем файл. Иногда сервер внезапно начинает сильно использовать CPU, и в итоге причиной оказывается агрессивное логирование. Если к этому добавить разнородный парк, где рядом с Ubuntu живут динозавры на AIX и Solaris, путаница приобретает глобальный характер. Сейчас мы живем в эпоху «двоевластия»: systemd‑journald уже стал стандартом де‑факто, но rsyslog все еще присутствует во многих дистрибутивах по инерции или ради совместимости. Эта статья для инженеров, которые хотят понимать, кто именно пишет логи в Linux, почему они дублируются, где теряются CPU и I/O, и как настроить логирование так, чтобы диск не превращался в помойку. Мы пройдем путь от бинарных логов AIX до journald, а в конце разберемся, как практически использовать journalctl с популярными инфраструктурными службами.

https://habr.com/ru/companies/k2tech/articles/1014402/

#devops #Linu #unix #ubunt #логирование #облака #сети #сервера #сетевые_технологии #сетевая_инфраструктура

Асинхронное логирование в C++ — не серебряная пуля: что на самом деле ограничивает производительность

Асинхронное логирование давно считается “очевидной оптимизацией”: вынесли запись в отдельный поток — и всё стало быстрее. Но если копнуть глубже, оказывается, что это не совсем так. В предыдущей статье я разбирал производительность популярных C++ логгеров и показывал реальные цифры: 👉 https://habr.com/ru/articles/1012874/ Там уже было видно, что хорошо оптимизированное синхронное логирование может быть очень быстрым. В этой статье разберёмся, почему async logging не делает логирование быстрее само по себе , и что на самом деле происходит внутри:

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

#с++ #логирование #асинхронное_программирование #производительность #многопоточность

Асинхронное логирование в C++ — не серебряная пуля: что на самом деле ограничивает производительность

Асинхронное логирование давно считается “очевидной оптимизацией”: вынесли запись в отдельный поток — и всё стало быстрее. Но если копнуть глубже, оказывается, что это не совсем так. В предыдущей статье я разбирал производительность популярных C++ логгеров и показывал реальные цифры: 👉 https://habr.com/ru/articles/1012874/ Там уже было видно, что хорошо оптимизированное синхронное логирование может быть очень быстрым. В этой статье разберёмся, почему async logging не делает логирование быстрее само по себе , и что на самом деле происходит внутри:

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

#с++ #логирование #асинхронное_программирование #производительность #многопоточность

Асинхронное логирование в C++ — не серебряная пуля: что на самом деле ограничивает производительность

Асинхронное логирование давно считается “очевидной оптимизацией”: вынесли запись в отдельный поток — и всё стало быстрее. Но если копнуть глубже, оказывается, что это не совсем так. В предыдущей статье я разбирал производительность популярных C++ логгеров и показывал реальные цифры: 👉 https://habr.com/ru/articles/1012874/ Там уже было видно, что хорошо оптимизированное синхронное логирование может быть очень быстрым. В этой статье разберёмся, почему async logging не делает логирование быстрее само по себе , и что на самом деле происходит внутри:

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

#с++ #логирование #асинхронное_программирование #производительность #многопоточность

Асинхронное логирование в C++ — не серебряная пуля: что на самом деле ограничивает производительность

Асинхронное логирование давно считается “очевидной оптимизацией”: вынесли запись в отдельный поток — и всё стало быстрее. Но если копнуть глубже, оказывается, что это не совсем так. В предыдущей статье я разбирал производительность популярных C++ логгеров и показывал реальные цифры: 👉 https://habr.com/ru/articles/1012874/ Там уже было видно, что хорошо оптимизированное синхронное логирование может быть очень быстрым. В этой статье разберёмся, почему async logging не делает логирование быстрее само по себе , и что на самом деле происходит внутри:

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

#с++ #логирование #асинхронное_программирование #производительность #многопоточность

Observability в финтехе: связываем клик пользователя с падением интеграции

Привет! Я Никита, Staff-инженер в крупном финтехе. В этой статье я хочу поделиться нашим опытом построения системы observability. Мы прошли путь от простых логов до сквозной трассировки, и я покажу, как это работает на фронтенде. TL;DR: В статье разбираем опыт внедрения OpenTelemetry в крупном финтех-проекте. Проблема: Логи без контекста не позволяют быстро найти причину 500-й ошибки в распределенной системе. Решение: Сквозная трассировка (Distributed Tracing) от фронтенда до бэкенда. Что внутри: Реализация CompositeLogger на TypeScript, патчинг fetch для сохранения контекста и примеры того, как превратить технические трейсы в карту бизнес-процесса. А именно - frontend реализация и практические детали интеграции.

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

#opentelemetry #observability #distributed_tracing #frontend_мониторинг #логирование #трассировка #react

Observability в финтехе: связываем клик пользователя с падением интеграции

Привет! Я Никита, Staff-инженер в крупном финтехе. В этой статье я хочу поделиться нашим опытом построения системы observability. Мы прошли путь от простых логов до сквозной трассировки, и я покажу, как это работает на фронтенде. TL;DR: В статье разбираем опыт внедрения OpenTelemetry в крупном финтех-проекте. Проблема: Логи без контекста не позволяют быстро найти причину 500-й ошибки в распределенной системе. Решение: Сквозная трассировка (Distributed Tracing) от фронтенда до бэкенда. Что внутри: Реализация CompositeLogger на TypeScript, патчинг fetch для сохранения контекста и примеры того, как превратить технические трейсы в карту бизнес-процесса. А именно - frontend реализация и практические детали интеграции.

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

#opentelemetry #observability #distributed_tracing #frontend_мониторинг #логирование #трассировка #react

Observability в финтехе: связываем клик пользователя с падением интеграции

Привет! Я Никита, Staff-инженер в крупном финтехе. В этой статье я хочу поделиться нашим опытом построения системы observability. Мы прошли путь от простых логов до сквозной трассировки, и я покажу, как это работает на фронтенде. TL;DR: В статье разбираем опыт внедрения OpenTelemetry в крупном финтех-проекте. Проблема: Логи без контекста не позволяют быстро найти причину 500-й ошибки в распределенной системе. Решение: Сквозная трассировка (Distributed Tracing) от фронтенда до бэкенда. Что внутри: Реализация CompositeLogger на TypeScript, патчинг fetch для сохранения контекста и примеры того, как превратить технические трейсы в карту бизнес-процесса. А именно - frontend реализация и практические детали интеграции.

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

#opentelemetry #observability #distributed_tracing #frontend_мониторинг #логирование #трассировка #react

Observability в финтехе: связываем клик пользователя с падением интеграции

Привет! Я Никита, Staff-инженер в крупном финтехе. В этой статье я хочу поделиться нашим опытом построения системы observability. Мы прошли путь от простых логов до сквозной трассировки, и я покажу, как это работает на фронтенде. TL;DR: В статье разбираем опыт внедрения OpenTelemetry в крупном финтех-проекте. Проблема: Логи без контекста не позволяют быстро найти причину 500-й ошибки в распределенной системе. Решение: Сквозная трассировка (Distributed Tracing) от фронтенда до бэкенда. Что внутри: Реализация CompositeLogger на TypeScript, патчинг fetch для сохранения контекста и примеры того, как превратить технические трейсы в карту бизнес-процесса. А именно - frontend реализация и практические детали интеграции.

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

#opentelemetry #observability #distributed_tracing #frontend_мониторинг #логирование #трассировка #react

[Перевод] Тонкости работы с процессором преобразования в OpenTelemetry

Transform processor в OpenTelemetry часто воспринимается как «универсальный костыль» на случай, когда стандартных процессоров уже не хватает. В итоге в конфигурации появляются OTTL-инструкции, которые вроде бы корректны, но ведут себя непредсказуемо: условия не срабатывают, поля не меняются, данные теряются без явных ошибок. В этой статье разберём, как на самом деле работает transform processor: какую модель данных он использует, как вычисляются инструкции, где чаще всего ломается логика и почему это не всегда видно сразу. На примере разбора JSON-логов и реальных конфигураций покажем, как писать преобразования, которые дают контролируемый результат и не ломают телеметрию в продакшене. Прокачать observability

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

#OpenTelemetry #transform_processor #OTTL #логирование #трейсинг #наблюдаемость #обработка_логов

[Перевод] Тонкости работы с процессором преобразования в OpenTelemetry

Transform processor в OpenTelemetry часто воспринимается как «универсальный костыль» на случай, когда стандартных процессоров уже не хватает. В итоге в конфигурации появляются OTTL-инструкции, которые вроде бы корректны, но ведут себя непредсказуемо: условия не срабатывают, поля не меняются, данные теряются без явных ошибок. В этой статье разберём, как на самом деле работает transform processor: какую модель данных он использует, как вычисляются инструкции, где чаще всего ломается логика и почему это не всегда видно сразу. На примере разбора JSON-логов и реальных конфигураций покажем, как писать преобразования, которые дают контролируемый результат и не ломают телеметрию в продакшене. Прокачать observability

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

#OpenTelemetry #transform_processor #OTTL #логирование #трейсинг #наблюдаемость #обработка_логов

[Перевод] Тонкости работы с процессором преобразования в OpenTelemetry

Transform processor в OpenTelemetry часто воспринимается как «универсальный костыль» на случай, когда стандартных процессоров уже не хватает. В итоге в конфигурации появляются OTTL-инструкции, которые вроде бы корректны, но ведут себя непредсказуемо: условия не срабатывают, поля не меняются, данные теряются без явных ошибок. В этой статье разберём, как на самом деле работает transform processor: какую модель данных он использует, как вычисляются инструкции, где чаще всего ломается логика и почему это не всегда видно сразу. На примере разбора JSON-логов и реальных конфигураций покажем, как писать преобразования, которые дают контролируемый результат и не ломают телеметрию в продакшене. Прокачать observability

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

#OpenTelemetry #transform_processor #OTTL #логирование #трейсинг #наблюдаемость #обработка_логов

[Перевод] Тонкости работы с процессором преобразования в OpenTelemetry

Transform processor в OpenTelemetry часто воспринимается как «универсальный костыль» на случай, когда стандартных процессоров уже не хватает. В итоге в конфигурации появляются OTTL-инструкции, которые вроде бы корректны, но ведут себя непредсказуемо: условия не срабатывают, поля не меняются, данные теряются без явных ошибок. В этой статье разберём, как на самом деле работает transform processor: какую модель данных он использует, как вычисляются инструкции, где чаще всего ломается логика и почему это не всегда видно сразу. На примере разбора JSON-логов и реальных конфигураций покажем, как писать преобразования, которые дают контролируемый результат и не ломают телеметрию в продакшене. Прокачать observability

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

#OpenTelemetry #transform_processor #OTTL #логирование #трейсинг #наблюдаемость #обработка_логов

Логи: всё, что нужно знать тестировщику

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

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

#логи #логирование #тестирование_вебприложений #тестирование_по #тестирование_мобильных_приложений #мониторинг_логов #kafka #kibana #sentry #jaeger

Логи: всё, что нужно знать тестировщику

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

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

#логи #логирование #тестирование_вебприложений #тестирование_по #тестирование_мобильных_приложений #мониторинг_логов #kafka #kibana #sentry #jaeger

Логи: всё, что нужно знать тестировщику

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

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

#логи #логирование #тестирование_вебприложений #тестирование_по #тестирование_мобильных_приложений #мониторинг_логов #kafka #kibana #sentry #jaeger

Логи: всё, что нужно знать тестировщику

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

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

#логи #логирование #тестирование_вебприложений #тестирование_по #тестирование_мобильных_приложений #мониторинг_логов #kafka #kibana #sentry #jaeger

Как можно писать логи

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

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

#логирование #логи #observability #logs #java

Закон Конвэя внутри нас: инженерные системы ломаются по тем же причинам, что и люди

Linux пропитан магией. Тип файла определяется не по расширению, а библиотекой magic, которая смотрит на сигнатуру первых байтов. В системе живут демоны, процессы могут работать в режиме daemon, а исполняемые файлы хранятся в формате ELF и разбираются утилитой readelf. Это похоже на шутки старых разработчиков, но они появились не случайно. Инженерные системы наполнены метафорами, потому что так проще думать о сложном, объяснять невидимое и работать с тем, что нельзя потрогать руками. Со временем мы привыкаем к этой «магии» и перестаём замечать, что вместе с ней перенимаем определённый способ мышления. Закон Конвэя обычно применяют к организациям и архитектурам. Но этот принцип работает и на уровне отдельного человека. Каждый из нас тоже система со своими процессами, ограничениями, шаблонами мышления и сбоями.

https://habr.com/ru/companies/X5Tech/articles/1005562/

#systems_thinking #закон_конвэя #архитектура_систем #системное_мышление #распределенные_системы #наблюдаемость #логирование #деградация_системы #когнитивная_нагрузка #устойчивость_системы

Эволюция логирования в Lenta tech: от Loki до Victoria Logs

Привет, Habr! Меня зовут Максим Юрченко, я руководитель группы DevOps-инженеров в Lenta tech («Группа Лента»). В статье я расскажу о том, как за последние четыре года менялась наша система логирования, какие решения мы принимали по ходу роста инфраструктуры и к какому результату в итоге пришли (спойлер — без подводных камней и граблей не обошлось).

https://habr.com/ru/companies/lentatech/articles/1012076/

#Elasticsearch #Loki #Victoria #victorialogs #logging #логирование #kubernetes

Запустить легко, эксплуатировать сложно: год жизни SOC «Газпром-Медиа Холдинга»

В 2024 году мы рассказывали , как развернули масштабный центр мониторинга безопасности над «Газпром-Медиа». Тогда даже позволили себе тезис о том, что способны подключить любой актив к мониторингу за одни сутки. Это правда, но опытный инженер, прошедший через реалии корпоративной среды, скажет вам, что запустить систему в продакшен — это всего лишь начало. А вот эксплуатировать ее на живой, постоянно изменяющейся инфраструктуре, где каждый день меняются сетевые доступы и появляются новые сервисы, — долгосрочная задача повышенной сложности. Что происходит, когда центр мониторинга безопасности федерального холдинга превышает отметку в 100 000 событий в секунду? Когда стандартные решения начинают буксовать, а инфраструктура разрастается до 100 сервисов? В 2025 году наша команда столкнулась именно с такими вызовами. В этой статье расскажем, как мы решали архитектурные «головоломки» высоконагруженного SIEM, боролись с экзотическими форматами логов медийных систем, создавали кастомные коннекторы и как Purple Team-учения помогли обнаружить настоящих злодеев.

https://habr.com/ru/companies/bastion/articles/1008436/

#soc #SIEM #информационная_безопасность #мониторинг #ClickHouse #KUMA #incident_response #высокие_нагрузки #корпоративная_безопасность #логирование

Запустить легко, эксплуатировать сложно: год жизни SOC «Газпром-Медиа Холдинга»

В 2024 году мы рассказывали , как развернули масштабный центр мониторинга безопасности над «Газпром-Медиа». Тогда даже позволили себе тезис о том, что способны подключить любой актив к мониторингу за одни сутки. Это правда, но опытный инженер, прошедший через реалии корпоративной среды, скажет вам, что запустить систему в продакшен — это всего лишь начало. А вот эксплуатировать ее на живой, постоянно изменяющейся инфраструктуре, где каждый день меняются сетевые доступы и появляются новые сервисы, — долгосрочная задача повышенной сложности. Что происходит, когда центр мониторинга безопасности федерального холдинга превышает отметку в 100 000 событий в секунду? Когда стандартные решения начинают буксовать, а инфраструктура разрастается до 100 сервисов? В 2025 году наша команда столкнулась именно с такими вызовами. В этой статье расскажем, как мы решали архитектурные «головоломки» высоконагруженного SIEM, боролись с экзотическими форматами логов медийных систем, создавали кастомные коннекторы и как Purple Team-учения помогли обнаружить настоящих злодеев.

https://habr.com/ru/companies/bastion/articles/1008436/

#soc #SIEM #информационная_безопасность #мониторинг #ClickHouse #KUMA #incident_response #высокие_нагрузки #корпоративная_безопасность #логирование

Запустить легко, эксплуатировать сложно: год жизни SOC «Газпром-Медиа Холдинга»

В 2024 году мы рассказывали , как развернули масштабный центр мониторинга безопасности над «Газпром-Медиа». Тогда даже позволили себе тезис о том, что способны подключить любой актив к мониторингу за одни сутки. Это правда, но опытный инженер, прошедший через реалии корпоративной среды, скажет вам, что запустить систему в продакшен — это всего лишь начало. А вот эксплуатировать ее на живой, постоянно изменяющейся инфраструктуре, где каждый день меняются сетевые доступы и появляются новые сервисы, — долгосрочная задача повышенной сложности. Что происходит, когда центр мониторинга безопасности федерального холдинга превышает отметку в 100 000 событий в секунду? Когда стандартные решения начинают буксовать, а инфраструктура разрастается до 100 сервисов? В 2025 году наша команда столкнулась именно с такими вызовами. В этой статье расскажем, как мы решали архитектурные «головоломки» высоконагруженного SIEM, боролись с экзотическими форматами логов медийных систем, создавали кастомные коннекторы и как Purple Team-учения помогли обнаружить настоящих злодеев.

https://habr.com/ru/companies/bastion/articles/1008436/

#soc #SIEM #информационная_безопасность #мониторинг #ClickHouse #KUMA #incident_response #высокие_нагрузки #корпоративная_безопасность #логирование

Запустить легко, эксплуатировать сложно: год жизни SOC «Газпром-Медиа Холдинга»

В 2024 году мы рассказывали , как развернули масштабный центр мониторинга безопасности над «Газпром-Медиа». Тогда даже позволили себе тезис о том, что способны подключить любой актив к мониторингу за одни сутки. Это правда, но опытный инженер, прошедший через реалии корпоративной среды, скажет вам, что запустить систему в продакшен — это всего лишь начало. А вот эксплуатировать ее на живой, постоянно изменяющейся инфраструктуре, где каждый день меняются сетевые доступы и появляются новые сервисы, — долгосрочная задача повышенной сложности. Что происходит, когда центр мониторинга безопасности федерального холдинга превышает отметку в 100 000 событий в секунду? Когда стандартные решения начинают буксовать, а инфраструктура разрастается до 100 сервисов? В 2025 году наша команда столкнулась именно с такими вызовами. В этой статье расскажем, как мы решали архитектурные «головоломки» высоконагруженного SIEM, боролись с экзотическими форматами логов медийных систем, создавали кастомные коннекторы и как Purple Team-учения помогли обнаружить настоящих злодеев.

https://habr.com/ru/companies/bastion/articles/1008436/

#soc #SIEM #информационная_безопасность #мониторинг #ClickHouse #KUMA #incident_response #высокие_нагрузки #корпоративная_безопасность #логирование

[Перевод] Когда разработчик просто сел рядом с инженером — и это спровоцировало DevOps-революцию

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

https://habr.com/ru/companies/flant/articles/993068/

#деплой #три_f #круг_боли #коллаборация #логирование #автоматизация_деплоя #кроссфункциональные_команды #наблюдаемость #непрерывное_улучшение #эмпатия_в_IT

[Перевод] Когда разработчик просто сел рядом с инженером — и это спровоцировало DevOps-революцию

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

https://habr.com/ru/companies/flant/articles/993068/

#деплой #три_f #круг_боли #коллаборация #логирование #автоматизация_деплоя #кроссфункциональные_команды #наблюдаемость #непрерывное_улучшение #эмпатия_в_IT

[Перевод] Когда разработчик просто сел рядом с инженером — и это спровоцировало DevOps-революцию

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

https://habr.com/ru/companies/flant/articles/993068/

#деплой #три_f #круг_боли #коллаборация #логирование #автоматизация_деплоя #кроссфункциональные_команды #наблюдаемость #непрерывное_улучшение #эмпатия_в_IT

[Перевод] Когда разработчик просто сел рядом с инженером — и это спровоцировало DevOps-революцию

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

https://habr.com/ru/companies/flant/articles/993068/

#деплой #три_f #круг_боли #коллаборация #логирование #автоматизация_деплоя #кроссфункциональные_команды #наблюдаемость #непрерывное_улучшение #эмпатия_в_IT

Под капотом qDebug(): как устроено логирование в Qt и что с этим можно сделать

Каждый Qt-разработчик начинает знакомство с фреймворком с магической строчки qDebug() << "Hello World" . Но задумывались ли вы, что происходит внутри этого вызова? Как Qt обрабатывает логи, какие есть ограничения, и главное — как это можно расширить под свои нужды? В этой статье я разберу внутреннее устройство системы логирования Qt, покажу её сильные и слабые стороны, а затем представлю свою библиотеку QtLogger — надстройку, которая превращает базовый механизм в полноценную систему логирования корпоративного уровня. Если вам не интересно вникать во внутренности qDebug(), но интересно узнать как решить его проблемы, то сразу переходите к разделу QtLogger — расширяем возможности .

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

#qt #logging #цветной_терминал #логирование #производительность #потокобезопасность #внутренности #qDebug #Log4Qt

[Перевод] Большой обзор релиза Go 1.26

Команда Go for Devs подготовила перевод большого обзора Go 1.26. Это один из самых масштабных релизов языка: серьёзные оптимизации производительности, улучшения стандартной библиотеки, новые инструменты для тестирования и логирования, а также обновлённый go fix. Разбираем, что именно изменилось и почему этот релиз важен для разработчиков.

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

#go126 #golang #производительность #тестирование #логирование #разработка

Логирование с Serilog: как повысить отказоустойчивость и скорость

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

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

#serilog #altenar #c# #net #логирование #spbdotnet

Логирование с Serilog: как повысить отказоустойчивость и скорость

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

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

#serilog #altenar #c# #net #логирование #spbdotnet

Логирование с Serilog: как повысить отказоустойчивость и скорость

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

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

#serilog #altenar #c# #net #логирование #spbdotnet

Логирование с Serilog: как повысить отказоустойчивость и скорость

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

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

#serilog #altenar #c# #net #логирование #spbdotnet