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: README.md
+49-9
Original file line number
Diff line number
Diff line change
@@ -51,6 +51,7 @@ Services will be exposed in this ports
51
51
```
52
52
Api Gateway Service : 8765
53
53
Eureka Discovery Service : 8761
54
+
Consul Discovery : 8500
54
55
Account Service : 4001
55
56
Billing Service : 5001
56
57
Catalog Service : 6001
@@ -59,6 +60,17 @@ Order Service : 7001
59
60
60
61
<hr>
61
62
63
+
### Service Discovery
64
+
This project uses Eureka or Consul as Discovery service.
65
+
66
+
While running services in local, then using eureka as service discovery.
67
+
68
+
While running using docker, then consul is the service discovery.
69
+
70
+
Reason to use Consul is it has better features and support compared to Eureka. Running services individually in local uses Eureka as service discovery because dont want to run consul agent and set it up as it becomes extra overhead to manage. Since docker-compose manages all consul stuff hence using Consul while running services in docker.
71
+
72
+
<hr>
73
+
62
74
### Troubleshooting
63
75
64
76
If any issue while starting up services or any api failing.
@@ -88,28 +100,39 @@ Below is the AWS Architecture diagram for better understanding.
88
100
<hr>
89
101
90
102
## Monitoring
91
-
Using Docker images of Prometheus, Graphana and Zipkin for monitoring microservices,
92
-
using docker images makes setting up graphana, zipkin, prometheus very easy. Just run docker images of those and
93
-
send or pull metrics from monitoring containers.
103
+
There are 2 setups for monitoring
94
104
95
-
`docker-compose` will take care of bringing all this monitoring containers up.
105
+
1. Prometheus and Graphana.
106
+
2. TICK stack monitoring.
107
+
108
+
Both the setups are very powerful, where prometheus works on pull model. we have to provide target hosts where the prometheus can pull the metrics from. If we specify target hosts using individual hostname/ip its not feasible at end because it will be like hard coded hostnames/ip. So we use Consul discovery to provide target hosts dynamically. By this way when more instances added for same service no need to worry about adding to prometheus target hosts because consul will dynamically add this target in prometheus.
96
109
97
-
More details at this link : https://www.callicoder.com/spring-boot-actuator-metrics-monitoring-dashboard-prometheus-grafana/
110
+
TICK(Telegraf, InfluxDB, Chronograf, Kapacitor) This setup is getting more attention due to its push and pull model. InfluxDB is a time series database, bookstore services push the metrics to influxDB(push model), In Telegraf we specify the targets to pull metrics(pull model). Chronograf/Graphana can be used to view the graph/charts. Kapacitor is used to configure rules for alarms.
111
+
112
+
`docker-compose` will take care of bringing all this monitoring containers up.
98
113
99
114
Dashboards are available at below ports
100
115
101
116
```
102
117
Graphana : 3030
103
118
Zipkin : 9411
104
119
Prometheus : 9090
120
+
Telegraf : 8125
121
+
InfluxDb : 8086
122
+
Chronograf : 8888
123
+
Kapacitor : 9092
124
+
105
125
```
106
126
107
-
**Screenshots of Monitoring in Graphana.**
127
+
```
128
+
First time login to Graphana use below credentials
0 commit comments