Skip to content
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

Add metrics for subscriptions and WebSocket sessions #944

Open
nlemoing opened this issue Apr 5, 2024 · 3 comments
Open

Add metrics for subscriptions and WebSocket sessions #944

nlemoing opened this issue Apr 5, 2024 · 3 comments
Assignees
Labels
in: web Issues related to web handling type: enhancement A general enhancement
Milestone

Comments

@nlemoing
Copy link

nlemoing commented Apr 5, 2024

Hi! I'm trying to follow the Observability instructions to get GraphQL actuator metrics published. We're using a Datadog StatsD sidecar container, so I've added the following dependencies to my classpath:

  • org.springframework.boot:spring-boot-starter-web, version 3.2.2
  • org.springframework.boot:spring-boot-starter-graphql, version 3.2.2
  • org.springframework.boot:spring-boot-starter-actuator, version 3.2.2
  • org.springframework.boot:spring-boot-starter-websocket, version 3.2.2
  • io.micrometer:micrometer-registry-statsd, version 1.12.1

I didn't do any additional configuration or create any additional beans.

To see what metrics were available, I set management.endpoints.web.exposure.include=* and went to /actuator/metrics, but didn't see any GraphQL metrics.

I have two questions:

  • Is there a configuration I'm missing, or am I looking in the wrong place for GraphQL metrics?
  • I was looking at the predecessor project, graphql-spring-boot, and found references to Websocket metrics like graphql.websocket.sessions. Do those metrics still exist in the current version of the library?
@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Apr 5, 2024
@nlemoing nlemoing changed the title Enabling GraphQL Actuator Metrics for WebSockets [Question] Enabling GraphQL Actuator Metrics for WebSockets Apr 8, 2024
@sgrannan
Copy link

sgrannan commented Apr 11, 2024

@nlemoing We migrated from the graphql-kickstart project as well and I could not find anything. I had to implement my own ConcurrentHashMap that tracked sessions with my own custom Gauge using afterConnectionEstablished and afterConnectionClosed extended from the GraphQLWebSocketHandler

// Simple Metric for active connections Gauge.builder( AppConstants.CustomMetrics.WEBSOCKETS_ACTIVE_SESSIONS, this::getActiveSessions ).strongReference(true).register(Metrics.globalRegistry);

@nlemoing
Copy link
Author

@sgrannan Thanks for the tip! I tried to use WebSocketGraphQlInterceptor to build my own metrics as well but it seems it was under-reporting connection close events. I think it might've under-reported because we were doing a stress test on the server and instances that were shutting down didn't report that their WebSocket connections were closing.

@bclozel bclozel added type: enhancement A general enhancement in: web Issues related to web handling and removed status: waiting-for-triage An issue we've not yet triaged labels Apr 12, 2024
@bclozel bclozel added this to the 1.3 Backlog milestone Apr 12, 2024
@bclozel
Copy link
Member

bclozel commented Apr 12, 2024

Hello @sgrannan and @nlemoing

Thanks for this report and the discussion so far. I agree, this feature is currently missing in Spring for GraphQL and we should have a look at it. So far, we have instrumented the GraphQL engine with a graphql-java Instrumentation so that you'll get observations (timer metrics and traces) for requests and data fetching operations.

For such metrics, we can't depend on the Observation API because it only covers timers. For gauges and counters, we'll need the Metrics API and we must make that an optional dependency. We should look into providing a MeterBinder for active sessions. Something like what's provided by Micrometer for Netty allocators, for example.

In the case of active WebSocket sessions, we could expose the information on the WebSocket handler directly and make the binder quite straightforward. As for the subscriptions count, it's a different story since subscriptions can happen over multiple transports (SSE, WebSocket, RSocket) - ideally, a single metric should count them all and they should be tagged by transport.

I'll schedule this for the 1.3.x generation and I'll report back here after investigating a bit.

@bclozel bclozel self-assigned this Apr 12, 2024
@bclozel bclozel changed the title [Question] Enabling GraphQL Actuator Metrics for WebSockets Add metrics for subscriptions and WebSocket sessions Apr 12, 2024
@rstoyanchev rstoyanchev modified the milestones: 1.3 Backlog, 1.x Backlog May 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: web Issues related to web handling type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

5 participants