Моей первой мыслью было бы создавать объекты каждый раз, когда мой анализатор встречал шаблон запуска с новым ключом.Я предполагаю, из вашего примера, что 1234 - это ключ, такой, что все строки журнала, которые должны быть связаны друг с другом, могут быть сопоставлены с состоянием одной «вещи» (объекта).
Итак, вы видите шаблон дляначинайте отслеживать один из них, и каждый раз, когда вы видите запись в журнале, которая относится к ней, вы вызываете методы для типа события (изменение состояния), которое представляют эти последующие строки.
Из вашего примера эти объекты "состояния журнала"(из-за отсутствия более подходящего термина) может содержать список или словарь (или другой контейнер) для каждого ServiceCall (который, как я ожидаю, будет другим классом объектов).
Таким образом, общий дизайн был бы парсером / диспетчером, который читает журнал, если элемент журнала относится к какому-либо существующему объекту (ключу), то элемент отправляется объекту, который затем может создать свой собственный (ServiceCall)или другие) объекты и / или события отправки для этих объектов или создания исключений или вызова обратных вызовов или вызовов других функций по мере необходимости.
Предположительно, вам также понадобится некоторый обработчик коллекции или окончательного расположения, который может быть вызванваши объекты журнала, когда события Stop отправляются им.
Полагаю, вы также захотите поддержать какой-либо метод сообщения о состоянии или состоянии, чтобы приложение могло перечислять все живые (не собранные) объекты в ответ на сигналы или команды в каком-либо другом канале (возможно, изнеблокирующая проверка, выполняемая анализатором / диспетчером)