You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CHANGELOG.md
+3Lines changed: 3 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,6 +4,9 @@ All notable changes to this project will be documented in this file.
4
4
The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/).
5
5
6
6
## [Unreleased]
7
+
### Added
8
+
- New metric `check_permissionship_total` for CheckPermission and CheckBulkPermissions that counts the number of requests that returned HAS_PERMISSION. Also, `write_relationships_updates` also includes BulkImport calls (https://github.com/authzed/spicedb/pull/3240)
9
+
7
10
### Changed
8
11
- Schema: reads inside write transactions now use a cheap hash-only lookup (`schema_revision`) to check the cache before loading the full schema blob, reducing DB round-trips on cache hits (https://github.com/authzed/spicedb/pull/3160)
9
12
- Updated the Prometheus buckets for `grpc_server_handling_seconds` and `spicedb_datastore_query_latency` to be able to correlate them (https://github.com/authzed/spicedb/pull/3188)
"description": "Average logical checks per second across all APIs. Counts each item within a CheckBulk and each result returned from LookupResources/LookupSubjects separately. This measures workload intensity independently of gRPC RPS — a single LookupResources call can account for hundreds of logical checks.",
529
+
"description": "Average logical checks per second across all APIs. Counts each item within a CheckBulk and each result returned from LookupResources/LookupSubjects separately. This measures workload intensity independently of gRPC RPS \u2014 a single LookupResources call can account for hundreds of logical checks.",
530
530
"fieldConfig": {
531
531
"defaults": {
532
532
"color": {
@@ -700,6 +700,101 @@
700
700
"title": "Avg Consistency Mode Distribution",
701
701
"type": "timeseries"
702
702
},
703
+
{
704
+
"datasource": {
705
+
"type": "prometheus",
706
+
"uid": "prometheus"
707
+
},
708
+
"description": "Percentage of check results (CheckPermission and CheckBulkPermissions, each bulk item counted individually) that return HAS_PERMISSION, aggregated across all instances. CONDITIONAL_PERMISSION and NO_PERMISSION results count toward the denominator. Only successful checks are counted; errored checks are excluded.",
"description": "Cache hit ratio for each dispatch operation type, split by dispatcher layer. High ratios (>80%) for check operations are expected under steady workloads. Low ratios indicate cache churn, highly diverse queries, or an undersized cache. Per-instance variance is expected and normal: the dispatch cache is local in-process (not shared across instances), and every cache key is scoped to a specific revision — so any write that advances the revision causes all instances to miss on subsequent requests until they re-warm at the new revision. Instances that recently restarted or received the first requests after a revision bump will show lower ratios than instances with a warm cache at a stable revision.",
999
+
"description": "Cache hit ratio for each dispatch operation type, split by dispatcher layer. High ratios (>80%) for check operations are expected under steady workloads. Low ratios indicate cache churn, highly diverse queries, or an undersized cache. Per-instance variance is expected and normal: the dispatch cache is local in-process (not shared across instances), and every cache key is scoped to a specific revision \u2014 so any write that advances the revision causes all instances to miss on subsequent requests until they re-warm at the new revision. Instances that recently restarted or received the first requests after a revision bump will show lower ratios than instances with a warm cache at a stable revision.",
905
1000
"fieldConfig": {
906
1001
"defaults": {
907
1002
"color": {
@@ -1050,7 +1145,7 @@
1050
1145
"type": "prometheus",
1051
1146
"uid": "prometheus"
1052
1147
},
1053
-
"description": "p99 of the number of chunks dispatched per Check request. Each chunk holds up to dispatch-chunk-size subjects (default: 100) and is processed in parallel. A value of N means the check fanned out to N×chunk-size subjects of the same type. Consistently high values indicate broad permission checks with large subject fan-out.",
1148
+
"description": "p99 of the number of chunks dispatched per Check request. Each chunk holds up to dispatch-chunk-size subjects (default: 100) and is processed in parallel. A value of N means the check fanned out to N\u00d7chunk-size subjects of the same type. Consistently high values indicate broad permission checks with large subject fan-out.",
1054
1149
"fieldConfig": {
1055
1150
"defaults": {
1056
1151
"color": {
@@ -1155,7 +1250,7 @@
1155
1250
"h": 1,
1156
1251
"w": 24,
1157
1252
"x": 0,
1158
-
"y": 56
1253
+
"y": 64
1159
1254
},
1160
1255
"id": 42,
1161
1256
"panels": [
@@ -1164,7 +1259,7 @@
1164
1259
"type": "prometheus",
1165
1260
"uid": "prometheus"
1166
1261
},
1167
-
"description": "Hit ratio per cache, from spicedb_cache_hits_total and spicedb_cache_misses_total. Three caches emit metrics:\n\n• namespace (32MiB): caches parsed namespace and caveat definitions. Should be near 100% — schemas change infrequently. A sustained drop means schema writes are frequent or the cache is undersized.\n\n• dispatch (default: 30% of free memory): caches sub-problem results for dispatches this node sends out (outbound). Revision-scoped — every write that advances the revision invalidates prior entries.\n\n• cluster_dispatch (default: 70% of free memory): caches sub-problem results for dispatches this node receives from other nodes (inbound). Also revision-scoped. Larger by default because in a multi-node cluster this node handles a proportionally larger share of inbound sub-problems.",
1262
+
"description": "Hit ratio per cache, from spicedb_cache_hits_total and spicedb_cache_misses_total. Three caches emit metrics:\n\n\u2022 namespace (32MiB): caches parsed namespace and caveat definitions. Should be near 100% \u2014 schemas change infrequently. A sustained drop means schema writes are frequent or the cache is undersized.\n\n\u2022 dispatch (default: 30% of free memory): caches sub-problem results for dispatches this node sends out (outbound). Revision-scoped \u2014 every write that advances the revision invalidates prior entries.\n\n\u2022 cluster_dispatch (default: 70% of free memory): caches sub-problem results for dispatches this node receives from other nodes (inbound). Also revision-scoped. Larger by default because in a multi-node cluster this node handles a proportionally larger share of inbound sub-problems.",
1168
1263
"fieldConfig": {
1169
1264
"defaults": {
1170
1265
"color": {
@@ -1295,7 +1390,7 @@
1295
1390
"h": 1,
1296
1391
"w": 24,
1297
1392
"x": 0,
1298
-
"y": 57
1393
+
"y": 65
1299
1394
},
1300
1395
"id": 30,
1301
1396
"panels": [
@@ -1583,7 +1678,7 @@
1583
1678
"type": "prometheus",
1584
1679
"uid": "prometheus"
1585
1680
},
1586
-
"description": "p99 of the number of relationship updates per WriteRelationships call, split by update kind (CREATE, TOUCH, DELETE). Large batches (>1000) can cause write amplification and lock contention in the datastore.",
1681
+
"description": "p99 of the number of relationship updates per write call, split by update kind (CREATE, TOUCH, DELETE). Includes WriteRelationships calls and bulk imports (ImportBulkRelationships and the deprecated BulkImportRelationships), whose imported relationships are counted as CREATE. Large batches (>1000) can cause write amplification and lock contention in the datastore. Uses the metric's native histogram representation, which has no bucket cap, so large bulk imports report accurate percentiles.",
"description": "Ratios (0–1) reflecting Spanner session pool health. max_allowed_sessions_ratio approaching 1 means the pool is near its configured limit. max_in_use_sessions_ratio shows peak concurrent session usage. num_sessions_in_pool_ratio and open_session_count_ratio show current utilization.",
3363
+
"description": "Ratios (0\u20131) reflecting Spanner session pool health. max_allowed_sessions_ratio approaching 1 means the pool is near its configured limit. max_in_use_sessions_ratio shows peak concurrent session usage. num_sessions_in_pool_ratio and open_session_count_ratio show current utilization.",
3269
3364
"fieldConfig": {
3270
3365
"defaults": {
3271
3366
"color": {
@@ -3389,7 +3484,7 @@
3389
3484
"type": "prometheus",
3390
3485
"uid": "prometheus"
3391
3486
},
3392
-
"description": "Rate of Spanner sessions acquired and released from the pool, plus the rate of GFE (Google Front End) responses missing the server-timing header — a non-zero gfe_header_missing_count may indicate requests bypassing the GFE or connectivity issues.",
3487
+
"description": "Rate of Spanner sessions acquired and released from the pool, plus the rate of GFE (Google Front End) responses missing the server-timing header \u2014 a non-zero gfe_header_missing_count may indicate requests bypassing the GFE or connectivity issues.",
0 commit comments