System Center

Direcionamento granular no Operations Manager 2007

Steve Rachui

 

Visão geral:

  • Usando um destino existente
  • O problema da descoberta de atributos
  • Criando destinos com o Console de Criação
  • Descoberta baseada em script

Sumário

Usando um destino existente
Criando destinos com o Console de Criação
Usando uma chave do Registro
Valor do Registro
Descoberta via script
Considerações adicionais

Criar objetos personalizados de monitoramento (regras, monitores, grupos etc.) é uma parte normal da rotina de muitos administradores do System Center OpsMgr (Operations Manager) 2007. Para cada objeto criado, uma pergunta comum precisa ser respondida: "Que destino utilizar?"

Escolher o destino correto para um objeto é essencial, mas nem sempre a abordagem certa é evidente. O OpsMgr oferece várias opções de direcionamento. Este artigo analisará muitas delas, com o objetivo de ajudar os administradores a escolher o método adequado para cada cenário. Os termos "classe" e "destino" serão usados de forma intercambiável.

Suponhamos que você tenha um aplicativo interno chamado widget, que precisa ser monitorado. Todas as especificações de monitoramento foram definidas, e a tarefa de criar os objetos de monitoramento para widget já começou. No entanto, rapidamente você descobre que não há um destino preciso para widget! Segundo as práticas recomendadas do OpsMgr, todas as regras, monitores etc. devem ser direcionados ao objeto de maior especificidade possível, a fim de limitar o escopo da distribuição apenas aos sistemas relevantes. Que opções do OpsMgr podem ajudá-lo a cumprir essa meta das práticas recomendadas?

Usando um destino existente

Por padrão, o OpsMgr inclui uma lista extensa de destinos, e essa lista cresce à medida que mais pacotes de gerenciamento são importados. Quando estiver criando um novo MPO (objeto do pacote de gerenciamento) e avaliando o melhor destino, primeiro examine os itens disponíveis para ver se um dos destinos preexistentes é suficiente. Se estiver criando MPOs para estender o monitoramento de servidores do SMS (System Management Server), por exemplo, é provável que os destinos existentes, importados juntamente com o pacote de gerenciamento do servidor SMS padrão, possam ser reutilizados no seu MPO.

Contudo, o uso de destinos padrão nem sempre funciona. Se os destinos disponíveis não forem específicos o bastante para o MPO que está sendo criado, você poderá adotar uma solução alternativa para a ausência de um destino ideal ou criar um novo destino.

Uma abordagem comum (embora apresente algumas desvantagens) é associar o novo MPO à classe do cliente ou do servidor Windows, ou então a qualquer outra classe base adequada que inclua os destinos necessários (mais uma vez, seja o mais específico possível). Ao fazer isso, certifique-se de criar o MPO em um estado desabilitado. Depois, você poderá criar um grupo contendo todos os sistemas onde esses MPOs precisam ser executados e substituir os MPOs desabilitados, de forma que o MPO seja habilitado somente para os agentes no grupo. Isso permite que o MPO seja entregue e executado somente nos agentes permitidos pela substituição.

Quais são as desvantagens dessa abordagem? Em primeiro lugar, o uso desse método se direciona à classe mais ampla de objetos (Windows Computer, por exemplo), para que todos os MPOs monitorados direcionados dessa forma apareçam sob o objeto de destino no Gerenciador de Integridade (veja a Figura 1).

fig01.gif

Figura 1. Gerenciador de Integridade de computador direcionado por substituição (clique na imagem para ampliá-la)

Na verdade, isso é apenas superficial. Então, talvez não seja um problema em determinados ambientes. Mas esse tipo de direcionamento faz com que o estado de integridade do objeto pai (como Windows Computer) seja afetado quando houver impacto sobre o monitor personalizado. Então, se o aplicativo widget tiver um problema, a integridade de todo o objeto de destino poderá ser afetada. Dependendo do que estiver sendo monitorado, isso terá ou não importância.

Em geral, direcionar MPOs para grupos não é uma abordagem adequada no OpsMgr — então, por que funciona? Lembre-se de que os grupos destes exemplos são usados como substituições, e não são o destino real do MPO.

Talvez isso pareça semântica, mas pense nos grupos do OpsMgr. Grupos são objetos, assim como qualquer outro objeto. Quando um objeto é escolhido como destino, isso significa que o MPO em questão é implantado nos agentes proprietários do objeto de destino.

