For what it's worth: PNP in SINGLE mode will drop ANY sets of perfdata with a differing number of DS, regardless of order. If only the order (or meaning) changes, data WILL get mixed up in the RRD files' data rows. PNP in MULTIPLE mode accepts perfdata with changed number and/or order of DS and works correctly up to and including STORING the data. (One of the reasons why MULTIPLE is the default now.) PNP templates used in creation of graphs can refer to DS by number, name, or even both, so they may or may not work after DS got reordered. Note that even if the template recognizes the DS by name, chances are that the rrdgraph DEFs get reordered as well, leading to not-yet-defined errors there if the template does some calculus to combine DS data. n2rrd refers to DS exclusively by name, and the graph templates are effectively plain rrdgraph instruction files. As long as you got the "add DS to RRD files automatically" option turned on, it is very resilient to changes in the perfdata structure. (You'll get to see the occasional "new DS" introduced into an RRD file by mis-parsing, though.) NagiosGrapher tries to parse data out of perfdata AND OUTPUT with regexps. Corollary: New DS are introduced when the regexps get updated, not when the plugin starts to output the additional data. The most evil thing you can do to NagiosGrapher is to edit the text surrounding a "DS", or use texts that are not unique or otherwise hard/unstable to regexp-match. All performance data backends that I know have given up on insisting on the strict limitation of UOMs from the specs, and assume that UOM strings are BASIC units of measurement that they can add their prefixes to as they autoscale. (Which leads to stuff like graphs showing "MkB" instead of GB when the plugin outputs kB in the first place.) All this taken together: <ul> <li>The least disruptive way of adding new data is to append DS to the perfdata.</li> <li>(There's something to be said in favor of ordering DS in such a way that any DS required to properly interpret another appears BEFORE it, though.)</li> <li>Don't remove or rename DS. Ever. Publish graph templates hiding them if they have proven utter rubbish, but DON'T touch them or you'll fling the rubbish into everyone's face.</li> <li>Requiring the local admin to add a magic option before the newest and bestest set of DS appears protects him from the nuisances of having side effects to an update (which, given you follow the previous rules, will tend to be minor) - and simultaneously guarantees that you'll have to support EVERY version / use case to all eternity and keep seeing sites not using your plugin to its full capacity.</li> <li>Make your DS unitless, "c"ounters, or a basic unit (preferably an SI unit), but DON'T scale, much less automatically (and thus differently from one run to the next).</li> </ul> — Reply to this email directly or <a href='https://github.com/nagios-plugins/nagios-plugins/pull/1201#issuecomment-26335971'>view it on GitHub</a>.<img src='https://github.com/notifications/beacon/_EHT0K2RMtzboqJPrl-P-GoZb4rVkzZVJ9JC3gllATFsnmYdvzP2vmImxiWPtdfI.gif' height='1' width='1'>