Zope Alta Performance

Transcrição

1 Zope Alta Performance Jorge Krishna Resumo Este documento apresenta uma alternativa de topologia para obtenção performace de servidores Zope 2.7 em ambientes multi-processados. Tratase de nossa experiência prática com um servidor de páginas que resultou em um modelo escalável de ótimo desempenho. Apresentaremos as vantagens e as desvantagens decorrente do modelo uma vez que para a melhoria de desempenho algumas características tiveram que ser alteradas na forma original de utilização do produto. Creative Commons versão brasileira 1

2 Sumário 1 Sobre este HOWTO Introdução O que é Python Zope Problemática Integração Python & Zope Cache Experimentação Forma padrão Modelo de várias instâncias Balanceamento de Carga Conclusão 8 3 Anexos conf: Apache VirtualHost conf: Zope conf: ZEO Client conf: ZEO Bibliograa 25 2

3 1 Sobre este HOWTO 1.1 Introdução Para compreendermos melhor este artigo e a proposta, iniciamos com a explicação do que é python e zope. Assim agregamos informações de base para o conhecimento coletivo sobre esse assunto O que é Python Python é uma linguagem fácil e agradável de ser utilizada. Foi elaborada por Guido Van Rossum em 1991 para o ensino de programação. Ela é orientada a objetos sem lhe forçar a programar desta maneira. É intuitiva e quem aprende uma vez, nunca se esquece pois é muito próxima de um pseudo-código. Ela não ca no seu caminho na hora de programar, formada por grandes comunidades 1 e é amplamente utilizada nos meios acadêmico, software livre, pesquisa (Google, NASA), jogos (Disney) dentre outros. Contém uma vasta biblioteca de funcionalidades incluídas que consiste de implementações diversas, chegando até ao manuseio de conexões HTTP seguras, processamento de XML e HTML, bancos de dados e muito mais. Com módulos extras para coisas mais especícas como engines de jogos e processamento de imagens. Possui módulos para chamadas entre-processos com RPC, RPC-XML e outros, incluindo até o RMI Zope Criado em 1996 pelo americano Jim Fulton na Digital Creations (DC), USA. Jim Fulton, o CTO da Digital Creations e Python guru, foi ensinar uma turma de programadores CGI, que não sabiam muito sobre Python e orientação a objeto. Comentou a turma o que ele considerava sobre os tradicionais ambiente de programação CGI: eles são fracos, falta orientação à objetos, e expõe detalhes dos servidores Web. A partir dessa reexão inicial, o coração do Zope foi escrito com base no plano de aulas daquela turma. O DevGuide do Zope, dene o Zope como um framework Open Source para aplicações Web: Um ambiente para o desenvolvimento e gerenciamento de aplicações Web. Interpretador de códigos ZPT, DTML, Python. Todas as páginas em um servidor Zope são geradas dinamicamente. 1.2 Problemática É reconhecido pela comunidade de usuários do Zope que este produto embora apresentando vantagens em suas funcionalidades, não apresenta Exclusivo para implementações com Jython, pois é necessário uma máquina virtual Java 3

4 na conguração padrão bom desempenho para sites que exigem desempenho com elevadas taxas de consulta. Para desenvolver os ajustes de performace e otimização, primeiro é necessário entender a arquitetura de composição e funcionamento do Zope. 1.3 Integração Python & Zope O que poucas pessoas explicam, como ocorre a integração do Zope como(s) sistema(s) operacional(ais) e outros programas? Como sabemos, o Zope foi desenvolvido em Python cujo interpretador de python é nativo/compilado para diversas plataformas (Linux, Windows,MacOs, etc). É por este motivo que o Zope herda e se benifícia desta portabilidade. A visibilidade do Zope sobre o sistema operacional é restrita as APIs do python e ao próprio python, assim tornando o servidor de aplicação mais seguro. Figura 1: Arquitetura Python & Zope A problemática começa aqui, ou seja, não basta fazermos ajustes no servidor Zope, é importante tornar o seu interpretador mais poderoso. Os recursos mais comuns quando precisamos de mais poder de processamento são: multi-thread e multicpu. O python nasceu com multi-thread, porém não com multi-cpu. Isto tem um preço quando a performace é requisito. Na prática quando executamos o Zope, zope.conf padrão, vericamos que é criado 4 threads sob o controle de um único processo python, controlado pelo Global interpreter lock ou GIL Em um ambiente multi-cpu 4

