Liveness : Checks if the microservice is alive, that is, if it’s able to accept requests and respond.
•
Readiness : Checks if the microservice’s dependencies (Database, queue services, etc.) are
themselves ready, s
o the microservice can do what it’s supposed to do.
Using diagnostics and logs event streams Logs provide information about how an application or service is running, including exceptions,
warnings, and simple informational messages. Usually, each log is in a text format with one line per
event, although exceptions also often show the stack trace across multiple lines.
In monolithic server-based applications, you can write logs to a file on disk (a logfile) and then analyze
it with any tool. Since applicatio
n execution is limited to a fixed server or VM, it generally isn’t too
complex to analyze the flow of events. However, in a distributed application where multiple services
are executed across many nodes in an orchestrator cluster, being able to correlate distributed events
is a challenge.
A microservice-based application should not try to store the output stream of events or logfiles by
itself, and not even try to manage the routing of the events to a central place. It should be
transparent, meaning that each process should just write its event stream to a standard output that
underneath will be collected by the execution environment infrastructure where it’s running. An
example of these event stream routers is
Microsoft.Diagnostic.EventFlow
, which collects event streams
from multiple sources and publishes it to output systems. These can include simple standard output
for a development environment or cloud systems like
Azure Monitor
and
Azure Diagnostics
. There are
also good third-party log analysis platforms and tools that can search, alert, report, and monitor logs,
even in real time, like
Splunk
.
65
CHAPTER 3 | Architecting container and microservice-based applications
