Então, se você está acompanhando do post anterior ou entrando agora, vamos passar para o mundo dos aplicativos eBPF e dar uma olhada no Parca, que se baseia em nossa breve investigação de gargalos de desempenho usando eBPF, mas coloca um aplicativo incrível no topo do seu cluster para monitorar todas as suas cargas de trabalho iris, continuamente, em todo o cluster!

Perfilamento Contínuo com Parca, Cargas de Trabalho IRIS em Todo o Cluster

Parca

Parca é nomeado pelo Programa para Avaliação Regional do Clima Ártico (PARCA) e a prática de perfilamento de núcleos de gelo que tem sido feita como parte dele para estudar a mudança climática. Este projeto eBPF de código aberto visa reduzir algumas emissões de carbono produzidas pelo uso desnecessário de recursos de data centers, podemos usá-lo para obter "mais por menos" com consumo de recursos e otimizar nossas cargas de trabalho nativas da nuvem executando IRIS.

Parca é um projeto de perfilamento contínuo. Perfilamento contínuo é o ato de selecionar perfis (como CPU, memória, E/S e muito mais) de programas de forma sistemática. A Parca coleta, armazena e torna os perfis disponíveis para serem consultados ao longo do tempo e, devido à sua baixa sobrecarga usando eBPF, pode fazer isso sem prejudicar as cargas de trabalho alvo.

Onde

Se você achou que monitorar um kernel que executa vários namespaces de kernel Linux era legal no último post, Parca consegue reunir tudo isso em um só lugar, com um único painel de vidro em todos os nós (kernels) em um cluster.

Parca tem dois componentes principais:

• Parca: O servidor que armazena dados e permite que sejam consultados e analisados ao longo do tempo
• Parca Agent: Um perfilamento sistema completo baseado em eBPF que roda nos nós.

Para pular direto no "Parca aplicado", eu configurei Parca no meu cluster com o seguinte:
 

 kubectl create namespace parca
 kubectl apply -f https://github.com/parca-dev/parca/releases/download/v0.21.0/kubernetes-manifest.yaml
 kubectl apply -f https://github.com/parca-dev/parca-agent/releases/download/v0.31.1/kubernetes-manifest.yaml

Resulta em um daemonset, executando o agente em todos os 10 nós, com cerca de 3-4 cargas de trabalho iris espalhadas pelo cluster.

Observação: Parca também funciona de forma autônoma, não é necessário k8s reqd!

Vamos Perfilar

Agora, sei que tenho algumas cargas de trabalho neste cluster de interesse, uma delas é uma carga de trabalho fhir que está atendendo a um GET no endpoint /metadata para 3 pods em um intervalo para amigos que estou tentando impressionar em uma festa eBPF, a outra é uma carga de trabalho 2024.2 pura executando o seguinte como um JOB:

Class EBPF.ParcaIRISPythonProfiling Extends %RegisteredObject
{

/// Do ##class(EBPF.ParcaIRISPythonProfiling).Run()
ClassMethod Run()
{
    While 1 {
            HANG 10
            Do ..TerribleCode()
            Do ..WorserCode()
            Do ..OkCode()
            zn "%SYS"
            do ##class(%SYS.System).WriteToConsoleLog("Parca Demo Fired")
            zn "PARCA"
    }
}

ClassMethod TerribleCode() [ Language = python ]
{

    import time
    def terrible_code():
        time.sleep(30)
        print("TerribleCode Fired...")
    terrible_code()
}

ClassMethod WorserCode() [ Language = python ]
{
    import time
    def worser_code():
        time.sleep(60)
        print("WorserCode Fired...")
    worser_code()
}

ClassMethod OkCode() [ Language = python ]
{

    import time
    def ok_code():
        time.sleep(1)
        print("OkCode Fired....")
    ok_code()
}

}

Agora, eu coloquei um serviço metallb no serviço parca e mergulhei direto no console, vamos dar uma olhada no que podemos observar nas duas cargas de trabalho.

Execução Python

Então eu não consegui o que eu queria dos resultados aqui, mas eu consegui algumas dicas sobre como o IRIS está fazendo toda a integração python.

No Parca, eu restringi ao pod particular, somei ele pela mesma coisa e selecionei um intervalo sensato:

E aqui foi o perfil resultante:

Consigo ver o irisdb executando o Python, rastreios com o ISCAgent e, à direita, basicamente coisas de inicialização do IRIS dentro do container. Para ser honesto, esperava ver os métodos Python, então preciso investigar mais a fundo. Porém, aprendi que o pythoninit.so é a estrela do show quando se trata de chamadas Python.

FHIR Thinger

Agora este aqui mostra alguns rastreios de uma perspectiva de kernel relevante para uma carga de trabalho FHIR. À esquerda, você pode ver as threads apache para o servidor web levantando a api, e você também pode ver nos rastreios irisdb o desempacotamento de JSON.

Tudo gerado a partir de uma thread por uma festa conhecida como zu210fun!

Agora, vamos dar uma olhada na mesma carga de trabalho no Grafana, enquanto o Parca exporta para observabilidade:

Não é revolucionário, eu sei, mas o objetivo é o perfil distribuído de um aplicativo IRIS com um eBPF, de forma leve, em todo um cluster... com o único objetivo de nunca mais ter que pedir a um cliente um relatório pButtons!