Histórico de problemas
As pequenas empresas, por um lado, necessitam de monitorização de alta qualidade da sua infra-estrutura (especialmente à luz da virtualização generalizada), por outro lado, é financeiramente difícil para elas adquirir novos equipamentos. Problemas de servidor/hardware também são comuns: muitas vezes há de 1 a 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 você só precisa fazer upload para um cartão microSD e inserir em um computador comum de placa única (famílias beaglebone, raspberry pi e orange pi, asus tinker board). Além disso, esse equipamento é barato e pode ser instalado em qualquer lugar.
Formulação do problema
Em muitos aspectos, o projeto desenvolveu-se como uma espécie de trabalho de laboratório com possibilidade de aplicação dos resultados.
O Zabbix foi escolhido como sistema de monitoramento por ser um sistema poderoso, gratuito e bem documentado.
O problema com a plataforma de hardware tornou-se agudo. Colocar uma máquina separada sob monitoramento também não é uma solução muito boa - ou é caro comprar equipamentos novos, ou procurar equipamentos antigos + em pequenas empresas há problemas frequentes com servidor/ hardware.
Usar o sistema de compilação buildroot permite criar soluções especializadas que podem ser operadas por pessoal com conhecimento mínimo de sistemas operacionais Linux. Este 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 o problema do monitoramento barato, mas totalmente funcional da infraestrutura de TI, com requisitos mínimos para o treinamento do pessoal que a opera.
Etapas da solução
Decidiu-se inicialmente criar firmware para x86_64 para rodar em qemu, por ser uma solução conveniente e rápida para depuração. Em seguida, porte-o para um computador de placa única (gostei da placa Asus Tinker).
buildroot foi selecionado como o sistema de compilação. Inicialmente faltava o pacote zabbix, então teve que ser portado. Houve problemas com a localidade russa, que foram resolvidos aplicando os patches apropriados (nota: em versões mais recentes do buildroot, esses patches não são mais necessários).
A portabilidade do pacote zabbix será descrita em um artigo separado.
Como tudo deveria funcionar como firmware (imagem de sistema imutável + arquivos de configuração/banco de dados recuperáveis), foi necessário escrever seus próprios alvos, serviços e temporizadores do systemd (destino, serviço, temporizador).
Foi decidido dividir a mídia em 2 seções - uma seção com arquivos de sistema e uma seção com configurações alteráveis e arquivos de banco de dados zabbix.
Resolver problemas relacionados ao banco de dados acabou sendo um pouco mais difícil. Eu não queria colocá-lo diretamente na mídia. Ao mesmo tempo, o tamanho do banco de dados pode atingir um tamanho que excede o tamanho de um possível ramdisk. Portanto, foi escolhida uma solução de compromisso: o banco de dados está localizado na segunda partição do cartão SD (os cartões SLC modernos têm até 30 ciclos de gravação), mas há uma configuração que permite o uso de mídia externa (por exemplo, usb- disco rígido).
O monitoramento da temperatura foi implementado através do dispositivo RODOS-5. Claro, você pode usar o Dallas 1820 diretamente, mas foi mais rápido e fácil conectar um USB.
grub86 foi selecionado como bootloader para x64_2. Foi necessário escrever uma configuração mínima para iniciá-lo.
Após a depuração no qemu, ele foi portado para o asus tinker board. A estrutura da minha sobreposição foi inicialmente planejada para ser multiplataforma - alocando configurações específicas para cada placa (defconfig da placa, bootloader, geração de imagem com partição do sistema) e máxima uniformidade na personalização do sistema de arquivos/criação de uma imagem com dados. Devido a essa preparação, a portabilidade foi rápida.
É altamente recomendável ler os artigos introdutórios:
Como montar
Após clonar o repositório, é obtida a seguinte estrutura de arquivos:
[alexey@comp monitor]$ ls -1
buildroot-2019.05.tar.gz
overlay
README.md
run_me.shbuildroot-2019.05.tar.gz - limpar arquivo buildroot
overlay é meu diretório com árvore externa. É aqui que tudo que você precisa para construir o firmware usando buildroot é armazenado.
README.md – descrição do projeto e manual em inglês.
run_me.sh é um script que prepara o sistema de compilação. Expande buildroot do arquivo, anexa uma sobreposição a ele (por meio 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 ao diretório buildroot-2019.05 e executar o comando make.
Assim que a compilação for concluída, todos os resultados da compilação 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
updateArquivos necessários:
- sdcard.img - imagem de mídia para gravação em um cartão SD (via dd ou rufus em wibdows).
- qemu.qcow2 - imagem de mídia para rodar 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 web
Geração de Guias
Não vale a pena escrever as mesmas instruções várias vezes. E o mais lógico é escrevê-lo uma vez no markdown e depois convertê-lo em PDF para download e html para a interface web. Isso é possível graças ao pacote pandoc.
Ao mesmo tempo, todos esses arquivos precisam ser gerados antes da montagem da imagem do sistema; esses scripts pós-construção já são inúteis. Portanto, a geração é feita na forma de pacote de manuais. Você pode consultar sobreposição/pacote/manuais.
O arquivo manuals.mk (que faz todo o trabalho)
################################################################################
#
# manuals
#
################################################################################
MANUALS_VERSION:= 1.0.0
MANUALS_SITE:= ${BR2_EXTERNAL_monitorOverlay_PATH}/package/manuals
MANUALS_SITE_METHOD:=local
define MANUALS_BUILD_CMDS
pandoc -s -o ${TARGET_DIR}/var/www/manual_en.pdf ${BR2_EXTERNAL_monitorOverlay_PATH}/../README.md
pandoc -f markdown -t html -o ${TARGET_DIR}/var/www/manual_en.html ${BR2_EXTERNAL_monitorOverlay_PATH}/../README.md
endef
$(eval $(generic-package))sistema
O mundo Linux está migrando ativamente para o systemd, e eu também tive que fazer isso.
Uma das novidades agradáveis é a presença de temporizadores. Em geral, um artigo separado está sendo escrito sobre eles (e não apenas sobre eles), mas contarei brevemente.
Existem ações que devem ser realizadas periodicamente. Eu precisava executar o logrotate para limpar os logs lighttpd e php-fpm. O normal seria escrever os comandos no cron, mas decidi usar o timer monotônico do systemd. Portanto, o logrotate é executado em um intervalo de tempo estrito.
Claro, é possível criar temporizadores que disparam em determinadas datas, mas eu não precisava disso.
Exemplo de temporizador:
- Arquivo de temporizador
[Unit] Description=RODOS temp daemon timer
OnUnitActiveSec=1min [Instalar] WantedBy=timers.target
- Файл сервиса, вызываемого таймером:
```bash
[Unit]
Description=RODOS temp daemon
[Service]
ExecStart=/usr/bin/rodos.shPlacas suportadas
A Asus Tinker Board é a placa principal na qual tudo deve funcionar. Selecionado como barato e muito poderoso.
Beaglebone black é a primeira placa em que o funcionamento foi testado (durante a seleção de uma placa mais potente).
Qemu x86_64 - usado para depuração de desenvolvimento.
Como funciona
Na inicialização, ocorre uma restauração das configurações em dois estágios:
- executando o script settings_restore (por meio do serviço). Ele restaura as configurações básicas do sistema – fuso horário, localidade, configurações de rede, etc.
- executando o script prepare (através do serviço) - aqui o zabbix e o banco de dados são preparados, o IP é enviado para o console.
Ao iniciá-lo pela primeira vez, o tamanho da segunda partição do cartão SD é determinado. Se ainda houver espaço não alocado, a mídia será reparticionada e a seção de dados ocupará 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 do postgresql é criado neste ponto. É por isso que o primeiro lançamento com uma nova operadora será mais longo do que os subsequentes.
Ao conectar um drive externo, no momento da inicialização ele procura um drive livre e o formata em ext4 com o rótulo externo.
Atenção! Ao conectar uma unidade externa (bem como desconectá-la ou substituí-la), você precisa fazer um backup e restaurar as configurações!
Para monitoramento de temperatura é utilizado o dispositivo RODOS 5. O fabricante fornece o código-fonte de seu utilitário para trabalhar com o dispositivo. Quando o sistema é ligado, é iniciado o temporizador rodos, que executa este utilitário uma vez por minuto. A temperatura atual é gravada no arquivo /tmp/rodos_current_temp, após o qual o zabbix pode monitorar este arquivo como um sensor.
A mídia de armazenamento de configuração é montada no diretório /data.
Ao iniciar o sistema e prepará-lo para operação, aparece a seguinte mensagem no console:
System starting, please waitApós a conclusão do trabalho preparatório, passará a exibir o endereço IP:
current ip 192.168.1.32
Ready to workConfigurando o zabbix para monitoramento de temperatura
Para monitorar a temperatura, basta realizar 2 passos:
- conecte o dispositivo RODOS à porta USB
- criar item de dados no zabbix
Abra a interface web do zabbix:
- Abra a seção Configuração → Hosts
- Clique em Itens na linha do nosso servidor zabbix
- Clique em Criar item
Insira os seguintes dados:
- nome - a seu critério (por exemplo, serverRoomTemp )
- Tipo - agente zabbix
- Chave - Rodos
- Tipo numérico
- Unidades - C
- Período de armazenamento do histórico — período de armazenamento do histórico. faltam 10 dias
- Período de armazenamento de tendências – período de armazenamento para a dinâmica das mudanças. Faltam 30 dias
- Novo aplicativo - servidor Room Temp
E pressione o botão ADICIONAR.
Gerenciar configurações via interface web
A interface web é escrita em PHP. Existem funções principais:
- visualizar o status do dispositivo
- alterando configurações de rede
- alterando a senha do usuário
- seleção de fuso horário
- backup/restauração/redefinição de fábrica
- 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 Zabbix: ${ip/dns}/zabbix
Endereço da interface de gerenciamento: ${ip/dns}/manage
Executando no qemu
qemu-system-x86_64 -smp 4 -m 4026M -enable-kvm -machine q35,accel=kvm -device intel-iommu -cpu host -net nic -net bridge,br=bridge0 -device virtio-scsi-pci,id= scsi0 -drive file=output/images/qemu.qcow2,format=qcow2,aio=threads -device virtio-scsi-pci,id=scsi0 -drive file=output/images/external.qcow2,format=qcow2,aio=threads
Este comando iniciará um sistema com 4 núcleos, 2048 RAM, KVM habilitado, uma placa de rede em bridge0 e dois discos: um para o sistema e outro externo para 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.vdiEm seguida, importe-os para o virtualbox e conecte-se via sata.
Conclusão
No processo, me interessei em fazer um produto pronto para uso - com uma interface não muito bonita (não gosto de escrevê-la), mas que funcione e seja fácil de configurar.
A última tentativa de instalação do zabbix-appliance no KVM mostrou que esta etapa estava correta (após a conclusão da instalação, o sistema não inicia). Talvez eu esteja fazendo algo errado 😉
Fonte: habr.com