csp-log-tutorial

Pré-requisitos

Confira se o git está instalado.

Criei uma pasta git dentro do diretório mgr do IRIS. Cliquei com o botão direito do mouse na pasta git e escolhi Git Bash Here no menu de contexto.

git clone https://github.com/oliverwilms/csp-log-tutorial.git

Clone meu repositório do GitHub csp-log-tutorial se quiser testar você mesmo.

Vou descrever neste tutorial como tento usar arquivos access.log e CSP.log em pods webgateway para monitorar solicitações e respostas.

Minha equipe trabalha com contêineres IRIS executados na Red Hat OpenShift Container Platform (Kubernetes) da AWS. Implantamos três pods webgateway que recebem solicitações por um Balanceador de Carga de Rede. As solicitações são processadas em uma produção da InterOperability que é executada em três pods de computação. Usamos a produção do Message Bank que é executada em pods de dados espelhados como um local para analisar todas as mensagens processadas por qualquer pod de computação.

Testamos nossas interfaces usando pods alimentadores para enviar várias mensagens de solicitação ao Balanceador de Carga de Rede. Enviamos 100 mil mensagens e testamos quanto tempo leva para processar todas elas no Message Bank e gravar as respostas nos alimentadores. O número de mensagens depositadas no Message Bank e respostas recebidas pelos alimentadores corresponderam ao número de mensagens de entrada.

Recentemente, recebemos a solicitação para testar os failovers dos pods e da zona de disponibilidade (AZ). Excluímos os pods individuais à força ou não e com ou sem período de carência. Simulamos a falha da zona de disponibilidade ao negar todo o tráfego recebido e enviado a uma subrede (uma das três zonas de disponibilidade) pelo console da AWS enquanto os alimentadores enviam várias mensagens de solicitação ao Balanceador de Carga de Rede. É bastante desafiador contabilizar todas as mensagens enviadas pelos alimentadores.

Outro dia, quando um alimentador enviou 5 mil mensagens, simulamos a falha da AZ. O alimentador recebeu 4933 respostas. O Message Bank estava com 4937 mensagens.

Armazenamos access.log e CSP.log no diretório de dados dos pods webgateway. Adicionamos esta linha ao Dockerfile da nossa imagem webgateway:

RUN sed -i 's|APACHE_LOG_DIR=/var/log/apache2|APACHE_LOG_DIR=/irissys/data/webgateway|g' /etc/apache2/envvars

Definimos o Nível do Log de Eventos no Web Gateway como Ev9r.

Criei os subdiretórios data0, data1 e data2 para nossos três pods webgateway. Copiei os arquivos CSP.log e access.log dos nossos três pods webgateway armazenados em volumes persistentes:

oc cp iris-webgateway-0:/irissys/data/webgateway/access.log data0/access.log
oc cp iris-webgateway-1:/irissys/data/webgateway/access.log data1/access.log
oc cp iris-webgateway-2:/irissys/data/webgateway/access.log data2/access.log
oc cp iris-webgateway-0:/irissys/data/webgateway/CSP.log data0/CSP.log
oc cp iris-webgateway-1:/irissys/data/webgateway/CSP.log data1/CSP.log
oc cp iris-webgateway-2:/irissys/data/webgateway/CSP.log data2/CSP.log

Acabei com três subdiretórios, cada um com arquivos access.log e CSP.log.

Contamos o número de solicitações processadas em qualquer pod webgateway usando este comando:

cat access.log | grep InComingOTW | wc -l

Contamos o número de solicitações e respostas registradas em CSP.log usando este comando:

cat CSP.log | grep InComingOTW | wc -l

Geralmente, esperamos o dobro de linhas no CSP.log em comparação com o access.log. Às vezes, encontramos mais linhas em CSP.log do que o dobro esperado do número de linhas em access.log. Lembro de ver menos linhas do que o esperado em CSP.log em comparação com o que estava em access.log pelo menos uma vez. Suspeitamos que isso tenha ocorrido devido às 500 respostas registradas em access.log, que não foram registradas em CSP.log de maneira adequada, porque o pod webgateway foi encerrado.

Como analisar várias linhas de solicitações e explicar o que aconteceu?

Criei as classes persistentes otw.wgw.apache e otw.wgw.csp para importar linhas de access.log e CSP.log. access.log contém uma linha por solicitação, incluindo o status da resposta. CSP.log contém linhas separadas para solicitações e respostas.

Abra o terminal do IRIS e importe as classes no diretório src do repositório csp-log-tutorial que clonamos antes:

Set src="C:\InterSystems\IRISHealth\mgr\git\csp-log-tutorial\src"
Do $system.OBJ.LoadDir(src,"ck",,1)

Se você não tiver seu próprio arquivo CSP.log para analisar, é possível importar o arquivo do repositório csp-log-tutorial:

Set pFile="C:\InterSystems\IRISHealth\mgr\git\csp-log-tutorial\wg2_20230314_CSP.log"
Do ##class(otw.wgw.csp).ImportMessages(pFile,.pLines,.pFilter,1)

pLines e pFilter são parâmetros de saída que não são tão importantes no momento. pImport controla se Extent é excluído antes de importar os dados.

Depois de importar os dados, podemos executar consultas SQL como esta:

SELECT count(*) FROM otw_wgw.csp where wgEvent='WebGateway.ProcessRequest'

Se o número retornado for ímpar, isso indica que há uma divergência entre as solicitações e as respostas.

Podemos executar a próxima consultar para identificar os nomes de arquivos nas solicitações que não têm uma resposta correspondente:

select zFilename, count(*) from otw_wgw.csp group by zFilename having count(*) = 1

Observe que eu usei o método CalcFilename para definir a propriedade zFilename antes de salvar uma linha importada do arquivo CSP.log.

Também incluí um arquivo access.log de amostra, que podemos importar assim:
Se você não tiver seu próprio arquivo CSP.log para analisar, é possível importar o arquivo do repositório csp-log-tutorial:

Set pFile="C:\InterSystems\IRISHealth\mgr\git\csp-log-tutorial\wg2_20230314_access.log"
Do ##class(otw.wgw.apache).ImportMessages(pFile,.pLines,.pFilter,1)

Podemos executar esta consulta para obter o número de mensagens relacionadas a esse tutorial:

SELECT count(*) FROM otw_wgw.apache where Text like '%tutorial%'

O que mais quero fazer se tiver tempo?

Gostaria de combinar os dados das tabelas apache e csp e possivelmente incluir os dados reunidos dos pods de computação.

Acho que posso usar os dados em access.log para determinar quando houve uma interrupção em um pod webgateway.