Tínhamos 14.000 objetos, zabbix, api, python e uma relutância em adicionar objetos manualmente. Sob o corte - sobre como os gerentes de rede implementaram o monitoramento com a adição automática de nós da rede e um pouco sobre a dor pela qual eu tive que passar.
Este artigo se concentra mais em engenheiros de rede com pouca experiência em python. Para ajudar na automação do monitoramento e na melhoria da qualidade de vida e trabalho, na ausência da necessidade de atualizar manualmente toda a frota de objetos.
Para encurtar a história, construímos um monitoramento
Oi Meu nome é Alexander Prokhorov e, junto com a equipe de engenheiros de rede de nosso departamento, estamos trabalhando em uma rede no # ITX5. Nosso departamento desenvolve infraestrutura de rede, monitoramento e automação de rede. Sim, e tudo relacionado à transferência de dados.
Eu dividiria o sistema de monitoramento em 5 subtarefas:
- Baixar dados mestre
- Obtendo informações sobre o estado dos objetos
- Disparadores e alertas
- Relatórios
- Visualização
Neste artigo, gostaríamos de compartilhar como fizemos a integração do monitoramento com os dados mestre em nossa empresa.
Temos 14.000 propriedades de varejo, e a primeira tarefa que resolvemos foi a determinação de objetos inacessíveis, seu número e distribuição geográfica.
O monitoramento foi feito no
Zabbix . Em poucas palavras, por que - sorte e legado. O resto:
Longa história.Tudo começou com a instalação do monitoramento em um computador sob a mesa ...
Quando cheguei ao trabalho da empresa em 2013, não tínhamos monitoramento de rede, embora a rede, na época, era grande, cerca de 4000 objetos. Aprendemos sobre quedas maciças (e não muito) com maior frequência com o recebimento de aplicativos, usuários ou outros departamentos, semelhantes a avalanches.
O primeiro foi instalado o Zabbix 1.8, como um produto que ganha impulso (moda, moderno, juventude), leve e acessível para instalar código-fonte aberto em uma grande comunidade. Nós tivemos sorte com a escolha.
Não havia recursos para instalação, ninguém solicitou. Não estava claro se isso funcionaria; ninguém tinha experiência em implementação. Mas precisávamos e o instalamos no computador "embaixo da mesa". Nível de redundância - UPS.
A principal questão após a instalação é como despejar todos os objetos (4k!) No monitoramento e, ao mesmo tempo, gerenciar aplicativos que já estão travados no Remedy. O Zabbix já suportava importação / exportação de xml com dados em hosts. O número de objetos é grande, não havia sentido em criar um grupo separado para o objeto (e ele não aparecia) e foi decidido fazer o upload do roteador de objetos como um nó de rede. Mais equipamentos de rede não foram controlados (já gerenciados).
A análise do nosso arquivo com hosts de rede (IPAM no Excel) foi concluída e foi reformatada para xml, que o Zabbix concorda em digerir. Não foi a primeira vez, mas todos os hosts foram carregados, a atualização foi realizada a cada três meses, removendo os objetos fechados e adicionando novos. Com o tempo, o Zabbix se tornou a principal e única fonte de informações para nós e a linha direta sobre a disponibilidade de instalações e, mais importante, sobre quedas de massa. Isso permitiu à linha direta aprender sobre acidentes de massa mesmo à noite e despertar os engenheiros com ligações (a propósito, quando ninguém sabia disso, era mais fácil viver). Nem sempre as quedas de energia noturnas no escritório permitiam ao no-break manter adequadamente o monitoramento de nossa rede. Em algum momento, começamos
a fazer backups. Porque Como o monitoramento era instável e intermitente, as empresas decidiram organizar um grupo dedicado apenas a essa tarefa. Logo, ela começou a implementar um Zabbix centralizado, que verifica não apenas a rede.
Nosso velho Zabbix continuou a viver debaixo da mesa. Depois de adicionar um certo número de itens, o banco de dados começou a ficar um pouco mais lento, a web, a fila e o atraso na pesquisa aumentaram; logo, tive que pegar mais dois computadores como proxy e colocá-los todos na cruz, para que a reserva real (e o local embaixo da mesa acabasse) . A vida útil foi suportada para adicionar rapidamente algum tipo de parâmetro personalizado ao monitoramento e observá-lo. Quanto ao resto, passamos para uma centralizada.
O monitoramento centralizado era responsável por todos os equipamentos de TI - roteadores, servidores, caixas registradoras, terminais. Depois de um tempo, ele cresceu com um grande número de itens. Para acessar informações valiosas de acessibilidade, você precisava esperar um pouco, talvez até tomar um café. Além disso, tínhamos mais e mais requisitos para monitoramento de rede mais específico e personalizado. Tendo naquela época alguma experiência em trabalhar com o sistema, decidimos fazer a implementação antiga do zero, mas com razão - sob o nome zabbix.noc.x5.ru Ele estava localizado no data center com a implementação das funções necessárias por nós mesmos. Sobre esta introdução e o corpo principal do artigo.
A versão do Zabbix é 3.0
LTS . Atualizado apenas nas versões LTS.
Configuração - 4 máquinas virtuais: Servidor + Banco de Dados, Proxy, Proxy, Web
Por recursos, tentamos seguir as recomendações no
zabbix.com para uma implementação grande e muito grande.
O primeiro problema que nos confrontou foi a adição automática de nós da rede ao monitoramento. A descoberta regular desapareceu imediatamente. Nossa gama de redes está em todos os espaços abertos da super-rede 10/8. Muitos endereços precisariam ser pesquisados e a descoberta automática consumiria muitos recursos do sistema, mas não resolveria o problema de adicionar informações não técnicas sobre um objeto.
Como adicionar objetos
A solução foi usar scripts externos para adicionar objetos. Os dados mestre dos objetos comerciais foram encontrados no SAP usado na empresa. O acesso sincronizado ao
serviço da web para o upload de dados diretamente do SAP não saiu, a solicitação para todos os objetos levou um bom tempo. Efetuou uma chamada assíncrona. Exatamente à meia-noite, a exportação completa do SAP é adicionada ao ftp na forma de
XML e, durante o dia, os
XMLs com diffs das últimas versões caem sobre ele.
O Zabbix usou a
API do
Zabbix para carregar dados e interagiu com ele a partir do
Python .
No primeiro estágio, o conjunto de dados que precisávamos para criar o objeto foi determinado. Utilizamos todos os sinais obtidos para a classificação correta de um objeto no sistema ou para maior comodidade. Esses sinais incluem:
- Endereço IP - o campo mais importante para criar uma interface de monitoramento
- SAP ID - temos um identificador de objeto exclusivo
- Status - aberto / fechado
- Nome - o nome ou o número do objeto, geralmente usado pelos usuários ao entrar em contato
- Localização - endereço físico
- Telefone - telefone de contato
- Grupos - este grupo de grupos é formado com base no tipo e localização do objeto
Módulo Sap-sync.py
XML da SAP<?xml version="1.0" encoding="ISO-8859-1"?> <werks> <WERKS>1234</WERKS> <NAME1>4321-</NAME1> <PLANT_IP>192.168.1.50</PLANT_IP> <REGION>31</REGION> <PSTLZ>308580</PSTLZ> <CITY1>.</CITY1> <CITY2> .</CITY2> <STREET> .</STREET> <HOUSE_NUM1>1</HOUSE_NUM1> <TEL_NUMBER>(999)777-77-77</TEL_NUMBER> <BRANCH>CH</BRANCH> <REGION>CH_MSK</REGION> <REGION_NAME> </REGION_NAME> <FORMAT>CH_MSK_D</FORMAT> <STATUS> </STATUS> </werks>
O principal objetivo deste módulo é a análise de
XML e a tradução
JSON para a API do Zabbix. É muito conveniente, neste caso, usar dicionários Python, como não é necessário formatá-los adicionalmente - usando o módulo
zabbix.api ,
você pode simplesmente
fornecer a ele um dicionário com a estrutura correta.
JSON com a estrutura se parece com isso:
{ 'host': 'Hostname' 'groups': [...] 'interfaces': [{},{},{}] 'inventory': {} 'templates': [{},{},{}] 'inventory_mode': '1' 'proxy_hostid': 'INT' 'status': '0' } [] - {} -
Em nosso campo com o endereço IP no SAP, o endereço do servidor é armazenado, não o roteador, mas, usando o módulo
ipaddress , consideramos o primeiro endereço de sub-rede, que no nosso caso é sempre um roteador.
str(ipaddress.ip_interface('%s/%s'%(di['PLANT_IP'].strip(),24)).network[1])
A data da última atualização bem-sucedida é registrada no
Inventory . Em situações controversas, ajuda a entender a relevância das informações no sistema.
Então é muito conveniente analisar as estatísticas da data da atualização nos dados do inventário:
O campo mais importante -
STATUS ,
"aberto" - é adicionado e começa a ser monitorado, qualquer outro status - desativa o host. Não excluímos objetos para preservar dados e estatísticas históricos.
Após os testes, tive que adicionar a função ping para verificar se o host está acessível antes da adição inicial, porque na prática, começaram a aparecer os status
"abertos" , que ainda não estão totalmente abertos, mas quase.
def ping(ip): if os.system('ping -c 2 -W 1 %s > /dev/null'%ip) == 0: return True else: return False
Anteriormente, a API do Zabbix tinha uma função
host.exist , mas em novas versões era combinada com
host.get . Se o nó existir, a solicitação retornará
hostid no banco de dados zabbix. Se não encontrado, retorna 0. Para verificação, agora eu tinha que adicionar
existhost , mas na verdade é
host.get .
Finalmente, coletamos informações sobre o trabalho realizado, adicionamos aos logs, relatórios e movemos o arquivo processado para o repositório no OLD.
Em geral, a base de monitoramento está pronta, execute o script no cron para execução automática e esqueça-o.
Como preencher inventário
Não somos mais nós, somos networkers.O segundo estágio é preencher objetos com dados que os engenheiros precisam para trabalhar. É necessário ver todos os dados para resolver o incidente em um sistema, para não percorrer sistemas diferentes, coletando informações em partes de diferentes fontes. E como os principais dados técnicos estão no monitoramento, também atraímos o restante para o monitoramento.
Para coletar e transmitir as informações necessárias, o Zabbix escreveu o
inventário.py , que é amplamente envolvido na coleta de dados
SNMP dos equipamentos e, em menor grau, na análise do arquivo do Excel.
A pergunta começa - por que não usar os
itens incorporados e inserir o resultado no
inventário usando as ferramentas do próprio Zabbix? Existem três respostas:
- Aninhamento insuficiente de ações, como geralmente é necessário extrair o valor pelo SNMP e usar o resultado na próxima consulta.
- A execução de uma coleta de dados uma vez por dia em todos os nós com um script externo não carrega a atividade principal de monitoramento e não há fila para o item'am
- Existem dados que não podem ser coletados via SNMP
Os dados dos provedores, dos quais os engenheiros de primeira e segunda linhas não podem prescindir, são armazenados em um arquivo do Excel em uma unidade de rede compartilhada e atualizados pelos gerentes que realizam contratos de comunicação. A integração com o arquivo causou grandes dúvidas - a análise do Excel, preenchida manualmente, que pode alterar a estrutura, o nome, o local etc., provavelmente gerará erros constantemente. Mas, devido à falta de outra fonte relevante desses dados, eu tive que usá-los. Para, de alguma forma, nos protegermos da constante edição do roteiro, concordamos com os gerentes sobre a estrutura e o preenchimento correto, explicamos como a descarga automática será realizada e que é importante observar a estrutura atual. Na prática, é claro, ocorreram erros, mas nós os rastreamos rapidamente, amaldiçoamos, mas os corrigimos.
BGP-AS-BASE.cfg3216:Beeline
9002:Retn
2854:Orange
~omit~
8359:MTS
O
arquivo BGP-AS-BASE.cfg representa a correspondência do número do
AS e do nome do provedor. É necessário determinar o provedor com o qual o
BGP está instalado (de repente, há um erro no arquivo com contratos). A base externa não foi utilizada, pois Existem muitos números
AS privados.
Em termos de
SNMP :
- solicitamos das sub-redes do roteador pelo OID 1.3.6.1.2.1.4.20.1.1 e das máscaras de sub-rede pelo OID 1.3.6.1.2.1.4.20.1.3 em uma solicitação. Nós processamos, convertemos para xxxx / xx e escrevemos na célula host_networks .
- Quando solicitamos dados nos endereços IP dos pares BGP , bem como em seu ASN , encontramos o nome do provedor por número no banco de dados que criamos. Nós os escrevemos nos campos host_router e host_netmask . É importante definir imediatamente um limite de 38 caracteres, pois esses campos não suportam mais. Nossos nomes de campo no banco de dados nem sempre coincidem com os dados que eles armazenam, porque usou os campos existentes no banco de dados do Zabbix, para não mexer na criação de novos campos na tabela. Os nomes de campo corretos foram corrigidos na WEB, não houve confusão.
- carregamos dados do fornecedor, modelo e equipamento de software. Parsim, escreva para as variáveis. O design associado à escrita do modelo do hardware deve-se ao fato de que, para alguns modelos, a Cisco tem um nome escrito em um OID diferente (geralmente para o chassi), então tive que fazer uma verificação de dados adicional.
Todo o bloco associado ao SNMP é incluído no
try-except , para que, se não houver SNMP no equipamento, o script não caia e, pelo menos, obtivemos dados do Excel pelos fornecedores. Para entender qual parte do script foi concluída e qual não é,
anotamos o sucesso do bloco SNMP no campo
date_hw_expiry , além da data da última vez em que removemos todos os dados do SNMP e a data da última vez em que encontramos os dados no arquivo do Excel.
Tudo isso volta na forma de
JSON pronto para o Zabbix.
A atualização de todos os dados do inventário é iniciada uma vez por dia, descarregando todos os hosts e iniciando o
inventário.py para cada objeto.
O multiprocessamento é usado (um exemplo é obtido das vastas extensões da Internet). Para pesquisar, usamos o
ID SAP , que temos no nome do host. A saída resultante é escrita
atualização 'ohm no Zabbix.
Sumário
Para a implementação de toda a integração, atualização automática e atualização dos mecanismos internos, a API do Zabbix é mais que suficiente. As principais funções usadas são
host.get ,
host.create e
host.update , que juntos permitem controlar totalmente a criação e atualização do banco de dados de objetos de monitoramento. Os dados de entrada dessas funções podem ser enviados de quaisquer sistemas e fontes disponíveis.
Os principais módulos python que nos ajudaram a lidar com esta tarefa:
pysnmp ,
xlrd ,
zabbix.api ,
xml ,
ipaddress ,
json .
xlrd - analisando o excel.
xml - análise de XML.
pysnmp -
extrai dados SNMP do equipamento.
A interação SNMP é mais fácil que o SSH, pelo menos porque, na prática, a peça de hardware responde mais rapidamente ao SNMP do que ao SSH, analisar as respostas SNMP é praticamente desnecessário, embora as CLIs de diferentes fornecedores geralmente sejam muito diferentes umas das outras e as conclusões sejam as mesmas as equipes podem diferir mesmo em modelos diferentes do mesmo fornecedor.
Os principais
OIDs aplicados:
iso.3.6.1.2.1.4.20.1.1 - endereços de todas as interfaces do roteador
iso.3.6.1.2.1.4.20.1.3 - máscaras de sub-rede de todas as interfaces do roteador
iso.3.6.1.2.1.15.3.1.7 - todos os pares de BGP do roteador
iso.3.6.1.2.1.15.3.1.9 - AS de todos os pares de BGP do roteador
iso.3.6.1.2.1.47.1.1.1.1.13.1 - modelo
iso.3.6.1.2.1.47.1.1.1.1.10.1 - versão curta do software
iso.3.6.1.2.1.47.1.1.1.1.1.12.1 - fornecedor
iso.3.6.1.2.1.1.1.0 - versão detalhada do software
iso.3.6.1.2.1.47.1.1.1.1.7.1 - modelo, tipo de chassi
O painel teve que ser adicionado um pouco para dividir os problemas nas redes de distribuição e não interferir com eles em um monte. Adicione também vários campos, por exemplo, ip, nome e endereço do provedor, para que, em caso de acidente em massa, seja suficiente copiar e colar do navegador na mensagem todos os objetos com problema, imediatamente com todos os dados necessários para o provedor.
O "Workview" foi escrito
separadamente , no qual podemos encontrar todas as informações coletadas, além dos gráficos coletados para esse objeto.
