Entonces, si estáis siguiendo desde la publicación anterior o si os incorporáis ahora, pasemos al mundo de las aplicaciones eBPF y echemos un vistazo a Parca. Este se basa en nuestra breve investigación sobre cuellos de botella en el rendimiento utilizando eBPF, pero añade una aplicación revolucionaria sobre vuestro clúster para monitorizar todas vuestras cargas de trabajo de IRIS de forma continua, ¡a nivel de todo el clúster!

Perfilado continuo con Parca, cargas de trabajo IRIS en todo el clúster

Parca

Parca toma su nombre del Programa para la Evaluación del Clima Regional Ártico (PARCA en inglés) y de la práctica del perfilado de núcleos de hielo que se ha realizado como parte de este para estudiar el cambio climático. Este proyecto de eBPF de código abierto tiene como objetivo reducir algunas emisiones de carbono producidas por el uso innecesario de recursos en los centros de datos. Podemos utilizarlo para obtener "más con menos" en cuanto al consumo de recursos y optimizar nuestras cargas de trabajo en la nube nativa que ejecutan IRIS.

Parca es un proyecto de perfilado continuo. El perfilado continuo es el acto de tomar perfiles (como CPU, memoria, I/O y más) de programas de manera sistemática. Parca recopila, almacena y pone los perfiles a disposición para ser consultados con el tiempo. Gracias a su bajo impacto, al utilizar eBPF, puede hacerlo sin afectar negativamente a vuestras cargas de trabajo objetivo.

Donde

Si pensabais que monitorizar un kernel que ejecuta múltiples namespaces del kernel de Linux era increíble en la última publicación, Parca consigue reunir todo eso en un solo lugar, con una **vista unificada** para todos los nodos (kernels) de un clúster.

Los dos componentes principales de Parca:

• Parca: El servidor que almacena los datos de perfilado y permite consultarlos y analizarlos a lo largo del tiempo.
• Parca Agent: Un perfilador de todo el sistema basado en eBPF que se ejecuta en los nodos.

Para entrar directamente en "Parca en acción", he configurado Parca en mi clúster con lo siguiente:

 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

El resultado es un **DaemonSet**, ejecutando el agente en los 10 nodos, con alrededor de 3-4 cargas de trabajo de IRIS distribuidas por todo el clúster.

Nota: ¡Parca también puede ejecutarse de forma independiente, no se requiere Kubernetes!

Perfiles

Ahora, sé que tengo un par de cargas de trabajo interesantes en este clúster. Una de ellas es una carga de trabajo FHIR que está atendiendo una solicitud GET en el endpoint /metadata para 3 pods en intervalos, para unos amigos a los que intento impresionar en una fiesta de eBPF. La otra es un pod 2024.2 que está ejecutando lo siguiente como un 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()
}

}

Ahora, he activado un servicio MetalLB en el servicio Parca y me he sumergido directamente en la consola. Echemos un vistazo a lo que podemos observar en las dos cargas de trabajo.

Ejecución Phyton

Así que no obtuve lo que quería de los resultados aquí, pero sí obtuve algunas pistas sobre cómo IRIS está manejando toda la integración con Python.

En Parca, restringí el análisis al pod en particular, lo sumé por el mismo criterio y seleccioné un período de tiempo razonable:

Y aquí está la prueba resultante:

Puedo ver que irisdb está realizando la ejecución de Python, trazas con ISCAgent, y a la derecha puedo observar básicamente el proceso de inicialización de IRIS en el contenedor. Para ser totalmente transparente, esperaba ver los métodos de Python, así que tengo que trabajar en eso, pero aprendí que pythoninit.so es la estrella del espectáculo de llamadas de Python.

FHIR Thinger

Ahora, este muestra algunas trazas desde una perspectiva del kernel que son relevantes para una carga de trabajo FHIR. A la izquierda, se pueden ver los hilos de Apache del servidor web que está levantando la API, y también se puede observar en las trazas de irisdb el desmarshalling de JSON.

Todo ello se genera desde un hilo mediante lo que se conoce como una fiesta `zu210fun`!

Ahora, echemos un vistazo a la misma carga de trabajo en Grafana, ya que Parca exporta a la observabilidad:

No es nada sorprendente, lo sé, pero el objetivo es realizar un perfilado distribuido de una aplicación IRIS con eBPF, de manera ligera, a través de todo un clúster... ¡con el único objetivo de no tener que pedirle nunca más a un cliente un informe de pButtons!