The Proposals Wiki has been deprecated in favor of creating Feature Requests in JIRA. If you wish to propose a new idea for a feature, visit the Community Ideas Dashboard and read the Feature Requests Wiki page for more information about submitting your proposal.

Liferay Monitoring Proposal - FSD #

@author: Rajesh Thiagarajan, Karthik Sudarshan



Feature Overview #

This documents captures the Functional Specification Document (FSD) for the Webspace Glassfish/Liferay server monitoring It also captures some aspects outside the FSD which are typically present in the marketing documents such as

  • Competitive Analysis
  • Feature Gaps
  • Potential Accelerators etc.

Technology Overview #

Webspace Glassfish server is based on the Liferay Portal and is primarily written in Java, This section provides a quick overview on different monitoring technologies that are currently available and their relevance in web applications specifically in Portals.

JMX( Java Management Extension) :
The JMX ( Java Management Extension) technology is a Java standard, it provides tool and APIs for building distributed, web-based, modular and dynamic solutions for managing and monitoring devices, applications, and service-driven networks.

The JMX technology can be employed by a web application in several ways the following are the list of broad category of possibilities in which an application can employ and benefit from using the JMX technology.

  • Monitoring & Error Detection : Simple attributes that can be exported for clients (SNMP/JMX agents) that monitor the availability and health of the system being monitored and to detect errors Eg : failover detection, database connectivity down etc.
  • Primitive tuning : Provides options to administrator to tune instances based on the above health of the system. Eg : provide options to increase the size of thread pool when utilization reaches 85% of max value etc.
  • Notification : Send notification or alerts to administrator on important events, threadhold meet or a resource crunch
  • Management : Provide options to manage the whole system using JMX, As supported by Portal server 7.2 Eg : Create remote instances -- stop/start instance etc.
  • Service Abstraction : As an abstraction to plugin implementations ( Similar to Spring )
  • Other possibilities : User tacking etc ?

SNMP Support :
JMX is the preferred technology for management of Java and J2EE applications. On the other hand, SNMP delivers an end-to-end management from various networks to different applications, it is a dominant protocol with widespread acceptance, but it also has its limitations.

The power of expression of SNMP/SMI is limited. It is ideally suited to describe and monitor numeric gauges and counters (scalar or tabular), but describing complex data is much more awkward. Some things which could appear trivial in JMX, like for instance, returning a thread stack trace, can reach incredible levels of complexity in SNMP. Describing complex configuration can also rapidly become nightmarish. The possibility of evolution for SNMP interfaces is thus limited: SNMP is a very good protocol - but like any management technologies, it has its strengths, weaknesses, and limitations.

One of the touted advantages of SNMP is support by third party monitoring console, such as HP OpenView, IBM Tivoli, etc. With increasing adoption of JMX and some of the above console already supporting JMX, The support for SNMP in this Portal monitoring project is given LOW.

However with custom MBean Agents and SNMP adapters for them the above may be still achievable but NOT desirable.

Acknowledgments : JMX vs SNMP &:JMX SNMP Adapter


Competitive Analysis #

Liferay portal being a web application, the following are some of the monitoring related technologies that are already available to customers and administrators that allows a rudimentary monitoring of the Liferay Portal. These technologies are not portal specific and can be employed by any webapplication.

The intent of this section is to capture all such existing available tools and arrive at an optimal portal monitoring requirements that this project should solve.

Google Analytics/Web analytics :
These are simple yet powerful technologies that are available to customers that help monitor a web site, especially track the users behavior on the side. Eventhough it does not directly provide any information on health of the system it provides useful analytic's such as

  • Most visited page
  • Keywords ( search words that leads to this page)
  • Visitor activity such as time on site, depth of visit
  • User network ( domains/locations from which users came from)
  • No of downloads etc.

Nagios, Rabbix & Similar Probes:
Nagios is an simple open source network monitoring tool. It allows you to probe the resource consistently to find out its availability, by probe we mean an intelligent form of ping, where the user can write a script which makes a request to the resource and the response is checked for error or success, a very rudimentary mechanism that allows administrators to check the availability of a resource.

Link to nagios.org

Application Server Monitoring :

Application servers typically have a Monitoring capabilities, specificall glassfish has the following options to monitor a web application deployed over it, The application server provide monitoring options to monitor applications(servlets, filters etc), services (web and ejb), JVM and J2EE Resources ( Database and Connectors).

  • Monitoring of application has
    • Response time
    • Error counts
    • Request Count
    • Max time
    • Service Time ??
  • Access log with filters
  • JVM Monitoring
  • Resource Monitoring : JDBC Connection Pool or J2EE/JNDI Resources. Connectors
  • Transactions, EJB and WebContainer
  • Appserver Thread Pool

