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

У меня есть экземпляр EC2 с потоком данных, который использует генератор событий для обработки данных. Например.

stream.on('new event', function doSomething(event){ do more stuff...})

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

Следовательно, я решил, что буду отправлять журналы пакетно. Например.

let logArray = [];
function sendToLogs(logs) {\** send stuff *\}

stream.on('new event', function doSomething(event){ 
  \\do some stuff

  logArray.push({newLog: event})
  if (logArray.length >= 500) {
     sendToLogs(logArray)
     logArray = [];
  }
})

Однако я боюсь, что с таким количеством событий, происходящих одновременно, приведенный выше код может привести к ошибочному поведению. Я видел это в локальном журналировании: длина этого массива довольно сильно прыгает и может иметь одно и то же значение для разных событий одновременно.

Кроме того, использование журналов cloudwatch требует от меня передачи «sequenceTokens» между различными вызовами функции ведения журнала. Если два события вызывают условие регистрации одновременно, все может стать странным. (Эта проблема существовала бы, даже если бы я регистрировал каждое событие отдельно.)

Как я должен вести журнал для этого типа потока данных?


person Logister    schedule 08.01.2017    source источник


Ответы (1)


Я бы выделил ведение журнала в один или несколько отдельных процессов. Ваше основное приложение будет помещать сообщения журнала в очередь SQS, используя логику типа "запустил и забыл". Затем ваше приложение ведения журнала будет читать очередь и записывать в журнал по вашему выбору. Преимущество состоит в том, что всплески активности будут поглощаться очередью. Нет прямых ограничений на длину очереди, поэтому она должна быть в состоянии обрабатываться. По сути, вы больше не ставите сообщения в очередь, а SQS.

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

Недостатки:

  1. Вам нужно написать этот отдельный процесс для обработки журналов в CloudWatch или где-либо еще.
  2. Ваши журналы не будут в реальном времени. Будет по крайней мере некоторая задержка между тем, когда ваше основное приложение регистрируется, и когда сообщение журнала помещается в CloudWatch. С дополнительными процессами регистрации вы должны быть близки, но это не гарантия.
person stdunbar    schedule 08.01.2017
comment
SQS определенно может работать. Лямбда-функции были бы еще одним вариантом, если требуется поведение, более близкое к реальному времени. Если процесс «выстрелил и забыл» просто делегирует лямбду, вы получите шаблон разветвления, в котором лямбда будет динамически масштабироваться до количества необходимых процессов ведения журнала. - person Dave Maple; 09.01.2017