Então, qual é o agente proprietário do objeto de grupo? Isso mesmo: o RMS (Servidor de Gerenciamento Raiz). O direcionamento para um grupo fará com que os MPOs sejam entregues ao agente proprietário do grupo, ou seja, os MPOs serão implantados somente no RMS! Se os MPOs forem direcionados corretamente, tudo estará pronto para que sejam implantados nos agentes corretos. Mas, se você desabilitar o MPO, interromperá o processo antes que possa começar.

Quando uma substituição é introduzida, o destino existente continua a ser o destino. A substituição apenas altera o status desabilitado para habilitado em alguns agentes de cada associação a um grupo. Mas os agentes nos quais o MPO é habilitado já fazem parte do destino original do MPO. Sei que, à primeira vista, é um pouco confuso.

Agora, imagine um cenário onde nada do que foi discutido até agora seja viável. O que fazer? Resta apenas uma opção: criar um novo destino especificamente para os MPOs, o que pode ser feito usando o modelo de monitoramento de serviço no Console de Operações ou criando um novo destino no Console de Criação.

Contudo, antes de avaliar essas opções, que tal criar uma descoberta de atributo? Talvez você esteja pensando que essa é uma opção viável que foi deixada de lado. Vamos analisar a questão. É possível criar uma descoberta de atributo que obtenha informações do Registro ou do WMI. Para funcionar, a descoberta de atributo precisa ser direcionada a uma classe que contenha as entradas relevantes do Registro ou do WMI. Os destinos mais comuns são as classes do cliente ou do servidor Windows, ou mesmo a classe mais genérica Windows Computer.

Observe que o termo em si — descoberta de atributo — indica o que realmente acontece: um novo atributo é descoberto e usado para estender uma classe existente. É claro que, como resultado, uma nova classe é criada, mas na verdade é a mesma classe antiga, com os mesmos membros, somente com um novo atributo informado. Com base nisso, você percebe que criar uma nova descoberta de atributo não é o mesmo que criar um destino realmente exclusivo.

Que tal um exemplo? Suponha que uma nova descoberta de atributo seja criada para encontrar a chave do Registro do produto widget. Essa descoberta é direcionada implantação em Windows Computer, de forma a incluir todos os agentes que possam conter a chave do Registro de widget.

Depois de fazer essa escolha no assistente, você recebe o aviso de que a classe Windows Computer não pode ser estendida (afinal, está em um pacote de gerenciamento lacrado — se não estivesse, não haveria um aviso desse tipo), e uma classe de destino renomeada é apresentada como uma opção que você pode usar para prosseguir (veja a Figura 2). Isso ocorre porque o objetivo da descoberta de atributo é estender uma classe existente.

fig02.gif

Figura 2. A descoberta de atributo não cria uma classe exclusiva (clique na imagem para ampliá-la)

Vejamos agora os modelos de serviço, que podem ser usados para criar destinos exclusivos para sistemas localizáveis com base em um serviço instalado. Os modelos de serviço são muito fáceis de usar; a Figura 3 mostra um exemplo.

fig03.gif

Figura 3. Um modelo de serviço

Contudo, fique atento, pois o uso do modelo pode resultar na criação de MPOs adicionais não pretendidos ou indesejados. Depois de usar o modelo de serviço, é uma boa idéia verificar os objetos adicionais criados e determinar se devem ou não ser retidos (veja a Figura 4).

fig04.gif

Figura 4. Objetos criados quando um modelo é utilizado (clique na imagem para ampliá-la)

Além disso, os modelos de serviço criarão uma descoberta e uma nova classe para cada serviço. Isso pode ser exatamente o que você deseja ou granular demais. Suponha, por exemplo, que o seu aplicativo personalizado tenha vários serviços. Nesse caso, uma nova classe e um novo monitor de serviço serão criados para cada um deles! Provavelmente, a abordagem de monitoramento desejada seria ter uma única classe, com cada monitor de serviço direcionado somente àquela classe.

Se você não pode ou não quer utilizar um modelo de serviço, a única opção restante é usar o Console de Criação. Uma rápida análise da documentação do Console de Criação mostra que o uso adequado desse recurso exige uma discussão aprofundada — algo muito além do escopo deste artigo.

Contudo, cabem aqui alguns exemplos simples de uso do Console de Criação para criar e preencher um novo destino no OpsMgr. Apresentarei dois exemplos que reforçam a idéia de usar uma entrada do Registro para identificar com exclusividade o aplicativo widget, e um terceiro exemplo que demonstra a descoberta por script.

Criando destinos com o Console de Criação

Em muitos casos, é possível examinar o Registro em busca de uma chave ou de um valor específico que identifique com exclusividade os servidores relevantes, hosts do destino desejado. Se fosse possível criar e preencher uma classe (destino) com sistemas onde existisse a chave do Registro de widget, essa seria uma forma simples de criar um destino exclusivo.