Java Monitoring :
The following Mbeans are made available by the JVM itself, These Mbeans are available for use on any program that is running on the JVM.

MBean Name Description
java.lang.management.ClassLoadingMXBean Class loading system of the Java virtual machine.
java.lang.management.CompilationMXBean Compilation system of the Java virtual machine.
java.lang.management.MemoryMXBean Memory system of the Java virtual machine.
java.lang.management.MemoryManagerMXBean Memory manager in the Java virtual machine.
java.lang.management.MemoryPoolMXBean Memory pool in the Java virtual machine.
java.lang.management.GarbageCollectorMXBean Garbage collector in the Java virtual machine.
java.lang.management.ThreadMXBean Threading system of the Java virtual machine.
java.lang.management.RuntimeMXBean Runtime system of the Java virtual machine.
java.lang.management.OperatingSystemMXBean Operating system on which the Java virtual machine is running.
java.util.logging.LoggingMXBean Logging facility.

What is there in Liferay :

There are 2 places in Liferay where monitoring related information is present in the current liferay code base

Control Panel --> Monitoring Tab
Has the following information

  • Active Sessions == Users online
  • Accessed URLS
  • Session Attributes

Control Panel --> Server Administration

  • Run the garbage collector to free up memory. (from JVM)
  • Clear content cached by this VM. (from JVM)
  • Clear content cached across the cluster. (Cache)
  • Clear the database cache. (Cache)
  • Reindex all search indexes. (Search)
  • Generate thread dump. (from JVM)
  • Log Levels
  • System/Portal Props (environment variables)
  • Portal Props ( portal.properteis)
  • Shut down ( Suppose to shut down portal)
  • OpenOffice ( Start openoffice server)

What to Monitor #

The above are some of the tools and technologies that are readily available for existing customers and liferay portal administrators to monitor the portal server. From the above analysis its obvious that even though the above tools and technologies provide some rudimentary monitoring capabilities none of them provide an insight into the internals of the liferay/webspace portal.

The intent of this project is to monitor and provide insight into the liferay portal which none of the above tools or technologies provide. There is no value add in providing a monitoring solution to the portal which addresses the above , since even today customers or adminstrator can get the above information in one form or another.

Monitoring is about monitoring the status and health of the resources. This project intents to monitor the health and status of Portal Resources & Services which should provide an insight into what is happening inside the Portal. Here is the list of portal resources and services with some descriptions which we intent to monitor.

Note : The below are not the list of MBean's -- Its just a list of portal resources -- Each portal resource may transtalate into one of more Mbeans.

Resource Name Description
Portal Instances Instances of liferay/webspace server
Plugins Applications deployed on to the portal server eg : portlets, themes, layout etc.
Channels/Windows Instances of portlets/ plugins
Pages Portal pages that aggregate portlet plugins
Communities Loosely grouped set of users
Organizations Hierarchical user groups
Caches Various caches in portals
Database Connections Connection to DB
Portal threads threads created by portal
Connection external machines HTTP and webservice invocations
Portal Users & Session Users in the system
Chat service Monitor Portal chat activity
Search service Monitor Portal search activity
Message Boards Monitor Portal message boards
Authentication Service Monitor auth filters
CMS Templates, portlets etc

Constraints #

Can the monitoring code be as an plugin?

The answer to this question is Maybe, but it would be limited.

The engineering recommendation on this is, it would be beneficial to integrate the monitoring onto the liferay trunk as a core.


Assumptions and Dependencies #


Requirements #

The words shall and must identify the mandatory (essential) requirements in this document. The words should and may identify optional (conditional) requirements. One is required for release the product ­ the other is desired, but not necessary.

Glossary

Dynamic attributes : These attributes provide the "current picture" of the systems. For Eg: The memory used, users online, elapsed time, request processing time etc. These are runtime attributes of the system which indicate the health and status of the system.


Static attributes : These attributes provide the static detail of the portal. For Eg : The number of pages, number of users present in a community etc. These are optional and LOW priority attributes of the system, These details will be available to the administrator only at the highest level of monitoring i.e HIGH. The intent of providing these attributes is to facilitate a single view of the related system information. These information are anyway available to the administrator via the control panel.


