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 [email protected] https://lists.linbit.com/mailman/listinfo/drbd-user