5 o GIL restringe a cada thread utilizar a mesma área de memória Zope/python, não tirando proveito do multi-processamento. Figura 2: Intel - Hyper-Threading Technology O lock usado pelo Python assegurar que somente uma thread pode ser executada em um dado momento. Isto simplica o gerenciamento de theads do Python, assegurando que nenhum dos dois processos possam acessar o mesmo endereço de memória ao mesmo tempo. O que justica restringir o intérpretador para tornar o ambiente multi-threads, contudo não deixa de utilizar o paralelismo de máquinas com multi-processadores. Na história do python tentou-se desenvolver um "free-thread", porém a performace em ambiente uni-processo foi muito baixa. 1.4 Cache Outro ponto importante é a velocidade com que o usuário navega no site, ou seja, qual a taxa de download da página? Em um site estático isso pode ser resolvido fazendo simples caches das imagens e dos textos pelo próprio servidor Web (ex.: Apache ou por um proxy reverso (ex.: SquidSquid Quando lidamos com conteúdo dinâmico, ou seja, constantemente atualizado, o cache é renovado em períodos mais curtos. O objetivo é consumir a menor carga de processamento com a melhor velocidade possível. Para isso funcionar temos que evitar ao máximo os acessos direto ao servidor de aplicação (Zope) e tornar distribuição do conteúdo via cache o mais eciênte possível, com o menor consumo de processamento. 1.5 Experimentação A arquitetura modular do Zope permite inúmeras congurações para obter a melhor performace. 1.6 Forma padrão A aplicação deste estudo foi realizada em um ambiente multi-processador, com a estimativa de 20 milhões de acessos mês de visitantes. O equipamento utilizado é um IBM xserver 4 Xeon HT, 4G ram, 2x36G HD SCSI e o sistema operacional Debian Woody GNU/Linux Kernel SMP version A sigla HT signica que neste caso o sistema operacional SMP irá identicar 2x 5

6 Figura 3: Arquitetura do Zope o número de processadores HT, ou seja, 2x4=8 processadores Xeon. Este é um ambiente multi-processador com 8 processadores. Inicialmente conguramos o zope (2.7.0) na sua forma padrão, 4 threads, sistema de armazenamento com o ZODB e depois alteramos para: armazenamento em Berkley DB alteração do zope.conf para 8 threads Realizamos varios experimentos utilizando o programa AB (Apache HTTP server benchmarking tool) para avaliação de tempos de respostas e consumo de processamento. Neste momento percebemos claramente que o uso geral dos processadores foi resumido a um só processador. Quando nos deparamos com o problema pela primeira vez, percebemos então que o Zope nunca rodava em mais do que um processador, cou claro que o efeito do GIL (Global Interpreter Lock) compromete a utilização dos processadores em um ambiente multiprocessado. Este efeito passou a ser o calcanhar de Aquiles para a escalabilidade do servidor. Como usar os outros processadores? Esta foi a questão que fez acreditarmos que o modelo de arquitetura com a implementação do ZEO (Zope Enterprise Objects) fosse a resposta. 6

7 1.7 Modelo de várias instâncias Montamos um novo cenário com um ZEO, 8 Zopes Clients e um Servidor Web Apache para rotacionar os acessos entre os Zope clients. Porquê 8 Zopes? Simples um para cada processador. A nova conguração foi alterada para 4 threads 8 instâncias Zope 1 instância ZEO com Berkley DB Figura 4: Arquitetura do Zope Apache2 com mod_rewrite, mod_proxy, mod_deate e mod_cache A implementação do Apache2 com mod_cache foi fundamental para aumentar o número de acessos diretos ao site Balanceamento de Carga O Balanceamento de Carga - Load Balance promove o aumento de performance através da distribuição da carga de forma balanceada. Distribui o tráfego das chamadas fazendo com que as diferentes máquinas Zope Client que compõe o cluster funcionem como uma única. Mantém o tempo de resposta das requisições e oferece escalabilidade de serviços e recursos, ou seja, à medida em que houver aumento de demanda (novas aplicações, maior número de usuários conectados), mais máquinas 3 podem ser incorporadas ao modelo, multiplicando assim o seu poder de resposta. 3Neste caso pode ser máquina física ou virtual 7

8 RewriteEngine On lb - variável dinâmica rnd - organiza o acesso randomico e retorna um só valor lista.txt - contém uma lista com "dynamic " RewriteMap lb rnd:/etc/apache2/lista.txt RewriteCond %{REQUEST_URI} ^/.* RewriteRule ^/(.+)$ 1}/\ VirtualHostBase/http/ [P,L] No entanto, chama-se atenção para o fato de que o este modelo está implementando um load sharing e não um load balance, ou seja, congurando o Apache com o recurso de RewriteMap juntamente com o parametro rnd 4, irá compartilhar os acessos entre os diferentes Zope Clients sem levar em conta nenhum critério de balanceamento de carga ou performance dos servidores em si. 2 Conclusão Para uma aplicação, site com muitos acessos onde há necessidade de processamento é natural em grandes empresas investir em equipamentos que proporcione os resultados desejados. O custo de equipamentos com a tecnologia Hyper-Threading da Intel é relativamente mais baixo que equipamentos com N processadores. No estilo For Dumms o HT sicamente corresponde a um só processador, contudo quando observamos a visão de um sistema operacional SMP (Symmetric multi-processing support) percebemos a apreseça de dois processadores lógicos. Com a preocupação de saber quantos processadores estão sendo utlizados durante os teste, descobrimos um programa chamado slmon, A realização dos teste foram feitos Durante os experimentos 4RND é responsável pela leitura sequencial da lista numerada do endereço de rede do Zope Client 8

9 3 Anexos 3.1 conf: Apache VirtualHost <VirtualHost :80> ServerAdmin ServerName DocumentRoot /var/www/ <Directory /> Options FollowSymLinks AllowOverride None </Directory> <Directory /var/www/> Options Indexes FollowSymLinks MultiViews AllowOverride None Order allow,deny allow from all </Directory> ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/ <Directory "/usr/lib/cgi-bin"> AllowOverride None Options ExecCGI -MultiViews +SymLinksIfOwnerMatch Order allow,deny Allow from all </Directory> ErrorLog /var/log/apache2/error.log Possible values include: debug, info, notice, warn, error, crit, alert, emerg. LogLevel warn CustomLog /var/log/apache2/access.log combined ServerSignature Off Alias /icons/ "/usr/share/apache2/icons/" <Directory "/usr/share/apache2/icons"> Options Indexes MultiViews AllowOverride None Order allow,deny Allow from all </Directory> Alias /doc/ "/usr/share/doc/" RedirectMatch ^/doc/apache2-doc/manual(.*)$ /manual$1 <Directory "/usr/share/doc/"> Options Indexes MultiViews FollowSymLinks AllowOverride None Order deny,allow Deny from all Allow from / ::1/128 </Directory> Compressao de HTTP <IfModule mod_deflate.c> SetOutputFilter DEFLATE DeflateFilterNote ratio LogFormat '"%r" = (%{ratio}n) ' deflate CustomLog /var/log/apache2/deflate.log deflate AddOutputFilterByType DEFLATE text/html text/plain 9

10 </IfModule> Proxy e ReWrite ProxyRequests Off ProxyReceiveBufferSize RewriteEngine On RewriteMap lb rnd:/etc/apache2/lista.txt RewriteCond %{REQUEST_URI} ^/.* RewriteRule ^/(.+)$ 1}/\ VirtualHostBase/http/ [P,L] </VirtualHost> 3.2 conf: Zope Welcome to Zope 2. This is the Zope configuration file. The Zope configuration file shows what the default configuration directives are, and show examples for each directive. To declare a directive, make sure that you add it to a line that does not begin with ''. Note that comments are only allowed at the beginning of a line: you may not add comments after directive text on the same line. ZConfig "defines" used for later textual substitution %define INSTANCE /var/lib/zope/instance/default %define ZOPE /usr/lib/zope %define ZOPECLIENT default Directive: instancehome Description: The path to the data files, local product files, import directory, and Extensions directory used by Zope. Required (no default) Example: instancehome /home/chrism/projects/sessions instancehome $INSTANCE Directive: clienthome Description: The directory in which a running Zope's process identifier files are placed. Default: $INSTANCE/var Example: clienthome /home/chrism/projects/sessions/var 10