Derived Attributes : Again derived attributes are optional these can be calculated based on the attributes that are exported by the system. Some of the derived attributes will be available optionally based on level of monitoring. All derived attributes mentioned in this document are optional and will be available only at the highest level of monitoring unless otherwise specified.

Product Level Requirements #

  1. Must provide options to completely disable monitoring for each of the portal resources and services.
  2. Must provide atleast 3 different levels of monitoring: Eg : HIGH, MODERATE, LOW , which can be configured by the administrator.
  3. The default monitoring level shall be LOW for some of the mandatory service and OFF for the rest of the resources and services.
  4. All the static & derived attributes of the system are optional and MAY be available only at the monitoring LEVEL= HIGH, unless otherwise specified.

Monitoring Framework Requirements :

Portal MBean Service API :

  1. Should provide API that enables MBeans Server/Agent developers to list and register portal MBeans with the MBean server of their choice.
  2. Should provide API to set the level on monitoring on each portal MBean.
  3. May provide API to lookup registered portal MBeans from other MBeans.
  4. May provide options to change Log level of each portal resource or service if applicable.

Portal MBean Agent:

  1. Should provide an default MBean server that uses the Portal MBeans API and registers all the portal MBeans.
  2. Should provide an option to export Portal MBeans locally -- only for local consumption.
  3. Should provide an option to export Portal MBeans remotely -- only for remote monitoring.
  4. Should provide option to disable or unregister individual Portal MBeans.
  5. JVM MBeans : May optional register JVM platform MBeans with portal -- For the sake of providing single access point for the administrators
  6. May provide adapters for SNMP clients.
  7. May provide MBean cascading support.

Authentication :

  1. Must provide an JAAS Authentication module that authenticates admin users against portal user service.
  2. Must provide a option to disable the above JAAS authentication module for local publishing of MBeans.

Functional Requirements #

This section provides an in depth view of the Portal Resources identified previously, from the perspective of monitoring.

Portal Instances:

Monitors the portal instances that are available on an webcontainer instance. The availability of this MBean would mean that the instance is up but not necessarily the portal server instance is up. The MBean server may be up and the MBean is accessible, but the Liferay/WebSpace Server web application is not accessible for some reason, In such cases the the MBean should provide the necessary details (This might be through some sort of HTTP Error code that is available on making a HTTP request).

Apart from the status of the Portal Instance, the health of the instance should also be monitored. For this purpose, the following dynamic and static attributes of the Portal instance can be monitored :

Dynamic attributes ://

  • Up time
  • Number of users online
  • Number of requests received
  • Avg. Request Processing time (in ms). As a side effect it should also show the highest and the least processing times.
  • Number of errors (HTTP Status > 400)
  • Number of request timeouts (Status 408). This might indicate that the system is overloaded.


Static attributes : Optional

  • Number of Communities (public, restricted, private)
  • Number of User Groups
  • Number of Organizations
  • Number of Sub-organizations (Child organizations)
  • Number of Locations (under Organizations)
  • Number of Registered Users

Communities / User Groups:

A Community in Liferay/WebSpace Server is a "loosely grouped set of users". The communities can be open, restricted or private. All these communities should be monitored for the various activities. A User Group is similar to a community, but it is mainly used to ensure that a User's default community (My Community) can be defined by its public and private pages.

The following static and dynamic attributes define the scope of community monitoring. (Please note that the community monitoring would be within the context of a Portal Instance)

Dynamic attributes ://

  • Number of community / user group members online
  • Number of requests for public pages
  • Number of requests for private pages (This should be considerably less for a community since only the community owner should by default be able to access the private pages)
  • Avg. Request Processing time (highest and least processing times as well)
  • Number of errors
  • Number of request timeouts (Status 408)


Static attributes :Optional

  • Number of public pages of a community / user group
  • Number of private pages of a community / user group
  • Number of members
  • Themes??
  • Average number of Channels per page

Organizations:

An Organization in Liferay/WebSpace Server is a "hierarchical set of users". It in most cases models the real world organizations. An Organization can have a sub (child) organization , and / or a location. The monitoring attributes of an organization (parent, child or location) are very similar to those of a community.(Please note that the organization monitoring would be within the context of a Portal Instance)
Dynamic attributes ://

  • Number of community members online
  • Number of requests for public pages
  • Number of requests for private pages (This should be considerably less since only the community owner should by default be able to access the private pages)
  • Avg. Request Processing time (highest and least processing times as well)
  • Number of errors
  • Number of request timeouts (Status 408)


