Comments 54
Непродуктовая розница, большая федеральная сеть. В одной из версий ПО кассовой техники «Ритейла» по умолчанию было такое чудовищное логирование, что ТЕКСТОВЫЙ (txt) лог-файл вырастал до полного заполнения системного диска за день-полтора. Кассовые компы вставали колом один за одним. Осознание и локализация проблемы, аварийный откат на предыдущую версию драйвера от «Ритейла» потребовали времени. Не страшно, но суеты в те несколько дней у нас было очень много. Некоторые магазины хорошо так постояли, теряя выручку.
Тоже вот, простой клочок текстового лога, а поди ж ты.
на NTFS можно было сжатие на папку поставить, сильно помогало в таких случаях
Тоже вот, простой клочок текстового лога, а поди ж ты.
По непонятной мне причине, огромное количество разработчиков кидает в лог все подряд, не понимая разницы между INFO и DEBUG уровнями.
И чем больше ентерпрайз компания, тем больше всякой ненужной фигни попадает в лог, из которой осознанно используется от силы несколько процентов.
Под каким-то непонятным страхом, боятся что-то не добавить в лог на случай инвестигейшена, даже если его шанс - разовые случаи в год.
В результате огромное количество никому не нужных логов и метрик собирается, архивируется, хранится годами. Для такого количества привлекаются не самые простые способы хранения типа эластика.
И вообще, я думаю что в случае микросервисной архитектуры, примерно 15-20% сервисов используют меньше ресурсов чем весь пакет мониторинга за этими сервисами.
При этом, если пообщаться с адекватными тимлидами, и выделить на это время, логи можно уменьшить в разы, а то и на порядки БЕЗ какого-либо ущерба.
По непонятной мне причине
Так понятные же причины?
- Обычно те, кто добавляет логи, не платят за них (редко когда у каждой команды свой бюджет на логи) — значит не понятно, зачем прикладывать доп. усилия
- Системы состоят из кучи сервисов, как все работает вместе — никто не знает, а если еще и самых подробных логов не будет — не ясно, как чинить инциденты
- Потом, когда случится инцидент, если не будет нужных логов — начальники спросят, почему так плохо было сделано. Выходит, с точки зрения разработчика выгоднее сразу добавлять много логов, на всякий случай.
- Не везде хорошая инфраструктура. Например, было бы здорово уметь в рантайме переключать уровень логов — но если система такое не поддерживает, ну, чтоже, будем логировать опять все, что можем.
- Не везде хороший CI/CD. Если случилась беда на проде, докинуть новые логи может занять не минуты, а часы, благодаря долгим пайплайнам сборок и деплоев.
Надо пользоваться сборщиками логов, а локальные чистить. Тогда и логи под рукой сразу со всех систем и никому они не мешают.
У нас так делает сервер видеонаблюдения, пишет лог пока место на диске не заканчивается. В ответ на жалобу, организация установщик только развела руками и посоветовала удалять почаще.
А еще так делает КриптоПро, он тихо генерирует запись с ошибкой в лог с частотой 3-5 записей в секунду. И обнаружить это можно только по внезапным тормозам диска.
Прочитал - и пошёл добавил в Графане к своим алертам "на диске меньше 10% свободного места" ещё и алерты "на диске такими темпами, как оно идёт в последние сутки, свободное место закончится меньше, чем за 5 дней". А то ведь и правда, если неожиданно начнёт какой-нибудь софт в логи гадить с повышенной скоростью, лучше заранее это увидеть.
Следующий уровень - просто "что-то скорость уменьшения места на диске резко возросла", но производные второго порядка в PromQL мне точно мозг вынесут :)
Хорошо вам, когда за 5 дней можно точно уложиться в расширение хранилища. В крупном бизнесе надо на годы вперёд планировать
Если речь о логах, можно уменьшить интервал ротации. Да, станет сложнее исследовать старые баги, но зато система продолжит работать.
Ну вообще ограничение глубины хранения лога вроде бы сразу должно в голове быть.
Что значит "старые баги"? Трехлетней давности до которых никому дела нет? Ну так ведь не бывает в реальной жизни. Логи постоянно мониторятся, если там что-то произошло - оформляется "дефект промсреды" с вырезкой нужного куска лога в качестве приложения.
Уровни логирования (хотя бы ошибки-предупреждения-отладка) тоже настраиваются - можно в любой момент переключить уровень.
Но все это должно постоянно мониториться дежурной сменой сопровождения.
У нас как минимум на год вперёд планируются место в хранилищах. Сделал новую бд? Оцени нагрузку заранее.
Оценка нагрузки - это вообще святое. У нас при вынесении архитектурного решения на согласование этот пункт (оценка предполагаемой нагрузки) обязателен. Без него согласования не будет и задача дальше не пойдет.
Но здесь "нагрузка" это не только БД, но и вычислительные ресурсы серверов. Которые тоже стоят денег. И сервер не может работать со 100% загрузкой процессора - всегда должен быть запас производительности (это тоже мониторится) т.к. есть периоды пиковых нагрузок, есть периоды умеренной загрузки.
можно уменьшить интервал ротации
Если мы говорим про крупный бизнес, то тоже просто так сделать это нельзя, например есть требование службы безопасности о хранении логов за последние 2-3 месяца, да непросто где-то в архивах, а в Elastic, где они в автоматическом и ручном режимах что-то смотрят/ищут.
И в таких условиях бывают ситуации, что что-то поменялось/обновилось и логов стало не 2гб/сутки, а 20гб/сутки, место на эластике стремительно кончается и становится ооочень весело, т.к. за приемлемое время как расширение мощностей под эластик так и уменьшение времени хранения логов согласовать очень трудно.
Если место внезапно стало заканчиваться, то причину обычно надо не хранить, а устранять.
Речь не про "расширение хранилища", а про то, чтобы успеть на досуге без лишней спешки залезть на этот сервер и понять, что конкретно там происходит, и устранить проблему. Здесь как раз крупному (да даже и любому не совсем крошечному, как у меня) бизнесу проще, у них сисадмины в штате отдельные на полный день сидят, а мне надо от других дел отрываться, которых гораздо больше :)
В крупном бизнесе всегда есть ещё пара десятков других хранилищ, куда можно перелить "остывающие" и "холодные данные"
"Нехватка места" - может означать неконтролируемое расширение БД, когда всё свободное место пожирается за минуты.
У нас были настроены и метрики а алёрты и балансировщики нагрузки, а в итоге получилась смешная и страшная ситуация:
Клиент присылает запрос на огромное количество данных.
Сервер падает с OutOfMemoryException, но пишет дамп на диск. Но увы не успевает записать логи из-за буферизации.
Клиент не получает ответ и отправляет запрос снова, который благодаря load balancer кладёт уже другой сервер.
Сервера по очереди поднимаются и регистрируются на load balancer, но клиент продолжает их класть один за другим. Каждый heap dump сжирает 64 гигабайта на диске.
В итоге выгрузили один из дампов памяти, нашли в нём плохой запрос, нашли клиента, попросили его так не делать - потому что других протоколов на тот момент не было.
Ну и как postmortem
Настроили приложение даже не пытаться обрабатывать запросы которые требуют аномально большого объёма памяти
Настроили параметры JVM чтобы дампы памяти писались в один и тот же файл и переписывали друг друга.
В сервисе что сейчас пишу - логи пишутся на отдельный раздел, и в худшем случае останемся без логов на какое-то время.
Битрикс, из-за сбойной даты в логах - логи не чистились, пишущиеся в БД. Сайт изначального размера в пару гигабайт на момент падения сожрал весь 4тб диск выделенный под него, запись в логи из 5 секунд загрузки страницы занимала около 3.5 секунд. После пары аналогичных случаев - одна из первых диагностик - посмотреть нет ли в БД какой-нибудь раздутой таблицы.
Если кто-нибудь из пользователей Informatica включит Verbose Data логирование в клиенте, то логи могут быть в сотни гигабайт. Так что периодический find -size и truncate (простое удаление занятого файла не освободит диск).
С лукапами та же история - если накосячат с join, то терабайты на диске это легко. Мониторим свободное место и если его мало - удаляем лукапы (кэши), которые не заняты приложением.
Будет некоторая деградация производительности, но не будет падения.
Ну а вообще, не всегда дело в мониторинге т.к не всегда дают массивы того размера, какого хочется :)
Не совсем про переполнение диска, но тоже в копилку знаний. На своём первом SSD я, начитавшись ужасов про вытирание флеша, установил профайлер записи. Через несколько дней обнаружилось, что из нескольких гигабайт в сутки что-то около 2 Гб записи приходилось на один единственный файл в каталоге uTorrent "resume.dat", размер которого всего несколько сотен Кбайт. Подозреваю, что после каждой одиночной записи этот файл либо закрывается, либо сбрасывает буфер на диск. С тех пор взял за правило запускать uTorrent исключительно с HDD.
PS: к слову диск был Intel X25-M 120 Gb, MLC 25 nm с тремя тысячами гарантированных циклов записи. Эх были времена... До сих пор жив с неубиваемым ресурсом. Со временем также купил в коллекцию легендарный X25-E.
Сегодняшние ssd контроллеры умеют обрабатывать такие ситуации. Когда один и тот же файл многократно перезаписывается, он записывается все время в разное место по физическому адресу.
Вы меня неправильно поняли. Контроллер в Intel X25M мало отличается от современных (ну разве что не было сборщика мусора) и тоже распределяет запись блоков с учётом истирания ячеек. О том и речь, что небольшой файл может сожрать 2 Гб ресурса диска за день, и это без учёта write amplification. А если это современный TLC/QLC/3D и прочие китайские noname, у которых минимальный overprovisioning или вообще не предусмотрен... Сегодня развитие SSD приняло экстенсивный путь развития, низкое качество ячеек с живучестью в 150-200 перезаписей компенсируется объёмом диска. Я лишь предупреждаю владельцев условного китайского нонейма, что существуют программы-пожиратели SSD, о которых пользователь даже не задумывается. Когда я начинал мониторить запись SSD я был готов к чему угодно - Windows пишет в своп, в логи, прочий софт... А в итоге лидером с большим отрывом оказался всего один лог uTorrent.
FYI: uTorrent хранит в "resume.dat" список торрентов и данные по ним (статистику, подключенных пиров и т.п.). Файл периодически перезаписывается. В uTorrent 3.0+ можно настроить интервал сохранения "resume.dat" -- опцией bt.save_resume_rate.
Любая нештатная ситуация сначала возникает первый раз. Например, скорость мониторинга могла не успеть за метрикой или создание такой ситуации самой системой мониторинга. Но больше вероятность человеческого фактора, в том числе из лучших побуждений, например при невозможности воспроизвести ошибку на тесте приходиться рисковать на бою - сам так делал :)
Тойота раз за разом пробивает: https://habr.com/ru/companies/pvs-studio/articles/310862/
Видимо, это бич всех автопроизводителей. Вспомним, как Фольксваген не смог выпустить в срок электромобиль из-за проблем с софтом.
Никто не застрахован. У нас тоже космические аппараты ломаются.
Но никто не ставит наш Роскосмос как пример, на который надо молиться. А тайоту - из любого утюга в пример приводят
Ротация логов. По-хорошему, у каждого лог файла в проде есть максимальный объем после которого старые записи начинают подчищаться (если это происходит чаще, чем хотелось бы, можно настроить алерт, по которому обдумывается повышение лимита размера за счёт увеличения диска).
Меня ещё на десктопном линуксе волновал вопрос, не могут ли логи забить весь диск, поэтому исследовал вопрос.
Частая ситуация, когда "в ходе удаления и систематизации данных" дисковое пространство, занимаемое БД, растёт. И чем больше данных вы якобы "удаляете", тем больше места будет занято. То есть, если у вас диск занят на 70%, и вы "удаляете" половину данных, то одномоментно можете получить прирост на 50% от занятого, то есть диск в итоге будет переполнен. И это можно сделать всего одним, на вид безобидным, запросом SQL.
Про мониторинг все конечно верно, но тут явно не этот случай, когда "проворонили, что место кончилось". Очевидно, что инцидент связан именно с оптимизацией данных.
The system was restored after the data was transferred to a server with a larger capacity on August 29
Они наверно очень консервативны в плане техники, некоторые до сих пор одежду на Z80 шьют.
Hidden text
Я наивно полагал, что у таких гигантов, как Тойота, проблем с местом на СХД не должно быть даже в теории
Реорг в Оракле?
Тот случай, когда люди, настроившие один раз в жизни базу 1С, дают оценку специалистов, обслуживающих базу данных Toyota.
Для начала надо понимать, что такое «база данных Тойоты»: это сотни тысяч поставщиков по всему миру, миллионы номенклатур и партий, а также учет всех аспектов производственного процесса (чтобы всегда можно было ответить на вопрос, какой рабочий, в какое время и от какого поставщика закрутил гайку вот на этот автомобиль, как эта гайка попала на завод, каким маршрутом ехала и перемещалась по заводу и где все это время лежала). Прослеживаемость производственного процесса в Тойоте на самом высоком уровне, если не на самом высочайшем – это основа менеджмента качества. Естественно с этой базой работает не 10-20, а десятки тысяч человек одновременно.
Опустим аспекты технической реализации этой базы, которое, скорее всего, выходит далеко за рамки привычного вами «файла базы и лога транзакций» - обслуживают эту базу куда более компетентные ребята, чем мы с вами, иначе бы она просто не справлялась со своей нагрузкой.
Давайте представим, что мы потеряем данные из этой базы всего на 1 рабочую минуту. Чем это грозит? А тем, что придется остановить производство и проводить полную переинвентаризацию всех складов и всех производственных процессов, а иначе весь учет полетит в тар-тарары и ни о каком Дао Тойоты можно будет не говорить. Займет такая работа в рамках такого концерна далеко не пару дней.
Дак вот, у ребят случилась ошибка в базе, из-за которой база непрерывно росла. Скорее всего, разобраться с ошибкой на лету, а уж тем более обрезать базу просто так у них не было возможности. Поэтому да, они приняли непростое решение остановить все, чтобы запуститься через пару дней. Решение они приняли в целом в духе Тойоты – для них нормально остановить производство, чтобы разобраться в допущенной в рамках него ошибке.
Вы можете сколько угодно писать про бекапы и мониторинги, но если в базе возникла ошибка, ведущая к ее непомерному росту, то пока вы не выявите причину этой ошибки, все эти действия не имеют значения.
Вспоминается, что именно у Toyota несколько лет назад было множество исков по поводу качества лапше-кода и даже смертельные исходы (https://www.edn.com/toyotas-killer-firmware-bad-design-and-its-consequences/, https://devm.io/programming/the-dangers-of-spaghetti-code-117807).
То ли это такая дикая экономия из-за кризисов и пандемий, то ли кто-то не делает выводов в ИТ-инфраструктуре...
Переполнение дискового пространства стало причиной остановки всех заводов Toyota в Японии