Add Prometheus registry and deployment tags for blue-green monitoring

[subsub97]

This pull request introduces several improvements related to application monitoring, metrics, and deployment management. The changes add enhanced metrics collection and tagging, enable additional actuator endpoints, and update the deployment scripts to support separate management ports for blue/green deployments.

Metrics and Monitoring Enhancements:

• Added a new configuration class MetricsConfig.kt to set common tags (application, deploy_color, app_version) for all exported metrics, improving observability and traceability.
• Updated application-prod.yml and application.yml to expose additional actuator endpoints (health, info, prometheus) and to always show health details, making it easier to monitor and debug the application. [1] [2]
• Enabled percentiles histogram for HTTP server request metrics in application-prod.yml for better performance analysis.

Deployment and Blue/Green Management:

• Modified the deployment script (deploy.sh) and Dockerfile to support separate management ports (8090/8091) for blue/green deployments, ensuring health checks and management endpoints are isolated and do not conflict. [1] [2] [3] [4]
• Updated application.yml to define the application name as moa, which is now used in metrics tagging.

These changes collectively improve the application's observability and make blue/green deployments more robust and easier to monitor.

[github-actions]

Test Results

53 tests   53 ✅  0s ⏱️
 6 suites   0 💤
 6 files     0 ❌

Results for commit bd87947.

♻️ This comment has been updated with latest results.

[Copilot]

Pull request overview

Adds Prometheus support and consistent metrics tagging, and updates blue/green deployment plumbing to isolate management/actuator traffic onto separate ports for improved monitoring.

Changes:

• Add Micrometer MeterRegistryCustomizer to apply common metric tags (application, deploy_color, app_version).
• Update Spring Boot management/actuator configuration (endpoint exposure, health details, Prometheus, HTTP request histograms; prod gets configurable management port).
• Update deployment script + container metadata to support separate management ports for blue/green deployments.

Reviewed changes

Copilot reviewed 5 out of 6 changed files in this pull request and generated 5 comments.

Show a summary per file

File	Description
src/main/resources/application.yml	Sets spring.application.name and broadens actuator exposure + health details globally.
src/main/resources/application-prod.yml	Adds configurable management port, expands exposed endpoints, enables histogram for HTTP server metrics.
src/main/kotlin/com/moa/common/config/MetricsConfig.kt	Introduces common Micrometer tags for all exported metrics.
scripts/deploy.sh	Adds management-port-aware container run + health check routing for blue/green.
build.gradle.kts	Adds Prometheus registry dependency.
Dockerfile	Exposes additional ports intended for management endpoints.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

management.endpoint.health.show-details: always and broad endpoint exposure in the shared application.yml means all environments (unless explicitly overridden) will expose detailed health info + /actuator/metrics//actuator/prometheus to any reachable client. This project does not appear to use Spring Security, so show-details=when_authorized won’t have any effect. Consider tightening the defaults (e.g., show-details: never and a minimal include list in the base config) and only enabling detailed health / extra endpoints in environments where the management interface is network-restricted (or moved to a separate management port/address).

Suggested change

	include: health,info,metrics,prometheus
	endpoint:
	health:
	show-details: always
	include: health,info
	endpoint:
	health:
	show-details: never

[subsub97]

내부 접근에서만 접근 가능한 엔드포인트에용

[Copilot]

In prod, management.endpoint.health.show-details: always will expose potentially sensitive dependency/status information to anyone who can reach the management port. Since there’s no Spring Security in the dependency graph, this is effectively unauthenticated. Consider setting show-details: never (or restricting access via network controls such as management.server.address: 127.0.0.1 / firewall rules) so production health details aren’t publicly readable.

Suggested change

	show-details: always
	show-details: never

[Copilot]

PR description says metrics endpoint is exposed in application-prod.yml, but the include list here is health,info,prometheus (no metrics). Either update the prod exposure list to match the intended endpoints or adjust the PR description so it reflects the actual behavior.

[Copilot]

The log line says the health check is waiting on ${NEXT_PORT}, but the script actually curls the management port (${NEXT_MGMT_PORT}). This is confusing during incident/debugging; update the message to reference the correct port (or print both app + management ports).

Suggested change

	echo "[Step 4] Waiting for health check on port ${NEXT_PORT}..."
	echo "[Step 4] Waiting for health check on management port ${NEXT_MGMT_PORT} (app port: ${NEXT_PORT})..."

[Copilot]

Exposing both 8090 and 8091 in the image metadata can lead to accidental publication of management endpoints (e.g., when running with -P or certain Compose defaults), even though only one management port is used at runtime. Consider not exposing management ports in the Dockerfile (rely on explicit -p mappings), or constrain the management interface via management.server.address so it can’t bind externally.

Suggested change

	EXPOSE 8080 8090 8091
	EXPOSE 8080