Decide future of Markscheider

[matterche]

Introduction

According to the Zalando Open Source rules of play several decisions about the future of the Markscheider project have to be made.

The following questions must be answered:

• Does the library provide a value generic enough to be useful for users outside of Zalando so that it can be moved from the Incubator organization to one of the official Zalando organizations on Github?
• If this is answered with “No”
  • The sources must be moved to an internal repository
  • The incubator repository must be removed
  • What happens with already published artifacts?
• If this is answered with “Yes”
  • To which organization will the project be moved (zalando, zalando-zmon)?
  • What needs to be done before being able to move it to an official Zalando organization?
  • Does it still make sense to keep it as a fork?

Markscheider mainly provides some support for using the Dropwizard metrics library so that an application can provide JVM and custom metrics. This functionality is derived from implicitly forking metrics-play by directly forking from https://github.com/fr3akX/metrics-play.

On top of the features already provided by metrics-play, Markscheider metrics are created in a format that is compatible with ZMON.

Proposal

From my point of view it does not make sense to move Markscheider to the zalando Github organization as the provided features are just no generic enough to be of use for a broader audience but it make sense to move to to the zalando-zmon Github organization because it provides a functionality similar to the ZMon Spring Boot Actuator. It’s just as easy as defining the dependency and registering the MetricsController to get content into the ZMon Cloud tab and being able to define checks and alerts based on the provided data.

Before being able to move Markscheider to zalando-zmon the documentation must be extended to explain more explicitly the use case and tests must be added. In addition, there is still something to do for being fully compliant to Zalando Open Source rules of play.

As for now I don’t understand why the original authors forked the library from https://github.com/fr3akX/metrics-play. It might make sense to consider still forking from https://github.com/kenshoo/metrics-play because the project already contains an appropriate test suite and is still maintained by several contributers. On contrast it’s also feasible to just base on the actual version to gain advantage from the existing test suite but don’t fork because most of the latest updates where related to Play framework upgrades. In addition, it might never make sense to merge back changes from Markscheider to metrics-play.

Last but not least I would recommend to rename the project to zmon-play-actuator or something similar to point out the similarity to zmon-actuator.

[matterche]

@alexkops If you have some time please could you have a look at this before I send a review request to our internal guilds?

[lenalebt]

Hi, since @matterche pointed me here, some thoughts from my side (as the original author): I am unsure why exactly I forked from https://github.com/fr3akX/metrics-play - I think at the time it had some updates that the original did not have. And I think it was not well-maintained at the time, which may have changed in the meantime as well. And this is thin ice, I don't really remember.

Main driver was zmon compatibility at the time, and I added some small features like calculation of time that went to external services in case you are calling them (external services were driving our response times at the time).

If it's worth it to bring it forward to another repo and put work in, I don't know. Up to you ;). I would add tests for the prometheus part witht he PR.

[matterche]

@lenalebt thanks for clarifying.

[matterche]

In a private message @whiskeysierra mentioned that ZMon Spring Boot Actuator has been abandoned because it's easier for everyone to just use the defaults provided by Spring and rather make ZMON support the format. That way you have to deal with the format once, in a check and teams can start using that. Rather than forcing everyone to use the same library.

Maybe the same approach makes markscheider completely obsolete?