Meu primeiro exemplo descreve como fazer isso simplesmente procurando uma chave do Registro existente. O segundo exemplo procura um valor específico associado à chave do Registro. Observe que, embora você possa criar uma regra de descoberta de atributo do Registro (como já foi discutido) e uma descoberta no Console de Criação, os dois não obtêm os mesmos resultados, conforme demonstram os exemplos a seguir. O primeiro simplesmente estende uma classe existente, e o segundo na verdade cria um novo destino.

Usando uma chave do Registro

Quando o Console de Criação é iniciado pela primeira vez, você precisa optar por carregar um pacote de gerenciamento existente ou criar um novo. Quando você decide criar um novo pacote de gerenciamento, um assistente aparece, permitindo selecionar um modelo de pacote de gerenciamento vazio ou de pacote de gerenciamento de Aplicativo do Windows (Registro) (veja a Figura 5).

fig05.gif

Figura 5. Escolhendo o modelo de um novo pacote de gerenciamento (clique na imagem para ampliá-la)

Qualquer um dos dois pode ser usado para obter os mesmos resultados, mas é fácil criar uma nova classe usando o modelo de Aplicativo do Windows (Registro). Você precisa apenas fornecer um nome e selecionar o modelo do Registro. Em seguida, precisa fornecer o nome e a descrição do pacote de gerenciamento na tela Nome e Descrição. O valor a ser inserido é o mesmo exibido sob o nó dos pacotes de gerenciamento, na interface do usuário do Operations Manager.

Depois, forneça uma descrição do aplicativo na tela Aplicativo do Windows. O valor inserido será exibido no nó Atributos da interface do usuário do Operations Manager. Em seguida, configure a freqüência na qual a descoberta deve ser executada. O padrão é a cada 15 segundos, provavelmente uma freqüência exagerada. Equilibre a necessidade de descoberta rápida com o possível impacto da descoberta muito freqüente sobre o desempenho. Em geral, não existe motivo relevante para que a descoberta seja executada mais do que uma vez por dia.

Agora, preencha os detalhes necessários para localizar a chave/valor do Registro no qual você tem interesse. Há vários tipos de atributos disponíveis; se você quiser apenas verificar a existência de uma chave, use o tipo Bool.

Por fim, compile a expressão de consulta. Talvez isso pareça trabalho duplicado — afinal, você não acaba de compilar a expressão de consulta? Na verdade, não. A tela Configuração de Investigação do Registro define a chave do Registro a ser procurada e como procurá-la. A tela Filtro de Expressões é usada para definir qual o valor esperado.

Depois de fazer tudo isso, o que exatamente você criou? Você alcançou o objetivo de criar uma nova classe? No Console de Criação, selecione o nó do modelo de serviço e clique nas classes. Observe que uma nova classe foi criada. Examine as propriedades para entender melhor essa nova classe.

E quanto à definição de descoberta? No modelo de integridade, observe a regra de descoberta. Examine também as propriedades para ver a real constituição da regra.

Valor do Registro

É igualmente fácil criar uma descoberta que procure um valor do Registro, em vez de uma chave. Use o assistente mais uma vez. Só que, agora, modifique a entrada para obter um valor do Registro, em vez de uma chave.

Para iniciar o assistente, após a conclusão do modelo inicial, navegue até Modelo de Integridade | Descobertas. No painel central, clique com o botão direito do mouse e selecione Novo | Registro (filtrado). As entradas serão as mesmas de antes, exceto pelo fato de que, desta vez, um valor do Registro será especificado.

É simples assim! Com os novos destinos criados, o exemplo termina aqui. Mas observe que ainda será necessário algum trabalho adicional para preencher o pacote de gerenciamento com os MPOs. Os MPOs podem ser criados com a interface do usuário do Operations Manager ou diretamente no Console de Criação — as duas formas funcionam bem.

No entanto, lembre-se de que, se você abrir no Console de Criação um MPO criado no Console de Operações, ele não terá o nome original atribuído por você. Em vez disso, o nome será substituído por uma cadeia de caracteres começando com UIGenerated. Embora isso não afete de forma alguma a função do MPO, pode ser frustrante, se você estiver tentando localizar um MPO específico no Console de Criação.

Independentemente do método escolhido, foi criada uma nova classe, que pode ser usada para a entrega de regras. Como saber se a classe e a descoberta novas funcionam? Você pode consultar as informações sobre o inventário descoberto da nova classe, e a nova classe também aparecerá como destino válido para um novo monitor (veja a Figura 6).

fig06.gif

