Linnix

Encuentra qué proceso está dañando tus SLOs — no solo quién está usando CPU, sino quién está causando bloqueos.

El Problema

top muestra 80% de CPU. Prometheus muestra latencia alta. Pero, ¿qué pod está realmente bloqueando tu servicio de pago?

Linnix utiliza eBPF + PSI (Pressure Stall Information) para responder esto. PSI mide el tiempo de bloqueo real — no el uso, sino la contención. Un pod que usa 40% de CPU con un 60% de PSI es peor que uno que usa 100% de CPU con un 5% de PSI.

Lo que Linnix detecta:

• Vecinos ruidosos: Qué contenedor está privando a otros
• Tormentas de forks: Creación descontrolada de procesos antes de que colapse el nodo
• Atribución de bloqueos: "El Pod X causó un bloqueo de 300ms al Pod Y"
• Saturación de PSI: Presión de CPU/IO/Memoria que no aparece en top

[!IMPORTANT] Solo monitoreo por defecto. Linnix detecta e informa — nunca toma acción sin configuración explícita.

🔒 Seguridad y Privacidad

• Política de Seguridad: Consulta nuestro modelo de seguridad, privilegios requeridos y proceso de reporte de vulnerabilidades
• Garantías de Seguridad: Entiende nuestra arquitectura "Monitor-First" y controles de seguridad
• Visión General de la Arquitectura: Diagrama del sistema y flujo de datos para revisiones de seguridad

Promesa clave: Todo el análisis ocurre localmente. Ningún dato sale de tu infraestructura a menos que configures explícitamente notificaciones de Slack. Más información sobre privacidad de datos →

Inicio rápido (Kubernetes)

Despliega Linnix como un DaemonSet para monitorear tu clúster.

# Apply the manifests
kubectl apply -f k8s/

Accede a la API:

kubectl port-forward daemonset/linnix-agent 3000:3000
# API available at http://localhost:3000
# Stream events: curl http://localhost:3000/stream

Inicio rápido (Docker)

Pruébalo en tu máquina local en 30 segundos.

git clone https://github.com/linnix-os/linnix.git && cd linnix
./quickstart.sh

Cómo funciona

1. Colector (eBPF): Se sitúa en el kernel, observando eventos de fork, exec, exit y del planificador con <1% de sobrecarga.
2. Motor de razonamiento: Agrega señales (PSI + CPU + Árbol de procesos) para detectar patrones de fallo.
3. Asistente de triaje: Cuando se supera un umbral, Linnix captura el estado del sistema y explica la causa raíz.

Detecciones soportadas

Seguridad y Arquitectura

Linnix está diseñado para la seguridad en producción.

• Monitor-First: Las capacidades de aplicación son optativas y requieren configuración explícita.
• Baja sobrecarga: Utiliza búferes de rendimiento eBPF, no sondeo de /proc.
• Aislamiento de privilegios: Puede ejecutarse con CAP_BPF y CAP_PERFMON en bare metal. El DaemonSet de Kubernetes actualmente usa modo privilegiado por simplicidad.

Consulta SAFETY.md para nuestro modelo de seguridad detallado.

Características de Kubernetes

Linnix tiene soporte de primera clase para Kubernetes:

• Atribución de pods: Cada evento de proceso está etiquetado con pod_name, namespace, container_id
• Conciencia de namespaces: Filtra y consulta por namespace
• Seguimiento de contribución de PSI: Ve qué pod contribuyó a la presión de PSI en todo el sistema
• Integración con cgroups: Asigna procesos a sus cgroups para agregación a nivel de contenedor

# Example: Get processes causing stalls in the payments namespace
curl "http://localhost:3000/processes?namespace=payments&sort=psi_contribution"

Comercio / Liquidación en Cadena

Linnix incluye una capa de pago sin confianza (Linnix-Claw) que liquida el trabajo entre agentes en cadena mediante stablecoins ERC-20. Cuando un agente delega una tarea a otro, el resultado — un recibo firmado con prueba de telemetría — se envía a un contrato inteligente TaskSettlement que libera el pago directamente del pagador al beneficiario.

Arquitectura

Agent A (payer)                    Agent B (payee)
   │  createTask(taskId, payeeDID, maxAmount)
   │──────────────────────────────────▶│
   │                                   │ ← does work, captures eBPF telemetry
   │    submitReceipt(taskId, amount, receipt, sig)
   │◀──────────────────────────────────│
   │                                   │
   └──── TaskSettlement.sol ─── ERC-20 transfer ──▶ payee

Contratos clave (testnet de Base Sepolia):

Configuración

Agrega una sección [chain] a tu linnix.toml:

[chain]
enabled = true
rpc_url = "https://sepolia.base.org"
chain_id = 84532
settlement_contract = "0x60eE6872920addF41359625B47A07401496bBD5b"
registry_contract = "0x9a6FeBA6d7B97ef91099051eB61F372d1EcD83a3"
token_address = "0x036CbD53842c5426634e7929541eC2318f3dCF7e"  # USDC on Base Sepolia
token_decimals = 6

La clave del firmante se resuelve en orden de prioridad:

1. chain.private_key en la configuración
2. Variable de entorno LINNIX_CHAIN_PRIVATE_KEY
3. Clave secp256k1 derivada de HKDF a partir de la identidad Ed25519 del agente (por defecto — configuración cero)

Demostración de extremo a extremo

# Deploy contracts to a local Hardhat node
cd linnix-claw-contracts && npx hardhat node &
npx hardhat run scripts/deploy.js --network localhost

# Run the commerce demo
./scripts/demo_commerce_e2e.sh --local

Consulta la fuente del contrato y cognitod/src/onchain.rs para detalles de implementación.

Adoptantes tempranos

Este proyecto está en desarrollo activo. Si lo estás usando o evaluando, abre un issue o envía un correo a [email protected].

Licencia

• Agente (cognitod): AGPL-3.0
• Colector eBPF: GPL-2.0 o MIT (los programas eBPF deben ser compatibles con GPL para la carga en el kernel)

Licencias comerciales disponibles para equipos que no pueden usar AGPL. Consulta LICENSE_FAQ.md para más detalles.