How does one link graphs in?

[Linwood]

I'm confused by something.

It's very easy to see triggers overall (and/or to see event notifications with them).

It's very easy to go from there to "latest data" (for example) for a specific host.

And on latest data the ad-hoc graph is pretty nice. But sometimes you want a more complex graph. And it's very easy to define graphs.

But how does one handle easy navigation? One has to remember there is such a graph and follow a bit convoluted path to get to it. Maybe.

Is there a better way? Am I missing some way to get the graphs into the on-click context menus, perhaps? Some other path?

I've got a perl script for sending actual notifications, I'm thinking of trying to generate the associated graphs (any defined for the items in that trigger) into the email as a substitute, but that could be a lot of graphs. And there has to be a better way, right?

Right?

Postscript: I'm talking most specifically about linking to a RELEVANT graph. I realize there is a path to all graphs, but many templates have dozens of graphs; also about linking to a specific item on Latest Data to a better graph than the ad-hoc graph.

[BDiE8VNy]

Nope, there is currently no other way to access graphs beside:

• Monitoring -> Graphs
• Host menu -> Host inventory -> (Monitoring) Graphs
• Global search -> (Host) Graphs

Extending the Host menu by hyper-links to Custom graphs of the respective host should be pretty easy. But as you already mentioned there might be many. How to handle this properly?

[Linwood]

I realize on rereading this I was less than clear.

The primary area of interest is with respect to triggers. What I'd like is some way to define (or determine) the relationship between graphs and triggers.

So (for specific example) I have a time sensitive ping trigger, where the criteria varies by time of day (client who has a slow network at night). I have a graph showing the actual response and trigger level for the response.

If that trigger goes off, I'd like a quick path from the trigger to that specific graph, not necessarily all the graphs for the host, and not just the default from latest data showing the response alone (I can't make that graph show the trigger as the value is not fixed, right?)

It might be adequate to just show the graphs having items that are involved in the trigger, but even nicer would be to specify a specific graph associated with a trigger that one would want to see first to understand the trigger.

As a simple example -- if disk F:\\ shows disk space shortage, I'd like to go directly to a graph of disk F's percentage used over time.

[BDiE8VNy]

Access to Simple graphs for all in a trigger expression involved items is also possible via the trigger menu. But I presume you're referring to Custom graphs.

Doing the same for Custom graphs as it is already done for Simple graphs should be pretty easy to patch too.

[Linwood]

Access to Simple graphs for all in a trigger expression involved items is also possible via the trigger menu. But I presume you're referring to Custom graphs.

Doing the same for Custom graphs as it is already done for Simple graphs should be pretty easy to patch too.

Yes, custom.

Patch... yeah. I've so often just missed things though that I was hoping I was missing it here.

I need to look more into how to patch the code. I'm quite comfortable with the coding and language, but keeping it updated with new releases -- need to spend some time with SVN (I think it's SVN that zabbix uses, or whatever VC it is).

[BDiE8VNy]

Maybe consider to create a ZBXNEXT (if non of such already exists). There you could also attach your patch then

[Linwood]

Maybe consider to create a ZBXNEXT (if non of such already exists). There you could also attach your patch then

I'm happy to share if I get that far.

I assume all the ZBXNEXT does is make the request (and allow others to see it), it doesn't actually do anything to track the change against the trunk does it?

Or from looking at many of the old 1.x patches out there, writing the code doesn't appear to make it more likely to get included in the mainline code? Or does it?

But yes, will do so if I get ambitious enough to do that. Probably more likely to change a couple other things (I'm not a fan of the definition of "discovered" for example).

[BDiE8VNy]

Exactly, it's just a request. It becomes visible to other users and they can vote for it, add patches as well or even (co-)sponsor development.

Whether a ZBXNEXT or an attached patch gets implemented depends on several things.
One has to keep in mind that there is a Company behind that must make revenue to exist, pay their developers and to keep a "stable" product.
To implement a ZBXNEXT one must invest time for investigating the issue, making sure what the best implementation is, writing specifications and documentation, well and doing code review of a patch or/and development.
That's a lot (unpaid) time when done right.

So, as long as there are paid customer requests, it is unlikely that time is spend on other unpaid things instead. And if there might be time, then probably only on things of a big interest (e.g. votes). Btw, once a year participants of the Zabbix conference can vote from a list of ZBXNEXTs what gets implemented for free.

However, making ZBXNEXTs is the best way to indicate that there is something missing. Even when patches get not applied upstream they can be a blessing to people suffering from the same issue.

[Linwood]

However, making ZBXNEXTs is the best way to indicate that there is something missing. Even when patches get not applied upstream they can be a blessing to people suffering from the same issue.

While I've hijacked my own thread....

Does any of this work like github, where people's patches and/or separate branches are visible and can be tracked in some automated way?

So for example, if I like some substantial change someone made, does one pull it directly from the ZBXNEXT's content, or can these in some form become part of the source code and so more automatedly visible (and potentially, if the person is doing so, updated).

[BDiE8VNy]

No,since the upstream SVN repository is not intended for public access, the common practice is to attach patches to the respective Jira tickets.
Some people started an attempt to organize community patches. But afaik the work on that stalled unfortunately:

http://zabbix.org/wiki/Docs/github_project

Maybe join IRC channel #zabbix on freenode and poke people found in the history log of the previously mentioned site.

[Linwood]

I will. Thanks again for the insights.