Figura 6. A nova classe é destino válido para um monitor (clique na imagem para ampliá-la)

Descoberta via script

Para criar uma descoberta via script em um pacote de gerenciamento existente, carregue-o no Console de Criação. Se estiver começando do zero, abra o Console de Criação e escolha criar um novo pacote de gerenciamento.

Por tratar-se de uma descoberta baseada em script, a única opção aplicável é criar um pacote de gerenciamento em branco. A primeira etapa do processo consiste em definir a classe que será preenchida com o script, além das propriedades (atributos) relevantes da classe. FileName, FileDirectory e FileDescription são propriedades disponíveis definidas por essa classe que podem ser manipuladas no script, o que será demonstrado em breve.

Além disso, a propriedade DisplayName é herdada da classe System.Entity e também pode ser manipulada via script. Observe que somente atributos contidos nessa lista podem ser manipulados com o script de descoberta. Então, certifique-se de que os itens relevantes sejam exibidos nela. Observe também que, conforme cada propriedade (atributo) é selecionada, seus detalhes aparecem do lado direito. Preencha a entrada de Nome para Exibição de cada propriedade (atributo). Se essas entradas forem deixadas em branco, as informações serão retornadas, mas os cabeçalhos de colunas no ambiente do OpsMgr, como na exibição Inventário Descoberto, ficarão em branco.

Com a classe definida, você pode criar a descoberta baseada em script. Navegue até Modelo de Integridade | Descobertas. Clique com o botão direito do mouse, selecione Novo | Script e crie a Descoberta. Há muitas informações aí. Primeiro, a guia Geral permite nomear a descoberta e fornecer um destino onde ela deve ser executada. Lembre-se de ser o mais específico possível na definição do destino.

Para os objetivos deste artigo, faz sentido escolher Windows Computer. Na guia Tipos Descobertos, configure o tipo de objeto a ser descoberto. Observe que o nome do tipo descoberto corresponde ao nome da classe definido anteriormente.

Em seguida, vem a guia Configuração, que exibe informações geradas automaticamente quando o script é definido (selecione Configurar para ver o script e a hora agendada para sua execução). Observe também a caixa Parâmetros (que pode ser acessada selecionando Configurar | Script | Parâmetros). Preste atenção nos parâmetros listados. Voltarei a mencioná-los mais adiante neste artigo.

O script para conduzir o processo de coleta da descoberta e enviar os resultados para o OpsMgr é mostrado na Figura 7. É um script muito básico, mas fornece a estrutura para os elementos principais necessários ao funcionamento da descoberta baseada em script.

Figura 7. Script de descoberta

Option Explicit
Dim oArgs
Set oArgs = WScript.Arguments

Dim oAPI

  'All of the work to submit discovery data is done in the context of
  'API's defined in the OpsMgr 2007 SDK.  Creating the oAPI object allows
  'access to the OpsMgr 2007 scripting environment
Set oAPI = CreateObject("MOM.ScriptAPI")

Dim SourceId, ManagedEntityId, targetComputer

  ' SourceId is the GUID of the discovery object that runs the script.
SourceId = oArgs(0)

  ' ManagedEntityId is the GUID of the computer class that is targeted by the script.
ManagedEntityId = oArgs(1)

  ' targetComputer is the Fully Qualified Domain Name
  ' of the computer targeted by the script. The FQDN
  ' is in Arg(2) of the command prompt.
targetComputer = oArgs(2)

Dim oFSO, oDiscoveryData, oInst

  'This operation sets the stage for creating new discovery data.  Note that the
  'values passed to the CreateDiscoveryData function are variables that are defined
  'by the command line when executed.  The parameters box was displayed earler.  This
  'is where the command-line parameters required by the CreateDiscoveryData object are 
  'defined and passed to the script.
Set oDiscoveryData = oAPI.CreateDiscoveryData(0, SourceId, ManagedEntityId)

  'This section defines objects needed to access the file system environment
