Конечно не так удобно. Особенно если ты давно с ней работал и руки привыкли. Человеку всегда тяжело переходить на новое, надо же изучить. Но тут плюс в том, что не пришлось учить новый язык запросов, так как SQL знает большинство. Мы вообще пошли немного дальше уже, о чем расскажем отдельно. Мы в этом году поменяли структуру хранения в базе, требования к самим логам, и сделали GUI для поиска по логам, которое упрощает поиск. Об этом расскажем несколько позже.
Опишем в отдельной статье. Пока вот можете посмотреть в видео доклада https://devopsconf.io/moscow/2024/abstracts/11564 (если доступ есть), или хотя бы в презентации (она там доступна для скачивания) с слайда 115 про Unified Log Pipeline.
У нас есть Minio, а в S3 в принципе можно прямо из Clickhouse настроить выгрузку для холодного хранилища. Пока у нас все на своих ресурсах внутри наших ЦОД.
Вот интересно как там с отладкой обработчиков логов, в vector я тесты пишу и их гоняю, как там в Loki не знаю. Возможно там другой подход
Посмотрел в вашей статье картинки, очень заинтерисовало как выделали схему по этапам трансформации сообщений. Это только картинка для статьи или у вас есть интерфейс визуализации топологии Vector? Я такой видел в демо DataDog (они купили vector и развивают), у них там видно как трансформы соединены и как идет переток событий https://youtu.be/GjcLWupY0jk?t=2990
Спасибо за ссылку - не видел этой статьи. Действительно проблема схожая. Там они еще описывают, как изменили свою схему хранения в ClickHouse. Мы тоже отошли от начальной схемы и сейчас переходим на новую - об этом я тоже расскажу, но позже.
200 Гб в день - это верно для нашей инфраструктуры. Мы можем и 1Тб генерить, только разреши писать все от DEBUG уровня и все запросы с телом запроса )) Но нам и 200 хватает )
Уже давал коммент по поводу Loki выше. В 2018 году он был совсем зелен и не рассматривался как готовое в прод решение.
Я бы с удовольствием прочитал о вашем решении, чтобы посмотреть и сравнить. У нас используются bloom фильтры в Clickhouse, вероятно в вас тоже он?
Говоря о нашем решении мы сразу оговариваемся, что мы были ограничены в ресурсах, потому мы выбирали компромиссное решение, а не лучшее.
Команды следят за своими логами - это их сервисы и их логи, которые они знают хорошо и могут оценить их актуальность достоверно. Мы же предоставляем сервис по их сбору и хранению.
Что сказать, в момент выбора мы полагались на официальную документацию Vector в которой уже было описано решение с Kafka, как готовое для прод применений. Так как время дорого, а все для ее воплощения было под рукой, то мы ее и применили.
Можете поподробнее рассказать про вашу схему с балансировщиками (что за балансировщики применяли)? И что за вектор-прокси? Как в этой схеме обеспечивается защита от потери логов в моменты перезагрузки vector (например в нашем случае буфер на агенте точно не спасет, так как логов очень много)
Я выступил первый раз на DevOpsConf 2024 и мне понравилось, мне этого реально не хватало - обратной связи от коллег по цеху. Лично я себя чувствовал замечательно, ещё весь день после доклада был на стенде и отвечал на вопросы по докладу. Из некоторых вопросов даже по своей теме узнаешь новое, потому что не во все уголки еще слазил, как оказывается - это круто. Меня народ зарядил и взбодрил, хочу еще.
банально даже в логах договориться поля назвать и то проблема бывает.
Я работал в международной команде и код писали на английском, словаря общего сначала не было, но после епенно сделали, причем это было от бизнеса. Каждый новичок должен был изучить этот словарь перед началом работы. Меня сначала коробило куча англицизмов в речи русскоговорящей команды и тоже самое в доке, пытался переводить, но понял - зря трачу время, проще уже словарь этот в речи и коже использовать.
Также был прикол, что один программист у нас учил немецкий, он переменные по немецки и называл ) мы сначала не могли понять причем тут нач.бар, оказалось nachbar - сосед, а он так в графе соседний узел называл.
В итоге я пришел к мысли, что язык терминов и переменных должен быть понятен большинству, а главное бизнесу, при этом это может быть любой национальный язык.
Оборачивать библиотеки в свои интерфейсы хорошо: 1) это лишает вас женской привязки 2) добавляет читабельности 3) позволяет спрятать ненужные нам методы.
Я лично был за перевод в английский, но вижу что не все коллеги это могут и вставляют гугл перевод. Потому я сменил мнение после этой статьи. В российском продукте для наших рынков русскоговорящей команде транслит будет больше во благо, да будет смесь местами с служебными словами языка программирования, но их число ограничено, они тут как раз как фон, а сам смысл именно в бизнес терминах и операциях. Я теперь даже думаю и переменные русским писать, где это язык позволяет.
А словарь терминов нужен все равно, причем по доменам. Бывает один и тот же термин в разных предметных областях значит разное. В идеале хочется добиться однозначности названий, но это путь к выдумыванию новых слов и языка, типа как товары Икея называет.
Нормальный проект начинает с MVP для проверки идеи, а по ее подтвержении развивают итеративно.
Сделай хорошо, а не круто.
И многие не понимают, что разработка ПО это такое же производство, тот же завод ,а процесс разработки - внесение изменений, доставки - конвеер. И на разных участках непрерывность поддерживают разные люди.
Можно плитку из цемента самостоятельно делать штучно, а можно тысячами и разные варианты - и ресурсы и проблемы будут разные.
А что есть инцидент в контексте on-call? Когда инцидент открывается? И есть ли у нас список всех инцидентов, чтобы потом смотреть потом статистику по ним?
Татьяна Гребенюкова еще делилась историями других компаний? У меня на примете такой список Industry insights от blameless https://www.blameless.com/industry-leader-insights
Конечно не так удобно. Особенно если ты давно с ней работал и руки привыкли. Человеку всегда тяжело переходить на новое, надо же изучить. Но тут плюс в том, что не пришлось учить новый язык запросов, так как SQL знает большинство.
Мы вообще пошли немного дальше уже, о чем расскажем отдельно. Мы в этом году поменяли структуру хранения в базе, требования к самим логам, и сделали GUI для поиска по логам, которое упрощает поиск. Об этом расскажем несколько позже.
Опишем в отдельной статье. Пока вот можете посмотреть в видео доклада https://devopsconf.io/moscow/2024/abstracts/11564 (если доступ есть), или хотя бы в презентации (она там доступна для скачивания) с слайда 115 про Unified Log Pipeline.
У нас есть Minio, а в S3 в принципе можно прямо из Clickhouse настроить выгрузку для холодного хранилища. Пока у нас все на своих ресурсах внутри наших ЦОД.
Вот интересно как там с отладкой обработчиков логов, в vector я тесты пишу и их гоняю, как там в Loki не знаю. Возможно там другой подход
Посмотрел в вашей статье картинки, очень заинтерисовало как выделали схему по этапам трансформации сообщений. Это только картинка для статьи или у вас есть интерфейс визуализации топологии Vector? Я такой видел в демо DataDog (они купили vector и развивают), у них там видно как трансформы соединены и как идет переток событий https://youtu.be/GjcLWupY0jk?t=2990
Спасибо за ссылку - не видел этой статьи. Действительно проблема схожая.
Там они еще описывают, как изменили свою схему хранения в ClickHouse. Мы тоже отошли от начальной схемы и сейчас переходим на новую - об этом я тоже расскажу, но позже.
200 Гб в день - это верно для нашей инфраструктуры. Мы можем и 1Тб генерить, только разреши писать все от DEBUG уровня и все запросы с телом запроса )) Но нам и 200 хватает )
Уже давал коммент по поводу Loki выше. В 2018 году он был совсем зелен и не рассматривался как готовое в прод решение.
Я бы с удовольствием прочитал о вашем решении, чтобы посмотреть и сравнить. У нас используются bloom фильтры в Clickhouse, вероятно в вас тоже он?
Говоря о нашем решении мы сразу оговариваемся, что мы были ограничены в ресурсах, потому мы выбирали компромиссное решение, а не лучшее.
Команды следят за своими логами - это их сервисы и их логи, которые они знают хорошо и могут оценить их актуальность достоверно. Мы же предоставляем сервис по их сбору и хранению.
Grafana Loki + Promtail сам появился только в апреле 2018 года и был достаточно сырой, потому был исключен из рассмотрения в нашем случае.
Что сказать, в момент выбора мы полагались на официальную документацию Vector в которой уже было описано решение с Kafka, как готовое для прод применений. Так как время дорого, а все для ее воплощения было под рукой, то мы ее и применили.
Можете поподробнее рассказать про вашу схему с балансировщиками (что за балансировщики применяли)? И что за вектор-прокси? Как в этой схеме обеспечивается защита от потери логов в моменты перезагрузки vector (например в нашем случае буфер на агенте точно не спасет, так как логов очень много)
OpenSearch не рассматривали, logstash - отказались еще до перехода на ELK, причины поросли мхом уже. А Filebit да смотрели, но vector победил - вот тут https://medium.com/ibm-cloud/log-collectors-performance-benchmarking-8c5218a08fea можно посмотреть сравнение
У нас 3 ЦОЦ и между ними есть избыточная связанность. Надежность для нас достаточная.
Я выступил первый раз на DevOpsConf 2024 и мне понравилось, мне этого реально не хватало - обратной связи от коллег по цеху. Лично я себя чувствовал замечательно, ещё весь день после доклада был на стенде и отвечал на вопросы по докладу. Из некоторых вопросов даже по своей теме узнаешь новое, потому что не во все уголки еще слазил, как оказывается - это круто. Меня народ зарядил и взбодрил, хочу еще.
То что есть еще одна альтернатива - это отлично. Есть такие нишевые штуки, где не нужно таких огромных объемов.
банально даже в логах договориться поля назвать и то проблема бывает.
Я работал в международной команде и код писали на английском, словаря общего сначала не было, но после епенно сделали, причем это было от бизнеса. Каждый новичок должен был изучить этот словарь перед началом работы. Меня сначала коробило куча англицизмов в речи русскоговорящей команды и тоже самое в доке, пытался переводить, но понял - зря трачу время, проще уже словарь этот в речи и коже использовать.
Также был прикол, что один программист у нас учил немецкий, он переменные по немецки и называл ) мы сначала не могли понять причем тут нач.бар, оказалось nachbar - сосед, а он так в графе соседний узел называл.
В итоге я пришел к мысли, что язык терминов и переменных должен быть понятен большинству, а главное бизнесу, при этом это может быть любой национальный язык.
Оборачивать библиотеки в свои интерфейсы хорошо: 1) это лишает вас женской привязки 2) добавляет читабельности 3) позволяет спрятать ненужные нам методы.
Я лично был за перевод в английский, но вижу что не все коллеги это могут и вставляют гугл перевод. Потому я сменил мнение после этой статьи. В российском продукте для наших рынков русскоговорящей команде транслит будет больше во благо, да будет смесь местами с служебными словами языка программирования, но их число ограничено, они тут как раз как фон, а сам смысл именно в бизнес терминах и операциях. Я теперь даже думаю и переменные русским писать, где это язык позволяет.
А словарь терминов нужен все равно, причем по доменам. Бывает один и тот же термин в разных предметных областях значит разное. В идеале хочется добиться однозначности названий, но это путь к выдумыванию новых слов и языка, типа как товары Икея называет.
Это про как делать не надо пример.
Нормальный проект начинает с MVP для проверки идеи, а по ее подтвержении развивают итеративно.
Сделай хорошо, а не круто.
И многие не понимают, что разработка ПО это такое же производство, тот же завод ,а процесс разработки - внесение изменений, доставки - конвеер. И на разных участках непрерывность поддерживают разные люди.
Можно плитку из цемента самостоятельно делать штучно, а можно тысячами и разные варианты - и ресурсы и проблемы будут разные.
DataDog развивает vector.dev потому что он сам его использует как фичу https://www.datadoghq.com/product/observability-pipelines/. Только она у них обмазана в красивый интерфейс.
я видел в этом боте - он смотрит на иконку статуса в мессенджере. Если пальма или смайлик с градусником - добавляет в исключения.
А что есть инцидент в контексте on-call? Когда инцидент открывается?
И есть ли у нас список всех инцидентов, чтобы потом смотреть потом статистику по ним?
некропостинг )
Татьяна Гребенюкова еще делилась историями других компаний? У меня на примете такой список Industry insights от blameless https://www.blameless.com/industry-leader-insights