Request for new plugin repo on gerrit-review: log-level plugin

[Gustaf Lundh]

Hi,

Name:

Gerrit Log Level Plug-in

Suggested repo:

plugins/log-level

Description:

Allows an administrator to persist configured log levels between restarts.

Typical configuration:

$ cat log-level.config

[log-levels "FATAL"]

    name = com.google.gerrit.server.change.EmailReviewComments

[log-levels "ERROR"]

    name = com.google.gerrit.sshd.GerritServerSession

    name = org.apache.mina.core.service.IoProcessor

[log-levels "INFO"]

    name = com.google.gerrit.common.Version

/Gustaf

[Saša Živkov]

I recently found out that log4j 2.x version actually supports automatic reconfiguration at runtime [1], see the monitorInterval setting.

Maybe it is worth exploring switching to log4j 2.x instead of creating a Gerrit plugin?

[1] https://logging.apache.org/log4j/2.x/manual/configuration.html#AutomaticReconfiguration

--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Gustaf Lundh]

I think log4j 2.x is absolutely worth exploring.

Though this plugin will be usable today for most stable branches and I've seen requests for exact this functionality in repo-discuss.

Note: The plugin does not affect the appenders configurations (outside of log levels) which is why we use it. We want to keep the logs exactly as Gerrits sets them up in the code (except for a few log-level adjustments). Exactly like how the sshd logging command works today.

This works great for us, so I personally wont be exploring log4j 2.x. My proposal is that we open source this plugin, and if the functionality is not needed anymore in the future, we deprecate it.

/Gustaf

---

From: Saša Živkov <ziv...@gmail.com>
Sent: Monday, September 24, 2018 2:27 PM
To: Gustaf Lundh
Cc: Repo and Gerrit Discussion
Subject: Re: Request for new plugin repo on gerrit-review: log-level plugin

 

[David Ostrovsky]

Am Montag, 24. September 2018 14:27:42 UTC+2 schrieb zivkov:

I recently found out that log4j 2.x version actually supports automatic reconfiguration at runtime [1], see the monitorInterval setting.

Maybe it is worth exploring switching to log4j 2.x instead of creating a Gerrit plugin?

Gerrit recently switched to using Google's FLogger frontend for logging.

FLogger still doesn't support log4j2 backend: [1]. Someone would have

to add it first, before we can perform that switch in Gerrit.

* [1] https://github.com/google/flogger/issues/24

[lucamilanesio]

On Monday, September 24, 2018 at 2:03:44 PM UTC+1, David Ostrovsky wrote:

Am Montag, 24. September 2018 14:27:42 UTC+2 schrieb zivkov:

I recently found out that log4j 2.x version actually supports automatic reconfiguration at runtime [1], see the monitorInterval setting.

Maybe it is worth exploring switching to log4j 2.x instead of creating a Gerrit plugin?

Gerrit recently switched to using Google's FLogger frontend for logging.

FLogger still doesn't support log4j2 backend: [1]. Someone would have

to add it first, before we can perform that switch in Gerrit.

* [1] https://github.com/google/flogger/issues/24

 

[1] https://logging.apache.org/log4j/2.x/manual/configuration.html#AutomaticReconfiguration

On Mon, Sep 24, 2018 at 1:35 PM Gustaf Lundh <gustaf...@axis.com> wrote:

Hi,

Name:

Gerrit Log Level Plug-in

Suggested repo:

plugins/log-level

Description:

Allows an administrator to persist configured log levels between restarts.

I agree, the plugin wold be very useful.

Any strong objections in creating the repo?

Otherwise I'll just do it, and thnaks Gustaf for contributing your plugin.

Luca.

[Saša Živkov]

On Mon, Sep 24, 2018 at 3:28 PM lucamilanesio <luca.mi...@gmail.com> wrote:

On Monday, September 24, 2018 at 2:03:44 PM UTC+1, David Ostrovsky wrote:

Am Montag, 24. September 2018 14:27:42 UTC+2 schrieb zivkov:

I recently found out that log4j 2.x version actually supports automatic reconfiguration at runtime [1], see the monitorInterval setting.

Maybe it is worth exploring switching to log4j 2.x instead of creating a Gerrit plugin?

Gerrit recently switched to using Google's FLogger frontend for logging.

FLogger still doesn't support log4j2 backend: [1]. Someone would have

to add it first, before we can perform that switch in Gerrit.

* [1] https://github.com/google/flogger/issues/24

 

[1] https://logging.apache.org/log4j/2.x/manual/configuration.html#AutomaticReconfiguration

On Mon, Sep 24, 2018 at 1:35 PM Gustaf Lundh <gustaf...@axis.com> wrote:

Hi,

Name:

Gerrit Log Level Plug-in

Suggested repo:

plugins/log-level

Description:

Allows an administrator to persist configured log levels between restarts.

I agree, the plugin wold be very useful.

Any strong objections in creating the repo?

No objections.

[Luca Milanesio]

On 24 Sep 2018, at 14:33, Saša Živkov <ziv...@gmail.com> wrote:

On Mon, Sep 24, 2018 at 3:28 PM lucamilanesio <luca.mi...@gmail.com> wrote:

On Monday, September 24, 2018 at 2:03:44 PM UTC+1, David Ostrovsky wrote:

Am Montag, 24. September 2018 14:27:42 UTC+2 schrieb zivkov:

I recently found out that log4j 2.x version actually supports automatic reconfiguration at runtime [1], see the monitorInterval setting.

Maybe it is worth exploring switching to log4j 2.x instead of creating a Gerrit plugin?

Gerrit recently switched to using Google's FLogger frontend for logging.

FLogger still doesn't support log4j2 backend: [1]. Someone would have

to add it first, before we can perform that switch in Gerrit.

* [1] https://github.com/google/flogger/issues/24

 

[1] https://logging.apache.org/log4j/2.x/manual/configuration.html#AutomaticReconfiguration

On Mon, Sep 24, 2018 at 1:35 PM Gustaf Lundh <gustaf...@axis.com> wrote:

Hi,

Name:

Gerrit Log Level Plug-in

Suggested repo:

plugins/log-level

Description:

Allows an administrator to persist configured log levels between restarts.

I agree, the plugin wold be very useful.

Any strong objections in creating the repo?

No objections.

 

Otherwise I'll just do it, and thnaks Gustaf for contributing your plugin.

Creating the repository as we speak :-)

[Gustaf Lundh]

Creating the repository as we speak :-)

Awesome. Thanks. 

/Gustaf

[Luca Milanesio]

On 24 Sep 2018, at 14:40, Gustaf Lundh <gustaf...@axis.com> wrote:

Creating the repository as we speak :-)

Awesome. Thanks. 

Done:

https://gerrit-review.googlesource.com/admin/repos/plugins/log-level

You are the Owner of the repo.

Luca.

[Gustaf Lundh]

Thanks. Pushed the code yesterday.

This is how the config works:

---

$ cat log-level.config

[FATAL]

    name = com.google.gerrit.server.change.EmailReviewComments

[WARN]

    name = org.eclipse.jetty.server.session

    name = com.google.gerrit.server.plugins

---

It's just a few lines of code, but works great for us. Hope someone else finds it useful.

/Gustaf

[Luca Milanesio]

On 26 Sep 2018, at 10:00, Gustaf Lundh <gustaf...@axis.com> wrote:

Thanks. Pushed the code yesterday.

This is how the config works:

---

$ cat log-level.config

[FATAL]

    name = com.google.gerrit.server.change.EmailReviewComments

[WARN]

    name = org.eclipse.jetty.server.session

    name = com.google.gerrit.server.plugins

---

It's just a few lines of code, but works great for us. Hope someone else finds it useful.

Can't tell you how many times my users asked for it :-)

Thanks again for contributing it.

Luca.

/Gustaf

On Monday, September 24, 2018 at 3:42:20 PM UTC+2, lucamilanesio wrote:

Done:

https://gerrit-review.googlesource.com/admin/repos/plugins/log-level

You are the Owner of the repo.

Luca.

[Saša Živkov]

First, thank you for contributing this plugin. I think we will start using it immediately :-)

Regarding the plugin config file (log-level.config) I am not sure if it has any advantage over the standard log4j properties format.

For example, instead of:

[WARN]

    name = org.eclipse.jetty.server.session

    name = com.google.gerrit.server.plugins

we would need just:

org.eclipse.jetty.server.session=WARN

com.google.gerrit.server.plugins=WARN

if we would use the standard log4j format. The boilerplate "name =" would be eliminated.

[Gustaf Lundh]

I fully agree. 

The reason for the "name=" format is that I wanted to make use of configFactory.getGlobalPluginConfig() to manage the plugin config and dots, as you know, cannot be used in config key names.

Escaping all the dots looked even worse than what we have now.

But if you think using a property file instead and scrapping configFactory all together is worth it, I would have no problems accepting a change like that. 

/Gustaf

To unsubscribe, email repo-disc...@googlegroups.com

More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Saša Živkov]

On Wed, Sep 26, 2018 at 12:36 PM Gustaf Lundh <gustaf...@axis.com> wrote:

I fully agree. 

The reason for the "name=" format is that I wanted to make use of configFactory.getGlobalPluginConfig() to manage the plugin config and dots, as you know, cannot be used in config key names.

Escaping all the dots looked even worse than what we have now.

But if you think using a property file instead and scrapping configFactory all together is worth it,

It shouldn't be too difficult to implement. Just injecting SitePaths and using something like sitePaths.etc_dir.resolve("log-level.properties") should work.

 

