Skip to content

Commit

Permalink
TODO List - New ideas
Browse files Browse the repository at this point in the history
  • Loading branch information
Patricio Bruna committed Apr 17, 2013
1 parent 5192478 commit d183cd1
Showing 1 changed file with 15 additions and 0 deletions.
15 changes: 15 additions & 0 deletions TODO.md
@@ -0,0 +1,15 @@
_This TODO list is based on the input of Rubén Romero._

* Show metrics for each Backend
* Show metrics for each Director
* A way to select diferent Varnish Agent if we have more than one Varnish Cache
* A way to auto-discover Varnish Agent on the network (should be a patch to VA2)

Ideas and examples:
* HA Proxy: http://demo.1wt.eu/
* Apache mod_status: http://www.cyberciti.biz/faq/apache-server-status/
* Lighttpd server status: http://www.freakcode.com/projects/pretty-lighty-status-page
* Varnish Status: https://github.com/huayra/libvmod-status
* Ideas from Varnish (pages 15 - 18): https://www.varnish-cache.org/sites/default/files/VUG5%20-%20Introductions_0.pdf

If you have any other idea, please fork and make a pull request, or send me an email.

3 comments on commit d183cd1

@huayra
Copy link

@huayra huayra commented on d183cd1 Apr 17, 2013

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Patricio, you have done a great job creating this shiny dashboard.

As much as I like this ToDo list I think it is important to remember that the Agent (and hence your Dashboard) is designed as a window into your Varnish Cache server and to be on a single server only. Doing additions to it at that level is low-hanging fruit and should be the focus of your development as that is where you will have quick wins (as you already have :-)

On top of the agent you can build a system that can see multiple Varnish servers (we do, as it is designed to be the Agent for VAC), but extending the agent itself to do that might require changes in the architecture of the software, although a module might be an option if you want to go that road.

Quoting from Kristian's blog:

http://kly.no/posts/2013_02_15_The_Architecture_the_Varnish_Agent.html

[...]
The Varnish Agent 2 was written as a replacement for the original Varnish Agent. They both share the same purpose: Expose node-specific Varnish features to a management system. They are design very differently, though.
[...]
==Requirements==

When designing a new system, it's important to know what you're trying to achieve, and perhaps just as important to know what you're /not/ trying to achieve.

The Varnish Agent is designed to:

Manage a single Varnish server.
Remove the need for management frontends to know the Varnish CLI language.
Expose log data
Persist configuration changes
Require "0" configuration of the agent itself
Ensure that Varnish works on boot, even if there is no management front-end present.
Be expandable without major re-factoring.
Be easy to expand

What we did NOT want was:

Support for running the agent on a different machine than the Varnish server.
Elaborate self-management of the agent (e.g: support for users, and management of them).
Mechanisms that are opaque to a system administrator
Front-end code mixed with back-end code
"Sessions"
[...]

@pbruna
Copy link

@pbruna pbruna commented on d183cd1 Apr 17, 2013

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ruben,
I get your points and i will work on a better plan that goes on a direction that you (Varnish Software) are confortable with.

Besides the tasks listed in the TODO, i've been thinking that the Dashboard should expose historic metrics and logs, but this would require other kind of work, like:

  • Write a vmod to send the metrics and logs (I know there is one that do something like this)
  • Write a backend to process the metrics/logs
  • Store the metrics: maybe MongoDB with capped collections
  • Store the logs: Elasticsearch
  • Extend the Dashboard to analyze this information

I know this is another kind of beast, but i would like to know your input on this idea and if it is something that would be useful and does not interfere with your (Varnish Software) goals.

@huayra
Copy link

@huayra huayra commented on d183cd1 Apr 17, 2013

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well this is open source, which means that the one that does the work decides what is done and the direction a project or a patch takes :-)

As an example, the Varnish agent could theoretically provide a Hyperic agent (or server) with enough data to monitor a Varnish server, as it is designed to provide data as it does already read the SHMlog, so it is a data source as much as it is an API similar to varnishadm, but in a Restful fashion. I think you get my point.

If what you want is a historic monitoring and trend analyzing tool, Munin could be what you are looking for. Historic and Real-time tools are VERY different beasts.

My remark was in the context of the dashboard as a patch to the agent (which per definition is a per individual Varnish aid tool). If what you want is to create a super dashboard for Varnish as the one you describe, go for it. You do not need permission to do that, but do make sure to check what others projects are up to. There is a lot going if you look around.

Please sign in to comment.