Histórico de tarefas
As pequenas empresas, por um lado, precisam de um monitoramento de alta qualidade de sua infraestrutura (especialmente à luz da virtualização generalizada); por outro, é financeiramente difícil para elas adquirir novos equipamentos. Além disso, geralmente há problemas com o servidor / hardware: geralmente existem 1-3 servidores em torre próximos às estações de trabalho dos usuários ou em um pequeno nicho / armário.
É mais fácil usar uma montagem pronta (distribuição), que é suficiente para carregar em um cartão microSD e inseri-la em um computador de placa única comum (famílias de beaglebone, raspberry pi e orange pi, asus tinker). Além disso, esse equipamento é barato e pode ser instalado em qualquer lugar.
Declaração do problema
De várias maneiras, o projeto se desenvolveu como uma espécie de trabalho de laboratório, com a possibilidade de aplicar os resultados.
O Zabbix foi escolhido como o sistema de monitoramento, pois é um sistema poderoso, gratuito e bem documentado.
A questão surgiu com a plataforma de hardware: colocar uma máquina separada sob monitoramento também não é uma boa solução - ou é caro comprar novos equipamentos ou procurar um antigo + nas pequenas empresas, há problemas frequentes com o servidor / hardware.
O uso do sistema buildroot build permite criar soluções especializadas que podem ser operadas pela equipe com conhecimento mínimo da família de sistemas operacionais Linux. Esse sistema é amigável para iniciantes, mas, ao mesmo tempo, oferece amplas oportunidades de personalização nas mãos de um desenvolvedor experiente. É perfeito para resolver a tarefa de um monitoramento não-caro, mas completo, da infraestrutura de TI, que é minimamente exigente no treinamento de seu pessoal operacional.
Etapas da solução
Decidiu-se criar inicialmente o firmware para o x86_64 ser executado no qemu, pois essa é uma solução rápida e conveniente para a depuração. Em seguida, mova para um braço de computador de placa única (gostei da placa de asus tinker).
A buildroot foi escolhida como o sistema de construção. Inicialmente, faltava o pacote zabbix, então tive que portá-lo.Existem problemas com a localidade russa que foram resolvidos aplicando os patches apropriados (nota: nas versões mais recentes do buildroot, esses patches não são mais necessários).
A portabilidade do próprio pacote zabbix será descrita em um artigo separado.
Como tudo deve funcionar como firmware (imagem do sistema inalterada + arquivos de configuração / banco de dados recuperáveis), foi necessário gravar os alvos, serviços e timers do systemd (target, service, timer).
Decidiu-se dividir a mídia em duas seções - uma seção com arquivos do sistema e uma seção com configurações mutáveis e arquivos de banco de dados zabbix.
Acabou sendo um pouco mais difícil resolver problemas associados ao banco de dados. Eu não queria colocá-lo diretamente na mídia. Ao mesmo tempo, o tamanho da base pode atingir um tamanho que excede o tamanho de um possível disco ram. Portanto, foi escolhida uma solução de compromisso: o banco de dados está localizado na segunda seção do cartão sd (os cartões SLC modernos têm até 30.000 ciclos de gravação), mas há uma configuração que permite o uso de mídia externa (por exemplo, usb-hdd).
O monitoramento da temperatura foi implementado através do dispositivo RODOS-5. Obviamente, você pode usar o dallas 1820 diretamente, mas foi mais rápido e fácil conectar um USB.
O Grub2 foi escolhido como o carregador de inicialização do x86_64. Levei para escrever uma configuração mínima para executar.
Após a depuração no qemu, foi realizada a portabilidade para a placa de asus tinker. Na estrutura da minha sobreposição, foi inicialmente apresentada a plataforma cruzada - a seleção de configurações específicas para cada placa (placas defconfig, carregador de inicialização, geração de imagens com uma partição do sistema) e a uniformidade máxima no ajuste do sistema de arquivos / criação de uma imagem com dados. Devido a essa preparação, a portabilidade foi rápida.
É altamente recomendável que você leia os artigos introdutórios:
https://habr.com/en/post/448638/
https://habr.com/en/post/449348/
Como montar
O projeto é armazenado no github
Após a clonagem do repositório, a seguinte estrutura de arquivo é obtida:
[alexey@comp monitor]$ ls -1 buildroot-2019.05.tar.gz overlay README.md run_me.sh
buildroot-2019.05.tar.gz - arquivo de buildroot limpo
overlay é meu diretório com árvore externa. Ele contém tudo o que você precisa para construir o firmware usando o buildroot
README.md - descrição e orientação do projeto em inglês.
run_me.sh é um script que prepara o sistema de construção. Expande a buildroot do arquivo morto, anexa sobreposição a ele (através do mecanismo de árvore externa) e permite selecionar a placa de destino para montagem
[0] my_asus_tinker_defconfig [1] my_beaglebone_defconfig [2] x86_64_defconfig Select defconfig, press A for abort. Default [0]
Depois disso, basta ir para o diretório buildroot-2019.05 e executar o comando make.
Após a montagem, todos os resultados da montagem estarão no diretório output / images:
[alexey@comp buildroot-2019.05]$ ls -1 output/images/ boot.img boot.vfat bzImage data data.img external.img external.qcow2 grub-eltorito.img grub.img intel-ucode monitor-0.9-beta.tar.gz qemu.qcow2 rootfs.cpio sdcard.img sys update
Arquivos necessários:
- sdcard.img - a imagem da mídia para gravar no cartão sd (via dd ou rufus sob wibdows).
- qemu.qcow2 - imagem de mídia a ser executada no qemu.
- external.qcow2 - imagem de mídia externa para o banco de dados
- monitor-0.9-beta.tar.gz - arquivo para atualização via interface da web
Geração manual
Não vale a pena escrever as mesmas instruções várias vezes. E é mais lógico escrever uma vez na remarcação e depois convertê-lo em PDF para download e html para a interface da web. Isso é possível graças ao pacote pandoc.
Ao mesmo tempo, você precisa gerar todos esses arquivos antes da montagem da imagem do sistema; esses scripts pós-compilação já são inúteis. Portanto, a geração é feita na forma de pacote de manuais. Você pode vê-lo em sobreposição / pacote / manuais.
O arquivo manuals.mk (que faz todo o trabalho)
systemd
O mundo do Linux está mudando ativamente para o systemd, e eu também precisei fazê-lo.
Das boas inovações - a presença de temporizadores. Em geral, um artigo separado é escrito sobre eles (e não apenas sobre eles), mas vou lhe dizer brevemente.
Existem ações que devem ser executadas periodicamente. Eu precisava executar o logrotate para limpar os logs lighttpd e php-fpm. Seria mais comum escrever comandos no cron, mas decidi usar o temporizador monótono do systemd. Assim, o logrotate inicia em um intervalo de tempo estrito.
Claro, existe a possibilidade de criar temporizadores que funcionam em determinadas datas, mas eu não precisava disso.
Exemplo de temporizador:
[Temporizador]
OnBootSec = 1min
OnUnitActiveSec = 1min
[Instalar]
WantedBy = timers.target
- , : ```bash [Unit] Description=RODOS temp daemon [Service] ExecStart=/usr/bin/rodos.sh
Placas Suportadas
Asus tinker board - a placa principal em que tudo deve funcionar. Selecionado como barato e muito poderoso.
O Beaglebone black é o primeiro painel em que o trabalho foi testado (durante a seleção de um painel mais poderoso).
Qemu x86_64 - usado para desenvolver depuração.
Como isso funciona
Na inicialização, ocorre uma recuperação de duas etapas das configurações:
- executando o script settings_restore (por meio do serviço). Restaura as configurações básicas do sistema - fuso horário, localidade, configurações de rede etc.
- executando o script de preparação (através do serviço) - aqui o zabbix é preparado, o banco de dados, o IP é exibido no console.
Na primeira partida, é determinado o tamanho da segunda seção do cartão SD. Se ainda houver espaço não alocado - a mídia é reparticionada, a seção de dados ocupa todo o espaço livre. Isso é feito para reduzir o tamanho da imagem de instalação (sdcard.img). Além disso, o diretório de trabalho postgresql é criado neste momento. É por isso que o primeiro lançamento com um novo meio será mais longo que os seguintes.
Quando você conecta uma unidade externa, no momento da inicialização, ela procura uma unidade gratuita e a formata em ext4 com a etiqueta externa.
Atenção! Ao conectar uma unidade externa (além de desconectá-la ou substituí-la), é necessário fazer backup e restaurar as configurações!
Para monitorar a temperatura, é utilizado o dispositivo RODOS 5. O fabricante fornece as fontes de sua utilidade para trabalhar com o dispositivo. Quando o sistema é ligado, o rodos timer inicia, que inicia esse utilitário uma vez por minuto. A temperatura atual é gravada no arquivo / tmp / rodos_current_temp, após o qual o zabbix pode monitorar esse arquivo como um sensor.
A mídia de armazenamento para a configuração é montada no diretório / data.
Quando você inicia o sistema e o prepara para o trabalho, uma mensagem aparece no console:
System starting, please wait
Após a conclusão do trabalho preparatório, ele será alterado para exibir o endereço IP:
current ip 192.168.1.32 Ready to work
Configurando o zabbix para monitoramento de temperatura
Para monitorar a temperatura, basta seguir 2 etapas:
- conecte o dispositivo RODOS à porta usb
- criar item de dados no zabbix
Abra a interface da web do zabbix:
- Abra a seção Configuração → Hosts
- Clique em Itens na linha do nosso servidor zabbix
- Clique em Criar item
Digite os seguintes dados:
- nome - a seu critério (por exemplo, serverRoomTemp)
- Tipo - agente zabbix
- Key - rodos
- Tipo - numérico
- Unidades - C
- Período de armazenamento do histórico - o termo do histórico. deixou 10 dias
- Período de armazenamento de tendências - período de armazenamento da dinâmica de alterações. Deixou 30 dias
- Nova aplicação - temperatura da sala do servidor
E pressione o botão ADICIONAR.
Gerenciamento via Web
A interface da web é escrita em php. Existem funções principais:
- ver status do dispositivo
- alterar configurações de rede
- alterar senha do usuário
- seleção de fuso horário
- backup / restauração / redefinição das configurações de fábrica
- a capacidade de conectar uma unidade externa
- Atualização do sistema
O login na interface da web é protegido por senha. Página inicial - manual.
Endereço da interface do Zabbix: \ $ {ip / dns} / zabbix
Endereço da interface de gerenciamento: \ $ {ip / dns} / manage
Executar no qemu
qemu-system-x86_64 -smp 4 -m 4026M -enable-kvm -machine q35, accel = serviço-kvm intel-iommu -cpu host -net nic -net bridge, br = bridge0 -device virtio-scsi-pci, id = scsi0 -drive arquivo = saída / imagens / qemu.qcow2, formato = qcow2, aio = threads - dispositivo virtio-scsi-pci, id = scsi0 -drive arquivo = saída / imagens / external.qcow2, formato = qcow2, aio = threads
Este comando iniciará um sistema com 4 núcleos, 2048 de RAM ativado pelo KVM, uma placa de rede no bridge0 e dois discos: para o sistema e externo para o postgresql.
As imagens podem ser convertidas e executadas no Virtualbox:
qemu-img convert -f qcow2 qemu.qcow2 -O vdi qcow2.vdi qemu-img convert -f qcow2 external.qcow2 -O vdi external.vdi
Em seguida, importe-os para o virtualbox e conecte-se via sata.
Conclusão
No processo, fiquei interessado em preparar um produto para o trabalho - com uma interface não muito agradável (não gosto de escrevê-los), mas funcionando e fácil de configurar.
A última tentativa de instalar o zabbix-appliance no KVM mostrou a correção dessa etapa (o sistema não inicia após a conclusão da instalação). Talvez eu esteja fazendo algo errado;)
Materiais
https://buildroot.org/