11 Directive: path Description: Name of a directory which should be inserted into the the beginning of Python's module search path. This directive may be specified as many times as needed to insert additional directories. The set of directories specified is inserted into the beginning of the module search path in the order which they are specified here. Note that the processing of this directive may happen too late under some circumstances; it is recommended that you use the PYTHONPATH environment variable if using this directive doesn't work for you. Default: $INSTANCE/lib/python Example: path $INSTANCE/mypymodules Directive: products Description: Name of a directory that contains additional Product packages. This directive may be used as many times as needed to add additional collections of products. Each directory identified will be added to the path of the Products package. All Products are initialized in ascending alphabetical order by product name. If two products with the same name exist in two Products directories, the order in which the packages appear here defines the load order. The master Products directory exists in Zope's software home, and cannot be removed from the products path (and should not be added to it here). Default: $INSTANCE/Products Example: products /home/chrism/projects/myproducts Directive: environment Description: A section which can be used to define arbitrary key-value pairs for use as environment variables during Zope's run cycle. It is not recommended to set system-related environment variables such as PYTHONPATH within this section. Default: unset Example: <environment> MY_PRODUCT_ENVVAR foobar </environment> Directive: debug-mode Description: A switch which controls several aspects of Zope operation useful for developing under Zope. When debug mode is on: - The process will not detach from the controlling terminal - Errors in product initialization will cause startup to fail (instead of writing error messages to the event log file). 11

