Детсад будет жить. Поприветствуем!

Коллеги, что за Детсад?) (простите, не удержался)

Место твоё в детсаду

Добрый день. У меня стоит простая задача - сделать так, чтобы логи писались из приложения в elasticsearch. Приложение - java. Логов может быть как много, так и мало, поэтому я хочу сделать буферизацию, чтобы посылать логи в эластик пачками. И заодно выкидывать логи если elastic не справляется или упал там. Я хочу для этой цели использовать fluentd. Есть планы перейти на fluent-bit, но пока fluentd. И соответственно использовать memory buffer. Но у меня не получается. И поэтому я хотел попросить кого-нибудь, кто это уже делал мне подсказать - это же обычная задача - многие наверняка с ней сталкивались. В частности мне совершенно непонятно как работают эти буфера и chunks во fluentd. Я по наивности полагал, что если не настраивать ключи для chunks, то fluentd будет выделять из общей памяти размером total_limit_size пространство под чанк, заполнять этот чанк новыми сообщениями и потом, как только чанк заполнится сообщениями на chunk_full_threshold начнет пытаться его отсылать. Если память кончится, то если выставить overflow_action drop_oldest_chunk, то старые чанки будут выкидываться. Но все оказалось не так, как я думал. А как - я не понимаю и поэтому прошу помочь разобраться. Итак конкретика: сначала у меня была конфигурация вот такая: <buffer> @type memory flush_interval 1s retry_forever false retry_wait 10 retry_exponential_backoff_base 2 retry_max_times 4 chunk_limit_size 512K total_limit_size 32M overflow_action drop_oldest_chunk fluentd 1.1 В принципе все работало, но память, потребляемая вырастала больше 150мегабайт. Но у нас же сконфигурено было 32мега лимит - откуда 150? Я попытался сделать по-другому: <buffer> @type memory ... flush_mode immediate chunk_limit_size 1M chunk_limit_records 1000 total_limit_size 32M и оно вообще перестало писать в эластик. Но ведь кто-то же умеет. Подскажите, а?

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

Редис вроде логи писать может , вплоть до синхронных

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

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

Ну там время в секундах выставляется, лог пишется последовательно, сложно будет упереться в диск. Чем не "взрослая" база данных? Там тоже fsync на каждую транзакцию никто не делает. (Нагруженный редис не практиковал, по-этому рассуждаю/спрашиваю)

Ну там время в секундах выставляется, лог пишется последовательно, сложно будет упереться в диск. Чем не "взрослая" база данных? Там тоже fsync на каждую транзакцию никто не делает. (Нагруженный редис не практиковал, по-этому рассуждаю/спрашиваю)

нет, там не так.

в режиме aof ты можешь сказать либо работать в режиме direct io тоесть на каждую операцию у тебя fsync, либо раз в секунду, либо никогда.

да, это похоже на БД, только дело в том что тут как бы у тебя что лог что данные, одна сущностть. и просто оно периодически компактится.

Ну там время в секундах выставляется, лог пишется последовательно, сложно будет упереться в диск. Чем не "взрослая" база данных? Там тоже fsync на каждую транзакцию никто не делает. (Нагруженный редис не практиковал, по-этому рассуждаю/спрашиваю)

"уперется в диск" - несовсем понимаю что значит, но там проблема в том что компакт(реврайт аоф) может вызывать спайки по дисковому ио.