I would have no problems accepting a change like that.

In this early phase we still have chance to change the config file format. If the only purpose of this

plugin (as its name says) is to set logging levels then I would vote for the property file format.

If no one disagrees then I would contribute that change.

[Gustaf Lundh]

+2

/Gustaf

[Saša Živkov]

Done in [1]

[1] https://gerrit-review.googlesource.com/c/plugins/log-level/+/197271

[Jacek Centkowski]

Hi Gustav,

What is the advantage of this plugin over adding:

container.javaOptions = -Dlog4j.configuration=file:///etc/log4j.properties

to gerrit.config?

Regards,

Jacek

[Jacek Centkowski]

I could see the difference if it was storing it refs/meta/config of All-Projects so that one wouldn't have to login to server.

Or better if one could use it instead of SSH command (so that it is stored and applied in the same time :D)

but AFAICT it requires file to be modified and it reads it upon Gerrit start...

Regards,

Jacek

[Saša Živkov]

On Thu, Sep 27, 2018 at 7:57 AM Jacek Centkowski <geminica...@gmail.com> wrote:

Hi Gustav,

What is the advantage of this plugin over adding:

container.javaOptions = -Dlog4j.configuration=file:///etc/log4j.properties

to gerrit.config?

IMO, one advantage is that this plugin honors the default log4j configuration packaged inside the gerrit.war

and applies the plugin configuration on top of it.

-Dlog4j.configuration completely replaces the log4j configuration from Gerrit, right? Therefore, it must

be a full copy plus adaptations.

Regards,

Jacek

On Monday, 24 September 2018 13:35:10 UTC+2, Gustaf Lundh wrote:

Hi,

Name:

Gerrit Log Level Plug-in

Suggested repo:

plugins/log-level

Description:

Allows an administrator to persist configured log levels between restarts.

Typical configuration:

$ cat log-level.config

[log-levels "FATAL"]

    name = com.google.gerrit.server.change.EmailReviewComments

[log-levels "ERROR"]

    name = com.google.gerrit.sshd.GerritServerSession

    name = org.apache.mina.core.service.IoProcessor

[log-levels "INFO"]

    name = com.google.gerrit.common.Version

/Gustaf

--

[Saša Živkov]

On Thu, Sep 27, 2018 at 8:03 AM Jacek Centkowski <geminica...@gmail.com> wrote:

I could see the difference if it was storing it refs/meta/config of All-Projects so that one wouldn't have to login to server.

Or better if one could use it instead of SSH command (so that it is stored and applied in the same time :D)

Yes, that would be a nice feature of the plugin.

 

but AFAICT it requires file to be modified and it reads it upon Gerrit start...

Actually upon plugin start. Just touching the plugin.jar can avoid Gerrit restart.

 

--

[Gustaf Lundh]

We want to keep the logs exactly as Gerrit sets them up in the code. (And there is a lot of setup being done).

I.e. we want gc, error, access and sshd logs to be formatted and managed exactly as intended. By using a log4j.properties we need to emulate all that setup being done in code, for all these logs, and we need to keep track of log related changes in the Gerrit code base and keep our properties file in sync. 

Using this plugin we adjust the log-levels in a similar way as the ssh logging-command but make them persistent.

/Gustaf

[Gustaf Lundh]

Would be a nice additional feature. We prefer to provision all config files to the server for now (using ansible), but I'm sure refs/meta/config would fit some admins better.

/Gustaf

[Saša Živkov]

On Thu, Sep 27, 2018 at 9:09 AM Saša Živkov <ziv...@gmail.com> wrote:

On Thu, Sep 27, 2018 at 8:03 AM Jacek Centkowski <geminica...@gmail.com> wrote:

I could see the difference if it was storing it refs/meta/config of All-Projects so that one wouldn't have to login to server.

Or better if one could use it instead of SSH command (so that it is stored and applied in the same time :D)

Yes, that would be a nice feature of the plugin.

 

Just to be more clear: here I meant to have an SSH command which stores and applies a log-level change.

I do not have an opinion (yet) on storing logging levels in the refs/meta/config.

[Luca Milanesio]

On 27 Sep 2018, at 08:33, Gustaf Lundh <gustaf...@axis.com> wrote:

We want to keep the logs exactly as Gerrit sets them up in the code. (And there is a lot of setup being done).

I.e. we want gc, error, access and sshd logs to be formatted and managed exactly as intended. By using a log4j.properties we need to emulate all that setup being done in code, for all these logs, and we need to keep track of log related changes in the Gerrit code base and keep our properties file in sync. 

Are you getting stats from Gerrit logs?

Why not using the audit-sl4j plugin with JSON format? It would be a lot *more* reliable as source of information of what's going on in Gerrit.

Luca.