12 - Filesystem-based scripts such as skins, PageTemplateFiles, and DTMLFiles can be edited while the server is running and the server will detect these changes in real time. When this switch is off, you must restart the server to see the changes. Setting this to 'off' when Zope is in a production environment is encouraged, as it speeds execution (sometimes dramatically). Default: on Example: debug-mode on Directive: effective-user Description: If you intend to run Zope as the "root" user, you must supply this directive with an effective username or userid number to which Zope will 'suid' after the server ports are bound. This directive only has effect under UNIX and if Zope is started as the root user. Default: unset Example: effective-user zope Directive: enable-product-installation Description: If this directive is turned on, Zope performs 'product installation' (the registration of Python modules in various Products directories) at startup. Turning this off can speed Zope/ZEO startup time, but it can also cause your Control_Panel Product list to become desynchronized with the contents of your Products directories. NOTE: Zope *must* be started at least once with this directive set to "on" or you will receive an error. If using ZEO, at least one ZEO client must be run with this directive set to "on" once, the others can have it turned off. NOTE: If your main storage is mounted read-only, you must set this directive to "off". Default: on Example: enable-product-installation off Directive: locale Description: Enable locale (internationalization) support by supplying a locale name to be used. See your operating system documentation for locale information specific to your system. If your Python module does not support the locale module, or if the requested locale is not supported by your system, an error will be raised and Zope will not start. Default: unset Example: locale fr_fr 12

13 Directives: port-base Description: Offset applied to the port numbers used for ZServer configurations. For example, if the http-server port is 8080 and the port-base is 1000, the HTTP server will listen on port This makes it easy to change the complete set of ports used by a Zope server process Default: 0 Example: port-base 9673 Directive: datetime-format Description: Set this variable either to "us" or "international" to force the DateTime module to parse date strings either with month-before-days-before-year ("us") or days-before-month-before-year ("international"). The default behaviour of DateTime (when this setting is left unset) is to parse dates as US dates. Default: us Example: datetime-format international Directive: zserver-threads Description: Specify the number of threads that Zope's ZServer web server will use to service requests. The default is 4. Default: 4 Example: zserver-threads 10 Directive: python-check-interval Description: Specify an integer representing the Python interpreter "check interval" This interval determines how often the interpreter checks for periodic things such as thread switches and signal handlers. The Zope default is 500, but you may want to experiment with other values in order to attempt to increae performance in your particular environment. Default: 500 Example: python-check-interval 1000 Directive: zserver-read-only-mode Description: 13

14 If this directive is set to 'on', it will cause Zope to inhibit the creation of log files and pid files. Access and event log files will be presented on standard output. Setting this directive 'on' causes pcgi, fastcgi, and daemon-related directives to have no effect. Default: off Example: zserver-read-only-mode on Directive: pid-filename Description: The path to the file in which the Zope process id(s) will be written. This defaults to client-home/z2.pid. Default: CLIENT_HOME/Z2.pid Example: pid-filename /home/chrism/projects/sessions/var/z2.pid Directive: lock-filename Description: The path to a "lock file" which will be locked by Zope while it's running. This file is used by zopectl.py to determine if Zope is currently running. This defaults to CLIENT_HOME/Z2.lock. Default: CLIENT_HOME/Z2.lock Example: lock-filename /home/chrism/projects/sessions/var/z2.lock Directive: mime-types Description: Tells Zope about additional mime.types files that should be loaded. The files have the same format as the mime.types file distributed with Apache. The "mime-types" setting may be given more than once in the configuration file. Example: mime-types $INSTANCE/etc/mime.types Directive: structured-text-header-level Description: Set the default starting HTML header level for structured text documents. The default is 3, which implies that top-level headers will be created with an <H3> tag. Default: 3 Example: structured-text-header-level 1 Directive: rest-input-encoding Description: 14

