We are currently solving the following issue within our repository. Here is the issue text:
--- BEGIN ISSUE ---
New web plugin idea: a health indicator
This ticket is a migrated Trac ticket [2966](http://trac.buildbot.net/ticket/2966)

People contributed to the original ticket: `benoit.allard@...`, @tardyp, @rutsky, @unknown_contributor, @sa2ajj, @rutsky
Ticket created on: `Oct 24 2014`
Ticket last modified on: `Mar 19 2016`

---

I like to extract as much useful indicator from my builds as possible (time, but also amount of warnings, and such ...)

It would be cool to have a web plugin that could print the evolution of my indicators over time ! (Of course, I would have to configure which indicator I want to see plotted, maybe the kind of plot, and so on ...)


---

_Comment from_: @sa2ajj
_Date_: `Oct 24 2014`

Could you please elaborate or provide a more specific example?

I think it's related to the [[metrics support|http://docs.buildbot.net/latest/developer/metrics.html]], but without an example I can easily be wrong :)

---
_Comment from_: @Ben
_Date_: `Oct 24 2014`

I was more aiming at [[Statistics|http://docs.buildbot.net/latest/developer/cls-buildsteps.html?highlight=statistics#buildbot.process.buildstep.[[BuildStep]].hasStatistic]], but I just realized that

   Note that statistics are not preserved after a build is complete.

So metrics is probably where we want to interface with the master.

I used to abuse Properties for that purpose ...

---
_Comment from_: @tardyp
_Date_: `Oct 24 2014`

Buildbot plugin system is really made for enabling such dashboards.

A web ui plugin is not technically restricted to creating a bunch of js file, it could also create a twisted service.

For me having the JS only use existing data api to query the data will be very inefficient. I think we could easily create a service, like a status service that registers to a bunch of mq events, and create statistics based on that.

I also had in mind that plugins could have some table in the DB they could use to store the data, or maybe use another db configuration with all schema + migration stuff separated.


---
_Comment from_: @tardyp
_Date_: `Oct 26 2014`

on IRC, sa2ajj talked about http://graphite.readthedocs.org/

He told us, he actually uses it at work, and has integration working with eigth.

Looking at the documentation, the first reaction is how to integrate this with multimaster, as graphite has its own db called whisper.
I haven't look too much deeply, but I think this is still feasible as a external tool. Probably this would be much cheaper than making our own metrics system inside buildbot.

An external graphite server could be setup, and watch for the (TBD) mq server. As there are messages for nearly every kind of activity that happens in buildbot, this is a good mean of making solid analysis of what is going on. Of course, this solution would not be fully integrated, as probably the UI would be external, but anyway, I think this is a possible cheap path.

@sa2ajj do you think it is possible? How would you estimate the cost of integration?




---
_Comment from_: @Ben
_Date_: `Oct 26 2014`

There are a lot of [[interfaces|http://graphite.readthedocs.org/en/latest/tools.html#visualization]], as well as data collectors / forwarders (same page, a bit higher) available for graphite. It looks like some of them are js-only ! Still way to go for a www-plugin !

---
_Comment from_: @sa2ajj
_Date_: `Oct 27 2014`

What I said was that we indeed use graphite, but I did not say we use it with Buildbot.

I have an oldish branch where I tried to publish metrics to graphite.  However I stopped working on that when I realised that it's not very straightforward to implement it to support multi-master case.

If there's an interest, I can revive the branch or, at least, publish what I have (after rebasing the latest master) so other could comment in what direction my thinking worked.

---
_Comment from_: @unknown_contributor
_Date_: `Mar 19 2016`

+1 for this feature. I suggest to merge the statistic API with the [[stats module|https://github.com/buildbot/buildbot/tree/master/master/buildbot/statistics]] developed last year by my GSOC student. And add a default backend that store a subset of these stat in the main database that would enable the development of heath/stats visualization modules directly installed by default (using Highchart js lib for example) 



--- END ISSUE ---

Below are some code segments, each from a relevant file. One or more of these files may contain bugs.
--- BEGIN FILES ---
Path: `pkg/setup.py`
Content:
```
1 #!/usr/bin/env python
2 #
3 # This file is part of Buildbot.  Buildbot is free software: you can
4 # redistribute it and/or modify it under the terms of the GNU General Public
5 # License as published by the Free Software Foundation, version 2.
6 #
7 # This program is distributed in the hope that it will be useful, but WITHOUT
8 # ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
9 # FOR A PARTICULAR PURPOSE.  See the GNU General Public License for more
10 # details.
11 #
12 # You should have received a copy of the GNU General Public License along with
13 # this program; if not, write to the Free Software Foundation, Inc., 51
14 # Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
15 #
16 # Copyright Buildbot Team Members
17 
18 from setuptools import setup
19 import buildbot_pkg
20 
21 setup(
22     name='buildbot_pkg',
23     version=buildbot_pkg.getVersion("."),
24     description='Buildbot packaging tools',
25     author=u'Pierre Tardy',
26     author_email=u'tardyp@gmail.com',
27     url='http://buildbot.net/',
28     license='GNU GPL',
29     py_modules=['buildbot_pkg'],
30 )
31
```
--- END FILES ---

Please first localize the bug based on the issue statement, and then generate a patch according to the `git diff` format fenced by three backticks.

Here is an example:

```diff
diff --git a/examples/server_async.py b/examples/server_async.py
--- a/examples/server_async.py
+++ b/examples/server_async.py
@@ -313,4 +313,4 @@
 
 
 if __name__ == "__main__":
-    asyncio.run(run_async_server("."), debug=True)
+    asyncio.run(run_async_server(), debug=True)
diff --git a/examples/server_sync.py b/examples/server_sync.py
--- a/examples/server_sync.py
+++ b/examples/server_sync.py
@@ -313,5 +313,5 @@
 
 
 if __name__ == "__main__":
-    server = run_sync_server(".")
+    server = run_sync_server()
     server.shutdown()

```

diff --git a/pkg/setup.py b/pkg/setup.py
--- a/pkg/setup.py
+++ b/pkg/setup.py
@@ -19,7 +19,7 @@
 import buildbot_pkg
 
 setup(
-    name='buildbot_pkg',
+    name='buildbot-pkg',
     version=buildbot_pkg.getVersion("."),
     description='Buildbot packaging tools',
     author=u'Pierre Tardy',

{"golden_diff": "diff --git a/pkg/setup.py b/pkg/setup.py\n--- a/pkg/setup.py\n+++ b/pkg/setup.py\n@@ -19,7 +19,7 @@\n import buildbot_pkg\n \n setup(\n-    name='buildbot_pkg',\n+    name='buildbot-pkg',\n     version=buildbot_pkg.getVersion(\".\"),\n     description='Buildbot packaging tools',\n     author=u'Pierre Tardy',\n", "issue": "New web plugin idea: a health indicator\nThis ticket is a migrated Trac ticket [2966](http://trac.buildbot.net/ticket/2966)\n\nPeople contributed to the original ticket: `benoit.allard@...`, @tardyp, @rutsky, @unknown_contributor, @sa2ajj, @rutsky\nTicket created on: `Oct 24 2014`\nTicket last modified on: `Mar 19 2016`\n\n---\n\nI like to extract as much useful indicator from my builds as possible (time, but also amount of warnings, and such ...)\n\nIt would be cool to have a web plugin that could print the evolution of my indicators over time ! (Of course, I would have to configure which indicator I want to see plotted, maybe the kind of plot, and so on ...)\n\n\n---\n\n_Comment from_: @sa2ajj\n_Date_: `Oct 24 2014`\n\nCould you please elaborate or provide a more specific example?\n\nI think it's related to the [[metrics support|http://docs.buildbot.net/latest/developer/metrics.html]], but without an example I can easily be wrong :)\n\n---\n_Comment from_: @Ben\n_Date_: `Oct 24 2014`\n\nI was more aiming at [[Statistics|http://docs.buildbot.net/latest/developer/cls-buildsteps.html?highlight=statistics#buildbot.process.buildstep.[[BuildStep]].hasStatistic]], but I just realized that\n\n   Note that statistics are not preserved after a build is complete.\n\nSo metrics is probably where we want to interface with the master.\n\nI used to abuse Properties for that purpose ...\n\n---\n_Comment from_: @tardyp\n_Date_: `Oct 24 2014`\n\nBuildbot plugin system is really made for enabling such dashboards.\n\nA web ui plugin is not technically restricted to creating a bunch of js file, it could also create a twisted service.\n\nFor me having the JS only use existing data api to query the data will be very inefficient. I think we could easily create a service, like a status service that registers to a bunch of mq events, and create statistics based on that.\n\nI also had in mind that plugins could have some table in the DB they could use to store the data, or maybe use another db configuration with all schema + migration stuff separated.\n\n\n---\n_Comment from_: @tardyp\n_Date_: `Oct 26 2014`\n\non IRC, sa2ajj talked about http://graphite.readthedocs.org/\n\nHe told us, he actually uses it at work, and has integration working with eigth.\n\nLooking at the documentation, the first reaction is how to integrate this with multimaster, as graphite has its own db called whisper.\nI haven't look too much deeply, but I think this is still feasible as a external tool. Probably this would be much cheaper than making our own metrics system inside buildbot.\n\nAn external graphite server could be setup, and watch for the (TBD) mq server. As there are messages for nearly every kind of activity that happens in buildbot, this is a good mean of making solid analysis of what is going on. Of course, this solution would not be fully integrated, as probably the UI would be external, but anyway, I think this is a possible cheap path.\n\n@sa2ajj do you think it is possible? How would you estimate the cost of integration?\n\n\n\n\n---\n_Comment from_: @Ben\n_Date_: `Oct 26 2014`\n\nThere are a lot of [[interfaces|http://graphite.readthedocs.org/en/latest/tools.html#visualization]], as well as data collectors / forwarders (same page, a bit higher) available for graphite. It looks like some of them are js-only ! Still way to go for a www-plugin !\n\n---\n_Comment from_: @sa2ajj\n_Date_: `Oct 27 2014`\n\nWhat I said was that we indeed use graphite, but I did not say we use it with Buildbot.\n\nI have an oldish branch where I tried to publish metrics to graphite.  However I stopped working on that when I realised that it's not very straightforward to implement it to support multi-master case.\n\nIf there's an interest, I can revive the branch or, at least, publish what I have (after rebasing the latest master) so other could comment in what direction my thinking worked.\n\n---\n_Comment from_: @unknown_contributor\n_Date_: `Mar 19 2016`\n\n+1 for this feature. I suggest to merge the statistic API with the [[stats module|https://github.com/buildbot/buildbot/tree/master/master/buildbot/statistics]] developed last year by my GSOC student. And add a default backend that store a subset of these stat in the main database that would enable the development of heath/stats visualization modules directly installed by default (using Highchart js lib for example) \n\n\n", "before_files": [{"content": "#!/usr/bin/env python\n#\n# This file is part of Buildbot.  Buildbot is free software: you can\n# redistribute it and/or modify it under the terms of the GNU General Public\n# License as published by the Free Software Foundation, version 2.\n#\n# This program is distributed in the hope that it will be useful, but WITHOUT\n# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS\n# FOR A PARTICULAR PURPOSE.  See the GNU General Public License for more\n# details.\n#\n# You should have received a copy of the GNU General Public License along with\n# this program; if not, write to the Free Software Foundation, Inc., 51\n# Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.\n#\n# Copyright Buildbot Team Members\n\nfrom setuptools import setup\nimport buildbot_pkg\n\nsetup(\n    name='buildbot_pkg',\n    version=buildbot_pkg.getVersion(\".\"),\n    description='Buildbot packaging tools',\n    author=u'Pierre Tardy',\n    author_email=u'tardyp@gmail.com',\n    url='http://buildbot.net/',\n    license='GNU GPL',\n    py_modules=['buildbot_pkg'],\n)\n", "path": "pkg/setup.py"}], "after_files": [{"content": "#!/usr/bin/env python\n#\n# This file is part of Buildbot.  Buildbot is free software: you can\n# redistribute it and/or modify it under the terms of the GNU General Public\n# License as published by the Free Software Foundation, version 2.\n#\n# This program is distributed in the hope that it will be useful, but WITHOUT\n# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS\n# FOR A PARTICULAR PURPOSE.  See the GNU General Public License for more\n# details.\n#\n# You should have received a copy of the GNU General Public License along with\n# this program; if not, write to the Free Software Foundation, Inc., 51\n# Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.\n#\n# Copyright Buildbot Team Members\n\nfrom setuptools import setup\nimport buildbot_pkg\n\nsetup(\n    name='buildbot-pkg',\n    version=buildbot_pkg.getVersion(\".\"),\n    description='Buildbot packaging tools',\n    author=u'Pierre Tardy',\n    author_email=u'tardyp@gmail.com',\n    url='http://buildbot.net/',\n    license='GNU GPL',\n    py_modules=['buildbot_pkg'],\n)\n", "path": "pkg/setup.py"}]}