Set oFSO = CreateObject("Scripting.FileSystemObject") 
If (oFSO.FolderExists("C:\WServer")) Then 

    'Assuming a folder called WServer was found on the root of the C drive, the script proceeds to create a new
    'class instance.  Once it's created, a number of property (attribute) values are filled in; note that all 
    'three of the properties (attributes) defined on the class are used in the script along with one property
    '(attribute) from the windows computer class.  Note the difference in how the script refers to properties 
    '(attributes) defined in the local class vs. a class that is accessed by reference.  Also note the Name field
    'as defined in the script.  Here the name is a friendly name that easily maps back to a known class name.  
    ' When the management pack is saved and imported into the Operations Console and the script delivered to the
    ' agents, these name values will no longer be friendly, they will be converted to the appropriate class GUID.  
    'Normally these converted values wouldn't be seen, but if the script directly on the agent is examined, 
    'the difference will be seen. Note that if the script attempts to define/use a property (attribute) 
    'that has not been defined in the referenced class, validation errors will be displayed.
  Set oInst = oDiscoveryData.CreateClassInstance("$MPElement[Name='Widget.Application.Script.Discovery.WidgetAppClass']$")
  Call oInst.AddProperty("$MPElement[Name='Windows!Microsoft.Windows.Computer']/PrincipalName$", targetComputer)
  Call oInst.AddProperty("$MPElement[Name='Widget.Application.Script.Discovery.WidgetAppClass']_
    /FileName$", "TestFileName.exe")
  Call oInst.AddProperty("$MPElement[Name='Widget.Application.Script.Discovery.WidgetAppClass']_
    /FileDirectory$", "TestFileDirectory")
  Call oInst.AddProperty("$MPElement[Name='Widget.Application.Script.Discovery.WidgetAppClass']_
    /FileDescription$", "TestFileDescription.exe")

    'Class Instance has now been created so the AddInstance method of the CreateDiscoveryData class is used to add
    'the completed instance.  From there the script returns the discovery data to OpsMgr for further processing.
  Call oDiscoveryData.AddInstance(oInst)
  Call oAPI.Return(oDiscoveryData)
End If

A importação desse pacote de gerenciamento para o OpsMgr resulta na descoberta do sistema correto, conforme mostrado na Figura 8. Todas as propriedades (atributos) definidas no script são exibidas na interface do usuário com os valores associados.

fig08.gif

Figura 8. Descoberta via script (clique na imagem para ampliá-la)

Se observar o script, você verá que o valor de um item descoberto pode ser passado explicitamente ou por meio de uma variável. E lembre-se de que, conforme indicado anteriormente, se o campo Nome para Exibição da propriedade (atributo) específica na classe tiver sido deixado em branco, os cabeçalhos de colunas FileName, FileDirectory e FileDescription (veja a Figura 8) também estarão em branco.

Considerações adicionais

Mantenha o controle das versões Quando você trabalha no Console de Criação, é comum gerar várias revisões antes de terminar. É preciso verificar se cada revisão para uso no OpsMgr foi salva com um incremento no número da versão.

O número da versão é acessado no Console de Criação selecionando Arquivo | Propriedades do Pacote de Gerenciamento. Deixar de incrementar o número da versão pode resultar na importação de um novo pacote de gerenciamento, em sobreposição a um pacote existente com o mesmo número de versão. Isso pode gerar confusão durante a importação.

Com ou sem lacre? Quando o pacote de gerenciamento for concluído, você precisará decidir se ele deverá ser lacrado para fins de produção ou deixado sem lacre. Há vantagens em deixá-lo sem lacre, como a capacidade de armazenar substituições diretamente no pacote de gerenciamento. Mas existem motivos mais fortes para lacrar um pacote de gerenciamento personalizado antes de introduzi-lo no ambiente de produção:

  • Lacrar um pacote de gerenciamento personalizado para uso na produção é uma prática recomendada.
  • O lacre permite um controle mais rigoroso de versões e alterações.
  • O lacre permite o uso dos mesmos procedimentos operacionais para pacotes de gerenciamento personalizados e comerciais. A exigência de procedimentos diferentes — por exemplo, onde colocar as substituições dos pacotes de gerenciamento personalizados e comerciais — gera muita confusão.
  • As classes criadas em um pacote de gerenciamento sem lacre serão visíveis e poderão ser utilizadas somente por outros MPOs armazenados no mesmo pacote de gerenciamento. O lacre permite a utilização de objetos, independentemente de onde o MPO está armazenado.
  • É possível manter uma biblioteca de pacotes de gerenciamento "de origem" sem lacre, sob o controle dos administradores do OpsMgr, para impedir alterações acidentais ou indesejadas.

O total entendimento dos destinos é fundamental para o sucesso na utilização do OpsMgr. Um pôster chamado "Práticas recomendadas de direcionamento de regras e monitores" está disponível em formato .pdf em go.microsoft.com/fwlink/?LinkId=125048. Você descobrirá que é uma referência muito útil para entender diferentes destinos e quando seu uso pode ser adequado.

Steve Rachui é engenheiro de suporte dedicado no grupo de engenharia de campo de ponta da Microsoft. Ele presta suporte ao SMS desde a versão 1.2 e ao MOM, desde a versão 2000. Entre em contato com Steve pelo email steverac@microsoft.com.