Казалось бы простая задача - переместить логи из пункта А в пункт Б, что тут сложного. Но даже для такой пустяковой задачи придумали множество ПО: как более популярных Rsyslog, Logstash, fluentd, fluentbit, так и менее известных как file.d, недавно принудительно-опенсорснутая Пилорама (спасибо, Яндекс!).

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

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

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

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

Фидбэк от команды оказался позитивным, поэтому я решил поделиться знаниями и с сообществом.

В этом посте я начну с самых основ - поделюсь как я выстраиваю коммуникацию с каждым отдельным участником команды. Если пост получит хороший отклик - постараюсь раскрыть и другие темы.

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

Помимо правил, в самом начале с вами поделились интересной информацией. Вероятность того, что инопланетянин достанет чёрный камень — всегда 50%. За несколько секунд до начала игры друг шепнул вам о стратегии, которой нужно придерживаться. И в результате, после бесконечного числа партий, вы оба стали победителями. Просто подфартило? Или сработала стратегия партнера?

Вопрос выбора СУБД для российской компании или госоргана – вопрос не праздный, тем более сейчас – когда с момента ухода с рынка западных вендоров прошло уже полтора года и пора что-то решать. Но как не запутаться в номенклатуре СУБД и выбрать ту, которая лучше всего подходит? Без ложной скромности скажу: мы в «Кругах Громова» уже немного поднаторели в систематизации, поэтому надеемся, что наша шпаргалка для тех, кто хочет выбрать СУБД, окажется полезной.

Начнем с классики. СУБД делятся на несколько типов. Не будем описывать их подробно, остановимся только на их основном предназначении.

Виртуальная машина eBPF, работающая в ядре Linux, приближается к десятилетнему юбилею своего включения в состав Linux; за это время она успела превратиться в инструмент, имеющий целое множество применений в этой экосистеме. Алексей Старовойтов (Alexei Starovoitov), который является создателем eBPF и занимался ее развитием, особенно на начальном этапе, выступил на открытии Linux Security Summit Europe 2023 с докладом о взаимосвязи BPF и безопасности. В нем он поделился с нами интересными историческими моментами в несколько иной перспективе, нежели они обычно раскрываются. Среди прочего, он рассказал, как BPF на протяжении всего своего пути была одновременно и проблемой безопасности, и ее решением.

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

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

Технологическая платформа 1С:Предприятие – это большой программный продукт (только на С++ - более 10 миллионов строк кода, а есть ещё Java и JavaScript). Подробнее про устройство платформы можно прочитать тут.

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

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

Если вам понадобилось обучить нейронную сеть обнаруживать объекты на изображении или в видеопотоке, то для вас есть хорошие новости - уже существуют простые в использовании готовые инструменты. Наверняка кто-то из читателей такими пользуется. Например модель YOLOv8 хорошо тренируется на новых данных "из коробки". И, наверное, права была посетитель выставки, которая около стенда демонстрирующего обнаружение животных на видео c БПЛА сказала: "Что тут такого. Я за 10 строчек кода такое сделаю".
Но что, если сделал все по инструкции, а оно не работает так как хочется?

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

Это очередная статья из цикла «BPF для самых маленьких» (0, 1, 2) и первая из серии практических статей про трассировку Linux современными средствами.

Из нее вы узнаете о программе и языке bpftrace — самом простом способе погрузиться в мир BPF с практической точки зрения, даже если вы не знаете про BPF ровным счетом ничего. Утилита bpftrace позволяет при помощи простого языка прямо из командной строки создавать программы-обработчики и подсоединять их к огромному количеству событий ядра и пространства пользователя. Посмотрите на КПДВ ниже… поздравляю, вы уже умеете трейсить системные вызовы при помощи bpftrace!

