metrics from various application containers into one standard format and protocol. In Figure 16-1, an  Adapter  container translates locally stored metrics information into the external format the monitoring server understands. With this approach, every service represented by a Pod, in addition to the main appli‐ cation container, would have another container that knows how to read the custom application-specific metrics and expose them in a generic format understandable by the monitoring tool. We could have one  Adapter  container that knows how to export Java-based metrics over HTTP, and another   container in a different Pod that exposes Python-based metrics over HTTP. For the monitoring tool, all metrics would be available over HTTP, and in a common normalized format. For a concrete implementation of this pattern, let’s revisit our sample random genera‐ tor application and create the adapter shown in Figure 16-1. When appropriately configured, it writes out a log file with the random-number generator, and includes the time it took to create the random number. We want to monitor this time with Prometheus. Unfortunately, the log format doesn’t match the format Prometheus expects. Also, we need to offer this information over an HTTP endpoint so that a Prometheus server can scrape the value. For this use case, an  Adapter  is a perfect fit: a  Sidecar  container starts a small HTTP server, and on every request, reads the custom log file and transforms it into a Prometheus-understandable format. Example 16-1 shows a Deployment with such an Adapter . This configuration allows a decoupled Prometheus monitoring setup without the main application needing to know anything about Prometheus. The full example in our GitHub repository demonstrates this setup together with a Prome‐ theus installation. 136  |  Chapter 16: Adapter Figure 16-1. Adapter pattern