[Gustaf Lundh]

We do build some stats from the logs. Mostly user related. Otherwise we gather data from the metrics framework.

Though the audit-sl4j plugin looks interesting. Is there any documentation?

I hate that we don't have a good way to explore or find new interesting plugins.

/Gustaf

---

From: Luca Milanesio <luca.mi...@gmail.com>
Sent: Thursday, September 27, 2018 10:15 AM
To: Gustaf Lundh
Cc: Luca Milanesio; Repo and Gerrit Discussion

Subject: Re: Request for new plugin repo on gerrit-review: log-level plugin

[David Pursehouse]

On Thu, Sep 27, 2018 at 5:07 PM Saša Živkov <ziv...@gmail.com> wrote:

On Thu, Sep 27, 2018 at 9:09 AM Saša Živkov <ziv...@gmail.com> wrote:

On Thu, Sep 27, 2018 at 8:03 AM Jacek Centkowski <geminica...@gmail.com> wrote:

I could see the difference if it was storing it refs/meta/config of All-Projects so that one wouldn't have to login to server.

Or better if one could use it instead of SSH command (so that it is stored and applied in the same time :D)

Yes, that would be a nice feature of the plugin.

 

Just to be more clear: here I meant to have an SSH command which stores and applies a log-level change.

There is already a core ssh command to set logging level.  Would it make more sense to extend that to allow persisting the level changes?

[Luca Milanesio]

On 27 Sep 2018, at 09:18, Gustaf Lundh <gustaf...@axis.com> wrote:

We do build some stats from the logs. Mostly user related. Otherwise we gather data from the metrics framework.

Though the audit-sl4j plugin looks interesting. Is there any documentation?

This is what is available at the moment:

https://gerrit.googlesource.com/plugins/audit-sl4j/+/stable-2.15/src/main/resources/Documentation

I hate that we don't have a good way to explore or find new interesting plugins.

True, we should discuss the topic at the next Hackathon/Summit in Palo Alto.

BTW: are you guys coming? Did not see your tickets coming through :-O

[Jacek Centkowski]

Thanks Sasa and Gustaf for explanation.

IOW one has a choice of either maintaining logs himself (also altering format if needed) through -Dlog4j.configuration or using this plugin build on the top of existing log configuration by adding extra entries (evolve)...

The latter sounds like a good candidate for core feature to me (just add --persist switch to logging set-level command).

Regards

Jacek

[Gustaf Lundh]

Thanks. I checked out the master branch which lacked the documentation folder.

> BTW: are you guys coming? Did not see your tickets coming through :-O

Sadly, I won't be able this year :(

/Gustaf

[David Pursehouse]

On Mon, Sep 24, 2018 at 10:03 PM David Ostrovsky <david.o...@gmail.com> wrote:

Am Montag, 24. September 2018 14:27:42 UTC+2 schrieb zivkov:

I recently found out that log4j 2.x version actually supports automatic reconfiguration at runtime [1], see the monitorInterval setting.

Maybe it is worth exploring switching to log4j 2.x instead of creating a Gerrit plugin?

Gerrit recently switched to using Google's FLogger frontend for logging.

FLogger still doesn't support log4j2 backend: [1]. Someone would have

to add it first, before we can perform that switch in Gerrit.

There was work ongoing to upgrade log4j to 2.x [2] but it was stalled due to this lack of support in Flogger.

[2] https://gerrit-review.googlesource.com/c/gerrit/+/142811/

 

* [1] https://github.com/google/flogger/issues/24

 

[1] https://logging.apache.org/log4j/2.x/manual/configuration.html#AutomaticReconfiguration

[Saša Živkov]

On Thu, Sep 27, 2018 at 10:19 AM David Pursehouse <david.pu...@gmail.com> wrote:

On Thu, Sep 27, 2018 at 5:07 PM Saša Živkov <ziv...@gmail.com> wrote:

On Thu, Sep 27, 2018 at 9:09 AM Saša Živkov <ziv...@gmail.com> wrote:

On Thu, Sep 27, 2018 at 8:03 AM Jacek Centkowski <geminica...@gmail.com> wrote:

I could see the difference if it was storing it refs/meta/config of All-Projects so that one wouldn't have to login to server.

Or better if one could use it instead of SSH command (so that it is stored and applied in the same time :D)

Yes, that would be a nice feature of the plugin.

 

Just to be more clear: here I meant to have an SSH command which stores and applies a log-level change.

There is already a core ssh command to set logging level.

Yes, I knew that.

 

Would it make more sense to extend that to allow persisting the level changes?

Yes, this could make sense. If we do that in Gerrit core then the log-level plugin wouldn't be necessary.

Ideally, applying of the persisted log levels should be applied as early as possible in Gerrit's startup,

because sometimes we may want to capture debug logs generated during the startup process.