quinta-feira, 17 de novembro de 2011

Oracle - Configurando Oracle Standby Physical Database no Linux

Os passos abaixo servem para criar uma database Standby Physical no Linux


Considerações:

- Testando no Oracle 11gR2;
- Homologado na distribuição RHEL 5.5 x64;
- Database: orcl ;
- Database em ARCHIVEMODE ;
- Comunicação entre o Master e Standby deve estar configurada, seja no hosts do Linux, seja por DNS, e importante por TNSNAMES ;

1 - Criando o usuário de replicação no master:

$ set ORACLE_SID=orcl
$ sqlplus /nolog
SQL > CONNECT / AS SYSDBA
SQL > CREATE USER STANDBY
IDENTIFIED BY password
DEFAULT TABLESPACE USERS
TEMPORARY TABLESPACE TEMP;
SQL > GRANT CONNECT TO STANDBY;
SQL > GRANT RESOURCE TO STANDBY;
SQL > GRANT DBA TO STANDBY;
SQL > ALTER USER STANDBY ACCOUNT UNLOCK;
SQL > DISCONNECT

2 - Alterar parâmetros de destino dos archives no master:

$ sqlplus /nolog
SQL > ALTER SYSTEM SET LOG_ARCHIVE_DEST_1='LOCATION=/data/archive_log/arc1' SCOPE=SPFILE;
SQL > ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='LOCATION=/data/archive_log/arc2' SCOPE=SPFILE;

* Os comandos abaixo geram indisponibilidade:
SQL > SHUTDOWN NORMAL
SQL > STARTUP OPEN
SQL > DISCONNECT

3 - Testando a conta de replicação:

$ sqlplus /nolog
SQL > CONNECT standby/password
SQL > ALTER SYSTEM SWITCH LOGFILE;

system altered.

SQL > DISCONNECT

* Verifique se os archives foram gravados nas pastas setadas como 'LOCATION' no passo 2.

4 - Criando o controlfile do Oracle Physical Standby Database:

$sqlplus /nolog
SQL > CONNECT / AS SYSDBA
SQL > ALTER DATABASE CREATE STANDBY CONTROLFILE AS ‘/data/archive_log\CTLSTB01.ORA’;

5 - Criando o PFILE do Oracle Physical Standby Database:

SQL > CREATE PFILE='/data/archive_log/PFILENFE.ORA' FROM SPFILE;

6 - Realizar as cópias dos datafiles para o '/dados/archive_log':


* Os comandos abaixo geram indisponibilidade:
SQL > SHUTDOWN NORMAL
SQL > DISCONNECT
* Faça a cópia fria via S.O.


7 - Copie os datafiles do Master para o standby(o caminho utilizado no PFILE), password file também. Aloque o controfile criado para o Standby via SCP ou como achar melhor.

8 - Alocar corretamente datafiles no Oracle Standby(idem ao Master).

9 - Iniciar Oracle Standby Physical Standby:

* Se não sabe como criar uma instância podes criar uma database com o mesmo nome da Master e baixá-la depois.

$ set ORACLE_SID=orcl
$ sqlplus /nolog
SQL> CONNECT / AS SYSDBA
SQL> STARTUP NOMOUNT PFILE='/data/archive_log\PFILE.ORA';

10 - Criar SPFILE no Oracle Standby Physical Standby:

SQL > CREATE SPFILE FROM PFILE='/data/archive_log/PFILE.ORA';

* Após não precisará mais do PFILE.

11 - Mountar a database em modo Standby:

SQL > ALTER DATABASE MOUNT STANDBY DATABASE;

SQL > RECOVER AUTOMATIC STANDBY DATABASE;

 * Caso dê algum erro aqui acesse o Master e gere um novo archive conforme passo 3.

12 - Verificar se o Standby está consumindo archives:

* Execute o seguinte comando no Master e no Standby: 

