Шесть дорогостоящих ловушек в сборе журналов: от местных ошибок управления до надвигающихся системных сбоев
15 августа 2025 г.Фон
При мониторинге статуса работы системы и устранения комплексных проблем с устранением неполадок журналы давно служили незаменимым методом наблюдения. Научные стратегии управления местным журналом не только сохраняют более полные исторические записи на местном уровне и минимизируют накладные расходы на производительность, но и облегчают сбор журналов и последующий анализ. Однако в реальном O & M мы часто сталкиваемся с контрпримерами. Проблемы сбора, вызванные такими дефектами управления, не могут быть идеально решены с помощью основных инструментов сбора, таких как LoingCollector (ранее ilogtail), FileBeat, Fluentbit, Vector и Collector Collector. Лучшая практика - решить основную причину. Здесь мы суммируем наш опыт, надеясь дать некоторое вдохновение и коллективно улучшить утилиту для всех.
1. Использование режима усечения копирования для вращения журнала может привести к потере журнала или дубликату из-за неатомных операций и создания новых файлов.
Принцип использования режима усечения копирования Logrotate для вращения журналов состоит в том, чтобы сначала скопировать исходный файл журнала, а затем усечь его. Этот метод поднимает следующие проблемы:
- Новые файлы, сгенерированные операцией копирования, могут быть неоднократно собираться в качестве нового контента. Из -за изменений INODE в файловой системе коллекционер может не идентифицировать это как вращающийся старый файл.
- Журналы, сгенерированные между операциями копирования и усечения, могут быть потеряны. Существует временное окно между этими двумя операциями, в течение которых написанное содержимое не существует ни в скопированном файле, ни в исходном файле (так как оно будет очищено операцией усечения).
- Операция усечения может уменьшить размер файла и изменить содержание заголовка. Сокращение файла или изменение подписи заголовка заставит коллекционера неправильно объект его в качестве нового файла, что приведет к дублирующей коллекции.
Следовательно, режим усечения копирования может привести к таким проблемам, как дубликат сбора журналов, потеря контента или несоответствие.
Рекомендуется использовать режим создания для вращения журнала, то есть для создания нового файла и переименования старого файла, который обеспечивает целостность и непрерывность файла. Если неизбежно используйте точное имя пути при настройке настроек сбора.
2. Использование NAS или OSS для хранения журналов может привести к усечению или прекращению сбора журналов из -за непоследовательных метаданных и плохой производительности списка файлов.
Сетевое хранилище (NAS) обычно использует возможную модель согласованности, которая является общим дизайном в распределенных системах. В сценариях сбора в режиме реального времени это может вызвать следующие проблемы:
- Несоответствие между метаданными объектами и фактическим содержанием. Из -за возможной согласованности метаданные, такие как размер файла, могут быть обновлены до фактического контента.
- Читать операции возвращают отверстия для файлов. Если метаданные показывают, что файл вырос, но фактический контент не был синхронизирован, операция чтения может вернуть 0 символов (отверстия файла).
- Задержка данных. Результаты операций записи могут быть не сразу видны для чтения операций, что приводит к задержке сбора.
- Потеря данных. NAS не поддерживает INOTIF, а объекты перечислены на низкой скорости, поэтому файлы не могут быть обнаружены, что приводит к потере данных.
Эти проблемы могут привести к тому, что собранные данные не соответствуют конечному содержанию.
Рекомендуется использовать EBS и использовать локальные диски для локальных серверов, чтобы обеспечить эффективность и согласованность чтения и письма. В случае неизбежного, реализуйте логику совместимости для журналов исключений на потребителе.
3. Multi-Process Writing Log может привести к неполному сбору данных из-за перезаписи взаимных данных.
Это обычная, но не рекомендуемая практика для нескольких процессов для записи в один и тот же файл журнала одновременно, что может привести к следующим проблемам:
- Чередовое содержимое файла. Запись по нескольким процессам может пересекаться друг с другом, вызывая расстройство в записях журнала.
- Неполная коллекция. Когда в файле происходит событие записи, коллекционер начинает собирать данные. Однако, если другие процессы продолжают писать данные в процессе сбора, это недавно написанное содержимое может быть пропущено.
- Файл блокировки. Multi-Process Writes может привести к конкурсу блокировки файлов, что влияет на производительность и надежность записи.
Этот шаблон может привести к неполному сбору данных, которые отклоняются от окончательного содержимого файла.
Рекомендуется, чтобы несколько процессов записывали свои соответствующие файлы, чтобы обеспечить целостность и порядка журнала. В случае неизбежного, реализуйте логику совместимости для журналов исключений на потребителе.
4. Создание отверстий файлов для выпуска места в файле журнала может привести к тому, что дубликат сбора журналов или потеря данных из -за изменений в подписи и контенте файла.
Выпустить пространство файла журнала путем создания отверстий в заголовке файла является рискованной практикой по следующим причинам:
- Измененная подпись файла. LoingCollector (ранее ilogtail) дополнительно использует содержание заголовка файла в качестве основы для определения уникальности файла, чтобы предотвратить пропущенную коллекцию из -за повторного использования INODE. Создание отверстий может изменить эту подпись, заставляя коллекционера неправильно оценить их как новый файл.
- Проблемы целостности данных. Создание отверстий по существу заменяет исходный контент на 0 символов, что может привести к потере важных исторических журналов.
- Фрагментация файловой системы. Частое создание отверстий может привести к фрагментации файловой системы, ухудшению производительности чтения и записи.
Эта практика может привести к дублированию сбора данных и потери исторических данных.
Рекомендуется использовать стандартный механизм вращения журнала для управления размером файла журнала, например, использование инструмента Logrotate для регулярного вращения журнала, что обеспечивает целостность и прослеживаемость журнала. В случае неизбежного, мы рекомендуем вам использовать Fallocate вместо усечения или DD, а также реализовать логику совместимости для журналов исключений для потребителя.
5. Частое перезапись файлов может привести к неполным или непоследовательным собранным данным из -за постоянно изменяющегося содержимого файла.
Часто перезаписывать весь файл журнала является небезопасным методом управления журналами. Это может вызвать следующие проблемы:
- Непоследовательные метаданные и содержание. В процессе перезаписи метаданные, такие как размер файла, могут быть обновлены до фактического контента. В результате коллекционер читает неполный или непоследовательный контент.
- Риск потери данных. Если во время сбора журнала происходят операции по перезаписи, собранные данные могут быть беспорядочными или потерянными.
- Сложность сохранения исторических данных. Частое перезапись вызывает неспособность сохранить исторические журналы, что не способствует выпуска трассировки и анализа. Эта практика может привести к несоответствию между собранным контентом и конечным содержанием файла или полной потере содержимого файла.
Рекомендуется записывать журналы в режиме приложения и использовать механизм вращения журнала для управления размером файла. В случае неизбежного, реализуйте логику совместимости для журналов исключений на потребителе.
6. Сохранение файлов, отредактированных с помощью VIM, может вызвать дубликат коллекции журналов из -за создания новых файлов для замены исходных.
Когда вы используете VIM для редактирования и сохранения файла, его механизм сохранения может вызвать следующие проблемы:
- Изменение INODE. Когда VIM создает новый файл для замены исходного, новый файл имеет другой INODE из оригинала, что может привести к тому, что коллекционер неправильно оценивает его как новый файл.
- Измененная подпись файла. Содержание заголовка нового файла может отличаться от содержимого исходного файла, который изменяет подпись файла. В результате коллекционер не может правильно идентифицировать файл.
- Потеря содержимого файла. Когда VIM заменяет файл, программа записи не может переключаться на недавно сохраненный файл журнала, что может привести к потере содержимого журнала.
Этот режим редактирования может привести к дублированию сбора журналов или потери данных.
Если вам нужно только просматривать журналы, мы рекомендуем вам использовать инструменты только для чтения, такие как меньше и Grep. В случае неизбежного, реализуйте логику дедупликации и обработки исключений для потребителя.
Краткое содержание
Журнал - это «черный ящик» системных операций, и его качество управления напрямую влияет на эффективность устранения неполадок и надежность системы. Избегая анти-паттернов, упомянутых в этой статье, и следования передовым методам, таким как использование вращения логического магазина, локальное написание дисков и однопоточное добавление, вы можете значительно снизить риски сбора лога и улучшить наблюдаемость. Есть надежда, что эта статья может дать практические ссылки для команд по созданию надежной и эффективной системы управления журналами.
Оригинал