15 Specifies the input encoding of re-structuredtext documents (e.g. 'utf-8', 'iso ' or any other valid encoding recognized by Python). The default is your Python's default encoding. Default: unset (uses system default) Example: rest-input-encoding iso Directive: rest-output-encoding Description: Specifies the output encoding of re-structuredtext documents (e.g. 'utf-8', 'iso ' or any other valid encoding recognized by Python). The default is your Python's default encoding. Default: unset (uses system default) Example: rest-output-encoding iso Directive: rest-header-level Description: Set the default starting HTML header level for restructured text documents. The default is 3, which implies that top-level headers will be created with an <H3> tag. Default: 3 Example: rest-header-level 2 Directive: rest-language-code Description: Language code used for some internal translations inside of the docutils package and for DTD bibliographic elements mapping. See lib/python/docutils/languages/ for a list of supported language codes. Default: en Example: rest-language-code de Directive: cgi-environment Description: A section which allows a user to define arbitrary key-value pairs for use as the initial CGI environment variables. This is useful when you want to proxy requests from another web server to Zserver, and would like Zserver's CGI environment to reflect the CGI environment of the other web server. Default: unset Example: <cgi-environment> HTTPS_SERVER Foobar Server 1.0 HTTPS_PORT 443 </cgi-environment> 15

16 Directive: dns-server Description: Specify the IP address of your DNS server in order to cause resolved hostnames to be written to Zope's access log. By default, Zope will not resolve hostnames unless this is set. Default: unset Example: dns-server Directive: ip-address Description: The default IP address on which Zope's various server protocol implementations will listen for requests. If this is unset, Zope will listen on all IP addresses supported by the machine. This directive can be overridden on a per-server basis in the servers section. Default: unset Example: ip-address Directive: http-realm Description: The HTTP "Realm" header value sent by this Zope instance. This value often shows up in basic authentication dialogs. Default: Zope Example: http-realm Slipknot Directive: automatically-quote-dtml-request-data Description: Set this directive to 'off' in order to disable the autoquoting of implicitly retrieved REQUEST data by DTML code which contains a '<' when used in <dtml-var> construction. When this directive is 'on', all data implicitly retrieved from the REQUEST in DTML (as opposed to addressing REQUEST.somevarname directly) that contains a '<' will be HTML-quoted when interpolated via a <dtml-var> or &dtml- construct. This mitigates the possibility that DTML programmers will leave their sites open to a "client-side trojan" attack. Default: on Example: automatically-quote-dtml-request-data on Directive: trusted-proxy Description: Define one or more 'trusted-proxies' directives, each of which is a hostname or an IP address. The set of definitions comprises a list of front-end proxies that are trusted to supply an accurate 16

17 X-Forwarded-For header to Zope. If a connection comes from a trusted proxy, Zope will trust any X-Forwarded header to contain the user's real IP address for the purposes of address-based authentication restriction. Default: unset Example: trusted-proxy trusted-proxy Directive: publisher-profile-file Description: Names a file on the filesystem which causes Zope's Python profiling capabilities to be enabled. For more information, see the Debug Information - > Profiling tab of Zope's Control_Panel via the Zope Management Interface. IMPORTANT: setting this filename will cause Zope code to be executed much more slowly than normal. This should not be enabled in production. Default: unset Example: publisher-profile-file $INSTANCE/var/profile.dat Directive: security-policy-implementation Description: The default Zope security machinery is implemented in C. Change this to "python" to use the Python version of the Zope security machinery. This impacts performance but is useful for debugging purposes and required by Products such as VerboseSecurity, which need to "monkey-patch" the security machinery. Default: C Example: security-policy-implementation python Directive: skip-authentication-checking Description: Set this directive to 'on' to cause Zope to skip checks related to authentication, for servers which serve only anonymous content. Only works if security-policy-implementation is 'C'. Default: off Example: skip-authentication-checking on Directive: skip-ownership-checking Description: Set this directive to 'on' to cause Zope to ignore ownership checking when attempting to execute "through the web" code. By default, this directive is on in order to prevent 'trojan horse' security problems whereby a user with less privilege can cause a user with more privilege to execute dangerous code. 17

