[
https://issues.apache.org/jira/browse/JSPWIKI-1311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18132830#comment-18132830
]
Arturo Bernal commented on JSPWIKI-1311:
----------------------------------------
Update after the discussion on
[[email protected]|mailto:[email protected]] on 27 October. Ulf
Dittmer suggested that, rather than adding dependencies for observability,
MBeans with the wanted information may be the simplest way: they can be queried
with a tool such as VisualVM, and Jolokia gives access over HTTPS where that is
needed. The JMX remote port should not be opened to the world.
A correction to the description above: the admin beans are already registered
as MBeans. SimpleAdminBean extends SimpleMBean, and DefaultAdminBeanManager
registers every admin bean that is a DynamicMBean with the platform MBean
server, so JMX is partly there. What I have not checked yet is which attributes
the existing beans expose, and whether any of them is operational data and not
configuration.
The scope of this issue is changed to this: first add MBeans with the
operational data that is missing (for example pages, cache, the search index,
sessions and failed logins), with no new dependency, and document how to reach
them with VisualVM and with Jolokia. Micrometer or Prometheus, a health
endpoint and structured logging stay as later options that depend on what the
group wants.
> 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)
