-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Add Prometheus metric to track sql stmts per transaction #29
feat: Add Prometheus metric to track sql stmts per transaction #29
Conversation
* Added a new summary metric `transaction_exec_query_total` to track the number of exec querys per transaction * Introduced a new struct `managedTx` to to hold the context and connection of a transaction * Introduced a new field `execQueryCounter` in the `managedConn` to track the number of exec querys in a transaction. * When SQL lib opens a transaction we are storing the connection for that transacation and context of the transaction in the `managedTx`. * Context is used to store the required grpc labels for the metric. i.e. grpc method, grpc service * Added a UnaryInterceptor to the grpc server to store the grpc method and grpc service in the context * On commit or rollback of the transaction we are removing the connection from the `managedTx` and resetting the execQueryCounter to 0 * On commit of the transaction we are observing the `transaction_exec_query_total` metric by the number of exec querys in the transaction
sample metrics:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM but add some tests for this.
conn.go
Outdated
@@ -79,6 +86,7 @@ func (c *managedConn) ExecContext(ctx context.Context, query string, args []driv | |||
if !ok { | |||
return nil, driver.ErrSkip | |||
} | |||
c.incExecQueryCounter() //increment the exec counter to keep track of the number of exec calls |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The Exec() call above also needs an inc()
* Added two counter to track exec and query statements seperately. * UTs added for the same.
8aceee8
to
7f60ff2
Compare
Updated Metrics:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The naming convention is to suffix counters with _total
. Since this is a summary, I think stmnts
is the unit. I don't see any examples in the best practices of summaries named like counters. So naming might be like transaction_sql_stmts
:
transaction_sql_stmts_sum
transaction_sql_stmts_count
This doesn't seem related to hotload. I would like to see it as a separate module with a signature like dbmetrics.WrapDB(*sql.DB) *sql.DB
. (You can add other arguments and error
if it would be useful.) We can still wrap hotload if we want, but it would also be useful on its own.
It may be useful as a standalone module however, we need this to be enabled on sql.Open so that we minimize changes to app code. Not it all instances can apps wrap the created sql.DB object. |
Updated the name to |
transaction_sql_stmts
to track the number of exec/querys stmts executed per transactionmanagedTx
to to hold the context and connection of a transactionexecStmtsCounter
andqueryStmtsCounter
in themanagedConn
to track the number of exec querys in a transaction.managedTx
.managedTx
and resetting the counters to 0transaction_sql_stmts
metric by the number of exec/querys got exexuted in the transaction