Mailing List Archive

which tool should I use for scripting?
Hi:
we have some scripts for monitoring drbd status. they are broken
after upgrading from 8.4 to 9.0. we use command below:

"cat /proc/drbd" => it is useless now.

drbdadm role => format changed. used to return like
"Primary/Secondary" but now only return "Primary" for current node.

"drbdadm dstate","drbdadm status" => still reporting correct status
for two nodes. but I don't know if they will change soon with
multiple nodes in the future.

drbdsetup event2 => new command. but I don't know if the output format
will be consistent after upgrading. the function of the command seems
change a lot with every update.

which tool should I rely in the future? will "drbdadm status" stable
or I should monitor "drbdsetup events2"?

thanks a lot for help!!
_______________________________________________
Star us on GITHUB: https://github.com/LINBIT
drbd-user mailing list
drbd-user@lists.linbit.com
https://lists.linbit.com/mailman/listinfo/drbd-user
Re: which tool should I use for scripting? [ In reply to ]
On Thu, Mar 11, 2021 at 01:42:33PM +0800, d tbsky wrote:
> Hi:
> we have some scripts for monitoring drbd status. they are broken
> after upgrading from 8.4 to 9.0. we use command below:
>
> "cat /proc/drbd" => it is useless now.

Yes, it simply did not scale for multiple nodes. You should not rely on
it.

> drbdadm role => format changed. used to return like
> "Primary/Secondary" but now only return "Primary" for current node.

Yeah, that inconsistency is unfortunate. There has not been any real
discussion on how/if that should get fixed or if we have to keep it as
is because people rely on it... "It's complicated"...

> "drbdadm dstate","drbdadm status" => still reporting correct status
> for two nodes. but I don't know if they will change soon with
> multiple nodes in the future.

If they already work for multiple nodes (which most of the commands
really should then we don't (try very hard) break them.

> drbdsetup event2 => new command. but I don't know if the output format
> will be consistent after upgrading. the function of the command seems
> change a lot with every update.

We introduce new "key:value" pairs, and we even introduce new
functionality like the differential "from->to" output (behind a new
flag!), but I can not remember that we changed the semantic of an
existing key or that we removed one in the default mode. Too many of our
own tools rely on it (LINSTOR has events2 parsing, drbdd,...). Do *not*
rely on the order of key:value pairs, I expect parsers to be able to
handle that they show up in an arbitrary order. grep "thiskey:foo
thatkey:bar" can break, again no guarantee about k:v ordering.

> which tool should I rely in the future? will "drbdadm status" stable
> or I should monitor "drbdsetup events2"?

IMO drbdsetup events2 and drbdsetup status --json are good candidates
that we don't break just for fun, actually the opposite, we really try
to not break them. "status --json" has the advantage, that well, it is
already json and not something self invented. For events2 you would need
to write some "parser" and if it only is grep to process events.

Being biased, I'd say for "serious monitoring" you should eventually use
one of drbdd's plugins, I expect prometheus.io integration very soon.
For hackish self written scripts: events2, better 'status --json'. It
depends how you monitoring looks like. If you just try to detect state
changes like a resource is disconnected, or that the disk state changes
from "foo" to "bar", that will land in drbdd very soon. I hope to
release RC1 early next week. Then you will be able to write rules for
almost arbitrary DRBD event changes like this:
[[umh]]
[[umh.resource]]
name = "resource now primary"
command = "/usr/local/bin/primary.sh"
resource-name = "foo"
old.role = "Secondary"
new.role = "Primary"

HTH, rck
_______________________________________________
Star us on GITHUB: https://github.com/LINBIT
drbd-user mailing list
drbd-user@lists.linbit.com
https://lists.linbit.com/mailman/listinfo/drbd-user
Re: which tool should I use for scripting? [ In reply to ]
Roland Kammerer <roland.kammerer@linbit.com>
> > which tool should I rely in the future? will "drbdadm status" stable
> > or I should monitor "drbdsetup events2"?
>
> IMO drbdsetup events2 and drbdsetup status --json are good candidates
> that we don't break just for fun, actually the opposite, we really try
> to not break them. "status --json" has the advantage, that well, it is
> already json and not something self invented. For events2 you would need
> to write some "parser" and if it only is grep to process events.
>
> Being biased, I'd say for "serious monitoring" you should eventually use
> one of drbdd's plugins, I expect prometheus.io integration very soon.
> For hackish self written scripts: events2, better 'status --json'. It
> depends how you monitoring looks like. If you just try to detect state
> changes like a resource is disconnected, or that the disk state changes
> from "foo" to "bar", that will land in drbdd very soon. I hope to
> release RC1 early next week. Then you will be able to write rules for
> almost arbitrary DRBD event changes like this:
> [[umh]]
> [[umh.resource]]
> name = "resource now primary"
> command = "/usr/local/bin/primary.sh"
> resource-name = "foo"
> old.role = "Secondary"
> new.role = "Primary"

thanks a lot for the detailed explanation!

it's amazing what drbdd can do. I need to think about what can we do
with this capability.
some of our scripts are working under pacemaker to add specific
functions for our need.
I think I will use "drbdsetup status --json" to rewrite them.

thanks again for your kindly help!
_______________________________________________
Star us on GITHUB: https://github.com/LINBIT
drbd-user mailing list
drbd-user@lists.linbit.com
https://lists.linbit.com/mailman/listinfo/drbd-user