Добрый день. У меня стоит простая задача - сделать так, чтобы логи писались из приложения в elasticsearch. Приложение - java. Логов может быть как много, так и мало, поэтому я хочу сделать буферизацию, чтобы посылать логи в эластик пачками. И заодно выкидывать логи если elastic не справляется или упал там. Я хочу для этой цели использовать fluentd. Есть планы перейти на fluent-bit, но пока fluentd. И соответственно использовать memory buffer. Но у меня не получается. И поэтому я хотел попросить кого-нибудь, кто это уже делал мне подсказать - это же обычная задача - многие наверняка с ней сталкивались. В частности мне совершенно непонятно как работают эти буфера и chunks во fluentd. Я по наивности полагал, что если не настраивать ключи для chunks, то fluentd будет выделять из общей памяти размером total_limit_size пространство под чанк, заполнять этот чанк новыми сообщениями и потом, как только чанк заполнится сообщениями на chunk_full_threshold начнет пытаться его отсылать. Если память кончится, то если выставить overflow_action drop_oldest_chunk, то старые чанки будут выкидываться. Но все оказалось не так, как я думал. А как - я не понимаю и поэтому прошу помочь разобраться. Итак конкретика: сначала у меня была конфигурация вот такая: <buffer> @type memory flush_interval 1s retry_forever false retry_wait 10 retry_exponential_backoff_base 2 retry_max_times 4 chunk_limit_size 512K total_limit_size 32M overflow_action drop_oldest_chunk fluentd 1.1 В принципе все работало, но память, потребляемая вырастала больше 150мегабайт. Но у нас же сконфигурено было 32мега лимит - откуда 150? Я попытался сделать по-другому: <buffer> @type memory ... flush_mode immediate chunk_limit_size 1M chunk_limit_records 1000 total_limit_size 32M и оно вообще перестало писать в эластик. Но ведь кто-то же умеет. Подскажите, а?

мож память фрагментировало сильно и не отдавало назад системе?

Работа !!! будет жить. Поприветствуем!

Приехали

Ну там время в секундах выставляется, лог пишется последовательно, сложно будет упереться в диск. Чем не "взрослая" база данных? Там тоже fsync на каждую транзакцию никто не делает. (Нагруженный редис не практиковал, по-этому рассуждаю/спрашиваю)

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

Ребята! Я заболел ?? Но уже выздоравливаю. Прилетел, и на следующий день заболел. Очень обидно( А пока я поправляюсь, посмотрите какую крутую статью написал Юра Рочняк в блоге на медиуме: https://medium.com/preply-engineering/lambda-edge-and-where-to-find-it-92b7c9c37f22 ?Во-первых, у него в Preply все очень неплохо, и хорошая экспертиза в serverless-related штуках; ?Во-вторых, завести блог, да еще и на английском - многого стоит. ?В-третьих, это действительно технически грамотная статья о Lambda@Edge + Cloudfront + Terraform; Preply, you rock! ??? (нажамкайте Юре пальцев вверх, и наверное он напишет еще что-то полезное)

Ебаный хромиум ушатывает мне файлуху по кд при запуске на 16.04. Это всё что нужно знать об охуенном опенсорсе.

Ебаный хромиум ушатывает мне файлуху по кд при запуске на 16.04. Это всё что нужно знать об охуенном опенсорсе.

Толсто

Ебаный хромиум ушатывает мне файлуху по кд при запуске на 16.04. Это всё что нужно знать об охуенном опенсорсе.

Может дело не в файлухе и хромиуме?!?

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

Есть ссылка на багрепорт?)

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

Диск-то живой?

Живой. Вот уже почти час прошел - ни одной ошибки. При старте хромиума файлуха сразу в РО.

Живой. Вот уже почти час прошел - ни одной ошибки. При старте хромиума файлуха сразу в РО.

Смарт с диска давно снимали?

Если файлуха разваливается, то лучше переразметить диск заново, а не каждый раз чинить fsck

Ну, переустановить я всегда смогу. Для начала "пуржну" хромиум. Но, сука, я домой прихожу чтобы деградировать, а не ебаться с файлухами по пятницам?

а не надо в пятницу вносить изменения

Ну, переустановить я всегда смогу. Для начала "пуржну" хромиум. Но, сука, я домой прихожу чтобы деградировать, а не ебаться с файлухами по пятницам?

Просто тогда твоя файлуха должна разваливаться любым браузером на базе хромиума) Пока слабо верится, что получилось найти уникальный use-case, так влияющий на файлуху

Ну, переустановить я всегда смогу. Для начала "пуржну" хромиум. Но, сука, я домой прихожу чтобы деградировать, а не ебаться с файлухами по пятницам?

Не btrfs ли у вас часом?

