No momento vou apenas jogaar questões pertinentes ao que eu chamo de sanitização do arquivo de entrada.
1 - Existem quebras de linha que suponho que foram geradas acidentalmente ao enviar ao fórum, por se tratarem de linhas muito longas, então vou desconsidera-las. Mas se não for isso me corrija depois, porque vejo algumas tags iniciarem em uma linha e fecharem na seguinte.
2 - Existem espaços que são inesperados ao meu ver, que não sei se é gerado realmente no seu log, ou se foi no processo de cópia ao fórum, similarmente como acontece no item anterior sobre quebra de linha. Nesse caso vou supor que é no seu log, o que deixa certos problemas para um arquivo XML válido.
Os espaços na tag de abertura e fechamento e o nome da tag não deveria existir O espaço do nome da tag caracterizada torna como um arqumento: "</ns2: nomeSolicitante>" é bem diferente de "</ns2:nomeSolicitante>" como está no exemplo acima. Além de existirem url quebradas por terem espaços inseridos no seu meio.
3 - As linhas de "XML ENVIADO" e "XML RETORNO" tem um comportamente diferente em relação a marcação baseado por data. "ENVIADO" está na linha seguinte e "RETORNO" está na mesma linha separado pela string "->". Isso confere?
4 - Após a linha "XML RETORNO" existem a seguinte linha: [04/17/17 10:00:15.344]:arq_GENERIC ST:%13Cxsl:message -> ##Debug:Retorno: 0 Essa linha, descontando o espaço indesejado antes do 0 (zero), não pode servir como uma âncora de fechamento e sucesso do processo? Suponho que o 0, seja sucesso e qualquer outro valor indicaria um erro, assim como os códigos de retorno do Shell. Ou essa confirmação apenas dever ser feita na tag "<code>" do "XML RETORNO"?
5 - O id do usuário suponho que seja a tag "<loginUsuario>", no exemplo seria "<loginUsuario>AM1235</ loginUsuario>", esse seria o local a filtrar por usuário, ou talvez pelo nome da pessoa, como no exemplo: "<nomeCompleto> MARTA BERNARDO</nomeCompleto>"? Ou seriam ambos?
As questões que levantei confesso que tem pouco a ver com o Shell em si, mas são válido para uma preparação do que se deseja em detalhe e se execute. Até mesmo considerar se o Shell para seu caso é o mais apropriado. Se tiver acesso ao gerador do log isso poderia ser feito como um subproduto dele ou usar opções como Python, PHP e Perl, etc podem ser mais efetivas dependendo do ambiente em que opera.
A saída que deseja é factível em Shell, mas há incosistências na solução que apresentou, por exemplo: - o código em awk me parece inócuo, e olha que eu gosto muito de awk. - o uso do grep poderia ser desnecessário se fizer um sed anterior só um pouco mais elaborado, ou usar o grep sem a necessidade do sed, de toda forma reduziria um pipe. - o sort eu recomento que seja com uso do argumento -n, para ordenação numérica, mas realmente é necessário? Normalmente logs são sequenciais o que torna o sort um processo inútil. O uniq vem na esteira desse raciocínio, pois suponho que sempre haverá registros únicos, especialmente se tiverem origem de um banco de dados relacional.
São questões que acho relevantes antes de qualquer coisa ser feita.