[
https://issues.apache.org/jira/browse/JSPWIKI-1311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18132966#comment-18132966
]
Arturo Bernal commented on JSPWIKI-1311:
----------------------------------------
Inventory of what the registered MBeans expose today, taken from reading
DefaultAdminBeanManager.reload and each bean class. I have not checked it
against a running JVM. They are registered on the platform MBeanServer, with
names of the form JSPWiki:component=...,name=title (applicationName). CoreBean
has two read-only attributes: pages, the total page count from
PageManager.getTotalPageCount, and version. UserBean has no attributes and no
operations. SearchManagerBean has no attributes and one operation, reload,
which indexes all pages again. PluginBean and FilterBean have no attributes and
no operations. Beans declared by plugins and editors are registered too, for
example PlainEditorAdminBean with the attributes title and checked. So, apart
from the page count and the version, the MBeans expose no number an operator
could watch: nothing about the page cache, the search index, sessions or
workflows. That is the gap for the monitoring use discussed on dev@. A first
step could be a few read-only attributes on the existing beans, for example
cache statistics and the number of indexed pages. I have not looked at how the
page cache and the Lucene provider can report those numbers, so I do not know
yet how much work each one is.
> Add metrics, a health endpoint and structured logging for operators
> -------------------------------------------------------------------
>
> Key: JSPWIKI-1311
> URL: https://issues.apache.org/jira/browse/JSPWIKI-1311
> Project: JSPWiki
> Issue Type: New Feature
> Reporter: Arturo Bernal
> Priority: Major
>
> JSPWiki gives operators little to observe a running instance with. What
> exists today is the following.
>
> The package org.apache.wiki.management has only SimpleMBean, which is the
> base of the admin beans of the administration page
> (org.apache.wiki.ui.admin); it is not a metrics system. WatchDog notifies
> about timeouts of the threads it watches. I found no code for metrics or
> health checks, with Micrometer, Prometheus or anything else, in the code or
> in the poms, and no Jira issue about it.
>
> Logging goes through Log4j 2, configured in WEB-INF/classes/log4j2.xml with a
> plain text PatternLayout for the console and for the rolling files, plus a
> separate audit log.
>
> Proposal, in three independent parts that can be done one at a time.
>
> Metrics, for example with Micrometer and exposed in the Prometheus format:
> pages and attachments, searches, logins and failed logins, the time of the
> page providers, the size of the caches and the state of the background
> threads.
>
> A health endpoint that tells whether the engine has started and whether the
> page provider, the search index and the user database respond, for load
> balancers and container orchestrators. It must say nothing sensitive and be
> protected or limited as the deployment needs.
>
> Structured logging: a JSON layout of Log4j 2 as an option, with the user and
> the request as context, and the audit log in the same format.
>
> Open questions: which dependency to use (Micrometer, or only JMX and plain
> servlets), whether the endpoints belong in a servlet of the war or in a
> separate module, how to secure them, and what to do with the old JMX-style
> admin beans.
>
> This ticket is a proposal; there is no implementation.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