Не btrfs ли у вас часом?

Да ext4 обычная.

Старая история про постоянно пишущий на диск хром: https://productforums.google.com/forum/#!topic/chrome/DrM9vRQ6e_w

60 гигабайт в час на диск фигачит

Не, это не старая история. Старая - это какой-то архитектурный косяк в QT, из-за чего иногда отваливает буфер обмена общий в линупсах. У меня на десктопной телеге, на 12.04 и на 16.04 такое проявляется. Этому багу около десяти лет, который наблюдается в разных продуктах

В какой-то момент та же телега начинает срать чем-то вродеcannot change owner x11 - и конец до перезапуска.

Не, это не старая история. Старая - это какой-то архитектурный косяк в QT, из-за чего иногда отваливает буфер обмена общий в линупсах. У меня на десктопной телеге, на 12.04 и на 16.04 такое проявляется. Этому багу около десяти лет, который наблюдается в разных продуктах

Он отваливается через кажется 42.7 дней аптайма

Бага простая, там где то таймер 32 бита

Но чуть ли не микросекундный

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

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

Он отваливается через кажется 42.7 дней аптайма

Блин, а я думаю чо ж в телеграме буфер отмена отвалился

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

Там не тока в телеге дело

Там не тока в телеге дело

Да это QT шная какая-то бага. Ей уже лет десять минимум.

WORK 24/7 будет жить. Поприветствуем!

Товарищ майор будет жить. Поприветствуем!

WORK 24/7 будет жить. Поприветствуем!

:’(

Это ты у меня будешь жить. Или нет

ERROR: S client not available

Это надо заскринить

лол

Видели вакансию в яндекс?)

какую из?

Видели вакансию в яндекс?)

У них из кг и маленькая тележка ?

Ну я девопс жобс сегодняшнюю

в этой помойке кто то еще сидит?

в этой помойке кто то еще сидит?

сидят и не матерятся, да

чудеса

тут вообще на днях псоле аварии была веерная рассылка от яндекса

Ну я девопс жобс сегодняшнюю

А не не видел

Яндекс меня постоянно в линкид пингуют , а прочитать профиль им не судьба

У меня подогрелся стул такое читать

Один хрен зп у яндекса были так себе

Скиньте сюда ресендом

#вакансия #DevOps #moscow #fulltime Город и адрес офиса: Москва, м. Парк Культуры Формат работы: офис Занятость: полная Зарплатная вилка: от 100 000 до 200 000 далее по результатам собеседования Описание вакансии: В компанию Яндекс, лидеру поисковых технологий на российском рынке, требуется DevOps. Требования: - опыт программирования (С++, Python, bash); - способность действовать самостоятельно; - ответственность, аккуратность, умение общаться с людьми; - желание развиваться и работать в команде; - готовность к быстрым изменениям окружающей среды; - понимание принципов работы веб-сервисов и протокола HTTP; - наличие опыта работы с Unix-системами; - опыт проектирования систем, работающих непрерывно и бесперебойно (24х7х365); - аналитические навыки предотвращения и быстрого устранения неисправностей. Обязанности: - профилировать и оптимизировать код; - анализировать нештатные ситуации, участвовать в решении проблем на сервисах; - придумывать и улучшать мониторинги и тесты; - автоматизировать выполнение ежедневных процессов. 80% разработки, 20% администрирование Что предоставляем компания: - белую зарплату и рост по результатам performance review; - ДМС, компенсация питания; - просторный и современный офис в центре Москвы; - сильную команду специалистов, с которой можно расти. Название компании: private recruiter Контакты: @krburmistrova (telegram) — ? Обсуждение вакансии в чате @devops_jobs

Интересно, что это похоже не их рекрутеры

тут вообще на днях псоле аварии была веерная рассылка от яндекса

Даже так?)

Непонятно что это за проект даже

Даже так?)

Ну там всем писали и сетевикам даже

Ну за последнее время это самая крупная авария у яндекса, как я понимаю

- способность действовать самостоятельно ... - желание развиваться и работать в команде