Revise and Test the Concepts

Review of the chapter #

• For any but the smallest systems, going from one resource to another and from one node to another to find the cause of an issue is anything but practical, reliable, or fast.

• More often than not, the kubectl logs command does not provide us with enough options to perform anything but the simplest retrieval of logs.

• Elasticsearch is excellent, but it does too much. Its lack of focus makes it inferior to Prometheus for storing and querying metrics, as well as sending alerts based on such data.

• Logs themselves are too expensive to parse, and most of the time they do not provide enough data to act as metrics.

• We need logs centralized in a single location so that we can explore logs from any part of the system.

• We need a query language that allows us to filter log messages.

• We need the solution to be fast.

• Use a service provided by your Cloud provider, unless it is more expensive than alternatives. If your cluster is on-prem, use a third-party service like Papertrail, unless there are rules that prevent you from sending logs outside your internal network. If everything else fails, use EFK.

• We should start exploring logs only when metrics reveal the culprit but not the cause of the issue.

Remove the previous resources #

You know what to do. Destroy the cluster if you created it specifically for this chapter.