Recentemente decidi publicar alguns documentos, artigos, códigos, etc, que eu havia feito há muito tempo. Não se assustem com o conteúdo e versões, pois estão “um pouco” desatualizados, mas o conceito permanece.
Escrevi o artigo abaixo em 25 de março de 2006. Naquela data, o LKST estava na versão 1.01.
Linux Kernel State Tracer (LKST)
1. Propósito
Ambientes computacionais de grande porte necessitam alguns tópicos indiscutíveis, levando-se em conta a viabilidade, alguns deles são:
a) Segurança
b) Alta disponibilidade
c) Hardware redundante
d) Resposta imediata à incidentes
Devido à grande evolução do hardware, e do próprio kernel, muitos deixam de analisar a viabilidade de utilizar Linux adequadamente em seus sistemas. Para eles não é fácil fazer isto devido a grande evolução do hardware, tão bem acompanhada pelo kernel.
O LKST foi desenvolvido não só para prover informações confiáveis aos programadores que precisam uma forma eficaz e rápida de depurar problemas no sistema, mas também para disponibilizar informações de depuração quando o sistema operacional travar. Isto melhorará a qualidade do sistema fazendo com que as correções do kernel estejam disponíveis mais rapidamente, acompanhando a velocidade da evolução do hardware. Um programador de kernel que deseja descobrir as causas fundamentais dos problemas no sistema, precisa de um log de estados de transição do kernel. Logo, recorrendo a este log, poderá localizar o que aconteceu antes da paralização do sistema. Um log de eventos bem como interrupções de hardware, ajudará a solucionar o problema causado pelo hardware ou pelo software. E tais logs tornarão isso possível para engenheiros de sistemas que conhecem pouco ou quase nada do kernel do Linux. Porém, as únicas operações disponíveis quando o sistema trava, são simples dumps* de memória, que deveriam ser pequenos. Além disso, essas informações deveriam ser coletadas pelo próprio sistema quando uma falha ocorresse enquanto o sistema estivesse rodando em algum cliente. Estes logs, sendo pequenos, seriam aceitáveis para os sistemas de clientes, e o trabalho poderia ser feito pelo kernel do Linux.
2. Conceito de design
a) Obtendo informações detalhadas sobre falhas do kernel:
O LKST grava não somente stack-traces* e valores dos registradores do processador, mas também as transições de estado mais importantes do kernel, modificações de variáveis importantes, e eventos de hardware.
E além de registrar esses eventos, registra informações relacionadas a eles.
b) Recuperar logs de apoio até mesmo quando o sistema operacional entra em loop infinito:
Os logs que o LKST grava deveriam ser pequenos o bastante para que eles possam ser simplesmente recobrados por um dump* de memória. O LKST também deveria prover meios de exportar logs, incluindo porta serial.
c) Minimizar o log, mesmo em sistemas multi-processados:
Já que o LKST será utilizado em sistemas de clientes, deveria requerer poucos recursos e também evitar locks em sistemas multi-processados.
d) Suportar triggers extensíveis ao usuário para permitir coletar erros e monitoramento:
As Informações coletadas podem diferir de sistema para sistema. Os usuários podem precisar de dados que o LKST padrão não coleta, assim eles poderiam personalizar as chamadas de funções do LKST quando determinados eventos ocorrerem.
e) Conformidade com o padrão:
As informações do LKST deveriam ter conformidade com o POSIX Draft Standard (1003.25). E o mesmo deveria ser controlado por APIs conforme este padrão.
3. Projetos relacionados
Os projetos a seguir podem ser de valor aos interessados no LKST:
a) LTT – Linux Trace Toolkit
b) LKCD – Linux Kernel Crash Dump
c) Linux Event Logging for Enterprise-Class Systems
d) Kernel Tracer in IKD – Integrated Kernel Debugging Facilities
4. Referências
a) Linux Kernel State Tracer (LKST)
b) lkst-spec-1.01.pdf
c) TechnicalConference