SELECT SEQUENCE#, APPLIED FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;
ou 
SELECT MAX(sequence#) FROM v$log_history;

O valor deve ser o mesmo, isto significa que a database Standby está consumindo os archives. Se der a diferença de um, basta gerar um novo archive no Master e realizar o procedimento de recovery no Standby.

13 - Automatizar a importação de archives:

* Agende um job no Crontab do Linux no Standby de tempo em tempo, o job deve ter o seguinte conteúdo:


- REPLICA.sh -


#!/bin/bash
# Script to sinc Master and Standby Oracle 


source /oracle/.bash_profile # (Aqui deve ter o LD_LIBRARY_PATH, SID, HOME)
sqlplus standby/password@MASTER <<EOS
ALTER SYSTEM SWITCH LOGFILE;
EOS
sqlplus sys/ as sysdba<<EOS
SHUTDOWN IMMEDIATE
STARTUP NOMOUNT
ALTER DATABASE MOUNT STANDBY DATABASE;
RECOVER AUTOMATIC STANDBY DATABASE;
exit
EOS
# EOF



*** Não esqueça de criar uma outra rotina que apague os archives antigos já consumidos pelo Standby.

terça-feira, 27 de setembro de 2011

GroundWork - Criar gráficos de performance para um AIC


Criar gráficos de performance


    Os procedimentos abaixo são destinados a criação de gráficos de performance dos AICs*. 

    AICs: Atributo de Item de Configuração -> Nada mais é que um serviço do Nagios, exemplo monitoramento do disco C de um host(IC). 
    ICs: Item de Configuração -> Nada mais é que um host do Nagios, exemplo monitoramento de um servidor. 

    Onde se aplica? 

    O GroundWork OpenSource Community Edition(GWOS) não cria por padrão gráficos de performance para os AICs adicionados. Para gerar novos gráficos é necessário um conhecimento básico da solução RRDTool que é utilizada no MTRG. 

    Explicando um pouco mais, imagine que você adicionou no host(IC) 'TESTE' o serviço(AIC) 'IC-Availability', ao acessar a guia 'Status' do Groundwork e selecionar o AIC alvo mencionado anteriormente, não poderá visualizar um histórico de valores obtidos nas checagens caso este gráfico de performance não esteja configurado corretamente. Dai a importância deste 'how-to', possibilitar isso ao cliente, o acompanhamento dos valores coletados para que com eles o cliente possa basear implementações e adição de recursos. 



    Requisitos:

    1. O AIC que adicionará o gráfico do RRDTool deve gerar perfdata;
    2. Noções administrativas de Nagios(core do GroundWork);
    3. Ser provido de cérebro; 

    Verificações:

    O AIC que quero criar o gráfico gera perfdata? 

    Teste executando uma checagem, seja via GroundWork(GWOS), ou através da console mesmo:

    GroundWork(GWOS):

    Console: 

    Perfdata: Toda informação que é enviada na execução da checagem após o pipe, logo no exemplo acima o perfdata é:
    rta=0.938ms;3000.000;5000.000;0; pl=0%;80;100;;

    Onde 'rta' e 'pl' são as duas métricas, sendo 'response time average' e 'packet loss'.
    O 'rta' é obtido em milissegundos(ms) e o 'pl' em porcentagem(%).
    0.938 é o valor em 'ms' obtido na checagem.
    0% é o valor em '%' obtido na checagem.
    3000.000 é o threshold(limite) de alerta para que o 'rta' seja considerado como WARNING ao Nagios(GWOS).
    5000.000 é o threshold(limite) de alerta para que o 'rta' seja considerado como CRITICAL ao Nagios(GWOS).
    0 é o valor mínimo na plotagem do gráfico do RRDTool. 

    Com as afirmações abaixo consideramos que o perfdata é composto por uma ou mais métricas, as quais possuem a seguinte sintaxe:
    [métrica]={valor obtido};{threshold para WARNING};{threshold para CRITICAL};{valor mínimo plotado no gráfico};{valor máximo plotado no gráfico}

    E se meu AIC não gera perfdata? 
    Existe uma função no GroundWork(GWOS) que é capaz de realizar expressão regular(REGEX) no status do AIC, ou seja, tudo que vem antes do pipe, em nosso exemplo seria: OK - 192.168.20.13: rta 0.938ms, lost 0%

    Vamos a configuração do Gráfico de Performance, no GroundWork acesse 'Configuration -> Performance' e clique em 'Create New Entry'.

    Serão apresentadas as opções para a criação de um novo gráfico, então explicando cada opção:

    Graph Label - Título do gráfico, para nosso exemplo 'ICMP Ping Response Time'
    Service - Nome do Serviço, para nosso exemplo 'IC-Availability'
    Use Service as a Regular Expression - Opção para utilizar o perfdata do AIC
    Host - IC aos quais o gráfico se aplicará, para aplicar para todos os ICs que possuam este AIC utilize *
    Status Text Parsing Regular Expression - Se utilizado o perfdata para coleta dos dados não preencha este campo, ele se aplica somente se seu AIC não gera perfdata, neste caso coloque sua REGEX ai
    Use Status Text Parsing instead of Performance Data - Marque essa opção para AICs sem perfdata
    RRD Name - O arquivo que será gravado no disco do Groundwork(GWOS), utilize '/usr/local/groundwork/rrd/$HOST$_$SERVICE$.rrd' 
    RRD Create Command - Este campo é para a criação do gráfico, caso não entenda as informações que serão inseridas neste campo procure conhecer um pouco mais de RRDTool, para nosso exemplo utilizaremos o seguinte:
    $RRDTOOL$ create $RRDNAME$ --step 300 --start n-1yr DS:rta:GAUGE:1800:U:U DS:pl:GAUGE:1800:U:U RRA:AVERAGE:0.5:1:8640 RRA:AVERAGE:0.5:12:9480
    RRD Update Command - Este campo é para o comando que o RRDTool utilizará para atualizar o gráfico, para nosso exemplo utilizaremos:
    $RRDTOOL$ update $RRDNAME$ $LASTCHECK$:$VALUE1$:$VALUE2$ 2>&1
    Custom RRDtool Graph Command - Este campo é para customização de cores e saídas do gráfico caso o perfdata não seja exatamente o que você quer mostrar, utilizaremos para nosso exemplo o seguinte:
    'rrdtool graph - --imgformat=PNG --title="ICMP Performance" --rigid --base=1000 --height=120 --width=700 --alt-autoscale-max --lower-limit=0 --vertical-label="Time and Percent" --slope-mode DEF:a="rrd_source":ds_source_1:AVERAGE DEF:b="rrd_source":ds_source_0:AVERAGE CDEF:cdefa=b CDEF:cdefb=a,100,/ AREA:cdefa#43C6DB:"Response Time (ms) " GPRINT:cdefa:LAST:"Current\:%8.2lf %s" GPRINT:cdefa:AVERAGE:"Average\:%8.2lf %s" GPRINT:cdefa:MAX:"Maximum\:%8.2lf %s\n" LINE1:cdefb#307D7E:"Percent Loss " GPRINT:cdefb:LAST:"Current\:%8.2lf %s" GPRINT:cdefb:AVERAGE:"Average\:%8.2lf %s" GPRINT:cdefb:MAX:"Maximum\:%8.2lf %s"'
    Enable - Para habilitar o gráfico deixe o checkbox marcado

    Após salve o gráfico e realize um 'Commit' na guia 'Control' do GroundWork(GWOS). Pronto, seu gráfico se estiver correto dentro de 4 checagens do seu AIC será criado e já poderá visualizá-lo. 

    segunda-feira, 26 de setembro de 2011

    JBoss - Usando o JConsole e JVisualM no JBoss

    Este post será útil para os que querem monitorar e invocar métodos através do JConsole ou JVisualM remotamente.

    Importante:

    - Utilizada instância 'all';
    - IP de bind do JBoss 192.168.56.101;

    Configurações necessárias no 'run.conf' da instância do JBoss:

    1 - Adicione a linha abaixo:

    JAVA_OPTS="$JAVA_OPTS -Djava.rmi.server.hostname=$IP_DO_JBOSS -Dcom.sun.management.config.file=/opt/jboss-epp-5.1/jboss-as/server/all/conf/management/management.properties -Dcom.sun.management.jmxremote -Djboss.platform.mbeanserver -Djavax.management.builder.initial=org.jboss.system.server.jmx.MBeanServerBuilderImpl"


    2 - Substitua o IP_DO_JBOSS pelo IP que o JBoss realiza o bind, e também path do arquivo de configuração do JMX.

    Ficaria assim um arquivo de configuração:

    ---


    if [ "x$JAVA_OPTS" = "x" ]; then


       JAVA_OPTS="-Xms512m -Xmx512m -XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Dsun.lang.ClassLoader.allowArraySyntax=true"


       # Gerenciamento JConsole
       JAVA_OPTS="$JAVA_OPTS -Djava.rmi.server.hostname=192.168.56.101 -Dcom.sun.management.config.file=/opt/jboss-epp-5.1/jboss-as/server/all/conf/management/management.properties -Dcom.sun.management.jmxremote -Djboss.platform.mbeanserver -Djavax.management.builder.initial=org.jboss.system.server.jmx.MBeanServerBuilderImpl"

    fi

    ---

    3 - Agora copie o conteúdo da pasta 'management' do seu JDK para o JBoss:

    $ mkdir /opt/jboss-epp-5.1/jboss-as/server/all/conf/management/
    $ cp /opt/jdk1.6.0_23/jre/lib/management/* /opt/jboss-epp-5.1/jboss-as/server/all/conf/management/

    4 - Edite o arquivo '/opt/jboss-epp-5.1/jboss-as/server/all/conf/management/jmxremote.access' deixando da seguinte forma:

    ######################################################################
    #     Default Access Control File for Remote JMX(TM) Monitoring
    ######################################################################
    #
    # Access control file for Remote JMX API access to monitoring.
    # This file defines the allowed access for different roles.  The
    # password file (jmxremote.password by default) defines the roles and their
    # passwords.  To be functional, a role must have an entry in
    # both the password and the access files.
    #
    # The default location of this file is $JRE/lib/management/jmxremote.access
    # You can specify an alternate location by specifying a property in
    # the management config file $JRE/lib/management/management.properties
    # (See that file for details)
    #
    # The file format for password and access files is syntactically the same
    # as the Properties file format.  The syntax is described in the Javadoc
    # for java.util.Properties.load.
    # A typical access file has multiple lines, where each line is blank,
    # a comment (like this one), or an access control entry.
    #
    # An access control entry consists of a role name, and an
    # associated access level.  The role name is any string that does not
    # itself contain spaces or tabs.  It corresponds to an entry in the
    # password file (jmxremote.password).  The access level is one of the
    # following:
    #       "readonly" grants access to read attributes of MBeans.
    #                   For monitoring, this means that a remote client in this
    #                   role can read measurements but cannot perform any action
    #                   that changes the environment of the running program.
    #       "readwrite" grants access to read and write attributes of MBeans,
    #                   to invoke operations on them, and optionally
    #                   to create or remove them. This access should be granted
    #                   only to trusted clients, since they can potentially
    #                   interfere with the smooth operation of a running program.
    #
    # The "readwrite" access level can optionally be followed by the "create" and/or
    # "unregister" keywords.  The "unregister" keyword grants access to unregister
    # (delete) MBeans.  The "create" keyword grants access to create MBeans of a
    # particular class or of any class matching a particular pattern.  Access
    # should only be granted to create MBeans of known and trusted classes.
    #
    # For example, the following entry would grant readwrite access
    # to "controlRole", as well as access to create MBeans of the class
    # javax.management.monitor.CounterMonitor and to unregister any MBean:
    #  controlRole readwrite \
    #              create javax.management.monitor.CounterMonitorMBean \
    #              unregister
    # or equivalently:
    #  controlRole readwrite unregister create javax.management.monitor.CounterMBean
    #
    # The following entry would grant readwrite access as well as access to create
    # MBeans of any class in the packages javax.management.monitor and
    # javax.management.timer:
    #  controlRole readwrite \
    #              create javax.management.monitor.*,javax.management.timer.* \
    #              unregister
    #
    # The \ character is defined in the Properties file syntax to allow continuation
    # lines as shown here.  A * in a class pattern matches a sequence of characters
    # other than dot (.), so javax.management.monitor.* matches
    # javax.management.monitor.CounterMonitor but not
    # javax.management.monitor.foo.Bar.
    #
    # A given role should have at most one entry in this file.  If a role
    # has no entry, it has no access.
    # If multiple entries are found for the same role name, then the last
    # access entry is used.
    #
    #
    # Default access control entries:
    # o The "monitorRole" role has readonly access.
    # o The "controlRole" role has readwrite access and can create the standard
    #   Timer and Monitor MBeans defined by the JMX API.

    #monitorRole   readonly
    #controlRole   readwrite \
    #              create javax.management.monitor.*,javax.management.timer.* \
    #              unregister

    admin   readwrite

    5 - Altere o arquivo '/opt/jboss-epp-5.1/jboss-as/server/all/conf/management/jmxremote.password.template' para '/opt/jboss-epp-5.1/jboss-as/server/all/conf/management/jmxremote.password' e edite o arquivo deixando-o da seguinte forma:

    # ----------------------------------------------------------------------
    #           Template for jmxremote.password
    #
    # o Copy this template to jmxremote.password
    # o Set the user/password entries in jmxremote.password
    # o Change the permission of jmxremote.password to read-only
    #   by the owner.
    #
    # See below for the location of jmxremote.password file.
    # ----------------------------------------------------------------------

    ##############################################################
    #        Password File for Remote JMX Monitoring
    ##############################################################
    #
    # Password file for Remote JMX API access to monitoring.  This
    # file defines the different roles and their passwords.  The access
    # control file (jmxremote.access by default) defines the allowed
    # access for each role.  To be functional, a role must have an entry
    # in both the password and the access files.
    #
    # Default location of this file is $JRE/lib/management/jmxremote.password
    # You can specify an alternate location by specifying a property in
    # the management config file $JRE/lib/management/management.properties
    # or by specifying a system property (See that file for details).


    ##############################################################
    #    File permissions of the jmxremote.password file
    ##############################################################
    #      Since there are cleartext passwords stored in this file,
    #      this file must be readable by ONLY the owner,
    #      otherwise the program will exit with an error.
    #
    # The file format for password and access files is syntactically the same
    # as the Properties file format.  The syntax is described in the Javadoc
    # for java.util.Properties.load.
    # Typical password file has multiple  lines, where each line is blank,
    # a comment (like this one), or a password entry.
    #
    #
    # A password entry consists of a role name and an associated
    # password.  The role name is any string that does not itself contain
    # spaces or tabs.  The password is again any string that does not
    # contain spaces or tabs.  Note that passwords appear in the clear in
    # this file, so it is a good idea not to use valuable passwords.
    #
    # A given role should have at most one entry in this file.  If a role
    # has no entry, it has no access.
    # If multiple entries are found for the same role name, then the last one
    # is used.
    #
    # In a typical installation, this file can be read by anybody on the
    # local machine, and possibly by people on other machines.
    # For # security, you should either restrict the access to this file,
    # or specify another, less accessible file in the management config file
    # as described above.
    #
    # Following are two commented-out entries.  The "measureRole" role has
    # password "QED".  The "controlRole" role has password "R&D".
    #
    # monitorRole  QED
    # controlRole   R&D
      admin teste123

    Onde "admin" é o usuário do access e "teste123" será a senha de acesso deste usuário. 

    6 - Edite o arquivo '/opt/jboss-epp-5.1/jboss-as/server/all/conf/management/management.properties' e deixe-o da seguinte forma:

    #####################################################################
    #       Default Configuration File for Java Platform Management
    #####################################################################
    #
    # The Management Configuration file (in java.util.Properties format)
    # will be read if one of the following system properties is set:
    #    -Dcom.sun.management.jmxremote.port=<port-number>
    # or -Dcom.sun.management.snmp.port=<port-number>
    # or -Dcom.sun.management.config.file=<this-file>
    #
    # The default Management Configuration file is:
    #
    #       $JRE/lib/management/management.properties
    #
    # Another location for the Management Configuration File can be specified
    # by the following property on the Java command line:
    #
    #    -Dcom.sun.management.config.file=<this-file>
    #
    # If -Dcom.sun.management.config.file=<this-file> is set, the port
    # number for the management agent can be specified in the config file
    # using the following lines:
    #
    # ################ Management Agent Port #########################
    #
    # For setting the JMX RMI agent port use the following line
    com.sun.management.jmxremote.port=21123
    #
    # For setting the SNMP agent port use the following line
    # com.sun.management.snmp.port=<port-number>

    #####################################################################
    #                   Optional Instrumentation
    #####################################################################
    #
    # By default only the basic instrumentation with low overhead is on.
    # The following properties allow to selectively turn on optional
    # instrumentation which are off by default and may have some
    # additional overhead.
    #
    # com.sun.management.enableThreadContentionMonitoring
    #
    #      This option enables thread contention monitoring if the
    #      Java virtual machine supports such instrumentation.
    #      Refer to the specification for the java.lang.management.ThreadMBean
    #      interface - see isThreadContentionMonitoringSupported() method.
    #

    # To enable thread contention monitoring, uncomment the following line
    # com.sun.management.enableThreadContentionMonitoring

    #####################################################################
    #                       SNMP Management Properties
    #####################################################################
    #
    # If the system property -Dcom.sun.management.snmp.port=<port-number>
    # is set then
    #       - The SNMP agent (with the Java virtual machine MIB) is started
    #         that listens on the specified port for incoming SNMP requests.
    #       - the following properties for read for SNMP management.
    #
    # The configuration can be specified only at startup time.
    # Later changes to the above system property (e.g. via setProperty method), this
    # config file, or the ACL file has no effect to the running SNMP agent.
    #

    #
    # ##################### SNMP Trap Port #########################
    #
    # com.sun.management.snmp.trap=<trap-destination-port-number>
    #      Specifies the remote port number at which managers are expected
    #      to listen for trap. For each host defined in the ACL file,
    #      the SNMP agent will send traps at <host>:<trap-destination-port-number>
    #      Default for this property is 162.
    #

    # To set port for sending traps to a different port use the following line
    # com.sun.management.snmp.trap=<trap-destination-port-number>

    #
    # ################ SNMP listen interface #########################
    #
    # com.sun.management.snmp.interface=<InetAddress>
    #      Specifies the local interface on which the SNMP agent will bind.
    #      This is useful when running on machines which have several
    #      interfaces defined. It makes it possible to listen to a specific
    #      subnet accessible through that interface.
    #      Default for this property is "localhost".
    #
    #      The format of the value for that property is any string accepted
    #      by java.net.InetAddress.getByName(String).
    #

    # For restricting the port on which SNMP agent listens use the following line
    # com.sun.management.snmp.interface=<InetAddress>

    #
    # #################### SNMP ACL file #########################
    #
    # com.sun.management.snmp.acl=true|false
    #      Default for this property is true. (Case for true/false ignored)
    #      If this property is specified as false then the ACL file
    #      is not checked:  all manager hosts are allowed all access.
    #

    # For SNMP without checking ACL file uncomment the following line
    # com.sun.management.snmp.acl=false

    #
    # com.sun.management.snmp.acl.file=filepath
    #      Specifies location for ACL file
    #      This is optional - default location is
    #      $JRE/lib/management/snmp.acl
    #
    #      If the property "com.sun.management.snmp.acl" is set to false,
    #      then this property and the ACL file are ignored.
    #      Otherwise the ACL file must exist and be in the valid format.
    #      If the ACL file is empty or non existent then no access is allowed.
    #
    #      The SNMP agent will read the ACL file at startup time.
    #      Modification to the ACL file has no effect to any running SNMP
    #      agents which read that ACL file at startup.
    #

    # For a non-default acl file location use the following line
    # com.sun.management.snmp.acl.file=filepath

    #####################################################################
    #                       RMI Management Properties
    #####################################################################
    #
    # If system property -Dcom.sun.management.jmxremote.port=<port-number>
    # is set then
    #     - A MBean server is started
    #     - JRE Platform MBeans are registered in the MBean server
    #     - RMI connector is published  in a private readonly registry at
    #       specified port using a well known name, "jmxrmi"
    #     - the following properties are read for JMX remote management.
    #
    # The configuration can be specified only at startup time.
    # Later changes to above system property (e.g. via setProperty method),
    # this config file, the password file, or the access file have no effect to the
    # running MBean server, the connector, or the registry.
    #

    #
    # ########## RMI connector settings for local management ##########
    #
    # com.sun.management.jmxremote.local.only=true|false
    #      Default for this property is true. (Case for true/false ignored)
    #      If this property is specified as true then the local JMX RMI connector
    #      server will only accept connection requests from clients running on
    #      the host where the out-of-the-box JMX management agent is running.
    #      In order to ensure backwards compatibility this property could be
    #      set to false. However, deploying the local management agent in this
    #      way is discouraged because the local JMX RMI connector server will
    #      accept connection requests from any client either local or remote.
    #      For remote management the remote JMX RMI connector server should
    #      be used instead with authentication and SSL/TLS encryption enabled.
    #

    # For allowing the local management agent accept local
    # and remote connection requests use the following line
    com.sun.management.jmxremote.local.only=false

    #
    # ###################### RMI SSL #############################
    #
    # com.sun.management.jmxremote.ssl=true|false
    #      Default for this property is true. (Case for true/false ignored)
    #      If this property is specified as false then SSL is not used.
    #

    # For RMI monitoring without SSL use the following line
    com.sun.management.jmxremote.ssl=false

    # com.sun.management.jmxremote.ssl.config.file=filepath
    #      Specifies the location of the SSL configuration file. A properties
    #      file can be used to supply the keystore and truststore location and
    #      password settings thus avoiding to pass them as cleartext in the
    #      command-line.
    #
    #      The current implementation of the out-of-the-box management agent will
    #      look up and use the properties specified below to configure the SSL
    #      keystore and truststore, if present:
    #          javax.net.ssl.keyStore=<keystore-location>
    #          javax.net.ssl.keyStorePassword=<keystore-password>
    #          javax.net.ssl.trustStore=<truststore-location>
    #          javax.net.ssl.trustStorePassword=<truststore-password>
    #      Any other properties in the file will be ignored. This will allow us
    #      to extend the property set in the future if required by the default
    #      SSL implementation.
    #
    #      If the property "com.sun.management.jmxremote.ssl" is set to false,
    #      then this property is ignored.
    #

    # For supplying the keystore settings in a file use the following line
    # com.sun.management.jmxremote.ssl.config.file=filepath

    # com.sun.management.jmxremote.ssl.enabled.cipher.suites=<cipher-suites>
    #      The value of this property is a string that is a comma-separated list
    #      of SSL/TLS cipher suites to enable. This property can be specified in
    #      conjunction with the previous property "com.sun.management.jmxremote.ssl"
    #      in order to control which particular SSL/TLS cipher suites are enabled
    #      for use by accepted connections. If this property is not specified then
    #      the SSL/TLS RMI Server Socket Factory uses the SSL/TLS cipher suites that
    #      are enabled by default.
    #

    # com.sun.management.jmxremote.ssl.enabled.protocols=<protocol-versions>
    #      The value of this property is a string that is a comma-separated list
    #      of SSL/TLS protocol versions to enable. This property can be specified in
    #      conjunction with the previous property "com.sun.management.jmxremote.ssl"
    #      in order to control which particular SSL/TLS protocol versions are
    #      enabled for use by accepted connections. If this property is not
    #      specified then the SSL/TLS RMI Server Socket Factory uses the SSL/TLS
    #      protocol versions that are enabled by default.
    #

    # com.sun.management.jmxremote.ssl.need.client.auth=true|false
    #      Default for this property is false. (Case for true/false ignored)
    #      If this property is specified as true in conjunction with the previous
    #      property "com.sun.management.jmxremote.ssl" then the SSL/TLS RMI Server
    #      Socket Factory will require client authentication.
    #

    # For RMI monitoring with SSL client authentication use the following line
    com.sun.management.jmxremote.ssl.need.client.auth=false

    # com.sun.management.jmxremote.registry.ssl=true|false
    #      Default for this property is false. (Case for true/false ignored)
    #      If this property is specified as true then the RMI registry used
    #      to bind the RMIServer remote object is protected with SSL/TLS
    #      RMI Socket Factories that can be configured with the properties:
    #          com.sun.management.jmxremote.ssl.config.file
    #          com.sun.management.jmxremote.ssl.enabled.cipher.suites
    #          com.sun.management.jmxremote.ssl.enabled.protocols
    #          com.sun.management.jmxremote.ssl.need.client.auth
    #      If the two properties below are true at the same time, i.e.
    #          com.sun.management.jmxremote.ssl=true
    #          com.sun.management.jmxremote.registry.ssl=true
    #      then the RMIServer remote object and the RMI registry are
    #      both exported with the same SSL/TLS RMI Socket Factories.
    #

    # For using an SSL/TLS protected RMI registry use the following line
    com.sun.management.jmxremote.registry.ssl=false

    #
    # ################ RMI User authentication ################
    #
    # com.sun.management.jmxremote.authenticate=true|false
    #      Default for this property is true. (Case for true/false ignored)
    #      If this property is specified as false then no authentication is
    #      performed and all users are allowed all access.
    #

    # For RMI monitoring without any checking use the following line
    com.sun.management.jmxremote.authenticate=true

    #
    # ################ RMI Login configuration ###################
    #
    # com.sun.management.jmxremote.login.config=<config-name>
    #      Specifies the name of a JAAS login configuration entry to use when
    #      authenticating users of RMI monitoring.
    #
    #      Setting this property is optional - the default login configuration
    #      specifies a file-based authentication that uses the password file.
    #
    #      When using this property to override the default login configuration
    #      then the named configuration entry must be in a file that gets loaded
    #      by JAAS. In addition, the login module(s) specified in the configuration
    #      should use the name and/or password callbacks to acquire the user's
    #      credentials. See the NameCallback and PasswordCallback classes in the
    #      javax.security.auth.callback package for more details.
    #
    #      If the property "com.sun.management.jmxremote.authenticate" is set to
    #      false, then this property and the password & access files are ignored.
    #

    # For a non-default login configuration use the following line
    # com.sun.management.jmxremote.login.config=<config-name>

    #
    # ################ RMI Password file location ##################
    #
    # com.sun.management.jmxremote.password.file=filepath
    #      Specifies location for password file
    #      This is optional - default location is
    #      $JRE/lib/management/jmxremote.password
    #
    #      If the property "com.sun.management.jmxremote.authenticate" is set to
    #      false, then this property and the password & access files are ignored.
    #      Otherwise the password file must exist and be in the valid format.
    #      If the password file is empty or non-existent then no access is allowed.
    #

    # For a non-default password file location use the following line
    com.sun.management.jmxremote.password.file=/opt/jboss-epp-5.1/jboss-as/server/all/conf/management/jmxremote.password

    #
    # ################ RMI Access file location #####################
    #
    # com.sun.management.jmxremote.access.file=filepath
    #      Specifies location for access  file
    #      This is optional - default location is
    #      $JRE/lib/management/jmxremote.access
    #
    #      If the property "com.sun.management.jmxremote.authenticate" is set to
    #      false, then this property and the password & access files are ignored.
    #      Otherwise, the access file must exist and be in the valid format.
    #      If the access file is empty or non-existent then no access is allowed.
    #

    # For a non-default password file location use the following line
    com.sun.management.jmxremote.access.file=/opt/jboss-epp-5.1/jboss-as/server/all/conf/management/jmxremote.access


    Parâmetros importantes:
    com.sun.management.jmxremote.port=21123 - Porta do JMX 
    com.sun.management.jmxremote.local.only=false - Se responderá só locamente 
    com.sun.management.jmxremote.ssl=false - Se utilizará SSL(é indicado utilizar)
    com.sun.management.jmxremote.authenticate=true - Se o JMX utilizará autenticação
    com.sun.management.jmxremote.password.file=/opt/jboss-epp-5.1/jboss-as/server/all/conf/management/jmxremote.password - Arquivo de senhas
    com.sun.management.jmxremote.access.file=/opt/jboss-epp-5.1/jboss-as/server/all/conf/management/jmxremote.access - Arquivo de usuários

    7 - Crie o arquivo dentro de seu JDK para o Jstat '/opt/jdk1.6.0_23/jre/lib/security/tools.policy' e deixe-o da seguinte forma:

    grant {
      permission java.security.AllPermission;
    };

    8 - Execute o seguinte comando:

    $ /opt/jdk1.6.0_23/bin/jstatd -p 1099 -J-Djava.security.policy=tools.policy &

    9 - Agora poderá utilizando o JConsole ou JVisualM adicionar seu JBoss para monitoramento remoto:

    JConsole - hostname - No meu caso 192.168.56.101
                   - porta 21123

    JVisualM 
                 JMX - hostname 192.168.56.101 - porta 21123
                 Jstat - hostname 192.168.56.101 - porta 1099

    Em produção - Utilize no JMX SSL e no Jstat utilize grants mais restritivas, também pode limitar o acesso por IPTables.