Как вы решали вопрос чтения больших логов при написании скрипта для их парсинга?

При работе с логами размером в десятки гигабайт стандартные методы чтения файлов не работают. Вот мой подход, основанный на использовании потокового чтения и утилит командной строки:

1. Потоковое чтение и обработка (Bash/Python): Основной принцип — никогда не загружать весь файл в память.

• Использование tail, grep, awk в пайплайнах:

  # Чтение и фильтрация логов в реальном времени
  tail -F /var/log/app/application.log | grep --line-buffered "ERROR" | awk '{print $1, $5}' > errors.txt

  Ключ -F отслеживает ротацию файла, а --line-buffered в grep обеспечивает немедленный вывод.

• Обработка по частям (чанками) в Python:

  import sys
  BUFFER_SIZE = 65536  # 64KB чанк
  
  def process_log_file(file_path):
      with open(file_path, 'r') as f:
          while True:
              lines = f.readlines(BUFFER_SIZE)
              if not lines:
                  break
              for line in lines:
                  if 'CRITICAL' in line:
                      # Логика обработки строки
                      sys.stdout.write(line)

2. Работа с ротированными и сжатыми логами: Часто логи архивируются (.gz, .bz2). Для их обработки без распаковки целиком:

# Прямой поиск по сжатым архивам
zcat /var/log/nginx/access.log.*.gz | awk '$9 == 500 {print $7}' | sort | uniq -c | sort -rn | head -20

3. Для экстремально больших или распределенных логов: Если один файл превышает сотни ГБ или логи разбросаны по кластеру, я применяю более тяжелые инструменты:

• ELK Stack (Elasticsearch, Logstash, Kibana): Logstash для приема и парсинга, Elasticsearch для индексации и хранения.
• Потоковая обработка: Использование Fluentd или Vector для сбора, трансформации и маршрутизации логов в реальном времени в хранилища типа S3 или BigQuery для последующего анализа через SQL или Spark.