Commit 377a2b91ba705965d2949796fc9e60ce068c65ed
1 parent
042f0e16
Exists in
master
Update Funcionamento agente.md
Showing
1 changed file
with
21 additions
and
20 deletions
Show diff stats
docs/Funcionamento agente.md
| 1 | -Atualmente o agente cacic funciona a partir de um serviço do windows, que assim que é iniciado realiza algumas verificações de diretório e consistência dos módulos e inicia o módulo principal, o cacic280, que, quando executado, realiza a chamada do módulo gercols com o parâmetro getConfigs para pegar as configurações do gerente, em seguida o chama de novo para a coleta. A coleta de hardware, assim como IP, nome do computador e etc, é realizada por WMI e a de software por meio dos registros do windows (regedit). | |
| 1 | + Atualmente o agente cacic funciona a partir de um serviço do windows, que assim que é iniciado realiza algumas verificações de diretório e consistência dos módulos e inicia o módulo principal, o cacic280, que, quando executado, realiza a chamada do módulo gercols com o parâmetro getConfigs para pegar as configurações do gerente, em seguida o chama de novo para a coleta. A coleta de hardware, assim como IP, nome do computador e etc, é realizada por WMI e a de software por meio dos registros do windows (regedit). | |
| 2 | 2 | |
| 3 | -Durante a pesquisa realizada do OCSInventory, notei que há muito que possamos melhorar, tanto em coleta quanto em desempenho. | |
| 3 | + Durante a pesquisa realizada do OCSInventory, notei que há muito que possamos melhorar, tanto em coleta quanto em desempenho. | |
| 4 | 4 | |
| 5 | -A principal mudança que vi foi na coleta, pois além do WMI, podemos fazer também pelo registro. Isso reduz a margem de erros durante a coleta. Além disso, a coleta pode ser feita de forma bem mais organizada. | |
| 5 | + A principal mudança que vi foi na coleta, pois além do WMI, podemos fazer também pelo registro. Isso reduz a margem de erros durante a coleta. Além disso, a coleta pode ser feita de forma bem mais organizada. | |
| 6 | 6 | |
| 7 | -Então, esse agente basicamente virá para melhorar, obviamente. A princípio pensei em algo bem parecido na teoria: | |
| 7 | + Então, esse agente basicamente virá para melhorar, obviamente. A princípio pensei em algo bem parecido na teoria: | |
| 8 | 8 | |
| 9 | 9 | #**O início de tudo, Instalador:** |
| 10 | -* O Instalador para Windows acredito que a melhor maneira seria fazer um MSI. Reduz a chance de conflito com firewall e etc, ficando também mais amigável pro usuário, já que a maioria dos instaladores são parecidos. | |
| 11 | -* Tentei pensar em algo menos trabalhoso, pois quando instalado por meio do netlogon pode complicar pra instalar na rede, como já presenciamos na PGFN, e também atrasar o login do usuário, então pensei nos seguintes procedimentos: | |
| 12 | -1. No windows: Para rodar no netlogon deverá ser passado como parâmetro o servidor para autenticação e o '/silent' pra rodar em segundo plano. Caso não seja netlogon, o usuário irá digitar o servidor em uma das telas de diálogo; | |
| 13 | -2. O instalador realiza o getTest; | |
| 14 | -3. Se positivo, cria a árvore de diretórios e faz download do módulo principal e a biblioteca de comunicação (dll ou so); | |
| 15 | -4. Cria o serviço para o módulo e o inicia. | |
| 10 | + O Instalador para Windows acredito que a melhor maneira seria fazer um MSI. Reduz a chance de conflito com firewall e etc, ficando também mais amigável pro usuário, já que a maioria dos instaladores são parecidos. | |
| 11 | +Tentei pensar em algo menos trabalhoso, pois quando instalado por meio do netlogon pode complicar pra instalar na rede, como já presenciamos na PGFN, e também atrasar o login do usuário, então pensei nos seguintes procedimentos: | |
| 12 | + * No windows: Para rodar no netlogon deverá ser passado como parâmetro o servidor para autenticação e o '/silent' pra rodar em segundo plano. Caso não seja netlogon, o usuário irá digitar o servidor em uma das telas de diálogo; | |
| 13 | + * O instalador realiza o getTest; | |
| 14 | + * Se positivo, cria a árvore de diretórios e faz download do módulo principal e a biblioteca de comunicação (dll ou so); | |
| 15 | + * Cria o serviço para o módulo e o inicia. | |
| 16 | 16 | |
| 17 | 17 | #**O módulo principal.** |
| 18 | -* Após a instalação, o módulo principal seria iniciado, coletando as informações de configuração (getConfig) e baixando os módulos necessários, que seriam as .dll (windows) ou .so(linux), para realizar a coleta depois; | |
| 19 | -* Faz a verificação das bibliotecas; | |
| 20 | -* Inicializa a biblioteca para realizar a coleta que será enviada a princípio pelo mesmo formato de XML do antigo (mas será modificado em uma nova release para json ou algo parecido); | |
| 18 | + * Após a instalação, o módulo principal seria iniciado, coletando as informações de configuração (getConfig) e baixando as bibliotecas necessárias, que seriam as .dll (windows) ou .so(linux), para realizar a coleta depois; | |
| 19 | + * Faz a verificação das bibliotecas; | |
| 20 | + * Inicializa a biblioteca e realiza a coleta; | |
| 21 | + * Se for a primeira coleta ou existir diferença entre a coleta atual e a antiga, os dados serão enviados ao gerente a princípio pelo mesmo formato de XML do antigo (mas será modificado em uma nova release para json ou algo parecido); | |
| 21 | 22 | |
| 22 | -##*O loop...* | |
| 23 | -* Acho que na instalação poderia ser setado um tempo de espera randomico entre 3 e 6 horas, pra não ficar muito demorado e, também, pra não fazer todos rodarem ao mesmo tempo e congestionar o gerente. | |
| 24 | -* No loop seria realizado: | |
| 23 | +##*A coleta* | |
| 24 | + Na instalação poderia ser setado um horário randomico entre 8 e 18 horas pra realizar a coleta diária e, também, pra não fazer todos rodarem ao mesmo tempo e congestionar o gerente. Caso o computador não esteja logado no horário estabelecido, a coleta será feita assim que for ligado. | |
| 25 | +Nessa "rotina diária" seria realizado: | |
| 25 | 26 | |
| 26 | -1. O procedimento de checagem das bibliotecas e etc, pra caso alguma esteja faltando ser realizado o download de novo; | |
| 27 | -2. O getConfig; | |
| 28 | -3. As coletas; | |
| 27 | + * O procedimento de checagem das bibliotecas e etc, pra caso alguma esteja faltando ser realizado o download de novo; | |
| 28 | + * O getConfig; | |
| 29 | + * As coletas; | |
| 29 | 30 | |
| 30 | 31 | ##*Força Coleta* |
| 31 | -* Aqui vem minha maior dúvida, estava pensando em algum tipo de sincronia em tempo real. Estou dando uma pesquisada ainda, mas isso demandaria uma atualização também no gerente. Então a princípio ficaria o mesmo, seria realizado por meio do getTest de 5 em 5 minutos. | |
| 32 | + Aqui vem minha maior dúvida, estava pensando em algum tipo de sincronia em tempo real. Estou dando uma pesquisada ainda, mas isso demandaria uma atualização também no gerente. Então a princípio ficaria o mesmo, seria realizado por meio do getTest de 5 em 5 minutos. Se houver alguma atualização, é realizado o getConfig e em seguida o procedimento solicitado, como forçar coleta ou executar o mapa. | ... | ... |