New post

Find

Question
· Oct 2, 2024

Create a CVS file with escape sequence to highlight the word in red

#CSV #Caché

Hi,

I try to create a tab delimiter file with bold header, when I convert the file into Microsoft Excel, it has a bold header.  The file can be in text or CSV exension.

Thank you.

Alan

4 Comments
Discussion (4)2
Log in or sign up to continue
Article
· Oct 2, 2024 4m read

eBPF: Parca - Perfilado Continuo para Cargas de Trabajo IRIS

#Kubernetes #Monitoring #Performance #Security #InterSystems IRIS

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!

Discussion (0)1
Log in or sign up to continue
Article
· Oct 2, 2024 15m read

eBPF: Rastreando eventos de Kernel para IRIS Workloads

#Performance #Kubernetes #Monitoring #Security #InterSystems IRIS

 

Eu estive na Cloud Native Security Con em Seattle com total intenção de entrar no dia de OTEL, então lendo o assunto de segurança aplicada a fluxos de trabalho Cloud Native nos dias seguintes até CTF como um exercício profissional. Isso foi felizmente finalizado por um novo entendimento de eBPF, que tem minhas telas, carreira, fluxos de trabalho e atitude com muita necessidade de uma melhoria com novas abordagens para resolver problemas de fluxo de trabalho.

Então, consegui chegar à festa do eBPF e desde então tenho participado de clínica após clínica sobre o assunto. Aqui, gostaria de "desempacotar" o eBPF como uma solução técnica, mapeada diretamente para o que fazemos na prática (mesmo que esteja um pouco fora), e passar pelo eBPF através da minha experimentação em suporte a cargas de trabalho InterSystems IRIS, particularmente no Kubernetes, mas não necessariamente vazio em cargas de trabalho autônomas.

Passos eBee com eBPF e fluxos de trabalho InterSystems IRIS


 

eBPF

eBPF (extended Berkeley Packet Filter) é um recurso poderoso do kernel Linux que implementa uma VM dentro do espaço do kernel e torna possível executar aplicativos sandboxes de forma segura com guias. Esses aplicativos podem "mapear" dados para o espaço do usuário para observabilidade, rastreamento, segurança e redes. Eu penso nisso como um "cheirador" do SO, onde tradicionalmente estava associado ao BPF e redes, e a versão estendida "cheira" pontos de rastreamento, processos, agendamento, execução e acesso a dispositivos de bloco. Se você não comprou minha analogia de eBPF, aqui está uma dos prós:

"O que JavaScript é para o browser, eBPF é para o Linux Kernel"

JavaScript permite que você anexe callbacks a eventos no DOM para trazer recursos dinâmicos à sua página web. De maneira semelhante, o eBPF permite conectar-se a eventos do kernel e estender sua lógica quando esses eventos são acionados!

Immediatamente Aplicável

SE; a seguinte métrica Prometheus parece impossível para você, empregue eBPF para observar processos que devem estar lá e monitorar em banda através do kernel

# HELP iris_instance_status The thing thats down telling us its down.
# TYPE iris_instance_status gauge
iris_instance_status 0

SE; você está cansado de implorar para o seguinte para um sidecar obter a observabilidade necessária, Adeus sidecars

  iris-sidecar:    
    resources:
      requests:
        memory: "2Mi"
        cpu: "125m"

onde

Uma das coisas mais satisfatórias sobre como o eBPF é aplicado é onde ele roda... em uma VM, dentro do kernel. E graças ao Linux Namespacing, você pode adivinhar o quão poderoso isso é em um ambiente nativo da nuvem, quanto mais em um kernel baseado em algum tipo de virtualização ou uma grande máquina ghetto blaster de ferro com hardware admirável.

 

"Olá Mundi" Obrigatório

Para aqueles de vocês que gostam de experimentar coisas por si mesmos e desde o "começo", por assim dizer, eu saúdo vocês com um obrigatório "Olá Mundo", torcido para ser um pouco "iristico". No entanto, é amplamente entendido que programar em eBPF não se tornará uma habilidade exercida com frequência, mas concentrada em indivíduos que desenvolvem o kernel Linux ou constroem ferramentas de monitoramento de próxima geração.

Eu uso Pop OS/Ubuntu, e aqui está meu código de consulta para entrar rapidamente no mundo do eBPF em 23.04:

sudo apt install -y zip bison build-essential cmake flex git libedit-dev \
  libllvm15 llvm-15-dev libclang-15-dev python3 zlib1g-dev libelf-dev libfl-dev python3-setuptools \
  liblzma-dev libdebuginfod-dev arping netperf iperf libpolly-15-dev
git clone https://github.com/iovisor/bcc.git
mkdir bcc/build; cd bcc/build
cmake ..
make
sudo make install
cmake -DPYTHON_CMD=python3 .. # build python3 binding
pushd ../src/python/
make
sudo make install
popd
cd bcc
make install

Primeiro assegure que o kernel objetivo tem as coisas necessárias...

cat /boot/config-$(uname -r) | grep 'CONFIG_BPF'
CONFIG_BPF=y

Se `CONFIG_BPF=y`  está na sua janela em algum lugar, podemos seguir.

O que queremos alcançar aqui com esse simples olá mundo é obter visibilidade de quando o IRIS está fazendo chamadas de sistema LInux, sem o uso de nada além de ferramentas eBPF e o próprio kernel.

Aqui está uma boa maneira de seguir com a exploração:

1️⃣ Ache uma chamada de sistema Linux de interesse

sudo ls /sys/kernel/debug/tracing/events/syscalls

Para este exemplo, vamos 

Para este exemplo, vamos interceptar quando alguém (modificado para interceptar IRIS), cria um diretório através da chamada de sistema sys_enter_mkdir.



2️⃣ Insira isso no Olá Mundo que segue

Seu programa BPF para carregar e rodar está na variável BPF_SOURCE_CODE, modifique para incluir a syscall que você deseja interceptar.

# Example eBPF program to a Linux kernel tracepoint
# Modified to trap irisdb
# requires bpfcc-tools
# To run: sudo python3 irismadeadir.py
from bcc import BPF
from bcc.utils import printb

BPF_SOURCE_CODE = r"""
TRACEPOINT_PROBE(syscalls, sys_enter_mkdir) {
bpf_trace_printk("Directory was created by IRIS: %s\n", args->pathname);
return 0;
}
"""
bpf = BPF(text = BPF_SOURCE_CODE)

print("Go create a dir with IRIS...")
print("CTRL-C to exit")

while True:
    try:
        (task, pid, cpu, flags, ts, msg) = bpf.trace_fields()
        #print(task.decode("utf-8"))
        if "iris" in task.decode("utf-8"):
            printb(b"%s-%-6d %s" % (task, pid, msg))
    except ValueError:
        continue
    except KeyboardInterrupt:
        break

 

3️⃣ Carregue no Kernel, Rode

Crie um diretório em IRIS 

Inspecione o rastreio!

Binários Impulsionados por eBPF

Não leva muito tempo quando se passa pelo repositório bcc e percebe que há muitos exemplos, ferramentas e binários por aí que aproveitam o eBPF para fazer traçamentos divertidos, e "grep" nesse caso será suficiente para derivar algum valor.

 

Vamos fazer exatamente isso em um start e stop do IRIS com alguns exemplos fornecidos.

execsnoop Rastreie novos processes via syscalls exec().

Este aqui conta uma história dos argumentos ao irisdb no start/stop

 
sudo python3 execsnoopy.py | grep iris

statsnoop Rastreie stat() syscalls... retorna atributos de arquivo sobre um inode, acesso arquivo/diretório.

Este aqui é informativo para o acesso ao nível de diretório e arquivo durante uma inicialização/parada... um pouco loquaz, mas informativo sobre o que o iris está fazendo durante a inicialização, incluindo acesso cpf, diários, atividade wij e o uso de ferramentas de sistema para realizar o trabalho.

 
sudo python3 statsnoop.py | grep iris

Flamegraphs

Uma das coisas mais legais que encontrei com a ferramenta eBPF foi a implementação de flamegraphs de Brendan Gregg por cima da saída bpf para entender desempenho e pilhas de chamadas.

Dado o seguinte registro de desempenho durante uma inicialização/parada de IRIS:

sudo perf record -F 99 -a -g -- sleep 60
[ perf record: Woken up 7 times to write data ]
[ perf record: Captured and wrote 3.701 MB perf.data (15013 samples) ]

