Transcription
Я здесь, чтобы поговорить с вами о том, что я могу только предположить, что для толпы, для всех любимая тема — это логи. Э-э, конкретно те, которые шумят в вашей среде, которые не дают ничего, кроме объема. И как мы смогли использовать конвейеры наблюдаемости, чтобы помочь решить некоторые из наших проблем. Итак, все началось с счета. Он был нехорошим. Это был тот тип, который вы открываете, протираете глаза и закрываете вкладку, думая, что, возможно, копия еще не вступила в силу. Вы открываете ее снова, надеясь, что цифры изменились, и они абсолютно не изменились. И становилось все хуже и хуже. >> [хмыкает] >> Но дело было не только в счете. Наши расходы на логи были неограниченными. Э-э, у нас была, по сути, одна корзина для оплаты всего и никакой реальной подотчетности. И они продолжали расти и расти и расти. И они были громкими. И не громкими, как много полезной информации. Громкими в смысле, где я вообще? Я ничего не вижу, кроме ASCII-баннеров, разбитых на многоуровневые события. Предупреждения срабатывали на этом шуме. Панели визуализировали этот шум. И мы платили за индексацию этого шума. И в дополнение к этому, у комплаенса были вопросы. У нас были данные PCI, которые нам нужно было отслеживать, и требования к хранению, которые варьировались в зависимости от команды. И всегда, казалось бы, идет аудит. Как будто постоянно происходит аудит. Итак, как мы сюда попали? Итак, это представление того, как выглядел наш конвейер раньше. Некоторые из вас, возможно, знакомы с этим. По сути, у нас было каждое приложение в корпорации, которое просто сбрасывало все, что хотело, в одно место. А именно, нашу бывшую безымянную платформу, Doom. Итак, результаты этого были таковы, что каждый лог, каждый уровень, каждая служба превращались скорее в воронку, чем в конвейер. Отладка, трассировка, проверки работоспособности, шум балансировщика нагрузки, все это. Просто на всякий случай. Итак, если это представление нашего объема логов до использования конвейеров наблюдаемости, хочет ли кто-нибудь рискнуть предположить, какой процент сокращения мы смогли достичь? О, 70 — это хорошо. >> [хмыкает] >> Итак, в целом мы смогли добиться сокращения на 40%. Это было бы более впечатляюще без предыдущего выступления, но э-э, так, 40% в целом. Э-э, по некоторым нашим конвейерам мы добились сокращения на 65-75%. Это составило примерно 1,2 петабайта в месяц до приема. Итак, как мы это сделали? Встречайте конвейеры. Итак, прежде чем я перейду к тому, что мы на самом деле сделали, я хочу убедиться, что мы все на одной волне, на случай, если вы не очень хорошо знакомы с конвейерами наблюдаемости. Кстати, я могу называть конвейеры OP во время этого выступления, и это не потому, что я обязательно считаю их слишком мощными, хотя они мне нравятся. Э-э, это потому, что это на шесть слогов короче. Итак, если вы посмотрите сюда, у вас есть наши стандартные источники логов, агент DataDog, OTEL, HTTPS, Elastic, тяжелый форвардер Splunk, Kafka, выбирайте, что хотите. И обычно, когда вы отправляете события через эти агенты, как вы знаете, они обычно идут напрямую к месту назначения. С конвейерами наблюдаемости мы вставляем стек в нашу инфраструктуру между источниками и местом назначения. Это позволяет нам последовательно маршрутизировать события через ряд процессоров для фильтрации, обогащения, редактирования и других действий. И с этого момента мы можем отправлять их дальше к месту назначения или к нескольким местам назначения, таким как DataDog, Microsoft Sentinel или S3. Это похоже на конвейеры логов на платформе DataDog, но опять же, это происходит до приема. Итак, давайте поговорим немного о некоторых процессорах, которые мы внедрили, чтобы помочь уменьшить шум наших логов. Итак, в нашей предыдущей реализации команды приложений могли отправлять свои отладочные логи в любую среду, которую они хотели. Это также означало, что они могли забыть отключить свои отладочные логи в любой среде, которую они хотели. Поэтому мы приняли решение отбрасывать отладочные логи до приема, используя процессор фильтрации. Это мгновенно удалило миллиарды событий из нашего приема. Пуф, исчезли. Как только мы добились успеха с этим, мы расширили его на логи уровня трассировки, в основном как предохранительный клапан. Теперь у отладочных логов и логов трассировки есть свое место, очевидно, но их не нужно принимать и хранить вечно. Наши команды приложений никогда не теряли из виду свои отладочные логи. Они всегда доступны в источнике. И для нас преимущества отбрасывания этих событий до приема перевешивали преимущества приема и хранения. Теперь, прямо перед Dash, мы запустили концепцию приложения под названием Kickflip, которое возвращает власть в руки команд приложений, чтобы они могли включать свои отладочные логи, если они им нужны на платформе для использования с такими вещами, как Bits AI. Итак, концепция заключается в том, что мы будем проверять наличие активного инцидента, и если он будет найден, мы изменим процессор фильтрации, а также фильтр исключения индексации платформы, скорее, на определенный период времени. Как только это время истечет, мы вернем его обратно. Итак, отладочные логи были легкой победой, но более интересная работа была связана с высокообъемными, низкоценными событиями. Итак, взгляните на этот пример. Одна из наших служб отправляла объемы, превосходящие любые другие службы. Итак, после анализа логов службы и разговора с командой приложения мы выяснили, что им просто не нужны все их информационные логи. Им нужны были некоторые из них. Можно сказать, статистически репрезентативная выборка из них, но не все. Итак, мы смогли использовать процессор выборки в OP, чтобы уменьшить объем выдаваемых логов со 100% до всего 10%. Это была победа-победа. Они были счастливы, мы были счастливы. >> [хмыкает] >> Э-э, одна из самых крутых вещей в этих процессах в целом — это то, насколько хирургически можно подойти к фильтрации. Итак, если вы посмотрите на второй пример, вы увидите, что мы смотрим на идентификатор приложения, конкретное сообщение и событие, а также конкретную среду. И если бы мы хотели добавить туда службу и статус, мы могли бы это сделать. Итак, эти процессоры выборки стали основной частью нашего контроля объема. Никто не аплодирует Grok-парсерам, что меня очень огорчает. Но вот в чем дело. Каждый оповещение, которое вы пишете, каждая панель, которую вы строите, каждое решение, принятое ниже по течению, зависит от того, что ваши логи структурированы должным образом. И если вы занимаетесь этим бизнесом какое-то время, вы знаете, что это просто не так. Поэтому мы смогли использовать процессоры парсинга и трансформации для структурирования событий логов, опять же, до приема для удобства использования с другими процессорами OP, а также с местами назначения, куда мы их отправляем. Итак, некоторые примеры этого — стандартный парсинг Grok, ввод сырой строки, вывод структурированных полей. Обогащение полей, где мы можем добавить имя команды, уровень службы, идентификатор приложения, что угодно. Пользовательские процессоры, волшебная палочка обработки событий. Я не думаю, что это официальный слоган, но я все еще работаю над этим, пока я здесь, на Dash. И затем пользовательская маркировка, где мы можем применять или удалять теги уровня конвейера перед тем, как они достигнут места назначения. Теперь вы можете спросить, почему мы делаем это в конвейерах наблюдаемости? Почему вы не делаете это в DataDog? Ну, мы не отправляем все в DataDog, и мы поговорим об этом в ближайшее время. Последний процессор, о котором я хочу упомянуть, — это процессор сканирования конфиденциальных данных. Как я уже сказал, я работаю в отрасли с большим количеством PCI, и если вы не знаете, что такое PCI, это сокращение от Payment Card Industry. Так что, если вы занимаетесь любыми транзакциями с кредитными картами, вы обязаны PCI и их аудиторам. И этим аудиторам не нравится, когда данные PCI попадают куда-то не туда. Поэтому мы смогли использовать процессор сканера конфиденциальных данных в конвейерах наблюдаемости для сканирования конфиденциальных данных и их очистки или редактирования до того, как они покинут наши стены. Это дополнительный уровень безопасности, который у нас есть перед отправкой данных по проводам, к которому мы были рады иметь доступ. И что может быть за техническая презентация без слайда, полного случайного кода, верно? Итак, это пример пользовательского процессора и некоторых базовых, но классных вещей, которые вы можете с ним сделать. Э-э, немного предыстории, прежде чем мы быстро рассмотрим код. В банке у нас есть идентификатор приложения, называемый car ID. На самом деле неважно, что это такое, просто у каждого приложения есть этот идентификатор. И мы хотели ввести некоторую систему управления вокруг этого идентификатора, чтобы гарантировать, что он существует и что он отформатирован должным образом. Итак, концепция пользовательских процессоров, мы могли бы использовать это для фактического выполнения этого управления. Итак, если мы настроим пользовательский процессор для просмотра потока событий, мы могли бы просмотреть каждое событие, извлечь значение, и как только у нас будет это значение, мы можем проверить, действительно ли оно существует, и получить его длину. Затем мы проводим фактическую проверку. Итак, мы можем установить тег отслеживания и пройти через шаги проверки, где мы делаем некоторые базовые вещи. Мы убеждаемся, что он существует. Мы убеждаемся, что у него нет ведущего нуля. Мы убеждаемся, что это только цифры. Мы убеждаемся, что это правильная длина, которую мы ищем. Если что-то из этого не удается, мы устанавливаем тег drop flag в true. И если это оказывается true, мы фактически создаем тег drop log. А затем мы очищаем внутренние теги, чтобы мы не отправляли вперед то, что нам не нужно. >> [хмыкает] >> Теперь вы можете спросить, почему вы используете флаг отмены и тег отмены, и это странно и расточительно. Это просто пример некоторой логики, которую вы можете встроить в пользовательские процессоры. Э-э, они действительно, действительно мощные. Э-э, но концепция тега drop log заключается в том, что у вас может быть несколько пользовательских процессоров, выполняющих различную логику для событий, которые вы, возможно, захотите отбросить. А затем под этими пользовательскими процессорами вы можете установить процессор фильтрации, ищущий этот тег drop log, а затем отбросить все, что окажется true. Итак, это обеспечивает большую гибкость в отношении вашего потока событий. Теперь, как я уже сказал, получение значения, выполнение регулярных выражений, получение его длины — это все очень, очень базовые вещи. Но функции, доступные в пользовательских процессорах, огромны. Если у вас есть какой-либо интерес к этому, я настоятельно рекомендую вам взглянуть на них. >> [хмыкает] >> Итак, к этому моменту мы перестали думать о конвейере как о пересыльщике логов, а скорее как о платформе, которую мы могли бы использовать для фильтрации, выборки, парсинга или редактирования. Но, сделав все это, они все равно должны куда-то идти, верно? И эта часть назначения важна. Итак, куда мы должны это отправлять? Теперь я предполагаю, что, поскольку вы здесь, на Dash, вы все любите или, по крайней мере, чувствуете себя сложным по поводу Datadog. Это премиальный продукт, и он должен получать премиальные логи, верно? Но должен ли он получать все? Я люблю думать об этом как о размещении на рейсе. Я уверен, что большинство из вас прилетели сюда. Не каждый лог должен сидеть в первом классе. Некоторые логи круто тусуются в экономе. Некоторым логам нужно дополнительное пространство для ног, хотя они не могут отнести это на счет стоимости билета. А некоторым нужно вообще пропустить аэропорт и использовать совершенно другой вид транспорта. Вопрос, который мы начали задавать: заслуживает ли этот лог своего места? Является ли он высокосигнальным? Является ли это тем, на что инженер действительно будет смотреть? Нужна ли ему возможность запросов в реальном времени? Мы обнаружили, что это не всегда так. Итак, давайте поговорим об одном из этих альтернативных назначений. Наша команда безопасности обратилась к нам с дилеммой. Они только что выбрали новый инструмент SIEM, в данном случае Microsoft Sentinel, и им нужно было переместить огромное количество данных из старой системы в новую. Они также столкнулись с крайним сроком конца года, и если бы они не сделали этот шаг, они получили бы один из тех счетов, о которых я говорил в начале. Хотя мы предложили использовать выделенные коннекторы, где это возможно, у них все еще было множество источников, которые не имели разумного способа попасть в Microsoft Sentinel. Итак, после некоторого анализа мы смогли выделить некоторые конвейеры наблюдаемости для этого проекта. И круто то, что благодаря возможностям парсинга OP мы смогли соблюсти очень, очень строгие правила форматирования, которые, кажется, есть у Sentinel. Таким образом, они смогли использовать свой KQL для написания всех своих правил обнаружения по мере необходимости. Но, в дополнение к этому, у них все еще были свои собственные проблемы с комплаенсом. Поэтому мы смогли также отделить трафик для их комплаенса и отправить его прямо в архивы AWS S3. И круто то, что мы можем использовать поиск по архивам DataDog в этот момент, чтобы извлечь эти данные, скорее, напрямую обратно на платформу без предварительной дегидратации. Благодаря гибкости конвейеров наблюдаемости мы смогли завершить этот проект примерно за пятую часть времени, которое они оценили. Я говорю месяцы против лет. Итак, давайте рассмотрим пример этого конвейера. Итак, здесь у нас есть снимок экрана OP. Мне нравится темный режим, поэтому, вероятно, он выглядит немного иначе, чем в основном выступлении. Но, [хмыкает] вы можете видеть, что у нас есть источник DataDog слева. И мы разделяем поток событий на две разные группы процессоров. В верхнем есть процессор обогащения полей, который затем направляет его к некоторым Grok-парсерам. А затем в нижнем просто обычный фильтр, чтобы убедиться, что архив S3 получает только те данные, которые мы хотели туда отправить. Итак, если мы посмотрим на верхний поток и раскроем его, мы увидим, что мы проверяем конкретные критерии в сообщении. Если это найдено, мы добавляем поле источника к этому событию. Теперь я знаю, что вы скажете: «Эй, подождите секунду. У вас есть агент DataDog спереди. Он отправит поле источника. О чем вы говорите? Вы сумасшедший». И вы правы. >> [вздыхает] >> Меня ударили по рукам моя компания в отношении разговоров о чем-либо, что было в прямом эфире в продакшене. Так что это просто макет. Фактическая реализация, которую мы используем, имеет другой источник, и этот источник не предоставляет поле источника. Поэтому нам приходится добавлять его таким образом. Но как только мы добавим это, события перейдут ко второму процессору, Grok-парсерам. И вы можете видеть, что мы определяем или фильтруем по источнику, который мы установили на предыдущем шаге. А затем это просто пример некоторых Grok, которые мы написали для этого конкретного источника. Я думаю, в какой-то момент мне сказали, что мы были самыми активными пользователями Grok в Datadog. Я не уверен, было ли это только в OP или на платформе в целом, но если вы возьмете то, что мы здесь видим, и умножите примерно на 50, то это то, что нам пришлось сделать, чтобы завершить этот проект. А затем это просто еще один забавный пример того, что еще можно сделать с конвейером OP. Итак, источник слева, процессоры посередине, и затем вы можете разделить эти события на три назначения. Sentinel, Datadog и Elasticsearch по какой-то причине. Я не знаю, зачем вам это нужно, но я видел и более странные вещи. Итак, теперь, если мы вернемся и поговорим о нижнем потоке в отношении данных комплаенса, как я уже сказал, наша команда безопасности имела данные, которые им были нужны для комплаенса PCI, но они никогда не будут использоваться ни в каких правилах обнаружения. И поэтому мы решили отправить их в архивы. И помимо экономии на стоимости приема, были и другие преимущества. Во-первых, более длительные периоды хранения. Наша индексация на платформе была небольшой. Нам нужны были логи PCI как минимум на год. Но почему бы не пойти на безумство? Если у вас есть логи HIPAA, сохраняйте их на семь лет. Если вам просто очень нравятся ваши логи, сохраняйте их на 20 лет. Это все, что вы хотите. Они по своей сути имеют низкий доступ. Как я уже указал, они никогда не будут использоваться на панелях, никогда не будут использоваться в оповещениях, они не должны использоваться ни для чего, кроме аудитов. Что делает их аудируемыми по своей природе. Не путать с Naughty by Nature, выдающейся хип-хоп группой начала 90-х. Все излучается источником в известном хорошем состоянии. Что делает очень легким использование поиска по архивам DataDog для потоковой передачи данных обратно на платформу без повторной гидратации. Итак, вот пример этого поиска по архиву в реальности. Это вопрос, который кто-то может получить, проходя PCI-аудит. Покажите мне недействительную попытку входа за последний год. Обычно вам придется зайти в хранилище архива, найти область, извлечь файл, распаковать его, искать, надеяться найти свои вещи. Это целая куча проблем. Или, если вы можете повторно гидратировать обратно в DataDog, вы можете сделать это тоже, но все еще есть проблемы со временем. Это может занять от минут до часов, в зависимости от размера данных, которые вы пытаетесь извлечь. С помощью поиска по архиву вы просто ищете его, и он передает его. Итак, ищите неудачный вход, бум-бум-бум. Ой, учетная запись заблокирована, галочка, PCI-аудит пройден, следующий вопрос. Итак, мы только начинаем использовать этот инструмент, но мы очень воодушевлены возможностями. Итак, вот где мы оказались. Каждый лог имеет преднамеренное назначение. Мы смогли использовать конвейеры наблюдаемости для маршрутизации этих данных к различным назначениям и решения сложных реальных проблем, которые иначе заняли бы месяцы и месяцы. И в дополнение к этому мы смогли активно запрашивать эти архивы на платформе, что может сэкономить огромное количество времени на аудитах и устранении неполадок. На данный момент мы чувствуем себя неплохо. Мы сократили объем наших логов. Мы решили проблемы для себя и других команд. И мы стали очень, очень, очень хороши в произнесении слова «наблюдаемость». Но у нас все еще была проблема с приемом. У нас все еще было слишком много входящих логов, и нам нужно было решение. Итак, теперь я хотел бы немного поговорить о нашей программе квот. Проблема, с которой мы столкнулись, — это то, с чем, я уверен, сталкивались многие из вас. Вы работаете над оптимизацией логов. Ваш объем падает. Команды, которые не работали над оптимизацией логов, на самом деле не замечают этого из-за 47 запросов на новые функции, над которыми они работают и которые должны быть готовы через 3 дня, и все эти функции имеют очень подробные логи. Таким образом, объем снова растет, и вы возвращаетесь к тому, с чего начали. Нам нужна была обратная связь. Мы решили создать строгую, но гибкую программу квот. Итак, каждое приложение получает бюджет квоты на логи. Эти корзины были основаны на истории приема логов. Из-за количества приложений в компании мы решили сгруппировать их по уровням отказоустойчивости. Уровень один, где критически важные приложения получают большую корзину. Меньшие приложения получают меньшую корзину. Теперь, я далеко не буду говорить приложению уровня четыре, что им не нужно 8 ТБ логов в день. Но я могу сказать им, что это статистически не соответствует другим приложениям в их уровне. И если им нужны все эти терабайты, они могут профинансировать разницу между их выделенным объемом и тем, что они хотят принять. Итак, как это работает на практике? При 80% квоты логов команды мы отправляем им инцидент низкого приоритета. Просто напоминание о том, что вы близки к пределу. При 100% мы отправляем инцидент более высокого приоритета. Теперь люди получают уведомления и знают, что есть проблема с логированием. При 120% мы отключаем ваши логи. Мы используем API Observability Pipeline для одновременного обновления процессора фильтрации в 20 различных конвейерах. Теперь последний пункт, когда я его упоминаю, обычно вызывает кучу странных реакций. Некоторые вроде этого. Некоторые вроде этого. А однажды даже это. Но давайте поговорим об этом немного подробнее. Итак, мы создали пользовательское приложение, которое отслеживает предполагаемые метрики приема для платформы по службам. В данном случае это car ID, о котором я говорил ранее. Это приложение отслеживает бюджет службы и обеспечивает полную гибкость во включении или отключении потока логов, а также во временном или постоянном изменении лимитов квот. Квоты сбрасываются ежедневно. Так что, если вы превышаете свою квоту к 2:00 утра каждый день, нам, вероятно, следует взглянуть на эти устаревшие пакетные процессы, работающие ночью, которые печатают слово «готово» 42 миллиарда раз. Цель — не остановить логи. Это напомнить командам, что они несут ответственность за то, что они излучают, и помочь продвинуть тему оптимизации. Если команды запрашивают продление, оно предоставляется. Обновления этих правил почти мгновенны благодаря базовой архитектуре Observability Pipeline. Тем не менее, развертывание все еще было бурным. В любом предприятии трудно донести изменения таким образом, чтобы все были осведомлены об изменениях в политике. Мы отправляли месяцы коммуникации об этом, и для некоторых команд это все еще было сюрпризом, даже по сей день. Теперь я не говорю, что это реальные сообщения, которые мы получили, но я не говорю, что это не так. Итак, через пару недель мы действительно начали замечать кое-что. Команды начали заботиться. Они начали задавать вопросы, которые раньше не задавали о своем объеме логов, почему их так много, что они могут сделать для оптимизации, чтобы уложить свои логи в квоту. Что затем означало, что ASCII-баннеры начали исчезать, появилось больше структурированных логов, что привело к рассмотрению и обновлению стандартов логирования. И наш объем начал снижаться. И что более важно, он остался там, где мы ожидали. Итак, в итоге, что мы узнали? Вы не можете исправить то, чего не видите. Сначала инструментируйте свои конвейеры. Вам нужно иметь возможность измерять, прежде чем вы сможете оптимизировать. Маршрутизация — это продуктовое решение, а не инфраструктурная мысль. Будьте преднамеренны в том, куда вы отправляете события. Команды меняют поведение, когда их привлекают к ответственности. Мы не пытаемся быть злыми, но кто-то должен за это платить. И комплаенс и сокращение затрат не противоречат друг другу. Это две цели, одно решение, все счастливы. Затем, что вы должны украсть сегодня? Номер один, проверьте свои пять основных источников логов по объему. Я, я, мне кажется глупым говорить это на Dash. Я знаю, что вы все уже это сделали, но сделайте это снова. Продолжайте делать это снова и снова. Используйте все инструменты, которые предоставляет вам Datadog, для оптимизации этих логов. Имейте трудные разговоры с командами приложений. Я гарантирую, что вы найдете возможности для дополнительного сокращения. Если у вас уже есть доступ к конвейерам наблюдаемости, направьте некоторые данные куда-то, кроме Datadog. Зайдите туда, поиграйте и посмотрите, как легко работать с потоком событий. Я думаю, есть 19 процессоров и 22 различных назначения и миллион источников. Типа, вы можете отправить что угодно откуда угодно куда угодно. И затем три, выясните, кто владеет вашим бюджетом логов. Если никто не владеет, вы владеете. По крайней мере, на данный момент. И если это так, вы можете использовать эти знания, чтобы почувствовать себя уполномоченным принимать значимые изменения. Итак, в конце концов, конвейеры наблюдаемости не могут исправить все в вашей среде. Они не могут помочь культуре вашей команды. Они не могут исправить ваш график дежурств. И, к сожалению, они не могут улучшить качество еды в столовой, но я все еще работаю над этим запросом на новые функции. Что они могут сделать, так это дать вам контроль над чем-то, что, скорее всего, уже вышло из-под контроля. А контроль, как оказалось, — это половина битвы. Знание — это другая половина. G.I. Joe. И на этом я благодарю вас за то, что вы провели время со мной, и я готов ответить на любые вопросы.