18 Default: off Example: skip-ownership-checking on Directive: maximum-number-of-session-objects Description: An integer value representing the number of items to use as a "maximum number of subobjects" value of the '/temp_folder/session_data' transient object container. Default: 1000 Example: maximum-number-of-session-objects Directive: session-add-notify-script-path Description: An optional fill Zope path name of a callable object to be set as the "script to call on object addition" of the session_data transient object container created in the /temp_folder folder at startup. Default: unset Example: session-add-notify-script-path /scripts/add_notifier Directive: session-delete-notify-script-path Description: An optional fill Zope path name of a callable object to be set as the "script to call on object deletion" of the session_data transient object container created in the /temp_folder folder at startup. Default: unset Example: session-delete-notify-script-path /scripts/del_notifier Directive: session-timeout-minutes Description: An integer value representing the number of minutes to be used as the "data object timeout" of the '/temp_folder/session_data' transient object container. Default: 20 Example: session-timeout-minutes 30 Directive: session-resolution-seconds Description: An integer value representing the number of seconds to be used as the "timeout resolution" of the '/temp_folder/session_data' transient 18

19 object container. Default: 20 Example: session-resolution-seconds 60 Directive: suppress-all-access-rules Description: If this directive is set to on, no access rules in your Zope site will be executed. This is useful if you "lock yourself out" of a particular part of your site by setting an improper access rule. Default: off Example: suppress-all-access-rules on Directive: suppress-all-site-roots Description: If this directive is set to on, no site roots in your Zope site will be effective. This is useful if you "lock yourself out" of a particular part of your site by setting an improper site root. Default: off Example: suppress-all-site-roots on Directive: database-quota-size Description: Set this directive to an integer in bytes in order to place a hard limit on the size which the default FileStorage-backed Zope database can grow. Additions to the database will not be permitted once this filesize is exceeded. Default: unset Example: database-quota-size Directive: read-only-database Description: This causes the main Zope FileStorage-backed ZODB to be opened in read-only mode. Default: off Example: read-only-database on Directive: zeo-client-name Description: 19

20 If you want a persistent ZEO client cache which retains cache contents across ClientStorage restarts, you need to define a zeo-client-name. If you use ZEO and you don't set a zeo-client-name, the client cache is stored in temporary files which are removed when the ClientStorage shuts down. The value of zeo-client-name is used to uniquely identify the local cache files created if this Zope is a ZEO client. Default: unset Example: zeo-client-name zeo1 Directives: logger Description: This area should define one or more "logger" sections of the names "access", "event", and "trace". The "access" logger logs Zope server access. The "event" logger logs Zope event information. The "trace" logger logs detailed server request information (for debugging purposes only). Each logger section may contain a "level" name/value pair which indicates the level of logging detail to capture for this logger. The default level is INFO. Level may be any of "CRITICAL", 'ERROR", WARN", "INFO", "DEBUG", and "ALL". Each logger section may additionally contain one or more "handler" sections which indicates a types of log "handlers" (file, syslog, NT event log, etc) to be used for the logger being defined. There are 5 types of handlers: logfile, syslog, win32-eventlog, http-handler, -notifier. Each handler type has its own set of allowable subkeys which define aspects of the handler. All handler sections also allow for the specification of a "format" (the log message format string), a "dateformat" (the log message format for date strings), and a "level", which has the same semantics of the overall logger level but overrides the logger's level for the handler it's defined upon. XXXX much more detail necessary here Default: The access log will log to the file <instancehome>/log/z2.log at level INFO, the event log will log to the file <instancehome>/log/event.log at level INFO, and the trace log will not be written anywhere. <eventlog> level all <logfile> path $INSTANCE/log/event.log level info </logfile> </eventlog> <logger access> level WARN <logfile> path $INSTANCE/log/Z2.log format %(message)s </logfile> </logger> <logger trace> level WARN <syslog-handler> host localhost port 514 </syslog-handler> 20