Gere o seguinte flamegrapth com o descrito abaixo:

sudo perf script > out.perf
./stackcollapse-perf.pl out.perf > /tmp/gar.thing
./flamegraph.pl /tmp/gar.thing > flamegraph.svg

Eu tentei o upload do svg, mas não funcionou com este editor e, por algum motivo, não consegui anexá-lo. Entenda, porém, que ele é interativo e clicável para detalhar as pilhas de chamadas, além de apenas parecer legal.

  1. "A função na parte inferior é a função on-CPU. Quanto mais alto no eixo y, mais profundamente aninhada está a função.
  2. A largura de cada função no gráfico representa a quantidade de tempo que a função levou para executar como uma porcentagem do tempo total de sua função pai.
  3. Encontrar funções que são altas no eixo y (profundamente aninhadas) e largas no eixo x (intensivas em tempo) é uma ótima maneira de reduzir problemas de desempenho e otimização.

"altas e largas" <--- 👀

red == nível de usuário

orange == kernel

yellow == c++

green == JIT, java etc.

Eu realmente gostei dessa explicação da interpretação de flamegraphs apresentada aqui (crédito para o acima), onde derivei uma compreensão básica sobre como ler flamegraphs. Especialmente poderoso para aqueles que estão executando Python em IRIS em produções com código de usuário e procurando otimização.

Em frente, espero que isso desperte seu interesse, agora vamos passar para o mundo dos aplicativos eBPF, onde os profissionais reuniram soluções fenomenais para colocar o eBPF a trabalhar em frotas de sistemas de forma segura e leve.

Discussion (0)1
Log in or sign up to continue
Question
· Oct 2, 2024

Possible contamination of full lock table between ECP application servers or via remote databases ?

#Databases #ECP #InterSystems IRIS

If several application servers are connected using ECP, and one of them create many locks, so many that lock table became full :

Should we expect only that application server to be impacted ? (usually, when lock table is full the system became instable). Or, are other application servers going to be impacted the same way ? (because that lock table is synchronized and maintained in sync across all servers)

I have another question (which is related) : is this the same with remote databases ?
Let's say 2 application servers access the same remote database and one application server create many locks. Is the other application server going to be impacted as well ?

3 Comments
Discussion (3)1
Log in or sign up to continue
Question
· Oct 2, 2024

Python.net Install

#.NET #Embedded Python #Python #InterSystems IRIS for Health

This is for IRIS For Health 2024.2.0

We are migrating away from the .NET Gateway and trying to use the python integration instead.

I followed the instructions to install IRIS

Then I installed python following the IRIS documentation indicating that python should be installed globally.

I set up the PythonRuntimeLibrary and PythonRuntimeLibraryVersion options under System->Configuration->Advanced memory settings and when I run the shell function, I get python:

USER>do ##class(%SYS.Python).Shell()
 
Python 3.12.6 (tags/v3.12.6:a4a2d2b, Sep  6 2024, 20:11:23) [MSC v.1940 64 bit (AMD64)] on win32
Type quit() or Ctrl-D to exit this shell

To reach out to our C# DLL, I ran the following command to install python.net

pip install pythonnet, it reported downloading items succuessfully.

To test, I have a simple python script that is just "import clr" and when I run this from the cmd prompt, it does not error out. I did make a demo DLL with a namespace, class, and one function. If I reference that DLL, it calls the function and prints hello world. So, it appears to me that python.net is working.

 

But when I create a new class and have 'import clr" in the classmethod with Language = python, I am getting this error:

USER>d ##class(User.Test).Check()
 
D ##CLASS(User.Test).Check()
^
<THROW> *%Exception.PythonException <PYTHON EXCEPTION> 246 <class 'RuntimeError'>: Failed to initialize Python.Runtime.dll

 

From my reading, I'm pretty sure its a path issue of some kind because I don't have the right environment variables set up.

I tried adding in all of these lines into the classmethod before I call import clr, and none of them have helped.

os.environ["PYTHONPATH"] = r"C:\Program Files\Python312\Lib\site-packages"

os.environ["PYTHONNET_PYDLL"] = r"C:\Program Files\Python312\python312.dll"

 

Has anyone else gotten python.net to work with IRIS?

Discussion (0)1
Log in or sign up to continue