[DRBD-user] which tool should I use for scripting?

[Roland Kammerer]

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