concourse / concourse/concourse-chart
concourse 6.0 service monitor is not auto discoverd by prometheus operator
Nobody has claimed this yet.
- Dominant language
- Mustache
- Stars
- 160
- Forks
- 189
- PR merge metrics
- No merged PRs in 30d
Description
Hello Colleagues,
I have enabled the Prometheus monitor as well as a scrapper. The concourse is running in my default namespace and Prometheus operator is running in monitoring namespace.
Not sure why the service monitor is not auto-discovered by the Prometheus Operator.
@
prometheus:
enabled: true
## IP to listen on to expose Prometheus metrics.
##
bindIp: "0.0.0.0"
## Port to listen on to expose Prometheus metrics.
##
bindPort: 9391
## If Prometheus operator is used, also create a servicemonitor object
serviceMonitor:
enabled: true
interval: "30s"
# Namespace the servicemonitor object should be in
namespace: monitoring
@KYannick can you help with this issue ? Am i missing anythig ?
BRs, Gowrisankar
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by rendering the Helm chart with the provided Prometheus and ServiceMonitor values, then inspect whether the ServiceMonitor is created in the monitoring namespace and whether the Prometheus Operator can select it across namespaces. Done means the generated ServiceMonitor is discovered by the Prometheus Operator and Concourse metrics appear.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- helm, kubernetes, prometheus
- Domain
- devops, infrastructure, observability
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100