В отличие от предыдущих статей серии, эта относительно короткая и ее основная часть написана в формате туториала, так что уже после пяти минут чтения вы сможете создавать обработчики и собирать статистику о любом событии в ядре Linux прямо из командной строки. В конце статьи рассказывается об альтернативах — ply и BCC. Минуты во фразе «после пяти минут чтения» подразумеваются меркурианские. Появление уникальных навыков после пяти минут чтения не гарантируется.

В начале была технология и называлась она BPF. Мы посмотрели на нее в предыдущей, ветхозаветной, статье этого цикла. В 2013 году усилиями Алексея Старовойтова (Alexei Starovoitov) и Даниэля Боркмана (Daniel Borkman) была разработана и включена в ядро Linux ее усовершенствованная версия, оптимизированная под современные 64-битные машины. Эта новая технология недолгое время носила название Internal BPF, затем была переименована в Extended BPF, а теперь, по прошествии нескольких лет, все ее называют просто BPF.

Грубо говоря, BPF позволяет запускать произвольный код, предоставляемый пользователем, в пространстве ядра Linux и новая архитектура оказалась настолько удачной, что нам потребуется еще с десяток статей, чтобы описать все ее применения. (Единственное с чем не справились разработчики, как вы можете видеть на кпдв ниже, это с созданием приличного логотипа.)

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

Berkeley Packet Filters (BPF) — это технология ядра Linux, которая не сходит с первых полос англоязычных технических изданий вот уже несколько лет подряд. Конференции забиты докладами про использование и разработку BPF. David Miller, мантейнер сетевой подсистемы Linux, называет свой доклад на Linux Plumbers 2018 «This talk is not about XDP» (XDP – это один из вариантов использования BPF). Brendan Gregg читает доклады под названием Linux BPF Superpowers. Toke Høiland-Jørgensen смеется, что ядро это теперь microkernel. Thomas Graf рекламирует идею о том, что BPF — это javascript для ядра.

На Хабре до сих пор нет систематического описания BPF, и поэтому я в серии статей постараюсь рассказать про историю технологии, описать архитектуру и средства разработки, очертить области применения и практики использования BPF. В этой, нулевой, статье цикла рассказывается история и архитектура классического BPF, а также раскрываются тайны принципов работы tcpdump, seccomp, strace, и многое другое.

Разработка BPF контролируется сетевым сообществом Linux, основные существующие применения BPF связаны с сетями и поэтому, с позволения @eucariot, я назвал серию "BPF для самых маленьких", в честь великой серии "Сети для самых маленьких".

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

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

Но, что если нам надо перемножить два числа любой длины? Не LONG, не байт, не число от 1 до 10, а любые два числа, которое, имеют в общем случае длину n бит, а результат умножения может иметь длину 2n бит.

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

Давайте применим его к нашей задаче.

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

Сегодня обсудим «извечный вопрос»: как обнаружить точное местоположение пользователя методами OSINT? Первым делом вспомним, что OSINT – это совокупность методов и приемов работы с открытыми источниками информации. И в этом контексте самые очевидные способы обнаружения геолокаций заключаются в анализе той публичной информации, которую пользователи оставляют о себе в глобальной паутине. Это геометки и чекины в социальных сетях, анализ публичных записей, координаты в метаданных загружаемых фотографий, исследование фото и видео контента для выявления местоположения оператора и тому подобные.

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

«О чем это я?» или вместо предисловия.

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

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

Чего в статье нет: «золотых правил идеального тим-лида», детально-пошаговых инструкций по разрешению конфликтов и прочей нравоучительной нудятины.

В предыдущей статье "Дерево Киви для поиска шаблона по тексту" я рассказывал, как можно эффективно находить по входящему сообщению все удовлетворяющие "поисковые запросы", избегая их перебора "в лоб" и прямого сопоставления. Это можно применить реализации полноценной Pub/Sub-системы, дополняющей уже существующие, такие как Nats, Apache Kafka или AWS SNS новой возможностью поддерживать действительно масштабируемое число wildcard-подписок. В этой статье я расскажу о такой системе.

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