Static attributes :Optional

  • Number of public pages of a community
  • Number of private pages of a community
  • Number of members
  • Average number of Channels per page
  • Themes ??

PAGES:

A page in Liferay/WebSpace Server is the canvas on which various portlet plugins are placed. Each page has a name and a url (even a friendly url) to uniquely identify it. Pages can be part of a Community, User Group, Organization, Sub Organization or Location. The various plugins are displayed inside a Channels, where one channel is for one plugin to be displayed.

The following static and dynamic attributes should be monitored for the pages: (Please note that the page level monitoring would be within the context of a community / organization / user group)

Dynamic attributes ://

  • Number of requests (a page is identified by a url, so basically requests to this url)
  • Number of errors encountered
  • Number of different users accessing the page (guest??)
  • Number of requests per channel in the page (local / remote)


Static attributes :Optional

  • Number of Channels for local portlets
  • Number of Channels for remote portlets
  • Number of pages with a particular layout
  • Number of pages with a particular Theme


CHANNELS / WINDOWS:

A Channel (optionally a Portlet Window) is the component which displays the markup of a portlet. Additionally, it provides options to configure a portlet, modify the state of the portlet or switch the modes of a portlet. Channels are placed within pages. The following static and dynamic attributes should be monitored for the channels : (Please note that the channel level monitoring would be within the context of a community / organization / user group / page)

Dynamic attributes ://

  • Time taken for each channel to render/action etc.
  • Number of requests per channel
  • Number of errors
  • Number of authorization failures (If this number is sufficiently high, then it indicates, that the channel is placed at the wrong place, where a number of unauthorized users are likely to visit)
  • Number of events generated.
  • Number of events consumed
  • Generated event details (payload??)
  • Consumed event details (sender, payload??)


Static attributes :Optional

  • Number of channels for each installed Portlet
  • Number of Customized channels for each installed Portlet
  • Number of channels for uninstalled portlets (here an unavailable error is displayed. This would be useful to remove the dead channels)
  • Number of channels for remote portlets

PLUGINS:

A Plugin in Liferay portal is a war which serves a specific purpose. There are multiple types of plugins supported by Liferay Portal/Web Space Server. The plugin monitoring is mostly static, is it is confined to the various installed plugins.

The following attributes of this plugin should be monitored :

Dynamic attributes

  • Number of Portlets initialized
  • Number of Portlets failed to initialized
  • Portlet initialization error if any

Static attributes : Optional

  • Number of Portlets installed
  • Number of Themes installed
  • Number of Layout Templates installed
  • Number of Hooks installed
  • Number of Web Plugins installed.

Coordination Service (Portlet Container & WSRP): Monitoring portal eventing and shared render parameter service.
Dynamic attributes

  • No of events fired.
  • Number of events failed.
  • No of public render parameters (PRP) shared.
  • No of public render parameters failed.


Static attributes : Optional

  • Aggregated Events and QNames.
  • List of portlets subscribing to each events.
  • List of portlets publishing events.
  • Aggregated PRP and QNames.
  • List of portlets subscribing to each PRP.
  • List of portlets publishing PRP.

CMS :

Dynamic attributes://
No of users viewing contents (this can be derived from the Page MBean, and the channels present in the page) No of documents crud (ed) No of structures crud (ed) No of templates crud (ed) No of images crud (ed) No of web contents crud (ed) No of web contents without any structures crud (ed) No of feeds crud (ed) Most frequently used tags


Static attributes://
No of structures with templates No of structures without templates No of contents for a structure No of contents without any structure associated No of feeds for a structure Average rating of contents of a structure (max rating and min rating) Contents with comments (provided comments are enabled)

Search :
Dynamic attributes://
No of searches made in this session Most frequently searched keyword by the user Average time taken to search (max time and min time with the search keywords) Average number of search results (max no and min no with the search keywords)

Static attributes://

  • Most commonly searched keywords

Chat :
Dynamic attributes

  1. No of active users on chat
  2. Total no of chat messages
  3. average no of chat sessions per user
  4. average no of messages per session
  5. average duration of chat session.

Message Bus and RUON ://

  1. No of messages sent on message bus
  2. average delivery time
  3. Max delivery time

Message Board :

Dynamic attributes://

  • No of new categories created
  • No of new messages created
  • No of new threads posted to existing messages
  • No of users accessing a particular message
  • No of unique users accessing the message board
  • No of positive votes for a post
  • No of negative votes for a post
  • Top posters
  • Number of banned users


Static attributes://
Total number of categories Total number of Posts Total number of participants Total number of banned users

Authentication :

