Linnix

Descubra qual processo está prejudicando seus SLOs — não apenas quem está usando CPU, mas quem está causando travamentos.

O Problema

top mostra 80% de CPU. O Prometheus mostra alta latência. Mas qual pod está realmente travando seu serviço de pagamento?

O Linnix usa eBPF + PSI (Pressure Stall Information) para responder a isso. O PSI mede o tempo real de travamento — não o uso, mas a contenção. Um pod usando 40% de CPU com 60% de PSI é pior do que um usando 100% de CPU com 5% de PSI.

O que o Linnix detecta:

• Vizinhos Barulhentos: qual contêiner está privando os outros de recursos
• Tempestades de Fork: criação descontrolada de processos antes de derrubar o nó
• Atribuição de Travamentos: "O Pod X causou um travamento de 300ms ao Pod Y"
• Saturação de PSI: pressão de CPU/IO/Memória que não aparece no top

[!IMPORTANT] Apenas monitoramento por padrão. O Linnix detecta e reporta — ele nunca age sem configuração explícita.

🔒 Segurança e Privacidade

• Política de Segurança: veja nosso modelo de segurança, privilégios necessários e o processo de reporte de vulnerabilidades
• Garantias de Segurança: entenda nossa arquitetura "Monitor-First" e os controles de segurança
• Visão Geral da Arquitetura: diagrama do sistema e fluxo de dados para revisões de segurança

Promessa-chave: toda a análise acontece localmente. Nenhum dado sai da sua infraestrutura a menos que você configure explicitamente notificações do Slack. Saiba mais sobre privacidade de dados →

Início Rápido (Kubernetes)

Implante o Linnix como um DaemonSet para monitorar seu cluster.

# Apply the manifests
kubectl apply -f k8s/

Acesse a API:

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

Início Rápido (Docker)

Experimente na sua máquina local em 30 segundos.

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

Como Funciona

1. Coletor (eBPF): fica no kernel, observando eventos de fork, exec, exit e de agendamento com menos de 1% de overhead.
2. Mecanismo de Raciocínio: agrega sinais (PSI + CPU + Árvore de Processos) para detectar padrões de falha.
3. Assistente de Triagem: quando um limite é excedido, o Linnix captura o estado do sistema e explica a causa raiz.

Detecções Suportadas

Segurança e Arquitetura

O Linnix foi projetado para segurança em produção.

• Monitor-First: recursos de aplicação de políticas são opcionais e exigem configuração explícita.
• Baixo Overhead: usa buffers de perf do eBPF, não polling de /proc.
• Isolamento de Privilégios: pode executar com CAP_BPF e CAP_PERFMON em bare metal. O DaemonSet do Kubernetes atualmente usa o modo privilegiado por simplicidade.

Veja SAFETY.md para nosso modelo de segurança detalhado.

Recursos do Kubernetes

O Linnix tem suporte de primeira classe para Kubernetes:

• Atribuição de Pods: cada evento de processo é marcado com pod_name, namespace, container_id
• Consciência de Namespace: filtre e consulte por namespace
• Rastreamento de Contribuição de PSI: veja qual pod contribuiu para a pressão de PSI em todo o sistema
• Integração com cgroups: mapeia processos para seus cgroups para agregação em nível de contêiner

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

Comércio / Liquidação On-Chain

O Linnix inclui uma camada de pagamento sem confiança (Linnix-Claw) que liquida trabalho agente-a-agente on-chain por meio de stablecoins ERC-20. Quando um agente delega uma tarefa a outro, o resultado — um recibo assinado com prova de telemetria — é enviado a um contrato inteligente TaskSettlement que libera o pagamento diretamente do pagador para o beneficiário.

Arquitetura

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-chave (testnet Base Sepolia):

Configuração

Adicione uma seção [chain] ao seu 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

A chave do assinante é resolvida na seguinte ordem de prioridade:

1. chain.private_key na configuração
2. variável de ambiente LINNIX_CHAIN_PRIVATE_KEY
3. chave secp256k1 derivada via HKDF a partir da identidade Ed25519 do agente (padrão — zero configuração)

Demonstração de Ponta a Ponta

# 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

Veja o código-fonte do contrato e cognitod/src/onchain.rs para detalhes de implementação.

Primeiros Adotantes

Este projeto está em desenvolvimento ativo. Se você está usando ou avaliando, abra uma issue ou envie um e-mail para [email protected].

Licença

• Agente (cognitod): AGPL-3.0
• Coletor eBPF: GPL-2.0 ou MIT (programas eBPF devem ser compatíveis com GPL para carregamento no kernel)

Licenciamento comercial disponível para equipes que não podem usar AGPL. Veja LICENSE_FAQ.md para detalhes.