You are viewing a plain text version of this content. The canonical link for it is here.
Posted to scimple@directory.apache.org by Kyle Thorpe <kt...@proofpoint.com.INVALID> on 2023/03/29 01:40:54 UTC

Issues with Splunk OTEL Collector and Spring Boot/Jersey

Good afternoon everyone!

My organization is deploying a SCIM server that uses Spring Boot alongside Jersey. This is required because of SCIMple using Jersey endpoints for Groups/Users, but our usual infrastructure supports Spring Boot based APIs.

In a local K8s cluster, we were able to run the pod just fine. But, when deploying to our K8s cluster, the readiness/liveness probes failed (we received 404s on those endpoints) and the pod entered a CrashLoopBackoff state. The liveness/readiness probes are set up using Spring Actuator.

However, we were able to deploy the application to the cluster when we disabled our OTEL Agent that sends metrics to Splunk. We do not see any port conflict with the OTEL Agent and the application. As far as we can tell, there may be some sort of conflict between the agent and Jersey, but we are stumped as to what.

Some of the relevant application.properties:

# These application properties allow Spring Boot Actuator to handle `/api/scim/actuator/*` requests,
# while `/api/scim/v2/*` requests will be handled by the SCIM Server and SCIMple using Jersey
server.servlet.context-path=/api/scim
spring.jersey.application-path=/v2

management.endpoints.web.exposure.include=*
management.endpoint.health.show-details=when-authorized
management.endpoint.health.show-components=when-authorized
management.info.git.mode=full
management.endpoint.health.probes.enabled=true
management.health.livenessState.enabled=true
management.health.readinessState.enabled=true
management.endpoint.health.group.readiness.include=readinessState
management.endpoint.health.group.liveness.include=livenessState

Has anyone faced similar issues with OpenTelemetry and SpringBoot/Jersey applications?