Dynamic attributes://
No of successful logins using LDAP / CAS / NTLM / OpenID / OpenSSO / Site Minder No of unsuccessful logins using LDAP / CAS / NTLM / OpenID / OpenSSO / Site Minder

Users and Sessions :
Dynamic://

  1. No of users online
  2. No of authenticated users online
  3. No of authless or guests users online
  4. Session attributes
  5. No of logins
  6. No of logoffs
  7. Average session time.
  8. No of session timeouts

Derived : optional

  1. Login rate (derived)
  2. Logoff rate. (derived)

Static : optional

  1. Total number of users

Caches :

Dynamic attributes://
Number of layout / css / velocity templates / hibernate queries / hibernate objects / JSP in cache Number of hits in cache Number of misses Time of objects in cache Cache size

Database Connections :

Dynamic attributes://
No of open connections No of connections available in pool Average time, a connection is in use (max time and min time)


Static attributes://
Initial number of connections in the pool Maximum number of connections in the pool


Portal threads :

  1. Quartz jobs (Low priority)
  2. Messaging thread pool ( Parallel, Serial etc (Low priority)

Open SSO and Access Manager :

  1. No of users replicated from Open SSO to Liferay
  2. Time taken for replication.
  3. No of auth redirects.
  4. No of failed authentications.
  5. No of successful authentication.
  6. No of single logoffs

Future Requirements #

Monitoring for Addons

SRA :

TBD
----

User Interface Requirements #

  1. Shall provide a GUI that integrates with the Liferay Control Panel.
  2. The monitoring Tab under the Liferay Control Panel may be modified to provide a GUI to above Portal Mbeans.
  3. May provide option to connect to local or remote Portal MBean Server/Agent.
  4. Should provide auto login option for monitoring remote instances ( for the same portal cluster).
  5. Optionally provide users with the option to enter credentials for remote authentication.

Performance Requirements #

  1. This feature must not cause performance regressions.
  2. Monitoring should optional and can be completely disable if not required by administration.

Other Requirements #

Globalization:

  1. The exceptions thrown from MBeans should have an error code associated with each exception which should be i18n'ed

Design #


Architecture #

The architecture of the monitoring subsystem is dictated by the liferay portal deployment architecture. For Eg here are some of the common deployment options that is supported by the liferay portal.

  1. Single Portal Instance on a Webcontainer ( Simple developer setup)
  2. Multiple Portal Instances on a Webcontainer ( ISV multiportal setup)
  3. Single/Multiple Portal Instance on multiple webcontainer instances (cluster, failover configuration)

Single Portal Instance on a Webcontainer #

This is a simplest configuration where the portal server MBeans are registered with the MBean server or an MBean Server Agent and exported for remote monitoring. There exists only

  • One portal instance deployed on a webcontainer.
  • The default Mbean server is created and managed within the portal web application.
  • The monitoring client connects to the MBean interface exported by the MBean server. ( Client may be on a different JVM)

Multiple Portal Instance on a Webcontainer #

The liferay portal has the capability to host multiple portal instances on a same webcontainer instance. Each instance of portal is identified by means of a company Id which is automatically generated, To create a new portal instance in liferay login as admin ControlPanel-->Admin Portlet--> Add Instance (virtual host, web id and mail host).

In this configuration all the portal server instances MBeans are registered with the MBean server or an MBean Server Agent and exported for remote monitoring. There exists

  • Only one Mbean server instance. The default Mbean server is created and managed within the portal web application.
  • All the portal instances Mbeans are namespaced and registered with the above MBean server.
  • The monitoring client connects to the MBean interface exported by the MBean server. ( Client may be on a different JVM) This gives an aggregated view of all the portal instances Mbeans to the clients.

The below diagram depicts this configuration.

Multiple Portal Instance on different Webcontainer #

Typically in enterprise deployments, there will be multiple webcontainer instances which hosts one or more portals, such a configuration addresses specifically the failover & high availability metrics for a SHARP deployment.

In this configuration all the portal server instances MBeans are registered with the MBean server or an MBean Server Agent and exported for remote monitoring. There exists

  • One Mbean server instance per web container instance
  • All the portal instances Mbeans on that webcontainer are namespaced and registered with the above MBean server.
  • The monitoring client now has different connection points to the 'n' number of MBean interface exported by each webcontainer interface. This DOES NOT give an aggregated view of all the portal instances Mbeans to the clients.

The below diagram depicts this configuration. Multiple instance Configuration

MBean Cascading : Multiple Portal Instance #

This configuration is same as the above "Multiple Portal Instance on different Webcontainer" configuration, However it has one difference, It tries to take advantage of the Mbean Agent Cascading feature and tries to export a single access point to clients. In such case the client can

1. Connect to any of the MBean server available and get an aggregated view of all the portal MBeans

Note : This is not a MBean feature/functionality rather a MBean Agent functionality, We guess JDMK Agents do support cascading operation - Need to check the status of such an configuration.

The below diagram depicts this configuration. Cascading Configuration


Portal MBean Service : As an exported API #

Instead of having a single monolithic monitoring module in the portal server, we intent to split up the portal monitoring into the following layer and provide a API called Portal MBean Service that glues these 2 layers.

      1. Instrumented MBean Layer : This is the actual Portal MBean class, which instruments and exports a portal resource for monitoring.
      2. MBean Server/Agent Layer : This is is MBean server/Agent layer which registers the MBeans and provides additional services to these MBeans.
      3. The Client : This is the JMX/SNMP client that connects to the above MBean server and monitors the portal.

The intent of this API is to provide clean separation and abstraction between the Instrumented MBean Layer and MBean Server/Agent Layer. This API provides developers and administrators with the ability to

  1. Register and Manage the portal MBeans with the MBean server of their choice.
  2. Provides potential to register Portal MBeans to Appserver server specific MBean server-- Single point of access.
  3. Develop custom MBean server agents that provide support for additional adapters (Webservice).
  4. Add a custom authentication module to the MBean.
  5. Potential to integration with other Sun stack (JES MF or CACAO).

The Portal MBean Agent will use the Portal MBean Service API to implement the MBean Server and serve as a reference implementation for custom MBean Agent development.The below diagram depicts this configuration. Portal MBean Service API


Security and Authentication #

Mbean servers can be configured for remote access or remote monitoring, This section addresses the security and access control architectural issues associated with such configuration.

1. Custom JAAS Authentication :

MBeans can be configured to require authentication to access to them, In this configuration a simple custom JAAS authentication module would be configured to use Liferay Portal User/Authentication service.

Note : Allows only admin user access, integration with auth filters and roles need to be validated and added for future requirements.

2. No Authentication - Only Local Access :

No authentication will be enabled, only client JVM's in the same host will be able to access the portal MBeans. This configuration provides options to disables the above custom JAAS module and register the mbean only for local access. Say for Eg : The MBeans are enabled for local access on a liferay install. Say a Client, may be a GUI liferay ControlPanel will access and provide details. In such scenario the Liferay Control Panel will provide access control.

Note : However this means that any Java process running on the same box can lookup and monitor the portal instance -- If you have gained access to the box the security in with any level of access control in any case is already compromised.

3. Other Auth Services :
The Portal MBean Service (API) would provide system administrators and developers an option to list the portal MBeans and register with their custom MBeans server or agent. This option also open up the possibility to add custom authentication to the monitoring system.


Interface Specification #

Imported Interfaces #

S.NoNameVersionStabilityComments
1JMXTBDTBDTBD

Exported Interfaces #

S.NoNameVersionStabilityComments
1MBean NamesTBDTBDTBD

Design Notes #

Portal MBeans ObjectName hierarchy #

Source layout and packaging #


Development Plan #


Resourcing #


Development Process #


Plan & Estimate #


Development Process #


QA #

TaskComments
Test plans for Monitoring TBD

Documentation#

TaskComments
Documentation plans for Monitoring TBD

Globalization #

TaskComments
i18N and l10N plans for Monitoring TBD

Open Issues #

The following parts may be touched upon later w.r.t Monitoring:

  1. Calendar events
  2. Blogs
  3. Wikis
  4. Polls
  5. Connection external machines
4 附件
24420 查看
平均 (4 票)
满分为 5,平均得分为 5.0。
评论
讨论主题回复 作者 日期
Hi. What is the state of this? I am looking... Felipe Sere 2011年7月31日 上午5:51
We monitoring all JMX metrics of Liferay. ... Seshi Paturi 2013年8月6日 上午11:58

Hi. What is the state of this? I am looking into monitoring Liferay but I have not found much more than the usual JMX stuff. What I am really interested is in monitoring avg/min/max request response time...

Felipe
在 11-7-31 上午5:51 发帖。
We monitoring all JMX metrics of Liferay.

http://www.aqualogic.in/ams

Aqualogic Tech Sysems
info@aqualogic.in
在 13-8-6 上午11:58 发帖以回复 Felipe Sere